Note: This Alert was updated by our security researchers on March 4, 2021 to provide further guidance.
CyberARM has observed active exploitation of vulnerabilities in Microsoft Exchange Server products. Successful exploitation of these vulnerabilities allows an unauthenticated attacker to execute arbitrary code on vulnerable Exchange Servers, enabling the attacker to gain persistent system access, as well as access to files and mailboxes on the server and to credentials stored on that system. Successful exploitation may additionally enable the attacker to compromise trust and identity in a vulnerable network. Microsoft released out-of-band patches to address vulnerabilities in Microsoft Exchange Server. The vulnerabilities impact on-premises Microsoft Exchange Servers and are not known to impact Exchange Online or Microsoft 365 (formerly O365) cloud email services.
Technical Details
Microsoft has released out-of-band security updates to address four vulnerabilities in Exchange Server:
- CVE-2021-26855 allows an unauthenticated attacker to send arbitrary HTTP requests and authenticate as the Exchange Server. The vulnerability exploits the Exchange Control Panel (ECP) via a Server-Side Request Forgery (SSRF). This would also allow the attacker to gain access to mailboxes and read sensitive information.
- CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 allow for remote code execution.
- CVE-2021-26858 and CVE-2021-27065 are similar post-authentication arbitrary write file vulnerabilities in Exchange. An attacker, authenticated either by using CVE-2021-26855 or via stolen admin credentials, could write a file to any path on the server.
- CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. An attacker, authenticated either by using CVE-2021-26855 or via stolen admin credentials, could execute arbitrary code as
SYSTEM
on the Exchange Server.
- To locate a possible compromise of these CVEs, we encourage you to read the Microsoft Advisory.
It is possible for an attacker, once authenticated to the Exchange server, to gain access to the Active Directory environment and download the Active Directory Database.
Tactics, Techniques and Procedures
CyberARM has observed the following files as targets of HTTP POST requests:
/owa/auth/Current/themes/resources/logon.css
/owa/auth/Current/themes/resources/owafont_ja.css
/owa/auth/Current/themes/resources/lgnbotl.gif
/owa/auth/Current/themes/resources/owafont_ko.css
/owa/auth/Current/themes/resources/SegoeUI-SemiBold.eot
/owa/auth/Current/themes/resources/SegoeUI-SemiLight.ttf
/owa/auth/Current/themes/resources/lgnbotl.gif
Administrators should search the ECP server logs for the following string (or something similar):
S:CMD=Set-OabVirtualDirectory.ExternalUrl=’
The logs can be found at <exchange install path>\Logging\ECP\Server\.
To determine possible webshell activity, administrators should search for aspx files in the following paths:
- \inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)
- \<exchange install path>\FrontEnd\HttpProxy\ecp\auth\ (any file besides TimeoutLogoff.aspx)
- \<exchange install path>\FrontEnd\HttpProxy\owa\auth\ (any file or modified file that is not part of a standard install)
- \<exchange install path>\FrontEnd\HttpProxy\owa\auth\Current\ (any aspx file in this folder or subfolders)
- \<exchange install path>\FrontEnd\HttpProxy\owa\auth\<folder with version number>\ (any aspx file in this folder or subfolders)
Administrators should search in the /owa/auth/Current directory for the following non-standard web log user-agents. These agents may be useful for incident responders to look at to determine if further investigation is necessary.
- DuckDuckBot/1.0;+(+http://duckduckgo.com/duckduckbot.html)
- facebookexternalhit/1.1+(+http://www.facebook.com/externalhit_uatext.php)
- Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)
- Mozilla/5.0+(compatible;+Bingbot/2.0;++http://www.bing.com/bingbot.htm)
- Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html
- Mozilla/5.0+(compatible;+Konqueror/3.5;+Linux)+KHTML/3.5.5+(like+Gecko)+(Exabot-Thumbnails)
- Mozilla/5.0+(compatible;+Yahoo!+Slurp;+http://help.yahoo.com/help/us/ysearch/slurp)
- Mozilla/5.0+(compatible;+YandexBot/3.0;++http://yandex.com/bots)
- Mozilla/5.0+(X11;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.103+Safari/537.36
CyberARM observed these user-agents in conjunction with exploitation to /ecp/ URLs:
- ExchangeServicesClient/0.0.0.0
- python-requests/2.19.1
- python-requests/2.25.1
These user-agents were also observed having connections to post-exploitation web-shell access:
- antSword/v2.1
- Googlebot/2.1+(+http://www.googlebot.com/bot.html)
- Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)
As with the non-standard user-agents, responders can examine internet information services (IIS) logs from Exchange Servers to identify possible historical activity. Also, as with the non-standard user agents, these should not be taken as definitive IOCs:
- POST /owa/auth/Current/
- POST /ecp/default.flt
- POST /ecp/main.css
- POST /ecp/<single char>.js
CyberARM has seen attackers leverage the following IP addresses. Although these are tied to virtual private servers (VPSs) servers and virtual private networks (VPNs), responders should investigate these IP addresses on their networks and act accordingly:
- 103.77.192[.]219
- 104.140.114[.]110
- 104.250.191[.]110
- 108.61.246[.]56
- 149.28.14[.]163
- 157.230.221[.]198
- 167.99.168[.]251
- 185.250.151[.]72
- 192.81.208[.]169
- 203.160.69[.]66
- 211.56.98[.]146
- 5.254.43[.]18
- 5.2.69[.]14
- 80.92.205[.]81
- 91.192.103[.]43
A list of webshell hashes have also been provided by Microsoft:
- b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
- 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
- 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
- 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
- 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
- 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
- 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
- 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944
Conduct Forensic Analysis
Should your organization see evidence of compromise, your incident response should begin with conducting forensic analysis to collect artifacts and perform triage. Please see the following list of recommendations on how to conduct forensic analysis using various tools.
While collecting artifacts to perform triage, use processes and tools that minimize the alteration of the data being collected and that minimize impact to the operating system itself.
Ideally, during data collection, store the data on removable/external media and, when possible, run the artifact collection tools from the same media.
Key artifacts for triage that should be collected:
- Memory
- All registry hives
- All windows event logs
- All web logs
Need Assistance?
If you have concerns that your servers or networks may have been compromised from this vulnerability, please reach out to the CyberArm team and we can help you make a determination if further investigation is warranted.