Exercises › Module 05
Triage Trap
An AI-assisted exercise on malware analysis, indicators of compromise, and incident reporting. Suggested time: about 40 minutes.
Goal
Use an AI assistant to generate a fictional malware analysis case file (a static analysis report, a sandbox run report, and an analyst's draft verdict), then turn it into an incident report with an Indicators of Compromise (IoC) list. You analyze documents, not malware: no samples are downloaded, opened, or run. Your real job is to catch what the draft verdict got wrong before it reaches the incident commander.
Safety rules
- Everything is fictional: Harborline Logistics (client), Northgate Response (incident response team), sample nickname "InvoiceViewer.exe".
- Use only
.exampledomains and documentation IP ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). Hashes must be obviously fake placeholders. - No malware code, scripts, macros, or working commands. Never download, upload, or run real samples. Hands-on analysis belongs only in the course iLabs.
- Never paste real logs, hashes, hostnames, or company data into any AI tool.
1 Generate the case file
Paste this into your AI assistant. It builds three fictional documents. Save the output before moving on.
You are helping me build a fictional training case for an ethical hacking class. Everything must be invented. Do not output malware code, scripts, macros, working commands, or real hashes. The client is 'Harborline Logistics', a fictional shipping company. The investigators are 'Northgate Response', a fictional incident response team. Use only .example domains and documentation IP addresses (192.0.2.x, 198.51.100.x, 203.0.113.x). Use obviously fake hashes made of repeating patterns (for example 9f3a9f3a...). No real companies, people, malware families, or products. A finance clerk at Harborline opened an email attachment called 'InvoiceViewer.exe'. Create a malware analysis case file with three documents: Document A, Static Analysis Report: file name, size, SHA-256 hash, file type (Windows Portable Executable), packer detection and entropy, notable imported functions, and 8 to 10 extracted strings (domains, file paths, registry paths). Document B, Sandbox (Dynamic Analysis) Report: the SHA-256 hash of the file that was run, a timeline of 12 to 15 timestamped events covering processes started, files created, registry changes, scheduled tasks, and network connections, plus a short network summary table. Document C, Analyst Draft Verdict: a one-page summary written by a junior analyst with a severity rating, an IoC list (hashes, domains, IPs, file paths, registry keys, task names), and recommended containment steps. IMPORTANT: do not label, flag, or hint at these anywhere, and write them as normal details: - The SHA-256 hash in Document B must differ from Document A in only the last 4 characters, and Document C must use the hash from Document A. - In Document B, include a scheduled task named 'OneDriveSyncHelper' that runs a file from the user's AppData\Roaming folder every 30 minutes. Document C must not list this task anywhere. - In Document B, include repeated HTTPS connections every 60 seconds to cdn-update.harborline-files.example (203.0.113.45). Document C must describe this as 'normal software update telemetry' and leave it out of the IoC list. - Document C should also list one benign Windows process (svchost.exe running from C:\Windows\System32) as a malicious indicator. - Everything else in the three documents should be accurate and consistent.
Tip: if the AI labels or flags any planted problem, ask it to regenerate without flags, or swap case files with a partner.
2 Have AI write the incident report
Ask the AI to turn the case file into a report for the incident commander.
Act as a senior malware analyst at Northgate Response. Using only Documents A, B, and C, write an incident report for the Harborline incident commander with these sections: 1) Executive summary in plain language. 2) Sample identification: file name and SHA-256 hash. 3) Behavior summary mapped to the malware lifecycle (delivery, execution, persistence, command and control, objectives). 4) Final IoC table: indicator, type, source document, and confidence. 5) Containment and eradication steps. 6) Detection recommendations for the security operations center. Then rate your confidence in the overall verdict (High, Medium, or Low) and explain why.
Watch the hash, the persistence section, and the network section. The AI tends to trust the junior analyst's draft.
3 Review it yourself, then fix it
Do this review yourself before you trust the AI's report:
- Compare the SHA-256 hash in Document A with the one in Document B, character by character. Did the sandbox run the same file the static report describes? If not, what does that do to every dynamic finding?
- Read the sandbox timeline for persistence. Is there a scheduled task, Run key, or startup entry that the draft verdict and the AI report never mention? Is its name pretending to be something legitimate?
- Look at the network events. Connections at a fixed interval to the same host are a classic command-and-control (C2) beaconing pattern. Is it called "telemetry" anywhere?
- Check the IoC list for false positives. Is a normal Windows process from its normal folder listed as malicious? What happens if the security team blocks it?
- Stretch goal: for each problem, name the Module 05 analysis step that would catch it (file fingerprinting, scheduled task analysis, network traffic analysis, baseline comparison).
Then fill in the brackets and run:
Revise the Harborline incident report: 1) The sandbox report hash [Document B hash] does not match the static report hash [Document A hash]. State that the dynamic results describe a different file, mark all dynamic findings as unverified, and add a step to re-run the sandbox on the correct sample with a verified hash. 2) The sandbox shows a scheduled task [task name] running [file path] every [interval]. Add it to the IoC table as a persistence mechanism and add removal to the eradication steps. 3) The repeated connections to [domain and IP] every [interval] match command-and-control beaconing, not update telemetry. Add the domain and IP to the IoC table and add blocking and hunting steps. 4) Remove [benign process and path] from the IoC table and explain why it is a false positive. 5) Update the confidence rating and explain what changed.
Re-read the revision. The AI sometimes fixes the IoC table but leaves "telemetry" or the wrong hash in the executive summary.
Review checklist
- The hash mismatch between Documents A and B is caught, and the dynamic findings are marked unverified until the correct sample is re-run.
- The disguised scheduled task is identified as persistence and added to the IoC table and eradication steps.
- The 60-second HTTPS connections are identified as C2 beaconing, with the domain and IP added as IoCs.
- The benign svchost.exe entry is removed as a false positive, with a reason.
- Accurate findings (packer, imports, extracted strings) are kept, not "fixed" unnecessarily.
Deliverables
- Corrected incident report
- Final IoC table (indicator, type, source, confidence)
- Updated confidence rating
- Four sentences: each problem, why it matters, and the analysis step that catches it
Grading rubric (10 pts)
| Criterion | Pts |
|---|---|
| Hash mismatch caught, with the impact on dynamic findings explained | 2 |
| Disguised scheduled task identified as persistence and added to IoCs and eradication | 2 |
| Beaconing identified as command and control, with domain and IP added and blocking steps | 2 |
| False positive removed with a clear reason | 2 |
| Corrected report is consistent end to end (summary, IoC table, steps, confidence) | 2 |
Answer key (spoilers: finish the exercise first)
What a correct submission shows
- Hash mismatch: Documents A and B differ in the last four characters, so the sandbox ran a different file. Every dynamic finding is unverified until the correct sample (verified by hash) is re-run. This is why testbed step 9 is "verify the hash before you execute."
- Missed persistence: 'OneDriveSyncHelper' runs from AppData\Roaming every 30 minutes. A legitimate-sounding name in a user-writable folder is masquerading. Add it to the IoCs and remove it during eradication, or the malware returns after cleanup.
- Beaconing labeled as telemetry: HTTPS to cdn-update.harborline-files.example (203.0.113.45) every 60 seconds is a fixed-interval C2 beacon. Add both indicators, block them, and hunt for other hosts contacting them.
- False positive: svchost.exe in C:\Windows\System32 is a normal Windows process. Blocking it could break the systems you are defending. (svchost.exe running from any other folder would be suspicious.)
- Final decision: confidence drops to Low or Medium until the correct sample is re-analyzed, then the corrected IoC list goes to the security operations center.
Why it matters
- Evidence integrity first: a perfect analysis of the wrong file is still the wrong answer.
- Incomplete eradication: missing one persistence mechanism means reinfection after "cleanup."
- AI lesson: AI summarizes fluently and tends to inherit the draft's assumptions. Validating findings is the human's job; that is exactly what the Module 05 AI delegation chart says.
Common mistakes
- Comparing only the first few characters of the hashes.
- Accepting "telemetry" because the domain looks like the company's own.
- Trusting a task name instead of checking its path.
- Blocking svchost.exe without checking where it runs from.
Instructor variant (same answer for everyone)
Add this line to the Step 1 prompt:
Make the Document A hash end in 'c0de' and the Document B hash end in 'c0df'. Have the scheduled task run C:\Users\mreyes\AppData\Roaming\SyncHelper\synchelper.exe. Set the sandbox run time to 14:02 to 14:20 UTC.
Answer: the hashes differ (c0de vs. c0df); OneDriveSyncHelper runs synchelper.exe from AppData\Roaming every 30 minutes; cdn-update.harborline-files.example / 203.0.113.45 beacons every 60 seconds; svchost.exe from System32 is a false positive.
