Quick Answer: How do i check whether my device or account is affected by brute force attacks?
You check for brute force attacks by reviewing failed sign-in records, successful logons that follow clusters of failures, and active session lists on each account and device. On Windows, that means Event ID 4625 failures in the Security log; on Linux, failed SSH attempts in the auth log; in the cloud, the sign-in history inside your identity provider.
The signals differ by platform but the pattern is the same: a burst of failures against one account or from one address, sometimes followed by a success. Password spraying looks different, spreading a few attempts across many accounts so no single account trips a lockout.
Before you act, confirm which logs your plan actually retains, how far back they go, whether multi-factor authentication is on, which devices and sessions are currently active, and whether any password was reused elsewhere.
A single failed login at 3 a.m. is usually nothing. A hundred of them in four minutes is a different story. Verizon’s long-running Data Breach Investigations Report has repeatedly found that stolen or weak credentials sit behind a large share of breaches, which is exactly why automated guessing remains such a popular entry point. The good news: brute force attacks leave a paper trail. You just have to know where to look and what pattern to expect. This guide walks through the practical checks, platform by platform, plus the mistakes that make people miss the evidence sitting right in their logs.
What a Brute Force Attack Actually Leaves Behind
Before digging into menus and log files, it helps to understand the fingerprint. A brute force attack is a guessing campaign. Software tries password after password against a login until something works. That process is noisy by nature, and the noise is recorded. (Brute-force attack)
The tell-tale signs fall into four buckets:
- Failure spikes. Many rejected logins against one account, or from one IP address, in a short window.
- Odd timing. Attempts at hours when you and your users are asleep.
- Success after failure. A successful login immediately following a run of failures is the loudest alarm of all.
- Behavioral drift. New devices, new locations, mailbox rules you didn’t create, or password reset emails you never requested.
The pattern matters more than any single event. One failed login is a typo. Forty in a row is a machine.
Checking a Windows PC or Server
Windows keeps authentication records in the Security log, and two event IDs do most of the work.
Event ID 4625 records a failed logon. Event ID 4624 records a successful one. Open Event Viewer, expand Windows Logs, and select Security. Use the filter option to isolate 4625 events, then sort by time. What you’re looking for is density: repeated 4625 entries against the same account name, or from the same source address, clustered within minutes.
A second pass looks for 4624 events that land right after a cluster of 4625s. If a successful logon follows twenty failures, treat that account as compromised until proven otherwise.
Two practical notes from experience. First, audit policy has to be enabled for these events to exist at all; many home installs log almost nothing. Second, the Security log rolls over. On a busy machine it may hold only days of history, so check it before you reboot or clear anything.
If you want to rule out a malicious payload dropped after a successful guess, it’s worth learning how to check for malware on a Mac or its Windows equivalent, since post-compromise tooling often arrives quietly.
Checking Linux Servers and SSH
On Linux, failed SSH authentication is the classic brute force target, because every internet-facing server has port 22 open by default.
The records live in /var/log/auth.log on Debian and Ubuntu systems, and /var/log/secure on RHEL-family distributions. Search for lines containing “Failed password” and count them per source address. A single IP with hundreds of failures in an hour is a bot, plain and simple.
Command-line tools shorten the job considerably. The `lastb` command summarizes failed login attempts, and `fail2ban`, if installed, keeps its own logs of banned addresses. Grep is your friend here: filter for “Failed password,” pipe to a sort and count, and the loudest offenders surface immediately.
One mistake people make: they check the log once, see nothing unusual, and stop. SSH brute force is often slow and low-volume by design, specifically to stay under alerting thresholds. Check a full week, not a single afternoon.
Checking Cloud and Email Accounts
Consumer and business cloud accounts expose sign-in history directly, no log parsing required.
| Platform | Where to look | What to scan for |
|---|---|---|
| Microsoft account / Entra ID | Security info and sign-in logs | Failed attempts, unfamiliar IPs, risky sign-ins |
| Google Account | Security tab, recent activity | Failed sign-ins, new devices, app access |
| Apple ID | Device list in settings | Unknown devices, unfamiliar sign-in alerts |
| Corporate SSO | Admin console audit logs | Failure bursts, impossible-travel flags |
Microsoft’s identity platform flags risky sign-ins and detects password spray patterns automatically, which is a genuine convenience. Google’s security dashboard shows recent activity with device and location detail. Both surface the same core question: does anything here look like it wasn’t you?
While you’re in there, check for forwarding rules and connected apps you didn’t authorize. Attackers who guess a password often set up persistence before the victim notices anything. And if you’re unsure whether a suspicious link in a “new sign-in” email is genuine, learn how to check whether a link is safe before clicking, because phishing frequently piggybacks on real breach anxiety.
Reading the Difference Between Brute Force and Password Spraying
This distinction trips up more people than any other part of the investigation.
Classic brute force hammers one account with many passwords. It produces a huge failure count against a single username, and account lockout policies usually stop it cold.
Password spraying flips the approach. It tries a handful of common passwords, like “Summer2026!” or “Password123,” across hundreds of accounts. Each individual account sees only two or three failures, which sails right past lockout thresholds and per-account alerts. The signal lives at the organization level, not the account level.
If your logs show a scattering of one-to-three failures across dozens of accounts within a short window, from a small set of IP addresses, that’s spraying. Per-account review will miss it entirely. This is the single most common blind spot in DIY investigations.
Checking Mobile Devices and App Stores
Phones rarely get brute forced directly, but the accounts attached to them do. Check the active device list in your Google or Apple account and remove anything unfamiliar. On Android, review Settings > Security > Recent security activity. On iOS, scroll to the bottom of Apple ID settings for the device list.
One adjacent risk deserves a mention: sideloaded apps. A malicious APK can harvest credentials and quietly feed them to an attacker, which then looks like a brute force campaign from the outside. Learning how to check whether an apk file is safe closes that loop. Similarly, if odd files or images appear on a compromised device, it’s worth knowing how to check whether an image is ai generated, since synthetic images are increasingly used in social engineering follow-ups.
Network Gear: The Forgotten Target
Routers, VPN appliances, and remote desktop services are brute forced constantly, and their logs are the ones nobody checks. Home routers typically keep a small log of failed admin logins; many enterprise firewalls export authentication failures to a central collector.
Three checks matter here. Look for repeated failed admin logins on the router’s management page. Confirm remote administration from the internet is switched off. And verify the firmware is current, since internet-exposed edge devices have been repeatedly flagged as preferred entry points in federal advisories.
Remote Desktop Protocol deserves special caution. Exposed RDP is one of the most heavily guessed services on the internet, and successful RDP access is a full machine compromise rather than only an account compromise. If RDP must stay on, put it behind a VPN and enforce multi-factor authentication.
Steps to Take Once You Confirm a Hit
Finding evidence is only half the job. The response sequence matters.
- Contain. Disable the affected account or change its password immediately, and terminate all active sessions so existing tokens die.
- Enable multi-factor authentication. This is the single most effective control against credential guessing, full stop. Even a correct password becomes useless without the second factor.
- Block the source. Add offending IP ranges to a firewall or fail2ban rule, and tighten lockout thresholds.
- Audit persistence. Check for new admin accounts, forwarding rules, API keys, and scheduled tasks created during the exposure window.
- Rotate reused credentials. If the password appeared anywhere else, change it everywhere. Credential stuffing runs on exactly this habit.
- Document and monitor. Note the timeline, then watch closely for a week. Attackers frequently return.
Speed beats thoroughness in the first ten minutes. Contain, then investigate.
Common Mistakes That Hide the Evidence
Practical experience surfaces the same errors again and again. People check only the account they suspect, ignoring organization-wide patterns that reveal spraying. They look at a single day of logs when retention allows a month. They clear logs or reboot before capturing evidence. And they treat “no lockout triggered” as proof of safety, when spraying is specifically designed to avoid lockouts.
The reverse error happens too: panicking over a handful of failed logins that turn out to be a stale phone retrying an old password. Context is everything. A failure cluster from your own IP range at a time you were awake is probably you.
If your investigation touches gaming handhelds or emulation setups with network shares, the same log-reading discipline applies; the comparison of EmuDeck 2.7 vs ES-DE 3.5 vs RetroDeck by device is a useful reminder that device-specific defaults shape what gets logged. And incidents like the reported OpenAI employee arrested over a hidden listening device show why unusual device behavior deserves a second look rather than a shrug.
Conclusion
Brute force attacks are loud, but only to people who know where the noise is recorded. The check itself is straightforward: pull the failed-login records on every platform you own, look for clusters, and hunt for a success that follows a run of failures. Windows gives you Event ID 4625 and 4624. Linux gives you auth logs and `lastb`. Cloud providers give you sign-in dashboards with risk flags built in. Network gear gives you admin logs most owners never open.
The harder skill is reading the pattern. Dense failures against one account mean classic brute force. A thin scatter across many accounts means spraying, and it demands an organization-wide view. Either way, the response is the same: contain, turn on multi-factor authentication, block the source, and audit for persistence.
Do the check quarterly, not only after something feels wrong. Logs expire, and the window for catching a quiet campaign closes faster than most people expect.
Frequently Asked Questions
How many failed logins should trigger concern?
There’s no universal number, but density matters more than raw count. Dozens of failures against one account within minutes is a clear signal. For password spraying, even two or three failures per account across many accounts in a short window warrants a look at the organization level.
Can a brute force attack succeed without me seeing failed logins?
Yes, in two scenarios. Password spraying keeps per-account failures low by design. And if an attacker already holds a valid credential from a breach elsewhere, they log in successfully on the first try, producing no failures at all. That’s why reviewing successful sign-ins and active sessions matters as much as counting failures.
Does multi-factor authentication stop brute force attacks completely?
It stops the overwhelming majority of credential-guessing attacks, because a correct password alone no longer grants access. It is not absolute: attackers can attempt MFA fatigue by spamming push notifications, or target weaker recovery methods. It remains the highest-value single control available.
How far back do sign-in logs usually go?
It varies widely. Local Windows Security logs may hold only days on a busy machine before rolling over. Cloud identity providers typically retain sign-in history for a limited window that depends on your plan tier, often 30 days on basic tiers and longer on premium ones. Check your specific retention before assuming a clean log means a clean account.
What’s the difference between a brute force attack and credential stuffing?
Brute force guesses passwords systematically against a login. Credential stuffing takes username and password pairs leaked in one breach and replays them against other services, betting on password reuse. Stuffing produces very few failures per account, so it hides well and is defeated mainly by unique passwords and multi-factor authentication. (Use Strong Passwords)
Is it dangerous to leave remote desktop exposed to the internet?
It’s one of the riskiest configurations you can run. Exposed RDP is scanned and guessed continuously, and a successful login hands an attacker full interactive control of the machine. Keep it behind a VPN, restrict source addresses, and enforce multi-factor authentication if it must remain reachable.
