u/3eandrews3

A researcher going by ‘bikini’ has published a personal archive called Exploitarium - 15 vulnerability targets across 109 tracked files, dropped with no coordinated disclosure and no vendor notification.

This isn’t a polished toolkit. It reads like a personal research dump. Some of it is noise that the community has already dismissed. But not all of it.

Two findings stand out and have been independently verified:

libssh2 pre-auth heap write - CVSS 9.2. Pre-authentication. Actively exploited.

Gitea default Docker auth bypass - Also independently confirmed, also being exploited in the wild.

If you’re running either of these in your environment, treat this as live.

What I built in response:
44 KQL detection rules covering the full Exploitarium scope: 18 product folders, 6 CVEs, cross-platform (Windows, Linux, macOS, Container, Network, SaaS).
Rules for:
libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares and more.

All rules are live on detections.ai with language translation available for non-KQL stacks. The full repo is structured by product on GitHub.
Full intel report + IOCs in the links below.

GitHub repo: https://github.com/Ethan-Andrews/Exploitarium-Detections

Exploitarium breakdown: Threat Intel

Drop questions below, happy to walk through anything.

Kaspersky published a writeup on a previously undocumented cluster called StrikeShark using a custom loader (SharkLoader) to drop Cobalt Strike Beacons against diplomatic and government targets across Southeast Asia, the Middle East, and Eastern Europe. Attribution unconfirmed, tooling artifacts suggest Chinese-speaking developer.

Initial Access

Mass exploitation of internet-facing apps such as Exchange, SharePoint, Openfire, GeoServer, F5 BIG-IP, FortiOS, Cisco IOS XE, Apache Shiro. CVE spread goes back to 2016, suggesting opportunistic scanning rather than targeted pre-selection.

The Loader

SharkLoader sideloads via SystemSettings.exe, staging DLL components in APPDATA\xwreg or APPDATA\xgdf. The “Perfect DLL Hijacking” technique manipulates LdrpLoaderLock to spawn the malicious thread outside normal load order. MinHook and Microsoft Detours hook ETW at the API level before the Beacon loads…by the time the payload executes, the memory scanning surface is already suppressed. You’re not catching this on Beacon behavior. You need to catch it on loader behavior.

Post-Exploitation

FScan, Searchall (domain enum), Pillager + comsvcs MiniDump (LSASS), SharpGPOAbuse, ntdsutil/vssadmin (NTDS.dit), scheduled task persistence masquerading as OneDrive tasks, Registry Run Key via SystemSettings.exe.

Detection Coverage

Built a full kill chain coverage set on detections.ai (KQL / Sentinel / Defender XDR):

- SystemSettings.exe sideloading from non-standard path

- DLL components written to APPDATA\xwreg or xgdf

- OneDrive-masquerading scheduled task persistence

- Registry Run Key persistence via SystemSettings.exe

- PPID spoofing under spoofed parent processes

- LSASS dumping via Pillager, procdump, comsvcs

- NTDS.dit extraction via ntdsutil or vssadmin

- Searchall domain group enumeration

Language translation available on the platform for non-KQL stacks.

Intel report + IOCs: https://detections.ai/intel-exchange/019efad5-160b-7416-8c5c-aa6a059c8574

Happy to dig into the ETW hook mechanic or specific detection logic in comments.