# IOC Patterns

> Taxonomy of indicator of compromise types, extraction techniques, quality assessment, and structured formatting for threat intelligence sharing.

## Knowledge Base

### Indicator Taxonomy

The Pyramid of Pain (David Bianco, 2013) ranks indicator types by how much effort it costs an adversary to change them:

```
        /  TTPs  \          <- Hardest to change (most valuable)
       / Tools    \
      / Artifacts  \
     / Domain Names \
    / IP Addresses   \
   / Hash Values      \    <- Easiest to change (least valuable)
```

**Hash Values (Trivial to change)**
- MD5 (32 hex chars) -- collision-prone, still used for lookup compatibility
- SHA-1 (40 hex chars) -- deprecated for security, still common in threat intel
- SHA-256 (64 hex chars) -- standard for reliable identification
- ssdeep (fuzzy hash) -- identifies similar files despite minor changes
- TLSH (Trend Micro Locality Sensitive Hash) -- better than ssdeep for many use cases
- Imphash (PE import hash) -- groups samples by import table, survives recompilation

**IP Addresses (Easy to change)**
- C2 server addresses
- Exfiltration endpoints
- Scanning/reconnaissance sources
- Proxy/relay infrastructure
- Note: Shared hosting, CDNs, and cloud IPs can cause false positives

**Domain Names (Moderate to change)**
- C2 domains (registered or compromised)
- DGA (Domain Generation Algorithm) domains -- daily/hourly generated
- Staging/distribution domains
- Exfiltration domains (including DNS tunneling)
- Subdomain patterns (randomized, sequential, encoded)

**Network Artifacts (Moderate to change)**
- JA3/JA3S hashes (TLS client/server fingerprints)
- JARM fingerprints (active TLS server fingerprinting)
- HTTP headers and patterns (User-Agent, custom headers)
- URI patterns and paths
- Certificate details (subject, issuer, serial, thumbprint)
- DNS query patterns (record types, query frequency, response sizes)

**Host Artifacts (Harder to change)**
- File paths (drop locations, staging directories)
- Registry keys and values
- Mutex/named event names
- Scheduled task configurations
- Service names and descriptions
- Named pipe names
- WMI subscriptions
- Process command-line patterns

**Tools (Hard to change)**
- Tool-specific artifacts (Cobalt Strike beacon configs, Mimikatz output patterns)
- Compiler/linker signatures (Rich header hashes)
- Packer/crypter signatures
- Framework indicators (Metasploit, Empire, Covenant)

**TTPs (Most expensive to change)**
- MITRE ATT&CK technique mappings
- Kill chain phase behaviors
- Operational patterns (working hours, target selection, infrastructure choices)

### Extraction Techniques

**From static analysis output**:
```
# Extract potential IPs from strings output
Pattern: \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b
Exclude: 0.0.0.0, 127.0.0.1, 10.x.x.x, 172.16-31.x.x, 192.168.x.x

# Extract potential domains
Pattern: \b[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.[a-zA-Z]{2,}\b
Exclude: microsoft.com, google.com, etc. (known legitimate)

# Extract potential URLs
Pattern: https?://[^\s"'<>]+
Also check for: hxxp://, hxxps://, [.]com defanged formats

# Extract email addresses
Pattern: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

# Extract file hashes
MD5:    \b[a-fA-F0-9]{32}\b
SHA-1:  \b[a-fA-F0-9]{40}\b
SHA-256: \b[a-fA-F0-9]{64}\b
```

**From sandbox reports**:
- Process creation events -> command-line IOCs and process tree patterns
- Network connections -> IPs, domains, ports, protocols
- File writes -> paths, hashes of dropped files
- Registry modifications -> keys, values, persistence indicators
- DNS queries -> domains, resolution patterns

**From PCAP/network captures**:
- DNS query names and response addresses
- HTTP Host headers and request URIs
- TLS SNI (Server Name Indication) values
- TLS certificate details
- JA3 hashes from TLS Client Hello
- JARM from active server probing

### Indicator Quality Assessment

| Quality Factor | Good Indicator | Poor Indicator |
|---------------|----------------|----------------|
| Specificity | Unique to this threat | Shared with legitimate services |
| Durability | Stable across campaigns | Changes per target |
| Actionability | Can be blocked/detected | Informational only |
| Context | Role in attack chain known | Found but purpose unclear |
| Confidence | Confirmed malicious | Possibly benign |
| Timeliness | Current infrastructure | Months-old, likely rotated |

### Structured Output Formats

**STIX 2.1 Indicator Object**:
```json
{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--uuid",
  "created": "2024-01-15T00:00:00.000Z",
  "modified": "2024-01-15T00:00:00.000Z",
  "name": "Malware X C2 Domain",
  "description": "C2 domain used by Malware X campaigns",
  "pattern": "[domain-name:value = 'malicious.example.com']",
  "pattern_type": "stix",
  "valid_from": "2024-01-15T00:00:00.000Z",
  "valid_until": "2024-04-15T00:00:00.000Z",
  "kill_chain_phases": [
    {
      "kill_chain_name": "mitre-attack",
      "phase_name": "command-and-control"
    }
  ],
  "indicator_types": ["malicious-activity"],
  "confidence": 85
}
```

**OpenIOC format** (Mandiant):
```xml
<Indicator operator="OR">
  <IndicatorItem condition="is">
    <Context document="FileItem" search="FileItem/Md5sum" type="mir"/>
    <Content type="md5">abc123...</Content>
  </IndicatorItem>
</Indicator>
```

**CSV format** (for SIEM bulk import):
```
type,indicator,context,confidence,tlp,first_seen,last_seen
ipv4,203.0.113.50,C2 server,high,amber,2024-01-10,2024-01-15
domain,evil.example.com,payload distribution,high,amber,2024-01-08,2024-01-15
sha256,abc123...,stage2 payload,confirmed,amber,2024-01-12,2024-01-12
```

## Patterns

### Pattern: DGA Domain Detection
**Characteristics**: High entropy (>3.5 per domain label), no meaningful words, consistent length patterns, large volume of NXDomain responses, algorithmic naming patterns.
**Extraction**: Capture all DNS queries from sandbox, filter out known-good domains, calculate entropy of remaining domains, cluster by length/character patterns.
**Action**: Reverse-engineer DGA algorithm from malware code to predict future domains for proactive blocking.

### Pattern: Beaconing Detection
**Characteristics**: Regular connection intervals (with jitter), consistent destination, similar request sizes, POST with encoded body or GET with encoded parameters.
**Extraction**: From PCAP or proxy logs, aggregate connections by destination, calculate inter-arrival times, identify periodicity using statistical analysis.
**Key metrics**: Mean interval, standard deviation (jitter), data volume per session, total duration.

### Pattern: Staging Infrastructure Identification
**Characteristics**: Newly registered domains (< 30 days), hosted on bulletproof providers, TLS certificates from free CAs (Let's Encrypt), low Alexa/Tranco rank, WHOIS privacy services.
**Enrichment sources**: PassiveTotal, DomainTools, Shodan, Censys, Certificate Transparency logs.

### Pattern: Lateral Movement IOCs
**Host indicators**: Remote service creation (`sc \\target create`), PsExec service installation (`PSEXESVC`), WMI process creation, RDP connection artifacts, SMB file copies to `ADMIN$` or `C$` shares.
**Network indicators**: SMB traffic to internal hosts, WinRM connections, RDP (3389), unusual authentication events between workstations.

## Anti-Patterns

- **Publishing IOCs without context** -- A list of IPs without descriptions of their role, confidence level, or valid timeframe creates noise, not intelligence
- **Treating all indicators equally** -- An IP address is not equivalent to a TTP. Weight and prioritize by the Pyramid of Pain
- **Ignoring indicator expiry** -- IOCs go stale. Set explicit valid_until dates. C2 IPs may rotate in 24-48 hours; domains in days to weeks
- **Including infrastructure IOCs without validation** -- CDN IPs, shared hosting IPs, and cloud provider ranges will cause massive false positives. Always validate specificity
- **Defanging inconsistently** -- When sharing IOCs in reports, consistently defang URLs (hxxps://) and domains (example[.]com) to prevent accidental resolution/clicks. In machine-readable exports, use the raw format
- **Extracting without deduplication** -- Raw extraction produces duplicates. Always deduplicate and normalize (lowercase domains, consistent hash case) before publishing

## References

- David Bianco - The Pyramid of Pain -- https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
- STIX/TAXII Standards -- https://oasis-open.github.io/cti-documentation/
- MITRE ATT&CK -- https://attack.mitre.org/
- OpenIOC format -- https://github.com/mandiant/OpenIOC_1.1
- JA3 TLS Fingerprinting -- https://github.com/salesforce/ja3
- JARM Fingerprinting -- https://github.com/salesforce/jarm
- Abuse.ch (MalwareBazaar, URLhaus, ThreatFox) -- https://abuse.ch/
- AlienVault OTX -- https://otx.alienvault.com/
- MISP (Malware Information Sharing Platform) -- https://www.misp-project.org/