« Potential Invoke-Mimikatz PowerShell Script Potential Kerberos Attack via Bifrost »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Potential Java Service Exploitation via Suspicious Child Process

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Java Service Exploitation via Suspicious Child Process

edit

Identifies a Java process that accepts an inbound network connection and then spawns a suspicious child process. This may indicate exploitation of a Java service that runs attacker-controlled code, such as one that deserializes untrusted objects.

Rule type: eql

Rule indices:

  • auditbeat-*
  • logs-endpoint.events.*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Linux
  • OS: macOS
  • Use Case: Threat Detection
  • Tactic: Execution
  • Use Case: Vulnerability
  • Data Source: Elastic Defend
  • Resources: Investigation Guide

Version: 109

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Potential Java Service Exploitation via Suspicious Child Process

Some Java services accept inbound connections and deserialize untrusted objects, such as a leftover Log4j socket or collector that rebuilds serialized LogEvent objects through FilteredObjectInputStream. If that path can be reached, an attacker can send a crafted payload to the listening port and get the JVM to run attacker-controlled code. This rule looks for a Java process that accepts an inbound connection on a service port from an ephemeral source port, then quickly starts a suspicious child process (shell, interpreter, curl, or wget) whose working directory is under /opt. That sequence is consistent with remote code execution against a Java listener rather than a normal outbound application callback.

Possible investigation steps

  • Confirm the inbound connection_accepted event: Java was the accepting process, network.direction is ingress, the destination port is a service port (below 49152), and the source port is ephemeral (32768 or higher on Linux; 49152 or higher is typical on macOS).
  • Identify the source IP and determine whether it is expected to talk to this Java service. Internal sources still matter; a collector or socket server exposed only on a private network can still be used for lateral movement.
  • Review the child process that started within a few seconds of the accepted connection. Check process.name, process.command_line, process.working_directory, and the parent/child PID relationship to Java.
  • Inspect the Java process command line and working directory to see which application accepted the connection (for example a service under /opt) and whether it is a known listener that deserializes input.
  • Look for follow-on activity on the same host after the child process: additional shells, file writes under /tmp or /opt, new outbound connections, or persistence changes.
  • Correlate with other alerts on the same host or user around the same time to see whether this is isolated or part of a broader intrusion.

False positive analysis

  • Java services installed may spawn shells or interpreters during install, upgrade, health checks, or administrative scripts. Confirm whether the child command line matches a known maintenance pattern before treating the alert as malicious.
  • Some already-excluded patterns include Flutter tooling, Jira helper scripts, and trivial bash -c probes such as ulimit or echo $$. Add similar exceptions for other trusted /opt applications when the parent Java process and command line are stable.
  • Development or lab collectors that intentionally accept serialized Java objects will match this rule if they also start a shell. Restrict those hosts or exclude the specific service path if that activity is expected.
  • Containerized or non-/opt Java applications are outside this rule’s working-directory constraint and should not be tuned here; investigate those with a broader hunt if needed.

Response and remediation

  • Isolate the affected host from the network to stop further inbound exploitation and limit lateral movement.
  • Stop the suspicious child processes and, if exploitation is confirmed, stop the Java listener that accepted the connection until it can be patched or removed.
  • Capture the Java process command line, listening port, child process command line, and inbound source IP for scoping.
  • Hunt for the same source IP, the same Java service path, and similar child processes on other hosts.
  • Remove or disable unused Java socket servers, collectors, or sample bridges that deserialize untrusted input. Patch remaining Java applications and apply a JVM-wide serialization filter where deserialization cannot be avoided.
  • Restore from a known-good backup if unauthorized files, persistence, or additional malware are found.
  • Escalate to the security operations center or incident response team if the inbound source, child process, or follow-on activity indicates a successful compromise.

Rule query

edit
sequence by host.id with maxspan=5s
 [network where event.action == "connection_accepted" and network.direction == "ingress" and

  process.name : "java" and
  destination.port < 49152  and source.port >= 32768] by process.pid
 [process where event.type == "start" and

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
  process.name : (
    "sh", "bash", "dash", "ksh", "tcsh", "zsh", "ash",  "mksh", "busybox",
    "curl", "wget", "perl*", "python*", "ruby*", "php*", "lua*", "socat",
    "nc", "ncat", "netcat", "netcat.openbsd", "netcat.traditional", "nc.openbsd",
    "nc.traditional", "nohup", "setsid", "disown", "hostname", "whoami", "id"
  ) and
    not process.command_line like~ (
      "bash -c ulimit -u",
      "bash /opt/flutter/bin/flutter*",
      "bash -c echo $$",
      "/bin/bash /opt/python3/bin/jira*",
      "/bin/sh -c env LC_ALL=C /usr/sbin/lpc status*"
    )] by process.parent.pid

Framework: MITRE ATT&CKTM

« Potential Invoke-Mimikatz PowerShell Script Potential Kerberos Attack via Bifrost »