Plaintext Credentials

Credentials stored in plain text are a common problem and are readily exploited by all attackers. However, this topic has already been discussed extensively and the solution is relatively simple, at least for end users, namely using a password manager. We have already looked at attacks and hardening of such a password manager in this blog post. Often overlooked, however, are stored credentials on network shares, a gold mine for attackers.

First, let's look at how to check an organization for stored plaintext credentials. This task is not as easy as one might think at first. How do you know that a stored word represents a password and, in particular, what it is used for? If this information is not explicitly there, it is rather difficult to recognize the password as such and to guess the purpose of its use. Of course, it is different if this context is given, for example in a script that contains plaintext passwords.

Fortunately, the procedure is basically the same for attackers and defenders, and the same tools and methods can be used. Thus, credentials that are easy for an attacker to find are also easy for defenders to discover and remove. Conversely, credentials that are difficult for the defense to discover are also difficult for the attackers to discover, and finding them requires more effort accordingly. By the way, this methodology of defense can be used quite often and very effectively in cyber security. By using the same methods and tools of the attackers for defense, their effort can be massively increased very quickly. Thus, there is more time to detect an attack and financially motivated attackers hopefully lose the "motivation" and look for an easier target.

Many privilege escalation scripts like PowerUp and WinPeas already search for obvious passwords by default. Running such scripts is also highly recommended otherwise, simple privilege escalation opportunities are quickly revealed this way. For example, a simple PowerShell script can be used to search for keywords in various file types that indicate passwords:

function Password-Search()
{
     param([Parameter(Mandatory = $true)] [string]$Path="")
     Write-Output "***Searching***"
     Get-ChildItem -Path $Path *.txt -Recurse | Select-String -Pattern "passw"
     Get-ChildItem -Path $Path *.ps1 -Recurse | Select-String -Pattern "passw"
Write-Output "***Done***"
}

A network share can also be used as a path and searched there.

Very popular among attackers and somewhat more sophisticated is the tool LaZagne. However, the tool goes a bit further and generally tries to obtain passwords stored on the local computer.

But now we want to talk about network shares. Access rights of users to network shares are often assigned a bit too liberally and so it can happen that suddenly all users get access to a network share, which was actually only needed briefly in a development process for specific users. In the worst case, a PowerShell script with access data of a service account with high permissions is located on such a network share and it is made extremely easy for the attacker. Once again, attackers and defenders can use exactly the same methods. The SharpShares tool can be used to display all accessible network shares of the executing user.

By the way: If C$ is displayed here for a network share (ex

cept for the executing system), this usually means that the corresponding user has administrator rights on the system and this situation should definitely be checked.

Ideally, these findings can already be used and unnecessary access rights to network shares can be removed. This is worthwhile in any case, the attack surface is massively reduced with such access rights, regardless of any access data on the shares.

The Snaffler tool can be used to find access data on these network shares. However, the creator's explanations on how to use it are a bit tricky and of a humorous nature. As always, caution is advised with tools from GitHub, i.e. study the source code carefully and in any case compile it yourself. Since the tool is written in C#, this should be relatively easy to do with VisualStudio. The disadvantage of using tools from attackers is that they are often detected by AV or EDR products. However, this can also be seen as a good test of the products used and the execution can be completed in a controlled manner.

For example, the tool can be executed as follows:

snaffler.exe -s -v Info -j 200
-s Enables outputting results to stdout
-o Enables outputting results to a file
-v Verbosity level: Trace, Debug, Info, Data (results only)
-j How many bytes of context either side of found strings

In our small test AD, a relatively large number of results are already output and false positives have to be sorted out.

Machine learning seems to be predestined for finding passwords and in fact there are already tools that follow this approach. Just recently, Will Schroeder released the DeepPass tool and explained his approach in his blog. The tool is easy to install locally with Docker and delivers fast results.

Files can be uploaded locally and the password in the documentation is actually recognized.

The password is recognized without any specific reference to a following password in the text.

In this case, an additional password can be found thanks to machine learning, which would not have been found with the other tools. The big sticking point with this method, however, is training the model with suitable data. For example, the model currently works relatively well for English-language data, but not for data in other languages; the model would first have to be trained with appropriate data. Obtaining and labeling such data is likely to be a bigger hurdle. Nevertheless, the tool impressively shows how machine learning can also be used in an interesting way for attackers.

One major problem is evident in all tools. In the end, a human being is still needed to classify these results and sort out false positives. This problem affects both attackers and defenders alike. As a defender, the goal must therefore be to weed out the access data that is easiest to find, thus increasing the effort required by the attackers as much as possible. If, at the same time, access rights to network shares can be restricted and unnecessary administrator rights can be uncovered, security is massively increased with relatively little effort. The awareness of the employees can also be increased through targeted searches for clear text access data and informing the responsible persons. In the end, the original problem can only be solved in one way: all employees must be aware of the problem and every time a password in plain text is visible somewhere, all alarm bells should ring and alternatives should be sought.