Security Operations · Topic 7 of 7
Analyzing Incident Artifacts
Interpret malware samples, email headers, memory, disk, network and cloud artifacts, and build a timeline to scope an incident and find the root cause.
- 5 min
- Static analysis does not execute the sample, and dynamic analysis observes behavior in a sandbox.
- Always analyze malware in an isolated environment.
- Read email Received headers from bottom to top.
What it is
An artifact is a piece of data left by activity: a log entry, a file, a registry or configuration change, a network connection, an email header. Incident analysis is the work of reading artifacts to decide what happened, how far it spread and how the attacker got in.
No artifact is conclusive alone. Analysts combine several, build a timeline, and separate facts from assumptions.
How it works
Malware analysis
Analysts examine suspicious files in a safe, isolated environment, never on a production machine.
| Approach | What it does | Strength | Limit |
|---|---|---|---|
| Static analysis | Examines the file without running it: hashes, readable strings, imports, structure | Safe and fast | Packing and obfuscation hide content |
| Dynamic analysis | Runs the sample in a sandbox and watches file, registry, process and network behavior | Shows what it does | Some malware detects the sandbox or waits |
| Reverse engineering | Studies the code in depth | Full understanding | Slow and skilled |
Hash lookups against intelligence sources can quickly flag known samples. Extracted indicators, such as contact addresses and mutex names, feed blocking and hunting. Rules written in a pattern language such as YARA can then search for related samples.
Email artifacts
Email headers record the path and the checks. Read the Received lines from the bottom up, since each server adds its line on top, so the earliest hop is at the bottom. Compare the From address with Return-Path and Reply-To, since a mismatch is a common sign of spoofing.
Three authentication checks appear in headers.
| Check | What it verifies |
|---|---|
| Sender Policy Framework (SPF) | The sending server is authorized for the domain |
| DomainKeys Identified Mail (DKIM) | A digital signature shows the message was not altered and ties it to a domain |
| Domain based Message Authentication, Reporting and Conformance (DMARC) | A policy that tells receivers what to do when SPF and DKIM do not align with the visible From domain |
Passing these does not make mail safe, since attackers can register look alike domains that pass all three.
Memory, disk and host artifacts
Memory shows running processes, loaded modules, network connections and code injected into other processes, and it may hold decrypted data or keys. Disk and host artifacts include file timestamps, deleted file remnants, scheduled tasks, services, startup entries, browser history and user account changes. Persistence mechanisms are a priority: anything that restarts the attacker's access after reboot.
Compare against a known good baseline or golden image to spot additions. Treat timestamps with care, because attackers can alter them, and time zones can mislead.
Network and authentication artifacts
Flow records and packet captures show command and control beacons, which are regular, repeated connections, and large outbound transfers that suggest exfiltration. Domain Name System (DNS) logs show lookups of suspicious domains and unusual query patterns. Proxy logs show web destinations and volumes.
Authentication logs reveal lateral movement: one account signing in to many hosts, new remote administration sessions, or sign ins at odd times. Privilege changes and new accounts show escalation and persistence.
Cloud and application artifacts
Cloud audit logs record who called which control plane action, from which address and with which credential. Look for new access keys, changed policies, new compute resources and snapshots shared outside the account. Application logs and database audit logs show what data was queried or exported.
Hardware analysis
When a device cannot be examined through its operating system, analysts go to the hardware. Joint Test Action Group (JTAG) is a standard test and debug interface that can allow memory and storage to be read, and a universal asynchronous receiver transmitter (UART) serial console may expose a boot menu or shell.
Chip off analysis removes a memory chip from the board and reads it with a reader, which is a destructive last resort. Firmware extraction copies the firmware image so that it can be compared with the vendor's known good version to find implants or tampering.
Document every step, work on copies, and weigh the risk of damaging the evidence.
Building a timeline
Normalize all times to one standard, usually coordinated universal time (UTC), then order events from all sources. A timeline shows the first sign of compromise (patient zero), the path the attacker took, what they accessed and when they were contained. Gaps in the timeline show where data is missing.
Root cause and scoping
Scoping answers which systems, accounts and data were affected, which drives containment, notification duties and recovery. Root cause explains the weakness that allowed entry, such as an unpatched service or a stolen credential, so it can be fixed. Fixing only the symptom leaves the door open.
What to remember for the exam
- Static analysis does not execute the sample, and dynamic analysis observes behavior in a sandbox.
- Always analyze malware in an isolated environment.
- Read email Received headers from bottom to top.
- SPF checks the sending server, DKIM checks a signature, and DMARC sets a policy based on SPF and DKIM results that align with the visible From domain.
- Passing email authentication does not prove a message is legitimate.
- Memory holds evidence of injected code and active connections that disk may not.
- Regular beacons suggest command and control, and large outbound transfers suggest exfiltration.
- A single time standard is needed to build a reliable timeline.
When a question shows a header chain, find the earliest Received line at the bottom, then compare the sender domain with the Return-Path.
Common mistakes
Running a sample on a normal workstation. Always use an isolated lab.
Trusting one artifact. Timestamps and logs can be altered, so corroborate with other sources.
Stopping at the first infected host. Look for lateral movement and persistence elsewhere.
Confusing SPF with DKIM. SPF is about who may send, while DKIM is a signature on the message.
Opening suspicious attachments or links to analyze them outside a sandbox can infect the analyst's own system.
Check yourself
Work through these three questions.
Which analysis type runs the sample and observes its behavior?
Dynamic analysis, usually in a sandbox.
Why read email Received headers from the bottom?
Each mail server adds its line at the top, so the original sending hop is at the bottom.
Why build a timeline during an incident?
It orders events across sources to show the entry point, the attacker's path and the full scope.
Topic 7 of 7 in Security Operations
Test yourself on Security Operations
The full CompTIA SecurityX CAS-005 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.