Detecting T1110 Brute force

How T1110 brute force shows up in your authentication logs

Brute force shows up in your authentication logs as a pattern, not as a single event. T1110 Brute Force sits under the Credential Access tactic (TA0006), which MITRE describes as the adversary trying to steal account names and passwords. The technique has four sub-techniques, and it is the failed authentication pattern across identity providers, IaaS consoles, container platforms and ESXi hosts that a SOC lead should watch for. This page targets Enterprise ATT&CK 20.0, and technique IDs use the form T#### with sub-techniques adding a three-digit suffix, so confirm the version your detection content names before you map alerts to it, because releases can rename, deprecate or revoke techniques.

At a high level, the attacker is guessing or spraying credentials against accounts until one works. That goal leaves a trail that differs by platform. Identity provider sign-in logs may show many failures against one account, or one source trying a small number of passwords across many accounts. IaaS control plane logs and ESXi host authentication logs may show bursts of failures from a single address or a mix of valid and invalid account names. Container platform API audit logs can record repeated denied requests from one client. Each of these sources is a different data component in the ATT&CK model, and the User Account Authentication data component is the common thread across them.

Before you write any alert, ask your platform owners three questions: which of these systems forward authentication events to your central log store, what fields they record for the source address, account name and result, and how long those events are retained. Some platforms log failures only at a verbose level, and some do not record the source address at all. Confirm these details in each environment rather than assuming them from a vendor default. The gaps you find here will decide which sub-technique detections are possible at all.

Data sources and signals for brute force detection

This table maps each data component ATT&CK links to T1110 Brute Force to the signal it reveals, the open-source collector that gathers it, and what to confirm in your own environment. Read it as a checklist: User Account Authentication carries the primary signal, while the other two sources add platform-specific and protocol-level context. Confirm each platform's log export before relying on any row.

Data source	Signal to look for	Collector and what to confirm
User Account Authentication (DC0002), primary	Failure bursts against one account, many accounts failing from one source, and a success shortly after a run of failures	Wazuh agents or syslog forwarding from identity and host logs. Confirm which authentication events each platform writes and whether failed and successful attempts both reach the SIEM.
Application Log Content (DC0038), platform audit events	Repeated invalid-password or invalid-token events on containers, ESXi, IaaS consoles and identity providers, including lockout and rate-limit events	Wazuh decoders or platform audit log export. Confirm that each platform logs failures with source address, account name and outcome, and that retention covers the lookback window you plan to use.
Network Traffic Content (DC0085), protocol context	High connection rates to authentication ports, many short sessions from one host, and repeated login requests to web or API login endpoints	Zeek or Suricata sensors on the relevant segments, with Security Onion as a packaged platform. Confirm which protocols are visible on your segments and whether TLS-protected login traffic is observable at the sensor.
Source address and geography context	Sources that fail against many accounts, or that appear for the first time in an authentication log	Enrichment inside the SIEM from Wazuh or Zeek connection logs. Confirm that internal NAT, load balancers and VPN concentrators do not hide the true origin in your logs.
Lockout and policy events	Account lockouts and password policy rejections that cluster in time	Wazuh alerting on identity platform lockout events. Confirm that lockout events are generated and forwarded, since some platforms log them only at higher verbosity.

Detection logic for password guessing and spraying

Password guessing and spraying look different in authentication logs, so detection needs several views of the same User Account Authentication telemetry. The cards below combine per-account failure counts, distinct-account counts per source, success after failures, and location anomalies, then explain how to tune them without hiding real attacks.

Per-account failure thresholds

Count failed authentications per target account over a rolling window and alert when the count crosses a level set from your own baseline. This catches classic guessing against a single user, including attempts against privileged accounts that deserve a lower threshold. Check that the window is long enough to catch slow guessing and short enough to avoid merging normal business-day lockouts. Start with privileged accounts and tune outward.

Distinct-account counts per source

Spraying tries one or two passwords across many accounts, so per-account counts stay low. Instead, count how many distinct accounts a single source address, client or user agent fails against within a window. A high distinct count with low failures per account is the signature to alert on. Confirm that your identity provider logs the source address reliably, including behind proxies and load balancers.

Success after a run of failures

The highest-priority signal is a successful sign-in that follows a run of failures for the same account or from the same source. This combination suggests a guess landed. Correlate the success event with the preceding failure sequence and the account's normal sign-in pattern. Treat any success on a privileged or dormant account following failures as an incident candidate.

Geographic and ASN anomalies

Compare the country and autonomous system of each authentication against the account's history. Hosting providers and unfamiliar networks attempting many accounts are a useful enrichment, but they produce false positives for travelers and remote staff. Use the anomaly as a score modifier rather than a standalone alert, and confirm your geolocation and ASN data source is kept current.

Tuning levers and false positives

Service accounts, scripts with stale credentials, misconfigured mail or sync clients, and mobile devices that reconnect after a network change all generate failures that resemble guessing. Password expiry events cause bursts of failures across many users at once. Suppress these by allow-listing known service identities with their expected source addresses, and by excluding expiry windows, rather than by raising thresholds for everyone.

Safe suppression and review

Every suppression should name the owner, the reason, the scope and an expiry date, and should be reviewed when the client or service changes. Keep suppressed events in the log store so later investigations can see them. Ask your SOC to test each suppression against a recent sample of production logs before it goes live. Record the ATT&CK version your rules target so mappings stay accurate across releases.

How to validate that the brute force detection fires

This sequence proves that each brute force detection rule raises the alert it is supposed to raise, on the platforms in scope, within a time the team has agreed in advance. It produces a dated evidence record that shows which rules work, which log sources are missing, and which rules need to be re-tested when ATT&CK changes.

Agree the emulation scope in writing
The security lead, the platform owners for the identity provider, IaaS console, container platform and ESXi hosts, and the SOC manager sign a short scope document before any activity starts. It names the lab tenants and accounts, the permitted failure patterns, the time window, the people who may stop the exercise, and the escalation path if a real account is affected. Done means every named platform owner has confirmed in writing that the lab targets are isolated from production identities.
Choose target platforms and rules to test
Select one target per platform class in the scope: the identity provider, the IaaS management console, a container platform control plane and an ESXi management interface. For each one, list the detection rules that should respond to password guessing and to the sub-technique patterns covered on this page. Record the exact ATT&CK version each rule was written against, so the test matches the mapping in use. Done means a rule register exists with one row per rule, its target platform and its expected data source.
Define the expected alert for each rule
For every rule in the register, write down the alert name or ID the SOC expects, the severity, the destination queue, and the condition that should trigger it, such as a threshold of failed logons from one source within a window. Keep the expectation in the team's own words so the test can show a mismatch clearly. Done means each row has an expected alert that the analyst on shift could recognize without reading the rule code.
Run a controlled failure pattern
The test operator generates failed authentication attempts against the lab accounts in a pattern agreed in step one, with a known count, known source, and known spacing. The operator keeps a timed log of each batch so the expected result can be checked against what was actually sent. Done means the batch record matches the scope document and every batch has a start and end time.
Record timestamps, alert IDs and time to alert
For each batch, capture the time of the first failed event, the time the event appeared in the log platform, the alert ID raised, and the time the alert reached an analyst. The gap between the first event and the alert is the time to alert, which the team should compare against its own response objective rather than an external benchmark. Done means each rule has a row showing whether it fired, which alert ID it produced, and the measured time to alert.
Document gaps in log coverage
Where a rule did not fire, or fired late, check whether the source events reached the log platform at all, whether the fields the rule depends on were parsed, and whether the agent or connector was healthy during the window. Record each gap with its owner and a planned fix. Done means every failed test has a root cause recorded as missing source, parsing failure, rule logic, or threshold, and none is left as unknown.
Re-run after each ATT&CK version change
When MITRE publishes a new Enterprise ATT&CK version, the team compares its technique and sub-technique changes against the rule register and re-runs the affected tests. Rules are re-tested whenever a technique is renamed, deprecated or revoked, and every test record states the ATT&CK version the rule targets. Confirm the current version and its change notes on the MITRE ATT&CK updates page before planning the next run. Done means the register shows the version each rule was last validated against and the date of that validation.

Preventive controls that reduce brute force success

Brute force succeeds when accounts accept unlimited guesses, when weak or reused passwords are allowed, and when stale or privileged accounts go unwatched. The mitigations below address those conditions directly, and each one depends on settings that differ by platform, so confirm them per system before relying on them.

Account lockout thresholds

Lockout and throttling settings limit how many failed attempts an account or source can make before access is blocked or delayed. For T1110 Brute force, the key check is whether the threshold applies to each identity provider, SSH service, container registry, and ESXi or IaaS console, and whether it resets on a timer or needs an administrator. Confirm each platform's lockout behavior in its own documentation, because some APIs and service accounts may bypass interactive lockout.

Password policy settings

Password policy under M1027 covers length, complexity, banned or breached password lists, and rules against reuse. These settings raise the cost of guessing but do not stop password spraying, which tries a few common passwords across many accounts. Review which policy engine governs each platform, since a policy defined in the directory may not apply to local accounts on appliances.

Account lifecycle management

User Account Management under M1018 covers onboarding, role changes, and removal of accounts. Dormant, orphaned, and shared accounts are common brute force targets because nobody watches their failed logins. Require a documented owner for each account, disable accounts that have been unused beyond the period your policy sets, and remove service accounts when their workload is retired.

Privileged account hygiene

Administrator, root, and break-glass accounts give an attacker the most value from a successful guess. Restrict where these accounts can sign in, separate them from daily-use identities, and avoid exposing their login pages to the internet. Confirm which of these controls your identity provider and infrastructure platforms support natively, and where they must be enforced through network rules instead.

Audit of account activity

Audit under M1047 supports the preventive controls by recording authentication outcomes, lockouts, and account changes in a central store. Without these records, you cannot tell whether a lockout policy fired or whether a password was guessed. Confirm that each platform logs failed and successful sign-ins with source address and account name, and that logs are retained long enough for your review cycle.

Triage and response when a brute force alert fires

The first decision is whether the alert represents an attack or a misconfigured client, and the fastest way to settle it is to look at the pattern of failures rather than the count. A sustained run of failures against many accounts from one source points toward password spraying or credential stuffing, while a burst of failures against a single account from a single service principal often points to an expired secret, a stale mobile token or a script with a hard-coded password. Confirm which by checking the User Account Authentication events for the source address, the user agent or client application, and the time window, then compare against the change calendar and recent deployments. Next, search the same window for a success event for any targeted account. A success after a run of failures, especially from an address with no prior history for that user, is the signal that moves the alert into an incident.

Once an attack looks plausible, identify the targeted accounts and rank them by privilege. Administrative roles, service accounts with broad API rights and accounts that can approve changes to the identity provider deserve priority, because a single success on one of them changes the blast radius. Contain at the narrowest effective point: block or rate limit the source at the edge or identity provider, then force credential resets only for accounts with a confirmed success or a credible exposure, so that legitimate users are not locked out at scale. Revoke active sessions and refresh tokens for those accounts at the same time, since a reset alone does not end an existing session. Review what each compromised account did afterward: new sign-in locations, MFA method changes, new OAuth grants, mailbox rules, role assignments and access to sensitive resources.

Preserve evidence before making changes that overwrite it. Export the raw authentication logs for the investigation window from the identity provider, the reverse proxy or VPN, and any cloud control plane, with their original timestamps and time zone, and hash the exports. Record the firewall or identity provider rules you applied, with the time and the approver, so they can be reversed later. Escalate to your incident response team when any targeted account shows a success, when a privileged or service account is involved, when the source is shared infrastructure that could affect other tenants, or when you see activity after a success. Confirm in advance with your incident response provider and legal or compliance owners which log retention periods and notification obligations apply to your environment.

How to rehearse brute force detection in a private cyber range

An identity provider is usually the most valuable target for T1110 Brute Force, because a single successful guess can grant access to many downstream applications. A private range for this platform should mirror production in its federation settings, lockout configuration and log export path. Use a non-production tenant or a self-hosted identity service with test accounts, and confirm that authentication events are forwarded to the same SIEM the production team uses. The injects should cover slow, low-rate guessing against one account, password spraying that tries one common password across many accounts, and a late success after a run of failures. Good detection means the User Account Authentication events are parsed, the failure-then-success pattern raises an alert within the window your team has agreed, and the alert names the account, source address and application. Good response means the on-call analyst can confirm or dismiss the alert, the account is locked or its sessions revoked, and the account owner is contacted. Record the containment time and the decisions in the exercise log.

Range topology: A test identity provider, a sample relying application, and a log path into your SIEM, with the lockout and throttling settings copied from production.
Injects: A slow guessing run against one account, a spray across a test user list, and a success after repeated failures.
Detection quality: Alerts fire inside the agreed window, route to the correct queue and include account, source and target application.
Response quality: Analysts reset credentials or revoke sessions, and the containment time is measured from first alert to action.
Lessons recorded: Note which thresholds missed the slow run and which account policies need review.

Check that the test identity provider's authentication logs carry the fields your detection depends on before the first inject runs.

Questions detection engineers ask about T1110

How do you separate password spraying from ordinary failed logins?

Look at the shape of the failures, not the count alone. Ordinary failed logins cluster on one account from one source, usually followed by a success or a lockout that the user resolves. Password spraying spreads a small number of attempts across many accounts from the same source or a small set of sources, often over a long window to stay under lockout thresholds. Build your rules on the User Account Authentication data component so that each event carries the account, source, result and time. Then correlate by source across accounts and by account across sources. Validate the logic in a private cyber range by replaying both patterns and confirming that each one raises a different alert.

How do you set brute force thresholds without flooding the alert queue?

Start from the authentication behavior of your own environment, not from a generic number. Measure normal failure rates per account, per source and per application over several weeks, then set thresholds above the normal peaks and tune them per platform. Separate alerts into tiers: a high-confidence alert for many failures followed by a success, and a lower-priority trend alert for sustained failures. Suppress known service accounts, scanners and load balancers through documented allowlists that are reviewed on a schedule. Record every threshold change with a reason so analysts can explain why an alert fired.

Is account lockout alone enough to stop brute force attacks?

No. Lockout limits repeated guessing against one account, but it does not detect spraying that keeps each account below the lockout threshold, and it can be turned into a denial of service against legitimate users. ATT&CK maps T1110 to User Account Management (M1018) and Password Policies (M1027), which work together: policy sets the rules for passwords and lockout, and account management governs who can authenticate and how accounts are monitored. Detection is still needed so that your team sees the attempts, not only the outcome. Confirm with your identity provider vendor how lockout is counted and whether it applies per account, per source or both.

How do you detect brute force when login goes through federated identity?

Federated login moves much of the failure telemetry to the identity provider, so the application logs may show only a redirect or a generic error. Collect authentication events from both the identity provider and the relying applications, and join them on a common session or correlation identifier where your platforms provide one. Pay attention to failures at the identity provider that never reach the application, because those are the attempts that are easiest to miss. Confirm which fields each identity provider exposes in its audit logs before writing rules, since field names and retention differ by product.

How do you measure brute force detection coverage per platform?

Build a coverage matrix with one row per platform, such as containers, ESXi, IaaS consoles, identity providers and SaaS applications, and one column per sub-technique and attack pattern. For each cell, record whether the required telemetry is collected, whether a rule exists, and whether a cyber range exercise has confirmed that the rule fires. Coverage is only as good as the log source, so track gaps in collection separately from gaps in logic. Review the matrix after each change to the environment and after each ATT&CK release, since mappings can change between versions.

How often should brute force detections be retested after an ATT&CK update?

Retest whenever the ATT&CK version you target changes and whenever your authentication platforms change. MITRE publishes releases on a schedule that has included v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each release can rename, deprecate or revoke techniques or change detection strategies. Map each detection to the version it targets, review the release notes for T1110 and its sub-techniques, and rerun the affected cyber range scenarios. Also retest after identity provider upgrades, because log formats can change without notice. Confirm the review cadence your compliance program requires before committing to a schedule.

Can our own team run brute force detection and cyber range rehearsals?

Often yes, if you have engineers who know your logging pipeline and the authentication platforms in scope. The work includes collecting the right telemetry, writing and tuning rules, building a repeatable test plan, and running exercises that do not affect production. Teams often need outside help with the cyber range build, with validating rules against realistic but isolated traffic, or with an independent review of coverage. DeployOpen plans, implements and supports open-source platforms inside your own infrastructure and runs cyber ranges and security testing. Ask for a fixed-scope written proposal that names the platforms, deliverables and timelines before work starts.

How to measure brute force detection coverage over time

Coverage for T1110 Brute force is only meaningful if you can show, at any point in time, which platforms emit usable authentication telemetry, which rules fire on it, and when those rules were last proven to work. Start with a platform-by-platform inventory covering containers, ESXi, IaaS consoles, the identity provider and any other systems the User Account Authentication data component applies to. For each one, record whether the events arrive in the SIEM, whether the fields needed to separate failed attempts, successful logons, source address and target account are populated, and whether the timestamps are reliable enough to count attempts in a window. A platform that sends events but leaves the source field empty should be marked partial, not covered.

Track validation as a schedule with owners, not as a one-time project. Decide how often each brute force rule is replayed in your private cyber range, which events the replay must produce, and who signs off on the result. Record the date, the rule version, the telemetry source and the outcome for every run, so that a rule that silently stopped matching after a logging change shows up as a failed check rather than a surprise during an incident. Your team should confirm the cadence with its own risk owners, since the right interval depends on how often authentication sources and logging configurations change.

Tie every mapping to the ATT&CK version your rules target. Record the version in each rule's metadata and in your coverage register, because releases can rename, deprecate or revoke techniques and sub-techniques and detection strategies can move between versions. Review the ATT&CK updates page for the version in use before each coverage review, and compare the T1110 entries and its sub-techniques against your register. When the mapping changes, re-run the affected rules in the range, because a mapping that still reads correctly may no longer describe the analytic your rule implements.

How DeployOpen builds brute force detections and range exercises

DeployOpen works on T1110 Brute force as a scoped engagement inside the client's own environment, from defining which authentication sources matter to rehearsing detection in a private cyber range. Each step produces written deliverables that the client's security and platform teams can keep, review and run again.

How we scope

Agree in writing which identity providers, IaaS consoles, ESXi hosts and container platforms are in scope for T1110 Brute force.
Confirm which User Account Authentication logs are available today, and which sources need forwarding or retention changes first.
Record the ATT&CK version the detection mappings target, so later releases can be compared against a fixed baseline.

How we build

Write detection logic for each in-scope platform in plain language, then translate it into Sigma rules and Wazuh or Security Onion content.
Tune thresholds for failed logons, password spraying patterns and lockout events against the client's normal authentication volume.
Map the detections to the ATT&CK sub-techniques of T1110 and to the User Account Management and Password Policies mitigations.

How we hand over

Deliver the detection rules, configuration changes and data source inventory with version control and a short operator guide.
Document the validation method, the expected alert fields and the known gaps for each platform in the written scope.
Run a rehearsal in a private cyber range with the client's analysts, then record findings and follow-up actions.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, rule updates when ATT&CK releases change T1110 mappings, and periodic re-testing are available as a retainer.
Ask for a written quote tied to the scope above. DeployOpen does not publish a price list.

T1110 Brute force