Azure Hunt

Scenario

A finance company’s Azure environment has flagged multiple failed login attempts from an unfamiliar geographic location, followed by a successful authentication. Shortly after, logs indicate access to sensitive Blob Storage files and a virtual machine start action. Investigate authentication logs, storage access patterns, and VM activity to determine the scope of the compromise.

Methodology

Origin — Geographic Anomaly

The investigation opens in Kibana against ingested Azure EventHub logs. Pivoting on source.geo.country_name.keyword immediately surfaces Germany as an outlier for a US-based organisation — all other authentication traffic originates domestically.

Sorting by @timestamp ascending narrows the first recorded event from Germany to 2023-10-05 15:09 — the start of the attacker’s footprint in the environment.

Initial Access — Credential Access (alice)

Filtering sign-in activity originating from Germany isolates the compromised entry point:

source.geo.country_name : "Germany" and event.action : "Sign-in activity"

The account alice recorded a successful authentication following the initial Germany-origin attempts. The pattern is consistent with password spraying or credential stuffing against a known account — failed attempts absorbed by the cloud identity layer before a valid credential lands.

Discovery — Blob Storage Enumeration

With a foothold established, the attacker moved to enumerate accessible storage. Filtering on StorageRead category and GetBlob operation name surfaces the accessed object:

azure.eventhub.category: "StorageRead" and azure.eventhub.operationName: "GetBlob"

Show Image

The attacker retrieved service-config.ps1 from the storage account cactusstorage2023. A PowerShell configuration script sitting in blob storage is a high-value target — these routinely contain service credentials, connection strings, or infrastructure layout details that enable lateral movement.

Lateral Movement — Pivot to it.admin1

The credentials or context harvested from service-config.ps1 appear to have directly enabled lateral movement. Re-filtering sign-in activity from Germany surfaces a second compromised account:

source.geo.country_name.keyword : "Germany" AND event.action : "Sign-in activity"

The UPN it.admin1@cybercactus[.]onmicrosoft[.]com authenticated successfully from Germany — a privileged IT administrator account, almost certainly referenced or implicitly accessible via the config script retrieved in the previous step.

Execution — VM Start

Operating under the elevated it.admin1 identity, the attacker started a dormant virtual machine:

event.action.keyword: "MICROSOFT.COMPUTE/VIRTUALMACHINES/START/ACTION"

azure.resource.name:     DEV01VM
azure.resource.provider: MICROSOFT.COMPUTE/VIRTUALMACHINES

Starting DEV01VM suggests the attacker intended to use it as a staging node, pivot point, or additional compute resource — a common pattern when an attacker wants a persistent interactive foothold beyond the identity plane.

Exfiltration — Database Export

The attacker triggered a SQL database export action:

event.action: "MICROSOFT.SQL/SERVERS/DATABASES/EXPORT/ACTION"

The scope field confirms the target:

/subscriptions/42439ab4-76df-453b-a380-2f7a4580f01f/resourceGroups/Rss1/
  providers/Microsoft.Sql/servers/cactusdbserver/databases/CustomerDataDB

CustomerDataDB — the name alone signals the data classification. Azure SQL export writes a BACPAC file to storage, making the entire database portable and exfiltrable outside the subscription boundary without triggering traditional DLP controls.

Persistence — Backdoor Account and RBAC Escalation

The final phase established durable access independent of the two compromised user accounts. The attacker created a new Azure AD user:

event.action: "Add user"

The account display name IT Support is deliberate — it blends into a legitimate IT department context, reducing the likelihood of manual review flagging it. Following account creation, an RBAC role assignment was issued:

event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"

The assigned role was Owner — the highest privilege level in Azure RBAC, granting full control over all resources in scope. The first recorded successful login for this backdoor account was 2023-10-06 07:30, the morning after initial compromise.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Conditional Access policies on geographic anomalies — Authentication from a country with no prior login history for that account should trigger MFA step-up or block outright. Azure AD Conditional Access supports named locations and risk-based policies that would have interrupted the initial alice compromise before it landed.

Blob Storage access logging and sensitivity classification — service-config.ps1 sitting in a storage account with credentials or infrastructure references is a misconfiguration, not just a detection gap. Secrets belong in Azure Key Vault with managed identity access. Storage diagnostic logs feeding a SIEM allow GetBlob events on sensitive containers to alert in near-real-time.

RBAC Owner assignment as a high-fidelity alert — ROLEASSIGNMENTS/WRITE assigning the Owner role to any account should be a P1 alert with immediate human review. This event is low-volume, high-signal, and essentially never legitimate outside a formal change window. Alerting on this single event would have surfaced the persistence mechanism within minutes of creation.

SQL Export action monitoring — Azure SQL EXPORT/ACTION in the activity log is an explicit, auditable event that produces a BACPAC containing the entire database schema and data. An alert on this action scoped to production database servers gives the SOC an opportunity to intercept exfiltration before the file leaves the subscription.

Azure AD audit log retention and UEBA baselining — The attacker created a plausible-looking account (“IT Support”) and granted it Owner rights the day after initial compromise. UEBA baselining new account creations against expected IT provisioning workflows — combined with alerting on any new account assigned a privileged role within 24 hours of creation — is a reliable control against this persistence class.