Introduction
The QRadar Detection Engineering Content team, comprised of seasoned red and blue teamers, is responsible for designing and implementing systems to detect cyber-attacks and attacker tactics, techniques, and procedures (TTPs). These systems are released as Content Packs through IBM App Exchange and can be downloaded and added to your existing rules for the purpose of detecting specific threats.
In this blog we will discuss the malware family SocGholish. We will provide a high-level description of the malware and how QRadar SIEM can help you detect it.
Threat Profile
SocGholish is a JavaScript malware loader commonly delivered through social engineering attacks. Sometimes also referred to as FakeUpdates, it often masquerades as a browser, software update, or malicious advertisement in drive-by download or phishing campaigns. Once installed, it retrieves and executes additional payloads to enable further exploitation, data theft, ransomware deployment, or sale of network access via initial access brokers. SocGholish was ranked #1 this year for Q2 in CIS MS‑ISAC’s Top 10 Malware report, responsible for 31% of detections, with malvertising cited as the top initial‑access vector.
Detection Work Done/Rules Description
The QRadar Detection Engineering Content team benefits from expertise on both the red team and blue team, enabling dedicated purple team exercises when necessary. In this case, the red team emulated the TTPs of a real SocGholish attack, while the blue team worked to detect, respond to, and mitigate the threat. These exercises strengthen detection coverage, incident response capabilities, and overall security posture for the product.

Figure 1: The malware was executed by the Red Team via asdf.zip

Figure 2: The malware was analyzed by the Blue Team
Two of the steps the red team took to simulate SocGholish can be seen in Figure 1 and Figure 2. In Figure 1 the red team has downloaded a malicious .zip file containing the command displayed in Figure 2. The snippet is simulating SocGholish’s typical second-stage behavior: a script fetched and executed on the host to pull down and run a payload. SocGholish commonly uses a web-delivered JavaScript that eventually causes a command or PowerShell invocation like this to run, allowing the attacker to retrieve and execute additional code.
The command does the following:
- Opens an HTTP request to http://192.168.56.104:8000/script.ps1 using the .NET System.Net.WebRequest API, instructing the host to fetch a PowerShell script.
- Retrieves the server response stream (GetResponse()), which contains the script text.
- Wraps the response stream in a System.IO.StreamReader and reads the entire payload with ReadToEnd().
- Passes the downloaded script text to IEX (Invoke-Expression), which evaluates and executes the script in the current PowerShell process.
- Runs the payload entirely in memory (no file written to disk), enabling a stealthy, flexible second-stage delivery that an adversary can update on their server.
In this way a SocGholish attack might go about fetching a second-stage PowerShell payload from a remote server and executing it in memory, a common technique the malware uses to extend its foothold after initial JavaScript-based deception. In a similar vein, additional testing can be seen in Figure 3. In this image the red team is demonstrating several methods to fetch and execute a remote PowerShell payload in memory. Each approach downloads script text from a remote server and passes it to IEX (Invoke-Expression) so the host executes the code directly.

Figure 3: Additional Red Team testing
The results of the blue team analysis produced two malware neutral rules, included in the QRadar SIEM Endpoint Content Extension Pack 3.0.0, and two SocGholish specific rules, included in the QRadar SIEM Threat Monitoring Content Extension Pack 3.1.0. The malware neutral rules were tested against SocGholish as well as an initial access malware loader known as GootLoader.
The first malware neutral rule is designed to detect when a malicious JavaScript file is executed via wscript.exe (Windows Script Host). Attackers frequently abuse this built-in Windows utility to launch scripts that can download or execute malware without requiring additional software.
The rule fires when:
- The event is recorded in the Microsoft Windows Security Event Log on the local system.
- The event type matches QID 5000862 ("Success Audit: A new process has been created").
- The newly created process is wscript.exe.
- The command line includes a file ending in .js.
This rule helps defenders catch early signs of compromise by spotting when Windows’ built-in script host is being hijacked to run suspicious JavaScript files, a common first step in many malware attacks.

Figure 4: wscript.exe Rule
The second malware neutral rule is designed to detect when a malicious JavaScript file is executed via cscript.exe (Windows Script Host, command-line version). Attackers frequently abuse this built-in Windows utility to launch scripts that can download or execute malware without requiring additional software.
The rule fires when:
- The event is recorded in the Microsoft Windows Security Event Log on the local system.
- The event type matches QID 5000862 ("Success Audit: A new process has been created").
- The newly created process is cscript.exe.
- The command line includes a file ending in .js.
This rule complements the detection for the other Windows Script Host (wscript.exe). Attackers may use either the GUI-based (wscript.exe) or command-line (cscript.exe) version depending on their goals, so both must be monitored.

Figure 5: cscript.exe Rule
While the first two rules focus on malware-neutral detections that catch generic abuse of Windows Script Host, the next two rules are tailored specifically to SocGholish, a malware loader that often masquerades as fake browser updates. SocGholish relies heavily on JavaScript execution for its initial access and reconnaissance, making these rules valuable for detecting its early-stage activity in an environment.
The first SocGholish rule detects when the malware uses wscript.exe to launch JavaScript during its initial access phase. SocGholish is known for masquerading as fake browser updates and using JavaScript execution to gain a foothold in the environment.
The rule fires when:
- The event is recorded in the Microsoft Windows Security Event Log on the local system
- The event ID is 4688, which corresponds to process creation events.
- The parent process is wscript.exe.
- The new process is cmd.exe
- The command line includes a file ending in .js.
This rule helps defenders detect SocGholish’s attempt to use wscript.exe to spawn cmd.exe for executing JavaScript, a behavior commonly seen during the malware’s reconnaissance and initial access activity.

Figure 6: SocGholish Recon Rule
The second rule is designed to detect SocGholish reconnaissance activity where the malware uses wscript.exe to launch cmd.exe and run the whoami command. This is a common step attackers take to gather information about the current user context and system privileges after initial access.
The rule fires when:
- The event is recorded in the Microsoft Windows Security Event Log on the local system.
- The event ID is 4688, which corresponds to process creation events.
- The new process is cmd.exe.
- The parent process is wscript.exe.
- The command line includes /c whoami /all.
This rule helps defenders detect SocGholish performing reconnaissance by executing the whoami command through cmd.exe, allowing the attacker to enumerate user and privilege information on the compromised system.
Taken together, these four rules provide layered coverage against script-based threats. The first two rules focus on generic abuse of Windows Script Host, giving defenders visibility into any suspicious JavaScript execution via wscript.exe or cscript.exe. The next two rules narrow in on SocGholish-specific behaviors, flagging its use of JavaScript to launch processes and perform reconnaissance commands. By combining malware-neutral and malware-specific detections, defenders can both catch broad classes of script abuse and identify the distinct patterns of known threats like SocGholish.
During investigation and analysis, the team also evaluated SocGholish’s behavioral indicators of compromise (IOCs) against existing QRadar detection content and identified a gap: the PowerShell cmdlet Invoke-Expression was not being detected. This cmdlet, which executes a string as a PowerShell expression, can be abused to dynamically run arbitrary code and is a common attack vector in malware campaigns. To close this detection gap, a new rule requirement was identified to monitor for and alert on the use of Invoke-Expression and is included the QRadar SIEM Threat Monitoring Content Extension Pack 3.1.0. This addition enhances coverage and provides customers with better protection against SocGholish and similar threats.

Figure 7: Invoke Expression not detected by existing content, marked as a blue X in the screenshot.
Where to find the content pack
As mentioned above, the malware neutral rules were included in the Endpoint Content Extension pack version 3.0.0, while the SocGholish specific rules and the Invoke Expression rule are included in the Threat Monitoring Content Extension pack version 3.1.0. These packs can be found in the IBM App Exchange. Install them today to ensure you can detect any attempted SocGholish infection!
Conclusion
SocGholish remains an actively deployed malware loader that poses significant risks, including data theft, ransomware, and initial access brokerage. To address these evolving threats, our detection engineering team leverages practical purple teaming exercises to simulate real-world attack scenarios and validate and improve our detection content for accuracy and completeness. This approach ensures QRadar customers receive effective and continuously tested coverage.
Stay tuned for future posts from the QRadar Detection Engineering Content team, where we will share further insights into emerging threats and detection strategies!