Azure Compute and Networking: What Incident Responders Actually Need to Know
- 4 hours ago
- 7 min read
When you are called into an Azure incident, there is a good chance a virtual machine is at the center of it. Either the VM itself was compromised, it was used as a launching pad, or the attacker deployed new VMs to run their own workloads. Understanding how Azure's compute and networking layer works — and how it differs from on-premises environments — will save you from costly mistakes and missed evidence.
Azure Virtual Machines: Not All VMs Are Equal
Azure offers a wide variety of VM types organized into named series. While the investigation process does not change based on which series a VM belongs to, knowing the taxonomy helps you understand what you are looking at when VM names appear in logs and resource IDs — and it helps you spot red flags when unexpected series appear in an environment.
VM Series Overview
Series A — Entry-level machines suited for development workloads, low-traffic websites, or microservices. If you see Series A VMs in production handling sensitive data, flag it as a potential configuration concern. Examples: A1 v2, A4 v2.
Series B — Burstable performance. Low-cost machines that run at reduced CPU baseline but spike when demand rises. Examples: B2S, B4MS, B16MS. Threat actors deploying crypto miners sometimes use burstable instances to reduce costs — the burst behavior can make elevated CPU harder to detect.
Series D — General purpose, the workhorse of Azure compute. Covers most production workloads. Examples: D2a v4, D4s v4. This is the series you will most commonly encounter during investigations.
Series F — Compute-optimized with a high CPU-to-memory ratio. Examples: F2s v2, F8s v2. If you see these deployed unexpectedly in bulk, it could indicate compute-intensive abuse such as mining.
Series E, G, M — Memory-optimized, built for databases and in-memory analytics. Examples: E4s v4, M8ms. Rarely involved in typical attacks unless the database itself is the target.
Series NC, NV, ND — GPU-optimized machines for graphics processing, machine learning, and predictive analytics. These are expensive. Their unexpected presence in an environment is a significant red flag.
Series H — High-performance computing for scientific and financial modeling. Also expensive and unusual in typical enterprise environments.
💡 Investigator Note: Regardless of VM series, log collection and forensic analysis works the same way. The series affects cost, performance, and potential attacker motivation — not the investigation methodology.
Managed Disks: The Foundation of VM Storage
Every Azure VM has at least one managed disk — its operating system disk. Unlike the physical hard drive in a laptop, Azure managed disks are cloud-hosted storage volumes billed on a recurring basis. Understanding managed disks is critical because disk snapshots are the primary method for forensically acquiring a running VM in Azure without disrupting it.
Four Types of Managed Disks
Standard HDD — Slowest and cheapest. Used for infrequent access workloads or backups. Rarely seen on production systems handling sensitive data.
Standard SSD — The standard for production workloads. Balanced performance and cost.
Premium SSD — High-performance storage for demanding applications. Common on database servers and high-traffic web servers.
Ultra Disk — Extreme performance for the most demanding workloads such as real-time analytics and high-transaction databases.
What VMs Typically Have
OS Disk — Selected when the VM is created. Contains the operating system.
Temporary Disk — Short-term storage used for page files or swap files. Not all VM types have this. Data here is NOT persistent and will be lost when the VM is stopped or deallocated.
Data Disks — Optional additional disks added by the user. These persist independently of the VM.
The Cost Reality That Shapes Investigations
Azure managed disk costs are ongoing — you pay for disk type, size, snapshots you create, data transfers out of Azure, and per-transaction charges. When you create a forensic snapshot of a disk, that snapshot incurs charges for as long as it exists. Coordinate with your client on retention and who absorbs that cost.
💡 Investigator Note: Downloading a disk image out of Azure to an external forensic workstation will incur network egress charges. For a 500GB disk, that cost adds up fast. Consider performing forensic analysis in-cloud instead.
Azure Virtual Networks: The Plumbing That Connects Everything
An Azure Virtual Network (VNet) is the software-defined private network that connects Azure resources to each other and, optionally, to the internet and on-premises environments. Understanding the network topology of an environment is foundational — it tells you how resources communicate, what is exposed to the internet, and what paths an attacker could have used to move laterally.
IP Address Allocation
When you create a VNet, Azure assigns a private IP address range from RFC 1918 space — typically starting with 10.0.0.0/24 for the first VNet. Resources within the same VNet communicate using these private addresses.
VMs do not have public internet connectivity unless a public IP address is explicitly assigned to them, which carries an additional recurring cost.
Connecting to On-Premises Environments
Many organizations extend their Azure environments to connect back to on-premises infrastructure. Three ways this is done:
Point-to-site VPN — A connection between the VNet and a single remote computer. Common for individual admin access.
Site-to-site VPN — A persistent connection between an on-premises VPN device and an Azure VPN gateway. Common in hybrid environments.
Azure ExpressRoute — A private dedicated circuit between an on-premises location and Azure through a network partner. No internet traffic — higher cost, lower latency, higher security.
From an investigative standpoint, knowing what connectivity exists between Azure and on-premises is crucial. Lateral movement between cloud and on-premises environments is a common attacker technique, and understanding the network paths helps you trace that movement.
Network Security Groups: Azure's Built-In Basic Firewall
When you deploy a VM in Azure, a Network Security Group (NSG) is automatically created alongside it. The NSG controls which traffic is allowed to reach your VM — both inbound and outbound. Think of it as a basic stateful firewall at the network interface level.
How NSG Rules Work
NSG rules evaluate traffic based on five parameters: source IP, source port, destination IP, destination port, and protocol.
Rules are applied in priority order, from lowest number to highest — 100 is the highest priority, 4096 is the lowest.
Azure automatically creates default rules in the 65000 priority range as catch-all fallbacks.
A critical investigative scenario:
imagine you are told a firewall rule was in place to block malicious inbound traffic — but your investigation reveals that rule was assigned priority 4000, while another rule explicitly allowing that traffic was assigned priority 200. The lower-numbered rule wins, and the blocking rule never actually blocked anything.
Priority misconfigurations like this are surprisingly common and can dramatically change the incident narrative.
NSG Flow Logs: Your Network Traffic Record
NSGs can be configured to capture flow logs — records of the network traffic hitting the NSG. These are one of the most valuable data sources in an Azure investigation. Key characteristics:
Layer 4 visibility — You see IPs, ports, and protocols. Not application-layer content.
One-minute intervals — Fixed, cannot be changed.
JSON format — Consistent with all other Azure logs.
One-year default retention — Longer than most Azure log sources.
5-tuple per record — Source IP, source port, destination IP, destination port, protocol — plus the traffic decision (Allow or Deny) and in Version 2, throughput data.
This data is essential for tracing data exfiltration, lateral movement, and C2 communications. The catch: flow logs are NOT enabled by default. If your client did not turn them on before the incident, you are working without this crucial data source.
💡 Investigator Note: NSG flow logs cost $0.50 per GB beyond the first 5GB per month, plus storage account charges. Some organizations skip them to save money. When conducting a pre-incident readiness review, always check that flow logs are enabled — and make sure your client understands what they are giving up if they are not.
Beyond NSGs: Other Network Infrastructure You Might Encounter
NSGs are just one layer of network control in Azure. Depending on the environment, you may encounter additional components that affect traffic flow and generate their own logs.
Azure Load Balancer
Distributes incoming traffic across multiple VM instances. If a compromised application server sits behind a load balancer, you may need to check load balancer logs to understand which backend VM actually handled specific requests.
Azure Firewall
A managed, cloud-based firewall that provides both stateful network filtering and application-layer (Layer 7) inspection. Unlike NSGs, Azure Firewall can filter traffic based on fully qualified domain names, detect and block known malicious traffic, and provide centralized logging. If an environment has Azure Firewall deployed, its logs are a rich data source.
Application Gateway
A web application firewall (WAF) that sits in front of web applications to filter malicious HTTP/HTTPS traffic. If the incident involves a compromised web application, Application
Gateway logs may show what attack traffic looked like before it reached the application.
VPN Gateway
Manages the connection between on-premises networks and Azure. Log any authentication events and connection records — these can reveal unauthorized remote access attempts.
Third-Party Network Virtual Appliances
Many organizations deploy third-party firewall, VPN, or WAN optimization appliances from the Azure Marketplace — vendors like Palo Alto, Check Point, Fortinet. These have their own logging capabilities separate from native Azure logs. Always ask your client what third-party network appliances are deployed. They may hold critical evidence that does not appear anywhere in the native Azure log stack.
When you first access an environment during an investigation, build a network topology picture before diving into logs. Know what is filtering traffic, where traffic flows, and what is exposed to the internet. This context makes every log entry more meaningful.
In the next article, we move into the core of what makes or breaks an Azure investigation: the logging system. We will cover the five types of Azure logs and how to configure, access, and query each one.
Special Thanks
I would like to extend my heartfelt gratitude to one of my dearest freinds, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication!
----------------------------------------------------------Dean--------------------------------------
Comments