Report All the Binary Code Executing on Your Network with Sysmon Event IDs

By Randy Franklin Smith

Computers do what they are told, whether good or bad. One of the best ways to detect intrusions is to recognize when computers are following bad instructions – whether in binary form or in some higher level scripting language. We’ll talk about scripting in the future, but in this article I want to focus on monitoring execution of binaries in the form of EXEs, DLLs and device drivers.

The Windows Security Log isn’t very strong in this area. Event ID 4688 tells you when a process is started and provides the name of the EXE – in current versions of Windows you thankfully get the full path – in older versions you only got the file name itself.  But even the full pathname isn’t enough. This is because that’s just the name of the file; the name doesn’t say anything about the contents of the file. And that’s what matters because when we see that c:\windows\notepad.exe ran how do we know if that was really the innocent notepad.exe that comes from Microsoft? It could be a completely different program altogether replaced by an intruder, or more in more sophisticated attacks, a modified version of notepad.exe that looks and behaves like notepad but also executes other malicious code.

Instead of just the name of the file we really need a hash of its contents. A hash is a relatively short, finite length mathematical digest of the bit stream of the file. Change one or more bits of the file and you get a different hash. (Alert readers will recognize that couldn’t really be true always – but in terms of probabilistic certainty, it’s more than good enough to be considered true.)

Unfortunately, the Security Log doesn’t record the hash of EXEs in Event ID 4688, and even if it did, that would only catch EXEs – what about DLLs and device drivers? The internal security teams at Microsoft recognized this need gap as well as some which apparently led to Mark Russinovich, et al, to write Sysmon. Sysmon is a small and efficient program you install on all endpoints that generates a number of important security events “missing” from the Windows Security Log.  In particular, sysmon logs:

  • Event ID 1 – for process creation (i.e. an EXE was started)
  • Event ID 6 – driver loaded
  • Event ID 7 – imaged loaded (i.e. an DLL was loaded)

Together these 3 events created a complete audit record of every binary file loaded (and likely executed) on a system where sysmon is installed.

But, in addition to covering DLLs and drivers, these events also provide the hash of the file contents at the time it was loaded.  For instance, the event below shows that Chrome.exe was executed and tells us that the SHA 256-bit hash was 6055A20CF7EC81843310AD37700FF67B2CF8CDE3DCE68D54BA42934177C10B57.

Process Create:

UtcTime: 2017-04-28 22:08:22.025

ProcessGuid: {a23eae89-bd56-5903-0000-0010e9d95e00}

ProcessId: 6228

Image: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

CommandLine: “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –type=utility –lang=en-US –no-sandbox –service-request-channel-token=F47498BBA884E523FA93E623C4569B94 –mojo-platform-channel-handle=3432 /prefetch:8

CurrentDirectory: C:\Program Files (x86)\Google\Chrome\Application\58.0.3029.81\

User: LAB\rsmith

LogonGuid: {a23eae89-b357-5903-0000-002005eb0700}

LogonId: 0x7EB05

TerminalSessionId: 1

IntegrityLevel: Medium

Hashes: SHA256=6055A20CF7EC81843310AD37700FF67B2CF8CDE3DCE68D54BA42934177C10B57

ParentProcessGuid: {a23eae89-bd28-5903-0000-00102f345d00}

ParentProcessId: 13220

ParentImage: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

ParentCommandLine: “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe”

Now, assuming we have the ability to analyze and remember hashes, we can detect whenever a new binary runs on our network.

Sysmon allows you to create include and exclude rules to control which binaries are logged and which hashes are computed based on an xml configuration file you supply sysmon at installation time or any time after with the /c command. Sysmon is easy to install remotely using Scheduled Tasks in Group Policy’s Preferences section. In our environment, we store our sysmon.xml file centrally and have our systems periodically reapply that configuration file in case it changes. Of course, be sure to carefully control permissions where you store that configuration file.

Just because you see a new hash – doesn’t necessarily mean that you’ve been hacked. Windows systems are constantly updated with Microsoft and 3rd party patches. One of the best ways to distinguish between legitimate patches and malicious file replacements is if you can regularly whitelist known programs from a systems patched early – such as patch testing systems.

Once sysmon is installed you need to collect the sysmon event log from each endpoint and then analyze those events – detecting new software. EventTracker is a great technology for accomplishing both of these tasks.

Can general purpose tools work for IT security?

This post got me thinking about a recent conversation I had with the CISO of a financial company. He commented on how quickly his team was able to instantiate a big data project with open source tools. He was of the view that such power could not be matched by IT security vendors who, in his opinion, charged too much money for demonstrably poorer performance.

The runaway success of the ELK stack has the DIY crowd energized. Why pay security vendors for specialist solutions when a “big data” project that we already have going on, based on this same stack, can work so much better, the thinking goes. And it’s free, of course.

What we know from 10+ years of rooting around in the security world is that solving the platform problem gets you about a quarter of the way to the security outcome. After that comes detection content, and then the skills to work the data plus the process discipline. Put another way, “Getting data into the data lake, easy. Getting value out of the data in the lake, not so much.”

In 2017, it is easier than ever to spin up an instance of ELK on premises or in the cloud and presume that success is at hand just because the platform is now available. Try using generic tools to solve the security problem and you will soon discover why security vendors have spent so much time writing rules and why service providers spend so much effort on process/procedure and recruitment/training.

Are you lowering your expectations to meet your SIEM performance?

It’s an old story. Admin meets SIEM. Admin falls in love with the demo provided by the SIEM vendor. Admin commits to a 3 year relationship with SIEM.

And now the daily grind. The SIEM requires attention, but the Admin is busy. Knowledge of what the SIEM needs in order to perform starts to dissipate from memory as the training period recedes in the past. Log volume constantly creeps up, adding to sluggishness.

Soon you are at a point where the SIEM could have theoretically performed but actually does not. It’s a mix of initial underestimation of hardware needs, increasing log volume, apathy and dissipation of knowledge about SIEM details.

How now?

In most implementations, this vicious cycle feeds on itself and the disillusionment reinforces itself. The SIEM is either abandoned or the user is resigned to poor performance.

What a revoltin’ development.

It doesn’t have to be this way, you know. Our SIEMphonic offerings were designed to address each of these problems. Don’t just buy a SIEM, get results!

Equifax’s enduring lesson — perfect protection is not practical

Recently Equifax, one of the big-three US credit bureaus, disclosed a major data breach. It affects 143 million individuals — mostly Americans, although data belonging to citizens of other countries, for the most part Canada and the United Kingdom, were also hit.

It’s known the data was stolen, not just exposed. Equifax disclosed it had detected unauthorized access. So this isn’t simply a case of potential compromise of data inadvertently exposed on the web. Someone came in and took it.

How the breach occurred remains publicly unknown, and Equifax has been close-mouthed about the details. But there’s considerable speculation online that the hackers exploited a patchable yet unpatched flaw in Equifax’s website.

Quartz suggests an Apache Struts vulnerability. Markets Insider says it’s unclear which vulnerability may have been exploited. The Apache Struts team has issued a statement which says: Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years. If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier. But this was actually not the case here –we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. What we saw here is common software engineering business –people write code for achieving a desired function, but may not be aware of undesired side-effects. Once this awareness is reached, we as well as hopefully all other library and framework maintainers put high efforts into removing the side-effects as soon as possible. It’s probably fair to say that we met this goal pretty well in case of CVE-2017-9805.

So where to turn? Is it reasonable to assume that Equifax should be rigorous in updating its systems, especially public facing ones with access to such valuable data? Yes, of course. But it frankly doesn’t matter what it was written in, how it was deployed, or whether it was up to date. How do you explain (apparently) no controls to monitor unusual activity? That’s dereliction of duty, in 2017.

Perfect protection is not practical, thus monitoring is necessary. Rinse and repeat, ad nauseam, it seems.

Looking for an expert set of eyes to monitor your assets? SIEMphonic can help. See what we’ve caught.

Three critical advantages of SIEMphonic Essentials

By now it’s accepted that SIEM is a foundational technology for both securing a network from threats as well as demonstrating regulatory compliance. This definition from Gartner says: Security information and event management (SIEM) technology supports threat detection and security incident response through the real-time collection and historical analysis of security events from a wide variety of event and contextual data sources. It also supports compliance reporting and incident investigation through analysis of historical data from these sources. The core capabilities of SIEM technology are a broad scope of event collection and the ability to correlate and analyze events across disparate sources.”

However, SIEM is not fit-and-forget technology, nor is it technically simple to implement and operate. In order to bring the benefits of SIEM technology to the small network, with a decade of experience behind us, we developed SIEMphonic Essentials to address the problems beyond mere technology. Here’s three specific advantages:

1) No hardware to procure or maintain

SIEMphonic Essentials is hosted in our Tier-1 data center freeing you from having to procure, maintain and upgrade server class hardware. Disk in particular is a challenge. Log data grows exponentially and while consumer disk cost is relatively inexpensive, the same cannot be said for business class disk cost.

2) More data? Fixed cost!

The hallmark of a successful SIEM implementation is growing volumes of data. Many SIEM solutions are priced based on log volume indexed or received (the so-called events per second). More data inevitably means more unforeseen cost. With SIEMphonic Essentials, you get simple t-shirt sizing (Small, Medium, Large) and you can leave both the cost and implementation of data storage to us.

3) Skill shortage

There is an African proverb that says, “It takes a village to raise a child.” In fact, it takes various skills to RUN and WATCH a SIEM solution. This specific problem is why many SIEM implementations become shelfware. Writing and tuning detection rules, performing incident investigations, and understanding how to search means that analysts need both security knowledge and specialized SIEM tool expertise. The IT Security space has zero unemployment, high staff acquisition costs and ongoing training costs. Buying a SIEM solution is easy. There are many providers and an end-of-quarter discount is always around the corner. Getting value from it? Not so much. With SIEMphonic Essentials, we start with a proper implementation (after all as Aristotle noted, well begun is half done) and then our 24/7 Security Operations Center escalates P1 events to your team.

SIEMphonic Essentials delivers visibility and detection across your enterprise. Not just technology…results!