Agent Foskett Investigation • Azure • Network Security Groups • Activity Logs • Resource Graph • KQL
The Azure Deployment Succeeded — And Quietly Opened a Security Hole
The release pipeline reported Succeeded.
The application was online. The deployment dashboard was green. The change ticket was ready to close.
Then Agent Foskett noticed an inbound Network Security Group rule allowing traffic from 0.0.0.0/0 to a management port.
“Wonderful,” he said. “We deployed the application. Apparently, we also invited the internet to troubleshoot it.”
Who changed the rule, when did it happen, and was anything actually exposed?
Azure Deployment Investigation
The deployment succeeded. Security validation was a different question.
✓ Reconstruct the control-plane change
✓ Inspect the effective NSG rule
✓ Determine whether traffic could reach a resource
The green deployment that raised a red flag
A successful Azure Resource Manager deployment indicates that Azure accepted and processed the requested change. It does not certify that every deployed setting follows security policy.
Deployment: SucceededThe infrastructure deployment completed without a reported deployment failure.
NSG rule: Too broadAn inbound allow rule included an internet-wide source range and a management destination port.
Exposure: Not yet provenAn NSG rule alone does not establish that a public endpoint was reachable or that anyone connected.
The first clue was a rule with an enormous guest list
The investigation is a fictional training scenario. The example uses an inbound allow rule for TCP port 3389, priority 120, source 0.0.0.0/0 and destination *. In a real case, verify the exact rule, subnet and NIC associations, public IP configuration, route, host firewall and listening service before concluding exposure.
Source0.0.0.0/0 — an IPv4 range covering all addresses, not evidence of a connection.
DestinationTCP 3389 — a management port that should not be broadly internet-accessible.
Priority120 — lower-numbered NSG rules take precedence over higher-numbered rules.
Reconstruct the change timeline
Agent Foskett built the timeline from the deployment record and resource write events. Times below are illustrative, not evidence from a live tenant.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
09:14 Deployment started by pipeline identity 09:16 Microsoft.Network/networkSecurityGroups/write completed 09:17 Deployment status = Succeeded 09:22 NSG review identified broad inbound rule 09:29 Change owner contacted; exposure assessment started 09:36 Rule restricted after approval and evidence capture
1. Find NSG write operations in Azure Activity Logs
Run this in Microsoft Sentinel / Log Analytics where Azure Activity Logs are ingested into the
AzureActivity table. The query finds control-plane write operations; it does not reveal the complete before-and-after rule definition.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue =~
"MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/WRITE"
| project TimeGenerated, Caller, ResourceGroup,
ResourceId, ActivityStatusValue,
CorrelationId, OperationNameValue
| order by TimeGenerated desc2. Follow the deployment correlation ID
A shared
CorrelationId can connect related Azure Activity operations. Replace the placeholder with an ID from the previous query; not every resource operation will necessarily share one correlation ID.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
let targetCorrelation = "REPLACE-WITH-CORRELATION-ID";
AzureActivity
| where TimeGenerated > ago(7d)
| where CorrelationId == targetCorrelation
| project TimeGenerated, Caller, ResourceId,
OperationNameValue, ActivityStatusValue,
CorrelationId
| order by TimeGenerated asc3. Identify who or what made the change
A pipeline service principal, managed identity or human operator may be responsible.
Caller is a starting point, not always the final attribution. Correlate with deployment history, pipeline run IDs, identity sign-ins and change approvals.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue =~
"MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/WRITE"
| summarize Writes = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Caller, ResourceGroup, ActivityStatusValue
| order by LastSeen desc4. Inspect the current NSG rules in Azure Resource Graph
Run the next query in Azure Resource Graph Explorer, not in Sentinel Log Analytics. It inspects the current resource configuration. It cannot by itself prove what the rule looked like at the moment of deployment, and results depend on access to the relevant subscriptions.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
Resources
| where type =~ "microsoft.network/networksecuritygroups"
| mv-expand Rule = properties.securityRules
| project NSG = name,
ResourceGroup = resourceGroup,
RuleName = tostring(Rule.name),
Priority = toint(Rule.properties.priority),
Direction = tostring(Rule.properties.direction),
Access = tostring(Rule.properties.access),
Protocol = tostring(Rule.properties.protocol),
Source = tostring(Rule.properties.sourceAddressPrefix),
DestinationPort = tostring(
Rule.properties.destinationPortRange)
| where Direction =~ "Inbound" and Access =~ "Allow"
| order by NSG asc, Priority asc5. Check for deployment-related operations
Look beyond the NSG write. A deployment may also create a public IP, update a NIC, alter subnet associations or change routes. This query identifies related network control-plane operations within a time window; it does not measure actual traffic.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
AzureActivity
| where TimeGenerated between
(datetime(2026-10-19 09:00:00) ..
datetime(2026-10-19 10:00:00))
| where ResourceProviderValue =~ "MICROSOFT.NETWORK"
| project TimeGenerated, Caller, ResourceId,
OperationNameValue, ActivityStatusValue,
CorrelationId
| order by TimeGenerated ascThe question an NSG rule cannot answer
An allow rule is a configuration finding. Confirming real exposure requires the effective security rules on the relevant NIC, subnet associations, public IP and routing, destination service state, and other network controls. A successful connection or malicious activity requires separate evidence.
ConfigurationWhat rule exists, at what priority, and where is the NSG associated?
ReachabilityCould internet traffic actually reach a listening service through all relevant controls?
ActivityDo network telemetry, host logs or endpoint events show attempted or successful connections?
Do not confuse a broad rule with proven compromise
The team checked the effective rules and reachability, then sought traffic and host evidence within available retention. Without those sources, the responsible conclusion is potential exposure, not a claim that an attacker entered the environment.
Activity LogsUseful for who changed Azure resources and when; not a packet-level network log.
Network and host telemetryUse available flow, firewall, connection and endpoint records to test traffic hypotheses.
Change recordsReview IaC source, pull requests, pipeline execution and approval history to explain why the rule was deployed.
The six-stage investigation
A repeatable process helps analysts avoid jumping from one worrying rule to an unsupported incident conclusion.
1. PreserveRecord deployment IDs, Activity Logs, resource configuration and timestamps.
2. AttributeIdentify the caller and connect the write to the change pipeline.
3. ScopeFind affected NSGs, NICs, subnets, public endpoints and ports.
4. TestAssess effective reachability and available traffic or host evidence.
5. ContainRestrict the rule with change-owner coordination and preserve evidence.
6. PreventAdd IaC checks, policy guardrails, review and alerting for risky rules.
What the organisation should do next
Remediation should address both the immediate rule and the process that created it.
Restrict management accessPrefer Azure Bastion, private access, approved source ranges or other appropriately secured management paths.
Add deployment guardrailsReview Infrastructure as Code changes and apply Azure Policy or CI checks for overly permissive NSG rules.
Monitor control-plane changesAlert on sensitive NSG writes and review changes alongside deployment and identity records.
Investigation findings
The fictional case established a risky configuration introduced during a successful deployment. It did not establish malicious access.
ConfirmedThe deployment succeeded and the NSG included an overly broad inbound allow rule.
InvestigatedThe change actor, deployment correlation, resource associations and reachability were reviewed.
Not assumedThe existence of the rule alone was not treated as proof of internet reachability, successful access or data loss.
Related Agent Foskett investigations
More cases where an apparently successful control or operation required deeper investigation.
Who Invited the Guest Who Could Read the Finance Files?Investigate access paths that were technically allowed but poorly governed.The DNS Query Looked Harmless — Until We Decoded the SubdomainFollow network evidence without treating one suspicious indicator as proof.Defender Detected the Threat — But the Response Action FailedWhy a successful detection is not the same as completed containment.
Final thought
Agent Foskett closed the deployment report. “Green means it deployed. It doesn’t mean I’d leave the front door open.”
The logs already knew. The pipeline just wasn’t asking the right question.
The logs already knew. The pipeline just wasn’t asking the right question.
Success is a deployment stateIt says the requested infrastructure operation completed.
Security requires validationCheck the effective rules, network path and intended access model.
Evidence determines the verdictSeparate configuration risk, reachable exposure and observed malicious activity.
