Microsoft has not yet attributed StilachiRAT to a specific threat actor or geolocation. Based on Microsoft’s current visibility, the malware does not exhibit widespread distribution at this time. However, due to its stealth capabilities and the rapid changes within the malware ecosystem, we are sharing these findings as part of our ongoing efforts to monitor, analyze, and report on the evolving threat landscape.

Microsoft security solutions can detect activities related to attacks that use StilachiRAT. To help defenders protect their network, we are also sharing mitigation guidance to help reduce the impact of this threat, detection details, and hunting queries. Microsoft continues to monitor information on the delivery vector used in these attacks. Malware like StilachiRAT can be installed through multiple vectors; therefore, it is critical to implement security hardening measures to prevent the initial compromise. 

This blog presents our detailed findings on all the key capabilities of StilachiRAT, which include:

• System reconnaissance: Collects comprehensive system information, including operating system (OS) details, hardware identifiers, camera presence, active Remote Desktop Protocol (RDP) sessions, and running graphical user interface (GUI) applications, allowing detailed profiling of the target system.
• Digital wallet targeting: Scans for configuration data of 20 different cryptocurrency wallet extensions for the Google Chrome browser.
• Credential theft: Extracts and decrypts saved credentials from Google Chrome, gaining access to usernames and passwords stored in the browser.
• Command-and-control (C2) connectivity: Establishes communication with remote C2 servers using TCP ports 53, 443, or 16000, enabling remote command execution and potentially SOCKS like proxying.
• Command execution: Supports a variety of commands from the C2 server, including system reboots, log clearing, registry manipulation, application execution, and system suspension.
• Persistence mechanisms: Achieves persistence through the Windows service control manager (SCM) and uses watchdog threads to ensure self-reinstatement if removed.
• RDP monitoring: Monitors RDP sessions, capturing active window information and impersonating users, allowing for potential lateral movement within networks.
• Clipboard and data collection: Continuously monitors clipboard content, actively searching for sensitive data like passwords and cryptocurrency keys, while tracking active windows and applications.
• Anti-forensics and evasion: Employs anti-forensic tactics by clearing event logs, detecting analysis tools, and implementing sandbox-evading behaviors to avoid detection.

Technical analysis of key capabilities

System reconnaissance

StilachiRAT gathers extensive system information, including OS details, device identifiers, BIOS serial numbers, and camera presence. Information is collected through the Component Object Model (COM) Web-based Enterprise Management (WBEM) interfaces using WMI Query Language (WQL). Below are some of the queries it executes:

Serial number

Camera

OS / System info (server, model, manufacturer)

Additionally, the malware creates a unique identification on the infected device that is derived from the system’s serial number and attackers’ public RSA key. The information is stored in the registry under a CLSID key.

Digital wallet targeting

StilachiRAT targets a list of specific cryptocurrency wallet extensions for the Google Chrome browser. It accesses the settings in the following registry key and validates if any of the extensions are installed:

\SOFTWARE\Google\Chrome\PreferenceMACs\Default\extensions.settings

The malware targets the following cryptocurrency wallet extensions:

Credential theft

StilachiRAT extracts Google Chrome’s encryption_key from the local state file in a user’s directory. However, since the key is encrypted when Chrome is first installed, it uses Windows APIs that rely on current user’s context to decrypt the master key. This allows access to the stored credentials in the password vault. The stored credentials are extracted from the following locations:

• %LOCALAPPDATA%\Google\Chrome\User Data\Local State – stores Chrome’s configuration data, including the encrypted key.
• %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data – stores entered user credentials.

The “Login Data” stores information using an SQLite database and the malware retrieves credentials using the following query:

Command-and-control (C2)

There are two configured addresses for the C2 server – one is stored in obfuscated form and the other is an IP address converted to its binary format (instead of a regular string):

• app.95560[.]cc
• 194.195.89[.]47

The communications channel is established using TCP ports 53, 443, or 16000, selected randomly. Additionally, the malware checks for presence of tcpview.exe and will not proceed if one is present. It also delays initial connection by two hours, presumably to evade detection. Once connected, a list of active windows is sent to the server. Additional technical findings regarding C2 communications functionality are listed in the section below.

Persistence mechanisms

StilachiRAT can be launched both as a Windows service or a standalone component. In both cases, there is a mechanism in place to ensure the malware isn’t removed.

A watchdog thread monitors both the EXE and dynamic link library (DLL) files used by the malware by periodically polling for their presence. If found absent, the files can be recreated from an internal copy obtained during initialization. Lastly, the Windows service component can be recreated by modifying the relevant registry settings and restarting it through the SCM.

RDP monitoring

StilachiRAT monitors RDP sessions by capturing foreground window information and duplicating security tokens to impersonate users. This is particularly risky on RDP servers hosting administrative sessions as it could enable lateral movement within networks.

The malware obtains the current session and actively launches foreground windows as well as enumerates all other RDP sessions. For each identified session, it will access the Windows Explorer shell and duplicate its privileges or security token. The malware then gains capabilities to launch applications with these newly obtained privileges.

Data collection

StilachiRAT collects a variety of user data, including software installation records and active applications. It monitors active GUI windows, their title bar text, and file location, and sends this information to the C2 server, potentially allowing attackers to track user behavior.

Clipboard monitoring

StilachiRAT has a functionality that is responsible for monitoring clipboard data. Specifically, the malware can periodically read the clipboard, extract text based on search expressions, and then exfiltrate this data. Clipboard monitoring is continuous, with targeted searches for sensitive information such as passwords, cryptocurrency keys, and potentially personal identifiers.

The list below includes the regular search expressions used to extract certain credentials. These are associated with the Tron Cryptocurrency blockchain that is popular in Asia, especially in China.

The same search expressions are then used to iterate files in the following locations:

• %USERPROFILE%\Desktop
• %USERPROFILE%\Recent

Anti-forensic measures

StilachiRAT displays anti-forensic behavior by clearing event logs and checking certain system conditions to evade detection. This includes looping checks for analysis tools and sandbox timers that prevent its full activation in virtual environments commonly used for malware analysis.

Additionally, Windows API calls are obfuscated in multiple ways and a custom algorithm is used to encode many text strings and values. This significantly slows down analysis time since extrapolating higher level logic and code design becomes a more complex effort.

The malware employs API-level obfuscation techniques to impede manual analysis, specifically by concealing its use of Windows APIs (e.g., RegOpenKey()). Instead of referencing API names directly, it encodes them as checksums that are resolved dynamically at runtime. While this is a common technique in malware, the authors have introduced additional layers of obfuscation.

Precomputed API checksums are stored in multiple lookup tables, each masked with an XOR value. During launch, the malware selects the appropriate table based on the hashed API name, applies the correct XOR mask to decode the value, and dynamically resolves the corresponding Windows API function. The resolved function pointer is then cached, but with an additional XOR mask applied, preventing straightforward memory scans from identifying API references.

Commands launched from the C2 server

StilachiRAT can launch various commands received from the C2 server. These commands include system reboot, log clearing, credential theft, executing applications, and manipulating system windows. Additionally, it can suspend the system, modify Windows registry values, and enumerate open windows, indicating a versatile command set for both espionage and system manipulation. The C2 server’s command structure assigns specific numbers to what commands it will initiate. The following section presents details on the said commands.

07 – Dialog box

Uses the Windows API function ShowHTMLDialogEx() to display a dialog box with rendered HTML contents from a supplied URL.

08 – Log clearing

Given an event log type, the relevant Windows APIs are used to open and then clear the log entries.

09 – System reboot

Adjusts its own executing privileges to enable system shutdown and uses an undocumented Windows API to perform the action.

13 – Network sockets

Appears to contain capability to receive a network address from C2 server and establish a new outbound connection.

14 – TCP incoming

Accepts an incoming network connection on the supplied TCP port.

15 – Terminate

If there’s an open network connection, then close it and disable the Windows service controlling this process. This appears to be the self-removal (uninstall) command.

16 – Initiate application

The malware creates a console window and initiates a command to launch the program provided by the C2 operator using the WinExec() API.

19 – Enumerate Windows

Iterates all windows of the current desktop to look for a requested title bar text. This might allow the operator to access specific GUI applications and their contents, both onscreen and clipboard.

26 – Suspend

Uses the SetSuspendState() API to put the system into either a suspended (sleep) state or hibernation.

30 – Chrome credentials

Launches the earlier mentioned functionality to steal Google Chrome passwords.

Mitigations

Malware like StilachiRAT can be installed through various vectors. The following mitigations can help prevent this type of malware from infiltrating the system and reduce the attack surface:

• In some cases, RATs can masquerade as legitimate software or software updates. Always download software from the official website of the software developer or from reputable sources.
• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on Safe Links and Safe Attachments for Office 365. In organizations with Microsoft Defender for Office 365, Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Specifically, Safe Links provides URL scanning and rewriting of inbound email messages during mail flow, and time-of-click verification of URLs and links in email messages, Microsoft Teams, and supported Office 365 apps. Safe Attachments provides an additional layer of protection for email attachments that have already been scanned by anti-malware protection in Exchange Online Protection (EOP).
• Enable network protection in Microsoft Defender for Endpoint to prevent applications or users from accessing malicious domains and other malicious content on the internet. You can audit network protection in a test environment to view which apps would be blocked before enabling network protection.

General hardening guidelines:

• Ensure that tamper protection is enabled in Microsoft Dender for Endpoint.
• Run endpoint detection and response in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on Potentially unwanted applications (PUA) protection in block mode in Microsoft Defender Antivirus. PUA are a category of software that can cause your machine to run slowly, display unexpected ads, or install other software that might be unexpected or unapproved.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• TrojanSpy:Win64/Stilachi.A

Microsoft Defender for Endpoint

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• A process was injected with potentially malicious code
• Process hollowing detected
• Suspicious service launched
• Possible theft of passwords and other sensitive web browser information

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Look for suspicious outbound network connections

Monitor network traffic for malicious activity caused by remote access trojans by focusing on identifying unusual outbound connections, irregular port activity, and suspicious data exfiltration patterns that may indicate RAT presence.

Outbound ports associated with common data transfer protocols such as HTTP/HTTPS (port 80/443), SMB (port 445), and DNS (port 53) or less common ports like 16000 used for specific applications and services for network communications might indicate such activity.

let domains = dynamic(['domain1', 'domain2', 'domain3']);
DeviceNetworkEvents
| where RemotePort in (53, 443, 16000)
| where Protocol == "Tcp"
| where RemoteUrl has_any (domains)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessCommandLine, ActionType, DeviceId, LocalIP, RemoteUrl, InitiatingProcessFileName

Look for signs of persistence

The malware can be run both as a Windows Service or a standalone component. To identify persistence and suspicious services, monitor for the following event IDs:

• Event ID 7045 – a new service was installed on the system. Monitor for suspicious services.
• Event ID 7040 – start type of a service is changed (boot, on-request). Boot may be a vector for the RAT to persist during a system reboot. On request indicates that the process must request the SCM to start the service.
• Correlated with Event ID 4697 – a service was installed on the system (Security log)

DeviceEvents
|where ActionType == “ServiceInstalled”
| project Timestamp, DeviceId,ActionType, FileName, FolderPath, InitiatingProcessCommandLine

Look for anti-forensic behavior

To identify potential event log clearing, monitor for the following event IDs:

• Event ID 1102 (Security log)
• Event ID 104 (System log)

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain/IP/Hash indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Additionally, Sentinel users can use the following query to detect when the security event log has been cleared, a potential indicator of an attempt to erase system evidence.

SecurityEvent
  | where EventID == 1102 and EventSourceName == "Microsoft-Windows-Eventlog"
  | summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated), EventCount = count() by Computer, Account, EventID, Activity
  | extend HostName = tostring(split(Computer, ".")[0]), DomainIndex = toint(indexof(Computer, '.'))
  | extend HostNameDomain = iff(DomainIndex != -1, substring(Computer, DomainIndex + 1), Computer)
  | extend AccountName = tostring(split(Account, @'\')[1]), AccountNTDomain = tostring(split(Account, @'\')[0])

Sentinel users can also use the following query to detect service installations or modifications in service settings, which may indicate potential persistence mechanisms used by attackers.

Event 
  // 7045: A service was installed in the system
 //  7040: A service setting has been changed
  | where Source == "Service Control Manager" 
  | where EventID in ( '7045', '7040')
  | parse EventData with * 'ServiceName">' ServiceName "<" * 'ImagePath">' ImagePath "<" *
  | parse EventData with * 'AccountName">' AccountName "<" *
  | summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated) by EventID, Computer, ServiceName, ImagePath, AccountName

Indicators of compromise

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

Microsoft is committed to delivering comprehensive customer experience through various Microsoft Offerings. Our approach goes beyond traditional support by focusing on detection, prevention, and in-depth mitigation to help customers quickly respond to security incidents and build resiliency. Want to know how to Build a More Secure Tomorrow? Check our Unified and Security eBook and visit https://aka.ms/Unified

Dmitriy Pletnev and Daria Pop
Microsoft Incident Response

The post StilachiRAT analysis: From system reconnaissance to cryptocurrency theft appeared first on Microsoft Security Blog.

That statistic alone tells us a great deal about the importance of preparedness for a potential cyberattack, which includes a robust incident response plan. To create such a plan, it is critical to understand potential risks, and one of the best ways to do that is to conduct a proactive threat hunt and compromise assessment.

Microsoft Incident Response is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. In addition to reactive response, they also conduct proactive compromise assessments to find threat actor activity. They’ll provide recommendations and best practice guidance to strengthen an organization’s security posture.

Microsoft Incident Response

Your first call before, during, and after a cybersecurity incident.

Microsoft Incident Response compromise assessments utilizes the same methodology and resources as those used in an investigation but without the time pressure and crisis-driven decision making associated with a live cyberattack. Compromise assessments are often used by those who have had a prior incident and want to measure their security posture after the implementation of new security measures. Some customers use the service as an annual assessment prior to locking down change controls. Others may use it to assess the environment of an acquisition prior to joining infrastructures.

What happens when a compromise assessment turns into a reactive incident response engagement? Let’s dive into a recent situation where our team encountered this very scenario.

Why differentiate between proactive and reactive investigations?

It is important to understand the key differences between proactive and reactive investigations, as each has different goals and measures for success. Microsoft Incident Response’s proactive compromise assessments are focused on detection and prevention, which includes identifying potential indicators of compromise (IOCs), bringing attention to potential vulnerabilities, and helping customers mitigate risks by implementing security hardening measures.

Our reactive investigations are centered on incident management during and immediately after a compromise, including incident analysis, threat hunting, tactical containment, and Tier 0 recovery, all while under the pressure of an active cyberattack.

Proactive and reactive incident response are essential capabilities for providing a more robust defense strategy. They enable an organization to address an active cyberattack during a period when time and knowing the next steps are critical. At the same time, it provides experts with the experience needed to help prevent future incidents. Not all organizations have the resources required to maintain an incident response team capable of proactive and reactive approaches and may want to consider using a third-party service.

The importance of Microsoft’s “double duty” incident response experts

When confronted by an active threat actor, two things are at the forefront of success and can’t be lost—time and knowledge.

While conducting a proactive compromise assessment for a nonprofit organization in mid-2024, Microsoft Incident Response began their forensic investigation. Initially identifying small artifacts of interest, the assessment quickly changed as suspicious events began to unfold. At the time the threat actor was not known, but has since been tracked as Storm-2077, a Chinese state actor that has been active since at least January 2024. Storm-2077’s techniques focus on email data theft, using valid credentials harvested from compromised systems. Storm-2077 was lurking in the shadows of the organization’s environment. When they felt they had been detected, these threat actors put their fingers on keyboards and started making moves.

Precious time to remediate was not lost. Microsoft Incident Response immediately switched from proactive to reactive mode. The threat actor created a global administrator account and began disabling legitimate organizational global administrator accounts to gain full control of the environment. The targeted organization’s IT team was already synchronized with Microsoft Incident Response through the active compromise assessment that was taking place. The targeted customer took note of the event and came to Microsoft for deconfliction. Once the activity was determined to be malicious, the organization’s IT team disabled the access, and the proactive incident response investigation converted to being reactive. The threat actor was contained and access was remediated quickly because of this collaboration.

The threat actor had likely been present in the organization’s environment for a few months or more. They had taken advantage of a stolen session token to conduct a token replay attack, and through this had gained access to multiple accounts.

Proactive assessments that don’t utilize reactive investigation teams for delivery may result in a delay in responding or even generate more challenges for the incoming investigation team.

Thankfully, Microsoft Incident Response conducts proactive compromise assessments with the same resources that deliver reactive investigations. They can take immediate action to halt active cyberthreats before they do more harm.

Read the report to go deeper into the details of the cyberattack, including Storm-2077 tactics, the response activity, and lessons that other organizations can learn from this case.

What is the Cyberattack Series?

With our Cyberattack Series, customers will discover how Microsoft Incident Response investigates unique and notable attacks. For each cyberattack story, we will share:

• How the cyberattack happened.
• How the breach was discovered.
• Microsoft’s investigation and eviction of the threat actor.
• Strategies to avoid similar cyberattacks.

Learn more

To learn more about Microsoft Incident Response capabilities, please visit our website, or reach out to your Microsoft account manager or Premier Support contact.

Download our Unified Security e-book to learn more about how Microsoft can help you be more secure.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Cybercrime Expected To Skyrocket in Coming Years, Statista. February 22, 2024.

²World GDP Rankings 2024 | Top 10 Countries Ranked By GDP, Forbes India. November 4, 2024.

The post Build a stronger security strategy with proactive and reactive incident response: Cyberattack Series appeared first on Microsoft Security Blog.

Microsoft Incident Response

Strengthen your security with an end-to-end portfolio of proactive and reactive cybersecurity incident response services.

Learn more

Threat intelligence is often oversimplified to represent a feed of indicators of compromise (IOCs). The intersection between multiple types of threat intelligence, however, enables organizations and their threat hunters to have a holistic understanding of the cyberattackers and techniques that can and will target them. With this comprehensive cheat sheet of knowledge, threat hunters can not only increase efficiency when responding to a compromise, but proactively hunt their systems for anomalies and fine-tune protection and detection mechanisms. 

Figure 1. Three types of threat intelligence.

Figure 1 introduces three types of threat intelligence that will be outlined in this blog—strategic, operational, and tactical. It provides a visualization of organizational effort versus the value gained when utilizing threat intelligence in more than one way. Typically, security teams integrate IOC cyberthreat feeds at a tactical level, but incorporating threat intelligence operationally requires daily investment, especially when alert queues seem endless. Strategic threat intelligence may seem familiar to most organizations but can be challenging to apply effectively, as this requires concentrated effort at multiple levels to understand the organization’s position within the overall threat landscape. How can threat hunters leverage these types of threat intelligence effectively for the benefit of their organization? 

Strategic threat intelligence: Informed hunting driven by the overarching cyberthreat landscape 

Security teams should be industry aware—being cognizant of the types of digital threats and current trends affecting industry verticals allows any team to be better prepared for potential compromise. Strategic threat intelligence is fundamentally based on understanding threat actor motives, which gives organizations an understanding of which threat actors they should be most conscious of in relation to the industry vertical or their most valuable resources. For example, government entities are traditionally targeted by nation-state advanced persistent threats (APTs) to perform cyber espionage, whereas organizations in the healthcare industry are commonly targeted by cybercriminal actor groups for ransomware operations and financial extortion due to the sensitivity of the data they possess. Understanding where the organization fits into this strategic picture determines the investment where its resources (people and time) may be constrained. Furthermore, it’s a key step toward developing an effective threat-informed defense strategy prioritizing the cyberattacks that target the organization.  

Operational threat intelligence: Informed hunting to proactively understand the environment and its data 

Having broad visibility into an organization’s attack surface is imperative when applying threat intelligence at an operational level. The crucial components spanning the perimeter of the on-premises network and extended entities such as cloud, software-as-a-service, and overall supply chain should be well understood: 

• Where are the tier 0 systems in the organization? 
• What intermediary lateral movement pathways exist to tier 0 systems? 
• What security controls across the environment are (or aren’t) in place? 
• What telemetry is produced by all systems in the environment?  

Security teams should proactively analyze the data that comes from these entities to develop a baseline of normal operations. Along with this baseline, threat hunters should comprehend and exercise organizational processes. In the event of an identified anomaly, how is that behavior deconflicted? What teams within the organization need to be consulted? What is the process for ensuring false positives can be reported and circulated efficiently and effectively? Considering the secondary questions and tertiary actions of response steps greatly benefits threat hunting timeliness, staving off confusion during a rapidly evolving incident.

Tactical threat intelligence: Informed hunting to reactively respond to a live cyberthreat 

Tactical threat intelligence is often an organization’s main integration to enhance a threat hunt, particularly in response to an active cyberattack scenario. Known-bad entities and atomic indicators such as IP addresses, domains, and file hashes are used to identify anomalies aligning to attacker techniques against targeted systems quickly. Additionally, if the cyberattack is already attributed to a threat actor, or the attack aligns to a particular motive, security teams can use these patterns of behavior to prioritize their hunting scope to their known tactics, techniques, and procedures. Novel indicators or associated research from the analysis should be shared with other vetted threat hunters within the organization and are a particularly valuable contribution to the wider threat intelligence community to further enrich detections for all organizations.  

Putting it together: Threat intelligence and iterative threat hunting 

Armed with this breakdown, threat hunters can now turn their attention to using varied threat intelligence to execute threat hunts and track down threat actors. The threat hunting iterative workflow shown in Figure 2 is something security teams will likely be familiar with; but are threat intelligence artifacts effectively being applied to create a holistic threat-informed defense strategy? 

Figure 2. Feeding threat intelligence artifacts into an iterative threat hunting workflow.

When preparing a hunt, threat hunters should seek to apply strategic threat intelligence to prioritize the cyberthreats that target the organization. This directly leads into the hypothesis phase. Threat hunters include the gathered strategic artifacts in a hunt hypothesis based on the trends or threat actors impacting other organizations in the same vertical. This casts a wide net to identify anomalies and behaviors common to the industry. They are not limiting the hunt based on any one IOC, rather using the collective intelligence learned from similar intrusions to detect or prevent the attack scenario. For every investigation, whether it be proactive or reactive, Microsoft Incident Response threat hunters consider other incidents impacting victim organizations in the same industry as a guiding force to efficiently identify focus areas of analysis, leveraging research from Microsoft Threat Intelligence that outlines any applicable threat actor attribution. 

Daily workflows should be enhanced with operational threat intelligence artifacts to determine an environmental baseline. Proactive hunt hypotheses should seek to test the understanding and actively seek to identify gaps in various aspects of the baseline, identifying any behavioral anomalies straying from “normal operations” and developing high-fidelity, real-world detections based on the true attempts at intrusion to their environments. Existing detections should be continuously reviewed and refined, hunting threads should include interrogation of both successful and failed access attempts, and data integrity should be verified. Security teams should question if: 

• Centralized data is both complete and accurate—identifying if there are any gaps in the data and why. 
• The schema is consistent between all data sources (for example, timestamp accuracy). 
• The correct fields are flowing through from their distributed systems’ sources.  

When security teams embody being the experts of their environment, they become more adept at identifying when a proactive threat hunt shifts into reactive response to active threat. This is invaluable when improving the speed of returning to normal operations and engaging additional support such as Microsoft Incident Response, who can enhance the hunt with threat intelligence from previous global incidents, working with the customer to deconflict abnormalities quickly for swift takeback and eviction of threat actors. 

When incident response teams like Microsoft Incident Response are engaged during a reactive incident, the objective of threat hunting is to conduct analysis of live, historical, and contextual data on targeted and compromised systems and provide a detailed story of not only the attack chain, but the threat actor(s) conducting that attack. Enriching a threat hunt with tactical threat intelligence artifacts in the form of IOCs concentrates investigation scope and allows for rapid identification of threat actor activity. As the hunt progresses, relational entities to that indicator are uncovered, such as the identities involved in activity execution and lateral movement paths to different systems. Attention shifts from atomic indicators such as IP addresses and malicious domains, to artifacts left directly on compromised systems, such as commands that were run or persistent backdoors that were installed. This builds an end-to-end timeline of malicious activity and related indicators for organizations to stay informed, implement target security controls, and prevent the same, or similar, incidents in the future.  

Adhering to the collaborative cycle of threat intelligence, Microsoft Incident Response contributes front-line research to enhance and further develop detections for customers worldwide. Entities are aligned with industry frameworks such as the Diamond Model, to build threat actor profiles detailing the relationship between adversaries’ infrastructure, capabilities and victims. Microsoft Threat Intelligence is available in Microsoft Defender XDR for the community and fellow security teams to consume, validate, and refine into proactive detections for the organization. 

How Microsoft Incident Response can support proactive threat protection

Microsoft Incident Response has cultivated and relies upon implementing the cycle between incident response and threat intelligence to protect our customers, leveraging insights from 78 trillion signals per day. Organizations can proactively position themselves to be well-informed by the threats targeting their organization by implementing threat intelligence in a holistic way, before an incident begins.  

Embracing a collaborative culture amongst the threat intelligence community to not only consume entities, but to further contribute, refine, and enhance existing research, results in improved detections, controls, and automation, allowing all security professionals to get behind the same goal—track down and protect themselves from threat actors and their malicious intent.  

You can read more blogs from Microsoft Incident Response. For more security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

Learn more

Learn more about Microsoft Incident Response.

To get notified about new Microsoft Threat Intelligence publications and to join discussions on social media, follow us on X (@MsftSecIntel).

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹The art and science behind Microsoft threat hunting: Part 1, Microsoft Incident Response Team. September 9, 2022.

²The art and science behind Microsoft threat hunting: Part 2, Microsoft Incident Response Team. September 21, 2022.

The post The art and science behind Microsoft threat hunting: Part 3 appeared first on Microsoft Security Blog.

To meet those needs:

1. Windows provides a range of operating modes that customers can choose from. This includes the ability to limit what can run to only approved software and drivers. This can increase security and reliability by making Windows operate in a mode closer to mobile phones or appliances.
2. Customers can choose integrated security monitoring and detection capabilities that are included with Windows. Or they can choose to replace or supplement this security with a wide variety of choices from a vibrant open ecosystem of vendors.

In this blog post, we examine the recent CrowdStrike outage and provide a technical overview of the root cause. We also explain why security products use kernel-mode drivers today and the safety measures Windows provides for third-party solutions. In addition, we share how customers and security vendors can better leverage the integrated security capabilities of Windows for increased security and reliability. Lastly, we provide a look into how Windows will enhance extensibility for future security products.

CrowdStrike recently published a Preliminary Post Incident Review analyzing their outage. In their blog post, CrowdStrike describes the root cause as a memory safety issue—specifically a read out-of-bounds access violation in the CSagent driver. We leverage the Microsoft WinDBG Kernel Debugger and several extensions that are available free to anyone to perform this analysis. Customers with crash dumps can reproduce our steps with these tools.

Based on Microsoft’s analysis of the Windows Error Reporting (WER) kernel crash dumps related to the incident, we observe global crash patterns that reflect this:

FAULTING_THREAD:  ffffe402fe868040

READ_ADDRESS:  ffff840500000074 Paged pool

MM_INTERNAL_CODE:  2

IMAGE_NAME:  csagent.sys

MODULE_NAME: csagent

FAULTING_MODULE: fffff80671430000 csagent

PROCESS_NAME:  System

TRAP_FRAME:  ffff94058305ec20 -- (.trap 0xffff94058305ec20)
.trap 0xffff94058305ec20
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffff94058305f200 rbx=0000000000000000 rcx=0000000000000003
rdx=ffff94058305f1d0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff806715114ed rsp=ffff94058305edb0 rbp=ffff94058305eeb0
 r8=ffff840500000074  r9=0000000000000000 r10=0000000000000000
r11=0000000000000014 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
csagent+0xe14ed:
fffff806`715114ed 458b08          mov     r9d,dword ptr [r8] ds:ffff8405`00000074=????????
.trap
Resetting default scope

STACK_TEXT:  
ffff9405`8305e9f8 fffff806`5388c1e4     : 00000000`00000050 ffff8405`00000074 00000000`00000000 ffff9405`8305ec20 : nt!KeBugCheckEx 
ffff9405`8305ea00 fffff806`53662d8c     : 00000000`00000000 00000000`00000000 00000000`00000000 ffff8405`00000074 : nt!MiSystemFault+0x1fcf94  
ffff9405`8305eb00 fffff806`53827529     : ffffffff`00000030 ffff8405`af8351a2 ffff9405`8305f020 ffff9405`8305f020 : nt!MmAccessFault+0x29c 
ffff9405`8305ec20 fffff806`715114ed     : 00000000`00000000 ffff9405`8305eeb0 ffff8405`b0bcd00c ffff8405`b0bc505c : nt!KiPageFault+0x369 
ffff9405`8305edb0 fffff806`714e709e     : 00000000`00000000 00000000`e01f008d ffff9405`8305f102 fffff806`716baaf8 : csagent+0xe14ed
ffff9405`8305ef50 fffff806`714e8335     : 00000000`00000000 00000000`00000010 00000000`00000002 ffff8405`b0bc501c : csagent+0xb709e
ffff9405`8305f080 fffff806`717220c7     : 00000000`00000000 00000000`00000000 ffff9405`8305f382 00000000`00000000 : csagent+0xb8335
ffff9405`8305f1b0 fffff806`7171ec44     : ffff9405`8305f668 fffff806`53eac2b0 ffff8405`afad4ac0 00000000`00000003 : csagent+0x2f20c7
ffff9405`8305f430 fffff806`71497a31     : 00000000`0000303b ffff9405`8305f6f0 ffff8405`afb1d140 ffffe402`ff251098 : csagent+0x2eec44
ffff9405`8305f5f0 fffff806`71496aee     : ffff8405`afb1d140 fffff806`71541e7e 00000000`000067a0 fffff806`7168f8f0 : csagent+0x67a31
ffff9405`8305f760 fffff806`7149685b     : ffff9405`8305f9d8 ffff8405`afb1d230 ffff8405`afb1d140 ffffe402`fe8644f8 : csagent+0x66aee
ffff9405`8305f7d0 fffff806`715399ea     : 00000000`4a8415aa ffff8eee`1c68ca4f 00000000`00000000 ffff8405`9e95fc30 : csagent+0x6685b
ffff9405`8305f850 fffff806`7148efbb     : 00000000`00000000 ffff9405`8305fa59 ffffe402`fe864050 ffffe402`fede62c0 : csagent+0x1099ea
ffff9405`8305f980 fffff806`7148edd7     : ffffffff`ffffffa1 fffff806`7152e5c1 ffffe402`fe864050 00000000`00000001 : csagent+0x5efbb
ffff9405`8305fac0 fffff806`7152e681     : 00000000`00000000 fffff806`53789272 00000000`00000002 ffffe402`fede62c0 : csagent+0x5edd7
ffff9405`8305faf0 fffff806`53707287     : ffffe402`fe868040 00000000`00000080 fffff806`7152e510 006fe47f`b19bbdff : csagent+0xfe681
ffff9405`8305fb30 fffff806`5381b8e4     : ffff9680`37651180 ffffe402`fe868040 fffff806`53707230 00000000`00000000 : nt!PspSystemThreadStartup+0x57 
ffff9405`8305fb80 00000000`00000000     : ffff9405`83060000 ffff9405`83059000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34 

Digging in more to this crash dump, we can restore the stack frame at the time of the access violation to learn more about its origin. Unfortunately, with WER data we only receive a compressed version of state and thus we cannot disassemble backwards to see a larger set of instructions prior to the crash, but we can see in the disassembly that there is a check for NULL before performing a read at the address specified in the R8 register:

6: kd> .trap 0xffff94058305ec20
.trap 0xffff94058305ec20
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffff94058305f200 rbx=0000000000000000 rcx=0000000000000003
rdx=ffff94058305f1d0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff806715114ed rsp=ffff94058305edb0 rbp=ffff94058305eeb0
 r8=ffff840500000074  r9=0000000000000000 r10=0000000000000000
r11=0000000000000014 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=000000000000
000
iopl=0         nv up ei ng nz na po nc
csagent+0xe14ed:
fffff806`715114ed 458b08          mov     r9d,dword ptr [r8] ds:ffff8405`00000074=????????
6: kd> !pte ffff840500000074
!pte ffff840500000074
                                           VA ffff840500000074
PXE at FFFFABD5EAF57840    PPE at FFFFABD5EAF080A0    PDE at FFFFABD5E1014000    PTE at FFFFABC202800000
contains 0A00000277200863  contains 0000000000000000
pfn 277200    ---DA--KWEV  contains 0000000000000000
not valid

6: kd> ub fffff806`715114ed
ub fffff806`715114ed
csagent+0xe14d9:
fffff806`715114d9 04d8            add     al,0D8h
fffff806`715114db 750b            jne     csagent+0xe14e8 (fffff806`715114e8)
fffff806`715114dd 4d85c0          test    r8,r8
fffff806`715114e0 7412            je      csagent+0xe14f4 (fffff806`715114f4)
fffff806`715114e2 450fb708        movzx   r9d,word ptr [r8]
fffff806`715114e6 eb08            jmp     csagent+0xe14f0 (fffff806`715114f0)
fffff806`715114e8 4d85c0          test    r8,r8
fffff806`715114eb 7407            je      csagent+0xe14f4 (fffff806`715114f4)
6: kd> ub fffff806`715114d9
ub fffff806`715114d9
                          ^ Unable to find valid previous instruction for 'ub fffff806`715114d9'
6: kd> u fffff806`715114eb
u fffff806`715114eb
csagent+0xe14eb:
fffff806`715114eb 7407            je      csagent+0xe14f4 (fffff806`715114f4)
fffff806`715114ed 458b08          mov     r9d,dword ptr [r8]
fffff806`715114f0 4d8b5008        mov     r10,qword ptr [r8+8]
fffff806`715114f4 4d8bc2          mov     r8,r10
fffff806`715114f7 488d4d90        lea     rcx,[rbp-70h]
fffff806`715114fb 488bd6          mov     rdx,rsi
fffff806`715114fe e8212c0000      call    csagent+0xe4124 (fffff806`71514124)
fffff806`71511503 4533d2          xor     r10d,r10d

6: kd> db ffff840500000074
db ffff840500000074
ffff8405`00000074  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`00000084  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`00000094  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`000000a4  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`000000b4  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`000000c4  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`000000d4  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
ffff8405`000000e4  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

Our observations confirm CrowdStrike’s analysis that this was a read-out-of-bounds memory safety error in the CrowdStrike developed CSagent.sys driver.

We can also see that the csagent.sys module is registered as a file system filter driver commonly used by anti-malware agents to receive notifications about file operations such as the creation or modification of a file. This is often used by security products to scan any new file saved to disk, such as downloading a file via the browser.

File System filters can also be used as a signal for security solutions attempting to monitor the behavior of the system. CrowdStrike noted in their blog that part of their content update was changing the sensor’s logic relating to data around named pipe creation. The File System filter driver API allows the driver to receive a call when named pipe activity (e.g., named pipe creation) occurs on the system that could enable the detection of malicious behavior. The general function of the driver correlates to the information shared by CrowdStrike.

6: kd>!reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csagent

Hive         ffff84059ca7b000
KeyNode      ffff8405a6f67f9c

[SubKeyAddr]         [SubKeyName]
ffff8405a6f683ac     Instances
ffff8405a6f6854c     Sim

 Use '!reg keyinfo ffff84059ca7b000 <SubKeyAddr>' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          2
REG_DWORD           Start                         1
REG_DWORD           ErrorControl                  1
REG_EXPAND_SZ       ImagePath                     \??\C:\Windows\system32\drivers\CrowdStrike\csagent.sys
REG_SZ              DisplayName                   CrowdStrike Falcon
REG_SZ              Group                         FSFilter Activity Monitor
REG_MULTI_SZ        DependOnService               FltMgr\0
REG_SZ              CNFG                          Config.sys
REG_DWORD           SupportedFeatures             f

We can see the control channel file version 291 specified in the CrowdStrike analysis is also present in the crash indicating the file was read.

Determining how the file itself correlates to the access violation observed in the crash dump would require additional debugging of the driver using these tools but is outside of the scope of this blog post.

!ca ffffde8a870a8290

ControlArea  @ ffffde8a870a8290
  Segment      ffff880ce0689c10  Flink      ffffde8a87267718  Blink        ffffde8a870a7d98
  Section Ref                 0  Pfn Ref                   b  Mapped Views                0
  User Ref                    0  WaitForDel                0  Flush Count                 0
  File Object  ffffde8a879b29a0  ModWriteCount             0  System Views                0
  WritableRefs                0  PartitionId                0  
  Flags (8008080) File WasPurged OnUnusedList 

      \Windows\System32\drivers\CrowdStrike\C-00000291-00000000-00000032.sys

1: kd> !ntfskd.ccb ffff880ce06f6970
!ntfskd.ccb ffff880ce06f6970

   Ccb: ffff880c`e06f6970
 Flags: 00008003 Cleanup OpenAsFile IgnoreCase
Flags2: 00000841 OpenComplete AccessAffectsOplocks SegmentObjectReferenced
  Type: UserFileOpen
FileObj: ffffde8a879b29a0

(018)  ffff880c`db937370  FullFileName [\Windows\System32\drivers\CrowdStrike\C-00000291-00000000-00000032.sys]
(020) 000000000000004C  LastFileNameOffset 
(022) 0000000000000000  EaModificationCount 
(024) 0000000000000000  NextEaOffset 
(048) FFFF880CE06F69F8  Lcb 
(058) 0000000000000002  TypeOfOpen 

We can leverage the crash dump to determine if any other drivers supplied by CrowdStrike may exist on the running system during the crash.

6: kd> lmDvmCSFirmwareAnalysis
lmDvmCSFirmwareAnalysis
Browse full module list
start             end                 module name
fffff806`58920000 fffff806`5893c000   CSFirmwareAnalysis   (deferred)             
    Image path: \SystemRoot\system32\DRIVERS\CSFirmwareAnalysis.sys
    Image name: CSFirmwareAnalysis.sys
    Browse all global symbols  functions  data  Symbol Reload
    Timestamp:        Mon Mar 18 11:32:14 2024 (65F888AE)
    CheckSum:         0002020E
    ImageSize:        0001C000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
6: kd> lmDvmcspcm4
lmDvmcspcm4
Browse full module list
start             end                 module name
fffff806`71870000 fffff806`7187d000   cspcm4     (deferred)             
    Image path: \??\C:\Windows\system32\drivers\CrowdStrike\cspcm4.sys
    Image name: cspcm4.sys
    Browse all global symbols  functions  data  Symbol Reload
    Timestamp:        Mon Jul  8 18:33:22 2024 (668C9362)
    CheckSum:         00012F69
    ImageSize:        0000D000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
6: kd> lmDvmcsboot.sys
lmDvmcsboot.sys
Browse full module list
start             end                 module name

Unloaded modules:
fffff806`587d0000 fffff806`587dc000   CSBoot.sys
    Timestamp: unavailable (00000000)
    Checksum:  00000000
    ImageSize:  0000C000

6: kd> !reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csboot
!reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csboot

Hive         ffff84059ca7b000
KeyNode      ffff8405a6f68924

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          1
REG_DWORD           Start                         0
REG_DWORD           ErrorControl                  1
REG_EXPAND_SZ       ImagePath                     system32\drivers\CrowdStrike\CSBoot.sys
REG_SZ              DisplayName                   CrowdStrike Falcon Sensor Boot Driver
REG_SZ              Group                         Early-Launch
6: kd> !reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csdevicecontrol
!reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csdevicecontrol

Hive         ffff84059ca7b000
KeyNode      ffff8405a6f694ac

[SubKeyAddr]         [VolatileSubKeyName]
ffff84059ce196c4     Enum

 Use '!reg keyinfo ffff84059ca7b000 <SubKeyAddr>' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          1
REG_DWORD           Start                         3
REG_DWORD           ErrorControl                  1
REG_DWORD           Tag                           1f
REG_EXPAND_SZ       ImagePath                     \SystemRoot\System32\drivers\CSDeviceControl.sys
REG_SZ              DisplayName                   @oem40.inf,%DeviceControl.SVCDESC%;CrowdStrike Device Control Service
REG_SZ              Group                         Base
REG_MULTI_SZ        Owners                        oem40.inf\0!csdevicecontrol.inf_amd64_b6725a84d4688d5a\0!csdevicecontrol.inf_amd64_016e965488e83578\0
REG_DWORD           BootFlags                     14
6: kd> !reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csagent
!reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csagent

Hive         ffff84059ca7b000
KeyNode      ffff8405a6f67f9c

[SubKeyAddr]         [SubKeyName]
ffff8405a6f683ac     Instances
ffff8405a6f6854c     Sim

 Use '!reg keyinfo ffff84059ca7b000 <SubKeyAddr>' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          2
REG_DWORD           Start                         1
REG_DWORD           ErrorControl                  1
REG_EXPAND_SZ       ImagePath                     \??\C:\Windows\system32\drivers\CrowdStrike\csagent.sys
REG_SZ              DisplayName                   CrowdStrike Falcon
REG_SZ              Group                         FSFilter Activity Monitor
REG_MULTI_SZ        DependOnService               FltMgr\0
REG_SZ              CNFG                          Config.sys
REG_DWORD           SupportedFeatures             f

6: kd> lmDvmCSFirmwareAnalysis
lmDvmCSFirmwareAnalysis
Browse full module list
start             end                 module name
fffff806`58920000 fffff806`5893c000   CSFirmwareAnalysis   (deferred)             
    Image path: \SystemRoot\system32\DRIVERS\CSFirmwareAnalysis.sys
    Image name: CSFirmwareAnalysis.sys
    Browse all global symbols  functions  data  Symbol Reload
    Timestamp:        Mon Mar 18 11:32:14 2024 (65F888AE)
    CheckSum:         0002020E
    ImageSize:        0001C000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
6: kd> !reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csfirmwareanalysis
!reg querykey \REGISTRY\MACHINE\system\ControlSet001\services\csfirmwareanalysis

Hive         ffff84059ca7b000
KeyNode      ffff8405a6f69d9c

[SubKeyAddr]         [VolatileSubKeyName]
ffff84059ce197cc     Enum

 Use '!reg keyinfo ffff84059ca7b000 <SubKeyAddr>' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          1
REG_DWORD           Start                         0
REG_DWORD           ErrorControl                  1
REG_DWORD           Tag                           6
REG_EXPAND_SZ       ImagePath                     system32\DRIVERS\CSFirmwareAnalysis.sys
REG_SZ              DisplayName                   @oem43.inf,%FirmwareAnalysis.SVCDESC%;CrowdStrike Firmware Analysis Service
REG_SZ              Group                         Boot Bus Extender
REG_MULTI_SZ        Owners                        oem43.inf\0!csfirmwareanalysis.inf_amd64_12861fc608fb1440\0
6: kd> !reg querykey \REGISTRY\MACHINE\system\Controlset001\control\earlylaunch
!reg querykey \REGISTRY\MACHINE\system\Controlset001\control\earlylaunch

As we can see from the above analysis, CrowdStrike loads four driver modules. One of those modules receives dynamic control and content updates frequently based on the CrowdStrike Preliminary Post-incident-review timeline.

We can leverage the unique stack and attributes of this crash to identify the Windows crash reports generated by this specific CrowdStrike programming error. It’s worth noting the number of devices which generated crash reports is a subset of the number of impacted devices previously shared by Microsoft in our blog post, because crash reports are sampled and collected only from customers who choose to upload their crashes to Microsoft. Customers who choose to enable crash dump sharing help both driver vendors and Microsoft to identify and remediate quality issues and crashes.

We make this information available to driver owners so they can assess their own reliability via the Hardware Dev Center analytics dashboard. As we can see from the above, any reliability problem like this invalid memory access issue can lead to widespread availability issues when not combined with safe deployment practices. Let’s dig into why security solutions leverage kernel drivers on Windows.

Why do security solutions leverage kernel drivers?

Many security vendors such as CrowdStrike and Microsoft leverage a kernel driver architecture and there are several reasons for this.

Visibility and enforcement of security related events

Kernel drivers allow for system wide visibility, and the capability to load in early boot to detect threats like boot kits and root kits which can load before user-mode applications. In addition, Microsoft provides a rich set of capabilities such as system event callbacks for process and thread creation and filter drivers which can watch for events like file creation, deletion, or modification. Kernel activity can also trigger call backs for drivers to decide when to block activities like file or process creations. Many vendors also use drivers to collect a variety of network information in the kernel using the NDIS driver class.

Performance

Kernel drivers are often utilized by security vendors for potential performance benefits. For example, analysis or data collection for high throughput network activity may benefit from a kernel driver. There are many scenarios where data collection and analysis can be optimized for operation outside of kernel mode and Microsoft continues to partner with the ecosystem to improve performance and provide best practices to achieve parity outside of kernel mode.

Tamper resistance

A second benefit of loading into kernel mode is tamper resistance. Security products want to ensure that their software cannot be disabled by malware, targeted attacks, or malicious insiders, even when those attackers have admin-level privileges. They also want to ensure that their drivers load as early as possible so that they can observe system events at the earliest possible time. Windows provides a mechanism to launch drivers marked as Early Launch Antimalware (ELAM) early in the boot process for this reason. CrowdStrike signs the above CSboot driver as ELAM, enabling it to load early in the boot sequence.

In the general case, there is a tradeoff that security vendors must rationalize when it comes to kernel drivers. Kernel drivers provide the above properties at the cost of resilience. Since kernel drivers run at the most trusted level of Windows, where containment and recovery capabilities are by nature constrained, security vendors must carefully balance needs like visibility and tamper resistance with the risk of operating within kernel mode.

All code operating at kernel level requires extensive validation because it cannot fail and restart like a normal user application. This is universal across all operating systems. Internally at Microsoft, we have invested in moving complex Windows core services from kernel to user mode, such as font file parsing from kernel to user mode.

It is possible today for security tools to balance security and reliability. For example, security vendors can use minimal sensors that run in kernel mode for data collection and enforcement limiting exposure to availability issues. The remainder of the key product functionality includes managing updates, parsing content, and other operations can occur isolated within user mode where recoverability is possible. This demonstrates the best practice of minimizing kernel usage while still maintaining a robust security posture and strong visibility.

Windows provides several user mode protection approaches for anti-tampering, like Virtualization-based security (VBS) Enclaves and Protected Processes that vendors can use to protect their key security processes. Windows also provides ETW events and user-mode interfaces like Antimalware Scan Interface for event visibility. These robust mechanisms can be used to reduce the amount of kernel code needed to create a security solution, which balances security and robustness.

How does Windows help ensure the quality of security related third-party products?

Microsoft engages with third-party security vendors through an industry forum called the Microsoft Virus Initiative (MVI). This group consists of Microsoft and Security Industry and was created to establish a dialogue and collaboration across the Windows security ecosystem to improve robustness in the way security products use the platform. With MVI, Microsoft and vendors collaborate on the Windows platform to define reliable extension points and platform improvements, as well as share information about how to best protect our customers.

Microsoft works with members of MVI to ensure compatibility with Windows updates, improve performance, and address reliability issues. MVI partners actively participating in the program contribute to making the ecosystem more resilient and gain benefits including technical briefings, feedback loops with Microsoft product teams, and access to antimalware platform features such as ELAM and Protected Processes. Microsoft also provides runtime protection such as Patch Guard to prevent disruptive behavior from kernel driver types like anti-malware.

In addition, all drivers signed by the Microsoft Windows Hardware Quality Labs (WHQL) must run a series of tests and attest to a number of quality checks, including using fuzzers, running static code analysis and testing under runtime driver verification, among other techniques. These tests have been developed to ensure that best practices around security and reliability are followed. Microsoft includes all these tools in the Windows Driver Kit used by all driver developers. A list of the resources and tools is available here.

All WHQL signed drivers are run through Microsoft’s ingestion checks and malware scans and must pass before being approved for signing. Additionally, if a third-party vendor chooses to distribute their driver via Windows Update (WU), the driver also goes through Microsoft’s flighting and gradual rollout processes to observe quality and ensure the driver meets the necessary quality criteria for a broad release.

Can customers deploy Windows in a higher security mode to increase reliability?

Windows at its core is an open and versatile OS, and it can easily be locked down for increased security using integrated tools. In addition, Windows is constantly increasing security defaults, including dozens of new security features enabled by default in Windows 11.

Security features enabled by default in Windows 11

Windows has integrated security features to self-defend. This includes key anti-malware features enabled by default, such as:

1. Secure Boot, which helps prevent early boot malware and rootkits by enforcing signing consistently across Windows boots.
2. Measured Boot, which provides TPM-based hardware cryptographic measurements on boot-time properties available through integrated attestation services such as Device Health Attestation.
3. Memory integrity (also known as hypervisor-protected code integrity or HVCI), which prevents runtime generation of dynamic code in the kernel and helps ensure control flow integrity.
4. Vulnerable driver blocklist, which is on by default, integrated into the OS, and managed by Microsoft. This complements the malicious driver block list.
5. Protected Local Security Authority is on by default in Windows 11 to protect a range of credentials. Hardware-based credential protection is on by default for enterprise versions of Windows.
6. Microsoft Defender Antivirus is enabled by default in Windows and offers anti-malware capabilities across the OS.

These security capabilities provide layers of protection against malware and exploitation attempts in modern Windows. Many Windows customers have leveraged our security baseline and Windows security technologies to harden their systems and these capabilities collectively have reduced the attack surface significantly.

Using the integrated security features of Windows to prevent adversary attacks such as those displayed in the MITRE ATT&CK® framework increases security while reducing cost and complexity. It leverages best practices to achieve maximum security and reliability. These best practices include:

1. Using App Control for Business (formerly Windows Defender Application Control), you can author a security policy to allow only trusted and/or business-critical apps. Your policy can be crafted to deterministically and durably prevent nearly all malware and “living off the land” style attacks. It can also specify which kernel drivers are allowed by your organization to durably guarantee that only those drivers will load on your managed endpoints.
2. Use Memory integrity with a specific allow list policy to further protect the Windows kernel using Virtualization-based security (VBS). Combined with App Control for Business, memory integrity can reduce the attack surface for kernel malware or boot kits. This can also be used to limit any drivers that might impact reliability on systems.
3. Running as Standard User and elevating only as necessary. Companies that follow the best practices to run as standard user and reduce privileges mitigate many of the MITRE ATT&CK® techniques.
4. Use Device Health Attestation (DHA) to monitor devices for the right security policy, including hardware-based measurements for the security posture of the machine. This is a modern and exceptionally durable approach to ensure security for high availability scenarios and uses Microsoft’s Zero Trust architecture.

What is next?

Windows is a self-protecting operating system that has produced dozens of new security features and architectural changes in recent versions. We plan to work with the anti-malware ecosystem to take advantage of these integrated features to modernize their approach, helping to support and even increase security along with reliability.

This includes helping the ecosystem by:

1. Providing safe rollout guidance, best practices, and technologies to make it safer to perform updates to security products.
2. Reducing the need for kernel drivers to access important security data.
3. Providing enhanced isolation and anti-tampering capabilities with technologies like our recently announced VBS enclaves.
4. Enabling zero trust approaches like high integrity attestation which provides a method to determine the security state of the machine based on the health of Windows native security features.

As we move forward, Windows is continuing to innovate and offer new ways for security tools to detect and respond to emerging threats safely and securely. Windows has announced a commitment around the Rust programming language as part of Microsoft’s Secure Future Initiative (SFI) and has recently expanded the Windows kernel to support Rust.

The information in this blog post is provided as part of our commitment to communicate learnings and next steps after the CrowdStrike incident. We will continue to share ongoing guidance on security best practices for Windows and work across our broad ecosystem of customers and partners to develop new security capabilities based on your feedback.

The post Windows Security best practices for integrating and managing security tools appeared first on Microsoft Security Blog.

This blog post, informed by insights from the Microsoft Incident Response team, will guide you through some key considerations of incident response readiness, structured through the people, process, and technology framework. Starting with the process, a key foundational piece, this blog post will provide guidance on actions such as:

• Developing a robust disaster recovery plan.
• Implementing a rigorous audit of admin accounts and services.
• Appointing an Incident Manager and outlining communication with vendors.

Read on to dive deeper into key technical concepts and actionable steps you can take to boost your incident response readiness and proactive threat engagements.

Microsoft Incident Response

Dedicated experts work with you before, during, and after a cybersecurity incident.

Explore services

The process

Developing a disaster recovery plan

Developing a robust disaster recovery plan ensures business continuity and resilience against cyberthreats, natural disasters, or other disruptive events. This plan specifies the procedures and protocols for responding to security incidents, emphasizing rapid response, data recovery, and the restoration of critical services. Many companies prepare for fires, so why not incidents? Due to lack of continuity and organization of efforts, organizations without disaster recovery plans usually experience greater impact from unforeseen incidents.

When crafting a disaster recovery plan, conduct a comprehensive risk assessment to pinpoint potential threats, vulnerabilities, and single points of failure within your infrastructure. This step requires defining recovery objectives, prioritizing critical assets and services, and setting recovery time objectives and recovery point objectives based on business requirements and risk tolerance. Many organizations lack the personnel or capability to maintain an in-house incident response team and outsource with services like Microsoft Incident Response.

Disaster recovery plans often include recommendations like implementing a tiered approach to network recovery, managing on-site backups, performing off-site replication, and using cloud-based recovery services. These practices boost resilience and redundancy, minimizing downtime and data loss. Regularly testing and validating your plan with tabletop exercises, simulations, and drills is critical for identifying gaps, refining procedures, and ensuring readiness for real-world incidents.

When Microsoft Incident Response engages with customers that have disaster recovery plans in place, those plans have tremendously aided in ensuring business continuity. Pre-existing processes, warm backups, trained staff, and communication agreements with applicable vendors all empower the investigation and recovery efforts. Rather than developing a reactive disaster recovery plan in parallel with investigation efforts, an existing disaster recovery plan allows Microsoft Incident Response and the organization to focus on investigating threat actor actions. This also enables the organization’s staff to focus solely on bringing up their line of business apps. Engaging an incident response team alongside a comprehensive disaster recovery plan greatly expedites restoration time to keep your environment running.

Figure 1. Workstreams that surround and support incident response throughout the lifecycle of an incident. See our team guide for context.

Validating effective deployment mechanisms

Ensuring the integrity and authenticity of software and system updates requires secure deployment mechanisms. Protect these systems—especially since threat actors often exploit them for tool deployment—by auditing their storage and configurations regularly. Adopting best practices like code signing, secure boot, and encrypted communications prevents unauthorized process tampering.

Correct setup requires varied deployment methods to be effective during incidents. Rapid tool deployment is important when working with an incident response team. Microsoft Configuration Manager, Microsoft Intune, Group Policy, and third-party tools are commonly used. Microsoft Incident Response deploys custom security tools alongside the Microsoft Defender suite to collect metadata efficiently across the environment, enabling a stronger response.

Enabling comprehensive auditing and logging

Auditing and logging are vital for a strong cybersecurity posture, offering insight into system activities and security events. Though enabling these features on all systems might increase overhead, the advantages in threat detection, incident response, and compliance outweigh the costs.

Adopting a risk-based approach to auditing and logging and focusing on critical assets and high-risk areas are essential. Configuring logs to capture relevant security events and optimizing retention policies ensure a balance between storage needs and forensic requirements.

Many Microsoft customers leverage Microsoft Sentinel, our cloud-native security information and event management (SIEM) solution for efficient large-volume data analysis. Microsoft Sentinel allows real-time log data aggregation, correlation, and analysis from various sources, aiding security teams in swift incident detection and response. Coupled with the Defender suite and Azure, Microsoft Sentinel offers invaluable trend data for incident response investigations.

The people

Appointing an incident manager for effective coordination

Appointing an Incident Manager is critical for leading and coordinating incident response efforts, from detection to recovery. This person serves as the main point of contact for stakeholders and response teams and ensures clear communication and effective collaboration. They examine, streamline, and log all environment change requests according to the disaster recovery plan.

An Incident Manager’s deep understanding of business processes and technical infrastructure aids in making informed decisions and prioritizing actions. Strong leadership and communication skills are essential for guiding teams and achieving consensus under pressure.

Without an Incident Manager, directionless and unclear communication allows threat actors to exploit chaos. A definitive leader streamlines work and facilitates clear communication, essential for efficient incident response. The absence of a coordinated effort can lead to fragmented work, prolonged network downtime, and severe access restoration delays for users or customers.

Figure 2. An example of the roles involved in incident response and the importance of an incident manager or controller. (See our team guide for more context.)

Maintaining open communication with security vendors

Open communication with security vendors is vital for enhancing cybersecurity. Strategic partnerships grant access to the latest technologies, threat intelligence, and best practices for threat management.

Security vendors assist in whitelisting tools, configuring policies, and optimizing security settings to meet standards and regulations. They also guide incident alert interpretation, remediation prioritization, and security measure implementation tailored to organizational needs.

Collaborating with vendors keeps organizations informed about emerging threats and attack techniques through threat intelligence feeds and security bulletins. This proactive intelligence sharing enables you to anticipate risks and mitigate them before security incidents escalate.

The technique

Enhancing security by hardening identity

Conduct a comprehensive Zero Trust audit on accounts and services with administrative privileges within your system to defend against potential security breaches effectively. This audit requires scrutinizing user and admin accounts, system configurations, and service permissions to spot anomalies or unauthorized access points. Leveraging robust identity and access management solutions is crucial to enforce the least-privilege principle. By giving users only the necessary permissions for their roles, organizations can significantly lower the attack surface and the risk of privilege escalation.

Use Enterprise Admins and Schema Admins, two built-in groups that can alter an Active Directory Forest, only for specific changes to the environment’s framework, then remove them. Also, you should audit AdminSDHolder, a common persistence method. Enforcing any privileges assigned to a user or group in the AdminSDHolder object remains effective regardless of changes in other Active Directory parts.

Microsoft Incident Response often recommends the enterprise access model or tiering to harden the identity plane for various environments. The tiering aims to protect identity (Tier 0) and all servers interacting with it, including Tier 0 management servers, all within the same plane. This model mandates administrators to have accounts in their specific plane, reducing the chances of lateral movement and privilege escalation.

Quick wins for safeguarding assets

When safeguarding accounts, methods like multifactor authentication introduce an additional security layer, making it harder for adversaries to compromise critical systems and data. Easy wins with multifactor authentication include enabling number matching and fraud alert, or mandating access through a Microsoft Entra-joined device.

Establishing an inactive (or stale) accounts policy is critical to reduce and eliminate potential entry points. Security vendors often create overprovisioned guest accounts that remain active until the contractor returns. Formulate a policy to disable and eventually delete accounts when not in use, marking a swift victory. A stale account policy, combined with a password policy and account lockout policy, helps secure the identity plane in an environment.

Proactively auditing services and machines

Auditing services and machines within the network is vital for identifying and mitigating security risks. Documenting the configurations and dependencies of all hardware and software assets, and assessing their vulnerability exposure, is important.

Automated asset management and vulnerability scanning tools streamline auditing and keep asset inventories current. Legacy software dependence, especially on unsupported systems, introduces vulnerabilities. Vulnerability scanning allows for proactive risk, patch, and configuration management, meeting security and compliance needs.

For best results, you should classify assets by criticality and sensitivity to prioritize security controls and resources. Distinguishing between protected legacy systems and risky end-of-life systems due to outdated or unsupported configurations is essential.

Driving incident response in your organization

Proactively preparing for incident response is essential given modern cybersecurity challenges. By strengthening defenses, maintaining a comprehensive disaster recovery plan, and leveraging expert resources like the Microsoft Incident Response team, you can confidently manage threats. Our expertise and quick response capabilities are invaluable in cyber risk mitigation.

Effective coordination and robust logging mechanisms reduce incident impacts and ensure operational resilience. Preparation is key in a world facing inevitable cyber threats. Learn more about Microsoft Incident Response proactive and reactive response services or find clarity in the maze of incident response in our helpful team guide.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post How to boost your incident response readiness appeared first on Microsoft Security Blog.

As part of any robust incident response plan, organizations often work through potential security weaknesses by responding to hypothetical cyberthreats. In this blog post, we’ll imagine a scenario in which a threat actor uses malware to infect the network, moving laterally throughout the environment and attempting to escalate their admin rights along the way. In this hypothetical scenario, we’ll assume containment of the incident requires a mass password reset.

Despite technological advances, many organizations still depend heavily on passwords, making them vulnerable to cyberthreats. During a ransomware attack, the need for mass password resets becomes urgent. Unfortunately, admins can quickly become overwhelmed, burdened with the daunting task of resetting passwords for countless users across multiple connected devices. The surge in help desk calls and service tickets as users face authentication issues on multiple fronts can significantly disrupt business operations. But it’s imperative to secure all digital access points to swiftly mitigate risks and restore system integrity. So how do we manage a mass password reset while minimizing disruption to users and the business?

This blog post delves into the processes and technologies involved in managing a mass password reset, in alignment with expert advice from Microsoft Incident Response. We’ll explore the necessity of mass password resets and the specific methods and security measures that Microsoft recommends to effectively safeguard identities. For a more technical explanation, read our Tech Community post.

Surge in password-based cyberattacks

According to the most recent Microsoft Digital Defense Report, password-based attacks in 2023 increased tenfold over the previous year, with Microsoft blocking about 4,000 attacks per second through Microsoft Entra.¹ This alarming rise underscores the vulnerability of password-dependent security systems. Despite this, too many companies haven’t adopted multifactor authentication, leaving them vulnerable to a variety of cyberattacks, such as phishing, credential stuffing, and brute force attacks. This makes a mass password reset not just a precaution, but a necessity in certain situations.

Deciding on a mass password reset

When the Microsoft Incident Response team determines a threat actor has had extensive access to a customer’s identity plane, a mass password reset may be the best option to restore environment security and prevent unauthorized access. Here are a few of the first questions we ask:

• When should you perform a mass password reset?
• What challenges might you face during the process?
• How should you prepare for it?

Microsoft Incident Response

Dedicated experts work with you before, during, and after a cybersecurity incident.

Explore services

How to manage a mass password reset effectively

In today’s world, many of us are working from anywhere, blending home and office environments. This diversity makes executing a mass password reset particularly challenging, and the decision isn’t always clear. Organizations need to weigh the risk to the business from ransomware and down time against the disruption to users and the often overwhelming strain on IT staff. Here are the two main drivers of mass password resets, as well as advanced security measures a cybersecurity team can apply.

User-driven resets

In environments where identities sync through Microsoft Entra, there’s no need for a direct office connection to reset passwords. Using Microsoft Entra ID capabilities allows users to change their credentials at their next login. Opting for Microsoft Entra ID can also add layers of security through features like Conditional Access, making the reset process both secure and user-friendly. Conditional Access policies work by evaluating the context of each sign-in attempt and allowing you to configure requirements based on that context—like requiring users to complete multifactor authentication challenges if they’re accessing files from outside the corporate network, for example. Conditional Access policies can significantly enhance security by preventing unauthorized access during the reset process.

Administrator-driven resets

This method is crucial when immediate action is needed. Resetting all credentials quickly might disrupt user access, but it’s sometimes necessary to secure the system. Providing options like self-service password reset (SSPR) can help users regain access without delay. SSPR allows users to authenticate using alternative methods such as personal email addresses, phone numbers, or security questions—options available when they have been previously configured. This method not only restores access quickly but also reduces the load on help desk and support hotline departments during critical recovery phases.

Advanced security measures: Beyond basic resets

In addition to the primary reset methods, advanced security measures should be considered to enhance the security posture further. For highly privileged accounts, using privileged identity management (PIM) can manage just-in-time access, reducing the risk of exposure. PIM enables granular control over privileged accounts, allowing administrators to activate them only when necessary, which minimizes the opportunity for attackers to exploit these high-level credentials. To explore more scenarios where mass password reset might be the best option, read through our technical post.

Securing emergency access: Don’t forget to monitor

For critical accounts, manually resetting credentials ensures tighter security. It’s essential to equip emergency access accounts with phishing-resistant authentication, such as FIDO2 security keys and support from the Microsoft Authenticator app. Monitoring the activities from these accounts is crucial to ensure they are used correctly and only in emergencies. IT admins can leverage Microsoft Entra ID logs to keep a close watch on login patterns and activities, viewing real-time alerts and ensuring quick response to any suspicious actions.

Passwordless authentication and enhancing incident response

As cybersecurity evolves, the move toward passwordless authentication is becoming integral to enhancing incident response strategies. Traditional passwords—often vulnerable to breaches—are giving way to more secure methods like Windows Hello for Business, Microsoft Authenticator, and FIDO2 security keys. These technologies leverage biometrics and secure tokens, reducing common attack vectors such as password theft and phishing, and thereby streamlining the incident response process. Policies like a Temporary Access Pass can be configured to empower a move towards passwordless authentication, making it easier for users to register new strong authentication methods.

Implementing multifactor authentication also further strengthens security frameworks. Multifactor authentication is an essential component of basic security hygiene that can prevent 99% of account compromise attacks.¹ When integrated with phishing-resistant authentication methods, together they form a formidable barrier against unauthorized access. This dual approach not only speeds up the response during security incidents but also reduces potential entry points for attackers. This transformative phase in cybersecurity shifts focus on reactive to proactive security measures, promising a future where digital safety is inherent and user interactions are inherently secure. An option to enable phish-resistant authentication is the newly released ability to use passkeys with the Microsoft Authenticator.

A mass password reset is just one of the many tools organizations need to understand and consider as part of their robust incident response plan. For a more in-depth look at scenarios that may require mass password reset, read our technical post.

Learn more

Learn more about Microsoft Incident Response and Microsoft Entra.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2023.

The post Microsoft Incident Response tips for managing a mass password reset appeared first on Microsoft Security Blog.

Organizations face an increasingly complex cybersecurity landscape. The cybersecurity workforce growth rate lags behind the necessary 12.6% annual expansion to effectively counter cyberthreats, only achieving an 8.7% increase. This shortfall leaves a gap of approximately 4 million professionals worldwide. Amidst this challenge, companies navigate layoffs, budget cuts, and hiring freezes with expectations of further economic tightening in 2024.¹

Yet cybersecurity expertise is crucial, especially when dealing with complex issues like analyzing Windows Internals during forensic investigations—a task that requires deep technical knowledge to interpret various artifacts and timestamps accurately. To help like-minded defenders tackle this difficult task, Microsoft Incident Response experts have created a guide on using Windows Internals for forensic investigations.

Guidance for Incident Responders

The new guide from the Microsoft Incident Response team helps simplify forensic investigations.

Get the guide

Microsoft Incident Response guide highlights

Our guide serves as an essential resource, meticulously structured to illuminate commonly seen, but not commonly understood, Windows Internals features in forensic investigations. Understanding these artifacts will strengthen your ability to conduct Windows forensic analysis. Equipped with this information and your new findings, you’ll be able to construct more complete timelines of activity. It includes the following topics:

• AmCache’s contribution to forensic investigations: The AmCache registry hive’s role in storing information about executed and installed applications is crucial, yet it’s often mistakenly believed to capture every execution event. This misunderstanding can lead to significant gaps in forensic narratives, particularly where malware employs evasion techniques. Moreover, the lack of execution timestamp specificity in AmCache data further complicates accurate timeline reconstruction.
• Browser forensics: Uncovering digital behaviors: The comprehensive analysis of browser artifacts is fraught with challenges, particularly regarding the interpretation of local file access records. The misconception that browsers do not track local file access can lead to significant oversight in understanding user behavior, underscoring the need for thorough and nuanced analysis of browser data.
• The role of Link files and Jump Lists in forensics: Link, or LNK, files and Jump Lists are pivotal for documenting user behaviors. However, investigators sometimes neglect the fact that they’re prone to manipulation or deletion by users or malware. This oversight can lead to flawed conclusions. Furthermore, Windows’ automatic maintenance tasks, which can alter or delete these artifacts, add another layer of complexity to their analysis.
• Prefetch files and program execution: Prefetch files’ role in improving application launch times and their forensic value in tracking application usage is well-documented. However, the common error of conflating the prefetch file’s creation date with the last execution date of an application leads to mistaken conclusions about usage patterns. Also, overlooking the aggregation of data from multiple prefetch files can result in a fragmented understanding of application interactions over time.
• ShellBags forensic analysis: ShellBags, with their ability to record user interactions with the File Explorer environment, offer a rich source of information. Yet not all investigators recognize that ShellBags track deleted and moved folders, in addition to current ones. This oversight can lead to incomplete reconstructions of user activities.
• Shimcache’s forensic evolution: The Shimcache has long served as a source of forensic information, particularly as evidence of program execution. However, the changes in Windows 10 and later have significantly impacted the forensic meaning of Shimcache artifacts: indicating file presence, and not indicating execution. This misunderstanding can mislead investigators, especially since Shimcache logs the last modification timestamp, not execution time, and data is only committed to disk upon shutdown or reboot.
• Forensic insights with SRUM: SRUM’s tracking of application execution, network activity, and resource consumption is a boon for forensic analysts. However, the wealth of data can also be overwhelming, leading to crucial details being missed or misinterpreted. For instance, the temporal discrepancies between the SRUM database and system logs can confuse investigators, making it challenging to align activities accurately. Additionally, the finite storage of SRUM data means older information can be overwritten without notice, a fact that’s often overlooked, resulting in gaps in data analysis.
• The importance of User Access Logging (UAL): UAL’s tracking of user activities based on roles and access origins is essential for security analysis, especially since this feature is designed for Windows Server operating systems (specifically 2012 and later). Its vast data volume can be daunting, leading to potential oversight of unusual access patterns or lateral movements. Additionally, the annual archiving system of UAL data can cause confusion regarding the longevity and accessibility of logs, impacting long-term forensic investigations.
• Decoding UserAssist for forensic evidence: The UserAssist feature’s tracking of GUI-based program interactions is often misunderstood, with analysts mistakenly prioritizing run counts over focus time. This misstep can lead to inaccurate assumptions about application usage, as focus time—a more reliable indicator of execution—gets overlooked.

Why read this guide today

Bridging the gap between gaining insights from the Microsoft Incident Response team and the practical application of these strategies within your own organization underscores a journey from knowledge acquisition to operational implementation. By downloading the guide, you’re not just accessing a wealth of expert strategies, you’re initiating a critical shift towards a more resilient cybersecurity posture. This transition naturally leads to the understanding that while the right tools and strategies are vital, the true essence of cybersecurity lies in the practice and adoption of a security-minded culture within your organization.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹How the Economy, Skills Gap and Artificial Intelligence are Challenging the Global Cybersecurity Workforce, ISC2. 2023.

The post New Microsoft Incident Response guide helps simplify cyberthreat investigations appeared first on Microsoft Security Blog.

Microsoft Incident Response

Strengthen your security with an end-to-end portfolio of proactive and reactive cybersecurity incident response services.

Explore services

One click opens the door to a threat actor

We know that 50% of Microsoft cybersecurity recovery engagements relate to ransomware,² and 61% of all breaches involve credentials.³ Identity attacks continue to be a challenge for businesses because humans continue to be a central risk vector in social engineering identity attacks. People click links without thinking. Too often, users open attachments by habit, thereby opening the door to threat actors. Even when employees recognize credential harvesting attempts, they’re often still susceptible to drive-by URL attacks. And teams focused on incident response are often disconnected from teams that manage corporate identities. In this incident, one click on a malicious link led a large customer to reach out to Microsoft Incident Response for help.

Figure 1. Diagram of a threat actor’s malware moving through the network.

The malicious link the employee clicked infected their device with Qakbot. Qakbot is a modular malware that has been evolving for more than a decade. It’s a multipurpose malware that unfortunately gives attackers a wide range of capabilities. Once the identity-focused threat actor had established multiple avenues of persistence in the network and seemed to be preparing to deploy ransomware, the customer’s administrators and security operations staff were overwhelmed with tactical recovery and containment. That’s when they called Microsoft.

Your first call before, during, and after a cybersecurity incident

Microsoft Incident Response stepped in and deployed Microsoft Defender for Identity—a cloud-based security solution that helps detect and respond to identity-related threats. Bringing identity monitoring into incident response early helped an overwhelmed security operations team regain control. This first step helped to identify the scope of the incident and impacted accounts, take action to protect critical infrastructure, and work on evicting the threat actor. Then, by leveraging Microsoft Defender for Endpoint alongside Defender for Identity, Microsoft Incident Response was able to trace the threat actor’s movements and disrupt their attempts to use compromised accounts to reenter the environment. And once the tactical containment was complete and full administrative control over the environment was restored, Microsoft Incident Response worked with the customer to move forward to build better resiliency to help prevent future cyberattacks. More information about the incident and remediation details can be found on our technical post titled “Follow the Breadcrumbs with Microsoft Incident Response and Microsoft Defender for Identity: Working Together to Fight Identity-Based Attacks.”

Strengthen your identity posture with defense in depth

We know protecting user identities can help prevent incidents before they happen. But that protection can take many forms. Multiple, collaborative layers of defense—or defense in depth—can help build up protection so no single control must shoulder the entire defense. These layers include multifactor authentication, conditional access rules, mobile device and endpoint protection policies, and even new tools—like Microsoft Copilot for Security. Defense in depth can help prevent many cyberattacks—or at least make them difficult to execute—through the implementation and maintenance of layers of basic security controls.

In a recent Cyberattack Series blog post and report, we go more in depth on how to protect credentials against social engineering attacks. The cyberattack series case involved Octo Tempest—a highly active cyberthreat actor group which utilizes varying social engineering campaigns with the goal of financial extortion across many business sectors through means of data exfiltration and ransomware. Octo Tempest compromised a customer with a targeted phishing and smishing (text-based phishing) attack. That customer then reached out to Microsoft Incident Response for help to contain, evict, and detect any further threats. By collaborating closely with the victim organization’s IT and security teams, the compromised systems were isolated and contained. Throughout the entire process, effective communication and coordination between the incident response team and the affected organization is crucial. The team provides regular updates on their progress, shares threat intelligence, and offers guidance on remediation and prevention strategies. By working together seamlessly, the incident response team and the affected organization can mitigate the immediate cyberthreat, eradicate the cyberattacker’s presence, and strengthen the organization’s defenses against future cyberattacks.

Honeytokens: A sweet way to defend against identity-based attacks

Another layer of protection for user identities is the decoy account. These accounts are set up expressly to lure attackers, diverting their attention away from real targets and harmful activities—like accessing sensitive resources or escalating privileges. The decoy accounts are called honeytokens, and they can provide security teams with a unique opportunity to detect, deflect, or study attempted identity attacks. The best honeytokens are existing accounts with histories that can help hide their true nature. Honeytokens can also be a great way to monitor in-progress attacks, helping to discover where attackers are coming from and where they may be positioned in the network. For more detailed instructions on how to tag an account as a honeytoken and best practices for honeytoken use, read our tech community post titled “Deceptive defense: best practices for identity based honeytokens in Microsoft Defender for Identity.”

Working together to build better resilience

Microsoft Incident Response is the first call for customers who want to access dedicated experts before, during, and after any cybersecurity incident. With on-site and remote assistance on a global scale, unprecedented access to product engineering, and the depth and breadth of Microsoft Threat Intelligence, it encompasses both proactive and reactive incident response services. Collaboration is key. Microsoft Incident Response works with the tools and teams available to support incident response—like Defender for Identity, Defender for Endpoint, and now Copilot for Security—to defend against identity-based attacks, together. And that collaboration helps ensure better outcomes for customers. Learn more about the Microsoft Incident Response proactive and reactive response services or see it in action in the fourth installment of our ongoing Cyberattack Series.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report, Microsoft. 2023.

²Microsoft Digital Defense Report, Microsoft. 2022.

³2023 Data Breach Investigations Report, Verizon.

⁴Microsoft Entra: 5 identity priorities for 2023, Joy Chik. January 9, 2023.

The post How Microsoft Incident Response and Microsoft Defender for Identity work together to detect and respond to cyberthreats appeared first on Microsoft Security Blog.

With more than 3,000 different activities (also known as operations) logged into the Microsoft 365 suite, knowing which are useful for your investigation can be daunting. With these guides, our goal is to make triaging and analyzing data in Microsoft 365 simpler. Many of these operations are data-based storytelling vehicles, helping Microsoft Incident Response to piece together an attack chain from beginning to end. We have worked on hundreds of cloud-centric cases with our customers, and while tactics, techniques, and procedures (TTPs) change with the times, analysis methodology and data triage techniques remain consistently successful. To enable Microsoft Incident Response to find ground truth quickly and effectively in an investigation, data mining based on known factors is essential. The known factors could be investigation specific, such as an IP address, known compromised username, or suspicious user agent string. It is also just as important to filter based on how actors move through a cloud environment and gather data. This is where these guides come into their own, and our hope is that sharing these guides can help you in the same way they help us every day.

Microsoft Incident Response guides

These new one-page guides from Microsoft Incident Response helps security teams analyze cyberthreat data in Microsoft 365 and Microsoft Entra.

Download the guides

Analyze the Unified Audit Log in Microsoft 365

First up is our general Microsoft 365 guide, centered around key activities in Exchange Online and SharePoint—Microsoft 365 products commonly targeted in cybersecurity attacks. Keep in mind that the motives of a Threat Actor, the tools available to them, and the level of access they have achieved will determine the actions they take. No two incidents are ever the same.

Actions carried out in a tenant are recorded in the Unified Audit Log, which can be accessed from the Security Portal or through PowerShell. You can filter the audit log by date, user, activity, IP address, or file name. You can also export the audit log to a CSV file for further analysis.

Most of the operations in these sheets are self-explanatory in nature, but a few deserve further context:

SearchQueryPerformed—A user or an administrator has performed a search query in SharePoint Online or OneDrive for Business. This operation returns information about a search query performed in SharePoint Online, including the query text used. Keep in mind that interacting with certain components of SharePoint will trigger background ‘searches.’

SearchQueryInitiatedSharePoint and SearchQueryInitiatedExchange—These operations are only logged if you have enabled them using the Set-Mailbox PowerShell cmdlet. This operation is much like SearchQueryPerformed, but applies to mailbox-level searches.

SearchExportDownloaded—A report was downloaded of the results from a content search in Microsoft 365. This operation returns information about the content search, such as the name, status, start time, and end time.

Update—A message item was updated, including metadata. One example of this is when an email attachment is opened, which updates the metadata of the message item and generates this event. An update operation is not always indicative of an email message being purposefully modified by a Threat Actor.

FileSyncDownloadedFull—User establishes a sync relationship and successfully downloads files for the first time to their computer from a SharePoint or OneDrive for Business document library.

Detailed identity and access data with Microsoft Entra

Our Microsoft Entra guide covers actions which allow organizations to manage and protect their identities, data, and devices in the cloud. As an industry-leading identity platform, Microsoft Entra ID offers advanced security features, such as multifactor authentication, Conditional Access policies, identity protection, privileged access management, and identity governance.

To view the activities performed by users and administrators in Microsoft Entra ID, you can use the Microsoft Entra ID audit log, which stores events related to role management, device registration, and directory synchronization to name a few. To view detailed sign-in information, you can use the Sign-In Logs. The events located in these two data sources can help you detect and investigate security incidents, such as unauthorized access or configuration changes to the identity plane.

You can use the following methods to access Microsoft Entra ID audit log data:

Microsoft Entra Admin Portal—Go to the portal and sign in as an administrator. Navigate to Audit and/or Sign-ins under Monitoring. Filter, sort, and export the data as needed.

Graph PowerShell—Install the Graph PowerShell module and connect to Microsoft Entra ID. Use Get-MgAuditLogDirectoryAudit and/or Get-MgAuditLogSignIn to get the data you need.

Microsoft Graph API—Register an application in Microsoft Entra ID and give it the permissions to read audit log data (AuditLog.Read.All and Directory.Read.All). Use /auditLogs/directoryAudits and /auditLogs/signIns API endpoints to query the data, along with query parameters such as $filter to refine the results.

Most of the operations in these sheets are self-explanatory in nature, but as with our Microsoft 365 operations, a few deserve further context:

Suspicious activity reported—This log event indicates that a user or an administrator has reported a sign-in attempt as suspicious. The log event contains information about the reported sign-in—such as the user, the IP address, the device, the browser, the location, and the risk level. It also shows the status of the report—whether it was confirmed, dismissed, or ignored by the user or the administrator. This log event can help identify potential security incidents, including phishing, credential compromise, or malicious insiders.

Update application: Certificates and secrets management—This log event indicates that an administrator has updated the certificates or secrets associated with an application registered in Microsoft Entra ID—such as creation, deletion, expiration, or renewal. Applications are frequently misused by Threat Actors to gain access to data, making this a critical administrative event if found during an investigation.

Any operation ending in ‘(bulk)’—These are interesting as they demonstrate a bulk activity being performed—such as ‘Download users’ or ‘Delete users.’ Keep in mind, however, that these are only logged if the bulk activity is performed using the graphical user interface. If PowerShell is used, you will not see these entries in your log.

Elevate Access—Assigns the currently logged-in identity the User Access Administrator role in Azure Role-Based Access Control at root scope (/). This grants permissions to assign roles in all Azure subscriptions and management groups associated with the Microsoft Entra directory. This toggle is only available to users who are assigned the Global Administrator role in Microsoft Entra ID. It can be used by Threat Actors to gain complete control of Azure resources, often for the purposes of crypto mining or lateral movement from cloud to on-premises.

Improve security analysis with the Microsoft Incident Response guides

We hope that these one-page guides will be a valuable resource for you when you need to quickly identify and analyze suspicious or malicious activity in Microsoft 365 and Microsoft Entra ID. Print them out, save them as your desktop background, or put them on a mouse pad. Whatever you do, let us know what you find useful and remember that the audit logs in Microsoft 365 and Microsoft Entra ID are not the only source of evidence in a cloud-based case, and you should always correlate and validate your findings with other data sources where possible.

To access further information on what data lies in these logs and how you can access them, reference the following blog posts from the Microsoft Incident Response team:

• Forensic artifacts in Office 365 and where to find them—Microsoft Community Hub.
• Good UAL Hunting—Microsoft Community Hub.

Learn more

Learn more about Microsoft Incident Response.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and Twitter (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post New Microsoft Incident Response guides help security teams analyze suspicious activity appeared first on Microsoft Security Blog.

Cybersecurity incidents are like mazes: unpredictable, challenging, and easy to get lost in. But with the right map for the maze, organizations can navigate through the twists and turns of critical incidents, avoid common pitfalls, and emerge stronger and more secure. While there are a number of incident response guides and materials readily available online, the Microsoft Incident Response team has created a downloadable, interactive guide specifically focused on two key factors that are critical to effective, timely incident response: People and process. “Navigating the Maze of Incident Response” explains how to structure the human elements of an incident response with recommendations and best practices to help navigate those crucial hours after a breach is first detected. 

One note—this guidance is not intended to replace comprehensive incident response planning, which should occur outside of a live incident. It is a tactical, people-centric guide to help both security teams and senior stakeholders navigate an incident response investigation, should you find yourself in the deep end during an incident.

People-centric planning for incident response

Incident response is always a shared responsibility. The first step during a major response is to assemble a team and define roles and responsibilities for each team member. The assumption is often that incident response is solely a technical endeavor requiring support from technical subject matter experts. While technical expertise is necessary, support is also required from other parts of the business to manage an incident efficiently and recover quickly. A comprehensive incident response team goes beyond technical staff to include leadership, communication, and regulatory support, allowing for an incident to be managed holistically.

At the leadership level, senior stakeholders are often not privy to the true impact and risk associated with a cybersecurity incident. This is often the result of a lack of clarity in communication channels that can be exasperated during a critical incident. Senior leaders can be left ill-equipped to make informed decisions and unable to quantify the true risk to the business. While the technical elements of an incident response are typically top of mind, responding effectively means having the right technical and non-technical support people, processes, and structure in place to manage the workstreams required during an incident response operation.

Microsoft Incident Response suggests organizations consider the command structure outlined in Figure 1 to help define workstreams, roles, and responsibilities. The diagram and the downloadable guide are only a starting point, and additional workstreams may be required depending on the context and complexity of each incident.

Figure 1. Example of an incident command structure.

Understanding roles, responsibilities, and relationships

Within the downloadable guide, the Microsoft Incident Response team details the key activities of each incident response workstream and the responsibilities they each have. It details the key actions, escalation points, potential blockers, and common pitfalls that can hinder a successful response to a major incident. It also surfaces often overlooked incident requirements—like shift planning for responses that span multiple time zones and the risk of team burnout.

An understanding of roles and responsibilities is essential for any organization that wants to be prepared to respond to a cybersecurity incident quickly and effectively. The guide helps leaders understand the “why?” of each workstream, as well as how they all work together. This is our most comprehensive role-based incident response guide yet, to help organizations deepen their understanding of critical people and processes needed for efficient incident response.

Processes to support people-centric incident response

The processes detailed in the guide are specific to each workstream and include links to collaborating roles that may need to be included in each process. For example, for the role of incident controller, the guide outlines the process of using situation reports (SITREPs) and includes a list of key components. It also notes that collaborators should include both the governance lead and the investigation lead roles. Like many processes, real-world situations necessitate some adjustments or refinements. The guide tries to capture those caveats and levers and calls them out in the “common pitfalls” sections. For the role of investigation lead, the guide includes a detailed description of how to define evidence requirements for both on-premises and cloud data, to help organizations understand what has occurred and preserve evidence. This is often a pivotal point in incident response, where the instinct to prioritize recovery efforts must be slowed enough to ensure forensic evidence can be collected first. And for the role of infrastructure lead, the guide outlines the importance of setting up an out-of-band communications channel as existing channels may not be safe for use during a response. These are just a few examples of processes that are defined in-depth within the downloadable guide.

We hope this interactive document delivers more detail, more nuance, and more actionable information on tactical responses to incidents, with a deeper focus on the people and processes required. Download the interactive guide today to see how you can improve your organization’s ability to response effectively and limit impact during a cybersecurity incident.

Navigating the Maze of Incident Response

This downloadable, interactive guide explains how to structure the human elements of an incident response.

Download the guide

Learn more

Learn more about Microsoft Incident Response.

To learn more about Microsoft Incident Response, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (formerly known as “Twitter”) (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Cost of a Data Breach Report, IBM. 2023.

The post New Microsoft Incident Response team guide shares best practices for security teams and leaders appeared first on Microsoft Security Blog.