Google Chronicle Security - Threat Detection & Hunting
Chronicle Security is a cloud service,
which is built as a specialized layer on the top of the Google infrastructure, designed for organizations to privately retain, analyze, and search the massive amounts of security and network logs or data they generate.
Chronicle receives the data and on that, it performs the following activities:
Normalizes
Indexes
Correlates, and analyzes the data to provide instant analysis and context on risky activity over the organization.
Chronicle also provides you the facility to examine the security information for your enterprise going back for months or longer. Use of Chronicle to search across all of the domains accessed within your enterprise. You can narrow your search to any specific asset, domain, or IP address to determine if it has been compromised.
The analytical capabilities and features of the Chronicle are provided to security professionals as a simple, browser-based application. Many of these capabilities and features can also be accessible programmatically through Read APIs. Chronicle gives analysts a way, when they see a potential threat, to determine what it is, what it’s doing, whether it matters, and how best to respond.
Chronicle features
Search
Raw Log Scan: Search your raw unparsed logs.
Regular Expressions: Search your raw unparsed logs by performing regular expressions over the query bar in the Chronicle UI.
Investigative views
Enterprise Insights: Displays the domains and assets most in need of investigation.
Asset view: Get Analysis of the assets within your enterprise and find out whether or not they have interacted with suspicious domains or malicious data.
IP Address view: Investigate specific IP addresses within your enterprise and what impact they have on your assets.
Hash view: Search for and investigate files based on their hash value.
Domain view: Investigate which domains are being accessed over the enterprise or organization. Based on that, get to know what impact such domains have on the enterprise.
User view: Investigate users within your enterprise who may have been impacted by security events.
Procedural filtering: Chronicle provides facility to filter out the asset by various parameters, including by event type, log source, network connection status, and Top Level Domain (TLD).
Detection Engine
You can use the Chronicle Detection Engine to automate the process of searching across your data for security issues.
You can specify rules to search all of your incoming data and notify you when potential and known threats appear in your enterprise.
Format of Logs
UDM events:(Unified Data Model)
Chronicle has its own format of representing the logs which are known by UDM events. Every unstructured log when ingested to the Chronicle platform, There are built-in parsers that convert them to the UDM events.
UDM events are a combination of key value pairs in the format JSON. Direct UDM events can also be prepared and ingested to the Chronicle platform. For reference on how to prepare UDM events, what are the types of UDM events and examples can follow the link. The following example illustrates how you would format a PROCESS_LAUNCH event using the Chronicle UDM syntax:
etadata { event_timestamp: "2020-01-01T13:27:41+00:00" event_type: PROCESS_LAUNCH vendor_name: "Microsoft" product_name: "Windows" } principal { hostname: "altostrat.com" } target { process { pid: "0xc45" file { full_path: "C:\\Windows\\regedit.exe" } } }
Unstructured Log
Chronicle also supports the ingestion of unstructured logs via various sources. This type of logs can be in any format from the below mentioned options:
CSV: Comma Separated Values
JSON: JavaScript Object Notation
SYSLOG: syslog formatted message
KV: key-value pair
XML: Extensible Markup Language
SYSLOG + KV: syslog header with key-value body.
SYSLOG + JSON: syslog header with key value body.
SYSLOG + XML: syslog header with XML body.
LEEF: Log Event Extended Format
CEF: Common Event Format
Chronicle has built various log_types into which the logs ingested to the Chronicle are categorized. The categories of the log types can be obtained over the link. When the logs are ingested to the Chronicle they are converted to a format called UDM(Unified Defined Events) events through the parsers that are built by the Chronicle. The parser passes the logs through it and as per the definition of it the logs are converted to specific key value pairs in UDM format. To know more about the supported parsers by the Chronicle.
Chronicle Ingestion API
The Chronicle supports ingestion of the unstructured or UDM events through it’s API built. The API can be called with the request type in the proper format and the data is ingested to the Chronicle.
For the reference on how to ingest the logs over the API and format supported, click here to learn more.
Use Cases
Phishing Attack
What is a phishing attack?
Phishing attacks are the practice of sending fraudulent communications or data by making it appear from a reputable source. It is usually performed through email. The goal of such activity is to steal sensitive information like credit card and login data or to install malware on the victim’s machine.
For simulating phishing attacks on Chronicle, we have tried a use-case by ingesting logs of Web Proxy and DNS type of logs.
Exploring Attack:
1. We’ve been targeted by a Phishing campaign! An employee has reported funchill.com as suspicious.
2. There are two distinct assets (crest_demo_4 and crest_demo_6) that have accessed the domain. And Mar31 was the date when the listed assets first accessed the domain.
3. There were 2 assets that sent POST requests to /login.php.
4. Now click on the IP link shown in the Resolved IP section, then select Continue.
5. This confirms the IP address has not only resolved to funchill.com but also “alsoknowsit.com”, “potvaporizer.com”
Betty Decaro Attack
What is the attack?
Here we try to simulate an attack that says that a malicious file or content was received and the content has been accessed. At first, a UDM event is ingested, which shows the login activity of the user. For simulating the attack on chronicle, we have tried a use-case by ingesting logs of Web Proxy and Tanium Stream types of logs.
Exploring Attack:
1. First, go to the Enterprise insights section. An alert for the user “alice” and assetname “crest_demo_system3” is raised which states malicious activity.
2. On click of “crest_demo_system3”, you can view the prevalence graph of it. Here you will be able to see that the user is accessing domains at intervals. You can filter the prevalence of domains. The domains showing at high prevalence shows that the domains are common to Chronicle and you can see only one domain “manygoodnews.com” having prevalence to 1 which indicates new to Chronicle.
3. This is the sequential log view of the malicious activity.
4. A rule is written in the Rule Engine for detecting the logs. Under that using the YARA-L language, Chronicle rules are written, where we specify in the logs what values or specific action needs to be detected.
5. Tanium Stream event.
6. Web Proxy event.
User Login Attack
What is the attack?
The user tries to login to it’s system. And these logs are ingested to the Chronicle. This set of logs contains the combination of failure and success login. On weekdays the login events are ingested and it shows the valid login activities by the user. The location of the user is common and it represents the WINDOWS SIGN IN type. Also on the weekdays along with the Login activities, the organization information is also registered to the Chronicle.
On weekend the login events are ingested and it shows the invalid login activities by an anonymous user as the normal user does not try to login on weekend. The location of the user trying to login is unknown and it represents the Office 365 type. This indicates that there was a suspicious activity held on the weekend which was not normal.
For simulating the attack on Chronicle, we have tried a use-case by ingesting logs of Success and Failure Login UDM events and Azure/Windows Active Directory Context types of logs.
Exploring Attack:
1. Search for any particular user: in our case, it’s “alice”.
2. The below image shows the organizational information of the “alice” user. This log will ingest on every weekday at 8:45 AM UTC.
3. The below image shows the user’s login events (successful and failure both) on weekdays during 9AM-6PM UTC.
4. The below image shows the login information of a user from unknown locations. The user failed a few times and after that succeeded.
That’s how the Chronicle analyzes the logs received and based on the analysis detects any suspicious activity or threat happening in the enterprise.
Also Read: Advanced Threat Hunting Harnessing Chronicle Backstory with Demisto
Author
BINOY OZA
Binoy Oza is a Senior Software Engineer working at Crest Data, with 3 years of experience in Software Development, he has successfully delivered projects in the area of E-Commerce, Management, Education, and Security domains. At Crest, Binoy works for the Security Analytics and Automation domain.