Threat Intelligence: TTPs, IOCs, Threat Hunting & TIP Platforms - Cybersecurity Hub

← Back to Home Threat Intelligence: TTPs, IOCs, Threat Hunting & TIP Platforms Table of Contents Introduction: Intelligence-Driven Defense Intelligence Levels: Tactical, Operational, Strategic STIX & TAXII: Standards for Sharing MITRE ATT&CK for Intelligence Threat Hunting Methodologies Intelligence Sharing (ISACs) Threat Intelligence Platforms (TIP) Conclusion Introduction: Intelligence-Driven Defense Cyber Threat Intelligence (CTI) is evidence-based knowledge about adversaries—their motivations, intents, capabilities, and tradecraft—used to inform defensive decisions. Without intelligence, defenders operate blind against adversaries who have unlimited time to study the target. The pyramid of pain captures the principle: low on the pyramid, indicators like IPs and hashes are abundant but trivial for adversaries to change. Top of the pyramid, TTPs (Tactics, Techniques, Procedures) are rare, behavior-based, and costly for adversaries to change. Intelligence-driven defense aims to detect based on TTPs, not just IOCs. Intelligence Levels: Tactical, Operational, Strategic Intelligence Pyramid Level Audience Content Use Case Strategic Executives, CISO, Board Trends, campaigns, geopolitical context, business risk Investment, planning, risk acceptance Operational Security Managers, Architects Campaign details, actor profiles, TTPs Defense planning, detection coverage Tactical SOC Analysts, Hunters IOCs, malicious hashes, IPs, domains, URLs, YARA rules Detection, blocking, hunting Pyramid of Pain (Detection Efficacy) # Pyramid of Pain (David J. Bianco) # Adversary pain increases as you climb # # /\ # / \ TTPs - Hardest to change (behaviors) # /____\ # / \ Tools - Need new tooling #/________\ #/ \ Network - Infrastructure changes #/____________\ Host - Rebuild artifacts #/ \ Hash - Trivial change # Top: TTPs (Tactics, Techniques, Procedures) # - "Process injection by манипulating LSASS" # - Very rare, very valuable # - Example: "Adversary X uses WMI for persistence" # # Middle: Tools # - Custom malware families # - Specific RAT variants # - Known exploit scripts # # Bottom: Hash, IP, Domain # - Commodity indicators # - Short lifespan (hours-days) # - Lowest friction for adversary to change STIX & TAXII: Standards for Sharing STIX (Structured Threat Information Expression) and TAXII (Trusted Automated Exchange of Intelligence Information) are OASIS standards for representing and exchanging threat intelligence. STIX 2.1 Objects # STIX 2.1 is JSON-based with these top-level object types: # - Indicator (atomic indicator: IP, hash, URL) # - Malware (malware family/description) # - Threat Actor (person/group) # - Intrusion Set (campaign/group of activities) # - Attack Pattern (MITRE ATT&CK technique) # - Tool (software used by adversaries) # - Vulnerability (CVE, weakness) # - Course of Action (mitigation) # - Relationship (links between objects) # - Report (narrative intelligence report) # - Identity (who) # - Location (where) # - Observed Data (what was seen, when) # Example STIX 2.1 Bundle { "type": "bundle", "id": "bundle--12345", "objects": [ { "type": "indicator", "id": "indicator--abc123", "created": "2026-01-01T00:00:00Z", "modified": "2026-01-01T00:00:00Z", "name": "Malicious IP - C2", "description": "Known C2 for APT-X", "pattern": "[ipv4-addr:value = '192.0.2.1']", "pattern_type": "stix", "valid_from": "2026-01-01T00:00:00Z", "labels": ["malicious-activity", "c2"] }, { "type": "intrusion-set", "id": "intrusion-set--xyz789", "created": "2026-01-01T00:00:00Z", "modified": "2026-01-01T00:00:00Z", "name": "APT-X", "description": "State-sponsored group targeting finance", "aliases": ["Group ABC"], "first_seen": "2020-01-01T00:00:00Z" }, { "type": "relationship", "id": "relationship--rel1", "source_ref": "indicator--abc123", "target_ref": "intrusion-set--xyz789", "relationship_type": "indicates" } ] } TAXII 2.1 API # TAXII 2.1 is REST API for exchanging STIX content # Endpoints: # GET /api-root/discovery (server info) # GET /api-root/collections (list collections) # POST /api-root/collections/{id}/objects/ (publish objects) # GET /api-root/collections/{id}/objects/ (read objects) # GET /api-root/manifest/ (object metadata) # Example: Subscribe to threat intel feed import requests from taxii2client.v21 import Server server = Server('https://taxii.example.com/', user='consumer', password='pass') api_root = server.api_roots[0] collection = api_root.collections[0] # Pull recent IOCs manifest = collection.get_manifest() for entry in manifest: obj = collection.get_object(entry['id']) print(f"{obj['type']}: {obj.get('name', 'unnamed')}") OpenCTI (Open Source TIP) # OpenCTI is a popular open-source threat intelligence platform # Supports STIX 2.1 natively, integrates with MITRE ATT&CK # GraphQL API example: Search for indicators mutation { indicatorAdd(input: { name: "Suspicious PS command" pattern_type: "stix" pattern: "[process:command_line MATCHES '*FromBase64*']" x_opencti_main_observable_type: "Process" valid_from: "2026-01-01T00:00:00Z" }) { id } } # Visualize relationships in graph view # Enrich with threat intel feeds: AlienVault OTX, MISP, MITRE ATT&CK MITRE ATT&CK for Intelligence ATT&CK 内容 Types Content Type Example Detection Level Tactic Initial Access (TA0001) Strategic: Why adversary acts Technique Phishing (T1566) Operational: General tactic Sub-technique Spearphishing Attachment (T1566.001) Operational: Specific method Procedure "APT29 sends macro-laced doc" Tactical: Specific actor's behavior Using ATT&CK for Intelligence # Adversary Profiling # 1. Identify adversary (intrusion set) # 2. Catalog observed TTPs from incidents, reports # 3. Map TTPs to ATT&CK IDs # 4. Build "attack flow" - sequence of ATT&CK IDs # 5. Identify defense gaps (what we can't detect) # 6. Create detections for gaps # 7. Update adversary profile with new TTPs from intel # Example: APT29 Attack Flow # T1566.001 (Spearphishing Attachment) # -> T1204.002 (User Execution: File) # -> T1059.001 (PowerShell) # -> T1027 (Obfuscated Files) # -> T1547.001 (Registry Run Keys) # -> T1071.001 (C2 over DNS/Web) # -> T1003.001 (LSASS Memory dump) # -> T1041 (Exfiltration over C2) # Detection coverage map: # T1566.001: 30% (mail sandbox) # T1204.002: 60% (EDR) # T1059.001: 85% (PowerShell logging) # T1027: 40% (AV signatures) # T1547.001: 70% (registry monitoring) # T1071.001: 20% (limited DNS logging) # T1003.001: 90% (EDR alerts on LSASS) # T1041: 50% (DLP + network) STIX for ATT&CK # MITRE ATT&CK is published as STIX 2.1 bundles # https://github.com/mitre/cti # Use ATT&CK STIX directly in tools import stix2 # Load ATT&CK STIX bundle with open('enterprise-attack.json') as f: bundle = stix2.parse(f.read(), allow_custom=True) # Find technique by external ID for obj in bundle.objects: if obj.get('external_references'): for ref in obj['external_references']: if ref['source_name'] == 'mitre-attack': if ref['external_id'] == 'T1059.001': print(f"Found: {obj.name}") print(f"Description: {obj.description}") print(f"Tactics: {[r['phase_name'] for r in obj['kill_chain_phases']]}") Threat Hunting Methodologies Threat hunting assumes the adversary is already inside. Hunters proactively search for indicators of compromise that defenses missed. Hunt Hypothesis Formulation # A good hunt starts with a falsifiable hypothesis # Structure: "If adversary did X, then Y should exist in data source Z" # Example hypotheses: # H1: "Adversaries using process hollowing will have a parent # process that is unexpected for the child" # Data: EDR process tree logs (parent-child mismatch) # H2: "Adversaries using Kerberoasting will request TGS for # SPN-enabled service accounts" # Data: DC 4769 events (Kerberos TGS request) # H3: "Adversaries maintaining persistence via WMI will create # permanent event subscriptions" # Data: WMI repository, EDR WMI events # Hypothesis evaluation: # - True: confirm detection works, document procedure # - False: hypothesis refuted (good outcome, no compromise here) # - Inconclusive: data gap, fix logging Hunt Lifecycle Trigger: External (intel report, new TTP) or internal (anomaly, gut feel) Hypothesis: Formulate a falsifiable claim Investigation: Search data, analyze anomalies Outcome: True / False / Inconclusive Output: New detection rule OR refined hunting query OR logging gap identified Hunt Techniques 1. Stack-Based Outlier Hunting # Find rare events by stacking (group + count) # Look for outliers in the stack # Splunk: Find rare process executions index=edr event=process_started | stats count by process_name, parent_process | where count < 5 | sort count # Sentinel KQL: Rare logon locations SigninLogs | where TimeGenerated > ago(7d) | summarize locations = make_set(LocationDetails), count() by userPrincipalName | where array_length(locations) > 1 | sort by array_length(locations) desc 2. Time-Based Anomaly # Detect activity outside normal hours # Sentinel KQL SigninLogs | where TimeGenerated > ago(30d) | extend hour = datetime_part("hour", TimeGenerated) | summarize avg_hour = avg(hour), stdev_hour = stdev(hour), count = count() by userPrincipalName | where count > 50 // Enough data for meaningful stats | extend normal_range_start = avg_hour - 2 * stdev_hour | extend normal_range_end = avg_hour + 2 * stdev_hour # Now find logons outside normal_range SigninLogs | where TimeGenerated > ago(7d) | extend hour = datetime_part("hour", TimeGenerated) | join kind=inner ( // normal_range query above ) on userPrincipalName | where hour < normal_range_start or hour > normal_range_end 3. Behavior-Based: Beacon Analysis # Detect C2 beaconing patterns # Splunk: Look for periodic outbound connections index=firewall action=allowed | stats count, min(_time) as first_seen, max(_time) as last_seen, stdev(_time) as time_stddev by src_ip, dest_ip, dest_port | eval time_range = last_seen - first_seen | eval beacon_score = (count / time_range) / (time_stddev + 1) | where beacon_score > 0.8 and count > 10 | sort -beacon_score # Zeek DNS: Detect DNS tunneling # DNS query lengths > 50 chars are suspicious # Many subdomain levels (more than 5) suspicious # Entropy of subdomain > 3 (random looking) Documenting Hunts # Hunt Report Template # # Title: Hunt for APT persistence via WMI subscriptions # Analyst: [name] # Date: YYYY-MM-DD # # Hypothesis: # Adversaries maintaining persistence via WMI event subscriptions # will create permanent event consumers in the WMI repository. # # Data Sources: # - EDR WMI event logs (T1085) # - PowerShell Module logging (4103) # - WMI repository (CIM) # # Query: # # # Findings: # - Number of anomalies found: X # - Confirmed malicious: Y/N # - Detection rule created: Y/N (link to rule) # - IOC added to blocklist: Y/N (link) # # Conclusion: # Hunt confirmed/refuted hypothesis # Recommendations: # - Improve logging on Z # - Detection rule needed for Y Intelligence Sharing (ISACs) Information Sharing and Analysis Centers (ISACs) enable sector-specific intelligence sharing. Major ISACs ISAC Sector Sharing Channels FS-ISAC Financial Services Fusion Center, SOPs E-ISAC Energy (Electric) 24/7 watch desk H-ISAC Healthcare HINN, weekly calls R-CISC Retail R-CISC portal MS-ISAC State/local gov CIS, 24/7 SOC Sharing Models # Traffic Light Protocol (TLP) - www.first.org/tlp # TLP:RED - Recipient only, do not share # TLP:AMBER - Limited sharing within organization # TLP:GREEN - Community sharing (sector) # TLP:CLEAR - Public, no restriction # Sharing channels: # 1. STIX/TAXII automated feeds # 2. Email distribution lists (with TLP) # 3. Secure portals (FS-ISAC CI, MS-ISAC Portal) # 4. Encrypted chat (Slack shared channels) # 5. Phone bridge during incidents # Insider sharing rules: # - Tag with TLP # - Strip customer/data owner PII unless explicit consent # - Provide context (why this is useful) # - Cite source intelligence report MISP (Malware Information Sharing Platform) # MISP - Open source threat intelligence sharing platform # github.com/MISP/MISP # Events and attributes: # Event: container for IOCs related to one incident/campaign # Attribute: individual IOC (IP, hash, domain, email) # Galaxy: meta-catalog (MITRE ATT&CK, malware, threat actors) # Taxonomy: tagging (TLP, PAP, type, sector) # API upload curl -k -H "Authorization: $API_KEY" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ --data @event.json \ "$MISP_URL/events/add" # Pull events modified in last 24h curl -k -H "Authorization: $API_KEY" \ "$MISP_URL/events/index/searchtimestamp:$(date -d 'yesterday' +%s)" # Sync with peers - built-in MISP sync # Configure sync servers in MISP UI, then auto-pull / push events Threat Intelligence Platforms (TIP) TIPs aggregate, enrich, and operationalize threat intel feeds, making raw intelligence actionable. TIP Evaluation Criteria Criteria Description Ingestion How many feed formats/sources supported (STIX, MISP, CSV, JSON) Enrichment Built-in enrichment (VT, WHOIS, GeoIP, reputation) Correlation Link IOCs to MITRE ATT&CK, threat actors, campaigns Output Export to SIEM, firewall, EDR; API access Collaboration Sharing with peers, comments, workflows TLP/PAP support Data classification, sharing restrictions Hosting Cloud vs on-prem TIP Landscape TIP Type Strengths MISP Open source Community, free, flexible, MISP galaxies OpenCTI Open source STIX native, GraphQL API, great UI ThreatConnect Commercial SOAR built-in, playbooks ThreatQuotient Commercial Strong ecosystem, FOCUS taxonomy Anomali ThreatStream Commercial Big data integrations, intel marketplace Recorded Future Commercial Tons of sources, AI enrichment TIP Integration Pattern # Intelligence flow in a mature CTI program: # # Feeds -----> TIP (Aggregation, Enrichment, Correlation) # | # +---> SIEM (Detection: watchlists, IOCs) # +---> Firewalls (Block IOCs) # +---> EDR (Hunt queries) # +---> Email Security (Block IOCs) # +---> SOAR (Playbook enrichment) # +---> Reports/Dashboards (Strategic) # # Two-way flow: # SIEM alerts -----> TIP (add new findings) # IR incidents ----> TIP (TTP observations, new IOCs) # Hunting findings --> TIP (refine intel) # # Final delivery: # - Daily/weekly threat brief for SOC # - Ad-hoc to IR during incidents # - Monthly strategic brief for CISO/execs Conclusion Threat intelligence transforms defense from a reactive posture to an evidence-informed program.