Session 13: Introduction to Blue Team

• Event Detection and Response Workflow
• Practical Example Scenario
• Event Processing Pipeline
• Agent-Based Log Collection
• Complete SIEM Workflow
• Indicators of Compromise
• Behavioral Analysis
• Rule Tuning and Intelligence
• Advanced Detection Rule Example
• Threat Framework Components
• Encoding and Obfuscation
• Query vs Rule Distinction
• Multi-Log Analysis Example
• SIEM Query Syntax

Event Detection and Response Workflow

Understanding the core components of security monitoring requires familiarity with key terminology. An event represents any action that occurs within the system. This action is recorded and stored as a log entry. The event rule defines the detection criteria that will be applied to these logs. When a rule is triggered, it generates an alert which serves as a notification to security analysts. The SIEM system performs continuous monitoring of all collected logs, while agents installed on endpoints are responsible for sending logs to the central SIEM platform. An incident refers to a bad event that requires investigation and response.

Practical Example Scenario

Consider a scenario where a browser accesses skidz.com. The login device is identified as omar.firas, and the user opens an application called sublime.exe. The primary application in use is chrome.exe, which navigates to the URL skidz.com. The server responds with response.code: 200, and the parameter being accessed is index. The detection rule can be written as: if app=chrome.exe AND URL=skidz.com, then trigger an alert.

Event Processing Pipeline

The complete flow of event processing follows this sequence: an event or action occurs, which gets recorded into a log. The log is then processed by applying predefined rules for detection. The detection engine produces a result, which generates an alert if the criteria are met.

Agent-Based Log Collection

Multiple devices equipped with agents send their logs to the central SIEM. For example, device.omar sends logs through its agent, device.semo sends logs through its agent, and device.firas sends logs through its agent. The SIEM system receives logs from various sources including firewalls, IDS, IPS, Windows systems, Linux systems, and servers. In a typical environment, you might be monitoring 90 or more different event sources.

Complete SIEM Workflow

The comprehensive workflow operates as follows: an event or action occurs and gets recorded as a log entry. Rules are applied to these logs for detection purposes. The detection result generates an alert, which is written to the SIEM platform. The SIEM receives logs from agents installed on devices, allowing security analysts to investigate and detect incidents effectively.

Indicators of Compromise

When investigating security incidents, analysts look for specific indicators of compromise. The attacker's IP address might be identified as 23.45.6.7. A malicious executable such as ddOl.exe can be identified by its hash value: ]]SLS7HEMK9267489ND029Y40300. The attacker's domain might be ggdff.xyz.

Behavioral Analysis

Behavioral indicators provide critical insight into attack patterns. For instance, mimi.exe might be observed interacting with lsass.exe, followed by an RDP connection to IP address 23.23.23.23. In such cases, the appropriate response would be to isolate the device immediately.

Rule Tuning and Intelligence

Rule tuning involves editing detection rules to reduce false positives and improve accuracy. The intelligence cycle follows a structured approach: analysis of information, which comes from processing raw data. This is often referred to as CTI or Cyber Threat Intelligence.

Advanced Detection Rule Example

A more complex rule might look like this: if (application: teams.exe AND file.type:.zip) OR (size >= 50mb), then trigger action: allow AND send email to manager. This rule demonstrates how multiple conditions can be combined to create sophisticated detection logic.

Threat Framework Components

Understanding adversary behavior requires knowledge of three key components. Tactics represent the goal or objective the attacker wants to achieve. Techniques describe the method used to accomplish that goal. Procedures provide the step by step execution details of how the technique is implemented.

Encoding and Obfuscation

Attackers often use multiple layers of encoding to hide malicious content. An example would be: frombase64(frombase64(frombase64(WkRKb2RsbFhNWEE9))). This demonstrates triple base64 encoding that must be decoded layer by layer.

Query vs Rule Distinction

Understanding the difference between queries and rules is fundamental to SIEM operation. Both use the same syntax within the SIEM platform. A query is used to search or filter data and is written manually inside the SIEM interface by analysts. A rule is designed for detection purposes and runs in the background, either in real time or on a scheduled basis.

Multi-Log Analysis Example

When analyzing multiple log entries, you need to identify patterns across different applications and response codes. Consider these log entries:

application: chrome.exe
URL: skidz.com
response.code: 200
parameter: index

application: edge.exe
URL: skidz.com
response.code: 400
parameter: index

application: duckduckgo.exe
URL: skidz.com
response.code: 200
parameter: index

application: tor.exe
URL: skidz.com
response.code: 400
parameter: index

All of these entries share common elements: URL: skidz.com, response.code varies between 200 and 400, and parameter: index remains consistent.

SIEM Query Syntax

When constructing queries in the SIEM, you need to specify the index and field values properly. For example: index=windows application: field:application value:skidz.com. Source IP addresses can appear in various field formats such as src_ip, srcip, or src.ip depending on the log source and SIEM platform being used.