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:

• Labofapenetrationtester - Week of PowerShell Shells

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:

• PowerShell Logging - Post
• Command Line Logging - Ask a Malware Archaeologist - Presentation
• Enable and Configure your logs - The Windows Logging Cheat Sheet

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

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.

• Video of the Card Key exploiting a pair of gates
• Paul's Security Weekly Podcast Episode 388
• Original Blog post on the exploit

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