Hands-on exercises

Alert. The rule claims a service account created a scheduled task, a rule-based detection on event 4698. First parsing action: decode the command. The base64 resolves to a downloader that pulls a payload from files-cdn-sync[.]net, the same domain in the proxy artifact. The heaviest validation artifact is the authentication log: logon type 10 means someone opened an interactive RDP desktop as a service account, and the baseline says that has never happened in 90 days. Task-creation alerts are common; a service account with an RDP session is the anomaly that carries the case.

Subject. The principal on the alert is svc-printmgmt, but a service account is a credential, not an actor. Candidates: (a) an administrator legitimately using the account, (b) an automation process on wkst-hr-22, (c) a human attacker who has obtained the account’s credentials and is operating from wkst-hr-22. The logon type discriminates: services and automation authenticate with network or service logons, not RemoteInteractive sessions at 03:24 on a Sunday. The working subject is whoever controls wkst-hr-22, acting through stolen or shared service-account credentials. Four dimensions on that composite subject: authentication abnormal (first RDP in 90 days), authorization abnormal (an HR workstation has no business path to a print server), behavior abnormal (task creation, encoded PowerShell), relationships now spanning two hosts and one service identity.

Scope. Entities: prt-01, svc-printmgmt, wkst-hr-22, and wkst-hr-22’s assigned user as a distinct fourth entity whose own compromise is now the leading question. Window: 03:00 UTC to now for the active intrusion, with a longer lookback (7 days minimum) on wkst-hr-22, because the workstation was compromised at some earlier, unknown time. Deliberately out: the other print servers and every other host svc-printmgmt can reach, until Uncover produces evidence of contact; the observation that pulls them in is any successful authentication from either compromised host.

Uncover. Sources in order: EDR on wkst-hr-22 (how was it compromised, what else has it touched), the decoded payload and EDR on prt-01 (what the task actually does), domain authentication logs filtered on svc-printmgmt and on wkst-hr-22 as source (lateral spread), proxy history for both hosts (C2 and staging). The timeline’s two required answers: how did wkst-hr-22 obtain service-account credentials, and what has executed on prt-01 since 03:24. Leading hypothesis: hands-on-keyboard lateral movement from a compromised workstation, with the scheduled task as persistence. Strongest surviving alternative at the start: an administrator doing undocumented weekend maintenance from a borrowed desk; it dies quickly (no change ticket, HR workstation, encoded downloader), and the ledger records why.

Risk. Impact high: an attacker with working service-account credentials and interactive access on a server is positioned to reach anything that account and host can touch; print servers commonly hold broad connectivity plus credential material in spooler and vendor services. Likelihood high: the chain (unexplained RDP, task named to mimic an OS component, encoded downloader, outbound to a domain absent from a 90-day baseline) is multi-source and has no surviving benign explanation. High × high: escalate immediately.

Escalation. Confirmed criteria: lateral movement (the RDP hop from wkst-hr-22 to prt-01, confirmed the moment the authentication log was read and baselined), and confirmed malicious activity (the decoded downloader plus the outbound transfer). Under the break-glass rule, escalation fires during validation or early Uncover, at the moment the RDP hop is confirmed as unexplainable, not after the phases complete. Working the rest of the arc after that point happens under IR’s clock, as scoping support.

Documentation. Summary model: “Interactive RDP session as service account svc-printmgmt from HR workstation wkst-hr-22 to print server prt-01 at 03:24 UTC Sunday, followed by creation of a persistence task masquerading as an OS component and an encoded PowerShell downloader with confirmed outbound transfer to a domain outside the host’s 90-day baseline. Assessed as hands-on-keyboard lateral movement from a previously compromised workstation; escalated on the lateral-movement criterion.” Detection feedback: the 4698 rule fired at persistence, late in the chain. The earlier, cheaper signal is the authentication event: interactive or RemoteInteractive logons (types 2 and 10) by any svc-* principal should alert on their own. That rule would have fired at 03:24, seventeen minutes before this one.

Traps planted in this packet. Anchoring: the alert names a Medium-severity task-creation event, and the task’s OS-flavored name invites a “Windows doing Windows things” dismissal. The case pivots on an artifact the alert never mentions. Availability: if your last service-account case was a misconfigured backup job, candidate (b) feels more likely than the evidence supports. The logon type is the discriminator that beats both.

Alert. The detection is correct: an unverified-publisher app did receive tenant-level consent. The open question is context, and the verdict this is heading toward is a benign true positive: the logic matched exactly what it describes, and the local context (a sanctioned migration) clears it. That is not a false-positive, and recording the difference matters, because a false-positive verdict would send tuning feedback against a rule that is working.

Subject → Uncover. Verifiable claims, verified: the ticket’s executor matches the consenting account (adm-jkoh on both); the consent timestamp sits inside the ticket’s window (10:02 inside 09:00-17:00); the app’s activity source range matches the vendor’s documented range (198.51.100.32/28 on both); the consent ceremony is consistent with a human administrator (interactive, MFA, corporate device), not a hijacked session. Checks the artifacts cannot satisfy: whether the app’s publisher identity is actually CloudShift’s registered application rather than a lookalike display name, which requires the app ID from the vendor’s onboarding doc or a call to the vendor, because display names are attacker-choosable; whether adm-jkoh actually performed the consent, which one out-of-band message to the ticket owner settles; and whether the read volume matches the wave’s expected site collections, which the migration runbook answers. The name-versus-identity check is the load-bearing one: timing an attack inside someone else’s maintenance window, with a plausibly named app, is an established adversary pattern.

Risk. Model verdict: “Impact if hostile would be high (tenant-wide file read with standing access), but likelihood is low: the consent’s principal, timing, source range, and ceremony all match an approved change record, and the app identity was confirmed against the vendor’s registered application ID rather than its display name. Assessed as benign true positive: sanctioned migration activity correctly flagged by a correctly-broad detection. Residual risk: the standing consent outlives the migration; a decommission check is scheduled with the ticket’s closure.” The close-on-sight stopper: until the app ID and the executor were verified, the ticket was a hypothesis, not an explanation. A change ticket in the search results is a fact about the change-management system, not about the consent event.

Escalation → Documentation. The close should produce a pattern-library entry (“OAuth consent by IT admin during documented migration wave”) so waves 4 and 5 are Level 0 closes against named discriminators. The two fields that must be re-verified every wave: the consenting principal against the wave’s ticket executor, and the application ID against the vendor’s registered app. The fields that may be inherited: the vendor’s source range and the window structure. An entry whose discriminators are “there was a ticket” will eventually close the real thing.

Traps planted in this packet. Deference and premature closure: the change ticket radiates authority, and everything after it reads as confirmation. The packet is passed only by treating the ticket as one more claim to verify. Automation bias variant: the vendor’s own doc supplied the IP range, and the range matching proves the traffic is from the vendor’s infrastructure, not that the app is the vendor’s app.

The close. All four discriminators check against the artifact: ci-build-14 is in ci-build-agents (1 ✓), the top process is bazel (2 ✓), the destination string matches the entry’s named endpoint (3 ✓), and 02:47 falls inside 01:30-04:30 (4 ✓). This is a legitimate Level 0 close: pattern PTN-017, checks recorded as the four observations above, verdict “expected nightly CI load, matches documented pattern,” disposition closed with analyst and timestamp. Total honest time: under three minutes, and every field filled from the artifact.

The failures that force Level 1. (1) The same alert on wkst-hr-22: a host outside the group means the pattern does not apply at all, whatever else matches. (2) Top process xmrig, or anything that is not the named toolchain: the load is real but the worker is wrong. (3) Destination cache.buildcache-vendor.io.cdn-relay[.]net or any string that merely contains the endpoint: the discriminator is an exact match to the entry’s named host, and lookalike suffixing is exactly how miners hide in CI. (4) The identical alert at 14:00: nightly load at midafternoon is a schedule anomaly the pattern does not cover. Any failure moves the case up the ladder, and per the ladder rules it does not slide back down mid-case.

The trap being drilled. The pattern reflex: by the twentieth night, the reflex is to close on the rule name alone. The five-minute close stays defensible only because the discriminators were checked against this alert’s fields. The one that rusts first is (3), because “the destination looked right” and “the destination string equals the entry’s named endpoint” feel identical at queue speed and are not.