What’s the issue?
SQL Server can log failed login attempts to the SQL Server error log based on the configured login auditing level, which is controlled through the server properties Security page or by editing the relevant registry value. The available levels are none, failed logins only, successful logins only, and both successful and failed logins, with failed-only being the most common production setting.When a login attempt fails, SQL Server records the reason in the error log along with the source IP address (in supported versions), the login name attempted, and the time of the attempt. These entries are the primary record of authentication failures against the instance.
This finding identifies instances where the error log shows recent failed login attempts.
Why is this a problem?
Failed login attempts can have many causes, ranging from benign to serious. On the benign end, they may reflect a user who mistyped their password, an application using stale cached credentials after a password change, a misconfigured connection string in a deployment, or a scheduled job pointing at the wrong instance.On the more serious end, failed logins can indicate brute-force attempts against the instance, particularly when the patterns show many attempts against well-known accounts such as sa, attempts against multiple different login names from the same source, or sustained activity over time. These patterns are characteristic of automated attacks and warrant immediate investigation.
The condition is also worth attention because failed logins often precede successful unauthorized access. An attacker may probe the instance with many failed attempts and eventually succeed, particularly if any login has a weak password (a separate finding) or if account lockout is not configured. Reviewing failed login activity is one of the earliest opportunities to detect and respond to such attempts.
Patterns of failed logins also provide useful signals about the overall health of authentication on the instance. Sustained failures from a known internal source often indicate a configuration problem that is worth fixing, while failures from external or unknown sources warrant a different response. Without regular review, the signal sits in the error log and produces no actionable response.
What should you do about this?
Review the failed login entries in the error log to understand the pattern and source. Capture the login names attempted, the source IP addresses, the timestamps, and the specific failure reasons (incorrect password, login does not exist, login disabled, and so on). Use EXEC sp_readerrorlog to extract and review the entries, filtering for the relevant authentication failure messages.Categorize the failures based on what they indicate. Single isolated failures from known sources are usually benign and can be addressed by correcting the source configuration. Repeated failures against sa, against multiple different login names, or from unfamiliar sources warrant investigation as potential brute-force or reconnaissance activity, and should be escalated to your security team.
Address benign causes by working with the relevant teams to fix the source. Common remediations include updating cached credentials in applications, correcting connection strings in deployments, fixing scheduled jobs that point at the wrong instance, and helping users who have forgotten or mistyped their passwords. Each fix removes noise from the error log and makes future reviews more meaningful.
For suspicious patterns, take immediate action. Confirm that the targeted accounts have strong passwords (or are disabled if not in use, particularly sa), block the source IP addresses at the network level if appropriate, and review the broader security posture of the instance to ensure that any successful authentication would be limited in impact. Consider implementing or strengthening account lockout policies if available in your environment.