0APT Hacked - And Then Got Hacked Back

Published: 14th April 2026 · Updated: 16th April 2026

On 13th April 2026, the threat actor known as 0APT breached the administrative panel of Krybit, a ransomware group first discovered on 3rd April 2026, publishing details of the intrusion on their leak site the following day.

0APT's post listed Krybit as their first named target — ID: 0APT-1001 — threatening to expose operator identities, photos, and locations unless payment was made. The status on the post read simply: "WAITING VICTIM."

Their warning stated:

"If the group does not make the payment or contact us, we will reveal their identity photos, names, location and other. And if you are one of their victims, contact us to get your data unlocked."

0APT's Operations Center listing Krybit Ransomware Group (ID: 0APT-1001) with status "WAITING VICTIM".

Detail view of 0APT's post targeting krybit Ransomware Group, with deadline and "VISUAL EVIDENCE DUMP" section.

0APT's leak site (defanged): hxxp://oaptxiyisljt2kv3we2we34kuudmqda7f2geffoylzpeo7ourhtz4dad[.]onion/

What happened next was not what 0APT expected.

Krybit Hits Back

In apparent retaliation, Krybit compromised 0APT's own infrastructure — defacing their site with the message:

"HACKED BY KRYBIT. Next time, don't play with the big boys."

Krybit's defacement of 0APT's leak site: "Next time, don't play with the big boys. The response will be fast."

Krybit's LEAKS page showing the "Hacked 0APT" entry marked PUBLISHED.

The counter-hack was not superficial. Krybit retrieved a significant haul of 0APT's configuration files, including:

• shadow and passwd — system credential files
• bash_history — a full record of commands run on the server
• hs_ed25519_secret_key — the private key for 0APT's Tor hidden service, which could allow impersonation or takeover of their onion address
• Server access logs and core application files

Inside the Krybit Panel

The breached Krybit admin panel revealed the full structure of the operation — operators, affiliates, victim records, and payment wallets.

Krybit admin panel — User Statistics view showing affiliates, admins, victims, and last activity timestamps.

Krybit admin panel — User Management view with affiliate accounts and Tox ID creation controls.

Krybit's leak blog (defanged): hxxp://krybitxdpxohsmjooeb3gbgpmdddreh6mnflzac6bnezz74b7yje67yd[.]onion/blog/65dc321e50f74c6fd042423cf707e16ef0ff3b265b0049db4d6c17249dbfb76a/

The Chat Transcript

Perhaps most revealing was a chat transcript recovered from the breach — a direct conversation between 0APT operator "alex" and Krybit support, timestamped 14th April 2026.

Recovered chat transcript between 0APT operator "alex" and Krybit support, 14th April 2026.

The exchange paints a picture that reframes the original attack entirely. Alex claimed he had attempted to contact Krybit beforehand but received no response — and that going public with the data was a last resort, not the original plan. He stated that he still held the decryption keys and had not made them public.

What followed was part negotiation, part threat exchange. Alex appeared to be seeking compensation or a working relationship with Krybit. Krybit's response was unambiguous:

"An enemy can never be a friend, no matter what."

"Wherever you are, I will find you."

The conversation ended without resolution.

What This Tells Us

Criminal-on-criminal attacks are not new — DragonForce made headlines in 2025 for targeting rival groups BlackLock and RansomHub. But this incident is notable for a few reasons:

• 0APT's motive appears to have been leverage, not disruption — more extortion attempt than ideological takedown
• Krybit's counter-hack was fast and technically capable — retrieving system-level files and the Tor private key within hours
• Both groups have now exposed each other — Krybit's full admin panel, affiliate credentials, victim list, and Bitcoin wallets are public; 0APT's server config and operator identity ("alex") are now known

For defenders, the Krybit panel data contains actionable intelligence: Bitcoin wallet addresses, Tox IDs for all operators and affiliates, and a 56MB file inventory from victim exfiltration servers.

At the time of writing, a countdown timer is active on Krybit's site. Further details are expected to follow — including what may be the secrets behind 0APT's true identity. We will update as the situation develops.

Update - 16th April 2026:

On 16th April 2026, Krybit published the contents of the 0APT breach on their own DLS. The 17 files, (can be found on our GitHub archived as 0APT.7Z) totalling 164MB uncompressed showed a detailed snapshot of 0APT's infrastructure at an early stage of operation.

Krybit's published 0APT file listing, including bash_history, passwd, shadow, Nginx logs, and PHP source files.

Machine Infrastructure

The most immediately striking finding is where the site was running. The hostname-linux file identifies the machine as AnLinux-Parrot — Parrot OS running on Android via the AnLinux app. The bash history confirms it: site files were staged from /sdcard/ and deployed to /var/www/html/. The full stack — Nginx, PHP 8.2-FPM, and Tor — was running on a mobile phone. That this infrastructure served 652,813 requests over the observed window is operationally significant, not merely a quirk. It represents a deliberate OPSEC decision to avoid conventional hosting while accepting meaningful performance constraints.

Those constraints showed. PHP-FPM was crashing under load regularly enough that the operator implemented a manual restart loop rather than addressing the root cause:

while true; do pkill php-fpm; service php8.2-fpm start; sleep 600; done

Notably, the operator also attempted to install xfce4 and TigerVNC — a full GUI desktop environment on the Android Linux instance. Whether this was for personal comfort working in a graphical environment or to provide remote desktop access to a second party is unknown.

Tor Configuration

Rather than generating a fresh onion address during setup, the operator copied pre-existing Tor hidden service keys from /sdcard/new/aa/ — including the hs_ed25519_secret_key, hs_ed25519_public_key, and hostname file. The address was planned and generated separately before infrastructure setup began, indicating a degree of prior organisation. These same keys were among the files retrieved by Krybit during the counter-hack, meaning the onion address is now fully compromised.

Key Files

The archive contained:

• bash_history — full root command history;
• access.MGnLeHGS.log.part — 652,813 lines of Nginx logs covering January to February 2026;
• passwd, shadow, gshadow — system credential files;
• krybitkey.php — a file browser and downloader;
• cochat.php, cosend.php, contact.php — the victim chat system;
• index.php — the main leak listing page;
• default — the Nginx site configuration;
• hostname-linux — identifying the host as AnLinux-Parrot;
• hosts — minimal, localhost only.

Bash History

The command history documents the entire build process from first boot, including repeated typos, misconfigured service names, and multiple failed attempts to set Tor permissions correctly. The operator was learning as they went — nginc instead of nginx, service php start before discovering the correct service name, cs usr instead of cd usr. They relied on a single startup one-liner throughout:

service php8.2-fpm start && service nginx start && service tor start

And obsessively monitored traffic in real time, repeatedly running:

tail -n 10 /var/log/nginx/access.log
ps -ylC php-fpm8.2 --sort:rss

Beyond the setup errors, several entries stand out.

The operator spent time analysing IshIpcm.sys, an Intel Integrated Sensor Hub driver, running strings and checking for process termination primitives, kernel write functions, and IOCTL handlers:

strings IshIpcm.sys | grep -Ei "ZwTerminate|NtTerminate|PsTerminate|ZwOpenProcess"
strings IshIpcm.sys | grep -Ei "RtlCopy|MmMapIo|ZwWrite|MSR"

This is consistent with BYOVD (Bring Your Own Vulnerable Driver) research — a technique used by ransomware operators to terminate EDR processes via a signed but exploitable kernel driver before deploying an encryptor. It suggests capability, or at least ambition, extending well beyond running a leak site.

The history also references a RaaS backend that never appeared in the public-facing site: raasdash.php, raas_data.txt, a payloads/ directory, a users/ directory, and an admin login page (0aptraaslogin.php, later obscured by renaming to 0aptraaslogin9999.php). 0APT was not simply an extortion blog — it was either already operating as a ransomware-as-a-service platform or actively building toward one.

An unidentified pre-compiled x86_64 ELF binary named server also appears in the history. The operator made repeated attempts to execute it on their ARM64 device using QEMU, ultimately without success due to the architecture mismatch. Its origin is unknown — a C2 component, affiliate panel binary, or something provided by a third party are all plausible. The fact it was never successfully run leaves a meaningful gap in understanding the full intended architecture of the operation.

Similarly, the Node.js monitoring tool cloned from github.com/koala73/worldmonitor was never successfully deployed. Between the failed server binary and the failed monitoring setup, the operator's intended infrastructure appears to have been meaningfully more sophisticated than what was actually running at the time of the breach.

The history also records a search for the string mahesh across the entire web directory, followed by a deeper strings sweep of all files, and then the creation of a file named Mahesh97m.txt. The searches preceded the file creation — suggesting the operator was locating where a known name had surfaced before documenting it. The file was not included in the archive and its contents remain unknown. No other reference to the name appears anywhere else in the recovered data.

Finally, at least ten victim negotiation chat sessions were deleted mid-operation, their hex-named log files wiped individually. The operator also manually cleared the live Nginx access log during the operation period:

echo "" > /var/log/nginx/access.log

The surviving log file is a logrotate remnant that escaped the wipe — meaning the full picture of site traffic is incomplete.

Shadow File Timeline

The /etc/shadow password change timestamps provide a cleaner operational timeline than the logs alone. System accounts were last changed on day 20116 of the Unix epoch — 28th January 2026, the initial setup date. The debian-tor account was modified around day 20480, corresponding to approximately 14th February, indicating Tor was reconfigured roughly two and a half weeks into operation. Remaining service accounts were updated around day 20493 — approximately 27th February. The operation was actively developed for at least a month beyond the log window.

Log Analysis

The surviving log covers 28th January to 5th February 2026 — eight days in which the site received 652,813 requests, a significant volume for a Tor hidden service. All source IPs appear as 127.0.0.1, expected for traffic routed through localhost via Tor.

Of those requests, 45,096 came from Axel/2.17.13, a CLI bulk download accelerator — consistent with affiliates or buyers systematically pulling victim data packages. The site was also actively probed during the same period: 89 SQL injection attempts, path traversal probes, and null byte injection attempts against the download endpoint. The site was attracting unwanted attention from external parties even at this early stage of operation.

The ao.txt flat file — which controlled whether the operator appeared online to victims in the chat interface — was created and deleted repeatedly throughout the operation, providing a rough indicator of when the operator was actively managing negotiations.

Site Architecture

The PHP source files reveal a more developed platform than the public interface suggested. index.php loaded victim listings dynamically from data.json. download.php served files with only a ltrim-based path check — weak enough to probe. krybitkey.php provided a secondary file browser for a specific directory. The chat system implemented Proof-of-Work bot protection on entry — though notably this check had been commented out on index.php, likely during testing and never re-enabled. Rate limiting of six messages per seven seconds triggered a ten-minute block, suggesting the operator anticipated meaningful interaction volume from victims or buyers.

Chat messages were stored as plaintext in session files under /var/www/html/cochats/. At least ten of these were selectively deleted mid-operation.

Alleged Victims

Download filenames in the log name over 150 organisations across healthcare, industrial, government, and logistics sectors globally. Healthcare accounted for roughly 40% of listed files. Industrial and engineering targets spanned nuclear, avionics, robotics, mining, and chemical sectors. Government targets included agencies from West Africa and the Middle East. One institution appeared most frequently in download requests, suggesting it was the highest-profile or most commercially valuable listing on the site. Whether the underlying data represents genuine exfiltration or was fabricated for leverage has not been independently verified.

Key IOCs

• Onion: oaptxiyisljt2kv3we2we34kuudmqda7f2geffoylzpeo7ourhtz4dad.onion
• Platform: Android (AnLinux) / Parrot OS
• Hostname: AnLinux-Parrot
• Services: nginx, php8.2-fpm, tor
• GitHub: github.com/koala73/worldmonitor
• Driver analysed: IshIpcm.sys (Intel ISH — potential BYOVD research)
• Possible handle: Mahesh97m
• Unidentified binary: server (x86_64 ELF, origin unknown)

Ransom-ISAC continues to monitor both groups. If your organisation appears in the Krybit victim dataset, please reach out.