ScaryBear Software

Jake Williams: How many of you guys are government employees or card-carrying members of the infamous CatCard? Yeah, it’s cool – I wouldn’t raise my hand either. So, one of the emails that we got – this is really interesting – actually involved some of the CatCard reader software installed on the “Golden Images” all around some US Government organizations. And so, what turns out is when you put your card in, then it launches the program to handle it. Program.exe then not only executes at some time in the future, but at some time that we can social-engineer in the future. Maybe we social-engineer the user of the machine that we’ve left program.exe on, say: “Hey, do something that would require you to insert your CatCard at this point.” Or maybe they’ll just insert their CatCard to log on – and then again we’re right back in business: when it launches, their credentials can be stolen.

So, the third technique we’re going to talk about is ImageFileExecutionOptions. Microsoft figured out a while ago thatthey would need potentially to allow users to set different execution options on a per-executable basis. This is controlled by the executable that has actually been launched, so we can set up, say, for notepad.exe and attach it to a process that we know is going to run, something maybe that we know runs periodically, like defrag.exe. You know that’s going to run relatively weekly, depending on your system. And we can specify debugger option in ImageFileExecutionOptions. And now that malware kicks off every time defrag.exe kicks off.

 So, picture the scenario here: we’ve got our incident responder who doesn’t take our advice, doesn’t wipe the drive, says: “Hey, I want to give Jake repeat business by the hour.” A week later, defrag.exe kicks off, launching our secondary malware that checks for a primary and re-infects the box. So we can attach it to any infrequently executed process, and maybe it’s something we social-engineer the admin to run as well that’s supposed to be periodically executed.

Mark Baggett: Alright, scheduled tasks. You guys know about scheduled tasks, right? We can take some date, time in the future and we’re going to launch a given process. You probably also know that you can take events that are showing up in the Windows event log, and you can associated tasks to occur when those things fire. That’s fun!

How about this? Inside of a domain, all of the backup service accounts are distributed across machines; usernames and passwords are hard-coded on those machines. I create a scheduled task on the domain controller that, when there’s a failed logon attempt by the backup service account (whatever software you might be using), then we’re going to fire off a process that perhaps creates a new domain admin. (Slide 17) You can manually clean up the infection – you didn’t wipe the drive, you just ran your antivirus software, but these scheduled tasks are left behind. At some point in the future, when I want to get back on the system – net use, hosts, username, backup account, password, incorrect password – it triggers a failed login attempt by the backup account, which never occurs under normal circumstances; fires off my malware – and I get re-infected. Or we need to do it remotely. How many people have RTP services available through your firewalls? Alright, you’re all lying, okay.

EXAMPLES OF INTERESTING TASKS

◦ Event based on backup Login failure: SCHTASKS /Create/TN OnBackupFailure /TR calc.exe /SC ONEVENT /EC System/MO *[System[(EventID=4776) and Security[@UserID=’S-1-5-
21-3621276321-2740821412-689634120-1001′]]]
◦ SCHTASKS /Create /TN OnGoogleRequest /TR calc.exe /SCONEVENT /EC System /MO
*[EventData[Data[@Name=’Domain’]=’google.com’]]

Some references:
◦ http://blogs.msdn.com/b/davethompson/archive/2011/10/25/running-ascheduled-
task-after-another.aspx
◦ http://blogs.technet.com/b/askds/archive/2011/09/26/advanced-xmlfiltering-
in-the-windows-event-viewer.aspx

 Jake Williams: It’s something that’s neat because we don’t have to tie it, from the RTP standpoint, to the actual account name that’s being logged out. But we can do even something a little more creative. As we all know from the RTP logs, it chooses the hostname that you’re doing the RTP from. We can tie it to that as well.

Mark Baggett: The custom options in there allow you to define XPaths, where you can define filters on a data element. So, things such as a given hostname showing up in the event log can be used to trigger your malware.

 I did a post on PaulDotCom about 6 months ago on how to use event tracing for Windows to steal SSL cookies, SSL usernames and passwords out of event logs on systems. So, basically on the Windows operating system you have about 650 different event trace providers. These are providers that generate event logs, but they’re not event logs that show up in the event viewer. They are just logs elsewhere in the system.

You can associate or you can define a service trigger that, based upon any one of those events, you can have it fire off a service, so you can start your services. This is how Windows operating system does things like starting the TCP stack whenever a network is present. And there are thousands and thousands of options when it comes to defining these event triggers and the things that are logged in there. I think there’s a lot of options for this, where a lot of interesting things can be done, such as when a given USB device is on a machine you can fire off a service.

How about these?  When a given hostname is resolved, when a browser goes to a specific web page, or when I email in an HTML document that has an image tag that goes off to a specified domain – whenever I see that domain name showing up in the logs from one of these even trace providers – fire off my malware. Or perhaps it’s based upon the physical presence of a physical network, so when the device is plugged in to a given SCADA network or plugged in to a separated business segment, then we fire off the executables. Or perhaps when it’s removed from the business network, to prevent forensics from occurring we fire off the malware there.

 I also like the option of doing it based upon wireless networks. So, the malware fires in the presence of a specific SSID; so they removed your malware from the system – and at a later point in time when you want to re-infect the organization you just come into range of the machines that have these even trace provider monitors that will fire off the malware because your wireless access point is now within range they detected and they launched the malware. Or you can even do this with a bring-your-own device: infect a machine at home; when the machine at home is brought into the presence of the business network, then it fires off the malware.

Previous: Wipe the Drive Dude! Techniques for Malware Persistence. Part 1.
Next: Techniques for Malware Persistence. Part 3.