05 — Defense Playbook: Mitigation & Hardening

Patch Management Timeline

Immediate Actions (Within 24 hours)

Priority 1: Identify Vulnerable Systems - Inventory all Java applications - Identify those using Log4j 2.0 through 2.14.1 - Flag as critical priority

Priority 2: Enable Workarounds (if patches not available) 1. Set JVM flag: -Dlog4j2.formatMsgNoLookups=true 2. Or set environment variable: LOG4J_FORMAT_MSG_NO_LOOKUPS=true 3. Restart applications

Short-term (1-2 weeks)

Upgrade to Log4j 2.17.1 or later
Breaking Note: 2.17.0 disabled JNDI by default; some applications may break
Test patches in non-production first
Deploy patches during change windows

Long-term (Ongoing)

Update vulnerability scanning to detect unpatched Log4j
Automate dependency updates (Dependabot, Renovate)
Regular assessment of transitive dependencies

Configuration Hardening

Disable JNDI Lookups

Option 1: JVM System Property (Safest)

# In application startup script
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

# Or in Docker
ENV JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
RUN java $JAVA_OPTS -jar myapp.jar

Option 2: Environment Variable

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true
./start-app.sh

Option 3: log4j2.properties Configuration

# In log4j2.properties
log4j.formatMsgNoLookups=true

Restrict JNDI Protocols

If you must keep JNDI enabled:

# Only allow specific JNDI protocols
log4j.jndiAllowedProtocols=java

This blocks LDAP/RMI but allows internal Java JNDI references.

Remove JndiLookup Class

For Log4j 2.15.0 (before complete JNDI disable):

# Remove the vulnerable class from the JAR
zip -d log4j-core-2.15.0.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

# Verify removal
unzip -l log4j-core-2.15.0.jar | grep JndiLookup
# (should return empty)

D3FEND Mitigation Techniques

D3-PA: Process Analysis

Monitoring for abnormal process spawning:

KGCS Link: T1059 --MITIGATED_BY--> D3FEND-PA

Technique: Monitor and analyze process creation events
  - Parent: java.exe
  - Child: shell interpreter (cmd, powershell, bash)
  - Baseline: Establish what processes Java should spawn
  - Alert: Any deviation from baseline

Implementation: - Deploy EDR agent on all servers running Java apps - Create baseline of normal processes - Alert on any java → shell spawning - Block suspicious processes

D3-RI: Restrict Input

Validate and sanitize all log inputs:

KGCS Link: CWE-91 --MITIGATED_BY--> D3FEND-RI

Technique: Filter special characters before logging
  - Remove/escape: $ { } $ jndi :
  - Whitelist approach: Only allow alphanumeric + spaces
  - Use Log4j Pattern: %msg{nolookups} (explicit no-lookups)

Code Implementation:

// Sanitize before logging
String userInput = request.getParameter("q");
String sanitized = userInput
    .replaceAll("[${}]", "")  // Remove special chars
    .replaceAll("jndi:", "")  // Remove JNDI strings
    .substring(0, Math.min(userInput.length(), 255));  // Truncate

logger.info("User search: " + sanitized);

D3-NTF: Network Traffic Filtering

Block all outbound LDAP/RMI from app servers:

KGCS Link: T1059 --MITIGATED_BY--> D3FEND-NTF

Technique: Firewall rules to restrict outbound connections
  - Block: TCP/389 (LDAP) from app servers
  - Block: TCP/1099 (RMI Registry) from app servers
  - Block: Unusual DNS queries from app servers
  - Allow: Only known-good outbound destinations

Firewall Rules (iptables example):

# Block outbound LDAP
iptables -A OUTPUT -p tcp --dport 389 -j DROP
iptables -A OUTPUT -p tcp --dport 1099 -j DROP

# Log attempts
iptables -A OUTPUT -p tcp --dport 389 -j LOG --log-prefix "BLOCKED_LDAP: "

SHIELD Deception

Deception-based Detection

Strategy: Create fake targets/responses to detect attackers

KGCS Link: T1059 --COUNTERED_BY--> SHIELD-D

Technique: Deploy honeypots/decoys
  - Decoy LDAP server on non-standard port (e.g., 1389)
  - Decoy RMI registry
  - Monitor for connection attempts
  - Any connection = confirmed attack attempt

Implementation:

# Decoy LDAP server (using rogue-jndi or similar)
java -jar rogue-jndi.jar --listen 0.0.0.0:1389 --command "echo 'Deception trap triggered'"

# Decoy RMI service
java -jar decoy-rmi-registry.jar --port 1099

# Monitor access logs for suspicious connections
tail -f /var/log/decoy-ldap.log | grep "bind"
# Any entry = exploitation attempt

ENGAGE Tactics

Engagement Through Analytics

Strategy: Engage attackers through deceptive behavior

KGCS Link: T1059 --DISRUPTS--> ENGAGE concepts

Techniques:
  1. Logged monitoring — Log failures in a way that makes
     attackers think they're succeeding (social engineering)
  2. Threat hunting — Proactive search for exploitation attempts
  3. User awareness — Train developers to not log user input naively

Incident Response Playbook

If Log4Shell exploitation detected:

Immediate (0-5 min):
- Alert security team
- Isolate affected system if RCE confirmed
- Preserve logs and memory
Short-term (5-30 min):
- Patch or disable Log4j on affected systems
- Block attacker's C2 infrastructure
- Review system for lateral movement
Long-term (30+ min):
- Forensic analysis
- Determine what attacker accessed
- Update detection rules
- Security awareness training

Layered Defense Summary

┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1: Patch Management                                       │
│ - Upgrade Log4j to 2.17.1+                                       │
│ - Set -Dlog4j2.formatMsgNoLookups=true as fallback               │
└─────────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 2: Input Validation                                       │
│ - Sanitize user input before logging                             │
│ - Use %msg{nolookups} in Log4j pattern                           │
└─────────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 3: Network Segmentation                                   │
│ - Block outbound LDAP/RMI from app servers                       │
│ - Restrict DNS queries to known-good servers                     │
└─────────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 4: Detection & Monitoring                                 │
│ - EDR process monitoring                                         │
│ - SIEM detection rules                                           │
│ - Decoy LDAP/RMI services                                        │
└─────────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 5: Response & Hunting                                     │
│ - Incident response playbook                                    │
│ - Proactive threat hunting                                      │
│ - Continuous vulnerability scanning                              │
└─────────────────────────────────────────────────────────────────┘

KGCS Defense Coverage

MATCH (t:Technique {attackId: "T1059"})
  -[:MITIGATED_BY]->(d:DefensiveTechnique)
  -[:PART_OF]->(d3fend_category)
RETURN t, d, d3fend_category

Defense count: 7 D3FEND techniques
Detection count: 4 CAR analytics
Deception count: 3 SHIELD tactics

Next Steps

Read: 06 Reasoning Walkthrough — See KGCS analysis

Or Jump To: 07 Live Query Examples — Run queries yourself

Sources: Apache Log4j Security Advisory, MITRE D3FEND, MITRE SHIELD, Incident Response Best Practices