If you want to keep up on the updates of Malware Reports, Training, our Cheat Sheets and other updates, add our site to your favorite RSS Reader.
More Malware Analysis Reports added
A couple more reports have been added to help you with Malware Management. Malware Management can help you understand and know WHERE to look and WHAT to look for when it comes to a possibly infected system. You can read about Malware Management here:
You can find the updated Malware Analysis reports here:
Also updated was the "Windows Splunk Logging Cheat Sheet" to expand on the Windows commands abused by hackers. You can get the Cheat Sheets here:
And you can read a blog entry about Windows commands abused by hackers over at HackerHurricane.com:
New for 2016, 2 new Cheat Sheets and an update
Happy New Year everyone!
We have added two new cheat sheets and an update to the "Windows Logging Cheat Sheet" to kick off the new year!
Introducing:
To continue our efforts in providing the community with information that can help people improve their logging capabilities, thus improving their overall security posture, we have released these two new cheat sheets focused on getting people started with file and registry auditing.
Why do file and registry auditing? Because there are common locations you can audit that will catch the bulk of commodity malware and many advanced malware artifacts. By configuring strategic auditing on key file directories and autorun registry locations, you can catch file drops as they happen and registry keys used to launch the malware.
Take the Dec 2015 Dridex malware variant where the malware created a file and registry entry when the system shutdown or was rebooted. How would you detect this type of infection when the malware is only in memory while the system is running? File auditing on the %AppData% or AppData\Roaming directory would catch the malware being written back to disk and the launching command in the HKCU Run key on reboot or shutdown and again being deleted on startup. You do not have to audit the entire disk or registry to do effective auditing, just key places that are known to be used in commodity and more advanced malware. Practice Malware Management to improve and expand your auditing rules.
Read more on the Dec Dridex malware on Michael's HackerHurricane blog here:
Read more on Malware Management here:
Auditing does not have to eat up your log management license because well tuned auditing adds very little to the logs. Event ID's 4663 (file) and 4657 (registry) are what will be added to the logs when auditing is used. Of course, tweak your auditing rules to only collect what you need and remove unnecessary locations. You should increase your local maximum Security log size to 1GB in order to collect enough events before the logs rotate, shooting for roughly 7 days of logs or more to be stored locally.
To refine your file and registry logging, use LOG-MD to evaluate what is being collected and tweak the auditing to reduce noisy folders, files and keys and collect only what is important to monitor security wise. LOG-MD may be fond here:
DNS Issues at our Registrar service provider solved
The DNS issue should now be resolved. You may now get to Log-MD.com
DNS Issues at our Registrar service provider ;-/
Technology has its bugs and we are no different. Our service provider is having DNS issues and Log-MD.com is not properly forwarding. We are aware of the issue and have opened up a Help request with them. Hopefully it will be resolved soon.
Malware Discovery and Basic Malware Analysis Training
Do you want to know how to find malware? Improve your malware hunting skills? Learn from those that have had to deal with the worst kind of malware?
Austin, TX. Oct 5-6, 2015
Round Rock Wingate Conference Center (BSides Austin location)
Malware Discovery is an essential skill for today’s InfoSec and IT professionals. Many malware courses start you off with an infected system and how to deep analyze or even reverse engineer the malware.
This course focuses on how to discover if a system has malware and then how to do basic malware analysis and build a simple lab to do testing in. The goal being speed so you can get back to other tasks. We will look at what tools you need, the techniques and steps to analyze malware so you can determine if a system is clean or truly infected.
This course is intended for everyday commodity malware that you might get in email or surfing, to advanced malware in a targeted attack. The focus will be on Windows systems; but will touch on some tools for Apple and Linux systems as well.
Cost:
- $199 per person
- $99 for ISSA, OWASP & InfraGard members with discount code
Course Requirements:
Bare Bones system running Windows
Laptop running a Virtual Machine (VirtualBox, VMWare, Parallels, etc.)
Guest VM Running Windows7 or later
A list of tools will be provided on DVD day of the training or can be downloaded from Malware Archaeology the week of the training.
Malware samples will be provided
A Cloud Server for infecting is optional
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:
- Advanced Auditing enabled (Win 7 and Win 2008 and later)
- Command Line logging registry hack applied
- Process Create - Success
- 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
Laziok malware uses same ol infection locations %AppData%
Symantec released some information on a malware affecting the Energy industry. There is nothing new about this malware as far as where is is found. It places files in the %AppData% directory with a random name like "azioklmpx" and then uses Windows system names for the malware. See the excerpt from the Symantec article below.
If you practice Malware Management then you would already be watching this location for new executables. Notably executables that look and are named like typical Windows executables. These names are NOT normal in the User space of AppData.
Infection
The Trojan hides itself in the %SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle directory, making new folders and renaming itself with well-known file names such as:
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\search.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\ati.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\lsass.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\smss.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\admin.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\key.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\taskmgr.exe
%SystemDrive%\Documents and Settings\All Users\Application Data\System\Oracle\azioklmpx\chrome.exe
Happy Hunting
@HackerHurricane