Blog

Archive for August, 2019

Compressed ISO Files (ISZ), (Mon, Aug 19th)

While researching a user submitted Direct Access Archive file (DAA), I learned about another file format I too had never heard of before: compressed ISO files, or .isz files.

ISZ files are similar to DAA files: insofar they also contain an ISO file, split in chunks that are then compressed. Like DAA, it’s a proprietary format, however, the ISZ specification is available publicly.

I highlighted the zlib header in the screenshot above.

My tool search-for-compression, that I showed in yesterday’s video and that can be downloaded from my beta github repository, is also able to decompress this format:

We have not yet received malicious ISZ files submitted by readers, and I’ve not read reports about malicious compressed ISO files. The future will tell if we will see ISZ files created by malware actors.

If you do encounter them, please submit a sample.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Video: Analyzing DAA Files, (Sun, Aug 18th)

This is a video to illustrate the analysis of DAA files (Direct Access Archives), discussed in diary entries “Malicious .DAA Attachments” and “The DAA File Format“.

As can be expected, these DAA files, sent as email attachment, contain a malicious Windows executable (PE file).

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

The DAA File Format, (Fri, Aug 16th)

In diary entry “Malicious .DAA Attachments“, we extracted a malicious executable from a Direct Access Archive file.

Let’s take a closer look at this file format. Here is an hex/ascii dump of the beginning of the file:

With the source code of DAA2ISO, I was able to make some sense of this data. I highlighted important parts:

  • First we have the magic sequence: DAA…
  • Second, we have an offset (0x0000004C) to the list of compressed chunk lengths
  • Third, we have the file format version: 0x00000100
  • Fourth, we have an offset (0x0000005E) to the first compressed chunk
  • And then we have the list of chunk lengths (position 0x0000004C)
  • And the chunks themselves (position 0x0000005E)

The list of compressed chunk lengths is a bit special: each lenght value is encoded with 3 bytes, using neither big-endian nor little-endian format.

The number format is the following: hex value 697 is encoded as 00 97 06. So first you have the most significant byte, then the least significant byte, and then the remaining, middle byte.

Together with the pointer to the first compressed chunk (position 0x0000005E), we can use this length list to calculate the offsets of the other compressed chunks.

Example: the second chunk is located at 0x5E + 0x697 = 0x06F3. DAA version 0x100 uses zlib compression (DEFLATE), and the compressed data is stored without header.

Armed with this information, I could write a Python script to extract and decompress the chunks stored inside a DAA file.

However, I wrote a different program. For quite some time, I was playing with the idea to write a program that can detect compressed data inside a binary stream. Since a DAA file is essentially a concatenation of zlib compressed chunks, such a program should also be able to extract and decompress the ISO file inside a DAA file.

Here is the result of my beta program running on the DAA sample:

Each line represents compressed data found by the tool. The columns are:

  1. start position of compressed data (hexadecimal)
  2. size of the compressed data (decimal)
  3. size of the decompressed data (decimal)
  4. size of the remaining data (decimal)

This generic method will also generate false positives: data that decompresses but is not actual compressed data. Like the first line: it’s very small (4 bytes compressed, 2 bytes decompressed) and is actually inside the DAA header. So this is clearly a false positive.

Option -n can be used to impose a minimum length on the compressed data. This can be used to filter out some false positives:

Remark that the first byte sequence of compressed data is found at position 0x5E, the same position as mentioned in the header.

And the second byte sequence of compressed data is found at position 0x6F5, that’s the position that we calculated with the length of the first chunk.

All decompressed chunks have a size of 65536, except the last chunk: that’s how the DAA format stores the embedded ISO file. It’s chopped-up in chunks of 65536 each, that are then compressed.

Finally, I can use option -d to decompress and concatenate all compressed chunks:

A similar file format is also used for other CD/DVD image formats, like the gBurner format, compressed ISO format, …

 

 

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Analysis of a Spearphishing Maldoc, (Thu, Aug 15th)

A spearphishing attack with a VBA maldoc on US utility companies was mentioned in SANS NewsBites Vol. 21, Num. 61. I always like to take a look at malicious documents mentioned in the news. Luckily for me, Proofpoint’s analysis includes the hashes of the maldocs, and  one maldoc can be found on VirusTotal.

This maldoc stands out because of the large size of its VBA stream (analysis with oledump.py):


It contains many hexadecimal strings, to be concatenated.

There are 3 embedded files in this maldoc (using hexadecimal strings in the source code). The first one uses variable psz1. Grepping for “psz1 = ” and using re-search.py to extract the embedded strings (minus double quotes), the hexadecimal digits that make up a file can be extracted:

This can then be decoded with base64dump.py, using option -e hex for hexadecimal decoding and -w to ignore all whitespace:

This is a certificate in PEM file format. If you’ve read my blog post “PowerShell Inside a Certificate?“, you know that the first letter of the binary data inside a PEM certificate has to be M. Anything else, and you know that the PEM file contains something else than a certificate. Especially when it starts with TVq…: that’s MZ in BASE64, or a Windows executable (PE file).

Running base64dump.py a second time finds the embedded executable:

This executable can be found on VirusTotal using the reported MD5 hash.

The second file can be extracted with the same method, this time grepping for variable s2:

This is also an executable, present on VirusTotal.

And the last file, variable s3, same method:

This is not an executable, but a configuration file, as explained in Proofpoint’s blog post:

The obfuscated extraction commands can be found at the end of the VBA stream:

Deobfuscating these commands is not hard, just remove ” & “:

And as could be expected, we see that the certutil command is used to extract the executables and config file from the PEM files.

 

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 3 of 6 12345...»