Password Guessing (T1110.001) is a sub-technique of Brute Force, in the credential access tactic. MITRE lists containers, ESXi, IaaS, identity providers, Linux, macOS, network devices, Office suites, SaaS and Windows.
It is the plain version: an adversary with no prior knowledge of valid credentials tries passwords until one works.
How attackers use it
MITRE describes an adversary guessing passwords with a repetitive or iterative mechanism, often from a list of common passwords. The guessing may or may not account for the target's complexity rules or lockout policy. It can be risky for the attacker, because it creates many failures and may lock accounts out.
Management services on common ports are the usual targets. MITRE lists:
- SSH (22/TCP), Telnet (23/TCP), FTP (21/TCP)
- NetBIOS, SMB and Samba (139/TCP and 445/TCP)
- LDAP (389/TCP) and Kerberos (88/TCP)
- RDP and Terminal Services (3389/TCP)
- HTTP and HTTPS management services (80/TCP and 443/TCP)
- MSSQL (1433/TCP), Oracle (1521/TCP), MySQL (3306/TCP)
- VNC (5900/TCP) and SNMP (161/UDP and 162)
Beyond these, adversaries may target single sign-on and cloud applications that use federated authentication, and externally facing email such as Office 365. MITRE also mentions abusing network device interfaces to brute force wireless authentication on accessible Wi-Fi routers.
One detail is useful for defenders. By default, LDAP and Kerberos attempts are less likely to raise the usual Windows logon failure events than SMB attempts do. If your detection only watches event 4625 from SMB, you have a blind spot.
How to detect it
MITRE's strategy is Password Guessing via Multi-Source Authentication Failure Correlation. Analytics describe:
- A series of failures (event ID 4625) against the same or similar accounts over time from one or more remote addresses.
- Repeated failed SSH logins followed by a possible success from the same host.
- Repeated failed logins in loginwindow or sshd on macOS.
- Many failed sign-ins from external sources across users, followed by success from the same address, in cloud identity logs.
- Failures over SNMP, Telnet or SSH on network devices, visible in syslog.
- Guessing against web apps such as file sharing and workspace suites, seen in API or sign-in logs.
Correlate across sources. Failures in one log and a success in another from the same address is the pattern to hunt for.
How to reduce the risk
MITRE lists four mitigations:
- Update software. Upgrade management services to the latest supported version, especially versions with stronger password complexity or policy enforcement that prevents default or weak passwords.
- Multi-factor authentication, including on externally facing services where possible.
- Password policies based on NIST guidelines.
- Account use policies. Set lockout after a number of failed attempts, balanced against denial of service. Use conditional access to block non-compliant devices or logins from outside defined IP ranges, and consider blocking risky requests from anonymizing services.
Also reduce exposure: management ports such as RDP, SSH, VNC and databases should not face the internet unless there is a clear need.
Check your own environment
- Which of the ports above are reachable from outside your network?
- Do Kerberos and LDAP failures reach your logs and alerts?
- Do network devices still accept default or shared passwords?
- Is MFA enabled on every external login?
# Linux (Debian or Ubuntu): recent failed SSH password attempts (RHEL family: use /var/log/secure)
sudo grep "Failed password" /var/log/auth.log | tail -n 20
Quick check
Why might password guessing over LDAP or Kerberos go unnoticed?
MITRE notes these attempts are less likely to trigger the Windows logon failure events that SMB attempts produce, so detection built only on those events can miss them.
Name two mitigations beyond MFA.
Password policies based on NIST guidance, and account use policies such as lockout and conditional access. Updating management services is a third.
Sources
- MITRE ATT&CK, Brute Force: Password Guessing (T1110.001)
