Z3R0DAY treats unauthorised internal scanner as hostile

Opening position

The fact set is narrow. An internal IP is generating port scan traffic. That IP is not on the authorised scanner list. Nothing else is confirmed. Not the user. Not the host role. Not the duration. Not whether this is the first occurrence. Not whether the source IP belongs to a managed asset, a contractor laptop, a misplaced lab device, or an attacker pivoting through a compromised endpoint. The investigation starts with one signal and one negative authorisation check. Everything beyond that must be produced by evidence collection, not assumption.

The interview question rewards candidates who do not collapse the fact set into a story. Most candidates immediately narrate an intrusion. They name a threat actor, assume lateral movement, assume credential theft, and start describing containment. None of that is supported. Internal scanning from an unauthorised IP is a behaviour, not an attribution. The behaviour can be produced by a compromised host, a rogue insider, a forgotten security tool, a misconfigured vulnerability scanner deployed by another team, a developer running nmap from a workstation, or malware. The investigator’s job is to identify which, using observable artefacts only.

The correct posture is treat-as-hostile until proven otherwise. Containment options must be on the table before attribution. The host is producing reconnaissance traffic inside the trust boundary. Whether the operator at the keyboard is a person, a service account, or a malicious process is a question to be answered, not assumed. The candidate who states this clearly is signalling operator discipline. The candidate who launches into a threat actor profile is signalling that they do not separate evidence from narrative.

What actually failed

The externally observable behaviour is the only ground truth. A host inside the network sent connection attempts across multiple destination ports, or multiple destination hosts, or both, in a pattern consistent with reconnaissance. That pattern was visible to a sensor. The sensor produced a signal. The signal reached an analyst queue. That is what is confirmed. The internal control set permitted the traffic to leave the source interface and traverse the network to its scan targets. Segmentation, host-based egress filtering, and east-west policy did not block the activity at source.

What is not confirmed: whether the host was compromised, whether the account was compromised, whether the scan was initiated by a human, whether it was the first scan, whether other hosts are exhibiting the same behaviour, and whether the source IP has been correctly attributed to a single device. DHCP lease churn, NAT inside virtualised environments, container overlays, and VPN concentrators all break the assumption that an IP equals an endpoint. The IP is a network position at a point in time. The device behind it must be resolved through correlation, not asserted.

The authorisation list itself is a control surface. The fact that this IP is not authorised assumes the authorisation list is current, accurate, and exhaustive. If the list is maintained manually by a team that does not coordinate with vulnerability management, the negative result may be a recordkeeping failure rather than a security event. The investigator must validate the list as part of triage. Treating an out-of-date inventory as an authoritative control is how legitimate scanning activity gets escalated as intrusion, and how real intrusions get dismissed as scanner drift.

Why it failed

The investigation proceeds by collecting evidence that converts the source IP into a device, the device into an account, and the account into an action. Start with the network layer. Pull the flow records or full packet capture for the source IP across the scan window. Confirm the destination set, port range, protocol distribution, packet rate, and inter-packet timing. A SYN sweep at line rate looks different from a slow, distributed probe. The traffic shape narrows the toolset. Masscan, nmap, Metasploit auxiliary modules, Cobalt Strike’s portscan command, and built-in PowerShell scripts all produce distinguishable fingerprints in flow data.

Resolve the IP to a device. Query DHCP logs for the lease active during the scan window. Cross-reference against the switch CAM table or wireless controller association logs to obtain the MAC address and the physical port or access point. Pull the ARP table from the upstream gateway at the time of the event. If the environment uses 802.1X, the RADIUS authentication log identifies the supplicant. If the host is in a virtualised environment, the hypervisor logs tie the virtual NIC to a VM identifier. At this stage the source IP becomes a host with an owner, a build profile, and an EDR agent, or it becomes a host with none of those, which is itself a finding.

With the host identified, pivot to endpoint telemetry. Pull process execution events, parent-child process chains, command line arguments, and network connection events from EDR for the scan window. The parent process of the scanning binary is the answer to the attribution question. A scheduled task spawned by SYSTEM points one direction. A user-launched cmd.exe spawning nmap.exe points another. A signed legitimate binary executing scan logic via injected code points to a third. If EDR is absent on the host, that absence is the finding. If EDR is present and shows no process responsible for the observed network traffic, the host is either compromised below the agent or the agent has been tampered with. Both are escalation conditions.

The attacker’s IP, in the framing of the question, is a category error worth correcting in the interview. If the scanning IP is internal, the attacker is either operating that internal host directly or operating it through a remote channel. The investigative target is the inbound session that established control of the host. Pull authentication logs for the host across a window that extends well before the scan. Pull VPN, RDP, SSH, and remote management tool logs. Pull proxy and firewall logs for outbound C2 candidates. The external IP of interest is the one on the other end of the session that preceded the scan, not the scanner address itself. That is the IP that goes into blocklists, threat intel enrichment, and the incident report.

Mechanism of Failure or Drift

The mechanism here is layered. The first failure is segmentation. An internal host produced reconnaissance traffic that traversed the network unimpeded. East-west controls existed in policy or did not. Either way, the traffic reached its destinations. The flow records confirm it. If segmentation had been enforced at the source VLAN or at the distribution layer, the scan would have terminated at the first denied destination and produced a smaller, contained signal. The fact that the analyst sees a recognisable scan pattern means the scan completed enough probes to be classified as one. Containment by design was not present.

The second failure is identity-to-asset binding. The investigation has to reconstruct which device owns the IP after the fact, through DHCP, ARP, switch CAM, and RADIUS. That reconstruction is forensic work performed under time pressure. If the environment maintained a real-time IP-to-asset map tied to the directory, the source would resolve in seconds, not hours. The drift is operational. Inventories age. Scanner authorisation lists are maintained in spreadsheets. The control that should answer the question of which host owns an address is fragmented across four systems owned by three teams. The authorisation list itself is one of those fragments. A negative match against a stale list is not evidence of intrusion. It is evidence that the list and reality have diverged. The investigator who treats the list as authoritative without validating its currency is consuming a control output that no longer maps to a control.

The third failure is telemetry coverage. The scan was caught by a network sensor. That is the floor, not the ceiling. If endpoint telemetry on the source host is incomplete or absent, the investigation cannot answer the only question that matters: which process, under which account, initiated the traffic. The presence of EDR is a precondition for attribution inside the perimeter. Without it, the analyst can confirm behaviour but cannot confirm cause. The gap converts every internal scan into an unresolved investigation, which over time conditions the team to close tickets on suspicion rather than evidence. The drift is cultural as well as technical. When attribution routinely fails, the organisation learns to tolerate failed attribution.

Expansion into Parallel Pattern

The same mechanism repeats anywhere a control depends on an out-of-band list to define legitimacy. Vulnerability scanner authorisation lists, allowed administrative jump host inventories, approved automation accounts, sanctioned outbound destinations. Each of these defines normal by reference to a record that is maintained by humans, updated on a cadence that lags reality, and consulted by detection logic that treats the list as authoritative. The same pattern produced this alert. It also produces the inverse: legitimate activity from a list-omitted source flagged as intrusion, and intrusion from a list-included source ignored as routine. A control that derives truth from a manually maintained list is a control that ages out of effectiveness on the schedule of the team that maintains it.

The pattern extends to attribution work generally. Any investigation that begins with an IP and works backward to identity is operating on the same brittle chain: address to lease, lease to MAC, MAC to switch port, port to physical location or virtual host, host to account, account to action. Each link is maintained by a different system with a different retention window. DHCP logs may rotate in twenty-four hours. Switch CAM tables age out in minutes. Hypervisor logs may not record vNIC reassignments. If any link is missing for the relevant window, attribution stops. The investigator is left with a behaviour and no actor. The same chain applies to insider misuse, data exfiltration, and ransomware staging. The internal scan is one trigger condition. The chain is the same.

The framing error in the interview question is the same framing error that shapes most internal incident response programmes. The phrase find the attacker’s IP presumes a single external address explains the activity. The investigative target is not an address. It is the inbound session that established control of the host, the process lineage that produced the scan, and the authentication event that authorised the session. Programmes that optimise for IP-level attribution underinvest in the controls that actually answer the question: session-level identity validation, process lineage telemetry, and command and control egress detection. The IP at the other end of the inbound session is one enrichment input. It is not the answer.

Hard Closing Truth

Internal port scanning from an unauthorised IP is not the incident. It is the symptom that the controls preventing it were absent or ineffective. A network where an arbitrary host can probe arbitrary destinations across arbitrary ports has no enforced east-west boundary. A network where the IP cannot be resolved to a device in under a minute has no operational asset map. A network where the device cannot be resolved to a process and an account has no endpoint visibility. The alert is doing its job. The infrastructure underneath is not. Detection without prevention is a measurement of exposure, not a defence.

The candidate who answers this question well does not produce a longer list of investigative steps. The candidate produces a shorter, ordered list and states what each step depends on. Flow records require sensor coverage. DHCP correlation requires log retention longer than the detection-to-response window. Process attribution requires EDR on every host capable of generating traffic, including build servers, jump hosts, and developer workstations that are routinely excluded from the deployment scope. Each dependency is a control. If any control is missing, the investigation stops at the boundary of available evidence. The honest answer names the dependencies and the conditions under which the investigation cannot complete. Interviewers who know the work are listening for that honesty.

The operator position is fixed. Treat the host as hostile. Isolate it at the switch port or via EDR network containment. Preserve volatile state before reimaging. Identify the inbound session that preceded the scan and treat its source as the priority enrichment target. Validate the authorisation list as part of the closeout, not as a prerequisite to action. Then write the finding that the organisation does not want to read. The scan was detected because a sensor saw it, not because a control stopped it. Until segmentation, identity binding, and endpoint telemetry gaps are closed, the next internal scan will be investigated the same way, with the same gaps, and the same probability of an unresolved outcome. Controls that are not enforced are not controls. Identity is the boundary. If the system allowed it, it will happen again.

---

#ad Contains an affiliate link.