Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Windows Zeroday Actively Exploited: Type 1 Font Parsing Remote Code Execution Vulnerability

Published: 2020-03-23
Last Updated: 2020-03-24 01:22:42 UTC
by Didier Stevens (Version: 1)
0 comment(s)

Microsoft announced limited exploitation of a zeroday remote code execution vulnerability in the type 1 font parser.

There are two RCE vulnerabilities in Windows Adobe Type Manager Library on Windows system, when parsing Adobe Type 1 PostScript format. There are multiple attack vectors, like documents.

Microsoft is working on a patch.

Following mitigation actions can be taken:

  • Disable the Preview Pane and Details Pane in Windows Explorer
  • Disable the WebClient service
  • Rename ATMFD.DLL

 

Remark that Microsoft points out the following in its advisory:

For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities.

 

Update: I can't find ATMFD.DLL on any of the Windows 10 machines I have access to, unless it's a version older than 1809. This DLL must have been removed when upgrading to 1809, and this could explain Microsoft's remark about supported version of Windows 10 and AppContainer sandboxes (1803 and older are no longer supported).

Update 2: Microsoft has updated the advisory to version 1.1, confirming that ATMFD.DLL (a kernel mode font driver) has been replaced by FONTDRVHOST.exe running in an AppContainer. In other words, this vulnerability that is inside kernelmode font parsing code in Windows 7, 8 and older versions of Windows 10, is no longer inside the kernel but in an AppContainer with limited privileges.

 

Microsoft advisory ADV200006

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords: font windows zeroday
0 comment(s)

KPOT Deployed via AutoIt Script

Published: 2020-03-23
Last Updated: 2020-03-23 18:31:52 UTC
by Didier Stevens (Version: 1)
0 comment(s)

I have other samples like the malware I covered in yesterday's diary entry.

All with the same body and attachment, it's just the sender that varies. The PowerShell scripts are the same and download from show1[.]website. Like I wrote yesterday, three files are downloaded:

  1. A legitimate, signed AutoIt interpreter (this is not malware)
  2. A heavily obfuscated AutoIt script, that is encoded as a PEM certificate
  3. An encrypted EXE: KPOT info stealer

The PowerShell script uses certutil to BASE64-decode the "certificate" to the AutoIt script, and then lauches the AutoIt interpreter with the script as argument.

The AutoIt script contains process hollowing shellcode (known as frenchy shellcode), that decrypts the encrypted PE file as guest and uses 32-bit dllhost.exe as host (as process hollowing host, not as dll host).

The PH shellcode contains mutex name "frenchy_shellcode_06", but this name is randomized by the AutoIt script before it is injected and executed.

As the decrypted KPOT EXE is never written to disk, it was unknown by VirusTotal. I did submit it today.

KPOT is an infostealer, as can be guessed from the strings found inside the executable:

More interesting strings are simply XOR-encoded (1-byte key).

Like the C2:

And the targets:

Usually, I explain in detail my analysis steps, so that you can reproduce them. I will do this too for this executable in one or more upcoming diary entries.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords: autoit kpot malware
0 comment(s)
Diary Archives