How Kenyan Small Businesses Actually Get Hacked (Nobody Is Burning a Zero-Day on Your Duka)

When a small business gets breached, the story that circulates is always the same: "we were hacked by sophisticated cybercriminals." It is a comforting story because it removes responsibility. It is also, in almost every case I have seen, false.

Nobody is burning a zero-day on your duka. Small businesses get compromised through a short, boring, repeatable chain: a credential that leaked somewhere else, an account with no second factor, an admin panel facing the open internet, and software that has not been patched since installation. That is the whole playbook. The good news buried in that sentence is that a boring attack is broken by boring defence, and boring defence is cheap.

What the data says

The 2025 Verizon Data Breach Investigations Report found that abuse of credentials was the leading initial access vector for the second year running, appearing in roughly 22 per cent of breaches analysed. Ransomware was present in 44 per cent of breaches, and 54 per cent of ransomware victims had their credentials show up in infostealer logs before the attack. Verizon's supplementary research put credential stuffing at about 19 per cent of all authentication attempts on a median day.

Locally, Kenya's National KE-CIRT/CC recorded around 4.56 billion detected cyber threat events between October and December 2025, up sharply from the previous quarter, and pointed to weak system patching, low phishing awareness, and attackers using AI to scale their operations. Not zero-days. Patching and passwords.

The attacker is not clever. The attacker is patient, automated, and working through a list. You are on the list because you have an IP address.

Chain one: the infostealer on the accountant's laptop

This is the most under-appreciated path into a Kenyan SME. Someone downloads a cracked copy of accounting software, a "free" PDF converter, or a pirated Windows activator. It carries an infostealer. Within seconds the malware copies every password saved in Chrome, every session cookie, and every autofill entry, and uploads them. Days or months later, someone buys that log and tries the ERP admin password on your server.

Session cookie theft is the nasty part: a stolen live session can sail past multi-factor authentication because the second factor was already satisfied when the cookie was minted.

What breaks it: no shared credentials, a real password manager instead of browser autofill for admin accounts, short session lifetimes for privileged roles, and a hard organisational rule against pirated software on any machine that logs into business systems. Also: bind admin sessions to a device or IP where your framework supports it, and force re-authentication for destructive actions.

Chain two: password reuse plus credential stuffing

Your customer portal has ten thousand users. A completely unrelated site those users signed up for got breached in 2022. Bots now replay those email and password pairs against your login form at a few requests per second per IP, from hundreds of IPs. A small percentage work, because people reuse passwords.

You will see this in your logs as a flood of POSTs to the login endpoint with a high failure rate and an unusual ratio of distinct usernames per IP.

# Top IPs hitting the login endpoint today
sudo awk '$7 ~ /login/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Failed vs successful logins by hour - a stuffing run has a brutal ratio
sudo grep "POST /api/method/login" /var/log/nginx/access.log \
  | awk '{split($4,a,":"); print a[2], $9}' | sort | uniq -c

What breaks it: rate limiting on the login path specifically, MFA for staff and for any customer account that can move money, lockout or exponential backoff per account rather than per IP alone, and checking new passwords against a breached-password list at signup. Do not silently rely on a WAF alone; stuffing traffic is low and slow by design.

Chain three: the admin panel the internet found in four hours

You spin up a VPS on Friday, install the stack, expose the admin interface temporarily "just while we test," and forget. Internet-wide scanners index the entire IPv4 space continuously. A new open port is typically discovered within hours, not weeks.

What gets found: phpMyAdmin and Adminer, Portainer, Grafana with the default admin login, Jenkins, an unauthenticated Redis on 6379, MongoDB or Elasticsearch bound to all interfaces, .git directories served by the web server, and .env files sitting in a public webroot.

# Am I serving my own source control or secrets? Run this against yourself.
curl -sI https://yourdomain.co.ke/.git/config
curl -sI https://yourdomain.co.ke/.env
curl -sI https://yourdomain.co.ke/backup.sql

# Anything answering the public internet that should not be?
sudo ss -tulpn | grep -v "127.0.0.1\|::1"

Any of those returning 200 is an emergency, and the fix is a deploy, not a discussion.

What breaks it: deny by default at the firewall, admin interfaces behind a VPN such as WireGuard or Tailscale or restricted by nginx allow/deny, no default credentials ever, and a webroot that contains only what you intended to publish.

Chain four: the plugin nobody updated since 2021

A marketing agency built the company website in WordPress three years ago and disappeared. Twenty-two plugins, four of them abandoned upstream. One has a publicly documented authentication bypass with a working exploit in every scanner. The site gets a web shell, which gets used to send phishing mail from your domain, or to pivot to the database that, unfortunately, is the same MySQL instance your ERP uses.

The unglamorous truth is that this is the most common way a Kenyan SME's server becomes someone else's asset. It is not targeted. It is a scanner walking a version number.

# Files modified in the webroot in the last 3 days - web shells show up here
sudo find /var/www -type f -mtime -3 -name "*.php" -printf '%TY-%Tm-%Td %p\n' | sort

# Suspicious PHP patterns
sudo grep -rlE "eval\(|base64_decode\(|assert\(|system\(" /var/www --include="*.php" | head

What breaks it: automatic updates for the CMS and plugins, deleting plugins and themes you do not use instead of deactivating them, separate database users and separate hosts for the marketing site and the business system, and an inventory of every internet-facing application with an owner's name next to it.

Chain five: the invoice that was not from your supplier

Not every loss involves malware. Business email compromise is the highest-value attack aimed at African SMEs, and it needs no exploit at all. An attacker watches a mailbox, waits for a genuine invoice thread, then sends a lookalike message from a domain one character off, asking that payment go to a new bank account or paybill "because of an audit."

Finance pays it. There is no technical incident to investigate because nothing was hacked in the traditional sense. In Kenya this pairs with SIM swap attacks against SMS-based verification.

What breaks it: a written rule that any change of bank or paybill details is verified by phone on a number you already had on file, never a number in the email; MFA on all mail accounts with an authenticator app rather than SMS; SPF, DKIM, and DMARC on your domain so lookalike spoofing is harder; and a payment approval threshold requiring two people.

A one-hour self-assessment

Answer these honestly. Every "no" is a link in a chain someone will eventually pull.

Question	Chain it breaks
Does every admin have MFA that is not SMS?	One, two, five
Are any admin panels reachable from the public internet?	Three
Do you know every internet-facing app and its version?	Four
Is there any shared login used by more than one person?	One, two
Is the login endpoint rate limited?	Two
Do bank detail changes require an out-of-band phone check?	Five
Have you restored a backup in the last 30 days?	All of them
Do you keep 90 days of access and auth logs?	Detection

Detection: knowing before the customer tells you

The other half of the problem is time. Attackers often sit inside for weeks. You do not need a security operations centre to shorten that. You need three cheap signals with alerts wired to a phone.

• Successful admin logins from new locations. Log them, alert on them. A login from an unfamiliar network at 03:00 is worth a text message.
• Unexpected file changes in the webroot. A nightly find -mtime -1 emailed to you is primitive and catches real web shells.
• Outbound traffic anomalies. A server that suddenly sends 40GB out, or starts talking SMTP when it never did, is telling you something.

# Cheap nightly integrity signal via cron
0 2 * * * find /var/www -type f -mtime -1 \
  | mail -s "Changed files on $(hostname)" ops@yourcompany.co.ke

The uncomfortable conclusion

If you are waiting to invest in security until you can afford a proper security team, you have misread the risk. Nothing in the five chains above requires a security team to defend against. It requires MFA, a closed firewall, current software, unique credentials, a tested backup, and one written rule about payment changes.

And if the worst happens anyway, remember that Kenya's Data Protection Act gives you 72 hours from becoming aware to notify the Data Commissioner where personal data was accessed and there is a real risk of harm. The businesses that survive that week are the ones who already knew where their logs were, who had encrypted their data at rest, and who had written the notification template before they needed it. That preparation is also boring. It also works.