In Part 1, I wrote about what happened on 9 August 2025 — the ransom note in the database, the team that gave up their National Day to come back to the office, the customers calling a hotline we could barely keep up with, and the fear that gripped me for days after.
This is Part 2. What we found out. What we did. What we are still doing.
I want to be honest from the start: we do not have a clean story where we discovered the problem, fixed the gap, and declared ourselves secure. It is messier than that. But I think the messy version is more useful to anyone reading this than a polished one.
What the Investigation Found
After the attack, we engaged cybersecurity experts and reported everything to the police. SingCERT was notified. A forensic investigation was conducted.
The forensic report was not conclusive. SingCERT has not yet provided a definitive finding. This is something I had to accept: sometimes you do not get a clean answer. The breach happened, the damage was real, but the exact entry point remains unknown.
What the police did find in the server logs was access from an IP address linked to a university associated with a threat group called UNC3886.
If you have not heard of UNC3886, they are not a group of opportunistic criminals looking for easy targets. They are a sophisticated, state-linked threat actor known for targeting enterprise systems across the region. OT-ISAC has specifically warned Singapore’s critical infrastructure about this group.
How exactly they got in, we still do not know. The forensic report was not conclusive. The investigation is ongoing. We may never have a definitive answer.
What I can say is this: before the attack, we were not careless. We had two-factor authentication and SSH access to our servers — no username and password login. We ran annual penetration tests by a third party. We thought we were reasonably protected.
We were still hit. I am not saying this to excuse anything. I am saying it because Singapore businesses need to understand that a sophisticated attacker does not always need you to make a mistake. Sometimes the door you thought was locked simply was not enough.
What the POS Was Actually Doing While the Backend Was Down
One thing I want to clarify from Part 1: our POS system did not go completely dark.
Because it is designed to run offline, merchants on Jade POS could still process orders, print receipts, and run their kitchen operations throughout the incident. What they lost was anything that required the server — updating menus, pulling reports, doing their z-reading at end of day. The local database kept running, and it would have continued running for an extended period without syncing to the cloud.
The harder impact, as I described in Part 1, was on our kiosk and QR ordering customers. Those systems depend on the backend. That is what we are now working to change.
What We Did Immediately
Once the systems were restored and we had space to think, we went through everything methodically. Here is what was done:
Whitelist database access to our office only. Previously the database had broader access. It is now locked down to our office IP. No external access.
Delete and reissue all SSH keys. Every key used to access our servers was revoked. New keys were issued to the people who need them.
Patch everything. The server operating system, the web server, the database version — all security patches applied. This should have been a routine process. We have now made it one.
Restrict firewall traffic to countries where we have customers. Traffic from anywhere outside our operating markets is now blocked at the firewall level.
Delete all users and reprovision from scratch. Every user account on our systems was removed and rebuilt. No legacy access, no forgotten accounts, no accounts that outlasted the people who held them.
Replace open third-party API access with SSH. We had open API connections with some integrations. These have been closed and replaced with SSH, which is more controlled and auditable.
None of these are exotic measures. They are disciplined ones. In the aftermath of an attack, you realise how many small gaps accumulate over time — not from negligence, but from the normal pace of running a company where the urgent always pushes out the important.
From Protection to Business Continuity
The immediate security fixes were necessary. But as we worked through the recovery, our thinking shifted.
We had already tried to protect ourselves — 2FA, SSH, annual pen tests. It was not enough. Spending the next year only on more protection felt like fighting the last war. What we really needed to ask was a different question: if this happens again, can our merchants keep their businesses running while we recover?
That shift — from protection to business response and business continuity — is what shaped everything we built next.
Kiosk now runs offline. In the attack, our kiosk customers were the worst hit because the system required a live backend connection to function. That has changed. Kiosk can now operate offline, the same way Jade POS always could. A restaurant can keep taking orders, printing receipts, and running their kitchen even if our servers are unreachable.
QR ordering now reads from a read-only database. We rebuilt the QR ordering architecture so that it reads menus and serves orders from a separate read-only database. The write layer is isolated. This means that even if the primary backend is compromised or unavailable, QR ordering can continue serving customers from the read-only replica. The attack surface is smaller and the resilience is higher.
Failover is in place. We have built failover into the system. If the primary goes down, traffic routes automatically. This is the infrastructure change I am most proud of — not because it is impressive on paper, but because it is the direct answer to the question that kept me awake: what happens to our merchants if this happens again? The answer now is: they keep running.
Incident communication plan. When the attack happened, we had no playbook for how to communicate with customers — what to say, in what sequence, through which channels. We improvised, and it showed. That plan now exists. When something goes wrong, the first call does not have to be the first time we think about what to say.
Regular scheduled downtime for security patches. Patches should not pile up. We now have a maintenance window so that updates are applied consistently and merchants know in advance when brief downtime will occur.
What This Does Not Mean
I want to be clear about what I am not saying.
I am not saying we are now secure. Security is not a destination. No combination of measures fully protects you against that.
What we have done is reduce the surface area. Limit access. Build in more resilience so that when — not if — something happens again, the damage is smaller and the recovery is faster.
That is the honest version of what “we fixed it” looks like.
One Year On
The fear has not completely gone away. I do not think it will. But fear without action is just suffering, and we have spent the past year acting.
If you are a F&B business operator or a technology company reading this: review your access controls, apply your patches, think about what happens to your operations when your backend goes offline. And if you have never thought about business continuity plan, start today.
We are still here. Still building. Still grateful for the team and the customers who stayed.
