Last Updated: 2013-03-20 18:41:52 UTC
by Kevin Liston (Version: 1)
The morning has brought a lot of links pointing to a number of different computer security incidents coming out of South Korea. It certainly sounds like the end of the world if you lump all together and attribute them to a single actor. However I don't think that is case.
Sifting through them I can tease out what appear to be 4 different threads to the story. In no particular order I have seen:
- A reported DDoS that hasn't identified the targets, or when it started or when it ended or what the impact was.
- Kaspersky reports of some web defacements here: http://www.securelist.com/en/blog/208194183/South_Korean_Whois_Team_attacks
- There were some news sites that were defaced to redirect visitors to install some banking malware that targeted Korean banks: http://blog.avast.com/2013/03/19/analysis-of-chinese-attack-against-korean-banks/
- There's reports that a lot of machines had their hard drives wiped and analysis was released today: http://training.nshc.net/KOR/Document/virus/2-20130320_320CyberTerrorIncidentResponseReportbyRedAlert.pdf
I'd like to urge readers to not link these 4 events together without additional analysis. Kaspersky linked the defacement with the wiper malware, despite this same warning being present in the news article that they linked to (I still heart you guys though.) The timelines on these events are still not clear, and the methods indicate different actors and motivations to me.
Last Updated: 2013-03-20 13:07:02 UTC
by Mark Baggett (Version: 1)
This is my third post in a series called “Wipe the Drive – Stealthy Malware Persistence” . The goal is to demonstrate obscure configuration changes that malware or an attacker on your computer can leave behind to allow them to reinfect your machine. Hopefully this will give you a few more arrows in your quiver during the next incident when you say “we need to wipe the drive” and they say “don’t waste my time”. We will pick up the conversation with techniques number five and six. If you missed the first four techniques you can read about those here:
TECHNIQUE #4 - Service Triggers based on ETW
Everyone knows to check for strange services running on your computer. If the service is running then the malware will be in memory during a forensic examination. So simply installing a service doesn’t really seem like a stealthy way to leave malware behind. But when you combine it with Event Tracing for Windows (ETW) triggers they can be very stealthy.
Windows Event Trace Providers generate a wealth of information about what is happening on your computer. They are similar to events that show up in your event logs, but they don’t show up in your event logs. You can turn on logging to see what types of events are being generated from a given provider. This can be used for good :
Or it can be used for evil (well.. penetration testing isn’t evil, but you get the point):
The events generated by event providers can be used to create “service triggers”. The triggers in turn start and stop services when predetermined events occur on the machine. So services containing malware can start and stop in very interesting scenarios. For example, attacker’s malware can lie dormant until a given DNS host name is resolved by the WinInet provider. When the attacker is ready to 0wn you they simply cause your host to resolve that hostname using a link to a webpage an image tag in an HTML document. Or the attacker could make the malware network aware so that it is running when connected to your domain but disabled when you unplug it from the network. Another interesting scenario would be to have the malware lie dormant until an event is registered indicating that a given wireless access point is in range. When the attacker wants to start his malware service he brings a laptop beaconing that wireless SSID within wireless range to activate it.
You can query the triggers on a given service by running “sc qtriggerinfo <service name>”. Here you can see the trigger for the Windows Usermode Driver Framework service. It has a custom trigger event that fires based on some event tracing for windows provider. The sequence of bytes defined below in the “DATA” element must be present in the event to activate the trigger.
However, determining good from evil isn’t that easy. Check out the trigger above. Is that a good trigger configuration? Is that the right data string? Who knows? In this case it is a default installation of Windows 7 so I hope it is good. The easy way to know if is right is to have a known good baseline of what your computer is supposed to look like and then detect changes. Do you want a baseline of triggers used on your systems? Here is a little for loop that will print all the services on your machine.
for /F "tokens=1,2 delims=:" %x in ('sc query ^| find "SERVICE_NAME"') do @echo %y & @sc qtriggerinfo %y
Technique #5 - Attach a debugger with ImageFileExecutionOptions
The operating system can be configured to automatically start a debugger every time a given application is launched. To set this up you simply create a registry key and windows will take care of the rest. So if I want to launch calculator every time someone tries to run notepad.exe it is one simple registry key. Give this a try. Use the following reg command to create a debugger key for notepad.exe.
reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options otepad.exe" /v Debugger /t REG_SZ /d c:Windowssystem32calc.exe
That’s it! Now when you try to launch notepad calculator is launched instead. Notepad never even starts. Only calc.exe is run. Notepad would start if calc.exe was an actual debugger. Users might notice the wrong processes running. The attacker can solve this by putting debugger functionality into their code. Or after the malware starts it can delete the Debugger key and relaunch the original process so it starts normally.
While this is a cool trick, by itself it doesn’t solve the attacker’s immediate problem. They want to lie dormant until incident response is finished. To do that they can attach the debugger to any infrequently run programs, such as the defrag process. On a server they might connect the debugger to Internet Explorer or another process that isn’t used very often. Then the attacker just sits back and waits for you to retrigger the infection of your machine.
If you see a “Debugger” option under anything in the "Image File Execution Options" registry key you investigate that debugger. Here we can see the debugger attached to notepad.exe using the “reg query” command:
To delete the debugger you can use the following command.
reg delete "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options otepad.exe”
Summary: Once a compromise has occurred finding all of the things the attacker could have done to your machine is usually more time consuming than just wiping the drive. Just wipe the drive. Still not convinced? I have a one part in this series to go.
Follow me on twitter : @MarkBaggett
Here is an AWESOME DEAL on some SANS training. Join Justin Searle and I for SANS new SEC573 Python for Penetration Testers course at SANSFire June 17-21. It is a BETA so the course is 50% off! Sign up today!
There are two opprotunities to join Jake Williams (Twitter @malwarejake ) for FOR610 Reverse Engineering Malware. Join him on vLive with Lenny Zeltser or at the Digital Forensics & Incident Response Summit in Austin.
vLive with Jake and Lenny begins March 28th, 2013:
Jake at DFIR Austin Texas July 11-15, 2013: