Category Archives: Anti-Forensics

Playing with Delay-Loaded DLLs…

Posted on by

Delay-Loaded DLLs is PE file feature that is almost obsolete today. Programmers who wanted to benefit from this mechanism in the past would write a program that would use many Windows API same as usual. During the linking process though they would enforce some restrictions: forcing some DLLs and their imports to be resolved some time later after the actual program start. This was meant to speed up the loading of the program and use less memory. In practice, it’s just a convenient mechanism that resolves APIs dynamically ‘just-in-time’ so that programmers can use API calls transparently & don’t need to write their own wrappers (or use LoadLibrary/GetProcAddress directly).

We can take the advantage of this mechanism to implement a simple beacon by adding a DLL name to delayed import table, and then using hex editor (or a quick script) to replace the name of this DLL with a UNC path in a same way as the PDB example:

Once program is executed, and the function that is resolved dynamically is encountered, the program’s library function will attempt to load that particular DLL (i.e. in our case it will try to resolve the UNC path and as such will ping the destination address). The DLL could be of course present on that remote site, or the the dynamic loader could be executed within an exception handler wrapper so that the program can continue…

Interestingly, Dependency Walker shows the UNC path when the program is told to view the imports used by the test exe file. It doesn’t stop it though from trying to load the delayed DLL from that UNC path. And because of that, the actual ‘call home’ ping can be made w/o execution of the main sample!

This is again should act as a warning against testing samples on systems that are online. Even static analysis could sometimes be harmful, especially if you use tools that blindly trust the input, or even worse, utilize LoadLibrary to load the DLLs that programs are linked to.

Playing with Program database paths…

Posted on by

Many executables include references (typically in a form of .pdb file name) to a program database path used by the software. This path typically points to some location on the software author’s system. I actually tried to cluster these paths in the past to build a list of account names used by malware authors. Of course, today it’s much harder – many modern malware authors randomize this path so it can evade signatures/yara rules.

These paths are used only by programs that actually… use them – primarily debuggers. It is a limitation, but it crossed my mind that we could still try to modify a PDB path to point it to any file really.

After test change and loading the program into Olly debugger I immediately saw that it tries to read the file from various locations. Interestingly, Olly tries to locate the pdb file based on a file name first. It looks for it in a debuggee’s current directory, then in ‘.\exe’ subdirectory, then ‘.\symbols\exe’, then comes back to the current directory and checks the same file name, but with a ‘.pdb’ extension, and finally in the fullpath provided inside the debug section:

This is interesting.

My first thought was to try to DoS Olly by making a reference to c:\pagefile.sys. This didn’t work, because Olly only reads a chunk at the top of the file, then bails out when the file is not present/proper. Also, it doesn’t seem to ‘see’ files with hidden/system attributes.

Another option I looked at was to point it to a file that could be e.g. including EICAR string. Any program reading such file will most likely trigger AV detection – as such killing and quarantining the debugger – – this could act as a truly naive anti-debug technique. Of course, such decoy EICAR file needs to exist first, so program would need to create it after first run. In such case tho, AV would pick the program instead! A perfect catch 22.

Then I thought of another option: we could use it as a beacon. This actually seemed to work pretty fine:

– I could see the request going out to the specified IP:

This could affect not only debuggers, but also any vendor tools that load files and leverage these debug sections by default (e.g. any sort of more advanced automation). As a result, it could flag attackers that the file is ‘burnt’, or the red team’s activity got discovered.

The chances for it being really practically useful are pretty low, but again, there maybe other ideas on how to leverage it that I have not thought of.

After writing this post, one more idea came to my mind – this could be a neat trick against CTF participants.

Anyone ‘caught’ to be using debugger in an online environment could be rickrolled, or put on a ‘harder’ track as a punishment for doing analysis w/o precaution. And of course, a cleverly designed .pdb delivered if analysis was made online could actually throw analysts off as well (e.g. by creating labels in program that could mislead / confuse disassemblers/debuggers).