Here are some screenshots of the signature of this Flame component (WuSetupV.exe).
Here are some screenshots of the signature of this Flame component (WuSetupV.exe).
I didn’t expect my virustotal-search program to be that popular, so here is a new version with new features and a few fixes (version 0.0.1 contained a buggy experimental feature I hadn’t planned to release then).
What I didn’t explain in my first post, is that virustotal-search builds a database (virustotal-search.pkl) of all your requests, so that recurring requests are served from that local database, and not from the VirusTotal servers. I’ve added a field (Requested) to indicate if the request was send to VirusTotal or served from the local database.
If you want all requests to be send to VirusTotal, regardless of the content of the local database, use option –force.
And if you don’t want to include your API key in the program source code, you have two alternatives:
Did you know that you can search VirusTotal? You don’t have to submit a file, but you can search for the report of a file has been submitted before. You use a cryptographic hash (MD5, SHA1, SHA256) to identify the file.
There are several tools to submit a batch of files to VirusTotal, but I didn’t find any that just searches VirusTotal for a list of search terms via VirusTotal’s API.
Thus I wrote my own Python program. It accepts a file with a list of hashes, and produces a CSV file with the result. Here is an example displayed with InteractiveSieve:
To get this program working, you need to get a VirusTotal API key and add it to this program. You need a VirusTotal account to get your API key.
And my program respects VirusTotal’s rate limitation (4 requests per minute), I don’t want it to DoS VirusTotal.
Last year I posted about some techniques and tools to restrict the rights of applications on Windows XP when you run with admin rights. I mentioned a new tool, LowerMyRights, which I forgot to publish. So here it is.
You would use LowerMyRights.dll only if the other tools and techniques are not appropriate for your specific case. LowerMyRights is useful when you can’t create a new process with restricted rights, but when you’ve to restrict the rights of an existing process.
When this DLL is loaded inside an existing process, it will check a whitelist and a blacklist to decide if it has to restrict the process’ rights (it also checks if it’s running on Windows XP). If the application’s name if found in the blacklist and not in the whitelist, LowerMyRights will do its job.
First, it will remove all the privileges of the primary token, except the SEChangeNotifyPrivilege.
Second, it will create a restricted token (with ACLs denying Administrator and Power Users rights) and use this token for impersonation (it uses impersonation because Windows doesn’t allow modifications to the ACLs of a primary token).
This impersonation is also a weak point of LowerMyRights compared with the other tools: exploit code can switch back to the unrestricted primary token by calling RevertToSelf.
You can load LowerMyRights inside all processes by adding it to the AppInit_DLL registry key, but be careful, this might cripple your system as it is loaded inside every process (even at boot time), so please test first.
Or else you use LoadDLLViaAppInit, or add it to the import table like explained here.
The whitelist (lowermyrights.wl.txt) is just a text file with a list of applications to whitelist (i.e. not lower the rights). You must use full pathnames in the whitelist.
The blacklist (lowermyrights.bl.txt) is just a text file with a list of applications to blacklist (i.e. to lower the rights). You must not use full pathnames in the whitelist, but just the application’s name.
The idea I had with this different operation of the whitelist and blacklist, is that you would be able to whitelist specific applications while blacklisting copies/fakes of these applications.
An example with notepad will make this clear: by adding c:\windows\system32\notepad.exe to the whitelist and notepad.exe to the blacklist, you would be able to use the original notepad.exe with full rights, while copies of notepad (located at other locations) or other programs with the name notepad.exe would be restricted. With hindsight, I don’t think this dual list feature is useful, but I left it in anyways (the program is a year old, I used it for a year and I haven’t modified it).
The title says it all…
This is a document I shared with my Brucon workshop attendees.
I know, this is a PDF document, you’ve to appreciate the irony ;-)
Here’s a heads up for some malicious PDF samples that are deliberately malformed to avoid detection.
The most important case is the missing endobj keyword:
Adobe Reader will happily parse a PDF where the object are not terminated with endobj, but my pdf-parser won’t. I’ll have to update the parser to deal with this case.
The cross-reference table can also be omitted:
This is not an issue for my parser.
And then I also received a sample with a stream object, where the case of the endstream object was wrong: Endstream. First we assumed Adobe Reader was not case-sensitive for the endstream keyword, but I found out it can actually parse a stream object with missing endstream keyword:
This is an issue for my parser.
Marcus Murray gave a great talk at TechEd Berlin 2009: “Hack-Proofing Your Clients Using Windows 7 Security”. In one of his demos, he showed a trojaned Excel spreadsheet. The spreadsheet was a simple text-based game, but it had a malicious component that executed surreptitiously while the game was played.
As I’ve done several hacks with Excel macros in the past, this made me realize that social engineering is a key element to get people to run macros from a spreadsheet of unknown origin.
Several 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: the info stealer. As I’ve written in my previous post, I don’t even need an exploit to get users to execute the info stealer. If I put the info stealer inside an Excel spreadsheet and social engineer the targeted users to execute the macros, I’ve achieved my goal without exploiting a software vulnerability.
I present you Frisky Solitaire:
Frisky solitaire is more compelling than text-based Excel games, because of the graphics. I took Solitaire from ReactOS, turned it into a DLL and embedded it with my memory loading shellcode into Excel macros (the same technique as I developed for cmd.dll and regedit.dll). I imagine that a simple game like Solitaire in Excel can go viral inside a company, when you know that many corporations disable standard Windows games on their desktops and Terminal Servers.
But in a crude attempt at social engineering the male population of a targeted company, I added an element of nudity to the game. The implied message of the game’s title is that winning games increases nudity. I know, I’m talking about basic instincts here, but it still does the trick…
So I imagine that this game can become popular with a large part of the male employees of a targeted company. And that they wouldn’t question the fact you have to execute Excel macros to play a game. Sounds plausible, no?
Of course, you guessed it: Frisky Solitaire is trojaned with an info stealer… No need to exploit a software vulnerability to steal info. Given that here too, everything is done in memory, detection is unlikely.
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.
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.
I produced a video where I disable util.printf:
Notice that when I blacklist util.printf, the script still executes until the blacklisted function util.printf is called. At that moment, the script is cancelled and the user is warned.
The framework is impervious to bypassing with some basic obfuscation techniques found in malicious PDFs (eval(“util.printf… ; x = util.printf; x(“… ).
I present you a new program to create the SafeBoot registry key with special permissions protecting it from deletion. After using this new program, you’ll be able to restore the SafeBoot registry keys with my .REG files.
But there exists malware that goes even further and actively monitors the registry to thwart every attempt to restore the keys by deleting them as soon as they are restored. Untill now, I recommended to use a Live CD to restore the keys in such a case (this is a complex procedure). This way, the malware is not running while you restore the SafeBoot keys.
Now I developed another solution: a program to create the SafeBoot registry key with permissions to deny Administrators and System accounts to delete the key. This way, the malware can’t delete the keys because it lacks the permissions to do so.
Here are the SafeBoot permissions on a default Windows XP install:
And here are the permissions of the SafeBoot key created with my new program:
I designed my program to create the SafeBoot key only when it is missing, and to set the special permissions while it is created:
My program will not set the special permissions when the key exists. If the SafeBoot keys exists and you can’t boot into Safe Mode, you’re dealing with another issue than a Safe Mode disabling malware (probably a buggy driver).
The program is a console program, but it will pause at the end so you can read its output, even when you launch it from Windows Explorer (i.e. double-click it). If you want to use it in a script and prevent the prompt from appearing, use option -n.
If the SafeBoot key exists, my program will tell this (SYSTEM\CurrentControlSet\Control\SafeBoot exists.) and it will leave the permissions unchanged. If your system is clean but you want to protect the SafeBoot keys, I recommend you change the permissions manually using RegEdit.
My program creates only registry key SYSTEM\CurrentControlSet\Control\SafeBoot, and not the subkeys. To restore the subkeys, you just need to use the appropriate .REG file.
Having read this, you might have thought that malware authors could bypass this protection by changing the permissions before deleting the keys. You’re right. I don’t deny Administrator and System accounts the permission to change the permissions, because I don’t expect there is malware in the wild that changes permissions of the SafeBoot key. I’ll deal with it when it eventually appears.