Regular Beaconing With NXDOMAIN Bursts From an Application Server
NetFlow shows INT-APP-07, a Java application server at 10.20.14.33, opening 1,440 outbound TLS sessions per day to 203.0.113.47 port 443, one per minute, with a standard deviation of about 3 seconds over 24 hours. Each session carries roughly 500 bytes in both directions. The JA3 fingerprint of those sessions matches nothing in your baseline, and the presented certificate chain is valid but issued to a domain unrelated to your business. In the same window the host issues queries for dozens of random-looking subdomains of one registered domain, most returning NXDOMAIN, interleaved with the successful connections. The outbound proxy permits 443 to any address without category filtering. The address has no threat-intelligence reputation, positive or negative. An asset inventory shows one documented periodic process on the host: a licensed backup agent that beacons to a cloud endpoint every 5 minutes with a fixed vendor certificate.
1. Decide whether this is malicious and rank the indicators by strength, including why the absence of a reputation hit should not carry weight.
Read the worked answer
Treat it as malicious until disproven, but be explicit about which evidence carries the decision.
Strongest: the DNS pattern. Dozens of random-looking subdomains under one registered domain, mostly NXDOMAIN, is the signature of either domain generation algorithm fallback or DNS tunneling. Legitimate software does not need to resolve nonexistent names to function.
Second: the timing. One session per minute with 3-second jitter sustained over 24 hours is machine-generated, and the small consistent payload is consistent with a check-in channel rather than user or API traffic. Compare this with the backup agent, which has a documented 5-minute cadence, a fixed vendor certificate, and an owner who can confirm it. That nearby legitimate beacon is the reason cadence alone cannot be the sole indicator.
Third: JA3 and certificate mismatch. An unknown JA3 combined with a valid certificate for an unrelated domain is a real inconsistency, though both can occur with legitimate CDN or proxy behavior, so corroboration is required.
Weakest: reputation. A null reputation result means the address is unobserved, not clean. Commodity infrastructure with short lifetimes is routinely unlisted at first contact, so treat it as neutral and never as the deciding factor.
2. Describe your containment sequence and explain why blocking the single external address is insufficient on its own.
Read the worked answer
Blocking one address is necessary but close to useless as strategy: the operator rotates infrastructure, and if you block first you also tell them they were seen. The address is a commodity, the domain and the tooling are the durable artifacts.
Sequence: isolate INT-APP-07 at the host level to stop the channel, then capture memory and the Java process tree before any reboot. Collect the proxy and DNS logs for the full window, not just the last day. Block the registered domain at the internal resolvers and the egress DNS path, and block the destination address at the perimeter. Then hunt across the estate for the same JA3, the same domain, and any host whose DNS pattern shows randomized subdomains. Until that hunt finishes you do not know whether this server is the victim or the relay.
On the server itself, identify how the process was started and what account it runs as; an application server beaconing usually means a deployed web shell, a malicious library, or compromised credentials. Containment that leaves the loader in place just forces a reconnect from a different address.
Finally, verify the proxy blocked the DNS fallback path as well, since a channel that loses HTTPS often falls back to tunneling over DNS.
3. Which control change would most reduce the chance of a repeat, what limitation does it carry, and how would you justify the cost?
Read the worked answer
Egress control is the highest-value change: deny-by-default outbound with allow-lists for known destinations, category and reputation filtering on 443, and DNS resolution forced through internal resolvers that log and block. The current proxy accepting 443 to any address is why a compromised server could talk freely.
Its limitation is operational, not technical: allow-lists break legitimate SaaS, vendor APIs, and update endpoints, and every break generates pressure to reopen broad access. That pressure is predictable, so design the exception process before enforcement, with a temporary allow path that is logged and expires. Second limitation: allow-listed destinations can themselves be abused, so this reduces opportunistic traffic rather than stopping a determined actor with a foothold on an approved host.
Justification to management should be framed as reducing detection cost as well as breach probability. Detection today depends on noticing a beacon among thousands of permitted connections; with egress control, blocked attempts are themselves an alert on any host that should not be reaching external addresses. Pair the change with a measured baseline: count of distinct external destinations per week before and after, and the number of alerts generated by denied attempts.