Microsoft’s patch for CVE-2020-0601 introduces a call to CveEventWrite in CryptoAPI when a faked certificate is detected.
This will write a Windows event entry in the Application event log.
For all of you out there in restricted corporate environments who need to test the processing of this event log entry, I wrote some VBA code to generate this event. The generated event will mimic a CVE-2020-0601 warning to some extent (didn’t bother getting para and otherPara right).
Copy the VBA code below in an Office application that supports VBA, like Word, and run the code. Then check your Application event log.
Option Explicit
'VBA7
Declare PtrSafe Sub CveEventWrite Lib "advapi32" (ByVal CveId As String, ByVal AdditionalDetails As String)
Sub TestCveEventWrite()
Dim strCveId As String
Dim strAdditionalDetails As String
strCveId = "[CVE-2020-0601] cert validation"
strAdditionalDetails = "CA: <@DidierStevens> sha1: 7A036FBBDBF7F29A3821A8087CE177E60927A6F3 para: something otherPara: something"
CveEventWrite StrConv(strCveId, vbUnicode), StrConv(strAdditionalDetails, vbUnicode)
End Sub
That special ZIP file is a concatenation of 2 ZIP files, the first containing a single PNG file (with extension .jpg) and the second a single EXE file (malware). Various archive managers and security products handle this file differently, some “seeing” only the PNG file, others only the EXE file.
My zipdump.py tool reports the following for this special ZIP file:
zipdump.py is essentially a wrapper for Python’s zipfile module, and this module parses ZIP files “starting from the end of the file”. That’s why it finds the second ZIP file (appended to the first ZIP file), containing the malicious EXE file.
To help with the analysis of such special/malformed ZIP files, I added an option (-f –find) to zipdump. This option scans the content of the provided file looking for ZIP records. ZIP records start with ASCII string PK followed by 2 bytes to indicate the record type (byte values less than 16).
Here I use option “-f list” to list all PK records found in a ZIP file containing a single text file:
This is how a normal ZIP file containing a single file looks on the inside.
The file starts with a “local file header”, a PK record that starts with ASCII characters PK followed by bytes 0x03 and 0x04 (that’s 50 4B 03 04 in hexadecimal). In zipdump’s report, such a PK record is identified with PK0304. This header is followed by the contained file (usually compressed).
Then there is a “central directory header”, a PK record that starts with ASCII characters PK followed by bytes 0x01 and 0x02 (that’s 50 4B 01 02 in hexadecimal). In zipdump’s report, such a PK record is identified with PK0102. This header contains an offset pointing to the corresponding PK0304 record.
And at the end of the ZIP file, there is a “end of central directory”, a PK record that starts with ASCII characters PK followed by bytes 0x05 and 0x06 (that’s 50 4B 05 06 in hexadecimal). In zipdump’s report, such a PK record is identified with PK0506. This header contains an offset pointing to the first PK0102 record.
A ZIP file containing 2 files looks like this, when scanned with zipdump’s option -f list:
Starting with 2 PK0304 records (one for each contained file), followed by 2 PK0102 records, and 1 PK0506 record.
Armed with this knowledge, we take a look at our malicious ZIP file:
We see 2 PK0506 records, and this is unusual.
We see the following sequence of records twice: PK0304, PK0102, PK0506.
From our previous examples, we can now understand that this sample contains 2 ZIP files.
Remark that zipdump assigned an index to both PK0506 records: 1 and 2. This index can be used to select one of the 2 ZIP files for further analysis. Like in this example, where I select the first ZIP file:
Using option “-f 1” (in stead of “-f list”) selects the first ZIP file in the provide sample, and lists its content.
It can then be further analyzed with zipdump like usual, for example, selecting the first file (order.jpg) inside the first ZIP file for an hex/ascii dump:
Likewise, “-f 2” will select the second ZIP file found inside the sample:
-f is a new option that I added for special/malformed ZIP files, but this is a work in progress, as there are many ways to malform ZIP files.
For example, I created a PoC malformed ZIP file that contains a single file, with reversed PK record order. Here is the output for the normal and “reversed” zip files (malformed, e.g. PK records order reversed):
This file can be opened with Windows Explorer, but there are tools and libraries than can not handle it. Like Python’s zipfile module:
I will further develop zipdump to handle malformed ZIP files as best as possible.
When you issue the command “oledump.py -y trojan.yara sample.vir”, oledump will load all the rules found inside file trojan.yara, and scan the streams of document sample.vir with these rules.
But if you want to search for a simple string, say “virus.exe”, then you have to create a YARA rule to search for this string, store it inside a file, and pass this file to oledump via option -y.
Ad hoc rules make this process simpler. Ad hoc rules start with #.
To generate an ad hoc rule for a string, use prefix #s#. Like this:
I regularly want to test the behavior of applications opening files downloaded from the Internet.
On Windows, files downloaded from the Internet (with Internet Explorer or Edge, for example) have metadata in an Alternate Data Stream to indicate their origin. This is the Zone.Identifier ADS.
To simulate a download, I will add the ADS myself, and I often refer to my own blog post here and here, as I don’t remember the exact syntax and numbers.
Until recently.
Now, I wrote a small Go program that helps me creating (and removing) the appropriate ADS for a mark-of-web (Zone.Identifier).
Just running zoneidentifier with a filename, will add a Zone.Identifier ADS for zone 3 (Internet) to the file. Like this:
Option -id is used to specify a different zone ID, like this:
And option -remove is used to remove a Zone.Identifier ADS:
This new version of oledump adds option -f to find embedded ole files, making the analysis of .DWG files with embedded VBA macros (for example) easier.
And there is a new plugin: plugin_version_vba.py. This helps with determining the VBA version.
Here is a video showing the analysis of .DWG files with option -f:
Didier Stevens 