You are browsing the archive for Anti-Forensics.

7z & Multi-volume archives

May 5, 2020 in Anti-Forensics, File Formats ZOO

This post is pretty much a summary of what I twitted the other day. I thought it will be good to post it in one place in case anyone is interested.

7z is a very flexible archiver and its support for multi-volume archives is just a natural consequence of other archivers supporting this feature, including Rar and Winrar that have it implemented since like… for-e-v-e-r.

While experimenting with 7z I noticed that it’s possible to make multi-volume archives with its first file being just… 1 byte. I was perplexed by it and started digging, because if this is the case, all the forensic tools that look for file magic, or even file extensions may need to rewrite their parsers.

So, for starters… you can run this:

7z a foo.7z -v1 -v10M

This creates a number of 7z archives with the first one being just one byte long:

The naming convention is interesting. As you can see, the standard .7z file extension is followed by a 001, 002 for two consecutive volumes created:

  • foo.7z.001
  • foo.7z.002

When I tested the same thing for Zip archives (still using 7z), I ran this:

7z a foo.zip -tzip -v2 -v10M

I noticed that for Zip files 7z needs at least 2 bytes in its first volume, but everything else works the same way as for .7z.

Finally, you can use Rar / WinRar to build a Rar archive, and then keep ‘R’ – the first character of the Rar! signature – in the first volume file, and the rest of the archive in another as demonstrated on this picture:

When I looked at the actual code of 7z to see how it interpretes file extensions:

I noticed that the code is relying on only the first character of its file extension to determine whether it is a zip or rar multi-volume archive. So… you can rename the volumes to:

  • foo.r.01
  • foo.r.02

or

  • foo.z.01
  • foo.z.02

And you will still be able to process these with 7z.

While the good ol’ Unix tools can do the same (split, cat, gzip, etc.) it is still an interesting find. 7z is used a lot on Windows boxes and people w/o much technical knowledge could use these built-in features w/o a need to learn much of *NIX CLI.

It really kinda changes the dynamics of the way file extensions should be understood and processed, and how access to archive files – especially these that by design are multi-volume – should be handled, especially by security tools. And in particular, these that help in malware detection and post-intrusion analysis. And perhaps… this is just a tip of the iceberg.

Hiding process creation and cmd line with a long com…

March 29, 2020 in Anti-Forensics, Compromise Detection, EDR

How long is the command line buffer?

Depends on a program…

How much of command line do Sysmon, 4688 events log?

A finite amount.

‘Depends’ minus ‘finite’ == opportunity.

Re-visiting my old Sysmon demo where I’ve shown how to hide long command lines I thought that it would be interesting to check a different idea:

  • Write a program A that launches program B
  • Program A passes a very long command line to program B
  • Program B retrieves the command line and prints out last 5 characters only

The idea was to check if we can use the end of that long buffer as a covert channel for two processes to exchange some data (lame IPC)…

After testing it with 4688 and Sysmon enabled I spotted two things:

  • 4688 completely missed the process B creation
  • Sysmon log truncated the last bits of the command line (these 5 characters!!!) with ellipsis.

The pic below shows how 4688 log looks like:

  • We can see the invocation of the program A (first event 4688), followed by conhost.exe and then Program B is not logged at all.
  • Then we see program termination – Program A, Program B, and conhost.exe.

Sysmon logged a long command line, but the last bits are truncated and replaced by the ellipsis:

This is the invocation of ProgramB that I used (via CreateProcess):

 buffer dw 'p','r','o','g','r','a','m','B',' '
 dw 32698 dup(0FABEh)
 dw 'h','e','l','l','o'
 dw 0

and this is what ProgramB shows: