Thread by @stvemillertime

One #DFIR / #INFOSEC thing that is useful to me that I wished I had learned sooner: the art of PDB path pivoting for #threatintel and mal analysis. This is pretty easy, but can be a crazy strong pivot for anyone studying large, tenured threat groups such as many espionage actors.

PDB Path Pivoting Primer

This is a tweet thing about malware PDB paths and their role in the disco, DFIR and/or #threatintel processes, using #KeyBoy as an example.

3/4) What are PDBs?
5) Where/why will I see PDB paths?
6/7) How can I use PDBs paths?
8-n) PDB paths and #KeyBoy

What are PDBs?

Program Data Base (PDB) files are used to store debugging info about a program when it is compiled. The PDB stores symbols, addresses, names of resources etc. Malware devs often have to debug their code and end up creating PDBs as a part of their dev process.

Inside another sample PDB we see links to the original CS code files in the development folder. This malware must be super l33t because the devs username is DarkSkeleton.

Where will I see PDB paths?

If a malware dev has "debugging enabled", the PDB path is often embedded in the debug portion of a PE upon compilation. The PDB path gives insight into the dev computer and can leave clues that for analysts discover additional malware.

How can I use PDB paths?

Analysts use PDB paths to: infer things about the malware development environment; cluster/relate malware families; discover new malware and tools made in the same dev environment. Here we see a PDB path under IMAGE_DEBUG_TYPE_CODEVIEW

You'll want to tokenize the PDB path and search for the most unique values, especially for user and PDB file names, which often do a great job at contextualizing the program's development, purpose, and history.

PDB paths and #Keyboy

I used the unique values in the PDB to start searching for related malware and ended up with a cluster of ~300 samples, ~250 PEs, ~80 of which had embedded PDB paths in the main file or a subfile.

With a simple chart of samples by timestamp and export DLL name, we see a concerted development effort for several related malware families, each with increasing sophistication, over a span of 10+ years (actually 2005 - 2018, but alas, I can only show so much...)

Naturally, the devs evolved their malware over time. Launching backdoors went from HTTP downloading to search-order hijacking to bitsadmin jobs. Persistence moved from services to registry to memory-only (none). C2 moved from HTTP to binary to binary-over-built-in @wolfSSL.

PDB paths are an important pivot for any analyst studying malware, mal developers, or mal operators. I started with one random file PDB (d:\work\project\vs\) and built my cluster from 2018 backwards in time using string pivots (Yara scans and a lot of Googling and reading)

A decade ago, the code was sloppy, the malware was noisy, and the error comments were childish. The current malware shows code and capabilities that are modern and professional.

There are no smoking guns here. These dev environments may have supported multiple devs and multiple threat actors over the years. We will never know. Still, it is worthwhile to note that nearly *every* single sample of #KeyBoy malware uses pieces of a common older code base.

Hope that was a fun and maybe informative (?) read. I leaned heavily on public #KeyBoy lit from @rapid7, @TrendMicro, @citizenlab, @PwC_UK, @alienvault and VSEC. Thanks y’all.

Pro tip: dont forget to turn off debugging before you build your implants. #adversarymethods