Last Updated: 2016-03-09 20:56:32 UTC
by Mark Baggett (Version: 1)
ISC Reader Eric Volking submitted a very nice sample of some Powershell based malware. Let's take a look! The malware starts in the traditional way, by launching itself with an autorun registry key. The key contains the following command:
Upon startup this will launch Powershell and execute the Base64 (UTF-16LE) encoded script stored in the registry path HKCU:\Software\Classes\UBZZXDJZAOGD' in the key 'XLQWFZRMYEZV'. That script, when decoded contains something that looks like the block of code below. For readability, I've removed a large blob of text from the script and collapsed the two functions that the malware uses to decrypt and extract itself.
This script decodes a big blob of Base64 encoded data that is stored in the variable $eOIzeGbcRBwsK. It decrypts it with the key stored in variable $DUUZTJAPEMZ and "inflates" the gzip encoded data. Windows Powershell ISE makes getting to the decrypted data painless. On my malware analysis VM, I go to the Powershell_ISE Right click on line 43 and select "Toggle Break Point". Line 43 assigns the decrypted payload to variable $eOIzeGbcRBwsK. I execute the script and the ISE breakpoint dutifully stops on the selected line. My Poweshell prompt changes to "[DBG]: PS C:\Users\mark>>" letting me know I am in the middle of debugging the script. I can use my Powershell prompt to inspect or change variables. I can also export the contents of that variable to another file. I go to the bottom of the ISE and type '$eOIzeGbcRBwsK | out-file -FilePath ".\decoded.ps1"'.
Now I can open up the file "decoded.ps1" and see the unencrypted payload. In decoded.ps1 we find a modified version of "Invoke-ReflectedPEInjection". The malware authors have obviously used part of the Powersploit framework in their attack. Powersploit is a very useful framework to penetration testers and network defenders alike so it doesn't surprise me that bad actors find value in it also. Invoke-ReflectedPEInjection will load a Windows EXE into memory and launch it without it ever writing to the hard drive. So where does the script get its EXE? Check out the next section of code:
The script is checking the size of an Integer to determine if the victim is a 32 bit or a 64 bit system. Depending upon the architecture it extracts a 32 bit or 64 bit version of the malware from the registry and launches it using Invoke-ReflectedPEInjection.
By using Powershell the attackers have been able to put malware that might other wise be detected on a hard drive into the Windows Registry. (Dear Trolls, Yes, I know the registry is technically on the hard drive.) As network defenders we should familiarize ourselves with these techniques and how to use Powershell_ISE to examine the scripts.
Thanks for the submission Eric!
Check out SEC573 at one of our upcoming events! https://www.sans.org/course/python-for-pen-testers Already know Python?? Prove it! http://www.giac.org/certification/python-coder-gpyc
Follow me on twitter https://twitter.com/markbaggett
Last Updated: 2016-03-09 13:09:50 UTC
by Rob VandenBrink (Version: 1)
A lot of attention has been paid lately to the Cryptowall / Ransomware "family" (as in crime family) of malware. What I get asked a lot by clients is "how can I prepare / prevent an infection?"
"Prepare' is a good word in this case, it encompasses both prevention and setting up processes for dealing with the infection that will inevitably happen in spite of those preventative processes. Plus it's the first step in the Preparation / Identification / Containment / Eradication / Restore Service / Lessons Learned Incident Handling process (see SANS SEC 504, or ask anyone with "GCIH" after their name)
My best advice is - look at how the infection happens, and make this as difficult as possible for the attacker, the same as you would try to prevent any malware. Most malware these days outsources the delivery mechanism - so Cryptowall is typically delivered by an exploit "kit". These days, that typically means the Angler, Rig, or maybe Nuclear exploit kits (Angler being the most prevalent at the moment). These kits aren't magic, they generally try to exploit old versions of Java, Flash, Silverlight or take advantage of missing Windows updates. When patches come out, the authors of these kits reverse the patches and bolt the exploits into their kit. We've analyzed several versions of these kits over the last few years, most recently Manuel's post last week
So to help prevent these kits from working, we need to give them fewer toeholds in your environment - start by uninstalling these add-ons across the board:
- Silverlight (https://isc.sans.edu/forums/diary/Pay+attention+to+Cryptowall/18243/)
If you can't uninstall them, be sure that you are patched up, and that as new patches and updates come out you have an AUTOMATED way of keeping them up to date. But seriously, if you can, uninstall them. Maybe you needed Java and Flash 5 years ago, my bet is that you don't need them now. Any you likely never needed Silverlight.
Keep your windows desktops and servers patched up. Patch on Patch Tuesday already!! Patch Tuesday was yesterday - have you patched yet? Have your rebooted your patched servers yet so the patches are actually live? Is there a really good reason why not?
Know what's on your network, and be sure it's all patched as patches and updates are released. If you've got old gear that isn't being updated anymore, it's time to retire and replace those stations.
Know what software is running on each of your workstations, and be sure that's all patched or updated as updates come out.
Hardware, OS and Software inventory is one of the basics - you need to automate this as much as possible, because not everything on the network always comes in through IT. Think TV's, projectors, exersize equipment, thermostats and HVAC systems, door controls, fridges and teapots (yes teapots) - the list only starts there. Everybody seems to be entitled to bolt things onto your network.
Those "appliances" on your network aren't immune to malware, they're likely more susceptible because they don't get patched. That 20 Ton press on your shop floor? That IV pump? They're both likely running a 10 year old OS (either XP or a Linux variant). Even if you bought them last week they might be running an OS that old, even in the best case it'll be months or years behind in patches.
Uninstall any software that you don't need. You can't infect what isn't there.
Be sure that folks aren't running as administrator on their workstations, and don't have access to that set of rights.
Is that it you ask? Nope - cryptowall almost always comes in via email as SPAM. If you don't have a decent anti-spam solution, it's time to get one! If your firewall has the capability of running attachments in a sandbox (for instance, Palo Alto and Cisco both have this), it's time to crank this feature up.
Block attachments that will execute (exe's, msi's, scr's, jar's, cmd, bat, etc)
Block zip files with passwords
What else should you have in place?
Using Group Policy, force your users to store their data on a network share rather than their local disk (redirect "my documents" etc).
Be sure that you have control of the ACLs on your server shares. The days of "we trust our users" are long gone - you can't trust your users' malware, so if you don't have a "you have access to what you need and only that" policy, it's time. Those "permit all" directories were all created in teh 1990's, and it's time to rethink them - "Read Only" is your friend! There is very little data in your organization that everyone needs read/write access to, but that's what we so often see, and that's what things like Cryptowall takes advantage of.
Also using Group Policy, disable Macro's in Microsoft Office, and disable VBS while you're at it. You can do this station by station, but the true win for a medium to large organization is using Group Policy to enforce a consistent set of rules across the board. The Australian Cyber Security Center has a nice document that outlines possible settings, depending on how your organization's requirements. Me, I'd say disable all of it. As awesome as document automation is, running someone else's automation to destroy your data is the exact opposite of awesome! If you use automation within your organization, trust your own macros and disable the rest (yes, you can do that and yes, it's easy - stay tuned, I'll write this up in the next week or so).
Get some semblance of a Security Awareness program going in your workplace. Folks should know NOT to click links or open attachments in email. This won't protect them from malvertising, but it's a great start. It also won't protect you after that "second click". Once a user has clicked "OK" to run malware, each successive click comes easier and with less thought. After the second click it's a foregone conclusion, they're determined to get to the end - if the malware is any good that person (and their workstation) is compromised.
Hopefully, with the list above, you've got a number of layers in your defence-in-depth (yes, I had to say it) strategy. But in the end, the link between the keyboard and the chair really is your last line of defense.
Have an incident response plan. Be sure that nobody is talking about "cleaning" workstations or servers. The absolute best recovery from any malware infection is "nuke from orbit" - wipe the drive and re-image from scratch.
BE SURE YOUR BACKUPS ARE UP TO DATE. Be sure that you can recover yesterdays files, last week's files and last month's files. Cryptowall attacks are often delayed, so that they get better coverage to help avoid detection. Know that in the end, you will be compromised, and you will need to do the Incident Response and data recovery thing.
Does this list sound familiar? I'm hoping so - essentially it's the first 14 of the 20 CIS Critical Controls https://www.sans.org/critical-security-controls and https://www.cisecurity.org/critical-controls/.
Is this list complete? I'm guessing not - what important thing am I missing? Please, use our comment form and let us know what you've been doing to stem the tide of malware we're seeing lately.