tl;dr:

• On Sunday, July 14th, 2024, our monitoring systems detected unusual activity in one of our backoffices. This activity was quickly identified as a malicious attack by a rogue account and was contained shortly after.
• An operator account access credentials were compromised, allowing the attacker to  exfiltrate data for ~0.5% of our user base. We regret what happened, and we will do our best to protect affected users.
• The operator, who had been with us for 3 years, had admin rights. This allowed the attacker to sidestep internal technical data privacy systems, however, system monitoring picked up the threat and allowed us to lock out the attacker 29 minutes later.  
• The operator didn’t follow our opsec policies and training. We have put technical measures in place to ensure these cannot be sidestepped by any operators in the future. This was not the result of a software vulnerability.
• We concluded with the help of external technical security support the scope of the attack and have contained it.
• We are taking steps to mitigate the consequences of this attack, including prioritizing additional security measures and working together with the authorities and cybersecurity services to limit the impact of the data breach.

Incident and response

On Sunday, July 14th, 2024 at 07:00 UTC, our systems monitoring alerted one of our engineers who was on call. This alert pointed to unusual activity on one of Fractal ID’s backoffices: one specific endpoint, not regularly used in the course of normal operations, was being queried. This initially appeared to be a regression on the backoffice’s frontend code, but it soon became clear it was instead evidence of an attack, and at 07:29 UTC they shut down this backoffice to thwart it.

This engineer immediately sounded the alarm and the team proceeded to look deeper into the situation. After our analysis, we concluded we had just suffered a data breach. An admin account in the backoffice had signed into the system using valid credentials and, using their privileged admin access, hit the system’s API to exfiltrate user data one by one, presumably keeping a copy of this data to themselves. This privilege was required for this account due to their role in Fractal ID. This level of access was granted to very few admin operators.

We disabled every account in this system before bringing it back up and limited the access to few senior core Fractal ID employees.

The admin privilege allowed the attacker to side step internal technical system data privacy protection methods, like severely limiting data access to currently processed users (one at a time). In addition, the operator didn’t follow our operational security policies and training, which allowed the attacker to siphon access credentials. This was due to the operator reusing credentials that were compromised by unrelated past hacks and ignoring security warnings.

We have since put measures in place to technically ensure that operational security cannot be sidestepped by any operators in the future, and reviewed and restricted the roles in the system.

We have also taken immediate steps to mitigate the impact of this breach, and have contacted the pertinent data protection authorities and the cybercrime police division. The breach was contained within our environment and did not affect any of our clients’ systems or their products that use our services. We will continue to work together with the pertinent data protection authorities to minimize the impact of the data breach.

We were later contacted by a party who claimed responsibility over the attack. They requested a ransom from us. We didn’t engage and reported them to the authorities.

Who was affected and what data was compromised

The rogue account had access to data from 6.3k users, representing approximately 0.5% of the users in our database. We have reached out to affected users directly to inform them of the breach. The data breached varies from proof-of-personhood checks only to a full KYC check, depending on what users needed to provide when onboarding. That may include names, email addresses or phone numbers, wallet addresses, physical addresses, images and pictures of any uploaded documents.

We have ongoing obligations to our clients to keep user data stored centrally after verification. This data is encrypted at rest, but since it was accessed by a valid operator’s account, our backend decrypted the data for display as it would during regular operations to support our clients. To reiterate, this data is not accessible to all operators, but just to a few administrators.

What measures we are taking to avoid similar attacks in the future

We’re prioritizing measures to make our login system more robust and avoid future similar attacks as well as mitigate their consequences:

• Request throttling: limiting the amount of user data that any account can access per time period
• Finer-grained authorization: creating additional account types which enable serving our clients without revealing anything other than the necessary for specific instances
• Tighter monitoring of failed authentication attempts: preventing attempts to dictionary-attack an account’s password
• Tighter IP control: use the current access IP monitoring to block access when an account is not authenticating from their regular IP

What we will do to protect customers

We take the security and privacy of our users’ data extremely seriously. In addition to improved security measures, we are engaging with a cybersecurity service to monitor if the user data is added to known data breach sites. We will keep users updated and contribute as much as possible to stop its diffusion.

We have also contacted the pertinent data protection authorities and filed a criminal report to the police cybercrime department of Berlin.

There is a possibility that the accessed data could be sold to third parties, used by impersonators online or exploited for commercial purposes. We recommend users to be cautious of unsolicited communications requesting additional personal information.

We will keep users informed with relevant updates. If you have any questions or we can help in any way, please reach out to help@fractal.id

Way forward

We realize that this data breach is really painful for our impacted users. It is also painful for us as we were tasked to keep these users’ data secure.

We have immediately analyzed and improved our systems. However, with centralized data storage it will always be a race between attackers and defenders like us. Our goal, long stated before this incident, has been to move people off Fractal ID’s centralized servers into a self-custody storage system. This is not an excuse for what happened, but a strongly held belief that we need to use decentralized systems to keep user data secure. We have been serving identity solutions for the web3 space since 2017, and are here to build a better system.

We deeply regret what happened, and we will do our best to protect affected users. We will keep working to finally build a system where this type of breach cannot happen.

Sincerely,

Fractal ID

—

More details on how we secure user data today

Collection and storage

Collection happens on the user’s browser when they input their identity information into our web application. All data in transit is encrypted. We implement HSTS and we keep our CSP rules as tight as possible.

We store our data with Amazon Web Services (AWS) in their Ireland region, and all data at rest is encrypted.

Access

For BI purposes, some employees have read access to some data, that’s neither personally identifiable information (PII) nor secret data (password hashes, MFA seeds, etc). Only specific well trained people are granted PII read access on the database, done on a per-need basis. Only system administrators have access to secret data and full read-write direct database access.

Personal data is only visible in the verification backoffice. Access accounts have to be manually created, they’re password-protected, login is constrained to expected working hours, sessions auto-logout on extended inactivity, we send email login notifications, etc.

Regular accounts are shown no additional user information other than what they need to conduct identity verification, and they cannot retrieve profiles they’ve already reviewed or of other arbitrary users, and all their actions are logged. Search functionality is restricted to a selected group of admins.

Infrastructure

We run our system on Amazon Web Services (AWS). We make heavy use of its services to leverage it as much as possible. Notably, we use:

• Virtual Private Cloud (VPC) to isolate our traffic as much as possible. All inbound and outbound traffic is encrypted and restricted to the minimum possible subset of inbound access protocols.
• AWS Certificate Manager (ACM) to delegate all our TLS certificate management.
• Application Load Balancers (ALB) in order to delegate HTTP networking security and to provide enhanced availability.
• Relational Database Service (RDS) with Multi-AZ deployments, at-rest encryption, enforced TLS connections, and with 35 days retention of daily backups.
• Simple Queue Service (SQS) with all payloads encrypted.
• Simple Storage Service (S3) with server-side encryption.
• Elastic Container Service (ECS) using only Fargate instances.

Using ECS with only Fargate instances buys us some interesting affordances. Namely:

• The software baseline that we need to care about is greatly reduced, since there’s no host system to manage, as this is delegated to AWS.
• Web worker instances only expose their HTTP port, and background worker instances expose no ports at all. This means that no system administrator has access to them, which eliminates any possibility of code or configuration drift.
• If there’s the need for operator intervention, we can bring up ephemeral instances with a public IP and an ssh server. These are spun up on a per intervention basis and spin themselves down after 30 minutes without an ssh session.

We use CloudWatch Logs and Alarms. Logs are kept for 7 days. All systems have relevant metrics monitored with tight thresholds to monitor for unusual patterns. We use Sentry to collect all errors.

Access to our AWS production account requires MFA. We maintain isolated production and testing accounts. Access to the production account is restricted to a small subset of well-trained engineers.