Last year on the show, Marcus J. Carey presented a tech segment about using memory analysis in penetration tests. Memory acquisition came into its own for incident responders a few years back. Even before tools like Volatility, Memoryze or HBGary's Responder were available, many incident responders, including me, used the strings command to perform rudimentary searches and "analysis" of memory artifacts.
Figure 1: strings output of a Linux VM's memory image. The highlighted "forensics" happens to be the root password.
Shortly after Carey's presentation, DarkOperator posted a Meterpreter script that would dump memory and save it offline for later analysis. Passwords are a high value memory artifact for penetration testers. As someone working in app sec and incident response, Carey got me thinking about other things that forensics practitioners may find commonplace, but that may be overlooked by penetration testers. Both disciplines inform each other.
Let's say you're a penetration tester (or an Amortized Perennial Threat as Shawn Moyer says he is) and you're working for a client who wants you to go beyond the shell. Your client has requested that you go after important company data. Databases are an obvious target, but companies also have critical information floating around in Microsoft Office documents (e.g. business plans, bid contracts, vulnerability remediation tracking information, etc.).
What is the best way to locate these documents? You could manually navigate the various common directories where people store documents, read the directory listings and copy down those files that look interesting. But this is a labor intensive process and you may miss something if the user has tucked important files in odd locations.
If only there were a place on the file system that held information about files, a place where we could look and see all of the files that had been opened on the system and that would map back to the location of those files, even if those files were on network shares or removable media. Fortunately for us, there is such a location, in fact, there are two well known ones.
Windows systems have a feature that creates shortcuts for common document types, including Office files when those files are opened by a user. The idea of using these shortcuts during a pen test is not new. In fact, it was mentioned before on Security Focus' Pen-Test mailing list, but I don't believe it's been ahem, weaponized until now.
These shortcuts or link files are created by Windows to facilitate the "Recent" document features of modern Windows operating systems. For Windows XP the default location for link files is under Documents and Settings\<username>\Recent with Microsoft Office files having their own location in Documents and Settings\<username>\Application Data\Microsoft\Office\Recent\. Vista and later versions of Windows have moved the recent link files to Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\ and Users\<username>\AppData\Roaming\Microsoft\Office\Recent. There may be other locations specific to other applications as well.
dumplinks.rb can be used with the Meterpreter to dump the contents of Windows' .lnk files either to the Metasploit user's local file system, or to the console. By default, dumplinks.rb, runs in a less verbose mode than Carvey's lslnk.pl, in that it only reports the time stamps for the .lnk files themselves, then prints the time stamps contained within the .lnk files that are time stamps for the target file and finally, the target file's location is printed.
Enough drivel, here's a couple of screen shots:
Figure 2: dumplinks help screen
And one of the script in action, dumping to the console:
Figure 3: dumplinks sending everything to the console
Of course there are other tools and techniques that cross-over from forensics to penetration testing. I will be back with another, as soon as I can find the time. For now, enjoy the dumplinks.
Dave Hull describes his working life as on the Venns between incident response, forensics and web applicaiton security. He will be teaching SANS Forensics 508: Computer Forensics Investigation and Incident Response in Boston, March 15 - 20