Death by a Thousand PaperCuts: AI-Driven Exploitation at Scale 

Key Takeaways 

• Blackpoint’s Adversary Pursuit Group (APG) identified active exploitation of internet facing PaperCut servers using CVE-2026-81578 and CVE-2026-82078, then traced the activity back to exposed operator infrastructure that revealed the development project behind the campaign. 

• The recovered directory structure preserves an AI assisted workflow from vulnerability research through proof of concept development, tooling hardening, target sourcing, campaign execution, failure analysis, code changes, and repeated retry waves. 

• Timestamped state files read like persistent coding agent context. They record completed work, blockers, next hypotheses, user interruptions, code changes, current campaign status, and the exact artifacts needed for a later session to continue. 

• Targeting was handled as a funnel rather than a single scan. Multiple source lists were merged, candidates were geolocated and filtered by country, reachability was checked before more expensive stages, and completed targets were removed from future processing. 

• The recovered campaign managed a target set of more than 500 systems, with tooling built to process up to 200 targets concurrently and recycle incomplete or failed systems through as many as 100 retry rounds while preserving successful results between runs. 

• The strongest AI impact in this campaign was not a novel exploit technique. It was the reduction of human effort required to research, develop, debug, classify, track, retry, and continuously improve exploitation across hundreds of real systems. 

Executive Summary 

The Adversary Pursuit Group (APG) uncovered a PaperCut exploitation campaign while investigating malicious activity involving an internet facing PaperCut server. The activity leveraged the recently disclosed CVE-2026-81578 and CVE-2026-82078 vulnerabilities to exploit the application. Analysis of the incident led the APG to infrastructure associated with the campaign at 45.142.193[.]132, where an exposed HTTP directory revealed a much larger collection of operator tooling, research material, target lists, campaign outputs, and development artifacts. 

The identified directory structure showed that the campaign extended well beyond a single PaperCut proof of concept. Recovered files documented vulnerability research, comparisons between patched and unpatched PaperCut builds, proof of concept development, multithreaded scanning and exploitation tooling, target filtering, failure classification, retry logic, and timestamped state files that preserved the project’s progress over time. 

The earliest recovered activity began on August 31, with the project focused on vulnerability research and comparing patched and unpatched PaperCut builds. Within hours, that research had been turned into a multithreaded validation tool that was reviewed, tested, and run against progressively larger target sets. When the user interrupted a longer scan, the project context preserved what had happened and recorded the next engineering steps: add a cheaper prefilter, shorten timeouts, and avoid spending the heavier probe on systems that did not appear to be running PaperCut. 

The targeting pipeline was similarly automated. Recovered code merged multiple source buckets, geolocated targets, applied a country exclusion policy, deduplicated URLs, and removed systems that had already been completed. Separate reachability scripts used 32 and 80 workers to identify live PaperCut systems before heavier processing. The campaign then classified targets by operating system, environment, failure reason, and missing stage rather than treating every unsuccessful attempt as the same problem. 

This campaign offers a rare look at how threat actors are starting to use AI across the exploitation lifecycle, not just to help write code, but to support the engineering and operational work surrounding exploitation. The recovered project shows that workflow in action, carrying context forward, working through failures, updating tooling, refining target sets, and retrying what remains incomplete. The underlying techniques are familiar, but AI makes it much easier to turn them into a repeatable process that can be operated across hundreds of targets. 

Technical Analysis 

It Started With a PaperCut 

The investigation began after Blackpoint contained active exploitation of an internet facing PaperCut Application Server. At a high level, CVE-2026-81578 provided a path for unauthenticated manipulation of PaperCut configuration, while CVE-2026-82078 allowed unsafe database connector behavior to be turned into code execution within the PaperCut application process. Together, the vulnerabilities gave an attacker a path from an unauthenticated web request to arbitrary code execution in the context of the PaperCut service. From there, Blackpoint’s APG traced the activity to associated infrastructure at 45.142.193[.]132, where a publicly exposed HTTP directory revealed the tooling and workflow surrounding the campaign. 

The exposed directory contained a much broader collection of operator tooling. The recovered structure included development files, target lists, campaign output, helper utilities, state files, and multiple generations of proof of concept code. At the root level, directories such as state, work, artifacts, and output sat alongside standalone PaperCut development scripts. A separate archive in the same environment contained an earlier pupercut project with its own state, targets, findings, poc, artifacts, and work directories. 

The root directory gives a clear snapshot of how the project was organized, with research, active development, campaign state, and execution output all sitting alongside one another (Figure 1). 

Figure 1: Screenshot showcasing the root directory 

That structure also made it possible to follow how the project evolved over time. The source code showed what the tooling could do at each stage, while the target and output directories captured how those capabilities were being used. The various markdown state files added the missing context, recording what had already been completed, what was still blocked, what needed to happen next, and where the relevant artifacts were located. Together, those pieces provided a running history of both the campaign and the development work behind it. 

This was also where the AI angle became much more interesting than the usual story of a threat actor asking a chatbot to write an exploit. Several recovered state files were written from the perspective of an assistant working through tasks for a user. One August 31 entry said the project was “building the material dump requested by user,” while a later checkpoint noted that a long scan had been “interrupted by user” before recording the next engineering changes to make (Figure 2). Hindsight, a persistent memory layer for AI agents, and AionUI, an interface for coordinating agent driven workflows, were also present in the broader operator environment, providing additional context around how AI could be used to preserve project state and orchestrate work across the campaign. 

Figure 2: State file showing assistant directed project context 

The recovered project showed AI assistance embedded throughout development and campaign management rather than limited to code generation. Hindsight’s persistent memory model and AionUI’s agent orchestration interface fit the workflow preserved in the state files: project context was carried between sessions, tools were run, files were updated, failures were worked through, and completed work, blockers, and next steps were continuously carried forward. 

Proof of Concept, Meet Production 

The earliest recovered project state still looked more like vulnerability research than an active exploitation campaign. The operator was collecting PaperCut advisories and release information, identifying patched and unpatched versions, searching for existing public research, and preparing to compare affected builds. Just as importantly, the state preserved the next steps for the project, showing that the work was being treated as an ongoing development effort rather than a one off research exercise. 

That research quickly moved into hands on testing. Patched and unpatched PaperCut builds were extracted and compared, the relevant code changes were documented, and the suspected code execution path was reproduced inside a local lab. At this stage, the project specifically noted that live code execution had not yet been attempted against public systems, making the transition from research into controlled validation unusually clear (Figure 3). 

Figure 3: Local validation of the PaperCut execution path 

Once the exploitation path had been validated locally, the focus shifted toward building tooling that could process real target sets. A Go-based checker introduced parallel processing, HTTP and HTTPS fallback, structured JSON output, and logic for sorting results into useful categories. Initial runs were deliberately limited, giving the operator a way to evaluate multiple PaperCut systems at once while still keeping the testing controlled. 

The checker did not remain static for long. Early runs exposed issues with output handling and session behavior, which were carried directly back into development. The project added unit tests and ran the code through race detection, vetting, formatting, and additional builds. This iteration is important because it shows the workflow doing more than simply generating a functional script. Each execution acted as a test cycle, with failures and edge cases feeding directly into the next version of the tooling. 

With those fixes in place, the checker was expanded to a much larger normalized target set using significantly greater concurrency. That run was ultimately interrupted, but the failure itself became part of the development process. The project state captured what had happened and immediately translated the problems into concrete engineering changes: add a cheaper prefilter, reduce connection timeouts, and reserve the heavier probe for systems that actually resembled PaperCut. Rather than treating the incomplete scan as a dead end, the operator used it as input for the next iteration of the tooling (Figure 4). 

Figure 4: Interrupted scan and planned engineering changes 

This progression shows how quickly the project evolved from vulnerability research into tooling designed for scale. The development cycle moved from collecting vulnerability material and comparing builds, to local exploitation validation, to a multithreaded checker, code hardening, and increasingly larger target sets. More importantly, it established a feedback loop that persisted throughout the campaign: build, test, observe failures, make changes, and run again. 

As the checker matured, the project shifted from improving the exploitation workflow to preparing a much larger target pool for it. Recovered CSV and JSON datasets were parsed and normalized into inventories containing more than 15,000 unique IP and port combinations, host and port combinations, and endpoints. These datasets were explicitly preserved as future input for the checker once the faster prefiltering logic was ready. 

The accompanying latest.md file illustrates how the operator maintained continuity across this development cycle. Rather than recording only the most recent command, it summarized the vulnerability research, local testing, checker development, code fixes, interrupted scans, normalized target lists, current blockers, next actions, and the locations of relevant artifacts. A later session could resume the project with a clear understanding of what had already been tested, what had failed, and what needed to happen next (Figure 5). 

Figure 5: Project state and next steps preserved in latest.md 

The same pattern continued as the campaign expanded. Later state files moved away from research questions and began documenting operational problems such as failed connections, incomplete stages, interference from security tooling, and bugs exposed by concurrency. The specific problems changed, but the development model remained consistent. Each state captured what had happened, what still required attention, and what the next session should attempt. 

That continuity is one of the clearest indications that this was more than a collection of isolated AI-generated code snippets. The operator was using an iterative development process in which AI-supported research, coding, testing, troubleshooting, and campaign execution continuously informed one another. Context was preserved as the project moved from vulnerability research to exploit validation, tooling development, target expansion, and eventually operational execution. 

As the target pool grew, the next engineering problem was no longer simply whether the exploit worked, but how to determine which systems were worth processing at scale. That requirement drove the next layer of automation around target sourcing, normalization, reachability checks, filtering, and removal of systems that had already been processed. 

Finding Needles at Scale 

Once the checker was working reliably, the problem changed. The project no longer needed to answer whether a PaperCut system could be tested; it needed to decide which systems were worth spending time on. The later work/ tree shows that target handling had become its own pipeline, with multiple input sources, deduplication, geographic filtering, reachability checks, environment classification, and separate queues for systems that needed different kinds of follow up. 

The broadest recovered list, papercut_master.txt, contained 4,107 unique IP addresses, but it was only one input into a larger target-building workflow. audit_all_targets.py merged four logical buckets named old, netlas, master, and new_rce into a single working set (Figure 6). The Netlas-labeled dataset contributed 57 unique IPs, including 26 that were not already present in the master list, showing how additional discovery sources were being folded into the campaign as it evolved. The recovered files do not preserve the original Netlas query or the exact process that produced papercut_master.txt, but they do show the surrounding scripts continuously combining and rebuilding target data into new working lists. 

Figure 6: Target sources merged into the working set 

Geography was also built directly into the target pipeline. audit_all_targets.py used local geolocation data to attach country codes before applying an exclusion list, while drop-countries.txt contained 28 country codes that were removed from the allowed set. This was not just a one time filter. Later state files show the list being adjusted as the campaign progressed, including the removal of Cambodia and Sri Lanka from active inputs and a later instruction to keep Brazil, South Africa, Nigeria, and Zimbabwe out of new stage lists (Figure 7). 

Figure 7: Country exclusions applied to active target lists 

The files do not explain why those countries were excluded, but the exclusions were clearly part of the campaign’s normal target management. The policy was not static either. As the operation progressed, countries were added or removed from active lists, and those changes were carried into later stages of the workflow. 

TLS data was collected as another layer of context around the target set. new-tls-san.tsv recorded certificate subjects, alternative names, and issuer information for discovered systems. There is not enough evidence to say those fields directly decided whether a target moved forward, but they gave the project additional information it could use while sorting and tracking PaperCut servers. 

More importantly, the target pool was not static. Later state files show new systems continuing to enter the workflow after the initial lists had already been built. One September 2 checkpoint recorded four new targets being added to the completed set while noting that a broader master-geo-new-added group was still waiting to be worked. That shows the campaign continuing to absorb newly identified PaperCut systems rather than simply exhausting a fixed list and stopping (Figure 8).  

Figure 8: New targets added while broader processing remained 

Those new candidates still had to prove they were worth the heavier processing. build_reachable_lists.py used a 32 worker pool to request the PaperCut /app endpoint, falling back from HTTP to HTTPS when needed and separating results into PaperCut, reachable, and unreachable groups. That gave the rest of the workflow a cleaner working set before more expensive stages were attempted. 

A later helper, probe_current_rest.py, made that optimization even more explicit. Its purpose was to probe remaining PaperCut targets over HTTP and HTTPS before expensive RCE, and it increased the worker pool to 80. By this point, the project was treating exploitation as something to reserve for systems that had already passed cheaper checks rather than throwing the full chain at every candidate (Figure 9). 

Figure 9: Reachability probing before more expensive exploitation 

Completed systems were filtered out as well. merge_master_targets.py checked existing results for targets already marked successful and excluded them when rebuilding the next working list. This kept the active queue focused on newly identified or incomplete systems instead of repeatedly processing targets that had already finished the workflow. 

The same pattern shows up throughout work/lists/. Rather than maintaining one giant target file, the project kept separate lists for systems that were ready, active, unreachable, missing specific stages, eligible for certain follow up actions, or waiting on another attempt. Many of those files were not new discovery sources at all. They were snapshots of the same target population at different points in the campaign. 

The retry tooling made those distinctions useful. build_callback_retry.py searched failed results for conditions that matched the callback path and produced a new list containing only those systems. build_h2_retry.py did the same for a specific H2 failure. Instead of throwing every failed target back into the same queue, the project could separate them by what actually went wrong and build the next run around that problem. 

That sorting continued as more was learned about each system. Windows hosts were separated from Linux systems, domain joined environments were distinguished from WORKGROUP hosts, and targets that had already completed some stages could be grouped by whatever was still missing. The target lists became less about where a system came from and more about what still needed to happen to it. 

The scale of that workflow was already visible in the first full runner checkpoint on September 1. That state recorded 517 targets being passed into the campaign runner, with administrator creation and verification, proxy startup, route collection, and vCenter candidate collection enabled. At that point, the project had moved well beyond identifying vulnerable PaperCut servers. It was trying to push hundreds of qualified targets through a broader post exploitation workflow while keeping track of where each one succeeded or stopped (Figure 10). 

Figure 10: Campaign runner processing 517 targets 

This is where the targeting pipeline starts to connect back to the AI assisted workflow. The scripts handled the predictable parts, but the campaign kept reshaping its own working set based on what happened next. New systems were added, completed systems were removed, failures were split into narrower queues, and partially completed targets were carried forward with their existing state. The result was not just a scanner feeding an exploit, but a campaign that continuously reorganized itself around what still required attention. 

Campaign as Code  

The most revealing part of the project came after the target funnel was already in place. By September, the tooling was no longer focused on simply finding vulnerable PaperCut servers. It was keeping hundreds of partially completed targets moving, tracking what had worked, identifying what was still missing, and changing the surrounding code when real environments broke the assumptions built into earlier versions. 

That scale was explicit in retry_loop.sh. The wrapper was configured for 200 concurrent threads and could continue for as many as 100 rounds, while preserving successful results and returning incomplete or failed systems to later passes. Administrator creation, verification, proxy startup, and incremental processing were all built into the run. The exploit itself was only one step inside a much larger campaign loop that decided what should be attempted again and what could be left alone (Figure 11). 

Figure 11: Retry loop configured for 200 threads and 100 rounds 

Completion was also more nuanced than a single success flag. validate_kits.py checked whether later stages had actually finished, including administrator access, account verification, Active Directory collection, proxy readiness where applicable, and machine account material when it was still required. A system could therefore have working code execution and still remain unfinished because one or more of the outcomes the campaign cared about had not been reached (Figure 12). 

Figure 12: Stage validation logic for completed target kits 

That distinction matters because exploitation was only the beginning of what the framework considered useful. The target kit continued into privileged access, credential collection, domain and network discovery, and proxy preparation. Those capabilities matter defensively, but for this story the more important point is how they were tracked. The campaign was not counting vulnerable servers. It was trying to turn each successful exploit into a reusable foothold, while preserving enough state to come back and finish whatever remained. 

A recovered failure summary shows what happened once the campaign started running into real world edge cases. unknown-failures-2026-09-01.md grouped 291 failed targets by what actually went wrong instead of treating them as one generic failure bucket. The largest group, 161 systems, reached the trigger but never served the expected output. Another 60 reached execution but failed during administrator creation, 56 failed while updating the PaperCut configuration, 12 timed out, and 2 fell into smaller application or network cases. 

Reason	Count	Recovered meaning
output_404	161	The chain reached its trigger, but the expected output file was not served.
rce_failed	60	Execution worked, but the administrator creation command failed.
config_fail	56	The configuration update was not accepted.
timeout	12	Network or HTTP timeout.
no_home / other	2	No PaperCut home page or a connection reset during configuration.

The 60 execution failures were then broken down again. Nineteen returned Windows access denied errors, at least seventeen could not reach the expected domain context, seven were non-Windows systems where the Windows net command was unavailable, and two failed during account lookup. Another fifteen were grouped as less common or localized failures.  

That extra classification is important because it turns a failed run into something the project can act on. An access denied error, a missing domain, and a Linux host all need different follow up. By recording those differences, the next pass could be built around the actual problem instead of blindly retrying the same action against every failed system (Figure 13). 

Figure 13: Failure classification across 291 unsuccessful targets 

As the campaign matured, the project stopped relying on a single PaperCut execution path. The recovered workspace included standalone proof of concept code and custom runners, but later states also show the operator incorporating the PaperCut Metasploit module when direct web RCE was unreliable. That path was eventually wrapped into an msf-only mode in the Go runner, with support for Java Meterpreter and later a native Windows Command payload. In other words, the campaign was not tied to one exploit implementation. It could move between different PoC and framework based paths depending on what worked against a given target. 

That flexibility also introduced its own engineering problems. One of the clearest examples appeared when the Metasploit based path was pushed across a larger target set. Every container attempted to bind the same fetch server port, causing the native command payloads to fail at scale. The runner was then changed to assign a unique fetch port to each target, and the same execution mode produced another complete target kit after the fix (Figure 14).  

Figure 14: Fetch port collision identified and corrected 

Another checkpoint caught a regression introduced during that same development cycle. A fix for Windows local administrator logon rights had already been added, but it disappeared from the msf-only path when a SYSTEM scheduled task fallback was introduced. A later audit caught the missing behavior, restored removeDenyPowerShell() in the shared runner, and made the fix part of future MSF runs again. The project was not simply adding new features as problems appeared. It was also checking whether earlier fixes survived later changes to the workflow. 

Protocol handling evolved in the same way. One rights fix pass left a number of systems unfinished until a later state showed that several of them were only reachable over HTTPS. The common code was updated to detect HTTP or HTTPS automatically, and the next pass completed eight additional kits (Figure 15). A difference in how the targets were configured had exposed a weakness in the tooling, and the fix was folded back into the shared path rather than handled as a one off exception. 

Figure 15: HTTP and HTTPS auto detection completing additional targets 

The project also corrected its own validation logic when a success check turned out to be wrong. One checkpoint recorded that the string MSF_SESSION_OK was being matched inside the generated resource command before a real session had actually opened. The check was changed so later runs required evidence of an actual session instead. The interesting part was not the Metasploit syntax itself, but that the workflow caught a bad assumption in its own classifier and changed the logic before continuing. 

Credential collection followed a similar pattern. When EDR blocked helper binaries and larger hive transfers repeatedly failed, the state files preserved both the blocker and the next ideas to try. Later versions moved toward collecting only the smaller registry values needed for local decryption instead of transferring an entire hive. The underlying technique was not novel, but the development cycle was clear: record the failure, change the approach, and carry the working method into later runs. 

The state/ directory tied those changes together. The timestamped files repeatedly captured what had been completed, what was still in progress, what was blocking the next step, what should happen next, and where the relevant artifacts lived. latest.md then carried the important pieces forward as the project grew, including completed target counts, missing stages, code changes, rebuilt batches, and retry decisions (Figure 16). 

Figure 16: State file tracking completed work and campaign progress 

That persistent project state is what allowed the campaign to keep moving without rebuilding context from scratch each time. A later session could see that one subset required HTTPS, another already had AD information, a previous code path had regressed, or a specific failure needed a different retry path. Those decisions were preserved across the state files, target lists, validation results, and updated source code, giving the workflow a working memory of what had already happened and what still needed attention. 

The working set kept getting smaller and more specific as the campaign progressed. On September 3, completed batches and systems without useful AD context were removed from active processing, leaving 398 active AD candidates. Of those, 367 were already classified as failed or incomplete, while 31 had succeeded at earlier stages but were still missing a later credential collection step. A separate audit found 58 additional successful AD kits outside the earlier ready folders, moved 27 already complete systems into a new batch, and sent the remaining 31 back through a narrower retry path (Figure 17).  

Figure 17: Active AD candidate cleanup and targeted retry selection 

By this point, latest.md had become much more than a running notebook. It functioned as the handoff between one working session and the next, carrying forward target counts, completed batches, remaining blockers, code changes, and the next retry paths to use. A later session could see not only what had happened, but what population was still worth working and why. 

This is where the AI assisted part of the campaign becomes most visible. The 200 thread runner, reachability checks, country filters, validators, and retry scripts were deterministic automation. The harder work sat above them: understanding why a run failed, deciding whether the failure was worth another attempt, changing the code, preserving what had already worked, reshaping the target queue, and carrying that plan into the next session. 

AI focused tooling elsewhere in the operator environment added useful context, but the strongest evidence was the behavior of the PaperCut project itself. The timestamped state files, user directed language, repeated code changes, structured failure handling, and constant cycle of run, review, change, and retry all fit an agentic development workflow operating across the campaign. The files do not show that every decision was autonomous, but they do show AI assistance embedded deeply enough that it appears to have helped keep the project moving as the campaign changed. 

The campaign is not evidence of fully autonomous exploitation. Nothing recovered shows an AI model independently discovering a zero day, choosing hundreds of targets, and compromising them without human involvement. What the project does show is narrower and more practical: AI assistance appears to have sat inside the engineering and operational loop that turned vulnerability research into an exploitation pipeline, then helped keep that pipeline running as real world failures, edge cases, and target differences accumulated. 

That changes how much attention an operator has to spend keeping the campaign moving. Traditional automation can retry a command or resume a known stage, but the recovered project went further by preserving failures, narrowing target sets, changing code, and carrying those decisions into later runs. A coding agent style workflow can help with the messy parts between those automated steps, where something unexpected happens and the tooling needs to be adjusted before the campaign can continue. 

The campaign is therefore better understood as a feedback loop than a straight exploit chain. Research and patch comparison fed PoC and checker development, which fed target sourcing, geographic filtering, reachability testing, and environment classification. Qualified systems moved into the campaign runner, where stage validation and failure classification determined what happened next. Those results then drove code changes, narrower retry workflows, and updates to state/latest.md, which preserved the project state for the next iteration (Figure 18). 

Figure 18: AI assisted campaign feedback loop 

The defensive impact extends well beyond PaperCut. The near term advantage of AI in offensive operations may not be the invention of entirely new techniques, but the ability to reduce the work required to turn familiar ones into sustained campaigns. Vulnerability research, target preparation, testing, failure analysis, code changes, and retries can all be tied together into a workflow that preserves context and keeps moving without forcing an operator to manually reconstruct every problem along the way. 

Recommendations 

• Patch and verify PaperCut. Upgrade affected PaperCut NG/MF deployments to the latest fixed release and confirm the running version after installation.  

• Remove unnecessary internet exposure. Restrict PaperCut Application Server and administrative interfaces to trusted IP ranges, VPN access, or private network paths.  

• Treat exploitation as a broader compromise. If exploitation is suspected or confirmed, scope beyond the PaperCut host. Review for privileged account creation, credential access, Active Directory discovery, and internal pivoting.  

• Hunt suspicious PaperCut process activity. Review pc-app.exe and related Java processes for unexpected child processes including cmd.exe, powershell.exe, whoami.exe, wmic.exe, sc.exe, cmdkey.exe, reg.exe, esentutl.exe, and nltest.exe, along with unusual outbound connections.  

• Review privileged accounts and exposed credentials. Search for unexpected administrator creation or group membership changes, then rotate PaperCut stored secrets such as LDAP bind, service, and database credentials. Include machine account and LSA secrets if SECURITY or SYSTEM hive material may have been accessed.  

• Investigate internal pivoting. Review long lived outbound connections from PaperCut servers and connections from those systems to internal hosts they do not normally access.  

• Monitor PaperCut configuration changes. Alert on unexpected changes to user-lookup.db-driver, user-lookup.db-url, user-lookup.id-to-username-sql, and user-lookup.enabled. Review historical changes because the configuration may be restored after exploitation.  

• Sweep for toolkit artifacts. Check temporary directories and the PaperCut installation for save_hives.exe, lsa_collect.exe, pc-*.hiv, pc-*.b64, SocksBrd*.class, SocksBrd*.conf, and related bridge logs.  

• Prioritize behavior over static indicators. Focus detections on PaperCut spawning discovery tools, modifying user lookup settings, creating administrators, accessing registry hives, and establishing unexpected outbound connections. Filenames, account names, and ports can be changed easily. 

Conclusion 

The most interesting artifact in this campaign was not the PaperCut exploit itself, but the project that grew around it. The recovered workspace preserved a progression from vulnerability research and patch comparison into proof of concept development, target qualification, and eventually a campaign capable of processing hundreds of systems while continuously carrying its own state forward. 

That evolution happened quickly. On August 31, the project was still collecting vendor material, testing assumptions, and building its first multithreaded validation tooling. Within hours, that tooling had parallel workers, automated testing, race detection, and normalized target inputs. By September, the same workspace was filtering countries, removing completed systems, classifying failures, validating post exploitation stages, modifying shared code paths, and rebuilding increasingly specific retry queues. 

The state files connected those phases. They preserved hypotheses, blockers, user interruptions, code changes, target counts, retry decisions, and artifact locations in a form that allowed later sessions to continue from where earlier ones stopped. The recovered data does not identify the model behind every change or show that every decision was autonomous, but it does show AI assistance embedded throughout the development and operational workflow. 

The advantage came less from AI inventing new exploitation techniques and more from reducing the work required to keep an existing campaign moving. Building and testing tooling, refining target sets, classifying failures, fixing bugs exposed by scale, preserving partial success, and revisiting only what remained incomplete could all be carried forward as part of the same workflow. The underlying tradecraft was familiar. What changed was how efficiently it could be coordinated across a much larger campaign. 

For defenders, that is the more immediate impact of AI assisted offensive operations. Existing vulnerabilities and well understood post exploitation techniques become more dangerous when the surrounding research, debugging, and campaign maintenance can be accelerated with less operator effort. That acceleration is also shrinking the window between disclosure and exploitation, making continuous monitoring and rapid response increasingly important alongside patching. In this case, the PaperCut vulnerabilities opened the door, but the engineering workflow around them is what turned that opening into something built for scale. 

Indicators of Compromise 

File Indicators 

Indicator	File Name	SHA-256
PaperCut target-kit binary	papercut_target_kit	6b5c50c2f88861943426b054fe3ff42f59ffd29d3dcf3cb1bb6c785b12077ee3
Campaign runner binary	papercut_gokit_runner	092788c6598784d91b411dde40f274c73448f6c803f57c8d0ca85a22d0516e19
Mass retry wrapper	retry_loop.sh	f03e9c6b1923556269004db628e23d373e11224304e136612a61b1e7ae1b7f1f
Reverse SOCKS launcher	live_reverse_socks5.py	844d80da0d8690586f156e1793cde12b5e93a24540e511d4ddb71489cf5a8796
Blind admin / command bridge	admin_bridge.py	5cc0eee4a1d8dbb737838e25f1e9ae37170a54ae757c431b5d6422904538bde3
Reverse bridge class	bridge_template.class	b1adeecb0f2df0d66298a4f3f9a866ddf4c83731892a13ec9b97d405fd50d7b9
Groovy bridge builder	bridge_groovy.py	4cd2a9d574febb1545966561d598c57194da47b09f9175dd888e6aa5d267f91c
Bridge transport	bridge_transport.py	ca996a2dea2529a1e94d7db141259f4fc700b9ab30da36d8b479b81a9b90973b
Open-directory helper	serve_tools.py	f5eebbce3769c8880646c6e8c26d86fbd00e21e193024295641d82c40822adcf
LSA secret reader source	lsa_read.rs	243de5404091bcd920041cf2f4dd22e80f2c2922022854991d2b5e0ac78f2fee
Registry LSA collector source	lsa_collect.rs	08387ff35cc7854ddea1e2106b1150e9fe80646541c95c5a7121b77c9bc0228e
Hive saver source	save_hives.rs	eb4a6a99019f5c5e35f5f3a86867ad65ff1e7338d4937544313b448172988f86
Machine hash decryptor	decrypt_machine_hash.py	b3d73d0a9d26bde03be3511e7293bf67c907fb00d5b6bb8c189a8f37b15987fe
PaperCut credential parser	parse_service_credentials.py	6106fa15dc10764114d039f26a96d793c559f04b080a27af9f2f27c2eeb391e0

Network Indicators 

Type	Indicator	Context
IP Address	45.142.193[.]132	Operator infrastructure hosting the publicly exposed directory containing campaign tooling and development artifacts.
TCP callback	TCP/31337	Default reverse bridge listener in the recovered SOCKS tooling.
TCP callback	Approx. TCP/31337-34336	Randomized reverse listener range used by automatic SOCKS startup.
HTTP helper	TCP/8000	Recovered helper tooling could expose files over a Python HTTP server.