Skip to main content

Chapter 1.2 Quiz Threat Intelligence & Attack Taxonomy

Quiz Mode All answers are hidden under collapsible sections. Attempt each question before revealing the answer.


Question 1

An analyst notices that their SIEM generates 500 alerts/day from a threat feed containing 50,000 IP addresses. The SOC blocks all IPs on the feed at the perimeter firewall. The security manager calls this "excellent threat intelligence operationalization." What is fundamentally wrong with this approach, referencing the Pyramid of Pain?

Reveal Answer & Explanation

Answer: Blocking IPs is the lowest-value action possible at the base of the Pyramid of Pain, trivial for attackers to evade.

Explanation:

The Pyramid of Pain (David Bianco) describes how much pain is caused to an attacker when each indicator type is detected and blocked:

  • Hash values trivial: change one byte, new hash
  • IP addresses trivial: use a new VPS, rotate through bulletproof hosting
  • Domain names easy: register a new domain, use DGA
  • Network/Host Artifacts moderate: requires changing tooling
  • Tools significant: requires rewriting or replacing tools
  • TTPs hard: requires fundamentally changing behavior

Problems with mass IP blocking:

  1. Massive false positives large IP feeds include CDN IPs, Tor exit nodes, and shared hosting IPs used by both attackers AND legitimate businesses. Blocking 104.21.x.x (Cloudflare range) breaks legitimate traffic.

  2. Near-zero detection value a sophisticated attacker uses fresh infrastructure for each campaign. By the time an IP is in a threat feed, the attacker has likely already moved on.

  3. Alert fatigue 500 alerts/day from IP blocks generates noise that buries real detections. Analysts tune out.

  4. Missing the attacker a determined attacker blocked at the perimeter pivots to a new IP. They aren't stopped; they're inconvenienced for minutes.

What good operationalization looks like:

Low value (stop over-investing here):
→ IP blocklists, hash blocklists

Medium value (automate these):
→ Domain reputation, known C2 domain blocking
→ File reputation scanning

High value (invest engineering here):
→ Behavioral detection rules (Sigma for TTPs)
→ YARA for malware family patterns (not just hashes)
→ Anomaly baselines for network behavior
→ ATT&CK-mapped detections

The correct metric is not "alerts generated" it is true positive rate, mean time to detect (MTTD), and coverage of ATT&CK tactics in your detection library.


Question 2

A threat intelligence report states that APT41 (a Chinese nation-state group) is targeting telecommunications companies using the following technique: T1190 Exploit Public-Facing Application for initial access, followed by T1505.003 Web Shell. Your organization runs a public-facing web application on Apache Tomcat 9.0.50. What are the immediate and strategic actions you should take, and how does the Diamond Model help you investigate if a compromise is suspected?

Reveal Answer & Explanation

Answer: Immediate patch/harden the application + deploy web shell detection; use Diamond Model to pivot from any discovered indicator.

Explanation:

Immediate Technical Actions:

# 1. Check Tomcat version and known CVEs for 9.0.50
# CVE-2022-34305 (XSS), CVE-2021-33037 (Request Smuggling) affect 9.0.x
# Check NVD: https://nvd.nist.gov/vuln/search/results?query=tomcat+9.0.50

# 2. Hunt for existing web shells on the server
# Web shells are typically PHP/JSP files with eval/exec capabilities
# Search for suspicious JSP files (Tomcat web shells)
find /var/lib/tomcat/webapps -name "*.jsp" -newer /var/lib/tomcat/webapps/ROOT/index.jsp
find /var/lib/tomcat/webapps -name "*.jspx" -o -name "*.war"

# Search for common web shell indicators in existing files
grep -r "Runtime.exec\|ProcessBuilder\|getRuntime\|cmd.exe\|/bin/sh" \
/var/lib/tomcat/webapps/ --include="*.jsp"

# 3. Check access logs for web shell access patterns
# Web shells accessed via GET/POST with cmd= or similar parameters
grep -E "(cmd=|exec=|command=|shell=|pass=)" /var/log/tomcat/localhost_access_log.*.txt

# 4. Look for anomalous POST requests to .jsp files not in your application
awk '$6 == "\"POST" {print $7}' /var/log/tomcat/localhost_access_log.*.txt | \
sort | uniq -c | sort -rn | head -20

# 5. Enable file integrity monitoring for the webapps directory
apt install aide
aide --init
# Run regularly and alert on new/modified JSP files

Strategic Actions:

  • Deploy a WAF rule blocking common web shell interaction patterns
  • Enable application-level logging (Tomcat access + error logs → SIEM)
  • Patch to latest Tomcat 9.x release
  • Implement egress filtering web shells typically initiate outbound C2; blocking outbound on the app server prevents the connection

Diamond Model Investigation (if compromise suspected):

Known: Capability (web shell, JSP backdoor)

▼ Pivot 1: Find the specific file hash
→ VirusTotal, MalwareBazaar lookup
→ Pivot to known malware family

▼ Pivot 2: From malware family → C2 infrastructure
→ Passive DNS: what IPs has the C2 domain resolved to?
→ Shodan: what other services run on that C2 IP?

▼ Pivot 3: From C2 infrastructure → other victims
→ Threat intel sharing: who else has seen this C2?
→ MISP community, FS-ISAC, sector ISAC

▼ Pivot 4: From victims + techniques → adversary attribution
→ Matches APT41 TTPs? (MITRE ATT&CK G0096)
→ Consistent with targeting (telecom sector)

This systematic pivoting turns a single web shell into a full picture of the intrusion, the actor, and potentially other compromised organizations.


Question 3

Examine the following YARA rule and identify two technical problems that would cause it to either not detect the target malware or generate excessive false positives:

rule BadRule_Example
{
strings:
$str1 = "cmd.exe"
$str2 = "powershell"
$str3 = "http"
condition:
any of them
}
Reveal Answer & Explanation

Answer: The strings are too generic (massive false positives) and the condition any of them is far too broad.

Explanation:

Problem 1 Overly generic strings → catastrophic false positive rate

  • "cmd.exe" appears in thousands of legitimate Windows binaries, batch scripts, installers, documentation files, and log entries
  • "powershell" appears in any script, log file, or tool that references PowerShell
  • "http" appears in virtually every application, library, and text file on the internet

This rule would flag nearly every executable, script, and document on a Windows system. It has near-zero detection specificity.

Problem 2 any of them condition is maximally permissive

The condition fires if even one of three extremely common strings is present. This guarantees millions of false positives.

Additional problems:

  • No wide ascii modifier misses Unicode strings (many PE files store strings as wide/UTF-16)
  • No file size constraint scanning 500MB log files for "http" is expensive and will match
  • No file type anchor (MZ header check) applies to all file types, not just executables

Corrected rule:

rule BetterRule_SuspiciousDropper
{
meta:
description = "Detects dropper with PowerShell download cradle and execution"
author = "SecurityTeam"
date = "2024-01-15"
mitre_attack = "T1059.001, T1105"

strings:
// Specific PowerShell download cradle patterns not just "powershell"
$ps_download1 = "IEX(New-Object Net.WebClient).DownloadString" wide ascii nocase
$ps_download2 = "Invoke-Expression" wide ascii nocase
$ps_enc = " -encodedcommand " wide ascii nocase

// Specific suspicious cmd patterns not just "cmd.exe"
$cmd_bypass = "cmd.exe /c powershell" wide ascii nocase
$cmd_hidden = "-WindowStyle Hidden" wide ascii nocase

// Specific C2 pattern not just "http"
$c2_pattern = /https?:\/\/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\/[a-z]{4,8}\.php/ ascii

condition:
uint16(0) == 0x5A4D // Must be PE file (MZ header)
and filesize < 5MB // Reasonable size constraint
and (
2 of ($ps_download1, $ps_download2, $ps_enc, $cmd_bypass, $cmd_hidden)
or $c2_pattern
)
}

Key improvements: specific multi-word patterns, wide ascii modifier, PE file anchor, file size limit, higher confidence threshold (2 of N), regex for C2 pattern specificity.


Question 4

You are threat hunting and notice the following DNS query pattern in your network logs over a 24-hour period:

08:14:23  src=10.0.1.55  query=aGVsbG8.updates.microsoft-patch[.]net  type=A
08:44:31 src=10.0.1.55 query=d29ybGQ.updates.microsoft-patch[.]net type=A
09:14:18 src=10.0.1.55 query=dGhpcw.updates.microsoft-patch[.]net type=A
09:44:52 src=10.0.1.55 query=aXMgYQ.updates.microsoft-patch[.]net type=A

Identify the attack technique, decode what is being transmitted, explain the beaconing pattern, and describe how you would investigate and remediate this.

Reveal Answer & Explanation

Answer: DNS tunneling C2 beacon data encoded in Base64 subdomains at 30-minute intervals. The domain is typosquatting Microsoft.

Explanation:

Step 1 Identify the technique

This is T1071.004 Application Layer Protocol: DNS (DNS tunneling). The attacker is encoding data in DNS query subdomains to exfiltrate data or maintain C2 communication, bypassing network controls that only inspect HTTP/HTTPS.

Step 2 Decode the subdomains (Base64)

echo "aGVsbG8" | base64 -d    # → "hello"
echo "d29ybGQ" | base64 -d # → "world"
echo "dGhpcw" | base64 -d # → "this"
echo "aXMgYQ" | base64 -d # → "is a"
# Full decoded message: "hello world this is a..." (ongoing exfiltration)

Step 3 Identify the beaconing pattern

Timestamps: 08:14, 08:44, 09:14, 09:44 → exactly 30-minute intervals. This is a classic C2 beacon sleep interval. The malware wakes up every 30 minutes, encodes a data chunk or status beacon as a subdomain, and queries the attacker's DNS server. The attacker receives the data in their DNS server logs.

Step 4 Domain analysis

microsoft-patch[.]net this is a typosquatted domain impersonating Microsoft. Microsoft's legitimate domains are microsoft.com they do not use .net for patch infrastructure. The registrant controls the DNS server, so all queries (data) go directly to the attacker.

Step 5 Investigation

# 1. Identify the compromised host
# src=10.0.1.55 get hostname and owner
nslookup 10.0.1.55
# Query AD/DHCP logs for lease history

# 2. Check full DNS query history for this host
# In your SIEM (Splunk example):
# index=dns src_ip="10.0.1.55" | stats count by query | sort -count

# 3. Check if domain is known malicious
dig microsoft-patch.net # Does it resolve?
curl "https://www.virustotal.com/api/v3/domains/microsoft-patch.net" \
-H "x-apikey: YOUR_KEY"

# 4. Calculate entropy of subdomains to confirm encoding
python3 -c "
import math, base64
subdomains = ['aGVsbG8', 'd29ybGQ', 'dGhpcw', 'aXMgYQ']
for s in subdomains:
p = [s.count(c)/len(s) for c in set(s)]
e = -sum(x*math.log2(x) for x in p)
try:
decoded = base64.b64decode(s + '==').decode()
except:
decoded = '?'
print(f'{s} → entropy={e:.2f}, decoded={decoded}')
"

# 5. Isolate the host immediately
# Block 10.0.1.55 at the network level
iptables -A FORWARD -s 10.0.1.55 -j DROP
# Or VLAN quarantine via switch config

# 6. Sinkhole the domain at your DNS resolver
# Bind9: redirect to 0.0.0.0
echo 'zone "microsoft-patch.net" { type redirect; masters { 127.0.0.1; }; };' \
>> /etc/bind/named.conf.local

Remediation:

  • Deploy DNS security (filtering of DGA-like subdomains, query length limits)
  • Alert on DNS queries with Base64-encoded subdomains > 20 chars
  • Block DNS queries to non-approved resolvers (force all DNS through your controlled resolver)
  • Deploy DNS-layer security (Cisco Umbrella, Cloudflare Gateway, Pi-hole with threat feeds)

SIEM detection rule:

# Sigma: DNS tunneling via long subdomain
title: Potential DNS Tunneling - Long Subdomain
detection:
selection:
dns.question.name|re: '^[A-Za-z0-9+/]{20,}\.[a-z0-9-]+\.[a-z]{2,}$'
condition: selection
level: high