Here is the uncomfortable truth about data centre attacks: most of them are boring from the inside, and the dangerous ones are silent. The movies show sirens and code scrolling. Reality shows a threshold crossed on a graph at 03:14, a guard reviewing a badge log, or, in the worst cases, nothing at all until a customer asks why their files open in notepad.
This article walks five realistic attack scenarios through a Kenyan data centre, one at a time. For each: how it unfolds, who notices and how fast, what the response looks like, and what tenants would actually feel. The scenarios are composites built from documented Kenyan incidents and standard facility operations, and the detection mechanics described are what separates a professional facility from a server room with a lock.
Scenario one: the flood on the shared pipe
How it unfolds. At 03:14 on a Sunday, traffic hitting the facility's edge triples, then multiplies. It is a distributed denial of service attack of the kind Anonymous Sudan rained on Kenya's government platforms in July 2023, and the facility's shared upstream links are filling with junk.
Who notices, and when. Everyone who is watching, immediately. Bandwidth graphs cross alarm thresholds within minutes; the network operations centre gets a pager alert; upstream providers' engineers start seeing the same flood from their side. This is the loudest attack class in existence. If anything, the risk is the opposite of silence: the noise drowns legitimate alerts.
The response. The NOC calls upstreams to confirm scrubbing is engaged, verifies that customer prefixes are being announced correctly, watches filtering take the junk out upstream, and communicates status to affected tenants. Within an hour the flood is usually still visible on graphs but no longer a customer problem.
What tenants feel. Brief slowness, or nothing. The July 2023 national attacks showed the difference infrastructure makes: platforms with upstream filtering degraded gracefully while unprepared services went dark (BBC, 28 July 2023). At a well-connected facility, a DDoS is a Tuesday.
Scenario two: the defacement that goes public first
How it unfolds. An attacker finds an unpatched admin panel on a public-facing web property and swaps its homepage for a message and a ransom demand, exactly as happened to president.go.ke in July 2026, when five Bitcoin was demanded and the site was defaced with an anti-government message (The Record, 21 July 2026).
Who notices, and when. Sometimes the public notices first. A defacement is designed to be seen; screenshots spread before the webmaster's coffee loads. Monitoring that checks page content and integrity flags it within minutes, but the embarrassing detection channel is a journalist's phone call.
The response. Take the property offline, preserve logs as evidence, restore from a known-clean backup, patch the entry point, and reopen. The presidency's site was restored within about two days, which is the right shape: offline fast, back clean, investigate in parallel.
What tenants feel. Nothing at all, if the defaced property is not theirs. That is the quiet danger: defacement of a shared management interface or the facility's own website can be the visible tip of a deeper intrusion, which is why a professional response treats the defacement as evidence, not just an embarrassment.
Scenario three: the ransomware that encrypts a tenant's world
How it unfolds. A tenant's administrator opens a phishing attachment on a Tuesday. By Thursday, the attacker has the tenant's VPN credentials, has spent two nights mapping the network, and begins encrypting every file server and backup the tenant owns. The data centre itself is untouched; the disaster is entirely inside the tenant's environment.
Who notices, and when. The tenant notices first, when files refuse to open, often days after the intruder got in. The facility's monitoring sees perfectly healthy infrastructure: power stable, cooling stable, network forwarding normally. A compromised virtual machine may only surface as odd traffic patterns, if the facility inspects tenant traffic at all, which most colocation providers deliberately do not, because tenant traffic is tenant business.
The response. The facility's role is containment support: freezing the tenant's access if asked, providing traffic captures, connecting the tenant to the incident response team, and handling its own perimeter so the attacker cannot pivot into shared services. The tenant's role is recovery: isolate, restore from offline backups, rebuild, and meet its own notification duties.
What tenants feel. Everything, if it is their environment. This scenario is also where the facility's contract terms matter: who responds, who is liable, what remote hands cost at 4am, and whether the facility can help or only watch. Ransomware is the clearest reason the split of responsibilities must be understood before the incident, not during it.
Scenario four: the insider who never trips an alarm
How it unfolds. A person with legitimate credentials, a contractor, a junior administrator, a departed employee whose account was never disabled, starts querying data they do not need for their job. Nothing crashes. No graph moves. Over weeks, sensitive records quietly leave.
Who notices, and when. Possibly nobody, ever, unless three specific things exist: logging of what accounts touched what, a baseline of normal behaviour to compare against, and a human who reviews the exceptions. This is the attack class that detection infrastructure exists for, because it defeats every other control. Kenya's registry breach of January 2025 showed how valuable bulk records are; insiders know better than anyone which databases hold them.
The response. Disable the account, preserve the logs, scope the access with forensic help, and start the legal clock. Here Kenya's frameworks bite: the Computer Misuse and Cybercrimes Act 2018 covers unauthorised access by insiders, and the Data Protection Act 2019 imposes notification duties when personal data is exposed (Bowmans, 23 January 2024).
What tenants feel. Usually nothing, until the report lands, which is exactly what makes this scenario expensive. Trust is the control here, and trust is built from least-privilege accounts, door logs, escort policies and audits that happen when nothing is wrong.
Scenario five: sabotage at the cooling plant
How it unfolds. Someone with access to the plant room stops the chillers, or a compromised building management system ramps cooling down while reporting everything normal. In a packed hall, air temperatures climb; server intake goes hot; thermal protection starts throttling and shutting hardware within minutes.
Who notices, and when. The building management system alarms on temperature and equipment state within minutes, if its sensors are independent of the system being manipulated, and that "if" is the entire security lesson of the scenario. Environmental monitoring is a security control, not just an operations tool; a facility whose alarms can be silenced from inside the system they watch is a facility trusting its attacker's politeness.
The response. Operators confirm physically at the plant, start the recovery sequence, and treat it as a deliberate act until proven otherwise, which means access logs, CCTV review and police involvement. Generators and UPS systems ride through the electrical side, but no UPS cools a hall; the cooling chain is its own availability story.
What tenants feel. A hot aisle, then emergency shutdowns if the event outruns the response. Well-run facilities document maximum hang times and automate the shutdown sequence so hardware survives the event cleanly. Sabotage is rare, but Kenya's 2023 attacks proved that determined opponents will aim at whatever hurts most, and for a data centre, cooling is second only to power.
So, would we notice?
Score the five scenarios on noticeability: the flood, minutes; the defacement, minutes to hours, possibly by the public; the ransomware, days, by the tenant; the insider, maybe never; the sabotage, minutes, if the sensors are honest. The pattern is the answer to the question in the title. You notice exactly the attacks your instrumentation is built to notice, and nothing else.
That is why serious facilities converge on the same kit: 24/7 eyes on correlated logs from firewalls, badge readers, CCTV and building systems; thresholds and baselines tuned so anomalies surface; rehearsed response plans with phone numbers, not just policies; and reporting lines to KE-CIRT/CC and the data protection regulator that are practised before they are needed. Kenya's national response team detects hundreds of millions of threat events per quarter, most of them automated and unremarkable, and the reason that number does not translate into national outages is exactly this: detection, layered deep, with humans behind it.
The most realistic danger in Kenya is not the attack nobody can stop. It is the attack nobody was watching for, in a building whose staff mistook silence for safety.