In April I published the ANAF technical record. In July, ANCPI was hit by ransomware. In October I returned to the public ANAF and ANCPI surface to check WHAT CHANGED and WHAT REMAINED. Below I separate what I observed, what the evidence demonstrates, and what the institutions operating these services still need to explain or remediate.
OPEN THE RECORD ↓SEE WHAT I FOUND →On 14 July 2026, ANCPI detected unauthorized access. The Romanian Government later stated that the technical investigation confirmed ransomware and that attackers encrypted and deleted part of the virtualization infrastructure hosting agency applications. The October audit is a separate event: it records what public services exposed at the time of capture.
Confirmed ANCPI ransomware incident, service disruption, investigation and recovery.
Reproducible public audit of ANAF and ANCPI, with hashes and per-case evidence references.
The captured request to http://ancpi.ro/ ended on HTTP and returned content. The observed public configuration did not force that request onto HTTPS.
REAL CONTROL RISK: traffic delivered over HTTP lacks TLS confidentiality, integrity and server authentication.
The published DMARC policy was p=none. That requests reporting, not quarantine or rejection based on DMARC failure.
REAL CONTROL RISK: the domain does not request DMARC enforcement. Actual mail acceptance still depends on SPF, DKIM, alignment and receiver policy.
Captured ANAF responses emitted JSESSIONID without HttpOnly, Secure and SameSite attributes. The observation was repeated across multiple captured responses.
REAL CONTROL RISK: those explicit browser-side restrictions are absent. The evidence does not prove XSS, CSRF, session theft or the role of that cookie.
Captured responses also showed missing HSTS and other browser-side hardening controls, plus public middleware fingerprinting. These are configuration findings, not proof of a successful attack.
REAL CONTROL RISK: missing hardening removes defensive layers and public fingerprinting reduces uncertainty for an attacker.
This terminal is a deterministic presentation of the preserved audit snapshot. It does not contact ANAF or ANCPI from your browser.
Every strong statement on this page is tied to a dated observation. Each card also states what the evidence cannot establish. That distinction makes the record stronger, because a reader can audit both the finding and its boundary.
The April TRACE investigation documented legacy technology, public error output and user-facing failures. The October follow-up adds a new, separately captured security-control record for ANAF and ANCPI. The two records should remain separate in time and linked, rather than rewritten into one undated accusation.
OPEN THE APRIL ANAF INVESTIGATION →After a confirmed ransomware incident, public statements emphasized recovery, safety and remediation. A later public audit still observed controls worth fixing or explaining, including HTTP without forced HTTPS and DMARC p=none. Those observations do not identify the ransomware entry point. They do create specific, answerable technical questions.
The incident chronology is linked to official/public institutional reporting. The October technical findings come from the preserved audit package. No claim here says that the public findings caused the ransomware incident, that every internal system is vulnerable, or that a named employee is responsible.
Do not ask readers to trust the author. Give them the URL, timestamp, observation, hash, technical consequence, remediation and the exact limit of the proof. Then let the record stand.