Table of Contents
Hello there. This is the second part in a series meant to explain topics related to threats in the Cyber realm. In our previous post, we explored how “ClickFix” has been abused by threat actors. Today, we’re going to explore an evolution of that Initial Access technique, which security researchers think may gain traction.
FileFix
We constantly hear about the “Cat and Mouse game” in information security. With that in mind, defenders aren’t simply waiting for the opponent to make their next move. We’re constantly trying to think ahead and gather information so that we have detections in place when previous techniques are phased out in favor of newer ones.
The community relies on one another in this regard. Recently, a researcher, Mr.d0x, has speculated that this attack may expand to having users enter code into the Windows File Explorer itself.
To fully understand what we’re about to discuss, a brief conceptual explanation of “path” is required. A lot of you may be familiar with the concept, simply using different terminology, like folders. On all Operating Systems, the machine needs a way to locate applications and resources it needs to continue operations. Behind the scenes, each user will have what are known as “environmental variables,” and typically this will include a “path”, or a series of folders, on the file system where the operating system can look for applications or programmatic dependencies. Windows users can view their path by opening PowerShell and executing this command: “$env:PATH” (without quotes).
One of the main path locations for all modern users of Microsoft Windows is “C:\Windows\System32”. Most programs that the operating system needs to function are stored here. When you hear or read about “LOLBins”, this path is where the mainstay of them is stored on disk.
As we just laid the groundwork for, Windows knows where to locate binaries based on the paths set in a user’s environmental variables. Microsoft has gone above and beyond, with an additional feature allowing users to execute any application from the path (yup, the LOLBINs) through File Explorer’s address bar as well. When using this feature, command aliases are acceptable for execution. I.e., typing “cmd” in the address bar of Explorer and key in “enter” for a command prompt to appear with the directory set to the one you are currently browsing (illustrated in Figures 1 – 3).
Figure 1
Figure 2
Figure 3
In addition to the features we’ve just demonstrated, Windows has a built-in protocol known as Search-MS. Search-MS exists for users and administrators to literally search for something using the Universal Resource Identifier (URI), which includes Windows UNC (Universal Naming Convention) file paths. That’s just fancy speak for “URL”.
This may seem innocuous to someone unfamiliar with Windows internals, but it’s quite meaningful. Users can quickly access SMB shares using the File Explorer’s address bar (Figure 4).
Figure 4
How Can Threat Actors Abuse FileFix?
Since threat actors are already proficient at getting a user to paste into the Windows Run dialogue, it’s not a stretch to think they may be able to get users to paste into File Explorer’s address bar. In fact, there are keyboard shortcuts built expressly for this.
The lure would presumably be interesting or required documents, but imagination is the only limit of the method. Mr. d0x released a POC written in HTML code on his site2, which explores how this may work. We adapted the code slightly for our scenarios. The technique abuses similar social engineering similar to ClickFix. Backend code presents a user with a fake site to display benign-looking instructions, which ultimately allow a threat actor to execute malware.
Figure 5
Illustrated in Figure 5, the user is asked to “copy” the location of the document themselves by clicking copy; then paste it into File Explorer’s address bar with keyboard shortcuts and a button which launches File Explorer. Figure 6 displays sample code the user is copying, similar to what we explored in the ClickFix blog.
Figure 6
By inserting a large amount of space between the command and the commented code, which is all that is presented to the user (Figure 7), the attacker hides the portion of the code that will be pasted and executed from the user’s view.
Figure 7
After hitting “enter” the user has executed the command.
Figure 8
Why is this more interesting than regular ClickFix??
Firstly, and more mundanely, an attacker can still trick a user into requesting a remote resource; however, if the attacker builds the functionality VIA WebDav, the initial loader can be made to appear like a legitimate file download to the user. This piggybacks off recent campaigns we’ve seen where the WebDav server hosts an .LNK file for execution. Most of these were initiated in the spring of 2024 and have tapered off, but the tactic isn’t quite dead.
The second issue is credential harvesting. When using Windows UNC (Universal Naming Convention) paths, the remote (attacker) server can subtly request authentication. In an effort to be as smooth and simple to manage large environments as possible, Windows simply obeys this request and sends the users’ NTLM hash to any resource that asks. Unless this is explicitly forbidden VIA administrative hardening in the registry or Group Policy, there is no way to stop this. Unfortunately, Microsoft views this as “a feature, not a bug”, although they are well aware of the issue.
We’ve adapted the POC (Figure 9), abusing the Windows Universal Naming Convention, to reach out to an attacker-controlled server, which will request the NTLM hash of the victim. Displayed below is a mockup of malicious code a threat actor may use to conduct this attack.
Figure 9
The victim will provide this hash with no interaction after the exploit is triggered.
Figure 10
With the hash acquired (Figure 10), an attacker has two options: Crack the password (get the plaintext from the hash) offline and/or potentially perform a Pass-the-Hash (PtH) attack, where cracking the password is unnecessary. Passing the hash is a way to echo the user’s encrypted password back to Windows, skipping a step in the authentication process of converting human-readable plaintext.
Resilience to NTLM Gathering
Administrators have a few methods of stopping NTLM Hashes from making their way into attacker’s hands.
- Enforce Kerberos authentication over NTLM by setting the LAN Manager authentication level to “Send NTLMv2 response only. Refuse LM & NTLM”.
- Use Group Policy or the registry to disable automatic NTLM authentication to untrusted hosts.
- Example GPO: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all
- Use SMB signing and NTLM relay protections (like Extended Protection for Authentication).
- Harden credential storage by using features like Credential Guard and disabling credential caching when possible.
- Use Microsoft LAPS or Windows LAPS to manage local administrator passwords and prevent pass-the-hash attacks.
Settings 1-3 will mitigate NTLM Hashes making their way to attacker-hosted servers. Settings 4 and 5 limit the ability to complete Pass-the-Hash attacks.
Detection Strategy
Detections for FileFix are largely the same as those for Click Fix. We’re listing them here again for anyone who may have missed:
- User Training: Emphasize that legitimate sites will never ask users to paste commands into system dialogs.
- Computer Policies: Harden PowerShell, restrict or disable the LOLBINs used for ingress (e.g., mshta.exe , certutil.exe ) via Group Policy or AppLocker.
- Email & Network Defenses: Implement robust phishing filters, attachment scanning, and intrusion prevention to intercept initial lures hhs.gov.
Administrators may also be able to monitor for NTLM authentication attempts using Event Logs (e.g., Event ID 4624 for Logon Type 3 or 9) to detect anomalies.
Suspicious PowerShell and CMD are the staples of execution for this technique. But recent reports suggest the PHP commands may be spawned from PowerShell as well. In reality, imagination is the only limit on the second stage.
Speaking directly to PowerShell, Methods of ingress vary, but monitoring for suspicious Download Cradles, including “New-Object System.Net.WebClient”, “DownloadFile”, or “.DownloadString” are important methods. Likewise, Invoke-WebRequest, Invoke-RestMethod, and their command flags are important to ingress methods as well.
On the CMD side, resources like https://lolbas-project.github.io/ can help with understanding the myriad ways for ingress.
Conclusion
Thanks for joining us as we continue analysis of current Threat Actors in the wild. Please check back as we will continue to post on new techniques and Intel as it becomes available.
