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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/suspicious-behaviors-detected-on-exchange-servers.png) _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. [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Exchange-servers-attack-chain-2.png)]() _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: ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/a-Exchange-server-web-shell-1.png) 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: ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/b-Exchange-server-web-shell-2.png) [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/A-suspicious-web-script-was-created.png)]() _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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/c-Exchange-server-reconnaissance-1.png) 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/d-Exchange-server-reconnaissance-2.png) [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Anomalous-account-lookups.png)]() _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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/e-Exchange-server-persistence.png) [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/New-local-admin-added-using-Net-commands.png)]() _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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/f-Exchange-server-credential-access-1.png) 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/g-Exchange-server-credential-access-2.png) In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/h-Exchange-server-credential-access-3.png) [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Malicious-credential-theft-tool-execution-detected.png)]() _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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/i-Exchange-server-credential-access-4.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/j-Exchange-server-credential-access-5.png) 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/k-Exchange-server-credential-access-6.png) 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/l-Exchange-server-credential-access-7.png) ## 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/m-Exchange-server-lateral-movement-1.png) * The attackers also used other techniques such as creating service or schedule task on remote systems. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/n-Exchange-server-lateral-movement-2.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/o-Exchange-server-lateral-movement-3.png) * In some cases, the attackers simply run commands on remote systems using PsExec. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/p-Exchange-server-lateral-movement-4.png) ## 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/q-Exchange-server-abuse-ems-1.png) In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/r-Exchange-server-abuse-ems-2.png) 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/s-Exchange-server-abuse-ems-3.png) * Export mailbox Attackers exported mailboxes through these four steps: 1. 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/t-Exchange-server-abuse-ems-4.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/u-Exchange-server-abuse-ems-5.png) ## 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/v-Exchange-server-security-tampering.png) ## 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/w-Exchange-server-remote-access.png) ## 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/x-Exchange-server-exfiltration.png) # 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. 2. 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](). 3. 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. 4. 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. 5. Prioritize alerts The distinctive patterns of Exchange server compromise aid in detecting malicious behaviors and inform security operations teams to quickly respond to the initial stages of compromise. 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. ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/IISExchgSpawnCMD-1-1.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/IISExchgSpawnEMS-1.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/WebShellTerminal-1.png) ![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/IISExchgSpawnNET-1.png) _Figure 7. Microsoft Defender ATP alerts on blocked behaviors_ In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into malicious behaviors associated with Exchange server compromise. Behavior-based Exchange-specific alerts include “Suspicious w3wp.exe activity in Exchange”, which indicates that attackers are running arbitrary commands via the IIS processes in an Exchange server. [![](https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Suspiciousw3wpexeactivityinExchange.png)]() _Figure 8. Microsoft Defender ATP alert and process tree for suspicious w3wp.exe activity in Exchange_ These alerts should be immediately prioritized and fully investigated, and any credentials present on the Exchange server, including those used for service accounts and scheduled tasks, should be considered compromised. Beyond resolving these alerts in the shortest possible time, 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 * [Exploit Public-Facing Application]() Execution * [Command-line interface]() * [Windows Management Instrumentation]() * [PowerShell]() Persistence * [Web Shell]() * [Create Account]() * [New Service]() * [Scheduled Task]() Privilege escalation * [Valid Accounts]() * [Web Shell]() Defense evasion * [Indicator Removal from Tools]() * [Obfuscated Files or Information]() * [Masquerading]() Credential access * [Credential Dumping]() Discovery * [System Network Configuration Discovery]() * [Remote System Discovery]() * [Account Discovery]() * [Permission Groups Discovery]() Lateral movement * [Windows Admin Shares]() * [Pass the Hash]() * [Remote File Copy]() * [Windows Management Instrumentation]() * [New Service]() * [Scheduled Task]() Collection * [Data From Local System]() * [Data Staged]() * [Email Collection]() Command and control * [Remote File Copy]() * [Connection Proxy]() Exfiltration * [Data Compressed]() * [Exfiltration Over Command and Control Channel]() The post [Defending Exchange servers under attack]() appeared first on [Microsoft Security.

Query Builder