Security Monitoring practice questions

Data exfiltration

A tenfold-plus jump above the host's 1 MB/hour baseline, with 50 MB leaving to an external server over TCP 443, matches bulk outbound transfer. Port 443 permits egress through most firewalls, so volume and direction, not the port, indicate data exfiltration.

Brute force attack

Multiple login attempts from one IP with varying usernames is typical of credential brute forcing.

http contains "password"

Wireshark's contains operator performs a case-sensitive substring match against the raw packet bytes, so http contains "password" restricts display to HTTP packets whose payload includes that literal string. This satisfies the requirement to view only HTTP traffic carrying the word password.

A false positive; the hash corresponds to an empty file.

The MD5 value d41d8cd98f00b204e9800998ecf8427e is the well-known digest of a zero-byte file. Treating it as malicious produces a false positive, since the hash reflects absent content rather than any actual payload; the threat feed match is coincidental.

Prioritize alerts based on severity and asset criticality.

Severity and asset criticality together rank alerts by potential business impact, letting the analyst address the highest-risk detections first. This directly satisfies the high-volume constraint by filtering noise and focusing limited investigation effort where compromise would cause most harm.

Correlate alerts with known threat intelligence feeds to identify true positives.

Matching alert indicators against threat intelligence feeds confirms whether observed activity maps to known malicious infrastructure or campaigns, separating genuine compromises from benign anomalies. This raises true-positive fidelity, satisfying the high-volume requirement by deprioritising alerts lacking corroborating intelligence.

Group alerts by source IP to identify patterns like brute force or port scans.

Grouping by source IP aggregates related events, so a single host hitting many destinations becomes one pattern rather than hundreds of alerts. This directly exposes brute-force and port-scan behaviour, letting the analyst triage by campaign instead of individual events in the high-volume queue.

Port scan reconnaissance

Numerous SYN packets across multiple ports without completed handshakes indicate half-open scanning, where the attacker sends SYN but never returns the final ACK. This satisfies the stem's constraint of probing many ports on one host while avoiding full TCP connections, the defining signature of port scan reconnaissance.

DNS amplification attack

Attackers send queries that return large responses, causing NXDOMAIN.

Fast-flux DNS activity

Fast-flux DNS rotates rapidly changing A records across compromised hosts, so many lookups for short-lived names return NXDOMAIN once records expire or rotate away. This satisfies the stem's high-volume NXDOMAIN constraint, since the analyst observes repeated failed resolutions for one domain rather than successful answers.

ip.src == 10.0.0.1 and tcp.dstport == 80

`ip.src == 10.0.0.1 and tcp.dstport == 80` matches the source address field and the TCP destination port field, combining them with the logical `and` operator so both conditions must hold. This satisfies the stem's requirement to display only packets from 10.0.0.1 to port 80, since HTTP traffic uses TCP.

tcp port 443

`tcp port 443` matches only TCP segments whose source or destination port is 443, satisfying the stem's requirement to isolate HTTPS traffic. Wireshark's capture filter syntax accepts `tcp port 443`, unlike display filters such as `tcp.port == 443`, which are applied after capture rather than during it.

Apply to traffic from client to server

The `flow:to_server` keyword constrains inspection to packets travelling from the client toward the server, matching the rule's directional arrow into $HOME_NET port 445. It filters out server replies and reverse-direction traffic, so the SMB content match triggers only on inbound exploit attempts rather than responses.

Wireshark for packet-level analysis

Wireshark captures and inspects individual packets, letting the analyst examine the actual HTTP requests generating the 404 responses, including user-agent, URI and payload. This satisfies the need to determine whether the errors come from scanning, fuzzing or broken links.

SIEM for correlation and alerting

A SIEM aggregates and correlates the web logs with other sources, applying rules and thresholds to alert on abnormal 404 volumes. This satisfies the requirement to detect patterns across time and hosts rather than reviewing entries manually.

Domain name used in the communication

A domain name contacted during the incident is a host-based or network artefact that can be blocked in DNS and proxy controls and hunted for across logs. It satisfies the IoC requirement because it evidences the malware communication described in the stem.

IP address of the external server

The external server's IP address is a network artefact directly tied to the malicious communication, suitable for blocking at the firewall and for retrospective log searches. It satisfies the IoC criterion because it records the observed command-and-control endpoint.

MD5 hash of a downloaded file

An MD5 hash uniquely identifies the downloaded file, enabling detection across endpoints and threat-intelligence lookups regardless of filename. It satisfies the IoC requirement because it captures the malware payload itself rather than just the network path to it.

The response code 200 indicates successful login

Correct. The 200 response code indicates a successful login, which is the most suspicious observation because it could represent the successful culmination of a brute-force attack.

Display filter using 'frame contains "password"'

A display filter is applied after capture and searches decoded frame data, so 'frame contains "password"' matches packets whose payload holds that string. Capture filters use BPF syntax and cannot search payload content this way.

ip.addr==192.168.1.10 && ip.addr==10.0.0.5

The `ip.addr` field matches either source or destination address, so chaining two with `&&` returns packets where both endpoints appear — capturing bidirectional traffic between 192.168.1.10 and 10.0.0.5 regardless of direction. This satisfies the requirement to isolate only that conversation, unlike `ip.src`/`ip.dst`, which would restrict to one direction.

System logs

System logs contain security events like logon failures.

file_extraction.zeek

The `file_extraction.zeek` script hooks Zeek's file analysis framework and writes reassembled files from HTTP sessions to disk, satisfying the requirement to extract all transferred files. It handles MIME types and connection reassembly automatically, unlike logging-only scripts that merely record metadata without recovering content.

DNS tunneling

Random subdomains encoding data is a hallmark of DNS tunneling.

URLs

URLs record the destination endpoints contacted during transfer, letting analysts trace where exfiltrated data was sent. For network-based file exfiltration, monitoring outbound URLs reveals command-and-control or upload destinations, satisfying the requirement to track files leaving over the network.

File hashes (MD5/SHA-256)

Cryptographic hashes uniquely fingerprint file contents, so matching MD5 or SHA-256 values against known-bad or sensitive files confirms exactly which files moved across the network. This satisfies the requirement to track specific exfiltrated files, since hashes survive renaming and identify content rather than location.

Set a 'threshold' to limit the number of alerts per time window

Threshold limits how many times a rule may fire within a set time window, suppressing repeated alerts from the same source and event. This directly reduces false-positive volume without altering what the rule detects, satisfying the requirement to make alerting more specific.

Add a 'content' field to match specific bytes

Adding a `content` field narrows detection to packets carrying specific byte sequences, directly satisfying the stem's requirement for greater rule specificity. Unlike broad header-only matching, content inspection anchors the signature to distinctive payload data, sharply cutting false positives from benign traffic that merely shares the same ports or protocols.