Unveiling LOLBins: Living off the land binaries part 2

| By:
Al Calleo

In part 2 of our blog series and continued exploration of the intricate landscape of LOLBins, we venture deeper, casting a spotlight on several commonly abused binaries: Rundll32, Regsvr32, Mshta, and Cscript.

These system tools, designed to streamline processes and accomplish various system tasks, have been contorted for malicious intent by threat actors, further emphasizing their dual-edged nature.

To reiterate from the first installment of the blog series, LOLBins, short for living off the land binaries, are binaries that are typically signed by Microsoft and pre-installed on Windows systems or available to download from Microsoft’s website. This ubiquity, combined with their genuine purposes, makes LOLBins an appealing tool for threat actors, allowing them to blend in with legitimate processes and thereby evade detection.

Crafty adversaries understand the benefits of being inconspicuous. Introducing foreign malicious tools onto a target system demands bypassing an array of cybersecurity mechanisms such as endpoint detection and response (EDR) and intrusion detection systems (IDR)—which can be a daunting hurdle. LOLBins, however, present a convenient shortcut. Given their native presence on systems, threat actors can manipulate these tools for nefarious purposes without raising many red flags.

 As we peel back the layers, the significance of understanding these binaries becomes increasingly evident. Their potential misuse can overshadow their legitimate functions, underscoring the importance of continuous monitoring and cybersecurity vigilance.


Rundll32.exe is a versatile Windows utility used for command line execution of functions embedded in a DLL. Traditionally, DLLs are libraries containing code, data, and resources that multiple applications can use concurrently. While these libraries cannot be executed directly, Rundll32 allows specific instructions inside them to be invoked. This can be particularly useful for settings and configuration operations that must be triggered from the command line or other scripts.

rundll32.exe shell32.dll,Control_Rundll, timedate.cpl

Figure 1: Typical Rundll32 activity

In the activity above, we can see that Rundll32 is referencing “shell32.dll”, a DLL file containing a variety of Windows shell API functions. After that, we see the function “Control_Rundll” being called, which is used to launch control panel applets. Then, at the end of the command, we see “timedate.cpl” being called, which is the control panel applet for date and time properties. This command will result in the display of the Windows date and time properties.

rundll32.exe C:\Users\[User]\AppData\Roaming\Microsoft\Kyuqya\tolawlra.dll",XS88

Figure 2: Observed malicious Rundll32 activity

When comparing the two activities, we can observe the typical behavior using local DLLs to perform legitimate tasks, while the malicious behavior might invoke unexpected local DLLs with suspicious arguments and sometimes might reach out to remote sources. In the malicious activity, we can see them reference a function by the name of “XS88,” which is likely a nondescriptive function name given by the threat actors to make this activity seem a bit more innocuous.

23-DMDG-1390 - BlogImage1_Figure3.png

Figure 3: Rundll32 POC lab activity

In the lab activity above, you can see that we used Rundll32 to run our custom DLL with the argument “entrypoint,” which refers to a specific function within the calctest.dll that Rundll32 is being directed to call and execute.

In the hands of malicious actors, Rundll32 can serve as an indirect method to launch embedded payloads within DLLs. Instead of running an innocuous function like launching the calculator application, a nefarious DLL could perform a myriad of malicious attacks, such as running malware, establishing a reverse shell, or downloading further malicious payloads. Rundll32 is one of the more popularly abused LOLBins. Gamarue has been observed using Rundll32 execution with long file names and random function names.


Regsvr32.exe, or “Microsoft register server,” is a tool for registering and unregistering object linking and embedding (OLE) controls, like DLLs and ActiveX controls in the Windows registry. These controls can extend the functionality of Windows and enable features like embedded videos in web pages or direct interaction with hardware devices. By registering these controls, they are made accessible to applications without the need for additional steps. This functionality is primarily used for troubleshooting and software development scenarios.

regsvr32.exe /s scrrun.dll 

Figure 4: Typical Regsvr32 activity

In the activity above, we can see that Regsvr32 is silently registering the “scrrun.dll” file. Scrrun.dll is a DLL file part of the Microsoft script runtime library. It provides various functionalities through scripting languages like VBScript. This command will provide functions within the scrrun.dll file to be used by various processes.

regsvr32.exe "C:\Users\[User]\AppData\Local\Temp\4\radF1C26941Fdar\IlRKOEJjrXrYmguyv3q.dll"

Figure 5: Observed malicious Regsvr32 activity

regsvr32 /s /n /u /i:// scrobj.dll

Figure 6: Observed malicious Regsvr32 activity

Under close observation, legitimate uses of Regsvr32 tend to interact with familiar or trusted DLLs locally, whereas malicious instances might point to remote scripts or unusual DLLs. For instance, the use of a .sct file—a scriptlet file, which is a feature in Windows scripting—from a remote source is a strong indication of a deviation from normal Regsvr32 behavior.

23-DMDG-1390 - BlogImage2_Figure7.png

Figure 7: Regsvr32 POC lab activity

When observing our lab activity, you can see that we’re using Regsvr32 to silently load our calc test DLL. This silent approach ensures that no noticeable message boxes or alerts pop up, making the process discreet and less likely to alert the user to the potential malicious activity that is occurring. In a real-world threat scenario, an attacker might use this technique to quietly load and execute malicious code embedded within a DLL.

This can lead to the deployment of ransomware or other malicious tools while minimizing their footprint and avoiding raising suspicions. APT hacking group Dragon Breath has been observed using this technique.


Mshta.exe is a utility that is used to execute Microsoft HTML applications (HTA). An HTA runs as a fully trusted application and, as a result, will execute scripts using the current user’s privileges, unlike the limited rights usually given to web-based scripts. HTAs are treated like any other executable, but the danger here is that this trust level can be misused by malicious scripts, giving them unrestricted access to system resources.

mshta.exe "C:\Program Files\HP\HP PageWide Pro 477dw MFP\Bin\HPSPProgress.hta" -

Figure 8: Typical Mshta activity

In the activity above, we can see that Mshta is being used to execute an HTA file related to a Hewlett Packard printer with an additional parameter, “lang_id,” which is likely referencing a specific language. This command is also likely related to the installation of some sort of functionality with an HP printer.

mshta.exe "C:\Users\[User] \AppData\Local\Temp\OneNote\16.0\Exported\{1AC036EC-C14F-4F5F-869D-75A5BCE3EDBF}\NT\0\attachment.hta" {1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}{1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}

Figure 9: Observed malicious Mshta activity

In the malicious activity above, we can see that Mshta is being used to execute an HTA file that was created as a result of a malicious OneNote document. This activity is unusual, as we wouldn’t typically see an HTA file in a OneNote export directory.

While OneNote can have attachments and scripts, executing them directly like this is not typical behavior that one may observe. This Mshta technique was popular with Qakbot earlier this year. The distinction between benign and malicious activities using Mshta lies in the source and content of the HTA. Standard operations engage with known, local HTA files, but malicious activities may involve remote and potentially harmful HTA files or use obfuscated commands.

23-DMDG-1390 - BlogImage3_Figure10.png

Figure 10: Mshta POC lab activity

In the activity above, you can see that we are using Mshta to execute our crafted HTA file that contains a script that launches calc.

In a real-world threat scenario, an attacker could use Mshta to reference or trigger another executable or script present on the targeted system, possibly one previously dropped by an attacker or downloaded from a malicious website. This can serve as a stepping stone in multi-stage attacks, where the initial exploit provides a foothold and subsequent payloads, like the one potentially delivered via the HTA, further the attacker’s objectives.


Cscript.exe is part of the Windows script host (WSH), enabling users to run scripts from the command line. It supports scripts written in VBScript or Jscript. Unlike Wscript.exe, which is designed to support GUI interactions, Cscript is designed to run in a command-line environment. Cscript allows you to automate tasks without additional GUI popups, making it more suitable for background or scheduled tasks.

cscript.exe /nologo "MonitorKnowledgeDiscovery.vbs”

Figure 11: Typical Cscript activity

In the activity above, we can see that Cscript is being used to execute a script called “MonitorKnowledgeDiscovery.vbs,” a Microsoft script related to Azure, with the “nologo” option, denoting notification box and banner suppression. This command is likely performing some sort of task related to Microsoft Azure.

cscript  //nologo "C:\Users\[User]\AppData\Local\Temp\4\_.vbs"

Figure 12: Observed malicious Cscript activity

When comparing the typical and malicious activity, in our observed malicious example, we can see that while there is also notification box suppression, the VBS file is being executed from a temporary directory with no specific determination of what this script does or where it originated from.

Determining benign vs. malicious behavior Cscript activity can be tricky, as the difference between regular and suspicious Cscript behavior often lies in subtle cues. Recognizing unusual directories or the intent to suppress banners and messages can be the key to identifying a potential cybersecurity incident, and monitoring for these deviations from established benign scripts and behaviors can be pivotal in the timely detection of malicious endeavors.

23-DMDG-1390 - BlogImage4_Figure13.png

Figure 13: Cscript POC lab activity

In our lab activity, we used Cscript to execute a VBS file that launched the calculator application. In a real-world threat scenario, an attacker might use Cscript to run a malicious script, potentially one embedded within a seemingly innocuous document, like Gamaredon. These scripts could perform a myriad of tasks, from setting up backdoors and keyloggers to downloading additional payloads or even orchestrating lateral movement within a network.

Preventative measures

There are several steps you can take to prevent this misuse of LOLBins by potential threat actors. This includes:

  • Disabling or removing any unneeded LOLBins
  • Implementing application safelisting to restrict the execution of LOLBins
  • Limiting the permissions of LOLBin utilities
  • Monitoring and alerting on suspicious command line arguments for LOLBins
  • Monitoring or blocking outbound connections for LOLBins to limit communication


Our deep dive into the nuanced world of LOLBins illuminates the undeniable significance of these binaries in the modern threat landscape. While designed for legitimate system tasks, these binaries are powerful tools in the hands of sophisticated adversaries, capable of bypassing traditional defenses and obfuscating their tracks.

One of the critical lessons from our investigation is the thin boundary that separates legitimate from malicious usage. Whether it’s Rundll32 invoking unusual DLLs, Regsvr32 pulling scripts from remote sources, Mshta executing potentially harmful HTA files, or Cscript running scripts in the background, the patterns are evident. Threat actors continue to rely on these binaries to “live off the land,” blending into legitimate system activity and thereby reducing their detection footprint.