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.

The team has observed common misconfigurations for both Microsoft Entra ID and on-premises Active Directory across various industry verticals. While Microsoft Entra ID differs from on-premises Active Directory in how it functions and how it is architected, similar high-level incident response and hardening principles can be applied to both. Concepts such as administrative least privilege, regularly reviewing access and application permissions and reviewing activity are important to secure both Active Directory and Microsoft Entra ID.

Microsoft IR engages with hundreds of customers each year, including many of the largest organizations worldwide. These organizations can have hundreds of thousands to millions of active users of Microsoft Entra ID and incredibly complex identity systems. In this blog, we present details on the common misconfigurations observed in these engagements and provide guidance on how to properly configure Microsoft Entra ID to remove risks and harden environments against cyberattacks. This blog is designed to be a Microsoft Entra ID companion piece to a previously published Microsoft IR blog on lessons learned on securing on-premises Active Directory.

• Misconfigured hybrid identity setups
  • Compromised Active Directory Federation Services or equivalent federated identity systems
  • Complex identity systems
  • Compromised synced service accounts
• Token theft of highly privileged accounts
• Excessive privilege granted to users
• Excessive privilege granted to workload identities
• Poor device access control
• Poor application access control
• Misconfigured delegated administrative privileges (DAP) permissions
• Misconfigured Conditional Access policy
• OAuth and consent phishing
• Self-service password reset & MFA social engineering
• Recommended focus areas to prevent identity compromise

To understand a compromise incident and aid in investigations, Microsoft IR retrieves the configuration of Microsoft Entra ID by reading tenant metadata from the Microsoft Graph API. This data is used to both investigate threat actor activity and to aid in providing recommendations for securing Microsoft Entra ID. In addition to configuration metadata, we also leverage native cloud forensic log sources such as Microsoft Entra ID sign-in and audit data – these data sources are available to any organization using Microsoft Entra ID. Open-source tools such as the Microsoft Entra ID Response PowerShell module, developed in conjunction with the Microsoft Entra ID product group, or the untitled goose tool from CISA can retrieve this same data.

Additionally, Microsoft IR uses Microsoft 365 Defender advanced hunting data such as log data from Microsoft Defender for Cloud Apps, and any other relevant log sources a customer may have. In cases of hybrid identity, logs from systems such as Active Directory Federation Services (AD FS) or third-party multifactor authentication (MFA) providers are also relevant. Depending on the nature of the investigation, traditional endpoint forensic sources may also need to be examined.

Misconfigured hybrid identity setups

In the following sub-sections, we present details on the different scenarios involving misconfigured hybrid identity setups that could lead to compromise of Microsoft Entra ID.

Compromised Active Directory Federation Services or equivalent federated identity systems

Each organization’s hybrid identity configuration is unique, and many organizations use a federated identity provider when users authenticate to cloud apps, such as Microsoft 365. These federated identity providers enable user authentication. While a significant percentage of organizations have now moved to cloud-native authentication in Microsoft Entra ID, these federated identity providers, such as AD FS and other third-party identity providers, are still in use.

Microsoft IR finds that federated identity providers present an administrative blind spot within organizations. Hybrid identity can be architecturally complicated with many moving pieces, which often lends itself to operational oversight. Securing these hybrid identity systems is complex, especially legacy solutions, and a single misconfiguration can lead to a significant compromise of an organization’s entire identity plane.

Federated identity providers are a favored target of some nation-state actors: these threat actors understand that if they can compromise the Tier 0 identity plane, then they can persist undetected within an environment for extended periods of time and take control of all identities. Microsoft has published blogs covering the sophisticated cyberattacks seen against AD FS, such as MagicWeb. A deep dive into this tactic was also covered in the Microsoft IR Cyberattack series.

Microsoft IR has also been engaged in multiple incidents where the Token Signing Certificate (TSC) was stolen from on-premises federation servers. Using this stolen certificate, attackers could forge their own SAML tokens and authenticate successfully to Microsoft Entra ID. With this certificate, a threat actor can successfully authenticate as any user in the tenant with any claims without requiring the user’s credentials.

Recommendations

• Microsoft IR strongly recommends moving to native Microsoft Entra ID authentication and decommissioning AD FS (or other federated identity providers) where possible. This reduces the overall complexity of the organization’s identity plane and makes it easier to secure identities.
• If you must use federated identity providers, it’s important to secure and monitor them appropriately.
  • For organizations using AD FS, ensure that the Microsoft Entra Connect Health client is installed. This client correlates multiple Event IDs from AD FS and enriches Microsoft Entra ID sign-in data with that information. This can both help with creating detection and threat hunting rules and serve as a valuable source of forensic data in the event of a compromise.Ensure that appropriate logging is enabled for AD FS and those logs are sent to a SIEM such as Microsoft Sentinel, where detection rules can be created, for both user and system-level compromise, including certificate theft. If an attacker can steal the token signing certificate from AD FS, they can forge their own tokens to authenticate to Entra ID. In these cases, Entra ID will alert on anomalies with the token issuer. Additionally, sign ins using forged tokens may trigger other risk events such as unfamiliar features.If your current MFA solution is integrated to AD FS, consider using native integrated MFA, especially phishing-resistant, options available in Entra ID
  • For organizations with Microsoft Defender for Identity and Microsoft Defender for Endpoint, ensure the agents are deployed to AD FS. Both products have specific capabilities to detect cyberattacks against AD FS.
• For other federated identity providers, ensure those services are configured in line with best practices and that both user logon telemetry and system-level audit events are sent to a central SIEM. Threat actors can dwell in environments, especially identity systems, for months or years before being detected, so it is important that key logs are kept for a long period of time. This helps responder teams understand how initial access was gained and ensure complete threat actor eviction from the environment.

Complex identity systems

Modern identity systems are complex and have changed significantly as ways of working have evolved. Organizations can have multiple identity providers, third-party MFA providers, custom systems designed for user onboarding and offboarding, and other interconnected systems. All these systems form an end-to-end trust chain that is an attractive target for threat actors. The more complex these systems are, the more difficult it is to adequately secure them. Organizations may have network appliances that complete 802.1x authentication, custom identity governance systems that manage user lifecycle, certificate authorities and HSM devices. Each system requires patching and vulnerability management, sufficient monitoring and maintenance and human expertise to ensure secure configuration. Additionally, certificate and credential management across these systems add further complexity.

For example, AD FS is trusted to issue tokens for users. Other systems, such as Microsoft Entra ID, accept those tokens and then authorize the users they represent. If AD FS is compromised, then the legitimacy of those tokens is in question. Each system needs to be adequately secured and monitored to ensure complete trust, as a compromise of a single system could lead to compromise of them all.

If a user signs into Microsoft 365 and the authentication is via a non-Microsoft identity provider, and then MFA is provided by yet another provider, significant complexity is added to the authentication flow. For instance, different systems may be responsible for validating passwords, checking certificates, performing MFA, and issuing tokens – these may be on-premises systems, non-Windows platforms, or third-party cloud solutions. In these situations, each system that forms part of this authentication flow trusts the others.

For example, Microsoft IR was recently engaged with an organization that suffered tenant-level compromise of Microsoft Entra ID. Once the investigation was complete, it was determined that an internet-facing on-premises server, which lacked MFA or proper access controls, had been compromised. That server ran a custom piece of software designed to sync users between multiple business systems. Once the threat actor gained access to the server, they uncovered the credentials for a Global Administrator-level service account. Servers that host key identity applications and integration services are often not held to the same security standard as Domain Controllers, decreasing the security posture of the entire identity plane significantly.

Misconfiguration or administrative oversight on any one of these interconnected systems leads to a decrease in overall security controls. If Microsoft Entra ID is configured to offload MFA to a third-party MFA provider and that MFA is misconfigured, Microsoft Entra ID will still trust the telemetry and configuration of that service.

Recommendations

• It’s crucial to understand all the systems that form your identity plane and how authentication and authorization flow between them. Understand which systems are responsible for which workloads within your identity trust chain.
• Treat the entire authentication system as tier 0, as compromise of a single link within it can lead to complete compromise.
• Ensure that all systems are configured in line with best practices and that the collective configuration is enforcing implemented policies as expected.
• For all systems forming your identity plane, ensure that sufficient logging is available, and that data is kept for a long period of time, preferably 2 years or more. Logging should include user logon events, administrative activity, and configuration changes. Having sufficient logging not only helps detect potential cyberattacks, but it can also alert on changes to any individual system that can reduce overall security posture, and, in the event of an incident, serve as a source of forensic information.
• Where possible, simplify the authentication and authorization mechanisms in your environment. This helps to reduce the attack surface of identity compromise. With each additional system, you increase the overhead of securing those systems and increase the chance of misconfiguration or compromise of one of them.

Compromised synced service accounts

In the hybrid identity world, most users and groups are synced from on-premises Active Directory to Microsoft Entra ID. This is required to allow users to access cloud resources via the same set of credentials used on premises. However, in engagements seen by Microsoft IR, accounts used to manage Microsoft Entra ID, such as Global Administrators, have also been synced to Microsoft Entra ID from on-premises. Staff then often use the same credentials to manage both environments.

If Active Directory is compromised and the credentials for these accounts are found by a threat actor, this allows them to easily pivot into Microsoft Entra ID, expanding the scope of the compromise. Synced service accounts are particularly vulnerable to exploitation. Microsoft IR commonly sees service accounts used to manage both on-premises Active Directory and Microsoft Entra ID targeted by threat actors. These accounts generally hold a high level of privilege in Microsoft Entra ID (often Global Administrator) but aren’t subject to the same controls such as MFA or Microsoft Entra Privileged Identity Management (PIM).

Microsoft IR has been involved in numerous investigations where on-premises Active Directory compromise led to Microsoft Entra tenant compromise. Threat actors sometimes uncover account credentials in clear text due to poor handling of credentials in an on-premises environment. If the threat actor already has a foothold in the on-premises environment, controls such as MFA are often not enforced as these networks are seen as ‘trusted’.

Recommendations

• Microsoft IR strongly recommends that accounts used to administer Microsoft Entra ID are native to Microsoft Entra ID using managed authentication and are not synced from on-premises Active Directory. This reduces the scope of compromise if Active Directory gets compromised by preventing a threat actor from leveraging the same credentials to compromise Microsoft Entra ID. Specific guidance to protect Microsoft 365 from on-premises cyberattacks can be found at https://aka.ms/protectm365 and https://aka.ms/securitysteps.
• Any account that holds privilege in on-premises Active Directory, such as Domain Administrators and the respective groups such as Domain Admins, should be completely excluded from being synced to Microsoft Entra ID.
• The credentials for service accounts that interact with Microsoft Entra ID and Active Directory should be stored securely, and not in clear text where they are easily recoverable by a threat actor.
• Privileged accounts should not be excluded from Microsoft Entra Conditional Access policies, regardless of network location. These accounts should always be held to the highest standards of security, specifically the use of Privileged Identity Management and phishing-resistant credentials such as FIDO2, including for break glass accounts.
• Service accounts that require both privileges to on-premises Active Directory and Microsoft Entra ID should have specific technical controls applied to them. This can include Conditional Access blocking access from non-approved locations or IP addresses, specific detection rules, and monitoring to alert on anomalous activity with these accounts.

Token theft of highly privileged accounts

Token theft is an increasingly common tactic used by threat actors. This technique can allow threat actors to access even MFA-protected resources. Token theft utilizes either credential stealing malware, to steal tokens from end user devices, or adversary-in-the-middle (AiTM) infrastructure to steal tokens during authentication.

AiTM attacks are targeted at users through phishing campaigns. Users are tricked to not only enter their user credentials to a malicious site, but the malicious site also steals the tokens associated with the sign in. These tokens have already satisfied MFA and can be reused by the adversary. This token is then imported to a threat actor-controlled device and access to MFA protected resources granted. Microsoft IR has previously written on the increase of token theft attacks.

Microsoft IR has seen cases where Global Administrator accounts were directly targeted by AiTM phishing. As result, a Global Administrator tier token was stolen, leading to tenant-level compromise.

In addition to AiTM phishing, tokens can also be stolen from endpoint devices themselves via credential-stealing malware. Microsoft IR has been engaged with organizations where credential-stealing malware was installed on an administrator’s endpoint device via an initial phishing email. While the admin used separate accounts for their day-to-day and administrative work, the Global Administrator had signed into both accounts from the same device. The malware had the capability to extract all the credentials and tokens on the device, eventually leading to tenant-level compromise.

Tokens on endpoints are typically stored as cookies, and theft can occur in several ways. Commodity malware such as Emotet, Redline, IcedID, and others have the capability to steal both credentials and tokens. Pirated or cracked software often has token and cookie stealing malware embedded within it as well.

Recommendations

• To increase the security of these accounts, phishing-resistant MFA methods such as FIDO2 keys and certificate-based authentication should be used. Authentication strengths can be used to enforce these MFA methods for the highest privileged accounts. Authentication strengths can prevent admins using weaker MFA methods, such as SMS or phone calls.
• To remove the attack vector of direct phishing attempts, users that hold privilege in Microsoft Entra ID should not have a mailbox assigned.
• When accessing Microsoft Entra ID to complete administrative tasks, access should be granted via a native Microsoft Entra account, not one synced from on-premises Active Directory.
• Access to the Microsoft Entra ID Portal and other similar management interfaces should also be restricted to only hardened workstations known as privileged access workstations. These workstations are designed to only administer Microsoft Entra ID and restricted from accessing other sites to reduce the attack surface of endpoint compromise.
• Microsoft has published a specific incident response playbook for cloud token theft. It is worth familiarizing yourself with to understand how to respond quickly.
• To prevent token theft more broadly, token protection (also known as token binding more generally) is currently in preview in Microsoft Entra Conditional Access. As a preview feature, it has certain limitations; however, it is still a valuable control. Token protection seeks to prevent replay of primary refresh token theft by binding an issued token to a specific device.

Excessive privilege granted to users

Much like on-premises Active Directory, Microsoft IR often sees accounts granted privilege that they do not require. While organizations often have mature technical controls over their Global Administrator accounts, these controls do not cover other privileged roles in Microsoft Entra ID. Global Administrator lives atop the privilege hierarchy, but there are also other roles that can lead to compromise. These include, but are not limited to:

• Privileged Role Administrator – can add users to Global Administrator and other privileged roles
• Privileged Authentication Administrator – can reset the password of or register MFA for a Global Administrator
• Security Administrator – can read and manage security related settings across Microsoft Entra ID and Microsoft 365 Defender
• Application Administrator – can generate a credential on any Microsoft Entra ID application
• Domain Name Administrator – can add a federated domain
• Conditional Access Administrator – can degrade access conditions
• Intune Administrator – can manage all aspects of Intune, including deploying software and remote wiping devices

These roles, along with others, are now flagged as privileged in the Microsoft Learn documentation, allowing organizations to focus on securing users that hold those roles. In many of our engagements, Global Administrators are not directly compromised. A user holding another privileged role is often initially targeted, and from there, the threat actor could escalate up to Global Administrator. In one instance, a service desk staff member who held the Privileged Authentication Administrator role was socially engineered into updating the MFA details for a Global Administrator. Once this had occurred, the threat actor completed self-service password reset for the Global Administrator account and then took control of the tenant.

Recommendations

• Microsoft IR recommends that organizations audit current role assignments to ensure privileged users are granted only the access required– enforcing least privilege to organizational resources. Roles that Microsoft considers privileged are now highlighted in the documentation, and in the Microsoft Entra portal itself – highlighting the importance of managing users in these roles.
• Ensure that all roles that could lead to tenant-level compromise are protected, not just Global Administrator. Changes to these roles should generate a high-priority alert to be investigated to confirm the activities are not malicious.
• AzureHound, the cloud sibling of BloodHound, can be used to visually map attack paths through Microsoft Entra ID. It is recommended that sanctioned audits using this tool are run and attack paths are removed or mitigated.
• Microsoft Entra PIM can provide further protection to these roles by ensuring users have just-in-time access to their roles and requesting that access is governed by additional workflows.

Excessive privilege granted to workload identities

A workload identity is a non-human identity created and assigned to a workload (such as a script, application, or other services) to allow them to authenticate and access other resources. For example, you may create a workload identity to provide custom integration between Microsoft Teams and Exchange Online. In Microsoft Entra ID, these are known as applications and service principals. Like users, these applications and service principals can be assigned to roles, such as Global Administrator, or provided specific access to API endpoints. Credentials like secrets or certificates are generated for the workload identity, and then used to authenticate.

Like service accounts in on-premises Active Directory, these workload identities are often granted much higher privileges than required, for example:

• Directory.ReadWrite.All – Allows the app to read and write data in your organization’s directory, such as users, and groups
• User.ReadWrite.All – Allows the app to read and write the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user
• Mail.ReadWrite – Allows the app to create, read, update, and delete mail in all mailboxes without a signed-in user

Even though the applications ask for and are subsequently granted access to these broad privileges, usually the applications require much less access to function correctly. For instance, they may need access to a specific mailbox, not all mailboxes. Microsoft has published specific guidance to understand appropriate permission scoping in Microsoft Entra ID.

These service principals and applications are often not secured to the same level as standard user accounts. Part of that is the nature of how they work: it is not possible to configure MFA for these applications, as they are non-human identities. Additionally, where a user may notice strange behavior on their account and provide feedback to security teams, there is no equivalent feedback for applications. Often, malicious activity from workload identities goes unnoticed because detection logic is focused on user identities.

Recommendations

• Applications and service principals should be granted access using the least-privilege principle. Often internal development teams or external third-party vendors request privileges over and above what are required because they make it easier for the service to work. However, this presents a significant risk and should be avoided.
• Microsoft recommends the use of strong credentials, such as certificates, for applications, instead of client secrets. Microsoft IR often finds client secrets held in clear text in emails or saved in easy to find locations. If the application is interacting with Microsoft Azure or other Microsoft services, then the use of Entra ID Managed Identities is recommended. Managed Identities eliminate the need for organizations to manage the credentials for these workloads.
• If providing access to the Microsoft Graph, exceptionally granular permissions are available for the various endpoints. Security teams should challenge requests for high privileges across Microsoft Graph. The permissions reference page lists the name of the permission and what access is provided if that permission is granted.
• For security teams and administrators that are familiar with Active Directory and less so with Microsoft Entra ID, it’s worth understanding how the permissions structure in Microsoft Entra ID and Microsoft Graph works. That way you are better informed to challenge requests for excessive privilege.
• Conditional Access for workload identities is available as a feature in Microsoft Entra Workload ID. As previously mentioned, due to the nature of these identities, MFA and similar controls cannot be enforced. With Conditional Access, however, you can allow access from specific IP locations or block access based on elevated risk patterns detected by Microsoft.
• Alerts should be configured to detect new credentials, additional privileges being added to existing applications, and anomalous sign-in activity. Much like users, service principals generate log in data and detections for new IP addresses or locations should be created. Threat actors have been known to compromise accounts with access to generate new credentials on pre-existing applications with high privilege, thereby allowing tenant takeover.

Poor device access control

In many engagements, Microsoft IR has detected threat actors registering their own devices to the Microsoft Entra tenant, giving them a platform to escalate the cyberattack. While simply joining a device to a Microsoft Entra tenant may present limited immediate risk, it could allow a threat actor to establish a foothold in the environment. Conditional Access or Microsoft Intune policy misconfiguration may allow this threat actor-controlled device to be marked as compliant. The threat actor could then access additional and potentially sensitive company resources. From there, they might be able to locate additional credentials or compromise further users to escalate privilege within the environment.

Microsoft IR was recently engaged with an organization that allowed users to join their own devices to Microsoft Entra ID. Threat actors compromised a regular user account via phishing and then used the compromised credentials to join their own device to the tenant. The actors then leveraged a misconfiguration in Intune to allow that device to be marked as compliant. From there, the threat actor was able to satisfy Conditional Access and access Microsoft 365, where they located the credentials of a privileged account sent via email.

Recommendations

• If you allow end users to register or join their own devices to your Microsoft Entra tenant, then Microsoft IR recommends you control the ability to complete those actions via Conditional Access.
• Using Conditional Access, you can add additional security to your tenant by creating policies to require MFA when joining or registering a device. Depending on the requirements of your business, you could enforce the MFA requirement to particular users, or locations such as untrusted locations. Microsoft IR recommends, however, requiring MFA for all device join events where possible.

• Auditing and alerting should be configured for device joining events to detect anomalous behavior such as users registering multiple devices, suspicious device names, or unusual times. Users themselves can be sent notifications via Intune each time a device is enrolled via their account; if they didn’t initiate the action, they can report it as suspicious.
• Hold members of the Intune Administrator role to the same security standard as more well known privileged roles, such as Global Administrator

Poor application access control

When analyzing customer tenants, Microsoft IR often finds that their lines of business applications do not have sufficient access controls applied to them. Applications such as IT service management and ticketing systems, code repos, HR systems, and more are available to any user, including guest accounts. Microsoft IR was recently engaged with an organization where the threat actor compromised a user by phishing. Once the actor had control over the account, they accessed the MyApps portal and began systematically accessing all the applications listed there. Eventually, they signed into the IT system used for onboarding and offboarding accounts and requested a new privileged account, despite having no reason to have access to that system. A new account was provisioned, giving the actor a privileged account under their control.

Microsoft IR often detects threat actors browsing the https://myapps.microsoft.com portal and trying to access all the applications visible there. Often the compromised user account has no business justification to access these applications, but access is granted to groups containing all user accounts or have no access control at all. These applications may have confidential data, contain unsecured credentials, or could allow threat actors to gain insights into business processes to facilitate social engineering.

Recommendations

Access to all business applications should be restricted to only those that require it. Microsoft Entra ID provides the capability to both restrict access to applications, and to hide the visibility of applications in the MyApps portal. Access to applications should always be governed by a security group, so that users are granted only the access required to work. To ensure that users can still access applications they require, self-service capability for requesting access is available in Microsoft Entra ID. Requests for access can be delegated to application owners, so that IT teams don’t need to fulfill every request.

Access reviews and entitlement management capabilities in Entra ID can help organizations management the on going governance of access and entitlement lifecycle at scale. These tools work together to allow users to gain access to the applications and data they need easily and give security teams the tools to ensure access is granted on as needed basis.

Misconfigured delegated administrative privileges (DAP) permissions

The DAP permissions model was created to allow Cloud Solution Providers (CSP) to provide services and licensing support to customers. A CSP could send an invitation to a customer to request a partner relationship. Prior to an update to the permissions model, upon accepting one of these invitations, the CSP would gain Global Administrator rights in the customer tenant.

In addition, customers themselves could not manage which users held privilege in their tenant. Membership in ‘AdminAgents’ group in the CSP tenant would provide downstream privilege to any customer tenants configured. These permissions are often a relic of previous partners or historical licensing agreements and the CSP may no longer be actively engaged with the customer.

CSP tenants have become an attractive threat actor target, as compromise of a single tenant can provide administrative access to any number of downstream tenants. Microsoft IR has been engaged in several incidents with organizations that have lost control of their tenant via a delegated administrative privilege configuration they were unaware existed. The threat actor compromised an account located in the AdminAgents group in the partner tenant via phishing. They then used the downstream privilege to create a Global Administrator account in our customer’s tenant and take control. Both the partner and the customer were unaware this relationship existed.

Recommendations

• Review the list of delegated administrative privileges in your tenant to understand if any such partnerships exist. If any are configured, assess if your business still requires your partner to retain privilege in your tenant.
• If they do require privilege, Microsoft recommends migrating to granular delegated admin privileges (GDAP). This updated permission model better aligns with Zero Trust principle of least privilege access and hands more control back into the hands of the customers themselves.
• Depending on the nature of the partner relationship, it may be possible to remove the delegated partner configuration entirely, and instead on-board accounts native to your tenant and securely provide the credentials to any resource that requires access to your tenant.

Misconfigured Conditional Access policy

It is common for Microsoft IR to find gaps in Conditional Access policies, particularly policies covering the most privileged accounts. It’s important to understand that threat actors can enumerate Conditional Access policies using a regular user account. By enumerating Conditional Access policies, threat actors can find those gaps and attempt to move laterally through them. For example, if MFA is excluded for users in a particular group or from specific locations, then a threat actor will attempt to add themselves to that group or compromise an account already excluded.

Furthermore, corporate networks are often excluded from MFA entirely and considered ‘trusted’ locations. This configuration and mindset are representative of the way of work from years ago, where being on the corporate network granted users and devices implicit trust. If a threat actor can find a way onto that network by compromising a device already connected to the network or gaining access via VPN, then at that point, they are considered ‘trusted’ and are unlikely to be further prompted for strong authentication.

Additionally, Microsoft IR regularly sees organizations that have configured their Conditional Access policies in a way that is overly complicated. While these policies are often created with the right intentions, as the policies add up, it becomes hard to tell which are enforced. The combination of these policies can give users a poor experience. This can make them susceptible to cyberattacks like MFA fatigue/spam. If users are being prompted dozens of times a day for MFA or being signed out of their session every few hours, they are going to pay less attention to a prompt for their credentials or an MFA prompt on their phone. As a result, when a threat actor-generated MFA prompt is sent to them, they might be less likely to consider it suspicious and report it as fraudulent.

Recommendations

• There are often legitimate business reasons why exclusions to Conditional Access need to apply; however, it is key that your privileged and Tier 0 accounts continue to be secured correctly.
• Alerts should be configured for any changes, additions, or deletions to Conditional Access. This will help detect both accidental and malicious changes to your policies.
• Any groups that are configured as exclusion groups for policies should be monitored for changes. Privileged users can be excluded from key policies by being placed into a group that then excludes them from policies. Microsoft Entra ID Access Reviews can be used to ensure continued governance of the members of these groups.
• Microsoft IR recommends enforcing strong authentication for users regardless of location, even if connecting via a corporate network, starting with your most privileged accounts. This is a key component of Zero Trust security principles, where we verify users and devices explicitly, regardless of location.
• It is worth periodically reviewing Conditional Access policies to ensure they are enforcing the expected controls. To help with this, you can simulate sign-in events with the ‘What If’ tool. Often multiple policies can be rolled into one. This provides better and more consistent user experience, and even just simplifying policy design can lead to improved security. There is also built in insights and reporting into Conditional Access, to help both identity and address gaps in policy.

It’s important to note that Zero Trust does not mean users should be prompted for MFA each time they access a resource. Modern strong authentication methods such as Windows Hello for Business provide the best combination of security and useability.

OAuth and consent phishing

Consent phishing expands on traditional phishing by tricking users into installing malicious OAuth applications rather than tricking them into providing their credentials. With consent phishing, users are tricked into providing threat actors with direct access to their personal or organizational data. The user may be presented with a link in an email that when clicked requests that the user consent to an application. The consent page will show the permissions requested by the application, and if the user has the right to consent, the application, and in turn the threat actor, is granted access to the data. These applications may be named in a way that appears that they are legitimate to users.

These kinds of cyberattacks are of particular concern if administrative accounts are targeted. If a privileged user is targeted by consent phishing, they may have the ability to consent to organization-wide permissions, granting the threat actor broad access into your tenant.

When standard users are targeted by consent phishing, the permissions requested can be considered low impact, but this type of cyberattack can provide a means for a threat actor to harvest information and data that can lead to higher impact. For example, if a user clicks and consents to a malicious application that provides access to only their email and OneDrive, that may be considered a minor incident. With that access though, the threat actor could enumerate all the corporate data that the user can access. That user may have access to sensitive credentials, personally identifiable information, or market sensitive information, which the threat actor can locate.

Microsoft, often with the help of security researchers and the security community, disables known malicious OAuth applications. At the same time, it’s important to protect yourself from these kinds of cyberattacks.

Recommendations

• Microsoft Entra ID provides strong and granular controls to protect your organization from consent phishing and other malicious application consent. These settings are configured in the Microsoft Entra portal. Microsoft IR recommends that the first or second option be selected. If your organization has the capability to respond effectively to all requests for application consent, then the first option, ‘Do not allow user consent’, is the most secure.

• Many organizations do not have the resources available to manage every request; in these cases, the second option provides the best mix of security and user experience. Staff can consent to applications that are from verified publishers or those considered to have a low impact in terms of permissions requested.
• Microsoft Defender for Cloud Apps can be utilized to investigate and remediate risky OAuth apps.
• As previously mentioned, privileged users should not have mailboxes assigned to them. This reduces the attack vector of traditional and consent phishing being targeted towards them.

Self-service password reset & MFA social engineering

Microsoft IR has seen cases of threat actors leveraging social engineering techniques to have service desk or similar staff update the self-service password reset (SSPR) and MFA details for users.

Microsoft IR commonly sees service desk staff being targeted via social engineering tactics. Often, a threat actor impersonates a user by creating an outlook.com or gmail.com mailbox with the same name as the legitimate user. They then send an email to the service desk and say that they have a new email address or phone number and ask the service desk to update their MFA details. Once this is completed, the threat actor could initiate self-service password reset and take over control of the account. With this initial foothold to the environment, they could pivot into Microsoft 365 and attempt to escalate privilege. Microsoft IR has seen these attempts target Global Administrator accounts directly as well as regular users.

Certain threat actors may even call the service desk and impersonate the user, taking information from sites such as LinkedIn, other information acquired from open-source intelligence (OSINT), or personal data lost in other breaches to successfully pass any identity validation required. The service desk then resets the password on the user account, or updates an MFA method, granting access to the attacker.

On top of being an initial access vector, this can also be a persistence mechanism deployed by threat actors to regain control over an already compromised account. If a user is detected as compromised and their credentials reset, the threat actor can again complete the SSPR workflow to regain access to that account.

Recommendations

• While SSPR is the preferred method of credential reset and is more secure than other methods, such as emailing credentials in clear text, it could still be susceptible to social engineering. Business processes should attempt to reduce the risk of these attempts succeeding. Importantly, empower your service desk staff to say no, or require additional validation, when something seems suspicious.
• Requests for updates to SSPR and MFA details should be validated to confirm they are legitimate, such as by challenging the user via the phone or having them confirm other details a threat actor would not have (e.g., employee ID numbers). Additionally, visual confirmation, via video calling, that the user is who they say they are can be a strong control.
• MFA registration can be further secured through the use of Temporary Access Passes (TAP). A TAP is a time-limited passcode that can be generated for users. More mature organizations have begun using these to protect the MFA registration process. A user will call the helpdesk and verify their identity. They are then granted a TAP which allows them access to the MFA registration portal for a short period of time, allowing them to then register their own MFA device.
• Ensure that IT admin staff that have the privilege to update passwords or MFA details for other privileged users are held to high security standards, such as phishing resistant MFA.
• Detections should be created for potential social engineering attempts for SSPR and MFA. These could include detections such as an update to SSPR details followed by risky sign-ins. A threat actor that takes control over an account will likely then attempt to sign into it, and if it is from a different location or has other unfamiliar features, it may trigger additional risk.

Recommended focus areas to prevent identity compromise

In real-world engagements, Microsoft IR sees combinations of the above issues and misconfigurations that could lead to total Microsoft Entra ID compromise. Depending on the motivation of the threat actor, this could further lead to additional malicious attacks, or even tenant destruction.

In the above cyberattack chain, a regular user was compromised through phishing. Through additional weak controls, poor credential hygiene, and lack of additional security over Tier 0, the entire tenant was compromised.

Compared to Active Directory, cyberattacks on Microsoft Entra ID are relatively new, and additional new attacks are constantly emerging. Microsoft IR recommends focusing on controls that will prevent your most privileged accounts being compromised. Focusing on protecting and hardening identities with the highest privilege makes the biggest impact in preventing identity compromise.

• Reduce privilege – All user and non-human identities should be assigned access according to the principle of least privilege. This will help prevent single user compromise leading to tenant-level compromise.
• Protect Tier 0 – All Global Administrator accounts, equivalent service principals, and accounts with additional paths to Tier 0 should be held to stricter security controls, including phishing-resistant MFA.
• Use cloud-only administrative accounts – All accounts that have privilege in Microsoft Entra ID should be cloud-native and not synced from Active Directory.
• Protect hybrid identity – In instances of complex hybrid identity, ensure that all interconnected systems such as AD FS or third-party MFA are configured and monitored properly.
• Accelerate your passwordless journey to reduce the risk of credential theft by phishing and other password-based attacks.

Much like on-premises Active Directory, protecting Microsoft Entra ID requires continued governance and monitoring. By reducing risk and controlling our most privileged accounts, you have the best chance of preventing or detecting attempts at tenant-wide compromise.

Matthew Zorich (@reprise_99 on X), Microsoft Incident Response

Listen to Matt discuss the importance of knowledge sharing and practical experimentation in incident response in the Microsoft Threat Intelligence Podcast episode, Incident Response with Empathy.

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 X (formerly Twitter) at https://twitter.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.

The post Microsoft Incident Response lessons on preventing cloud identity compromise appeared first on Microsoft Security Blog.

Highly privileged users at risk

Credential-based cyberattacks often begin with cyberthreat actors targeting individuals who they believe are connected to the people who have the credentials they need. Then they conduct social and dark web reconnaissance to find and wind their way to highly privileged users and gain enough information to impersonate them. In the past, cyberthreat actors have even been known to impersonate and masquerade as staff, including chief information security officers (CISOs) and other incident response firms. Cybercriminals use trust, context, and emotion to trick people with smishing links. At that point, they don’t need to hack, they just log in. Many smishing and social engineering attacks employ a rush of push notifications that can overwhelm or confuse a target, causing multifactor authentication fatigue. Researchers believe the onslaught of notifications is causing us to get tired faster and lose focus, leaving us especially prone to distraction as the day wears on.¹ All the pings, clicks, swipes, buzzes, texts, and taps can weigh on a target, causing them to believe an access attempt is legitimate. And cyberthreat actors don’t let up. By the end of June 2023, we observed approximately 6,000 multifactor authentication fatigue attempts—per day—every day.²

Untangling the tentacles of a cyberattack

In the case of threat actor Octo Tempest, once they gained access, they began wrapping their tentacles around valuable assets and collecting additional credentials by using third-party credential-harvesting tools against cloud and on-premises assets. They searched through the customer’s SharePoint and email system for sensitive information about IT processes and VPN architecture. Then they modified the normal authentication flow, which allowed them to authenticate as any user in the organization, without requiring their credentials.

In this report, we examine the factors contributing to the cyberthreat actor’s initial incursion and explore what could have happened without prompt tactical mitigation efforts. We walk through mitigation efforts step by step. Then we examine Octo Tempest’s tactics, techniques, and procedures (TTPs) to understand the extent of the compromise and how we were able to help the customer evict the cyberthreat actor completely. We’ll also explore how organizations can educate employees to reduce the chance of social engineering attacks, and share five proactive elements of a Zero Trust approach that can protect against highly motivated, tenacious cyberthreat actors like Octo Tempest.

Preventing cyberattacks

Many cyberattacks can be prevented—or at least made more difficult to execute—through the implementation and maintenance of basic security controls. Organizations can strengthen their cybersecurity defenses and better protect against cyberattacks by understanding in-depth the tentacles of a far-reaching credential breach like this one. Microsoft Incident Response can provide expert guidance to customers when an attack becomes too complex and challenging to mitigate alone—and before an attack happens—to develop a comprehensive incident response plan and ensure security personnel are trained to recognize and respond to social engineering attacks. With Microsoft’s intelligence-driven incident response, customers can access the help they need on a global scale with global incident response, all day, every day—both on-site and remotely. The proactive and reactive incident response services let customers take advantage of the depth and breadth of Microsoft Threat Intelligence and gain unique access to product engineering. It also means customers can benefit from the longstanding Microsoft partnerships with government agencies and global security organizations for the latest, most comprehensive intelligence available. Read the report to learn more about the cyberattack, including the response activity, and lessons that other organizations can learn to avoid being caught in the tentacles of a social engineering compromise.

What is the Cyberattack Series?

With this Cyberattack Series, customers will discover how Microsoft incident responders investigate unique and notable exploits. For each cyberattack story, we will share:

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

Read the first blog in the Cyberattack Series, Solving one of NOBELIUM’s most novel attacks.

Microsoft Incident Response

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

Explore services

Learn more

To learn more about Microsoft Incident Response, visit our website or reach out to your Microsoft account manager or Premier Support contact. 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.

¹Phone Notifications Are Messing With Your Brain, Discover Magazine. April 29, 2022.

²Microsoft Digital Defense Report 2023

The post Protecting credentials against social engineering: Cyberattack Series appeared first on Microsoft Security Blog.