Archive

Archive for the ‘Exchange Server’ Category

Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082

October 1st, 2022 No comments

Microsoft is aware of limited targeted attacks using two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. The first one, identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability, while the second one, identified as CVE-2022-41082, allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker. Refer to the Microsoft Security Response Center blog for the mitigation guidance regarding these vulnerabilities.  

CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. However, authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either vulnerability, and they can be used separately.

Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect post-exploitation malware and activity associated with these attacks. Microsoft also released a script, available at https://aka.ms/eomtv2, to apply the mitigations for the SSRF vector CVE-2022-41040 to on-premises Exchange servers.

Microsoft will continue to monitor threats that take advantage of these vulnerabilities and take necessary response actions to protect customers.

Analysis of observed activity

Attacks using Exchange vulnerabilities prior to public disclosure

MSTIC observed activity related to a single activity group in August 2022 that achieved initial access and compromised Exchange servers by chaining CVE-2022-41040 and CVE-2022-41082 in a small number of targeted attacks. These attacks installed the Chopper web shell to facilitate hands-on-keyboard access, which the attackers used to perform Active Directory reconnaissance and data exfiltration. Microsoft observed these attacks in fewer than 10 organizations globally. MSTIC assesses with medium confidence that the single activity group is likely to be a state-sponsored organization.

Microsoft researchers were investigating these attacks to determine if there was a new exploitation vector in Exchange involved when the Zero Day Initiative (ZDI) disclosed CVE-2022-41040 and CVE-2022-41082 to Microsoft Security Response Center (MSRC) in September 2022.

Diagram of the attacks using Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082
Figure 1: Diagram of attacks using Exchange vulnerabilities CVE-2022-41040 and CVE-2022-21082

Observed activity after public disclosure

On September 28, 2022, GTSC released a blog disclosing an exploit previously reported to Microsoft via the Zero Day Initiative and detailing its use in an attack in the wild. Their blog details one example of chained exploitation of CVE-2022-41040 and CVE-2022-41082 and discusses the exploitation details of CVE-2022-41040. It is expected that similar threats and overall exploitation of these vulnerabilities will increase, as security researchers and cybercriminals adopt the published research into their toolkits and proof of concept code becomes available.

While these vulnerabilities require authentication, the authentication needed for exploitation can be that of a standard user. Standard user credentials can be acquired via many different attacks, such as password spray or purchase via the cybercriminal economy. Prior Exchange vulnerabilities that require authentication have been adopted into the toolkits of attackers who deploy ransomware, and these vulnerabilities are likely to be included in similar attacks due to the highly privileged access Exchange systems confer onto an attacker.

Mitigation

Microsoft Exchange Online customers do not need to take any action. On-premises Microsoft Exchange customers should review and apply the URL Rewrite Instructions in our Microsoft Security Response Center post. Microsoft has released a script to apply these mitigations against the SSRF vulnerability CVE-2022-41040, available at https://aka.ms/eomtv2 . Microsoft has confirmed that the URL Rewrite Instructions discussed publicly can break current attack chains.

Microsoft Exchange Server customers using Microsoft 365 Defender are advised to follow this checklist:

  • Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
  • Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
  • Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.

As these vulnerabilities require successful authentication, assessing that MFA policies are applied across all accounts and confirming legacy authentication is disabled could help mitigate the threat by preventing an attacker with stolen credentials from fully authenticating against Exchange.

Multifactor authentication (MFA)

  • Enforce MFA on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times.
  • Enable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Identify and secure workload identities to secure accounts where traditional MFA enforcement does not apply.
  • Ensure that users are properly educated on not accepting unexpected two-factor authentication (2FA).
  • For MFA that uses authenticator apps, ensure that the app requires a code to be typed in where possible, as many intrusions where MFA was enabled still succeeded due to users clicking “Yes” on the prompt on their phones even when they were not at their computers. Refer to this article for an example.
  • Disable legacy authentication.
  • Ensure AD FS servers in the environment point to strong MFA controls like Azure Active Directory

Detection

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint detects post-exploitation activity. The following alerts could be related to this threat:

Indicators of attack MITRE ATT&CK techniques observed   
 Possible web shell installation    Installation  
 Possible IIS web shell    Installation   
 Suspicious Exchange Process Execution    Actions  
 Possible exploitation of Exchange Server vulnerabilities    Exploitation  
 Suspicious processes indicative of a web shell    Actions  
 Possible IIS compromise    Actions  

As of this writing, Defender for Endpoint customers with Microsoft Defender Antivirus enabled can also detect the web shell malware used in in-the-wild exploitation of this vulnerability with the following alerts:

Indicators of attack MITRE ATT&CK techniques observed   
 ‘Chopper’ malware was detected on an IIS Web server    Actions   
 ‘Chopper’ high-severity malware was detected    Actions  

Microsoft Defender Antivirus

Microsoft Exchange AMSI integration and Antivirus Exclusions

Exchange supports the integration with the Antimalware Scan Interface (AMSI) since the June 2021 Quarterly Updates for Exchange. It is highly recommended to ensure these updates are installed and AMSI is working using the guidance provided by the Exchange Team, as this integration provides the best ability for Defender Antivirus to detect and block exploitation of vulnerabilities on Exchange.  

Many organizations exclude Exchange directories from antivirus scans for performance reasons. It’s highly recommended to audit AV exclusions on Exchange systems and assess if they can be removed without impacting performance and still ensure the highest level of protection. Exclusions can be managed via Group Policy, PowerShell, or systems management tools like System Center Configuration Manager.

To audit AV exclusions on an Exchange Server running Defender Antivirus, launch the Get-MpPreference command from an elevated PowerShell prompt.

If exclusions cannot be removed for Exchange processes and folders, running Quick Scan in Defender Antivirus scans Exchange directories and files regardless of exclusions.

Microsoft Defender Antivirus detects the post-exploitation malware currently used in-the-wild exploitation of this vulnerability as the following:

Microsoft Defender Antivirus detections MITRE ATT&CK techniques observed   
 Backdoor:ASP/Webshell.Y  Persistence 
 Backdoor:Win32/RewriteHttp.A  Persistence
 Backdoor:JS/SimChocexShell.A!dha  Persistence
 Behavior:Win32/IISExchgDropWebshell.A!dha  Installation 
 Behavior:Win32/IISExchgDropWebshell.A      Installation 
 Trojan:Win32/IISExchgSpawnCMD.A  Execution 
 Trojan:Win32/WebShellTerminal.A    Installation 
 Trojan:Win32/WebShellTerminal.B   Installation

Microsoft Defender Threat Intelligence

Microsoft Defender Threat Intelligence (MDTI) maps the internet to expose threat actors and their infrastructure. As indicators of compromise (IOCs) associated with threat actors targeting the vulnerabilities described in this writeup are surfaced, Microsoft Defender Threat Intelligence Community members and customers can find summary and enrichment information for all IOCs within the Microsoft Defender Threat Intelligence portal.

Advanced hunting

Microsoft Sentinel

Based on what we’re seeing in the wild, Microsoft Sentinel customers can use the following techniques for web shell-related attacks connected to these vulnerabilities. Our post on web shell threat hunting with Microsoft Sentinel also provides guidance on looking for web shells in general. 

The Exchange SSRF Autodiscover ProxyShell detection, which was created in response to ProxyShell, can be used for queries due to functional similarities with this threat. Also, the new Exchange Server Suspicious File Downloads and Exchange Worker Process Making Remote Call queries specifically look for suspicious downloads or activity in IIS logs. In addition to these, we have a few more that could be helpful in looking for post-exploitation activity:

Microsoft 365 Defender

To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:

Chopper web shell

Use this query to hunt for Chopper web shell activity:

DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where ProcessCommandLine has_any ("&ipconfig&echo", "&quser&echo", "&whoami&echo", "&c:&echo", "&cd&echo", "&dir&echo", "&echo [E]", "&echo [S]")

Suspicious files in Exchange directories

Use this query to hunt for suspicious files in Exchange directories:

DeviceFileEvents
| where Timestamp >= ago(7d)
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "FrontEnd\\HttpProxy\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName,FolderPath,SHA256, InitiatingProcessCommandLine, DeviceId, Timestamp

External attack surface management

Microsoft Defender External Attack Surface Management

Microsoft Defender External Attack Surface Management continuously discovers and maps your digital attack surface to provide an external view of your online infrastructure. Attack Surface Insights are generated by leveraging vulnerability and infrastructure data to showcase the key areas of concern for your organization.

A High Severity Observation is being published to surface assets within an attack surface which should be examined for application of the mitigation steps described above. This insight, titled “CVE-2022-41082 & CVE-2022-41040 – Microsoft Exchange Server Authenticated SSRF and PowerShell RCE”, will be found under the high severity observations section of the Attack Surface Summary dashboard.

The post Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082 appeared first on Microsoft Security Blog.

Malicious OAuth applications used to compromise email servers and spread spam

Microsoft researchers recently investigated an attack where malicious OAuth applications were deployed on compromised cloud tenants and then used to control Exchange servers and spread spam. The investigation revealed that the threat actor launched credential stuffing attacks against high-risk accounts that didn’t have multi-factor authentication (MFA) enabled and leveraged the unsecured administrator accounts to gain initial access. The unauthorized access to the cloud tenant enabled the actor to create a malicious OAuth application that added a malicious inbound connector in the email server. The actor then used the malicious inbound connector to send spam emails that looked like they originated from the targets’ domain. The spam emails were sent as part of a deceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions.

Microsoft has been monitoring the rising popularity of OAuth application abuse. One of the first observed malicious usage of OAuth applications in the wild is consent phishing. Consent phishing attacks aim to trick users into granting permissions to malicious OAuth apps to gain access to user’s legitimate cloud services (mail servers, files storage, management APIs, etc.). In the past few years, Microsoft has observed that more and more threat actors, including nation-state actors, have been using OAuth applications for different malicious purposes – command-and-control (C2) communication, backdoors, phishing, redirections, and so on.

This recent attack involved a network of single-tenant applications installed in compromised organizations being used as the actor’s identity platform to perform the attack. As soon as the network was revealed, all the related applications were taken down and notifications to customers were sent, including recommended remediation steps.

This blog presents the technical analysis of this attack vector and the succeeding spam campaign attempted by the threat actor. It also provides guidance for defenders on protecting organizations from this threat, and how Microsoft security technologies detect it.

A diagram of the attack chain. It presents the flow of activity from left to right, starting with the attacker gaining access to its target tenant and leading to spam messages being sent to targets.
Figure 1. Overview of the attack chain. The time between application deployment and usage varied; there were cases where the actor took months before using the application.

Initial access

For the attack to succeed, the threat actor needed to compromise cloud tenant users with sufficient permissions that would allow the actor to create an application in the cloud environment and give it admin consent. The actor performed credential stuffing attacks against their targets, attempting to access users with the global admin role. The authentication attempts, which originated from a single IP address, were launched against the Azure Active Directory PowerShell application (app ID: 1b730954-1685-4b74-9bfd-dac224a7b894). The same application was later used to deploy the rest of the attack.

Based on the success ratio of the authentication attempts, it is inferred that the attacker used a dump of compromised credentials. The investigation also revealed that 86% of the compromised tenants had at least one admin with a real-time high risk score, which means they were flagged by Azure AD Identity Protection to be most likely compromised. It is also important to note that all the compromised admins didn’t have MFA enabled, which could have stopped the attack. These observations amplify the importance of securing accounts and monitoring for high-risk users, especially those with high privileges.

Deploying malicious OAuth application

Once the threat actor gained access to privileged users, their next step was to set up the malicious application. Based on analysis of the event user agent (Swagger-Codegen/1.4.0.0/csharp) and how quickly the deployment of the application was done, it is likely that the actor ran a PowerShell script to perform the following Azure Active Directory (AAD) management activities in all targeted tenants:

  • Register a new single–tenant application with the naming convention of [domain name]_([a-zA-Z]){3} (for example: Contoso_GhY)
  • Add the legacy permission Exchange.ManageAsApp which can be used for app-only authentication of Exchange Online PowerShell module
  • Grant admin consent to the above permission
  • Give global admin and Exchange admin roles to the previously registered application
  • Add application credentials (key/certificate/both)  

The threat actor added their own credentials to the OAuth application, which enabled them to access the application even if the initially compromised global administrator changed their password.

The activities mentioned gave the threat actor control of a highly privileged application. It was observed that the threat actor did not always use the application right after it was deployed. In some cases, it took weeks or months before the application was utilized. Also, in organizations that didn’t monitor for suspicious applications, the applications were deployed for months and used multiple times by the threat actor.

Modifying Exchange settings

The threat actor used the privileged application to authenticate the Exchange Online PowerShell module and modify the Exchange settings of the compromised server. There were two modifications which allowed them to perform the next step in the attack chain:

Create a new inbound connector

Connectors are a collection of instructions that customize the way email flows to and from organizations using Microsoft 365 or Office 365. Most organizations using Microsoft 365 and Office 365 don’t need custom connectors for regular mail flow, but some use it when they need to process messages from another messaging system that’s not running Exchange, or if they have a network appliance that performs policy checks and then routes messages to their Exchange server.

The threat actor set a new inbound connector with the naming convention Ran_([a-zA-Z]){5} (for example Ran_xAFzd). The purpose of the inbound connector was to allow mails from certain IPs (that are related to the attacker’s infrastructure) to flow through the victim’s Exchange server. This allowed the threat actor to send emails that looked like they originated from the compromised Exchange domain. The configuration information for the newly created connectors were seen in Exchange audit event New-InboundConnector. The following table shows the configuration parameters in the audit event related to this change:

Name Value
“Name” “Ran_jBelh”
“Enabled” “True”
“CloudServicesMailEnabled” “True”
“RestrictDomainsToCertificate” “False”
“SenderDomains” “smtp:*;1”
“SenderIPAddresses” “170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95; 54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”
“RestrictDomainsToIPAddresses” “True”
“ConnectorSource” “HybridWizard”
“EFSkipIPs” “170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95; 54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”
“TreatMessagesAsInternal” “False”
“ConnectorType” “OnPremises”
“RequireTls” “False”

Create transport rules

Transport rules (also known as mail flow rules) are sets of actions that can be taken on any mail that flows in the organization. The threat actor utilized this feature to set 12 new transport rules with the naming convention of Test01 to Test012. Each of these transport rules were responsible for deleting the following specific headers from every mail that flowed in the organization:

  • X-MS-Exchange-ExternalOriginalInternetSender
  • X-MS-Exchange-SkipListedInternetSender
  • Received-SPF
  • Received
  • ARC-Authentication-Results
  • ARC-Message-Signature
  • DKIM-Signature
  • ARC-Seal
  • X-MS-Exchange-SenderADCheck
  • X-MS-Exchange-Authentication-Results
  • Authentication-Results
  • X-MS-Exchange-AntiSpam-MessageData-ChunkCount

By deleting these headers, the attacker tried defense evasion to prevent security products or email providers detecting or blocking their emails and increase the success rate of the spam campaign. The configuration information for the newly created transport rules were seen in Exchange audit event New-TransportRule. The following table shows the configuration parameters in the audit event related to this change:

Name Value
“Name” “Test06”
“SenderAddressLocation” “Header”
“RemoveHeader” “ARC-Message-Signature”

These modifications to the Exchange server settings allowed the threat actor to perform their primary goal in the attack: sending out spam emails. After each spam campaign, the actor deleted the malicious inbound connector and transport rules to prevent detection, while the application remained deployed in the tenant until the next wave of the attack (in some cases, the app was dormant for months before it was reused by the threat actor).

A screenshot of the PowerShell script used by the attacker to modify the Exchange server settings in the target tenant. The code indicates that the attacker set up a new Exchange connector and transport rules.
Figure 2. An example of the PowerShell script used for setting new Exchange connector and transport rules

Spam email campaign sent through Exchange connector

The actor behind this attack has been actively running spam email campaigns for many years. Based on our research, this actor has sent high volumes of spam emails in short timeframes through other methods, such as connecting to mail servers from rogue IP addresses or sending directly from legitimate cloud-based bulk email sending infrastructure.

The actor’s motive was to propagate deceptive sweepstakes spam emails designed to trick recipients into providing credit card details and signing up for recurring subscriptions under the guise of winning a valuable prize. While the scheme possibly led to unwanted charges for targets, there was no evidence of overt security threats such as credential phishing or malware distribution.

The spam campaign carried the hallmarks of this actor: programmatically generated messages containing two visible hyperlinked images in the email body, as well as dynamic and randomized content injected within the HTML body of each mail message to evade spam filters.

A screenshot of a spam message sent to targets as part of the attack. The email bears the branding of a popular retail store and contains an image of an iPhone, suggesting to the reader that they have won the said device. At the bottom of the image, the email states that the reader has been chosen to participate in a survey.
Figure 3. An example of spam email sent through the Exchange inbound connector

The hyperlinked images within the spam messages implied to recipients that they were eligible for a prize. Once clicked, the hyperlink directed recipients to a website where they were asked to complete a survey and provide credit card details to pay for the shipping of their prize.  Familiar brand logos, names, and websites were used throughout the spam email, likely to give an illusion of legitimacy.

A screenshot of the webpage that is presented once the target answers the survey. The page contains the image of an iPhone, and states that the target has won an iPhone 14. The target is then instructed to enter their address and pay a certain amount for the shipping fee of their iPhone 14.
Figure 4. Clicking the image in the spam email leads to this website indicating a prize has been won

The fine print, visible only by scrolling to the very bottom of a subsequent page, revealed that in providing their credit card information, recipients were not paying a shipping fee for their prize, but were in fact agreeing to be charged fees for several paid subscription services in order to enter into a sweepstakes for the prize. It is likely the threat actor’s main motive was potential financial gain from people who fell victim to this deceptive sweepstakes spam campaign.

A screenshot of the text at the bottom of the webpage where the target is asked to pay for a supposed shipping fee. The text indicates the details of the several paid subscriptions they are signing up for by entering their details on the page. It also reveals that the target did not win a device, but only signed up to join a sweepstakes to win an iPhone.
Figure 5. The fine print shows the chance to win a prize is only through a sweepstakes after paying fees

Likely to achieve scale and further maximize the chances of successful email delivery, the actor triggered this spam campaign from cloud-based outbound email infrastructure outside of Microsoft, mainly Amazon SES and Mail Chimp. These email platforms enable sending of mass bulk email, normally for marketing and other legitimate purposes.

The campaign also utilized techniques to generate unique dynamic URLs underpinning the hyperlinked images within each spam email message, as shown in the examples below.

A screenshot of a list of dynamic URLs generated by the threat actor, with the domains obfuscated. Attackers hyperlinked the said URLs to images in spam messages.
Figure 6. Examples of dynamic URL generation (domain obfuscated)

This spam campaign exclusively targeted consumer email accounts. In the case of spam messages sent to Microsoft-hosted consumer email accounts (outlook.com), the spam emails were moved into customers’ junk folders before they could be viewed and clicked.

Mitigations

While the follow-on spam campaign targets consumer email accounts, this attack targets enterprise tenants to use as infrastructure for this campaign. This attack thus exposes security weaknesses that could be used by other threat actors in attacks that could directly impact affected enterprises.

As the main initial access vector of the attack was to obtain the admin’s credentials, we recommend organizations take the following steps to reduce their attack surface:

Mitigate credential guessing attacks risks

A key step in reducing the attack surface is securing the identity infrastructure. The most common initial access vector observed in this attack was account compromise through credential stuffing, and all the compromised administrator accounts did not have MFA enabled. Implementing security practices that strengthen account credentials such as enabling MFA raises the cost of an attack.   

Enable conditional access policies

Conditional access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.

Enable continuous access evaluation

Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Enable security defaults

While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.

Detections for related techniques

Leveraging its cross-signal capabilities, Microsoft 365 Defender alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, and Azure Active Directory Identity Protection to detect the techniques covered in the attack through the attack chain. Each product can provide a different aspect for protection to cover the techniques observed in this attack:

Microsoft 365 Defender

Suspicious email-sending pattern from new Exchange inbound connector – This alert is generated when a suspicious email-sending pattern originating from a new Exchange inbound connector is detected. This behavior might suggest that an attacker set a malicious inbound connector to allow anonymous relay through the organization’s Exchange server.

Recommended reading to response for malicious connector incidents:

New transport rule removing antispam header – This alert is generated when a new transport rule to remove antispam header is detected.

Suspicious inbound connector and transport rule created to remove sender email headers – This alert is generated when a suspicious inbound connector and transport rule is created to remove headers that identify the true source address of sender. This might indicate a spam campaign is ongoing from the organization’s mailbox.

Suspicious Azure AD app creation – This alert is generated when a user account creates Azure Active Directory OAuth application with suspicious characteristics, as observed in this campaign.

Azure AD app registration by risky user – This alert is generated when a user account with high risk score as calculated by AAD Identity Protection is creating a new OAuth application and grants admin consent to it.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

Email messages from a campaign removed after delivery​. This alert is generated when any messages associated with a campaign are delivered to mailboxes in an organization. Microsoft removes the infected messages from Exchange Online mailboxes using zero-hour auto purge (ZAP) if this event occurs.

Microsoft Defender for Cloud Apps

Activity from suspicious IP addresses. This alert is generated when there is activity from an IP address that has been identified as risky by Microsoft Threat Intelligence or by the organization. These IP addresses were identified as being involved in malicious activities, such as performing password spray, botnet C2, and may indicate a compromised account.

Activity from a password-spray associated IP address. This alert is generated when a successful sign-in from an IP address that had been identified as participating in password spray was observed.

App governance

App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Administrative activities along with other threat detection alerts. Activity related to this campaign will trigger the following alert:

OAuth app with suspicious metadata has Exchange permission​. This alert is generated when a line of business OAuth app with suspicious metadata has privilege to manage permission over Exchange, which can lead an OAuth App to perform data collection or exfiltration activities or attempts to access and retrieve sensitive information.

Azure AD Identity Protection

Azure AD Identity Protection automatically detects and remediates identity-based risks. It detects suspicious sign-in attempts and raises any of the following alerts:

  • Anomalous Token. This alert flags a token’s unusual characteristics, such as its token lifetime or played from an unfamiliar location.
  • Unfamiliar sign-in properties. In this phishing campaign, the attackers used multiple proxies or VPNs originating from various countries or regions unfamiliar to the target user.This alert flags anomalies in the token claims, token age, and other authentication attributes.
  • Anonymous IP address. This alert flag sign-in attempts from anonymous IP addresses (for example, Tor browser or anonymous VPN).

Hunting queries

To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:

Applications given the “Exchange.ManageAsApp” permission:

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType == "Add app role assignment to service principal."
| where RawEventData.ResultStatus == "Success"
| where RawEventData has "dc50a0fb-09a3-484d-be87-e023b12c6440" //Exchange.ManageAsApp Role Id 
| project Timestamp, AccountObjectId,AccountDisplayName, AppId = RawEventData.ModifiedProperties[0].NewValue, AppName = RawEventData.ModifiedProperties[6].NewValue

New transport rules that remove anti-spam headers from emails:

CloudAppEvents
| where ActionType == "New-TransportRule"
| mvexpand Param = RawEventData.Parameters
| where Param.Name == "RemoveHeader" and Param.Value contains "X-MS-Exchange-AntiSpam-MessageData"
| project Timestamp, AccountObjectId, AccountDisplayName, ServicePrincipalId = tostring(RawEventData.AppId)

The post Malicious OAuth applications used to compromise email servers and spread spam appeared first on Microsoft Security Blog.

Analyzing attacks taking advantage of the Exchange Server vulnerabilities

March 25th, 2021 No comments

Microsoft continues to monitor and investigate attacks exploiting the recent on-premises Exchange Server vulnerabilities. These attacks are now performed by multiple threat actors ranging from financially motivated cybercriminals to state-sponsored groups. To help customers who are not able to immediately install updates, Microsoft released a one-click tool that automatically mitigates one of the vulnerabilities and scans servers for known attacks. Microsoft also built this capability into Microsoft Defender Antivirus, expanding the reach of the mitigation. As of today, we have seen a significant decrease in the number of still-vulnerable servers – more than 92% of known worldwide Exchange IPs are now patched or mitigated. We continue to work with our customers and partners to mitigate the vulnerabilities.

As organizations recover from this incident, we continue to publish guidance and share threat intelligence to help detect and evict threat actors from affected environments. Today, we are sharing intelligence about what some attackers did after exploiting the vulnerable servers, ranging from ransomware to data exfiltration and deployment of various second-stage payloads. This blog covers:

  • Threat intelligence and technical details about known attacks, including components and attack paths, that defenders can use to investigate whether on-premises Exchange servers were compromised before they were patched and to comprehensively respond to and remediate these threats if they see them in their environments.
  • Detection and automatic remediation built into Microsoft Defender Antivirus and how investigation and remediation capabilities in solutions like Microsoft Defender for Endpoint can help responders perform additional hunting and remediate threats.

Although the overall numbers of ransomware have remained extremely small to this point, it is important to remember that these threats show how quickly attackers can pivot their campaigns to take advantage of newly disclosed vulnerabilities and target unpatched systems, demonstrating how critical it is for organizations to apply security updates as soon as possible. We strongly urge organizations to identify and update vulnerable on-premises Exchange servers, and to follow mitigation and investigation guidance that we have collected and continue to update here: https://aka.ms/ExchangeVulns.

Mitigating post-exploitation activities

The first known attacks leveraging the Exchange Server vulnerabilities were by the nation-state actor HAFNIUM, which we detailed in this blog. In the three weeks after the Exchange server vulnerabilities were disclosed and the security updates were released, Microsoft saw numerous other attackers adopting the exploit into their toolkits. Attackers are known to rapidly work to reverse engineer patches and develop exploits. In the case of a remote code execution (RCE) vulnerability, the rewards are high for attackers who can gain access before an organization patches, as patching a system does not necessarily remove the access of the attacker.

Figure 1. The Exchange Server exploit chain

In our investigation of the on-premises Exchange Server attacks , we saw systems being affected by multiple threats. Many of the compromised systems have not yet received a secondary action, such as human-operated ransomware attacks or data exfiltration, indicating attackers could be establishing and keeping their access for potential later actions. These actions might involve performing follow-on attacks via persistence on Exchange servers they have already compromised, or using credentials and data stolen during these attacks to compromise networks through other entry vectors.

Attackers who included the exploit in their toolkits, whether through modifying public proof of concept exploits or their own research, capitalized on their window of opportunity to gain access to as many systems as they could. Some attackers were advanced enough to remove other attackers from the systems and use multiple persistence points to maintain access to a network.

We have built protections against these threats into Microsoft security solutions. Refer to the Appendix for a list of indicators of compromise, detection details, and advanced hunting queries. We have also provided additional tools and investigation and remediation guidance here: https://aka.ms/exchange-customer-guidance.

While performing a full investigation on systems is recommended, the following themes are common in many of the attacks. These are prevailing threat trends that Microsoft has been monitoring, and existing solutions and recommendations for prevention and mitigation apply:

  • Web shells – As of this writing, many of the unpatched systems we observed had multiple web shells on them. Microsoft has been tracking the rise of web shell attacks for the past few years, ensuring our products detect these threats and providing remediation guidance for customers. For more info on web shells, read Web shell attacks continue to rise. We have also published guidance on web shell threat hunting with Azure Sentinel.
  • Human-operated ransomware – Ransomware attacks pose some of the biggest security risks for organizations today, and attackers behind these attacks were quick to take advantage of the on-premises Exchange Server vulnerabilities. Successfully exploiting the vulnerabilities gives attackers the ability to launch human-operated ransomware campaigns, a trend that Microsoft has been closely monitoring. For more information about human-operated ransomware attacks, including Microsoft solutions and guidance for improving defenses, read: Human-operated ransomware attacks.
  • Credential theft – While credential theft is not the immediate goal of some of these attacks, access to Exchange servers allowed attackers to access and potentially steal credentials present on the system. Attackers can use these stolen credentials for follow-on attacks later, so organizations need to prioritize identifying and remediating impacted identities. For more information, read best practices for building credential hygiene.

In the following sections, we share our analysis of known post-compromise activities associated with exploitation of the Exchange server vulnerabilities because it is helpful to understand these TTPs, in order to defend against other actors using similar tactics or tools. While levels of disruptive post-compromise activity like ransomware may be limited at the time of this writing, Microsoft will continue to track this space and share information with the community. It’s important to note that with some post-compromise techniques, attackers may gain highly privileged persistent access, but many of the impactful subsequent attacker activities can be mitigated by practicing the principle of least privilege and mitigating lateral movement.

DoejoCrypt ransomware

DoejoCrypt was the first ransomware to appear to take advantage of the vulnerabilities, starting to encrypt in limited numbers shortly after the patches were released. Ransomware attackers often use multiple tools and exploits to gain initial access, including purchasing access through a broker or “reseller” who sells access to systems they have already compromised. The DoejoCrypt attacks start with a variant of the Chopper web shell being deployed to the Exchange server post-exploitation.

The web shell writes a batch file to C:\Windows\Temp\xx.bat. Found on all systems that received the DoejoCrypt ransomware payload, this batch file performs a backup of the Security Account Manager (SAM) database and the System and Security registry hives, allowing the attackers later access to passwords of local users on the system and, more critically, in the LSA Secrets portion of the registry, where passwords for services and scheduled tasks are stored.

Figure 2. xx.bat

Given configurations that administrators typically use on Exchange servers, many of the compromised systems are likely to have had at least one service or scheduled task configured with a highly privileged account to perform actions like backups. As service account credentials are not frequently changed, this could provide a great advantage to an attacker even if they lose their initial web shell access due to an antivirus detection, as the account can be used to elevate privileges later, which is why we strongly recommend operating under the principle of least privileged access.

The batch file saves the registry hives to a semi-unique location, C:\windows\temp\debugsms, assembles them into a CAB file for exfiltration, and then cleans up the folders from the system. The file also enables Windows Remote Management and sets up an HTTP listener, indicating the attacker might take advantage of the internet-facing nature of an Exchange Server and use this method for later access if other tools are removed.

Figure 3. xx.bat actions

The xx.bat file has been run on many more systems than have been ransomed by the DoejoCrypt attacker, meaning that, while not all systems have moved to the ransom stage, the attacker has gained access to multiple credentials. On systems where the attacker moved to the ransom stage, we saw reconnaissance commands being run via the same web shell that dopped the xx.bat file (in this instance, a version of Chopper):

Figure 4. DoejoCrypt recon command

After these commands are completed, the web shell drops a new payload to C:\Windows\Help which, like in many human-operated ransomware campaigns, leads to the attack framework Cobalt Strike. In observed instances, the downloaded payload is shellcode with the file name new443.exe or Direct_Load.exe. When run, this payload injects itself into notepad.exe and reaches out to a C2 to download Cobalt Strike shellcode.

Figure 5. DoejoCrypt ransomware attack chain

During the hands-on-keyboard stage of the attack, a new payload is downloaded to C:\Windows\Help with names like s1.exe and s2.exe. This payload is the DoejoCrypt ransomware, which uses a .CRYPT extension for the newly encrypted files and a very basic readme.txt ransom note. In some instances, the time between xx.bat being dropped and a ransomware payload running was under half an hour.

Figure 6. DoejoCrypt ransom note

While the DoejoCrypt payload is the most visible outcome of this attackers’ actions, the access to credentials they have gained could serve them for future campaigns if organizations do not reset credentials on compromised systems. An additional overlapping activity observed on systems where xx.bat was present and the attackers were able to get Domain Administrator rights was the running of scripts to snapshot Active Directory with ntdsutil—an action that, if executed successfully, could give the attackers access to all the passwords in Active Directory from a single compromised system.

Lemon Duck botnet

Cryptocurrency miners were some of the first payloads we observed being dropped by attackers from the post-exploit web shells. In the first few days after the security updates were released, we observed multiple cryptocurrency miner campaigns, which had been previously targeting SharePoint servers, add Exchange Server exploitation to their repertoire. Most of these coin miners were variations on XMRig miners, and many arrived via a multi-featured implant with the capability to download new payloads or even move laterally.

Lemon Duck, a known cryptocurrency botnet named for a variable in its code, dove into the Exchange exploit action, adopting different exploit styles and choosing to use a fileless/web shell-less option of direct PowerShell commands from w3wp (the IIS worker process) for some attacks. While still maintaining their normal email-based campaigns, the Lemon Duck operators compromised numerous Exchange servers and moved in the direction of being more of a malware loader than a simple miner.

Using a form of the attack that allows direct execution of commands versus dropping a web shell, the Lemon Duck operators ran standard Invoke Expression commands to download a payload. Having used the same C2 and download servers for some time, the operators applied a varied degree of obfuscation to their commands on execution.

Fig 7. Example executions of Lemon Duck payload downloads

The Lemon Duck payload is an encoded and obfuscated PowerShell script. It first removes various security products from the system, then creates scheduled tasks and WMI Event subscription for persistence. A second script is downloaded to attempt to evade Microsoft Defender Antivirus, abusing their administrative access to run the Set-MPPreference command to disable real-time monitoring (a tactic that Microsoft Defender Tamper protection blocks) and add scanning exclusions for the C:\ drive and the PowerShell process.

Figure 8. Lemon Duck payloads

One randomly named scheduled task connects to a C2 every hour to download a new payload, which includes various lateral movement and credential theft tools. The operators were seen to download RATs and information stealers, including Ramnit payloads.

Figure 9. Lemon Duck post-exploitation activities

In some instances, the operators took advantage of having compromised mail servers to access mailboxes and send emails containing the Lemon Duck payload using various colorful email subjects.

Figure 10. Email subjects of possibly malicious emails

Figure 11. Attachment variables

In one notable example, the Lemon Duck operators compromised a system that already had xx.bat and a web shell. After establishing persistence on the system in a non-web shell method, the Lemon Duck operators were observed cleaning up other attackers’ presence on the system and mitigating the CVE-2021-26855 (SSRF) vulnerability using a legitimate cleanup script that they hosted on their own malicious server. This action prevents further exploitation of the server and removes web shells, giving Lemon Duck exclusive access to the compromised server. This stresses the need to fully investigate systems that were exposed, even if they have been fully patched and mitigated, per traditional incident response process.

Pydomer ransomware

While DoejoCrypt was a new ransomware payload, the access gained by attackers via the on-premises Exchange Server vulnerabilities will likely become part of the complex cybercriminal economy where additional ransomware operators and affiliates take advantage of it. The first existing ransomware family to capitalize on the vulnerabilities was Pydomer. This ransomware family was previously seen using vulnerabilities in attacks, notably taking advantage of Pulse Secure VPN vulnerabilities, for which Pulse Secure has released security patches, to steal credentials and perform ransomware attacks.

In this campaign, the operators scanned and mass-compromised unpatched Exchange Servers to drop a web shell. They started later than some other attackers, with many compromises occurring between March 18 and March 20, a window when fewer unpatched systems were available. They then dropped a web shell, with a notable file name format: “Chack[Word][Country abbreviation]”:

Figure 12. Example web shell names observed being used by the Pydomer attackers

These web shells were observed on around 1,500 systems, not all of which moved to the ransomware stage. The attackers then used their web shell to dump a test.bat batch file that performed a similar function in the attack chain to the xx.bat of the DoejoCrypt operators and allowed them to perform a dump of the LSASS process.

Figure 13. Pydomer post-exploitation activities

This access alone would be valuable to attackers for later attacks, similar to the credentials gained during their use of Pulse Secure VPN vulnerabilities. The highly privileged credentials gained from an Exchange system are likely to contain domain administrator accounts and service accounts with backup privileges, meaning these attackers could perform ransomware and exfiltration actions against the networks they compromised long after the Exchange Server is patched and even enter via different means.

On systems where the attackers did move to second-stage ransomware operations, they utilized a Python script compiled to an executable and the Python cryptography libraries to encrypt files. The attackers then executed a PowerShell script via their web shell that acts as a downloader and distribution mechanism for the ransomware.

Figure 14. PowerShell downloader and spreader used to get the Pydomer payload

The script fetches a payload from a site hosted on a domain generation algorithm (DGA) domain, and attempts to spread the payload throughout the network, first attempting to spread the payload over WMI using Invoke-WMIMethod to attempt to connect to systems, and falling back to PowerShell remoting with Enter-PSSession if that fails. The script is run within the context of the web shell, which in most instances is Local System, so this lateral movement strategy is unlikely to work except in organizations that are running highly insecure and unrecommended configurations like having computer objects in highly privileged groups.

The Pydomer ransomware is a Python script compiled to an executable and uses the Python cryptography libraries to encrypt files. The ransomware encrypts the files and appends a random extension, and then drops a ransom note named decrypt_file.TxT.

Figure 15. Pydomer ransom note

Interestingly, the attackers seem to have deployed a non-encryption extortion strategy. Following well-known ransomware groups like Maze and Egregor which leaked data for pay, the Pydomer hackers dropped an alternative readme.txt onto systems without encrypting files. This option might have been semi-automated on their part or a side effect of a failure in their encryption process, as some of the systems they accessed were test systems that showed no data exfiltration. The note should be taken seriously if encountered, as the attackers had full access to systems and were likely able to exfiltrate data.

Figure 16. Pydomer extortion readme.txt

Credential theft, turf wars, and dogged persistence

If a server is not running in a least-privilege configuration, credential theft could provide a significant return on investment for an attacker beyond their initial access to email and data. Many organizations have backup agent software and scheduled tasks running on these systems with domain admin-level permissions. For these organizations, the attackers might be able to harvest highly privileged credentials without lateral movement, for example, using the COM services DLL as a living-off-the-land binary to perform a dump of the LSASS process:

Figure 17. Use of COM services DLL to dump LSASS process

The number of observed credential theft attacks, combined with high privilege of accounts often given to Exchange servers, means that these attacks could continue to impact organizations that don’t fully remediate after a compromise even after patches have been applied. While the observed ransomware attempts were small-scale or had errors, there is still the possibility of more skillful groups utilizing credentials gained in these attacks for later attacks.

Attackers also used their access to perform extensive reconnaissance using built-in Exchange commandlets and dsquery to exfiltrate information about network configurations, user information, and email assets.

While Lemon Duck operators might have had the boldest method for removing other attackers from the systems they compromised, they were not the only attacker to do so. Others were observed cleaning up .aspx and .bat files to remove other attackers, and even rebuilding the WMI database by deleting .mof files and restarting the service. As the window on unpatched machines closes, attackers showed increased interest in maintaining the access to the systems they exploited. By utilizing “malwareless” persistence mechanisms like enabling RDP, installing Shadow IT tools, and adding new local administrator accounts, the attackers are hoping to evade incident response efforts that might focus exclusively on web shells, AV scans, and patching.

Defending against exploits and post-compromise activities

Attackers exploit the on-premises Exchange Server vulnerabilities in combination to bypass authentication and gain the ability to write files and run malicious code. The best and most complete remediation for these vulnerabilities is to update to a supported Cumulative Update and to install all security updates. Comprehensive mitigation guidance can be found here: https://aka.ms/ExchangeVulns.

As seen in the post-exploitation attacks discussed in this blog, the paths that attackers can take after successfully exploiting the vulnerabilities are varied and wide-ranging. If you have determined or have reason to suspect that these threats are present on your network, here are immediate steps you can take:

  • Investigate exposed Exchange servers for compromise, regardless of their current patch status.
  • Look for web shells via our guidance and run a full AV scan using the Exchange On-Premises Mitigation Tool.
  • Investigate Local Users and Groups, even non-administrative users for changes, and ensure all users require a password for sign-in. New user account creations (represented by Event ID 4720) during the time the system was vulnerable might indicate a malicious user creation.
  • Reset and randomize local administrator passwords with a tool like LAPS if you are not already doing so.
  • Look for changes to the RDP, firewall, WMI subscriptions, and Windows Remote Management (WinRM) configuration of the system that might have been configured by the attacker to allow persistence.
  • Look for Event ID 1102 to determine if attackers cleared event logs, an activity that attackers perform with exe in an attempt to hide their tracks.
  • Look for new persistence mechanisms such as unexpected services, scheduled tasks, and startup items.
  • Look for Shadow IT tools that attackers might have installed for persistence, such as non-Microsoft RDP and remote access clients.
  • Check mailbox-level email forwarding settings (both ForwardingAddress and ForwardingSMTPAddress attributes), check mailbox inbox rules (which might be used to forward email externally), and check Exchange Transport rules that you might not recognize.

While our response tools check for and remove known web shells and attack tools, performing a full investigation of these systems is recommended. For comprehensive investigation and mitigation guidance and tools, see https://aka.ms/exchange-customer-guidance.

Additionally, here are best practices for building credential hygiene and practicing the principle of least privilege:

  • Follow guidance to run Exchange in least-privilege configuration: https://adsecurity.org/?p=4119.
  • Ensure service accounts and scheduled tasks run with the least privileges they need. Avoid widely privileged groups like domain admins and backup operators and prefer accounts with access to just the systems they need.
  • Randomize local administrator passwords to prevent lateral movement with tools like LAPS.
  • Ensure administrators practice good administration habits like Privileged Admin Workstations.
  • Prevent privileged accounts like domain admins from signing into member servers and workstations using Group Policy to limit credential exposure and lateral movement.

 

Appendix

Microsoft Defender for Endpoint detection details

Antivirus                                                                                                                                   

Microsoft Defender Antivirus detects exploitation behavior with these detections:

Web shells are detected as:

Ransomware payloads and associated files are detected as:

Lemon Duck malware is detected as:

Some of the credential theft techniques highlighted in this report are detected as:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Suspicious w3wp.exe activity in Exchange
  • Possible exploitation of Exchange Server vulnerabilities
  • Possible IIS web shell
  • Possible web shell installation
  • Web shells associated with Exchange Server vulnerabilities
  • Network traffic associated with Exchange Server exploitation

Alerts with the following titles in the security center can indicate threat activity on your network specific to the DoejoCrypt and Pydomer ransomware campaign:

  • DoejoCrypt ransomware
  • Pydomer ransomware
  • Pydomer download site

Alerts with the following titles in the security center can indicate threat activity on your network specific to the Lemon Duck botnet:

  • LemonDuck Malware
  • LemonDuck botnet C2 domain activity

The following behavioral alerts might also indicate threat activity associated with this threat:

  • Possible web shell installation
  • A suspicious web script was created
  • Suspicious processes indicative of a web shell
  • Suspicious file attribute change
  • Suspicious PowerShell command line
  • Possible IIS Web Shell
  • Process memory dump
  • A malicious PowerShell Cmdlet was invoked on the machine
  • WDigest configuration change
  • Sensitive information lookup
  • Suspicious registry export

Advanced hunting

To locate possible exploitation activities in Microsoft Defender for Endpoint, run the following queries.

Processes run by the IIS worker process

Look for processes executed by the IIS worker process

// Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for PowerShell spawned from the IIS worker process, observed most frequently in Lemon Duck with Base64 encoding to obfuscate C2 domains

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine contains "MSExchange"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Tampering

Search for Lemon Duck tampering with Microsoft Defender Antivirus

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference", "ExclusionProcess")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Batch script actions

Search for batch scripts performing credential theft, as observed in DoejoCrypt infections

DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"C:\Windows\Temp"
| where ProcessCommandLine has "reg save"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Look for evidence of batch script execution that leads to credential dumping

// Search for batch script execution, leading to credential dumping using rundll32 and the COM Services DLL, dsquery, and makecab use
DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"\inetpub\wwwroot\aspnet_client\"
| where InitiatingProcessParentFileName has "w3wp"
| where FileName != "conhost.exe"
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Suspicious files dropped under an aspnet_client folder

Look for dropped suspicious files like web shells and other components

// Search for suspicious files, including but not limited to batch scripts and web shells, dropped under the file path C:\inetpub\wwwroot\aspnet_client\
DeviceFileEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "\\aspnet_client\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName, FolderPath, InitiatingProcessCommandLine, DeviceId, Timestamp

Checking for persistence on systems that have been suspected as compromised

Search for creations of new local accounts

DeviceProcessEvents
| where FileName == "net.exe"
| where ProcessCommandLine has_all ("user", "add")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for installation events that were used to download ScreenConnect for persistence

Note that this query may be noisy and is not necessarily indicative of malicious activity alone.

DeviceProcessEvents
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has @"C:\Windows\Temp\"
| parse-where kind=regex flags=i ProcessCommandLine with @"C:\\Windows\\Temp\\" filename:string @".msi"
| project filename, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Hunting for credential theft

Search for logon events related to services and scheduled tasks on devices that may be Exchange servers. The results of this query should be used to verify whether any of these users have privileged roles that might have enabled further persistence.

let devices =
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe" and InitiatingProcessCommandLine contains "MSExchange"
| distinct DeviceId;
//
DeviceLogonEvents
| where DeviceId in (devices)
| where LogonType in ("Batch", "Service")
| project AccountName, AccountDomain, LogonType, DeviceId, Timestamp

Search for WDigest registry key modification, which allows for the LSASS process to store plaintext passwords.

DeviceRegistryEvents
| where RegistryValueName == "UseLogonCredential"
| where RegistryKey has "WDigest" and RegistryValueData == "1"
| project PreviousRegistryValueData, RegistryValueData, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for the COM services DLL being executed by rundll32, which can be used to dump LSASS memory.

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("rundll32.exe", "comsvcs.dll")
| project FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for Security Account Manager (SAM) or SECURITY databases being saved, from which credentials can later be extracted.

DeviceProcessEvents
| where FileName == "reg.exe"
| where ProcessCommandLine has "save" and ProcessCommandLine has_any ("hklm\\security", "hklm\\sam")
| project InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Indicators

Selected indicators from attacks are included here, the threats may utilize files and network indicators not represented here.

Files (SHA-256)

The following are file hashes for some of the web shells observed during attacks:

  • 201e4e9910dcdc8c4ffad84b60b328978db8848d265c0b9ba8473cf65dcd0c41
  • 2f0bc81c2ea269643cae307239124d1b6479847867b1adfe9ae712a1d5ef135e
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 8e90ed33c7ee82c0b64078ea36ec95f7420ba435c693b3b3dd728b494abf7dfc
  • a291305f181e24fe7194154b4cd355ccb039d5765709c80999e392efec69c90a
  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • dd29e8d47dde124c7d14e614e03ccaab3ecaa50e0a0bef985ed59e98928bc13d

DoejoCrypt associated hashes:

  • 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
  • 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
  • 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
  • 904fbea2cd68383f32c5bc630d2227601dc52f94790fe7a6a7b6d44bfd904ff3
  • bf53b637683f9cbf92b0dd6c97742787adfbc12497811d458177fdeeae9ec748
  • e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6
  • fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
  • feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

Lemon Duck associated hashes:

  • 0993cc228a74381773a3bb0aa36a736f5c41075fa3201bdef4215a8704e582fc
  • 3df23c003d62c35bd6da90df12826c1d3fdd94029bf52449ba3d89920110d5ec
  • 4f0b9c0482595eee6d9ece0705867b2aae9e4ff68210f32b7425caca763723b9
  • 56101ab0881a6a34513a949afb5a204cad06fd1034f37d6791f3ab31486ba56c
  • 69ce57932c3be3374e8843602df1c93e1af622fc53f3f1d9b0a75b66230a1e2e
  • 737752588f32e4c1d8d20231d7ec553a1bd4a0a090b06b2a1835efa08f9707c4
  • 893ddf0de722f345b675fd1ade93ee1de6f1cad034004f9165a696a4a4758c3e
  • 9cf63310788e97f6e08598309cbbf19960162123e344df017b066ca8fcbed719
  • 9f2fe33b1c7230ec583d7f6ad3135abcc41b5330fa5b468b1c998380d20916cd
  • a70931ebb1ce4f4e7d331141ad9eba8f16f98da1b079021eeba875aff4aeaa85
  • d8b5eaae03098bead91ff620656b9cfc569e5ac1befd0f55aee4cdb39e832b09
  • db093418921aae00187ae5dc6ed141c83614e6a4ec33b7bd5262b7be0e9df2cd
  • dc612f5c0b115b5a13bdb9e86f89c5bfe232e5eb76a07c3c0a6d949f80af89fd
  • f517526fc57eb33edb832920b1678d52ad1c5cf9c707859551fe065727587501
  • f8d388f502403f63a95c9879c806e6799efff609001701eed409a8d33e55da2f
  • fbeefca700f84373509fd729579ad7ea0dabdfe25848f44b2fbf61bf7f909df0

Pydomer associated hashes:

  • 7e07b6addf2f0d26eb17f4a1be1cba11ca8779b0677cedc30dbebef77ccba382
  • 866b1f5c5edd9f01c5ba84d02e94ae7c1f9b2196af380eed1917e8fc21acbbdc
  • 910fbfa8ef4ad7183c1b5bdd3c9fd1380e617ca0042b428873c48f71ddc857db
  • a387c3c5776ee1b61018eeb3408fa7fa7490915146078d65b95621315e8b4287
  • b9dbdf11da3630f464b8daace88e11c374a642e5082850e9f10a1b09d69ff04f
  • c25a5c14269c990c94a4a20443c4eb266318200e4d7927c163e0eaec4ede780a
  • c4aa94c73a50b2deca0401f97e4202337e522be3df629b3ef91e706488b64908

Network indicators

Domains abused by Lemon Duck:

  • down[.]sqlnetcat[.]com
  • t[.]sqlnetcat[.]com
  • t[.]netcatkit[.]com

Pydomer DGA network indicators:

  • uiiuui[.]com/search/*
  • yuuuuu43[.]com/vpn-service/*
  • yuuuuu44[.]com/vpn-service/*
  • yuuuuu46[.]com/search/*

The post Analyzing attacks taking advantage of the Exchange Server vulnerabilities appeared first on Microsoft Security.

Analyzing attacks taking advantage of the Exchange Server vulnerabilities

March 25th, 2021 No comments

Microsoft continues to monitor and investigate attacks exploiting the recent on-premises Exchange Server vulnerabilities. These attacks are now performed by multiple threat actors ranging from financially motivated cybercriminals to state-sponsored groups. To help customers who are not able to immediately install updates, Microsoft released a one-click tool that automatically mitigates one of the vulnerabilities and scans servers for known attacks. Microsoft also built this capability into Microsoft Defender Antivirus, expanding the reach of the mitigation. As of today, we have seen a significant decrease in the number of still-vulnerable servers – more than 92% of known worldwide Exchange IPs are now patched or mitigated. We continue to work with our customers and partners to mitigate the vulnerabilities.

As organizations recover from this incident, we continue to publish guidance and share threat intelligence to help detect and evict threat actors from affected environments. Today, we are sharing intelligence about what some attackers did after exploiting the vulnerable servers, ranging from ransomware to data exfiltration and deployment of various second-stage payloads. This blog covers:

  • Threat intelligence and technical details about known attacks, including components and attack paths, that defenders can use to investigate whether on-premises Exchange servers were compromised before they were patched and to comprehensively respond to and remediate these threats if they see them in their environments.
  • Detection and automatic remediation built into Microsoft Defender Antivirus and how investigation and remediation capabilities in solutions like Microsoft Defender for Endpoint can help responders perform additional hunting and remediate threats.

Although the overall numbers of ransomware have remained extremely small to this point, it is important to remember that these threats show how quickly attackers can pivot their campaigns to take advantage of newly disclosed vulnerabilities and target unpatched systems, demonstrating how critical it is for organizations to apply security updates as soon as possible. We strongly urge organizations to identify and update vulnerable on-premises Exchange servers, and to follow mitigation and investigation guidance that we have collected and continue to update here: https://aka.ms/ExchangeVulns.

Mitigating post-exploitation activities

The first known attacks leveraging the Exchange Server vulnerabilities were by the nation-state actor HAFNIUM, which we detailed in this blog. In the three weeks after the Exchange server vulnerabilities were disclosed and the security updates were released, Microsoft saw numerous other attackers adopting the exploit into their toolkits. Attackers are known to rapidly work to reverse engineer patches and develop exploits. In the case of a remote code execution (RCE) vulnerability, the rewards are high for attackers who can gain access before an organization patches, as patching a system does not necessarily remove the access of the attacker.

Figure 1. The Exchange Server exploit chain

In our investigation of the on-premises Exchange Server attacks , we saw systems being affected by multiple threats. Many of the compromised systems have not yet received a secondary action, such as human-operated ransomware attacks or data exfiltration, indicating attackers could be establishing and keeping their access for potential later actions. These actions might involve performing follow-on attacks via persistence on Exchange servers they have already compromised, or using credentials and data stolen during these attacks to compromise networks through other entry vectors.

Attackers who included the exploit in their toolkits, whether through modifying public proof of concept exploits or their own research, capitalized on their window of opportunity to gain access to as many systems as they could. Some attackers were advanced enough to remove other attackers from the systems and use multiple persistence points to maintain access to a network.

We have built protections against these threats into Microsoft security solutions. Refer to the Appendix for a list of indicators of compromise, detection details, and advanced hunting queries. We have also provided additional tools and investigation and remediation guidance here: https://aka.ms/exchange-customer-guidance.

While performing a full investigation on systems is recommended, the following themes are common in many of the attacks. These are prevailing threat trends that Microsoft has been monitoring, and existing solutions and recommendations for prevention and mitigation apply:

  • Web shells – As of this writing, many of the unpatched systems we observed had multiple web shells on them. Microsoft has been tracking the rise of web shell attacks for the past few years, ensuring our products detect these threats and providing remediation guidance for customers. For more info on web shells, read Web shell attacks continue to rise. We have also published guidance on web shell threat hunting with Azure Sentinel.
  • Human-operated ransomware – Ransomware attacks pose some of the biggest security risks for organizations today, and attackers behind these attacks were quick to take advantage of the on-premises Exchange Server vulnerabilities. Successfully exploiting the vulnerabilities gives attackers the ability to launch human-operated ransomware campaigns, a trend that Microsoft has been closely monitoring. For more information about human-operated ransomware attacks, including Microsoft solutions and guidance for improving defenses, read: Human-operated ransomware attacks.
  • Credential theft – While credential theft is not the immediate goal of some of these attacks, access to Exchange servers allowed attackers to access and potentially steal credentials present on the system. Attackers can use these stolen credentials for follow-on attacks later, so organizations need to prioritize identifying and remediating impacted identities. For more information, read best practices for building credential hygiene.

In the following sections, we share our analysis of known post-compromise activities associated with exploitation of the Exchange server vulnerabilities because it is helpful to understand these TTPs, in order to defend against other actors using similar tactics or tools. While levels of disruptive post-compromise activity like ransomware may be limited at the time of this writing, Microsoft will continue to track this space and share information with the community. It’s important to note that with some post-compromise techniques, attackers may gain highly privileged persistent access, but many of the impactful subsequent attacker activities can be mitigated by practicing the principle of least privilege and mitigating lateral movement.

DoejoCrypt ransomware

DoejoCrypt was the first ransomware to appear to take advantage of the vulnerabilities, starting to encrypt in limited numbers shortly after the patches were released. Ransomware attackers often use multiple tools and exploits to gain initial access, including purchasing access through a broker or “reseller” who sells access to systems they have already compromised. The DoejoCrypt attacks start with a variant of the Chopper web shell being deployed to the Exchange server post-exploitation.

The web shell writes a batch file to C:\Windows\Temp\xx.bat. Found on all systems that received the DoejoCrypt ransomware payload, this batch file performs a backup of the Security Account Manager (SAM) database and the System and Security registry hives, allowing the attackers later access to passwords of local users on the system and, more critically, in the LSA Secrets portion of the registry, where passwords for services and scheduled tasks are stored.

Figure 2. xx.bat

Given configurations that administrators typically use on Exchange servers, many of the compromised systems are likely to have had at least one service or scheduled task configured with a highly privileged account to perform actions like backups. As service account credentials are not frequently changed, this could provide a great advantage to an attacker even if they lose their initial web shell access due to an antivirus detection, as the account can be used to elevate privileges later, which is why we strongly recommend operating under the principle of least privileged access.

The batch file saves the registry hives to a semi-unique location, C:\windows\temp\debugsms, assembles them into a CAB file for exfiltration, and then cleans up the folders from the system. The file also enables Windows Remote Management and sets up an HTTP listener, indicating the attacker might take advantage of the internet-facing nature of an Exchange Server and use this method for later access if other tools are removed.

Figure 3. xx.bat actions

The xx.bat file has been run on many more systems than have been ransomed by the DoejoCrypt attacker, meaning that, while not all systems have moved to the ransom stage, the attacker has gained access to multiple credentials. On systems where the attacker moved to the ransom stage, we saw reconnaissance commands being run via the same web shell that dopped the xx.bat file (in this instance, a version of Chopper):

Figure 4. DoejoCrypt recon command

After these commands are completed, the web shell drops a new payload to C:\Windows\Help which, like in many human-operated ransomware campaigns, leads to the attack framework Cobalt Strike. In observed instances, the downloaded payload is shellcode with the file name new443.exe or Direct_Load.exe. When run, this payload injects itself into notepad.exe and reaches out to a C2 to download Cobalt Strike shellcode.

Figure 5. DoejoCrypt ransomware attack chain

During the hands-on-keyboard stage of the attack, a new payload is downloaded to C:\Windows\Help with names like s1.exe and s2.exe. This payload is the DoejoCrypt ransomware, which uses a .CRYPT extension for the newly encrypted files and a very basic readme.txt ransom note. In some instances, the time between xx.bat being dropped and a ransomware payload running was under half an hour.

Figure 6. DoejoCrypt ransom note

While the DoejoCrypt payload is the most visible outcome of this attackers’ actions, the access to credentials they have gained could serve them for future campaigns if organizations do not reset credentials on compromised systems. An additional overlapping activity observed on systems where xx.bat was present and the attackers were able to get Domain Administrator rights was the running of scripts to snapshot Active Directory with ntdsutil—an action that, if executed successfully, could give the attackers access to all the passwords in Active Directory from a single compromised system.

Lemon Duck botnet

Cryptocurrency miners were some of the first payloads we observed being dropped by attackers from the post-exploit web shells. In the first few days after the security updates were released, we observed multiple cryptocurrency miner campaigns, which had been previously targeting SharePoint servers, add Exchange Server exploitation to their repertoire. Most of these coin miners were variations on XMRig miners, and many arrived via a multi-featured implant with the capability to download new payloads or even move laterally.

Lemon Duck, a known cryptocurrency botnet named for a variable in its code, dove into the Exchange exploit action, adopting different exploit styles and choosing to use a fileless/web shell-less option of direct PowerShell commands from w3wp (the IIS worker process) for some attacks. While still maintaining their normal email-based campaigns, the Lemon Duck operators compromised numerous Exchange servers and moved in the direction of being more of a malware loader than a simple miner.

Using a form of the attack that allows direct execution of commands versus dropping a web shell, the Lemon Duck operators ran standard Invoke Expression commands to download a payload. Having used the same C2 and download servers for some time, the operators applied a varied degree of obfuscation to their commands on execution.

Fig 7. Example executions of Lemon Duck payload downloads

The Lemon Duck payload is an encoded and obfuscated PowerShell script. It first removes various security products from the system, then creates scheduled tasks and WMI Event subscription for persistence. A second script is downloaded to attempt to evade Microsoft Defender Antivirus, abusing their administrative access to run the Set-MPPreference command to disable real-time monitoring (a tactic that Microsoft Defender Tamper protection blocks) and add scanning exclusions for the C:\ drive and the PowerShell process.

Figure 8. Lemon Duck payloads

One randomly named scheduled task connects to a C2 every hour to download a new payload, which includes various lateral movement and credential theft tools. The operators were seen to download RATs and information stealers, including Ramnit payloads.

Figure 9. Lemon Duck post-exploitation activities

In some instances, the operators took advantage of having compromised mail servers to access mailboxes and send emails containing the Lemon Duck payload using various colorful email subjects.

Figure 10. Email subjects of possibly malicious emails

Figure 11. Attachment variables

In one notable example, the Lemon Duck operators compromised a system that already had xx.bat and a web shell. After establishing persistence on the system in a non-web shell method, the Lemon Duck operators were observed cleaning up other attackers’ presence on the system and mitigating the CVE-2021-26855 (SSRF) vulnerability using a legitimate cleanup script that they hosted on their own malicious server. This action prevents further exploitation of the server and removes web shells, giving Lemon Duck exclusive access to the compromised server. This stresses the need to fully investigate systems that were exposed, even if they have been fully patched and mitigated, per traditional incident response process.

Pydomer ransomware

While DoejoCrypt was a new ransomware payload, the access gained by attackers via the on-premises Exchange Server vulnerabilities will likely become part of the complex cybercriminal economy where additional ransomware operators and affiliates take advantage of it. The first existing ransomware family to capitalize on the vulnerabilities was Pydomer. This ransomware family was previously seen using vulnerabilities in attacks, notably taking advantage of Pulse Secure VPN vulnerabilities, for which Pulse Secure has released security patches, to steal credentials and perform ransomware attacks.

In this campaign, the operators scanned and mass-compromised unpatched Exchange Servers to drop a web shell. They started later than some other attackers, with many compromises occurring between March 18 and March 20, a window when fewer unpatched systems were available. They then dropped a web shell, with a notable file name format: “Chack[Word][Country abbreviation]”:

Figure 12. Example web shell names observed being used by the Pydomer attackers

These web shells were observed on around 1,500 systems, not all of which moved to the ransomware stage. The attackers then used their web shell to dump a test.bat batch file that performed a similar function in the attack chain to the xx.bat of the DoejoCrypt operators and allowed them to perform a dump of the LSASS process.

Figure 13. Pydomer post-exploitation activities

This access alone would be valuable to attackers for later attacks, similar to the credentials gained during their use of Pulse Secure VPN vulnerabilities. The highly privileged credentials gained from an Exchange system are likely to contain domain administrator accounts and service accounts with backup privileges, meaning these attackers could perform ransomware and exfiltration actions against the networks they compromised long after the Exchange Server is patched and even enter via different means.

On systems where the attackers did move to second-stage ransomware operations, they utilized a Python script compiled to an executable and the Python cryptography libraries to encrypt files. The attackers then executed a PowerShell script via their web shell that acts as a downloader and distribution mechanism for the ransomware.

Figure 14. PowerShell downloader and spreader used to get the Pydomer payload

The script fetches a payload from a site hosted on a domain generation algorithm (DGA) domain, and attempts to spread the payload throughout the network, first attempting to spread the payload over WMI using Invoke-WMIMethod to attempt to connect to systems, and falling back to PowerShell remoting with Enter-PSSession if that fails. The script is run within the context of the web shell, which in most instances is Local System, so this lateral movement strategy is unlikely to work except in organizations that are running highly insecure and unrecommended configurations like having computer objects in highly privileged groups.

The Pydomer ransomware is a Python script compiled to an executable and uses the Python cryptography libraries to encrypt files. The ransomware encrypts the files and appends a random extension, and then drops a ransom note named decrypt_file.TxT.

Figure 15. Pydomer ransom note

Interestingly, the attackers seem to have deployed a non-encryption extortion strategy. Following well-known ransomware groups like Maze and Egregor which leaked data for pay, the Pydomer hackers dropped an alternative readme.txt onto systems without encrypting files. This option might have been semi-automated on their part or a side effect of a failure in their encryption process, as some of the systems they accessed were test systems that showed no data exfiltration. The note should be taken seriously if encountered, as the attackers had full access to systems and were likely able to exfiltrate data.

Figure 16. Pydomer extortion readme.txt

Credential theft, turf wars, and dogged persistence

If a server is not running in a least-privilege configuration, credential theft could provide a significant return on investment for an attacker beyond their initial access to email and data. Many organizations have backup agent software and scheduled tasks running on these systems with domain admin-level permissions. For these organizations, the attackers might be able to harvest highly privileged credentials without lateral movement, for example, using the COM services DLL as a living-off-the-land binary to perform a dump of the LSASS process:

Figure 17. Use of COM services DLL to dump LSASS process

The number of observed credential theft attacks, combined with high privilege of accounts often given to Exchange servers, means that these attacks could continue to impact organizations that don’t fully remediate after a compromise even after patches have been applied. While the observed ransomware attempts were small-scale or had errors, there is still the possibility of more skillful groups utilizing credentials gained in these attacks for later attacks.

Attackers also used their access to perform extensive reconnaissance using built-in Exchange commandlets and dsquery to exfiltrate information about network configurations, user information, and email assets.

While Lemon Duck operators might have had the boldest method for removing other attackers from the systems they compromised, they were not the only attacker to do so. Others were observed cleaning up .aspx and .bat files to remove other attackers, and even rebuilding the WMI database by deleting .mof files and restarting the service. As the window on unpatched machines closes, attackers showed increased interest in maintaining the access to the systems they exploited. By utilizing “malwareless” persistence mechanisms like enabling RDP, installing Shadow IT tools, and adding new local administrator accounts, the attackers are hoping to evade incident response efforts that might focus exclusively on web shells, AV scans, and patching.

Defending against exploits and post-compromise activities

Attackers exploit the on-premises Exchange Server vulnerabilities in combination to bypass authentication and gain the ability to write files and run malicious code. The best and most complete remediation for these vulnerabilities is to update to a supported Cumulative Update and to install all security updates. Comprehensive mitigation guidance can be found here: https://aka.ms/ExchangeVulns.

As seen in the post-exploitation attacks discussed in this blog, the paths that attackers can take after successfully exploiting the vulnerabilities are varied and wide-ranging. If you have determined or have reason to suspect that these threats are present on your network, here are immediate steps you can take:

  • Investigate exposed Exchange servers for compromise, regardless of their current patch status.
  • Look for web shells via our guidance and run a full AV scan using the Exchange On-Premises Mitigation Tool.
  • Investigate Local Users and Groups, even non-administrative users for changes, and ensure all users require a password for sign-in. New user account creations (represented by Event ID 4720) during the time the system was vulnerable might indicate a malicious user creation.
  • Reset and randomize local administrator passwords with a tool like LAPS if you are not already doing so.
  • Look for changes to the RDP, firewall, WMI subscriptions, and Windows Remote Management (WinRM) configuration of the system that might have been configured by the attacker to allow persistence.
  • Look for Event ID 1102 to determine if attackers cleared event logs, an activity that attackers perform with exe in an attempt to hide their tracks.
  • Look for new persistence mechanisms such as unexpected services, scheduled tasks, and startup items.
  • Look for Shadow IT tools that attackers might have installed for persistence, such as non-Microsoft RDP and remote access clients.
  • Check mailbox-level email forwarding settings (both ForwardingAddress and ForwardingSMTPAddress attributes), check mailbox inbox rules (which might be used to forward email externally), and check Exchange Transport rules that you might not recognize.

While our response tools check for and remove known web shells and attack tools, performing a full investigation of these systems is recommended. For comprehensive investigation and mitigation guidance and tools, see https://aka.ms/exchange-customer-guidance.

Additionally, here are best practices for building credential hygiene and practicing the principle of least privilege:

  • Follow guidance to run Exchange in least-privilege configuration: https://adsecurity.org/?p=4119.
  • Ensure service accounts and scheduled tasks run with the least privileges they need. Avoid widely privileged groups like domain admins and backup operators and prefer accounts with access to just the systems they need.
  • Randomize local administrator passwords to prevent lateral movement with tools like LAPS.
  • Ensure administrators practice good administration habits like Privileged Admin Workstations.
  • Prevent privileged accounts like domain admins from signing into member servers and workstations using Group Policy to limit credential exposure and lateral movement.

 

Appendix

Microsoft Defender for Endpoint detection details

Antivirus                                                                                                                                   

Microsoft Defender Antivirus detects exploitation behavior with these detections:

Web shells are detected as:

Ransomware payloads and associated files are detected as:

Lemon Duck malware is detected as:

Some of the credential theft techniques highlighted in this report are detected as:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Suspicious w3wp.exe activity in Exchange
  • Possible exploitation of Exchange Server vulnerabilities
  • Possible IIS web shell
  • Possible web shell installation
  • Web shells associated with Exchange Server vulnerabilities
  • Network traffic associated with Exchange Server exploitation

Alerts with the following titles in the security center can indicate threat activity on your network specific to the DoejoCrypt and Pydomer ransomware campaign:

  • DoejoCrypt ransomware
  • Pydomer ransomware
  • Pydomer download site

Alerts with the following titles in the security center can indicate threat activity on your network specific to the Lemon Duck botnet:

  • LemonDuck Malware
  • LemonDuck botnet C2 domain activity

The following behavioral alerts might also indicate threat activity associated with this threat:

  • Possible web shell installation
  • A suspicious web script was created
  • Suspicious processes indicative of a web shell
  • Suspicious file attribute change
  • Suspicious PowerShell command line
  • Possible IIS Web Shell
  • Process memory dump
  • A malicious PowerShell Cmdlet was invoked on the machine
  • WDigest configuration change
  • Sensitive information lookup
  • Suspicious registry export

Advanced hunting

To locate possible exploitation activities in Microsoft Defender for Endpoint, run the following queries.

Processes run by the IIS worker process

Look for processes executed by the IIS worker process

// Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for PowerShell spawned from the IIS worker process, observed most frequently in Lemon Duck with Base64 encoding to obfuscate C2 domains

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine contains "MSExchange"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Tampering

Search for Lemon Duck tampering with Microsoft Defender Antivirus

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference", "ExclusionProcess")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Batch script actions

Search for batch scripts performing credential theft, as observed in DoejoCrypt infections

DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"C:\Windows\Temp"
| where ProcessCommandLine has "reg save"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Look for evidence of batch script execution that leads to credential dumping

// Search for batch script execution, leading to credential dumping using rundll32 and the COM Services DLL, dsquery, and makecab use
DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"\inetpub\wwwroot\aspnet_client\"
| where InitiatingProcessParentFileName has "w3wp"
| where FileName != "conhost.exe"
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Suspicious files dropped under an aspnet_client folder

Look for dropped suspicious files like web shells and other components

// Search for suspicious files, including but not limited to batch scripts and web shells, dropped under the file path C:\inetpub\wwwroot\aspnet_client\
DeviceFileEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "\\aspnet_client\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName, FolderPath, InitiatingProcessCommandLine, DeviceId, Timestamp

Checking for persistence on systems that have been suspected as compromised

Search for creations of new local accounts

DeviceProcessEvents
| where FileName == "net.exe"
| where ProcessCommandLine has_all ("user", "add")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for installation events that were used to download ScreenConnect for persistence

Note that this query may be noisy and is not necessarily indicative of malicious activity alone.

DeviceProcessEvents
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has @"C:\Windows\Temp\"
| parse-where kind=regex flags=i ProcessCommandLine with @"C:\\Windows\\Temp\\" filename:string @".msi"
| project filename, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Hunting for credential theft

Search for logon events related to services and scheduled tasks on devices that may be Exchange servers. The results of this query should be used to verify whether any of these users have privileged roles that might have enabled further persistence.

let devices =
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe" and InitiatingProcessCommandLine contains "MSExchange"
| distinct DeviceId;
//
DeviceLogonEvents
| where DeviceId in (devices)
| where LogonType in ("Batch", "Service")
| project AccountName, AccountDomain, LogonType, DeviceId, Timestamp

Search for WDigest registry key modification, which allows for the LSASS process to store plaintext passwords.

DeviceRegistryEvents
| where RegistryValueName == "UseLogonCredential"
| where RegistryKey has "WDigest" and RegistryValueData == "1"
| project PreviousRegistryValueData, RegistryValueData, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for the COM services DLL being executed by rundll32, which can be used to dump LSASS memory.

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("rundll32.exe", "comsvcs.dll")
| project FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for Security Account Manager (SAM) or SECURITY databases being saved, from which credentials can later be extracted.

DeviceProcessEvents
| where FileName == "reg.exe"
| where ProcessCommandLine has "save" and ProcessCommandLine has_any ("hklm\\security", "hklm\\sam")
| project InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Indicators

Selected indicators from attacks are included here, the threats may utilize files and network indicators not represented here.

Files (SHA-256)

The following are file hashes for some of the web shells observed during attacks:

  • 201e4e9910dcdc8c4ffad84b60b328978db8848d265c0b9ba8473cf65dcd0c41
  • 2f0bc81c2ea269643cae307239124d1b6479847867b1adfe9ae712a1d5ef135e
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 8e90ed33c7ee82c0b64078ea36ec95f7420ba435c693b3b3dd728b494abf7dfc
  • a291305f181e24fe7194154b4cd355ccb039d5765709c80999e392efec69c90a
  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • dd29e8d47dde124c7d14e614e03ccaab3ecaa50e0a0bef985ed59e98928bc13d

DoejoCrypt associated hashes:

  • 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
  • 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
  • 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
  • 904fbea2cd68383f32c5bc630d2227601dc52f94790fe7a6a7b6d44bfd904ff3
  • bf53b637683f9cbf92b0dd6c97742787adfbc12497811d458177fdeeae9ec748
  • e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6
  • fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
  • feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

Lemon Duck associated hashes:

  • 0993cc228a74381773a3bb0aa36a736f5c41075fa3201bdef4215a8704e582fc
  • 3df23c003d62c35bd6da90df12826c1d3fdd94029bf52449ba3d89920110d5ec
  • 4f0b9c0482595eee6d9ece0705867b2aae9e4ff68210f32b7425caca763723b9
  • 56101ab0881a6a34513a949afb5a204cad06fd1034f37d6791f3ab31486ba56c
  • 69ce57932c3be3374e8843602df1c93e1af622fc53f3f1d9b0a75b66230a1e2e
  • 737752588f32e4c1d8d20231d7ec553a1bd4a0a090b06b2a1835efa08f9707c4
  • 893ddf0de722f345b675fd1ade93ee1de6f1cad034004f9165a696a4a4758c3e
  • 9cf63310788e97f6e08598309cbbf19960162123e344df017b066ca8fcbed719
  • 9f2fe33b1c7230ec583d7f6ad3135abcc41b5330fa5b468b1c998380d20916cd
  • a70931ebb1ce4f4e7d331141ad9eba8f16f98da1b079021eeba875aff4aeaa85
  • d8b5eaae03098bead91ff620656b9cfc569e5ac1befd0f55aee4cdb39e832b09
  • db093418921aae00187ae5dc6ed141c83614e6a4ec33b7bd5262b7be0e9df2cd
  • dc612f5c0b115b5a13bdb9e86f89c5bfe232e5eb76a07c3c0a6d949f80af89fd
  • f517526fc57eb33edb832920b1678d52ad1c5cf9c707859551fe065727587501
  • f8d388f502403f63a95c9879c806e6799efff609001701eed409a8d33e55da2f
  • fbeefca700f84373509fd729579ad7ea0dabdfe25848f44b2fbf61bf7f909df0

Pydomer associated hashes:

  • 7e07b6addf2f0d26eb17f4a1be1cba11ca8779b0677cedc30dbebef77ccba382
  • 866b1f5c5edd9f01c5ba84d02e94ae7c1f9b2196af380eed1917e8fc21acbbdc
  • 910fbfa8ef4ad7183c1b5bdd3c9fd1380e617ca0042b428873c48f71ddc857db
  • a387c3c5776ee1b61018eeb3408fa7fa7490915146078d65b95621315e8b4287
  • b9dbdf11da3630f464b8daace88e11c374a642e5082850e9f10a1b09d69ff04f
  • c25a5c14269c990c94a4a20443c4eb266318200e4d7927c163e0eaec4ede780a
  • c4aa94c73a50b2deca0401f97e4202337e522be3df629b3ef91e706488b64908

Network indicators

Domains abused by Lemon Duck:

  • down[.]sqlnetcat[.]com
  • t[.]sqlnetcat[.]com
  • t[.]netcatkit[.]com

Pydomer DGA network indicators:

  • uiiuui[.]com/search/*
  • yuuuuu43[.]com/vpn-service/*
  • yuuuuu44[.]com/vpn-service/*
  • yuuuuu46[.]com/search/*

The post Analyzing attacks taking advantage of the Exchange Server vulnerabilities appeared first on Microsoft Security.

Automatic on-premises Exchange Server mitigation now in Microsoft Defender Antivirus

March 18th, 2021 No comments

As cybercriminals continue to exploit unpatched on-premises versions of Exchange Server 2013, 2016, and 2019, we continue to actively work with customers and partners to help them secure their environments and respond to associated threats. To date, we have released a comprehensive Security Update, a one-click interim Exchange On-Premises Mitigation Tool for both current and out-of-support versions of on-premises Exchange Servers, and step-by-step guidance to help address these attacks.

Today, we have taken an additional step to further support our customers who are still vulnerable and have not yet implemented the complete security update. With the latest security intelligence update, Microsoft Defender Antivirus and System Center Endpoint Protection will automatically mitigate CVE-2021-26855 on any vulnerable Exchange Server on which it is deployed. Customers do not need to take action beyond ensuring they have installed the latest security intelligence update (build 1.333.747.0 or newer), if they do not already have automatic updates turned on.

The Exchange security update is still the most comprehensive way to protect your servers from these attacks and others fixed in earlier releases. This interim mitigation is designed to help protect customers while they take the time to implement the latest Exchange Cumulative Update for their version of Exchange.

Microsoft will provide guidance to our security partners so that they have the option to make available similar, simple mitigations in their products as well.

We are deeply committed to protecting our customers.  To stay up to date please continue to review the content posted at https://aka.ms/exchangevulns.

Frequently Asked Questions

Q: If I have Microsoft Defender Antivirus installed on my Exchange Server do I need to take any further action to get this mitigation?

A: Customers that install Microsoft Defender Antivirus and have automatic definition updates enabled (default setting) do not have to take further action to receive the mitigation.

Q: My organization manages Microsoft Defender Antivirus definition updates.  What do I need to do to ensure I have this mitigation?

A: Customers that manage Microsoft Defender Antivirus definition updates need to select the new detection build (1.333.747.0 or newer) and deploy that to the Exchange Server.

Q: After this mitigation, do I still need to install the security update?

A: Yes.  This automatic mitigation breaks the attack chain by mitigating CVE-2021-26855.  Customers should still prioritize getting current on security updates for Exchange Server to comprehensively address the vulnerabilities.

Q: When does Microsoft Defender Antivirus apply the mitigation?

A: Microsoft Defender Antivirus will automatically identify if a vulnerable version of Exchange Server is installed and apply the mitigations the first time the security intelligence update is deployed.  The mitigation is deployed once per machine.

Q: Is cloud protection required to receive the mitigation?

A: No.  However, enabling cloud protection is a best practice that will keep you with the most current protections against the ever-changing threat environment.  Customers are encouraged to enable cloud protection.

Q: What can I do if I don’t have Microsoft Defender Antivirus?

A: Use the One-Click Microsoft Exchange On-Premises Mitigation Tool found here.

The post Automatic on-premises Exchange Server mitigation now in Microsoft Defender Antivirus appeared first on Microsoft Security.

HAFNIUM targeting Exchange Servers with 0-day exploits

March 2nd, 2021 No comments

Microsoft has detected multiple 0-day exploits being used to attack on-premises versions of Microsoft Exchange Server in limited and targeted attacks. In the attacks observed, the threat actor used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts, and allowed installation of additional malware to facilitate long-term access to victim environments. Microsoft Threat Intelligence Center (MSTIC) attributes this campaign with high confidence to HAFNIUM, a group assessed to be state-sponsored and operating out of China, based on observed victimology, tactics and procedures.

The vulnerabilities recently being exploited were CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065, all of which were addressed in today’s Microsoft Security Response Center (MSRC) release – Multiple Security Updates Released for Exchange Server. We strongly urge customers to update on-premises systems immediately. Exchange Online is not affected.

We are sharing this information with our customers and the security community to emphasize the critical nature of these vulnerabilities and the importance of patching all affected systems immediately to protect against these exploits and prevent future abuse across the ecosystem. This blog also continues our mission to shine a light on malicious actors and elevate awareness of the sophisticated tactics and techniques used to target our customers. The related IOCs, Azure Sentinel advanced hunting queries, and Microsoft Defender for Endpoint product detections and queries shared in this blog will help SOCs proactively hunt for related activity in their environments and elevate any alerts for remediation.

Microsoft would like to thank our industry colleagues at Volexity and Dubex for reporting different parts of the attack chain and their collaboration in the investigation. Volexity has also published a blog post with their analysis. It is this level of proactive communication and intelligence sharing that allows the community to come together to get ahead of attacks before they spread and improve security for all.

Who is HAFNIUM?

HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.

HAFNIUM has previously compromised victims by exploiting vulnerabilities in internet-facing servers, and has used legitimate open-source frameworks, like Covenant, for command and control. Once they’ve gained access to a victim network, HAFNIUM typically exfiltrates data to file sharing sites like MEGA.

In campaigns unrelated to these vulnerabilities, Microsoft has observed HAFNIUM interacting with victim Office 365 tenants. While they are often unsuccessful in compromising customer accounts, this reconnaissance activity helps the adversary identify more details about their targets’ environments.

HAFNIUM operates primarily from leased virtual private servers (VPS) in the United States.

Technical details

Microsoft is providing the following details to help our customers understand the techniques used by HAFNIUM to exploit these vulnerabilities and enable more effective defense against any future attacks against unpatched systems.

CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability in Exchange which allowed the attacker to send arbitrary HTTP requests and authenticate as the Exchange server.

CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave HAFNIUM the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to exploit.

CVE-2021-26858 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

CVE-2021-27065 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

Attack details

After exploiting these vulnerabilities to gain initial access, HAFNIUM operators deployed web shells on the compromised server. Web shells potentially allow attackers to steal data and perform additional malicious actions that lead to further compromise. One example of a web shell deployed by HAFNIUM, written in ASP, is below:

Following web shell deployment, HAFNIUM operators performed the following post-exploitation activity:

  • Using Procdump to dump the LSASS process memory:

  • Using 7-Zip to compress stolen data into ZIP files for exfiltration:

  • Adding and using Exchange PowerShell snap-ins to export mailbox data:

  • Using the Nishang Invoke-PowerShellTcpOneLine reverse shell:

  • Downloading PowerCat from GitHub, then using it to open a connection to a remote server:

HAFNIUM operators were also able to download the Exchange offline address book from compromised systems, which contains information about an organization and its users.

Our blog, Defending Exchange servers under attack, offers advice for improving defenses against Exchange server compromise. Customers can also find additional guidance about web shell attacks in our blog Web shell attacks continue to rise.

Can I determine if I have been compromised by this activity?

The below sections provide indicators of compromise (IOCs), detection guidance, and advanced hunting queries to help customers investigate this activity using Exchange server logs, Azure Sentinel, Microsoft Defender for Endpoint, and Microsoft 365 Defender. We encourage our customers to conduct investigations and implement proactive detections to identify possible prior campaigns and prevent future campaigns that may target their systems.

Check patch levels of Exchange Server

The Microsoft Exchange Server team has published a blog post on these new Security Updates providing a script to get a quick inventory of the patch-level status of on-premises Exchange servers and answer some basic questions around installation of these patches.

Scan Exchange log files for indicators of compromise

  • CVE-2021-26855 exploitation can be detected via the following Exchange HttpProxy logs:
    • These logs are located in the following directory: %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\HttpProxy
    • Exploitation can be identified by searching for log entries where the AuthenticatedUser is empty and the AnchorMailbox contains the pattern of ServerInfo~*/*
      • Here is an example PowerShell command to find these log entries:

Import-Csv -Path (Get-ChildItem -Recurse -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy” -Filter ‘*.log’).FullName | Where-Object {  $_.AuthenticatedUser -eq ” -and $_.AnchorMailbox -like ‘ServerInfo~*/*’ } | select DateTime, AnchorMailbox

    • If activity is detected, the logs specific to the application specified in the AnchorMailbox path can be used to help determine what actions were taken.
      • These logs are located in the %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging directory.
  • CVE-2021-26858 exploitation can be detected via the Exchange log files:
    • C:\Program Files\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog
    • Files should only be downloaded to the %PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OAB\Temp directory
      • In case of exploitation, files are downloaded to other directories (UNC or local paths)
    • Windows command to search for potential exploitation:

findstr /snip /c:”Download failed and temporary file” “%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log”

  • CVE-2021-26857 exploitation can be detected via the Windows Application event logs
    • Exploitation of this deserialization bug will create Application events with the following properties:
      • Source: MSExchange Unified Messaging
      • EntryType: Error
      • Event Message Contains: System.InvalidCastException
    • Following is PowerShell command to query the Application Event Log for these log entries:

Get-EventLog -LogName Application -Source “MSExchange Unified Messaging” -EntryType Error | Where-Object { $_.Message -like “*System.InvalidCastException*” }

  • CVE-2021-27065 exploitation can be detected via the following Exchange log files:
    • C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server

All Set-<AppName>VirtualDirectory properties should never contain script. InternalUrl and ExternalUrl should only be valid Uris.

    • Following is a PowerShell command to search for potential exploitation:

Select-String -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log” -Pattern ‘Set-.+VirtualDirectory’

Host IOCs

Hashes

Web shell hashes

  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
  • 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944

Paths

We observed web shells in the following paths:

  • C:\inetpub\wwwroot\aspnet_client\
  • C:\inetpub\wwwroot\aspnet_client\system_web\
  • In Microsoft Exchange Server installation paths such as:
    • %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
    • C:\Exchange\FrontEnd\HttpProxy\owa\auth\

The web shells we detected had the following file names:

  • web.aspx
  • help.aspx
  • document.aspx
  • errorEE.aspx
  • errorEEE.aspx
  • errorEW.aspx
  • errorFF.aspx
  • healthcheck.aspx
  • aspnet_www.aspx
  • aspnet_client.aspx
  • xx.aspx
  • shell.aspx
  • aspnet_iisstart.aspx
  • one.aspx

 Check for suspicious .zip, .rar, and .7z files in C:\ProgramData\, which may indicate possible data exfiltration.

Customers should monitor these paths for LSASS dumps:

  • C:\windows\temp\
  • C:\root\

Tools

Many of the following detections are for post-breach techniques used by HAFNIUM. So while these help detect some of the specific current attacks that Microsoft has observed it remains very important to apply the recently released updates for CVE-2021-26855, CVE-2021-26857, CVE-2021-27065 and CVE-2021-26858.

Microsoft Defender Antivirus detections

Please note that some of these detections are generic detections and not unique to this campaign or these exploits.

  • Exploit:Script/Exmann.A!dha
  • Behavior:Win32/Exmann.A
  • Backdoor:ASP/SecChecker.A
  • Backdoor:JS/Webshell (not unique)
  • Trojan:JS/Chopper!dha (not unique)
  • Behavior:Win32/DumpLsass.A!attk (not unique)
  • Backdoor:HTML/TwoFaceVar.B (not unique)

Microsoft Defender for Endpoint detections

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Possible web shell installation (not unique)
  • Process memory dump (not unique)

Azure Sentinel detections

Advanced hunting queries

To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint and Azure Sentinel:

Microsoft Defender for Endpoint advanced hunting queries

Microsoft 365 Defender customers can find related hunting queries below or at this GitHub location: https://github.com/microsoft/Microsoft-365-Defender-Hunting-Queries/

Additional queries and information are available via Threat Analytics portal for Microsoft Defender customers.

UMWorkerProcess.exe in Exchange creating abnormal content

Look for Microsoft Exchange Server’s Unified Messaging service creating non-standard content on disk, which could indicate web shells or other malicious content, suggesting exploitation of CVE-2021-26858 vulnerability:

DeviceFileEvents | where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "CacheCleanup.bin" | where FileName !endswith ".txt"
| where FileName !endswith ".LOG" | where FileName !endswith ".cfg" | where FileName != "cleanup.bin"

UMWorkerProcess.exe spawning

Look for Microsoft Exchange Server’s Unified Messaging service spawning abnormal subprocesses, suggesting exploitation of CVE-2021-26857 vulnerability:

DeviceProcessEvents
| where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "wermgr.exe" | where FileName != "WerFault.exe"

Please note excessive spawning of wermgr.exe and WerFault.exe could be an indicator of compromise due to the service crashing during deserialization.

Azure Sentinel advanced hunting queries

Azure Sentinel customers can find a Sentinel query containing these indicators in the Azure Sentinel Portal or at this GitHub location: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/.

Look for Nishang Invoke-PowerShellTcpOneLine in Windows Event Logging:

SecurityEvent  | where EventID == 4688  | where Process has_any ("powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has "$client = New-Object System.Net.Sockets.TCPClient"

Look for downloads of PowerCat in cmd and Powershell command line logging in Windows Event Logs:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has "https://raw.githubusercontent.com/besimorhino/powercat/master/powercat.ps1"

Look for Exchange PowerShell Snapin being loaded. This can be used to export mailbox data, subsequent command lines should be inspected to verify usage:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where isnotempty(CommandLine)  | where CommandLine contains "Add-PSSnapin Microsoft.Exchange.Powershell.Snapin"  | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, Account, CommandLine

 

The post HAFNIUM targeting Exchange Servers with 0-day exploits appeared first on Microsoft Security.

Defending Exchange servers under attack

June 24th, 2020 No comments

Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.

If compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.

There are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.

The second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker’s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.

The first scenario is more common, but we’re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like CVE-2020-0688. The security update that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.

In many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, web shells allow attackers to steal data or perform malicious actions for further compromise.

Behavior-based detection and blocking of malicious activities on Exchange servers

Adversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.

Behavior-based blocking and containment capabilities in Microsoft Defender ATP, which use engines that specialize in detecting threats by analyzing behavior, surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.

In April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web  (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the  Exchange Control Panel or ECP), executing net.exe, cmd.exe, and other known living-off-the-land binaries (LOLBins) like mshta.exe is very suspicious and should be further investigated.

Figure 1. Behavior-based detections of attacker activity on Exchange servers

In this blog, we’ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.

Figure 2. Anatomy of an Exchange server attack

Initial access: Web shell deployment

Attackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:

  • %ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess
  • %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

The ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.

These directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping .aspx or .ashx files in any of the said directories is highly suspicious.

In our investigation, most of these attacks used the China Chopper web shell. The attackers tried to blend the web shell script file with other .aspx files present on the system by using common file names. In many cases, hijacked servers used the ‘echo’ command to write the web shell. In other cases, certutil.exe or powershell.exe were used. Here are some examples of the China Chopper codes that were dropped in these attacks:

We also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an .ashx version of a popular, publicly available .aspx web shell, which exposes minimum functionality:

Figure 3. Microsoft Defender ATP alert for web shell

Reconnaissance

After web shell deployment, attackers typically ran an initial set of exploratory commands like whoami, ping, and net user. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.

Attackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like lg.exe instead of the built-in net.exe. Attackers also used the EternalBlue exploit and nbtstat scanner to identify vulnerable machines on the network.

Next, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:

  • List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network
  • Get a summary list of all the Exchange servers in the network
  • Get information on mailboxes, such as size and number of items, along with role assignments and permissions.

Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups

Persistence

On misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.

The attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.

Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands

Credential access

Exchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.

In our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.

Next, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.

In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.

Figure 6. Microsoft Defender ATP alert on detection of Mimikatz

In environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using reflective DLL injection. Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.

The attackers also enabled ‘wdigest’ registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.

Another example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of reflective DLL injection where the Mimikatz binary was present only in memory.

With attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called DCSYNC attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users’ passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.

Lateral movement

In these attacks, the attackers used several known methods to move laterally:

  • The attackers heavily abused WMI for executing tools on remote systems.

  • The attackers also used other techniques such as creating service or schedule task on remote systems.

  • In some cases, the attackers simply run commands on remote systems using PsExec.

Exchange Management Shell abuse

The Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.

To understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools MSExchangeOWAAppPool or MSExchangeECPAppPool accessing the shell should be considered suspicious.

In our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.

In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.

These cmdlets allowed the attackers to perform the following:

  • Search received email

In our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event ‘Received’. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.

  • Export mailbox

Attackers exported mailboxes through these four steps:

    1. Granted ApplicationImpersnation role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.
    2. Granted ‘Mailbox Import Export’ role to the attacker-controlled account. This role is required to be added before attempting mailbox export.
    3. Exported the mailbox with filter “Received -gt ‘01/01/2020 0:00:00’”.
    4. Removed the mailbox export request to avoid raising suspicion.

Tampering with security tools

As part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for .dat extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Remote access

The next step for attackers was to create a network architecture using port forwarding tools like plink.exe, a command line connection tool like ssh. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.

Exfiltration

Finally, dumped data was compressed using the utility tool rar.exe. The compressed data mostly comprised of the extracted .pst files, along with memory dumps.

Improving defenses against Exchange server compromise

As these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like plink.exe, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.

Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don’t fall victim to Exchange server compromise.

  1. Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use threat and vulnerability management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

  1. Keep antivirus and other protections enabled

It’s critical to protect Exchange servers with antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate settings.

  1. Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

  1. Restrict access

Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and Enable MFA. Use tools like LAPS.

Place access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don’t expose the ECP directory to the web if it isn’t necessary and to anyone in the company who doesn’t need to access it. Apply similar restrictions to other application pools.

  1. Prioritize alerts

Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like ‘MSExchangeOWAAppPool’ or ‘MSExchangeECPAppPool’ are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as net.exe, cmd.exe, and mshta.exe originating from these pools or w3wp.exe in general.

Behavior-based blocking and containment capabilities in Microsoft Defender Advanced Threat Protection stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.

 

 

Figure 7. Microsoft Defender ATP alerts on blocked behaviors

In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into other suspicious and malicious activities on Exchange servers, which are raised as alerts. The new alert page presents data in an investigation-driven approach meant to empower SecOps teams to easily investigate and take actions.

Figure 8. Microsoft Defender ATP alert and process tree

If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent further damage. Beyond resolving these alerts in the shortest possible time, however, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.

Microsoft Defender ATP is a component of the broader Microsoft Threat Protection (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the incidents view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.

In addition, MTP’s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable web shell threat hunting.

Through built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. Learn more.

 

Hardik Suri

Microsoft Defender ATP Research Team

 

MITRE ATT&CK techniques

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Lateral movement

Collection

Command and control

Exfiltration

 

The post Defending Exchange servers under attack appeared first on Microsoft Security.

BRANCHCACHE for Exchange 2010 OAB Download How-To:

BRANCHCACHE for Exchange 2010 OAB Download How-To:

Requirements for BranchCache

Following is a list of operating systems that support BranchCache content server or BranchCache client computer functionality. To successfully deploy BranchCache in a test lab environment, you must use operating systems that support BranchCache.


General Requirements to Server and Client

Server and Clients must be able to communicate to each other. Clients must be in the same Subnet (otherwise Discovery of Cached Content will not work). All Machines must be able to resolvable in DNS or WINS.


Operating systems for BranchCache client computer functionality

To perform the steps in this guide, you must have three physical or virtual client computers that are running one of the following operating systems:

  • Windows® 7 Enterprise
  • Windows® 7 Ultimate

Operating systems for BranchCache content server functionality

To perform the steps in this guide, you must have one physical or virtual server computer to be used as a BranchCache content Web server that is running one of the Windows Server® 2008 R2 family of operating systems, with the following exceptions:

  • In Windows Server® 2008 R2 Enterprise Core Install with Hyper-V, BranchCache is not supported.
  • In Windows Server® 2008 R2 Datacenter Core Install with Hyper-V, BranchCache is not supported.

Necessary Installation and Configuration Steps for Content-Server:

In our Lab Environment the Content Server should deliver the Exchange OAB. In this case the
existing CAS-Server is responsible for the Content we want to get, so the CAS-Server will be our Content-server. As prerequisite for CAS the IIS-Server is in place so we don’t need to change anything at this point.

The first neccassary Step is to install the Branchcache Feature from Roles and Features.

After this is done install the B.I.T.S. feature with IIS Extension Subfeature.

At the Server this should be the needed configuration Steps.

Additionaly to verify the functionality you can use Perfmon to Monitor the Branchcache related traffic information.

 Configure BranchCache performance counters on the content server
 

  1. 1.   On CAS with Branchcache installed, click Start, click Search programs and files, and type perfmon. In Search results, in Programs, click perfmon.exe. Windows Performance Monitor opens.
  2. 2.   In Monitoring Tools click Performance Monitor to view the Performance Monitor graph. To change the performance monitor graph to report view, click the graph toolbar icon that displays an arrow to reveal the drop-down list, and then click Report.
  3. 3.   To add BranchCache counters, click the graph toolbar icon that is a green plus sign (+). The Add Counters dialog box opens. In the left pane, scroll to BranchCache Kernel Mode, and click to expand the list of BranchCache Kernel Mode counters. Click Client Cache Miss Bytes, hold down the Ctrl key, and then click Server Cache Miss Bytes, Hash Bytes, and Projected Server Bytes Without Caching.
  4. 4.   Click Add, and then click OK.

  Perfmon Content-Server with working Branchcache

 

 To reset the Branchcache functionallity and the performance counters on the content server use:

 

        Netsh branchcache reset

 

 After the Branchcache reset the Perfmon Counters are reset as well.

 Client computer configuration: 
 Neccessary Installation and Configuration Steps for Client Computers to enable BranchCache distributed cache mode using network shell commands

 

1.   On the BranchCache client computer that you want to configure, click Start, click Search programs and files, and then type command. In search results, under Programs, right-click Command Prompt, and then click Run as Administrator. The command prompt opens with the elevated privileges that are required to run netsh commands.

2.   Run the following command: netsh branchcache set service mode=DISTRIBUTED

Suggestion:

Running the netsh branchcache set service command both configures the client computer for distributed cache mode and automatically configures the client computer firewall with the following inbound exceptions for distributed cache mode: TCP port 80 and UDP port 3702.

3.   To verify that BranchCache distributed cache mode is correctly configured on the client computer, run the following command: netsh branchcache show status. The BranchCache Service Status is displayed in the command prompt window with the following values: Service Mode: Distributed Caching; Serve peers on battery power: Disabled; and Current Status= Running.

  

To configure BranchCache performance counters on the Client Computers
 

4.   On Client with Branchcache installed, click Start, click Search programs and files, and type perfmon. In Search results, in Programs, click perfmon.exe. Windows Performance Monitor opens.

5.   In Monitoring Tools click Performance Monitor to view the Performance Monitor graph. To change the performance monitor graph to report view, click the graph toolbar icon that displays an arrow to reveal the drop-down list, and then click Report.

6.   To add BranchCache counters, click the graph toolbar icon that is a green plus sign (+). The Add Counters dialog box opens. In the left pane, scroll to BranchCache, and select all underlying counters.

7.   Click Add, and then click OK.

 

  First Windows 7 Client got Data from Server                                                                                              Other Windows 7 Clients got Hashes from Server but Data from Cache of First Client

                                      

 

To reset the Branchcache functionallity and the performance counters on the Client machines use:

 

      netsh branchcache reset

 

and after that

 

       netsh branchcache set service mode=DISTRIBUTED

These are the steps to make OAB Download over Branchcache possible.

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 Comments off

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

How to link existing AD accounts to the correct organization in a Microsoft Exchange Server 2010 SP1 multi-tenant environment

With Microsoft Exchange Server 2010 SP1 there is a built-in multi-tenant support feature available that replaces many features of HMC. A good overview about the features, limitations, installation and configuration is available at Technet article:

Multi-Tenant Support

http://technet.microsoft.com/en-us/library/ff923272.aspx 

The hosting solution available for Exchange 2010 SP1 includes most of the features and functionality available in Exchange 2010 SP1 Enterprise deployments, but also includes features and functionality that will allow you to create and manage tenant organizations. Microsoft Exchange Server 2010 SP1 will form part of the suite of multi-tenant capable products that will replace the Hosted Messaging and Collaboration 4.5 solution. 

The account provisioning rollout of new Accounts and new mailboxes works via the new-mailbox cmd:
============================================================================

New-Mailbox -Database “Mailbox Database name” -Name “name” -LinkedDomainController “DCName” -LinkedMasterAccount domain\name -UserPrincipalName name@domain.com linkedCredential:(Get-Credential domain\Administrator) -Organization “tenant or organization name” 

The new-mailbox procedure only covers the creation of new accounts and new mailboxes by assigning the appropriate tenant for the particular AD Account.

The –Organization switch is responsible to match the correct tenant. In many customer environments, migrating to Exchange 2010, there already exist the AD accounts that need to be linked to a new mailbox in the appropriate tenant.

To match an existing AD account to a new mailbox we need the Enable-mailbox cmd. Unfortunately the Enable-mailbox cmd syntax options do not include the –Organization option.

This way we cannot connect an existing AD account to a new mailbox in the appropriate tenant.

Solution:
=======   

If you want to enable an existing AD user for a mailbox at a specific organization, you can still use Enable-Mailbox cmdlet. There is some extra work to stamp a few attributes correctly in the AD user before running the cmdlet (here as a sample domain name.test.microsoft.com):

===========================================================================

1. msExchCU: CN=Configuration, CN=<tenant name>, CN=ConfigurationUnits,CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=name  DC=test, DC=microsoft, DC=com
2. msExchOURoot: OU=<tenant name>, OU=Microsoft Exchange Hosted Organizations, DC=name  DC=test, DC=microsoft, DC=com
3. userPrincipalName: Usually it is <user name>@<tenant domain name> 

After stamping these attributes the Enable-mailbox cmd automatically links the AD accounts to a mailbox in the appropriate tenant or organization.

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 Comments off

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Updates to the Forefront Server Protection documentation in the TechNet library (August 2010)

August 5th, 2010 Comments off

Hi, my name is Scott Floman, and I’m a technical writer in the Forefront Server Protection group. Every few months or so, we update our existing “legacy” documentation on our TechNet Web site, and this post is to make you aware of our recent August 2010 update. (p.s. By “legacy” content I mean products that are already supported in production environments, such as Forefront Protection 2010 for Exchange Server (FPE), Forefront Protection 2010 for SharePoint (FPSP), and our Forefront Server Security Version 10 and Antigen Version 9 products).

 

Some of the topics we added or provided updated information about are:

 

·         FPE capacity planning: http://technet.microsoft.com/en-us/library/ff921060.aspx

·         Supported operating systems and Exchange Server versions: http://technet.microsoft.com/en-us/library/ff921059.aspx

·         Best practices for configuring FPE operations: http://technet.microsoft.com/en-us/library/ff716689.aspx

·         Managing performance and health. We added recommended resolutions for when your health monitors are not green (“healthy”).

·         FPE: http://technet.microsoft.com/en-us/library/ee358897.aspx

·         FPSP: http://technet.microsoft.com/en-us/library/ee358924.aspx

·         Submitting malware to Microsoft for analysis. The documentation was revised because customers are advised to use the Microsoft Malware Protection Center Portal to submit malware for analysis.

·         FPE: http://technet.microsoft.com/en-us/library/dd639384.aspx

·         FPSP: http://technet.microsoft.com/en-us/library/dd639465.aspx

·         Maximizing FPSP scan engine performance: http://technet.microsoft.com/en-us/library/ff729711.aspx

 

These are just some of the updates we made. We also made smaller-scale updates in many areas, for example we updated the Forefront Server Security Management Console (FSSMC) system requirements, the FPSP Performance Monitor topic, and the FPE cluster documentation.

In addition, the Table Of Contents (TOC) on TechNet has recently undergone a reorganization, and we are also continuing to seek out ways to optimize search results so that our customers can more easily find the information that they are looking for. 

Also, our team has been busy in creating videos that we hope you will find useful in learning about our products. Here are some recent FPE videos: 

 

So, that’s that, I just wanted to say a few words about our latest TechNet update, the TechNet TOC reorg, and our increased use of the video format. Please used the feedback feature on TechNet, because we do attempt to address all feedback received.

 

Also, another good resource for information is the Forefront Server Security Forum (http://social.technet.microsoft.com/Forums/en-us/category/forefront) where you can read and answer questions about our products. A passport account is needed to access the Forum.

There are other Microsoft forums, blogs, and online technology sites that might prove useful as well; for more information, read this blog article:

http://blogs.technet.com/fss/archive/2009/03/10/other-blogs-and-content-of-interest-for-fss-users.aspx

 

Finally, I want to call your attention to the TechNet wiki, which you can access at the following URL: http://social.technet.microsoft.com/wiki/

 

This is a new community where Forefront employees and customers can post technical articles and interact with one another, much like how wikipedia works. We’re excited about the possibilities of this wiki, which we feel will be a great resource of information, so please stop by and check it out. I recently posted the following wiki articles which I hope will help customers configure our products in multi-server environments (there are also videos for these topics if you want to see a visual demonstration):

Again, thanks for your time, and feel free to e-mail me with any feedback.


Scott Floman
scfloman@microsoft.com

Manually updating engines and definitions in Forefront Protection 2010 for Exchange Server and SharePoint

July 30th, 2010 Comments off

Hello,

 

We get quite a few calls from administrators who ask if they can manually update their Forefront Protection 2010 for Exchange Server (FPE) and Forefront Protection 2010 for SharePoint scan engines.

 Well, the short answer is yes, but the long answer is a bit longer, so in order to provide guidance to those of you who wish to manually update the FPE/FPSP scan engines and definitions as part of your Forefront Protection defense strategies, Microsoft has provided a comprehensive set of instructions via the following Knowledge Base article:

 http://support.microsoft.com/kb/2292741

 So, whatever your reason for not using automatic updating, you can follow the steps outlined in the KB to manually update Forefront Protection’s scan engines.

 Included in the KB is a sample PowerShell script that you can customize to synch with your specific network parameters and adjust to your environmental needs.

 Regards,

Robert McCarthy

Support Engineer – Microsoft Security

Winmail.dat received with a Lotus Notes Client

When an Exchange based email organization sends out an email to a non Exchange based organization (Lotus Notes or other systems for example web mailers) it could happen, that a non mapi client receives an empty email with a winmail.dat file attachment.

The client is unable to open the winmail.dat file and so the email is useless for him.

The reason for this is, that the Microsoft internal TNEF alias RTF (Rich Text Format) was sent out of the Exchange organization. There are different places and settings which have an influence, which you may need to check:


1. Domain level (Exchange server settings):

 

a) Exchange 2003

 In the ESM (Exchange System Manager) go to, Global Settings, Internet Message Format, select the domain. Default domain is “*” but please configure an extra entry for the external SMTP domain for example dominodomain.com.

If you open the property of the domain and go to advanced, there is a setting “Exchange richt-text format”. You can set it to “Always use”, “Never use” and to “Determined by individual user settings”.

Please set it to never use

 

 

b) For Exchange 2007:

Powershell:

Set-remotedomain domainname tnefenabled $false

In the GUI:

Open the Exchange management console, Organization, Hub Transport, Remote Domains, Domain name:

Please set it to never use.

 

   

2. Recipient level

 

Another place where you can configure RTF is at the recipient level.  

a) AD contact

If you got an active directory based contact you can set it to be a non mapi recipient:

 

 

Please uncheck the „Use Mapi rich text format) box

Note: For an AD contact there is one additional setting which may need to be set:

InternetEncoding: 1310720

See KB 924240 for more details.

KB 924240        The email message attached with winmail.dat when you send a mail from Exchange to Lotus Notes through a SMTP connector

http://support.microsoft.com/default.aspx?scid=kb;EN-US;924240 

b) For Exchange 2007:

Open the Exchange management console, Recipient Configuration, Mail Contact:

 

 

c) The same is true for a personal contact created in Outlook:

 

  

d) Even for a one off addresses this can be set. If you enter the smtp address in the to line for example john.doe@domain.com then do a check names, double click on the email address in the to line,

and you will see the same box as before:

 

 

3) Other important Outlook settings:

 

a) Message Format :

Tools, Options, Mail Format, Message Format (Compose in this message format):

Plain Text, Rich Text, HTML

 

 

b) Internet Format:

Tools, Options, Mail Format, Internet Format, Outlook Rich Text options:

When sending Outlook Rich Text messages to Internet recipients, use this format:

       Convert to Plain Text format

       Convert to HTML format

–    Convert to Rich Text format

 

 

4. Outlook overwriting the Exchange settings:

 

329454 Outlook 2002 message format overrides Exchange server message format

http://support.microsoft.com/default.aspx?scid=kb;EN-US;329454

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail DWORD:
DisableInetOverride Value: 1

When the registry key is set to a non-zero number, the message format does not override the Internet Message Format that is specified by Exchange.

The key DisableInetOverride still exists in Outlook 2003, 2007 and 2010.

 

5. NK2 cache

 

If you have Outlook clients where it sometimes work and sometimes not please delete
the name cache files from the outlook clients (delete username.NK2 file(s))

 

6. More to read:

 

821750 How to configure Internet e-mail message formats at the user and the domain levels in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;821750

290809 How e-mail message formats affect Internet e-mail messages in Outlook

http://support.microsoft.com/default.aspx?scid=kb;EN-US;290809