Ioc Patterns

---
name: "ioc-patterns"
description: "Indicator of compromise taxonomy ranked by the Pyramid of Pain, extraction and defanging patterns, quality assessment, and structured formats such as STIX 2.1 for sharing. Use when extracting, prioritizing, or formatting IOCs from an investigation."
---

# 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/