An info stealer is malware that steals credentials or files from its victims.
Info stealers don’t require admin rights to perform their task, and can be designed to evade or bypass AV, HIPS, DLP and other security software.
I helped out a friend testing his environment with a PoC PDF info stealer I designed (I will not publish it).
This PDF document exploits a known vulnerability, and executes shellcode to load a DLL (embedded inside the PDF document) from memory into memory. This way, nothing gets written to disk (except the PDF file). The DLL searches the My Documents folder of the currect user for a file called budget.xls, and uploads it to Pastebin.com.
My PDF info stealer was succesful: file budget.xls was posted to Pastebin.com
Preventing an info stealer from operating is not easy. The Windows operating system is designed to give user processes unrestricted access to the user’s data. It’s only starting with the Windows Vista kernel and Windows Integrity Control that a process can be assigned a lower level than user data and be restricted from accessing it. Lowering the Integrity Level of Acrobat Reader will help us in this case, but if I exploit an Excel vulnerability (or just use macros, without exploiting a vulnerability), the integrity levels will not protect us.
Neither is preventing data egress easy. OK, you can decide to block Pastebin.com. But can you block all sites that can be posted to? Like Wikipedia? And if you can, do you block ICMP packets?
To protect confidential data, don’t let it be accessed by systems with Internet access. That’s not very practical, but it’s reliable. Or use strong encryption with strong passwords (not the default RC4 Excel encryption). The info stealer will have the extra difficulty to steal the password too.
I know this is obvious advice, but it’s not easy protecting data from carefully designed info stealers on Windows.
Didier Stevens 
Hmm. Not good. I assume that you were using one of the recent published exploits? Is disabling the JavaScript funtionality sufficient to mitigate against your PoC?
Comment by Rich — Monday 8 March 2010 @ 0:29
PDF-Dokument sucht und versendet beliebige Dateien…
Mal wieder hat Didier Stevens in seinem Blog einem Beitrag veröffentlicht, der beschreibt, warum man mit PDF-Dateien sehr vorsichtig sein sollte. Und das nicht nur bei Dateien aus unbekannten Quellen. Wie leicht sich mit einer manipulierten PDF-Datei s…
Trackback by Klipper on Security — Monday 8 March 2010 @ 0:42
Search-and-send PDF files…
Again Didier Stevens demonstrates the danger that comes along with PDF files. In his blog he showed how easy it is to spread malicious PDF files in order to search-and-send confidential information to the Internet. His example shows, how he exploited a…
Trackback by Klipper on Security — Monday 8 March 2010 @ 0:53
@Rich Actually, I exploit an old vulnerability, util.printf. I made a PDF because that’s the easiest for me to make with my tools.
Like I wrote, this can be done by exploiting another application like Office, or even with plain macros and some SE.
Comment by Didier Stevens — Monday 8 March 2010 @ 11:01
The exploit targets *Adobe* reader, right? What about other free PRF readers such as Foxit or PDF-XChange? Are they immune? If so, it should be pointed out that this is about an *Adobe* weakness, not a general PDF weaknes!
Comment by Christoph Schmees — Monday 8 March 2010 @ 16:29
@Christoph Schmees It’s not about the vulnerability or the exploit, but about the payload. Like I wrote: I can do this with Office vulnerabilities too, or even without any vulnerability, just social-engineering you to open a spreadsheet and execute macros. I use an old Adobe Reader vulnerability (util.printf) to execute the info stealer payload, but like I said, that’s just because it’s easy for me to do so.
Comment by Didier Stevens — Monday 8 March 2010 @ 17:29
[…] people have asked me about de details of the vulnerability I exploited in my PDF Info Stealer PoC. But that’s not important. It’s not about the exploit, it’s about the payload: […]
Pingback by Frisky Solitaire – Another Info Stealer « Didier Stevens — Tuesday 9 March 2010 @ 0:01
Any way of releasing the payload itself, So it loads a certain dll into the memory to search for important files in which you gave it to search e.g. passwords.xls, secret.txt, http://ftp.txt could it search for more than one file or do you have to edit shellcode each time?
Comment by Nazz — Saturday 13 March 2010 @ 20:14
No, even if I call this a PoC, the payload is still an info stealer, I’m not publishing this. And the DLL can be adapted to collect several files.
Comment by Didier Stevens — Sunday 14 March 2010 @ 21:22
Interesting technique…
Is there a string in the dll looking for “My Documents”?
Comment by Irgendwer — Wednesday 17 March 2010 @ 18:52
@Irgendwer No, I just call SHGetFolderPath with CSIDL_PERSONAL to get the absolute path to My Documents.
Comment by Didier Stevens — Wednesday 17 March 2010 @ 18:58
Very interesting and somewhat disturbing for those tasked with preventing data leakage. Thank you for posting this.
(Its a shame people seem to have fixated on the mechanism you have used, PDF, rather than the more worrying concept it demonstrates).
At the moment it does seem like encryption is the only real mitigtion against this – assuming it can workout unexpected file names.
Comment by GreenSquirrel — Monday 22 March 2010 @ 19:57
[…] c’est quand Didier Stevens y intègre un programme pour voler des informations sensibles. Ce billet montre comment un « simple » fichier PDF est capable de chercher puis de transmettre […]
Pingback by Bruno Kerouanton » Failles PDF… — Thursday 1 April 2010 @ 6:49
[…] of todays major security loopholes is malformed file types, i.e. PDFs that are not really PDFs or PDFs with something malicious attached or […]
Pingback by All PDFs are not created Equal « The Journeyler — Tuesday 15 March 2011 @ 21:12