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).
