Search This Blog

Loading...

Monday, August 1, 2016

LOG-MD Selected For Blackhat Arsenal Based On The 'Windows Logging Cheat Sheet'

https://www.blackhat.com/us-16/arsenal.html#log-md
Come on by Blackhat Arsenal Thursday and check out LOG-MD in action with the latest version on how to check, set, and harvest malwarious activity on Windows systems.


Michael Gough & Brian Boettcher
Palm Foyer, Level 3, Station 8
Thursday Aug 4th - 16:00 - 17:50
Based on the 'Windows Logging Cheat Sheet' LOG-MD audits a Windows system for compliance to the 'Windows Logging Cheat Sheet', CIS, US-GCB and AU-ACSC standards, and if it fails creates a nice report to help you know what to set and then guides you where to set the items needed to pass the audit check.  Once properly configured, LOG-MD then harvests security related log data to help you investigate a suspect system.
In addition LOG-MD can perform full file system hashing to create a baseline that can be used to compare against a suspect system.  LOG-MD can also baseline the registry and compare a suspect system registry to a known good baseline to find altered settings and even look for LARGE Reg keys where malware is hiding payloads.
Come by Blackhat Arsenal and check us out and maybe get a goody too ;-)

Thursday, June 16, 2016

The Windows PowerShell Cheat Sheet is now available!

We are proud to announce the release of the "Windows PowerShell Logging Cheat Sheet".  This latest cheat sheet is focused at what options to set, where to set them and what to monitor to detect PowerShell activity and more so, malicious PowerShell activity.

This cheat sheet covers PowerShell versions 2 through 4 and the new PowerShell version 5, or Windows Management Framework as it is now called.  There are links to other great PowerShell resources, settings to configure, either through Group Policy or manually in the registry.  What to gather and harvest as far as Event ID's and what to look for as far as malicious activity.

The first goal of yours, of course after downloading the cheat sheet will be to get some test systems configured and validate everything is collecting as you expect.  Then push out the settings to all your target systems you want to monitor, which should be all of them.

Also included is the use of Sysmon to catch PowerShell being called by another binary other than powershell.exe or powershell_ise.exe to catch misuse of the PowerShell Dll's.

Take a read, do some testing and of course, send us your thoughts.


#HappyHunting


Tuesday, March 29, 2016

PowerShell RansomeWare via Word Docs starting to rear its ugly head - completely detecable



Carbon Black last week released a report that PowerShell is being used in RansomWare attacks.  Why is this important?  By using PowerShell the RansomWare can be 100% diskless, meaning no malware binary needs to be dropped onto the system and stored on disk.  It can, but does not have to, it just uses PowerShell commands to encrypt your data!

So how do you detect this condition or attack?

First, the malware is delivered in Malicious Word documents, so your email gateway might be able to scan and execute these type of documents.  Most Email gateways do not detonate attachments without a usually expensive add-on feature, but of course, more $$$.

You can enable logging per the "Windows Logging Cheat Sheet" found here:
 And once your logs and auditing is configured, alert on the following with your Log Management solution;

1.  Execution of VSSAdmin.exe
2.  Execution of a PowerShell bypass

VSSAdmin is used to delete the volume shadow copies from your system by the RansomWare to make recovery without backups impossible.  The PowerShell bypass is used to bypass any restrictions you might have to keep PowerShell scripts from running.  Yes, Microsoft incldued a backdoor to execute PowerShell commands... YAY #FAIL

You would look for the following in the 'Process Command Line' being executed;
  • ExecutionPolicy bypass -noprofile
  • and possibly -windowstyle hidden
The first bullet will definitely alert you to PowerShell nefarious behavior, the hidden window may be used by admins to do maintenance items, so secondary on the alert.

Prevention - Whitelisting: 

Whitelisting is about the only protection you have from RansomWare other than GREAT backups!!!
 
You can setup Software Restriction Policies found on all versions of Windows except Windows Home versions for FREE!  Just deny execution of:
  • C:\Users\* 
  • You can do this for other directories too and make exceptions for what you want to execute
You can also use AppLocker to block an unknown executable or script.  AppLocker requires Windows Ultimate or Windows Enterprise.  There is an audit mode for AppLocker so you can test and allow what normally runs before enforcing the policy to block.

Both Software Restriction Policies and AppLocker write blocks or potential blocks to their respective logs.  The Application Log for Software Restriction Policy violations and the AppLocker 'EXE and DLL' Log under Applications and Services - Microsoft Windows log.

There you go, you better start logging PowerShell if you are going to keep up with the malwarians and this Crypto RansomWare!

Carbon Black article on PowerWare 

Happy Hunting

#InfoSec #IncidentResponse #RansomWare

Wednesday, February 17, 2016

Detecting port scans between hosts on the same segment, could you detect this? Windows could help





Thanks to one of my fellow InfoSec brethren and fellow security product developer, he got me thinking as to how to detect a situation he presented me, and well, I finally had an engram kick-in and off I went to see how I would I detect this condition.

We are all too familiar with port scans against our firewalls from a myriad of ne'er-do-wellers and how a firewall or other specialty network device detects and blocks reconnaissance behavior. Simply stated, one IP hitting multiple ports, OK, a lot of ports in a fairly short period of time, is the main indicator.

But what about inside your network, not just Internet facing systems, how would you detect a port scan occurring? Say, recon by a malwarian already inside a compromised box, a misguided employee, rogue admin, Pen Test consultant, etc. As long as there is a firewall or network device between the source (bad guy) and target that is being logged you could detect a port scan. Or if you have an IDS/IPS inline between the two hosts involved, you could detect the port scan IF you have logs being monitored and alerting on this kind of behavior. If you have a managed service IDS/IPS provider then they should be calling you, or at a minimum alerting you to an internal port scan, so this is a way to see if they are doing what you pay them for, or you have short comings in malicious network detection capabilities.  I will also assume that switches are not being logged as this produces more noise versus value in most cases.

But what about same segment port scanning? What if a malwarian is on one host and scans ONLY that subnet and surrounding IP's, could you detect a port scan?  Is your IDS/IPS connected to a span port that can see ALL traffic going between systems within a switch or network segment?  If not, what else could you do?  Would you believe Windows Logs to the rescue if the target is Windows?  You could do the same with IPTables on NIX systems by the way.

The Windows Firewall Logs can detect this behavior, but not a setting I normally recommend because of the noise it normally generates that is not of much value.  And thus why this blog post.  So if you test your port scan detection capabilities, and I suggest you do, this is where my InfoSec Musketeer comes into play.  Thanks Marcus for planting the seed and "Hey.. where is my avatar on the main page???".  VThreat is an all browser based solution that enables you to test your ability to detect various nefarious activities and your ability to detect them, one of which is a port scan.  Many of you might be wondering right about now, does my IDS/IPS cover this condition?  Could you detect a port scan between two hosts, workstations or servers or the same segment, an IP or two apart?  Check out VThreat if you want to test for it!  Or play with what I list below, at a minimum if you can detect a local segment port scan successfully.  You should be able to detect most of them with well tuned tools that VThreat can help you test.
For Windows systems and Group Policy, if you enable "Filtering Platform Connection" under Object Access found in Advanced Audit Policy and you enable "Failure", where normally I recommend only "success", you can detect a local port scan where your network devices may fail you.  The logs will provide you with EventCode 5156 "failed" attempts to create a connection to the Windows host, and in quantities that are never normal.  An example where I generally recommend not to enable this option, but an example of why you might want to.

Remember, you do not have to send this data to Splunk or other log management solution. You can collect it locally and craft some script to query for this data as you see fit. Of course LOG-MD will collect this information if enabled for a tactical solution, IR work or you want to test if your network devices and logging are up to snuff.
Here is a sample Splunk query for you to ponder and expand upon. Just adjust the ports you want to cover (<20000) and the quantity over time (>10) and then search over the past hour and do some testing.

index=win_logs LogName=Security EventCode=5156 | table host Source_Address, Source_Port, Destination_Address, Destination_Port, Protocol, Keywords | search Source_Port < 20000 | stats count dc(Source_Port) AS Port_Count values(Source_Port) AS Port values(Keywords) by Destination_Address | where Port_Count > 10

Happy Hunting!

#InfoSec #MalwareArchaeology

Wednesday, February 3, 2016

Japanese National Cert Blog on Windows commands abused by attackers




Japan's National CERT released a blog on the breakdown of Windows commands abused by attackers. This is GREAT WORK and one of the best articles to reinforce what I have been saying in my presentations, Windows Logging training and of course the 'Windows Logging Cheat Sheet'. Logging command line execution is critical for a mature Detection and Response program.

JP-CERT broke down the commands into 3 categories:
  1. Initial investigation: Collect information of the infected machine
  2. Reconnaissance: Look for information saved in the machine and remote machines within the network
  3. Spread of infection: Infect the machine with other malware or try to access other machines

This is the first time someone has tried to break up the commands into categories to better understand what the hackers are doing and at what stage. I have a slightly different opinion on this, but I do not have the luxury of compiling data like they do to create this kind of breakdown.

Most of the p0wnage I have been involved with is pure 'spread the infection' with some recon or investigation occurring during the spread. Much of what they do is scripted, so identical behavior, other attacks had indications that there was more than one malwarian involved by the mistakes made (the Newb) and the way the other hacker worked and the commands used.

I have never really thought of breaking these commands into these three categories or more, but it might lead to so ideas to craft some logging alerts or tool tweaks From the behavior based solutions and our own work.

I promote The concept of 'Malware Management', the review of malware reports and analysis to gain artifacts used by the malwarians. These artifacts are used to help tune, tweak and improve your SecOps, Active Defense and Blue Team capabilities. I also promote the 'Windows Logging Cheat Sheet' to encourage enabling Command Line Logging to catch malicious behavior. You can get the Cheat Sheets here:
I have been involved in some hairy advanced attacks by a very persistent hacker group and the commands the malwarians executed can be a fantastic way to separate normal admin or developer behavior from malwarian behavior. I recently saw a Tweet and disagreed on the point that 'a good hacker in indistinguishable from a developer'. I just don't agree and the commands attackers execute as the data from JP-CERT show is something that can be distinguished from normal behavior and the quanties of execution is key as the data shows.

While doing malware analysis in my lab I also get to see what commodity malware of all types do from crapware to RansomeWare to the Dridex Trojan. What commands are built into the delivery, execution and call back and the follow on commands executed are also telling and help to improve Detection and Response, if we listen.

If you look up some of my presentations On SlideShare (MalwareArchaeology) you will see what commands were executed, malware payloads used, and built-in Windows commands abused by the malwarians.

I further the need to log command line execution and the importance by providing a sample query I created in Splunk for my 2015 Splunk .Conf presentation which can be found in the 'Windows Splunk Logging Cheat Sheet' also found on my website at the link above.

Now my list of commands to watch out for is more extensive than the ones in the JP-CERT blog for what I recommend people monitoring for. But all the commands I monitor for have been added in part to practicing Malware Management, analyzing malware to see what commands were executed, actual infected and compromised systems and all the reports folks and companies like us put out. Once you see and experience an actual advanced attack and are able to capture and see the malwarians behavior first hand, a light will go off and you will be able to tweak and adjust your tools to improve your Detection and Response capabilities.

Keep in mind that combining the Windows commands with other process executions, minus your normal program executions will allow you to separate the developers and admins from your adversaries. Consider looking at where the commands are executed, such as user space \AppData\ versus All Users \ProgramData to the program and Windows core directories. The data will begin to speak to you, of course ONLY if you have adequately configured logging like the Cheat Sheets recommend.

Happy Hunting!

JPCERT blog on Windows commands used by hackers

#InfoSec #MalwareArchaeology

Thursday, January 21, 2016

Malware Management is even spelled out in ISO 27002



I have mentioned many times how Malware Management is a much needed practice for improving an Information Security program and your Security Operations team. If you want to begin hunting and find malware in your environment, you must first learn what and where to look as far as artifacts and IOC's.

It is not just me suggesting you do this, it can also be found in the industry's leading information security framework standard ISO 27002. Below is an excerpt of the standard discussing the need for Malware Management.

A.12.2.1 Controls against malware

j) implementing procedures to regularly collect information, such as subscribing to mailing lists or verifying websites giving information about new malware.

In my Malware Discovery training I teach people to go out and read virus/malware write ups, malware analysts reports and IR firms reports to collect the artifacts and IOC's that you can then populate into your security solutions, scripts or detection and response and incident response practices.

So you should consider adding this to your 2016 list of security goals and objectives to spend the one hour a week to research and read the materials available to start a practice of Malware Management.

You can find a list of Malware Reports from some of the more recognized malware campaigns on our websites:

www.MalwareArchaeology.com/analysis

or
www.IMFSecurity.com/malware-reports

And read what and how to do Malware Management here:

The Malware Management Framework

By all means, send us links to other good reports so we can share. Generally You can find these reports discussed or released in Articles from RSS Feeds from many of the vendors who work in the IR space, InfoSec Blogs and many podcasts like "Brakeing Down Security" where I have been a guest discussing the subject.

So don't take our word for it, take the advice straight from ISO 27002 and use this to help justify starting a Malware Management program in your organization.

Happy Hunting

#InfoSec #MalwareArchaeology #MalwareManagement

Wednesday, January 6, 2016

For the love of humanity retailers, read the PoS malware reports and stop the BREACHES! Malware Management can save you, seriously!

I have blogged many times before about how Malware Management helps information security professionals and organizations improve their detection, Active Defense and Incident Response capabilities. The Hyatt breach and MODPoS proves yet again Malware Management would have saved Hyatt and many other retailers after Jan 2014.  Retailers must evolve or continue to be compromised.  For that matter, all of us must evolve our detection capabilities or suffer a breach at some point.  The ultimate goal of security operations is to detect an intrusion BEFORE the mass loss of data resulting in a breach and your firms name in the news and possibly new employment opportunities for you.

In October 2015 iSight Partners released another good analysis report on the MODPoS malware.  Much like their first report from Jan 2014 on BlackPoS, one of the main conclusions is the same, the malware installed a new service!  

For the love humanity information security professionals, monitor your systems for the creation of new services!  This is Malicious Detection 101 people.  The one item that by default is enabled and available on Windows systems are the events for services starting, stopping, changing and installing.  Yes, there were many more artifacts in these two malware reports, but one thing is common in both and many other malware reports, a new service was installed and is the core persistence mechanism used in retail Point of Sale (PoS) infections.  Many advanced malware attacks also use a new or existing service to maintain persistence, it's very common technique.


Detect Event ID 7045 or a change of a service state Event ID 7040 and you can detect and stop PoS malware and many other advanced malware dead in their mag stripes.


Malware Management to the rescue!


Take it from someone who has lived there, too many times and caught the malwarians within an hour or so of the initial compromise.  You CAN detect most advanced attacks and many commodity malware infections, but you must practice Malware Management.  Read the malware analyst reports these experienced and seasoned professionals create, for the very reason of educating all of us to improve from real world events and experiences.


Read more on Malware Management here:



Read more on Windows Logging and use several cheat sheets we created to help you begin and refine your Windows logging ability available here:



And of course, use LOG-MD to audit your system, help setup proper logging to gather the needed log data.  Even if you have a Log Management solution, use LOG-MD to refine your logging improving what you collect and help you reduce the noise, the quantity of events and help you reduce your license and storage requirements.  You can get LOG-MD here:



So come on retailers, it is time to get with the times and read the malware reports on your own breaches to learn and improve and better defend yourselves.  Everyone else too.

More Malware Analyst reports are available on our website:

Happy Hunting!

Thursday, December 24, 2015

December Dridex variant and the best way to clean it without using Safe Mode and detect it using file and registry auditing




If you ever wondered if file and registry auditing has value and worth doing, look no further than the latest Dridex malware variants as a perfect example of why you should start doing it.

The latest variants of Dridex are delivered using specialty crafted Word or Excel documents. The malicious documents contained macros and VB Scripts that when opened and content enabled, or un-patched 0-Day (MS15-070), drops and executes the Dridex malware.

There have been many variants of this malware largely delivered with malicious Microsoft Office docs. The malwarians use an interesting approach in that they drop VB Script in a .vbs file that is assembled with variables from a batch file (.CMD) that then calls an executable (.EXE) and sometimes using a PowerShell script backdoor (.PS1). Note that the recent variants changed from using powershell, but all variants seem to share the .CMD, .VBS and .EXE files to launch the initial malware infection.

In one of the latest variants of Dridex, the malwarians have utilized some morphing and anti-virus avoidance by generating a new file name with a different hash and varying file sizes each time the system reboots! More importantly the malware on system startup deletes the only payload file which is a DLL that is obfuscated with possibly version 4 of the Armadillo packer and uses the .TMP file extension. To avoid detection, Dridex malware launches on system startup, injects its malicious code into Explorer.exe, deletes itself from disk and deletes the Run key entry it used to launch itself all before the user logs in! On shutdown Dridex writes itself back to disk, albeit with a differnet name and hash, and updates the Run key to allow restart on the launch of Explorer at the next boot.

When the system is up and running and a user logged on, there are no files on disk or no autorun values in registry to detect the Dridex malware. The only Key or keys that exist are a subkey in HKCU Explorer\CLSID that stores what looks to be configuration data written just before the Run Key is deleted on startup.

So how does someone detect malware of this type? Well your properly configured logs of course! If you follow the 'Windows Logging Cheat Sheet' you would catch the malware launching with several 4688 'New Process Created' events. But how do you detect a condition where malware deletes itself on startup and writes back to disk on shutdown and more importantly how do you clean or remediate it? Furthermore how do you remediate it at scale, say over 100 systems?

Your best friend will be file and registry auditing to catch 4663 'File' and 4657 'Registry' events. Where and What locations do you need to audit? For files, the users AppData directories and for the registry the autorun locations. This way when new file(s) drop or get deleted, file auditing will catch this behavior and allow you to match the process execution 4688 events with the file auditing 4663 event along with any autorun registry changes with 4657 events. If you enable Windows Firewall logging (Packet Filtering) you will get the 5156 events listing the process and IP's that match the 4688 events as Dridex communicates with the Command and Control servers.

Applying file auditing on the \Users\AppData directories will catch the Dridex file activity. In the latest variant, or the variants we analyzed, Dridex uses the AppData\Roaming (%AppData%) directory for the .TMP file that is loaded on startup. The dropper/infector that comes out of the malicious Word or Excel document Dridex uses the AppData\Local\Temp (%temp%) directory where the scripts (.cmd, .vbs and .ps1) and initial infector executable are dropped and deleted upon the initial infection.

This particular variant uses a random 4 letter file name with the .tmp as the extension; but is actually a DLL that also includes padding that changes the file size and hash and a packer (possibly Armadillo v4) to obfuscate the malware from detection by anti-virus and avoid obvious string discovery during analysis.

File and registry auditing detects the new file being created and the HKCU Run key being updated on shutdown and deleted on startup. New process execution on startup will catch RunDll32 calling the random named (e.g. A32B.tmp) .TMP file found in the %AppData% Roaming root directory, which normally never contains executable files, or .tmp files for that matter; a key indicator of nefarious activity.

ARTIFACTS/IOC's:

Directories used:


  • %temp% - used for initial dropped scripts and infector malware
  • %LocalAppData% - Used by previous versions of Dridex for dropped files
  • %AppData% - Where the main payload <4 char random>.TMP file is written on shutdown
 Registry Keys used:


  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\<GUID>\ShellFolder Type of REG_BINARY Data (varying length HEX data)

The ShellFolder key is the only artifact that can be discovered while the system is running. Look for a key named "ShellFolder" that is of Type REG_BINARY and has one or more 16 character random Value names and data fields of approximately 80-120 byte length. A new value is created each time the system reboots which can tell you when the system was first infected.

CLEANUP/REMEDIATION

Below are two articles that discuss how to clean Dridex off a system. Those methods discussed would work fine if you are doing one system at a time, but those do not scale for tens or hundreds of systems in multiple office locations.


When malware researchers do analysis, they must take into account that a large outbreak, like we saw with Conficker in 2008 or a typical advanced APT attack could occur where it is typical for tens, hundreds or worse yet, thousands of systems to clean. Safe Boot is unfortunately a manual way to clean a system that requires touching the keyboard. Malware researchers and analysts must also recommend ways, methods or tools that can be completed over the wire or remote. It should be a goal of every malware researcher and analyst to provide an enterprise method of recovery along with our research/analysis. So here is such an approach for Dridex; but knock yourself out if you choose this method for a small amount of systems.



Workstations versus servers:

Servers often have a way to kill the power of the system by using a management interface from the chassis or virtual management console. This can come in handy for the types of infections that live only in memory with no way to restart until the system shuts down and writes the launch sequence to disk. This method provides servers an option not readily available to workstations. Pulling the power on a server will interrupt the hook of the malware and kill its ability to write to disk since the system does not perform a proper shutdown, rather the power is just cut off. Of course you should shutdown databases and applications before using this method to avoid data corruption. For workstations you can just pull the plug and Dridex is gone, but this is not the best approach for scale if there is another way, and with Dridex and many other malware, there is.

Dridex hooks Explorer.exe which loads itself with the following Run key entry:







  • Rundll32.exe C:\Users\\AppData\Roaming\3309.tmp asd34dfghjklzx

The random length code or key following the .tmp file is required for the malware to persist, most likely the key to unlock the obfuscated packed code.

Once Explorer.exe calls RunDll32.exe and loads the
.tmp file which then calls Taskhost.exe that manages DLLs loaded by a service for example, Explorer.exe is then hooked with Dridex. Rundll32.exe and then Taskhost.exe terminate as the Dridex load completes.

Knowing Explorer.exe is hooked, which can be verified by doing a memory dump and analyzing the strings, Dridex can be unhooked.

All that is needed is to terminate the Explorer process which is what users see as their desktop environment. Once Explorer is terminated Dridex is killed and the desktop is no longer useable. No fear, all that is needed is the three finger salute... CTRL-ALT-DELETE and logoff or reboot the system. The three-finger-salute also requires a person physically touch the keyboard, but easier than booting into Safe Mode.

For true scalability and remote management and no keyboard required on the target, terminating Explorer.exe can be scripted or remotely executed using the /S option of the following built-in utilities to specify a remote system with proper admin credentials. Use Tasklist.exe to identify the PID Explorer is running on or just use Taskkill.exe /IM Explorer.exe to terminate Explorer and then execute the Shutdown.exe command to reboot the system. Many remote management solutions have a reboot the system option, so all that is needed is to execute the proper Taskkill command line and then reboot. You can also script the deletion of the config settings found in the ShellFolder key listed above, but the key is benign once Dridex is terminated.


There you go, all you need to know on the current stealthy variant of Dridex. Now go do some malware infections and play... In an isolated lab of course.
Happy Hunting!

RESOURCES

Virus Research article on Dridex removal using Safe Mode

Lexsi Security article on cleaning Dridex in Safe Mode and an incomplete tool

MalwareBattle article on Christmas Dridex

Blue live article on Dyre and Dridex malware

Stop Malvertising article on Dridex / Cridex / Feodo / Bugat

#InfoSec #MalwareArchaeology #LOG-MD, #Dridex


Saturday, October 31, 2015

A Simple built-in FREE way to block malware and odd programs from infecting your Windows system - Software Restriction Policies




When I put on Malware Discovery and Basic Malware Analysis training I am always asked "Isn't there a simple way to stop things like Crypto Ransomeware that keeps infecting my users, friends, family, kids and wife"?

Actually there is and it is FREE with Windows!  Thank you Microsoft for not including this feature with ALL versions of Windows.  ;-(

It is available only if you have Windows Professional, Ultimate, Enterprise or MSDN versions, sorry, Windows Home and Starter versions do not have the Local Security Policies console needed to configure it.  But this IS a reason to upgrade your computers to Pro or Ultimate for sure.

So how do you use it to block malicious software like Crypto Ransomeware?

First things first.  You need to understand this is a manual configuration on each computer, you can automate it using Group Policy for domain attached systems. 

Second, you need to understand that this method will block everything from running in the Users directory space and that you must poke holes to allow what is needed and what you want to run.  But there is an easy way to gather this information once a block occurs.

So what is it?  "Software Restriction Policies" (SWRP) is found in the Local Security Policy Console which is found under:


  • Control Panel - Administrative Tools - Local Security Policies


Enforcement:

This is where the roles of the users are defined that you will grant access.  These are not adjustable, just select the one you want when you create a rule.

Designated File Types:

This is where you can add or delete file types, but some file types are not supported like driver .SYS files.


Trusted Publishers:

This is where you can trust certain publishers like Microsoft, Google and other companies who sign their software with a certificate.  You must manually go find the file you want to trust and select the part(s) or levels of the publisher info you want to trust.  This is manual and not very friendly as the same company can/will sign their software many different ways.


Additional Rules:

This is where you should spend most of your time, especially if you want SWRP to be easy and fast.

There are four rules:


  • New Certificate Rule
  • New Hash Rule
  • New Network Zone Rule
  • New Path Rule

Spend most of your time with the "New Path Rule".  This is where you will create a BLOCK ALL rule and then poke holes to allow ONLY what you want to allow to execute.


The first rule you want to make is to BLOCK ALL for the path:
  • C:\Users\*
This will block execution of any executable in the C:\Users directory structure.  Once an existing program tries to update itself, like Google Chrome, you will get an error on the screen if it is a GUI based install or update.  If it is a background process then you won't see anything.

But wait, there is a Log entry registered each time a failure occurs and this makes it easy to populate your New Path Rules!

Open up Event Viewer and the "Application" Log and filter the log for Event ID 866.


These log entries will give you what you need to create a "New Path Rule", all you do is copy the path of the failure.


Then you will create a "New Path Rule" by right clicking on the "Additional Rules" item or in the window and select "New Path Rule" and paste the copied path from Event ID 866 and that is it.  Of course select "Unrestricted" so the program can run and save the entry.  Repeat this for each program you want to allow to run.

Take a minute and look at the path and make it generic to users (C:\Users\*\AppData\Local\Adobe) and versions of the software.  Some software uses a directory name that matches the version (GTM\1251\update\install.exe) so as it updates the one level of the directory (1251) will change with each new version.  You don't want to keep adding similar rules, just use a wildcard "*" in place of any username or version (GTM\*\update\install.exe) to make it work for everyone and every version.  

Of course you can use the wildcard to further refine the rule to your liking.  But be careful!  You don't want to make a wildcard entry that will allow bad software to run due to an odd .tmp file path name that opens up the whole directory to allow any file to execute.  Some installers use random named files with a .tmp extension that you will have to craft a rule for.  Make the rule as specific as needed to protect odd things from being able to run in that location.  Here is an example of several "New Path Rules".


If you play with this on your system, you will find this will work fairly well in blocking odd programs from infecting your system.  Of course TEST your rules by dropping a known .EXE, maybe renamed to "malware_test.exe" for effect into a directory under C:\Users and try to execute it.  You should see a message like the following letting you know the rules are working.



Check your Application Log for Event ID 866 to see the blocked file.




Now you have a way to block some typical commodity malware for your users, family, friends, children and anyone else that asks you for help.  Below are some more articles to help give you ideas.

Happy Hunting.


TechNet article on using Software Restriction Policies

TechNet article on Software Restriction Policies

TechNet article on using Software Restriction Policies

Another article on Software Restriction Policies

#InfoSec #MalwareSucks

Friday, September 25, 2015

ANNOUNCING Log-MD, the latest tool to help you fight infection, malware infection




@HackerHurricane and @Boettcherpwned are releasing the Log Malicious Detection tool "Log-MD" for Windows based systems at DerbyCon 2015!

This FREE tool will assist you in Enabling and Configuring your Windows logs based on the recommendations of the "Windows Logging Cheat Sheet" (WLCS).

When first run, Log-MD will fail until, or unless all the needed auditing items are enabled and configured. You can either pipe out the console or read the "Audit Settings Report" giving you a measure of how your system compares to the Center for Internet Security (CIS) Benchmarks, or the recommended configuration of the "Windows Logging Cheat Sheet". This is a great report to add to your security assessments!

Once the system is properly configured, either through Group Policy or the Local Security Policy and some other system tweaks, Log-MD will produce Report.csv collecting all the security goodness we Active Defenders, Malware Hunters and InfoSec people want and need! The report is a simple to consume and parse CSV format for additional scripting or filtering using Microsoft Excel.



It does not stop there! There are three white lists that allow you to filter out the good, to help you find the bad and the ugly! So as you find obviously good conditions, you can use the white lists to filter out the items the next time Log-MD is run. The three white lists are:

1. By Process Command Line and/or Process Name
2. By Source IP and/or Destination IP and/or Destination Port, yup, no source port.
3. File Auditing (4663) and Registry Auditing (4657) locations

There are multiple use cases for Log-MD, whether or not you have a Log Management solution, aka SIEM, this tool can help you refine what to collect and improve your policies.

1. Audit your system against best practices - Compliance Auditors, IT professionals, consultants, InfoSec and Incident Responders can all use this tool to know how their environment stacks up log and audit wise against the CIS Benchmarks or WLCS recommendations.

2. Use the output to set and refine your File and a Registry Auditing to start monitoring key directories (e.g. \appdata) and auto run locations in the registry (e.g. Run and RunOnce keys). Start using auditing and have a way to refine your settings!

3. Malware Labs - Use Log-MD in your malware labs to find the key artifacts or IOC's needed to find other infected systems and the cleanup details to remediate. Speeds up basic malware analysis significantly!

4. Investigate a suspect system - Do you want to know if a system is clean or infected? Log-MD can help you analyze the data after boot up to see if anything odd has launched or communicated on the system.

5. Incidence Response - We don't always have fancy Log Management solutions or Endpoint solutions, so Log-MD can be run on systems to help get them configured to collect the needed data and then provide Incident Responders much needed information to focus their attention. Great for companies that are budget limited and lack some of Enterprise Security tools IR firms use.

A major goal of Log-MD is to help move organizations forward and enable and configure much needed logging details, even if it is only collected locally with or without a Log Management solution. Or to use this technique when doing malware analysis and while investigating a suspect system.

Take a look and download the tool and try it out! Send us your comments and suggestions. For security, we have posted the file hash on HackerHurricane to validate the download ;-).

You can get Log-MD at:

www.Log-MD.com

Happy Hunting!!!

#InfoSec #MalwareArchaeology

Thursday, September 24, 2015

Finding and Alerting on crypto events with your Cloud storage logs




This may be an actual compelling reason to use a business class Cloud Storage solution like those from DropBox, Box and others.

Normally to detect crypto events you have to enable the File Auditing policy in GPO or Local Security Policy and on set File Auditing for the Server Shares you want to monitor so the data is captured in your Security Event Log (Event ID 4663). This is an effective way to detect a Crypto event in process and also know what directories will need to be restored once the user is contained or disconnected.

Recently a user was hit with one of the many Crypto ransomware variants and needed to be cleaned up. Since a business class Cloud Storage was being used, the question was raised; can they roll back to last known good files since this occurred 2 weeks earlier? That got me thinking...

If you are one of the companies using Cloud Storage as an alternative to local file server storage, ease of sharing between partners, or using it for the encrypted storage, you may be in luck if you have a log management solution. You may be able to use their web portal to search for this condition, let me know I have not tried it.

If you upload or sync the cloud storage logs to your log management solution, say Splunk, Loggly or one of the many others, you could have what you need to answer the following questions:

1. When did the event happen
2. Who was the user(s) involved
3. What directories were involved (probably all)

The logs will have all this data and if you write a query to search for "HELP_DECRYPT" and say "stats count by username", you will have what you need to alert on a crypto event using your cloud storage logs!

Since users should not have any "HELP_DECRYPT" files, usually 2 per directory, the HTML file and Image file, monitoring for these is a great artifact to look for.

Just look for these files and say "where count > 5" as a trigger and send an email to the appropriate people.

Just another artifact that we can use to detect malwarious activities.

Also check out my new "Windows Splunk Logging Cheat Sheet" for some Windows Splunk logging goodness.

Happy Hunting!

#InfoSec #MalwareArchaeology

Sunday, September 20, 2015

POS Malware variant MWZLesson substantiates Malware Management should be practiced by retailers




Security experts at Doctor Web have discovered a new PoS Trojan dubbed MWZLesson that borrows code from other popular malicious software.


The DrWeb article states that "The new PoS Trojan, dubbed Trojan.MWZLesson, was designed reusing the code of other popular malware, including the Dexter PoS and the Neutrino backdoor.".

This Blog covers interesting malware and logging tips, but even the malware analysts are seeing what I have been saying for several years. Malware repeats patterns, artifacts, methods and clearly, code reuse.

If the retailers, IT and InfoSec staff would start practicing Malware Management, or any organization for that matter, they could be in a good position to detect any variants of similar malware or code reuse as the lesson to be learned from the latest MWZLesson POS malware shows us.

This concept is taught in my Malware Discovery and Basic a Malware Analysis training as it was pivotal in detecting APT I have dealt with in the past.

Seriously consider practicing Malware Management before the malwarians show you why you should have been doing it.

DrWeb article on MWZLesson POS malware

Various Malware Reports and Analysis

How to begin using the Malware Management Framework

#InfoSec #MalwareArchaeology

Sunday, September 6, 2015

New Banking malware 'Shifu' proves Malware Management works!




IBM's Security X-Force team has released an initial report on a new malware named 'Shifu' that uses methods in several other known malware currently compromising banks in Japan.

The lesson to learn here is that it uses similar traits or functions of other know malware. The report lists the following traits from known malware:

Shiz - Domain Generation Algorithm (DGA)
Corcows - Theft from Bank Apps
Gozi - Stealth hiding techniques
Zeus - Anti-Sec avoidance
Dridex - Config using XML
Conficker - Wipe system restore
Dyre - Self signed certs

This blog has stated that Malware Management should be practiced just like we practice Vulnerability Management. The benefits are that malware uses patterns over time that allows you to look in places or for artifacts and indicators that other malware have already used, thus making Malware Discovery easier each time you do it, improving results.

I look forward to the detailed report by the IBM Security X-Force team and HOPE they publish the artifact details we Active Defenders and Incident Responders need to discover this malware or similar types of malware in our own environments.

IBM Trusteer intro on Shifu malware

#InfoSec #MalwareArchaeology

Wednesday, September 2, 2015

Symantec just proved Malware Management works with Regin update




I have blogged about Malware Management and Regin before and how it can improve your Information Security program, Malware Discovery, Active Defense efforts and improve your Malware Analysis. Take reports published by AV companies, IR Firms, Bloggers like 'Malware Must Die' and here of course, read them, pull out the artifacts, or IOC's if you must and apply them to all the above.

Symantec is aware of two distinct versions of Regin. Version 1.0 appears to have been used from at least 2008 to 2011. Version 2.0 has been used from 2013 onwards, though it may have possibly been used earlier


In the Fall of 2013 Symantec and others published details behind the Regin malware, see links below. Thanks to Symantec publishing an update in August 2015, "Regin: Top-tier espionage tool enables stealthy surveillance", they just proved if you had read the first Regin malware reports, you would have been well on your way to detecting any updates or similar behaviors if you were unfortunate enough to contract the malware disease known as Regin or similarly crafted malware.

You would already be watching for things like:
* New files being added to \Windows, \Windows\Fonts, \Windows\Cursors and \Windows\IME
* New files being added to \System32, \System32\Config and \System32\Drivers
* Auditing certain Registry Keys
* Auditing for files that have NTFS Extended Attributes
* Filename extensions
* Large Registry blobs (Size does matter)
* Software\Classes Keys for new entries
* See the report Appendix for more details

Several of the locations and techniques found in Regin I have seen in other APT and even some in commodity malware. So if you start reading these reports and taking the data and acting on it, you are in essence practicing Malware Management and improving your Malware Discovery, Active Defense and Information Security program. Not to mention if you analyze malware, you have a better idea of what to look for and where.

Early reports and Symantec's update to Regin:

Symantec Report on Regin

The Intercept article on Regin

Kaspersky report on Regin

F-Secure report on Regin

Happy Hunting everyone, Malware Management ROCKS!

#InfoSec #MalwareArchaeology

Monday, August 17, 2015

Size DOES matter when it comes to Registry Keys




I just LOVE when a Twitter conversation turns into a new tool! It is a perfect example of collaboration and how the community can ban together to solve a need.

That happened last week when Austin's own @dnlongen read a blog post from @codereversing about hiding malware in Windows registry keys and mentioned that he first heard it from me ;-)

In the following tweets I pointed out how the majority of registry keys are below 20k and easy to filter out the normal noise to find a hidden payload. I was involved in an event that had a 250k payload hidden in the HKLM\Software\Classes key and the size of the key was a dead give away. It led us to finding a couple other hidden payloads in other parts of the registry on various systems allowing us to harvest and detect additional infections.


Nirsoft makes a GUI tool called RegScanner that allows you to scan the registry for keys based on size. Unfortunately it is a GUI tool and that can not be easily scripted. What we need is a command line based tool that can be scripted to look for large registry keys and whitelisted normal keys.

In the following tweets @dnlongen announced a python script named "RegLister" which can be found here:

RegLister - Registry key scanner by size

@dnlongen added a whitelist and size tweaks after I inquired, and now there is a new tool to help you Hunt the Malwarez.

GREAT JOB @dnlongen!!!

#InfoSec #MalwareArchaeology