Agent Foskett Investigation • Microsoft Azure • Virtual Networks • Lateral Movement • KQL
The Azure VM Didn't Have a Public IP — So How Did the Attacker Reach It
The Azure VM had no public IP address.
RDP was not exposed directly to the Internet.
The NSG did not contain an Internet-wide rule for port 3389.
Yet the logs showed a successful remote session.
Agent Foskett stared at the network diagram and asked:
Who said the attacker came directly from the Internet?
No Public IP Does Not Mean No Network Path
Removing a public IP reduces direct Internet exposure. It does not automatically isolate a VM from resources in the same virtual network, peered networks, VPN-connected networks or other permitted private paths.
✓ Identify the source private IP
✓ Reconstruct the route into the workload network
✓ Correlate network activity with endpoint logons
The VM looked private
The server, AZ-SQL-APP01, sat in an Azure workload subnet with a private address of
10.30.2.8. There was no public IP attached to its network interface. The team had deliberately removed direct Internet-facing RDP and believed that meant the server could not be reached remotely.No public IPThere was no direct public address on the VM for an Internet client to target.
Private addressThe VM was still a networked resource inside Azure and remained reachable over permitted private routes.
The assumptionNo public IP quietly became “nobody outside this subnet can reach it.” Those are not the same statement.
Then the remote logon appeared
Defender telemetry showed a remote session on the VM. The source was not a public Internet address. It was 10.20.4.17 — another private address inside the organisation's Azure network estate.
Investigation principle: when the expected ingress path does not explain the evidence, stop staring at the perimeter and reconstruct the route.
Start with the target VM's network evidence
Microsoft Defender XDR DeviceNetworkEvents can expose local and remote IP addresses, ports, protocol and process context for network activity recorded on onboarded devices. Here the first goal is simple: identify the address communicating with the target around the incident window.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let Target = "AZ-SQL-APP01";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName startswith Target
| where LocalPort == 3389
| project Timestamp, DeviceName, ActionType,
LocalIP, LocalPort, RemoteIP, RemotePort,
Protocol, InitiatingProcessFileName,
InitiatingProcessAccountName
| order by Timestamp asc
Important: endpoint network telemetry is not a replacement for Azure network-flow logging. Use the evidence sources available in your environment and correlate them rather than expecting one table to describe the entire Azure route.
The source address changed the investigation
00:46An Internet-facing web VM in a separate spoke network records suspicious activity.
00:53The web VM begins connecting to private addresses in another Azure network.
00:57Traffic from 10.20.4.17 reaches AZ-SQL-APP01 on TCP 3389.
00:58A remote logon is recorded on AZ-SQL-APP01.
01:04PowerShell activity begins inside the target VM.
Confirm the logon context
Next, pivot into DeviceLogonEvents. The important evidence is not merely that a remote logon occurred, but which account was used and which remote address was associated with it.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let Target = "AZ-SQL-APP01";
DeviceLogonEvents
| where Timestamp > ago(7d)
| where DeviceName startswith Target
| where LogonType has "Remote"
or RemoteIP != ""
| project Timestamp, DeviceName, ActionType,
LogonType, AccountDomain, AccountName,
RemoteDeviceName, RemoteIP,
InitiatingProcessFileName
| order by Timestamp asc
Do not overclaim: a private source IP does not prove that the source device was compromised. Map the address to the Azure resource and correlate its endpoint, identity and administrative evidence.
The path was through a peered network
The source address belonged to AZ-WEB-02 in a different Azure virtual network. The two networks were connected through virtual network peering. That peering allowed private communication between the address spaces, subject to the effective NSG, routing and other network controls.
Internet → Web VMThe first compromised system had the external exposure.
Web VM → PeeringThe attacker then used an existing private network relationship.
Peering → Target VMThe target never needed a public IP because the attacker was already inside a network that could route to it.
Pivot on the private source
Once
10.20.4.17 is identified, search for network activity involving that address. On Defender-onboarded systems this can help connect the target session to activity on the pivot host and reveal what the source device was doing around the same time.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let PivotIP = "10.20.4.17";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where LocalIP == PivotIP or RemoteIP == PivotIP
| project Timestamp, DeviceName, ActionType,
LocalIP, LocalPort, RemoteIP, RemotePort,
Protocol, InitiatingProcessAccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
Network design matters: resources in the same VNet can communicate by default, and peering can provide direct private connectivity between VNets. NSGs, firewalls, route tables and segmentation determine which of those routes are actually permitted.
No public IP solved one problem — not every problem
Removing the public IP was still a good security decision. It removed a direct Internet attack path to the target VM. The mistake was treating that control as complete isolation.
Direct exposureNo public IP prevented direct Internet addressing of the target VM.
Private reachabilityThe VM still participated in a network topology that included other workloads and peered address spaces.
Lateral movementOnce another reachable workload was compromised, permitted east-west connectivity became the next path to investigate.
What Agent Foskett checked
Network interfaceWas a public IP actually absent during the incident window?
Effective NSG rulesWhich inbound sources and ports were permitted at subnet and NIC scope?
Peering and routesWhich VNets and connected networks had a private path to the target?
Source workloadWhat happened on 10.20.4.17 before it connected to the target?
Logon evidenceWhich account authenticated and what happened after the session began?
Flow telemetryIf enabled, do Azure virtual network flow logs or traffic analytics corroborate the route?
The architecture was part of the evidence
Azure Bastion, VPN, ExpressRoute and peering can all provide legitimate private access patterns without placing a public IP on the target VM. In this case the evidence pointed to a compromised workload and VNet peering, but investigators should test every route the architecture actually provides.
Agent Foskett rule: “not Internet-facing” describes exposure. It does not mean “unreachable.”
What the evidence can and cannot prove
SupportedThe target received network and logon activity from a private source address that had a permitted route to it.
Needs correlationWhether the source workload was under attacker control at that moment and how the credentials used on the target were obtained.
Do not assumeA missing public IP means the target has no reachable management path.
Related investigations
Continue following Azure exposure and private administration paths.
The RDP Port Was Open… And Everyone Could See ItInvestigate the opposite problem: an Azure VM with a public IP and RDP exposed to the Internet.Just-In-Time VM AccessExplore temporary management access, effective network rules and reducing unnecessary exposure.The Intune Device Was Retired — But It Was Still Accessing Microsoft 365Another investigation where the control state and the observed access timeline must be separated.
Final thought
The team was correct that AZ-SQL-APP01 was not directly exposed to the Internet. The mistake was assuming that meant the attacker could not reach it. The attacker had already compromised another Azure workload, and the existing private network path did the rest. Once Agent Foskett stopped looking for a public IP and started following the private source address, the contradiction disappeared. The Logs Already Knew! 🔎
No public IP?That removes a direct path, not every path.
Private source?Map it to the resource and reconstruct the route.
Peered network?Treat east-west connectivity as part of the attack surface.
