Detecting Malicious Use of LOLBins

Background

More than once, those within the cybersecurity community have shared that malicious threat actors employ native Windows utilities, also known as LOLBins or LOLBAS, to “bypass detection” and “blend in with legitimate activity.” Huntress analysts have identified, and continue to see, incidents involving the use of native utilities by threat actors. They can show how, with just a small amount of effort, impacted organizations can discern and better understand the impact of these efforts on their infrastructure. By looking at how LOLBins are used for both legitimate and malicious purposes, we can begin to see valuable detection opportunities. Discerning the difference between legitimate and malicious use of native utilities, and exploiting these differences for detection opportunities, allows us to disrupt the threat actor’s activities much earlier in the attack chain. 

‍

Creating a User Account

On Windows endpoints, there are a number of ways to create user accounts. User accounts can be created and managed via PowerShell, WMI, or the Local User and Groups Manager, as illustrated in Figure 1.

‍

By clicking on “Users” in the Local Users and Groups Manager, and selecting “New User,” you’ll see the new user dialog illustrated in Figure 2.

‍

Completing the New User dialog form and clicking “Create” will cause the new user account to be created. In addition, there are a number of commercial products available that can be used within an organization to create and manage large groups of user accounts, across an entire infrastructure.

Another means for creating user accounts involves the native utility, [.highlight]net.exe[.highlight]. Many administrators use this LOLBin to create, manage, and remove user accounts. Threat actors do so as well. 

When it comes to detecting the malicious use of native utilities such as [.highlight]net.exe[.highlight] to create user accounts within your organization, the first step is to understand whether or not your administrators use the native utility as part of normal operations and workflow. If they don’t, there you go…that’s your detection opportunity right there. Whenever you see [.highlight]net.exe[.highlight] being run with arguments such as [.highlight]user[.highlight], [.highlight]localgroup[.highlight], or [.highlight]add[.highlight], then you can likely assume that the use of the LOLBin is malicious in nature.

If your organization does use [.highlight]net.exe[.highlight] to create user accounts, do you have specific administrators who do so, from a specific endpoint? Is a specific account used to create and manage user accounts, from a specific system? If so, any activity outside of those guardrails should be considered, at the very least, suspicious in nature and afforded a closer look. 

Another aspect regarding the use of native utilities is how those utilities are launched. One common means for doing so is for administrators to log into a system, open a command prompt, and type the command (illustrated in Figure 3), or run the command from a batch file.

‍

In this case, the process lineage has [.highlight]cmd.exe[.highlight] as the process parent and [.highlight]Explorer.exe[.highlight] (the Windows Explorer shell) as the process grandparent. Any observed command line where the process parent or grandparent is [.highlight]wmiprvse.exe[.highlight] (indicating that the command was run over a type 3 remote network connection), [.highlight]PSExec.exe[.highlight] (free Microsoft utility for privilege escalation), or [.highlight]sqlservr.exe[.highlight] (MS SQL Server) should therefore be considered malicious. 

Something else to consider is the convention used for usernames and passwords for new user accounts within your organization. If what you’re seeing in the suspicious activity differs from this convention, then it’s likely that the activity is malicious. For example, if your organization uses a naming convention for new user accounts that includes a reference to a department or team, or consists of the user’s first name and last name (together, or separated with a “.”), then any new user accounts created that don’t follow that convention should be considered malicious. 

Yet another aspect to help identify the malicious use of the [.highlight]net.exe[.highlight] LOLBin is the structure of the command line itself. Many times when [.highlight]net.exe[.highlight] is used legitimately, the structure of the command line appears as follows:

Note that the [.highlight]/add[.highlight] switch, for creating a new user (not using the switch changes the password of the user account), falls at the end of the command line. However, it doesn’t have to; this is simply a convention that many administrators tend to follow. 

Earlier this year, Huntress analysts observed the following command line being used to create user accounts on several incidents, against multiple customers:

[.highlight]net  /add user WDAGUtilltyAccount Ujmqaz5055 /y[.highlight]

Note the subtle misspelling of the username, with the second “[.highlight]l[.highlight]” that should be an “[.highlight]i[.highlight].” Huntress analysts also observed the following command line employed on a customer network during June 2023:

[.highlight]net /add user ASP.NET Ujmqaz5055[.highlight]

Note that the use of this password by threat actors has also been observed by others, and similarly reported.

Huntress analysts have also been able to capture a number of usernames and passwords seen repeatedly used by threat actors over a considerable period. One example of a commonly used password is from the previous example: [.highlight]Ujmqaz5055[.highlight]. Other observed examples include [.highlight]P@ssw0rd01![.highlight], [.highlight]Nullpass123[.highlight], [.highlight]JapanNight!128[.highlight], and [.highlight]Noface66Nocase![.highlight].

Examples of usernames commonly observed used by threat actors include [.highlight]adm[.highlight], [.highlight]sqladmin[.highlight], [.highlight]Adminstrator[.highlight] (note the missing “i”), [.highlight]installl[.highlight], and [.highlight]backupsql[.highlight].

‍

Conclusion

A threat actor’s use of LOLBins does not mean that it’s “game over” for the defender, nor for the impacted organization. Using native utilities doesn’t have to mean that a threat actor’s activities blend in with legitimate activity. In fact, with a little thought, and just a bit of foresight, the threat actor’s use of those native utilities can instead be exploited as a detection opportunity, allowing defenders to disrupt the threat actor’s activities much earlier in the attack chain. Understanding who uses those utilities, when, how they use them, and from which endpoints within the infrastructure presents a number of valuable opportunities to inhibit or even obviate attacks.

‍