Executive Summary

CloudSEK's Caught in 4K series documents investigations into exposed threat actor infrastructure. In our first entry, we uncovered an Aurora ransomware affiliate mid operation. This time, an exposed open directory led us somewhere bigger.

An exposed open directory and a misconfigured storage server revealed the complete operation of a threat actor calling themselves Azazel, a Russian-speaking affiliate of the Gentlemen ransomware group who simultaneously robbed his victims, betrayed his own RaaS operator, and left everything out in the open. Two servers totalling more than 29TB of raw storage held more than two dozen victim directories and approximately 6TB of stolen data spanning logistics, insurance, pharmaceutical, AI, medical devices, and government-adjacent infrastructure across six countries.
Azazel was not running a standard affiliate playbook. He built and operated his own independent leak site under the brand LEAKNED, publishing victim data and collecting extortion proceeds without routing them through the Gentlemen program, a betrayal of the RaaS operator running alongside the betrayal of victims. One exfiltration was still actively running during the investigation, with a target directory growing by hundreds of gigabytes between observations.

Disclosure note: Coordinated victim notification was initiated ahead of publication for organisations identified in this report that had not yet appeared on Azazel's public leak presence.TLP:RED notifications covering full technical detail were provided to each named victim's security contact prior to this publication date.

Key Findings

• Azazel used Gentlemen's infrastructure and tooling to compromise more than two dozen organisations, then published victims on his own independent leak site (LEAKNED) and kept the proceeds bypassing the group entirely.
• Every confirmed victim was reached through stolen CI/CD secrets. A single compromised GitLab instance produced footholds at two unrelated organisations.
• Azazel registered a reverse shell handler as a tool inside an AI coding assistant via MCP, then drove attack execution through it. He also built dedicated internet wide scanning infrastructure to hunt for other exposed AI assistant ports.
• The operator's own storage server shows output consistent with an AI assistant answering questions about backing up his loot AI tooling used to run the criminal operation itself.
• Multiple operational scripts contain native Russian prose. The staging server was codenamed "novostnik",  Russian for "newsman."
• One victim's data was still actively transferring to the storage server during the investigation, growing by hundreds of gigabytes between observations.

The Operator: Azazel

The actor behind this operation self-identifies as Azazel across his LEAKNED infrastructure. The name carries deep roots in Russian Orthodox and Slavic cultural tradition most prominently as a character in Mikhail Bulgakov's The Master and Margarita, one of the most culturally significant Russian novels of the twentieth century. The choice of this handle is consistent with a Russian speaking operator, and the operational scripts confirm it directly. Multiple shell scripts and Python files contain fluent Russian prose in their comments, not single borrowed words or transliterations, but full grammatical sentences written by someone who thinks in Russian.

The NEWSMAN exfil server was internally designated "novostnik"  a colloquial Russian agent noun meaning "newsman" or "one who deals in news". Azazel was operating as an affiliate of the Gentlemen ransomware group using their tooling, negotiation channels, and ransom note template. But simultaneously he ran LEAKNED, his own independent data leak blog, publishing victim data and conducting extortion without sharing proceeds with the RaaS operator. The Gentlemen group's leak site and Azazel's LEAKNED site are separate properties. Victims hit by Azazel were exposed to both. The RaaS operator lost revenue. This is not a common pattern in the affiliate ecosystem.

Infrastructure: Three Servers, One Operation

Azazel ran a three-node infrastructure with distinct roles, keeping victim-facing activity, staging, and long-term storage physically and logically separate. Across all three nodes the raw storage footprint exceeds 50TB.

23.236.169.183 - C2 and open directory. The victim-facing box. Port 8000 served the unauthenticated file listing that exposed the operation. Port 9999 ran the HTTP upload listener receiving stolen data from victim networks. Penelope reverse shell sessions were handled here alongside the MCP C2 tooling.

162.220.163.26 - forgitlab. The active operations staging server. The hostname is not accidental; forgitlab.com masquerades as legitimate GitLab infrastructure, consistent with an operator whose entire primary attack chain revolves around GitLab CI/CD enumeration. 

The hardware configuration confirms this is a rented dedicated physical machine, not a cloud VM: an Intel Xeon D-1541 processor, 125GiB RAM, dual enterprise spinning-disk HDDs (WD Gold WUH721816AL and Seagate ST16000NM001G, 16TB each), providing 29.2TB raw capacity. Physical dedicated servers at this specification are rented from bare-metal providers since they are significantly cheaper per TB than cloud storage, harder to attribute, and not subject to cloud provider abuse reporting pipelines. 

Network throughput measured at approximately 848Mbps down and 91Mbps up, saturating the 1Gbps uplink. At time of discovery approximately 6TB was occupied across more than two dozen victim directories. All operational scripts, per-victim working directories, and active exfil jobs lived here.

66.179.30.155 - novostnik. The publication and long-term archive node. The internal codename "novostnik" is a colloquial Russian word for "newsman" the server runs the LEAKNED leak site frontend (9GB), a victim evidence badge store (80GB), and a 22TB long-term vault. The vault alone exceeds the entire forgitlab data store, meaning the majority of what Azazel stole over the lifetime of the operation had already moved to long-term storage before the investigation found it. Combined with forgitlab's 29.2TB, the confirmed physical storage across both dedicated machines exceeds 50TB.

MEGA cloud - 66.203.124.135:443. Final exfil destination. Data moved from victim networks to the C2 box, staged on forgitlab, then transferred to MEGA via mega-cmd-server. Three hops between victim and final destination: taking down any single node does not recover the data.

The Victim Roster

Correlating victim directories across the operator's infrastructure with posts on LEAKNED confirmed more than two dozen breached organisations across six countries. All identified organisations were notified ahead of publication.

Following the Keystrokes

Azazel ran two fundamentally different attack chains. The first is a purpose-built CI/CD secrets harvesting operation that produced most of the victim set. The second is a deep, sustained, multi-stage compromise of a single high-value target, an AI company that demonstrates a skill level anomalous for a RaaS affiliate and deserves separate treatment.

Infrastructure Setup

Before any victim was touched, Azazel's setup script installed a coherent toolkit oriented specifically at CI/CD attack surfaces: glato for GitLab enumeration, nord-stream for cloud CI/CD secret extraction, gitlab-secrets, gitlab-watchman, and gitleaks for credential harvesting from repositories and variable stores, and brute_odoo.py for Odoo ERP brute forcing.

Chain A - CI/CD Secrets Harvesting

Every victim outside the AI sector engagement was reached the same way. GitLab CI/CD variable stores and git repository history became credential sources. From a single point of GitLab exposure, Azazel extracted tokens, database credentials, API keys, and SSH private keys. The tool stack did the work systematically.

A single GitLab instance hosted CI/CD pipelines for two unrelated organisations. One CI/CD token gave Azazel Oracle and PostgreSQL credentials, shipping API credentials, and SSH private keys for three separate cloud-hosted servers belonging to the second organisation. Shared infrastructure, two victims, three cloud hosts compromised from one token.

None of the victims Azazel compromised using Gentlemen's tooling appeared on the Gentlemen group's own leak site. They appeared on LEAKNED. Two cases illustrate the downstream impact.

A SaaS platform breach extended beyond the primary target to more than a dozen of the platform's own client companies. From a single CI/CD token, Azazel reached more than 150 databases, payment gateways, and hundreds of source code repositories across the platform and its clients. Azazel named three downstream clients directly in the LEAKNED post.

A second breach involved a platform hosting a government linked financial registry. More than 120,000 records were exfiltrated across multiple client environments. After exfiltration, Azazel ran a python script killing the live PostgreSQL process and deleting the production data directory.

The ransom note was assigned a unique tracking identifier embedded across every surface. va.py verified delivery across six internal hosts, checking eight surfaces in sequence:

• /etc/motd - system message of the day
• /root/ATTENTION_SENSITIVE_INFORMATION.txt - root home directory
• /home/ubuntu/ATTENTION_SENSITIVE_INFORMATION.txt - ubuntu home directory
• SSH banner via sshd_config
• PostgreSQL cluster_name parameter
• pgAdmin login template (login_user.html)
• Victim's own GitLab repository README
• GitLab Issue opened directly against the victim's project

Each check was executed via exec_in_session MCP calls to 127.0.0.1:35367 this script is the confirmed operational use of MCP as an attack execution channel in this investigation.

A publicly listed medical device manufacturer had a dedicated exfil script written specifically for their infrastructure, connecting directly to a Microsoft SQL Server instance and dumping every table to JSON. Hundreds of thousands of assets, more than a dozen client databases, SQL backups, JWT secrets, and cleartext passwords. The LEAKNED post hashtags reference a Middle Eastern ERP platform among the affected client data, indicating the breach extended to enterprise customers across multiple geographies.

Chain B - Deep Compromise: High-Value AI Platform

This engagement is different in kind from everything else in this report. Not a CI/CD credential harvest - a sustained, multi-stage compromise that ran for weeks and produced more than 6TB of exfiltrated data still transferring when the investigation found it.

Two separate directories on the storage server resolved to the same organisation. Combined footprint: more than 6TB.

Initial access. Entry was through an AI medical imaging API that fetches user-supplied URLs server-side without validation of an unauthenticated proxy into the internal network. From there, Azazel reached internal service discovery, object storage, caching infrastructure, and monitoring systems without further authentication.

Credential decryption. The platform encrypted credentials in cluster configuration files using Jasypt. Azazel recovered the master key and bulk-decrypted every protected value across the entire configuration set - every database password, API key, and service token in one pass.

JWT backdoor from git history. A hardcoded authentication bypass token existed in the platform's production codebase, had been removed in a later commit, but remained in git history. Azazel mined the log, recovered the token, and had permanent authenticated access to the platform without valid credentials.

Grafana offline cracking. The monitoring stack's database files were inside the exfiltrated object storage. Azazel extracted admin hashes and ran offline cracking against them. The candidate list recovered from earlier in the engagement included HPC cluster credentials and what appears to be a live AWS secret key.

Live object storage exfil. An incremental sync tool mirrored the victim's object storage bucket to forgitlab continuously, with retry logic to survive connection drops. The directory grew by hundreds of gigabytes between two observations taken hours apart during the investigation.

Kubernetes and infrastructure sweep. A dedicated script swept all 6.1TB of exfiltrated data for kubeconfig files, SSH private keys, and credential-bearing container configs - producing a complete exploitation blueprint of the victim's cluster. Application logs from the monitoring stack were decoded and analysed. The full scope of what Azazel extracted from this single target extended across the platform source code, object storage, monitoring data, HPC cluster credentials, and Kubernetes infrastructure.

Command and Control - MCP Abuse

The security research community has documented MCP attack risks since 2025 tool poisoning, prompt injection, supply chain abuse, and the theoretical risk of locally-bound MCP ports being leveraged for lateral movement. CloudSEK has not identified prior public reporting of a threat actor operationally using MCP exec_in_session as a C2 channel in a live criminal campaign. This investigation documents one confirmed instance.

The operational use is in va.py the ransom note verification script. The script calls 127.0.0.1:35367 with a fixed bearer token to loop SSH verification checks across six internal hosts as part of the multi-surface defacement chain. exec_in_session against a locally-bound MCP server port, driving real attack execution inside a confirmed victim environment.

‍

mcp_test.py and recon_mcp.py alongside va.py confirm this is developed, iterated tooling across multiple scripts - not a single discovery repurposed once.

The beacon log shows internet-wide scanning under the fingerprint "internet-census-mcp-scanner" - dedicated infrastructure hunting exposed MCP server ports at global scale, treating them as a general-purpose initial access vector independent of the CI/CD secrets chain.

‍

The storage server configuration output shows responses consistent with an agentic AI assistant answering infrastructure planning questions, backup capacity, disk throughput, scan performance against large datasets. The operator used AI tooling for sysadmin planning of his own infrastructure alongside using it as an attack execution channel against victims.

Exfiltration

Azazel staged data through three hops. Victims were hit with aws s3 sync for cloud-native targets, scp and pg_dump for database and host-level exfil, and HTTP POST to port 9999 on the C2 box. From there, scp moved staged data to forgitlab's /data directory. mega-cmd-server transferred the final consolidated set to MEGA cloud at 66.203.124.135:443.

The use of mc (MinIO Client) for object storage exfiltration, combined with MEGA for data transfer/storage, is consistent with the documented evolution of Gentlemen affiliate TTPs. Affiliates have adapted their tooling based on data volume and transfer performance requirements, with mc representing a more efficient option for large-scale object storage transfers. The use of MEGA as the final destination is also consistent with previously observed Gentlemen affiliate activity.

What distinguishes Azazel's setup from the wider Gentlemen affiliate pool is the dedicated physical infrastructure behind it. Most affiliates exfiltrate to temporary cloud storage or rented VPS nodes. Azazel maintained a 29TB dedicated staging server connected to a separate 22TB long term vault built for retention across multiple engagements, not a single operation.

‍Assessment

Azazel used Gentlemen's infrastructure, tooling, and negotiation channels while simultaneously building his own leak site and keeping the proceeds. Victims had no visibility into LEAKNED. The Gentlemen operator had no control over a parallel revenue stream running off the same access. This is a structural problem in the RaaS affiliate model, not an edge case.

The Chain B engagement SSRF through an AI inference endpoint, Jasypt decryption, JWT recovery from git history, Grafana cracking, MinIO incremental sync, Kubernetes kubeconfig harvesting - reflects a skill level well above standard affiliate tradecraft. The MCP tooling adds a further dimension: operational use against one victim cluster, global scanning infrastructure for exposed AI assistant ports, and confirmed use of AI tooling for the operator's own infrastructure management. The security community has documented MCP attack risks theoretically since 2025. This investigation documents a confirmed operational instance.

Sigma Rules 

title: MinIO Client Bulk Mirror to External Destination
id: a3e9f852-bcde-4f02-cd34-6543210987fa
status: experimental
description: >
  Detects mc mirror commands exfiltrating object storage bucket contents
  to an external destination with retry logic. Confirmed TTP in Azazel's
  Gentlemen affiliate operation - used to continuously mirror a victim's
  MinIO bucket producing hundreds of gigabytes of ongoing transfer.
  Also documented across broader Gentlemen affiliate incidents as part
  of a confirmed progression from Rclone to Restic to mc.
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    Image|endswith: '/mc'
    CommandLine|contains: 'mirror'
  filter_legitimate:
    CommandLine|contains: 'localhost'
  condition: selection and not filter_legitimate
falsepositives:
  - Legitimate MinIO backup jobs to authorised remote destinations
level: high
tags:
  - attack.exfiltration
  - attack.t1530

Mitigations:

1. Store CI/CD credentials in a dedicated secrets manager, not raw pipeline variables. Mask and protect every variable, rotate tokens on a fixed cadence, and audit git history for committed secrets - Azazel recovered credentials from commits that appeared removed from the current branch.
2. Never bind an MCP server beyond strict loopback. Treat exec_in_session as a privileged operation requiring an audit trail. Monitor for MCP initialize RPCs from client identities outside an approved allowlist. The identity "hermes" and scanner fingerprint "internet-census-mcp-scanner" are confirmed malicious indicators for this operator.
3. Do not treat Jasypt ENC() values or embedded secrets in values.yaml and docker-compose files as a security boundary. Store encryption keys and kubeconfig files in a dedicated secrets manager, separate from the configs they protect. Rotate cluster credentials on any suspected exfil of the repository containing them.
4. Restrict MinIO bucket access to specific service accounts with least privilege. Monitor for mc mirror or bulk sync operations from unexpected source IPs. Apply the same access controls to Grafana SQLite databases, Prometheus TSDB, and Loki chunks all contain credential material.
5. Store backup credentials on separate infrastructure from production and test restoration procedures before an incident forces it. Restrict COPY TO PROGRAM on PostgreSQL and audit C extension load permissions. An operator who destroys production data after exfiltration turns a credential rotation exercise into a full recovery operation.
6. Alert on CI/CD variable reads from unexpected IPs, service account token use outside normal runner infrastructure, and README or Issue modifications via pipeline token from an unusual source. Enforce content-based file upload validation suffix-only checks are trivially bypassed.

References

• *Intelligence source and information reliability - Wikipedia
• ^#Traffic Light Protocol - Wikipedia