Enrichment in Chronicle SIEM

In my previous article, I covered aliasing in Chronicle SIEM. In this post, I will discuss Enrichment, the process of adding additional data into a UDM event. I will also cover an exciting new UI update that now shows you enriched versus un-enriched UDM fields (below).

Chronicle SIEM now shows you enriched versus unenriched UDM fields, so you can quickly and easily see which fields have been enriched with additional data.

To recap on the TLDR summary from that prior post:

Aliasing

• Aliasing is the process of associating and linking together the different identities of an asset or user entity within a UDM event. For example, you could alias a user’s Windows login ID to their email address, or a user’s IP address to a hostname (or FQDN).

Enrichment

• Enrichment is the process of adding contextual data to a known entity. This data can come from either user-provided or Google Chronicle-provided context sources. For example, you could enrich an event with the user’s department from their Active Directory record, or the asset’s geographic location from Chronicle’s inbuilt Geo-IP enrichment.

Endpoint Detection & Response (EDR) Enrichment

The first type of enrichment in Chronicle SIEM that I’ll be covering is EDR enrichment.

Below is an example CrowdStrike log in its raw, original format. Notice that there are 18 lines, but the log itself doesn’t include a human-readable:

• user
• hostname
• process path
• hash value

An example CrowdStrike EDR raw log

However, if you look at the below UDM event associated with this CrowdStrike raw log, you will see that it includes 36 UDM fields, double the number of fields in the original log.

The UDM event also includes the following information that was not present in the original log:

• user
• hostname
• process path
• hash values

The Chronicle SIEM user interface conveniently displays Unenriched (U) and Enriched (E) fields, so you can easily see which values were parsed from the log and which fields were enriched by Chronicle SIEM.

An example of a Chronicle SIEM Enriched UDM Crowdstrike event

EDR enrichment in Chronicle SIEM provides analysts with access to complete UDM events. This means that analysts can search, detect, or pivot for specific processes, command lines, or hashes and get results for matching events, even if those events did not originally contain those specific fields in the raw log 🤯

Chronicle SIEM natively builds and maintains a mapping table for EDR process mapping. This means that no external source is required, and analysts can be confident that they are always working with complete events.

This powerful feature of Chronicle SIEM is not limited to just CrowdStrike. It also works with other EDR solutions within Chronicle, such as Carbon Black and Tanium.

Asset Enrichment

The next type of enrichment in Chronicle SIEM is asset enrichment. Below is an example of a web proxy log. Notice the limited information in the syslog message, including:

• IP addresses
• Port
• Protocol
• URL

An example original Web Proxy log

Let’s compare the original event to the enriched Asset UDM Event:

Asset enrichment uses aliasing and namespaces to identify the source IP address 10.166.0.3 as the asset win-dc-01. In this case, win-dc-01 is a Google Compute Engine (GCE) VM, so the enrichment includes additional context information from Google Cloud Asset Inventory (CAI), such as:

• Project name
• Region
• Zone
• VPC network
• Hardware information

The origin of the Asset enrichment can be viewed in Chronicle SIEM Asset View under the Entity tab.

The Asset context enrichment source details

Chronicle SIEM can enrich assets from a variety of sources, including Google Cloud Platform, Azure Active Directory, OKTA, and JAMF.

📝 Tip, while you can query an enriched value via UDM Search or Detection Engine, you can’t directly search Chronicle SIEM Views for aliased values unless they’ve been directly parsed from a raw log.

User Enrichment

User enrichment is similar to asset enrichment, but it focuses on people instead of machines.

Below is an example of a Google Cloud Platform cloud audit log, specifically a Chronicle SIEM data access log. While this is a richer log than the previous examples, it only contains one field from a user perspective: the principalSubject, which contains the user’s email address:

An example Chronicle SIEM audit log with one User identifying field

A single aliasing field, principal.user.email_addresses, can be used to enrich the following UDM events with information from a user context source, such as Google Cloud Identity (aka Google Workspace):

• First name
• Last name
• Display name
• Recovery email addresses
• Additional email addresses
• User ID
• User attributes

Additionally, common enrichment fields may include values such as:

• Department
• Manager
• Employee ID

A partial UDM event showing user enrichment from Cloud Identity

Chronicle SIEM can enrich users from a variety of sources, including Google Cloud Platform, Azure Active Directory, OKTA, Workday, and more. This enrichment provides analysts with additional context about users, such as their name, role, location, and group memberships.

Geo IP Enrichment

Chronicle SIEM includes Google’s own GeoIP enrichment. For more information, see blog post on the Google Cloud site.

An example of a UDM enriched event with Google’s GeoIP mapping

I will be covering the MISP Threat Intelligence Platform, in-depth, in an upcoming post; however, in the meantime, here is a quick example of how you can use MISP CTI to match against suspected malicious ASNs or domains.

An example attribute object within a MISP event

Using MISP Attributes in a UDM Search or Detection Engine rule is as simple as the example below. This example can detect accesses to ASNs from a known TIP event, with any log that includes an IP address automatically being enriched to include the ASN.

network.asn = "14061" or network.asn = "399629" or network.asn = "399629"

Virus Total Enrichment

If you are a Virus Total Enterprise customer you can use native VT file metadata enrichment. For more information, see this blog post on the Google Cloud site.

📝 Tip, this enrichment is particularly neat as you can start to take YARA rules and, in some cases, port them into YARA-L.

rule yara_Windows_API_Function {

  meta:
        author         = "InQuest Labs"
        description    = "This signature detects the presence of a number of Windows API functionality often seen within embedded executables. When this signature alerts on an executable, it is not an indication of malicious behavior. However, if seen firing in other file types, deeper investigation may be warranted."
        created_date   = "2022-03-15"
        updated_date   = "2022-03-15"
        blog_reference = "http://en.wikipedia.org/wiki/Windows_API"
        labs_reference = "https://labs.inquest.net/dfi/hash/f9b62b2aee5937e4d7f33f04f52ad5b05c4a1ccde6553e18909d2dc0cb595209"
        labs_pivot     = "N/A"
        samples        = "f9b62b2aee5937e4d7f33f04f52ad5b05c4a1ccde6553e18909d2dc0cb595209"


  events:
    $e.metadata.event_type = "FILE_CREATION"
    $e.target.file.sha256 = $file

    $e.target.file.pe_file.imports.functions = "LoadLibraryA" or
    $e.target.file.pe_file.imports.functions = "ShellExecuteA" or
    $e.target.file.pe_file.imports.functions = "GetProcAddress" or
    $e.target.file.pe_file.imports.functions = "GetVersionExA" or
    $e.target.file.pe_file.imports.functions = "GetModuleHandleA" or
    $e.target.file.pe_file.imports.functions = "OpenProcess" or
    $e.target.file.pe_file.imports.functions = "GetWindowsDirectoryA" or
    $e.target.file.pe_file.imports.functions = "lstrcatA" or
    $e.target.file.pe_file.imports.functions = "GetSystemDirectoryA" or
    $e.target.file.pe_file.imports.functions = "WriteFile" or
    $e.target.file.pe_file.imports.functions = "ReadFile" or
    $e.target.file.pe_file.imports.functions = "GetFileSize" or
    $e.target.file.pe_file.imports.functions = "CreateFileA" or
    $e.target.file.pe_file.imports.functions = "DeleteFileA" or
    $e.target.file.pe_file.imports.functions = "CreateProcessA" or
    $e.target.file.pe_file.imports.functions = "GetCurrentProcessId" or
    $e.target.file.pe_file.imports.functions = "RegOpenKeyExA" or
    $e.target.file.pe_file.imports.functions = "GetStartupInfoA" or
    $e.target.file.pe_file.imports.functions = "CreateServiceA" or
    $e.target.file.pe_file.imports.functions = "CopyFileA" or
    $e.target.file.pe_file.imports.functions = "GetModuleFileNameA" or
    $e.target.file.pe_file.imports.functions = "IsBadReadPtr" or
    $e.target.file.pe_file.imports.functions = "CreateFileW" or
    $e.target.file.pe_file.imports.functions = "SetFilePointer" or
    $e.target.file.pe_file.imports.functions = "VirtualAlloc" or
    $e.target.file.pe_file.imports.functions = "AdjustTokenPrivileges" or
    $e.target.file.pe_file.imports.functions = "CloseHandle" or
    $e.target.file.pe_file.imports.functions = "CreateFile" or
    $e.target.file.pe_file.imports.functions = "GetProcAddr" or
    $e.target.file.pe_file.imports.functions = "GetSystemDirectory" or
    $e.target.file.pe_file.imports.functions = "GetTempPath" or
    $e.target.file.pe_file.imports.functions = "GetWindowsDirectory" or
    $e.target.file.pe_file.imports.functions = "IsBadReadPtr" or
    $e.target.file.pe_file.imports.functions = "IsBadWritePtr" or
    $e.target.file.pe_file.imports.functions = "LoadLibrary" or
    $e.target.file.pe_file.imports.functions = "ReadFile" or
    $e.target.file.pe_file.imports.functions = "SetFilePointer" or
    $e.target.file.pe_file.imports.functions = "ShellExecute" or
    $e.target.file.pe_file.imports.functions = "UrlDownloadToFile" or
    $e.target.file.pe_file.imports.functions = "WinExec" or
    $e.target.file.pe_file.imports.functions = "WriteFile" or
    $e.target.file.pe_file.imports.functions = "StartServiceA" or
    $e.target.file.pe_file.imports.functions = "VirtualProtect"


    not $e.target.file.file_type = "FILE_TYPE_PE_DLL" and
    not $e.target.file.file_type = "FILE_TYPE_DOS_EXE"
    not $e.target.file.file_type = "FILE_TYPE_PE_EXE"    

  outcome:
    $risk_score = if($e.target.file.signature_info.sigcheck.verified != true, 50,0)
    $t_importFunctions = array_distinct($e.target.file.pe_file.imports.functions)
    $t_countImportFunctions = count_distinct($e.target.file.pe_file.imports.functions)

  condition:
    $e and $t_countImportFunctions > 1 and $risk_score >= 50
}

User Agent Enrichment

Not technically an enrichment, but a hidden gem: The ability to extract User Agent fields into greater depth is a powerful feature that is often overlooked. For more details on how to implement this, please see this previous post.

Summary

Finally, it is important to know that enrichment is applied against the following UDM objects only:

• Principal
• Src
• Target

Enrichment is not applied against all remaining UDM objects, specifically:

• Intermediary
• Observer
• About, including Security Result (Hashes, Emails)

The following UDM Nouns are not available for Context Enrichment:

• Network (email addresses)