Brute-Force Handler Drowning a Real Compromise

The event log for each FortiGate carries admin authentication records with fields such as logdesc, action, status, user, srcip, method and, for successful logins, the assigned profile. The timeline is reconstructable:

• Repeated failed logins from 10.20.30.41 during business hours at regular intervals, all with the same source, no successful login following them. This is scanner behaviour: high volume, fixed cadence, known owner.
• At 02:14, five or more failed logins from 185.220.101.44, an address outside any corporate range, at an hour when no administrator works, followed by a successful authentication from the same address. That success is the pivot the process missed.
• Shortly after, configuration-change entries in the event log showing an admin account being created or modified, with the change attributed to the compromised administrator session, and the new account svc-backup2 appearing.
• Possibly further entries showing policy, address or admin-trust changes made by that session.

The failure was not detection capability, it was detection design. The handler counted only failures and had no follow-on rule for a successful login from an untrusted source, no rule for local administrator account creation, and no correlation between the two within a short window. Auto-closure treated all matches as equivalent, so volume noise was the only prioritisation signal available. Combined with an internet-exposed management interface and no trusted hosts, a single successful guess became an unmonitored administrative session.

Start from the principle that suppression should remove known-benign sources, not whole event classes.

• Keep a handler for repeated failures, but add a source-IP exclusion list that contains the authorised scanner range, owned by the network team and reviewed quarterly. The handler then still fires for any other source.
• Add a separate high-severity handler for a successful administrator login from an address outside the corporate ranges and outside approved jump hosts. This is the alert that would have fired at 02:15.
• Add handlers for local administrator account creation, modification and deletion, and for changes to admin trusted hosts, profiles and authentication settings.
• Add a proximity rule: successful login within 30 minutes of failures from the same source, regardless of source, scored higher than either event alone.
• Route alerts to a queue with explicit ownership and a no-auto-close rule for the high-severity handlers; auto-close only the low-severity noise handler and require a reason code.
• Tune at the source as well: the scanner should not be generating FortiGate admin failures at all. Give it a dedicated account with a narrow profile and apply local-in policy or trusted hosts limiting management access to the management VLAN and jump hosts, which also removes internet exposure of 8443.

Validate the redesign by replaying the last 90 days of logs against the new handlers and confirming both that the historical compromise is caught and that the daily alert volume falls to a workable level.

Order matters because containment can destroy evidence.

1. Preserve first: export the relevant FortiAnalyzer logs for the affected device for the preceding 14 days to read-only storage, and take a full config backup including the revision history. Record analyst actions in the ticket with timestamps.
2. Contain the source: block 185.220.101.44 at the edge and on the FortiGate, and check whether the same address appears against other customer devices in the shared platform. This is an MSSP, so assume shared infrastructure and check all ADOMs.
3. Lock the door: disable or delete svc-backup2, force password resets for all administrator accounts and any LDAP or RADIUS service accounts used for admin login, and enable trusted hosts or local-in policy so management is reachable only from approved networks. Remove the internet exposure on 8443.
4. Scope the damage: diff the FortiGate config against the last known-good FortiManager revision to find every change made after 02:14, including policies, address objects, admin users, and logging or syslog-forwarding changes. Attackers commonly alter logging first.
5. Check for persistence: look for additional local accounts, API tokens, automation stitches, and any scheduled scripts or one-time schedules, all of which can outlive a password reset.
6. Verify logging integrity: confirm the device is still sending logs and that the syslog or FortiAnalyzer configuration has not been redirected or disabled.
7. Recover and report: rotat credentials, confirm no anomalous sessions remain, document the timeline and root cause, and set a follow-up to verify the new detection content actually fires.