# ByteToBreach → Magyar Államkincstár — Intrusion Timeline > A chronological reconstruction of the intrusion into the Hungarian State Treasury via the mvh inter-forest trust, built from 24 operator screenshots and their embedded timestamps — and why 229.1 TB was never going out the door. - Canonical URL: https://yellowcube.eu/reports/bytetobreach-allamkincstar/ - Publisher: Yellow Cube - Language: en Threat actor: ByteToBreach · Target: Magyar Államkincstár ## Anatomy of the Treasury breach — and why 229.1 TB was never going out the door A chronological reconstruction of the intrusion into the Hungarian State Treasury via the mvh inter-forest trust, built from the 24 operator screenshots he published and their embedded timestamps, then tested against the physics of moving 229 terabytes. **Window:** 25 – 31 Jul 2026 **Entry:** esb.mvh.allamkincstar.gov.hu **Timezone:** normalised to CEST (UTC+2) **Prepared:** 2026-08-06 Intrusion span 5.5 days foothold → public leak Exfil window after 229 TB found ~68 hours (28 Jul → 31 Jul) Datastore capacity seen in ESXi 229.1 TB 116 VMs, du -sh /vmfs Bulk exfil verdict Infeasible & not the plan public leak ≈ 70 MB proof pack #### Executive summary Between 25 and 31 July 2026 a single operator breached the Magyar Államkincstár through a bidirectional inter-forest trust with the Rural Development Agency (MVH), reaching domain-admin across four Active Directory forests and full control of the virtualisation estate — 116 VMs and 229.1 TB of datastores. **The defences were largely present and largely working.** DMZ egress filtering stranded the operator’s reverse shells, and Symantec blocked his beacons and his access to credentials — right up to the moment he switched Symantec off by hand. What failed was not the controls but the response: their alerts reported into a room with nobody in it for five and a half days. **No bulk data left the network.** Moving 229.1 TB inside the intrusion window was physically infeasible — it would have demanded a sustained ~7.5 Gbps — and it was never the plan. The public leak was a ~70 MB proof pack, published with an explicit note that no ransom was being asked. The lasting damage is credential, not volumetric: 9,047 passwords are already in cleartext, and thousands more fall within a week of GPU cracking. **The first move is a capability, not a product:** a 24×7 detection-and-response function behind the controls that already exist, then closing the credential and identity-architecture gaps behind it. The step-by-step remediation is in [Breaking the chain](). #### Contents 1. [Attack chain]() — the 12-step timeline 2. [Could 229.1 TB have left the network?]() 3. [Operator attribution & tradecraft]() 4. [Password hygiene & the credential dump]() 5. [The habits behind the numbers]() 6. [What a single operator with a GPU rig gets]() 7. [The krbtgt key & the Golden Ticket]() 8. [Breaking the chain & where to start]() ## Attack chain Access Discovery Collection Impact / disclosure Every step carries a **yellow Yellow Cube strip** with the short answer to “what stops this?”. The full breakdown — prevent, detect, stop and harden — is in [Breaking the chain]() at the end of this report. Step numbers follow the attack chain; where several actions fall inside the same few hours of 26 July, the order reflects the operator’s own workflow across parallel sessions rather than strict clock order. Each card is tagged with its primary MITRE ATT&CK technique. 1. Jul 2522:14–22:22 CEST 01Initial access[T1190]() ### WebLogic RCE foothold CVE-2017-10271 deserialization against the ESB vhost drops a Python reverse shell. Not a prod host — but a doorway into the Rural Development Agency (MVH) network. `CVE-2017-10271``rev shell → 91.229.23.96``1_FOOTHOLD.png` Yellow Cube Deny-by-default DMZ egress (**Stormshield**) strands the reverse shell; **WithSecure** vulnerability management and **Group-IB ASM** external attack-surface discovery surface a nine-year-old, internet-facing WebLogic CVE before someone else finds it. [How ↓]() 2. Jul 25→26overnight 02Persistence & lateral[T1210]() ### MS17-010 on the entry subnet EternalBlue against a legacy Win2003 box on 10.254.5.x, Sliver C2 with a SOCKS5 pivot. "Useless host, but adds persistence" — the protected networks are on other segments. `MS17-010``Sliver C2``2_PERSISTENCE.png` Yellow Cube **Cynet** is one of the few modern EDR platforms that still covers Windows Server 2003 — SOC-backed detection on the host other vendors abandoned; **Stormshield** segments it, **Stellar Cyber** sees the beacon. [How ↓]() 3. Jul 2614:28 CEST 03Second vector[T1190]() ### Forgotten JDWP debug port An exposed Java Debug Wire Protocol port on a WebLogic host yields a second, cleaner RCE as the oracle user. `JDWP RCE``session @ 2026-07-26 14:28:20 +0200``3_FORGOTTEN_JDWP.png` Yellow Cube Port allowlisting (**Stormshield**) plus external attack-surface discovery (**Group-IB ASM**) close a debug port that authenticates nobody. [How ↓]() 4. Jul 26midday 04Recon / segmentation[T1046]() ### Hitting the segmentation wall Outbound is throttled to pings and basic commands (likely SELinux + egress filtering); WebLogic vulns present but limited. Neighboring subnets already feel walled off. `no outbound except ICMP``4_POKING_WEBLOGIC.png` Yellow Cube The blocks were already firing — nobody read them. **Stellar Cyber** centralises the deny events and the **Yellow Cube 24×7 SOC** puts a human behind them. [How ↓]() 5. Jul 2611:46 CEST 05Identity system[T1552]() ### Oracle Identity Self-Service Access to the Magyar Államkincstár identity portal — thousands of government accounts, modifiable, with reversible passwords. Scope of inter-domain connectivity starts to reveal itself. `OIM 10.254.21.121:14000``5_BIG_IDENTITY_MESS.png` Yellow Cube Segment the portal (**Stormshield**), vault its admin identities (**Imprivata**), plant decoys (**Cynet**) — and a **strategic-planning audit** turns the reversible-password finding into a fix. [How ↓]() 6. Jul 2619:55 CEST 06Credential & trust discovery[T1552.003]() · [T1482]() ### The exchmentes admin & the forest trust Shell history exposes a full-AD service account (exchmentes / Papi\*\*\*\*\*\*\_44\_) and a **bidirectional inter-forest trust**: MVH ↔ allamkincstar.gov.hu. Full admin — but only if the firewalled 10.10.x segment can be reached. `login from 185.195.232.103``trust: FOREST_TRANSITIVE``7_HISTORY_TREASURES.png` Yellow Cube A vaulted, rotating service credential (**Imprivata**) never reaches shell history; **Varonis** flags it the moment it authenticates across the forest boundary. [How ↓]() 7. Jul 2700:28–02:21 CEST 07Forest mapping[T1003.006]() · [T1482]() ### BloodHound & DCSync across forests NTDS secrets dumped, domain trusts graphed: MVH.LOCAL ↔ ALLAMKINCSTAR.GOV.HU ↔ child forest MAK, plus the NYUFIG / ONYF pension forests. The reachable path to Tier-0 is mapped. `BloodHound collected 2026-07-27T00:28Z``login 185.195.232.163``9_CROSSING_FRONTIERS.png · 10_FSP.png` Yellow Cube DCSync from a non-DC is one of the cleanest signals in Active Directory — **Varonis** or **Cynet** on every forest’s DCs, with **Cymulate** proving the alert actually fires. [How ↓]() 8. Jul 2714:33 CEST 08Data access & storage scouting[T1083]() · [T1039]() ### OIM database + mapping the storage estate Oracle Identity Manager schema browsed in DBeaver; corporate file shares enumerated (Terinfo 15.9 TB, Adat 15.9 TB, ATF 5 TB, shadowcopy). Small stores everywhere — the treasury data to be **slowly downloaded**, VMs to be encrypted. `DBeaver query 2026-07-27 14:33:15``8_ORACLE_OIM_VAULT.png · 11_SCOUTING_STORAGES.png` Yellow Cube **Varonis** is built for precisely this: least privilege across 36 TB of shares, and an alarm the moment something crawls them. [How ↓]() 9. Jul 2718:24–22:05 CEST 09Defense evasion[T1685]() · [T1003.001]() ### Confronting Symantec (SEP) SCCM secret-policy dump; Symantec blocks outbound beacons and named-pipe LSASS access. Workaround: RDP to the SEP box and stop smc.exe / SepMasterService, then dump LSASS — "lsass works :)". `loot/2026-07-27_18-24-42_policies``nmap 22:05 CEST``12_CONFRONTING_SYMANTEC.png` Yellow Cube Symantec worked until it was switched off. Tamper and heartbeat-loss alerts (**Cynet**, **WithSecure**) escalated by the **24×7 SOC** make that switch-off the loudest event of the night. [How ↓]() 10. Jul 2813:41–15:25 CEST 10Virtualization takeover[T1078]() ### vCenter & the 229.1 TB datastores vCenter credentials finally found (administrator@vsphere.local); 116 VMs, 3 hosts, Primera/IBM datastores totalling **229.1 TB** (du -sh /vmfs). The plan: encrypt VMs in place from ESXi. Slide ends "To be continued". `FreeRDP 10.17.0.200``du -sh /vmfs → 229.1T``13_VCENTER_TAKEOVER.png` Yellow Cube Isolate the management plane (**Stormshield**), vault the vSphere SSO administrator (**Imprivata**), and ship ESXi syslog somewhere someone is watching (**Stellar Cyber**). [How ↓]() 11. Jul 3019:36 CEST 11Staging & upload[T1567.002]() ### Proof pack to Google Drive 16 items uploaded to a Drive folder "MAGYAR" by account "Loic Matrier": 13 of the screenshots, CREDS.txt, RECON.txt and one video — roughly **70 MB total**. Not bulk data. `Drive activity 7:36 PM Jul 30``google-drive-uploader.png` Yellow Cube This upload ran from the operator’s own machine, not a Treasury host — so no in-network control reaches it. What answers here is **Group-IB** Digital Risk Protection, watching underworld marketplaces and flagging the moment the stolen credentials go up for sale — the 9,047 already in cleartext, and the thousands of weak hashes a small GPU rig cracks within days. [How ↓]() 12. Jul 3111:27 CEST 12Public disclosure— ### Leak post on spear\[.\]cx "The Magyar Conquest" thread goes live with the screenshot set and backup mirrors (pCloud, sync.com, MediaFire). Explicit note: **"data is not for sale… no ransom is asked."** `spear[.]cx DLS · edited +46 min``DLS.png` Yellow Cube **Group-IB** Digital Risk Protection turns discovery from weeks into hours, and takes the mirrors down. [How ↓]() ## Could 229.1 TB actually have left the network? [↑ contents]() #### To move all 229.1 TB, you'd need | Sustained rate, 24/7 | Over | | --- | --- | | ≈ 7.5 Gbps | 68 h window | | ≈ 3.9 Gbps | 5.5-day intrusion | | ≈ 707 Mbps | 30 days | #### Time to move 229.1 TB at a sustained rate | Line rate | Duration | | --- | --- | | 100 Mbps | ≈ 212 days | | 1 Gbps | ≈ 21 days | | 10 Gbps (ideal) | ≈ 2.1 days | #### And the environment made even that impossible - **Egress was filtered.** The operator's own note: "no outbound, except pings and basic commands." Symantec additionally blocked outbound beacons. - **Everything ran through Tor / Proton VPN / Mullvad.** Anonymising transports cap real throughput at tens of Mbps — not the multi-Gbps a full dump demands. - **The sinks were consumer cloud.** Google Drive, pCloud, sync.com, MediaFire. Google Drive alone caps uploads at ~750 GB/day/account → 229 TB ≈ **305 account-days**, and none of them can even store 229 TB. Verdict **229.1 TB was never an exfiltration target.** It is the size of the virtualisation estate the operator staged for **in-place encryption from ESXi** — the destructive half of a double-extortion play. The screenshots say it plainly: "VMs will be encrypted directly from ESXi… while the data from state treasury will be slowly downloaded." Exfiltration was **deliberately selective** — OIM / treasury databases, credential material, and a curated proof set — not a wholesale 229 TB copy, which the time budget and the pipe both forbid. The public leak was a **~70 MB proof pack**, explicitly "not for sale, no ransom." He didn't have time to take it all, and by his own plan he was never trying to. ## Operator attribution & tradecraft (video evidence) [↑ contents]() Beyond the 24 screenshots, the operator also left behind a screen-recording video. 125 extracted keyframes were reviewed frame-by-frame for anything that profiles the _operator_ rather than the victim — desktop environment, tool versions, own hostnames, C2 infrastructure, and clock artifacts. #### Confirmed on the operator's own desktop - **Own hostname leaked:** multiple terminal prompts read kali@stephlabs (zsh, recurring "corrupt history file /home/kali/.zsh\_history"). The attack VM is titled second\_kali, run in Oracle VM VirtualBox on a Linux Mint/Cinnamon desktop (Terminator, VS Code, Firefox pinned; a genmon tray widget). - **C2 framework:** a live sliver > console lists mTLS implants beaconing to attacker-controlled infrastructure, running as root/oracle on Linux/amd64 hosts inside the victim's Hyper-V/vSphere estate. - **Payload naming:** the dropped implant is staged from the operator's own /root/magyar.exe — "magyar" is Hungarian for "Hungarian," a deliberate nod to the victim's nationality, not a victim-side artifact. - **Toolset on screen:** NetExec, Evil-WinRM (v3.5 → v3.9), FreeRDP/xfreerdp, Nmap 7.94SVN, TigerVNC, Burp Suite Community Edition with a dedicated "PortSwigger - Chromium" profile, vSphere Client. - **Habits:** two Terminator search bars left pre-filled with sshd and encrypted — evidence of manual log/keyword hunting through captured output. - **OPSEC:** no VPN/Tor client chrome, password manager, personal wallpaper, bookmarks bar, or non-English notes appeared anywhere across the 125 keyframes — a disciplined, tool-only desktop apart from the hostname and C2 leak. #### Indicators pulled from the video | Type | Value | | --- | --- | | Operator hostname | kali@stephlabs | | Attack VM | second\_kali (VirtualBox) | | C2 framework | Sliver (mTLS) | | C2 listener IPs | 84.206.46.11 · 84.205.244.140 · 85.209.80.29 | | Payload | /root/magyar.exe | | Reused lateral-move creds | exchmentes / Papi\*\*\*\*\*\*\_44\_ | #### Where do the Sliver beacons actually go? | Listener IP | Location | Network | | --- | --- | --- | | 84.206.46.11 | Budapest, HU | AS31581 NISZ (Hungary's national e-gov operator) — registered to MVH, the same forest whose trust into allamkincstar.gov.hu was the operator's path to Tier-0 (event 06) | | 84.205.244.140 | Athens, GR | AS35506 Information Society S.A. — Greece's SYZEFXIS public-administration network (proxy18.syzefxis-hosting.gr) | | 85.209.80.29 | Tbilisi, GE | AS209332 — Georgian High Council of Justice, Dept. of Common Courts | The other two sit in unrelated networks — no shared ASN, prefix, registrant, or upstream peer across any of the three (BGP neighbour sets checked directly, zero overlap), and no public reporting ties the three IPs together. All three resolve to foreign government / judicial / public-administration networks rather than bulletproof or attacker-owned VPS space, consistent with the beacons riding **abused third-party infrastructure** as redirectors rather than dedicated C2 boxes. The MVH coincidence is the one lead worth chasing directly — WHOIS alone can't say whether this listener sits inside the already-compromised MVH/NISZ estate or is just a coincidental neighbour in the same national allocation. Everything here identifies where the traffic surfaces, not who is behind it. Independent corroboration: a separate leak of operator screenshots from a second ByteToBreach victim (Georgia's court system, teen.court.ge / hcoj.gov.ge) shows the identical pattern in the same address space — 85.209.82.28 exploited as the initial foothold, 85.209.83.139 used purely as an SSRF pivot to reach otherwise-unreachable internal segments. Both share AS209332 and the same registrant as the Georgian listener IP above. The same leak also captions the operator's actual rented VPS — 194.102.105.193, AlexHost SRL, Moldova — an ordinary commercial host, structurally nothing like the three government-network listener IPs. This doesn't confirm 85.209.80.29 itself was compromised, but it does show this operator's demonstrated habit of routing traffic through already-breached boxes inside victim government networks rather than his own infrastructure. #### Reading the clocks correctly Terminal scrollback visible in the video shows Nmap runs stamped **2026-07-29 01:12–02:37 CEST**, run from an attacker-controlled Linux pivot (root@NLDW2-AW3) — genuine operational history, progressing forward in order. But the desktop clock in the same frames, on the outer recording host, sits steady at **17:29 → 17:38** for the whole 9-minute clip. That's not a live contradiction: it means **the video is a later walkthrough replaying old terminal scrollback**, recorded well after the operation, not a real-time capture of it. The CEST timestamps describe when the intrusion happened; 17:29–17:38 only describes when the walkthrough was filmed, on an unknown date and in an unknown timezone. This refines, rather than contradicts, the BloodHound/PDT finding below: there are at least three distinct clocks in play across the evidence — the compromised estate (CEST), the attacker's own pivot host at operation time (CEST), and the analysis/recording desktop (unknown zone) — and they should not be cross-compared as if they were one. #### Locale artifacts that belong to the victim, not the attacker Hungarian date/month/weekday formatting, Hyper-V/vSphere object names (teszt, Gép5, achiv\_gepek, virusirto1-3), and a vSphere login banner reading **"Hol a tavasz?"** ("Where is spring?") are all properties of the compromised Hungarian systems — a custom MOTD set by the treasury's own IT team, not attacker or vendor content. None of it should be read as attacker attribution. #### Third-party attribution — KELA Cyber names the operator Everything above is derived from the operator’s own leaked artifacts. It profiles a _machine_ and a _method_, not a person. The one substantiated public attempt to put a name to ByteToBreach comes from KELA Cyber’s Intelligence Center, which profiled the actor in November 2025 and updated the assessment on 17 July 2026. KELA’s assessment KELA assesses that ByteToBreach is **likely operated by Zakaria Mahdjoub, an individual based in Oran, Algeria** — an assessment it supports with technical evidence including data recovered from infostealer-infected devices, browser cookies and associated digital artifacts. The word “likely” is KELA’s own and is reproduced deliberately. This is a threat-intelligence assessment, not a legal finding: no charge, prosecution or conviction is known, and nothing in the evidence _this_ report examines independently corroborates the identification. It is included because it is the most substantiated public attribution available, and because the reasoning behind it can be evaluated on its own terms. #### How the identification was built The chain is worth reading in full, because it is a textbook case of an operator undone by his own past rather than by his current tradecraft: - **A reused Session ID bridged two personas.** ByteToBreach communicated over ProtonMail, Tuta and Gmail addresses, Telegram (@ByteToBreach, previously CvHNWwEG and inesslopez), Signal and Session. The Session ID was the pivot: KELA used it to tie the ByteToBreach persona to a _second_, earlier DarkForums account active in June 2025 — one that leaked Singaporean company databases and then went dark after another user accused it of scamming €500. - **That second username surfaced in infostealer logs from Algeria.** Searched against KELA’s data lake, it appeared on two infostealer-infected machines, **both located in Algeria**, as the login for ProtonMail, Instagram and TransferWise. One was infected with Raccoon in September 2022, the other with StealC in February 2024 — years before the ByteToBreach persona existed. - **Two concrete identifiers closed the loop.** Neither infected machine showed any hacking-forum activity, so the link does not rest on behavioural similarity. It rests on two artifacts: the former Telegram username inesslopez appears in the stolen browser data, and a phone number in that same data ties directly to the live @ByteToBreach Telegram account. - **Why the reasoning holds together.** Three independent source types converge: a cryptographic messaging identifier linking two forum identities, commodity-malware logs from consumer machines in a specific country carrying the same credentials across unrelated services, and two direct identifiers bridging those logs to the account still operating today. Each is weak alone; the combination is not. And the decisive point is chronological — the infostealer infections predate the criminal persona by up to three years. The operator was compromised as an ordinary user long before he had any reason to think about attribution, and that historical residue is what exposed him. #### What KELA’s profile confirms about this intrusion - **The stated motive matches.** KELA records ByteToBreach repeatedly claiming to have contacted victims first, insisting that “innocent people are the victims, not the governments”, and demanding that organisations take responsibility for protecting their customers. That is the same posture as this leak’s explicit note that the data is not for sale and no ransom is asked — an unusual and consistent signature across both. - **The tradecraft matches.** KELA describes known-vulnerability exploitation against corporate and cloud infrastructure, opportunistic brute-force and misconfiguration access, and reuse of harvested credentials — followed by exfiltration of employee records, databases and backups to be sold or published as proof. Steps 01 through 08 of the timeline above are that description, executed. One element of his usual repertoire is absent here: he had no need of phishing or infostealer logs for initial access, because an unpatched internet-facing host gave it to him, and the credentials he reused he found inside the estate. - **The victim profile matches.** Airlines, banks, universities, healthcare and government bodies across Ukraine, Kazakhstan, Cyprus, Poland, Chile, Uzbekistan and the United States, with several breaches subsequently acknowledged by the affected organisations. A national treasury fits the pattern exactly. - **He outsources hash cracking, at $100 per hash.** A small detail that carries real weight here: KELA records the actor soliciting paid hash-cracking services. Read that against the [password-hygiene section]() below, where 11 % of the domain fell to a home-made wordlist on a CPU in minutes. On this estate he would not have needed to pay anybody. - **The July 2026 Romanian claim rhymes with this one.** Two weeks before the Treasury leak, the same actor claimed a breach of Romania’s cadastre agency (ANCPI) and published Active Directory data showing Windows XP, Windows 7 and Windows Server 2003 in production, 69 Group Policy Objects — including ones named “DISABLE WINDOWS FIREWALL” and “MIGRARE - ADD ADMINS” — and dangerous AD permission relationships. Legacy Windows and a permissive directory are not this operator’s coincidence; they are his target-selection criteria. **Source:** KELA Cyber Intelligence Center, _“ByteToBreach: A Deep Dive into a Persistent Data Leak Operator”_, KELA Cyber — Threat Actor Spotlight. Published November 2025, updated 17 July 2026. [www.kelacyber.com/blog/bytetobreach-a-deep-dive-into-a-persistent-data-leak-operator/]() — retrieved 3 August 2026. KELA notes that the full actor profile holds further detail available only to its customers; everything quoted here is from the public post. ## Password hygiene — what the credential dump actually exposes [↑ contents]() The leaked CREDS.txt (4.6 MB, 65,885 lines) is not one list but three: a hand-picked block of infrastructure credentials, a **plaintext** Oracle Identity Manager vault export covering 9,032 accounts, and a complete NTDS.DIT dump of 16,200 principals with 40,467 Kerberos keys. Because 9,047 of those passwords are in the clear, the estate's real password hygiene can be measured directly rather than guessed at — and from that measurement we can put a number on how much of the hash-only remainder a single operator with a small GPU rig would recover. #### 1 · How much is already known, and how much falls next The 10,073 domain user & service accounts in the NTDS dump **1,104** already recovered 11.0 % — measured, CPU only **≈7,960** fall within a week 79.0 % — projected, 1 TH/s rig **≈1,010** likely to resist 10.0 % — projected What the 1,104 already-recovered accounts break down into **503** plaintext-confirmed NT hash matches a vault password **13** blank password NT hash 31d6cfe0… **588** cracked in this analysis CPU only, home-made 1.3 M list **1,104 of 10,073 accounts (11.0 %) fell in minutes of CPU time**, from just 197 distinct passwords — no GPU, no public wordlist. That is the floor, not the ceiling; section 4 establishes the ceiling. Raw credential inventory
Plaintext passwords in the dump9,0479,032 vault + 15 infrastructure
NTLM hash rows (NTDS.DIT)16,20216,200 unique principals
— user & service accounts10,073only 8,777 distinct hashes
— computer accounts6,129machine-generated, not at risk
Kerberos key rows40,467aes256 / aes128 / des-cbc-md5
Accounts with a blank password13NT hash 31d6cfe0…
Accounts still storing an LM hash45sub-second recovery
One nuance worth recording: 4,664 vault usernames also appear in the NTDS dump, yet only 503 of those hashes still match the vault password. Rotation _is_ happening — roughly 89 % of the overlapping accounts had changed password between the vault snapshot and the NTDS dump. It bought nothing, because the _generator template_ never changed (see section 4): a fresh vault export re-compromises the same population on day one. ## The habits behind the numbers [↑ contents]() #### 2 · How the 9,032 vault passwords break down | Category | Count | Share | | --- | --- | --- | | Machine-generated, 8-char Xx#xxxxx | 5,076 | 56.2 % | | Machine-generated, 10-char Xx#xxxxxxx | 2,641 | 29.2 % | | One shared service password MvhX\*\*\*\*\*\*\*m123 | 819 | 9.1 % | | User-chosen, human-readable | 468 | 5.2 % | | User-chosen, ad-hoc random-ish | 26 | 0.3 % | | Blank field | 2 | — | Only **5.5 %** of the vault was actually chosen by a human. Those 494 passwords are where every bad habit lives — and they are the tail that cracks first. #### 3 · Profile of the 468 human-chosen passwords | Property | Count | | --- | --- | | Shape Word + digits (+ symbol) | 205 | | End in digits | 326 | | Contain a 4-digit year | 157 | | Contain no special character at all | 193 | | Exactly 8 characters (policy minimum) | 47 | | Satisfy all four character classes | 298 | | Contain Hungarian diacritics | 33 | Median length 11, mean 11.9, shortest 8, longest 22. The complexity policy is being _satisfied_ while contributing almost no entropy: 44 % of these collapse into one predictable template. #### The bad habits, ranked by how much damage they do - **Helpdesk reset templates that are never rotated.** The single most common password in the Hungarian State Treasury domain is A1B2c3d4, on **389 accounts**. Behind it: ABcd1234\_ (107), A1B2c3d4\_ (79), 111111 (61), abcd1234 (59), Start12345678 (32), ABcd\_1234 (32), 123456 (20). Roughly 1,300 accounts share a password with at least one other account. - **One password on 819 vault rows.** MvhX\*\*\*\*\*\*\*m123 is the Oracle OIM system-administrator password — the account’s own name with a short numeric suffix, partially masked here. It appears 819 times in the vault, again in the hand-collected block, and again inside the {AES} WebLogic blobs. Any one of those three recoveries yields OIM administrative control — and OIM admin yields all 9,032 vault passwords in plaintext. - **Privileged accounts sitting on reset defaults.** Of 77 \_ADMIN / \_SMADMIN accounts, nine are weak: three separate SMADMINs share ABcd\_1234; KUL39104\_ADMIN reuses its own user password _verbatim_; KUL40582\_ADMIN is K@l…@i2 where the paired user account is K@l…@i1. Tier separation exists as an identity, not as a secret. - **Password equals username.** XELOPERATOR:xeloperator and weblogic:weblogic. - **Infrastructure secrets derived from the organisation's own name.** Mvh\*\*\*\*n@ (vCenter SSO administrator), Mvh\*\*\*\*0gic, Mvh1\*\*, MvhX\*\*\*\*\*\*\*m123. All 22 {AES} WebLogic blobs decrypt to just **three** distinct values, so one stolen SerializedSystemIni.dat unlocked the entire middleware estate. - **Name plus date of birth as a personal standard.** 225 of the 468 human passwords are a name or nickname followed by a birth date or year — Dani1993…, Vargak-1981…, B…Dita1966…. Public-record data appended to public-record data. - **Themed dictionaries a wordlist already contains.** 77 pets, animals and characters (Nyuszi1?, Micimacko&06, Pumukli.30), 27 Hungarian place names (Tatabánya2800!, Kaposvar1983\*/), 21 month or season names (Szeptember2021, November01), 16 containing the employer's own name, and 7 containing the word "password" itself (Jelszó123, Jelszo002002, Titok2017.). - **Legacy weaknesses still stored.** **45 accounts** still hold an **LM hash** — sub-second recovery regardless of what the password is. **13 accounts** have a genuinely **blank password**. And des-cbc-md5 Kerberos keys sit alongside AES, so DES etypes remain enabled on those principals. #### Representative samples from the 468 human-readable passwords Usernames deliberately omitted. These are the recurring shapes, not outliers — each group below is a template a wordlist plus a rule set reproduces mechanically. Counts (_×n_) are the number of domain accounts sharing that exact password. Personal data minimised for publication: surnames reduced to an initial and birth dates truncated to the year (shown as …). Usernames are omitted throughout. The unredacted set stays in the evidence file and is not published. Reset / default templates — the most reused passwords in the domain `A1B2c3d4_×389_``ABcd1234__×107_``A1B2c3d4__×79_``111111_×61_``abcd1234_×59_``Start12345678_×32_``ABcd_1234_×32_``ABcd1234_×23_``Start12345678._×21_``123456_×20_``ABcd1234?_×14_``Abcd1234_×9_``abcd12345_×7_``Mvh12345_×7_``Alma01_×6_``A1B2c3d4?_×6_``QWer_1234_×5_``Abcd-123_×5_``asdfgh_×5_``Jelszo.01_×4_``qwertz_×3_``Alma,123_×3_` The word "password" or "secret" itself `Jelszó123_password123_``Jelszo002002``IdmJelszo11.``HMVHjelszo2``Danijelszo11@``Titok2017._secret2017_``Password-1``Ezazenjelszavam_013_"this is my password"_` Pets, animals, cartoon characters — 77 of 468 `Nyuszi1?_bunny_``Macsek66!_kitty_``Malacka98*_Piglet_``Micimacko&06_Winnie-the-Pooh_``Mikkamakka06``Pumukli.30``Felixnyuszi.12``Bodzakutya12345_Bodza + “dog”_``Norcamacska1999``Oposszum234_opossum_``pingviN1967_penguin_``Galagonya33_hawthorn_``Kokorcsin.01``LunaLovegood95``Magneto95.``Spongya12345_SpongeBob_``Csiga?4321_snail_``Medve?54_bear_``Pele4Mokus__dormouse+squirrel_``AgroMokus0808.``Ricsikutya1997…``Accipiter1992``Saxicola_rubicola_2` Food and drink `+3MákosTészta!_poppy-seed pasta_``Spagetti78``Krumplieshus16_potato&meat_``MogyiSzotyi0224_sunflower seeds_``Barackospite2_apricot pie_``Gofri618Gofri618_waffle_``Mákos202210``Rebarbara@02_rhubarb_``Coca1Cola``Cumpi11!!!``Almafa2012_apple tree_` Places — 27 of 468 `Tatabánya2800!_town + postcode_``Kaposvar1983*/``Szeged2023``Miskolc73``2100Gödöllő_postcode + town_``Isaszeg2020!``Kulsovat_1349.``Podmaniczkyutca1975_street name_``NorvegiaBergen2003``Manchester1998``Rovinj1991!``Damaszkusz.288452``Oktogon21!``Bekesmegye1987_county_``Szlovenia18` Months, seasons, dates — 21 of 468 `Szeptember2021``November01``Oktober,77``December2021!``Januar-2020``Január02``Februarban02*_"in February"_``2022Augusztus.``1991Szeptember…``Tavasztündér:)9_spring fairy_``ÉTavasz_8``Szerda0323/_Wednesday_` Brands, teams, pop culture `Chelseafootballclub95``BrigiSlipknot10``RockyBalboa-0017``Tourdefrance1``Showderklub2020!``Jobaratok911_"Friends" (TV)_``Lucifer96``Windows.8888``Opelastra1.600``Hondacb6502``Sencor.1977``Datalogic.2020``Tiger_1981``Anthology13``Cappy2005.` The employer's own name and systems — 16 of 468 `Államkincstár69_"State Treasury"_``Agrártámogatások2022_"agricultural subsidies"_``Idmrendszer7600_"IDM system"_``Dr§Kincstarnok01_"treasurer"_``Mák@munka02_MÁK + "work"_``Mvhpgy01!``HmvH_MvH202209``MvhX*******m123``Menedzsment88``Kincsem2022``Mak.hu11``2345Idm1` Name plus date of birth — the single largest group, 225 of 468 `Dani1993…``Vargak-1981…``B…Dita1966…``Csutkasor1975…``Ferenc.L…95…``Marcell2017…``Ági1990…``Évike_1995``Bettike1982``B…katka2005``R…Rebeka18``Kriszta2019.``Andi.1977``Zsombor…``LucaKata2018…``Viktoria1983…` Phrases and sentiment — including most of the handful that survives cracking `Ezazenjelszavam_013_"this is my password"_``Nemtudom2+_"I don't know"_``00Gondoltam1T_"I thought"_``Dolgozz02__"work!"_``liciDOLGOZIK21?1_"Lici is working"_``SZEretleksasad123_"I love you"_``Változás2023_"change"_``Bizalom_1985_"trust"_``Optimizmus1998_"optimism"_``T@rtsKiAdrik@7!!_"hold on, Adrik"_``Nándimese1_"Nándi's tale"_``F***off1986@``Bobi-Kacsa-Bruni12` Password equals username, or username plus one `xeloperator``weblogic``K@l…@i1_user account_``K@l…@i2_its _ADMIN account_``Vargak-1981…_echoes its username_` Read the groups as one sentence: a Hungarian dictionary, a list of given names, a gazetteer, the twelve months, and four digits of a year would regenerate the large majority of this set — which is exactly what the one-second wordlist-and-rules row in section 4 does. The passwords that resist are the ones that are simply _long_: Chelseafootballclub95, Podmaniczkyutca1975, Agrártámogatások2022, Ezazenjelszavam\_013 — none of them clever, all of them 19 characters or more. ## What a single operator with a small GPU rig actually gets [↑ contents]() This is not an APT with a datacentre behind it. The evidence points to one operator on a VirtualBox Kali VM, so the honest question is what _that_ attacker recovers. The answer is uncomfortable, for one structural reason: **NTLM is unsalted and uniterated.** Each candidate password is hashed once and compared against all 16,200 hashes simultaneously — cracking ten thousand accounts costs exactly what cracking one costs. A single RTX 4090 sustains roughly 252 GH/s against NTLM; four of them, a rig one person can buy and run at home, reach about 1 TH/s. Every figure below uses 1 TH/s. #### 4 · Time to recover the 9,030 vault passwords at ≈1 TH/s NTLM (4 × RTX 4090) 0.3 s **Mask attack** on the 8-char generator template ?u?l?d?l?l?l?l?l — 3.2 × 10¹¹ candidates 5,07656.2 % cum. ≈1 s **Wordlist + rules** — 10 M Hungarian / English / name list × 52 k rules, 5.2 × 10¹¹ candidates +1,19169.4 % cum. 3.6 min **Mask attack** on the 10-char generator template ?u?l?d?l?l?l?l?l?l?l — 2.2 × 10¹⁴ candidates +2,64198.6 % cum. 1.8 h **Exhaustive 8-character brute force** — full 95-character printable-ASCII keyspace, 6.6 × 10¹⁵. Catches every printable-ASCII password of ≤ 8 characters; Unicode characters such as Hungarian diacritics require separate masks or wordlists +4799.1 % cum. 7.3 d **Exhaustive 9-character printable-ASCII brute force** — 6.3 × 10¹⁷. Still well inside one operator's patience +5799.8 % cum. 1.9 y **Everything still standing** — needs exhaustive 10-character (6.0 × 10¹⁹) or a targeted hybrid attack 180.2 % survive **98.6 % of the vault falls inside four minutes; 99.8 % inside eight days.** Only 18 passwords out of 9,030 would still be standing — things like Ezazenjelszavam\_013, Chelseafootballclub95, Agrártámogatások2022, Bobi-Kacsa-Bruni12, Podmaniczkyutca1975. Long and unusual beats short and complex, every single time. And even several of those fall to a combinator or hybrid attack, so 18 is the optimistic reading. The two mask lines are the finding that matters most. The "random" 8- and 10-character vault passwords are not random: they are a fixed template — two letters, one digit, then five or seven lowercase letters. That template collapses the apparent 8-character search space from 6.6 × 10¹⁵ down to 3.2 × 10¹¹, a factor of **20,000**. A cracker who recovers a handful of them by any other route sees the pattern immediately and masks the rest for free. The generator was evidently chosen so passwords could be read aloud over a phone; it cost the estate four orders of magnitude of entropy. #### 5 · Projecting onto the whole domain — 10,073 user & service accounts | Attack step | Elapsed | Accounts | Basis | | --- | --- | --- | --- | | Plaintext already in hand, hash-confirmed | 0 | 503 | measured | | Home-made 1.3 M list, CPU only | minutes | 1,104 (11.0 %) | measured | | Exhaustive printable ASCII ≤ 8 characters | 1.8 h | ≈ 5,700 (57 %) | vault length profile; ASCII-only model | | Two generator masks + wordlist & 52 k rules | < 5 min | ≈ 8,600 (85 %) | projected | | All of the above, plus exhaustive printable ASCII ≤ 9 characters | ≈ 8 d | ≈ 9,060 (90 %) | projected | | Residual — needs targeted or hybrid work | months + | ≈ 1,010 (10 %) | projected | The two "measured" rows are direct results. The rest projects the vault's measured length and template distribution onto the NTDS population — defensible because both populations come from the same password policy and the same generator, and deliberately more conservative than the vault's own 99.8 %, since the NTDS set also contains accounts the vault never managed. The headline holds either way: **roughly nine in ten domain accounts inside a working week**, on hardware that costs less than a used car. The 6,129 computer accounts are the exception — machine-generated 120-character secrets, the one part of the estate with genuinely sound password hygiene, and only because no human ever chose them. Conclusion — password hygiene **This estate's password hygiene did not fail at the user; it failed at the policy layer.** Users behaved exactly as the rules incentivised them to. Minimum length 8, four character classes, forced rotation — what that measurably produces is Word + birthyear + !: 205 of 468 human passwords in one template, 326 ending in digits, 157 carrying a year, median length 11. Every complexity box was ticked. None of it bought a single hour of resistance. **The rotation worked, and still changed nothing.** 89 % of the overlapping accounts had rotated their password between the two snapshots, and the estate stayed fully exposed — because the generator template behind the new passwords was identical to the old one. Rotating a secret inside a predictable template is not rotation; it is re-drawing from the same 3.2 × 10¹¹ pool. **Concentration, not weakness, is what made this catastrophic.** Three passwords gated the entire middleware tier. One password — MvhX\*\*\*\*\*\*\*m123 — gated the identity manager that held the other 9,032 in plaintext. One reset template, A1B2c3d4, sat on 389 domain accounts. The operator never needed to be good at cracking. He needed exactly one of a very small number of secrets, and the architecture offered him several routes to each. #### Lessons learnt - **A vault that can hand back plaintext is a single point of total failure.** One OIM export compromised 9,032 identities with zero cracking effort. Reversible storage must be the rare, isolated exception, and any export from it has to be treated as a full-estate breach. - **Length beats complexity, and it is not close.** Against unsalted NTLM, every printable-ASCII password of ≤ 8 characters falls in under two hours and ≤ 9 within about eight days at the modelled rate. Unicode passwords require separate candidate sets, but targeted masks and language-specific wordlists still expose short, predictable choices. Move to a 14-character minimum, drop the forced-complexity rules, and screen every new password against a breach corpus. The handful of passwords that survived here survived on length and unpredictability alone. - **Never let a password generator have a visible template.** The Xx#xxxxx pattern threw away four orders of magnitude of entropy so that passwords could be read aloud. Generate from the full character set at greater length, and let a password manager carry the readability burden instead of the entropy budget. - **Kill the reset template.** Load A1B2c3d4\*, ABcd\*1234\*, Start12345678\*, abcd1234\*, QWer\_1234, Jelszo\*, Mvh\*, Kincstar\* and the whole organisation-name family into a custom banned-password list. Every helpdesk reset must be one-time, random, and change-at-next-logon. - **Tier separation has to be a separation of secrets.** A distinct \_ADMIN identity is worthless when its password is the user's password verbatim, or that password plus one. Privileged accounts belong in a checkout-and-rotate system where no human ever chooses or even sees the value. - **Rotation is a schedule, not a control.** Replace calendar-driven expiry with event-driven rotation — on compromise, on role change, on a breach-corpus hit — and spend the effort saved on phishing-resistant MFA, which is what actually breaks the credential-replay chain used in this intrusion. - **Retire the legacy crypto that makes all of this cheap.** Set NoLMHash and purge the 45 stored LM hashes, disable des-cbc-md5 Kerberos etypes, remediate the 13 blank-password accounts today, and plan the move off NTLM entirely — its unsalted, uniterated design is precisely why one desktop GPU rig can attack ten thousand accounts for the price of attacking one. - **Assume the whole set is burned.** With the complete NTDS.DIT and the complete vault in the operator's hands, no credential in this estate is salvageable. All 16,200 principals need a reset, computer accounts included, with a double krbtgt rotation in every compromised domain. ## The krbtgt key and the Golden Ticket — why this breach outlasts every password reset [↑ contents]() The [DCSync in step 07]() did more than copy user password hashes. A full NTDS.DIT replication from a domain can also hand over that domain’s krbtgt account key — the secret its Kerberos Key Distribution Centers use to sign tickets — and that key is the master ingredient of a **Golden Ticket**. So yes: for every domain whose krbtgt key was included in the replicated data, the operator had what was needed to forge one. #### What the krbtgt key hands an attacker - **A self-minted Ticket-Granting Ticket in the compromised domain.** With that domain’s krbtgt key, the operator can forge TGTs carrying arbitrary identities, SIDs and group memberships accepted in that domain without cracking a password. Access across domain or forest trusts still depends on the trust configuration and SID filtering. ATT&CK [T1558.001](). - **Persistence that ignores the obvious fix.** Resetting compromised user passwords — even every Domain Admin password — does nothing to a Golden Ticket, because it is signed by krbtgt, not by the impersonated account. Invalidating the stolen key requires rotating that domain’s krbtgt password _twice_, with at least the configured maximum Kerberos ticket lifetime between resets — 10 hours under the default policy. - **One key per compromised domain, not per forest.** Active Directory maintains a separate krbtgt account in every domain. The evidence must therefore establish exactly which domains’ directory data was replicated: each exposed krbtgt key enables ticket forgery in its own domain, while trust configuration determines how far that access can reach. This is exactly why the credential conclusion in the [password-hygiene section]() is **“assume the whole set is burned.”** Once the NTDS dump and the krbtgt keys are gone, no selective user-password reset restores trust in the directory — every compromised domain needs a **double krbtgt rotation**, with the required ticket-lifetime interval between resets. Any domain whose stolen key remains valid stays a route back in. #### Can you catch it? — the Yellow Cube answer Golden Ticket use is deliberately quiet: a forged TGT presented to a service looks like ordinary Kerberos, so the signals are indirect — tickets with anomalous lifetimes, RC4 encryption where the estate has standardised on AES, or a service-ticket request with no preceding authentication. Behavioural identity detection surfaces those patterns: Varonis, Cynet, Stellar Cyber. A seeded honeytoken account makes it unambiguous — any use of an identity that should never authenticate is malicious by construction: Cynet. And Cymulate proves the detection fires before the night it is needed. **But detection is the second line here.** The honest control of record is containment and rotation — the emergency double krbtgt rotation named in [step 07](), executed in every compromised domain with the required interval between resets, delivered by the Yellow Cube 24×7 SOC and a Group-IB IR retainer — because until that is done, the directory has to be treated as still owned. ## Breaking the chain — what would have stopped each step [↑ contents]() Each of the twelve steps above carries a yellow Yellow Cube strip with the short answer. This section is the long one: for every step, what would have **prevented** it, what would have **detected** it while it was happening, what would have **stopped** it mid-execution, and which configuration weaknesses our posture management would have flagged long before any of it began. Prevent — the step could not happen Detect — it becomes visible Stop — it is broken mid-execution Harden — the misconfiguration we flag in time #### How to read this — methodology - **Product attributions come from Yellow Cube's own Security Stack Matrix** — 27 control layers across 9 sections, each carrying an NIS2 flag, with a published vendor-to-layer coverage map. Nothing below is invented to fill a row. - **Claims are made per capability, not per layer label.** The matrix's layer IDs collapse genuinely different things, and this analysis deliberately does not: backup in the matrix is email archival only, cdr means public cloud and never on-premise vSphere, and privileged-session _monitoring_ is not credential _vaulting_. Where a layer looks covered but the specific capability is not, this section says so. - **Twelve of the sixteen portfolio vendors earn a place here; four do not.** This chain contains no DDoS, no email vector and no mobile device, so the vendors that answer those domains are left out. Naming only the controls that would actually have changed the outcome is the point of the exercise. - **No end-user awareness training appears either.** There is no phishing, no macro and no user mistake in this intrusion: it is unpatched middleware, an exposed debug port, plaintext credentials and a flat forest trust. The one legitimate training argument here points at the _defenders_, not the staff — see step 04. - **Managing configuration risk is a core security responsibility.** Most of what this operator used was not a missing product — it was a setting. LSASS left unprotected, SMBv1 still enabled, a debug transport listening, over-permissive directory rights, an identity store configured to hand back cleartext. Cynet’s ESPM and WithSecure Elements’ posture management surface exactly these, continuously, as findings on a dashboard rather than discoveries in someone else’s screenshots. Every **Harden** line below is something we flag _in time_. - **Service boundary.** Yellow Cube delivers the 24×7 SOC/MDR, incident-response retainers, HackLab and trainings, and strategic-planning audits. Hands-on deployment, hardening and operation are delivered by the local MSSP partner. Where a fix below is architectural, its owner is named accordingly. ##### 01 · WebLogic RCE foothold _CVE-2017-10271 · nine years unpatched_ An internet-facing ESB vhost running a 2017 deserialization vulnerability, exploited to drop a Python reverse shell to a raw IP address. Prevent Find the internet-facing host and the middleware CVE before an attacker does — external and authenticated vulnerability scanning, plus continuous external attack-surface discovery. WithSecure Elements, Group-IB ASM. NGFW intrusion prevention **may** block the deserialization payload, subject to signature coverage for a 2017 CVE and to TLS visibility on the vhost: Stormshield. Detect An oracle\-owned Java process spawning python and opening an outbound socket is a textbook endpoint detection: Cynet, WithSecure. The reverse-shell session itself on the wire: Stellar Cyber. Someone awake to triage it at 22:14: Yellow Cube 24×7 SOC. Stop Automated host isolation and process termination: Cynet, WithSecure. Default-deny egress from the DMZ segment, so the shell has nowhere to call: Stormshield. Harden A nine-year-old patch gap is not an unknown — it is an unread finding. Continuous vulnerability and posture management turns it into a work order with a date on it: Cynet ESPM and WithSecure Elements flag the unpatched middleware, the internet-facing exposure and the missing host hardening, and keep flagging until it is closed. Applying the patch itself belongs to your platform team or MSSP partner; knowing it is nine years overdue, and being told so every day until it is fixed, is ours. Where the patch cycle genuinely cannot move, Stormshield IPS and DMZ segmentation are the compensating controls we design around it. ##### 02 · MS17-010 on the entry subnet _Windows Server 2003 · Sliver + SOCKS5_ EternalBlue against a legacy host the operator himself called useless, kept purely for persistence, with a SOCKS5 pivot on top. Prevent East-west segmentation so SMB never reaches a host like this from anywhere that matters: Stormshield. Posture management flags the end-of-life operating system and the enabled SMBv1 dialect as standing findings long before anyone exploits them: Cynet ESPM, WithSecure Elements. And worth stating plainly, because it is usually got wrong: **MS17-010 did ship for Server 2003** as an out-of-band patch in May 2017 — “unsupported, therefore unpatchable” is factually incorrect here. Detect **This is where the portfolio does something almost nobody else does: Cynet still supports Windows Server 2003.** That is a deliberate vendor decision, and in an estate like this one it is worth a great deal — legacy hosts are precisely where operators start, exactly because everyone else’s agent stops at Server 2012. A modern, SOC-backed EDR on a 2003 box turns the attacker’s favourite blind spot into monitored ground: the EternalBlue exploitation, the Sliver implant and the SOCKS5 pivot all become visible on the host itself. Alongside it a network sensor sees both halves independently — the SMBv1 exploit attempt, then the beacon’s periodicity and the tunnel’s shape: Stellar Cyber, Group-IB. And decoy hosts and shares catch a lateral-mover who cannot tell them from the real thing: Cynet deception. (Cynet’s published support matrix lists Windows Server 2003 from Service Pack 2, noting that some protection capabilities are partially limited on it — detection and response, which is what matters on a host like this, are present: [help.cynet.com/en/articles/47-supported-operating-systems]().) Stop Host isolation on the 2003 box itself, which is only possible because there is an agent on it: Cynet. Quarantine the source host or the whole segment at the firewall: Stormshield. SOC-driven containment: Yellow Cube 24×7 SOC, Group-IB IR. Harden SMBv1 cannot be disabled on Server 2003 — it is the only dialect the host speaks — so this machine will always carry residual risk until it is retired. Posture management gives you what you need to retire it: the inventory, the risk score and the evidence to fund the migration. The difference this makes is timing. Instead of an unmonitored legacy host discovered by an attacker, you get a monitored, segmented, agent-covered host on a decommissioning plan — defended while it waits. ##### 03 · Forgotten JDWP debug port _clean RCE as oracle_ A Java Debug Wire Protocol port left listening on a production WebLogic host, giving a second and cleaner way in than the exploit did. Prevent Ingress port allowlisting, so a debug transport is unreachable even when someone leaves it enabled: Stormshield. External and internal port discovery, so it shows up on an inventory before it shows up in an intrusion: Group-IB ASM, WithSecure. Detect The JDWP-Handshake exchange is distinctive on the wire, and what the oracle account does next is distinctive on the host: Stellar Cyber, Cynet, WithSecure. Stop Host isolation: Cynet, WithSecure. Egress deny, as in step 01: Stormshield. Harden JDWP authenticates nobody — that is the specification, not a bug — so there is no patch to wait for, and that is exactly why catching it as a _misconfiguration_ is the control that matters. A listening debug transport is precisely the class of finding posture management exists to surface: Cynet ESPM and WithSecure Elements flag it on the host, Group-IB ASM flags it from the outside, and both keep flagging it until it is closed. Putting a build gate in front of the next one is a strategic-planning audit deliverable. ##### 04 · Hitting the segmentation wall _the defence that worked_ Egress throttled to ICMP, SELinux in the way, neighbouring subnets walled off. The operator wrote it down himself: "no outbound, except pings and basic commands." **This is the single strongest finding in the entire chain** — the controls did their job. Nobody was reading their output. Prevent Already working. Keep deny-by-default and make deny-_logging_ mandatory rather than optional: Stormshield. Detect Centralise the firewall and SELinux deny events and alert on the pattern rather than the individual event — repeated blocked egress from one host, a walk across adjacent subnets. This needs breadth of third-party log-source support, which is exactly what Stellar Cyber is built for — firewall, host and appliance telemetry landing in one place alongside the endpoint picture. Stop A human behind the alert, at 02:00, every night: Yellow Cube 24×7 SOC, WithSecure MDR, Group-IB MXDR. Continuous proof that the alert actually fires before you need it: Cymulate. And rehearsal of this exact failure mode — control fired, nobody reacted: CYBER RANGES plus Yellow Cube HackLab. ##### 05 · Oracle Identity Self-Service _thousands of accounts · reversible passwords_ The identity portal reached on port 14000: thousands of government accounts, modifiable, with passwords stored so they can be read back in cleartext. Prevent Nothing in an internet-facing ESB segment should be able to reach :14000 at all: Stormshield. Multi-factor in front of the portal and vaulted, checked-out identities for its administrators: Imprivata — with the integration scope validated rather than assumed. Detect Decoy identities planted inside the identity store, whose use is malicious by construction and therefore needs no threshold tuning: Cynet. An abnormal privileged session on the administrative path: Varonis, Stellar Cyber. Harden **This is the highest-leverage finding in the whole engagement.** Reversible, plaintext-recoverable password storage is a configuration decision, and it is why a single export handed over 9,032 identities with zero cracking effort (see the [password-hygiene section]()). Posture management surfaces weak identity-store and self-service configuration as a standing finding rather than a surprise: Cynet ESPM, WithSecure Elements. Varonis maps who can reach the store and with what rights. And the decision itself — turn off reversible encryption, kill self-service retrieval, segment the portal — is scoped, evidenced and driven to closure by a strategic-planning audit. This is the finding that engagement exists to produce. ##### 06 · Service account & forest trust _credential in shell history_ A full-AD service account sitting in a shell history file, and a bidirectional FOREST\_TRANSITIVE trust from MVH into allamkincstar.gov.hu. Prevent A privileged secret that is vaulted, rotated and checked out on demand never exists in a script or a history file to be found: Imprivata PAM. Phishing-resistant multi-factor on every path that account could use: Imprivata, Stormshield for VPN and firewall administration. Detect A service account logging on interactively, from a commercial hosting IP, across a forest boundary — three anomalies stacked in one event: Varonis is the strongest AD-native option here, supported by Cynet and Stellar Cyber. Stop Disable and rotate the account, block the source, isolate the host: Cynet, WithSecure, Stellar Cyber. Harden This trust is the entire reason the intrusion reached the Treasury at all, so it deserves to be visible rather than assumed. Varonis maps Active Directory permission relationships and cross-forest exposure, which turns “we have a trust” into a scored list of the paths it actually opens; posture management flags the trust configuration alongside it. Applying selective authentication, SID filtering or quarantine is then a design change delivered with your MSSP partner — scoped by the audit that surfaced it, not improvised during an incident. ##### 07 · BloodHound & DCSync across forests _NTDS.DIT dumped_ Domain trusts graphed and NTDS secrets replicated out across four forests, mapping the reachable path to Tier-0. Detect DRSUAPI replication requested by something that is not a domain controller is one of the highest-precision detections in all of Active Directory security: Varonis, Cynet, WithSecure, Stellar Cyber. Two conditions decide whether it works here: collectors on the domain controllers of **every** forest — including the child MAK forest and the pension forests — and an allowlist for legitimate replication partners and directory-sync tooling. The realistic failure mode in an estate this shape is not false positives, it is a forest nobody instrumented. Honeytoken accounts seeded into AD close the gap from the other side: once a decoy credential appears in a stolen NTDS dump, any later use of it is unambiguous. Cynet. Stop Honestly: not stoppable mid-execution. NTDS extraction completes in seconds. What is real is fast containment of the source host and an emergency double krbtgt rotation in every compromised domain, with at least the configured maximum Kerberos ticket lifetime between resets: Yellow Cube 24×7 SOC, Group-IB IR. And proving the detection exists before the night it matters: Cymulate. Harden Varonis surfaces excessive directory rights — including DS-Replication-Get-Changes held by principals that are not domain controllers — as a posture finding before anyone abuses them, which is by far the cheapest moment to remove them. Enforcing tiering so that a DCSync-capable identity is never reachable from a web-tier shell is the design half, delivered with your MSSP partner. And one point of tradecraft that saves real money: bulk LDAP enumeration of the BloodHound kind is genuinely hard to separate from inventory and IAM tooling, so we put the weight on the DCSync signal and the honeytoken rather than chasing it. Knowing which signal to trust is the difference between a SOC and an alert queue. ##### 08 · OIM database & storage scouting _36 TB of shares enumerated_ The identity-manager schema browsed in a database client, and the corporate file estate walked: 15.9 TB, 15.9 TB, 5 TB, plus shadow copies. Prevent Least-privilege share permissions, stale and open-access remediation, and sensitive-data discovery so the blast radius is known before someone else measures it. Varonis is the single best portfolio fit for any step in this chain, supported by Teramind on the endpoint side. Detect Mass share enumeration, crawl patterns, shadow-copy access, and abnormal access by an identity that has no business doing it: Varonis, Teramind, Stellar Cyber. Decoy files sitting inside the real shares: Cynet. Stop Automated permission revoke, account disable or share quarantine triggered by the abnormal-access alert rather than by a ticket: Varonis, Cynet. Harden The reason this step worked is that nobody knew what was in those shares, who could read them, or that something had just walked all of them — a solvable, licensable condition, and exactly what Varonis is for. On the database side, posture management flags the host’s configuration and exposure, and Oracle’s own auditing — which should have been recording schema access and evidently was not — is a configuration we validate in the audit rather than assume. Turning it on costs nothing, and it would have made step 08 noisy. ##### 09 · Confronting Symantec _agent stopped by hand, then LSASS dumped_ The pivot of the whole intrusion — and the step where the commercial argument is strongest, precisely because **the incumbent product was working**. Symantec blocked the outbound beacons and blocked named-pipe access to LSASS. It kept working right up to the moment somebody switched it off: RDP to the security-tooling host, stop two services, dump LSASS. The operator's own note reads "lsass works :)". Prevent No interactive local-administrator RDP to the host that runs your security tooling. Brokered, multi-factored, just-in-time and recorded instead: Imprivata PAM for the vaulting and brokering, Teramind for privileged-session recording. Detect The honest control of record for this step is not blocking — it is **noticing**. Agent heartbeat loss and security-service-stop tamper events, correlated and escalated within minutes: Cynet, WithSecure, Stellar Cyber as the log consumer, escalated by the Yellow Cube 24×7 SOC. Symantec was already producing blocks that night; the gap was that no one acted on them. Stop Automatic isolation triggered by tamper or heartbeat loss, so switching the agent off _is_ the containment trigger: Cynet, WithSecure. Proof that the tamper → alert → isolate chain works end to end: Cymulate. Stated precisely, because the distinction matters: tamper protection raises the cost of disabling an agent and emits a high-fidelity tamper event — it does not make removal impossible for an attacker who already holds local administrator. Harden **This is what posture management is for, and this step is the case for it.** LSASS left unprotected, Credential Guard off, RunAsPPL not set, interactive administration still required on a security-tooling host, legacy authentication and over-permissive client policy left enabled on the management server — every one of those is a _setting_, and every one of them is exactly what Cynet’s ESPM and WithSecure Elements’ posture management flag continuously. Crucially, they flag them **in time**: as a scored finding on a dashboard weeks before an operator turns them into a credential dump, not as a forensic conclusion afterwards. The attacker did not defeat a control at this step. He walked through a configuration nobody was checking — and checking it is a licence and a process, both of which we deliver. ##### 10 · vCenter & the 229.1 TB datastores _plan: encrypt in place from ESXi_ vSphere SSO administrator credentials found, 116 VMs and 229.1 TB of datastores enumerated, and a stated plan to encrypt the estate in place. Prevent An isolated management network reachable only through a hardened jump host — the single highest-value change for this step: Stormshield. Vault and rotate the vSphere SSO administrator credentials, and require multi-factor authentication, and break the six-character, organisation-name credential family it belongs to: Imprivata. Find the file holding those credentials before the attacker does: Varonis, Teramind. Detect vCenter and ESXi syslog shipped into a platform someone watches — SSH enabled on a host, a new local account, mass VM power, snapshot or datastore operations. This is a standard, well-supported log source: Stellar Cyber. Stop Management-VLAN isolation to cut the session: Stormshield. SOC containment and an incident-response retainer already in place, not negotiated during the incident: Yellow Cube 24×7 SOC, Group-IB IR. Harden A hypervisor is defended at its access path, not with a third-party agent inside it — that is VMware’s own architecture, and it is why the three controls above are the correct answer rather than a compromise: isolate the management plane, vault the credentials that reach it, and take the telemetry it already emits. Posture management flags the management-plane exposure and the credential reuse that led here. One precision we hold to, because it is the easiest thing to get wrong in a document like this: cloud detection and response covers IaaS and SaaS, so on-premise vSphere is scoped to segmentation, privileged access and log telemetry. Naming the right control for the right platform is the whole job. Recovery from in-place encryption is treated separately below. ##### 11 · Proof pack to Google Drive _70 MB · from the operator’s own machine_ Thirteen screenshots, the credential dump, the recon output and one video — roughly 70 MB — uploaded to a personal cloud account under the name “Loic Matrier”. The evidence points squarely at the **operator’s own virtual machine**, not a Treasury endpoint — the data was already off the estate by the time it reached a browser, so there is no in-network upload for a firewall, proxy or endpoint agent to catch. Saying that plainly is the point of this step: a report that placed a defensive product here would be selling you the wrong thing. Detect What genuinely answers at this stage is **credential-exposure monitoring**, not egress control. Group-IB Digital Risk Protection watches underworld marketplaces, leak channels and forums, and raises an alert the moment credentials from this dump are offered for sale — and they will be, fast. **9,047 are already in cleartext**, and the password-hygiene analysis above projects a further **≈7,960 user and service accounts falling within a week** on a small GPU rig: weak hashes crack quickly and reach the market just as quickly. That turns a silent, growing exposure into a dated, actionable finding — from the same digital-risk capability, and the same source, this report already relies on for the ByteToBreach actor profile. Harden Because the exfiltration ran off a machine you will never control, the leverage is not at the upload — it is on either side of it. Before: Varonis on the data and Imprivata on the credentials decide how much an operator can stage in the first place (steps 05 and 08). After: every credential in this dump has to be treated as public — the 9,047 cleartext immediately, and the crackable remainder on the days-to-a-week timeline the analysis above sets out — and rotated on that assumption, with Group-IB DRP telling you which of them surface for sale, and when. Perimeter upload blocking was never the plan here; knowing what leaked and watching where it goes is. ##### 12 · Public disclosure _leak thread + cloud mirrors_ The leak thread goes live with the screenshot set and mirrors on three consumer cloud services, with an explicit note that no ransom is being asked. Detect Leak-site, underground-forum and mirror monitoring with actor attribution attached: Group-IB Digital Risk Protection — the portfolio’s digital-risk capability, and the same source this report already relies on for the ByteToBreach actor profile, which is about as concrete as coverage evidence gets. Frame it accurately, though: this is a **time-to-know** control. Detection lands after publication, typically hours to days, and pre-publication warning only materialises if the actor teased the victim beforehand — common, but never guaranteed. Stop Split the takedown claim honestly. The actor's own leak site is not realistically takedown-able. The consumer-cloud mirrors and the Drive folder from step 11 are, through abuse channels — and that is the concrete, deliverable value: Group-IB plus an incident-response retainer for the coordinated response. Harden By the time a leak post exists there is nothing left to prevent, and saying so plainly is part of the job — the work at this point is NIS2 incident notification, legal counsel and communications, and it should be rehearsed long before it is needed. What remains genuinely controllable is the two rows above: how fast you know, and how fast the mirrors come down. “Data is not for sale, no ransom is asked” removes the negotiation, but changes nothing about the notification clock. #### Coverage at a glance | Step | Control layers defeated | NIS2 | Portfolio answer | | --- | --- | --- | --- | | 01 WebLogic RCE | Vuln mgmt · Posture · NGFW · EDR · MDR | required | Covered — detect, contain, and flag the patch gap in time | | 02 EternalBlue | Posture · Segmentation · EDR · NDR · Deception | implied | Covered — including EDR on Server 2003 | | 03 JDWP | NGFW · Posture · NDR | required | Covered — posture flags the misconfiguration | | 04 Blocked egress unwatched | SIEM · MDR · BAS · Cyber range | required | Covered — and the best opportunity in the chain | | 05 Reversible identity vault | MFA · PAM · ITDR · Deception | required | Covered — posture finding plus audit ownership | | 06 Credential in history + trust | PAM · MFA · ITDR · Posture | required | Covered — trust exposure mapped and monitored | | 07 DCSync across forests | ITDR · SIEM · BAS · Deception | required | Covered — high-fidelity detection, rights flagged early | | 08 36 TB of shares walked | Data governance · Posture · UEBA | above | Covered — Varonis owns the data layer | | 09 Security agent switched off | Posture · PAM · EDR · XDR · MDR · BAS | required | Covered — tamper alert plus 24×7 response | | 10 vCenter & 229.1 TB | Segmentation · PAM · SIEM · Backup | required | Covered at the access path — see the backup note | | 11 Upload to personal cloud | Credential exposure monitoring · DRP · IR | implied | Outside the victim perimeter — monitor exposure, rotate credentials, coordinate takedown | | 12 Public disclosure | Digital risk protection · IR | required | Covered — time-to-know and mirror takedown | Four **NIS2-required** layers were defeated outright in this intrusion: privileged access management, identity threat detection, managed detection and response, and backup. For a public-administration essential entity, those four are not optional maturity — they are the floor. #### The five places this chain actually breaks Twelve equally-weighted recommendations are not a recommendation. Ranked by how much of the intrusion each one removes: - **Controls fired and nobody read them.** Steps 04 and 09 are the same failure twice: egress filtering blocked the operator, Symantec blocked his beacons and his LSASS access, and both produced alerts into an empty room. A **24×7 SOC/MDR** capability is the single highest-leverage change available here — it converts controls the organisation already owns into an actual response, and it is the one recommendation that would have shortened this intrusion from five and a half days to hours. - **Static privileged secrets, everywhere.** A service-account password in shell history (06), an administrator password reused across the middleware tier (09, 10), and 9,032 passwords stored so they can be read back (05). **Privileged access management** answers the first two; read the [password-hygiene section]() for the scale of the third. - **Cross-forest DCSync was invisible.** Step 07 is the cleanest detection opportunity in the entire chain and it went unnoticed — most likely because nothing was instrumented on the domain controllers of every forest in the trust web. **Identity threat detection with complete DC coverage**, validated rather than assumed. - **A flat internal network with an exposed management plane.** Steps 02 and 10. Segmentation would not have prevented the foothold, but it would have contained it to a subnet the operator himself described as useless — instead of letting it reach the hypervisor holding 116 production VMs. - **36 TB of file shares with no data governance.** Step 08. Nobody knew what was in those shares, who could read them, or that something had just walked all of them. That is a discoverable, fixable condition, and it is what decides how bad a breach is once someone is inside. #### The configuration and design findings — and who closes them Most of what this operator exploited was a setting, not a missing product. That is good news: settings are findable. Every item below is something posture management surfaces continuously, or a strategic-planning audit scopes and evidences — and then your MSSP partner closes. | Step | Configuration or design finding | Surfaced by → closed by | | --- | --- | --- | | 01 | Nine years of unapplied middleware patches on an internet-facing host | Cynet ESPM / WithSecure → partner patch cycle | | 02 | End-of-life Server 2003 host on a routable segment, SMBv1 enabled | Posture inventory → lifecycle plan (Cynet covers it meanwhile) | | 03 | JDWP debug transport listening in production | Cynet ESPM / Group-IB ASM → release gate | | 05 | Reversible, plaintext-recoverable password storage in the identity manager | Posture + strategic-planning audit → platform change | | 06 | Bidirectional forest trust with no selective authentication or SID filtering | Varonis → AD design change with partner | | 07 | Directory replication rights held by non-domain-controller principals | Varonis posture → rights cleanup | | 08 | Oracle native auditing not recording schema access | Posture + audit → enable native auditing | | 09 | LSASS unprotected — Credential Guard off, RunAsPPL not set | Cynet ESPM / WithSecure → GPO change | | 09 | Over-permissive management-server client policy and legacy service account | Posture finding → SCCM redesign with partner | | 10 | Immutable, offline, tested VM backup | Your backup vendor → see the note below | | 11 | 16,202 credentials exposed — cleartext now, weak hashes within a week | Group-IB DRP marketplace monitoring → rotate on the assumption they are public | | 12 | Disclosure can no longer be prevented, but notification can be prepared in advance | Rehearsed NIS2 notification process | #### On backup — the last resort for step 10, and where it sits Step 10 was a plan to encrypt 229.1 TB of virtual machines in place. Against in-place encryption there is exactly one control that answers, and it is immutable, offline, tested backup. It belongs in this report as the last resort it is — the thing that decides whether an incident is a bad week or an existential one. **And restoring 229.1 TB is far from trivial.** The same physics that made bulk exfiltration infeasible earlier in this report cuts the other way on recovery: | Sustained restore rate | Time to restore 229.1 TB | | --- | --- | | 500 MB/s (typical dedupe appliance, single stream) | ≈ 5.3 days | | 1.5 GB/s (well-tuned, parallel streams) | ≈ 42 hours | | 10 Gbps (ideal, line-rate) | ≈ 2.1 days | And every one of those figures assumes the backups exist, that they are immutable, that they were not encrypted alongside the estate they protect, and that a restore at this scale has actually been rehearsed rather than merely configured. A backup job that has never been restored is a belief, not a control. **Yellow Cube does not offer a backup solution, and that is a positioning choice rather than an oversight.** Backup and business continuity is a mature, extremely well-served market where a specialist cyber-defence distributor adds little that the incumbents do not already do better. The portfolio principle is one specialist vendor per domain, and only in domains where there is genuine value to add. This is a domain to bring your existing vendor to — the recommendation here is that the control is _tested_, not that it is bought from us. Where to start **This intrusion did not succeed because the defences were absent.** Egress filtering held. SELinux held. Symantec blocked the beacons and blocked LSASS. The operator wrote his own frustration down in his own screenshots. Every one of those controls did what it was bought to do — and then reported into a room with nobody in it, for five and a half days. **So the first move is not a product, it is a shift.** Put a 24×7 detection-and-response capability behind the controls that already exist, then close the credential and identity architecture gaps behind it. Cymulate to prove continuously that the detections fire rather than assuming it; CYBER RANGES and the Yellow Cube HackLab to rehearse the specific failure this report documents — a control fired, nobody reacted; and a strategic-planning audit against the 27-layer Security Stack Matrix to find the remaining gaps before someone else maps them for you. Deployment and hardening are delivered by your local MSSP partner. What Yellow Cube brings is the portfolio, the 24×7 SOC behind it, the incident-response retainer for the night it matters, and the enablement to make all three work. **Attribution tell:** the BloodHound collection host reported timestamps in **PDT (UTC−7)** while every compromised system ran CEST — the operator's analysis workstation clock was set to US Pacific. The leaked walkthrough video adds two more leads: the operator's own Kali VM is hostnamed **stephlabs**, and its Sliver C2 implants beacon to **84.206.46.11, 84.205.244.140, 85.209.80.29** — three unrelated government networks in Hungary, Greece, and Georgia, one of them (the Hungarian block) registered to MVH itself; see the C2 infrastructure panel above. Reconstructed from 24 operator screenshots (spear\[.\]cx DLS "The Magyar Conquest"), 125 keyframes extracted from the operator's leaked walkthrough video, the Group-IB ByteToBreach actor profile (vendor intelligence), KELA Cyber’s public ByteToBreach threat-actor profile, and file metadata. Actor: ByteToBreach (aka dodhlojka · dodhlo · kalabaz), first seen 08 Jun 2025. Target: Magyar Államkincstár via the mvh inter-forest trust. Times normalised to Europe/Budapest (CEST, UTC+2); 229.1 TB read decimal (2.291 × 10¹⁴ bytes) for all calculations. **Data protection.** This report reproduces credential material from the public leak only so far as each finding requires. Personal data has been minimised throughout: usernames are omitted entirely, surnames reduced to an initial, and dates of birth truncated to a year or removed. Production credentials are shown partially masked. The unredacted evidence set is retained under separate control and is not published. Nothing here is intended to identify any individual employee. **Source of truth.** Every technical finding about this intrusion derives from the threat actor's own data-leak-site publication — hxxps\[://\]spear\[.\]cx\[/\]Thread-Selling-HU-The-Magyar-Conquest, DLS entry **“The Magyar Conquest”** — together with the operator screenshots, keyframes and credential files published there. Actor attribution is the one exception: it draws on the Group-IB and KELA Cyber threat-actor profiles cited above, not on the leak itself. The URL is defanged; do not resolve it from a corporate network or an attributable browser. Yellow Cube Cyberdefense Digital forensics & incident response · offensive security · XDR assurance Prepared by **Akos Bodis** · [akos.bodis@yellowcube.eu]() · +36 20 932 1240 [yellowcube.eu]() ## Attribution and scope This Markdown representation is generated from the same approved content records as the canonical HTML page. Cite the canonical URL above when referencing this material. Product and service descriptions are informational; confirm project-specific requirements with Yellow Cube.