CySA+ CS0-004 Tools to Determine Malicious Activity: CyberChef, Wireshark, Suricata, Zeek, YARA, Sandboxes and More

CyberChef (an open-source browser tool from GCHQ) decodes obfuscated data by chaining operations into an ordered recipe: the output of each step becomes the input of the next. It runs entirely in the browser, needs no code, and a recipe can be saved, shared as a URL or reused on the next sample. Typical operations are From Base64, From Hex, URL Decode, Gunzip, Raw Inflate, XOR, Decode text, Remove null bytes, Extract URLs and Extract IP addresses. The Magic operation tries likely decodings automatically when you do not recognise the encoding.

Recognise the encoding before you choose the operation

Encoded PowerShell

PowerShell's -EncodedCommand switch (accepted abbreviated as -enc or -e) takes the command as Base64 of UTF-16LE text. From Base64 alone exposes the command but with a null byte after every ASCII character, because UTF-16LE spends two bytes per character; adding Decode text: UTF-16LE (1200) gives clean text. Reading it as UTF-8 leaves the nulls in. Attackers often add a second layer, for example a Base64 string that is itself gzip-compressed inside the script, so you keep adding operations (From Base64, Gunzip) until readable text appears. What usually surfaces is a download cradle such as IEX (New-Object Net.WebClient).DownloadString(...): fetch a script from a URL and run it in memory.

CyberChef answers "what does this blob say?". It does not tell you whether a file is known malware (VirusTotal), what the traffic was (Wireshark, Zeek) or how a sample behaves (a sandbox).

tcpdump is a command-line packet capture tool, ideal on servers without a graphical interface; Wireshark is the graphical analyser that dissects every protocol field. The usual workflow is to capture with tcpdump on the host or sensor, write a pcap file, and open it later in Wireshark.

tcpdump essentials

• -i eth0 picks the interface; -w file.pcap writes raw packets in pcap format (what Wireshark reads); -r file.pcap reads a saved capture back.
• -n skips name resolution, -A prints payloads as ASCII and -X as hex and ASCII. Only -w produces a capture file that Wireshark can open.
• -c 1000 stops after a number of packets; -s 0 captures whole packets.
• The filter at the end is a BPF capture filter: host 203.0.113.50 (either direction), src host / dst host, net 10.0.0.0/8, port 443, tcp / udp, combined with and, or, not.

tcpdump -i eth0 -n -w web01.pcap host 192.0.2.10 and not port 22

Capture filters versus display filters

Wireshark has two filter languages, and mixing them up is the most common error.

Useful display filters: ip.src and ip.dst (direction matters: an upload is a request whose destination is the external server), ip.addr (either direction), dns.qry.name contains "example", tls.handshake.extensions_server_name (the SNI of a TLS session), http.request.uri and frame contains "password". Filtering on a port alone keeps every packet of those connections, including replies and handshakes. Follow TCP/HTTP stream rebuilds a whole conversation as text, Statistics > Conversations shows who talked to whom and how much, and File > Export Objects > HTTP carves transferred files out of cleartext HTTP.

Snort and Suricata are signature-based IDS/IPS engines that alert on (or block) traffic matching rules; Zeek is a network security monitor that writes structured metadata about all traffic whether or not anything matched.

Reading a rule

Snort and Suricata share a rule format: a header (action, protocol, source address and port, direction, destination address and port) followed by options in brackets.

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"Inbound SSH root login attempt"; flow:to_server,established; content:"root"; nocase; sid:1000200; rev:1;)

• $HOME_NET and $EXTERNAL_NET are variables for internal and external ranges; -> fixes direction (<> means either). The protocol (tcp, udp, icmp, http in Suricata) must match too.
• flow:to_server,established inspects only packets from the client (the side that opened the connection) in an established session; to_client / from_server inspects the replies.
• content matches bytes in the payload; nocase makes it case-insensitive. msg is the alert text, sid the unique rule ID (local rules use 1000000 and above), rev its revision.

Think about who opens the connection: in a reverse shell the victim connects out to the attacker's listener, so a rule for it runs from $HOME_NET to $EXTERNAL_NET, and the shell banner travels to_server.

Rule actions

Moving a validated rule from alert to drop is the normal way to start blocking a confirmed threat: blocking is decided by the rule's action, nothing else. Suricata writes alerts and protocol events as JSON lines to eve.json (see the file-formats section).

Zeek logs

Zeek writes one log per protocol, all linked by a connection uid:

• conn.log: every connection with timestamp, duration, bytes and packets each way, and connection state. Regular intervals and near-identical byte counts here expose beaconing even when the payload is encrypted.
• dns.log: queries and answers; http.log: methods, hosts, URIs, user agents; ssl.log: TLS version, cipher and server name (SNI), with certificate details in x509.log (TLS 1.3 encrypts the server certificate; JA3/JA4 client fingerprints can be added with packages); files.log: transferred files with hashes; notice.log: notable events raised by Zeek's detection scripts; weird.log: protocol oddities.
• Logs built from payload content need a payload Zeek can read. For an encrypted session, the timing, volume and handshake metadata in conn.log and ssl.log are what remain.

Because Zeek records everything compactly, hunters can search weeks of history for a new indicator after the fact, which neither a signature engine (alerts only on matches) nor raw tcpdump storage (unstructured, huge) offers. Tools such as RITA analyse Zeek logs for beacons.

A SIEM collects logs from many sources, parses and normalizes them into common fields, and lets analysts search, correlate and alert across sources; UEBA adds behavioural baselines per user and entity so it can flag activity that breaks no rule.

Normalization decides whether correlation works

A correlation rule (for example, "a firewall allow followed by a proxy download by the same host within ten minutes") compares fields and times across sources. If one source logs UTC and another local time without an offset, matching events land hours apart and the rule silently never fires. The root-cause fix is to normalize timestamps at ingestion: parse each source with its correct time zone and store everything in UTC (and keep sources synchronized with NTP). Workarounds that leave the time base wrong only hide the skew and add unrelated matches. The same applies to fields: a parser that maps src, SourceIP and client_ip to one normalized field is what makes a single query work across firewall, proxy and endpoint logs. Correlation problems are fixed where the data is parsed, not where it is stored or shipped.

Typical SIEM analysis steps

• Search and filter by indicator (IP, hash, domain, user) across all sources for the incident window.
• Aggregate: count by source, user or destination to find the outlier (top talkers, rare processes, failed-then-successful logins).
• Correlate events from different sources on shared fields and time.
• Enrich with threat intelligence, asset criticality and identity data before deciding severity.

UEBA: when no rule fires

Rules, thresholds and signatures only catch patterns someone wrote down. An insider or a stolen account using valid credentials and existing permissions may stay under every organisation-wide threshold. UEBA models what is normal for each user and entity (working hours, data volumes, hosts and applications used, peer-group behaviour) and raises a risk score when behaviour departs from that baseline, for example a 2 a.m. copy many times the user's usual volume. OpenUBA is an open-source UEBA framework; commercial SIEM and XDR products ship UEBA modules. UEBA needs a learning period and produces risk signals to investigate, not verdicts.

All three store and share indicators of compromise, but they differ in who hosts them and what they are built for: OTX is a free hosted community service, MISP is self-hosted software for sharing events between organisations, and OpenCTI is self-hosted software for modelling intelligence as a STIX 2.1 knowledge graph.

They combine rather than compete: OpenCTI's connectors import from MISP, OTX and other feeds, so an organisation can keep its existing sharing arrangements and still analyse everything in one graph. Single-indicator reputation services (covered below) answer a narrower question than any of these platforms.

EDR records detailed telemetry on each endpoint and lets responders act on it remotely; XDR extends detection and correlation across several security layers; MDM manages and enforces policy on mobile devices.

EDR

An EDR agent records process creation with command lines and parent processes, file and registry changes, network connections and module loads, and presents them as a process tree and timeline. Response actions include killing a process, quarantining a file, collecting files or memory, running live-response scripts and network isolation (containment). Isolation applies host firewall rules that block everything except the channel to the EDR console, so the host can no longer reach shares or other machines while the responder can still investigate it remotely. That is why it is the usual first containment step: it stops spread while keeping volatile evidence and remote investigation available.

XDR

EDR sees only endpoints. XDR ingests telemetry from endpoint, email, identity, cloud and network sources and stitches related alerts into one incident with a shared timeline, for example a phishing email, the process it launched and a suspicious cloud sign-in by the same account.

MDM

MDM enrols phones and tablets, enforces compliance (passcode, encryption, OS version, jailbreak/root detection) and can lock, locate or wipe them. On personally owned (BYOD) devices, corporate apps and data live in a managed container or work profile; a selective wipe (called retire or enterprise wipe in some products) removes only that container and its managed apps, leaving personal photos and apps untouched. A full wipe factory-resets the device and suits lost, stolen or company-owned devices. Identity-side controls govern future sign-ins; only a wipe acts on data already stored on the device. MDM compliance status is also a useful signal in investigations (a rooted device or one out of compliance).

Reputation tools answer different questions about an indicator: WHOIS/RDAP says who registered a domain or holds an IP block and when; AbuseIPDB says whether others have reported an IP for abuse; GeoIP estimates where an IP address is; MXToolbox checks a domain's mail records, blocklists and message headers.

Weak versus strong signals

A newly built attack domain has no reputation history, so clean lookups prove little. Weigh each finding by whether legitimate sites commonly share it: attributes that most normal domains also have are weak on their own, while evidence that the domain was set up specifically for this campaign (its age relative to the lure, a name imitating your brand, infrastructure shared with known-bad domains) is strong.

GeoIP and impossible travel

Impossible-travel detections compare GeoIP locations of consecutive sign-ins. When one address belongs to a commercial VPN, proxy or cloud ASN, the "travel" may be the user's own VPN, but attackers use the same services. Location alone justifies neither dismissing the alert nor a drastic response: corroborate it with other evidence about the sign-in, then decide.

Email: SPF, DKIM and DMARC in headers

Paste a message's full headers into MXToolbox's header analyzer to see the hop path and the Authentication-Results line. SPF checks whether the sending IP is authorized for the envelope-from domain; DKIM checks a cryptographic signature over the message; DMARC passes when SPF or DKIM passes and aligns with the visible From domain, and its policy tells receivers what to do on failure:

• p=none: monitor and report only, so a failing message can still be delivered to the inbox.
• p=quarantine: treat failures as suspicious (spam or junk folder).
• p=reject: refuse failing messages.

Each mechanism reports its own result. none means no record was found to check against, while fail and softfail mean a record was found and the sending server did not match it.

File analysis moves from cheap and safe to slow and revealing: static inspection without running the file (strings, hashes, YARA), reputation (VirusTotal), then dynamic analysis by detonating it in a sandbox (Joe Sandbox, Cuckoo).

strings

strings prints runs of printable characters, revealing URLs, IP addresses, file paths, registry keys, commands and API names. GNU strings by default looks only for single-byte (ASCII) characters of at least four characters. Windows programs often store text as UTF-16LE, where each ASCII character is followed by a 00 byte, so those strings are invisible by default; strings -e l searches for 16-bit little-endian text (-e b is big-endian, -e L/-e B are 32-bit). The other options change what is printed (for example -n, the minimum length); the encoding searched is set only by -e. Sysinternals strings on Windows searches ASCII and Unicode by default. Packed or encrypted samples show few useful strings at all, which is itself a finding.

VirusTotal: search the hash before uploading

VirusTotal scans files and URLs with many antivirus engines and shows behaviour and relationship data. Uploaded files are shared with the security community and premium subscribers, and attackers monitor for their own tooling. For a sensitive or targeted sample (containing internal hostnames, or when you do not want to tip off the attacker), search by SHA-256 hash: it reveals an existing report without disclosing the file. An unknown hash suggests custom or freshly repacked malware. Public sandbox services have the same disclosure problem as an upload. A detection count is evidence, not a verdict: zero detections does not prove a file clean.

YARA rules

YARA matches files against rules with three parts: optional meta, strings and a condition.

rule Example_Stealer
{
    meta:
        author = "SOC"
    strings:
        $a = "Login Data" ascii wide
        $b = "wallet.dat" nocase
        $h = { 6A 40 68 00 30 00 00 }
    condition:
        uint16(0) == 0x5A4D and filesize < 2MB and ($h or 2 of ($a, $b))
}

• A text string with no modifier matches ASCII only. wide matches the UTF-16 form (each character followed by 00); ascii wide matches both; nocase ignores case; fullword requires non-alphanumeric boundaries.
• Hex strings in braces match byte sequences and can include wildcards (??).
• uint16(0) == 0x5A4D checks the first two bytes are "MZ" (read little-endian), so only Windows PE files qualify. and, or, parentheses, any of them, 2 of ($a, $b) and filesize build the logic.

Evaluate a rule string by string: which strings are present in the encoding the modifiers allow, then whether the condition is satisfied.

Sandboxing with Joe Sandbox and Cuckoo

A sandbox runs the sample in an instrumented, isolated VM and reports the process tree, file and registry changes, network activity (DNS, HTTP, dropped connections), screenshots and signature hits. Joe Sandbox is a commercial service (with a free cloud tier whose reports are public). Cuckoo Sandbox is the classic open-source sandbox; the original Cuckoo 2 is no longer maintained, and Cuckoo3 is its successor project (CAPE is a widely used fork).

An empty report does not mean a benign file. Malware evades sandboxes by sleeping longer than the analysis time, checking for virtualization artefacts (VirtualBox or VMware registry keys, drivers, MAC prefixes), waiting for user interaction, or checking language, location or date. Counter it by lengthening the run or accelerating sleeps, using a guest hardened against those checks, simulating a user, or using bare metal; let static findings (a long Sleep, VM-detection strings) tell you which.

Which sandbox findings make good hunting indicators?

A report mixes stable behaviour with values that change per run or per build. Compare runs and keep what the malware reproduces everywhere:

This is the Pyramid of Pain in practice: hashes are trivial for an attacker to change, while behaviour and infrastructure are costlier.

Pattern recognition means writing regular expressions that extract or match indicators in logs, and reading command lines to tell what an attacker was doing.

Regular expressions for IoCs

• . matches any character; a literal dot is \.. Forgetting the backslash lets 10a20b30c40 match an IP pattern.
• \d is a digit, {1,3} one to three repetitions, (?:...) a non-capturing group, ? makes the preceding item optional, \S+ one or more non-space characters.
• \b is a word boundary, so a pattern can match inside a line; ^ and $ anchor to the start and end, forcing the match to be the whole line.
• An IPv4 candidate: \b(?:\d{1,3}\.){3}\d{1,3}\b: exactly three "digits plus dot" groups, then a final group. It still accepts 999.1.1.1, so treat matches as candidates to validate.
• In Python, re.search finds a match anywhere in the string, while re.match only matches at the start, so re.match on syslog lines that begin with a timestamp finds nothing.

Suspicious commands

Attackers favour signed built-in tools (living off the land) because allow-listing trusts them. The parent process and destination matter as much as the command: Word or Excel spawning a shell or downloader is a classic macro infection.

Security data arrives in a few formats, and each needs the right parser: JSON and XML are structured text, YAML is indentation-based configuration, and EVTX is Windows' binary event-log format that must be converted before text tools can read it.

The formats

• JSON: objects of key/value pairs that can nest. Many tools write one JSON object per line (JSON Lines), as Suricata's eve.json does: shared fields (timestamp, event_type, src_ip, dest_ip, proto) sit at the top level, and event-specific details sit in an object named after the event type (alert.signature_id, dns.rrname). Query it with jq; the path must follow that nesting, and a wrong path prints null or nothing.
• XML: tagged elements and attributes. Windows events are XML when rendered (<System> with EventID, <EventData> with named <Data> fields, shown below), and Event Viewer custom views filter them with XPath such as *[System[EventID=4625]].
• YAML: indentation-significant key/value configuration, used for Sigma detection rules (vendor-neutral rules that are converted into SIEM queries), Kubernetes manifests and many pipelines; a mis-indented line changes meaning or breaks parsing.
• EVTX: binary XML with UTF-16 strings, so grep on the raw file finds nothing. Open it with Event Viewer, Get-WinEvent or wevtutil on Windows, or convert it with cross-platform parsers (python-evtx, EvtxECmd, Chainsaw, Hayabusa) into XML, CSV or JSON first.

A Windows failed-logon event rendered as XML (trimmed):

<Event>
  <System>
    <EventID>4625</EventID>
    <Computer>FS01.corp.example</Computer>
  </System>
  <EventData>
    <Data Name="TargetUserName">svc_backup</Data>
    <Data Name="IpAddress">192.0.2.77</Data>
  </EventData>
</Event>

A Sigma rule in YAML that looks for the same thing. Under detection, each named block is a set of field conditions and condition combines them:

title: Failed logons for a service account
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
    TargetUserName|startswith: 'svc_'
  condition: selection
level: medium

Suricata's eve.json queried with jq:

jq -r 'select(.event_type=="dns") | .dns.rrname' eve.json | sort | uniq -c | sort -rn

PowerShell and Windows event IDs

Get-WinEvent -FilterHashtable @{LogName=...; Id=...} retrieves events efficiently; pipe to Where-Object with -match to filter on message text. Know which log holds which event:

Asking a log for an event ID it never contains returns nothing, so pair each ID with its own log.

Shell pipelines

grep filters lines, awk '{print $1}' or cut extracts fields, and sort | uniq -c | sort -rn | head counts and ranks values. uniq only collapses adjacent duplicates, so the input must be sorted first; so always sort before uniq.

A shell script adds variables, loops and conditions around those pipelines, for example to sweep every web log for one indicator:

#!/bin/bash
ioc="198.51.100.200"
for f in /var/log/nginx/access.log*; do
  n=$(zgrep -c "$ioc" "$f")
  if [ "$n" -gt 0 ]; then
    echo "$f: $n hits"
  fi
done

Read it as: set the indicator, loop over each (possibly gzip-compressed) log, count matching lines with zgrep -c, and print only files with at least one hit.

Python

Python handles what one-liners cannot: the re module for patterns (remember search versus match), collections.Counter for tallies, the json and csv modules for structured data, and libraries such as python-evtx for event logs. Read a script line by line: what the pattern matches (optional groups, which group is captured), what is counted, and the threshold applied at the end.

import json
from collections import Counter

hits = Counter()
with open("eve.json") as f:
    for line in f:
        ev = json.loads(line)
        if ev.get("event_type") == "alert":
            hits[ev["src_ip"]] += 1
print(hits.most_common(5))