Archive

Archive for the ‘Exchange Server’ Category

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

 

Messages sent from Exchange 2007 to Non-Exchange Recipients through an Exchange 2003 Connector are NDRed by the first Hub/Transport Server

In a mixed Exchange 2007/2003 environment with a Connector to a Non-Exchange System on an Exchange 2003 Server you cannot send messages from Exchange 2007 to a recipient in the Non-Exchange System if the following two conditions are true:


1) the Connector contains an Address Space with an underscore (“_”) in it, like in the following example:


  


2) one part of the address of the final recipient (for example, the “Domain”-part) matches this Address Space.


In this case, the sender of the message will receive a Non Delivery Report from the first Exchange 2007 Hub/Transport-Server and the message will not be routed to the recipient.


The Non Delivery Report contains the following error-information:


 #550 5.4.4 ROUTING.NoNextHop; unable to route


This error is returned despite the fact, that the Scope of the Connector is set to “Entire organization” and the Address Space is visible in the Routing Log Viewer in Exchange 2007.


Please note, that this issue can occur in conjunction with all EDK-Gateways for Exchange 2003 and hence is not limited to the Lotus Notes Connector for Exchange 2003.


You can work around the problem by re-defining the Address Space in question so, that the underscore is eliminated from it and replaced by a wildcard. One possible solution for the example above would be, to replace “abcd_ef” by “abcd*”. As soon as this change has been replicated to Exchange 2007, the problem is resolved and messages can be sent from Exchange 2007 to the desired destination.

How to control routing from your own routing agent

With the release of Microsoft Exchange Server 2007 Service Pack 1 you can programmatically override the default routing for message recipients on a per-recipient basis. This can be done by using the SetRoutingOverride method on the recipient for which you want to override the default routing.


Let’s assume that you have an Exchange 2007 server with just one send connector “Internet Connector”” using DNS for the address space *. With this configuration all messages leaving the organization will use this connector. Let’s further assume that you want to route messages from certain senders to a smarthost instead of using DNS. This can be done as follows:


– Create an additional send connector “Smarthost Connector” pointing to the smarthost
– Specify a non-existing domain (e.g. nexthopdomain.com) as address space of the new connector
– Write, install and enable a routing agent which registers for the OnResolvedMessage event and overwrites the default routing for the recipient.


The sample agent of this article shows you how to route messages from administrator@contoso.com over the new connector, the routing for all other sender’s won’t be changed. 


1.) Create a C# project (dll/library type) 


2.) Copy the following DLLs from the C:\Program Files\Microsoft\Exchange Server\Public directory of an Exchange 2007 server to the debug directory of your new C# project:
     a. Microsoft.Exchange.Data.Common.dll
     b. Microsoft.Exchange.Data.Transport.dll


3.) Add references to the two DLLs to the C# project using the Visual Studio solution explorer


4.) Add the following code to your project:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


using Microsoft.Exchange.Data.Transport;
using Microsoft.Exchange.Data.Transport.Email;
using Microsoft.Exchange.Data.Transport.Smtp;
using Microsoft.Exchange.Data.Transport.Routing;
using Microsoft.Exchange.Data.Common;



namespace RoutingAgentOverride
{
    public class SampleRoutingAgentFactory : RoutingAgentFactory
    {
        public override RoutingAgent CreateAgent(SmtpServer server)
        {
            RoutingAgent myAgent = new ownRoutingAgent();


            return myAgent;
        }
    }
}
public class ownRoutingAgent : RoutingAgent
{
    public ownRoutingAgent()
    {
        //subscribe to different events
        base.OnResolvedMessage += new ResolvedMessageEventHandler(ownRoutingAgent_OnResolvedMessage);
    }


    void ownRoutingAgent_OnResolvedMessage(ResolvedMessageEventSource source, QueuedMessageEventArgs e)
    {
        try
        {
            // For testing purposes we do not only check the sender address but the subject line as well
            // If the subject contains the substring “REDIR” then the default routing is overwritten.
            //
            // Instead of hard-coding the sender you could also perform an LDAP-query, read the information
            // from a text file, etc.
            //
            if (e.MailItem.FromAddress.ToString() == “administrator@contoso.com
                && e.MailItem.Message.Subject.Contains(“REDIR”))
            {


                // Here we set the address space we want to use for the next hop. Note that this doesn’t change the recipient address.
                // Setting the routing domain to “nexthopdomain.com” only means that the routing engine chooses a suitable connector
                // for nexthopdomain.com instead of using the recpient’s domain.


                RoutingDomain myRoutingOverride = new RoutingDomain(“nexthopdomain.com”); 
                                                                                         
                foreach (EnvelopeRecipient recp in e.MailItem.Recipients)
                {
                    recp.SetRoutingOverride(myRoutingOverride);


                }


            }
        }


        catch // (Exception except)
        {


        }
    }


}


5.) Compile the DLL


6.) Copy the DLL to the HT server


7.) Install the transport agent using the Exchange Management Shell:
     Install-TransportAgent “OwnTestAgent” -TransportAgentFactory “RoutingAgentOverride.SampleRoutingAgentFactory” -AssemblyPath “Path to DLL”


8.) Enable the transport agent using the Exchange Management Shell:
     Enable-TransportAgent “OwnTestAgent”


9.) IMPORTANT: Exit Powershell
10. IMPORTANT: Restart the MSExchangeTransport service


11.) Verify that the agent was successfully enabled / registered by running Get-Transportagent


Tips:



  • To live debug the dll you need to attach to edgetransport.exe.

  • To recompile after a change


    • detach from edgetransport

    • stop the transport service (otherwise Visual studio won’t be able to overwrite the file)
      (only if you registered the dll from the \debug folder)

  • Sometimes messages remain in the outbox until the mail submission service is restarted