Anatomy of the Treasury breach — and why 229.1 TB was never going out the door

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.

Where do the Sliver beacons actually go?

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.

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.

1 · How much is already known, and how much falls next

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 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.

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.

4 · Time to recover the 9,030 vault passwords at ≈1 TH/s NTLM (4 × RTX 4090)

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

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.

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, everything ≤ 8 characters falls in under two hours and ≤ 9 within a week, no matter how clever the characters are. 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.

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.
• Configuration weakness is treated as a first-class control. 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.
• Configuration weakness is treated as a first-class control. 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.

Coverage at a glance

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 above 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.

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:

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.