Pequod Toolkit Exposure - ThreatWatch Analysis

Executive summary:

A public disclosure identified 107[.]152[.]37[.]252 as infrastructure associated with a cybercriminal operation referred to as Pequod. Securonix Threat Labs independently confirmed that the host exposed a Python HTTP directory on TCP/8000. The directory contained source files for service discovery, deployment, cryptocurrency mining, proxying, browser automation, and fraud-related activity. The same IP also appears in hard-coded deployment configuration within the exposed collection. 

The investigation confirmed the exposed repository and several technically usable capabilities. It did not confirm a functioning botnet, successful exploitation of third-party systems, active mining, valid credentials, stolen data, Telegram-based resale, or AI/ML poisoning. 

The repository is best assessed as a mixed-maturity development or staging environment. Some components contain working network, deployment, mining, persistence, proxy, or automation logic. Others are incomplete, simulated, internally inconsistent, or unable to validate the result they report. 

This distinction matters for defenders. Unfinished tooling can still lower the effort required to abuse exposed cloud services. The repository includes usable Masscan execution, Shodan-based target discovery, deployment logic for improperly secured services, XMRig execution, SSH-key persistence, reverse proxying, browser automation, and blind WordPress comment submission. 

Defenders should hunt for the confirmed behaviors and indicators described in this report. An indicator seen in isolation, particularly on an internet-facing service, should not be treated as proof that the system is a confirmed Pequod victim.

Key findings:

• Confirmed exposure: This observed a Python SimpleHTTP service on TCP/8000 on 10 August 2026. A standard GET request on 11 August reproduced the exposed directory, which contained 45 listed entries. The host view showed TCP/8000.

  • Assessment: CONFIRMED. 

• Toolkit association: The live host served the same filenames referenced in the originating disclosure. deploy_to_vps.py also contains a hard-coded reference to 107[.]152[.]37[.]252 as a deployment target. This establishes a relationship between the exposed host and the toolkit. It does not identify the operator.

  • Assessment: CONFIRMED association. ACTOR ATTRIBUTION UNRESOLVED. 

• Mixed capability maturity: Several reviewed files contain functional network or process logic, including infect_swarm.py, masscan_acquisition.py, the XMRig launch scripts, reverse_hub.py, zombie_dialer.py, and the browser and fraud modules. Seventeen of the 37-reviewed artifacts also contain explicit mock or simulation indicators.

  • Assessment: MIXED MATURITY. 

• Operational activity: The investigation found no passive evidence of successful exploitation, compromised secondary systems, active services on TCP/4444 or TCP/9000, mining payouts, working proxy credentials, Telegram activity, or stolen data.

  • Assessment: OPERATIONAL USE UNVERIFIED. 

• AI/ML claims: ai_poison_payload.py does not modify models or datasets, submit prompt injections, or launch a GPU miner. Its observed behavior consists primarily of local checks, termination of a named process, and simulated success output.

  • Assessment: CLAIMS CONTRADICTED AS IMPLEMENTED. 

Scope, methodology, and evidence standards:

Securonix Threat Labs used the originating disclosure as an intelligence lead rather than as independent proof. The investigation then compared those claims against passive infrastructure observations, reproduction of the exposed HTTP directory, static analysis of the retrieved code, and authoritative product documentation. 

The live directory contained 45 entries. Thirty-seven selected text artifacts were reviewed, totaling 2,904 lines. Heuristic review identified explicit mock or simulation language in 17 files, network or process-related calls in 16 files, and seven potential secret occurrences. 

The investigation did not attempt to exploit third-party services. TCP/4444 and TCP/9000 were not directly contacted. Exposed proxy or Telegram credentials were not tested. No mining-pool interaction or blockchain transaction analysis was performed as part of the review. 

The following evidence terms are used throughout this report:

Initial disclosure:

On 10 August 2026, researcher Yusuf Can Cakir published an X post alleging that a single unsecured VPS exposed a “Pequod botnet toolkit” together with credentials, SSH material, target lists, mining components, and reverse proxy tooling. 

The screenshots included a directory listing and portions of target_scraper.py and deploy_to_vps.py. During analysis, those screenshots were treated as disclosure-derived evidence. The exposed directory was independently reproduced on 11 August. 

Infrastructure analysis:

The exposed service uses Python’s SimpleHTTPRequestHandler, which serves local files over HTTP and generates a directory listing when no index page is present. Python documentation states that http.server is not intended for production use and provides only basic security protections. 

That configuration is consistent with careless or temporary staging exposure. The service configuration alone does not establish malicious operation. 

No TLS certificate was observed on the exposed service. The public OSINT view showed TCP/8000. Source files reference TCP/4444 and TCP/9000, but neither service appeared in the reviewed passive results and neither port was directly probed. 

• Assessment for TCP/8000: CONFIRMED. 

• Assessment for TCP/4444 and TCP/9000: CODE-CONFIGURED. OPERATION UNVERIFIED.

Exposed toolkit and artifact analysis:

The reviewed collection spans six main functional areas.

Acquisition and scanning:

Representative artifacts: 

• botnet_node_hunter.py
• clickbank_vector_scan.py
• masscan_acquisition.py
• target_scraper.py

The code includes Shodan-based target discovery and Masscan execution. The hard-coded Masscan run scans 104.236.0.0/16 at a nominal 50,000 packets per second across ports 6379, 8080, and 8888. 

• Assessment: CAPABILITY CONFIRMED. OPERATIONAL TARGETING UNVERIFIED.

Deployment and access:

Representative artifacts:

• infect_swarm.py
• deploy_to_vps.py
• payload.sh
• exploit_*

The deployment logic contains service-specific paths for Ray, Docker, Kubernetes, Redis, Jupyter, and Jenkins. Several routes depend on exposed or improperly secured management interfaces rather than on a demonstrated vulnerability in a confirmed target. 

• Assessment: CAPABILITY PRESENT. SUCCESSFUL COMPROMISE UNVERIFIED. 

Mining:

Representative artifacts:

• xmrig_deployer.py
• payload.sh
• infect_swarm.py

The collection contains XMRig download and launch logic, mining-pool configuration, and persistence-related paths. 

• Assessment: CAPABILITY CONFIRMED. MINING ACTIVITY UNVERIFIED.

Proxy / C2:

Representative artifacts:

• reverse_hub.py
• zombie_dialer.py
• zombie_proxy.py
• local_forwarder.py

The code implements back-connect and proxy-related behavior, including TCP relay logic and HTTP CONNECT handling. 

• Assessment: CAPABILITY CONFIRMED IN CODE. INFRASTRUCTURE OPERATION UNVERIFIED.

Fraud automation:

Representative artifacts:

• browser_agent.py
• behavior_engine.py
• cpa_fraud_engine.py
• clickbank_scraper.py
• wp_comment_spammer.py

These files automate browser navigation, pointer movement, link selection, form submission, affiliate-link generation, and WordPress comment requests. 

• Assessment: AUTOMATION CAPABILITY CONFIRMED. FRAUDULENT CONVERSIONS OR SUCCESSFUL SPAM DELIVERY UNVERIFIED.

AI and data-related claims:

Representative artifacts:

• ai_poison_payload.py
• data_extractor.py
• data_packager.py
• exploit_elastic_gamma.py
• telegram_drop.py

The reviewed AI-related code contains simulated or incomplete behavior and does not support stronger claims associated with model poisoning or dataset manipulation. 

• Assessment: CLAIMS OVERSTATED OR INCOMPLETE.

Operational mistakes and internal inconsistencies:

• Analysis identified several implementation problems that limit direct execution or weaken claims made by the code.

• Shodan-derived categories such as redis_compute and jupyter_compute do not match the redis and jupyter router labels accepted by infect_swarm.py. A transformation step would be required before direct handoff.

• masscan_acquisition.py includes Docker parsing logic, but its configured port list omits TCP/2375. Its main routine scans only 104.236.0.0/16 even though comments describe broader coverage.

• The Jupyter path creates a session but does not submit code to the kernel.

• Several modules print success without validating the HTTP response or continue to report success after caught errors. Those messages cannot be used as evidence of exploitation.

• Example target ranges include 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24. RFC 5737 reserves these networks for documentation.

• The WebRTC proxy uses no-cors fetch semantics, which prevent the script from reading the resulting opaque response. The path also assumes that browser code execution has already been obtained.

• These findings are consistent with a repository that combines working components with unfinished or demonstrative code.

Initial access and exploitation analysis:

The collection mainly targets insecure or overly permissive management interfaces. The investigation did not identify target software versions or configurations, so the available code cannot establish that a vulnerable or exploitable service was present. 

Ray and CVE-2023-48022:

infect_swarm.py submits a job entrypoint through the Ray Jobs API.

Ray documentation states that the Dashboard, Jobs, and Client interfaces can provide broad access to cluster resources and should be restricted to trusted users. NVD lists CVE-2023-48022 as a disputed issue involving unauthenticated job submission in certain reported Ray versions. 

The exposed code does not identify a target Ray version. 

• Assessment: PLAUSIBLE AGAINST AN IMPROPERLY SECURED SERVICE. TARGET VULNERABILITY UNVERIFIED. 

MySQL and CVE-2012-2122:

The MySQL-related files reference CVE-2012-2122, which affected specific older MySQL and MariaDB releases under particular implementation conditions. 

The reviewed modules rely on random or simulated success and do not demonstrate the authentication flaw itself. No target version was established. 

• Assessment: THEORETICALLY RELEVANT. EXPLOITATION NOT DEMONSTRATED. 

Misconfiguration-dependent service paths:

• Other modules depend on administrative services that are exposed or insufficiently protected.
• Docker documentation warns that access to the Docker daemon can provide root-level control and recommends protecting daemon access with TLS or SSH.
• Kubernetes requires authentication and authorization. Anonymous network exposure does not establish that an attacker can create a DaemonSet.
• Redis recommends limiting network access and using protected mode or authentication.
• Jenkins Script Console access requires administrative privileges and can allow arbitrary code execution.
• Jupyter enables token authentication by default because access to a Jupyter server can provide code-execution capability.
• These code paths are useful for defensive hunting, but service exposure by itself should not be classified as successful exploitation.

Botnet and deployment workflow:

The intended workflow can be reconstructed from the code:

1. OSINT searches and a Masscan subprocess identify candidate services.

2. Parsers categorize Redis, Jupyter, Jenkins, and other targets, although several category names do not match the labels accepted by infect_swarm.py.

3. infect_swarm.py routes targets to service-specific HTTP or raw-protocol requests for Ray, Docker, Kubernetes, Redis, Jupyter, or Jenkins. 

4. Successful paths are intended to retrieve or install an SSH key, XMRig, and a dialer. Several routes do not validate execution, and _infect_node is incomplete or unused.

5. Configured monetization paths include mining, proxy traffic, browser and affiliate activity, and spam.

   • Assessment: WORKFLOW PRESENT IN CODE. END-TO-END OPERATION NOT OBSERVED.

Cryptomining analysis:

payload.sh, infect_swarm.py, and xmrig_deployer.py reference XMRig 6.21.0 and use both TLS and non-TLS HashVault pool endpoints. XMRig’s official changelog confirms the referenced version.

The same 95-character Monero subaddress-like value appears in multiple artifacts.

• Assessment: MINING CAPABILITY CONFIRMED IN CODE. EXECUTION AND REVENUE UNVERIFIED.

Reverse proxy and C2 analysis:

• reverse_hub.py binds TCP/4444 for “zombie” connections and TCP/9000 for client connections. It pairs the resulting sockets and relays traffic in both directions.
• zombie_dialer.py connects to 107.152.37[.]252:4444 and implements a basic HTTP/CONNECT proxy. Some comments describe the functionality as SOCKS, but the code does not implement a SOCKS4 or SOCKS5 handshake.
• The design is consistent with a bandwidth-hijacking or back-connect proxy architecture.
• This showed TCP/8000. No passive banner or historical observation identified TCP/4444 or TCP/9000, and the investigation did not directly contact either service.

  • Assessment: PROXY CAPABILITY CONFIRMED IN CODE. TCP/4444 AND TCP/9000 REMAIN CODE-CONFIGURED ENDPOINTS.

Residential proxy and affiliate-fraud analysis:

Proxy integration: local_forwarder.py contains upstream proxy credentials and adds a Proxy-Authorization header. cpa_fraud_engine.py contains a separate credential set.

• Assessment: CREDENTIAL MATERIAL AND AUTHENTICATED-PROXY INTEGRATION CONFIRMED. VALIDITY, OWNERSHIP, AND USE UNVERIFIED.

Browser and behavior automation: browser_agent.py uses Playwright to automate navigation, scrolling, pointer movement along generated curves, and clicks on candidate links or buttons. 

behavior_engine.py generates Bezier-like movement paths, although the implementation uses blocking sleeps within an asynchronous flow.

target_scraper.py collects native-ad links from public news sites. 

• Assessment: BROWSER AUTOMATION CAPABILITY CONFIRMED. FRAUDULENT USE UNVERIFIED.

Affiliate and WordPress modules: clickbank_scraper.py generates HopLinks containing the affiliate identifier bzomert.

cpa_fraud_engine.py creates synthetic identities, attempts form submissions, and clicks call-to-action elements. 

wp_comment_spammer.py submits requests to wp-comments-post.php using a default post ID. It treats HTTP 200 and 302 responses as successful without verifying that a comment was published or approved. 

• Assessment: AUTOMATION INTENT AND REQUEST LOGIC CONFIRMED. SUCCESSFUL FRAUD OR SPAM DELIVERY UNVERIFIED.

AI / ML abuse assessment:

The collection contains code associated with cloud-resource hijacking and an incomplete Jupyter path. The reviewed AI module does not perform model poisoning, model manipulation, prompt injection, or dataset modification.

The investigation cannot assess activity outside the reviewed repository. No such activity was observed within the investigation scope.

Actor and campaign attribution assessment:

The repository contains enough incomplete and simulated material to make a mature criminal operation an unsupported characterization.

Evidence for a development or staging environment includes explicit mock markers, documentation-only IP ranges, workflow mismatches, missing protocol steps, and success messages that do not validate the underlying operation.

The repository is not purely demonstrative. Functional offensive components, real network logic, hard-coded infrastructure, XMRig deployment, SSH persistence, and proxy code are present. 

• Assessment: MIXED-MATURITY DEVELOPMENT OR STAGING ENVIRONMENT. SPECIFIC ACTOR ATTRIBUTION NOT ESTABLISHED.

Securonix Threat Labs summary:

Securonix Threat Labs assesses the exposed Pequod collection as a mixed-maturity toolkit containing credible cloud-resource hijacking, cryptomining, proxy, persistence, scanning, and automation capabilities alongside incomplete, simulated, or internally inconsistent components.

High-confidence findings are the exposed TCP/8000 repository, its association with 107.152.37[.]252, the presence of functional offensive code, and the artifacts listed in the IOC appendix.

No evidence reviewed during this investigation confirms an operational botnet or successful compromise of third-party systems. Claims of AI/ML poisoning are not supported by the implementation that was analyzed.

Mitigation and Defensive Recommendations:

Pequod-specific hunting and containment:

• Search historical network, DNS, proxy, and endpoint telemetry for 107.152.37[.]252, TCP/8000 retrievals, outbound TCP/4444 connections, listed file hashes, the Monero wallet value, and both SSH public-key fingerprints. 

• Review Linux authorized_keys files and privileged cron locations for the listed keys or related unauthorized entries. Preserve forensic copies before removing identified persistence. 

• Identify unauthorized XMRig or other miner processes and Python-based reverse-proxy or dialer activity. After affected workloads are scoped, rotate credentials and keys associated with the compromised environment. 

• If proxy or Telegram credentials found in the exposed repository belong to the organization, revoke them through the legitimate provider. Do not attempt to validate exposed credentials against third-party services. 

• Use process context when investigating HashVault or other public mining infrastructure. A legitimate shared service should not be treated as malicious solely because its domain appears in this repository. 

Service and platform hardening:

• Remove unnecessary public access to Docker, Kubernetes, Ray, Redis, Jupyter, Jenkins, Elasticsearch, MySQL, and Tomcat management interfaces.

• Require authenticated and encrypted administrative access. Examples include Docker over SSH or TLS, Kubernetes RBAC, Ray interfaces limited to trusted networks, Redis protected mode and ACLs, Jupyter token or password authentication, and least-privilege Jenkins administration.

• For container environments, restrict privileged workloads, host namespace access, hostPath mounts to /, unapproved images, and excessive permissions through admission controls and policy enforcement.

• Alert on unusual Masscan execution, unexpected Python-based network tools, workload-originated scanning, and public management API access from segments where such activity is not expected. 

Longer-term engineering and response readiness:

• Maintain an inventory of internet-facing management services and reconcile it regularly against the approved service catalog.

• Build detection sequences that connect external management requests with container or job creation, shell or file-transfer activity, persistence changes, and subsequent mining-pool or proxy connections.

• Enable secret scanning across source repositories, build artifacts, object storage, and HTTP staging locations. Development teams should not use Python http.server to expose sensitive deployment bundles.

• Exercise response procedures for compute and bandwidth hijacking, including workload isolation, cost controls, credential and key rotation, and preservation of forensic evidence.

Conclusion:

The investigation confirmed that 107.152.37[.]252 exposed a substantial collection of Pequod-labeled offensive artifacts over TCP/8000 and that the same address appears in toolkit configuration. 

The repository contains working components for scanning, deployment, mining, persistence, proxying, and automation, but its overall maturity is uneven. Several paths are incomplete, simulated, internally inconsistent, or unable to prove the success they report. 

For defensive purposes, the confirmed indicators and behaviors justify hunting and hardening exposed management services. They do not justify classifying every matching system as a Pequod victim or describing the exposed host as a proven operational botnet. 

The current assessment remains: MIXED-MATURITY DEVELOPMENT OR STAGING TOOLKIT. OPERATIONAL USE PARTIALLY UNVERIFIED. ACTOR ATTRIBUTION UNRESOLVED.

Appendix A: Indicators of Compromise

Appendix B: MITRE ATT&CK Mapping

References:

1. Originating X disclosure by Yusuf Can Cakir 

2. Shodan host record for 107.152.37.252