Microsoft, Mandiant and EXPMON researchers discovered a set of flaws in MSHTML (Internet Explorer’s browser engine) that remote, unauthenticated attackers can use to execute code on a system.
Threat actors are exploiting this zero-day vulnerability in the wild by creating weaponized Office documents to hijack vulnerable Windows systems. Threat actors can use a malicious ActiveX control for an Office document that hosts the browser rendering engine. The attacker would need to persuade a user to open the malicious file, according to Microsoft.
CVE-2021-40444👍 https://t.co/YKlDlPCeiQ
— b0ring (@dnpushme) September 8, 2021
The CVE has a severity rating of 8.8 out of 10 and affects Windows Server 2008 through 2019 and Windows 8.1 through 10. EXPON confirmed via Twitter that they reproduced the attack using Office 2019/Office 365 on Windows 10:
We have reproduced the attack on the latest Office 2019 / Office 365 on Windows 10 (typical user environment), for all affected versions please read the Microsoft Security Advisory. The exploit uses logical flaws so the exploitation is perfectly reliable (& dangerous).
— EXPMON (@EXPMON_) September 7, 2021
The good news: the default setting for Microsoft Office opens documents from the internet using Protected View or Application Guard for Office, which prevents the attacks.
To determine the severity of this vulnerability, it’s important to consider the context. Word is currently one of the most common tools used for initial access. For example, CVE 2017-11882 accounted for nearly three-quarters of all exploits leveraged in Q4 2020, according to a report from HP Bromium.
CVE-2021-40444 will give adversaries yet another way to access Word — which is by no means lacking in existing methods to attack — and will likely have a long tail in terms of exploitation. It still requires people to bypass the “internet protection” step, but does not require the same additional step as macros.
Microsoft recommends disabling the installation of ActiveX controls in Internet Explorer by updating the registry.
Microsoft provides the following instructions in its advisory documentation:
To disable installing ActiveX controls in Internet Explorer in all zones, paste the following into a text file and save it with the .reg file extension:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0]
"1001"=dword:00000003
"1004"=dword:00000003
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1001"=dword:00000003
"1004"=dword:00000003
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2]
"1001"=dword:00000003
"1004"=dword:00000003
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1001"=dword:00000003
"1004"=dword:00000003
Double-click the .reg file to apply it to your Policy hive.
Reboot the system to ensure the new configuration is applied.
This may seem like an easy mitigation, but some organizations have applications that use ActiveX and will be unable to use this workaround. In those cases, admins should reinforce training on Protected View with End Users to ensure that emailed and downloaded documents do not leave Protected View until patches can be applied. The exploits cannot be triggered until a document moves into “Edit” mode away from Protected View. If you previously disabled Protected View, you should enable it immediately if you cannot disable ActiveX.
Blumira is actively developing detection opportunities in our lab environment. Early reports indicate that possible EDR detection of execution may include control.exe with command arguments including cpl:../../../…
Another #IOC-Based free #Sigma which included this behavior. @RedDrip7 nice find! this also tracked by @joe4security sandbox.
➡️https://t.co/NvtEcj78uy
+ one more #ThreatHunting rule available by tag: ➡️https://t.co/dgLlxL41Ir#vulnerabilities #APT #CVE-2021-40444 #Microsoft https://t.co/2uTcl6F1cv pic.twitter.com/HN6p1oTptr— Ring3API (@rimpq) September 8, 2021
Organizations running both Microsoft Defender Antivirus and Microsoft Defender for Endpoint will be able to detect the exploit without taking additional action, according to Microsoft.
However, it is important to note that organizations running just Microsoft Defender for Endpoint (not AV) are not protected by default. In that case, you must set EDR to block mode.
Microsoft’s guidance for this requires you to be running their AV and EDR tooling, directs you to definitions 1.349.22.0 which I suspect is a typo (they’re on .222), and says if you run Defender you do not need to take additional action. EDR in block mode isn’t default.. pic.twitter.com/vcZsFzjlNB
— Kevin Beaumont (@GossiTheDog) September 7, 2021
Update 9/8/2021 @ 5:35 PM ET: According to Kevin Beaumont aka Twitter user GossiTheDog, threat actors can potentially bypass the Microsoft workaround.
For bonus points I just modified it to not need a new ActiveX control, which beats the MS work around. Took about a minute. 🤦♀️https://t.co/oaVfJfzZcb
— Kevin Beaumont (@GossiTheDog) September 8, 2021
If this is true, you should rely on detections to mitigate your risk.
Update 9/9/2021 @ 9:35 AM ET: Well, things are still bad, will continue to be bad, but not all that much more bad than the rest of Office threat landscape ¯\_(ツ)_/¯
At Blumira, we’re still working on detection opportunities in our lab environment. One of the more promising detection opportunities we’re looking at is with parent/child process relationships between Office products and control.exe, but we haven’t confirmed this yet. Also, .inf loads are pretty well expected at this point, so detection should work with that in mind. There are also .cab files that are dropped and extracted which may be a detection point as well. Here’s one of the .cab files we pulled down yesterday: 94e5f6d9921493645ad47df612edfc67683a075eaa9e25c7e61298491b097b64 Payload/ministry.cab
Update 9/13/2021 @ 10:04 AM ET:
It’s dead simple and we wouldn’t be surprised if MS comes back with a “working as intended” but we’ll see. Nothing done here is particularly magical and if this is really the first time this is being exploited, it was more of an oversight of techniques by attackers than it was a new magical vulnerability.
Any document that can support an externally linked OLE Object that can reference ActiveX can potentially be weaponized. That makes it quite easy to weaponize modern Office files due to how easy it is to modify the XML one unzipped. We could see Autodesk CAD or similar tools that leverage OLE being used here as well potentially, that’s a much more refined/focused campaign then docx though. Most/many would have Word, only specific targets would be using CAD.
It’s however much harder to do it in a way that AV/EDR tools won’t be able to detect the file once it’s pulled down, Defender (default) seems to detect the final stage whereas Defender ATP (fancy) detects the initial loader.
The initial loader patterns that were being detected in the document references (word/_rels/document.xml.rels -> !x-usc:) does not appear to be required so there may be some avoidance if signatures aren’t updated. However the actual behaviors once exploitation starts involved likely won’t be changing much until we get to fileless.
The detection for EDR/AV is strong already, this requires (right now) a file to be downloaded (.cab file) extracted and then the .dll (.inf named files) within the cab are run against the control.exe in the ActiveXObject. This means that the attacker not only has to get past signature detection for the initial docx (or similar Office file), but also through the downloaded external html file and the downloaded .cab file.
To detect, we recommend enabling Sysmon. Here’s a snippet pulled from a host that was exploited with Sysmon, even just detecting with a basic like something such as “%control.exe%.inf” should get pretty quick detection on the current implementation: <Data Name="ParentCommandLine">"C:\Windows\System32\control.exe" ".cpl:../../msword.inf",</Data>
Update 9/15/2021 @ 10:50 AM ET: Microsoft released a patch last night as a part of Patch Tuesday. The main focus of this attack, .docx, still does the external template gathering but does not appear to execute the downloaded exploit. We are still doing more testing around this, but the patch at least does appear to resolve the issues around this specific exploit.
While this appears to mitigate the worry of current ActiveX exploitation, this still leaves the concern of remote templates being loaded and executed. The risk for this now migrates to attack methods such as URI Scheme manipulation of vulnerable applications by leveraging javascript to redirect the endpoint to a specific location once the document is opened. There have been no real world examples of this exploitation method as of yet, however and ensuring your applications are up to date will always help defend against this vector.
We’ll update this post as we find out more.
Blumira can detect activity that is indicative of NTLM Relay attacks, as well as many other Microsoft security incidents. By easily integrating Blumira’s detection and response platform with your Windows environment, you can identify indicators of an attack in progress and contain threats to minimize their impact.
Blumira’s free trial is easy to deploy; IT and security teams can start seeing immediate security value for their organizations. Sign up for a free trial to start detecting and mitigating exposure related to Windows vulnerabilities.
For more information on how to secure against Windows vulnerabilities, download our free guide: