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.

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.

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.

Together, we work with the company to help remediate and update business processes and systems to better prevent or detect. We collectively share our world-class threat intelligence and knowledge between Microsoft and PwC to help solve wide-ranging and complex problems that arise during and after a breach.

“This type of industry collaboration is key to addressing the volume, complexity, and severity of breaches we see today. It will take all of us working together to stop nation-actors from attacking organizations and governments around the world,” said Kelly Bissell, Corporate Vice President, Microsoft Security Solutions. “For example, Microsoft security researchers have seen a 130.4 percent increase in organizations that have encountered ransomware over the last year. Microsoft Threat Intelligence is tracking more than 300 unique threat actors, including 160 nation-state actors, 50 ransomware groups, and hundreds of others.¹”

PwC and Microsoft formed this collaboration because they both have a long history of helping customers with incident response globally, offering both remote and boots-on-the-ground support. By combining our forces, we bring distinct areas of specialty to a broader range of customers.

How Microsoft Incident Response and PwC collaborate

When a customer experiences a crisis and engages Microsoft Incident Response and PwC, both teams can immediately mobilize. We typically start helping the customer remotely straight away and, when needed, can have people in their offices within 24 to 48 hours, parlaying their large global footprint so we can be at wherever the issue is quicker.

The Incident Response team focuses on evicting the bad actor, determining root cause analysis, and getting the customer’s core technology back up and running. Our extensive relationships with government agencies and organizations around the world can help stop the damage and bring criminals to justice. We can help find the bad guys so customers can start their recovery journey.

Meanwhile, PwC focuses on the broader incident response, like executing contingency plans—or helping companies navigate through the situation quicker, updating business processes, and identifying control failures to design a prioritized and measurable recovery strategy. They can work closely with C-suite and the board of directors to help address their needs. For example, the chief financial officer should understand the cost implications due to fines or fees. The legal counsel should engage the right law firm to help during the response and recovery. And the board and public relations team should figure out the appropriate thing to say to the media and customers. PwC can stay with customers to provide guidance throughout this very abridged sample recovery journey with the goal of helping the company emerge stronger.

Why Microsoft Incident Response and PwC are better together

“Time is often the enemy in any breach. The incident response collaboration between Microsoft and PwC means our customers have a team that can help support them from discovery through recovery. With a global footprint and history of recovery, remediation, and transformation experience, we can assist customers with the speed, agility and broad knowledge needed to provide a level of confidence and professional services during a potentially chaotic period,” said Sean Joyce, Global Cybersecurity and Privacy Leader, PwC.

The collective lessons learned from Microsoft and PwC’s incident response collaboration are interwoven into the fabric of how Microsoft’s solutions operate and how the two companies’ teams can help customers contain, isolate, eradicate, and emerge from an incident. This collaboration is better together because it combines the strength of both organizations: Microsoft’s deep understanding of technology and PwC’s industry-leading knowledge in business and risk management.

Here are some specific examples of how the collaboration can benefit customers:

• Faster and more effective response: When a customer experiences a security incident, Microsoft and PwC can mobilize a team of specialists to help contain the cyberthreat, investigate the root cause, and get the client’s systems back up and running quickly. The two companies’ combined knowledge allows them to respond to incidents quicker and more effectively than either company could on its own.
• More holistic response: The collaboration also allows Microsoft and PwC to provide a more holistic response to incidents. Microsoft can focus on the technical aspects of the incident, such as evicting the bad actor and restoring systems, while PwC can focus on the business and risk management aspects, such as developing a recovery plan and communicating with stakeholders. This holistic approach can help customers decrease the impact of incidents and recover quicker.
• Improved security posture: The lessons learned from incident response engagements are used to improve Microsoft’s solutions and the security posture of its customers. Microsoft and PwC work together to help identify and mitigate common security vulnerabilities and to develop new security solutions. This can help clients to reduce their risk of future incidents.

That’s why it’s so important to have a team of professionals in place who can help you respond faster and more effectively to cybersecurity incidents. The Microsoft and PwC incident response collaboration can be an asset for customers when they are experiencing a breach within their organization. To connect with PwC and learn more about this collaboration, register for our webinar in December 2023 called “5 things you (probably) don’t know about incident response.”

Microsoft Incident Response

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

Learn more

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 X (formerly known as “Twitter”) (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2023 .

The post An integrated incident response solution with Microsoft and PwC appeared first on Microsoft Security Blog.

Octo Tempest is a financially motivated collective of native English-speaking threat actors known for launching wide-ranging campaigns that prominently feature adversary-in-the-middle (AiTM) techniques, social engineering, and SIM swapping capabilities. Octo Tempest, which overlaps with research associated with 0ktapus, Scattered Spider, and UNC3944, was initially seen in early 2022, targeting mobile telecommunications and business process outsourcing organizations to initiate phone number ports (also known as SIM swaps). Octo Tempest monetized their intrusions in 2022 by selling SIM swaps to other criminals and performing account takeovers of high-net-worth individuals to steal their cryptocurrency.

Building on their initial success, Octo Tempest harnessed their experience and acquired data to progressively advance their motives, targeting, and techniques, adopting an increasingly aggressive approach. In late 2022 to early 2023, Octo Tempest expanded their targeting to include cable telecommunications, email, and technology organizations. During this period, Octo Tempest started monetizing intrusions by extorting victim organizations for data stolen during their intrusion operations and in some cases even resorting to physical threats.

In mid-2023, Octo Tempest became an affiliate of ALPHV/BlackCat, a human-operated ransomware as a service (RaaS) operation, and initial victims were extorted for data theft (with no ransomware deployment) using ALPHV Collections leak site. This is notable in that, historically, Eastern European ransomware groups refused to do business with native English-speaking criminals. By June 2023, Octo Tempest started deploying ALPHV/BlackCat ransomware payloads (both Windows and Linux versions) to victims and lately has focused their deployments primarily on VMWare ESXi servers. Octo Tempest progressively broadened the scope of industries targeted for extortion, including natural resources, gaming, hospitality, consumer products, retail, managed service providers, manufacturing, law, technology, and financial services.  

In recent campaigns, we observed Octo Tempest leverage a diverse array of TTPs to navigate complex hybrid environments, exfiltrate sensitive data, and encrypt data. Octo Tempest leverages tradecraft that many organizations don’t have in their typical threat models, such as SMS phishing, SIM swapping, and advanced social engineering techniques. This blog post aims to provide organizations with an insight into Octo Tempest’s tradecraft by detailing the fluidity of their operations and to offer organizations defensive mechanisms to thwart the highly motivated financial cybercriminal group.

Analysis 

The well-organized, prolific nature of Octo Tempest’s attacks is indicative of extensive technical depth and multiple hands-on-keyboard operators. The succeeding sections cover the wide range of TTPs we observed being used by Octo Tempest.

Initial access 

Social engineering with a twist

Octo Tempest commonly launches social engineering attacks targeting technical administrators, such as support and help desk personnel, who have permissions that could enable the threat actor to gain initial access to accounts. The threat actor performs research on the organization and identifies targets to effectively impersonate victims, mimicking idiolect on phone calls and understanding personal identifiable information to trick technical administrators into performing password resets and resetting multifactor authentication (MFA) methods. Octo Tempest has also been observed impersonating newly hired employees in these attempts to blend into normal on-hire processes.

Octo Tempest primarily gains initial access to an organization using one of several methods:

• Social engineering
  • Calling an employee and socially engineering the user to either:
    • Install a Remote Monitoring and Management (RMM) utility
    • Navigate to a site configured with a fake login portal using an adversary-in-the-middle toolkit
    • Remove their FIDO2 token
  • Calling an organization’s help desk and socially engineering the help desk to reset the user’s password and/or change/add a multi-factor authentication token/factor
• Purchasing an employee’s credentials and/or session token(s) on a criminal underground market
• SMS phishing employee phone numbers with a link to a site configured with a fake login portal using an adversary-in-the-middle toolkit
• Using the employee’s pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.

In rare instances, Octo Tempest resorts to fear-mongering tactics, targeting specific individuals through phone calls and texts. These actors use personal information, such as home addresses and family names, along with physical threats to coerce victims into sharing credentials for corporate access.

Reconnaissance and discovery 

Crossing borders for identity, architecture, and controls enumeration

In the early stage of their attacks, Octo Tempest performs various enumeration and information gathering actions to pursue advanced access in targeted environments and abuses legitimate channels for follow-on actions later in the attack sequence. Initial bulk-export of users, groups, and device information is closely followed by enumerating data and resources readily available to the user’s profile within virtual desktop infrastructure or enterprise-hosted resources. 

Frequently, Octo Tempest uses their access to carry out broad searches across knowledge repositories to identify documents related to network architecture, employee onboarding, remote access methods, password policies, and credential vaults.

Octo Tempest then performs exploration through multi-cloud environments enumerating access and resources across cloud environments, code repositories, server and backup management infrastructure, and others. In this stage, the threat actor validates access, enumerates databases and storage containers, and plans footholds to aid further phases of the attack.

Additional tradecraft and techniques:

• PingCastle and ADRecon to perform reconnaissance of Active Directory 
• Advanced IP Scanner to probe victim networks
• Govmomi Go library to enumerate vCenter APIs 
• PureStorage FlashArray PowerShell module to enumerate storage arrays 
• AAD bulk downloads of user, groups, and devices

Privilege escalation and credential access

Octo Tempest commonly elevates their privileges within an organization through the following techniques:

• Using their pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.
• Social engineering – calling an organization’s help desk and socially engineering the help desk to reset an administrator’s password and/or change/add a multi-factor authentication token/factor

Further masquerading and collection for escalation

Octo Tempest employs an advanced social engineering strategy for privilege escalation, harnessing stolen password policy procedures, bulk downloads of user, group, and role exports, and their familiarity with the target organizations procedures. The actor’s privilege escalation tactics often rely on building trust through various means, such as leveraging possession of compromised accounts and demonstrating an understanding of the organization’s procedures. In some cases, they go as far as bypassing password reset procedures by using a compromised manager’s account to approve their requests.

Octo Tempest continually seeks to collect additional credentials across all planes of access. Using open-source tooling like Jercretz and TruffleHog, the threat actor automates the identification of plaintext keys, secrets, and credentials across code repositories for further use.

Additional tradecraft and techniques:

• Modifying access policies or using MicroBurst to gain access to credential stores
• Using open-source tooling: Mimikatz, Hekatomb, Lazagne, gosecretsdump, smbpasswd.py, LinPEAS, ADFSDump
• Using VMAccess Extension to reset passwords or modify configurations of Azure VMs
• Creating snapshots virtual domain controller disks to download and extract NTDS.dit
• Assignment of User Access Administrator role to grant Tenant Root Group management scope

Defense evasion

Security product arsenal sabotage

Octo Tempest compromises security personnel accounts within victim organizations to turn off security products and features and attempt to evade detection throughout their compromise. Using compromised accounts, the threat actor leverages EDR and device management technologies to allow malicious tooling, deploy RMM software, remove or impair security products, data theft of sensitive files (e.g. files with credentials, signal messaging databases, etc.), and deploy malicious payloads.

To prevent identification of security product manipulation and suppress alerts or notifications of changes, Octo Tempest modifies the security staff mailbox rules to automatically delete emails from vendors that may raise the target’s suspicion of their activities.

Additional tradecraft and techniques:

• Using open-source tooling like privacy.sexy framework to disable security products
• Enrolling actor-controlled devices into device management software to bypass controls
• Configuring trusted locations in Conditional Access Policies to expand access capabilities
• Replaying harvested tokens with satisfied MFA claims to bypass MFA

Persistence 

Sustained intrusion with identities and open-source tools

Octo Tempest leverages publicly available security tools to establish persistence within victim organizations, largely using account manipulation techniques and implants on hosts. For identity-based persistence, Octo Tempest targets federated identity providers using tools like AADInternals to federate existing domains, or spoof legitimate domains by adding and then federating new domains. The threat actor then abuses this federation to generate forged valid security assertion markup language (SAML) tokens for any user of the target tenant with claims that have MFA satisfied, a technique known as Golden SAML. Similar techniques have also been observed using Okta as their source of truth identity provider, leveraging Okta Org2Org functionality to impersonate any desired user account.

To maintain access to endpoints, Octo Tempest installs a wide array of legitimate RMM tools and makes required network modifications to enable access. The usage of reverse shells is seen across Octo Tempest intrusions on both Windows and Linux endpoints. These reverse shells commonly initiate connections to the same attacker infrastructure that deployed the RMM tools.

A unique technique Octo Tempest uses is compromising VMware ESXi infrastructure, installing the open-source Linux backdoor Bedevil, and then launching VMware Python scripts to run arbitrary commands against housed virtual machines.

Additional tradecraft and techniques:

• Usage of open-source tooling: ScreenConnect, FleetDeck, AnyDesk, RustDesk, Splashtop, Pulseway, TightVNC, LummaC2, Level.io, Mesh, TacticalRMM, Tailscale, Ngrok, WsTunnel, Rsocx, and Socat
• Deployment of Azure virtual machines to enable remote access via RMM installation or modification to existing resources via Azure serial console
• Addition of MFA methods to existing users
• Usage of the third-party tunneling tool Twingate, which leverages Azure Container instances as a private connector (without public network exposure)

Actions on objectives

Common trifecta: Data theft, extortion, and ransomware

The goal of Octo Tempest remains financially motivated, but the monetization techniques observed across industries vary between cryptocurrency theft and data exfiltration for extortion and ransomware deployment.

Like in most cyberattacks, data theft largely depends on the data readily available to the threat actor. Octo Tempest accesses data from code repositories, large document management and storage systems, including SharePoint, SQL databases, cloud storage blobs/buckets, and email, using legitimate management clients such as DBeaver, MongoDB Compass, Azure SQL Query Editor, and Cerebrata for the purpose of connection and collection. After data harvesting, the threat actor employs anonymous file-hosting services, including GoFile.io, shz.al, StorjShare, Temp.sh, MegaSync, Paste.ee, Backblaze, and AWS S3 buckets for data exfiltration.

Octo Tempest employs a unique technique using the data movement platform Azure Data Factory and automated pipelines to extract data to external actor hosted Secure File Transfer Protocol (SFTP) servers, aiming to blend in with typical big data operations. Additionally, the threat actor commonly registers legitimate Microsoft 365 backup solutions such as Veeam, AFI Backup, and CommVault to export the contents of SharePoint document libraries and expedite data exfiltration.

Ransomware deployment closely follows data theft objectives. This activity targets both Windows and Unix/Linux endpoints and VMware hypervisors using a variant of ALPHV/BlackCat. Encryption at the hypervisor level has shown significant impact to organizations, making recovery efforts difficult post-encryption.

Octo Tempest frequently communicates with target organizations and their personnel directly after encryption to negotiate or extort the ransom—providing “proof of life” through samples of exfiltrated data. Many of these communications have been leaked publicly, causing significant reputational damage to affected organizations.

Additional tradecraft and techniques:

• Use of the third-party services like FiveTran to extract copies of high-value service databases, such as SalesForce and ZenDesk, using API connectors
• Exfiltration of mailbox PST files and mail forwarding to external mailboxes

Recommendations

Hunting methodology

Octo Tempest’s utilization of social engineering, living-off-the land techniques, and diverse toolsets could make hunting slightly unorthodox. Following these general guidelines alongside robust deconfliction with legitimate users will surface their activity:

Identity

• Understand authentication flows in the environment.
• Centralize visibility of administrative changes in the environment into a single pane of glass.
• Scrutinize all user and sign-in risk detections for any administrator within the timeframe. Common alerts that are surfaced during an Octo Tempest intrusion include (but not limited to): Impossible Travel, Unfamiliar Sign-in Properties, and Anomalous Token
• Review the coverage of Conditional Access policies; scrutinize the use of trusted locations and exclusions.
• Review all existing and new custom domains in the tenant, and their federation settings.
• Scrutinize administrator groups, roles, and privileges for recent modification.
• Review recently created Microsoft Entra ID users and registered device identities.
• Look for any anomalous pivots into organizational apps that may hold sensitive data, such as Microsoft SharePoint and OneDrive.

Azure

• Leverage and continuously monitor Defender for Cloud for Azure Workloads, providing a wealth of information around unauthorized resource access.
• Review Azure role-based access control (RBAC) definitions across the management group, subscription, resource group and resource structure.
• Review the public network exposure of resources and revoke any unauthorized modifications.
• Review both data plane and management plane access control for all critical workloads such as those that hold credentials and organizational data, like Key Vaults, storage accounts, and database resources.
• Tightly control access to identity workloads that issue access organizational resources such as Active Directory Domain Controllers.
• Review the Azure Activity log for anomalous modification of resources.

Endpoints

• Look for recent additions to the indicators or exclusions of the EDR solution in place at the organization.
• Review any generation of offboarding scripts.
• Review access control within security products and EDR software suites.
• Scrutinize any tools used to manage endpoints (SCCM, Intune, etc.) and look for recent rule additions, packages, or deployments.
• Scrutinize use of remote administration tools across the environment, paying particular attention to recent installations regardless of whether they are used legitimately within the network already.
• Ensure monitoring at the network boundary is in place, that alerting is in place for connections with common anonymizing services and scrutinize the use of these services.

Defending against Octo Tempest activity

Align privilege in Microsoft Entra ID and Azure

Privileges spanning Microsoft Entra ID and Azure need to be holistically aligned, with purposeful design decisions to prevent unauthorized access to critical workloads. Reducing the number of users with permanently assigned critical roles is paramount to achieving this. Segregation of privilege between on-premises and cloud is also necessary to sever the ability to pivot within the environment.

It is highly recommended to implement Microsoft Entra Privileged Identity Management (PIM) as a central location for the management of both Microsoft Entra ID roles and Azure RBAC. For all critical roles, at minimum:

• Implement role assignments as eligible rather than permanent.
• Review and understand the role definition Actions and NotActions – ensure to select only the roles with actions that the user requires to do their role (least privileged access).
• Configure these roles to be time-bound, deactivating after a specific timeframe.
• Require users to perform MFA to elevate to the role.
• Optionally require users to provide justification or a ticket number upon elevation.
• Enable notifications for privileged role elevation to a subset of administrators.
• Utilize PIM Access Reviews to reduce standing access in the organization on a periodic basis.

Every organization is different and, therefore, roles will be classified differently in terms of their criticality. Consider the scope of impact those roles may have on downstream resources, services, or identities in the event of compromise. For help desk administrators specifically, ensure to scope privilege to exclude administrative operations over Global Administrators. Consider implementing segregation strategies such as Microsoft Entra ID Administrative Units to segment administrative access over the tenant. For identities that leverage cross-service roles such as those that service the Microsoft Security Stack, consider implementing additional service-based granular access control to restrict the use of sensitive functionality, like Live Response and modification of IOC allow lists.

Segment Azure landing zones

For organizations yet to begin or are early in their modernization journey, end-to-end guidance for cloud adoption is available through the Microsoft Azure Cloud Adoption Framework. Recommended practice and security are central pillars—Azure workloads are segregated into separate, tightly restricted areas known as landing zones. When deploying Active Directory in the cloud, it is advised to create a platform landing zone for identity—a dedicated subscription to hold all Identity-related resources such as Domain Controller VM resources. Employ least privilege across this landing zone with the aforementioned privilege and PIM guidance for Azure RBAC.

Implement Conditional Access policies and authentication methods

TTPs outlined in this blog leverage strategies to evade multifactor authentication defenses. However, it is still strongly recommended to practice basic security hygiene by implementing a baseline set of Conditional Access policies:

• Require multifactor authentication for all privileged roles with the use of authentication strengths to enforce phish-resistant MFA methods such as FIDO2 security keys
• Require phishing-resistant multifactor authentication for administrators
• Enforce MFA registration from trusted locations from a device that also meets organizational requirements with Intune device compliance policies
• User and sign-in risk policies for signals associated to Microsoft Entra ID Protection

Organizations are recommended to keep their policies as simple as possible. Implementing complex policies might inhibit the ability to respond to threats at a rapid pace or allow threat actors to leverage misconfigurations within the environment.

Develop and maintain a user education strategy

An organization’s ability to protect itself against cyberattacks is only as strong as its people—it is imperative to put in place an end-to-end cybersecurity strategy highlighting the importance of ongoing user education and awareness. Targeted education and periodic security awareness campaigns around common cyber threats and attack vectors such as phishing and social engineering not only for users that hold administrative privilege in the organization, but the wider user base is crucial. A well-maintained incident response plan should be developed and refined to enable organizations to respond to unexpected cybersecurity events and rapidly regain positive control.

Use out-of-band communication channels

Octo Tempest has been observed joining, recording, and transcribing calls using tools such as OtterAI, and sending messages via Slack, Zoom, and Microsoft Teams, taunting and threatening targets, organizations, defenders, and gaining insights into incident response operations/planning. Using out-of-band communication channels is strongly encouraged when dealing with this threat actor.

Detections

Microsoft 365 Defender

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

NOTE: Several tools mentioned throughout this blog are remote administrator tools that have been utilized by Octo Tempest to maintain persistence. While these tools are abused by threat actors, they can have legitimate use cases by normal users, and are updated on a frequent basis. Microsoft recommends monitoring their use within the environment, and when they are identified, defenders take the necessary steps for deconfliction to verify their use.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• HackTool:Win32/Mimikatz
• HackTool:Win64/Mimikatz
• Behavior:Win32/BlackCatExec
• Ransom:Win32/Blackcat
• Ransom:Linux/BlackCat
• Behavior:Win32/BlackCat
• Ransom:Win64/BlackCat

Turning on tamper protection, which is part of built-in protection, prevents attackers from stopping security services.

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Octo Tempest activity group

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

• Suspicious usage of remote management software
• Mimikatz credential theft tool
• BlackCat ransomware
• Activity linked to BlackCat ransomware
• Tampering activity typical to ransomware attacks
• Possible hands-on-keyboard pre-ransom activity

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AitM-related alerts in multiple scenarios. For Microsoft Entra ID customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Microsoft 365 Defender through Defender for Cloud Apps connectors for Microsoft Office 365 and Azure. In such scenarios, Microsoft 365 Defender raises the following alerts:

• Backdoor creation using AADInternals tool
• Suspicious domain added to Microsoft Entra ID
• Suspicious domain trust modification following risky sign-in
• User compromised via a known AitM phishing kit
• User compromised in AiTM phishing attack
• Suspicious email deletion activity

Similarly, the connector for Okta raises the following alerts:

• Suspicious Okta account enumeration
• Possible AiTM phishing attempt in Okta

Microsoft Defender for Identity

Microsoft Defender for Identity raises the following alerts for TTPs used by Octo Tempest such as NTDS stealing and Active Directory reconnaissance:

• Account enumeration reconnaissance
• Network-mapping reconnaissance (DNS)
• User and IP address reconnaissance (SMB)
• User and Group membership reconnaissance (SAMR)
• Suspected DCSync attack (replication of directory services)
• Suspected AD FS DKM key read
• Data exfiltration over SMB

Microsoft Defender for Cloud

The following Microsoft Defender for Cloud alerts relate to TTPs used by Octo Tempest. Note, however, that these alerts can also be triggered by unrelated threat activity.

• MicroBurst exploitation toolkit used to enumerate resources in your subscriptions
• MicroBurst exploitation toolkit used to execute code on your virtual machine
• MicroBurst exploitation toolkit used to extract keys from your Azure key vaults
• MicroBurst exploitation toolkit used to extract keys to your storage accounts
• Suspicious Azure role assignment detected
• Suspicious elevate access operation (Preview)
• Suspicious invocation of a high-risk ‘Initial Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Credential Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Impact’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Lateral Movement’ operation detected (Preview)
• Unusual user password reset in your virtual machine
• Suspicious usage of VMAccess extension was detected on your virtual machines (Preview)
• Suspicious usage of multiple monitoring or data collection extensions was detected on your virtual machines (Preview)
• Run Command with a suspicious script was detected on your virtual machine (Preview)
• Suspicious Run Command usage was detected on your virtual machine (Preview)
• Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview)

Microsoft Sentinel

Microsoft Sentinel customers can use the following Microsoft Sentinel Analytics template to identify potential AitM phishing attempts:

• Possible AitM Phishing Attempt Against Azure AD

This detection uses signals from Microsoft Entra ID Identity Protection and looks for successful sign-ins that have been flagged as high risk. It combines this with data from web proxy services, such as ZScaler, to identify where users might have connected to the source of those sign-ins immediately prior. This can indicate a user interacting with an AitM phishing site and having their session hijacked. This detection uses the Advanced Security Information Model (ASIM) Web Session schema. Refer to this article for more details on the schema and its requirements. 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection info, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Octo Tempest
• Octo Tempest uses social engineering and AADInternals to compromise cloud identities

Microsoft 365 Defender Threat analytics  

• Actor profile: Octo Tempest
• Threat insights: Octo Tempest uses social engineering and AADInternals to compromise cloud identities

Hunting queries

Microsoft Sentinel

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

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.

• Suspicious sign-in followed by MFA modification
• Account MFA modifications
• Okta SSO phishing detection
• Okta rare MFA operations
• Okta login from different locations
• Okta user password reset
• SharePointFileOperation via clientIP with previously unseen user agents
• SharePointFileOperation via devices with previously unseen user agents
• SharePointFileOperation via previously unseen IPs of risky ASN’s
• SharePointFileOperation via previously unseen IPs
• Anomalous AAD account manipulation
• New external user granted admin
• Anomolous sign-ins based on time
• New account added to admin group
• Authentication methods changed for privileged account
• Rare run command PowerShell script
• Azure NSG administrative operations
• Rare operations of create and update of snapshots
• AdFind usage
• Anomalous listing of storage keys
• Storage account key enumeration
• Potential Microsoft Security services tampering
• Potential Microsoft Defender tampering
• Office mail forwarding
• Multiple users Office mail forwarding

Further reading

Listen to Microsoft experts discuss Octo Tempest TTPs and activities on The Microsoft Threat Intelligence Podcast.

Visit this page for more blogs from Microsoft Incident Response.

For more 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.

November 1, 2023 update: Updated the Actions of objectives section to fix the list of anonymous file-hosting services used by Octo Tempest for data exfiltration, which incorrectly listed Sh.Azl. It has been corrected to shz.al.

The post Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction appeared first on Microsoft Security Blog.