Phase 6: Blue Team & Defensive Security

🎮 Practice Network Monitoring

• TryHackMe — Snort room: Learn to write and tune Snort rules
• TryHackMe — Wireshark 101: Guided packet analysis exercises
• TryHackMe — NetworkMiner room: Network forensics tool practice
• Malware Traffic Analysis (.net): Free PCAPs from real malware infections to analyze
• Our Wireshark Guide — Deep dive into traffic capture and analysis

Indicators of Compromise (IOCs) vs Indicators of Attack (IOAs)

These are two different ways defenders look for threats. Think of IOCs as clues left behind after a crime, and IOAs as suspicious behavior that suggests a crime is happening right now.

• IOCs (Indicators of Compromise) — Static forensic artifacts that indicate a system has been compromised: file hashes, known malicious IP addresses, C2 domain names, registry keys, mutex names, email addresses. IOCs are reactive — they identify known threats after the fact.

  # IOC examples:
  # File hash: e99a18c428cb38d5f260853678922e03 (known malware)
  # IP address: 185.220.101.34 (known C2 server)
  # Domain: evil-update.com (phishing domain)
  # File path: C:\Windows\Temp\beacon.exe
  # Registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\Run\UpdateSvc
  # Email: [email protected] (phishing sender)

• IOAs (Indicators of Attack) — Behavioral patterns that indicate an attack is in progress, regardless of the specific malware. More durable than IOCs because they focus on attacker behavior, not specific tools:

  # IOA examples:
  # Behavior: Process injection (any process injecting code into another)
  # Behavior: Credential dumping (any tool accessing LSASS memory)
  # Behavior: Lateral movement pattern (authenticate → whoami → net user → net group)
  # Behavior: DNS beaconing (regular interval DNS queries to unusual domains)
  # Behavior: Scheduled task creating outbound connections
  # Behavior: PowerShell downloading and executing in memory (fileless)

💡 Key insight: IOCs are like wanted posters — they work until the attacker changes their face. IOAs are like suspicious behavior patterns — an attacker can change tools but the behavior pattern remains. The best detection strategies combine both.

📊 SIEM Basics — Centralized Security Monitoring

A SIEM (Security Information and Event Management) system collects logs from every source in your environment, normalizes them, correlates events, and generates alerts. It's the nerve center of a SOC (Security Operations Center).

How a SIEM Works

1. Collection: Ingest logs from firewalls, servers, endpoints, applications, cloud services, network devices
2. Normalization: Convert all log formats into a common schema (different sources log the same events differently)
3. Correlation: Connect related events across sources — e.g., firewall allows connection + web server logs SQLi + endpoint creates new process = attack chain
4. Detection: Rules and machine learning identify known attack patterns and anomalies
5. Alerting: Notify analysts with context, severity, and recommended actions
6. Investigation: Analysts drill into alerts, pivot across data sources, determine if it's a true/false positive

Popular SIEM Platforms

• Splunk: The industry leader. Powerful SPL (Search Processing Language). Expensive but incredibly capable. Free trial and Splunk Enterprise Security for learning.
• Elastic SIEM (ELK Stack): Open-source: Elasticsearch + Logstash + Kibana. Free, flexible, widely used. Great for home labs.
• Microsoft Sentinel: Cloud-native SIEM built on Azure. KQL (Kusto Query Language). Growing rapidly in enterprise.
• Wazuh: Open-source SIEM + XDR (Extended Detection and Response — combines endpoint, network, and cloud monitoring in one platform). Excellent for learning — full-featured and free.

Writing Detection Rules

# Splunk SPL — Detect brute force (10+ failed logins from same IP in 5 min)
index=windows EventCode=4625
| stats count by src_ip, Account_Name
| where count > 10
| sort -count

# Splunk SPL — Detect lateral movement (Pass the Hash)
index=windows EventCode=4624 Logon_Type=3
| where Account_Name!="ANONYMOUS LOGON" AND Account_Name!="*$"
| stats dc(dest) as unique_hosts by src_ip, Account_Name
| where unique_hosts > 5
| sort -unique_hosts

# ELK/KQL — Detect new service installation (persistence)
event.code: "7045" AND NOT winlog.event_data.ImagePath: ("C:\\Windows\\System32\\*")

# ELK/KQL — Detect PowerShell download cradle
event.code: "4104" AND winlog.event_data.ScriptBlockText: (*DownloadString* OR *WebClient* OR *IEX* OR *Invoke-Expression*)

# Sigma rule — a universal detection rule format that works across SIEMs.
# Write once, convert to Splunk SPL, ELK KQL, Microsoft Sentinel, etc.:
title: Suspicious Process Creation - Recon Commands
status: experimental
description: Detects common reconnaissance commands used after initial compromise
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'whoami'
      - 'net user'
      - 'net group "domain admins"'
      - 'ipconfig /all'
      - 'systeminfo'
      - 'nltest /dclist'
  condition: selection
  timeframe: 5m
  | count() by Computer > 3
level: medium
tags:
  - attack.discovery
  - attack.t1033
  - attack.t1069

💡 Sigma rules are a universal detection rule format that can be converted to Splunk SPL, ELK KQL, Microsoft Sentinel, QRadar, and more. Writing Sigma rules means you write once, deploy anywhere. The SigmaHQ repository has thousands of community-contributed rules.

# Quick ELK Stack setup with Docker (for learning):
git clone https://github.com/deviantony/docker-elk.git
cd docker-elk
docker compose up -d

# Access Kibana at http://localhost:5601
# Default creds: elastic / changeme

# Ingest sample data:
# 1. Download Windows event log samples from EVTX-ATTACK-SAMPLES on GitHub
# 2. Use Winlogbeat or manually import into Elasticsearch
# 3. Create detection rules in Kibana → Security → Rules

# Alternative: TryHackMe SIEM rooms:
# - "Splunk 101" — Learn SPL basics
# - "Splunk: Exploring SPL" — Advanced queries
# - "Investigating with ELK 101" — KQL and Kibana
# - "Wazuh" — Open-source SIEM/XDR setup and usage

🔬 Malware Analysis — Introduction

Malware analysis is the process of understanding what a malicious program does, how it works, and what indicators it leaves behind. There are two main approaches:

Static Analysis — Examining Without Executing

Analyze the malware without running it. Safe but limited — you see the code, not necessarily the behavior.

# Step 1: Get basic file info
file suspicious.exe                    # File type
md5sum suspicious.exe                  # Hash for VirusTotal lookup
sha256sum suspicious.exe
strings suspicious.exe | less          # Readable strings (URLs, IPs, commands)
strings suspicious.exe | grep -i "http\|ftp\|cmd\|powershell\|reg\|192\.\|10\."

# Step 2: PE (Portable Executable) analysis — PE is the file format for Windows
# .exe and .dll files. Use PE-bear, pestudio, or CFF Explorer to inspect them.
# Check: imports (what APIs does it call?), sections, resources, timestamps
# Suspicious imports: VirtualAlloc, WriteProcessMemory, CreateRemoteThread
#   → Process injection capability
# Suspicious imports: InternetOpen, URLDownloadToFile, HttpSendRequest
#   → Network communication / download capability
# Suspicious imports: RegSetValueEx, CreateService
#   → Persistence mechanisms

# Step 3: Disassembly / Decompilation
# Ghidra (free, by the NSA) or IDA Pro (paid, industry standard) — these tools
# convert compiled programs back into readable assembly/pseudo-code
# Look for: C2 communication logic, encryption routines, persistence mechanisms

# Step 4: YARA rules — pattern matching for malware
# YARA is like "grep for malware" — you write rules that describe patterns
# (strings, byte sequences, file properties) and YARA scans files to find matches.
# Security teams use YARA rules to detect and classify malware across their systems.
rule SuspiciousStrings {
    meta:
        description = "Detect common malicious strings"
    strings:
        $s1 = "cmd.exe /c" nocase
        $s2 = "powershell -enc" nocase
        $s3 = "FromBase64String" nocase
        $s4 = "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run"
        $url = /https?:\/\/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/
    condition:
        uint16(0) == 0x5A4D and 3 of them  // MZ header (PE file) + 3 matching strings
}

Dynamic Analysis — Observing Behavior in a Sandbox

Run the malware in an isolated environment and watch what it does. Reveals actual behavior including network connections, file changes, and registry modifications.

# Sandboxing tools:
# - ANY.RUN (online, interactive sandbox — watch malware execute in browser)
# - Cuckoo Sandbox (self-hosted, automated analysis)
# - Joe Sandbox (online, detailed reports)
# - Windows Sandbox (built into Win 10/11 Pro — quick disposable environment)
# - REMnux (Linux VM pre-loaded with malware analysis tools — strings, disassemblers, network tools)
# - FlareVM (Windows VM with analysis tools — from Mandiant, the incident response company)

# What to monitor during dynamic analysis:
# Process activity: What processes does it create? Does it inject into others?
# File system: What files does it create/modify/delete?
# Registry: What keys does it add? (persistence check!)
# Network: What IPs/domains does it contact? What data does it send?
# API calls: What system functions does it invoke?

# Tools for monitoring during execution:
# Process Monitor (ProcMon) — file system + registry + process activity
# Process Explorer — process tree, loaded DLLs, handles
# Wireshark/FakeDNS — capture network traffic
# Regshot — snapshot registry before/after execution

⚠️ CRITICAL: Never run malware on your real machine or a connected network. Always use an isolated VM with no network access (or only monitored/faked network). Snapshot before execution, revert after. Treat every sample as if it's the most dangerous malware you've ever seen.

alert http any any -> $HOME_NET any (msg:"SQLi attempt";  http_uri; sid:1000010; rev:1;)