You are browsing the archive for PDB Paths.

PDB Goodness

August 31, 2019 in Clustering, PDB Paths

In a recently published Definitive Dossier of Devilish Debug Details, Steve Miller is going on a very entertaining adventure of looking at PDB paths of known malware campaigns and authors. I love this article, because I have always felt that PDB is a great forensic artifact, often overlooked, and even if I did some research on it in the past myself, I have never seen a comprehensive study on a level that Steve delivered.

Inspired by it, I had a quick look at PDB paths of… primarily clean files. I am saying primarily, because while I am almost certain that most of them are clean one can never be sure 100%… To support the claim, I can list a couple of paths I found in this (allegedly) clean corpora suggesting that clean probably means different things to different people:

  • D:\TEMP\fuckingasus\Debug\fuckingasus.pdb
  • D:\Work\pgtool\svn\pgtoolfuck\Release\RTNicPgW32.pdb
  • D:\Work\pgtool\svn\pgtoolfuck\x64\Release\RTNicPgW64.pdb
  • d:\tmp\1driver\fuck4\rtl818xb\platform\ndis6\usb\objfre_wlh_x86\i386\rtl8187.pdb
  • C:\TMP\shit\msikbd.2k\objfre\i386\msikbd2k.pdb
  • c:\WORK\XPSDriver\oishitts_view\oishitts_xpsdrv093_051208_build\XPSRenderer092\xpsdriver\AquaFilter\Release\Win32\AquaFilter.pdb
  • C:\Users\lol g\Desktop\PowerBiosServer_20561\PowerBiosServer_20080428\PowerBiosServer\obj\Release\PowerBiosServer.pdb

I still believe that most of these are clean, and… perhaps an honest mistake made these paths incorporated into final executables ;), and who knows… maybe even some of them got signed 😉

Looking at all these paths we can draw some quick conclusions:

  • We could use them to generate a bunch of good yara signatures that catch good stuff; helps with clustering
  • Of course, since the file is now public, it means that bad guys could re-use existing paths to bypass aforementioned potential yara sigs by making them trigger on bad stuff pretending to be a good stuff
  • We see that Perforce, SVN, CVS, GIT are popular repos and perhaps their presence can indicate a proper software development practice at a company that generated the executables (could this alone be a good indicator for determining if the file is benign?)
  • Lots of different programming languages in use
  • Lots of personal build environments (1K user unique names under c:\users folder alone!)
  • Some coders compiled programs under an Administrator account (in fairness, my corpora are files between 2000-2019, so plenty of files come from the old-school times when Admin was a default for everything)
  • There are traces of some beautiful build environments out there; seriously, these are symptoms of very mature development practices visible directly in some of these PDB paths (their clusters)
  • Surprisingly, many paths are outside of C: drive — could this be a generic indicator of ‘good’ too?
  • Also, some of the usernames are clearly test-related; I am curious if these are overlooked in a final build, or some files were ‘leaked’? (test, Test, SKtester, nbtester, cvcctest, Pretest, tester, test5, TestUser, Test2, Test05, TestPC, Pinocchio_test)
  • We have users from all over the place: English/American, Chinese, Indian, Irish, French, Korean, Russian, Arabic, etc.

You can download a zipped archive with PDB paths here.

Note: This file is watermarked; you cannot use it for commercial purposes.

Playing with Program database paths…

June 2, 2019 in Anti-Forensics, PDB Paths, Random ideas

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