Event, Event on the wall, who’s the fairest of them all? Part 2

May 30, 2019 in threat hunting

In part 1 I highlighted possible unexplored areas where we can look for additional interesting Events. Programmatic access to Event Log templates that Brian pointed me to makes these analysis even more straightforward (and desirable!).

Let’s start with the bad news first.

After exporting all the unique field names on Windows 10 I realized there are over 600 unique items across all these available templates. That’s a lot. Hard to find common denominator between all of them.

These fields will be most likely localized (not sure if they finally fixed it in new versions of Windows, or plan to, because it’s a major pain in the neck).

Also, if you study the output file (generated via the powershell bit shared in the part 1) you will notice that these templates exist in different versions, hence some of the fields will not always be available in the logs we have. It makes ingestion of these logs a bit more problematic too (parsers need to cater for different versions). Plus, your queries will have to take it into account as well.

  • 4688 version 0
  • 4688 version 1
  • 4688 Version 2

Finally, there is a long way for these field names to be delivered to your log aggregation system in a way they were originally named. It is almost for granted that these fields will be named differently than in these original templates (e.g. AccountName will become AcctName, acct, useraccount, etc.). Hence, you need to dig up the actual field names used by your log aggregation system and match them against templates. If you are only just starting to use a log aggregation system pay attention and influence the decisions that will ensure these fields are named the same way as in the templates, wherever possible!

Last, but not least – not all of these events will be set up (won’t be logged), not all of them will be properly forwarded even if logged, not all of them will be delivered in an unified way across all the systems. This means constant battle to ensure we audit our log sources to confirm that we still ‘see’ things, and on all the assets we want.

For the better news.

In my previous post I mentioned Event IDs that include references to process names. These process names not always mean exactly the same thing (sometimes it’s a full file path, sometimes a DLL name, or a component name), but we at least kinda know what to expect:

  • CallerProcessName
  • LogonProcessName
  • NewProcessName
  • ParentProcessName
  • ProcessName
  • TargetProcessName

With that info we can very quickly sift through our data and see what useful events we can find. From there, it’s not far to actual alerts and dashboards.

Here’s an example SPL query for statistics of events that include process name one way or another:

EvID=4611 OR EvID=4615 OR EvID=4616 OR EvID=4624 OR EvID=4625 OR EvID=4648 OR
EvID=4649 OR EvID=4656 OR EvID=4657 OR EvID=4658 OR EvID=4660 OR EvID=4661 OR
EvID=4663 OR EvID=4670 OR EvID=4673 OR EvID=4674 OR EvID=4688 OR EvID=4689 OR
EvID=4696 OR EvID=4703 OR EvID=4798 OR EvID=4799 OR EvID=4818 OR EvID=4904 OR
EvID=4905 OR EvID=4907 OR EvID=4911 OR EvID=4913 OR EvID=4985 OR EvID=5039 OR
EvID=5050 OR EvID=5051 OR EvID=5712 OR EvID=6417 OR EvID=6418
| stats count by EvID

We can also look at top 100 events:

EvID=4611 OR EvID=4615 OR EvID=4616 OR EvID=4624 OR EvID=4625 OR EvID=4648 OR EvID=4649 OR EvID=4656 OR EvID=4657 OR EvID=4658 OR EvID=4660 OR EvID=4661 OR EvID=4663 OR EvID=4670 OR EvID=4673 OR EvID=4674 OR EvID=4688 OR EvID=4689 OR EvID=4696 OR EvID=4703 OR EvID=4798 OR EvID=4799 OR EvID=4818 OR EvID=4904 OR EvID=4905 OR EvID=4907 OR EvID=4911 OR EvID=4913 OR EvID=4985 OR EvID=5039 OR
EvID=5050 OR EvID=5051 OR EvID=5712 OR EvID=6417 OR EvID=6418
| fillnull=”” CallerProcessName, LogonProcessName, NewProcessName,
ParentProcessName, ProcessName, TargetProcessName
| head 100
| table _time, EvID, CallerProcessName, LogonProcessName, NewProcessName,
ParentProcessName, ProcessName, TargetProcessName

As you run it in e.g. Splunk (Verbose mode), you can start adding additional fields that show up, and also remove Event IDs that are too noisy (put them on a side for more targeted analysis).

The goal is to find rare events for immediate alerts, noisy events, but with good filtering opportunities, and finally any others that can enrich our detections, even if just being simply present on a detailed timeline.

Here’s a list of other interesting field groups to play with:

  • Network IP/Addresses

ClientAddress, ClientIPAddress, DestAddress, IpAddress, IpAddresses, IpPort, IpProtocol, LocalAddress, NASIPv4Address, NASIPv6Address, PeerPrivateAddress, RemoteAddress, RemoteIpAddress, RemotePrivateAddress, SourceAddr, SourceAddress, SourcePort, TargetName, TargetServer, TargetServerName

  • Paths

HomePath, KeyFilePath, ObjectPath, ObjectVirtualPath, ProfilePath, ScriptPath, ShareLocalPath

  • Algorithms

AlgorithmName, CryptoAlgorithms

  • Status/Result

AuditStatusCode, EAPErrorCode, Error, ErrorCode, FailureCode, FailureReason, LoggingResult, QuarantineSystemHealthResult, ReplicationStatusCode, SecurityError, Status, StatusCode, SubStatus

  • Packages

AuthenticationPackageName, LmPackageName, NotificationPackageName, PackageName, SecurityPackageName

  • Dates/Timestamps

ClientCreationTime, Duration, ExpirationTime, LockoutDuration, MembershipExpirationTime, MMLifetime, NewDate, NewTime, PreviousDate, PreviousTime, ProcessCreationTime, QuarantineGraceTime, TGT Lifetime

Unfortunately, I don’t have a ready-to-use recipe for all the events extracted from templates (400+ IDs!). Some are obviously uninteresting, some are interesting, but not feasible to use due to volumes. Others could be very interesting, but legitimate software written in an old-school way is indirectly abusing them (e.g. requesting higher privileges than needed by default and this is immediately logged, often many times per minute).

Another thing is that even within a single Event there may be subgroups that we could focus on (e.g. trivial example with filtering by LogonType can narrow down logon events, but there is more).

Still, we can try to come up with some bundles of interesting events:

Code Integrity related:

  • 5038 Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized
  • 6281 Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without
  • 6410 Code integrity determined that a file does not meet the security requirements to load into a process.

Attack-related:

  • 4618 A monitored security event pattern has occurred.
  • 4649 A replay attack was detected.
  • 4961 IPsec dropped an inbound packet that failed a replay check. If this problem persists, it could indicate a replay attack
  • 5148 The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack
  • 5149 The DoS attack has subsided and normal processing is being resumed.
  • 5479 The IPsec Policy Agent service was stopped. Stopping this service can put the computer at greater risk of network attack expose the computer to potential security risks.

Policy-violation related:

  • 6423 The installation of this device is forbidden by system policy.
  • 6424 The installation of this device was allowed, after having previously been forbidden by policy.

Other possibly interesting:

  • 4793 The Password Policy Checking API was called.
  • 4612 Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits.
  • 4695 Unprotection of auditable protected data was attempted.
  • 4793 The Password Policy Checking API was called.
  • 4797 An attempt was made to query the existence of a blank password for an account.
  • 4864 A namespace collision was detected.

And as I am finishing this post I am really curious if anyone has ever attempted to build flowcharts that would map Event IDs to actual lifecycle of activities happening on Windows. While some events are atomic (e.g. system time change), many of events are clustered together around the lifecycle of network, system, logon, services, accounts, groups, tickets, policies, certificates, etc. events.

Finally, one thing that makes for an interesting observation: grepping the templates for words like ‘virus’, ‘malware’, ‘threat’ I find nothing. This confirms that the primary role of Windows Events is not supporting threat hunting activities. While we all suffer and complain about the noise they generate, let’s be grateful that they are out there.

Share this :)

Comments are closed.