Log4j RCE Scare, Airport Cyberattack, and Ransomware Claims: A Defender's Response Playbook

This week's under-the-radar roundup carries a consistent theme that every SOC lead should internalize: the gap between a claim and a confirmed compromise is where defenders either shine or burn cycles. A newly reported critical code-execution flaw in Apache Log4j triggered a fresh patching scramble across Java estates — echoing, uncomfortably, the December 2021 mobilization. Simultaneously, Manchester Airports Group (MAG) — operator of Manchester, London Stansted, and East Midlands airports — disclosed a cyberattack, a ransomware gang publicly claimed an encryption-based incident against U.S. Bank (which the bank has pushed back on), and the purported Carhartt breach turned out to contain at least partly fabricated data. Meanwhile, Washington levied new sanctions against Iranian hackers, and the security startup Minimus announced it is shutting down.

For practitioners, the actionable items are clear: (1) verify your Log4j exposure and hunt for exploitation attempts now, before exploit code matures; (2) build a disciplined process for validating extortion claims before they trigger crisis-mode spending; and (3) review any dependency on Minimus tooling. This post covers each from a defensive standpoint.

Technical Analysis

1. The Log4j Critical Code-Execution Scare

Affected component: Apache Log4j 2, the ubiquitous Java logging library embedded in thousands of commercial and in-house applications — from Apache Struts and Elasticsearch derivatives to vendor appliances where the library is buried inside a JAR you'll never see in a dependency manifest.

How this class of flaw works: Log4j code-execution vulnerabilities historically fall into two buckets:

• JNDI lookup injection (the Log4Shell pattern): attacker-controlled strings passed into log statements (user-agent headers, form fields, chat messages, usernames) trigger outbound LDAP/RMI/DNS lookups that fetch and instantiate a malicious Java object from an attacker server. The kill chain is: untrusted input → logged string → lookup resolution → remote class loading → code execution in the JVM context.
• Deserialization abuse: attacker-controlled serialized objects delivered to an appender (e.g., SocketAppender or JDBC appender with attacker-influenced configuration) instantiate gadget chains already present on the classpath.

In both cases, the defender-observable fingerprints are remarkably consistent, regardless of the specific bug: the Java process makes unexpected outbound connections (typically LDAP 389/636, RMI 1099, or DNS with encoded subdomains), and the JVM spawns child processes it never should — shells, curl/wget, or scripting interpreters.

Exploitation status: As of publication this is a developing situation — a critical-severity claim driving urgent version verification, not yet a mass-exploitation event on the scale of 2021. Treat that as a window, not a reprieve. Log4Shell PoCs appeared within hours of disclosure in 2021; assume the same timeline compression applies here. Whether or not a given instance lands in CISA's Known Exploited Vulnerabilities catalog, internet-facing Java applications should be treated as contested territory the moment technical details go public.

2. Manchester Airports Group Cyberattack

MAG confirmed a cyberattack affecting its operations. Aviation and transport infrastructure remains a high-value target for both financially motivated actors and state-aligned groups seeking disruptive impact. Airports aggregate identity data (passenger manifests, employee credentials), operational technology dependencies, and just-in-time logistics — meaning even an IT-side incident can cascade into physical disruption. Details remain limited; the defensive lesson is about sector-specific hardening and segmentation, addressed below.

3. U.S. Bank Extortion Claim and the Carhartt "Breach" That Wasn't

A ransomware gang claimed an encryption-based attack against U.S. Bank; the bank responded to the claims without confirming a compromise. Separately, data circulating as a Carhartt breach was determined to be at least partly fabricated — recycled, synthetic, or padded records assembled to inflate a leak's credibility.

This is not noise; it is an attack pattern. Extortion actors routinely repackage old credential dumps, fabricate row counts, and claim victims they never touched to build reputation, pressure future targets, and pollute breach-notification pipelines. If your threat intel or legal team treats every dark-web claim as a confirmed breach, you will hemorrhage incident-response budget on fiction.

4. Iranian Hacker Sanctions and Minimus Shutdown

New U.S. Treasury sanctions against Iranian hackers reinforce a compliance reality: paying or facilitating ransom to sanctioned entities creates OFAC liability exposure. If your organization is hit by an actor who is later sanctioned, your ransom-payment decision chain must include sanctions screening. Separately, Minimus — a container/application security startup — announced it is winding down. If Minimus is in your stack, you now have an orphan-tooling risk: an unmaintained security control is often worse than none, because it projects false assurance.

Detection & Response

The highest-value hunting right now is on the Log4j attack surface, since the exploitation pattern is well-understood from the 2021 campaign and the signatures transfer directly.

Sigma Rules

---
title: Java Process Spawning Shell or Script Interpreter
tid: 8f3a2c91-4b7d-4e5a-9c1f-2d6e8a0b3f47
status: experimental
description: Detects Java/Tomcat application server processes spawning command shells or script interpreters, a hallmark of successful Log4j-style remote code execution in the JVM.
references:
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\tomcat9.exe'
      - '\tomcat8.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\curl.exe'
      - '\certutil.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; legitimate Java management tooling occasionally invokes scripts
level: high
---
title: JNDI Injection Pattern in Web Server Request
id: 1c9e4b52-7d3a-4f8c-b2e6-5a0d9f1c8e34
status: experimental
description: Detects JNDI lookup injection patterns (${jndi:ldap, rmi, dns}) in web proxy and WAF logs, indicative of Log4j exploitation attempts against Java applications.
references:
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '${jndi:'
      - '%24%7Bjndi'
      - '%24%7b%6a%6e%64%69'
      - '${lower:j}'
      - '${upper:J}'
  selection_header:
    User-Agent|contains:
      - '${jndi:'
      - '%24%7Bjndi'
  condition: 1 of selection*
falsepositives:
  - Vulnerability scanners and authorized penetration tests
level: critical
---
title: JVM Outbound LDAP or RMI Connection
id: 4d7b8e21-9f3c-4a5d-8e1b-6c2f0a9d3b58
status: experimental
description: Detects Java processes initiating outbound connections to LDAP or RMI ports, a key stage of JNDI-based Log4j exploitation where the victim fetches a malicious remote object.
references:
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    Image|endswith:
      - '\java.exe'
      - '\javaw.exe'
    DestinationPort:
      - 389
      - 636
      - 1099
      - 1389
  filter_internal:
    DestinationIp|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
  condition: selection and not filter_internal
falsepositives:
  - Java applications legitimately integrating with external directory services
level: high

For Linux estates, port the first rule to product: linux with ParentImage|endswith: '/java' and children sh, bash, curl, wget, python, perl — that pairing fires on real intrusions and almost nothing else.

KQL — Microsoft Sentinel Hunt for Log4j Exploitation Attempts

This query assumes web/proxy logs ingested via CommonSecurityLog (CEF) or Syslog, plus endpoint network telemetry via Defender. Run it across the last 14 days, then pivot to any host with hits for deeper triage.

let JndiPatterns = dynamic(["${jndi:", "%24%7Bjndi", "%24%7b%6a%6e%64%69", "${lower:", "${upper:", "${env:", "${sys:"]);
let WebHits =
    CommonSecurityLog
    | where TimeGenerated > ago(14d)
    | where RequestURL has_any (JndiPatterns) or RequestClientApplication has_any (JndiPatterns) or AdditionalExtensions has_any (JndiPatterns)
    | project TimeGenerated, SourceIP, DestinationIP, DestinationHostName, RequestURL, RequestClientApplication, DeviceAction;
let EndpointC2 =
    DeviceNetworkEvents
    | where TimeGenerated > ago(14d)
    | where InitiatingProcessFileName in~ ("java.exe", "javaw.exe", "java")
    | where RemotePort in (389, 636, 1099, 1389)
    | where not(RemoteIP startswith "10." or RemoteIP startswith "192.168." or RemoteIP startswith "172.16.")
    | project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl;
WebHits
| union EndpointC2
| sort by TimeGenerated desc

Follow-on triage for any matching host: check DeviceProcessEvents for java.exe as InitiatingProcessFileName spawning cmd, powershell, sh, curl, or wget within 5 minutes of the network event — that correlation is near-certain active exploitation.

Velociraptor VQL — Hunt JVM Hosts for Post-Exploitation Execution

-- Hunt for Java application servers spawning shells or downloaders (Log4j post-exploitation)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(sh|bash|dash|zsh|cmd\.exe|powershell\.exe|pwsh\.exe|curl|wget|python|perl)'
  AND (
    SELECT Name AS ParentName FROM pslist(pid=Ppid)
  ) =~ '(?i)(java|javaw|tomcat|jetty|jboss|wildfly|weblogic)'

On large fleets, wrap this in a hunt scoped to hosts tagged as running Java application servers (your CMDB or the version-inventory script below can feed that tag list).

Remediation Script — Log4j Inventory and Version Verification (Linux/Unix)

The single most common failure in Log4j response is not knowing where Log4j lives. This script inventories the library across a host and flags end-of-life or vulnerable-branch versions for upgrade.

#!/bin/bash
# Security Arsenal - Log4j 2.x inventory and exposure verification
# Run on application servers, container hosts, and build agents.

REPORT="/var/tmp/log4j_inventory_$(hostname)_$(date +%Y%m%d).csv"
echo "path,jar_name,log4j_version,assessment" > "$REPORT"

# Locate all log4j-core JARs, including those nested in exploded WAR/EAR dirs
find / -xdev \( -path /proc -o -path /sys -o -path /run \) -prune -o \
  -type f -iname 'log4j-core*.jar' -print 2>/dev/null | while read -r JAR; do
    VER=$(basename "$JAR" | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1)
    ASSESS="REVIEW"
    if [ -n "$VER" ]; then
        MAJOR=${VER%%.*}; REST=${VER#*.}; MINOR=${REST%%.*}
        # Flag anything on the 2.x branch below the current fixed release for patching
        if [ "$MAJOR" -eq 2 ]; then ASSESS="UPGRADE_REQUIRED"; fi
        if [ "$MAJOR" -lt 2 ]; then ASSESS="EOL_REPLACE"; fi
    fi
    echo "${JAR},$(basename "$JAR"),${VER:-unknown},${ASSESS}" >> "$REPORT"
done

# Check running JVMs for the dangerous message-lookup flag state
for PID in $(pgrep -f 'java' 2>/dev/null); do
    CMD=$(tr '\0' ' ' < /proc/$PID/cmdline 2>/dev/null)
    echo "$CMD" | grep -q 'formatMsgNoLookups=true' \
        && echo "PID $PID: lookups DISABLED (mitigation present)" >> "$REPORT" \
        || echo "PID $PID: $CMD" >> "$REPORT"
done

echo "Inventory complete: $REPORT"
grep -c UPGRADE_REQUIRED "$REPORT" 2>/dev/null | xargs -I{} echo "{} JAR(s) require upgrade"

For Windows application servers, the equivalent sweep is a recursive filesystem search for log4j-core*.jar under C:\Program Files, C:\ProgramData, and application install roots, cross-referenced against Get-Process java* command lines.

Remediation

Log4j Exposure — Priority Actions

1. Inventory before you patch. The 2021 response taught us that organizations find Log4j in 3–5x more locations than their SBOM suggests — embedded in vendor appliances, shaded into fat JARs, baked into container images. Run the inventory script above across servers, build agents, and container registries. Scan images with Trivy or Grype before assuming a redeploy pulled the fixed base image.
2. Upgrade to the latest Log4j 2.x fixed release published by the Apache Logging Services project. Pull the current advisory directly from logging.apache.org — do not rely on third-party mirrors for version numbers, and verify GPG signatures on release artifacts given this library's supply-chain attractiveness.
3. If you cannot patch immediately, apply layered mitigations:
   • Remove or neutralize the JndiLookup class from the classpath (zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class) on JARs that must remain in service temporarily.
   • Set log4j2.formatMsgNoLookups=true as a JVM argument — note this mitigation covers lookup-injection patterns only, not deserialization-style vectors, so it is a stopgap, not a fix.
   • Egress-filter JVM hosts: deny outbound LDAP/RMI (389/636/1099/1389) and restrict outbound 443 to an allowlist where feasible. This breaks the fetch-the-payload stage even if injection succeeds.
4. Validate compensating controls with a detection test. Fire a benign JNDI canary string (e.g., ${jndi:ldap://your-interactsh-equivalent/}) at your internet-facing apps and confirm both the WAF/proxy log detection and the egress block trigger. If you can't detect your own test, you can't detect an attacker's.
5. Watch CISA KEV daily. If any current Log4j flaw is added, federal civilian agencies face Binding Operational Directive remediation deadlines (typically 2–3 weeks for new entries, days for internet-facing) — use that clock as your own internal SLA.

Ransomware and Extortion Claims — Validation Discipline

• Stand up a claim-validation runbook before you need it. For any dark-web claim naming your organization: verify sample data authenticity against known old dumps (check Have I Been Pwned–style corpuses and your own credential-leak monitoring), confirm whether claimed file trees match your actual directory structures, and hunt internally for the claimed dwell-time window before escalating. The Carhartt case — partly fabricated data — is the norm, not the exception.
• Do not let unverified claims trigger public statements. U.S. Bank's posture — respond to the claim, confirm nothing prematurely — is the correct template. Coordinate legal, comms, and IR through a single decision log.
• Sanctions screening is mandatory before any ransom payment consideration; the newly sanctioned Iranian actors make OFAC exposure a first-order risk. Your IR retainer should include a sanctions-check step.

Aviation/Critical Infrastructure Hardening (MAG Lesson)

• Enforce strict segmentation between passenger-facing IT, corporate IT, and any OT/baggage/operations networks; an IT breach should be physically incapable of grounding flights.
• Review third-party and SaaS dependencies — airport groups commonly inherit incidents through parking vendors, loyalty platforms, and ground-handling partners.
• Pre-stage tabletop scenarios for "IT outage during peak operations" so containment decisions (isolate vs. observe) are pre-authorized.

Minimus Customers

• Identify every workload relying on Minimus images/tooling, set a migration deadline, and treat the unmaintained control as absent in your risk register effective immediately. An unsupported security layer silently drifting out of currency is a liability masquerading as coverage.

Conclusion

The throughline this week is verification under pressure. The Log4j scare rewards teams that can answer "where is our exposure?" in hours rather than weeks — and that answer only exists if inventory and egress controls were built before the headline. The airport attack, the bank extortion claim, and the fabricated Carhartt data all punish organizations that confuse claims with compromises. Build the hunts above, run the inventory today, and put a claim-validation runbook in your IR binder. The next headline will not wait for you to prepare.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub