Search This Blog

Tuesday, August 6, 2019

The Windows Registry Auditing Cheat Sheet update! Aug 2019, v2.5

The Windows Registry Auditing Cheat Sheet has been updated to include a few new items to monitor for malicious activity. Keep in mind when applying to the users space, that the current user (HKCU) is the one logged in. Any other users you want to set Registry auditing on you must do so under HKU/GUID, so you must know their user GUID or use a script that crawls all the GUID and applies the settings.

Thursday, July 12, 2018

Come learn how to hunt on Windows quickly - SANS Threat Hunting & IR Summit

I am giving a talk at the SANS Threat Hunting & IR Summit in New Orleans Sept 6th & 7th.  You Can get more information here:

"This is the fastest way I found to hunt for malicious activity on Windows endpoints" will help people understand how to hunt and what to hunt for on Windows endpoints.

Saturday, April 21, 2018

Sample WinLogBeat.yml file for ELK and Humio users

We have published a sample WinLogBeat.yml file for ELK and Humio users to collect the right stuff and provide an example of how to exclude various events to collect less noise and make your log management experience easier.

This config can be expanded to collect more log events, or exclude more noisy normal events.  Refer to the other Cheat Sheets for more information on items to collect.  The Windows Logging Cheat Sheets may be found here:

You may find a copy of the sample WinLogBeat.yml file here:

Try out Humio, a new Cloud and On-Prem logging solution.  Humio is easy to use and they even offer a FREE version with 2GB of data with a 7 day retention.  Perfect for the home user and lab to begin and expand on your Windows logging expertise.  You can find Humio here:
Watch for a "Windows Humio Logging Cheat Sheet" coming in the near future!!!

Don't forget to send us your tips, suggestion and comments!!!

#Happy Hunting !!!

Saturday, March 10, 2018

New Incident Response Podcast

I have joined Brian Boettcher and started the "Brakeing Down Incident Response" podcast expanding the "Brakeing Down Security" podcast family.

We will focus on practical application on incident response in what we do in our daily IR tasks in order for others to learn and apply more Fu to their jobs.

So take a listen, send us comments and be sure to read the detailed show notes.
#Happy Hunting

Monday, October 23, 2017

Looking at APT28 latest Talos Security write up and how YOU could catch this type of behavior

The Cisco Talos Team just published a report on the latest APT28 malware that came in as a deceptive "Cyber Conflict U.S. Conference" flyer.  You can read the article here:

I just wanted to capture some thoughts that come to mind when I read these types of reports and ask myself "How can we detect this type of attack?" There are some key take-ways from this report that would allow you to detect this type of attack fairly easily, or prevent it altogether since it used Word macros.

  1.  Prevention - The email delivered a Microsoft Word document that used macros to infect the user.  Prevent these types of attacks by 'Blocking Word Macros' using Group Policy!
  2.  Detection - Using Event ID 4688 with Command Line logging enabled you could trigger on Word calling cscript, wscript, and PowerShell as this is NOT normal.
  3.  Detection - A Dll is used to infect the system using a batch file to load it which runs RunDll32.  Alerts on RunDll32 using 4688 with Command Line logging could trigger on this behavior.
  4.  Detection - If you use Windows Firewall logging, which does NOT require using the Windows Firewall, you could detect the IPs used to communicate to the C2 server with 5156 events.  Scan your environment for anyone else using the suspicious IPs.  
  5.  Detection - Monitoring changes to well known AutoRun registry locations could detect this behavior using a 4657 event.  An Autoruns scanner like LOG-MD can also discover these malicious changes.  This payload used the following key:

  • HKCU\Environment\UserInitMprLogonScrip

  • These types of attacks leave noise in well configured logs and can be detected, and in this case prevented by blocking macros for Word documents.  You can use whatever solution you have to collect log data, LOG-MD of course can discover this type of attack if the logs are properly configured, but just searching AutoRuns and doing a Reg Compare would also gain you valuable data.  Of course you need to configure your systems to collect the data locally in order to use it.  Please read the 'Windows Logging Cheat Sheet' and the other cheat sheets on what to configure.  You can get them here:

    There is also a presentation I give on reducing/preventing malware/ransomware from phishing that can be found on the website as well:

    And LOG-MD to collect logs, Autoruns, files, and registry data:

    #Happy Hunting

    Thursday, September 28, 2017

    Microsoft is breaking our security improvements with the new Windows 10 cumulative updates/upgrades

    Windows 10 has been touted as a more secure Windows.  With Windows 10, Microsoft has changed the way systems are patched.  No more ‘Patch Tuesday’ with a bunch of miscellaneous files or individual patch items numbering in the tens.  Microsoft is now rolling up the patches into an actual Operating System upgrade referred to as “Windows 10 cumulative updates”.  Some see this as a good thing, but it actually breaks settings many of us security people apply, or are recommending people apply, or worse have applied and are now removed due to the upgrade(s).

    Before continuing I think it is important to state that I do not feel the default configuration of Windows is at all secure enough for today’s security threats.  It is not secure enough for home users, pro users, education users, or enterprise users.  Microsoft is implementing many new security features with Windows 10, but completely failing at basic ‘Security 101’.  Some can argue that compliance and standards address this by telling you what to set using Group Policy (GPO), but not everyone, nor does every system have Group Policy as an option.  Home users (You, Mom & Dad, Kids, friends, etc.), Small and Medium Businesses (SMB’s), educational institutions, kiosks, labs, and many other systems purposefully do not use Group Policy.  Expecting "Group Policy is the only way to control or apply basic security settings" is a flawed way of thinking in today’s security eco-system.

    Without GPO forcing settings to each system, it is left to the system admin(s) or consultants to manually configure the system, or create a ‘gold image’ that has many of these settings built-in to the image that is being deployed.  Many security hardening standards such as: the Center for Security (CIS) Benchmarks, US GCB’s, or our own ‘Windows Logging Cheat Sheets’ are meant to improve the basic security of a Windows system that is crucial for systems built today, or tomorrow.

    So what kind of things do us InfoSec people recommend and set to improve Windows security?  Here is a list of a few things:
    1. Improved logging by setting over 50 items that are NOT set by default EVER
    2. Increased log sizes in order to collect more than a few minutes or hours of logs, the goal is a week or longer
    3. Enabling logs that are NEVER enabled by default, but crucial to catching malicious behavior
    4. Change default file associations that are regularly used to infect systems due to insecure default configurations
    5. Enable auditing of key directories to monitor for new or deleted files

    Logging is important as it tells us what happens and how so we can fix or clean up an infection, and hopefully learn how the whole event happened to begin with.  The goal, to hopefully avoid it from happening again.  In order to gather this data, one must first enable the logging to collect that which we Incident Responders and Forensics people would want and need.  Even if it is Mom and Dad, your Chiropractor, SMB’s, even corporate users need these settings and Group Policy is often not available to set and push them.

    File associations are, have been, and will be a major way users are so easily infected with malware and ransomware.  Why?  Because of the terrible default configuration that has left this vulnerability unaddressed since Windows 3.1.  The malwarians know about these default configurations and with the recent WannaCry and Not Petya ransomware attacks, the malwarians continue to take advantage of these default file associations to infect systems.  Windows users, system administrators, and even many InfoSec Professionals still have no clue how easily malware and ransomware can be significantly reduced, if not almost eliminated by changing a few file associations.

    Now back to HOW Microsoft is breaking security of Windows 10 with their cumulative updates.

    When Microsoft applies one of their new “cumulative updates” they apply a security policy to the system at the end of the upgrade.  So why is this an issue?    

    If you alter any of the following items the settings are reset to the grossly inadequate Windows default:
    1. Log sizes are reset to 20,480kb, sadly inadequate
    2. The Task Scheduler log and others are disabled if they were enabled
    3. File associations are reset to defaults if they were changed
    4. File auditing set on folders are removed
    5. Data that was in the logs from larger settings is rolled out with reset of log sizes
    These are ones I currently know about, there are likely more.  So far there has been three (3) of them since Windows 10 shipped.

    Here are some screen shots of the settings AFTER the Patch/Cumulative upgrade:

    Application Log Size:
    • Before - 256,000
    • After - 20,480
     Security Log Size:
    • Before - 1,000,000
    • After - 20,480
     System Log Size:
    • Before - 256,000
    • After - 20,480
     PowerShell/Operational Log Size:
    • Before - 500,000
    • After - 15,360

    Windows PowerShell Log Size:
    • Before - 500,000
    • After - 15,360

    TaskScheduler Log:
    • Before - Enabled
    • After - Disabled

    What the C:\Users Folder Auditing was BEFORE the upgrade:
    • Everyone for adds and deletes

    Folder Auditing of C:\Users\<username>\Local
    • Before - Everyone for adds and deletes
    • After - nothing

    Folder Auditing of C:\Users\<username>\Local
    • Before - Everyone for adds and deletes
    • After - nothing

    File Associations:

    • Before - Set to Notepad.exe

    • After - Set to default script engine

    So what are the ramifications of these changes?

    While investigating an incident, I tried to use LOG-MD to harvest the log data and discovered this issue.  I am REALLY glad we built this audit logic into LOG-MD by design!  Maybe we should call this feature the “Post Windows 10 Update Security Settings Validation Tool”.  Unfortunately LOG-MD is designed not to collect log data unless the system is compliant to the settings in the ‘Windows Logging Cheat Sheet’.  

    The data we all want and need was in the log before the “cumulative update”.  After the “cumulative update” was applied, the data that was there the day before was rotated out!  In addition it was discovered folders being audited to collect file drops malware created were no longer set and events being collected.  Also significant was the File Associations that were altered to prevent several malicious file types from executing when clicked on by the user were reset to once again execute the script engine defaults.

    If this were my chiropractor that accidentally clicked a .js file, it would have detonated the malicious payload.  If I were to open the logs and look at what happened, it would have been gone before I arrived on-site.  I present a “How to avoid Ransomware” talk at many security conferences to educate people on the risks and how to reduce it, while providing more log data when an investigation is warranted.  

    Testing these security improvements in our malware lab clearly showed these log, file association and audit settings are crucial to reducing risk from a user clicking the wrong file type and having access to the data in the logs that could explain what happened, and hopefully remediate the system back to a normal state quickly.

    I have provided this information to Microsoft in hopes that they research, investigate and address this issue to stop this weakening of security following a patch cycle that is theoretically supposed to increase security.  Hopefully they will address the issue and fix this terribly insecure oversight.

    Because of this ill side-effect, I have provided a script that will set these items to their recommended desired state and settings from the ‘Windows Logging Cheat Sheet’ that you can tweak to your needs.  The script will set the following file associations to open Notepad versus the default script engine that will detonate malicious payload if a user double-clicks a malicious email attachment:
    • .js, .jse, .wsf, .wsh, .vbe, .vbs, .hta, .pif
    The log sizes are set to the following:
    • Application and System – 256,000kb
    • Security – 1,000,000kb
    • Windows PowerShell – 500,000kb
    • PowerShell/Operational – 500,000kb
    The following log is enabled:
    • TaskScheduler
    Optionally, the following folder auditing can be enabled if you choose, follow the 'Windows File Auditing Cheat Sheet' on what you should audit by default:
    • C:\Users\<username>\AppData\Local
    • C:\Users\<username>\AppData\Roaming
    • C:\Users\Public
    The script can be scheduled to run when a user logs in, every 15 minutes, or added to the users Startup folder, but the user must be an administrator to alter the log settings, and why scheduling a task would be the best option as that will run with elevated rights.

    You can find the script on the website:
    You can find several cheat sheets for Windows logging on the website as well:

    And the tool we discovered this issue with, LOG-MD is found here:


    Monday, May 1, 2017

    Fileless Malware? Not so fast, let's consider new terms

    There is a lot of discussion lately about 'fileless malware', also referred to as 'living off the land', 'memory only', or 'non-malware attacks' .  I do not necessarily agree with this simplistic classification and feel we need to expand what we are calling these attacks to better understand the attack, and thus better detect and defend against them.
    Cylance recently put out an article that listed a 'fileless malware attack chain', below is their "Malware Attack Chain" from the article:

    Being a defender that spends most of the time performing detection and response duties, I would like to suggest some new concepts to better separate what malware today is doing versus generically calling it 'fileless' which is misleading and does not help us understand the method of the attack, which would also help us detect and defend against them, which is the ultimate goal.

    I would like to introduce a new "Malware Archaeology Malware Attack Chain" to incorporate the new proposed concepts.  Let's start with the word malware, which is meant to stand for 'malicious software'.  Let's take this term and modernize it to reflect the evolution of today's malware by aligning it to the ways we would detect and defend against what the malwarians are doing within the attack, whatever type of malware used, which includes the fileless component.

    So what do the vendors mean when they say 'fileless malware'?  Well, I think this may vary by vendor and researcher, but generally it is meant to indicate that once a system is fully infected, there are no files remaining on disk that can be found while the system is running and the malware is active.

    We should consider that there is more to an infection than the final infected state, because there is!  The stages or ways the system is infected and persists should be the focus to better detect and respond, and perform more focused Incident Response.

    Let's take a typical malware infection and walk through the steps or stages of the infection.  We will use a an attack that was received via email, like the above Cylance article used.
    1. Email received and opened
    2. User double clicks an attachment or downloads a file via a URL in the email
    3. The system gets infected executing all the needed steps by downloading any needed files
    4. Executing the malware components
    5. Adding, changing or deleting files
    6. Creating some form of persistence on the system
    7. Running Malware behavior
    8. Re-Infection after a reboot
    9. Re-Infection behavior
    10. Network behavior

    Now let's give names to some of these steps so we can define what they are and how they can vary to include a "fileless" type of malware infection.

    How about the delivery method, in this case Email.  How about to better know the method of attack delivery something more descriptive like;

    • EmailWare
    • URLWare, or WebWare

    Once the download has begun there are many things that happen, starting with the way the infection is delivered, downloaded and initially executed.  How about we call this stage;

    • InfectWare

    This would include how the system initially gets infected including the noise made that properly configured logs would capture.  Whether it used built-in utilities, initial executions of binaries, file and registry changes, and everything that can be detected during the initial infection, the logs could capture it.  This can include, as some fileless malware reports mention, the dropping, execution and deletion of files.  Which to me negates the generic term calling it 'fileless', but we will ignore this point for the time being.  This stage I propose it be named "InfectWare".

    If files are used, and remain on disk after the infection is complete, we can refer to this stage as;

    • FileWare 

    To understand that files are involved at some point during the infection, even if they get deleted after the persistence.  If the files were deleted after the initial infection, we can refer to this as:

    • DeletedWare
    Now the persistence can have many names since there are so many ways to persist on a Windows system.  For example; A Simple run key where files remain on disk is a typical malware infection, but we are seeing more methods of persistence with the evolution of malware.  So we need a new way to refer to these infection methods.  There are many forms that are generically referred to as 'fileless malware', so let's give it a better, more descriptive name so we can better focus detection and response.  So let's consider these names to better describe 'fileless malware';

    • RegWare - Malware that hides in the registry
    • WMIWare - Malware that that hides in the WMI database 
    • PSWare - Malware that utilizes PoserShell
    • BootWare - Malware that hides in a systems boot sector
    • Etc...

    Now that we have some new terms we can now add clarification to malicious attacks and add much needed context to the "Malware Attack Chain".  Let's add these new terms to the "Malware Archaeology Malware Attack Chain" and we get more information to help us detect and respond and even understand more where to look, and what for.

    Now that we have more terms to describe what "fileless" is, fileless malware can be demystified, not as scary, and would be better able to detect and respond to this type of threat using the right tool(s) to hunt for the artifacts.

    For example;  LOG-MD-Professional can search the registry for large registry keys, PowerShell Logs, and also locked files which is a new tactic to block binaries from being inspected.  LOG-MD also has an AutoRuns feature that can discover the majority of persistence locations.  Other tools and scripts can focus at WMI persistence or other interesting bits.  Now we at least can get direction at where to look for fileless malware and better improve our detection abilities.

    We can also use this logic to evaluation Next Generation Anti-Virus to EndPoint Detection and Response (EDT/EDTR) tools.

    Happy Hunting!



    #InfoSec #MalwareArchaeology #LOG-MD

    Monday, October 24, 2016

    The Windows Logging, File and Registry Auditing Cheat Sheets updated for Windows 10 and some cleanup and additions

    The 'Windows Logging Cheat Sheet', 'Windows File Auditing Cheat Sheet' and 'Registry Auditing Cheat Sheet' have been updated for 2016.  The cheat sheets have been updated in part due to auditing improvments added by the 'Windows 10 Anniversary Update' released earlier this year.  We also took the opportunity to do some cleanup and add more autorun keys to the registry auditing cheat sheet.  Updates are easy to spot, just look for 'new'.

    We also post the cheat sheet on SlideShare with our presentations, just search for "LOG-MD" and/or "MalwareArchaeology" 

    LOG-MD is currently being updated to incorporate the changes, so watch for an announcement soon !

    You can get the "LOG-MD Free edition" here:

    Happy Hunting!

    #InfoSec, #MalwareArchaeology

    Thursday, September 15, 2016

    Avoiding Ransomware with built in basic changes

    Ransomware is a pain for those that have been unfortunate to get infected or had to respond to a ransomware event.  While presenting at ISC2 Congress ransomeware was a hot topic and I was asked what can you do to avoid users getting infected?  Notice I am saying "avoid" versus "prevent".  Prevention is difficult due to the constant changes by malware creators to get people to open the malware.  Avoidance means a reduction, not 100% prevention.

    Turns out there are a couple easy things you can do that are built into Windows and FREE, just add a little effort that will drastically reduce the ransomware infections.  First, let's look at how users get ransomeware in the first place.

    Drive by surfing:

    While surfing the Internet ransomeware can infect a computer when a person just visits a compromised website.  A person does not have to do anything other than visit the wrong website at the wrong time to get infected.

    Drive by RansomWare avoidance:

    I tell people to do the following things...

    1. Stop using Internet Explorer or Edge to surf the Internet unless the website specifically requires one of these browsers.  Why?  because there are no script blockers available for IE and Edge as of yet.  Drive by ransomware uses javascript to auto execute the ransomware script using the browser as the execution device.  Using a script blocker will avoid these types of infections.  

    2. Use Chrome or FirsFox with a script block extension(s) such as uBlock Origin, Script Block or No Script to name a few.

    3. Use Ad block extentions to block ads, ransomware loves ads, they will pay real money to get their infection ads on a legitimate ad website  

    Email RansomWare avoidance:

    This is how most people contract ransomware infections.  An email comes in with an attachment or URL and the person opens the attachment or weblink and BAM! infected.  But there is hope.  Email attachments or the URL that will take a user to a website that then has the user download a file and open the file.  The vulnerability here is the auto execution of file types that just are NOT needed by the average user or most users.  These file types are heavily used to infect computers because Microsoft and their ultimate wisdom allows odd file types to be executed if a user opens them and ransomeware is capitalizing on this vulnerability.  You can however tell Windows using Group Policy or setting locally to change the default behavior for any file type like the ones used by ransomware:
    • .js
    • .jse
    • .vbe
    • .vbs
    • .wsh
    • .wsf
    • .scr
    • .pif
    • .hta
    To change the file extension default program in Windows 7 thru 10 open:

    Control Panel - Default Programs - Associate a file type or protocol with a specific program

    Find these extensions and change them all to open Notepad.  In fact, any file type that opens a script program should be changed.  Anyone actually using these file types will know how to open the file in the correct program they need.  Your average user will never need these auto execution settings.  Change anything with "Microsoft Windows based script host" to Notepad and now the scripts will not execute when a person opens them, they will just see the contents in Notepad.

    Block Email attachments that are scripts or executables:

    Many Email gateways and mail servers have the ability to block certain file types from being delivered to the end user.  Most will have executables blocked like attachments containing ".EXE", but most will not have the scripts mentioned above blocked.  Add these file types to be blocked upon receipt and now users will never even see the bad emails with ransomware.  If you do need these file types for developers, then educate the users to encrypt the files in an archive format like .Zip or .7z and password protect them.

    We have already seen ransomeware being emailed within zip files, but without passwords or with the password included in the email asking the recipient to open the archive.  At least you now only have one thing to educate your users to watch out for and never open an archive where the password is included in the same email.

    Of course there is always whitelisting using Applocker and/or Software Restriction Policies or other application whitelisting solution to block executable types and scripts that are not specifically approved.  This takes more work and effort by IT and is the most intrusive to users since you will block the execution of anything that drops onto a system, but will definitely block ransomware and other malware.

    These simple improvements will reduce the ransomware risk your organization significantly.

    Happy Hunting

    Monday, August 1, 2016

    LOG-MD Selected For Blackhat Arsenal Based On The 'Windows Logging Cheat Sheet'
    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.


    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