Last Updated: 2015-02-17 10:37:04 UTC
by Rob VandenBrink (Version: 1)
Both the mainstream media and our security media is abuzz with Kasperksy's disclosure of their research on the "Equation" group and the associated malware. You can find the original blog post here: http://www.kaspersky.com/about/news/virus/2015/equation-group-the-crown-creator-of-cyber-espionage
But if you want some real detail, check out the Q&A document that goes with this post; http://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf
Way more detail, and much more sobering to see that this group of malware goes all the way back to 2001, and includes code to map disconnected networks (using USB key C&C like Stuxnet did), as well as the disk firmware facet that's everyone's headline today.
Some Indicators of Compromise, something we can use to identify if our organizations or clients are affected - are included in the PDF. The DNS IoC's included are especially easy to use, either as checks against logs or as black-hole entries.
Last Updated: 2015-02-17 03:17:33 UTC
by Rob VandenBrink (Version: 1)
A while back I put an article up on exposing a GPU up to a virtual machine for cracking password hashes (https://isc.sans.edu/forums/diary/Building+Your+Own+GPU+Enabled+Private+Cloud/16505). This worked great for me for a while, but then it became evident that 1 or two GPUs just wasn't enough - each GPU adds a linear amount of processing power, so 6 GPUs will solve problems 6 times faster than a single. Problems like cracking wireless keys, windows passwords, passwords on documents or databases, any number of things (150 different hash types in the latest version hashcat).
What I found when I added more GPUs to my ESX host was that there's a limit on VT-d (DirectPath I/O in ESX) - you can only assign up to 8 devices in ESXi 5.x. Since each GPU represents 2 devices, that's only 4 GPUs. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010789)
So I had to go to a physical server to get past 4. What more is there to learn you ask? First of all, the Linux drivers just don't cut it. Getting more than a few GPUs to be recognized from one reboot to the next is a challenge, even if you use the exact OS Versions and drivers recommended. Even getting lspci to see them all was a gamble - each time I powered the server on was a roll of the dice.
Windows drivers work fairly well - however, in Windows 7 there's a hard limit of 4 AMD GPUs (mine are AMD R9 280x's) buried in the driver - don't forget that these are supposed to be graphics adapters, and limiting a system to 4 PCIE x16 graphics card actually makes decent sense. However, we're not using these for graphics! You can fix this limit with some judicious registry edits, but these vary quite a bit depending on the GPU model and OS. The fine folks at lbr.id.lv put together an executable (6xGPU_Mod) that builds the reg changes for your setup - find it here:
But wait, there's more! OCLHashcat requires a specific version of the AMD drivers to work correctly. Again, these are graphics cards, and the newer versions of the driver don't lend themselves to computation apparently (a bug that doesn't affect graphics affects mathematical calculation). Today's recommendation (for oclhashcat) is to use AMD driver version 14.9 (exactly), and no other. This version recommendation does change - refer back to the documentation for whatever tools you are using for driver version recommendations.
Also, don't skimp on power supplies. I have 2500W available (2x1250) for these 6 GPUs and the powered risers that feed them, plus the power supply for the system unit. If the cards don't have enough power, either they'll just run slower, or they won't run - either way it's an easy fix. And if you have issues during the build (everyone does on these), ruling out power problems is a good start in resolving these problems. I budget 300W per card - likely at least a bit overkill, but I'd rather have a bit extra than be a bit short. The old proverb "when in doubt, max it out" is a good one for a reason.
At long last though, I now have 6 GPUs dedicated to cracking whatever encrypted information I need to throw them at!
One final note - yes, I do know that you can spin up an AWS instance with GPUs to perform similar functions. In my practice though, I'm not comfortable cracking customer passwords on someone else's server. Also, in my previous rig, it was not uncommon to see password cracking runs for a typical list of hashes take 5-7 days, with 2 GPUs running flat-out - depending on the list and the hashing algorithm, this can run up to some serious computation time, which costs real dollars in a cloud service. Bumping the count up to 6 GPUs in my own build cuts the time for me down by a factor of 3 for a pretty low cost, and still keeps the password hashes (and cracked passwords) in my own rack of servers.
If you've found other gotcha's in this sort of implementation, or if you've had good luck using a cloud service for stuff like this, please, use our comment form and let us know how you've fared !
Last Updated: 2015-02-17 03:01:06 UTC
by Rob VandenBrink (Version: 1)
In the author's own words, oclHashcat 1.33 is "what 1.32 should have been". I think they're too hard on themselves - - 1.32 was pretty darned good too. There are a number of good changes in 1.33 though - of interest to most of us is support for PDF passwords and PBKDF2 (2 variants of that so far). Look for more PBKDF2 variants in days to come - version 1.33 sees a PBKDF2 kernel added. Also a new feature that will affect the bottom line of many folks who use oclhashcat - wordlist processing is now multithreaded, so expect to see dictionary attacks run quicker.
So if your client took your advice and moved their MD5 hashed password database to PBKDF2, with a few more GPU's you can make a point on that new method as well. Though I'm not sure what you'd recommend to replace PBKDF2 ...
In my rig (6 GPUs), I'm seeing 3 million hashes per second on PBKDF2, and 30,000 hashes per second on PDF 1.7 level 8 (Acrobat 10 or 11). So PBKDF2 is still way more computationally expensive than MD5 (now tracking around 54 Billion hashes per second), but if you use intelligent, targeted password lists - maybe using CEWL for a base list and perhaps some numeric / season mods folded into those words, you can still make a serious dent in a list of poorly chosen passwords (in other words, almost any hashed password list).
Happy password cracking!