Intermediate·300 points·2 solves
PowerShell Attack Investigation
Learn to investigate PowerShell abuse the way it actually presents in a managed Windows estate: as one edge in a process tree rather than one suspicious string. You will group Sysmon process creations by parent, decode a base64 UTF-16LE command by hand, correlate script-block logging with process creation and file-write events, and separate a real intrusion from deployment tooling that looks far worse than the attack does.
Encoded PowerShell is not suspicious. -EncodedCommand is how Configuration Manager, Group Policy, scheduled tasks and most endpoint agents invoke PowerShell, because it is the only reliable way to pass a script containing quotes and newlines through a command line. A managed estate produces these constantly, and this one produces dozens in a single day. Any triage approach that starts by filtering for encoded commands, or by decoding everything and looking for something that reads badly, will drown — one of the entirely legitimate deployment scripts here is longer, uglier and more heavily nested than the attack is. The question worth asking is not what the command said but what started it. Ask which processes ought to be able to launch an interpreter at all: a deployment agent, a scheduled task, an installer running a post-install action and a Group Policy script all legitimately do. A process whose job is to render a document to a human legitimately does not, and when one does it means the content itself executed code. Evidence is in /var/log/soc: start with incident-brief.md, then sysmon.log (process creation and file writes), powershell-operational.log (script-block text, already decoded by the logging subsystem), wazuh-alerts.json and asset-inventory.csv. powershell-reference.md explains the fields and the decoding step.
Your tasks
1
Read the brief, then measure the noise
Open incident-brief.md first — it tells you what was reported and, importantly, what the SOC has already failed to get anywhere with. Then count how many processes in sysmon.log ran with -EncodedCommand. The number is the point of the exercise: it tells you immediately that "encoded" is not a filter, and the exact figure is one of the answers.
2
Group process creations by their parent
Take only the encoded-command process creations and aggregate them by ParentImage, then sort by frequency. A handful of parents account for nearly all of them and every one of those is ordinary management tooling. Do not simply take the rarest — more than one parent appears exactly once here, and one of those is a perfectly normal installer action. Decide on the merits which parent has no business starting an interpreter, and be ready to justify it. Note that the parent also appears elsewhere in the log doing something entirely routine, so grepping its name alone will not isolate anything.
3
Identify the host, the account and the moment
Once you have the offending parent-child edge, read that Sysmon record properly: Computer, User and UtcTime. Cross-check the host against asset-inventory.csv to see whose machine it is and what the department does, because that determines how bad this is. Answers are expected in UTC on a twenty-four hour clock.
4
Decode the command
The command arrived base64-encoded as UTF-16LE, which is what -EncodedCommand takes. Decode it with `base64 -d | tr -d '\0'` — the tr strips the null bytes UTF-16LE leaves between ASCII characters. Then check yourself against powershell-operational.log: script-block logging (EID 4104) records the text PowerShell compiled after decoding, so the plain text was already there. Knowing both routes matters, because script-block logging is not always enabled.
5
Separate downloading from downloading somewhere bad
Several script blocks in this log construct a web client and fetch a file, and the logging subsystem raises the level on all of them. Most are legitimate: management scripts pull configuration and inventory data from internal servers constantly. Compare each destination against the approved ranges and internal hostnames in asset-inventory.csv. Exactly one reaches outside the estate — record the host it contacts and the full path of the file it writes to disk.
6
Follow the payload and map the activity
The write itself is recorded as a separate Sysmon event with its own hash, and something executes the dropped file moments later — find both and note the recorded SHA-256. Then map what you have to ATT&CK. Two techniques are wanted and they are different claims: one names the interpreter that was abused to execute code, the other names the fact that the command was encoded to make it harder to read. Do not use one where the other belongs.
Answer the questions
Start the lab, investigate the evidence in the terminal, and answer the questions here.