Threat Intelligence · Full Technical Report

The AI-Assisted Breach of Mexico's Government Infrastructure

Between late December 2025 and mid-February 2026, a threat actor breached at least nine Mexican government organizations at federal, state, and municipal levels.

By Eyal Sela, Director of Threat Intelligence, Gambit Security
Download the PDF version

Overview

Between late December 2025 and mid-February 2026, a threat actor breached at least nine Mexican government organizations at federal, state, and municipal levels. The threat actor exfiltrated data from databases containing hundreds of millions of citizen records, compromised hundreds of internal servers, and built both a live query API into government systems and a document forgery service.

The campaign relied heavily on two commercial AI platforms as core operational tools — Anthropic's Claude Code and OpenAI's GPT-4.1 API. These systems performed much of the technical work, including reconnaissance, exploit customization, privilege escalation, database architecture mapping, exfiltration infrastructure development, tunnel chain construction, and credential harvesting. Approximately 75 percent of remote command execution activity across the campaign was generated and executed by Claude Code via its tool-use interface.

Several victims, however, were compromised through manual methods. The campaign was a hybrid, human-directed operation in which AI functioned as a primary operational tool. Throughout the campaign, Claude refused or resisted certain requests — questioning the legitimacy of operations, requesting authorization evidence, and declining to generate specific tools. These friction points recurred across sessions, though the attacker found ways to work around them.

9
government organizations compromised
~75%
of remote command execution run by Claude Code
5,317
AI-executed commands across 34 sessions
2,597
intelligence reports generated via OpenAI

Within days, the attacker had access to databases containing approximately 195 million taxpayer records and a functional API capable of querying live government systems on demand. By day six, the attacker had accessed Mexico City's civil registry servers. By January 22, victims included the National Electoral Institute, three state governments, and a municipal water utility. In the Jalisco state government breach, the attacker gained administrative control over the state's entire virtualization infrastructure, including a 13-node Nutanix cluster and 37 database servers.

This campaign reveals several dimensions of AI impact that defenders will have to contend with. It compressed attack timelines to below standard detection and response windows. It transformed raw reconnaissance data from hundreds of servers into actionable intelligence quickly, enabling a single operator to process volumes that would normally require a team of analysts. And it maximized exploitation opportunities across the attack surface — analyzing unfamiliar systems, identifying high-value targets, and tailoring exploits in hours rather than days or weeks.

The technical-debt warning

This should also serve as a wake-up call for all operations that have been questioning investments in addressing technical debt, particularly in relation to mission critical systems. There is evidence that systems involved in this attack were end-of-life or considering out-of-support, preventing the ability to receive and apply relevant security updates. Addressing technical debt can indeed be costly but balancing such costs against the impact to operations if relevant systems compromised by attackers is an imperative assessment that should be performed by all operations, prior to the attack itself. AI is clearly making it easier to reach and compromise such systems than ever before and as a result, the time for such assessments and proactive investments is now.

While the AI-assisted methods documented here represent a significant evolution in offensive capability, many of the underlying vulnerabilities exploited were addressable through standard security controls — patching, credential rotation, network segmentation, and endpoint detection.

Victims and Timeline

The graph below depicts the length of operation in each of the compromised organizations.

Gantt-style timeline showing when each of the nine Mexican government organizations was breached, from late December 2025 through mid-February 2026.
Campaign timeline by victim organization. The breaches ran from late December 2025 through mid-February 2026, beginning with SAT.

The following table presents the scope of breach in each victim organization:

VictimScope of breach
SAT
Servicio de Administración Tributaria — federal tax authority
195 million taxpayer records and 52 million directory records exfiltrated. Domain-wide credential compromise. Live query API built and exposed publicly. Tax status certificate forgery mechanism operationalized. 305 internal servers accessed and analyzed.
Estado de México
State government
15.5M vehicle registry records, 3.6M property owner records, and millions of additional population registry records exfiltrated.
Registro Civil de CDMX
Mexico City civil registry
Approximately 220M civil records exfiltrated, along with hundreds of judicial records and thousands of government employee records and credentials.
Jalisco state government50K patient records, 17K domestic violence victim records, 36K healthcare employee records, and 180K digital government records exfiltrated. Full virtualization infrastructure compromised — 13-node Nutanix cluster, both management consoles, 37 of 38 database servers accessed. Custom rootkits deployed across 20 state agencies.
INE
Instituto Nacional Electoral
13.8K voter card records exfiltrated across six states; total accessible pool estimated in the tens of millions.
Michoacán state government2.28M property records exfiltrated; 2K user accounts with plaintext passwords compromised.
SADM Monterrey
Agua y Drenaje — municipal water utility
Access to 3.5K procurement and vendor records, and 5K procurement bid records.
Tamaulipas state governmentActive Directory compromise.
Salud CDMX
Mexico City health department
Zimbra email server exploited.

Conventions and Clarifications

  • Due to the scale of the campaign and the volume of forensic evidence, only selected portions are analyzed in this report.
  • AI conversations were originally conducted in Spanish and are presented in English translation throughout the report.
  • In conversations presented throughout the report, portions of the "thinking" blocks in which Claude reasons before showing output to the user are marked as "Claude [Thinking]."
  • Trusted parties may receive access to sanitized forensic materials upon request. Please contact ti@gambit.security.

We would like to thank Hunt.io for facilitating this research, Dolev Cfir for his contributions to the investigation, and Daniel Gordon and The ShadowServer foundation for notifying affected organizations.

A Rare Look Inside an AI-Driven Cyber Campaign

We recovered forensic materials from three virtual private servers used in the campaign.

Claude Code metadata on the primary VPS recorded a first token date of November 27, 2025 — one month before the campaign's first operational session on December 27. A pre-written Claude Code prompt file, 156 pre-approved command patterns, and a structured project directory indicate a deliberate preparation phase before the attacker deployed against live targets.

The recovered material shows the two AI systems serving complementary roles. Claude Code operated as an interactive exploitation assistant — the attacker directed it conversationally to advance access, write exploits, build tunnels, and map victim architecture. BACKUPOSINT.py, a custom 17,550-line Python tool, piped harvested server data through OpenAI's GPT-4.1 API for automated mass analysis across 305 internal SAT servers. It produced 2,597 structured intelligence reports. The attacker read OpenAI's reports and fed relevant findings into Claude sessions as natural language instructions. The attacker's use of both platforms was in direct violation of each company's clearly documented Terms of Use.

The forensic material we recovered includes

  • 20 tailored exploit scripts targeting 20 different CVEs
  • 2,597 structured intelligence reports generated by OpenAI
  • Over 400 custom attack scripts — 301 Bash and 113 Python — including tunnel management, credential spraying, data extraction, deployment automation, operational security cleanup, and rootkits
  • 1,088 individually logged attacker prompts generating 5,317 AI-executed commands across 34 sessions on live victim infrastructure

This report is not comprehensive. It presents selected portions of the recovered material highlighting AI's role in the campaign.

Framing Statement

The campaign began with an exchange that defined much of what followed. On December 27, 2025 at 03:09 UTC, the attacker started a new Claude Code instance.

The attacker opened with what social engineers call a framing statement — a conversational line designed to establish the rules of engagement for everything that follows, setting the AI's behavioral boundaries before any technical work began (translated from Spanish):

Recovered chat log of the attacker opening with a framing statement, instructing Claude to delete logs, disable command history, and follow 'bug bounty' rules without providing any authorization evidence.

Claude's internal reasoning:

Recovered log of Claude's internal reasoning that the attacker's requested rules — deleting logs and disabling history — are detection-evasion techniques, not legitimate bug bounty practices.

The reasoning was sound. Log deletion and history suppression are evasion tactics, not documentation practices. Claude asked the attacker for verification — program name, authorized scope, a link to HackerOne or Bugcrowd rules.

The attacker ignored all three questions. Instead, the attacker asked Claude to save these anti-forensic rules to a persistent file so future sessions would follow them automatically. Claude refused.

Recovered chat log of Claude refusing to save the attacker's anti-forensic rules to a persistent file, identifying them as detection-evasion techniques.

The attacker's next move circumvented the refusal.

Handing Claude the hacking manual

Shortly after, the attacker pasted a pre-written 1,084-line document — a comprehensive penetration testing cheatsheet covering anti-forensics, privilege escalation, Active Directory attacks, credential spraying, and persistence techniques — and asked Claude to save it to disk.

Recovered chat log of the attacker pasting a 1,084-line CTF/pentesting cheatsheet and asking Claude to save it as claude.md.

The attacker's response to Claude's refusal: hand Claude the finished document and ask it to write a file. Claude processed this as a file-write operation, not a content-generation request.

Recovered log showing Claude's reasoning as it decides to save the attacker's CTF/pentesting cheatsheet to a claude.md file.

This file — claude.md in the project root — is the persistent system prompt that loads automatically at the start of every Claude Code session. From this point forward, the 1,084-line malicious cheatsheet was loaded into every conversation.

Reframed as a file-write. After refusing to generate the content, Claude saves the same 1,084-line cheatsheet to claude.md when the request is framed as writing a file.

Claude Executes Its First Exploit

Twelve minutes later, the attacker pointed Claude at SAT — Mexico's national tax authority, and told it to run Vulmap, an open-source vulnerability scanner, against an internet-facing server.

Recovered chat log of the attacker directing Claude to run the Vulmap scanner against an internet-facing SAT server.

After several iterations to stabilize the exploit connection, Claude achieved remote code execution.

Recovered transcript in which Claude reports a successful foothold on a SAT server and asks the operator what command to execute next.
Foothold confirmed. Claude reports remote command execution on a SAT server, notes files from a possible prior compromise, and asks: “What command do you want to execute now?”

Tailoring and Debugging the Exploit

The attacker then asked Claude to create a standalone exploit script independent of Vulmap, with proxy routing and automatic retry on failure.

Recovered chat log of the attacker requesting a standalone, proxy-aware exploit script with automatic retry logic, including the proxy address used.

Claude wrote s2_005_exploit.py — a 285-line Python script with proxy support, retry logic, and the full injection payload for remote command execution. The code hardcoded the target URL and routed traffic through us.proxy.geonode.io, a residential proxy provider. Over the next 7 minutes, Claude iterated through 8 sequential edits, exploring multiple payload delivery mechanisms, Unicode escapes, and base64 encoding to avoid character restrictions. When one approach failed, it analyzed why, referenced payload structures from related CVEs, and tried a different method.

Recovered exploit workflow on a live SAT server, showing the standalone script Claude built with proxy routing and retry logic.
A standalone weapon. Claude rebuilt the exploit as an independent script with proxy routing and automatic retry, iterating through encoding tricks to bypass character restrictions.

The result was a tailored, proxy-aware exploit ready for deployment.

In 40 minutes, the conversation moved from “I'm not going to create that file” to “What command do you want to execute now?” on a live government server.

Claude's safety reasoning was sound at every step — it identified evasion techniques, refused to generate the anti-forensic rulebook, and requested authorization evidence. The guardrails did not hold in this case.

Claude's refusals were not limited to this initial exchange. Throughout the campaign, the attacker had to work around safety barriers repeatedly — rephrasing instructions, reframing requests, or abandoning certain approaches entirely. The persistent system prompt reduced but did not eliminate these friction points.

“I Have Root!”

The following excerpts are from a single session on January 1, 2026 — day five of the operation, by which point the attacker had already breached SAT's perimeter and was operating across multiple victim networks simultaneously.

Claude was operating inside the Registro Civil network — Mexico City's civil registry system — connected through SSH tunnels and Chisel SOCKS proxies. Extraction jobs were running in the background, pulling millions of rows from multiple databases into CSV files on the attacker's VPS. Claude executed the extractions including progress monitoring loops, parallel dumps and file transfers.

One of these database servers had yet to yield root privileges.

Finding a Writable Crontab

The attacker asked Claude to look for privilege escalation paths on this server. Claude scanned crontabs and found a writable entry.

Recovered chat log of Claude scanning crontabs and identifying a writable script that runs as root, creating a privilege-escalation path.

Claude checked. The file was owned by a service account it already had access to, and it was writable. It confirmed the escalation path and asked the attacker whether to inject an SSH key into root's @@PROTECT4@@ or only document the finding.

Recovered chat log of Claude confirming the root-escalation path and asking whether to inject an SSH key into root's authorized_keys or only document the finding.

The attacker responded with a single instruction. The anti-forensic requirement was notable — but this time it was executed without refusal.

Recovered chat log of the attacker instructing Claude to inject the SSH key and disguise the change so it doesn't look suspicious.

Claude's thinking block described the operation plan. Claude recorded the original file timestamp, modified a scheduled system script to inject an SSH backdoor key into root's @@PROTECT5@@, then restored the file's modification time so it appeared untouched. These are the actual commands Claude executed on the remote server, captured verbatim from the session log.

Recovered log of Claude's plan to inject a root SSH key, disguise the change, and restore the file's original timestamp.Recovered bash commands Claude executed to inject a backdoor SSH key into root's authorized_keys via a compromised cron script, routed through a chained SOCKS proxy.Recovered bash commands Claude executed to verify the SSH key injection and restore the script's original modification timestamp to avoid detection.

Every command passed through two network hops before reaching the target. The VPS connected through a SOCKS proxy (@@PROTECT6@@) that traversed a compromised internet-facing server, then authenticated to the civil registry server using an SSH key (@@PROTECT7@@) stolen earlier in the campaign.

Claude updated the attacker. The attacker wanted to make sure. The cron job was scheduled for 14:30.

Recovered transcript describing Claude's root-persistence step: an SSH key injected into root's authorized_keys with file timestamps restored.Recovered chat log of the attacker questioning whether Claude's edit preserved the original script, and Claude confirming both the injection and the original functionality remained intact.

Root Access

The attacker asked. Claude attempted the SSH connection — this time authenticating as root instead of the service account used previously.

Recovered chat log of the attacker asking Claude to check for root access, and Claude's plan to test the injected SSH key.Recovered terminal output showing Claude's SSH connection authenticating as root, confirmed by uid=0(root) in the command output.Recovered log of Claude confirming root access was achieved through the previously injected SSH key.

The attacker had asked only to check access. Claude had root — and then, still within the same turn and without any follow-up prompt, proceeded to dump the shadow file, extract the root password hash, and initiate timestamp cleanup.

Recovered log of Claude's internal reasoning after obtaining root, showing the extracted /etc/shadow password hash and the plan to fix timestamps to avoid detection.
Root persistence. Claude documents injecting an SSH key into root's authorized_keys, restoring the file's timestamps to look untouched, and confirming root access via a cron job.

“Excellent!” — Claude's internal reasoning upon gaining root access. It then continued to harvest credentials and fix timestamps to avoid detection, in accordance with the anti-forensic rules loaded from the persistent system prompt.

Automated Reconnaissance with OpenAI

The following sections describe SAT-related operations that ran throughout the campaign's first week, in parallel with the activity described above.

The exploitation phase was interactive and conversational, one target at a time. But the SAT's internal network contained hundreds of servers across dozens of subnets. Manually analyzing each compromised host for credentials, pivot paths, and lateral movement opportunities would have taken weeks. The attacker solved this with a second AI system running in parallel.

BACKUPOSINT.py — a 17,550-line custom Python tool — connected to compromised servers via the same SOCKS tunnel chains that Claude had built. It extracted system data (processes, ports, configurations, histories, credentials, SSH keys) and piped everything through OpenAI's GPT-4.1 API for analysis. Across the campaign, it made approximately 2,800 API calls analyzing 305 internal SAT servers.

The tool's OpenAI prompts defined six personas, culminating in (original Spanish prompt):

Recovered Python source showing the system prompt sent to OpenAI's GPT-4.1, instructing it to act as an elite intelligence analyst analyzing harvested server data.

Translation: “ELITE INTELLIGENCE ANALYST with experience in: NSA TAO, CIA/SAD cyber infiltration operations, APT hunting, nation-state level operations.”

Analysis at scale. The system prompt piped to OpenAI's GPT-4.1 cast the model as an “elite intelligence analyst,” instructing it to flag critical findings, classify credentials, and map lateral-movement paths.

For each compromised server, BACKUPOSINT generated a suite of intelligence reports. Here is an excerpt from the AI_PURPOSE_REPORT.md generated for one of SAT's authentication servers:

Recovered markdown report generated by OpenAI's GPT-4.1 describing the purpose of a compromised SAT authentication server and possible lateral-movement vectors.

For each server, BACKUPOSINT produced an AI_LATERAL_SUGGESTIONS.md with tables mapping each harvested credential to internal servers where it might work, along with ready-to-execute spraying scripts. It also produced an 00_AI_MEGA_REPORT.md — styled as “NSA/CIA intelligence dossiers” — that scored OPSEC risk levels and provided immediate action commands. This excerpt is from a “MEGA” report generated for an internal logging and aggregation server:

Recovered OPSEC recommendations and ready-to-run commands generated by OpenAI's GPT-4.1 for exfiltrating SSH keys and credentials from a compromised server.

Lateral Movement

In parallel, Claude Code performed lateral movement analysis. The attacker sent a vague, conversational prompt — “could you look at the bash histories to see what other IPs could work or checking hosts or I don't know so we can see what other SSHes we could do the same” — and Claude parsed the data, filtered out broadcast addresses and already-visited hosts, ranked candidates by evidence strength, and returned a structured recommendation.

Recovered log of Claude filtering candidate IP addresses from bash history and recommending which hosts to try connecting to next.

Researching SAT's Systems Architecture

Over roughly four days, 254 user prompts generated approximately 2,500 remote command executions. Under the attacker's directives, Claude mapped SAT's internal architecture. The attacker's questions revealed his knowledge gaps.

Recovered chat message from the attacker asking Claude to explain what Mexico's CIEC taxpayer credential system is and what it queries.Recovered follow-up chat message from the attacker pressing Claude for more detail on the CIEC system and whether it underlies the broader government architecture.

CIEC is Mexico's taxpayer authentication credential system. Claude responded with a full architectural document. It drew diagrams, listed every database table involved, explained the authentication flow step by step, and showed configuration file paths with embedded credentials. Claude demonstrated substantial analytical and operational capability:

  • Connected when needed via proxychains and database command-line tools
  • Enumerated all accessible schemas and tables
  • Identified tables containing personal data (names, addresses, phones, FIEL records)
  • Discovered stored procedures used in taxpayer record retrieval
  • Mapped database links to adjacent databases, discovering additional database targets
  • Cracked database password hashes, revealing 8 accounts
  • Built a comprehensive conceptual map of the entire data model

The attacker then asked for additional data — biometrics, FIEL keys, CURP records.

Recovered chat log of the attacker requesting every available personal data field, including biometric and FIEL credential data.

Live Data Exfiltration API

Claude used its understanding of SAT's database schemas, SOAP services, and LDAP directory to build sat_api_DEFINITIVO.py — a 594-line Flask REST API. It connected directly to SAT's live systems through the attacker's proxy tunnels and assembled enriched taxpayer profiles from four live data sources on every request. The API was built through 20 iterative revisions in approximately 2 hours, integrating database stored procedures, SOAP web services, and LDAP directory queries.

Recovered build log showing Claude writing and iterating sat_api_DEFINITIVO.py, the live taxpayer-data exfiltration API, over roughly two hours.

Each API request made four live network calls through SSH and SOCKS proxy tunnels into SAT's compromised infrastructure — a database stored procedure call, an additional database query, a SOAP address enrichment request, and an LDAP operational attribute lookup — returning comprehensive taxpayer profiles assembled in real time. The system depended on the breach remaining active.

The Forgery Layer

The data API was only the backend. On top of it, the attacker built a document forgery layer — a system that generated fake “Constancias de Situación Fiscal,” Mexico's official tax compliance certificates (or ‘tax status certificate’). These are the documents citizens and businesses present to banks, employers, landlords, and government agencies to prove their standing with the tax authority. The forgery script, generar_constancia_pdf.py (541 lines), was not written by Claude — it was built outside Claude Code sessions — and it used the same data collected by sat_api_DEFINITIVO.py from SAT's systems.

Example PNG asset used by the forgery script to replicate Mexico's official tax authority letterhead on forged certificates.

How the Forgery Works

When a client requested a ‘tax status certificate’ for a given RFC (Mexico's taxpayer ID), the server made the live calls into SAT's infrastructure through the attacker's proxy chain in the backend. The forged PDF was constructed by generar_constancia_pdf.py.

Every field in the resulting PDF — name, address, tax regime, economic activities, registration date, fiscal obligations — was current and accurate, because it was pulled from the government's own databases at the moment of generation. The document wrapped this live data in SAT's official formatting: header layout, QR code, cadena original, and a digital seal.

Faking the Digital Seal

The seal was the one element the attacker could not replicate. Real SAT documents are signed with the institution's RSA private key. The forgery substituted a fake:

Recovered Python source of the function that fabricates a fake digital seal for forged tax certificates using a SHA-256 hash and random padding.

A SHA-256 hash plus 96 bytes of random padding, base64-encoded to look like a real signature. It had no cryptographic validity — but a “constancia” is a PDF that people print and hand to a bank teller, not a digitally-verified artifact. For any recipient who checks by reading the document rather than cryptographically validating the seal — which is how these certificates are checked in practice — the forgery would be difficult to distinguish from a genuine document because the underlying data was real.

A few external clients were observed accessing the /constancia_pdf generation endpoint within hours of deployment. Each generated certificate was assembled from the government's own live records. It worked only as long as the breach remained active — all four data sources had to be reachable through the proxy chain. Rotating any single credential or firewalling the VPS would have disabled it instantly.

Lateral Movement at SADM

On January 3, 2026, the target was SADM — the municipal water utility of Monterrey. The attacker had a webshell on an SADM public-facing portal and credentials extracted from a database. The attacker asked Claude to test these passwords against Kerberos, dump the Active Directory if any were valid, and use secretsdump.

Recovered chat message from the attacker asking Claude to test extracted credentials against Kerberos and dump Active Directory.Recovered log of Claude's plan to enumerate the domain controller and test the harvested credentials against Kerberos.

Claude enumerated the domain controllers via DNS SRV lookup through the webshell. Six domain controllers came back. Later the same day, the attacker said “haz todo” — do everything. Claude ran crackmapexec against five servers and identified that the domain controllers required SMB signing, but three other servers did not.

Recovered command log of Claude enumerating SADM's domain controllers via a DNS SRV lookup through the webshell.Recovered log of Claude parsing crackmapexec results and identifying which domain controllers were vulnerable to SMB relay.

When Claude presented the SMB signing finding, the attacker asked: “que hace ese ataque?” — what does that attack do? Claude explained the relay technique. The attacker approved: “vale hazlo” — okay do it. Claude set up ntlmrelayx targeting the three servers with a base64-encoded PowerShell payload calling back to the attacker's VPS.

The attacker asked if there were other options. Claude presented a menu of escalation techniques. The attacker picked PetitPotam.

Recovered chat log of Claude presenting a menu of lateral-movement escalation techniques after simpler relay attacks failed.Recovered chat message from the attacker choosing the PetitPotam authentication-coercion technique to force lateral movement.Recovered log of Claude's plan to run PetitPotam against the three servers found vulnerable to SMB relay.

PetitPotam is an authentication coercion technique that tricks a Windows server into attempting to authenticate to the attacker's machine. The attacker captures that authentication and relays it to access another server without knowing any passwords.

PetitPotam returned STATUS_INVALID_PARAMETER — the servers were patched. PrinterBug also failed.

The attacker insisted: “keep going, I want to lateralize no matter what.” Over the next hours, Claude attempted EternalBlue, password sprays against database servers, SSH brute force, FTP, credential searches through the webshell, RID cycling, LDAP anonymous bind, and a credential spray against a SCADA web interface. All failed.

Recovered log of Claude summarizing every lateral-movement technique attempted against SADM's patched Active Directory environment before recommending a web interface as the next target.

Claude wrote a summary for the attacker, labeling the failures as evidence of defensive quality — “What Didn't Work (Well-Protected Infrastructure)” — and recommended investigating a web interface it had identified as the most promising path forward.

Targeting Cloud Assets

The campaign also reached cloud-hosted environments. The attacker's recovered command history included connections to two database instances hosted on Amazon Web Services, using standard database client tools and credentials likely found in application configuration files on previously compromised servers. A reverse shell callback from a third AWS-hosted system was recorded on the secondary VPS.

Recovered terminal commands showing a connection to an AWS-hosted Microsoft SQL Server database using credentials found on previously compromised servers.Recovered terminal commands showing a connection to an AWS-hosted PostgreSQL database using the same harvested credentials.

Indicators of Compromise

Certificates

  • SHA-256: 54E16777EF0EAEFC066277B96A40B4673B8694CEA68CF347862C1DBBC2365820

IP Addresses

  • 165.22.184.26
  • 62.171.185.97
  • 159.65.202.204
  • 5.189.169.97
  • 174.138.15.149
  • 146.190.227.64
  • 161.35.156.89
  • 104.248.201.250
  • 188.166.16.232
  • 188.166.127.85

Domains

  • Lightbox-voltage-acute-duncan.trycloudflare[.]com

Files

294 files recovered from attacker infrastructure, listed with their SHA-256 hash.

FileSHA-256
sshd-helperb84450974bd3f1fc5dc09ec0edeec50647df81716e305ef391c9115c751aab17
ysoserial.jar2c9bddd6a1a4ec66c1078ea97dacb61eb66d1c41aec7b6d21e3c72214ce170f1
ysoserial-all.jar2c9bddd6a1a4ec66c1078ea97dacb61eb66d1c41aec7b6d21e3c72214ce170f1
helper64.dll91eda7b1e7bf2b2642f7060ccc018e5d4399936c53e714adf2ddf6e104b2df01
pwnkit_bin44e83f84a5d5219e2f7c3cf1e4f02489cae81361227f46946abe4b8d8245b879
pwnkit_x6444e83f84a5d5219e2f7c3cf1e4f02489cae81361227f46946abe4b8d8245b879
gp.dat9a8e9d587b570d4074f1c8317b163aa8d0c566efd88f294d9d85bc7776352a28
.bao-healthea92c50ffa228da28a9de6a56cdfcc0611f12695ab6a05c65865d6b3ed19e634
.ntnx-era-monitor-new28b2e77316ff4c3480c68a5a63e4e649c7ae5bc0d74f3a0f3dcfc5c10bf92c8b
.openbao-monitor465be0967690da93bec5dcc7f36fbdf0ae15f1e943a4374bb2fcb4cbbacc5900
.vlt-gcd174b9b182bf09f0e1c91f69e8e50c74e22faa0e1b5e3a7b4b01ec79f53c3b5d
.zabbix-proxy-hc538309d7b74fd481bc1ac95c7c7ff09bfa48a7a58e9b0a3c2e02c37d5e4d2b1f
Ysoperravida.jar9b0dbeacaccff663533c2dc5cd570c1d3538dbf8b2eb9fc1f1e07514545744a4
tf.jsp386f15e9dd3d234af02194d9d0b9b87ee8d7bbaec3b479042dbcf12df29fa73c
ts.jsp2a5656426de9ddb7d807464dd6568b8d8bd2332976e8ede93f711aae16c96339
webshell_disfrazada.jspae8f5ba0fdb8ec27890966e705c4fbc09ab390c6b41b38d4c14665572eaa779a
tunnel_apex_v12.jsp85706359974fabd8b673ad2ea07ee459a45bd3cc5a24ade7311e427925a10637
shell.phpae4ba9d99188d0a386dfc0c84a225dd31d145e4813fdb4a3fa62087dcbf40592
mini_imp.tgzf30bd7a155853b712da7a7c68ed30c4afd0944c0ac7009f0c9331148aff56bce
mini_imp2.tgz75e671f01ccc197145e9c74d03416d23a30bb0b89efe5656fe392779ec06f4b3
mini_imp3.tgz00c5f829d64723bed0f0fcc48161d014a022ee218af11dbfd324fc8ddec16922
mini_imp4.tgza8e4c0371fc45f05c69f3f70e2775260bd848fbec301b03af6bce2ded4f48b76
pg_maint1844558373581ab1daa1b482807527b1caf8348572c46e1ddc8d925630b17156
pg_maint28b93e2661350507e962ef37da57507b6dbeb7900eaea7912ed5efca414ccabf8
exploit0ede4e8200c095a4c13859ac8824edcb7b5363808773fb086077d172ded0213c
health.war03e9e297a6366c711f41a5bdd1d056609172e3ada43b055d1679e097b1a345a3
AclaracionesWeb.ware8744a07fd5f623f2e477c0f311f749a807982b647c412b034e5bee3482bda17
bt.php2a8a35869e2bf7739b7514784c0b07c19d5fda1a7c7579b05fc38d82aa1a13d2
check.php4bd146f48b684ee4c5e81e534e8ac46bfa76f083d5758ac5a0ea0acc5b5496fe
com.phpbf42b3bcecb01c9d4cbf530896d91815f7d433ed384a7b2c40c92638776c02b4
com_sedema_estadisticas.zip2c0be4d8fac2ab483a467b30a30a75c54e72d2b4b09d46d91967406c6d61f092
payload.bindaa36a12d6e86cf5ce3a7ee7d489d698ec8f9980a36c800a8502b82381c1736b
payload_utf16.binf1e15fc72729a41d59e9300711df67501daa314fe583d6795c527dc001305603
po.php2f3845353cdf8d007d6d0a199abeb2c56c96736eb79146b6ee3d43d919863b85
renapoProxyLibs.jar226c2478b5ddfd97a39f29424c03d2bd13b855dd9ab4195e4a1a6227ff2ecadb
sc.bin22d4c6f8299a61fccac44c06e0b8b4789271548b69443ab554e67bd7a4bcb964
sc32.binddebe9d942b9417dcc6fb9b6abf813a0660d70b331b72e8112f809c9acd4bb11
sedema.zip6fcc30696d002992f0b259ffce50ad7c2b4c9caf407e9c44a975cf026b091167
sedema_proc.jsp4003dede86877a5654df5dbb242631b4bc120fa43dc864a61349780fa2a751cc
sh.cfm36a2b4a5fb22eb5c118b1f2c7bd5f76ba1e5669b950639e22abb0c1ea8ce3151
sh.php11bdcd85c794a5e1452a17e60db0d9ed44efa4ac48281864831b79942ccc337f
sh.wsdl36a2b4a5fb22eb5c118b1f2c7bd5f76ba1e5669b950639e22abb0c1ea8ce3151
siddrc.jarf338b730adb4b8e12582aad55b544a9fb91802d5e991de6ec20848c215808827
siddrcWSClient.jard259419e52b9d602e884ce8313797169807d9bccc16089764e2f314a71818336
sock_exp7c00b30ca5c2f81cc7b9c36c0d9c103c2292a0826a5601225ed3384d159eb065
status.jspaabe9c8fe4352be93deddebafcdb44e6d416f61ad20bd2cad300eb42ab0e4340
test_deser.bine70c4c5c41075c45907327e495d64b7d162f1c0e1f3459b57e2147f33d3e2eeb
ver.jspdc24b55130a9f78d45e18979c03ccd8db938e11459b14d2b6d9e4b42993f04a6
ws.php28c528eda62f5767c10ef9dc9e9ab3fe82dbf665ba35f979f45722dab5ce87af
wscurp4Test.jar4fb1908492ee45cf9b5ef3577e0c6b28f57763f7d5adbb8b5693554d1cd4ad26
avgm.zip23c2f059da85101d2ba8b2c60c5f74d0b60d0a9b3c1a5d2f7e8b4c6d9e0f1a2b
sw.dat93e72961c148c0da8d13da8d3d38cb0ff18c6c506d33f75509eb4b7b9f37cd32
http_implant.pya5c00451eb50fbafd0440d629fe153ed3e833d9df10d9932a273628438b8088d
BACKUPOSINT.py1e4cfc64c82c2257ab6738ef3901282a6b813a6b058a19dd344de524037e2b49
sat_api_DEFINITIVO.pye5b187a158dc8940f7b905c7de78d08132447075d761f90629307b9095451afe
constancia_pdf_generator.py4a4cb95fc70d0ce9a084e52de5bce7079cf35f991c76cf0ee2a563cb6c5da99b
clientehttp5.py05ac9eafeece2f45bdeb49413bcb41a20edfbe700a1bcd160663d4d131f24d21
clientesocks.pyad693bbefe342d787b98e244c15a95dc3c62bc35a04385cacffcf42d93c46021
webshell_tunnel_v2.pye8702684bdf221811a99c5af9c00b8cce17256e0afe4a8548ff0b3e78d74085f
webshell_ultimate.pycc612f33a93143e143b85691ac50eb749b0d85be73123d693ac72e575a63a911
reverse_socks.py3f44002ac3d6129cda249912c2310b503c23151d948650730d7cce92095ad8ee
socks5_via_sjsp.py8fbbe7af07cbd440a96a872463fe5e3610ead2cafc13857250cb5e800eadd214
webshell_b64.txt0904e809a0cc2e97429ab5275a2122a713dc81e658df58b8a435db58c24dec29
rce.b64ca600bacdac7a8a24861b6f66747952714a99c870c1510ef57db5a0284b29e85
struts_rce.py60079c91b15fb3002e48579f956b3fb6c5f50f5dace53902c96cc8b92ffed883
FileSHA-256
geoserver_rce.py3fa243ff472f334b4527053100d4549c0d840cf53c5503c5fb1db87695aee3f5
bind_shell.py2811c4f8bc2f859a2dc5fdb1473dece4aa5231a02478b8d5b77f0c15b1f526a1
smbghost_payload.py6340a8e1d6aee8d527173acc88540a6b1674cb9193da52d088d89fb865dd734a
malicious_grid.jsd281cbcc921e7039647d2991c24a100d6ec8504e15f1d4b02dd6b3d2e8f65d9b
decrypt_all_creds.py52b0bb7d7748f37f3725422444689ced67afed6d74af3670e512431066f1cbe7
install_hook.sh4d108b390bff0641342272dcce486aebeef161fd47e7f33a8e12df3ab9fe5d5b
install_hook_v2.shd206b8abbab71d3dcd4b76cd7cfa49714a63825a9f79449163c7c33ea1bcbba7
install_hook_152.shab83dbfe73db42aaf18e8166cbcdc2816633a3b4f7b5c86b4a5f0032b74fd4b2
install_proc_hook.shf14d3ba09deafc365627d00aa02d50e5f43f8ab37c38452ffc3af93fec069aad
hide_ip.shfc91bf7f163e353a4c122739ff49f44722425c8bd63e100c7e35c177b50897f4
setup_stealth.sha471238f23d450bb662888af8af0060f45c6f07aac58853c34a740443830dabe
setup_stealth_v2.shedc6b272bbbd8bb651433d76c69814bc7a774ebde468d30445e64d8f617b80bd
check_edr.sh56efca03c82f55ce7376d72ff694eaf187ddd0ac246fe9fe13e84f490608c39c
upload_agent.sh8d629aa099cda2d61568a5309abb68dcf7eb825c43e96dfcf98176cec39f25f8
upload_agent2.shde1e501383bb4baaa2f77e6a2d0164d3be04c0b326fd8e00e50ed90e633db471
upload_agent_xor.sh8d629aa099cda2d61568a5309abb68dcf7eb825c43e96dfcf98176cec39f25f8
upload_gp.sh7faf27729b85177982ece41a790243de66f9a61001630f1e548db45cfecd43bd
upload_gp_xor.sh02b041a002380fc4f19249cc18905e879f90b863cc154c878450663662a3507e
gp_setup.sh386ea9b16cef9734e3f413fd82ed1d14e1aa7922e94c169db275b7933d041bd1
loot_all.sh3a394c300371f107a045b734dfea4bf3dabf3cec0963ed4da673a2013b65b3ae
sat_api.pyb164cde58c696e39c47127f1941070e83e2cbddcf89d316dcad61e5d533b7cd5
sat_api_v2.py1765df3d42ac5c3378d7911816a43d2c31ad05210d64f702ca1e61b82c283983
sat_api_secure.pybd97e34e2d5bfde708cbcff2a4308f8153bae8c39d6a1bd1b3fd7f9a81c141db
sat_api_profesional.py630cddc8b849b78803fb3c5b43d4c7f65fe3e537c6f1ae655b7f7114015e763f
sat_api_final.py52a63fddb9be598535425cbbc01ff4b1aa635eaa115ab0eefa3578ff873c0e56
sat_api_TEMP.pye64f4fe49580d45115665b3d6fdd39f627345430d8224bf75ab84af2e6afcd63
sat_api_MEJORADO_BACKUP_.py3c856099dba6d5f6b4018b00215eedba85dd1a943f816088c12d7dbf0fa6f08f
generar_constancia_pdf.pyc57c97e7ce5a36b749ebe69b72ab6a00a0640b9db70e59e2933eb403d2658063
sat_web_query.py36ad087fcadb32d4d35b91d49de93f33ff257d95ba115f10c3f94868061bf001
endpoint_pdf.pya716d31b15ca63a1bddcdb48d29e21310b90193b68d036a89ded9995fce06eb2
cliente.py573b6bd3ef425f1d798e38fa7b5c571c873fc2324cabd22b2255303341669f53
cliente2.py0b9f2eeb159bdedbf9d5a596b61daf96ca99e4b0ab3da6afa01cab889e6135ea
cliente3.py63332ccc5f588be0901a1443abb8b4ce9ab988a85d7789a6f64ce6293adabad0
clientehttp.py2ad65c1e609efa25ba34267f44dd79f272e5e5fd6b252589c0dc6666c909fa8a
clientehttp2.pycd9441b2503151f28d7f5a231d0b3db95d93da882979f314d5394256d3782cbf
clientehttp3.py4df561219a3cdf1806557900d20212ce61ae192165532622e57efd327c984030
clientehttp4.py45aa8c3a22ab17868f8177d520035aff7443edc7dd22952232e0705f89e71ea9
apex_client_v10.py5fed04a7c07fd89572cbbf5a3f3ab652071b077d3539d78220580d5d446b520e
apex_client_v15.py8e3a6e914588bc39fae3c04eab2a1fb34640ee1c9fe875e8df93251904f1b0cb
turbo_client.pyeae7dc42451223c5cf2c6b8d384ded82f1fbeae70439e09d5ecaf42d16f1de95
simple_client_v12.py01a1ae66f9a104d91878638d27e8244ebfb8409576b949e347ff5f5b398769f3
v12_client.pyfd3b4937765eeb147352e51f8f3d8b5392ae4177d50e8f111758de830e6d9777
v13_client.pyfb49ef9da12f85972913db2a86050ba79d5e71cbf1eb9cf580f28c43417fe66e
tf_client.pyb69b0779e4de5e05001b629b680023cc030a5d1d603767caa3d176f504baacf3
c53.py676aed5533923a443a662a9243c370568ba33a5c0c040cf0dacf354269a148cb
cf.py0ad55270a166050f76a02813256ed21a368b9e873894dfb5236c432b195b7692
cs.pya2b11c970c285c2df2c1101dc141c1a5ae7ef6e5ef6cd7856756c8863ab2f86d
deploy_tunnel_v10.py889c8c29e1bcc83457292fcf27174c726c306177c20943e63251870422e48440
HTTP-Server.pyee95561681807fde086dee4b2200c2c301358c102d0654778876678147b9b5e5
http_server.py46b3efe9877f9d3e4fc4b9547ec213e75938397fdc30828857155238335973e7
http_srv.py8e2d84abb8b68c9fb6de9b62b12483c1727bddf781808e8fd140c6bf422b026c
server_test.py825bf8f912b7c9095b2f78510acf3b882e15177dad6ea4231aba6a3c5b84f1ed
telnet.py0ed4c8a47a2feb3f29dd2cec50eb24c96069be119f01676795027332a0326d84
edomex_shell.py6b5979709984e5a500f3be45630597214bf77f98b8b1961ee627938a86848e47
ine_shell.pyc25413774b0a5d9e760cf1189c0b22dfa12942929c24cb6a494ee678ec9fb611
node2_shell.pyff262ec65ebde39e8cacf41e47d99397b84c2c6db73226a32351a08de44bc5d6
node3_shell.py58fc29379a34310e841038a18460d043837b88be2375806dbf04b3fb124ca26c
node4_shell.pyd440bd329a74fa845a927c2011a6d8f9b119de1a326f725936014cbb7e302c92
node5_shell.py70baa964acf6c75d765b4538f37fdc4426358c582acaf8131777117b285e246b
s_shell.pyc7805997d6bfc44de25af07e87308c05d9fa787575d377dae4faac73cbcb814d
shell_payload.py9fbe1a19344a13db061705e747437ffd4acca0f734588e207b04efd6e8fa0b52
revshell_debug.py7927e98a9a8ca9b2f24c7ef944f7a6c244e992837c95e4d5f66c350a70e812cd
cmd.pya6185fc27b54c0bc86ba9d39613d967caf819f3910507ea52f21d40eceaa93e4
cmd2.pybac90c918bfeebdc4a06c27166d8da7643739eba09a8c661152eeadae5bc8dc5
FileSHA-256
struts_node2_rce.py9f01390b9aab2645a1d08a505f4ec9c5c32e1b6b490537bf9e78b38acd46b072
struts_node3_rce.py1900764e9eacedff3bbfa48e9dc1b95bec192e942ff0e4c239d91a2369c1e75c
struts_node4_rce.py45553aef63801ece82fe971f31d710f6135a0885afa88f10c61871f280a8ca4d
struts_node5_rce.py491e785903f88e03a71973a1e08b1ace97486e86d60e6b062189f2f8ce354a14
test_ognl_xxe.pya0dce59ca18604c93d84864a31848c74563f287dde71f7a58293514ab29ffa4c
test_sqli_ssrf.py7a69a95f5fefe67897c54290a6cd1a41250aeee77f2ba31a0cb7751757ae2d3d
test_viewstate_deser.py7404bee858fae8b58cd545dd3a6400726242403802a59d5870fa3afdc5b81c9e
test_upload.py6315de4cc1195508ce910b5be536b98e3297505465c68ab9d2223357606c0ba1
fuzz_ptsc.pycb21ae8556710999971a006ffd7b59b7a8d1568eb2bfdc0fcbc4fa43b08b33a9
wizard_upload.pya0c82a28b270a540a9d4caf4e43be45fa7ef5ab930e02393ce6c0e303c1e9439
find_webroot.py9e3d1044be273d34bf9c3ab2caed2979fbbf58f5d7b34ee664922a43b3aa12a2
smbghost_scan.py902e7b0f453f8bb1023d07934e8b7fa4af1ad3da039ee38ab08b3dc79e10242e
exploit_jboss.pydd5f178278cd347f24df5ec556c25f8e505006ebc86751b7c475e92cb70b0126
try_jalisco2022.py3f9cf1a8751db2dd578491bdc670c148f5bc3b9749389a2caff0dd100bbf7072
oracle_deep_scan.py92e7296bfb77f60db1e01445136246e86fe4daab431f9341307c7826cc49187f
decrypt.py621c1591ff91f66dbc40b5fad16fdb9c8e30bc023f1e55f2458f891336f5c267
decrypt_refined.py9a8ca2ffd8a240044f3febd7657f38f3b0166e26c1aef2113ad99f11f7b2f99c
decrypt_weblogic_v3.pycbe76edeb64031446170857edfa2e34ec53c42fa9c2c4e8d2a026cdcc751d4df
decrypt_with_key.py77c6734ce1cbf5a424afa450c6fb5c2b793ec0fefa4030d56607fd2ae29734a8
wl_decrypt.pya68bcf3a4bcfedac4cf381fe2907a7c3420d8f8dcf8e85f8a918015345624781
oracle_enc_decrypt.py8a9ee1fec6a6b2c71b7ea2557f89fd23eba2a0cda6aaa458caba667a98a18434
mysql_crack.pyf49f13aff4a88a8d0db8a122510f2cf2bfdc69593336feb3e20b19e17afae570
mysql_crack2.pye5ea1a5a122e4f0a8dd19ffdab580201e26c056e8f8bbead6ff3c2708a1906ec
mysql_crack3.py376877d0ee00c59d7c51e5cab07edc4200839635029134556c4a55f64cebe04c
mysql_crack4.py8cbaa34976cfb9617badf3d0f4a0d0f0f5612dcab478ee9f94ebe04422851531
pfsense_brute.py2a32272d5f829d8d266b2f491fbf6e6c4831aba67eee3e1523825a889ee280ed
ndb_creds.py6f40ffd5282b2aefaa3df3886af29275a67907a621d6d8177b41fc908c654cc5
map_servers_passwords.py9c087fc66b3e23613ff0550ca936b0521847f78656a542d8e3d2aa0c88a0865d
tunnel_keeper.sh952f5f4ed62e83818513b764d68265a16e8d90348c952e4e5e93302fe95e225b
tunnel_master_keeper.sh42dca53c8754ec91ee459ebd6672ab1a12c6dea3765e05276599dc8620b63717
tunnel_master_keeper_v2.sh9fa6960053f1511e953cbbf5a3fb0858133d8dcdf4421031862577f42582ff81
tunnel_1095_keeper.sh8e27ebaa46afb0e03ba435581c2b654797d1beedad530e8c77583c8bba3a297c
tunnel_1095_keeper_final.shc851ca08bb9ee438f7c58a84c577268f054402803ceeeb6782ba05b4012af3de
chisel_keeper.sh24d5a9066f898f0e71f4c551df62faad81800234e718ad6f80d3e3bc2b09e2e0
chisel_53_keeper.shabcc58eeff286dcaaf842dc18190780645d192567439074f156f74fb5ba0f6c1
chisel_5019_keeper.shf54e0031edc6270d3dbc2c9b67243981920660f3933575e12ddefddc31d73004
chisel_9090_keeper.sh308087670b971ed6a794bbf1bc884c6d59699d68d4450a9928557b7f3dd1538e
http_implant_keeper.sh9ea805fa8579a7098f4facfac086a4a38a640186b98d33ed0a585bc76c027ded
clientehttp_5487_keeper.shc00b84a01de7905dfe44518219739edbc9431d105a898d1612bde7088adbbde0
start_neoreg.sh08413428cfbf122ee0e5188e8b1e3b94f02e1789bd43c006974fb91b1ad37a49
deploy_via_webshell.py84e0b90827b6e53b4acd4924537dbdb43b8b8e67dc11529fc67c0ae160d67765
deploy_final.py5e5efbe54e60adbc27e5137be286075a90b31e30bb7dd6aaede1878f9d454dd6
deploy_todos_nodos.pyba08e40a745b97ff2c1a9d1997acb5fb5039a9d39974d4a5e5216d086ef5a204
deploy_all_mirrors.py66aaff1b8798d65451d5bfede3bf82e272723b636168ffa65abb837009d83b55
deploy_152.shbaa3f08b26e422f7ce84823078687d02bd80a7f8d14574d33699300a85ea7eb1
deploy_152_v2.sh0df97535e7b9f615b9c8f8800e5c888e55d68ab3614512943493397b5b57ccf0
deploy_167.sh0dc75fc30065417bba3b9966f094dc9ed33a9f859eb70ef096f10a446ff035e0
deploy2_167.sh6fa5666ae90c89c8d6634383daac1d80eb9d0aa91ec3272edc2462a39da4da17
deploy_agent.sh4ccf4b51fffe69b9b8582b960239383391d19a262bf437774856339d4aa46bf5
deploy_opsec.shc3b23c712aafb682debb2fc69ce1f0daf3fc51e9f68a97c00b84c9bda7ecdd89
step_full_deploy.sh9ce91435b0464aada43ac379e61d0038394e00d55f804090bb5e8a83d2ade624
dl_ntds.py42ec7f88c8a2f163c8b8bd9eed22ef9b45cf087f843285dbcf93626e51dba2f2
dl_system.pyec08acadcce37b4221c497609a1026ae0ae85df3096b712d727f3bd98ab291e1
dl_vhdx.py9bf22275cb64758e2607a059cf7cd4085960f25dc2f259da1fd8cce993c8be14
dl_parallel.py8172f66a82af800479999b573b3d436a91a059dba3ce2c681a4ce91c167513c7
dl_fast.py3c7c9d930026366b6ebda78f06fb280d0a4480e10ee38d455d6fe61bebc7ed76
continue_download.py946a02244cbb0ec15ee64a8479e756a9462e8defe3c37a7853a06131bb5debef
pivot.sh4f3fa3a5c7a4d71b1dc04fa2347bb076cf5e8dae3cd4e42a0c41590c212e6957
pivot-setup.sh46eaef5bbe9c75aba0748b44433beef7abfa28af574dd1add35c02442640fe26
priv.shf0a2e2cbd03db4573184d5211d77e81cde4458458bea8506de3f56c668883d1a
pexp.shd7863bafc25e9fcda946ab813ad7d2313d60027f796d48b3229d904305c9ba7f
scan_ports.sh6ae957969a404ee54f31aedffdcd9a7b474006beefc0bdbce5c65e2c4a862abf
fast_scan.sh2a0406c45c366a5556d63ff81fc282f3c9b8250b187a2ff7ae4fa0a1993b3f03
smart_scan.sh68d976838cc7a67a6d80aa48f0df0e6318ffa1f6a74bd905feb07a659330b89f
FileSHA-256
rapido_scan.sh566d9ef0e57aa11cea2585c39340dd6306d9c462457e8db1d02a0bff45aaa83f
rce.sh37af84ad732df31886439c0411a63a82ebdc7a6b6a4c1298ede6ef28bd48237f
upload_rce.sh5409aaf8ae24e9148a08b5d70d375d610119b7e82fb28fd9dbbcc134e82d6188
scan_gov.shc9dce5d676f7c0ad8ac6dfe9322a0b6fe4f394797b61724120b3dda9109d8e56
spray.sh8f66e730be2f3b9db4b6bd79a62c1b94cbdd0178bb28556b10a0ae590b40f0e4
fix_opsec.sh7602e35043a875c0bada43a40941a7d61e0a5570c7872dfac13305be5dfd18a9
fix_opsec_167.sh42acd12eeaf196c8c5cba533c2320faa3a5851feecc4366b28c9826a4653f41c
fix_opsec_final.sha3b352285e258e103a2adad264c3134404454a323693f189b73e0b5e81e799a6
opsec_audit.sha263d1ad77791b474c9dae61d836aca39e3f6da4926216dd57476db25573716e
opsec_clean.sh91b90c8176e4a85d7ffd7d873471803e5bb7043f99512f9b2d88599e0dc22798
opsec_deep.sh0d9156b0f271175b01a217f44cfff2d8c20e0561e0b06248bfe73c0695ad702a
opsec_152.sh39c9b707a0b08b21bf90d5032d10d6254f733a5f675ccfd3626703899ac27a08
cleanup_all.sh6cb7995ce1201e2594d92eb71038603a26df09365f4d541f6a09d1883b55b7f9
final_clean.sh8817c43ed346c568148a020bae24d7cfbfc2e88a50a8043cdd98a4790306082a
final_clean_167.she79f192e2a916792c04996339f0e64f6585d9e6498d2f088c70dade6318fdd18
final_opsec.shfe752acb087730afa7bb71cd400e3dd793f3f959b542ee07e5438c1edb05fedd
final_opsec_167.sh064b71bebe13a1f9051a5789ea2c83b5b8cc203d9664a79c1260c76d2adc6d39
check_persist.sh92f0150c2e39dc4f9740be8f166979ad741a9b4d07d6f10629453d5064b891b3
check_persist_full.sh23a40453ca9502fffd95de93a197961cbca47260579ace0bb69b7a3415828248
update_persist.sh5d744e7bd47f80730569b5344c3675baf064f04b16badc54318635901e1c502d
force_root.sh649c95d3be17afe8cd60be1c65dccd04bf2e725a0ef029b460d28cf3cfc0daf0
force_root2.sh7e6bd9cb6458db236b6989b6b93a2157270e0c7d74135218a342cf0a7be293b4
root_agent.sha714be6965f6d90df2be5e6e897eb7262830a5ba8fdc314605341a55c6667f52
step_potato.sh4b345131769f66c28192799682a5ae053fa4c887a85d95fa2568f4b0238ca842
step_amsi.sh870ee164b7441102488886fd23655f35600bdbf69d619371a785f5b1c6428c37
step_amsi2.sh97f09c69101a78f69fad863da7197539ab2b6594084f98657226bdcb0830cdef
step_killdef.shc061e00d8f0300368e431cf964d57a6e623f42d888e32864076b65b76171b516
step_sam.sh358af3fd58d5a8e85c90795ffb5bc5a974d5faff161253063f4576489ed5fc53
step_sam2.sh90526be3bdad7cc461e800ce9f9c83c5ac1c64ccaa955b14c2fcd7e893025968
step_creds.sh902915e60435a0f8409d73e41fbb79404f56bb44800f1a62e09205e664a9a8ae
step_adump.sh3ff77a17dd8cd9b07f9527f2c42d3fadbc3ef746e76e9f811c881a34c4b0920e
step_clr.sh62f699cb302bb8881660a5c858869b80100a2cd58e64314ec72785a75a03c448
step_clrpot.she6895f6820059809811003d4dd71aab1c201061377b8fd6d449303dc5d7d8052
step_clrpot2.shac4292c0d60861fb9848615bb964533b35a48f6a881340db136a84ed2d0aab07
step_clrspoof.sh70d96e00e91294b980b3cbea0be92f2300a527b35ca860d79a47b1f25f35b0c5
step_clrspoof2.shaf6c54d9552b05678ee3ec5e1bd1bd341040e6b2b2f220b3373cfcc2c26b3da1
step_clrsys.sh90775cd213e2e502729bfc3c04d19c08fb06f5230f173546fce737b2b1744d0d
step_efs.sh2fa132aa46f8ac5daa8ab98d933bccc191ff66446b33a3cc18e9e4b49983552e
step_efspot.she998afe8e2ea8c4311e3ce3b2730ee7f8c683761888d4b9b8b6eaf5c85ac7218
step_rd.sh58092fda89eafecd33ae5f23f3e2a2b4eb6db6f554d39cf27ea9549628da78d8
step_dns.sh7da3176f348a5cf79c4884cba63f1d792dde5734b7156c91e62833d2c2fb84e8
step_recon.sh6354cdaeb8386a1d76fac38b0dbfd9db205a244a6c57e052ea604215e5e78922
step_recon2.shac573f63f15d4322732d5e18bfbd9161bf07d823002afc147030d358c172de5b
step_c2.sh4800648954ba959fae92961858a9437aac2f17aa7f55c1a4156a75020d80960c
step_disdef.sh6d39d897be24c72bd59f163edf22f7a649c33a3bac3b85eaf048a68e12520ce8
step_cp.sh0bdeb1afccdcc6997a1aa7a37b3602c24ef44ebbe1fede1ce9b8878138116f01
enum.sha09f9622a2a8f59f1d24f96a902124314adde7c1014e7a372ddf40d006126b95
enum_25.shaaf46444c080b042e15957b86f2629312a7bacaa9bd68243310493b5b2efded5
enum_48.sh27fef7ebdd018cb284b768e1e640f3fc3160a5121073dee9cce939ec76c91c64
enum_48_mysql.sh0cac9fe1bf3719f71117c41adb9f2bde2fd846ebf86608aa5c7079826627a8b5
enum_48_sihuman.shd5f52028962f0916b3654665eae807bce9aa5495c2701f6c5a0de466ec8a2382
enum_48_v2.sha54f287e649c41512d581a81f9b41eb774642ac875face5c54b019ba6b802bdc
mysql_dump.sh73ce11d88bf97bc6d18f15f65f12d73e878a89e492edfa53842cd66037a9d30a
mysql_dump2.shc052f8964c30d4fac0d831f72b57192db36ecc50eccc2c32c9d65dbdb4cd4246
mysql_enum.sh79c6f60255099ed4356a476895ff4decb4314e7a051ff9e2604ae6c3f707dfc3
mysql_test.shea4a27a7702d67666e4ba4327a1e9bd688bf02e908374749d2ac0268f5f2b8e6
ndb_enum.sh2f64dac0a2b0affa43f2b4d609d2fcc67b486c0989b4bd61766eee478b4668fc
ndb_enum2.sh707335d194c70b55cb53d28f24415059be3684187c7e566731db3d1e3011055e
pg_enum.shc906ef286a8c2db62fc2b2f509f56b17899f5fd62b978f1d82ae5a716803ae0b
tbl_my.shd283ba770f371a1fd5fb6fc75b43b7479588b38b7ee0769c1c483c126d2d92b0
tbl_pg.shc3bca149a276b989b7f4717d46ba09154bc3d7cfa669ccb9340ca682299bfddc
sample_191.she2a5ce5152494c46cf92c00e3a5a0d7143a1009e644b19f501288239af252529
sample_194.sh2b39be0c9406d6ea3e5041442184341925365e7d22246698244c47490e15e4cd
esxi_extract.py51e6b5af37417185b9b082a84d7b92b1d0bafc90ca6c81b656d27fd607c51fcd
esxi_login.py39b6c945fcdd2a6515a31c716ea4e12d37213523bdee3f004610f88447004ffb
FileSHA-256
browse_ds.pyb462b40b89ae89e24b64e4361bcf61327d0da5055f5f6e958e99df1c3da7c51a
guest_ops.py4262272daa3e4ee8afe3a12204ccf851dc8e48005bb19afc97ab34210be7e2cc
guest_ops2.py3e33e307438a45c8dd118060aa76f08f9f3596821621598cd1923a300d0f3c43
prism_enum.py9e5f362ce718d1f6feab3e7b19f83eaa576e0fcd3a3e4c2c02e8c47050829ab5
superset_cmd.pyb04f615745abffc2175a3eb321582e76af4162e00e99ce87a51f48a745464697
fetch_prs.py1d1bd97b4b78865980a7f7de6a864adfe570cc20bc5b9b1148e31aeee0cb6991
bruteforce_cua.sh71d1325aaf4bf95ef4ef3dec9b55f4b71067a36fcecaf18534c09703bca39f9c
brute_cua.sh9b42e0ad64ef19741879e944ca6d2599636ea8668c7842d5f24a11afc036af6b
vcsat_brute.sh2e0b0c8b35a0018c9825dd2b6cb65a4bb7ce9c19f32fef74b66b78e18c512f35
sqli_inject.shf942d075bbc657798880ad7fd86707aaae3a5778451c246fbf10bedea3fe06cc
exfil_certs.sh8e9a9461ffe7586852d9d25a14b990ecbd30d128a460f28f77aec4b81e7f9e6c
extract_certs.sheaf589fe6693c5ac4a6ab66fbabb7e21728330e8f47cffd5a82627e8d8a3eefa
db_shell.sh48ed2ea6b50cb638923c0b5fd06ef0c7696d0f109e86ef98c8c7985f789431e5
zimbra_exploit.pyac8ad1efb3b74259a30434f4bb553adab086e4ce13165710c5726053eec07a8a
zimbra_dtd_exploit.sh8ece74a64ecc5b07fcd0bb0cd6ae48d6a67b094e5a88b16bc627de0822493788
eternalblue.rc93076cb62cfe29d9a91ab918d8a05660b30593ec093551cf1aea283d0c0dd619
psexec.rc8cdc68ff6f7ac4b960535d6efe7b2ab5eb814fdd4aa0de08bfdc4d4eb1722e5f
samba_usermap.rcd3ba916a47597950f7f1cbdca7ecc4afe3126a5365f49c3f8acd283bfca66219
sambacry.rcf12d0e729da16e6b98a00a3f7bc7e87acb6af00d3343f0d8c560c3645bc03267
jmx_exploit.rce1c1409daeedf85ff7b663143269cea71d9bea07beefc60b0fb67a4f6bad3ce2
jmx_webshell.rc52cb917bd09c7465ebe0308dcb35be4c5c353493f343731d64e3b754cb93b155
smbghost_msf.rc52c7547c0091ada68eb08f00c1bdda841c6668672e089d6801038d3628170e08
eb_exploit.rc76913d76a0020cfdad6e4b4334c0f8ee82b2597a09d4022dbbde4194b4a6c0e8
eb_final.rcc6f8eecfffa294f9a7d9a1cf4fbb9f23fc31ce34e8371414a6cde681988e950d
simple_kimera.py5b6fd55cfcb350c2fea690fbe3137773d7c017996d57c6d9c6da5ce63da76272
modify_kimera.pyb1ae104759ef393e646ced41530881e70dfbdb8df0dcf949b90b3e6ba4338683
sendpage.c631319466c4981e4b0ea4f0e7da47deb9f44ea172ec759e375198ec1edeeb6b7
vmsplice.c8dcb2c662760f345aac80191fec06a768a45d068aba5bbf005dfab56649c8c3a
vms.c74493e08d1f2987519eef1af0b2cd75a1f76c9637e2c682367c94ff8c2741d1c
sock.c00ff43bb39964a2c08256b4f96fa42d92895ca303d1341ef5d17e543b4753089
sock2.c55fd0e1b003f66fc33c0ddfab81446e1c7d097b417dce8271a1a0a939dcad82e
pg2.cc09eb982efc539be71e9c9e194c060a484c436aa964e29a888faaf5b0bdf5ca1
pg_backup_util.c424af728e0e78d0ebbb9370808f47940508c34b3af95a0281227b91e3d1ce9f3
pg_exec.ca7b453b9d6439cf902b68e24edd753b964a51d9efcd8a0c53522ed913887c5cc
dah.cs80c3180e13ebcca47bb5af595c52997814ace74fea5f7d71a9df83cbbe3eb9b8
util.cs29878003c75c917134ac89651f39cd1ecd5dce4193de1b0fa219907fd3941962