Cloud forensics: Prepare for the worst -implement security baselines for forensic readiness in Azure
Forensic readiness in the cloud Forensic readiness in the cloud refers to an organization’s ability to collect, preserve, and analyze digital evidence in preparation for security incidents. Forensic readiness is increasingly important as more organizations migrate workloads to the cloud. Achieving an appropriate security posture ensures that organizations are adequately equipped for forensic investigations. This requires more than just the presence of logs; logging and monitoring configurations must be thoughtfully scoped and proactively enabled. Additionally, the adoption of cloud environments presents unique challenges for forensic investigations. First, capturing the right evidence can be difficult due to the dynamic nature of cloud data. Second, in a shared responsibility model, organizations must work closely with their cloud providers to ensure preparedness for forensic investigations. Azure’s multi-tenant architecture adds another layer of complexity, as data from multiple customers may reside on the same physical hardware. Therefore, strict access controls and robust logging are essential. To maintain forensic readiness, organizations must implement comprehensive monitoring and logging across all cloud services to ensure evidence is available when needed. Preparing your Azure environment for forensic readiness When the Azure environment is set up correctly and configured with accurate logging in place, it becomes easier to quickly identify the scope of a security breach, trace the attacker’s actions, and identify the Tactics, Techniques, and Procedures (TTP) employed by a threat actor. Through the implementation of these measures, organizations can ensure that data required to support forensic investigations is available, hence ensuring compliance with auditing requirements, improving security, and ensuring security incidents are resolved efficiently. With that granularity of log data in the environment, organizations are more well-equipped to respond to an incident if it occurs. Case study: Forensic investigation disrupted due to lack of forensic readiness in Azure In a recent cybersecurity incident, a large company utilizing Azure experienced a major setback in its forensic investigation. This case study outlines the critical steps and logs that were missed, leading to a disrupted investigation. Step 1: Initial detection of the compromise The organization’s Security Operations Centre (SOC), identified anomalous outbound traffic originating from a compromised Azure virtual machine (VM) named “THA-VM.” Unfortunately, the absence of diagnostic settings significantly hindered the investigation. Without access to Guest OS logs and data plane logs, the team was unable to gain deeper visibility into the threat actor’s activities. The lack of critical telemetry—such as Windows Event Logs, Syslog, Network Security Group (NSG) flow logs, and resource-specific data plane access logs—posed a major challenge in assessing the full scope of the compromise. Had these diagnostic settings been properly configured, the investigation team would have been better equipped to uncover key indicators of compromise, including local account creation, process execution, command-and-control (C2) communications, and potential lateral movement. Figure 1: Diagnostic settings not configured on the virtual machine resource Step 2: Evidence collection challenges During the forensic analysis of the compromised virtual machine, the team attempted to capture a snapshot of the OS disk but discovered that restore points had not been configured and no backups were available—severely limiting their ability to preserve and examine critical disk-based artefacts such as malicious binaries, tampered system files, or unauthorized persistence mechanisms. Restore points, which are not enabled by default in Azure virtual machines, allow for the creation of application-consistent or crash-consistent snapshots of all managed disks, including the OS disk. These snapshots are stored in a restore point collection and serve as a vital tool in forensic investigations, enabling analysts to preserve the exact state of a VM at a specific point in time and maintain evidence integrity throughout the investigation process. Step 3: Analysis of the storage blob The team then turned to storage blobs after identifying unusual files that appeared to be associated with threat actor tool staging such as scanning utilities and credential dumping tools. However, because diagnostic settings for the storage account had not been enabled, the investigators were unable to access essential data plane logs. These logs could have revealed who uploaded or accessed the blobs and when those actions occurred. Since storage diagnostics are not enabled by default in Azure, this oversight significantly limited visibility into attacker behavior and impeded efforts to reconstruct the timeline and scope of malicious activity—an essential component of any effective forensic investigation. Step 4: Slow response and escalation In the absence of tailored logging and monitoring configurations, response timelines were delayed, and the full incident response process that was required was not initiated quickly enough to minimize the impact. Step 5: Recovery and lessons learned Despite the delays, the team pieced together elements of the story based on the data they had available, without determining the initial access vector largely because the necessary diagnostic data wasn't available. This absence of forensic readiness highlights the importance of configuring diagnostic settings, enabling snapshots, and using centralized logging solutions like Microsoft Sentinel, which will bring all this telemetry into a single pane of glass, providing real-time visibility and historical context in one place. This unified view enables faster incident detection, investigation, and response. Its built-in analytics and AI capabilities help surface anomalies that might otherwise go unnoticed, while retaining a searchable history of events for post-incident forensics. Recommended practices for forensic readiness in Azure The table below outlines key recommendations for deploying and administering workloads securely and effectively in Azure. Each recommendation is categorized by focus area and includes a best practice description, specific action to take, and a reference to supporting documentation or resources to assist with implementation. Category Best Practice Recommended Action Resource/Link Identity and Access Enable MFA for all users. [ ] Enable Multi-Factor Authentication (MFA) for all Azure AD Users. MFA in Azure AD Monitor Access Review and Role Assignments [ ] Regularly review identities (SPNs, Managed Identities, Users), role assignments and permissions for anomalies. Azure Identity Protection Implement RBAC with least privilege. [ ] Use Role-Based Access Control (RBAC) and assign least-privilege roles to users. Azure RBAC Overview Configure PIM for privileged roles. [ ] Configure Privileged Identity Management (PIM) for all privileged roles. Require approval for high privilege roles. PIM in Azure AD Enable Sign-in and Audit Logs. [ ] Ensure all sign-in activities and audit logs are enabled and logging in Azure AD. Azure Entra (AD) Sign-In Logs Conditional Access Policies: Protect high-risk resources from unauthorized access. [ ] Set Conditional Access policies to enforce MFA or access restrictions based on conditions like risk or location. Conditional Access in Azure Entra (AD) Logging and Monitoring Enable Azure Monitor [ ] Enable Azure Monitor to collect telemetry data from resources. Azure Monitor Overview Activate Microsoft Defender for Cloud. [ ] Activate and configure Microsoft Defender for Cloud for enhanced security monitoring. Microsoft Defender for Cloud Enable Diagnostic logging for VM and Applications. [ ] Configure Diagnostic logging for Azure VMs, and other critical resources. Azure Diagnostics Logging Centralize Logs in Log Analytics Workspace. [ ] Consolidate all logs into a Log Analytics Workspace for centralized querying. Log Analytics Workspace Set Audit logs retention to 365+ days. [ ] Ensure audit logs are retained for a minimum of 365 days to meet Forensic needs. Audit Log Retention Enable Advanced Threat Detection. [ ] Enable Microsoft Defender for Cloud and Sentinel to detect anomalous behavior and security threats in real time. Azure Sentinel Overview Data Protection Ensure Data encrypted at rest and in transit. [ ] Enable encryption for data at rest and in transit for all Azure resources. Azure Encryption Use Azure Key Vault for Key management. [ ] Store and manage encryption key, certificates and secrets in Azure Key Vault. Azure Key Vault Rotate Encryption Keys Regularly. Regularly rotate encryption key, certificates and secrets in Azure Key Vault. Manage Keys in Key Vault Configure Immutable Backups. [ ] Set up immutable backups for critical data to prevent tampering. Immutable Blob Storage Implement File Integrity Monitoring [ ] Enable File Integrity Monitoring in Azure Defender for Storage to detect unauthorized modifications. Azure Defender for Storage Network Security Configure Network Security Groups (NSGs). [ ] set up NSGs to restrict inbound/outbound traffic for VM’s and services. Network Security Groups Enable DDoS Protection. [ ] Implement DDoS Protection for critical resources to safeguard against distributed denial-of-service attacks. DDoS Protection in Azure Use VPNs or ExpressRoute for secure connectivity. [ ] Establish VPNs or ExpressRoute for secure, private network connectivity. Azure VPN Gateway Incident Response Set Up Alerts for suspicious activities. [ ] Configure alerts for suspicious activities such as failed login attempts or privilege escalation. Create Alerts in Azure Sentinel Automate incident response. [ ] Automate incident response workflows using Azure Automation or Logic Apps. Azure Logic Apps Integrate Threat intelligence with Sentinel. [ ] Integrate external threat intelligence feeds into Microsoft Sentinel to enrich detection capabilities Threat Intelligence in Azure Sentinel Run Advanced KQL Queries for Incident Investigations. [ ] Use Kusto Query Language (KQL) queries in Sentinel to investigate and correlate incidents. KQL Queries in Sentinel Establish Incident Response Plan [ ] Document and formalize your organization’s incident response plan with clear steps and procedures. Incident Response in Azure Policies and Processes Define a Forensic Readiness Policy. [ ] Establish and document a Forensic Readiness policy that outlines roles, responsibilities, and procedures. Azure Security Policies Conduct Administrator training. [ ] Provide regular training for administrators on security best practices, forensic procedures, and incident response. Azure Security Training By using Microsoft’s tools and implementing these recommended best practices, organizations can improve their forensic readiness and investigation capabilities in Azure. This approach not only helps in responding effectively to incidents but also enhances an organization’s overall security posture. By staying ahead of potential threats and maintaining forensic readiness, you’ll be better equipped to protect your organization and meet regulatory requirements. Conclusion Forensic readiness in Azure is not a one-time effort, it is an ongoing commitment that involves proactive planning, precise configuration, and strong coordination across security, operations, and governance teams. Key practices such as enabling diagnostic logging, centralizing telemetry, enforcing least-privilege access, and developing cloud-tailored incident response playbooks are essential. Together, these measures improve your ability to detect, investigate, and respond to security incidents in a timely and effective manner.Recover an ADCS platform from compromise
Discover how Microsoft DART executes the recovery of an Active Directory Certificate Services server amidst a ransomware incident. Gain insights into the vital components necessary for a successful restoration, enabling ongoing recovery efforts for infrastructure, data, and applications affected by this threat.A BlackByte Ransomware intrusion case study
Introduction As ransomware attacks grow in number and sophistication every year, threat actors can quickly impact business operations if organizations are not well prepared. In this blog, we detail an investigation into a ransomware event. During this intrusion the threat actor progressed through the full attack chain, from initial access through to impact, in less than five days, causing significant business disruption for the victim organization. During the investigation, the Microsoft Incident Response team (formerly known as DART) identified the threat actor employing a range of tools & techniques to achieve their objectives, including: Exploitation of unpatched internet exposed Microsoft Exchange Servers Web Shell deployment facilitating remote access Use of living of the land tools for persistence and reconnaissance Cobalt Strike beacons for command and control Process Hollowing and the use of vulnerable drivers for defense evasion Deployment of custom developed backdoors to facilitate persistence Deployment of a custom developed data collection and exfiltration tool Forensic analysis Initial Access In order to obtain initial access into the victim’s environment, the Threat Actor was observed exploiting known vulnerabilities (ProxyShell) on unpatched Microsoft Exchange Servers: CVE-2021-34473 CVE-2021-34523 CVE-2021-31207 The exploitation of these vulnerabilities allowed the Threat Actor to: Attain SYSTEM level privileges on the compromised Exchange host Enumerate LegacyDN of users by sending an Autodiscover requests, including SIDs of users Construct a valid authentication token and use it against the Exchange Powershell backend Impersonate domain admin users and creates a web shell by using the New-MailboxExportRequest cmdlet Create web shells in order to obtain remote control on the affected servers The Threat Actor was observed operating from the following IP to exploit ProxyShell and access the web shell: 185.225.73[.]244 Persistence Backdoor Microsoft IR identified the creation of Registry Run Keys, a common persistence mechanism employed by threat actors to maintain access to a compromised device, where a payload is executed each time a specific user logs in. Registry Key ValueName ValueData HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run MsEdgeMsE rundll32 C:\Users\user\Downloads\api-msvc.dll,Default HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run MsEdgeMsE rundll32 C:\temp\api-msvc.dll,Default HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run MsEdgeMsE rundll32 C:\systemtest\api-system.png,Default api-msvc.dll, detected by Microsoft Defender Antivirus as Trojan:Win32/Kovter!MSR, was determined to be a backdoor capable of collecting system information such as installed antivirus products, device name and IP address. This information is then sent via HTTP POST request to a command and control (C2) channel: hxxps://myvisit[.]alteksecurity[.]org/t FileName SHA-256 api-msvc.dll 4a066569113a569a6feb8f44257ac8764ee8f2011765009fdfd82fe3f4b92d3e Unfortunately, the organization was not using Microsoft Defender as the primary AV/EDR solution, preventing to take action against the malicious code. An additional file name, api-system.png, was identified with similarities to api-msvc.dll. This file behaved like a DLL, had the same default export function, and also leveraged Run Keys for persistence. Cobalt Strike Beacon The threat actor leveraged Cobalt Strike, a common commercial penetration testing tool, to achieve persistence. The file sys.exe, detected by Microsoft Defender Antivirus as Trojan:Win64/CobaltStrike!MSR, was determined to be a Cobalt Strike beacon and was downloaded directly from the file sharing service temp.sh: hxxps://temp[.]sh/szAyn/sys.exe This beacon was configured to communicate with the following command and control (C2) channel: 109.206.243[.]59:443 FileName SHA-256 sys.exe 5f37b85687780c089607670040dbb3da2749b91b8adc0aa411fd6280b5fa7103 AnyDesk Microsoft IR frequently observes threat actors leveraging legitimate remote access during an intrusion, in an effort to blend in on a victim network. In this case, the threat actor utilized AnyDesk, a common remote administration tool to maintain persistence and move laterally within the network. AnyDesk was installed as a Service and was executed from the following paths: C:\systemtest\anydesk\AnyDesk.exe C:\Program Files (x86)\AnyDesk\AnyDesk.exe C:\Scripts\AnyDesk.exe Successful connections were observed in AnyDesk Logs (ad_svc.trace) involving anonymizer service IP addresses linked to TOR and MULLVAD VPN. This is a common technique that actors employ to obscure their source IP ranges. Reconnaissance and Privilege Escalation Microsoft IR found the presence and execution of the network discovery tool NetScan being used by the threat actor to perform network enumeration, under the following executable names: netscan.exe netapp.exe FileName SHA-256 netscan.exe 1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e netapp.exe 1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e In addition, execution of AdFind, an Active Directory reconnaissance tool, was observed in the environment. FileName SHA-256 adfind.exe f157090fd3ccd4220298c06ce8734361b724d80459592b10ac632acc624f455e Credential Access Evidence of likely Mimikatz usage, a credential theft tool commonly used by threat actors, was also uncovered, through the presence of a related log file mimikatz.log. Microsoft IR assesses that Mimikatz was likely used to attain credentials for privileged accounts. Lateral Movement Using compromised domain admin credentials, the threat actor used Remote Desktop Protocol and Powershell Remoting to obtain access to other servers in the environment, including Domain Controllers. Data Staging and Data Exfiltration A suspicious file named “explorer.exe” was identified. The file was recognized by Microsoft Defender Antivirus as “Trojan:Win64/WinGoObfusc.LK!MT” and quarantined, but after disabling Windows Defender Antivirus service, the threat actor was able to execute the file using the following command: explorer.exe P@$$w0rd FileName SHA-256 explorer.exe 2d078d18e64c0085278245e284112e01aa64c69a1485bf07a6d649773293faf6 Explorer.exe was reverse engineered by Microsoft IR and determined to be ExByte, a GoLang based tool developed and commonly used in BlackByte ransomware attacks for collection and exfiltration of files from victim networks. The binary is capable of enumerating files of interest across the network, and upon execution creates a log file containing a list of files and associated metadata. Multiple log files were uncovered during the investigation in the path: C:\Exchange\MSExchLog.log Analysis of the binary revealed a list of file extensions which are targeted for enumeration. Binary analysis showing file extensions enumerated by explorer.exe Forensic analysis identified a file named data.txt that was created and later deleted after ExByte execution. This file contained obfuscated credentials which ExByte leveraged to authenticate to the popular file sharing platform Mega NZ, via it’s API at: hxxps://g.api.mega.co[.]nz Binary analysis showing explorer.exe functionality for connecting to file sharing service MEGA NZ Microsoft IR also determined that this tool was crafted specifically for the victim, as it contained a hardcoded device name belonging to the victim and an internal IP address. Execution Flow Upon execution ExByte decodes several strings and checks if the process is running with privileged access by reading \\.\PHYSICALDRIVE0: If this check fails, ShellExecuteW is invoked with IpOperation parameter RunAs which runs explorer.exe with elevated privilege. After this access check, explorer.exe attempts to read data.txt file in the current location: If the text file doesn’t exist, it invokes a command for self-deletion and exits from memory: C:\Windows\system32\cmd.exe /c ping 1.1.1.1 -n 10 > nul & Del <PATH>\explorer.exe /F /Q If data.txt exists, explorer.exe reads the file, passes the buffer to Base64 decode function and then decrypts the data using the key provided in the command-line. The decrypted data is then parsed as JSON below and fed for login function: { “a”:”us0”, “user”:”<CONTENT FROM data.txt>” } Finally, it then forms an URL for login to the API of file sharing service MEGA NZ: hxxps://g.api.mega.co[.]nz/cs?id=1674017543 Data Encryption and Destruction MICROSOFT IR found several devices where files had been encrypted and identified suspicious executables, detected by Microsoft Defender Antivirus as Trojan:Win64/BlackByte!MSR, with the following names: wEFT.exe schillerized.exe The files were analyzed and determined to be BlackByte 2.0 binaries responsible for encryption across the environment. This binary requires an 8-digit key number to encrypt files. Two modes of execution were identified: When the -s parameter is provided, the ransomware self-deletes and encrypts the machine it was executed on When the -a parameter is provided, the ransomware conducts enumeration and uses an UPX packed version of PsExec to deploy across the network. Several domain admin credentials were hardcoded in the binary, facilitating the deployment of the binary across the network. Depending on the switch (-s or -a), execution may create below files: C:\SystemData\M8yl89s7.exe (Random Name – UPX Packed PsExec) C:\SystemData\wEFT.exe (Additional BlackByte binary) C:\SystemData\MsExchangeLog1.log (Log file) C:\SystemData\rENEgOtiAtES A Vulnerable (CVE-2019-16098) driver RtCore64.sys, used to evade detection by installed AV/EDR software C:\SystemData\iHu6c4.ico (Random Name – BlackBytes icon) C:\SystemData\BB_Readme_file.txt (BlackByte ReadMe File) C:\SystemData\skip_bypass.txt (Unknown) FileName SHA-256 M8yl89s7.exe (RANDOM NAME) ba3ec3f445683d0d0407157fda0c26fd669c0b8cc03f21770285a20b3133098f rENEgOtiAtES 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd Some capabilities identified for the BlackByte 2.0 ransomware were: AV/EDR Bypass: The file rENEgOtiAtES created matches RTCore64.sys, a vulnerable driver (CVE-2049-16098) that allows any authenticated user to read/write to arbitrary memory. The BlackByte binary then creates and starts a service named RABAsSaa calling rENEgOtiAtES, and exploits this service to evade detection by installed AV/EDR software. Process Hollowing Invokes svchost.exe, injects to it to complete device encryption, and self-deletes by executing the following command: cmd.exe /c ping 1.1.1.1 -n 10 > Nul & Del “PATH_TO_BLACKBYTE” /F /Q Modification / Disabling of Windows Firewall The following commands are executed to either modify existing Windows Firewall rules, or to disable Windows Firewall entirely: cmd /c netsh advfirewall set allprofiles state off cmd /c netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes cmd /c netsh advfirewall firewall set rule group=”Network Discovery” new enable=Yes Modification of Volume Shadow Copies The following commands are executed to destroy volume shadow copies on the machine: cmd /c vssadmin Resize ShadowStorge /For=B:\ /On=B:\ /MaxSuze=401MB cmd /c vssadmin Resize ShadowStorage /For=B:\ /On=B:\ /MaxSize=UNBOUNDED Modification of Registry Keys/Values The following commands are executed to modify the registry, facilitating elecated execution on the device: cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLinkedConnections /t REG_DWORD /d 1 /f cmd /c reg add HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f Additional Functionality Ability to terminate running services and processes. Ability to enumerate and mount volumes and network shares for encryption. Perform anti-forensics technique time-stomping (sets the file time of encrypted and ReadMe file to 2000-01-01 00:00:00) Ability to perform anti-debugging techniques. Recommendations To guard against BlackByte ransomware attacks, Microsoft IR recommends the following: Ensure that you have a patch management process in place and that patching for internet exposed devices is prioritized. Implement an EDR solution like Microsoft Defender for Endpoint to gain visibility of malicious activity in real time across your network Ensure antivirus signatures are updated regularly and that your AV solution is configured to block threats Block inbound traffic from Ips specified in the Indicators of Compromise table Block inbound traffic from TOR Exit Nodes Block inbound access from unauthorized public VPN services Enable tamper protection to prevent components of Microsoft Defender Antivirus from being disabled Understand and assess your cyber exposure with advanced vulnerability and configuration assessment tools Indicators of compromise (IOC) The table below shows IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems. Indicator Type Description api-msvc.dll (Backdoor installed through RunKeys) SHA-256 4a066569113a569a6feb8f44257ac8764ee8f2011765009fdfd82fe3f4b92d3e sys.exe (Cobalt Strike Beacon) SHA-256 5f37b85687780c089607670040dbb3da2749b91b8adc0aa411fd6280b5fa7103 explorer.exe (Exbyte, file enumeration and exfiltration tool) SHA-256 2d078d18e64c0085278245e284112e01aa64c69a1485bf07a6d649773293faf6 rENEgOtiAtES (Vulnerable driver RtCore64.sys created by BlackByte binary) SHA-256 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd [RANDOM_NAME].exe (UPX Packed PsExec created by BlackByte binary) SHA-256 ba3ec3f445683d0d0407157fda0c26fd669c0b8cc03f21770285a20b3133098f “netscan.exe”, “netapp.exe (Netscan network discovery tool) SHA-256 1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e AdFind.exe (Active Directory information gathering tool) SHA-256 f157090fd3ccd4220298c06ce8734361b724d80459592b10ac632acc624f455e hxxps://myvisit[.]alteksecurity[.]org/t URL C2 for backdoor api-msvc.dll hxxps://temp[.]sh/szAyn/sys.exe URL Download URL for sys.exe 109.206.242[.]59 IP Address C2 for Cobalt Strike beacon sys.exe 185.225.73[.]44 IP Address Originating IP address for ProxyShell exploitation and web shell interaction NOTE: These indicators should not be considered exhaustive for this observed activity. Detections Microsoft 365 Defender Microsoft Defender Antivirus Trojan:Win32/Kovter!MSR Trojan:Win64/WinGoObfusc.LK!MT Trojan:Win64/BlackByte!MSR HackTool:Win32/AdFind!MSR Trojan:Win64/CobaltStrike!MSR Microsoft Defender for Endpoint Microsoft Defender for Endpoint customers should watch for these alerts that can detect behavior observed in this campaign. Note however that these alerts are not indicative of threats unique to the campaign or actor groups described in this report. 'CVE-2021-31207' exploit malware was detected An active 'NetShDisableFireWall' malware in a command line was prevented from executing. Suspicious registry modification. ‘Rtcore64’ hacktool was detected Possible ongoing hands-on-keyboard activity (Cobalt Strike) A file or network connection related to a ransomware-linked emerging threat activity group detected Suspicious sequence of exploration activities A process was injected with potentially malicious code Suspicious behavior by cmd.exe was observed 'Blackbyte' ransomware was detected Microsoft Defender Vulnerability Management Microsoft Defender Vulnerability Management surfaces impacted devices that may be affected by the Exchange (ProxyShell) and drivers vulnerabilities used in the attack: CVE-2021-34473 CVE-2021-34523 CVE-2021-31207 CVE-2019-16098 Advanced hunting queries Microsoft 365 Defender and Microsoft Sentinel ProxyShell Web Shell Creation Events DeviceProcessEvents | where ProcessCommandLine has_any ("ExcludeDumpster","New-ExchangeCertificate") and ProcessCommandLine has_any (("-RequestFile","-FilePath") Suspicious Vssadmin Events DeviceProcessEvents | where ProcessCommandLine has_any ("vssadmin","vssadmin.exe") and ProcessCommandLine has "Resize ShadowStorage" and ProcessCommandLine has_any ("MaxSize=401MB"," MaxSize=UNBOUNDED") Conclusions BlackByte Ransomware attacks are still targeting organizations having infrastructure with old unpatched vulnerabilities, allowing them to accomplish their objectives with a minimum effort. According to Shodan, at the time this blog was written, there are nearly 3300 public facing servers still affected to ProxyShell vulnerabilities, making this an easy target for threat actors looking to impact organizations around the world. As Microsoft shows in the Microsoft Digital Defense Report, key practices like “Keep up to date” in conjunction to other good practices mentioned from a basic security hygiene strategy, could protect against 98 percent of attacks. As new tools are being developed by threat actors, a modern threat protection solution M365 Defender is necessary to prevent and detect the multiple techniques used in the attack chain, especially where the threat actor attempts to evade or disable specific defense mechanisms. Hunting for malicious behavior should be performed regularly in order to detect potential attacks that could evade detections, as a complementary activity for continuous monitoring from security tools alerts and incidents. To understand how Microsoft can help you secure your network and respond to network compromise, visit https://aka.ms/MicrosoftIR. Appendix Encryption Different file extensions are targeted by BlackByte binary for Encryption: .4dd .4dl .accdb .accdc .accde .accdr .accdt .accft .adb .ade .adf .adp .arc .ora .alf .ask .btr .bdf .cat .cdb .ckp .cma .cpd .dacpac .dad .dadiagrams .daschema .db .db-shm .db-wal .db3 .dbc .dbf .dbs .dbt .dbv . dbx . dcb . dct . dcx . ddl . dlis . dp1 . dqy . dsk . dsn . dtsx . dxl . eco . ecx . edb . epim . exb . fcd . fdb . fic . fmp . fmp12 . fmpsl . fol .fp3 . fp4 . fp5 . fp7 . fpt . frm . gdb . grdb . gwi . hdb . his . ib . idb . ihx . itdb . itw . jet . jtx . kdb . kexi . kexic . kexis . lgc . lwx . maf . maq . mar . masmav . mdb . mpd . mrg . mud . mwb . myd . ndf . nnt . nrmlib . ns2 . ns3 . ns4 . nsf . nv . nv2 . nwdb . nyf . odb . ogy . orx . owc . p96 . p97 . pan . pdb . pdm . pnz . qry . qvd . rbf . rctd . rod . rodx . rpd . rsd . sas7bdat . sbf . scx . sdb . sdc . sdf . sis . spg . sql . sqlite . sqlite3 . sqlitedb . te . temx . tmd . tps . trc . trm . udb . udl . usr . v12 . vis . vpd . vvv . wdb . wmdb . wrk . xdb . xld . xmlff . abcddb . abs . abx . accdw . and . db2 . fm5 . hjt . icg . icr . kdb . lut . maw . mdn . mdt File extensions targeted by BlackByte binary for encryption Also, the following Shared Folders are targeted to encrypt: Users Backup Veeam homes home media common Storage Server Public Web Images Downloads BackupData ActiveBackupForBusiness Backups NAS-DC DCBACKUP DirectorFiles share Example: \\IP_Address\Downloads Extensions ignored: .ini .url .msilog .log .ldf .lock .theme .msi .sys .wpx .cpl .adv .msc .scr .key .ico .dll .hta .deskthemepack .nomedia .msu .rtp .msp .idx .ani .386 .diagcfg .bin .mod .ics .com .hlp .spl .nls .cab .exe .diagpkg .icl .ocx .rom .prf .thempack .msstyles .icns .mpa .drv .cur .diagcab .cmd .shs Folders ignored: windows boot program files (x86) windows.old programdata intel bitdefender trend micro windowsapps appdata application data system volume information perflogs msocache Files ignored: bootnxt ntldr bootmgr thumbs.db ntuser.dat bootsect.bak autoexec.bat iconcache.db bootfont.bin Process terminated by BlackByte binary teracopy teamviewer nsservice nsctrl uranium processhacker procmon pestudio procmon64 x32dbg x64dbg cff explorer procexp pslist tcpview tcpvcon dbgview rammap rammap64 vmmap ollydbg autoruns autorunssc filemon regmon idaq idaq64 immunitydebugger wireshark dumpcap hookexplorer importrec petools lordpe sysinspector proc_analyzer sysanalyzer sniff_hit windbg joeboxcontrol joeboxserver resourcehacker fiddler httpdebugger dumpit rammap rammap64 vmmap agntsvc cntaosmgr dbeng50 dbsnmp encsvc infopath isqlplussvc mbamtray msaccess msftesql mspub mydesktopqos mydesktopservice mysqld mysqld-nt mysqld-opt Ntrtscan ocautoupds ocomm ocssd onenote oracle outlook PccNTMon powerpnt sqbcoreservice sql sqlagent sqlbrowser sqlservr sqlwriter steam synctime tbirdconfig thebat thebat64 thunderbird tmlisten visio winword wordpad xfssvccon zoolz Services terminated by BlackByte binary CybereasonRansomFree vnetd bpcd SamSs TeraCopyService msftesql nsService klvssbridge64 vapiendpoint ShMonitor Smcinst SmcService SntpService svcGenericHost Swi_ TmCCSF tmlisten TrueKey TrueKeyScheduler TrueKeyServiceHelper WRSVC McTaskManager OracleClientCache80 mfefire wbengine mfemms RESvc mfevtp sacsvr SAVAdminService SepMasterService PDVFSService ESHASRV SDRSVC FA_Scheduler KAVFS KAVFS_KAVFSGT kavfsslp klnagent macmnsvc masvc MBAMService MBEndpointAgent McShield audioendpointbuilder Antivirus AVP DCAgent bedbg EhttpSrv MMS ekrn EPSecurityService EPUpdateService ntrtscan EsgShKernel msexchangeadtopology AcrSch2Svc MSOLAP$TPSAMA Intel(R) PROSet Monitoring msexchangeimap4 ARSM unistoresvc_1af40a ReportServer$TPS MSOLAP$SYSTEM_BGC W3Svc MSExchangeSRS ReportServer$TPSAMA Zoolz 2 Service MSOLAP$TPS aphidmonitorservice SstpSvc MSExchangeMTA ReportServer$SYSTEM_BGC Symantec System Recovery UI0Detect MSExchangeSA MSExchangeIS ReportServer MsDtsServer110 POP3Svc MSExchangeMGMT SMTPSvc MsDtsServer IisAdmin MSExchangeES EraserSvc11710 Enterprise Client Service MsDtsServer100 NetMsmqActivator stc_raw_agent VSNAPVSS PDVFSService AcrSch2Svc Acronis CASAD2DWebSvc CAARCUpdateSvc McAfee avpsus DLPAgentService mfewc BMR Boot Service DefWatch ccEvtMgr ccSetMgr SavRoam RTVsc screenconnect ransom sqltelemetry msexch vnc teamviewer msolap veeam backup sql memtas vss sophos svc$ mepocs wuauserv EDR/AV drivers Blackbyte can bypass 360avflt.sys 360box.sys 360fsflt.sys 360qpesv.sys 5nine.cbt.sys a2acc.sys a2acc64.sys a2ertpx64.sys a2ertpx86.sys a2gffi64.sys a2gffx64.sys a2gffx86.sys aaf.sys aalprotect.sys abrpmon.sys accessvalidator.sys acdriver.sys acdrv.sys adaptivaclientcache32.sys adaptivaclientcache64.sys adcvcsnt.sys adspiderdoc.sys aefilter.sys agentrtm64.sys agfsmon.sys agseclock.sys agsyslock.sys ahkamflt.sys ahksvpro.sys ahkusbfw.sys ahnrghlh.sys aictracedrv_am.sys airship-filter.sys ajfsprot.sys alcapture.sys alfaff.sys altcbt.sys amfd.sys amfsm.sys amm6460.sys amm8660.sys amsfilter.sys amznmon.sys antileakfilter.sys antispyfilter.sys anvfsm.sys apexsqlfilterdriver.sys appcheckd.sys appguard.sys appvmon.sys arfmonnt.sys arta.sys arwflt.sys asgard.sys ashavscan.sys asiofms.sys aswfsblk.sys aswmonflt.sys aswsnx.sys aswsp.sys aszfltnt.sys atamptnt.sys atc.sys atdragent.sys atdragent64.sys aternityregistryhook.sys atflt.sys atrsdfw.sys auditflt.sys aupdrv.sys avapsfd.sys avc3.sys avckf.sys avfsmn.sys avgmfi64.sys avgmfrs.sys avgmfx64.sys avgmfx86.sys avgntflt.sys avgtpx64.sys avgtpx86.sys avipbb.sys avkmgr.sys avmf.sys awarecore.sys axfltdrv.sys axfsysmon.sys ayfilter.sys b9kernel.sys backupreader.sys bamfltr.sys bapfecpt.sys bbfilter.sys bd0003.sys bddevflt.sys bdfiledefend.sys bdfilespy.sys bdfm.sys bdfsfltr.sys bdprivmon.sys bdrdfolder.sys bdsdkit.sys bdsfilter.sys bdsflt.sys bdsvm.sys bdsysmon.sys bedaisy.sys bemk.sys bfaccess.sys bfilter.sys bfmon.sys bhdrvx64.sys bhdrvx86.sys bhkavka.sys bhkavki.sys bkavautoflt.sys bkavsdflt.sys blackbirdfsa.sys blackcat.sys bmfsdrv.sys bmregdrv.sys boscmflt.sys bosfsfltr.sys bouncer.sys boxifier.sys brcow_x_x_x_x.sys brfilter.sys brnfilelock.sys brnseclock.sys browsermon.sys bsrfsflt.sys bssaudit.sys bsyaed.sys bsyar.sys bsydf.sys bsyirmf.sys bsyrtm.sys bsysp.sys bsywl.sys bwfsdrv.sys bzsenspdrv.sys bzsenth.sys bzsenyaradrv.sys caadflt.sys caavfltr.sys cancelsafe.sys carbonblackk.sys catflt.sys catmf.sys cbelam.sys cbfilter20.sys cbfltfs4.sys cbfsfilter2017.sys cbfsfilter2020.sys cbsampledrv.sys cdo.sys cdrrsflt.sys cdsgfsfilter.sys centrifyfsf.sys cfrmd.sys cfsfdrv cgwmf.sys change.sys changelog.sys chemometecfilter.sys ciscoampcefwdriver.sys ciscoampheurdriver.sys ciscosam.sys clumiochangeblockmf.sys cmdccav.sys cmdcwagt.sys cmdguard.sys cmdmnefs.sys cmflt.sys code42filter.sys codex.sys conduantfsfltr.sys containermonitor.sys cpavfilter.sys cpavkernel.sys cpepmon.sys crexecprev.sys crncache32.sys crncache64.sys crnsysm.sys cruncopy.sys csaam.sys csaav.sys csacentr.sys csaenh.sys csagent.sys csareg.sys csascr.sys csbfilter.sys csdevicecontrol.sys csfirmwareanalysis.sys csflt.sys csmon.sys cssdlp.sys ctamflt.sys ctifile.sys ctinet.sys ctrpamon.sys ctx.sys cvcbt.sys cvofflineflt32.sys cvofflineflt64.sys cvsflt.sys cwdriver.sys cwmem2k64.sys cybkerneltracker.sys cylancedrv64.sys cyoptics.sys cyprotectdrv32.sys cyprotectdrv64.sys cytmon.sys cyverak.sys cyvrfsfd.sys cyvrlpc.sys cyvrmtgn.sys datanow_driver.sys dattofsf.sys da_ctl.sys dcfafilter.sys dcfsgrd.sys dcsnaprestore.sys deepinsfs.sys delete_flt.sys devmonminifilter.sys dfmfilter.sys dgedriver.sys dgfilter.sys dgsafe.sys dhwatchdog.sys diflt.sys diskactmon.sys dkdrv.sys dkrtwrt.sys dktlfsmf.sys dnafsmonitor.sys docvmonk.sys docvmonk64.sys dpmfilter.sys drbdlock.sys drivesentryfilterdriver2lite.sys drsfile.sys drvhookcsmf.sys drvhookcsmf_amd64.sys drwebfwflt.sys drwebfwft.sys dsark.sys dsdriver.sys dsfemon.sys dsflt.sys dsfltfs.sys dskmn.sys dtdsel.sys dtpl.sys dwprot.sys dwshield.sys dwshield64.sys eamonm.sys easeflt.sys easyanticheat.sys eaw.sys ecatdriver.sys edevmon.sys ednemfsfilter.sys edrdrv.sys edrsensor.sys edsigk.sys eectrl.sys eetd32.sys eetd64.sys eeyehv.sys eeyehv64.sys egambit.sys egfilterk.sys egminflt.sys egnfsflt.sys ehdrv.sys elock2fsctldriver.sys emxdrv2.sys enigmafilemondriver.sys enmon.sys epdrv.sys epfw.sys epfwwfp.sys epicfilter.sys epklib.sys epp64.sys epregflt.sys eps.sys epsmn.sys equ8_helper.sys eraser.sys esensor.sys esprobe.sys estprmon.sys estprp.sys estregmon.sys estregp.sys estrkmon.sys estrkr.sys eventmon.sys evmf.sys evscase.sys excfs.sys exprevdriver.sys failattach.sys failmount.sys fam.sys fangcloud_autolock_driver.sys fapmonitor.sys farflt.sys farwflt.sys fasdriver fcnotify.sys fcontrol.sys fdrtrace.sys fekern.sys fencry.sys ffcfilt.sys ffdriver.sys fildds.sys filefilter.sys fileflt.sys fileguard.sys filehubagent.sys filemon.sys filemonitor.sys filenamevalidator.sys filescan.sys filesharemon.sys filesightmf.sys filesystemcbt.sys filetrace.sys file_monitor.sys file_protector.sys file_tracker.sys filrdriver.sys fim.sys fiometer.sys fiopolicyfilter.sys fjgsdis2.sys fjseparettifilterredirect.sys flashaccelfs.sys flightrecorder.sys fltrs329.sys flyfs.sys fmdrive.sys fmkkc.sys fmm.sys fortiaptfilter.sys fortimon2.sys fortirmon.sys fortishield.sys fpav_rtp.sys fpepflt.sys fsafilter.sys fsatp.sys fsfilter.sys fsgk.sys fshs.sys fsmon.sys fsmonitor.sys fsnk.sys fsrfilter.sys fstrace.sys fsulgk.sys fsw31rj1.sys gagsecurity.sys gbpkm.sys gcffilter.sys gddcv.sys gefcmp.sys gemma.sys geprotection.sys ggc.sys gibepcore.sys gkff.sys gkff64.sys gkpfcb.sys gkpfcb64.sys gofsmf.sys gpminifilter.sys groundling32.sys groundling64.sys gtkdrv.sys gumhfilter.sys gzflt.sys hafsnk.sys hbflt.sys hbfsfltr.sys hcp_kernel_acq.sys hdcorrelatefdrv.sys hdfilemon.sys hdransomoffdrv.sys hdrfs.sys heimdall.sys hexisfsmonitor.sys hfileflt.sys hiofs.sys hmpalert.sys hookcentre.sys hooksys.sys hpreg.sys hsmltmon.sys hsmltwhl.sys hssfwhl.sys hvlminifilter.sys ibr2fsk.sys iccfileioad.sys iccfilteraudit.sys iccfiltersc.sys icfclientflt.sys icrlmonitor.sys iderafilterdriver.sys ielcp.sys ieslp.sys ifs64.sys ignis.sys iguard.sys iiscache.sys ikfilesec.sys im.sys imffilter.sys imfilter.sys imgguard.sys immflex.sys immunetprotect.sys immunetselfprotect.sys inisbdrv64.sys ino_fltr.sys intelcas.sys intmfs.sys inuse.sys invprotectdrv.sys invprotectdrv64.sys ionmonwdrv.sys iothorfs.sys ipcomfltr.sys ipfilter.sys iprotect.sys iridiumswitch.sys irongatefd.sys isafekrnl.sys isafekrnlmon.sys isafermon isecureflt.sys isedrv.sys isfpdrv.sys isirmfmon.sys isregflt.sys isregflt64.sys issfltr.sys issregistry.sys it2drv.sys it2reg.sys ivappmon.sys iwdmfs.sys iwhlp.sys iwhlp2.sys iwhlpxp.sys jdppsf.sys jdppwf.sys jkppob.sys jkppok.sys jkpppf.sys jkppxk.sys k7sentry.sys kavnsi.sys kawachfsminifilter.sys kc3.sys kconv.sys kernelagent32.sys kewf.sys kfac.sys kfileflt.sys kisknl.sys klam.sys klbg.sys klboot.sys kldback.sys kldlinf.sys kldtool.sys klfdefsf.sys klflt.sys klgse.sys klhk.sys klif.sys klifaa.sys klifks.sys klifsm.sys klrsps.sys klsnsr.sys klupd_klif_arkmon.sys kmkuflt.sys kmnwch.sys kmxagent.sys kmxfile.sys kmxsbx.sys ksfsflt.sys ktfsfilter.sys ktsyncfsflt.sys kubwksp.sys lafs.sys lbd.sys lbprotect.sys lcgadmon.sys lcgfile.sys lcgfilemon.sys lcmadmon.sys lcmfile.sys lcmfilemon.sys lcmprintmon.sys ldsecdrv.sys libwamf.sys livedrivefilter.sys llfilter.sys lmdriver.sys lnvscenter.sys locksmith.sys lragentmf.sys lrtp.sys magicbackupmonitor.sys magicprotect.sys majoradvapi.sys marspy.sys maxcryptmon.sys maxproc64.sys maxprotector.sys mbae64.sys mbam.sys mbamchameleon.sys mbamshuriken.sys mbamswissarmy.sys mbamwatchdog.sys mblmon.sys mcfilemon32.sys mcfilemon64.sys mcstrg.sys mearwfltdriver.sys message.sys mfdriver.sys mfeaack.sys mfeaskm.sys mfeavfk.sys mfeclnrk.sys mfeelamk.sys mfefirek.sys mfehidk.sys mfencbdc.sys mfencfilter.sys mfencoas.sys mfencrk.sys mfeplk.sys mfewfpk.sys miniicpt.sys minispy.sys minitrc.sys mlsaff.sys mmpsy32.sys mmpsy64.sys monsterk.sys mozycorpfilter.sys mozyenterprisefilter.sys mozyentfilter.sys mozyhomefilter.sys mozynextfilter.sys mozyoemfilter.sys mozyprofilter.sys mpfilter.sys mpkernel.sys mpksldrv.sys mpxmon.sys mracdrv.sys mrxgoogle.sys mscan-rt.sys msiodrv4.sys msixpackagingtoolmonitor.sys msnfsflt.sys mspy.sys mssecflt.sys mtsvcdf.sys mumdi.sys mwac.sys mwatcher.sys mwfsmfltr.sys mydlpmf.sys namechanger.sys nanoavmf.sys naswsp.sys ndgdmk.sys neokerbyfilter netaccctrl.sys netaccctrl64.sys netguard.sys netpeeker.sys ngscan.sys nlcbhelpi64.sys nlcbhelpx64.sys nlcbhelpx86.sys nlxff.sys nmlhssrv01.sys nmpfilter.sys nntinfo.sys novashield.sys nowonmf.sys npetw.sys nprosec.sys npxgd.sys npxgd64.sys nravwka.sys nrcomgrdka.sys nrcomgrdki.sys nregsec.sys nrpmonka.sys nrpmonki.sys nsminflt.sys nsminflt64.sys ntest.sys ntfsf.sys ntguard.sys ntps_fa.sys nullfilter.sys nvcmflt.sys nvmon.sys nwedriver.sys nxfsmon.sys nxrmflt.sys oadevice.sys oavfm.sys oczminifilter.sys odfsfilter.sys odfsfimfilter.sys odfstokenfilter.sys offsm.sys omfltlh.sys osiris.sys ospfile_mini.sys ospmon.sys parity.sys passthrough.sys path8flt.sys pavdrv.sys pcpifd.sys pctcore.sys pctcore64.sys pdgenfam.sys pecfilter.sys perfectworldanticheatsys.sys pervac.sys pfkrnl.sys pfracdrv.sys pgpfs.sys pgpwdefs.sys phantomd.sys phdcbtdrv.sys pkgfilter.sys pkticpt.sys plgfltr.sys plpoffdrv.sys pointguardvista64f.sys pointguardvistaf.sys pointguardvistar32.sys pointguardvistar64.sys procmon11.sys proggerdriver.sys psacfileaccessfilter.sys pscff.sys psgdflt.sys psgfoctrl.sys psinfile.sys psinproc.sys psisolator.sys pwipf6.sys pwprotect.sys pzdrvxp.sys qdocumentref.sys qfapflt.sys qfilter.sys qfimdvr.sys qfmon.sys qminspec.sys qmon.sys qqprotect.sys qqprotectx64.sys qqsysmon.sys qqsysmonx64.sys qutmdrv.sys ranpodfs.sys ransomdefensexxx.sys ransomdetect.sys reaqtor.sys redlight.sys regguard.sys reghook.sys regmonex.sys repdrv.sys repmon.sys revefltmgr.sys reveprocprotection.sys revonetdriver.sys rflog.sys rgnt.sys rmdiskmon.sys rmphvmonitor.sys rpwatcher.sys rrmon32.sys rrmon64.sys rsfdrv.sys rsflt.sys rspcrtw.sys rsrtw.sys rswctrl.sys rswmon.sys rtologon.sys rtw.sys ruaff.sys rubrikfileaudit.sys ruidiskfs.sys ruieye.sys ruifileaccess.sys ruimachine.sys ruiminispy.sys rvsavd.sys rvsmon.sys rw7fsflt.sys rwchangedrv.sys ryfilter.sys ryguard.sys safe-agent.sys safsfilter.sys sagntflt.sys sahara.sys sakfile.sys sakmfile.sys samflt.sys samsungrapidfsfltr.sys sanddriver.sys santa.sys sascan.sys savant.sys savonaccess.sys scaegis.sys scauthfsflt.sys scauthiodrv.sys scensemon.sys scfltr.sys scifsflt.sys sciptflt.sys sconnect.sys scred.sys sdactmon.sys sddrvldr.sys sdvfilter.sys se46filter.sys secdodriver.sys secone_filemon10.sys secone_proc10.sys secone_reg10.sys secone_usb.sys secrmm.sys secufile.sys secure_os.sys secure_os_mf.sys securofsd_x64.sys sefo.sys segf.sys segiraflt.sys segmd.sys segmp.sys sentinelmonitor.sys serdr.sys serfs.sys sfac.sys sfavflt.sys sfdfilter.sys sfpmonitor.sys sgresflt.sys shdlpmedia.sys shdlpsf.sys sheedantivirusfilterdriver.sys sheedselfprotection.sys shldflt.sys si32_file.sys si64_file.sys sieflt.sys simrep.sys sisipsfilefilter sk.sys skyamdrv.sys skyrgdrv.sys skywpdrv.sys slb_guard.sys sld.sys smbresilfilter.sys smdrvnt.sys sndacs.sys snexequota.sys snilog.sys snimg.sys snscore.sys snsrflt.sys sodatpfl.sys softfilterxxx.sys soidriver.sys solitkm.sys sonar.sys sophosdt2.sys sophosed.sys sophosntplwf.sys sophossupport.sys spbbcdrv.sys spellmon.sys spider3g.sys spiderg3.sys spiminifilter.sys spotlight.sys sprtdrv.sys sqlsafefilterdriver.sys srminifilterdrv.sys srtsp.sys srtsp64.sys srtspit.sys ssfmonm.sys ssrfsf.sys ssvhook.sys stcvsm.sys stegoprotect.sys stest.sys stflt.sys stkrnl64.sys storagedrv.sys strapvista.sys strapvista64.sys svcbt.sys swcommfltr.sys swfsfltr.sys swfsfltrv2.sys swin.sys symafr.sys symefa.sys symefa64.sys symefasi.sys symevent.sys symevent64x86.sys symevnt.sys symevnt32.sys symhsm.sys symrg.sys sysdiag.sys sysmon.sys sysmondrv.sys sysplant.sys szardrv.sys szdfmdrv.sys szdfmdrv_usb.sys szedrdrv.sys szpcmdrv.sys taniumrecorderdrv.sys taobserveflt.sys tbfsfilt.sys tbmninifilter.sys tbrdrv.sys tdevflt.sys tedrdrv.sys tenrsafe2.sys tesmon.sys tesxnginx.sys tesxporter.sys tffregnt.sys tfsflt.sys tgfsmf.sys thetta.sys thfilter.sys threatstackfim.sys tkdac2k.sys tkdacxp.sys tkdacxp64.sys tkfsavxp.sys tkfsavxp64.sys tkfsft.sys tkfsft64.sys tkpcftcb.sys tkpcftcb64.sys tkpl2k.sys tkpl2k64.sys tksp2k.sys tkspxp.sys tkspxp64.sys tmactmon.sys tmcomm.sys tmesflt.sys tmevtmgr.sys tmeyes.sys tmfsdrv2.sys tmkmsnsr.sys tmnciesc.sys tmpreflt.sys tmumh.sys tmums.sys tmusa.sys tmxpflt.sys topdogfsfilt.sys trace.sys trfsfilter.sys tritiumfltr.sys trpmnflt.sys trufos.sys trustededgeffd.sys tsifilemon.sys tss.sys tstfilter.sys tstfsredir.sys tstregredir.sys tsyscare.sys tvdriver.sys tvfiltr.sys tvmfltr.sys tvptfile.sys tvspfltr.sys twbdcfilter.sys txfilefilter.sys txregmon.sys uamflt.sys ucafltdriver.sys ufdfilter.sys uncheater.sys upguardrealtime.sys usbl_ifsfltr.sys usbpdh.sys usbtest.sys uvmcifsf.sys uwfreg.sys uwfs.sys v3flt2k.sys v3flu2k.sys v3ift2k.sys v3iftmnt.sys v3mifint.sys varpffmon.sys vast.sys vcdriv.sys vchle.sys vcmfilter.sys vcreg.sys veeamfct.sys vfdrv.sys vfilefilter.sys vfpd.sys vfsenc.sys vhddelta.sys vhdtrack.sys vidderfs.sys vintmfs.sys virtfile.sys virtualagent.sys vk_fsf.sys vlflt.sys vmwvvpfsd.sys vollock.sys vpdrvnt.sys vradfil2.sys vraptdef.sys vraptflt.sys vrarnflt.sys vrbbdflt.sys vrexpdrv.sys vrfsftm.sys vrfsftmx.sys vrnsfilter.sys vrsdam.sys vrsdcore.sys vrsdetri.sys vrsdetrix.sys vrsdfmx.sys vrvbrfsfilter.sys vsepflt.sys vsscanner.sys vtsysflt.sys vxfsrep.sys wats_se.sys wbfilter.sys wcsdriver.sys wdcfilter.sys wdfilter.sys wdocsafe.sys wfp_mrt.sys wgfile.sys whiteshield.sys windbdrv.sys windd.sys winfladrv.sys winflahdrv.sys winfldrv.sys winfpdrv.sys winload.sys winteonminifilter.sys wiper.sys wlminisecmod.sys wntgpdrv.sys wraekernel.sys wrcore.sys wrcore.x64.sys wrdwizfileprot.sys wrdwizregprot.sys wrdwizscanner.sys wrdwizsecure64.sys wrkrn.sys wrpfv.sys wsafefilter.sys wscm.sys xcpl.sys xendowflt.sys xfsgk.sys xhunter1.sys xhunter64.sys xiaobaifs.sys xiaobaifsr.sys xkfsfd.sys xoiv8x64.sys xomfcbt8x64.sys yahoostorage.sys yfsd.sys yfsd2.sys yfsdr.sys yfsrd.sys zampit_ml.sys zesfsmf.sys zqfilter.sys zsfprt.sys zwasatom.sys zwpxesvr.sys zxfsfilt.sys zyfm.sys zzpensys.sys
Cloud forensics: Forensic readiness and incident response in Azure Virtual Desktop
Co-authors: Dan Weinstock and Christoph Dreymann Azure Virtual Desktop (AVD) has rapidly become a core tool for enabling remote work at scale. Consequently, it’s also emerging as a target for threat actors. Recent Microsoft Incident Response engagements show that threat actors are exploiting AVD deployments for lateral movement and persistence. By hijacking legitimate AVD user accounts, they gain what is essentially a trusted “endpoint” inside the network without having to install malware. Why does this matter to incident responders? AVD intrusions can be stealthy and fast-moving, and responders must be prepared to detect and investigate suspicious AVD usage quickly. AVD’s architecture is not the same as a typical endpoint or server, so traditional forensic approaches alone may fall short. This blog post focuses on how to build forensic readiness in AVD and outlines investigation strategies to handle AVD-related incidents. We’ll cover the unique forensic challenges AVD presents, methods to collect critical data and best practices to allow incident responders to approach AVD investigation with confidence. Real-World Threat Actor Behaviors in AVD To put theory into context, consider some real threat actor behaviors Microsoft Incident Response – the Detection and Response Team (DART) has observed in AVD environments: Threat actors used stolen helpdesk credentials with AVD access to log in from a foreign IP address. In another case, threat actors compromised identities, leveraged their AVD sessions to pivot into on-premises resources using the AVD Virtual Machine (VM) as a steppingstone to RDP into other machines for lateral movement. Another threat actor accessed the browser in AVD to search internal SharePoint sites for sensitive data and intellectual property. Once threat actors hijack a legitimate, often poorly monitored AVD session, they gain a privileged execution environment without needing to deploy traditional malware. This enables threat actors to perform identity discovery, pivot across cloud/on-premises boundaries, exfiltrate data, and stage ransomware operations, emphasizing the necessity for robust logging, monitoring, and least-privilege configurations in virtual desktop environments. Forensic Challenges Unique to AVD Incident responders should enable forensic readiness by combining cloud-native and traditional methods to investigate, enable core logs for visibility, and understand how profiles are distributed across VMs and remote storage. AVD from the lens of a Threat Hunter An understanding of AVD architecture is essential for detection and response. AVD’s distinctive management of user sessions, profiles, and application delivery presents specific benefits and complexities when monitoring adversary activity. The system has the following fundamental components: Session Hosts – AVD’s multi-session architecture allows multiple users (or threat actors) to share a single underlying VM. Because these hosts are often ephemeral – frequently spun up and deallocated – offline evidence such as event logs or memory artifact can be lost quickly without proactive collection. When FSLogix is in use, user profiles are stored as VHDs in remote storage, rather than on the session host; browsing history, downloads, registry hives (i.e., NTUSER.DAT), MRU lists, and startup files live in these offloaded containers. Workspaces, Application Groups, & Host pools Workspaces serve as the top-level container, grouping resources and providing users with a single-entry point to their virtual desktops and applications. Application Groups determine which apps or desktops are published and define who can access them, shaping both user experience and permissions. Host Pools, on the other hand, are collections of session hosts – virtual machines that supply the compute power needed for user sessions. Azure Storage Accounts & FSLogix VHDs – because FSLogix stores each user’s profile as a VHD or VHDX file on Azure Files or a similar storage solution, investigators must know how to identify and export these VHDs and analyze them using tools like Autopsy or Eric Zimmerman’s utilities to recover user-centric artifact (i.e., browser history, downloads, NTUSER.DAT registry hives). This process is crucial when FSLogix is enabled, as no user data remains on the AVD host after logout. The following illustration demonstrates the relationship between the key components discussed above: Further information on that can be found within Azure Virtual Desktop for the enterprise - Azure Architecture Center. This clarifies that AVD is not simply "another VM"; rather, it is an Infrastructure-as-a-Service (IaaS) offering with a corresponding shared responsibility model, in which customers are accountable for identity management and the deployment of individual Azure resources. Logging Considerations Many actions such as user session brokering and application publishing are logged not on the VM but in Azure – if logging is enabled. By default, Azure Monitor diagnostics logs for AVD are not turned on. If an organization hasn’t enabled these, responders may lack crucial logs like when sessions started/ended, which applications were opened, or from what client IP address. Entra ID handles AVD authentication and therefore, Entra ID sign-in logs will provide further details and should be retained appropriately as well. Forensics implication: Misconfigured or missing diagnostic settings can hide evidence. Log sources The following table outlines various sources that provide comprehensive insights in the event of an incident: Artifact / Log Source Location & Access Method Host Forensics artifact On the AVD session host VM. AVD Diagnostic Logs (WVD* tables in Log Analytics) Azure Log Analytics workspace (if AVD Diagnostic Settings were enabled for Host Pools, Workspaces, and App Groups). Access via Kusto queries in the Logs blade or via Microsoft Sentinel. Key tables: WVDFeeds - Shows what published applications were visible. Also shows ClientIP and ClientType. WVDConnections - Shows Client IP address, clientType, ConnectionType, ResourceAlias and which host they connected to. WVDCheckpoints - Find which published App was used and Path for execution of Published App Entra ID Sign-In Logs Entra ID (Azure AD) tenant logs. Access via Azure Portal > Entra ID > Sign-in logs, or query the SigninLogs table in Sentinel/Log Analytics. Endpoint Detection and Response (EDR) Telemetry, for example Microsoft Defender for Endpoint (MDE) Specifically for MDE, Looking at Microsoft 365 Defender portal (Devices section) or via Advanced Hunting queries (DeviceProcessEvents, DeviceNetworkEvents). This requires the AVD session host VMs to be onboarded as monitored devices in MDE.* Network Flow Logs (NSG and Firewall logs) Azure Network Watcher’s NSG flow logs (if enabled on the VM’s subnet/NIC) stored in a storage account or Log Analytics; and/or Azure Firewall logs if an Azure Firewall is in the path. These may also be surfaced via Microsoft Sentinel. FSLogix User Profile Container (VHD/VHDX) Stored on Azure Storage (Azure Files share or NetApp Files). Access by locating the user’s profile .vhd(x) in the storage account and downloading it (i.e., via Azure Storage Explorer or generating an SAS URL). * Onboard non-persistent virtual desktop infrastructure (VDI) devices - Microsoft Defender for Endpoint | Microsoft Learn Enabling diagnostic logs Enabling diagnostic logs in AVD Azure resources offers valuable insights into session activities and remote application usage for detecting anomalies, tracing threat actor activity, and supporting forensic investigations. For threat hunting, the most relevant log tables include: WVDFeeds – shows which published applications were available, including ClientIP and ClientType details. WVDConnections – lists information such as Client IP address, clientType, ConnectionType, ResourceAlias, and host connection data. WVDCheckpoints – indicates which published application was accessed and supplies its execution path. You can enable these logs via the diagnostics settings for Host Pool, Application Group, and Workspace Azure resources. If an incident occurs, these logs help determine exactly what a threat actor interacted with, which is vital for assessing whether additional logs should be collected. Forensic Data Collection Strategies When an incident is suspected in an AVD environment, investigators need a plan for acquiring and preserving evidence: Live vs. Offline Collection – disk and memory artifact can be captured either from a running system or from an offline snapshot. Live collection can recover volatile data like memory (RAM) but might miss user profile content when FSLogix is in use. In such cases, focus on offline acquisition by generating a snapshot of the relevant disk or file share and downloading the associated VHD. For live or offline captures, you can leverage widely used forensic tools such as Velociraptor (for remote collection across endpoints) or disk forensics tools like Autopsy to extract and analyze forensic data. Disk Snapshots – to acquire disks for offline collection and analysis, create a snapshot of the AVD Host VM disk and export it to your designated collection and analysis environment. The high-level steps are captured here. Storage account VHD Extraction – if FSLogix is enabled, user profiles are stored as VHD containers in Azure Storage. To review user data such as browser history, downloads, NTUSER.DAT, MRU lists, startup folders, and other profile artifacts you have to download the VHD that matches the username within the Azure Storage account. More about Storage account forensics can be found within Cloud forensics: Why enabling Microsoft Azure Storage Account logs matters. Artifact Analysis: What to Look for on a Host Once the user’s profile VHD and VM Host disk snapshot are acquired, analysts should focus on: Browser Data – cached web history, downloads, and session cookies can reveal malicious downloads or credential collection attempts. Threat actors frequently exploit post-breach browser access to scrape credentials, hijack sessions, or implant malicious extensions. User Registry Hives – files like NTUSER.DAT contain valuable user-specific configuration settings and MRU (Most Recently Used) lists that can reveal executed commands or opened documents. Startup Items and Temporary Directories – malicious payloads or scripts often persist by storing components in startup folders or system temp directories. These may be visible only within the user VHD if FSLogix is in use. Jump Lists and Shell Bags – these systems cache file access and folder navigation actions, offering timelines and insights into threat actoractivities. Threat Hunting in AVD Environments Threat hunting in AVD environments requires three critical dimensions: Identity, Azure platform, and host/endpoint artifact. Each layer provides unique signals and telemetry that, when correlated, help uncover malicious activity and reduce dwell time. Identity – investigate authentication patterns, privilege escalations, and anomalous sign-ins across Entra ID and related identity providers. Azure – examine control-plane operations, resource configurations, and subscription-level activities for indicators of compromise or persistence mechanisms. Host/Endpoint Artifacts – analyze session hosts for forensic traces such as browser history, file events, and registry changes that may reveal lateral movement or payload deployment. By combining insights from these components, defenders can build a threat-hunting strategy tailored for AVD’s distributed architecture. Core Hunting Objectives When hunting in AVD environments, start with three fundamental questions: Where did the threat actor log in from? – identify unusual or foreign IP addresses and devices accessing your host pools. What did they do once inside? – track actions within the session host, such as which applications were launched, commands executed, or files accessed. Where did they go next? – look for lateral movement to other resources (cloud or on-premises) and evidence of persistence (i.e., credential artifacts, backdoor accounts). These questions form the basis for iterative, hypothesis-driven hunts, allowing you to “follow the thread” and adapt as you uncover new evidence – be it new accounts, unexpected machines, or suspicious process trees. The following diagram illustrates a standard hunting process from the initial event through hunting within the entire environment and cross-domain correlation: Today’s security tools can make this process easier. Microsoft Sentinel combines Entra ID logs, AVD diagnostics, and MDE events into one place, so you can use KQL queries and workbooks to link related data, like joining Sign-in Logs and WVDConnections using the same user and timestamp. With MDE’s Advanced Hunting feature, you can query across endpoints; for example, you might review all AVD host devices for certain indicators or activity patterns, such as listing processes that ran during a suspected breach. The aim is to build a complete picture of the incident. Sample Hunting Queries Below are example Sentinel queries tailored to address the core hunting objectives. These should be adapted to your environment and replace dummy values with real user names, host identifiers, or IP ranges. Where did the threat actor log in from? Hunt for the suspicious user in the Entra Sign-in logs: SigninLogs | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserPrincipalName has "<<Suspicious User>>" | where AppDisplayName has "Azure Virtual Desktop | project-reorder TimeGenerated, UserPrincipalName, AppDisplayName, ResultType, ClientAppUsed, DeviceDetail, IPAddress, UserAgent | summarize FirstDate=min(TimeGenerated), LastDate=max(TimeGenerated), count() by UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, UserAgent Sign-in events to AVD always use the below Entra Applications. Both the application name and ID can be hunted on: What did they do once inside? To investigate a potential security incident within AVD, it is important to review the user activity within the diagnostic logs. Therefore, we are looking next into the diagnostic logs tables WVDFeeds, WVDConnections, and WVDCheckpoints to get a better understanding of what has happened: WVDFeeds Displays the published applications that are accessible, as well as the ClientIP and ClientType information. WVDFeeds | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserName has <<UserName>> //splitting the IP as the ClientIP is shown with port i.e. 1.1.1.1:54282 | extend ClientIP = tostring(split(ClientSideIPAddress, ":")[0]) | summarize FirstDate = min(TimeGenerated), LastDate = max(TimeGenerated), count() by UserName, ClientOS, ClientType, ClientIP WVDConnections Displays the Client IP address, client type, connection type (Desktop or App), resource alias, and the host (from the host pool) to which the client has connected. WVDConnections | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserName has <<UserName>> | project-reorder TimeGenerated, UserName,ClientSideIPAddress, ClientOS, ConnectionType, SessionHostName, SessionHostPoolType, State | sort by TimeGenerated asc WVDCheckpoints Determine which published application was utilized. It shows also the Operation conducted when a session was started. WVDCheckpoints | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | extend ConnectionStage = tostring(Parameters.connectionStage) | extend AppFileName = tostring(Parameters.filename) //It is only populated when it published App and not Desktop Session | extend Operation= Name | project-reorder TimeGenerated, UserName, ActivityType, Source, Operation, AppFileName, ConnectionStage Advanced Hunting in Microsoft Defender for Endpoint Now that the AVD host has been identified, you can then deep dive further by focusing on EDR and host forensic logs. If MDE Advanced Hunting is enabled, the following tables helps often to understand what happened on a system: DeviceNetworkEvents DeviceProcessEvents DeviceRegistryEvents Further tables within MDE and the Device Timeline help to get a full picture of what happened. Lateral Movement After gaining access to an AVD session host, threat actors often attempt lateral movement to expand their foothold or establish persistence. This can involve pivoting to other session hosts, Azure resources, or even on-premises systems. Focus on the following tables/log sources: Firewall logs (On premise / Cloud) DeviceNetworkEvents (Cloud: Defender) DeviceProcessEvents (Cloud: Defender) DeviceRegistryEvents (Cloud: Defender) NSG logs (Diagnostic Logs) Windows EventsLogs (Collected host logs) Best Practices for AVD Forensic Readiness The following measures enhance forensic processes for Azure Virtual Desktop: Implement an endpoint detection and response product – deploy an endpoint detection and response (EDR) solution to provide advanced detection and response capabilities on AVD VMs. Enable and export comprehensive logging – activate diagnostic logging for all host pools, workspaces, and application groups. Ensure these logs are exported to a Log Analytics workspace or a security information and event management (SIEM) platform such as Microsoft Sentinel. Develop forensic workflows for AVD – establish and document clear forensic workflows for AVD incident response. This should cover the entire process, from detecting suspicious activity, through live or offline evidence acquisition, to verifying FSLogix profile stores, exporting VHDs, and analyzing collected artifacts. Security Recommendations for Azure Virtual Desktop When implementing AVD, it is vital to follow recommended security practices. These strategies complement the best practices for forensic readiness and ensure that both proactive and reactive security measures are in place. Review Microsoft AVD Security Guidance – utilize the official Microsoft documentation for Azure Virtual Desktop security to guide your deployment and operational security policies. The resource provides up-to-date recommendations on securing your AVD environment. Enable MFA on all users – implement multi-factor authentication (MFA) for every user accessing Azure Virtual Desktop to ensure an additional layer of security beyond just passwords. Where possible, implement phish-resistant MFA for maximum protection. If full adoption isn’t practical, prioritize high-risk accounts and critical roles first. Enable Conditional Access – utilize Conditional Access policies to proactively manage and mitigate risks before granting access to your AVD environment. This helps ensure only legitimate users and trusted devices can connect to your resources. Regularly review Conditional Access policies for exceptions and minimize them wherever possible. Implement detection and alerting for any changes to CAP configurations to maintain a strong security posture. More information can be found in the following article from Microsoft - Security recommendations for Azure Virtual Desktop - Azure Virtual Desktop | Microsoft Learn Conclusion As the threat landscape evolves, cloud-hosted virtual desktops become both enablers of productivity and channels for threat actor persistence. By applying robust logging configurations, understanding the unique forensic challenges of FSLogix and AVD, and enhancing your threat hunting capabilities, you can achieve higher levels of forensic readiness. This preparedness not only accelerates investigations when incidents occur but also strengthens the overall security posture of your organization. Proactive planning today is essential to respond to tomorrow’s threats with confidence and clarity.Cloud forensics: Why enabling Microsoft Azure Storage Account logs matters
Co-authors - Christoph Dreymann - Shiva P Introduction Azure Storage Accounts are frequently targeted by threat actors. Their goal is to exfiltrate sensitive data to an external infrastructure under their control. Because diagnostic logging is not always fully enabled by default, valuable evidence of their malicious actions may be lost. With this blog, we will explore realistic attack scenarios and demonstrate the types of artifacts those activities generate. By properly enabling Microsoft Azure Storage Account logs investigators gain a better understanding of the scope of the incident. The information can also provide guidance for remediating the environment and on preventing data theft from occurring again. Storage Account A Storage Account provides scalable, secure, and highly available storage for storing and managing data objects. Due to the variety of sensitive data that can be stored, it is another highly valued target by a threat actor. Threat actors exploit misconfigurations, weak access controls, and leaked credentials to gain unauthorized access. Key risks include Shared Access Signature token (SAS) misuse that allows threat actors to access or modify exposed blob storages. Storage Account key exposure could grant privileged access to the data plane. Investigating storage-related security incidents requires familiarity with Azure activity logs and Diagnostic logs. Diagnostic log types for Storage accounts are StorageBlob, StorageFile, StorageQueue, and StorageTable. These logs can help identify unusual access patterns, role changes, and unauthorized SAS token generation. This blog is centered around StorageBlob activity logs. Storage Account logging The logs for a Storage Account aren’t enabled by default. These logs capture operations, requests, and use such as read, write, and delete actions/requests on storage objects like blobs, queues, files, or tables. NOTE: There are no license requirements to enable Storage Account logging, but Log Analytics charges based on ingestion and retention (Pricing - Azure Monitor | Microsoft Azure) For more information on enabling logging for a Storage Account can be found here. Notable fields The log entries contain various fields which are of use not only during or after an incident, but for general monitoring of a storage account during normal operations (for a full list, see what data is available in the Storage Logs). Once the storage log is enabled, one of the key tables within Log Analytics is StorageBlobLogs, which provides details about blob storage operations, including read, write, and delete actions. Key columns such as OperationName, AuthenticationType, StatusText, and UserAgentHeader capture essential information about these activities. The OperationName field identifies operations on a storage account, such as “PutBlob” for uploads or “DeleteBlob” and “DeleteFile” for deletions. The UserAgentHeader fields offer valuable insights into the tools used to access a Blob storage. Accessing blob storages through the Azure portal is typically logged with a generic user agent, which indicates the application used to perform the access, such as a web browser like Mozilla Firefox. In contrast, tools like AzCopy or Microsoft Azure Storage Explorer are explicitly identified in the logs. Analyzing the UserAgentHeader provides crucial details about the access method, helping determine how the blob storage was accessed. The following table includes additional investigation fields, Field name Description TimeGenerated [UTC] The date and time of the operation request. AccountName Name of the Storage account. OperationName Name of the operation. A detailed list of for StorageBlob operation can be found here. AuthenticationType The type of authentication that was used to make this request. StatusCode The HTTP status code for the request. If the request is interrupted, this value might be set to Unknown. StatusText The status of the requested operation. Uri Uniform resource identifier that is requested. CallerIpAddress The IP address of the requester, including the port number. UserAgentHeader The User-Agent header value. ObjectKey Provides the path of the object requested. RequesterUpn User Principal Name of the requester. AuthenticationHash Hash of the authentication token used during a request. Request authenticated with SAS token includes a SAS signature specifying the hash derived from the signature part of the SAS token. For a full list, see what data is available in the Storage Logs. How a threat actor can access a Storage Account Threat actors can access the Storage Account through Azure-assigned RBAC, a SAS token (including User delegated SAS token), Azure Storage Account Keys and Anonymous Access (if configured). Storage Account Access Keys Azure Storage Account Access Keys are shared secrets that enable full access to Azure storage resources. When creating a storage account, Azure generates two access keys, both can be used for authentication with the storage account. These keys are permanent and do not have an expiration date. Both Storage Account Owners and roles such as Contributor or any other role with the assigned action of Microsoft.Storage/storageAccounts/listKeys/action can retrieve and use these credentials to access the storage account. Account Access Keys can be rotated/regenerated but if done unintentionally, it could disrupt applications or services dependent on the key for authentication. Additionally, this action invalidates any SAS tokens derived from that key, potentially revoking access to dependent workflows. Monitoring key rotations can help detect unexpected changes and mitigate disruptions. Query: This query can help identify instances of account key rotations in the logs AzureActivity | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION" | where ActivityStatusValue has "Start" | extend resource = parse_json(todynamic(Properties).resource) | extend requestBody = parse_json(todynamic(Properties).requestbody) | project TimeGenerated, OperationNameValue, resource, requestBody, Caller, CallerIpAddress Shared Access Signature SAS tokens offer a granular method for controlling access to Azure storage resources. SAS tokens enable specific permitted actions on a resource and their duration. They can be generated for blobs, queues, tables, and file shares within a storage account, providing precise control over data access. A SAS token allows access via a signed URL. A Storage Account Owner can generate a SAS token and connection strings for various resources within the storage account (e.g., blobs, containers, tables) without restrictions. Additionally, roles with Microsoft.Storage/storageAccounts/listKeys/action rights can also generate SAS tokens. SAS tokens enable access to storage resources using tools such as Azure Storage Explorer, Azure CLI, or PowerShell. It is important to note that the logs do not indicate when a SAS token was generated [How a shared access signature works]. However, their usage can be inferred by tracking configuration changes that enable the use of storage account keys option which is disabled by default. Figure 1: Configuration setting to enable account key access Query: This query is designed to detect configuration changes made to enable access via storage account keys AzureActivity | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" | where ActivityStatusValue has "Success" | extend allowSharedKeyAccess = parse_json(tostring(parse_json(tostring(parse_json(Properties).responseBody)).properties)).allowSharedKeyAccess | where allowSharedKeyAccess == "true" User delegated Shared Access Signature A User Delegation SAS is a type of SAS token that is secured using Microsoft Entra ID credentials rather than the storage account key. For more details see Authorize a user delegation SAS. To request a SAS token using the user delegation key, the identity must possess the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action (see Assign permissions with RBAC). Azure Role-Based Access Control A threat actor must identify a target (an identity) that can assign roles or already holds specific RBAC roles. To assign Azure RBAC roles, an identity must have Microsoft.Authorization/roleAssignments/write, which allows the assignment of roles necessary for accessing storage accounts. Some examples of roles that provide permissions to access data within Storage Account (see Azure built-in roles for blob): Storage Account Contributor (Read, Write, Manage Access) Storage Blob Data Contributor (Read, Write) Storage Blob Data Owner (Read, Write, Manage Access) Storage Blob Data Reader (Read Only) Additionally, to access blob data in the Azure portal, a user must also be assigned the Reader role (see Assign an Azure role). More information about Azure built-in roles for a Storage Account can be found here Azure built-in roles for Storage. Anonymous Access If the storage account configuration 'Allow Blob anonymous access' is set to enabled and a container is created with anonymous read access, a threat actor could access the storage contents from the internet without any authorization. Figure 2: Configuration settings for Blob anonymous access and container-level anonymous access. Query: This query helps identify successful configuration changes to enable anonymous access AzureActivity | join kind=rightouter (AzureActivity | where TimeGenerated > ago(30d) | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" | where Properties has "allowBlobPublicAccess" | extend ProperTies = parse_json(Properties) | evaluate bag_unpack(ProperTies) | extend allowBlobPublicAccess = todynamic(requestbody).properties["allowBlobPublicAccess"] | where allowBlobPublicAccess has "true" | summarize by CorrelationId) on CorrelationId | extend ProperTies = parse_json(Properties) | evaluate bag_unpack(ProperTies) | extend allowBlobPublicAccess_req = todynamic(requestbody).properties["allowBlobPublicAccess"] | extend allowBlobPublicAccess_res = todynamic(responseBody).properties["allowBlobPublicAccess"] | extend allowBlobPublicAccess = case (allowBlobPublicAccess_req!="", allowBlobPublicAccess_req, allowBlobPublicAccess_res!="", allowBlobPublicAccess_res, "") | project OperationNameValue, ActivityStatusValue, ResourceGroup, allowBlobPublicAccess, Caller, CallerIpAddress, ResourceProviderValue Key notes regarding the authentication methods When a user accesses Azure Blob Storage via the Azure portal, the interaction is authenticated using OAuth and is authorized by the Azure RBAC roles configuration for the given user. In contrast, authentication using Azure Storage Explorer and AzCopy depends on the method used: If a user interactively signs in via the Azure portal or utilizes the Device code flow, authentication appears as OAuth based. When using a SAS token, authentication is recorded as SAS-based for both tools. Access via Azure RBAC is logged in Entra ID Sign-in Logs, however, activity related to SAS token usage does not appear in the sign-in logs, as it provides pre-authorized access. Log analysis should consider all operations, since initial actions can reveal the true authentication method even OAuth-based access may show as SAS in logs. The screenshot below illustrates three distinct cases, each showcasing different patterns of authentication types used when accessing storage resources. A SAS token is consistently used across various operations, where the SAS token is the primary access method. The example below highlighted as ‘2’ demonstrates a similar pattern, with OAuth (using assigned Azure RBAC role) serving as the primary authentication method for all listed operations. Lastly, example number ‘3’, Operations start with OAuth authentication (using an assigned Azure RBAC role for authorization) and then uses a SAS token, indicating mixed authentication types. Figure 3: Different patterns of authentication types Additionally, when using certain applications such as Azure Storage Explorer with Account Access Keys authentication, the initial operations such as ListContainers and ListBlob are logged with the authentication type reported as “AccountKey”. However, for subsequent actions like file uploads or downloads, the authentication type switches to SAS in the logs. To accurately determine whether an Account Access Keys or SAS was used, it's important to correlate these actions with the earlier enumeration or sync activity within the logs. With this understanding, let’s proceed to analyze specific attack scenarios by utilizing the log analytics, such as the StorageBlobLogs table. Attack scenario This section will examine the typical steps that a threat actor might take when targeting a Storage Account. We will specifically focus on the Azure Resource Manager layer, where Azure RBAC initially dictates what a threat actor can discover. Enumeration During enumeration, a threat actor’s goal is to map out the available storage accounts. The range of this discovery is decided by the access privileges of a compromised identity. If that identity holds at least a minimum level of access (similar to a Reader) at the subscription level, it can view storage account resources without making any modifications. Importantly, this permission level does not grant access to the actual data stored within the Azure Storage itself. Hence, a threat actor is limited to interacting only with those storage accounts that are visible to them. To access and download files from Blob Storage, a threat actor must be aware of the names of containers (Operation: ListContainers) and the files within those containers (Operation: ListBlobs). All interactions with these storage elements are recorded in the StorageBlobLogs table. Containers or blobs in a container can be listed by a threat actor with the appropriate access rights. If access is not authorized, attempts to do so will result in error codes shown in the StatusCode field. A high number of unauthorized attempts resulting in errors would be a key indicator of suspicious activity or misconfiguration. Figure 4: Failure attempts to list blobs/containers Query: This query serves as a starting point for detecting a spike in unauthorized attempts to enumerate containers, blobs, files, or queues union Storage* | extend StatusCodeLong = tolong(StatusCode) | where OperationName has_any ("ListBlobs", "ListContainers", "ListFiles", "ListQueues") | summarize MinTime = min(TimeGenerated), MaxTime = max(TimeGenerated), OperationCount = count(), UnauthorizedAccess = countif(StatusCodeLong >= 400), OperationNames = make_set(OperationName), ErrorStatusCodes = make_set_if(StatusCode, StatusCodeLong >= 400), StorageAccountName = make_set(AccountName) by CallerIpAddress | where UnauthorizedAccess > 0 Note: The UnauthorizedAccess filter attribute must be adjusted based on your environment. Data exfiltration Let’s use the StorageBlobLogs to analyze two different attack scenarios. Scenario 1: Compromised user has access to a storage account In this scenario, the threat actor either compromises a user account with access to one or more storage accounts or alternatively, obtains a leaked Account Access Key or SAS token. With a compromised identity, the threat actor can either enumerate all storage accounts the user has permissions to (as covered in enumeration) or directly access a specific blob or container if the leaked key grants scoped access. Account Access Keys (AccountKey)/SAS tokens The threat actor might either use the storage account’s access keys or SAS token retrieved through the compromised user account provided they have the appropriate permissions or the leaked key itself may already be either an Account access key or SAS token. Access keys grant complete control while SAS key can generate a time-bound access, to authorize data transfers enabling them to view, upload, or download data at will. Figure 5: Account key used to download/view data Figure 6: SAS token used to download/view data Query: This query helps identify cases where an AccountKey/SAS was used to download/view data from a storage account StorageBlobLogs | where OperationName has "GetBlob" | where AuthenticationType in~ ("AccountKey", "SAS") | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project TimeGenerated, AccountName, OperationName, RequesterUpn, AuthenticationType, Uri, ObjectKey, StatusText, UserAgentHeader, CallerIpAddress, AuthenticationHash User Delegation SAS Available for Blob Storage only, a User Delegation SAS functions similar to a SAS but is protected with Microsoft Entra ID credentials rather than the storage account key. The creation of a User Delegation SAS is tracked as a corresponding "GetUserDelegationKey" log entry in StorageBlobLogs table. Figure 7: User-Delegation Key created Query: This query helps identify creation of a User-Delegation Key. The RequesterUpn provides the identity of the user account creating this key. StorageBlobLogs | where OperationName has "GetUserDelegationKey" | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project TimeGenerated, AccountName, OperationName, RequesterUpn, Uri, CallerIpAddress, ObjectKey, AuthenticationType, StatusCode, StatusText Figure 8: User-Delegation activity to download/read Query: This query helps identify cases where a download/read action was initiated while authenticated via a User delegation key StorageBlobLogs | where AuthenticationType has "DelegationSas" | where OperationName has "GetBlob" | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project Type, TimeGenerated, OperationName, AccountName, UserAgentHeader, ObjectKey, AuthenticationType, StatusCode, CallerIpAddress, Uri The operation "GetUserDelegationKey" within the StorageBlobLogs captures the identity responsible for generating a User Delegation SAS token. The AuthenticationHash field shows the Key used to sign the SAS token. When the SAS token is used, any operations will include the same SAS signature hash enabling you to correlate various actions performed using this token even if the originating IP addresses differ. Query: The following query extracts a SAS signature hash from the AuthenticationHash field. This helps to track the token's usage, providing an audit trail to identify potentially malicious activity. StorageBlobLogs | where AuthenticationType has "DelegationSas" | extend SasSHASignature = extract(@"SasSignature\((.*?)\)", 1, AuthenticationHash) | project Type, TimeGenerated, OperationName, AccountName, UserAgentHeader, ObjectKey, AuthenticationType, StatusCode, CallerIpAddress In the next scenario, we examine how a threat actor already in control of a compromised identity uses Azure RBAC to assign permissions. With administrative privileges over a storage account, the threat actor can grant access to additional accounts and establish long-term access to the storage accounts. Scenario 2: A user account is controlled by the threat actor and has elevated access to the Storage Account An identity named Bob was identified as compromised due to an unauthorized IP login. The investigation triggers when Azure Sign-in logs reveal logins originating from an unexpected location. This account has owner permissions for a resource group, allowing full access and role assignments in Azure RBAC. The threat actor grants access to another account they control, as shown in the AzureActivity logs. The AzureActivity logs in the figure below show that Reader, Data Access, and Storage Account Contributor roles were assigned to Hacker2 for a Storage Account within Azure: Figure 9: Assigning a role to a user Query: This query helps identify if a role has been assigned to a user AzureActivity | where Caller has "Bob" | where OperationNameValue has "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" | extend RoleDefintionIDProperties = parse_json(Properties) | evaluate bag_unpack(RoleDefintionIDProperties) | extend RoleDefinitionIdExtracted = tostring(todynamic(requestbody).Properties.RoleDefinitionId) | extend RoleDefinitionIdExtracted = extract(@"roleDefinitions/([a-f0-9-]+)", 1, RoleDefinitionIdExtracted) | extend RequestedRole = case( RoleDefinitionIdExtracted == "ba92f5b4-2d11-453d-a403-e96b0029c9fe", "Storage Blob Data Contributor", RoleDefinitionIdExtracted == "b7e6dc6d-f1e8-4753-8033-0f276bb0955b", "Storage Blob Data Owner", RoleDefinitionIdExtracted == "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1", "Storage Blob Data Reader", RoleDefinitionIdExtracted == "db58b8e5-c6ad-4a2a-8342-4190687cbf4a", "Storage Blob Delegator", RoleDefinitionIdExtracted == "c12c1c16-33a1-487b-954d-41c89c60f349", "Reader and Data Access", RoleDefinitionIdExtracted == "17d1049b-9a84-46fb-8f53-869881c3d3ab","Storage Account Contributor", "") | extend roleAssignmentScope = tostring(todynamic(Authorization_d).evidence.roleAssignmentScope) | extend AuthorizedFor = tostring(todynamic(requestbody).Properties.PrincipalId) | extend AuthorizedType = tostring(todynamic(requestbody).Properties.PrincipalType) | project TimeGenerated, RequestedRole, roleAssignmentScope, ActivityStatusValue, Caller, CallerIpAddress, CategoryValue, ResourceProviderValue, AuthorizedFor, AuthorizedType Note: Refer to this resource for additional Azure in-built role IDs that can be used in this query. The Sign-in logs indicate that Hacker2 successfully accessed Azure from the same malicious IP address. We can examine StorageBlobLogs to determine if the user accessed data of the blob storage since specific roles related to the Storage Account were assigned to them. The activities within the blob storage indicate several entries attributed to the Hacker2 user, as shown in the figure below. Figure 10: User access to blob storage Query: This query helps identify access to blob storage from a malicious IP StorageBlobLogs | where TimeGenerated > ago (30d) | where CallerIpAddress has {{IPv4}} | extend ObjectName= ObjectKey | project TimeGenerated, AccountName, OperationName, AuthenticationType, StatusCode, StatusText, RequesterUpn, CallerIpAddress, UserAgentHeader, ObjectName, Category An analysis of the StorageBlobLogs, as shown in the figure below, reveals that Hacker2 performed a "StorageRead" operation on three files. This indicates that data was accessed or downloaded from blob storage. Figure 11: Blob Storage Read/Download activities The UserAgentHeader suggests that the storage account was accessed through the Azure portal. Consequently, the SignInLogs can offer further detailed information. Query: This query checks for read, write, or delete operations in blob storage and their access methods, StorageBlobLogs | where TimeGenerated > ago(30d) | where CallerIpAddress has {{IPv4}} | where OperationName has_any ("PutBlob", "GetBlob", "DeleteBlob") and StatusText == "Success" | extend Notes = case( OperationName == "PutBlob" and Category == "StorageWrite" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was written through Azure Storage Explorer", OperationName == "PutBlob" and Category == "StorageWrite" and UserAgentHeader has "AzCopy", "Blob was written through AzCopy Command", OperationName == "PutBlob" and Category == "StorageWrite" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was written through Azure portal", OperationName == "GetBlob" and Category == "StorageRead" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was Read/Download through Azure Storage Explorer", OperationName == "GetBlob" and Category == "StorageRead" and UserAgentHeader has "AzCopy", "Blob was Read/Download through AzCopy Command", OperationName == "GetBlob" and Category == "StorageRead" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was Read/Download through Azure portal", OperationName == "DeleteBlob" and Category == "StorageDelete" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was deleted through Azure Storage Explorer", OperationName == "DeleteBlob" and Category == "StorageDelete" and UserAgentHeader has "AzCopy", "Blob was deleted through AzCopy Command", OperationName == "DeleteBlob" and Category == "StorageDelete" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was deleted through Azure portal","") | project TimeGenerated, AccountName, OperationName, AuthenticationType, StatusCode, CallerIpAddress, ObjectName=ObjectKey, Category, RequesterUpn, Notes The log analysis confirms that the threat actor successfully extracted data from a storage account. Storage Account summary Detecting misuse within a Storage Account can be challenging, as routine operations may hide malicious activities. However, enabling logging is essential for investigation to help track accesses, especially when compromised identities or misused SAS tokens or keys are involved. Unusual changes in user permissions and irregularities in role assignments which are documented in the Azure Activity Logs, can signal unauthorized access, while Microsoft Entra ID sign-in logs can help identify compromised UPNs and suspicious IP addresses that ties into OAuth-based storage account access. By thoroughly analyzing Storage Account logs which details operation types and access methods, investigators can identify abuse and determine the scope of compromise. That not only helps when remediating the environment but can also provide guidance on preventing unauthorized data theft from occurring again.
