ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Azure • AzureActivity • Configuration Change • Audit Trail • KQL

The Administrator Fixed the Setting — But Nobody Investigated Who Changed It

The risky setting had already been fixed.

An administrator found the problem.
Changed the configuration.
Confirmed the service was secure again.

The ticket could have been closed.

But Agent Foskett asked the question the remediation had not answered.

Who changed the setting in the first place?

A configuration can be repaired in seconds.

The reason it changed can matter for much longer.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating an Azure configuration change after remediation
Fixed Did Not Mean Explained.

Remediation restores the configuration. Investigation determines how it changed and whether the same identity changed anything else.

✓ Identify the change operation
✓ Attribute the caller
✓ Expand the activity timeline

The technical problem was already gone

By the time Agent Foskett opened the case, the current Azure configuration looked correct.

That made the environment safer.

It also meant the live setting could no longer explain how the exposure had occurred.

The investigation had to move from current state to historical evidence.

Start with the affected resource

The team knew which Azure resource had changed and approximately when the risky configuration had existed.

Agent Foskett used those facts to search the Azure control-plane audit trail.

AzureActivity records subscription-level administrative activity, including many create, update and delete operations performed through Azure Resource Manager.

Find configuration changes to the resource

Agent Foskett narrowed AzureActivity to the affected resource and successful administrative operations around the suspected period. The exact operation depends on the resource and setting that changed.
azure-resource-change.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TargetResource =
"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Network/networkSecurityGroups/nsg-prod";
AzureActivity
| where TimeGenerated > ago(14d)
| where ResourceId =~ TargetResource
| where ActivityStatusValue =~ "Success"
| project TimeGenerated,
          OperationNameValue,
          ActivityStatusValue,
          Caller,
          CallerIpAddress,
          CorrelationId,
          ResourceGroup,
          ResourceId,
          Properties
| order by TimeGenerated asc

The audit trail contained two important changes

One operation aligned with the risky configuration being introduced.

A later operation aligned with the administrator fixing it.

The current resource showed only the safe state.

The activity history showed the transition.

Current configuration answers “what is true now?” Audit history helps answer “how did it become true?”

Identify the caller behind the original change

Agent Foskett isolated the earlier operation and preserved the attribution fields available in the activity record. Caller, CallerIpAddress and CorrelationId became pivots for the wider investigation.
azure-change-attribution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TargetResource =
"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Network/networkSecurityGroups/nsg-prod";
let ChangeStart = datetime(2026-10-05 00:00:00);
let ChangeEnd   = datetime(2026-10-05 06:00:00);
AzureActivity
| where TimeGenerated between (ChangeStart .. ChangeEnd)
| where ResourceId =~ TargetResource
| where ActivityStatusValue =~ "Success"
| project TimeGenerated,
          Caller,
          CallerIpAddress,
          OperationNameValue,
          CorrelationId,
          ResourceId,
          Properties
| order by TimeGenerated asc

Attribution was the beginning, not the conclusion

A caller identity establishes which identity was used for the operation.

It does not automatically prove who was physically behind the keyboard or whether the action was malicious.

The account could have been used legitimately.
Its credentials could have been compromised.
An automation identity could have performed the change.

Agent Foskett attributed the operation first — then investigated the identity.

Look for other changes by the same caller

The next question was whether the same caller changed anything else. Agent Foskett expanded the time range and searched across Azure administrative activity for the identity.
same-caller-azureactivity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let SuspectCaller = "admin@contoso.com";
AzureActivity
| where TimeGenerated > ago(14d)
| where Caller =~ SuspectCaller
| project TimeGenerated,
          OperationNameValue,
          ActivityStatusValue,
          CallerIpAddress,
          ResourceGroup,
          ResourceId,
          CorrelationId
| order by TimeGenerated asc

One change became a sequence

The caller had touched more than the original resource.

Some operations were routine. Others occurred close to the risky change and deserved inspection.

Agent Foskett grouped them by time, source address, resource and correlation context rather than assuming every action was suspicious.

The question changed from “who changed this setting?” to “what did this identity do around the same time?”

Pivot on the correlation ID

Azure operations associated with the same request or workflow can share a CorrelationId. Agent Foskett used it as another pivot while interpreting it in the context of the relevant Azure service.
azure-correlation-pivot.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let TargetCorrelationId =
"00000000-0000-0000-0000-000000000000";
AzureActivity
| where TimeGenerated > ago(14d)
| where CorrelationId == TargetCorrelationId
| project TimeGenerated,
          OperationNameValue,
          ActivityStatusValue,
          Caller,
          CallerIpAddress,
          ResourceGroup,
          ResourceId,
          Properties
| order by TimeGenerated asc

Then investigate the sign-in context

If the caller was a Microsoft Entra user and the relevant sign-in data was available, Agent Foskett compared the administrative activity with SigninLogs.

Was the account signing in from an expected location and device?
Was MFA involved?
Were there unusual applications or Conditional Access results?

The Azure operation identified the identity used. Sign-in evidence helped establish the authentication context around that identity.

Correlate with Microsoft Entra sign-ins

Agent Foskett searched a bounded window around the configuration change. Nearby timestamps or matching IP context can strengthen an investigation, but should not be treated as proof that one particular sign-in directly caused an Azure operation without supporting evidence.
admin-signin-context.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
let TargetUser = "admin@contoso.com";
let StartTime = datetime(2026-10-05 00:00:00);
let EndTime   = datetime(2026-10-05 08:00:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ResourceDisplayName,
          ResultType,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          DeviceDetail,
          Location,
          CorrelationId
| order by TimeGenerated asc

Remediation had solved only half the problem

The administrator who fixed the setting restored the intended configuration.

But if the original change resulted from compromised credentials, unsafe automation, excessive privilege or an unauthorised action, restoring the setting would leave the underlying cause untouched.

Remediation fixes the state. Investigation explains the cause.

Build the configuration-change timeline

Configuration is safeThe resource begins in its expected state.
Risky change occursAn administrative operation changes the resource configuration.
Exposure is discoveredAn administrator notices the unsafe setting.
Setting is repairedThe current configuration is returned to its intended state.
Audit trail investigatedAzureActivity identifies the caller, operation, source context and related changes.
Identity context investigatedRelated administrative actions and sign-in evidence are reviewed before closure.

What Agent Foskett checked

Affected resourceWhich Azure resource and configuration were changed?
OperationWhich control-plane action introduced the risky state?
CallerWhich identity was recorded as performing the operation?
Source contextWhat caller IP and authentication evidence surrounded the change?
Related changesDid the same identity modify other resources around the same time?
Root causeWas the change authorised, accidental, automated or potentially associated with a compromised identity?

What the evidence can and cannot prove

AzureActivity can provide control-plane evidence such as the operation, caller, source IP context, affected resource and correlation information for supported Azure administrative activity.

A caller field identifies the identity associated with the operation; it does not independently prove human intent or credential ownership at that moment.

SigninLogs can add authentication context when applicable, but temporal or IP correlation should be interpreted carefully.

Attribution is built from multiple pieces of evidence — not from a username alone.

The lesson

The administrator did the right thing.

The unsafe setting was corrected quickly.

But restoring the configuration was only remediation.

Agent Foskett went back to the audit trail because the unanswered question still mattered.

Do not close a security configuration incident just because the setting has been fixed. Find out why it changed.
Investigation principle: Treat remediation and attribution as separate tasks. Restore the safe state, then investigate the identity, operation and surrounding activity that created the unsafe state.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to reconstruct administrative changes across Azure and Microsoft security telemetry.SOC Analyst AcademyBuild practical cloud investigation, attribution and incident-response skills.
The setting was fixed. The question wasn't.
Restore the configuration. Then investigate who changed it and why.
Continue the Investigation

Final thought

A green configuration screen can tell you the environment is safe now.

It cannot tell you why it was unsafe yesterday.

That answer lives in the history.

Agent Foskett did not stop when the setting was repaired. He followed the change back to the identity that made it.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Administrator Fixed the Setting — But Nobody Investigated Who Changed It

This Agent Foskett investigation examines an Azure security configuration that was remediated but never attributed to the identity that originally changed it.

Investigate Azure Configuration Changes with KQL

Use AzureActivity, Caller, CallerIpAddress, CorrelationId, SigninLogs and KQL to reconstruct administrative changes, identify the identity used and investigate surrounding activity.

Remediation vs Root Cause Investigation

Learn why restoring a secure Azure configuration should not automatically close the investigation and why analysts should determine whether the original change was authorised, accidental, automated or associated with a compromised identity.