### Corelight SMTP Log Data Example

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0001_Initial_Access/T1566.002_Spearphishing_Link.md

This example demonstrates the structure of the `smtp_links` and `smtp` logs generated by Corelight sensors. The `smtp_links` log contains information about links found in SMTP messages, while the `smtp` log provides details about the email itself. The `fuid` field in `smtp_links` links to the `fuids` or `uid` field in the `smtp` log, enabling correlation.

```text
path: smtp_links
fuid: FhahXA1eJ32gHvNP27
id.orig_h: 172.16.0.10
id.orig_p: 62345
id.resp_h: 10.0.1.10
id.resp_p: 25,
link: http://www.hamsterwaffle.com/dl.php?id=jimmydean37
uid: C62txO1FHoJFJpsgP1

path: smtp
from: Your Friend <Jeremy.Rigeur@gmail.com>
fuids: [ "FhahXA1eJ32gHvNP27" ]
mailfrom: attacker@fake-mail.com
rcptto: [ "victim@corp-mail.com" ]
subject: Click this link, please
to: [ "victim@corp-mail.com" ]
uid: C62txO1FHoJFJpsgP1
user_agent: Apple Mail (2.3608.80.23.2.2)
```

--------------------------------

### Convert Sigma Rules to Splunk Queries using Sigmac

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Demonstrates the process of converting Sigma rules into Splunk queries using the `sigmac` tool. This involves setting up a Python virtual environment, installing `sigmatools`, and then executing the conversion command with the appropriate configuration and target.

```bash
# Install sigmatools in Python virtual environment
python3 -m venv sigma-tools-venv
source sigma-tools-venv/bin/activate  # Linux/Mac
# ./sigma-tools-venv/bin/Activate.ps1  # Windows PowerShell
python3 -m pip install sigmatools

# Convert Sigma rule to Splunk query
sigmac --config splunk-corelight --target splunk T1133-inbound-rdp-from-internet.yml

# Example output (prepend with index specification):
index=corelight sourcetype=corelight_conn
  (dest_ip="10.*" OR dest_ip="192.168.*" OR dest_ip="172.16.*")
  service="*rdp*"
  NOT (src_ip="10.*" OR src_ip="192.168.*")
  NOT resp_bytes=0
| table id.orig_h id.resp_h id.resp_p service
```

--------------------------------

### Host and User Identification from Network Logs (Zeek/Bro)

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Illustrates how to identify hostnames and usernames from various Zeek logs such as dhcp.log, dns.log, kerberos.log, ntlm.log, rdp.log, and http.log. This is crucial for attributing network activity to specific entities.

```Zeek/Bro
# Hostname identification sources:

# dhcp.log - Host requesting DHCP lease
host_name: WORKSTATION01
domain: corp.local
assigned_addr: 192.168.1.100

# dns.log - DNS resolution records
query: workstation01.corp.local
answers: 192.168.1.100

# kerberos.log - Domain-joined devices (hostname ends with $)
client: WORKSTATION01$/CORP.LOCAL
id.orig_h: 192.168.1.100

# ntlm.log - NTLM authentication
server_dns_computer_name: DC01.corp.local
hostname: WORKSTATION01
id.orig_h: 192.168.1.100

# User identification sources:

# rdp.log - RDP sessions
cookie: jsmith
id.orig_h: 192.168.1.100

# kerberos.log - Kerberos authentication
client: jsmith/CORP.LOCAL
id.orig_h: 192.168.1.100

# ntlm.log - NTLM authentication
username: jsmith
id.orig_h: 192.168.1.100

# http.log - HTTP Basic Auth
username: jsmith
id.orig_h: 192.168.1.100
```

--------------------------------

### Corelight Log Structure and UID Linkage (Zeek/Bro)

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Demonstrates the structure of Corelight's conn.log and how the 'uid' field links to protocol-specific logs like http.log for deeper analysis. This is fundamental for correlating network session data.

```Zeek/Bro
# Core conn.log fields for session identification
id.orig_h    # Originator (source/client) IP address
id.orig_p    # Originator port
id.resp_h    # Responder (destination/server) IP address
id.resp_p    # Responder port
uid          # Unique identifier linking to protocol logs
service      # Detected application protocol (http, ssl, dns, etc.)
history      # TCP connection history flags
duration     # Connection duration
orig_bytes   # Bytes sent by originator
resp_bytes   # Bytes sent by responder

# Example: Pivot from conn.log to http.log using uid
# conn.log entry:
uid: CEeVS92Ljnr9jbW2J5
id.orig_h: 192.168.1.100
id.resp_h: 93.184.216.34
id.resp_p: 80
service: http

# Use uid to find corresponding http.log entry:
uid: CEeVS92Ljnr9jbW2J5
method: GET
host: example.com
uri: /malicious/payload.exe
user_agent: Mozilla/5.0
```

--------------------------------

### Detect HTTP Beaconing with Zeek Logs

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Hunt for suspicious HTTP patterns indicative of command and control beaconing. This involves analyzing HTTP logs to identify hosts and URIs with a high frequency of requests within a specific time bucket, suggesting automated callback behavior.

```zeek
# Hunt for suspicious HTTP patterns
# http.log query - Beaconing detection
id.orig_h: 192.168.1.100
GROUP BY: host, uri
COUNT: requests
TIME BUCKET: 5 minutes
# Look for regular intervals indicating automated callbacks
```

--------------------------------

### Analyze Software Log for Network Visibility (Zeek)

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0008_Lateral_Movement/T1021_Remote_Services.md

This snippet demonstrates how to use the 'software' log in Zeek to gain visibility into software present on the network. It helps in identifying unexpected or unauthorized servers, vulnerable services, and unpatched client software by providing details like software type, name, and version.

```zeek
path: software
host: 192.168.0.53
software_type: SMTP::MAIL_CLIENT
name: Microsoft Outlook Express
version.major: 6
version.minor: 0
version.minor2: 2900
version.minor3: 5512
unparsed_version: Microsoft Outlook Express 6.00.2900.5512
```

--------------------------------

### Splunk Query for Producer/Consumer Ratio (PCR) Calculation

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0010_Exfiltration/T1020_Automated_Exfiltration.md

This Splunk query calculates the Producer/Consumer Ratio (PCR) from Corelight connection logs. It aggregates originating and responding bytes per host pair and then computes the PCR value, which helps in identifying data exfiltration patterns.

```splunk
index=corelight sourcetype=corelight_conn | stats sum(orig_bytes) as Total_orig_bytes, sum(resp_bytes) as Total_resp_bytes by id.orig_h id.resp_h | eval PCR=(Total_orig_bytes-Total_resp_bytes)/(Total_orig_bytes+Total_resp_bytes) | fields id.orig_h id.resp_h Total_orig_bytes Total_resp_bytes PCR
```

--------------------------------

### T1110 Brute Force Attack Detection (Zeek/Bro)

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Details Zeek log queries and Corelight Extended Detection Capabilities (EDC) for detecting brute force attacks. This includes aggregating connection counts and identifying long-duration sessions or specific SSH log indicators.

```Zeek/Bro
# Hunt for brute force by aggregating connections
# conn.log aggregation query
GROUP BY: id.orig_h, id.resp_h, id.resp_p, proto, service
COUNT: connections
SORT BY: count DESC
TIME WINDOW: 1 hour

# Example suspicious result:
id.orig_h: 203.0.113.100
id.resp_h: 192.168.1.5
id.resp_p: 389            # LDAP
proto: tcp
service: ldap
count: 5000               # Abnormally high connection count

# Hunt for long connections indicating sustained attack
# conn.log query
duration: >600            # Connections longer than 10 minutes

# notice.log - Corelight Long Connections package
note: LongConnection::found
id.orig_h: 203.0.113.100
id.resp_h: 192.168.1.5
id.resp_p: 22
duration: 3600            # 1 hour SSH session

# SSH brute force inference (Corelight ETC)
# ssh.log indicators:
# KS  - Contains keystrokes
# FU  - File upload detected
# FD  - File download detected
# ABP - Authentication bypass
# SV  - Version scanning
# SC  - Capability scanning
```

--------------------------------

### Monitor HTTP Log for Suspicious Requests (Zeek)

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0008_Lateral_Movement/T1021_Remote_Services.md

This snippet shows how to monitor the 'http' log in Zeek for suspicious and unexpected HTTP requests, such as OPTIONS requests, which can indicate reconnaissance or exploitation attempts. It includes fields like method, host, and URI for analysis.

```zeek
_path: http
uid: CEeVS92Ljnr9jbW2J5
id.orig_h: 54.235.163.229
id.orig_p: 41855
id.resp_h: 192.168.0.2
id.resp_p: 80
trans_depth: 1
method: OPTIONS
host: host-90-236-3-35.mobileonline.telia.com
uri: *
version:1.1
```

--------------------------------

### Detect Inbound RDP from Internet with Sigma Rule

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

A Sigma rule designed to detect inbound Remote Desktop Protocol (RDP) sessions originating from internet address space. It filters out internal traffic and connections with zero response bytes, aiming to identify potentially unauthorized external access.

```yaml
title: Inbound RDP from Internet
description: Detects inbound RDP sessions from Internet address space
author: Corelight
tags:
  - attack.initial_access
  - attack.T1133
logsource:
  product: zeek
  service: conn
detection:
  selection:
    dest_ip|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.20.'
      - '172.21.'
      - '172.22.'
      - '172.23.'
      - '172.24.'
      - '172.25.'
      - '172.26.'
      - '172.27.'
      - '172.28.'
      - '172.29.'
      - '172.30.'
      - '172.31.'
    service|contains: 'rdp'
  filter_private_source:
    src_ip|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
  filter_zero_response:
    resp_bytes: 0
  condition: selection and not 1 of filter*
fields:
  - id.orig_h
  - id.resp_h
  - id.resp_p
  - service
level: low
falsepositive:
  - Intentionally-exposed RDP gateways or VDI
```

--------------------------------

### Detect DNS C2 and Tunneling with Zeek Logs

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Hunt for command and control traffic abusing DNS protocols. This includes detecting Domain Generation Algorithm (DGA) patterns by looking for a high count of NXDOMAIN responses from a single host, and identifying DNS tunneling by searching for non-ASCII characters in DNS queries and answers.

```zeek
# Hunt for DNS-based C2 using Domain Generation Algorithm (DGA)
# dns.log query - High NXDOMAIN count from single host
id.orig_h: 192.168.1.100
rcode_name: NXDOMAIN
GROUP BY: id.orig_h
COUNT: queries
HAVING: count > 100       # Threshold for suspicious activity

# Hunt for DNS tunneling - Non-ASCII characters in queries
# dns.log query
query: contains non-ASCII characters
answers: contains non-ASCII characters
```

--------------------------------

### Detecting Non-Standard HTTP on Port 80 (Corelight DPD Log)

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0011_Command_and_Control/T1571_Non-Standard_Port.md

This example shows a Corelight `dpd` log entry indicating a non-standard HTTP request on port 80. It highlights potential malicious activity by showing a `failure_reason` of 'not a http request line', suggesting an unexpected protocol or malformed request on a common port.

```json
{
  "_path": "dpd",
  "uid": "C5LNtk1n9NkT8m300j",
  "id.orig_h": "192.168.0.54",
  "id.orig_p": "52841",
  "id.resp_h": "54.89.42.30",
  "id.resp_p": "80",
  "proto": "tcp",
  "analyzer": "HTTP",
  "failure_reason": "not a http request line"
}
```

--------------------------------

### T1133 External Remote Services Detection (Zeek/Bro)

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Provides Zeek log queries for detecting unauthorized remote access services like RDP, SSH, and VNC exposed externally, and outbound connections for services like TeamViewer and GoToMyPC. This helps identify potential unauthorized access vectors.

```Zeek/Bro
# Hunt for inbound RDP/SSH/VNC from internet
# conn.log query - Find external connections to internal remote services
service: rdp OR ssh OR rfb
local_orig: false
local_resp: true
history: Sh*  # Ensure TCP handshake completed

# Expected fields to review:
id.orig_h: 203.0.113.50      # External attacker IP
id.resp_h: 192.168.1.10      # Internal server
id.resp_p: 3389              # RDP port
orig_cc: CN                  # Country code of origin
service: rdp

# Hunt for outbound TeamViewer connections (reverse remote access)
# conn.log query
id.resp_p: 5938
local_orig: true
local_resp: false

# ssl.log query - TeamViewer SNI detection
server_name|endswith: teamviewer.com

# ssl.log query - GoToMyPC detection
server_name: poll.gotomypc.com
```

--------------------------------

### Detect Remote Services Lateral Movement with Zeek Logs

Source: https://context7.com/corelight/threat-hunting-guide/llms.txt

Monitor for suspicious use of remote services that may indicate lateral movement. This includes detecting unusual HTTP OPTIONS requests, identifying outdated software versions on hosts, and flagging multiple connections to Windows administrative shares (ADMIN$, C$, IPC$).

```zeek
# http.log - Suspicious OPTIONS requests (web vulnerability probing)
_path: http
method: OPTIONS
uri: *
id.orig_h: 54.235.163.229   # External IP
id.resp_h: 192.168.0.2      # Internal server

# software.log - Monitor for unexpected software versions
path: software
host: 192.168.0.53
software_type: SMTP::MAIL_CLIENT
name: Microsoft Outlook Express
unparsed_version: Microsoft Outlook Express 6.00.2900.5512
# Flag: Outdated software versions may indicate unpatched vulnerabilities

# smb_files.log - Windows Admin Share access patterns
# Look for multiple connections to ADMIN$, C$, IPC$
path: \\192.168.1.5\ADMIN$
id.orig_h: 192.168.1.100
action: SMB::FILE_OPEN
```

--------------------------------

### Log SMB FILE_OPEN Action on Windows Admin Share

Source: https://github.com/corelight/threat-hunting-guide/blob/master/TA0008_Lateral_Movement/T1021.002_SMB_Windows_Admin_Shares.md

This log entry demonstrates the 'FILE_OPEN' action performed on a Windows administrative share (ADMIN$) via SMB. It includes details such as source and destination IP addresses, ports, the specific path accessed, and timestamps for file modifications, access, creation, and changes. This data is crucial for detecting unauthorized administrative actions.

```log
path: smb_files
uid: CB3Ezw2X3tYKtxunq
id.orig_h: 10.10.199.101
id.orig_p: 49710
id.resp_h: 10.10.199.31
id.resp_p: 445
action: SMB::FILE_OPEN
path: \\10.10.199.31\admin$
name: <share_root>
size: 24576
times.modified: 2020-04-07T21:17:30.244159Z
times.accessed: 2020-04-07T21:17:30.244159Z
times.created: 2016-07-16T06:04:24.770745Z
times.changed: 2020-04-07T21:17:30.244159Z
```