Free Driver Laptop

Goin huntin

Goin huntin

I ran across this write-up on W32.Brambul recently, and as I often do when I see this sort of thing, I thought about how one might go about trying to find this within an infrastructure, from an endpoint perspective.  After all, this is the perspective that most of the "threat intelligence" that we see tends to leave out.

The most obvious indicator would be failed login attempts within the Security Event Log of target systems, and possibly account lockouts.  Youd see this sort of indicator either via the SIEM youre using, or if you were proactively hunting within the domain.

As something of a side note, I mentioned Ryans (of Tanium) presentation at the HTCIA2015 conference a bit ago, where he discussed "hunting in the dark".  I thought it was a really good presentation as he broke down how to get started.  Hunting in any infrastructure can be a bit overwhelming, but if you break your goal down into discrete, manageable steps, it can be easier to get started.  As Ryan recommends, starting small is key...you start eating the elephant one bite a time.  Looking at the enormity of an infrastructure can make things overwhelming, so start small.  Start with examining the contents of the Run key on systems, maybe starting with domain controllers and then once youve automated that, move to workstations.  Learn whats "normal" in your environment.  Then move on to the Windows Event Logs.  But the point is to not get overwhelmed by the apparent size and scope of the task, and to instead start working with what you have.

Okay.,.that said, well go back to the Brambul...

On the infected systems, looking in the Run key might be a place to start.  However, if the malware installs as a service, locating "Service Control Manager/7045" event records (there shouldnt be many) within the System Event Log would be the way to go.  If youre using a SIEM, and forwarding the right logs, you could search there, instead.  Or set a filter.  If you dont have a SIEM, you can use Powershell (MS has some good documentation available...) or WMI.

Something else that may occur on the infected systems is Security Auditing/4648 event records, indicating the use of explicit credentials.  This likely wont be definitive without further context, and to be honest, its not surprising that malware write-ups arent addressing this sort of indicator.

The key is that if youre going to "go huntin" within your infrastructure, what do you look for?  Do you look for malware, when the write-ups youre seeing all talk about how the folks writing this stuff are using high-speed techniques to ensure that the malware avoids detection and is hard to analyze?  Do you search for file hashes on systems?  Do you search for IP addresses in your logs?  Or do you go looking for indicators of behavior?

So, how is looking beyond low-level technical indicators (hashes, IP addresses) valuable?  Remember the Moker write-up?  This new APT reportedly includes anti-detection and anti-debugging techniques, allowing it to bypass detection.  Yet, it apparently persists via the Run key...so, if I just enumerate the values within this key and look for anything suspicious, such as a path that includes "C:ProgramData".  If I did that, and then correlated that information with a new user account being created on the system, would I then be able to determine that the system was infected with something?  And thats not so much a low-level technical indicator as it is moving closer to a behavior, something that may be anomalous within your infrastructure and indicate that something needs to be looked at a bit closer.

Heres another bit of malware that, according to some write-ups, may be associated with Brambul.  youll notice in the write-up that it states:

If it is successful in logging in, it will set the %System Root% as a network share named adnim. 

I added the emphasis, in order to draw your attention to the spelling of the share (I did a copy-paste and didnt try to retype that...).  If you were hunting in your environment, looking at the values beneath the LanmanServer/Shares key within the Registry might help you find this (or anything else that might be suspicious), particularly if you dont have auditing for Object Access/File Shares enabled.

Just for fun, I created a couple of shares using the "net share" command...one called "adnim" and one called "adnim$".  Both appeared as values beneath the LanmanServer/Shares key.  So rather than looking for file hashes on a system, we can start to correlate various indicators, based on time, and also develop context around what were seeing.  The name of the share may change, but if the malware continues to create a share, we know what to look for when were hunting.

Testing and Monitoring
If youre testing malware, doing dynamic analysis by running it in a VM (or on bare metal), something that I dont seen done very often is running it with monitoring tools such as SysMon or Carbon Black.

Why would anyone want to do this?  After all, who really cares what happens on the endpoint, right?  Not the malware RE and AV guys.  If youre protecting an infrastructure, or responding to a breach, you probably do care, because process creation monitoring is extremely valuable.

Heres an example...weve seen malware that persists via a particular key, and at one point that malware stopped using the API and instead used an embedded reg add command to maintain persistence.  Okay, so now, we have not only the persistence location, but we also have a command we can monitor for in order to perform detection much closer to the time of infection.  Or...and bear with me here...if you dont use reg.exe in your infrastructure, you can take steps to prevent it from being used, even by an account running with System-level privileges.

The same holds true for other processes.  Consider the malware described above that creates a share...how does it do this?  Via the API, included as part of the code, or via an embedded "net share" command?

Monitoring for this sort of activity within the infrastructure can give us a great deal more visibility into whats going on.  For example, if someone archives files (via WinRAR) and encrypts the archive, the process runs and completes, and the memory used if freed up for use by other processes.  However, if we monitor for process creation, we can capture that command line (along with the password used).  Process creation monitoring provides a great deal of insight into what the bad guys are doing, or are trying to do, and will illustrate behaviors.

go to link download download