You are browsing the archive for Malware Analysis.

Logs from 1.6M sandboxed samples – release

July 17, 2019 in Batch Analysis, Clustering, Malware Analysis, Sandboxing

Update

Silas offered to host a mirror of the file – you can download it from here. Thank you very much Silas!

Old Post

On 31st of Dec 2017 I released a sampleset of my sandbox reports. It was a subset of a much larger set.

Today I am releasing the whole set – 1.6M+ samples.

The biggest challenge for a release like this is… space. Luckily, VirusShare graciously offered space to host the project so… thank you very much J-Michael!!!

The file apilog_2019-07-14.zip is available from VirusShare page. It is a 11GB archive, and it takes 200GB after unzipping.

The file format is very straightforward: it’s a large, single text file where reports are saved one by one, with a delimiter similar to the one used in the previous dump:

SAMPLE #<number> – <md5>

<report>

Yup. This time you have got a md5 hash too, so can map reports to actual samples.

As usual, it may contain bugs, errors, omissions, and other booboos. You have been warned. Also, it’s not OK to use it commercially.

This is the top of the file:

DefineDosDevice symbolic link trick

June 21, 2019 in Anti-Forensics, Archaeology, Malware Analysis

I don’t know who is the original author of this trick – I saw it being used by some malware a few years ago and it was also discussed on KernelMode forum, and StackOverflow. Reading McAfee’s paper about Process Reimaging I suddenly remembered it.

How does it work?

With a DefineDosDevice API (the same API that is used by the subst command) we can create a new MSDOS device name. We can map it to a new, non-existing file path. The main executable can be then moved to that new space (i.e. new path the space is mapped to).

This little trick makes the original file ‘disappear’ from the system. Most of the process listing tools continue to map the running process to its original path, yet any attempts to access properties of the file itself end up with nothing. This is because the process is running, but the file it was launched from is ‘not there’ anymore:

Let’s examine it step by step:

  • Create a foobar namespace using DefineDosDevice and point it to \??\c:\test\test_hidden.exe.
  • Move the current process’ file e.g. c:\test\test.exe to \.\foobar.

That’s it.

In my test case I just renamed test.exe to test_hidden.exe, still inside the c:\test. It could be any location really, including very deeply nested directories that may be harder to inspect w/o forensic tools.

To find such mapping, one has to use tools like WinObj – it shows the DosDevice called foobar that points to the .exe:

One can also launch it via \\.\foobar (need a dedicated tool tho).

And if you are wondering what Sysmon will see when we launch such hidden file – luckily, it will link to a proper image on the drive:

Last, but not least – we can create a space that maps to Alternate Data Stream too 🙂 e.g. \??\c:\test\test.exe:hidden. In such case, a copy command can be used to copy files to such newly-created space/location e.g.:

  • copy test.exe \\.\foobar