The spear-phishing emails in this campaign were sent to thousands of targets in over 100 organizations and contained a signed Remote Desktop Protocol (RDP) configuration file that connected to an actor-controlled server. In some of the lures, the actor attempted to add credibility to their malicious messages by impersonating Microsoft employees. The threat actor also referenced other cloud providers in the phishing lures.

While this campaign focuses on many of Midnight Blizzard’s usual targets, the use of a signed RDP configuration file to gain access to the targets’ devices represents a novel access vector for this actor. Overlapping activity has also been reported by the Government Computer Emergency Response Team of Ukraine (CERT-UA) under the designation UAC-0215 and also by Amazon.

Midnight Blizzard is a Russian threat actor attributed by the United States and United Kingdom governments to the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs), and IT service providers, primarily in the United States and Europe. Its focus is to collect intelligence through longstanding and dedicated espionage of foreign interests that can be traced to early 2018. Its operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection.

Midnight Blizzard is consistent and persistent in its operational targeting, and its objectives rarely change. It uses diverse initial access methods, including spear phishing, stolen credentials, supply chain attacks, compromise of on-premises environments to laterally move to the cloud, and leveraging service providers’ trust chain to gain access to downstream customers. Midnight Blizzard is known to use the Active Directory Federation Service (AD FS) malware known as FOGGYWEB and MAGICWEB. Midnight Blizzard is identified by peer security vendors as APT29, UNC2452, and Cozy Bear.

As with any observed nation-state actor activity, Microsoft is in the process of directly notifying customers that have been targeted or compromised, providing them with the necessary information to secure their accounts. Strong anti-phishing measures will help to mitigate this threat. As part of our commitment to helping protect against cyber threats, we provide indicators of compromise (IOCs), hunting queries, detection details, and recommendations at the end of this post.

Spear-phishing campaign

On October 22, 2024, Microsoft identified a spear-phishing campaign in which Midnight Blizzard sent phishing emails to thousands of users in over 100 organizations. The emails were highly targeted, using social engineering lures relating to Microsoft, Amazon Web Services (AWS), and the concept of Zero Trust. The emails contained a Remote Desktop Protocol (RDP) configuration file signed with a LetsEncrypt certificate. RDP configuration (.RDP) files summarize automatic settings and resource mappings that are established when a successful connection to an RDP server occurs. These configurations extend features and resources of the local system to a remote server, controlled by the actor.

In this campaign, the malicious .RDP attachment contained several sensitive settings that would lead to significant information exposure. Once the target system was compromised, it connected to the actor-controlled server and bidirectionally mapped the targeted user’s local device’s resources to the server. Resources sent to the server may include, but are not limited to, all logical hard disks, clipboard contents, printers, connected peripheral devices, audio, and authentication features and facilities of the Windows operating system, including smart cards. This access could enable the threat actor to install malware on the target’s local drive(s) and mapped network share(s), particularly in AutoStart folders, or install additional tools such as remote access trojans (RATs) to maintain access when the RDP session is closed. The process of establishing an RDP connection to the actor-controlled system may also expose the credentials of the user signed in to the target system.

RDP connection

When the target user opened the .RDP attachment, an RDP connection was established to an actor-controlled system. The configuration of the RDP connection then allowed the actor-controlled system to discover and use information about the target system, including:

• Files and directories
• Connected network drives
• Connected peripherals, including smart cards, printers, and microphones
• Web authentication using Windows Hello, passkeys, or security keys
• Clipboard data
• Point of Service (also known as Point of Sale or POS) devices

Targets

Microsoft has observed this campaign targeting governmental agencies, higher education, defense, and non-governmental organizations in dozens of countries, but particularly in the United Kingdom, Europe, Australia, and Japan. This target set is consistent with other Midnight Blizzard phishing campaigns.

Email infrastructure

Midnight Blizzard sent the phishing emails in this campaign using email addresses belonging to legitimate organizations that were gathered during previous compromises. The domains used are listed in the IOC section below.

Mitigations

Microsoft recommends the following mitigations to reduce the impact of this threat.

Strengthen operating environment configuration

• Utilize Windows Firewall or Windows Firewall with Advanced Security to help prevent or restrict outbound RDP connection attempts to external or public networks external or public networks
• Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
• Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with number matching. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and help blocks malicious websites, including phishing sites, scam sites, and sites that host malware.

Strengthen endpoint security configuration

If you are using Microsoft Defender for Endpoint take the following steps:

• Ensure tamper protection is turned on in Microsoft Defender for Endpoint.
• Turn on network protection in Microsoft Defender for Endpoint.
• Turn on web protection.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can help block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to help remediate malicious artifacts that are detected post-breach.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to help resolve breaches, significantly reducing alert volume. 
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to help prevent common attack techniques used by threat actors.
  • Block executable content from email client and webmail
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Strengthen antivirus configuration

• Turn on cloud-delivered protection in Microsoft Defender Antivirus, or the equivalent for your antivirus product, to help cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections help block a majority of new and unknown variants.
• Enable Microsoft Defender Antivirus scanning of downloaded files and attachments.
• Enable Microsoft Defender Antivirus real-time protection.

Strengthen Microsoft Office 365 configuration

• Turn on Safe Links and Safe Attachments for Office 365.
• Enable Zero-hour auto purge (ZAP) in Office 365 to help quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.

Strengthen email security configuration

• Invest in advanced anti-phishing solutions that monitor incoming emails and visited websites. For example, Microsoft Defender for Office 365 merges incident and alert management across email, devices, and identities, centralizing investigations for email-based threats. Organizations can also leverage web browsers that automatically identify and help block malicious websites, including those used in phishing activities.
• If you are using Microsoft Defender for Office 365, configure it to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Microsoft 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect an organization from malicious links used in phishing and other attacks.
• If you are using Microsoft Defender for Office 365, use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns. Run spear-phishing (credential harvest) simulations to train end-users against clicking URLs in unsolicited messages and disclosing credentials.

Conduct user education

• Robust user education can help mitigate the threat of social engineering and phishing emails. Companies should have a user education program that highlights how to identify and report suspicious emails.

Microsoft Defender XDR detections

Microsoft Defender for Endpoint

The following alerts may also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Midnight Blizzard Actor activity group
• Suspicious RDP session

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects at least some of the malicious .RDP files as the following signature:

• Backdoor:Script/HustleCon.A

Microsoft Defender for Cloud

The following alerts may also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Communication with suspicious domain identified by threat intelligence
• Suspicious outgoing RDP network activity
• Traffic detected from IP addresses recommended for blocking

Microsoft Defender for Office 365

Microsoft Defender for Office 365 raises alerts on this campaign using email- and attachment-based detections. Additionally, hunting signatures and an RDP file parser have been incorporated into detections to block similar campaigns in the future. Defenders can identify such activity in alert titles referencing RDP, for example, Trojan_RDP*.

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 threat intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Midnight Blizzard targets NGOs in new wave of initial access campaigns.
• Midnight Blizzard targets diplomatic, NGOs, and humanitarian organizations in global spear phishing activity.

Hunting queries

Microsoft Defender XDR

Identify potential Midnight Blizzard targeted recipients 

Surface possible targeted email accounts within the environment where the email sender originated from a Midnight Blizzard compromised domain related to the RDP activity.

EmailEvents 
| where SenderFromDomain in~ ("sellar.co.uk", "townoflakelure.com", "totalconstruction.com.au", "swpartners.com.au", "cewalton.com") 
| project SenderFromDomain, SenderFromAddress, RecipientEmailAddress, Subject, Timestamp 

Surface potential targets of an RDP attachment phishing attempt

Surface emails that contain a remote desktop protocol (RDP) file attached. This may indicate that the recipient of the email may have been targeted in an RDP attachment phishing attack attempt.

EmailAttachmentInfo
| where FileName has ".rdp"
| join kind=inner (EmailEvents) on NetworkMessageId
| project SenderFromAddress, RecipientEmailAddress, Subject, Timestamp, FileName, FileType

Identify potential successfully targeted assets in an RDP attachment phishing attack

Surface devices that may have been targeted in an email with an RDP file attached, followed by an RDP connection attempt from the device to an external network. This combined activity may indicate that a device may have been successfully targeted in an RDP attachment phishing attack.

// Step 1: Identify emails with RDP attachments
let rdpEmails = EmailAttachmentInfo
| where FileName has ".rdp"
| join kind=inner (EmailEvents) on NetworkMessageId
| project EmailTimestamp = Timestamp, RecipientEmailAddress, NetworkMessageId, SenderFromAddress;
// Step 2: Identify outbound RDP connections
let outboundRDPConnections = DeviceNetworkEvents
| where RemotePort == 3389
| where ActionType == "ConnectionAttempt"
| where RemoteIPType == "Public"
| project RDPConnectionTimestamp = Timestamp, DeviceId, InitiatingProcessAccountUpn, RemoteIP;
// Step 3: Correlate email and network events
rdpEmails
| join kind=inner (outboundRDPConnections) on $left.RecipientEmailAddress == $right.InitiatingProcessAccountUpn
| project EmailTimestamp, RecipientEmailAddress, SenderFromAddress, RDPConnectionTimestamp, DeviceId, RemoteIP

Threat actor RDP connection files attached to email

Surface users that may have received an RDP connection file attached in email that have been observed in this attack from Midnight Blizzard.

EmailAttachmentInfo
| where FileName in~ (
    "AWS IAM Compliance Check.rdp",
    "AWS IAM Configuration.rdp",
    "AWS IAM Quick Start.rdp",
    "AWS SDE Compliance Check.rdp",
    "AWS SDE Environment Check.rdp",
    "AWS Secure Data Exchange - Compliance Check.rdp",
    "AWS Secure Data Exchange Compliance.rdp",
    "Device Configuration Verification.rdp",
    "Device Security Requirements Check.rdp",
    "IAM Identity Center Access.rdp",
    "IAM Identity Center Application Access.rdp",
    "Zero Trust Architecture Configuration.rdp",
    "Zero Trust Security Environment Compliance Check.rdp",
    "ZTS Device Compatibility Test.rdp"
)
| project Timestamp, FileName, SHA256, RecipientEmailAddress, SenderDisplayName, SenderFromAddress

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.

Indicators of compromise

Email sender domains

RDP file names

• AWS IAM Compliance Check.rdp
• AWS IAM Configuration.rdp
• AWS IAM Quick Start.rdp
• AWS SDE Compliance Check.rdp
• AWS SDE Environment Check.rdp
• AWS SDE Environment Check.rdp 
• AWS Secure Data Exchange – Compliance Check.rdp
• AWS Secure Data Exchange Compliance.rdp
• Device Configuration Verification.rdp
• Device Security Requirements Check.rdp
• IAM Identity Center Access.rdp
• IAM Identity Center Application Access.rdp
• Zero Trust Architecture Configuration.rdp
• Zero Trust Security Environment Compliance Check.rdp
• ZTS Device Compatibility Test.rdp

RDP remote computer domains

References

• https://cert.gov.ua/article/6281076
• https://aws.Alpha XR/blogs/security/amazon-identified-internet-domains-abused-by-apt29/
• https://media.defense.gov/2024/Oct/09/2003562611/-1/-1/0/CSA-UPDATE-ON-SVR-CYBER-OPS.PDF
• http://approjects.co.za/?big=security/blog/2021/09/27/foggyweb-targeted-nobelium-malware-leads-to-persistent-backdoor/?msockid=392e4194f0f26165030055c3f1de6080
• http://approjects.co.za/?big=security/blog/2022/08/24/magicweb-nobeliums-post-compromise-trick-to-authenticate-as-anyone/?msockid=392e4194f0f26165030055c3f1de6080

Learn more

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

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://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 Midnight Blizzard conducts large-scale spear-phishing campaign using RDP files appeared first on Microsoft Security Blog.

As stated in the MSRC blog, given the reality of threat actors that are well resourced and funded by nation states, we are shifting the balance we need to strike between security and business risk – the traditional sort of calculus is simply no longer sufficient. For Microsoft, this incident has highlighted the urgent need to move even faster.

If the same team were to deploy the legacy tenant today, mandatory Microsoft policy and workflows would ensure MFA and our active protections are enabled to comply with current policies and guidance, resulting in better protection against these sorts of attacks.

Microsoft was able to identify these attacks in log data by reviewing Exchange Web Services (EWS) activity and using our audit logging features, combined with our extensive knowledge of Midnight Blizzard. In this blog, we provide more details on Midnight Blizzard, our preliminary and ongoing analysis of the techniques they used, and how you may use this information pragmatically to protect, detect, and respond to similar threats in your own environment.

Using the information gained from Microsoft’s investigation into Midnight Blizzard, Microsoft Threat Intelligence has identified that the same actor has been targeting other organizations and, as part of our usual notification processes, we have begun notifying these targeted organizations.

It’s important to note that this investigation is still ongoing, and we will continue to provide details as appropriate.

Midnight Blizzard

Midnight Blizzard (also known as NOBELIUM) is a Russia-based threat actor attributed by the US and UK governments as the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs) and IT service providers, primarily in the US and Europe. Their focus is to collect intelligence through longstanding and dedicated espionage of foreign interests that can be traced to early 2018. Their operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection.

Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Midnight Blizzard’s espionage and intelligence gathering activities leverage a variety of initial access, lateral movement, and persistence techniques to collect information in support of Russian foreign policy interests. They utilize diverse initial access methods ranging from stolen credentials to supply chain attacks, exploitation of on-premises environments to laterally move to the cloud, and exploitation of service providers’ trust chain to gain access to downstream customers. Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection. OAuth is an open standard for token-based authentication and authorization that enables applications to get access to data and resources based on permissions set by a user.

Midnight Blizzard is tracked by partner security vendors as APT29, UNC2452, and Cozy Bear.

Midnight Blizzard observed activity and techniques

Initial access through password spray

Midnight Blizzard utilized password spray attacks that successfully compromised a legacy, non-production test tenant account that did not have multifactor authentication (MFA) enabled. In a password-spray attack, the adversary attempts to sign into a large volume of accounts using a small subset of the most popular or most likely passwords. In this observed Midnight Blizzard activity, the actor tailored their password spray attacks to a limited number of accounts, using a low number of attempts to evade detection and avoid account blocks based on the volume of failures. In addition, as we explain in more detail below, the threat actor further reduced the likelihood of discovery by launching these attacks from a distributed residential proxy infrastructure. These evasion techniques helped ensure the actor obfuscated their activity and could persist the attack over time until successful.

Malicious use of OAuth applications

Threat actors like Midnight Blizzard compromise user accounts to create, modify, and grant high permissions to OAuth applications that they can misuse to hide malicious activity. The misuse of OAuth also enables threat actors to maintain access to applications, even if they lose access to the initially compromised account. Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment. The actor created additional malicious OAuth applications. They created a new user account to grant consent in the Microsoft corporate environment to the actor controlled malicious OAuth applications. The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.

Collection via Exchange Web Services

Midnight Blizzard leveraged these malicious OAuth applications to authenticate to Microsoft Exchange Online and target Microsoft corporate email accounts.

Use of residential proxy infrastructure

As part of their multiple attempts to obfuscate the source of their attack, Midnight Blizzard used residential proxy networks, routing their traffic through a vast number of IP addresses that are also used by legitimate users, to interact with the compromised tenant and, subsequently, with Exchange Online. While not a new technique, Midnight Blizzard’s use of residential proxies to obfuscate connections makes traditional indicators of compromise (IOC)-based detection infeasible due to the high changeover rate of IP addresses.

Defense and protection guidance

Due to the heavy use of proxy infrastructure with a high changeover rate, searching for traditional IOCs, such as infrastructure IP addresses, is not sufficient to detect this type of Midnight Blizzard activity. Instead, Microsoft recommends the following guidance to detect and help reduce the risk of this type of threat:

Defend against malicious OAuth applications

• Audit the current privilege level of all identities, users, service principals, and Microsoft Graph Data Connect applications (use the Microsoft Graph Data Connect authorization portal), to understand which identities are highly privileged. Privilege should be scrutinized more closely if it belongs to an unknown identity, is attached to identities that are no longer in use, or is not fit for purpose. Identities can often be granted privilege over and above what is required. Defenders should pay attention to apps with app-only permissions as those apps may have over-privileged access. Additional guidance for investigating compromised and malicious applications.
• Audit identities that hold ApplicationImpersonation privileges in Exchange Online. ApplicationImpersonation allows a caller, such as a service principal, to impersonate a user and perform the same operations that the user themselves could perform. Impersonation privileges like this can be configured for services that interact with a mailbox on a user’s behalf, such as video conferencing or CRM systems. If misconfigured, or not scoped appropriately, these identities can have broad access to all mailboxes in an environment. Permissions can be reviewed in the Exchange Online Admin Center, or via PowerShell:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers

• Identify malicious OAuth apps using anomaly detection policies. Detect malicious OAuth apps that make sensitive Exchange Online administrative activities through App governance. Investigate and remediate any risky OAuth apps.
• Implement conditional access app control for users connecting from unmanaged devices.
• Midnight Blizzard has also been known to abuse OAuth applications in past attacks against other organizations using the EWS.AccessAsUser.All Microsoft Graph API role or the Exchange Online ApplicationImpersonation role to enable access to email. Defenders should review any applications that hold EWS.AccessAsUser.All and EWS.full_access_as_app permissions and understand whether they are still required in your tenant. If they are no longer required, they should be removed.
• If you require applications to access mailboxes, granular and scalable access can be implemented using role-based access control for applications in Exchange Online. This access model ensures applications are only granted to the specific mailboxes required.

Protect against password spray attacks

• Eliminate insecure passwords.
• Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
• Reset account passwords for any accounts targeted during a password spray attack. If a targeted account had system-level permissions, further investigation may be warranted.
• Detect, investigate, and remediate identity-based attacks using solutions like Microsoft Entra ID Protection.
• Investigate compromised accounts using Microsoft Purview Audit (Premium).
• Enforce on-premises Microsoft Entra Password Protection for Microsoft Active Directory Domain Services.
• Use risk detections for user sign-ins to trigger multifactor authentication or password changes.
• Investigate any possible password spray activity using the password spray investigation playbook.

Detection and hunting guidance

By reviewing Exchange Web Services (EWS) activity, combined with our extensive knowledge of Midnight Blizzard, we were able to identify these attacks in log data. We are sharing some of the same hunting methodologies here to help other defenders detect and investigate similar attack tactics and techniques, if leveraged against their organizations. The audit logging that Microsoft investigators used to discover this activity was also made available to a broader set of Microsoft customers last year.

Identity alerts and protection

Microsoft Entra ID Protection has several relevant detections that help organizations identify these techniques or additional activity that may indicate anomalous activity that needs to be investigated. The use of residential proxy network infrastructure by threat actors is generally more likely to generate Microsoft Entra ID Protection alerts due to inconsistencies in patterns of user behavior compared to legitimate activity (such as location, diversity of IP addresses, etc.) that may be beyond the control of the threat actor.

The following Microsoft Entra ID Protection alerts can help indicate threat activity associated with this attack:

• Unfamiliar sign-in properties – This alert flags sign-ins from networks, devices, and locations that are unfamiliar to the user.
• Password spray – A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been successfully performed. For example, the attacker has successfully authenticated in the detected instance.
• Threat intelligence – This alert indicates user activity that is unusual for the user or consistent with known attack patterns. This detection is based on Microsoft’s internal and external threat intelligence sources.
• Suspicious sign-ins (workload identities) – This alert indicates sign-in properties or patterns that are unusual for the related service principal.

XDR and SIEM alerts and protection

Once an actor decides to use OAuth applications in their attack, a variety of follow-on activities can be identified in alerts to help organizations identify and investigate suspicious activity.

The following built-in Microsoft Defender for Cloud Apps alerts are automatically triggered and can help indicate associated threat activity:

• App with application-only permissions accessing numerous emails – A multi-tenant cloud app with application-only permissions showed a significant increase in calls to the Exchange Web Services API specific to email enumeration and collection. The app might be involved in accessing and retrieving sensitive email data.
• Increase in app API calls to EWS after a credential update – This detection generates alerts for non-Microsoft OAuth apps where the app shows a significant increase in calls to Exchange Web Services API within a few days after its certificates/secrets are updated or new credentials are added.
• Increase in app API calls to EWS – This detection generates alerts for non-Microsoft OAuth apps that exhibit a significant increase in calls to the Exchange Web Serves  API. This app might be involved in data exfiltration or other attempts to access and retrieve data.
• App metadata associated with suspicious mal-related activity – This detection generates alerts for non-Microsoft OAuth apps with metadata, such as name, URL, or publisher, that had previously been observed in apps with suspicious mail-related activity. This app might be part of an attack campaign and might be involved in exfiltration of sensitive information.
• Suspicious user created an OAuth app that accessed mailbox items – A user that previously signed on to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

The following Microsoft Defender XDR alert can indicate associated activity:

• Suspicious user created an OAuth app that accessed mailbox items – A user who previously signed in to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

Related hunting queries

February 5, 2024 update: A query that was not working for all customers has been removed.

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

• Find MailItemsAccessed or SaaS actions performed by a labeled password spray IP

CloudAppEvents 
| where Timestamp between (startTime .. endTime) 
| where isnotempty(IPTags) and not(IPTags has_any('Azure','Internal Network IP','branch office')) 
| where IPTags has_any ("Brute force attacker", "Password spray attacker", "malicious", "Possible Hackers") 

Microsoft Sentinel customers can use the following analytic rules to find related activity in their network.

• Password spray attempts – This query helps identify evidence of password spray activity against Microsoft Entra ID applications.
• OAuth application being granted full_access_as_app permission – This detection looks for the full_access_as_app permission being granted to an OAuth application with Admin Consent. This permission provides access to Exchange mailboxes via the EWS API and could be exploited to access sensitive data. The application granted this permission should be reviewed to ensure that it is necessary for the application’s function.
• Addition of services principal/user with elevated permissions – This rule looks for a service principal being granted permissions that could be used to add a Microsoft Entra ID object or user account to an Admin directory role.
• Offline access via OAuth for previously unknown Azure application – This rule alerts when a user consents to provide a previously unknown Azure application with offline access via OAuth. Offline access will provide the Azure app with access to the resources without requiring two-factor authentication. Consent to applications with offline access should generally be rare.

Microsoft Sentinel customers can also use this hunting query:

• OAuth apps reading mail both via GraphAPI and directly – This query returns OAuth Applications that access mail both directly and via Graph, allowing review of whether such dual access methods follow expected user patterns.

Learn more

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

Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence 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 information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:

• Midnight Blizzard
• Midnight Blizzard credential attacks
• Threat overview: Cloud identity abuse
• Techniques profile: Password spray attacks

February 13, 2024 minor update: Updated guidance in “Defend against malicious OAuth applications” section with clearer wording and links to additional resources.

The post Midnight Blizzard: Guidance for responders on nation-state attack appeared first on Microsoft Security Blog.

Our current investigation indicates this campaign has affected fewer than 40 unique global organizations. The organizations targeted in this activity likely indicate specific espionage objectives by Midnight Blizzard directed at government, non-government organizations (NGOs), IT services, technology, discrete manufacturing, and media sectors. Microsoft has mitigated the actor from using the domains and continues to investigate this activity and work to remediate the impact of the attack. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Midnight Blizzard (NOBELIUM) is a Russia-based threat actor attributed by the US and UK governments as the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-government organizations (NGOs), and IT service providers primarily in the US and Europe. Their focus is to collect intelligence through longstanding and dedicated espionage of foreign interests that can be traced to early 2018. Their operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection.

Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. They utilize diverse initial access methods ranging from stolen credentials to supply chain attacks, exploitation of on-premises environments to laterally move to the cloud, exploitation of service providers’ trust chain to gain access to downstream customers, as well as the Active Directory Federation Service (AD FS) malware known as FOGGYWEB and MAGICWEB. Midnight Blizzard (NOBELIUM) is tracked by partner security vendors as APT29, UNC2452, and Cozy Bear.

Midnight Blizzard’s latest credential phishing attack

Midnight Blizzard regularly utilizes token theft techniques for initial access into targeted environments, in addition to authentication spear-phishing, password spray, brute force, and other credential attacks. The attack pattern observed in malicious activity since at least late May 2023 has been identified as a subset of broader credential attack campaigns that we attribute to Midnight Blizzard.

Use of security-themed domain names in lures

To facilitate their attack, the actor uses Microsoft 365 tenants owned by small businesses they have compromised in previous attacks to host and launch their social engineering attack. The actor renames the compromised tenant, adds a new onmicrosoft.com subdomain, then adds a new user associated with that domain from which to send the outbound message to the target tenant. The actor uses security-themed or product name-themed keywords to create a new subdomain and new tenant name to lend legitimacy to the messages. These precursory attacks to compromise legitimate Azure tenants and the use of homoglyph domain names in social engineering lures are part of our ongoing investigation. Microsoft has mitigated the actor from using the domains.

Social engineering attack chain

In this activity, Midnight Blizzard either has obtained valid account credentials for the users they are targeting, or they are targeting users with passwordless authentication configured on their account – both of which require the user to enter a code that is displayed during the authentication flow into the prompt on the Microsoft Authenticator app on their mobile device.

After attempting to authenticate to an account where this form of MFA is required, the actor is presented with a code that the user would need to enter in their authenticator app. The user receives the prompt for code entry on their device. The actor then sends a message to the targeted user over Microsoft Teams eliciting the user to enter the code into the prompt on their device.

Step 1: Teams request to chat

The target user may receive a Microsoft Teams message request from an external user masquerading as a technical support or security team.

Step 2: Request authentication app action

If the target user accepts the message request, the user then receives a Microsoft Teams message from the attacker attempting to convince them to enter a code into the Microsoft Authenticator app on their mobile device.

Step 3: Successful MFA authentication

If the targeted user accepts the message request and enters the code into the Microsoft Authenticator app, the threat actor is granted a token to authenticate as the targeted user. The actor gains access to the user’s Microsoft 365 account, having completed the authentication flow.

The actor then proceeds to conduct post-compromise activity, which typically involves information theft from the compromised Microsoft 365 tenant. In some cases, the actor attempts to add a device to the organization as a managed device via Microsoft Entra ID (formerly Azure Active Directory), likely an attempt to circumvent conditional access policies configured to restrict access to specific resources to managed devices only.

Recommendations

Microsoft recommends the following mitigations to reduce the risk of this threat.

• Pilot and start deploying phishing-resistant authentication methods for users.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Apply security best practices for Microsoft Teams. Refer to the security guide for Microsoft Teams.
  • Understand and select the best access settings for external collaboration for your organization.
  • Specify trusted Microsoft 365 organizations to define which external domains are allowed or blocked to chat and meet.
• Keep Microsoft 365 auditing enabled so that audit records could be investigated if required.
• Allow only known devices that adhere to Microsoft’s recommended security baselines.
• Educate users about social engineering and credential phishing attacks, including refraining from entering MFA codes sent via any form of unsolicited messages.
  • Educate Microsoft Teams users to verify ‘External’ tagging on communication attempts from external entities, be cautious about what they share, and never share their account information or authorize sign-in requests over chat.
  • Educate Microsoft Teams users about accepting or blocking people outside the organization who send messages in Microsoft Teams.
• Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.

Indicators of compromise

Hunting guidance

Microsoft Purview

Customers hunting for related activity in their environment can identify users that were targeted with the phishing lure using content search in Microsoft Purview. A content search can be created for selected Exchange mailboxes (which include Teams messages) using the following keywords (remove the [] around the “.” before use): 

• mlcrosoftaccounts.onmicrosoft[.]com
• msftonlineservices.onmicrosoft[.]com
• msonlineteam.onmicrosoft[.]com
• msftservice.onmicrosoft[.]com
• noreplyteam.onmicrosoft[.]com
• accounteam.onmicrosoft[.]com
• teamsprotection.onmicrosoft[.]com
• identityverification.onmicrosoft[.]com
• msftprotection.onmicrosoft[.]com
• accountsverification.onmicrosoft[.]com
• azuresecuritycenter.onmicrosoft[.]com
• We detected a recent change to your preferred Multi-Factor Authentication (MFA)

The search results will include the messages that match the criteria. The first result will appear to be from <threadid>@unq.gbl.spaces addressed to the target user and the threat actor (i.e., the request to chat as described in Step 1), followed by the message sent by the threat actor, as shown in the Microsoft Purview image below:

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with “TI map”) to automatically match indicators associated with Midnight Blizzard in Microsoft Defender Threat Intelligence 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 Defender Threat Intelligence connector and analytics rule deployed in their Sentinel workspace. Learn more about the Content Hub.

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect activity related to the activity described in this blog:

• Azure portal sign-in from another Azure tenant
• Successful sign-in from non-compliant device
• User accounts – Sign-in failure due to CA spikes
• New onmicrosoft domain added to tenant

Further reading

Read about the threat actor Midnight Blizzard (formerly tracked as NOBELIUM).

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 Twitter at https://twitter.com/MsftSecIntel.

The post Midnight Blizzard conducts targeted social engineering over Microsoft Teams appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. NOBELIUM is now tracked as Midnight Blizzard.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The Microsoft Detection and Response Team (DART) has been renamed to Microsoft Incident Response (Microsoft IR). For more information on IR services, go to Microsoft Incident Response

August 26, 2022 update: Added instructions to enable collection of AD FS event logs in order to search for Event ID 501, and added a new resource for AD FS audit logging in Microsoft Sentinel.

Microsoft security researchers have discovered a post-compromise capability we’re calling MagicWeb, which is used by a threat actor we track as NOBELIUM to maintain persistent access to compromised environments. NOBELIUM remains highly active, executing multiple campaigns in parallel targeting government organizations, non-governmental organizations (NGOs), intergovernmental organizations (IGOs), and think tanks across the US, Europe, and Central Asia. The Microsoft Threat Intelligence Center (MSTIC) assesses that MagicWeb was likely deployed during an ongoing compromise and was leveraged by NOBELIUM possibly to maintain access during strategic remediation steps that could preempt eviction.

NOBELIUM has used abuse of identities and credentialed access as a method for maintaining persistence, and a specialized capability like MagicWeb is not novel for the actor: in September 2021, Microsoft disclosed a post-exploitation capability named FoggyWeb with methods and intent similar to MagicWeb. FoggyWeb was capable of exfiltrating the configuration database of compromised AD FS servers, decrypting token-signing certificates and token-decryption certificates, and downloading and executing additional malware components. MagicWeb goes beyond the collection capabilities of FoggyWeb by facilitating covert access directly. MagicWeb is a malicious DLL that allows manipulation of the claims passed in tokens generated by an Active Directory Federated Services (AD FS) server. It manipulates the user authentication certificates used for authentication, not the signing certificates used in attacks like Golden SAML.

NOBELIUM was able to deploy MagicWeb by first gaining access to highly privileged credentials and moving laterally to gain administrative privileges to an AD FS system. This is not a supply chain attack. The attacker had admin access to the AD FS system and replaced a legitimate DLL with their own malicious DLL, causing malware to be loaded by AD FS instead of the legitimate binary. The backdoor was discovered by Microsoft’s Detection and Response Team (DART) in coordination with MSTIC and Microsoft 365 Defender Research during an ongoing incident response investigation. Microsoft is sharing this information with consent from the client. At the time of this investigation, MagicWeb appears to be highly targeted.

Like domain controllers, AD FS servers can authenticate users and should therefore be treated with the same high level of security. Customers can defend against MagicWeb and other backdoors by implementing a holistic security strategy including the AD FS hardening guidance. In the case of this specific discovery, MagicWeb is one step of a much larger intrusion chain that presents unique detection and prevention scenarios.

With all critical infrastructure such as AD FS, it is important to ensure attackers do not gain administrative access. Once attackers gain administrative access, they have many options for further system compromise, activity obfuscation, and persistence. We recommend that any such infrastructure is isolated, accessible only by dedicated admin accounts, and regularly monitored for any changes. Other security measures that can prevent this and other attacks include credential hygiene to prevent lateral movement. AD FS is an on-premises server, and as with all on-premises servers, deployments can get out of date and/or go unpatched, and they can be impacted by local environment compromises and lateral movement. For these reasons, migration to a cloud-based identity solution such as Azure Active Directory for federated authentication is recommended for the robust security it provides. See the mitigation section below for more information. Though we assess the capability to be in limited use, Microsoft anticipates that other actors could adopt similar methodologies and therefore recommends customers review hardening and mitigation guidance provided in this blog.

How MagicWeb subverts authentication

MagicWeb is a post-compromise malware that can only be deployed by a threat actor after gaining highly privileged access to an environment and moving laterally to an AD FS server. To achieve their goal of maintaining persistent access to an environment by validating authentication for any user account on the AD FS server, NOBELIUM created a backdoored DLL by copying the legitimate Microsoft.IdentityServer.Diagnostics.dll file used in AD FS operations. The legitimate version of this file is catalog signed by Microsoft and is normally loaded by the AD FS server at startup to provide debugging capabilities. NOBELIUM’s backdoored version of the file is unsigned. The threat actor’s highly privileged access that allowed them to access the AD FS server meant they could have performed any number of actions in the environment, but they specifically chose to target an AD FS server to facilitate their goals of persistence and information theft during their operations.

After gaining administrative access to an AD FS server via elevation of privilege and lateral movement, the loading of NOBELIUM’s malicious Microsoft.IdentityServer.Diagnostics.dll into the AD FS process is possible by editing C:\Windows\AD FS\Microsoft.IdentityServer.Servicehost.exe.config to specify a different public token, which controls what loads into the AD FS process when it is started. Because AD FS is a .NET application, it loads the DLLs specified in the config file from the Global Assembly Cache (GAC). By changing the token in the configuration, the adversary directed AD FS to load in the malicious DLL. The interception and manipulation of claims by MagicWeb enables the actor to generate tokens that allow the adversary to bypass AD FS policies (role policies, device policies, and network policies) and sign in as any user with any claims, including multifactor authentication (MFA).

To understand how NOBELIUM can subvert the AD FS process with the MagicWeb malware, it’s important to understand how AD FS claims work. AD FS extends the ability to use single sign-on functionality available within a single security or enterprise boundary to internet-facing applications to provide customers, partners, and suppliers a streamlined user experience while accessing an organization’s web-based applications. AD FS relies on claims-based authentication to validate the identity of the user and their authorization claims. These claims are packaged into a token that can be used for authentication. MagicWeb injects itself into the claims process to perform malicious actions outside the normal roles of an AD FS server.

Security Assertion Markup Language (SAML) uses x509 certificates to establish trust relationships between identity providers and services and to sign and decrypt tokens. These x509 certificates contain enhanced key usage (EKU) values that specify what applications the certificate should be used for. For instance, an EKU containing an Object Identifier (OID) value of 1.3.6.1.4.1.311.20.2.2 would allow for the use of a SmartCard logon. Organizations can create custom OIDs to further narrow certificate usage.

MagicWeb’s authentication bypass comes from passing a non-standard Enhanced Key Usage OID that is hardcoded in the MagicWeb malware during an authentication request for a specified User Principal Name. When this unique hard coded OID value is encountered, MagicWeb will cause the authentication request to bypass all standard AD FS processes (including checks for MFA) and validate the user’s claims. MagicWeb is manipulating the user authentication certificates used in SAML sign-ins, not the signing certificates for a SAML claim used in attacks like Golden SAML.

NOBELIUM uses unique tradecraft per target, so it’s highly likely that the OIDs and public tokens are unique per target as well. We’ve redacted these OIDs and tokens in this report. Please see the hunting guidance section for information on how to look for variants related to this attack.

How to mitigate this threat

NOBELIUM’s ability to deploy MagicWeb hinged on having access to highly privileged credentials that had administrative access to the AD FS servers, giving them the ability to perform whatever malicious activities they wanted to on the systems they had access to.

It’s critical to treat your AD FS servers as a Tier 0 asset, protecting them with the same protections you would apply to a domain controller or other critical security infrastructure. AD FS servers provide authentication to configured relying parties, so an attacker who gains administrative access to an AD FS server can achieve total control of authentication to configured relying parties (include Azure AD tenants configured to use the AD FS server). Practicing credential hygiene is critical for protecting and preventing the exposure of highly privileged administrator accounts. This especially applies on more easily compromised systems like workstations with controls like logon restrictions and preventing lateral movement to these systems with controls like the Windows Firewall.

Migration to Azure Active Directory (Azure AD) authentication is recommended to reduce the risk of on-premises compromises moving laterally to your authentication servers. Customers can use the following references on migration:

• Use the activity report to move AD FS apps to Azure AD
• Move application authentication to Azure AD

Advanced hunting queries

Recommended hunting guidance

• Have Inventory Certificate Issuance policies in your Public Key Infrastructure (PKI) environment, including all EKU attributes used in the environment and compare to known OID values.
• Hunt across Windows Event Logs by enabling AD FS verbose logging. Enable security auditing to allow collection of the AD FS event logs, and specifically look for Event ID 501. This event specifies all the EKU attributes on a claim. Hunt across these logs to look for EKU values which your PKI infrastructure isn’t configured to issue.
• Look for portable executable files in the GAC or AD FS directories on your systems that aren’t signed by Microsoft and inspect these files or submit them for analysis.
• Perform an audit of your exclusion settings to be sure that the AD FS and GAC are included in scans. Many organizations exclude the AD FS directories from security software scanning because of performance degradation concerns.

Microsoft Sentinel

Microsoft Sentinel customers who have enabled verbose mode logging for ADFS can use this query to look for suspicious OIDs: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/SecurityEvent/ADFSAbnormalEnhancedKeyUsageAttribute-OID.yaml.

NOTE: It’s important to enable the proper connector in Sentinel with the correct Event collection. Refer to this post for more details on AD FS Audit logging collection in Sentinel.

Searching for unsigned files in the GAC

The legitimate Microsoft.IdentityServer.Diagnostics.dll is catalog signed by Microsoft. Catalog signing is a method Windows uses for validating code integrity different from Authenticode, and is used for offline validation rather than runtime enforcement of running only signed code. The catalog signing on this file means the file may appear to be unsigned on the file properties pane and in file integrity checkers, security tools, and online malware repositories. The scripts below allow you to look for unsigned binaries and understand both catalog-signed binaries and Authenticode-signed binaries.

Surface unsigned DLLs in GAC using Microsoft 365 Defender

This query surfaces unsigned DLLs in the GAC folder created within the last 60 days.

DeviceImageLoadEvents

     | where FolderPath has @"C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.IdentityServer." and FileName endswith ".dll" and not(isempty(SHA1))

     | join kind = leftanti (DeviceFileCertificateInfo) on SHA1

     | distinct DeviceName, FolderPath, FileName, SHA1, SHA256

Enumerate non-Microsoft signed DLLs in the GAC using PowerShell

Below is an example script that could be used to enumerate non-Microsoft signed DLLs in the relevant GAC folder, where servers.txt is a list of servers you wish to scan. Because the legitimate Microsoft.IdentityServer.Diagnostics.dll is catalog signed, signing won’t appear when viewing file properties, but it will show in PowerShell querying and on load of the DLL.

$servers = get-content -Path (path to file)\servers.txt 
Foreach ($server in $servers) { 
Write-Output "Processing server: $server" 
Invoke-Command -ComputerName $server {Get-ChildItem -Filter "*.dll" -Recurse "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\" | get-authenticodesignature | ft} 
}

Detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus provides detection for this threat under the following malware name:

• Trojan:MSIL/MagicWeb.A!dha

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see the following alert as an indication of possible attack:

• ADFS persistent backdoor detected

Indicators of compromise (IOCs)

Microsoft isn’t sharing IOCs on this NOBELIUM activity at this time. However, NOBELIUM frequently customizes infrastructure and capabilities per campaign, minimizing operational risk should their campaign specific attributes be discovered. If MagicWeb is identified in your environment, it’s unlikely to match any static IOCs from other targets such as a SHA-256 value. It’s recommended to use the hunting guidance provided above to investigate your environment.

Technical analysis of MagicWeb

NOBELIUM has modified the legitimate Microsoft.IdentityServer.Diagnostics.dll by adding malicious code to the TraceLog class from the Microsoft.IdentityServer.Diagnostics namespace/type.

The header section of the TraceLog class from the legitimate Microsoft.IdentityServer.Diagnostics.dll is shown below:

Meanwhile, the header section of the TraceLog class from NOBELIUM’s backdooredversion of Microsoft.IdentityServer.Diagnostics.dll is shown below:

In the backdoored version of the code, as shown above, NOBELIUM has added a static constructor for the TraceLog class. A static constructor is used to initialize any static data, or to perform a particular action that needs to be performed only once. It’s called automatically before the first instance is created or any static members are referenced.

The malicious static constructor gets executed once before the first instance of the TraceLog class is created. Given that new instances of the TraceLog class is created in various locations in this DLL, the execution of the malicious static constructor is guaranteed to occur as soon as the DLL is loaded for the first time (which would be upon startup of the AD FS server after the malicious changes to Microsoft.IdentityServer.Servicehost.exe.config described above).

NOBELIUM’s malicious static constructor contains a reference to the Initialize() method from a class named AuthLog.

The AuthLog class is a brand-new and malicious class that’s been added to the DLL by NOBELIUM.

As shown above, the Initialize() method references a class named RuntimeHelper, yet another class added to the DLL by the actor. The primary purpose of the RuntimeHelper class and its OverloadMethod() method is to hook legitimate AD FS related methods at runtime. By hooking the legitimate AD FS methods, the backdoor is capable of intercepting calls to the legitimate methods to instead invoke its own custom methods.

The screenshot above shows the following legitimate AD FS methods being hooked by MagicWeb:

Hook method: BeginBuild()

MagicWeb’s BeginBuild() method is used to hook the legitimate target method Build() (from Microsoft.IdentityServer.IdentityModel.dll).

The BeginBuild() method first calls the MagicWeb’s helper method ValidateX509Extensions().

If the helper method ValidateX509Extensions() returns true, BeginBuild() returns true.

If ValidateX509Extensions() returns false, or an exception is thrown by calling ValidateX509Extensions(), BeginBuild() invokes and returns the value returned by the legitimate Build() method from Microsoft.IdentityServer.IdentityModel.dll.

This means that before the legitimate target method Build() from the legitimate Microsoft.IdentityServer.IdentityModel.dll gets an opportunity to inspect/build a certificate, MagicWeb’s hook method first inspects the certificate and returns true if the helper method ValidateX509Extensions() returns true.

This allows the attacker to subvert the normal certificate inspection/build process by introducing a custom certificate inspection/build method that’s invoked before the legitimate Build() method is invoked.

Helper Method: ValidateX509Extensions()

MagicWeb’s helper method ValidateX509Extensions() is called by BeginBuild() and other methods.

ValidateX509Extensions() returns false if the X509 certificate passed to the method is null or the Microsoft Cryptographic API certificate context handle/pointer isn’t set.

Next, the method enumerates the extensions in the X509 certificate passed to the method. If an enumerated extension is of type X509EnhancedKeyUsageExtension, the method iterates the OIDs of the extension, calculating the MD5 hash of each OID (using a custom hash computation helper method ComputeHash() that leverages the .NET MD5 class).

If the MD5 hash value of the OID matches one of the two following hardcoded MD5 values, the method returns true (this methodology is used to check if one of the two OID values below are present in the extension):

• 67F5BD28A842A1C9[REDACTED] (MD5 hash value corresponding to the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED])
• 6E3466296D2F63D[REDACTED] (MD5 hash value corresponding to the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED])

If none of the OID values are present, the method returns false.

This helper method returns true if the certificate passed to the method contains one of the two magic OID values listed above.

Hook method: BeginGetClientCertificate()

To retrieve the client’s X509 certificate, this method first calls the legitimate GetClientCertificate() method from Microsoft.IdentityServer.WebHost.dll. Next, the hook method calls the helper method ValidateX509Extensions() to determine whether the client certificate contains one of the two “magic” OID values. If the client certificate contains one of the two OID values, the hook method:

• Obtains the _adapter field from the current object
• Obtains the _request field from the _adapter object
• Sets the value of the m_ClientCertificateError field (from the _request object) to 0

This means that regardless of what the legitimate method GetClientCertificate() (from Microsoft.IdentityServer.WebHost.dll) sets the m_ClientCertificateError field to, if a client certificate contains one of the magic OID values, the hook method overwrites or sets the m_ClientCertificateError field to 0.

By using this technique, the hook method appears to be influencing the normal behavior of the application to treat or accept a non-valid client certificate as a valid certificate.

Hook method: BeginProcessClaims()

The hook method first indirectly invokes the legitimate ProcessClaims() method by invoking the ProcessClaims() method of the AuthLog class.

On line 198 in figure 16, the hook method calls MagicWeb’s helper method GetClaims(), passing in the processed identity object returned by invoking the legitimate ProcessClaims() method.

As shown above, the GetClaims() method accepts an identity object as a parameter. The method then initializes three variables named type, type2, and type3 with values obtained from the RuntimeHelper’s static field/array named types:

The types field contains the following values:

The assemblyByName2 variable above contains an assembly object representing the legitimate assembly Microsoft.IdentityServer.IdentityModel.dll (if not already loaded, the RuntimeHelper class loads the assembly into the current application domain). By calling the GetType() method, RunHelper initializes the member of the types field/array with .NET types from the Microsoft.IdentityServer.IdentityModel.dll assembly.

Returning to the GetClaims() method and the initialization of type, type2, and type3 the variables type, type2, and type3 get initialized with the following type objects from Microsoft.IdentityServer.IdentityModel.dll:

• type: Microsoft.IdentityModel.Claims.IClaimsIdentity type object
• type2: Microsoft.IdentityModel.Claims.ClaimCollection type object
• type3: Microsoft.IdentityModel.Claims.Claim type object

Next, the GetClaims() method retrieves the Claims property of the Microsoft.IdentityModel.Claims.IclaimsIdentity identity object. It also retrieves the number of claims (of type Microsoft.IdentityModel.Claims.ClaimCollection) present in the Claims property:

GetClaims() then enumerates the claims (of type Microsoft.IdentityModel.Claims.Claim), retrieving the string containing each claim and the corresponding claim type:

As shown above, the claim string and claim type string are then stored in a list named list. This list of claims and their corresponding claim types is then returned to the caller of the GetClaims() method, BeginProcessClaims().

Returning to the BeginProcessClaims() method, after retrieving the claims using the GetClaims() method, the hook method BeginProcessClaims() searches the claims list for presence of a claim with claim type of http://schemas.microsoft.com/claims/authnmethodsreferences:

As shown on line 198 above, the claim(s) of type http://schemas.microsoft.com/claims/authnmethodsreferences (if any) is stored in a list named list. If claim of type http://schemas.microsoft.com/claims/authnmethodsreferences is present and its value is set to http://schemas.microsoft.com/claims/multipleauthn, the hook method returns the IclaimsIdentity object returned by the legitimate target method ProcessClaims() (from Microsoft.IdentityServer.Service.dll) on line 191 of the hook method.

This behavior ensures that if MFA is already satisfied, then the hook method simply acts as a pass-through method and doesn’t affect the normal behavior of the claim processing pipeline.

If a claim of type http://schemas.microsoft.com/claims/authnmethodsreferences is not present or its value is not set to http://schemas.microsoft.com/claims/multipleauthn, the hook method proceeds to perform additional checks on the unprocessed claims (that is, the claims contained in the unprocessed identity object identity passed to the hook method). Once again, the hook method obtains a list of claims by calling the GetClaims() helper method. As mentioned above, instead of calling the GetClaims() helper method with the processed identity object returned by invoking the legitimate ProcessClaims() method (stored in the result variable on line 191), the hook method calls the GetClaims() helper method with the unprocessed identity object identity passed to the hook method:

On line 204, the hook method enumerates the value of each claim and uses the ComputeHash() helper method to calculate the MD5 hash value of each claim value (from the unprocessed identity object). It then checks if the MD5 value of any of the claims equals the MD5 hash value 6E3466296D2F63DE[REDACTED]. This hash value is the only element of a hardcoded hash list named oidMFAHashes (that is, this list can be expanded to include other hash values of interest):

If none of the claims have a value with MD5 hash value of 6E3466296D2F63DE[REDACTED], on line 206, the method simply returns the processed identity object returned by the legitimate target method ProcessClaims() (from Microsoft.IdentityServer.Service.dll) on line 191 of the hook method. As previously discussed, the hash value 6E3466296D2F63DE[REDACTED] corresponds to the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED].

Hence, the hook method enumerates the claims and if a claim with value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED] isn’t present on the claim list, the hook method simply acts as a pass-through method and doesn’t affect the normal behavior of claim processing pipeline.

If by this point in the execution cycle the hook method hasn’t returned yet, it means one of the claims contains the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED] (otherwise, according to the logic described in the paragraph above, the hook method would’ve returned). 

Proceeding with confirmation that one of the claims contains the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED], the hook method proceeds to the section that represents the main purpose of MagicWeb, to perform claim injection.

Before describing the code responsible for the claim injection process, it’s important to revisit what’s already stored in the list and claims variables:

• list: As mentioned before, the hook method invokes the legitimate method ProcessClaims() to process the incoming identity object. The processed identity object (stored in result on line 191) is then passed to the GetClaims() helper method to obtain a list of claim type/value pairs extracted from the processed identity object (line 198). After obtaining the claim type/value pairs, the claim(s) of type http://schemas.microsoft.com/claims/authnmethodsreferences (if any) are stored in a list named list (line 198).

claims: As mentioned above, this variable is used to store a list of claim type/value pairs extracted from the unprocessed identity object:

With this information in mind (and the fact that one of the claims contains the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED]), once again here’s the first part of the claim injection code:

As shown above, if list is empty (that is, the processed identity object contained no claim type/value pairs of type http://schemas.microsoft.com/claims/authnmethodsreferences), the hook method instead turns to claims (containing the list of all claim type/value pairs extracted from the unprocessed identity object) and searches for claim type/value pairs of type http://schemas.microsoft.com/claims/authnmethodsreferences in the claims list. If the claims list contains one or more claim type/value pairs of type http://schemas.microsoft.com/claims/authnmethodsreferences, the hook method uses the claim information to add an identical claim of type http://schemas.microsoft.com/claims/authnmethodsreferences to the processed identity object (line 213 above).

Using this method, if after passing the identity object to the legitimate ProcessClaims() method, no claim of type http://schemas.microsoft.com/claims/authnmethodsreferences is returned by the legitimate method, the hook method manually adds a fraudulent claim of type http://schemas.microsoft.com/claims/authnmethodsreferences to the list of claims returned to the caller of the hooked legitimate method ProcessClaims().

As shown above, to add the fraudulent claim to the list of claims, the hook method calls a helper method named AddClaim().

Like the code in the helper method GetClaims(), AddClaims() initializes two variables with the following type objects:

• type: Microsoft.IdentityModel.Claims.IClaimsIdentity type object
• type2: Microsoft.IdentityModel.Claims.ClaimCollection type object

On line 235, AddClaims() gets the constructor for type Microsoft.IdentityModel.Claims.Claim and invokes the constructor (passing in the claim type and value from the caller of AddClaim()) to instantiate a new Claim object.

The legitimate internal constructor from Microsoft.IdentityModel.Claims.Claim, retrieved and invoked by AddClaim(), invokes the internal constructor Claim (overloaded method) with the following method parameters:

After instantiating a new Claim object, AddClaim() uses the Add() method from type Microsoft.IdentityModel.Claims.ClaimCollection to add the new claim to the identity object passed to AddClaim() by its caller (in this case, the new claim is added to the identity object containing the list of claims returned by the call to the legitimate method ProcessClaims()).

Revisiting the claim injection code in the hook method BeginProcessClaims() (and recalling the fact that one of the claims contains the OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED]), here’s the second part of the claim injection code:

Recall that list contains claim type/value pairs of type http://schemas.microsoft.com/claims/authnmethodsreferences extracted from the processed identity object. If none of the claims in list have the value http://schemas.microsoft.com/claims/multipleauthn, the hook method proceeds to call AddClaim() to add a fraudulent claim of type http://schemas.microsoft.com/claims/authnmethodsreferences and value http://schemas.microsoft.com/claims/multipleauthn to the list of claims returned to the caller of the hooked legitimate method ProcessClaims().

Using the fraudulent claim injection techniques described above, if a claim with the Magic OID value 1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[REDACTED].[REDACTED].[REDACTED].[REDACTED] is presented to AD FS, regardless of how the legitimate hooked method ProcessClaims() handles the claim, the BeginProcessClaims() hook function ensures that a claim with value http://schemas.microsoft.com/claims/multipleauthn is returned to the caller of the legitimate hooked method ProcessClaims().

Hook method: BeginEndpointConfiguration()

The backdoor BeginEndpointConfiguration() method, used to hook the legitimate target method EndpointConfiguration() (from Microsoft.IdentityServer.WebHost.dll) is shown below:

The enumType variable is initialized with RuntimeHelper.types[0] which is a Microsoft.IdentityServer.WebHost.Proxy.CertificateValidation type object. The PropertyInfo variables propertyInfo, propertyInfo2, and propertyInfo3 are initialized with property objects retrieved from ‘properties’ field/array of RuntimeHelper:

• propertyInfo: CertificateValidation property from type Microsoft.IdentityServer.WebHost.Proxy.ProxyEndpoint of Microsoft.IdentityServer.WebHost.dll
• propertyInfo2: Path property from type Microsoft.IdentityServer.WebHost.Proxy.ProxyEndpoint of Microsoft.IdentityServer.WebHost.dll
• propertyInfo3: Endpoints property from type Microsoft.IdentityServer.WebHost.Proxy.ProxyEndpointConfiguration of Microsoft.IdentityServer.WebHost.dll

Next, the hook method retrieves the value of the Endpoint property of the value object that the legitimate EndpointConfiguration() method was called with. The Endpoint property holds a collection of ProxyEndpoint objects. The hook method enumerates the ProxyEndpoint objects and for each object, it checks if the value of the CertificateValidation enum is set to ‘1’ which signifies ‘SSL’. If the CertificateValidation enum for a ProxyEndpoint object is set to ‘1’/’SSL’, on line 165, the hook method overwrites the value of the CertificateValidation enum with ‘0’ which signifies ‘None’. To ensure the change is reflected, the hook method then overwrites the Endpoint property of the value object with the updated Endpoint property containing the overwritten CertificateValidation enum values (that is, ‘SSL’ overwritten with ‘None’).

Behaving as a true hook method, on line 179, the method calls the legitimate EndpointConfiguration() method but with the modified ‘value’ object. Hence, when the legitimate EndpointConfiguration() method is invoked during the normal operation of AD FS, this hook method intercepts the call and, before passing the object to the legitimate EndpointConfiguration() method was invoked with, it overwrites the CertificateValidation value of each ProxyEndpoint object and only then it calls the legitimate EndpointConfiguration() method but now with modified CertificateValidation value(s), changed from ‘SSL’ to ‘None’.

The purpose of overwriting CertificationValidation value to ‘None’ (wherever it’s ‘SSL’) is to allow WAP to pass the request with the specific malicious certificate to AD FS for further authentication processing. According to Microsoft.IdentityServer.ProxyService/TLSClientReqeustHandler, WAP stops sending the current request from client to AD FS if CertificateValidation is ‘1’ (‘SSL’) and the client certificate has an error during validation.

References

• “I am AD FS and so can you: Attacking Active Directory Federated Services”, Austin Baker and Douglas Bienstock, Troopers 2019
• Understanding Key Active Directory Federation Services Concepts, Microsoft documentation

The post MagicWeb: NOBELIUM’s post-compromise trick to authenticate as anyone appeared first on Microsoft Security Blog.

Nation-state attacks are a serious and growing threat that organizations of all sizes face. Their primary objective is to gain strategic advantage for their country, such as by stealing secrets, gathering cyber intelligence, conducting reconnaissance, or disrupting operations. These efforts are typically conducted by state-sponsored actors with significant expertise and funding, making them a particularly challenging adversary to defend against.

NOBELIUM, a Russian-linked group, is perhaps best known for the widespread SolarWinds supply chain breach. The incident was part of an even larger and more advanced campaign that had been quietly underway for more than a year. As details of this attack were uncovered, it became clear that it was the most sophisticated nation-state cyberattack in history.

In the final episode of our “Decoding NOBELIUM” series, we provide an after-action report that explores Microsoft’s findings and discusses lessons learned.

NOBELIUM deployed extensive tactics

Let’s start by reviewing the key stages of the attack.

The intrusion

It’s critical to understand how NOBELIUM achieved penetration into environments. Going beyond the supply chain compromise, this actor also deployed many common-place tactics like password spraying or exploiting the vulnerabilities of unpatched devices to steal credentials and gain access to systems. Ultimately, NOBELIUM leveraged a wide range of techniques to achieve penetration and adapted their toolset to each victim’s unique environment in order to achieve their goals.

The exploitation

Once NOBELIUM had gained entry, they followed the typical pattern for internal reconnaissance: discover the elevated accounts, find out which machines were there, and create a sophisticated map to understand how to reach their targets. They demonstrated extensive knowledge of enterprise environments and cybersecurity systems by evading defenses, masking activities in regular system processes, and hiding malware under many layers of code.

The exfiltration

Armed with an understanding of their target’s environment, NOBELIUM executed their plan—gaining access to their source codes, harvesting emails, or stealing production secrets.

NOBELIUM demonstrated patience and stealth

The NOBELIUM group moved methodically to avoid getting caught. “They were so deliberate and careful about what they did. It wasn’t like a smash and grab, where they came in and just vacuumed up everything and fled,” said Security Analyst Joanne of the Microsoft Digital Security and Resilience (DSR) Security Operations Center (SOC) Hunt Team.

It took time to move undetected through networks, gathering information and gaining access to privileged networks. For example, they disabled organizations’ endpoint detection and response (EDR) solutions from being launched upon system startups. NOBELIUM then waited up to a month for computers to be rebooted on a patch day and took advantage of vulnerable machines that hadn’t been patched.

“The adversary showed discipline in siloing all of the technical indicators that would give up their presence,” said John Lambert, General Manager of the Microsoft Threat Intelligence Center. “Malware was named different things. It was compiled in different ways. The command and control domains they would use differed per victim. As they moved laterally within a network from machine to machine, NOBELIUM took great pains to clean up after each step.”

Preparing for future nation-state attacks

When adversaries take this much care in hiding their activities, it can take the detection of many seemingly benign activities across different vectors pulled together to highlight one overall technique.

“In order to respond to an attack like NOBELIUM, with its scope and breadth and sophistication, you need to have visibility into various entities across your entire digital state,” explains Sarah Fender, Partner Group Program Manager for Microsoft Sentinel. “You need to have visibility into security data and events relating to users and endpoints, infrastructure, on-premises and in the cloud, and the ability to quickly analyze that data.”

NOBELIUM leveraged users and credentials as a critical vector for intrusion and escalation. Identity-based attacks are on the rise. “Once I can authenticate into your environment, I don’t need malware anymore, so that means monitoring behaviors,” says Roberto, Principal Consultant and Lead Investigator for Microsoft’s Detection and Response Team. “Building a profile for when Roberto’s using his machine, he accesses these 25 resources, and he does these kinds of things and he’s never been in these four countries. If I ever see something that doesn’t fit that pattern, I need to alert on it.” 

Bottom line: ensure you are protecting your identities.

Finally, if we’ve learned anything, it’s that we need to take care of our security teams, especially during a cybersecurity incident. 

“Defender fatigue is a real thing,” says Lambert. “You have to be able to invest in those defenders so that they can surge when they need to. Security, like other professions, is not just a job, it’s also a calling. But it also leads to fatigue and exhaustion if the incident drumbeat is too strong. You have to have reserves and plan for that so that you can support your defenders and rest them in between incidents.”

As we prepare for future attacks, it comes down to joining forces. 

“When I think about what this incident means going forward, it certainly reinforces the need for the world to work together on these threats,” explains Lambert. “No one company sees it all and it is very important, especially with sophisticated threats, to be able to work very quickly with lines of trust established. This is not just about companies working together, it’s also about individuals trusting each other, impacted companies, fellow security industry companies, and government institutions.”

How can you protect your organization and defenders?

Learn more in the final episode of our four-part video series “Decoding NOBELIUM,” where security professionals give insights from the after-action report on NOBELIUM. Thanks for joining us for this series and check out the other posts in the series:

• How nation-state attackers like NOBELIUM are changing cybersecurity
• The hunt for NOBELIUM, the most sophisticated nation-state attack in history
• Behind the unprecedented effort to protect customers against the NOBELIUM nation-state attack

Microsoft is committed to helping organizations stay protected from cyberattacks, whether cybercriminal or nation-state. Consistent with our mission to provide security for all, Microsoft will use our leading threat intelligence and a global team of dedicated cybersecurity defenders to partner across the security industry and help protect our customers and the world. Just some recent examples of Microsoft’s efforts to combat nation-state attacks include:

• The investigation of ongoing targeted activity by NOBELIUM against privileged accounts of service providers to gain access to downstream customers.
• The September 2021 discovery and investigation of a NOBELIUM malware referred to as FoggyWeb.
• The May 2021 profiling of NOBELIUM’s early-stage toolset of EnvyScout, BoomBox, NativeZone, and VaporRage.
• Issuing more than 1,600 notifications to more than 40 IT companies alerting them to targeting by several Iranian threat groups (from May through October, those threats were 10 to 13 percent of the total notifications).
• The seizure of websites operated by NICKEL, a China-based threat actor, and the disruption of ongoing attacks targeting organizations in 29 countries.
• The investigation of Iran-linked DEV-0343, conducting password spraying focused on United States and Israeli defense technology companies, Persian Gulf ports of entry, and global maritime transportation companies with a business presence in the Middle East.

For immediate support, visit the Microsoft Security Response Center (MSRC) where you can report an issue and get guidance from the latest security reports and Microsoft Security Response Center blog posts.

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 at @MSFTSecurity for the latest news and updates on cybersecurity.

The post A report on NOBELIUM’s unprecedented nation-state attack appeared first on Microsoft Security Blog.

Defending against a major cyberattack requires the same level of readiness that you need for any major crisis, according to Microsoft 365 Security Chief of Staff Elizabeth Stephens, a 19-year Marine Corps veteran who served in three combat deployments. There’s a mission. There’s a plan of action. And there’s an expert team ready to go. Stephens was part of a dedicated response team that was mobilized in response to the NOBELIUM nation-state attack in December 2020.

“All of the teams came together in a way that very much reminded me of the way my Marine Corps came together,” said Stephens. “The way we respond is very much like first responders. We pride ourselves on being able to come together regardless of our areas of specialty and expertise and fill in the gaps between each other very quickly to get a mission completed. [It’s about] selflessness and the sense of, if we weren’t defending then who else was going to?”

As explained in our first post in the series, How nation-state attackers like NOBELIUM are changing cybersecurity, these sophisticated actors are working to further a given country’s interests through cyberespionage or intelligence-gathering efforts. The multi-pronged attack, which included supply chain compromise from NOBELIUM, a Russian-linked group of hackers, is widely recognized as the most sophisticated nation-state cyberattack in history. When an attack of this magnitude is discovered, the response is equally significant. In the second post in the series, The hunt for NOBELIUM, the most sophisticated nation-state attack in history, we covered the initial industry-wide investigation and gathering of data to understand the attack.

In the third episode of our “Decoding NOBELIUM” series, we reveal new details about how Microsoft worked to disrupt the adversary and safeguard the organizations: notifying and supporting impacted customers, deploying novel prevention rapidly, and providing detection measures to protect all of its customers against the threat.

Notifying customers of the NOBELIUM attack

Customers needed to be notified quickly so they could investigate and understand the scope of the attack inside their environments. Once the threat hunters began isolating threat markers for NOBELIUM activity, they could effectively identify and contact impacted customers. The security community, traditionally, tells customers that they will never receive a phone call from defenders—and to view any calls suspiciously. In this case, with attackers having access to victim environments, there was no safe alternative. Making a call with the difficult news of a sophisticated incursion would be hard enough, but in some instances, they had to find creative ways to validate that it was, in fact, Microsoft on the phone. As part of the notification, the team shared information and guidance about the attack to enable the customer to further investigate the scope and act to begin remediation. The news of NOBELIUM’s activity understandably stunned customers.

“To see the look on people’s faces as the gravity of that [situation] settled in, was certainly sobering for me and my team, but it was also a tremendous incentive to keep going until we could get to the very bottom of it,” said Franklin, Microsoft Identity Security Response Team Lead.

Building product detections to support customers

Those customer contacts were just part of Microsoft’s response to this attack. Microsoft’s threat hunters continued to pore over massive amounts of aggregated telemetry—including user, email, collaboration tools, endpoint, cloud activity, and cloud application security—to identify more subtle attack markers. Called tactics, techniques, and procedures (TTP), these markers were used to track NOBELIUM’s movements.

“By taking a holistic view, we are able to track attackers that move from domain to domain and that is usually where they get lost in the noise, in the transitions,” said Michael Shalev, Principal Program Manager for Microsoft 365 Defender.

The team identified more than 70 TTPs associated with the NOBELIUM attack that we shared publicly. Together, they painted a picture of how the NOBELIUM group operated. Microsoft teams determined which TTPs were specific to an organization, and which were found across the impacted organizations. They quickly used these TTPs to build automated detections into security products so impacted organizations could “return their network and assets to a healthy state” and unimpacted organizations could protect themselves from similar threats, Shalev explained.

Releasing detections into security products in response to a specific attack isn’t new; Microsoft regularly releases detections into security products in response to attacks. But the release volume after the NOBELIUM incident was unprecedented. During a three-week period, Microsoft researchers released multiple detections a day—in the form of targeted custom queries shared through blog posts or updates released directly into the products to enable real-time action. “Seconds count when responding to an attack like this,” said Partner Product Manager Sarah Fender of Microsoft Sentinel, Microsoft’s cloud-native security information and event management platform.

For example, the threat hunters discovered specific techniques that NOBELIUM used to evade security software and analyst tools. As there can be benign reasons to turn off sensors or logging, the TTP research was critical to detecting when the activity was malicious. In response, the Microsoft Defender for Endpoint team developed new anti-tampering policies, hunting queries, and detections to identify and send alerts on these specific NOBELIUM-related activities.

“You really have to meet the customer where they are because the attack is so significant that they’re all going to need help in different sorts of ways,” said Cristin Goodwin, Associate General Counsel for the Microsoft Digital Security Unit.

Cybersecurity strategies and available resources

In the third episode of our “Decoding NOBELIUM” series, security professionals share insights on defending customers after NOBELIUM’s discovery. Watch the episode for guidance on effective cybersecurity hygiene. Look out for the final post in the NOBELIUM nation-state attack series, where we will offer a fuller breakdown of the NOBELIUM attack and share predictions and tips for the future of cybersecurity. Read our previous posts in this series:

• How nation-state attackers like NOBELIUM are changing cybersecurity
• The hunt for NOBELIUM, the most sophisticated nation-state attack in history

Microsoft is committed to helping organizations stay protected from cyberattacks whether cybercriminal or nation-state. Consistent with our mission to provide security for all, Microsoft will use our leading threat intelligence and a global team of dedicated cybersecurity defenders to help protect our customers and the world. Just two recent examples of Microsoft’s efforts to combat nation-state attacks include a September 2021 discovery, an investigation of a NOBELIUM malware referred to as FoggyWeb, and our May 2021 profiling of NOBELIUM’s early-stage toolset compromising EnvyScout, BoomBox, NativeZone, and VaporRage.

For immediate support, visit the Microsoft Security Response Center where you can report an issue and get guidance from the latest security reports and Microsoft Security Response Center blogs.

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 at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Behind the unprecedented effort to protect customers against the NOBELIUM nation-state attack appeared first on Microsoft Security Blog.

Microsoft Detection and Response Team (DART) has been assisting multiple organizations around the world in investigating the impact of NOBELIUM’s activities. While we have already engaged directly with affected customers to assist with incident response related to NOBELIUM’s recent activity, our goal with this blog is to help you answer the common and fundamental questions: How do I determine if I am a victim? If I am a victim, what did the threat actor do? How can I regain control over my environment and make it more difficult for this threat actor to regain access to our environments?

This blog outlines steps incident responders can take to investigate potential abuse of these delegated admin permissions, independent of the threat actor. In this blog, we’ll cover:

• Identifying trust chains in Microsoft 365 and Microsoft Azure.
• Investigating trust chains.
• Mitigating malicious activity.
• Recommendations: detect and protect.

Identifying trust chains in Microsoft 365 and Microsoft Azure

Several types of trust chains exist in Microsoft 365 and Microsoft Azure, which include delegated administration privileges (DAP), Azure admin-on-behalf-of (AOBO), Microsoft Azure Active Directory (Azure AD) business-to-business (B2B), multi-tenant Azure AD applications, as well as guest users. Many of these trust chains can grant a high level of access to Azure resources and Microsoft 365, requiring close monitoring.

Delegated administration privileges

DAP is a method by which your service providers can administer a Microsoft 365 environment without needing to maintain local identities. DAP can be beneficial for both the service provider and end customer because it allows a service provider to administer a downstream tenant using their own identities and security policies. More information about delegated administration privileges and other admin-on-behalf-of scenarios are available in the following resources:

• Azure AOBO.
• Manage subscriptions and resources under the Azure plan.

Service providers with DAP can be identified in the Microsoft 365 admin center by navigating to Settings then to Partner relationships. In the Partner relationships pane, you can view a list of all service providers that have established a billing relationship with the tenant and whether the service provider has any roles assigned (refer to Figure 1).

Figure 1. Identifying DAP as a downstream customer.

While end customers cannot see a list of all users in the service provider’s tenant that can make administrative changes to the end customer tenant, they can view logins by a service provider (refer to Figure 2) by viewing the Azure Active Directory sign-in logs and filtering for a Cross tenant access type of Service provider. The results can be exported by clicking Download and leveraged to further target your triage across Azure and Microsoft 365.

Figure 2. Sign-ins by service providers.

Azure AOBO

Azure AOBO is similar in nature to DAP, albeit the access is scoped to Azure Resource Manager (ARM) role assignments on individual Azure subscriptions and resources, as well as Azure Key Vault access policies. Azure AOBO brings similar management benefits as DAP does.

Note: To fully assess the AOBO permissions in your subscriptions, ensure you have granted access to the Global Administrator who will be assessing service provider access to all subscriptions in each tenant. Read our documentation for details on how to elevate to user access administrator on the tenant root group.

The Azure AOBO access is added at subscription creation time and can be seen under Access control (IAM) on a given Azure subscription (refer to Figure 3).

Figure 3. Foreign Principal with Owner role on subscription.

If you have multiple subscriptions, consider running the following command to identify subscriptions where service providers might have access to resources:

Get-AzSubscription % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" Where-Object {$_.DisplayName -like "Foreign Principal for * in Role 'TenantAdmins' (*)"} Select DisplayName, Scope Format-Table}

It is also possible to grant CSPs direct access to Key Vaults. The following PowerShell command can be used to identify Key Vaults with access policies that allow access via AOBO:

Get-AzKeyVault % { $vault = Get-AzKeyVault -VaultName $_.VaultName; if ($vault.AccessPolicies Where-Object {$_.DisplayName -like "Foreign Principal for '*' in role 'TenantAdmins' (*)"}) { $vault |select VaultName,ResourceId Format-Table}}

The Azure Red Team tool Stormspotter can also be used in addition to the above commands for large environments.

The information gathered from the previous steps will be used to scope log review during triage.

Azure AD B2B

Azure AD B2B accounts (guests) can be used to administer Azure and Microsoft 365 resources. This method of administrative access leverages an individual existing identity in another tenant and is not typically recommended by Microsoft due to the limitations of control over the identity. Investigators should be mindful of the many ways in which guests can be granted access to resources in Microsoft 365, which may include Exchange Online roles and SharePoint online roles. The guidance for this type of identity should be considered non-exhaustive and focused on Azure AD and Azure specifically. For more information, read our documentation about Azure AD B2B best practices.

Azure subscriptions

In order to fully assess the B2B permissions in your subscriptions, ensure you have granted access to users who will be assessing service provider access to all subscriptions in each tenant by following the following guidance: Elevate access to manage all Azure subscriptions and management groups.

Azure AD B2B identities granted Azure roles appear in the Access control blade in the Azure Portal with (Guest) next to them (see Figure 4).

Figure 4. Guest user with Owner role on subscription.

Azure AD B2B identities can be systematically identified with the following command, which will produce a list of identities and resources that can be used to target initial triage.

Get-AzSubscription % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" Where-Object {$_.SignInName -like "*#EXT#@*"} Select DisplayName, SignInName, Scope Format-Table}

Microsoft 365 (Azure AD)

Azure AD B2B identities that have been granted roles in Azure AD can be viewed in the assignments blade of Azure AD Privileged Identity Management blade. Filtering for “#EXT#” will allow you to view all guest users assigned to administrative roles (see Figure 5).

Figure 5. Filtering for guest users.

The following PowerShell can also be used to identify guest accounts with administrative roles. This identity information will be used to help target triage.

Get-AzureADDirectoryRole Get-AzureADDirectoryRoleMember Where-Object {$_.UserPrincipalName -like "*#EXT#@*"}

Investigating trust chains

In Microsoft 365 and Microsoft Azure, there are multiple points of observability where activity via trust chains can be seen, including the Azure AD Audit log, Azure Activity log, Intune audit log, and the unified audit log. Using the data collected in the “identification” phase, a targeted review of logs can be performed to identify trust chain abuse. Each log should be reviewed for activity sourced from trust chains, specifically with a focus on activity that facilitates persistence, data collection, and reconnaissance.

Figure 6. Indicators of tenant compromise.

Azure AD

Adversaries will often establish persistence using various methods including the creation of new service principals, addition of new secrets on to existing application registrations, service principals, creation of new privileged users, and the takeover of existing privileged accounts. You can identify modifications made to Azure AD via trust chains by reviewing the Azure AD Audit log and filtering for the users identified as having recent sign-ins during the “identification” phase. Some specific activities of interest:

• Password resets.
• Modification of service principals.
• Addition of users to privileged roles.
• Changes to multifactor authentication (MFA).
• Creation of new users.

Unified audit log

The unified audit log can be used to identify activity performed via trust chains in SharePoint Online, Exchange Online, Azure AD, and other Microsoft 365 products.

Keep in mind that the unified audit log ingests data from across Azure AD and Office 365 and retains this data for at least 90 days, making it an incredibly valuable source of centralized information, typically with longer retention than the source (for example, Azure AD only retains data for up to 30 days). If E5 licenses are applied, this data will be retained for 1 year, with a maximum configurable retention period of 10 years using Advanced Audit.

The Search-UnifiedAuditLog cmdlet can be used to search for actions performed by the users identified during the “identification” phase. Alternatively, the logs can be searched using a GUI in the Microsoft 365 Defender portal.

Azure activity

Access by a malicious actor to Azure resources enables them to exfiltrate data and move laterally to other environments that are connected to the targeted Azure environment. Actors with access to the subscription can deploy new resources, access existing resources via virtual machine extensions, or simply exfiltrate data and keys directly from the Azure subscription. Access and manipulation of Azure resources can be audited by reviewing the Azure Activity logs that are present in each subscription. Refer to our blog post, Investigating Azure Activity with Microsoft Sentinel, for information about using Microsoft Sentinel queries to identify areas of interest.

Microsoft Endpoint Manager

It may be possible for a malicious actor to access Microsoft Endpoint Manager via various trust chains and as Microsoft Endpoint Manager manages the configuration of devices, it is another important audit log to review. The Microsoft Endpoint Manager audit log can be accessed under the Tenant Administration blade of the Microsoft Endpoint Manager portal. In the audit log, the initiator, “Partner,” can be used to filter for actions initiated by Partners. Actions taken by guest users, identified as having privileges during the “identification” phase, will need to be searched for by User Principal Name. These log events should be reviewed to ensure no malicious activity occurred via the identified trust chains.

Figure 7. Actions initiated by Partners.

Mitigating malicious activity

If during the investigation, malicious activity is discovered and confirmed or unneeded and overly permissive trust chains are discovered, decisive action should be taken to block or minimize access. Depending on the type of trust chain, different steps may need to be taken to block access. It is not recommended to fully delete the artifacts until the conclusion of any ongoing investigation; deleting certain artifacts may delay or make completing an investigation more difficult. Customers should talk with their service provider to understand what protections they have in place, and in the event of potential malicious activity, notify their service provider to obtain their assistance with activity validation.

Delegated administrative privileges

DAP should be removed if it is not required for the active, day-to-day administration of the tenant by the service provider. In some cases, permissions are required to facilitate administration by the service provider. In these instances, Microsoft will be introducing granular delegated admin privileges (GDAP), which will allow partners to control more granular and time-bound access to their customers’ workloads.

We recommend service providers leverage named accounts in the customer tenant to reduce blast radius and risk. In the event there is evidence of compromise stemming from a service provider relationship, it is recommended to remove the delegated admin privileges from the relationship at least until the conclusion of the investigation.

To remove delegated admin privileges, navigate to Settings then to Partner relationships in the Microsoft 365 admin center. From the Partner relationships pane, click on the relationship and then select Remove roles in the details pane. Taking this action will prevent the service provider from accessing the tenant as a Global Administrator or Helpdesk Administrator. Removing this access will not change or alter the billing relationship or licenses currently purchased through the service provider.

Azure AOBO

Azure AOBO access should be removed if it is not required for the active, day-to-day administration of the Azure subscription. If the service provider requires access to the Azure subscriptions, least privilege should be applied by adding the Foreign Principal with the proper roles and permissions. If there is evidence of compromise stemming from a service provider, the foreign group principal should be removed from every Azure Subscription.

Permissions granted via AOBO can be monitored by leveraging Azure Policy. You can deploy an Azure Policy at the Tenant Root Group that will throw non-compliance if a foreign principal is assigned permissions to resources in Azure. While the Azure Policy cannot block the creation of subscriptions with foreign principals, it simplifies reporting on the existence of them and allows the automation of their removal or prevention of creation if desired.

Azure AOBO permissions can be removed by navigating to the Access control (IAM) blade on the impacted subscription, selecting the foreign principal for the service provider, and then pressing Remove.

Figure 8. Removing Azure AOBO permissions for the foreign principal. 

The foreign principal can be added back with more specific permissions if required, following the best practice of least privilege.

Recommendations

Detect

The centralized availability of logging is critical for responding to and investigating potential incidents and is the top blocker to DART investigations of this type. If an organization is monitoring their cloud environment for privileged access and administrative changes, then malicious activities involving delegated admin privilege abuse should be discoverable and alerted.

Cloud activity logs should be ingested into a security information and event manager (SIEM) and retained for analysis. This should include:

• Office 365 unified audit log.
• Azure AD admin audit logs and sign-in logs.
• Microsoft Endpoint Manager audit log.
• Azure Activity logs and specific data plane logs, such as Azure Key Vault and Storage Azure Policy, can be leveraged to enforce a consistent logging standard.

As incident responders, DART are at their most effective when there is data available which is rich in both quantity and quality. One log type of interest is sign-in logs; identity events can tell us a lot about an actor’s activity. Patterns can often be identified in these logs to give us confidence in our analysis of threat actor activity. These patterns can be something as simple as an IP address matching, or as complex as a UserAgent string, time of day, and application ID match.

With that said, the most critical logging is that of administrative activity. Any usage of or actions performed by administrative accounts are of great interest and should be monitored and deconflicted. In enterprise environments, most changes are usually made during approved change windows, and changes outside of this should be assessed for their validity and integrity.

Logs on their own are useful, but alerting is critical to surfacing unusual or malicious activity in a timely manner. The Microsoft 365 Defender portal has some useful alerting built-in to identify suspicious activity. Some examples of these are:

• Elevation of Exchange admin privilege.
• eDiscovery search started or exported.
• Creation of forwarding or redirect rule.

Custom alerts can also be created to alert for other types of activity. Another excellent tool for alerting is Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security). This tool can ingest data from Azure AD, Office 365, Azure, Defender for Endpoint, Defender for Identity, along with many third-party services. A policy engine can be used to create alert policies based on built in templates or custom definitions. Some examples of the templated policies are:

• Administrative activity from a non-corporate IP address.
• Unusual administrative activity (by user).
• Unusual addition of credentials to an OAuth application.
• Suspicious OAuth application file download activities.
• Multiple virtual machine creation activities.

Protect

We recommend customers engage in a dialogue with their service providers on a regular basis to understand security controls that are in place for access to their tenant. Access to resources by the service provider should be closely monitored, and if unused for a period, removed following a strong least privilege process.

Review the Microsoft Security Best Practices and Azure Security Benchmark for guidance on improving security posture in combination with Microsoft Secure Score in the Microsoft 365 Security Center and Secure Score in Microsoft Defender for Cloud.

Some specific examples for protecting administrative access includes using just-in-time administrative solutions such as Privileged Identity Management, including regular reviews of administrators to ensure their access is still required. MFA is also critical, and not just the enablement of MFA, but also ensuring that all administrators have registered MFA methods. DART has seen threat actors find an account which is enabled for MFA but has never been registered, and this allows the threat actor to register their own MFA details, elevating their level of trust in the environment.

Learn more

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 at @MSFTSecurity for the latest news and updates on cybersecurity.

The post How to investigate service provider trust chains in the cloud appeared first on Microsoft Security Blog.

As the name suggests, HTML smuggling lets an attacker “smuggle” an encoded malicious script within a specially crafted HTML attachment or web page. When a target user opens the HTML in their web browser, the browser decodes the malicious script, which, in turn, assembles the payload on the host device. Thus, instead of having a malicious executable pass directly through a network, the attacker builds the malware locally behind a firewall.

Figure 1. HTML smuggling overview

This technique is highly evasive because it could bypass standard perimeter security controls, such as web proxies and email gateways, that often only check for suspicious attachments (for example, EXE, ZIP, or DOCX) or traffic based on signatures and patterns. Because the malicious files are created only after the HTML file is loaded on the endpoint through the browser, what some protection solutions only see at the onset are benign HTML and JavaScript traffic, which can also be obfuscated to further hide their true purpose.

Threats that use HTML smuggling bank on the legitimate uses of HTML and JavaScript in daily business operations in their attempt to stay hidden and relevant, as well as challenge organizations’ conventional mitigation procedures. For example, disabling JavaScript could mitigate HTML smuggling created using JavaScript Blobs. However, JavaScript is used to render business-related and other legitimate web pages. In addition, there are multiple ways to implement HTML smuggling through obfuscation and numerous ways of coding JavaScript, making the said technique highly evasive against content inspection. Therefore, organizations need a true “defense in depth” strategy and a multi-layered security solution that inspects email delivery, network activity, endpoint behavior, and follow-on attacker activities.

The surge in the use of HTML smuggling in email campaigns is another example of how attackers keep refining specific components of their attacks by integrating highly evasive techniques. Microsoft Defender for Office 365 stops such attacks at the onset using dynamic protection technologies, including machine learning and sandboxing, to detect and block HTML-smuggling links and attachments. Email threat signals from Defender for Office 365 also feed into Microsoft 365 Defender, which provides advanced protection on each domain—email and data, endpoints, identities, and cloud apps—and correlates threat data from these domains to surface evasive, sophisticated threats. This provides organizations with comprehensive and coordinated defense against the end-to-end attack chain.

This blog entry details how HTML smuggling works, provides recent examples of threats and targeted attack campaigns that use it, and enumerates mitigation steps and protection guidance.

How HTML smuggling works

HTML smuggling uses legitimate features of HTML5 and JavaScript, which are both supported by all modern browsers, to generate malicious files behind the firewall. Specifically, HTML smuggling leverages the HTML5 “download” attribute for anchor tags, as well as the creation and use of a JavaScript Blob to put together the payload downloaded into an affected device.

In HTML5, when a user clicks a link, the “download” attribute lets an HTML file automatically download a file referenced in the “href” tag. For example, the code below instructs the browser to download “malicious.docx” from its location and save it into the device as “safe.docx”:

The anchor tag and a file’s “download” attribute also have their equivalents in JavaScript code, as seen below:

The use of JavaScript Blobs adds to the “smuggling” aspect of the technique. A JavaScript Blob stores the encoded data of a file, which is then decoded when passed to a JavaScript API that expects a URL. This means that instead of providing a link to an actual file that a user must manually click to download, the said file can be automatically downloaded and constructed locally on the device using JavaScript codes like the ones below:

Today’s attacks use HTML smuggling in two ways: the link to an HTML smuggling page is included within the email message, or the page itself is included as an attachment. The following section provides examples of actual threats we have recently seen using either of these methods.

Real-world examples of threats using HTML smuggling

HTML smuggling has been used in banking malware campaigns, notably attacks attributed to DEV-0238 (also known as Mekotio) and DEV-0253 (also known as Ousaban), targeting Brazil, Mexico, Spain, Peru, and Portugal. In one of the Mekotio campaigns we’ve observed, attackers sent emails with a malicious link, as shown in the image below.

Figure 2. Sample email used in a Mekotio campaign. Clicking the link starts the HTML smuggling technique.

Figure 3. Threat behavior observed in the Mekotio campaign

In this campaign, a malicious website, hxxp://poocardy[.]net/diretorio/, is used to implement the HTML smuggling technique and drop the malicious downloader file. The image below shows an HTML smuggling page when rendered on the browser.

Figure 4. HTML smuggling page of the Mekotio campaign. Note how the “href” tag references a JavaScript Blob with an octet/stream type to download the malicious ZIP file.

It should be noted that this attack attempt relies on social engineering and user interaction to succeed. When a user clicks the emailed hyperlink, the HTML page drops a ZIP file embedded with an obfuscated JavaScript file.

Figure 5. ZIP file with an obfuscated JavaScript file

When the user opens the ZIP file and executes the JavaScript, the said script connects to hxxps://malparque[.]org/rest/restfuch[.]png and downloads another ZIP file that masquerades as a PNG file. This second ZIP file contains the following files related to DAEMON Tools:

• sptdintf.dll – This is a legitimate file. Various virtual disc applications, including DAEMON Tools and Alcohol 120%, use this dynamic-link library (DLL) file.
• imgengine.dll – This is a malicious file that is either Themida-packed or VMProtected for obfuscation. It accesses geolocation information of the target and attempts credential theft and keylogging.
• An executable file with a random name, which is a renamed legitimate file “Disc Soft Bus Service Pro.” This legitimate file is part of DAEMON Tools Pro and loads both DLLs.

Finally, once the user runs the primary executable (the renamed legitimate file), it launches and loads the malicious DLL via DLL sideloading. As previously mentioned, this DLL file is attributed to Mekotio, a malware family of banking Trojans typically deployed on Windows systems that have targeted Latin American industries since the latter half of 2016.

HTML smuggling in targeted attacks

Beyond banking malware campaigns, various cyberattacks—including more sophisticated, targeted ones—incorporate HTML smuggling in their arsenal. Such adoption shows how tactics, techniques, and procedures (TTPs) trickle down from cybercrime gangs to malicious threat actors and vice versa. It also reinforces the current state of the underground economy, where such TTPs get commoditized when deemed effective.

For example, in May, Microsoft Threat Intelligence Center (MSTIC) published a detailed analysis of a new sophisticated email attack from NOBELIUM. MSTIC noted that the spear-phishing email used in that campaign contained an HTML file attachment, which, when opened by the targeted user, uses HTML smuggling to download the main payload on the device.

Since then, other malicious actors appeared to have followed NOBELIUM’s suit and adopted the technique for their own campaigns. Between July and August, open-source intelligence (OSINT) community signals showed an uptick in HTML smuggling in campaigns that deliver remote access Trojans (RATs) such as AsyncRAT/NJRAT.

In September, we saw an email campaign that leverages HTML smuggling to deliver Trickbot. Microsoft attributes this Trickbot campaign to an emerging, financially motivated cybercriminal group we’re tracking as DEV-0193.

In the said campaign, the attacker sends a specially crafted HTML page as an attachment to an email message purporting to be a business report.

Figure 6. HTML smuggling page attached in a Trickbot spear-phishing campaign

When the target recipient opens the HTML attachment in a web browser, it constructs a JavaScript file and saves the said file in the device’s default Downloads folder. As an added detection-evasion technique against endpoint security controls, the created JavaScript file is password-protected. Therefore, the user must type the password indicated in the original HTML attachment to open it.

Figure 7. HTML attachment constructs a password-protected downloader JavaScript in the browser

Once the user executes the JavaScript, it initiates a Base64-encoded PowerShell command, which then calls back to the attacker’s servers to download Trickbot.

Figure 8. HTML smuggling attack chain in the Trickbot spear-phishing campaign

Based on our investigations, DEV-0193 targets organizations primarily in the health and education industries, and works closely with ransomware operators, such as those behind the infamous Ryuk ransomware. After compromising an organization, this group acts as a fundamental pivot point and enabler for follow-on ransomware attacks. They also often sell unauthorized access to the said operators. Thus, once this group compromises an environment, it is highly likely that a ransomware attack will follow.

Defending against the wide range of threats that use HTML smuggling

HTML smuggling presents challenges to traditional security solutions. Effectively defending against this stealthy technique requires true defense in depth. It is always better to thwart an attack early in the attack chain—at the email gateway and web filtering level. If the threat manages to fall through the cracks of perimeter security and is delivered to a host machine, then endpoint protection controls should be able to prevent execution.

Microsoft 365 Defender uses multiple layers of dynamic protection technologies, including machine learning-based protection, to defend against malware threats and other attacks that use HTML smuggling at various levels. It correlates threat data from email, endpoints, identities, and cloud apps, providing in-depth and coordinated threat defense. All of these are backed by threat experts who continuously monitor the threat landscape for new attacker tools and techniques.

Microsoft Defender for Office 365 inspects attachments and links in emails to detect and alert on HTML smuggling attempts. Over the past six months, Microsoft blocked thousands of HTML smuggling links and attachments. The timeline graphs below show a spike in HTML smuggling attempts in June and July.

Figure 9. HTML smuggling links detected and blocked

Figure 10. HTML smuggling attachments detected and blocked

Safe Links and Safe Attachments provide real-time protection against HTML smuggling and other email threats by utilizing a virtual environment to check links and attachments in email messages before they are delivered to recipients. Thousands of suspicious behavioral attributes are detected and analyzed in emails to determine a phishing attempt. For example, behavioral rules that check for the following have proven successful in detecting malware-smuggling HTML attachments:

• An attached ZIP file contains JavaScript
• An attachment is password-protected
• An HTML file contains a suspicious script code
• An HTML file decodes a Base64 code or obfuscates a JavaScript

Through automated and threat expert analyses, existing rules are modified, and new ones are added daily.

On endpoints, attack surface reduction rules block or audit activity associated with HTML smuggling. The following rules can help:

• Block JavaScript or VBScript from launching downloaded executable content
• Block execution of potentially obfuscated scripts
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Endpoint protection platform (EPP) and endpoint detection and response (EDR) capabilities detect malicious files, malicious behavior, and other related events before and after execution. Advanced hunting, meanwhile, lets defenders create custom detections to proactively find related threats.

Defenders can also apply the following mitigations to reduce the impact of threats that utilize HTML smuggling:

• Prevent JavaScript codes from executing automatically by changing file associations for .js and .jse files.
  • Create new Open With parameters in the Group Policy Management Console under User Configuration > Preferences > Control Panel Settings > Folder Options.
  • Create parameters for .jse and .js file extensions, associating them with notepad.exe or another text editor.
• Check Office 365 email filtering settings to ensure they block spoofed emails, spam, and emails with malware. Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Office 365 to recheck links on click and neutralize malicious messages that have already been delivered in response to newly acquired threat intelligence.
• Check the perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Such restrictions help inhibit malware downloads and command and control (C2) activity.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites. Turn on network protection to block connections to malicious domains and IP addresses.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Educate users about preventing malware infections. Encourage users to practice good credential hygiene—limit the use of accounts with local or domain admin privileges and turn on Microsoft Defender Firewall to prevent malware infection and stifle propagation.

Learn how you can stop attacks through automated, cross-domain security with Microsoft 365 Defender.

Microsoft 365 Defender Threat Intelligence Team

The post HTML smuggling surges: Highly evasive loader technique increasingly used in banking malware, targeted attacks appeared first on Microsoft Security Blog.

The threat hunters had but weeks to unravel a global attack that had been planned and executed by an advanced adversary for over a year. The early days of a cyberattack investigation can feel like joining a high-stakes chess match after your opponent has already made a series of moves. You must figure out what your adversary has done while anticipating their next step, and launching a counterplay—all simultaneously. Instead of on a chessboard, your clues are found in the code, logs, and responses to your counterattacks. In the case of the NOBELIUM nation-state attack, this was a highly skilled chess player, but we came together as a company and as an industry to take on this shared adversary. This all started when one security company, Mandiant (formerly known as FireEye), spotted an anomaly in its own environment and shared the evidence with Microsoft for additional analysis, but this story would eventually involve thousands of defenders across the industry to uncover the full picture and help protect organizations.

As explained in our first post in this series, How nation-state attackers like NOBELIUM are changing cybersecurity, nation-state attacks are malicious cyberattacks that originate from a particular country and are an attempt to further that country’s interests. The nation-state attack from NOBELIUM, a Russia-sponsored group of hackers, is widely recognized as the most sophisticated in history. The group gained access to multiple enterprises before their actions were detected. This second episode of “Decoding NOBELIUM” explores how the group was detected and how defenders responded in the weeks that followed.

How was NOBELIUM detected?

It was late November 2020 when a security analyst at cybersecurity company Mandiant detected something unusual in its environment. While reviewing sign-in logs for the previous day, she noticed an event for a user with a different registered device. Intuition told her something was off so she called the user to ask if they’d registered a new device. The answer would set off an unprecedented, industry-wide hunt to catch a cybercriminal. The user said, “No.”

The security professional alerted her colleagues, including her supervisor, Charles Carmakal, Mandiant Senior Vice President and Chief Technology Officer. While they didn’t yet know the identity of the adversary, they would come to realize the importance of this initial detection.

Recognizing that his company needed more collaboration and telemetry to better understand the nature of the attack, Carmakal quickly turned to Microsoft. It was about 9:00 PM when Microsoft Detection and Response Team (DART) Lead Dan Taylor received the call asking for help. Dan initially thought Carmakal was joking and when he realized it was serious, he called Microsoft DART Lead Investigator Roberto, who was taking his dog for the last walk of the day, to ask him if he recognized the anomalous code Mandiant had found. Roberto confirmed that he had seen this anomaly during a previous nation-state investigation.

How did the defense team come together?

Every second counts when responding to large-scale cyberattacks like this. NOBELIUM had a year-long advantage on the defenders. A global threat-hunting effort was formed around the Microsoft Threat Intelligence Center, which defends Microsoft and its customers from advanced threat actors around the world. They immediately activated Microsoft’s team of global security experts, who are on-call for major incidents.

Microsoft Security Analyst Joanne was lacing up her hiking boots on a Saturday when she received a text from her supervisor to the entire team that read, “We need all hands on deck for an active incident.” The hike would have to wait as she and her teammates began studying the available data for indicators of an attack.

As Microsoft continued to partner with Mandiant, it quickly became clear that this attack extended well beyond one security company. The Microsoft response team grew along with this knowledge. With every meeting, another 50 to 100 Microsoft threat experts joined in—everyone came together to help. And the industry-wide collaboration grew as well. “Many different partners across the industry came together with a common goal,” said Ramin, Senior Malware Reverse Engineer with the Microsoft Threat Intelligence Center.

The biggest challenge was the sophisticated tradecraft of the attacker. They practiced extreme variability. “It became very clear to us that we were dealing with a highly capable, highly clandestine, and advanced adversary,” said Carmakal. NOBELIUM would never use the same IP address across organizations—even going so far as to change it every time the group re-entered the same organization’s network. That meant that traditional markers—including hashes, file names, and IP addresses—were all brittle indicators and less helpful for tracking the attacker’s path. Over time, they began identifying subtle markers of malicious activity.

The team’s relentless investigation led to a breakthrough—they discovered that the unknown threat actor was stealing credentials and moving through the networks undetected. During the ongoing investigation, the team uncovered that anomalous activity was happening within the SolarWinds platform. After decompiling 50,0000 lines of SolarWind’s code, Mandiant and Microsoft’s reverse engineers identified NOBELIUM malware carefully obfuscated within layers of code, designed to easily spread undetected to thousands of target organizations. “When we found that scope, it was a combination of exciting and scary,” said Pete, Senior Software Engineer of the Microsoft Threat Intelligence Center.

“You got a sense that this attacker could start in hundreds of customer networks, very deep into them with elevated rights,” said John Lambert, General Manager of the Microsoft Threat Intelligence Center. “When you realize how many enterprise customers and government departments use [SolarWinds], you knew that this attacker had achieved a place to have major impact, across the globe.”

Over weeks, the hunters uncovered a sophisticated, advanced threat with a scale and scope beyond anything they could have initially guessed. Now, it was time to use that hard-won knowledge to find and repel the current threat from NOBELIUM and prepare for future attacks.

NOBELIUM lessons

How did cybersecurity professionals identify NOBELIUM as the threat actor behind the attack and what can your organization do to detect and respond to nation-state attacks? In the second episode of our four-part video series “Decoding Nobelium,” security professionals talk about the investigation that followed the discovery of NOBELIUM’s attack. Watch the episode for tips on how to protect your organization against cyberattacks.

Microsoft is committed to helping organizations stay protected from cyberattacks, whether cybercriminal or nation-state. In particular, nation-state adversaries have significant expertise and resources and will develop new attack patterns to further their geopolitical objectives. Consistent with our mission to provide security for all, Microsoft will use our leading threat intelligence and global team of dedicated cybersecurity defenders to help protect our customers and the world. Just two recent examples of Microsoft’s efforts to combat nation-state attacks include a September 2021 discovery, an investigation of a NOBELIUM malware referred to as FoggyWeb, and our May 2021 profiling of NOBELIUM’s early-stage toolset compromising EnvyScout, BoomBox, NativeZone, and VaporRage.

For immediate support, reach out to the Microsoft Security Response Center. Keep an eye out for future posts in the Nobelium nation-state attack series where we share how we fought the NOBELIUM threat and predict the future of cybersecurity. Read our previous post in this series:

• How nation-state attackers like NOBELIUM are changing cybersecurity

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 at @MSFTSecurity for the latest news and updates on cybersecurity.

The post The hunt for NOBELIUM, the most sophisticated nation-state attack in history appeared first on Microsoft Security Blog.

The aims of nation-state cyber actors—largely espionage and disruption—remain consistent, along with their most reliable tactics and techniques: credential harvesting, malware, and VPN exploits. However, a common theme this year among the actors originating from China, Russia, North Korea, and Iran has been increased targeting of IT service providers as a way of exploiting downstream customers.¹

Earlier this month, we published the 2021 Microsoft Digital Defense Report (MDDR), which provides more in-depth findings about Microsoft’s tracking of nation-state threat groups, including information on the most heavily targeted sectors and countries, specific threat actors, attack methods, and more. This blog captures the high-level themes from the MDDR, and we encourage you to download the full report for additional details.

Government agencies and non-governmental organizations are favored targets

Whenever an organization or individual account holder is targeted or compromised by observed nation-state activities, Microsoft delivers a nation-state notification (NSN) directly to that customer to give them the information they need to investigate the activity. Over the past three years, we’ve delivered over 20,500 NSNs. According to the analysis of the actor activity behind these NSNs, nation-state attacks in the past year have largely focused on operational objectives of espionage and intelligence collection rather than destructive attacks.

“Nation-state activity spans nearly every industry sector and geographic region. In other words, protections against these tactics are critical for every organization and individual.”—2021 Microsoft Digital Defense Report.

The Microsoft Threat Intelligence Center (MSTIC) and the Microsoft Digital Crimes Unit (DCU) have observed that nearly 80 percent of nation-state attacks were directed against government agencies, think tanks, and non-government organizations (NGOs). The nation-state groups we refer to as NOBELIUM, NICKEL, THALLIUM, and PHOSPHORUS were the most active against the government sector, targeting mostly government entities involved in international affairs.

Figure 1: Sectors targeted by nation-state attacks (July 2020 to June 2021).

Russia-based cyber attackers in particular have increasingly set their sights on government targets. Year-on-year comparisons of NSN data depict a marked increase in successful compromises, from a 21 percent success rate between July 2019 and June 2020, up to 32 percent since July 2020. In turn, the percentage of government organizations targeted by Russian threat actors exploded from roughly 3 percent last year, to 53 percent since July 2020 (see figure 3).

Most-targeted countries

The United States remained the most highly targeted country in the past year. Russia-based NOBELIUM also heavily targeted Ukraine, particularly focusing on government interests involved in rallying against a build-up of Russian troops along Ukraine’s border—driving the number of Ukrainian customers impacted from 6 last year to more than 1,200 this year. This past year also saw a near quadrupling in the targeting of Israeli entities, driven exclusively by Iranian actors as tensions escalated between the two countries.

Figure 2: Countries most targeted (July 2020 to June 2021).

Microsoft identifies nation-state activities by chemical element names, some of which are shown in the table below, along with their countries of origin. This small sample of the total nation-state actors tracked by Microsoft represents several of the most active in the last year.

Figure 3: Reference map for nation-state actors.

Volume versus precision

Rates of successful compromises varied widely among threat groups this year. Some, such as North Korea-based THALLIUM, had a low rate of successful compromise likely because their common tactic of large-scale spear-phishing campaigns has become easier to detect and deter as users become increasingly aware of these lures and organizations use security solutions to detect them more effectively. Russia-based NOBELIUM, in contrast, had more successful compromises as a result of their more targeted attack against software supply chains coupled with more high-volume password spray campaigns in pursuit of credential theft. Nation-state actors appear to be increasing the scale of these blunt attacks in an attempt to evade detection and improve their chances of a successful breach. The first fiscal quarter of 2020 (July to September) saw a proportionally higher compromise rate; not necessarily because threat actors were more successful, but because we saw fewer high-volume campaigns during this time.

Figure 4: Average rates of compromise (all tactics, July 2020 to June 2021).

Snapshot: Nation-state activity

Russia

Russia-based NOBELIUM proved how insidious software supply chain attacks can be with its devastating compromise of the SolarWinds Orion software update.² Although the group limited its follow-up exploitation to approximately 100 organizations, its backdoor malware was pushed to roughly 18,000 entities worldwide. In other incidents, NOBELIUM has employed password spray and phishing attacks to compromise third-party providers and facilitate future compromises. This threat actor targeted cloud solution providers (CSPs) and leveraged the backdoor to steal a Mimecast private key.³ Get the full account from world-class defenders on what it took to respond to the most advanced nation-state attack in history by watching the Decoding NOBELIUM docuseries.

China

Chinese nation-state threat actors have been targeting the United States political landscape for insight into policy shifts. In early March 2021, Microsoft blogged about HAFNIUM and the detection of multiple zero-day exploits used to attack on-premises versions of Microsoft Exchange Server. HAFNIUM operates primarily from leased virtual private servers in the United States and targets entities across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.

Iran

Iran continued its streak of destructive cyberattacks against regional adversaries, including a string of ransomware attacks against Israeli entities. Iran-linked threat actor RUBIDIUM has been implicated in the Pay2Key⁴ and N3tw0rm⁵ ransomware campaigns that targeted Israel in late 2020 and early 2021. A common element in Iranian nation-state cyberattacks was the targeting of Israeli logistics companies involved in maritime transportation. Despite Tehran’s less aggressive approach toward the United States in the wake of last year’s election, United States entities remained Iranian threat actors’ top target, comprising nearly half of the NSNs Microsoft delivered to cloud-service customers.

North Korea

Just over half the NSNs Microsoft issued were for North Korea-based state actors during the last three months of 2020. The majority of the North Korean targeting was directed at consumer account targets, based on the likelihood of obtaining non-publicly available diplomatic or geopolitical intelligence. As Microsoft reported in November 2020,  ZINC and CERIUM targeted pharmaceutical companies and vaccine researchers in several countries, probably to speed up North Korea’s own vaccine research. North Korea also continued to target financial companies with the intent of stealing cryptocurrency and intellectual property.⁶

Private sector actors supply the tools

Though not nation-state actors themselves, private sector offensive actors (PSOAs) create and sell malicious cyber technologies to nation-state buyers. PSOA tools have been observed targeting dissidents, human rights defenders, journalists, and other private citizens. In December 2020, Microsoft’s efforts to protect our customers led us to file an amicus brief in support of WhatsApp’s case against Israel-based NSO Group Technologies.⁷ The brief asks the court to reject NSO Group’s position that it’s not responsible for the use of its surveillance and espionage products by governments. Microsoft also worked with Citizen Lab to disable malware used by Israel-based PSOA, SOURGUM (aka Candiru), which created malware and zero-day exploits (fixed in CVE-2021-31979 and CVE-2021-33771) as a part of a hacking-as-a-service package sold to government agencies and other malicious actors.

Comprehensive protection starts with individuals

One thing is clear: nation-state actors are well-funded and employ techniques of tremendous breadth and sophistication. More than other adversaries, nation-state attackers will also target individuals specifically for access to their connections, communications, and information. These attackers are constantly refining their tactics and techniques; therefore, defense-in-depth strategies should include educating employees on how to avoid being targeted themselves. Most importantly, applying Zero Trust principles across corporate resources helps secure today’s mobile workforce—protecting people, devices, applications, and data no matter their location or the scale of threats faced.

Learn more

For a deep dive into our latest information on nation-state threats, download the 2021 Microsoft Digital Defense Report and watch the Decoding NOBELIUM docuseries. Also, look for more blog posts providing information for each themed week of Cybersecurity Awareness Month 2021. Read our latest posts:

• #BeCyberSmart: When we learn together, we’re more secure together
• How cyberattacks are changing according to new Microsoft Digital Defense Report
• Get career advice from 7 inspiring leaders in cybersecurity
• Defenders wanted—building the new cybersecurity professionals

Be sure to visit our Cybersecurity Awareness Month page for links to additional resources and information on protecting your organization year-round. Do your part. #BeCyberSmart

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 at @MSFTSecurity for the latest news and updates on cybersecurity.

¹Awareness Briefing: Chinese Cyber Activity Targeting Managed Service Providers, Cybersecurity Infrastructure Security Agency.

²A ‘Worst Nightmare’ Cyberattack: The Untold Story Of The SolarWinds Hack, Monika Estatieva, NPR. 16 April 2021.

³Mimecast attributes supply chain attack to SolarWinds’ hackers, David Jones, Cybersecurity Dive. 14 January 2021.

⁴Pay2Key Ransomware Joins the Threat Landscape, Tomas Meskauskas, Security Boulevard. 30 November 2020.

⁵N3TW0RM ransomware emerges in wave of cyberattacks in Israel, Lawrence Abrams, Bleeping Computer. 2 May 2021.

⁶North Korean hackers charged in massive cryptocurrency theft scheme, Dan Mangan, CNBC. 17 February 2021.

⁷Google, Cisco and VMware join Microsoft to oppose NSO Group in WhatsApp spyware case, Zack Whittaker, Tech Crunch. 21 December 2020.

The post Microsoft Digital Defense Report shares new insights on nation-state attacks appeared first on Microsoft Security Blog.