Search This Blog


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


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:

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

Sunday, July 19, 2015

Considerations when selecting a logging solution and the endpoint agent

I recently posted a sample Windows nxlog configuration file used to control what logs, events and messages to drop or collect and on my website which can be found here:

Nxlog can be found here:

Being a Logoholic and a HUGE fan of Splunk, I of course use Splunk when and where I can and recommend it to clients and the community as the de-facto standard as far as what to compare other logging solutions or a ’SIEM' too. With the discontinuation of Splunk Storm (Boooo), Splunk's free, low storage, low retention option, I needed another solution that was cost effective and useful. The need is to conduct malware archaeology to harvest artifacts, do some malware lab work and recommend to SMB's a simple solution. In addition, an easy to use and easy to configure logging option for use in Incident Response engagements when a log solution was not currently being used. Of course I tried, tested, even found bugs I reported to the vendors on a few cloud based logging solutions. Something I can have the potential client deploy on suspect systems and configure the logs settings manually before I get onsite so real data is waiting for me when I arrive, or remotely review.

Nxlog is a generic syslog agent for Windows, MAC and NIX systems. Nxlog can even format the logs into JSON providing some formatting for ease of reporting. Several solutions use it as their default or recommended log agent. Even Splunk, Sumologic and LogEntries who have their own logging agent can use nxlog.

Another logging agent to consider is the "Windows Logging Agent" or WLS, but that is another Blog post for another time... More info on WLS can be found here:

A few folks reached out and asked "Why nxlog"? Thus this Blog post. There are several considerations when selecting a logging solution or vendor. The short list is:

1. What logs can their agent read, not just the default logs, but all the other logs on the system that often get ignored and not collected. Windows has lots of them.
2. What configuration options does the logging agent have. You can send all your data, sometimes WAY more than you will ever need to your logging solution and filter from there, if they can filter at the server, most cloud solutions cannot. Logs equal disk space and appliances have limited disks, limited disk space equals short retention periods. Properly configured logs, which by default in Windows and databases are crap, properly configured logs equals more disk space. Unless you can filter your log data BEFORE sending it to your log server, you will need more disk space or license, thus filtering log data before it is stored on your log server is key unless your log solution allows server side filtering like Splunk does. This helps to reduce known good noise, making what you are looking for easier.
3. License or recurring costs for basic needs, think SMB's, Analysis Labs, Testing, etc., think Cloud based solutions
4. Scalable for medium and large needs, typical logging solutions and Cloud based solutions that scale
5. The ability to send alerts that are meaningful. Not the entire log entry, but just the columns of the data that says this IP at this time had this detail. Most important is the ability to read the alerts on a Smartphone so we know if we have an issue and need to act in a simple easily readable email.
6. The ability to exclude data easily from your queries to reduce 'known good' noise. I really don't need log entries that just don't tell me anything and are completely normal. Filter the good out to reduce what you are looking at to make log analysis easier.
7. Of course being able to send log files like web servers, network hardware and other odd devices you might have is also important. Most of these are syslog capable and most can handle raw syslog data, but sometime little no formatting once in your log solution, JSON formatting is best.
8. Ease of use to create queries, easy searching to create reports and alerts is key, selecting columns of only the data you want, not all of it.
9. The ability to normalize data or mark data so known fields (EventID, Username, CommandLine, etc.) are easy to select making a simple report with only the parts of the logs that are meaningful.
10. Does the solution have some intelligence to correlate events, or will you need to build the correlation events, which is OK as I know what I want to see, most vendor compliance log reports suck IMHO and don't help in alerting me to a real attack, they are just so you can check the we have it on a compliance report.

If a log solution can do all of the above, then you have a solution to evaluate to see if it fits what you need, or a guide to evaluate some more enterprise capable solutions.

If you use these ten items to evaluate a logging solution, you should come up with a short list pretty quick. Here are a few solutions worth trying.

  • Loggly Cloud (cost effective and scalable) I use this for my lab work! $45/mo. for 1GB per day of data
  • Splunk Cloud (much more costly and scalable)
  • Splunk Server (enterprise)
  • LogRhythm (enterprise)
  • ELK Stack (OpenSource project, poor alerting)

Happy Logging and don't forget to use the "Windows Logging Cheat Sheet" to learn what to enable, configure, gather and harvest.

#InfoSec #MalwareArchaeology #Logging

Wednesday, June 17, 2015

Freezing your Credit is a great idea

If you have had your credit or worse debit cards compromised, in my case on my 5th credit card in a year, then freezing your credit and your children's credit is a great idea.

The process is pretty simple, you can do it over the phone and the fees per credit bureau vary per state, but roughly $30 for all three credit bureaus.

A nice side affect of freezing your credit is that it also prevents you, or someone bad from creating an account to get a copy of your IRS accounts for things like federal tax filing transcripts as I found out when I tried to register for my transcript records.

You will have to "unfreeze" your credit when you want to buy a car or home, and do so about 72 hours prior to requesting credit from someone.  The same process applies, call the credit bureau's and unfreeze your account.

Here is the URL's for all three credit bureau's:


Safe retailing ;-)

Sunday, May 17, 2015

Detecting and Defending against PowerShell Shells

So much of our industry focuses at Red Team P0wnage.  I read a retweet by my Con 'son' @Ben0xA last week on PowerShell Shells by 'Lab of a Penetration Tester' Blog Nikhil Mittal @Nikhil_Mitt.  Nikhil did a week of PowerShell Shells on his Blog found at:
Nikhil did a great five days of PowerShell Shell examples of different types. Here are the five PowerShell Shells Nikhil reported on:
  • Day 1 - Interactive PowerShell shells over TCP
  • Day 2 - Interactive PowerShell shells over UDP 
  • Day 3 - Interactive PowerShell shells over HTTP/HTTPS
  • Day 4 - Interactive PowerShell shells with WMI
  • Day 5 - Interactive PowerShell shells over ICMP and DNS
This is a perfect exercise for Blue Teamer's as more and more malware is trying to use PowerShell and by default, Windows has terrible default logging to detect PowerShell use or misuse.  PowerShell provides malwarians a way to persist their backdoors without having to leave a malware payload behind on disk that us defenders may be able to find.  This method is also used by MetaSploit and the 'Social Engineering Toolkit' (SET) pen testing tools.

The post exploitation kit known as PowerShell is included in every newer version of Windows and being used more an more by administrators, InfoSec pros and yes, the malwarian Hackers since it is so powerful and already on the system reducing the need for malware files to remain behind and potentially get detected.

The week of PowerShell Shells is interesting in that you can try the Shells in the five posts Nikhil created as he provided great examples and sample code and scripts.  This is kewl in that you can try them and for those of us on the Blue Team side, figure out what we would do to detect this type of attack.  If you are like me, you use these types of Red Team Hackery posts to test, validate and improve your defenses.

So what can we do to defend against PowerShell P0wnage?  A lot actually, but you do have some configuration to do which I have already discussed in a previous post, but let's take a direct look at one of the the PowerShell Shells.

Here is a screen shot of the TCP PowerShell Shell I ran for the test.

As you can see the connection was successful.

So what can we detect for this type of attack ?

First off, we need to make sure your system is ready to capture the behavior so be sure you have the following items configured:

  1. Advanced Auditing enabled (Win 7 and Win 2008 and later)
  2. Command Line logging registry hack applied
  3. Process Create - Success
  4. PowerShell default profile enable enabling command line logging
You can see how to enable and configure your logs to detect these types of attacks with my info:
Just an example, here is what a netcat shell listening looks like in the logs to get us started.  EventID 4688 picks this up easily with the command line logging tweak!

Now let's take a look at what you can detect when a PowerShell Shell is executed.  There are two ways to execute PowerShell scripts, inside a PowerShell Shell and via a Command Shell.  It was not clear how this was done in Nikhil's posts so let's take a look at launching both methods and how to detect this behavior.  Also, it was not clear what the PowerShell ExecutionPolicy was set to on the system, so lets assume it is set to restricted (default) and the hacker would have to bypass this restriction.  But here is what a failed execution looks like in the logs due to the ExecutionPolicy being set to 'Restricted'.

If a hacker wants to execute PowerShell scripts and bypass any restrictions, they will need to state a bypass on the command line when launching PowerShell.  The EventID 4688 will detect this behavior and if you have command line logging enabled, catch this condition every time.  This should be a key alert that you setup as this is a clear indication someone is trying to hack you!

If the entire command was executed at the command line it would look like this in the EventID 4688 log entry.  BAM!  Got you sucka!

Monitoring for an ExecutionPolicy bypass and/or NoProfile bypass would catch someone trying to p0wn you instantly.  I recommend you monitor and alert for this as a critical Top 10 that you monitor and alert on!

Let's assume we ignore any EventID 4688 events and want to detect this using PowerShell logging.  There are two ways to do this, the first being easier to integrate into a central Log Managment solution by properly configuring the PowerShell logs to capture command line activity.  The other is to use the PowerShell Transcript logs which can be configured to capture everything executed when a PowerShell Shell is invoked.  PowerShell Transcripts are a text file usually found under the users AppData directory structure.

Let's look at EventID 500 or 501 of the 'Windows PowerShell' Log to see what the PowerShell Shell execution looks like.

As you can see we are able to catch the hackery with either a Security Log EventID 4688 or with a Windows PowerShell Log EventID 500 or 501.

Here are the details executing in the PowerShell script Nikhil provides.

You can easily see the IP and Port used, streaming information, path, byte info and encoding.  Clearly communication is taking place that shows up in the Logs if properly configured.

The second method is the PowerShell Transcript log that you can invoke in the default profile so started each time PowerShell is invoke, to either overwrite or append.  This is what the PowerShell Shell execution looks like when I was testing.

As you can see as kewl as the file-less PowerShell Shell hacking may be, it is clearly detectable and you MUST look for this behavior in your logs as it is getting used much more in malware I am seeing today.  Within the last month I dissected a malware sample I received that was a Microsoft Word document that executed a VB script launching a command shell, calling CScript script which then launch a PowerShell Shell backdoor.
Being a Blue Team Defender I REALLY wish the Red Team Breakers and Hackers would include the Blue Team 'How To Defend' against the breaking and hackery they discuss...  Instead, us Blue Teamers must digest these types of posts and create a counter-point post on how to defend against these attacks.  

Happy Hunting!

#InfoSec #PowerShell #Defend

Friday, May 15, 2015

Protecting Card Key Systems on your network

I was in the airport awaiting a flight this week and someone who saw my presentation on a Card Key system hack from a year or two ago stopped to ask if I had created a White Paper to help in securing the systems from P0wnage like I demonstrated with a major vendor.
I told him check out my Blog (This post specifically) and that I would write up something to the vulnerability that is easily exploited on many, if not most Card Key systems using Lantronics Ethernet adapters.  So here it is, what you need to know to asses and how to protect your existing Card Key systems back end controllers.

First off, newer designed Card Key systems are moving away from the Lantronics daughter board concept by building ethernet adapters right onto the controller board.  This should fix many of the flaws we found, and give the vendors more control over what they can code into their solution, but does not mean that a clear text Auth flaw in a new design will not exist, let's hope encryption is on by default in any new designs.  Hint: if you are evaluating Card Key systems, make encryption on by default a must have and No Go decision point.  Evaluating the newer designs is a job for another security researcher, or when I come across one I have to assess, or that is given to me ;-)

Internet based Card Key systems

For Internet based Card Key systems (like Brivo) where you login to a web portal to grant or revoke access, username and passwords are all you have to protect against break in from anyone on the Internet, which is the world.  So you better use a very long password and cryptic username that is not like anything else you use on your corporate network.

A few of the flaws of network accessible Card Key systems

One flaw with network based Card Key systems is the ability to open all doors in a maintenance mode.  Yes, all your front, side and back doors, not to mention sensitive or secret locations.  So your access control by user and function is worthless to the flaw we found and why better protection of the Card Key master controller(s) is required.

Another flaw with Card Key systems you might have is logging is non-existent.  I can brute force the system and you would have no idea that I was doing it, they do not have any usable logging or lockout capability after 5,10 or 10,000 attempts.  Keep in mind these systems were designed before needing network access and the Lantronics daughter board modification.  Adding the Serial to Ethernet board opened up a whole new use of remote administration without any re-design of the solution.  The Internet is littered with these controllers for remote administration by a management or security company.

A third flaw is that these systems only had unencrypted communication.  On the re-designed systems we were provided the encryption was off by default and thus only an option, not to mention off by default for 15 seconds if you could power cycle a system, which is not hard as these often have no battery backups.  When I asked a Card Key system security implement or why they did not set the encryption option, a simple password or phrase to generate a unique key... His answer "Because no one would remember or know how to find the password"... Grrrrreat!

Secure Option 1 - Network Isolation

Isolating the Card Key system and all the PC's that would access it is an option, but not overly practical for anyone but large organizations with dedicated IT network staff.  But here is what to do if this is a viable option for your organization.

Step One - Assess the signature of your Card Key System(s) NMap or any other port mapping utility is your friend here.  Throw scans at all of your Card Key systems and understand the ports they are using.  Ports 80, 443, 9999, 100001, etc.  These are the ports used by the Windows fat client application to communicate with your Card Key interface.  Lantronics systems have an obvious signature once you discover them, record what you have for future reference.

Step Two - Who needs access to add users and from where?
If you have any chance to limit access to the Card Key system over the network, you will need to know what users, specifically their systems IP address, which will need to be a static IP in order to build ACL rules to limit what systems might be able to try and gain access to administer the Card Key system.  If you can manage to limit who's computer needs to access your Card Key systems and in what locations, you might have a chance to build some network ACL's to restrict the Card Key system IP's to just those IP's of the workstations with the fat client.  This is how you would secure the Card Key systems from a network access control perspective.  Though if a malwarian pops one of these approved systems and finds the software... Game over.

Keep in mind if I can find your Card Key system on your network, it IS game over or more appropriately Doors Open, and all of them, not just one.

Secure Option 2 - Consider a replacement or upgrade 

Once we reported the flaw to the vendor we tested they graciously provided an updated system after they addressed a couple of the issues they were able to, but Lantronics did not change a thing.  This means the best way to improve this vulnerability is replace all your Card Key systems.  I know this is a bad option since roughly 10,000+ Lantronics controllers are shipped each month... Yup....  Major bummer for users of this legacy design.

Secure Option 3 - Isolate the Card Key system to a single PC ( My highest recommendation) 

Ironically the reason that the Lantronics Serial to Ethernet daughter board was created was to move away from the limitation of one PC serially connected to the Card Key device so any user on the network could manage user access in any location or worse... Over the Internet in the clear.. Yup, you heard me... Clear text auth!

This option would still allow you some flexibility in that you could locate the dedicated PC in any server room or closet with your other phone gear and use patch cables to connect directly to the PC via a hub or cross over cable.  Using a 2nd Network card you could then connect the PC to the open network.  If I were to scan your network for the Lantronics signature, I would not find any, just the Windows PC it was connected to and no way to know if it had a Card Key system attached.  This security option allows you to remote into the PC using basic Windows remote utilities, RDP, VNC, or whatever you fancy for remote control and from anywhere on the network and yes, if you use a secure remote control option, even over the Internet.

So there you have it, the basic ways to secure the Card Key systems controlling your door access.  Check out what JGor (@Indiecom) has done with some nifty Card cloning P0wnage.  You might want to understand how this works as well, but is a different problem and affects a specific users card and the access of that card, unlike opening all the doors of a building.

Happy Hunting!

#InfoSec #CardKey 

Thursday, March 26, 2015

Detecting PowerShell Malware Hacking - It's popular, so you better start doing this!

The Post Exploitation Kit known as PowerShell, included with every version of Windows since Win 7 is being taken advantage of more and more by criminal malware authors. SET and MetaSploit also use this method.

I recently evaluated a SPAM barrage that included a Word Doc and ZIP file containing a Word Doc. At first I thought "laaame", but after throwing it into my lab malware analysis system, I was surprised what I found. Keeping in mind this was commodity malware since it came via Email, not APT, it had components that one would find in more advanced attacks.

PowerShell is well, powerful since it utilizes .NET. PowerShell can do just about anything on a Windows system. With this kind of capability PowerShell is a perfect exploitation option for malwarians as it is already on every system making it a no brainer for the criminal malware writers to utilize and reduce payloads on the system.

So what was special about this Word Doc SPAM I was given to analyze? For starters it bypassed the Word script protection we see when we open a Word document for the first time which is suppose to prompt the user to accept or enable macros. The malware had MS Word automatically run the embedded script displaying in the only page of the document, "There was an error contacting your financial institution". Another version I received had gibberish and failed the script bypass, clearly the BETA attempt of their malware.

So what was in the Word Doc? A quick peak at the file showed embedded script so I knew something bad was within. I opened it on my malware lab system to see what malness was hiding. The file dropped a .BAT, .VBS and .PS1 file and launched the batch file which called the .VBS file which then launched the PowerShell script. Oddly enough each script obfuscated the name of the next by using variables for parts of the name that were then assembled to create the commands to execute the next script. So if you ran strings against the files for things like .vbs or .ps1 you wouldn't have seen any results, maybe to hide from IPS and network sniffers too, lame.

In addition to the three scripts, an executable and PNG were dropped. The PNG a was the Google logo and the amount of writes that occurred to the image indicated to me the PNG was the keystroke logger file, hiding as an image. The malware pinged a site in China and then made a connection to a system in Germany. It's nice to play with multi-national malware. So what did the malware do from a PowerShell perspective?

A vew of the PowerShell reverse shell after MS Word closed as the parent:
First, the malware tried to hide the fact that a PowerShell script was being used.
Second, the VB script bypassed the PowerShell ExecutionPolicy in order to run the malware.ps1 script. PowerShell by default disables the ability to run .ps1 scripts without changing the ExecutionPolicy. Oh yeah, Microsoft has a built-in bypass for ExecutionPolicy, #fail.
Third, the script bypasses any profiles used, such as the default profile.ps1. Oh yeah, Microsoft has a built-in bypass for Running profiles, #fail. So if you are using a default profile, which I recommend everyone does due to the capabilities of PowerShell, the malwarians bypassed this as well. Why? Because this is where you set the two variables to enable command line logging to catch behavior just like this. All this from commodity malware used in a SPAM campaign. WOW!

PowerShell Bot for sale!!!
If you have not heard of this, there is a commodity bot named "Phase" that claims a "Fileless" malware to infect the targets. How? By using PowerShell to run the reverse shell. Using yet another flaw in Windows, Rundll32.exe, used to,load Dll's, common for services can launch JavaScript which in turns calls wscript, which in turn launches PowerShell, pOOf - Got Shell?

How does "Phase" persist? Lamely it is via the Run Key calling the PowerShell script via Rundll32 calling JavaScript which uses wscript to call PowerShell. And the kicker, the payload is hidden in the Registry as a benign entry waiting to be read, decrypted and executed.

So what are we learning from these two unrelated malware?

1. Bot Kits utilizing PowerShell as the heavy lifter are available making the injector virtually Fileless.
2. We are seeing malware using PowerShell more frequently.
3. If you set a default profile (profile.ps1), which I recommend everyone do to set command line logging for every PowerShell session, it can be bypassed.
4. If you have a default install of PowerShell and think it can't run .ps1 scripts, think again, the malwarians can bypass the PowerShell ExecutionPolicy, regardless of what you set it to.
5. Most people do not monitor for PowerShell execution or monitor the 'Windows PowerShell' logs.
6. PowerShell is used by system admins to manage Exchange servers for example.

So how do we deal with this new threat? How do we monitor for PowerShell nefarious behavior?

Logs are your best friend here!  The SEXY Six to the rescue...

Of course you first must Enable your logs and Configure them. Please read my "Windows Logging Cheat Sheet" on How and What to enable and configure. If you feel you have your logs enabled and configured, then you are ready to detect PowerShell p0wnage!

1. Set 'Detailed Tracking - Audit Process Creation to Success'
2. Set the registry tweak to enable process command line logging (see below)
3. Check that you are capturing execution of a process and capturing the command line executing. Open a command window and type 'net use * \\\c$ /u:TestUser /p:OhCrap'.
4. Open EventViewer, Splunk, WEvtUtil, LogParser or (snicker) PowerShell and look for EventCode 4688 in the Security log and find your Net Use test.
5. Do you see your test? If so then you are ready to detect PowerShell exploitation. If not, then you have not configured things correctly.

Now test that you can detect the following commands being executed. Open a command window and type the following:

1. "PowerShell -ExecutionPolicy bypass -noprofile"
2. "Rundll32 JavaScript wscript" and some other words
3. "CMD /c Cscript" and some fake script name

If you see any variation of the above three command lines in EventCode 4688 (Process Create - SUCCESS), then you are detecting PowerShell hacking!  If you see any combination of the items below of PowerShell security bypasses being executed - INVESTIGATE!

1.  PowerShell -ExecutionPolicy bypass
2.  PowerShell -noprofuile
3.  cmd /c PowerShell -ExecutionPolicy bypass -noprofile

If you see any combination of powershell, javascript, mshtml, wscript, cscript or cmd.exe being executed in the command line of a 4688 event, you are probably being or have been hacked!

You are looking for executions like this which are way outside the norm of what RunDll32 normally executes. Also this will occur on boot or infection. Check your Run keys and services for these type of executions as well. Malwarians LOVE replacing good Dll's with bad ones. And everyone must watch CMD.exe executions!!! Active Defense 101.

From the Phase bot:

Rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";eval((new%20ActiveXObject("WScript.Shell")).RegRead("HKCU\\Software\\Microsoft\\Active%20Setup\\Installed%20Components\\{72507C54-3577-4830-815B-310007F6135A}\\JavaScript"));close();

Watch the Registry for large key/value/data sizes
Look for large Registry keys and validate they are normal. Look for keys over 50k and work your way down to 20k as you build a Whitelist of normal large keys, there are a few that are normal. Use a tool like 'RegScanner' by NirSoft to search for large keys, a nice GUID utility. Any keys with data starting with "MZ" or "4D5A" are clearly bad and executable content. Of course if the key is encrypted in some way, as the case with Phase using RC4, then the starting values can be anything and the size, location and uniqueness will be your indicator of badness.

I hope this example of Malware Management, reading of malware analysis and tweaking your defenses helps you improve your capabilities.

Send me your comments.

Here is how to enable Command Line logging for Windows systems (kb3004375 patch needed):
reg add "hklm\software\microsoft\windows\currentversion\policies\system\audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1

The Windows Logging Cheat Sheet

Great articles on PowerShell based malware:

MalwareTech article on Phase - Part 1

MalwareTech article on Phase - Part 2

Great article on Poweliks PowerShell malware

Happy Hunting!

#InfoSec #HackerHurricane #PowerShell #Hacking

Wednesday, March 25, 2015

PoSeideon malware is incredibly easy to detect

Here we go again. A new PoS Malware variant dubbed PoSeidon has been analyzed by Cisco and the details made public. When I read this I said out loud, "This is stupid easy malware to detect".

Practicing Malware Management shows us there is so much to learn or validate that your defenses can indeed detect this type of attack. The Process also provides you with details to improve your defenses by adding or adjusting some checks.

PoSeidon uses typical malware vectors and seems to have nothing sophisticated, nor any improvements to hide or conceal the infection. If you have been practicing Malware Management or reading my other blog entries on the subject of malware, it will become apparent how typical and easy this malware variant is to detect. Let's take a look.

First off this is Windows malware so Eventcodes are key.

1. The loader is an odd .EXE that can be detected with EventCode 4688
2. The malware uses the Run Key for persistence to survive a reboot. Detectable by EventCode 4663 if you audit the Run Keys, which you should, it's Active Defense 101
3. The loader downloads and installs a file called FindStr.exe. We all know what the CMD FindStr does, so seeing this execute in a way that is not looking for a string in a file would be easy if you enabled command line logging (See below for the setting). Detectable by EventCode 4688.
4. If you look at the strings of the malware (after you found it), the project file name is a dead give away, "keylogger.pdb", hello McFly, really? They are not even trying to hide it. Detectable after you find the suspect file and use (strings -n 5 malware.exe | find /I ".pdb"). Not to mention the loader file also used "loader.pdb" as the project title, and even FindStr.pdb was found. Thank you malwarians for making it easy to see the project titles and that it's obviously malware.
5. Two file names were used, WinHost.exe and WinHost32.exe and saved in... You guessed it \Windows\Systems32. Detectable with EventCode 4663 if you enabled auditing for System32 for NEW files. Read the "Windows Logging Cheat Sheet" for more on this. Also detectable with EventCode 4688 as it will be an executable you have not seen before, thus suspicious.
6. There is mention the loader tries to install a service. Detectable by EventCode 7045, NEW Service installed, this too is Active Defense 101. Know your services!
7. Command lines, you gotta love them! To delete the loader the command "cmd.exe /c del >> NUL" was executed. If you are not watching what command line parameters are being called with ALL CMD.exe executions, you are missing the Goose that laid the Golden Egg! Detectable with the command line logging Reg Mod and Event Code 4688, focused on executions of CMD.exe
8. Of course there is the network traffic too, but that is another area of expertise and between "IPConfig /DisplayDNS" and "NetStat -abno" you can see what IP's and Domains are being used by the funky executables, IF you know what your systems normally run.
This malware is almost laughable in the effort to hide what they are doing. Clear readable .pdb project names clearly indicating the files are malware shows strings are a powerful step in malware analysis.

I promote the SEXY Six Windows Event Codes and this malware is easily detectable using the SEXY Six.
Read more about how to log Windows with my recent BSides presentations.

Get my presentations HERE to learn more on Malware Discovery and Logging

Remember, the goal is to take this information, tweak your tools to look for and detect the behaviors discussed and to improve your Incident Response and Information Security Programs to detect and respond to these persistent attacks.

And...  Enable Command Line logging on ALL Windows systems!  And Audit this key and alert to ANY and ALL changes.  Win 7 and Server 2008 R2 and later with patch KB3004375 installed (Feb 2015), Win 8.1 and Server 2012 already have it by design.

reg add "hklm\software\microsoft\windows\currentversion\policies\system\audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1

Happy Hunting !

Cisco details on PoSeidon malware

#InfoSec #HackerHurricane #Malware #CommandLine_Logging

Wednesday, January 7, 2015

Is the New Windows 8.1 0-Day a big deal? Not really if you're logging like you should

Google engineers just released a Proof of Concept for an undisclosed Windows 8.1 vulnerability that would allow privilege escalation.

Is this a big deal? Only if the bad guys can execute something on your system and execute a specific command. By now you should know if the malwarians can get you to visit a compromised website, get a user to click on a URL or open an attachment in email, game over anyways. No 0-day needed, but hey, just another option for the malwarians to use. This vulnerability bypasses UAC in typical not secure enough Windows Default settings. You can always annoy your users by turning up UAC to prompt more as Vista did, I'm sure they won't mind ;-) because users are great at knowing what is good and what is bad .

THANK YOU GOOGLE for releasing the details which allows me and other Blue Team Defender Ninja's who utilize logging, as we all should be doing to easily detect this vulnerability and its use in an attack. Some are saying a company the size of Google, (who does not use Windows as a primary OS for desktops FYI) should not have disclosed how to exploit a system. That is another discussion on what is responsible disclosure.

Why is this a good thing for us defenders and you?

While Microsoft figures out the fix, us defenders and those reading this BLOG can take the following actions to detect if the attack is used or attempted, even after the patch is issued. I think this is awesome info as watching for these types of command executions are crucial to active defense Blue Teamers like myself and others who use and rely on logging for security.

Here is the command used in the exploit:

"AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll"

- Test.dll being the malwarians bad code.

So how do we detect these types of attacks?

Step 1:
Enable Command Line logging for Windows 8.1 and Windows 2012 R2 by creating the following key or adding to GPO if your on Server 2012 Domain Controllers.


Step 2:
Look at EventID 4688 for the "Process Command Line" that contains:
"AppCompatCache.exe c:\"

Create an alert whenever this is executed. You can go as far as specifying the exact command Google disclosed, but You should keep it more generic so you can pick up typos, yes hackers make typos.. They are human by the way.

This is similar to another vulnerability malwarians often use exploiting "sysprep.exe" by using the command line:

"sysprep.exe c:\windows\sysprep\cryptbase.dll"

- Cryptbase.dll being the malicious payload.

Setting up monitoring for these type of commands as you discover them while practicing Malware Management, as I recommend everyone start doing, or as you read these type of disclosures and think "I wonder if anyone has attempted this on my systems"... Will vastly improve your InfoSec defense capabilities. Below is an example of the Win 8.1 Command Line logging enable.

If you are running older versions than mentioned above, have no fear, Sysmon is here! The Windows Logging Service (WLS) can also provide this Command Line logging. Below is an example of Sysmon capturing the commands entered.

From my perspective, there is far more good than bad that Google released this to the public as Microsoft will patch this quickly. It did however help reinforce Malware Management can help you detect things as they occur, 0-day or not, so you can react faster and avoid being a Target, Home Depot or Sony.

Google research on 8.1 vulnerability

Happy Hunting!!!!

#InfoSec #HackerHurricane #YayGoogle

Sunday, December 14, 2014

(I) Regin Malware sophisticated? Maybe in function, NOT discovery

Everything you read about the Regin (Reg In or Reagan) malware indicates that it is one of the most "sophisticated" malware since StuxNet.

Reading this irks me since many in our industry read "sophisticated malware" and they think "I can't detect this stuff". Actually you can! You just have to look and applying The Malware Management Framework could have discovered.

Before taking a look at how to discover Regin, what is sophistication as far as malware needs to be discussed as the Information Security industry really needs to change how It discusses malware. Malware should be broken into two components as far as sophistication:

1. Function
2. Artifacts

Function of the malware, the application portion is different than the artifacts or indicators that exist on the system. Sophisticated function does NOT make malware too sophisticated to discover.

Discovery and Function are not synonymous when it comes to malware. As a Blue Team Defender and IR person, the first order of business is to discover malware. What the malware does application wise is secondary and part of the malware analysis stage that occurs after malware is discovered.

Malware is made up of files and processes. If malware exists on disk which 95% does, it can be discovered. Now that function and artifacts have been discussed and split as far as sophistication, let's take a look at discovering Regin as it is NOT that sophisticated that we could not discover it.

Two clever functions Regin used are to use NTFS extended attributes to hide code that pointed to the Windows \fonts and \cursors directories. But the main payload was stored on disk mimicking a valid file, not hidden in any way. Regin has pieces littered in many directories, but the main payload is fairly obvious if you watch for a few indicators.

The second clever thing that Regin did is to store some of the payload in the space between the end of the partition and the end of the disk as most drives have empty blocks that can hold a small partition, enough for malware to be stored. You would have to use disk utilities to find an odd partition area.

What we are after in malware detection is some indicator that we can focus on that indicates a system is infected. The goal is to find one or more artifacts, not necessarily every artifact since once you find an artifact it will lead you to more details once you begin detailed analysis. The goal of malware discovery is to discover something so that you can take some action. You can do nothing, not advised, you can re-image a system, or find enough of the malware, what we call the head of the snake, and cut off the malware's head to clean the system enough to move on. A lot of organizations do not have the resources to do full analysis up front and business and management just wants you to clean it up and move on in many cases.

Regin drops the initial malware Stage 1 & 2 into the following directories:

• %Windir%
• %Windir%\fonts
• %Windir%\cursors (possibly only in version 2.0)

The main Stage 1 payload is a driver (.SYS):

• usbclass.sys (version 1.0)
• adpu160.sys (version 2.0)

This driver is the thing you should be able to discover. According to the reports, the only malware component that is visible. This driver is added to the Windows main directory with the other components using the first clever feature by storing the other parts of the malware into the NTFS Extended Attributes in other directories. You discover this driver and you found the head of the snake!

The malware can also store some of the code in the Registry. Regin used two keys for this purpose:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RestoreList\VideoBase (possibly only in version 2.0)

If you use Auditing like I recommend for many directories and registry keys, you could have detected the additions to the Class Key as this location does not change much.

Since malware can be stored just about anywhere in the registry that the active user can access, discovery of this part of the malware is challenging. You are usually led to additional artifacts when you analyze the malware and find a string pointing you to a registry key, but auditing keys can help you discover malicious behavior, so consider using auditing on main keys that you find in your Malware Management reviews of reports such and Regin, Cleaver and many others to help build your detection abilities. Be sure to test the audit settings as some keys generate crazy noise and you will want to disable auditing in these locations.

After the initial Stage 1 driver loads, the encrypted virtual file system is added at the end of the partition instead of using the standard disk Stage 3 is stored in typical directories:

• %Windir%\system32 • %Windir%\system32\drivers

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\

This portion should be encrypted and harder to detect, but there is the registry key! So auditing is your friend here.

Hopefully this shows how even the 'most sophisticated malware' could and can be discovered if you practice the Malware Management Framework. The head of the snake was visible and detectable with Regin as well as registry keys used. Read the reports, pull out the indicators, tweak your tools or scripts and begin WINNING!

Read more on the Regin malware and use Malware Management to improve your malware discovery Skillz and Information Security Posture.

#InfoSec #HackerHurricane

Tuesday, November 11, 2014

(I) Powershell logging, what everyone needs to know about it

Powershell is, well powerful. Microsoft is making Powershell the future of Windows Management starting with Windows Server 2012. For us security peeps, Powershell is capable of doing a LOT of security tasks, like Ben Ten, @Ben0xA showed at his Powershell workshop at BSidesDFW. With all the capabilities Powershell has leveraging .NET, you and the hackers can do just about anything!

So how do we monitor and defend against such a powerful hacker tool? MetaSploit and the Social Engineering Toolkit uses Powershell as does PowerCat, a Powershell netcat tool. Powershell is used since commands can be executed and no files are dropped on disk, unless you want to, making it VERY hard to detect... Or is it hard to detect?

You log it, that's how. But alas, Microsoft does not enable what you need by default so you must do some work to get the commands properly logged. If Powershell is executed you will see EventID 4688, but that only tells you Powershell executed, not what was executed. We security peeps need more details, but first execute a few Powershell commands and look at the logs. see any command lines???? Nope...

If you want to improve your security posture and protect against Powershell misuse and abuse, and just plain know what the heck is going on with Powershell in your environment, give this a test drive.

1. Create an All User profile (profile.ps1) so you can enable some global variables
2. Enable two global variables so Powershell will log what is entered at the Command Line
3. Increase the size of the two PowerShell Logs
4. Gather the two PowerShell logs
5. Enable file auditing to profile.ps1 so you know if anyone changes the default profile! Most important in case the bad guys look for, modify and/or delete it.

#1. Create profile.ps1 in \Windows\System32\WindowsPowerShell\v1.0. Add something to the beginning of the profile so you know the profile is working, for example; change the drive letter to D:, assuming you have one, or echo a Reg Rey or write a Reg Key entry (great to log for later).

#2. Add the following two variables to your profile.ps1
a) $LogCommandHealthEvent = $true
b) $LogCommandLifecycleEvent = $true

Sample profile.ps1
CD D:\
$LogCommandHealthEvent = $true
$LogCommandLifecycleEvent = $true

WARNING: If you use usernames and passwords in Powershell scripts, this will show them in the logs. Of course you know to rotate these Creds frequently

#3. Increase the size of the Powershell logs so they collect a LOT of stuff. Do this by opening Event Viewer, navigate to "Applications and Services Logs" right-click and selecting properties of the logs "Windows Powershell" and "Microsoft\Windows\Powershell\Operational" logs, increase their sizes and be generous.

#4. Gather the Powershell logs however you can, through wevtutil, Powershell, or a log agent like Splunk. Below I have included a Splunk query for harvesting Powershell commands being executed, enjoy.

#5. Enable File Auditing on the profile.ps1 file for any changes or deletion so you can alert on this condition in case the bad guys modify and/or delete your default profile. Do this by right clicking on the profile.ps1 file in Explorer, selecting Security, Advanced, Auditing, Continue, Add, type Everyone, Check Names, OK and then select the following properties:
a) Create Files
b) Write Attributes
c) Delete
d) Change permissions
e) Take ownership

Now you will audit any changes, ownership and deletions to the profile.ps1 file. Look in Event Viewer for EventID 4663 Accesses = DELETE and Accesses = WriteData. Test it!

And there you have it, go ahead and test your new settings and execute some Powershell commands and see how it logs unlike before so you can catch your Pentesters, hackers or nefarious admins using Powershell for more than just administration.

For you Splunkers, here is a query I threw together to monitor what Powershell Command Line parameters are being used. Filter out the good to look for the bad.

1. Add Powershell to your inputs.conf (tweak as needed)

disabled = false

[WinEventLog:Windows PowerShell]
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5

2. Create a query like the following:

index=* LogName="*Powershell*" | eval Message=split(Message,". ") | eval Message=mvindex(Message,0) | eval MessageA=split(_raw,"Details:") | eval Message1=mvindex(MessageA,1) | eval Message1 = replace (Message1,"[\n\r]","!!") | eval MessageC=split(Message1,"!!") | eval Message2=mvindex(MessageC,2) | eval Message3=mvindex(MessageC,3) | eval Message4=mvindex(MessageC,4) | eval Message4=split(Message4,"=") | eval PS_Ver=mvindex(Message4,1) | eval Message5=mvindex(MessageC,5) | eval Message6=mvindex(MessageC,6) | eval Message6=split(Message6,"=") | eval Engine_Ver=mvindex(Message6,1) | eval Message7=mvindex(MessageC,7) | eval Message8=mvindex(MessageC,8) | eval Message8=split(Message8,"=") | eval PLine_ID=mvindex(Message8,1) | eval Message9=mvindex(MessageC,9) | eval Message9=split(Message9,"=") | eval Command_Name=mvindex(Message9,1) | eval Message10=mvindex(MessageC,10) | eval Message10=split(Message10,"=") | eval Command_Type=mvindex(Message10,1) | eval Message11=mvindex(MessageC,11) | eval Message11=split(Message11,"=") | eval Script_Name=mvindex(Message11,1) | eval Message12=mvindex(MessageC,12) | eval Message12=split(Message12,"=") | eval Command_Path=mvindex(Message12,1) | eval Message13=mvindex(MessageC,13) | eval Message13=split(Message13,"=") | eval Command_Line=mvindex(Message13,1) | table _time, host, ComputerName, TaskCategory, EventCode, Message, PS_Ver, Engine_Ver, PLine_ID, Command_Name, Command_Type, Script_Name, Command_Path, Command_Line

I split my raw logs versus using RegEx as they are more readable in the future and by others. Powershell logs use a strange end of line carriage return, so another Splunk Ninja Tip on parsing Splunk Logs.

Use SplunkStorm for FREE and test it out!!

Happy PowerLogging!!!

#InfoSec #HackerHurricanel