Detecting Hard-Coded Credentials with LogRhythm
Hard-coded is a term used to describe when a software developer embeds data directly into the source code of a program or script, rather than supplying it externally as a parameter. If the data consists of user credentials, this can create major problems. Let me give you an example to explain how this happens in a Windows environment, and then we can look at how to go about finding hard-coded passwords in your own environment using LogRhythm NextGen SIEM Platform.
An Example of Hard-Coded Passwords
If you have ever been fortunate enough to have cobbled together a script which automates some menial task to save someone else hours of work, in their eyes, you may seem like Xerxes from the movie 300 (i.e., a god-king).
In this example, let’s say you are writing the script and you are at the point of “just testing to see if it works,” then you suddenly find the script working! You naturally don’t want to break anything, so you leave it as is and head off to make tea, feeling a bit like a triumphant Roman emperor. Soon you have completely forgotten that you hard-coded your own username and password in the script, which unfortunately was a Domain Admin account (this has indeed happened!).
What are the Security Implications?
Overall, this is a bad operational practice and likely goes against company policy. But the real issue is if someone bad gets hold of that script because that person now has your credentials.
Just like what happened at this unfortunate Russian bank:
The source code of the Russian 🇷🇺 Bank @sberbank subdomain (https://t.co/FhJUkJoPyi) has been published on a Telegram group.
Several hard-coded credentials related to APIs and Internal services were found.#Bank #DataLeak pic.twitter.com/K1TZv70Qte
— Bank Security (@Bank_Security) December 3, 2020
It is also worth noting that a red team or penetration testers will be looking for this kind of stuff too (and you really don’t want your name to be on their final report). The same goes for running Windows services as Administrator. While it’s an easy way to get things working, hackers can leverage this for privilege escalation.
Ultimately, the security implications can be detrimental. By misusing their domain credentials, a user is inadvertently exposing the organization to needless risk.
How to Identify Hard-coded Credentials in Your Environment
If you use LogRhythm, you can run a basic search for all logs classified as “Authentication Success” or “Authentication Failure.” Run this over a span of three or four hours and see what you get (you may want to run this for more or less time depending on your log volumes):
Figure 1: A basic search within LogRhythm for authentication logs
Start by looking at the Classification widget, which denotes a count of logs by category:
Figure 2: A of count of authentication logs by type
Then filter by Authentication Failure and look at the User (Origin) chart. This denotes the user logins. In some cases, a problem will be immediately obvious because you will see a large count of failed authentications for a single user account. If that is the case, you may have a situation where user credentials have been used for a script or service, and those credentials have since expired.
If there is nothing obvious, move on to look at the successful authentications. Filter by double-clicking on Authentication Success, and again check out the User (Origin) field. You can also filter out computer or service accounts (those that end with a $) with the following Lucene filter in the LogRhythm dashboard:
originUser:* AND NOT originUser:*$
You may now have something that looks similar to this (albeit with many more usernames):
Figure 3: A count of authentications by user
This is where things start to get interesting. You will probably find that there are large counts of successful authentication events for each user, which can be completely normal. Windows just generates a large amount of authentication events. Use the LogRhythm MPE Rule Name widget to review the Windows event types by count (you may also need to filter on the Windows Security log source type):
Figure 4: A count of logs by Windows Event ID
Here you may find a large count of Windows Event ID 4776 (authentication via NTLM) which could be normal for your environment. Microsoft replaced NTLM with Kerberos for user authentication back in Windows 2000; however, there are still many applications which use the NTLM protocol. Another one you may see is Windows Event ID 4624 Type 3 (network logon). Many of these can be generated when a user opens a document from a file share. You may also see large counts of EVID 4768 or 4769 Kerberos authentication events.
Identifying Abnormal User Behavior — Let the Hunt Begin!
We now need to move into hunting mode, which means we are looking for something that is abnormal when compared to our normal user behavior. For example, one user account which has a higher count of authentication logs than any other user could be considered abnormal. If you are seeing many EVID4776, look at the associated usernames and the source hosts. Do the same for EVID4264. Next, you should compare the counts of these logs and source hosts to that of other users — is it normal? Adjust the search timeframe as necessary.
Figure 5: This shows counts of Windows authentication types for a user
Frequency of occurrences
Remember that we are looking for user credentials misuse in a script or application, which means that we need to manipulate our data to identify repeating patterns that are indicative of automated mechanisms.
A good way of doing this is by using a trend graph, which will show a count of logs over time. If one user stands out, filter your data on that user and look at the trend pattern of authentications events. The example below shows what a normal trend pattern of user authentication events may look like:
Figure 6: A trend graph showing an expected pattern of user authentication logs
The example below shows a pattern of authentication logs which quite clearly indicate an automated mechanism. If this is related to a user account, you definitely want to take a closer look at the host in question:
Figure 7: This trend graph shows a suspicious pattern of user authentications. If this is associated with a user (and not service) account, it is worthy of further investigation.
So, there you have it. Just remember that there are many vagaries when it comes to Windows event logging and this means that many authentication events for a user could be entirely normal; for example, someone leaving a workstation locked or RDP session open, whilst logged into an application such as SSMS (but it’s always worth checking!).
How do YOU check for hard-coded credentials in your environment? Please feel free to share in the comment section below this post!
The post Detecting Hard-Coded Credentials with LogRhythm appeared first on LogRhythm.
*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by Kelsey Gast. Read the original post at: https://logrhythm.com/detecting-hard-coded-credentials-with-logrhythm/
