Anybody who is frequently using a CLI has already typed at least once in his life a password in the command line. When this happen, a simple clean up of the bash history is usually enough to correct this mistake. And if you are a red or blue team, you have probably hunted for passwords typed in command line history. However, it appears that a similar mistake is made way more frequently by end users, and is way more difficult to clear when made; typing its password in the username field of a login screen.

Indeed, doing so will usually log an authentication failure with the username (well in this case, the password…) in cleartext. Anybody who have Read access to the logs can then retrieve the mistyped password. This can happen when you log to your laptop, when you authenticate on a specific website,…When this happen, clearing the logs are usually off the table, so changing the password become the only realistic option if you want to make sure of it’s confidentiality, but let’s be honest, nobody does that.

With this idea in mind, I started to dig in few systems that I have access to, and the results were surpising. I was expecting to find some passwords this way, but the mistake appeared to be way more frequent than I though and allowed to find thousands of passwords with simple queries, including the ones for highly privileged accounts.

In the hands of an attacker, those failed authentication logs can allow simple privilege escalation or lateral movement, without requiring advanced skills or vulnerability to use.

What to look for ?

If you have access to a system storing logs, you can look for interactive failed logons and filtering on the usernames that includes special characters and numbers or look for usernames that matches the password policy. Usually the following regex has great success but it should obviously be adapted to reflect the target organisation’s password policy.

^(?:(?=.*[a-z])(?:(?=.*[A-Z])(?=.*[\d\W])|(?=.*\W)(?=.*\d))|(?=.*\W)(?=.*[A-Z])(?=.*\d)).{8,}$

Beside this regex, additional filtering is usually necessary to filter out the noise caused by service accounts, email addresses, and other odd usernames. A manual analysis should quickly highlight if you have any success with this method.

Sometimes the usernames are prepended to the password, giving the complete credentials set. If only the password is present, some simple correlation by looking at the next authentication success from the same machine usually gives the missing information on the username.

Even if the password does not work, for a red teamer, the findings gathered this way can make a great starting point for a dictionary-based brute force, specifically combined with rulesets.

SIEMs are the obvious the place of choice to look for bulk failed authentications, but EDR appears to be quite good also, aggregating the authentication attempts of all your endpoints. While there is a low probability that your EDR or SIEM got compromised (and probably bigger problems if it was to happen), the main issue reside against insider threats. An analyst who got bad intentions and try to leverage the response capabilities of your EDR to connect to an other system would most likely get caught by the audit logs, but would you be able to detect that he re-used credentials found in the telemetry to connect to the same system ? If you are a red teamer and was already capable to compromise a system, at smaller scale the local logs can also sometimes give you interesting hits for further lateral movement.

How to reduce the probability that passwords get stored in the logs as a system administrator

On Windows systems, it appears that this mistake is often made by users because of a bad habit. Indeed, endusers tend to keep muscle memory of pressing enter right after having typed their password, without verifying that they have entered it in the correct field. And when they forgot to change the focus to the password field, or because they are used to only enter the password, they send it in the username field.

Windows has a security policy named Interactive logon: Don’t display last signed-in permitting to specify if the last signed-in user should be displayed or not during interactive logon. When this is disabled, when the user starts its machine, the last sign-in username will be pre-filled and the user simply needs to type its password. In contrary, when this policy is enabled, the sign-in screen will request both a username and a password. This policy changes the behaviour of the login screen only during first sign-in but not after a lock. When the machine is locked, the user is only prompted to type its password. This discrepency increase the probability that the mistake is made.

Without much surprise, Microsoft recommend to enable this policy to avoid giving information about the last signed-in user to an attacker who would have access to the machine. While, this can make sense for servers, in particular when accessed via RDP, it seems that for workstations or laptops, users are getting used to only have to type their password to unlock their machine, and based on my observations when this policy is active, the mistake is made more frequently right after the computer is (re)started, when they have to suddenly type the username and the password. In my opinion, the risk of having more passwords stored in plaintext in logs is greater than giving info about last signed-in user to an hypothetical attacker who would have physical access to the machine, and this policy should be turned off.

For applications,

How to protect ?

Soon…