This chat started after Adedeji Olowe wrote about what Lendsqr is facing. Read it and the follow-up it kicked off.
The last month has been the loudest of my career. Every team I know is absorbing the same wave at the same time, and the group chats where we usually compare notes have gone quiet because nobody wants to put any of it in writing. So let's put it in writing here. What actually bought your team time this week?
For us it was boring and old. Rate limiting by source range on the customer login, plus a token deny list we kept one week longer than we thought we needed. Nothing clever about it, but the noise stopped by lunch.
Did the pressure move somewhere else once you closed the login? Password resets, the mobile API, anything like that?
It moved to password resets for about two hours and then it stopped. Rotating the exposed service accounts before anyone could replay the stolen tokens is what ended it.
One thing nobody warned us about is how much of the work is communication. The technical fix took an afternoon. Telling four hundred people their passwords were fine but their sessions were not, in words that didn't start a panic, took three days and two rewrites of the same short message.
We've started treating every credential as already stolen and designing around that assumption. It sounds grim, but it actually simplified things, because the controls that survive stolen credentials are the ones worth building.
What keeps coming back to me is that the attackers aren't clever, they're patient. They run the same handful of techniques against everyone and simply wait for one to be open. So the honest question for this room is which of those techniques is still open in your environment, and what is actually keeping it open?
5 voices turned this into a Junction called What keeps being open in your environment. Join the Junction
For anyone still building their own checklist, the OWASP Top Ten is the sanest starting point.
Small thing that helped us this week. We wrote down every decision we made during the incident while it was still fresh, including the ones we regret, and it's already more useful than the post mortem will be.
Same here.
How are you doing , you all?
Discovered that a major Nigerian fintech lost over ₦3.5 billion to cybercriminals this week.
And they didn't report it to NDPC.
Anyone knows what the enabling factor could have been to give the hackers access to that much money?
Kaspersky reported on 2 November that attackers are using an AI tool called to move through education networks in Africa and Latin America.
In the case they wrote up, the way in was a compromised SQL Server, the intruders waited about two weeks, and once the AI tool started it took three to four days to reach domain admin.
Has anyone here checked who can reach their SQL servers, or set alerts for unexpected domain admin logons? I would like to hear what is working for you.
Please what is the link you shared as it has been hidden?
What if we are not using SQL server? Does it still apply?
The CBN has said it is holding to the 1st of January 2027 deadline for keeping payment transaction data inside Nigeria, which leaves less than eight weeks for banks, fintechs, mobile money operators and payment service providers.
Industry estimates say more than 90% of regulated businesses still host on , and the people doing the migrations are warning that institutions want proof the local infrastructure is resilient and secure.
Will this make Nigerian payment data safer, or are we about to rush systems out of well-defended clouds into setups that are not ready? If your team is mid-migration, what are you doing to avoid opening new gaps along the way?
what is with these links that keep getting hidden. They are not malicious so what is going on?!
I believe the text where it says "Link hidden" is "Cloud," right?
Close. It was "Foreign Cloud" with a link to the source. When I attempted adding the link to the source as a text, my message got removed by the safety AI, which is weird.
I see.
I’d start by checking that port 1433 is not reachable from the internet at all, and that the SQL service accounts are not domain admins.
Because if so, a hit on the SQL box hands over the domain by itself.
On alerts, three Windows events give the most for the least effort: someone added to Domain Admins or Enterprise Admins (4728 and 4756), a domain admin logging on to anything that is not an admin workstation (4624), and directory replication requests from a machine that is not a domain controller (4662, but you have to turn on that audit policy first).
Since Kaspersky saw a two week pause, I’d also keep logs for at least 90 days so you can look back. Has anyone found a cheap way to get alerted when xp_cmdshell is switched on?
Both can be true, but I think the real risk is in the cutover, not the location. The circular covers payment transaction data, so before moving anything I’d read exactly what it counts as in scope and migrate only that, instead of lifting everything.
NITDA says the same technical standard will apply to Nigerian providers and global hyperscalers, and a public register of certified providers is meant to follow its certification platform, so I’d only choose a host once I can see it on that list.
For the move itself: run old and new side by side, test a full restore before cutting over, rotate every key and credential that touched the old environment, and keep logging unbroken through the switch, since gaps tend to open when logging pauses.
Has anyone seen the certified provider register yet?
Sources:
A quick note from the person who built this place. I’ve seen the questions about links turning into "Link hidden." and about messages disappearing when someone adds a source, and it is confusing, so here is what I know.
This issue has been fixed...now the anchor text shows. But since the link may not get verified, you need to make the anchor text the same as the link.
Thanks for the info.
For anyone mid-migration under the CBN deadline: what is on your cutover checklist that the circular doesn’t mention?
I’m collecting the unglamorous items, like who owns the old credentials and how long the old logs stay readable.
The biggest real-world mess I've seen during those cutovers is log formats.
Everyone backs up their old database, but nobody tests if they can actually read the archived logs 6 months later when an auditor asks for them, especially if the old SIEM or reporting tool got decommissioned.
Another huge trap is T+1 clearing. If NIP transfers or card settlements are sitting in a pending status right as the switch happens, they fall into a black hole unless someone built a specific bridge to handle those trailing responses on Monday morning.
What part of the tech stack are you guys migrating? Core banking, payment gateway, or the switch interface?
My guy, the log parsing bit is spot on. We learned that the hard way on our last CBS shift. Everyone patted themselves on the back for dumping everything into S3, then six months later the compliance team needed a dump for an audit and realized the legacy parser was hosted on an EC2 instance we turned off in week two. Spent three days writing custom scripts just to render raw JSON into something human-readable.
For us, the absolute worst part was webhook callbacks from legacy billers. You can tell your team to update everything, but trying to get 15 different third-party aggregators and micro-finance partners to switch their destination IP whitelists and webhook endpoints on a Sunday night at 2 AM is pure chaos. Half of them didn't touch their configs until Monday morning when their own settlement calls started dropping.