🔄 Topic

Understanding Squiblydoo, a LOLBin technique that abuses rundll32.exe for script execution.

🎯 Goal

Learn how attackers abuse legitimate Windows binaries and why command-line context matters more than process names alone.

🛠 What I Did

Today I studied Squiblydoo.

Squiblydoo is a known LOLBin abuse technique involving rundll32.exe and script execution through mshtml.

A LOLBin is a legitimate binary already present on the system that can be abused for malicious purposes.

The important binary today was:

rundll32.exe

Rundll32 is a legitimate Windows utility used to run code from DLL files.

Attackers abuse it because it is trusted, common, and already available on Windows systems.

A suspicious Squiblydoo-style pattern may involve:

rundll32.exe
javascript:
mshtml
RunHTMLApplication
script:http://example/payload.sct

The exact command may vary, but the suspicious idea is the same:

A legitimate Windows binary is being used to execute script content in an abnormal way.

🔗 Key Cybersecurity Connections

This matters because attackers often avoid dropping obvious malware.

Instead, they use built-in Windows tools.

This is called living off the land.

The defender’s mistake would be to say:

rundll32.exe is a Microsoft binary, so it must be fine.

That is weak analysis.

The stronger SOC question is:

What is rundll32 executing, who launched it, and what happened next?

Suspicious signs include:

  • rundll32 executing script-related content
  • rundll32 launched by Office
  • rundll32 connecting to the internet
  • rundll32 using strange command-line arguments
  • rundll32 spawning PowerShell or cmd
  • rundll32 touching temporary directories
  • rundll32 associated with remote payload retrieval

🔍 Investigation Questions

  • What launched rundll32.exe?
  • What command-line arguments were used?
  • Is mshtml involved?
  • Is javascript involved?
  • Is RunHTMLApplication involved?
  • Is there a remote URL in the command line?
  • Did rundll32 create a network connection?
  • Did it spawn PowerShell, cmd, or another child process?
  • Which user executed it?
  • Is this normal for the host?
  • Did an email attachment or browser download happen before execution?

🚨 Detection Opportunities

Possible detection ideas:

  • rundll32.exe with javascript in command line
  • rundll32.exe with mshtml in command line
  • rundll32.exe with RunHTMLApplication
  • rundll32.exe connecting to external IPs
  • rundll32.exe launched by Office applications
  • rundll32.exe spawning PowerShell or cmd
  • rundll32.exe executing content from remote URLs
  • abnormal rundll32 activity from user directories

Example detection pattern:

process=rundll32.exe
command_line contains "javascript:"
command_line contains "mshtml"
network_connection=true
suspicion=possible_squiblydoo

This is much stronger than alerting on rundll32.exe alone.

🧭 MITRE ATT&CK Techniques

  • T1218.011 — Rundll32
  • T1059 — Command and Scripting Interpreter
  • T1105 — Ingress Tool Transfer
  • T1027 — Obfuscated Files or Information
  • T1204 — User Execution

🗺 Visual Investigation Diagram

User opens file or link
    ↓
Parent process starts rundll32.exe
    ↓
Suspicious script argument used
    ↓
Remote payload requested
    ↓
Child process or network activity follows
    ↓
SOC investigates command line and process tree

⚠ Challenges

The main challenge is that rundll32.exe is normal on Windows.

It appears in legitimate activity.

That means defenders cannot treat every rundll32 event as malicious.

The command-line arguments and process relationships are what make the difference.

Bad detection:

Alert whenever rundll32.exe runs

Better detection:

Alert when rundll32.exe runs with script-related arguments, remote URLs, or suspicious parent-child relationships

📚 What I Learned

I learned that LOLBin abuse depends on context.

The binary may be legitimate, signed, and trusted.

The behavior may still be malicious.

This is why command-line logging is critical.

Without command-line visibility, Squiblydoo-style activity becomes much harder to detect.

➡ Next Steps

  • Study other LOLBins such as regsvr32, mshta, wmic, and installutil
  • Practice reading Windows process trees
  • Build fake rundll32 detection examples
  • Learn normal rundll32 usage
  • Compare suspicious arguments with legitimate ones
  • Add a LOLBin section to my detection notes

🧠 Reflection

This topic made one thing very clear:

Attackers do not always bring their own tools.

Sometimes they use the tools already inside the house.

That makes detection harder, but also more interesting.

The process name is only the start of the investigation.

🧩 Lessons Learned

What worked

Focusing on command-line arguments instead of only process names.

What broke

Assuming legitimate Windows binaries are automatically safe.

Why it broke

Attackers deliberately abuse trusted binaries to blend into normal activity.

Fix / takeaway

For LOLBins, investigate the full process context:

  • parent
  • command line
  • user
  • network activity
  • child processes

📈 Skill Progression Context

This builds detection engineering skills because LOLBin abuse is common in real endpoint alerts.

Learning to distinguish normal administrative use from malicious abuse is a core SOC skill.

😄 TL;DR

Rundll32 is not suspicious because it exists.

It becomes suspicious when it starts acting like a delivery truck for remote scripts.