Reading malicious activity on the network

Why this matters

Objective 1.2 is the largest analytical block on the exam, and the network is where most scenarios start. You will be shown a log extract, a flow summary or a description of traffic and asked what it indicates.

The skill being tested is not memorising bad ports. It is recognising shape — regularity where there should be variety, volume where there should be none, a protocol carrying something it was not designed to carry. Attackers change their tooling constantly; the shapes stay remarkably stable, because they are imposed by what the attacker needs to accomplish.

The lesson

Beaconing, jitter and long-tail connections

Implanted malware has to ask for instructions. Asking repeatedly produces a pattern no human browsing session has: regularity.

What beaconing looks like:

• Connections to the same destination at near-constant intervals — every 60 seconds, every 5 minutes, every hour.
• Small, similar request sizes, because the request is usually "anything for me?".
• Responses that are also small, except occasionally when a command arrives.
• Continuing outside working hours, through lunch, overnight, at weekends. This is the tell that separates it most cleanly from a human.

Attackers know this and add jitter — randomising the interval by a percentage so the pattern is less obvious. Jitter defeats a naive "exactly every 60 seconds" rule, but not statistical analysis: a beacon with 30% jitter still clusters tightly around a mean, while genuine human traffic is wildly irregular with long idle gaps.

How to hunt it:

• Group connections by source and destination pair, then look at the distribution of intervals. Low variance is the signal.
• Count distinct destinations per source: a host that talks to one external address 400 times a day and nothing else is unusual.
• Look at the connection count over a long window. Beacons are persistent; ordinary sessions are bursty.
• Check what else that destination talks to. A single internal host beaconing somewhere no other host has ever contacted is more interesting than one contacting a popular CDN.

False positives are abundant and worth knowing: software update checks, monitoring agents, licence validation, telemetry, and email clients polling. All are regular, all are automated, and all are benign. The distinguishing question is not "is it regular?" but "is this destination and this process expected on this host?" — which needs the inventory and the endpoint telemetry from earlier lessons.

DNS as an exfiltration and command channel

DNS is allowed out of almost every network, is rarely inspected as closely as web traffic, and is often permitted even when everything else is blocked. That makes it attractive for both command and control and data theft.

DNS tunnelling encodes data into names. Data goes out in the query — a long random-looking label under a domain the attacker controls — and comes back in the response records. It is slow and noisy, and it works.

Indicators:

• Unusually long query names, particularly with high-entropy labels.
• High query volume to a single domain, often from one host.
• Uncommon record types where you would expect A or AAAA — TXT and NULL records carry far more data.
• Many unique subdomains under one parent: each carries a chunk of the payload, so the subdomain count explodes while the parent stays constant.
• Responses that are large or numerous relative to normal lookups.
• Low or zero TTLs, keeping the client returning.

Separately, domain generation algorithms produce large numbers of algorithmically generated names so that blocking one achieves nothing. The signature is a host issuing many lookups that mostly fail — NXDOMAIN responses in bulk — until one resolves. A burst of NXDOMAIN from a single host is one of the cleanest detections in this whole area.

Also worth watching: DNS over HTTPS and DNS over TLS. Both are good for user privacy and remove your resolver logs entirely, because the lookup now travels inside an encrypted web session to a third party. If internal hosts can reach external DoH providers, your most valuable log source has a hole in it. The usual control is to force internal resolvers and block known DoH endpoints.

Unexpected protocols and ports on unexpected hosts

The useful question is never "is this port bad?" It is "is this normal for this host?"

Patterns that earn attention:

• A workstation acting as a server. Desktops should rarely accept inbound connections. Inbound SMB or RDP to a user machine suggests lateral movement.
• A server initiating outbound connections it never made before, especially to the internet. Most servers should be far more predictable than users.
• Protocol on a non-standard port, or a standard port carrying something else. SSH on 443 to evade filtering is common; so is a non-web protocol on 80 because 80 is always open.
• Administrative protocols crossing zone boundaries — RDP, WinRM, SSH, SMB from a user subnet into a server or management zone.
• Legacy protocols reappearing. Telnet, FTP or SMBv1 traffic in a network that retired them is either misconfiguration or tooling brought in by someone.
• Peer-to-peer or tunnelling protocols where no business case exists.

The exam favours scenarios where the traffic is technically ordinary and contextually wrong. The correct reasoning is always the same: establish what this host normally does, then describe the deviation.

Data volume anomalies and staging behaviour

Exfiltration has an unavoidable signature: data has to move, and the direction is outward.

Volume anomalies worth alerting on:

• Outbound bytes from a host far exceeding its own baseline.
• An inverted ratio — hosts normally download far more than they upload, so a large upload is conspicuous.
• Large transfers outside business hours.
• Transfers to a destination with no prior relationship, or to a personal cloud storage service.

Before data leaves, it usually gets staged: collected into one place and compressed, often encrypted, ready for a single transfer. Staging is frequently the easier thing to catch, and it happens internally where you have host telemetry:

• Archive files appearing in temporary directories, oddly named, unusually large.
• One host reading from many file shares in a short period — the collection phase.
• Archive utilities running on servers where nobody works interactively.
• Database exports or backup tools used outside a schedule.

Attackers also throttle deliberately, moving data slowly over days to stay under volume thresholds. That defeats a daily threshold and not a cumulative one, which is why "total outbound to this destination over 30 days" is a query worth running even when no single day looked wrong.

Encrypted traffic: what you can still tell

Most traffic is encrypted, and the common conclusion — that network monitoring is therefore finished — is wrong. Encryption hides the payload. It does not hide the metadata, and metadata is most of what this lesson has relied on.

Still visible without decryption:

• Who talked to whom, when, for how long, and how much data moved. Every technique above works on flow data alone.
• The destination name, via the DNS lookup that preceded it, or SNI in the TLS handshake where encrypted client hello is not in use.
• Certificate details for the server: issuer, subject, validity, and whether it is self-signed. Self-signed certificates on internet-facing connections from an internal host are worth a look.
• TLS fingerprints such as JA3 and JA3S, derived from how the client and server negotiate. Different client software produces different fingerprints, so a fingerprint that does not match any approved software on that host indicates something else is making the connection — a genuinely powerful detection.
• Timing and size patterns, which is exactly how beacon detection survives encryption.

Where decryption is deployed — usually at a proxy, for outbound traffic, with exclusions for banking and health sites — you get payload visibility at the cost of complexity, performance, and a legitimate privacy conversation. Certificate pinning also breaks it for some applications.

The honest summary for the exam: encryption changes which questions you can ask, not whether the network is worth watching. Combine metadata with endpoint telemetry, which sees the plaintext before it is encrypted, and very little is genuinely lost.

Topics this lesson owns

• [x] Beaconing, jitter and long-tail connections
• [x] DNS as an exfiltration and command channel
• [x] Unexpected protocols and ports on unexpected hosts
• [x] Data volume anomalies and staging behaviour
• [x] Encrypted traffic: what you can still tell