Nigerian financial institutions are under attack

Over the past week, we at Lendsqr have watched a sustained wave of attacks on Nigerian financial institutions. Several banks, fintechs and lenders are being targeted at the same time, and the patterns are consistent enough that we think they are worth acting on now. On 6 November, we sent a security advisory to security teams across the industry. This post shares that advisory publicly, so that anyone can check their own environment against it.

Sharing this does not mean we are perfect. We have been targeted too, and we have had to fix things along the way. We are sharing because disclosure helps everyone, and silence only helps the attackers.

These attacks are often prepared and launched on Fridays and over weekends, when teams are thin. Stay alert, especially at weekends, and hold people accountable.

What is going on

There is a sustained wave of attacks on Nigerian financial institutions, and most of the industry is staying quiet about it. Our CEO has written about it publicly here: Lendsqr is battling a wave of cyberattacks, and I’m done keeping quiet about it. Condia also covered it: Nigerian financial institutions face cyberattacks as industry remains largely silent.

The attack patterns

• Leaked developer tokens. Old GitHub personal access tokens committed into code years ago are being used to force-push malicious loaders into repositories, so that the next CI build or developer checkout runs them. The loader hides in build scripts and config files, and calls home to a command-and-control server.
• Phishing through hijacked email-provider accounts. Lures are sent through compromised SendGrid customer accounts, so they pass email checks, and point to fake SendGrid login pages (client-sgportal[.]com and consult-sgportal[.]com). They steal logins, 2FA codes and API keys, so the attacker can take over a company’s email sending and phish its customers. The pages show nothing unless you arrive with the token from the email, which is why automated scanners miss them.
• Admin login spraying. One server cycles through a list of admin accounts across many organisations every few seconds. Account lockout stopped it.
• Scripted API probing. Receipts, password resets, webhooks and payment links are being tested for anything that leaks data or moves money.
• Industrial-scale hunting for secret files. Every hour, dozens of cloud servers, mostly on Google Cloud, request .env files, .git folders and cloud credential files across every public site. Between the afternoon of 5 November and the afternoon of 6 November, we blocked 213 of them.
• Mule accounts with impossible account numbers. At some banks, the all-zero account number 0000000000 passes name enquiry and returns a real account name, so money can be sent to it. Attackers are routing stolen funds to these accounts. Some of the names returned match people who have previously been charged by US law enforcement for laundering scam proceeds.

What we suggest you check today

• Block transfers and payouts to 0000000000 and other obviously invalid account numbers, and look back for any recent payouts to them.
• Scan every repository, including history, for committed tokens and keys. Revoke them, block force-pushes on protected branches, require reviews, pin GitHub Actions to exact versions and make workflow tokens read-only.
• Make sure no .env, .git or credential file is reachable on any public site, and block the scanners at the edge.
• Lock down the email-sending accounts (SendGrid and others): 2FA, rotated API keys, and alerts on new senders or unusual volume.
• Check admin login logs for one address failing across many accounts, and make sure lockout is on.
• Check the indicators below against your logs and block what fits.

Indicators of the targeted attacks

Addresses are broken up with [.] so they don’t turn into links.

Address	Network	What it did
103.151.172[.]0/23, including 103.151.172[.]31 and 103.151.172[.]84	AS134972, Hong Kong hosting	Admin login spraying: 60 attempts on 11 admin accounts in 48 minutes (3 Nov), plus earlier visits to customer payment pages.
18.182.61[.]18	AWS, Tokyo	Scripted API probing (2 Nov): receipt PDFs, admin password-reset emails, forged webhooks, payment links.
142.249.39[.]80	AS153371	Same campaign: customer onboarding attempts (2 Nov).
66.55.76[.]127	US	Used a leaked GitHub personal access token to force-push malicious code into source repositories.
95.135.181[.]151		Command-and-control server for that malicious loader (ports 80 and 443).
102.244.78[.]57	Orange Cameroun	Hands-on probing of a dormant business account (4 Nov): admin password-reset emails, login guesses, endpoint guessing.
155.138.236[.]211	Vultr	Same actor as above, same short user agent.
147.161.247[.]9	Zscaler (shared proxy, do not block the range)	Same actor as above.
141.11.146[.]78, 223.91.198[.]216, 103.42.183[.]18, 38.91.101[.]149, 43.243.192[.]91	Various	Linked attacker addresses from 2 to 4 Nov.
181.215.186[.]252	AS209630	Secret-file scanning across public sites (5 Nov), 8,224 requests in 3 hours.
91.239.78[.]39	AS6698, Kyiv	Secret-file scanning (4 to 5 Nov), came back after first being blocked.
Networks	AS134972, AS24445, AS62468	Blocked in full because of repeated attacks from them.

Beyond these, we have blocked 238 automated scanners since 5 November: 156 on Google Cloud, 27 on DigitalOcean, 15 on Microsoft Azure and the rest spread across smaller hosting networks. Security teams that want the full list can write to [email protected].

Phishing infrastructure

• Phishing domains: client-sgportal[.]com and consult-sgportal[.]com, both registered on 2 Nov 2026 through Dominet (HK). The credential collector is client-sgportal[.]com/api.
• Lures sent through SendGrid accounts 8916641 (sending as noreply[@]dmsiworks[.]com, subject “New contacts export request”) and u51909559.

What we have done at Lendsqr, and what we recommend

• Do VAPT (vulnerability assessment and penetration testing) like your life depends on it. Do not stop at black-box tests, where the testers know nothing about your systems. Do white-box tests too, where they can see your code and configuration, because that is where the deeper problems show up.
• Use outside testers, independent of your own team and your usual vendors. Hinoki Security works: for about $20 to $30 it did a deep and very solid review of our internet-facing systems, and found real issues that we have since fixed.
• pwn.ai is another option we have seen. It runs autonomous, AI-driven penetration tests and costs about $3,000 to $6,000.
• For a hands-on engagement with experienced testers, we also recommend Technology and X (technologyandx.com) and Vendetta Security (vendetta.ng), who are carrying out our own vulnerability assessment and penetration testing.
• Scan and audit every single day. What worked yesterday might not work tomorrow.
• Test your people for social engineering on a continuous basis, almost every week, to find the weak links. The aim is not to catch people out or call them careless. It is to make everyone aware of how these attacks work.
• Hold a compulsory all-hands security session. At Lendsqr, everybody had to attend, and we walked through what is happening and what each person must do. Larger companies can split it into groups, but it should not be optional for anyone.
• Keep your staff informed. Every couple of days, we send all employees an update on what is happening in the market. When a story is only alleged, we say so, but we treat it as true until it is proven wrong. That level of paranoia is what keeps people alert.
• Filter traffic at the edge and stop the scanners there, before they reach your servers. We use Cloudflare, with rules that block known attacker networks, regions we do not serve, and anyone asking for secret files.
• If you are on Cloudflare, pay for Enterprise. It is worth it for the extra tools it gives you to see and stop attacks.
• Block and report automatically, with no person involved. Every 15 minutes, our systems find any address hunting for secret files or using attack tools, block it across all of our domains at once through Cloudflare’s programmatic access, and email the abuse team of the network it came from with the evidence. Cloud providers act on these reports; Amazon Web Services has opened cases from ours.
• Report every attacking address to AbuseIPDB (abuseipdb.com) automatically, so that other companies’ firewalls can block it before it reaches them. We already do this for every address we block, and we have reported every attacker we have seen since 5 November. From the weekend of 7 November, we will also send a daily report to ngCERT, Nigeria’s national computer emergency response team.
• Put admin screens behind an extra sign-in layer, so a stolen password alone is not enough.
• Rotate keys and tokens, turn on two-factor sign-in everywhere, and remove access for anyone who has left.
• Set every domain that sends no email to reject all email in its name, so nobody can fake it.
• Keep your internal domain a secret. Run internal services on a separate domain that is never your public company domain and never mentioned outside. Staff reach it only through your own internal DNS, never public DNS, so outsiders cannot map it or imitate it. We made some mistakes here ourselves, and we are cleaning them up.
• Lock server logins and internal tools to your VPN. We moved server logins and several admin consoles so that they only answer from our VPN, not from the open internet.
• Remove DNS records for services you no longer use. An old record that points at a cancelled service can be claimed by someone else and used to host a page under your name. We found and removed several.
• Report phishing sites the moment you find them, to whoever hosts them and to Netcraft, so that browsers start warning people. We did this for the fake SendGrid pages above, and both are now flagged.

If your team would like hands-on help with any of this, our engineers can take a look with you as paid work. Write to [email protected].

Security starts with you

Many of the senior people we have spoken to keep talking about politics, and some do not want to do anything. We should stop pretending that somebody else has to act first. Security starts with you. When you have done your part, then you can look at who else should have done theirs. Waiting for the central bank, the police or an industry group to do something is counterproductive.

The most important tool: speaking up

Above all, report the bad things you see, in a way that does not compromise your own position. We understand why it can be hard to speak up. Sometimes it is confidentiality, sometimes plain shame, and sometimes not knowing how it happened at all. But silence is what lets the same people use the same tricks on the next company. Speaking up is how we protect each other.

Please share this as widely as you can

You never know who this could help. When we sent the advisory, we sent it to every developer who has ever worked with us, whether as staff, contractors or friends of the house, because the earlier people see it, the better. This wave is global, so please send it to your friends in other countries too. Please also make sure it reaches your regulators, so they can guide the industry on what to do without causing panic. We have also spoken with industry leaders and with people at the Central Bank of Nigeria to spread these stories, because sharing them is the best way for all of us to stay protected. We have also written to our customers with the steps in this advisory.

If you have information that can help others, please share it, and let’s protect the market together.