Video summary

What Happens When You Name a Folder Wrong on Windows — Rémi Gascou - Hackers On The Rocks Podcast

Main summary

Key takeaways

Technology

Main topic

The episode investigates a quirky Windows security flaw where folder name character/parameter injection can break how PowerShell interprets the command created by the built-in “Shift + Right Click → Open PowerShell here” context-menu action. It combines:

  • Windows folder/file naming
  • Character set / delimiter abuse (notably spaces and quotes)
  • PowerShell command-line parsing
  • Windows Registry context-menu configuration

Core technical findings (what goes wrong)

  • On Windows 10/11, naming a folder with specific payload-like text can cause the PowerShell command that Windows builds for “Open PowerShell here” to be parsed incorrectly.
  • The resulting PowerShell errors indicate argument/parameter parsing confusion, where injected text makes the command treat parts of the folder name as command/parameter structure rather than as a literal path.
  • The speaker emphasizes that the vulnerability stems from how PowerShell parses positional arguments/parameters, and how folder names can accidentally (or intentionally) inject syntactic meaning.

Exploitation approach (how this becomes usable)

  1. Initial primitive (needs user interaction)

    • The injection triggers only when a user opens PowerShell via the Shift + Right Click menu on a directory whose name contains the malicious payload.

  2. Making it stealthier / more realistic

    • Instead of putting the payload directly on the visible folder, the research places the payload folder deeper in the path or elsewhere and uses shortcuts so the user right-clicks something that looks benign.
    • The payload may be hidden in parent/ancestor path elements, while Windows Explorer may display only truncated paths (e.g., with “…”), reducing visibility.

  3. Using network shares

    • The speaker notes it can be easier when the payload can be created on a share accessible to the target, and then the target is induced to use a shortcut that leads to the payload directory.

Registry + context menu angle

  • Windows Registry is described as the configuration store for OS and third-party integrations, including context menu entries.
  • Because the registry can be modified by sufficiently privileged attackers, the research discusses manipulating what right-click context-menu actions do—e.g., installing or altering entries such as “Open in PowerShell” or similar launcher behaviors.

Observability / detection notes

  • When exploitation works, the resulting command injection happens inside PowerShell, so spawned processes are child processes of PowerShell.
  • Therefore, defenders can likely observe activity with process inspection tools (e.g., PowerShell/command-line visibility), though the user-facing execution can be masked by the shortcut strategy.

“AI poisoning” / LLM angle (analysis & motivation)

The episode claims the issue has been present for years and that modern AI/LLM systems used for coding assistance can be “poisoned” indirectly:

  • LLMs trained on scraped data (including registry snippets/configs posted online) may generate registry/configuration templates that contain vulnerable command-line patterns.

The speaker’s intent is framed less as “attack AI directly” and more as demonstrating that LLMs can replicate insecure/vulnerable patterns when they appear in training data—especially for third-party context menu integrations that invoke PowerShell.

Disclosure & response (product/security process)

  • The researcher reports:
    • Microsoft denied a CVE and bounty/credit, even though the issue was allegedly fixed silently afterward.
    • The reasoning given was that it wasn’t considered remote and/or was dismissed as too dependent on social engineering (requiring user clicks and a shift+right-click sequence).
  • The emotional takeaway is frustration that the fix occurred, but credit/standard disclosure wasn’t granted.

Related controversy mentioned

  • The episode briefly discusses “Nightmare Eclipse”, described as a Twitter-based researcher who publicly claimed a series of Windows zero-day reports to MSRC and disputes over how MSRC handled them (denied responses/bounties/CVEs), followed by public proof/PR conflict.

Practical “guides/tutorials” called out in the episode

There isn’t a step-by-step defensive tutorial, but the speaker provides a conceptual “how it’s exploited” workflow:

  • Create/select a folder name that injects into PowerShell parsing (payload in name)
  • Use shortcuts or shares to make the interaction socially plausible
  • Optionally rely on path truncation in Explorer to reduce user notice
  • If registry context-menu entries are controllable, modify or rely on context-menu behaviors to reach the vulnerable PowerShell invocation

Main speakers / sources

  • Rémi Gascou (guest researcher) — primary source of the technical findings and disclosure story.
  • Hackers on the Rocks hosts (interviewer[s], unnamed in the subtitles) — ask questions about command injection, registry/context menus, observability, and disclosure.

Original video