PRTCT

The cyber insurance market has tripled since 2020 but remains inefficient due to a lack of trust. Insurers delay payouts because they do not recognise the occurrence of a Cyber-Incident without manually verifying confidential IT infrastructure. Affected companies even refuse to receive payouts just to prevent data leaks from insurers and additional legal expenses.

We are building a cyber insurance infrastructure platform that allows policyholders to prove the occurrence of a Cyber-Incident without disclosing corporate secrets, reducing the approval payout time from several months to a few hours. We replace trust with ZKP: a Cyber-Incident can be proven only with strong evidence in the form of signed audit logs, which are verified within the ZK circuit to ensure compliance with the terms of the cyber insurance policy.

The PRTCT platform acts as an intermediary between the Insurer and the Policyholder. For Policyholder to generate a ZKP of Incident, a reliable source of trustworthy and authentic Cyber-Incident data that is extremely difficult to tamper with is required. Such a source can be SOAR-class cybersecurity systems, which emit Cyber-Incident artifacts that cannot be tampered with or altered without being detected. SOAR-class systems are the best choice due to their orchestration function: they collect raw security data and alerts from all other company cybersecurity modules, such as SIEM, EDR, DLP, WAF, NGFW, etc.

To ensure a stable and secure data transfer channel from Policyholder to PRTCT, we assume to integrate the lightweight Watch Guardian module into Policyholder's IT infrastructure during the cyber risk underwriting phase, ensuring the delivery of Cyber-Incident artifacts over secure communication channels in real time. We have several working hypotheses regarding practical implementation (TLS in backend is major), but we plan to experiment with zkTLS separately.

To ensure legal validity and as an additional measure to prevent fraud by Policyholder, each sent Cyber-Incident data packet is additionally digitally signed within Watch Guardian, which is legally binding in court proceedings.

After receiving and processing all Cyber-Incident data, the PRTCT platform allows the Policyholder to initiate the generation of a ZK Proof and send it to the Insurer for verification. Within the arithmetic circuit, a check is made to determine whether the Cyber-Incident actually meets the policy terms. A ZK Proof cannot be generated if the Cyber-Incident does not meet the policy terms. Successful Proof of Incident generation, in turn, confirms the Policyholder's right to promptly receive insurance compensation: timely assistance from the Insurer can minimize the impact of existing Cyber-Incidents and prevent them from escalating into more serious events.

The platform's operating algorithm consists of 5 main phases:

1. Cyber-Incident Occurence
2. Cyber-Incident Processing
3. ZKP of Incident: Initiation
4. ZKP of Incident: Generation
5. ZKP of Incident: Broadcast

As part of the hackathon, we were able to build a simplified prototype system and write the logic for proving the onset of a rather critical Golden Ticket Attack — a cyberattack targeting Active Directory infrastructure that allows attackers to gain persistent domain-level access by forging Kerberos authentication tickets.

The current version of the architecture implements only the basic logic of Policyholder and Insurer authorization via Azguard Wallet (Aztec), acceptance and processing of incidents in the form of mock data, generation of ZK Proof of Incident (Golden Ticket Attack) via Noir circuit, as well as ZK Proof broadcast and display on the Frontend.

Stack

• Backend: Python, PostgreSQL, FastAPI, Uvicorn
• Frontend: Typesript, NextJS, Aztec.js, Azguard Wallet SDK
• ZKP: Noir
• Contracts: Noir, Aztec.nr, Aztec Devnet

Attack Vector

• The circuit processes Windows Security Event logs, specifically focusing on Kerberos authentication events.
• Compromise: Attacker obtains the KRBTGT account password hash (domain controller's master key)
• Forgery: Creates fake Ticket-Granting Tickets (TGT) with arbitrary parameters
• Persistence: Gains unlimited access to any domain resource while remaining undetectable

Attack Detection Logic

1. Anomalous Ticket Lifetime Detection: What we prove: TGT ticket exceeds policy maximum (normal: 10 hours, attack: years)
2. Ghost User Detection: What we prove: Ticket requested for non-existent/forged user account
3. Privilege Escalation Detection: What we prove: Non-existent user has Domain Admin privileges