Derbycon 3 / 2013 presentation
Thanks to Adrian Crenshaw @irongeek_adc for getting this video posted so quick.
Reference to the rest of the Derbycon Videos.
Details and references from slides listed below.
Tony's twitter : https://twitter.com/Myne_us
Juan's twitter : https://twitter.com/kongo_86
We often perform pentests, vulnerability assessments, social engineering tests, and physical security but these test all miss 1 major form of attack, malware. The concept here is to introduce a different sort of test than we normally do right now.
So what is the difference between testing malware and doing something like a pentest? Some of the primary items are listed here.
--Persistence : most pentests deal with getting in and getting out and not persisting on a network. Malware more often than not will try to stick around to gather more data, propagate, or just lend itself to resources of the attacker.
--Kernel level attacks : A large portion of tests do not deal with planting itself into the kernel. Most pentests exist in memory which lends itself to it's own issues but does not replicate the type of actions malware would perform.
--No vulnerability needed : The majority of malware is coming in via phishing using email and browsers. A lot of these are not even attempting to take advantages of vulnerabilities but instead takes advantage of humans lack of knowledge in the space. This can be replicated to some degree in social engineering tests but malware has a wider spread on the number of techniques used than most SE testing platforms.
--Targets : A lot of times pentests want to try to compromise server to get at some company data. Malware may take this approach but a lot of malware such as banking trojans and bots are attacking people through the browser and taking control of things like bank accounts and trusted logins.
--Handling and Response : The way you handle a malware based infection could be very different than a hacker infiltrating your network. Malware is really good about getting itself planted in many ways on a system where most hacker types try to leave little footprints.
http://www.verizonenterprise.com/DBIR/2013/
https://www2.trustwave.com/2013GSR.html
http://upx.sourceforge.net/
https://www.lookout.com/resources/reports/state-of-mobile-security-2012
http://www.tenable.com/blog/detecting-known-malware-processes-using-nessus
These are the types of test we came up with. You may have more you could consider in your network but these where just the starter ones to consider.
One basic component of this is just training people how to deal with malware and the tools they would use to work with malware. Performing controlled test, reading some of the malware books such as malware analyst cookbook and doing the exercises or just taking live malware and doing analysis against it.
Egg hunting can allow you to setup a scenario in smaller controlled conditions and see if your staff can handle even some basic items. For example setup 3 boxes and infect one and see if they can detect what is infected.
This is a good way to perform future tests against up coming threats as well. Install the latest thread on one of the 3 boxes and then have your staff find out what it is, you can then determine how they found it and script that to fit a large scale environment.
Test your IR team to make sure they are reacting to malware correctly. I have seen many IR teams thought of malware response is to run AV or re-image. They treat malware more like hassle instead of a threat. This is a good way to make sure they are investigating infections and they are then working with them as they should.
This one is my personal favorite. Write a controlled specific piece of software that replicated malware like actions but is really benign. I give an example of this later in the talk.
The idea here is to infect a system on your live network with this controlled testing pseudo malware.
-- You can use this sort of test to see if your monitoring is working
-- Determine what tools do you have that are helping detect infection.
-- Give your people constantly something to look for. This could even get turned into an incentive based system where if someone finds the fake malware they get a gift card or day off or whatever management decides. Just never tell them when the test is going on so the thought of something being out there to find is always there.
Here I would like to introduce you to some techniques and places you can look into to start your testing. These are items that are typical of malware and can be replicated in ways that won't always be harmful or malicious.
Persistence is one of the core components of a piece of malware. If it can't persist it can't cont to steal information, money, or use your resources. There are some tools such as autoruns.exe you can use to find some of the most common locations to test but I have been able to find many many more locations to persist at.
Some testing ideas :
-- name a benign piece of software something like malware.exe and set it up in one of the persistence locations.
-- Build a browser extension that does something malicious. Firefox and Chrome are currently not monitored by any of the persistence detection programs like autoruns.exe, gmer, hijack this, or any of the other tools that do this. This is a way to persist that takes manual work to detect.
One major form of persistence is dll hijacking. This is a great persistence technique as long as you know a specific application you can use to leverage this technique.
http://securityxploded.com/dllhijackauditor.php
http://vimeo.com/14391242
Rootkits are a core component to malware. They allow attacker to take so much control over a system they can prevent you from even being able to see they are working in any form. This is something that is extremely hard to detect over a network and the longer it exists the harder it gets to detect because all markers of the infections start to just become part of the noise.
Developing a basic rootkit or using some source from one of the books shown here can allow you to refine detection techniques and understand how rootkits looks on a system.
Process Hollowing and Process Injection are ways to hide what is bad in something good. This is used very very often and setting up simple dll injection scenarios so you can find ways to identify infected processes would be a great place to look.
http://blog.spiderlabs.com/2011/05/analyzing-malware-hollow-processes.html
Most malware leaves behind footprints that are unique but hard to automate detection. You can replicate this kind of behavior without having to be malicious.
For example :
-- Create a running process tree that doesn't make sense. For example cmd.exe running under svchost.
-- Create odd names like xyxjz.exe. Malware will drop unique names to prevent AV from using just it's name as a detection technique. This leaves it harder for AV but easier for humans to determine this.
-- Create a processes with missing icons. Something may be named iexplorer but miss the internet explorer icon.
-- Create a process from something like %TEMP% directory. This shows a processes running from an odd directory location.
-- Create a process running from a weird session id. For example cmd.exe should not be running as sid 0 normally.
-- Create an application and compile it using the name malware.exe then rename it to something simple like services.exe. The original file name is detectable in some cases and can be a sign of a suspect application.
Malware will often try to normalize it's traffic to make it not too detectable by network based detection systems. Even though they try this it is hard to export data in some forms and just make it look like http. Also if it hard to talk to systems you are not supposed to and not look suspect.
Replicate suspect traffic
for example
-- Connect to an irc server and receive some off commands such as just integers or just one word communication.
-- Have cmd.exe start talking http to a place like dyndns
-- Have a system connect attempt to connect to you DC every 30 seconds with a random incorrect login.
Here are some simple locations that can replicate malware type attacks or are currently used in malware that you can use for testing.
Metasploit is a very obvious and supplies you with a large number of testing items in a simple format. You already have your command and control server, the metasploit engine, and payloads you can use as the infection.
I also want to mention SET here as well. I really should have included this in the slides as it has some phishing items that really help facilitate this type of test.
Use malware... There are a few good dumps of major malware kits. These are easy to find and have large amounts of code you can grab and use to build your own samples.
Do not strait copy and paste from these dumps, some may have backdoors.
RATS or Remote Administrative Tools are used by malware in any low end pieces of malware. You can use these but I would suggest against using them in live environments because of some of the risks.
This is really my highest suggestion. Develop your own test items. This might seem like something very hard to do and might be dismissed at start but I think here I can make a case why this is much easier than you expect.
-- You don't have to worry about evasion technique or some complicated controls. You are not developing malware, you are developing testing software that looks like malware.
-- You don't have to use something like ASM or C unless you are working on a rootkit. I have ran by many samples that are python compiled using py2exe, vbscript, powershell, c#
-- If you are a corporation you probably have programmers. Malware is just a program and your programmers might not know it but they can probably write a large portion of the malware out there. Instead of asking them to produce a piece of test malware ask them to do what you want it to do. For example say this...
"Can you write something for me that downloads a executable from a public site then drops it in X directorys. I want it to start on boot using this reg key or file location and then I would like for it to call these API calls. After a while can you have it send test this data to this server."
This is something that not only are you getting samples to test against but you also are getting another point of contact in your network for malware knowledge.
Books, a lot of the books listed above and in the previous locations have example code and knowledge you can use to perform these tests.
Juan and I (myne-us) have a little malware kit we are developing from scratch. This is something that helps our knowledge but also puts us in the seat of the malware developers to understand a lot of the challenges.
We are still not sure what we are going to do with this kit or what we will release.
When I was doing the talk at Derbycon I had someone ask me why I didn't want to release this public like a lot of other tools out there. I told them about some of my concerns with some AV bypass techniques and some code I am using that comes from fairly advanced techniques that could easily be used. I do want to add to this... I don't care what others do and I don't make my decisions based on if someone else would do it. Because of this we will make some decisions based on our look in on this and when we do we will try to make it useful but not harmful.
Eventually I would like to start a website that I can put some of these concepts as a total into. This takes time and that is what is really preventing me from getting it rolling now.
This is just a simple idea of something that you can use for testing. This is a good first step test that is not all that complicated and can be done in a short period of time.
One thing I would suggest in live tests is to try to replicate some infection vectors such as phishing, exploits, or something that allows it to get on a system. I would not spend a lot of time on this because this is what pentests and SE tests test but it if good to leave the footprint for detection purposes. Remember you want to improve your detection not just cause your staff to get mixed up.
Phishing email comes in
website is hosted on google sites and asks for JRE update. The download link leads to a dropbox download.
side note : This just shows that you can simply pack the payloads using CFF explorer's UPX packer option to help replicate the look of malware.
When the above "java updater.exe" ran it dropped a iexplorer.exe binary in TEMP.
It also setup for the binary to start on login using the standard
HKCU\SOFTWARE\MICROSOFT\CURRENTVERSION\RUN reg key
The iexplorer.exe binary itself replicates some actions of a piece of malware but does it in a benign way.
It starts a SetWindowsHookex() shim on the keyboard but never attempts to attach to any other process to sniff. It will just sniff the keyboard from the local processes leaving it useless but still replicating a keylogger.
It then every X seconds writes out to a file some data that looks like a keylogged session. For example a login to gmail, domain creds login, or some browser activity. It then sends this data up to a website. I just used my own when I developed this but you may want to send the data to some fast flux style DNS address.
Post any questions here in the comments and I will try to address them if possible.
Code from this talk will be posted after I do some cleanup and make sure there are no issues with what I am posting.
After I posted this a friend of mine linked me to a topic similar to this topic and shows some data points that are really interesting and a talk worth watching.
http://vimeo.com/31548167
https://www.isecpartners.com/media/12955/eip-final.pdf
