Coordinated SSH Brute Force Attacks in UAE

What coordinated means in practice

A single machine hammering port 22 gets blocked in minutes. Modern SSH brute force campaigns do not work that way. The operator rents or builds a botnet, loads it with a target list and a credential list, and lets each node make a few attempts per day. Ten attempts a day from ten thousand nodes is a hundred thousand guesses against your estate every day, and no individual source ever crosses the five-failures threshold that fail2ban or your firewall watches for.

The credential lists are not random. They combine breach dumps, default vendor credentials, and username patterns harvested from LinkedIn and mail headers. Password spraying is the common variant: one plausible password tried against many accounts, which also sidesteps account lockout policies.

Timing matters too. Serious campaigns run for weeks at low intensity, precisely because slow and quiet beats fast and loud. If your detection logic looks for bursts, a campaign that never bursts is invisible.

Why this lands on UAE banks

Not because attackers hold a grudge against the region. Banks run large Linux estates: payment middleware, integration servers, jump hosts, appliance underlays, and a long tail of vendor-managed boxes. Internet-wide scanning is cheap and constant, so any SSH service that faces the internet is found within hours of going live, and every found service gets fed into someone's target list. Whether it then falls depends on three things: is password authentication enabled, is the credential guessable, and does anyone review the logs.

In my experience the weak point is rarely a tier-one production system. It is the forgotten box: the file-transfer server a vendor stood up during a migration, the monitoring VM still on its default login, the DR replica nobody patched. Inventory failure, not cryptographic failure, is what turns background internet noise into a breach. It is also what a decent external assessment surfaces first; mapping exposed management services is a standard early finding in the VAPT engagements I scope for regional organisations.

Regulatory pressure raises the stakes rather than the difficulty. CBUAE assessors expect evidence that remote administrative access is controlled and monitored. An SSH service open to the internet with password authentication is the kind of finding that turns a routine review into a remediation programme.

Why per-IP defences fail

Fail2ban, firewall rate limits and geo-blocking all key on the source address. Distributed campaigns are built against exactly that. Each node stays under the ban threshold. Rotating residential proxies give the operator clean IP space, including UAE address space, so blocking foreign ranges achieves little beyond locking out your own travelling admins.

These controls are still worth running. They strip out unsophisticated noise and keep your logs readable. But treat them as hygiene, not as the control that protects the asset.

Hardening that removes the attack class

Brute force only works where there is a password to guess. The strongest response makes the whole technique irrelevant:

• Set PasswordAuthentication no and PermitRootLogin no in sshd_config, everywhere, and verify it with configuration scanning rather than trusting the build document.
• Use key-based authentication as the floor and short-lived SSH certificates as the target state. Certificates expire on their own, which solves the key sprawl that plain authorized_keys files create.
• Remove direct internet exposure. Administrative SSH belongs behind a bastion or a ZTNA gateway with MFA at the front door. If a partner genuinely needs inbound SSH, allowlist their source addresses and put an expiry date on the rule.
• Route privileged sessions through a PAM platform so credentials are vaulted, sessions are recorded and access is time-bound. This is the control assessors ask about by name; the practical options for the region are on the privileged access management page.
• Changing the port from 22 reduces log noise and nothing else. Do it if you want quieter logs, but never count it as a control.

Service accounts deserve their own pass

Spraying campaigns hit service accounts hardest because they have predictable names, old passwords and no MFA. Inventory them, move them to keys, and alert on any interactive login by an account that should only ever run batch jobs.

Detection: aggregate by target, not by source

This is where most SIEM deployments miss. The default dashboards group failed logins by source IP, which is exactly the dimension a distributed campaign randomises. The signal lives on the other axis: failures per target account and per destination host, across all sources, over a long window.

The queries worth building:

• Failed SSH logins per destination host over 24 hours, trended across weeks. A slow rise is a campaign.
• Distinct source IPs per targeted account. One account receiving failures from four hundred sources is not a typo problem.
• Invalid-user failures, which reveal the attacker's username list and often identify the campaign family.
• The one that matters most: a successful login on an account or host that recently accumulated distributed failures. That single event is your incident, and it is easy to lose in the noise if nobody built the correlation.

This is standard correlation work on any serious platform. On FortiSIEM, which I run in production, the aggregation rules take an afternoon to build and tune; the harder job is making sure every Linux host actually forwards its auth logs. Gaps in log collection are the most common reason these campaigns go unseen.

When a login succeeds

Treat any authenticated session that follows a spray pattern as a confirmed compromise, not a curiosity. The immediate steps:

• Terminate the session, isolate the host if it touches anything sensitive, and preserve auth logs and shell history before they rotate.
• Check for persistence: new entries in authorized_keys, new local users, modified cron jobs, unfamiliar systemd units.
• Rotate the compromised credential and every place it was reused. Assume reuse until proven otherwise.
• Look outward from the host. known_hosts entries, stored keys and internal reachability tell you where the attacker could go next; lateral movement from an unimportant box to an important one is the actual damage path in these incidents.

If your team would be improvising those steps under pressure, write them down now. A working incident response plan that names owners and thresholds is the difference between a contained event and a reportable one.

Three questions to answer this week

1. How many SSH services does your organisation expose to the internet, and can you produce the list in under an hour?
2. Does any of them accept password authentication? If you do not know, the answer is yes.
3. If a spray campaign started against you today at ten attempts per source per day, would anything alert? If your detection keys on source IP, the honest answer is no.

Answer those three and you have done more against coordinated SSH brute force than any amount of perimeter spend.