Azure VM Boot Diagnostics Retrieved
Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/06/15"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/06/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies retrieval of Azure VM boot diagnostics data
11("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this
12operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain
13plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with
14VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the
15network, to harvest credentials.
16"""
17false_positives = [
18 """
19 Support engineers, infrastructure-as-code, and VM health automation may legitimately retrieve boot diagnostics
20 during troubleshooting. The first occurrence per principal will alert; baseline expected support users, service
21 principals, and managed identities and exclude them if the activity is verified as authorized.
22 """,
23]
24from = "now-9m"
25index = ["logs-azure.activitylogs-*"]
26language = "kuery"
27license = "Elastic License v2"
28name = "Azure VM Boot Diagnostics Retrieved"
29note = """## Triage and analysis
30
31### Investigating Azure VM Boot Diagnostics Retrieved
32
33Retrieving boot diagnostics (`retrieveBootDiagnosticsData/action`) returns SAS URIs to the VM serial console log and a
34console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and
35sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no
36guest footprint, and bypasses NSG/JIT.
37
38### Triage checklist
39
40- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and
41 `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. Service principal or
42 managed identity retrieval is more suspicious than a known support user.
43- Review the source: `source.ip`, `source.as.number`, `source.as.organization.name`, `source.geo.country_name`.
44 Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress.
45- Inspect `azure.resource.id` / `azure.resource.name` to identify the target VM. Was the same principal recently granted
46 access to it, or is this their first interaction?
47- Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the
48 VM or subscription?
49
50### Possible investigation steps
51
52- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM.
53- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or
54 other secrets that now require rotation.
55- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence.
56
57### Response and remediation
58
59- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke
60 the principal's access if compromised.
61- Collect activity log artifacts per incident procedures.
62"""
63references = [
64 "https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors",
65 "https://www.microsoft.com/en-us/msrc/blog/2023/08/azure-serial-console-attack-and-defense-part-1",
66 "https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics",
67 "https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/",
68]
69risk_score = 47
70rule_id = "e7509f8f-e70b-4b67-b864-aaa4254b4484"
71severity = "medium"
72tags = [
73 "Domain: Cloud",
74 "Domain: Endpoint",
75 "Data Source: Azure",
76 "Data Source: Azure Activity Logs",
77 "Use Case: Threat Detection",
78 "Tactic: Credential Access",
79 "Resources: Investigation Guide",
80]
81timestamp_override = "event.ingested"
82type = "query"
83
84query = '''
85data_stream.dataset:azure.activitylogs and
86 event.action:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION" and
87 event.outcome:(success or Success)
88'''
89
90
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1552"
95name = "Unsecured Credentials"
96reference = "https://attack.mitre.org/techniques/T1552/"
97
98
99[rule.threat.tactic]
100id = "TA0006"
101name = "Credential Access"
102reference = "https://attack.mitre.org/tactics/TA0006/"
103
104[rule.investigation_fields]
105field_names = [
106 "@timestamp",
107 "event.outcome",
108 "azure.activitylogs.operation_name",
109 "azure.activitylogs.identity.authorization.evidence.principal_id",
110 "azure.activitylogs.identity.authorization.evidence.principal_type",
111 "azure.activitylogs.identity.claims.appid",
112 "azure.resource.name",
113 "azure.resource.id",
114 "source.ip",
115 "source.as.number",
116 "source.as.organization.name",
117 "source.geo.country_name",
118 "azure.subscription_id",
119 "azure.activitylogs.tenant_id",
120]
Triage and analysis
Investigating Azure VM Boot Diagnostics Retrieved
Retrieving boot diagnostics (retrieveBootDiagnosticsData/action) returns SAS URIs to the VM serial console log and a
console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and
sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no
guest footprint, and bypasses NSG/JIT.
Triage checklist
- Identify the acting principal via
azure.activitylogs.identity.authorization.evidence.principal_idand...principal_type(User vs ServicePrincipal) andazure.activitylogs.identity.claims.appid. Service principal or managed identity retrieval is more suspicious than a known support user. - Review the source:
source.ip,source.as.number,source.as.organization.name,source.geo.country_name. Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress. - Inspect
azure.resource.id/azure.resource.nameto identify the target VM. Was the same principal recently granted access to it, or is this their first interaction? - Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the VM or subscription?
Possible investigation steps
- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM.
- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or other secrets that now require rotation.
- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence.
Response and remediation
- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke the principal's access if compromised.
- Collect activity log artifacts per incident procedures.
References
Related rules
- Azure Compute VM Command Executed
- Azure Run Command Correlated with Process Execution
- Azure VM Extension Deployment by User
- Azure Arc Cluster Credential Access by Identity from Unusual Source
- Azure Storage Account Keys Accessed by Privileged User