Loading today’s stories
Build1 distinct publisher3 min readUpdated
Wiz says a TeamCity honeypot exposing JDWP was mining Monero within hours, and GreyNoise counted more than 6,000 unique IPs scanning for the protocol in 90 days.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Wiz's research team says an exploitation attempt hit one of its honeypot servers running TeamCity, the JetBrains CI/CD product, and that the attacker obtained remote code execution by abusing an exposed Java Debug Wire Protocol interface before deploying a cryptomining payload and multiple persistence mechanisms [1]. The timing is the part operators should act on: Wiz reports the malware arrived within a few hours of the machine being exposed, and that it saw the same turnaround across multiple attempts [2].
JDWP is a standard feature of the Java platform, built so developers can inspect threads, memory and execution flow in a live application without restarting it [3]. It implements no authentication or access control by default [4]. Exposure therefore hands an attacker full control over the running Java process, which in Wiz's incident was enough to inject and execute arbitrary commands, establish persistence and run malware [5].
The sequence Wiz describes has no CVE in it. The attacker scanned for open JDWP ports, reached the honeypot on port 5005, and sent a JDWP-Handshake to confirm the interface was live [6]. The JVM replied with version details and a list of loaded classes [7]. From there, according to Wiz, the actor followed a structured path to code execution, probably using a variant of the public tool jdwp-shellifier with extra features [8]: query the JVM for classes and methods, locate java.lang.Runtime along with getRuntime() and exec() [9], then build Java strings containing system commands and invoke them through INVOKESTATICMETHOD_SIG and INVOKEMETHOD_SIG [10]. That is the protocol doing its job. There is nothing to patch.
Which is why this belongs on the build desk rather than the appsec desk. The flag developers use tells the JVM to listen for debugger connections on port 5005 and accept them on all interfaces [11]. Wiz lists TeamCity, Jenkins, Selenium Grid, Elasticsearch, Quarkus, Spring Boot and Apache Tomcat among the applications that may start a JDWP server when run in debug mode [12], often without making the risk obvious to the developer [13]. Debug mode in a container image, a CI agent template or a troubleshooting session that never got reverted is the same misconfiguration as an intentional internet-facing debugger.
Scanning volume supports the speed. Using GreyNoise tag-based search, Wiz found more than 6,000 unique IP addresses probing for JDWP endpoints over the previous 90 days [14], an average of roughly 67 new scanning addresses a day [15].
The payload was built to survive a look. Wiz says the attacker used a modified XMRig with a hardcoded configuration, avoiding the suspicious command-line arguments defenders tend to flag [16], and routed through mining pool proxies to hide the wallet address so investigators could not pivot on it [17].
Caveats worth keeping: this is one vendor's honeypot telemetry, and Wiz notes it observed multiple JDWP exploitation attempts from different actors and wrote up a single representative incident, with the published indicators covering all the activity rather than that one case [18].
What to watch: whether 5005 and other agentlib listeners appear in your own egress and ingress data, whether debug flags are baked into base images and agent definitions, and whether the workloads exposed this way stay limited to mining. The access described here is control of the running process [5], and on a build server that process is the one holding the credentials.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The Wiz Research Team observed an exploitation attempt against one of its honeypot servers running TeamCity, a CI/CD tool; investigation determined the attacker 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.
Malware was deployed within just a few hours of exposing the vulnerable machine, and Wiz observed this rapid turnaround across multiple attempts.
The attacker began by scanning for open JDWP ports across the internet; one scan reached the honeypot, which was exposing JDWP on port 5005, and the attacker sent a JDWP-Handshake request to confirm the interface was active and establish a session.
The JVM responded with version details and a list of loaded classes, confirming JDWP was exposed and fully interactive.
Wiz assessed that the attacker followed a structured sequence to achieve remote code execution, likely using a variant of jdwp-shellifier with additional features.
The attacker queried the JVM for available classes and methods, then located java.lang.Runtime and its associated getRuntime() and exec() methods.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-party telemetry, single interested source
The technical chain is documented at protocol level (JDWP handshake, get_all_classes/get_methods, INVOKESTATICMETHOD_SIG/INVOKEMETHOD_SIG, Wireshark captures), with dropper behaviour, persistence locations, payload naming and appendix IoCs, plus a third-party scanning figure from GreyNoise. It is nonetheless one vendor's honeypot narrative with no independent verification of the timeline and no data on real exposed populations, which caps the score.
Active, repeated attacker interest; unknown exposed population
Attacker-side adoption is demonstrably real: exploitation within hours across multiple honeypot deployments, multiple distinct actors, and 6,000+ unique scanning IPs in 90 days (~67/day). What is absent is the defender-side denominator - how many JDWP interfaces are actually internet-exposed and how many production systems were compromised - so the measurement reflects scanning and honeypot activity, not confirmed real-world victim scale.
Slightly overstated: honeypot signal generalised to the wild
The technical claims are well evidenced and stated without inflation, but the framing generalises honeypot-derived speed and scanner counts into a broader in-the-wild exposure narrative without any count of exposed instances, confirmed production victims, or quantified impact. Scanning IPs measure reconnaissance interest, not successful compromise, and the vendor publishing the finding also sells exposure detection - a modest positive gap rather than a large one.
Vendor research promoting its own detection domain
The only source is Wiz's corporate blog. Wiz sells cloud security tooling covering exactly the exposure and cryptojacking detection problems described, and the writeup showcases its honeypot sensor network and research capability. The disclosure is technically candid (acknowledging honeypot methodology, multiple actors, mixed IoCs) and cites third-party GreyNoise data, which tempers but does not remove the commercial interest.
Internally consistent but unverified single-publisher account
Confidence is supported by the specificity and internal consistency of the technical account and by JDWP's well-known lack of authentication, and limited by the absence of any second publisher, any production-victim confirmation, and any exposure-population data. Nothing in the cluster contradicts the account, but nothing independently confirms it either.
build
Your test grid is an RCE surface: SeleniumGreed turns exposed Selenium hubs into miners2 distinct publishers
build
Three services you can delete: queue, cache and search in one Postgres1 distinct publisher
build
2,513 tool calls, zero refactorings: what agents actually do when you ask them to refactor1 distinct publisher
build
A file-copy Allure adapter for Katalon, and the history IDs that make retries useful1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 16, 2026