ThreatMon examined a recovered workspace used to check access to internet-facing systems and deploy reverse proxy tunnels. The clearest records concern AhsayCBS: 189 webshell probes, 134 responding endpoints and follow-on deployment attempts using Chisel and GOST. The operator’s wider result files report positive proxy checks for 141 distinct host identifiers. These are records recovered from the workspace, not independently confirmed victim counts.
The investigation draws on source code, JSONL reports, SSH artifacts and server logs. Taken together, they show how a working command channel could be converted into a SOCKS proxy reachable from a shared VPS. The same workspace also contains large-scale scanning data, failed deployment attempts and code for other vulnerabilities. We distinguish those records from demonstrated access throughout this report.
The principal finding is a shared post-exploitation framework built around Chisel and GOST. It was designed to accept command execution from different vulnerabilities and turn that access into a SOCKS proxy reachable through the operator’s VPS. AhsayCBS provides the most complete trail of this activity. Other modules show how the operator sought to repeat the method against newly disclosed vulnerabilities.
The exposed workspace contained 1,357 files, approximately 2.15 GB in total. The directory mixed vulnerability-specific PoCs with a unified deployment framework, downloaded tunnel binaries, JSONL result files and service logs. A significant portion of the storage belonged to third-party dependencies and binaries. The volume of files should not be read as the number of tools authored by the operator.
Figure 1. Recovered workspace directory listing. Only filenames are shown.
Several components are particularly revealing. poc2tunnel.py documents how a PoC can become a command channel and how an existing webshell can be used instead. A separate AhsayCBS script checks for live JSP endpoints. Deployment reports record whether the target-side process and reverse port were usable. On the VPS side, Chisel logs show repeated reverse-mapping activity. This combination provides a view of the operator’s intended workflow and, in part, its observed results.
AhsayCBS is a centralized backup-management platform often deployed by managed service providers. In October 2026, CVE-2026-105133 and CVE-2026-105134 were reported in an exploitation chain that could lead to remote code execution and JSP webshell deployment. Huntress documented attacks beginning on 7 October and published hotfix guidance; Bitdefender also described exploitation activity. Those reports provide vulnerability context, but they do not establish that the operator in our recovered dataset was responsible for the incidents observed by either company.
The file webshell_probe.jsonl contains 189 webshell checks. Of these, 134 returned an alive=true result and 55 did not. The failures included timeouts, HTTP 404 responses, connection errors and other HTTP or TLS failures. A positive response was supported by application output identifying an operating system, not just by an accessible TCP port.
The responses showed a pronounced Windows majority: 118 were classified as Windows, 15 as Linux and one could not be classified. Among the Windows records, Server 2019 was most common with 44, followed by Server 2022 with 26 and Server 2016 with 25. These versions were reported by the remote command response and have not been independently checked against host inventories.
Figure 2. Operating systems returned by the recovered webshell checks. These are operator-side responses.
The raw records include complete webshell URLs and access tokens. We have withheld them. Their publication would provide access material rather than useful context for defenders.
The main deployment script describes a sequence that is straightforward in concept but operationally significant. First, the operator checks whether a vulnerability-specific PoC or a webshell can execute commands. If the channel responds as expected, the script identifies the target operating system and architecture. It then attempts to deliver Chisel and GOST binaries, starting with public release downloads and falling back to a file server controlled by the operator.
GOST is configured to offer a SOCKS service on the target’s local interface. Chisel connects outward from that host to the VPS and requests reverse forwarding. The operator can then address a port on the VPS that forwards traffic to the target-side SOCKS service. A subsequent proxy check tests whether this route is functioning.
The distinction between the two tools is useful for detection. GOST provides the proxy service. Chisel carries the connection back to the operator. The exact local SOCKS port and the VPS-side reverse port may change from one deployment to another. Static port matching alone will therefore miss part of the activity.
Figure 3. The recovered deployment framework describes a PoC-to-proxy workflow across different vulnerabilities.
Figure 4. Reconstructed path from command execution to a working SOCKS proxy, based on scripts and operator-side results.
The shared configuration names 143.244.140[.]188 as the control and staging VPS. The principal Chisel listener was configured on TCP/26925, while TCP/9191 was used as an HTTP fallback for binary distribution. A separate NVR-related stack reserved TCP/28733 for Chisel and TCP/9288 for HTTP file serving. A GitLab-focused callback script referenced TCP/8000. These latter services are documented in code; their default settings should not be treated as proof that every listener was simultaneously active.
The more detailed 123.fast.jsonl sample contains 45 deployment records across 30 host identifiers. Thirty-six records report deployed_proxy_ok together with a positive nested proxy check. Those 36 records represent 24 hosts. The remaining nine records were failures. In the positive subset, 29 entries were associated with Windows and seven with Linux. The returned command output included Windows SYSTEM and Linux root contexts.
These details make the results more substantial than a simple success flag. They show what the operator’s tool claimed to execute and how it checked the proxy connection. They remain operator-generated evidence, however, and are not a substitute for forensic artifacts obtained from the affected servers.
After normalizing and correlating the larger proxy datasets, we identified 137 distinct host identifiers with positive proxy checks. A later OpenHands dataset added four identifiers absent from that group. The combined result was 141 host identifiers with at least one positive proxy check, drawn from 198 identifiers in the reviewed proxy-attempt datasets. Fifty-seven identifiers had no positive proxy check in the records we reviewed.
The webshell and proxy evidence sets overlap, but they are not identical. Eighty-eight identifiers appear in both positive groups. Another 53 have a positive proxy result without a corresponding live webshell result, while 46 have a live webshell result without a positive proxy record. Their union contains 187 identifiers: 175 IPv4 literals and 12 hostnames. This is not a count of 187 organizations, and the same asset may appear under both an IP address and a hostname.
Figure 5. Overlap between positive proxy checks and responding webshell endpoints, measured by normalized host identifier.
The main Chisel server log contains 18,835 lines. It includes 936 reverse-mapping messages and 15,670 entries containing unexpected packet. Other Chisel logs were found in the workspace, but we did not add their counts together because sessions and restarts may overlap.
The mapping messages support that reverse forwarding was being requested and recorded at the server. They do not establish 936 unique, stable tunnels. The packet errors do not establish another 15,670 sessions. Both kinds of entry must be read alongside process and connection evidence, not used as stand-alone victim statistics.
Figure 6. Chisel server log excerpt showing reverse mapping activity. A log line does not represent a distinct compromised host.
A separate HTTP receiver log contains 894 GET requests, 877 of which request /payload.jpg, from 98 source IPs. That filename was used by a JPEG/PHP polyglot delivery component in the workspace.
A GET request does not prove that the payload was executed. The sources may include repeat requests, scanners and intermediary systems. We did not count them as additional victims.
A supplied geolocation dataset covers 131 of the public IPv4 addresses associated with the positive webshell responses. The addresses map to 27 countries. The United Kingdom accounts for 23, the Netherlands for 17 and the United States for 16. Brazil accounts for eight, Norway for seven, and Spain and Denmark for six each.
Figure 7. Country distribution of 131 geolocated webshell IP addresses, not the locations of victim organizations.
The regional breakdown is 87 addresses in Europe, 31 in the Americas, seven in Asia, four in Oceania and two in Africa. These figures describe IP geolocation, not the geographic distribution of victim organizations. The numbers also apply to the 131 geolocated webshell IPs, not all 141 proxy-positive identifiers.
Figure 8. Regional breakdown of the geolocated webshell IP addresses.
One AhsayCBS management script contains instructions for preserving a selected JSP webshell while proposing removal of other JSP files and receiver entries. It can also prepare an optional hotfix step. In isolation, this looks like an attempt to retain a preferred access method while limiting alternative access paths.
The result file changes what we can claim. All 134 records in remediate_report.jsonl show dry_run=true. The script recorded proposed actions, but the supplied results do not show them being carried out. We found no evidence that 134 systems were actually patched, that other webshells were deleted, or that exclusive control of those servers was achieved.
Figure 9. Source code designed to preserve a selected JSP file while proposing deletion of other JSP files. The corresponding report records dry runs.
The operator was not limited to AhsayCBS. Several modules targeted newer disclosures or different application stacks. Their evidentiary value varies considerably.
Product | Vulnerability | Evidence in the recovered material |
|---|---|---|
AhsayCBS | CVE-2026-105133 / CVE-2026-105134 | Webshell checks, command output and proxy deployment records |
Frappe | CVE-2025-68953 | File-read routines and a conditional Werkzeug debugger path |
Nextcloud built-in CODE Server | CVE-2026-110447 | PHP backdoor and NVR deployment code; related transfers failed |
WordPress The Grid | CVE-2026-94169 | Standalone and Pocsuite-style execution checks |
Cisco Catalyst SD-WAN | CVE-2026-20182 | DTLS, SSH and NETCONF validation attempts |
GitLab | CVE-2026-97229 | Callback listener script, without confirmed exploitation results |
Joomla / YOOtheme Pro | CVE-2026-102785 | Polyglot payload serving component, without proved execution |
OpenHands SDK | CVE-2026-112346 | PoC and proxy-deployment records |
The Cisco SD-WAN dataset contains 2,218 distinct host identifiers. Many checks ended in SSH failure or timeout, and the operator’s classification flagged 272 as potential honeypots. None of the reviewed records was classified as REAL. The dataset is evidence of probing, not 2,218 compromised controllers.
The Nextcloud-related NVR backdoor report contains 108 rows from 107 hosts, all marked transfer_fail. The existence of code to deploy a backdoor does not turn these failures into successful installations. The Frappe module contains file-read logic and an optional debugger-based execution path, but that second stage depends on conditions that the source alone cannot establish.
The OpenHands results offer a narrower positive finding: 17 deployment records included eight positive proxy rows covering four hosts. Those four hosts were not included in the preceding set of 137 positive proxy identifiers. This suggests the framework was extended to a new target family, but it does not establish when the first exploitation occurred.
Figure 10. Redacted OpenHands results showing positive proxy checks alongside unsuccessful or dry-run records.
The table below maps the recovered workflow to MITRE ATT&CK Enterprise techniques. It separates results supported by response or log records from behaviors that are visible in scripts but not independently confirmed on each target. It is not an assertion that every technique occurred on every host.
Technique | Tactic | Case-specific evidence | Assessment |
|---|---|---|---|
Initial Access | Vulnerability-specific modules and AhsayCBS webshell responses | Exploitation path supported; individual entry events not independently verified | |
Persistence | JSP endpoints returning live responses in webshell_probe.jsonl | Strong operator-side access evidence | |
Execution | Windows command results and reported SYSTEM context in deployment records | Supported by operator-reported command output |
Execution | Linux command results and reported root context | Supported by operator-reported command output | |
Command and Control | Chisel/GOST download logic, GitHub release paths and VPS fallback server | Tooling capability; target transfer outcomes vary | |
Command and Control | Chisel reverse forwarding in scripts and server-side mapping logs | Supported by code and server logs | |
Command and Control | Target-local GOST SOCKS service and operator-side proxy checks | Supported by positive operator-side proxy results |
We deliberately did not map data exfiltration, privilege escalation, lateral movement or defense impairment as confirmed techniques. The reviewed records do not establish those outcomes across the operation. In particular, the webshell management file’s removal steps were recorded in dry-run mode.
The following indicators come from the recovered files. Some are concrete infrastructure pivots; others are low-specificity strings suitable only for correlation. Network addresses and ports should be reviewed against the time period and local telemetry before any blocking decision.
Indicator | Type | Role in the recovered material | Evidentiary status |
|---|---|---|---|
143.244.140[.]188 | IPv4 | Shared VPS in Chisel and payload-staging configurations | High-confidence configuration pivot; also matched an offline SSH host record |
143.244.140[.]188:26925 | TCP endpoint | Principal Chisel reverse-tunnel control listener | Configuration and matching tunnel-log context |
143.244.140[.]188:9191 | HTTP endpoint | Fallback binary-distribution service | Explicit code configuration |
143.244.140[.]188:28733 | TCP endpoint | Separate NVR Chisel controller | Code configuration only |
143.244.140[.]188:9288 | HTTP endpoint | Separate NVR binary server | Code configuration only |
143.244.140[.]188:8000 | TCP endpoint | GitLab callback service default | Code configuration only |
/payload.jpg | HTTP path | Filename requested in the recovered receiver log | Low specificity; HTTP requests alone do not establish code execution |
A separate Ed25519 SSH host-key fingerprint was recovered for the shared VPS: SHA256:ytM/3PMwMS8eKymWGeuP0HGsnU/4TADBOOPFX1vz0G4. It is an infrastructure-correlation artifact, not a malware signature or a reason to block unrelated systems. The string dsh-jump-20261020 is an authorized_keys comment and should likewise be treated only as an attribution lead.
We have not published working webshell URLs, query tokens, private keys, SOCKS usernames or passwords, or the full list of target IP addresses. No unique malware SHA-256 value was verified for publication from the currently reviewed evidence. We are not presenting upstream Chisel or GOST binary hashes as malicious IOCs, since their presence alone does not identify this operation.
For organizations running AhsayCBS, review the management interface and verify the installed hotfix build. Huntress and Bitdefender report that v10 requires build 10.3.4.45 and v7 through v9 require 9.15.2.70 or later. Review replication receiver configuration, unexpected JSP files and child processes launched from AhsayCBS services, particularly command interpreters or unusual download utilities. Patching the entry point does not remove a previously planted webshell.
For endpoint and network investigations, combine process ancestry with network connections. An unfamiliar application process launching a shell, downloading a Chisel or GOST binary to a temporary directory, then making a persistent outbound connection to an uncommon VPS and port is more meaningful than a Chisel filename in isolation. On Linux, inspect temporary executables and local SOCKS listeners; on Windows, correlate command execution with the backup service and subsequent outbound traffic.
Use the defanged VPS address above as a retrospective pivot for the relevant period. Validate ownership and current allocation before relying on it for present-day blocking. Where possible, compare endpoint events, application audit logs, network flows and the recovered server-side timestamps. A successful operator-side proxy check merits investigation, but the affected organization’s telemetry is needed to confirm the incident and its scope.
The source files contain extensive Chinese-language comments and references to ZCode and Zhipu material. A Windows development path also includes the account-directory name wjg. Those details may help establish code provenance, but they do not identify a person or country. The recovered known_hosts record matches the shared VPS, while the authorized_keys file includes a public key labeled dsh-jump-20261020. Neither proves a successful login by a specific operator.
The .bash_history contains 323 lines with repeated Chisel and GOST references and 38 appearances of tmux attach. There are no usable Bash timestamp markers in that file. The included knownsec/pocsuite3 Git checkout is a clone of a public framework and is not evidence connecting its maintainers to the operation.
We are therefore leaving attribution unresolved. We found no reliable basis to assign the workspace to a named threat group, to a government or to an operator based in China.
Figure 11. Chinese-language development notes in the recovered SD-WAN tooling, including references to ZCode and Zhipu.
Our review was performed offline using recovered source code, configuration files, JSONL outputs and logs. We did not execute the PoCs against the listed targets or use live webshell and proxy credentials. Host totals were calculated from normalized IP addresses and hostnames, with repeated records collapsed within the relevant dataset. IP addresses and hostnames may still represent the same asset or multiple assets belonging to one organization. The geolocation graphs cover only the 131 addresses in the supplied geolocation CSV.
Evidence is described according to its source: a script establishes intended functionality, an operator-side result reports an outcome, and server logs may corroborate part of that outcome. These categories should not be treated as interchangeable. No data-theft volume, confirmed sale of access or independently established victim-organization count was available in the reviewed materials.
This case shows how a collection of unrelated public-facing application flaws can be managed through a single post-exploitation process. The operator’s framework was designed to turn access into proxy capacity, with GOST providing the SOCKS service and Chisel carrying it back to the control VPS. The AhsayCBS records offer the clearest evidence of that approach: live webshell responses, high-privilege command output, proxy checks and matching server-side tunnel activity.
The remaining evidence is less conclusive. Some modules contain only PoC code, some record failed transfers, and a substantial SD-WAN dataset never establishes a confirmed controller compromise. For that reason, our published figures remain tied to exactly what the recovered records can support. That is enough to describe the activity in technical detail without assigning it to a group or overstating the impact.
The public sources below provide vulnerability and technique context. The host counts, logs and source-code findings in this article come from the recovered workspace, not from these advisories.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
