Published by The RSM Defense Threat Hunting Team
Author: Justin Dolgos – Sr. Threat Hunter
MITRE ATT&CK: T1204.002 · T1059 · T1218 · T1219 · T1222
| ⚠ TLDR Executive Summary
Our threat hunters built a custom detection that fires the moment a browser or Windows Explorer spawns a script or suspicious executable from a user-writable directory. In a recent real-world engagement, it was the only alert that fired, catching an active intrusion that no native tooling flagged. The payload deployed two remote-access tools, modified firewall rules, and attempted to establish persistence. The threat was identified, contained, and remediated before it became a breach. No lateral movement. No confirmed exfiltration. |
The Threat: Browser-Delivered Malicious File Execution
Social engineering has never gone out of style. At its core, the most effective delivery chains in use today share a single moment of exploitation: a user opens a browser, encounters something that looks legitimate, downloads a file, and runs it. The 2025 Verizon Data Breach Investigations Report found that the human element was a factor in roughly 60% of all confirmed breaches.
The incident described in this post is consistent with a malicious file delivery via social engineering, a pattern where a threat actor uses a trusted brand, an expected workflow, or an urgent prompt to convince a user to download and execute a file. The file lands in a user-writable directory like Downloads or Temp. The user runs it. The attack begins.
What makes this pattern so durable is that it requires no vulnerability, no exploit, and no elevated privileges. It only requires a convincing enough reason for a user to interact with a download, whether the browser launches the file directly or the user opens it themselves. The attacker’s investment is entirely in the lure. The execution happens on the victim’s own terms, through normal Windows behavior, which is precisely why so many endpoint tools miss it.
| 🔍 The Behavioral Choke Point
Regardless of the specific lure, brand, or file format used, malicious file delivery chains all converge on the same moment: a script or executable spawned from a browser-writable directory with a browser or Explorer as the parent process. That single behavior, occurring before any C2 connection, before any persistence, and before any lateral movement, is what this detection targets. |
What the Detection Looks For
Our detection is composed of three distinct but complementary logic branches, each targeting a different stage or variant of browser-delivered script execution. Together they cover both direct browser-to-script-host chains and the broader case of any suspicious executable spawning from a user-writable path.
Branch 1 — Browser-Spawned Script Host Execution
This branch fires when a known Windows script interpreter, specifically wscript.exe or cscript.exe, is launched as a direct child process of a web browser (Chrome, Firefox, Edge, or Internet Explorer). The detection also requires that the script being executed lives in the Downloads or Temp directory and carries a script extension (.vbs, .js, .jse, or .wsf).
The only intentional exclusion is legitimate Microsoft Office automation: if Excel is launching the script through its own COM automation channel (the /automation -Embedding flag), the rule stands down. This prevents noise from normal macro-enabled Office workflows while keeping the rule tight for everything else. (We’ve created a separate rule for macros)
Why it matters: No legitimate browser workflow results in wscript.exe or cscript.exe being spawned directly from the browser process. This behavior is almost exclusively associated with malware delivery.
Branch 2 — Suspicious Executable Launched from a Writable Path via Browser/Explorer
Rather than looking at the script interpreter, this branch watches the process image path itself. If an executable with a script or script-adjacent extension, .scr, .bat, .cmd, .ps1, .vbs, or .js, is running directly out of Downloads, Temp, or AppData\Local\Temp, and its parent process is a browser or Windows Explorer, the detection fires.
The inclusion of Windows Explorer alongside browsers is intentional: many social-engineering chains end with the user opening File Explorer, navigating to Downloads, and double-clicking the file. Explorer is the trusted parent in that scenario, so it must be covered.
The .scr extension deserves a special callout. Screen saver files are standard Windows PE executables, they are functionally identical to .exe files but carry a different extension. Threat actors abuse .scr specifically because it looks innocuous to non-technical users and bypasses some extension-based defenses.
Branch 3 — Catch-All: Writable-Path Execution from Browser or Explorer
The third branch is a deliberate catch-all that repeats the executable-from-writable-path logic to ensure coverage even when process lineage data is incomplete or when telemetry gaps exist between Branches 1 and 2. Defense in depth applies to detections too, if a sensor misses the parent-child link, this branch can still surface the event based purely on the file path and extension.
A Real-World Catch: The DocuSignAccess.scr Incident
The value of a detection rule is proven when it fires on something real. Here is a recent case from our hunting operations where this detection caught an active intrusion in progress.
Initial Execution
DocuSign is one of the most widely used e-signature platforms in business. At any given time, employees across virtually every organization are waiting on a DocuSign envelope, a contract to be countersigned, an HR document, an NDA, or a vendor agreement. Threat actors know this. A lure referencing DocuSign does not need to be perfectly crafted; it simply needs to arrive at the right moment, when the target is already expecting something.
The most likely scenario here is a phishing or malvertising delivery that landed while the user had an active or recently completed DocuSign workflow. The victim received an email or was redirected to a page notifying them that a document was ready for access or required a viewer to open. The page or email presented a download link for what appeared to be a DocuSign access tool or document launcher, a believable premise, since DocuSign does occasionally prompt users to download files or certificates for certain document types. The user clicked the download link and, when prompted by Chrome, opened the file directly from the browser. The filename was convincing enough on its own. For a user expecting a legitimate DocuSign file, DocuSignAccess sounds like exactly what they were waiting for. There was no prompt, no warning that looked alarming, and no reason to pause. From the user’s perspective, they were completing a routine business task.
This is precisely what makes social-engineering file delivery so effective and so dangerous. The social context, an expected document, a trusted brand, a familiar workflow, does the heavy lifting. The malware just has to get out of the way. Log telemetry confirmed that DocuSignAccess.scr was launched directly by chrome.exe, placing it squarely in the scope of Branch 1 of our detection: a browser process spawning an executable with a script-adjacent extension from a user-writable directory. Our detection fired immediately when DocuSignAccess.scr was launched, before any payload had a chance to establish itself.
Payload: JWrapper-Based Remote Access (SimpleHelp)
The .scr executable was a JWrapper-packaged installer for SimpleHelp, a legitimate commercial remote-access product. Threat actors frequently abuse legitimate RMM (Remote Monitoring and Management) tools because they are signed, known-good applications that bypass many endpoint defenses and blend into environments that legitimately use them. The executable dropped and launched the following components:
- Remote Access Service.exe, the core SimpleHelp service binary
- Remote Access.exe, the client-facing access binary
- Remote AccessLauncher.exe, the launcher stub responsible for spawning the service
- exe, a utility to terminate competing gateway services
Permission Staging with icacls
Following installation, the malware invoked icacls.exe twice in rapid succession. This is a key behavioral indicator: legitimate software installers do not typically need to manipulate ACLs immediately after installation in the current user session.
| icacls “C:\ProgramData\JWrapper-Remote Access” /t /remove *S-1-1-0
icacls “C:\ProgramData\JWrapper-Remote Access\JWApps” /t /c /grant *S-1-5-32-545:(OI)(CI)RX |
The first command removes all permissions for Everyone (SID S-1-1-0) from the JWrapper directory tree, likely to lock out other users from modifying or removing the implant. The second command grants Read & Execute permissions to the local Users group (SID S-1-5-32-545) with object and container inheritance (OI)(CI), ensuring the remote-access binaries can run under any standard user account without requiring elevation. Together, these two commands stage the implant to survive reboots and prevent casual removal.
Firewall Rule Manipulation
The implant called netsh advfirewall to add explicit inbound allow rules for both the launcher and the service binary, ensuring inbound remote-access connections would not be blocked by the Windows host firewall:
| netsh advfirewall firewall add rule “name=SH Remote Access Service Launcher” dir=in action=allow “program=…\Remote AccessLauncher.exe”netsh advfirewall firewall add rule “name=SH Remote Access Service” dir=in action=allow “program=…\Remote Access.exe” |
Immediately following the firewall modifications, the implant called netsh advfirewall firewall show rule name=all, enumerating all existing firewall rules. This is a standard recon step to verify the new rules took effect and to profile the host’s existing security posture.
Wireless Reconnaissance
netsh wlan show interfaces was executed to enumerate the host’s wireless network adapters and current SSID. This is a classic host-profiling step performed by remote operators to understand the network environment they have landed in, particularly useful for determining whether the host is on a corporate network or a home/guest connection.
Security Product Enumeration
wmic.exe /namespace:\\root\SecurityCenter2 PATH FirewallProduct get was used to query the Windows Security Center for installed firewall and security products. This tells the operator exactly what endpoint protection is present before deciding how to proceed with the attack.
Hidden PowerShell Execution
A PowerShell script was executed with a fully evasive command line:
| PowerShell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive
-WindowStyle Hidden -file SC-2-1771251036650-h9fse2tf.ps1 |
The flags used here are a near-canonical malware PowerShell invocation: -ExecutionPolicy Bypass disables script execution restrictions; -NoLogo -NonInteractive suppress any UI; and -WindowStyle Hidden ensures no console window appears. The randomized filename (SC-2-1771251036650-h9fse2tf.ps1) is consistent with dynamically generated ScreenConnect staging scripts, confirming that ScreenConnect was being deployed as a second remote-access tool alongside SimpleHelp, a redundancy tactic threat actors use to ensure continued access if one RAT is discovered and removed. This matters: even if an analyst identifies and kills SimpleHelp, a second foothold is already waiting.
Containment and Outcome
When the detection fired, it was the only alert in the environment. No native tooling, no platform default rule, no other detection of any kind generated a signal on this activity. This custom rule, built specifically because our hunters identified a behavioral gap that nothing else was covering, was the sole point of visibility into an active intrusion.
Our SOC analysts reviewed the alert, assessed the dynamic behavior of the payload, confirmed malicious intent, and executed containment: the threat was killed, the endpoint quarantined, all changes made by the payload reversed, and network connections blocked. Both remote-access tools were fully removed, and the environment was restored to a clean state.
No lateral movement was observed. A thorough review of available logs found no confirmed exfiltration of data or credentials. The intrusion was contained before it became a breach. Without this detection, there would have been no alert.
MITRE ATT&CK Mapping
| Tactic | Technique | ID |
| Initial Access | User Execution: Malicious File | T1204.002 |
| Execution | Command & Scripting Interpreter | T1059 |
| Execution | System Binary Proxy Execution (LOLBin) | T1218 |
| Defense Evasion | Modify File/Directory Permissions (icacls) | T1222.001 |
| Persistence | Remote Access Software (SimpleHelp/ScreenConnect) | T1219 |
| Command & Control | Remote Access Tools | T1219 |
Why This Detection Matters for Your Organization
Malicious file delivery via social engineering is consistently among the top initial-access vectors reported across every industry vertical. It is active, high-volume, and not slowing down. And because this detection targets the underlying execution behavior rather than any specific campaign signature, file type, or lure theme, it is positioned to catch the full range of threats that converge on this pattern, including techniques and variants that have not been named yet.
What makes this detection particularly high-value is its position in the kill chain. It fires the moment a file executes from a user-writable directory, before any C2 beacon is established, before persistence is written, and before lateral movement begins. That is the earliest possible intervention point. In the DocuSign incident, it was also the only alert that fired across the entire environment. A thorough post-incident review confirmed no other tool, platform rule, or detection of any kind generated a signal on this activity. One custom detection was the difference between a contained incident and a breach that went undetected.
Attackers are acutely aware that endpoint detection improves after the first network connection. That is precisely why social-engineering delivery chains invest so heavily in making the initial lure look legitimate. Catching them at execution, regardless of how convincing the lure is, neutralizes that investment entirely.
If You’re Not Hunting, You’re Dying
This detection did not come from a vendor feed. It did not arrive pre-packaged in a tool. It was built by a hunter who went looking for something that wasn’t being caught and found it.
That distinction matters. Every major endpoint and SIEM platform ships with a default rule set. Those rules are broad, vendor-maintained, and tuned to minimize false positives across thousands of different customer environments. They are designed for the average organization. But sophisticated attackers do not target the average organization, they target yours. And they have already studied what those default rules catch.
At RSM Defense, our philosophy is simple: every threat hunt should end with a detection. When our hunters go into a customer environment, whether chasing a hypothesis, investigating an anomaly, or responding to a new threat intel report, they are not just looking for active threats. They are actively asking: “Is there a behavior happening right now that nothing is alerting on?” When the answer is yes, we engineer a custom detection to close that gap, purpose-built for that customer’s environment, tuned to their telemetry, and validated against their specific baseline. That detection gets deployed. It stays deployed. And it fires the next time the same technique shows up, whether it’s a known campaign or a new one borrowing the same playbook.
The detection featured in this post is a direct product of that process. Our hunters identified that browser-spawned script execution from writable user directories was a behavioral gap that nothing in the environment was alerting on. They built the rule, validated it, and deployed it. When a real intrusion hit, it was the only signal that fired. Two RATs deployed, firewall rules modified, remote access tools staging, and the entire environment’s native detection stack stayed silent. One custom rule saw it. Our SOC contained it before it became a breach. This is one rule. RSM Defense has engineered over 300 custom detections across our customer environments, each one a direct output of a hunt that found something no existing rule was catching.
The uncomfortable truth about modern threat detection is that the gap between what your tools detect by default and what attackers are actually doing grows every day. Threat actors are not standing still. They are actively testing their techniques against commodity detection stacks, iterating on what gets flagged, and deliberately engineering their tooling to fall into blind spots. Social-engineering delivery works precisely because it routes around the controls that assume malware arrives via exploit or network intrusion. A user running a file is expected behavior, and expected behavior requires context to become a detection. Building that context, tuning it to a specific environment, and keeping it current as techniques evolve is not something any off-the-shelf rule set can do on its own. That is the work. These are not accidents, they are deliberate evasions of the default detection layer and closing them requires someone who is actively looking.
Threat hunting is how you close that gap. Not reactively, waiting for an alert that may never come, but proactively, going into your environment with a hypothesis, looking for evidence of techniques that should not be there, and turning every finding into durable detection logic that raises the cost for the next attacker who tries the same thing.
| 🎯 The RSM Defense Hunt-to-Detection Commitment
Every engagement our team conducts follows a hunt-to-detection workflow. When our hunters identify a behavioral gap, something that is happening in your environment and not generating an alert, we engineer a custom detection to close it before we close the engagement. That detection is tuned to your environment, validated against your telemetry, and maintained as the threat landscape evolves. RSM Defense has deployed over 300 custom detections across our customer base, with more added after every hunt. The goal is not just to find what’s in your environment today. It’s to make sure you catch it yourself tomorrow. |
Appendix: Sigma Rule
For the detection engineers and security operators reading this post, the following Sigma rule represents the logic described above. This is shared in the spirit of community defense, raise the baseline for everyone. The custom detections RSM Defense builds for customers go beyond single rules: they are tuned to each environment’s specific telemetry, baselining, and threat profile, and are continuously maintained as the landscape evolves.
| title: Browser or Explorer Spawned Script/Executable from Writable Path id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: experimental description: > Detects script interpreters or suspicious executables launched by a web browser or Windows Explorer from user-writable paths (Downloads, Temp, AppData\Local\Temp). Targets browser-spawned malicious file execution; covers social-engineering file delivery via browser or Explorer parent. references: – https://attack.mitre.org/techniques/T1204/002/ – https://attack.mitre.org/techniques/T1059/ author: ‘RSM Defense Threat Hunting Team’ date: 2025/01/01 tags: – attack.execution – attack.t1059 – attack.t1204.002 – attack.t1218 – attack.initial_access logsource: category: process_creation product: windows detection: # Branch 1: Browser spawns wscript/cscript on script in Downloads or Temp browser_script_host: ParentImage|endswith: – ‘\chrome.exe’ – ‘\firefox.exe’ – ‘\msedge.exe’ – ‘\iexplore.exe’ Image|endswith: – ‘\wscript.exe’ – ‘\cscript.exe’ CommandLine|contains: – ‘Downloads’ – ‘Temp’ CommandLine|contains: – ‘.vbs’ – ‘.js’ – ‘.jse’ – ‘.wsf’ # Branch 2 & 3: Script-like executable launched from writable path writable_path_exec: ParentImage|endswith: – ‘\chrome.exe’ – ‘\firefox.exe’ – ‘\msedge.exe’ – ‘\explorer.exe’ Image|re: ‘.*\.(scr|bat|cmd|ps1|vbs|js)$’ Image|contains: – ‘\Downloads\’ – ‘\Temp\’ – ‘\AppData\Local\Temp\’ condition: (browser_script_host or writable_path_exec) # Exclude: legitimate Office COM automation filter_office_automation: TargetCommandLine|re: – ‘”?C:\\Program Files\\Microsoft Office\\Root\\Office[0-9]{1,}\\EXCEL\.EXE”? /automation -Embedding’ falsepositives: – Legitimate Office COM automation (excluded via filter above) – Custom enterprise software that self-extracts to Temp and auto-runs – Developer workflows running local scripts from Downloads level: high fields: – Image – ParentImage – CommandLine – User – ProcessId |
References
The following primary sources were used in the preparation of this post. Statistics and threat intelligence claims are cited directly from these publications.
[1] Verizon Data Breach Investigations Report 2025Source of the finding that the human element was a factor in roughly 60% of all confirmed breaches in 2025, consistent with prior years. Based on analysis of 12,195 confirmed data breaches across 139 countries. https://www.verizon.com/business/resources/reports/dbir/
[2] Microsoft Digital Defense Report 2025
Source of the finding that 28% of breaches were initiated through phishing or social engineering as the initial access vector. Based on Microsoft Incident Response telemetry across global engagements. Published October 2025. https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2025
[3] MITRE ATT&CK Framework
Reference for technique classifications cited in this post: T1204.002 (User Execution: Malicious File), T1059 (Command & Scripting Interpreter), T1218 (System Binary Proxy Execution), T1222.001 (File & Directory Permissions Modification), T1219 (Remote Access Software). https://attack.mitre.org
One custom detection. The only alert that fired. The breach that never happened.
In the DocuSign incident, every platform default went silent. One custom detection, built by our hunters because they saw a gap no vendor rule was covering, was the only thing standing between that organization and an undetected breach.
This is one of over 300 custom detections RSM Defense has engineered for customers just like yours.
Want to know what’s in your environment that your tools aren’t catching?
Request a Threat Hunting Briefing
| Contact the RSM Defense team |
