AWSDoor: Post-Compromise Persistence Tool in AWS
AWSDoor is a post-compromise tool first identified in recent years, designed to help attackers maintain access inside AWS environments after an initial breach. It does not directly break into accounts but instead abuses AWS-native services and permissions to remain hidden. The tool automates persistence techniques by injecting new IAM access keys, modifying trust policies to allow external accounts to assume privileged roles, or creating hidden administrator-level policies with the NotAction operator. It also extends beyond IAM by deploying backdoors through Lambda functions, hiding code in Lambda layers, leveraging AWS Systems Manager on EC2 instances for reverse SSH tunnels, and sharing EBS snapshots with external accounts to facilitate data exfiltration. Because these methods use standard AWS features, they often blend in with legitimate administrative tasks, making them difficult to detect without disciplined monitoring. AWSDoor is primarily used by threat actors who already have access and want to ensure long-term persistence, whether for espionage, data theft, or continued disruption. Defenders should treat the presence of AWSDoor as a clear sign of compromise. Organizations must enable detailed CloudTrail logging and monitor for IAM changes, new key creation, or updates to trust policies. Alerts should be configured for risky policy operators, such as NotAction, unexpected Lambda layer updates, and snapshot sharing to unfamiliar accounts. Service Control Policies should explicitly block actions such as LeaveOrganization, and long-term IAM access keys should be replaced with AWS SSO. Regular IAM audits, strict least-privilege enforcement, and CSPM solutions can help surface hidden persistence tactics. AWSDoor can also weaponize S3 lifecycle rules to trigger large-scale shadow deletions without raising standard delete events. Because AWS processes these expirations internally, the only dependable detection point is the PutBucketLifecycleConfiguration API event, which should be closely monitored for risky expiration rules. By focusing on unusual configuration changes and closely tracking the services AWSDoor abuses, defenders can significantly reduce the chance of attackers maintaining a foothold in AWS.
Ongoing npm Supply Chain Attacks Raise Fresh Concerns
In mid-September 2025, security researchers confirmed that multiple npm packages had been compromised, apparently as part of a continuation of the supply chain activity dubbed the Shai-Hulud attack. This campaign has previously targeted popular libraries, including tinycolor and dozens of others, by injecting malicious code designed to steal developer secrets and manipulate workflows. Reports indicate that attackers leveraged a compromised publisher account to push backdoored versions of packages, some of which were branded under CrowdStrike’s npm namespace. The injected malware included a bundle.js component that executed TruffleHog to scan for secrets, harvested API keys and cloud credentials, and attempted to validate and exploit developer publishing tokens. Compromised versions were quickly removed from npm once the issue was identified. Still, any environment that installed them during the window of availability may have been exposed to credential theft and unauthorized modifications to GitHub workflows. While attribution and full technical details remain under investigation, this incident underscores the persistent risk of supply chain abuse in open-source ecosystems. The branding of this campaign with references, including shai-hulud[.]yaml suggests an intentional effort by the attacker to link activity across multiple compromised projects. Developers and organizations should immediately review dependency lists, uninstall or pin to known-good versions, and rotate any potentially exposed credentials to ensure security. Monitoring for unusual npm publish events, unauthorized GitHub Actions workflows, and outbound connections to unfamiliar endpoints is strongly advised. As more details emerge, this attack serves as another reminder that trust in public package registries must be paired with vigilant monitoring, credential hygiene, and defense-in-depth strategies to mitigate the impact of malicious package injections.
SEO Poisoning Campaign Delivers Multiple RATs Through Fake Software Sites
In late August 2025, researchers at Fortinet discovered a campaign that exploited search engine optimization to distribute malware through fake software download pages. The attackers boosted malicious domains using SEO plugins and registered lookalike sites that mimicked legitimate ones, targeting tools such as Google Chrome, Telegram, WhatsApp, DeepL Translate, and WPS Office. Victims who downloaded installers from these spoofed pages received both the legitimate application and a hidden payload. Fortinet identified HiddenGh0st and Winos (ValleyRAT), both variants of Gh0st RAT. Winos have ties to the Silver Fox group, which has been active since at least 2022. The infection chain relied on a JavaScript file called nice[.]js to redirect users through multiple JSON responses before serving the final malicious installer. Once executed, the malware performed anti-analysis checks to evade detection, then established persistence through COM hijacking or the creation of Windows shortcuts. It sideloaded a malicious DLL that enabled command-and-control communications, system monitoring, and credential harvesting, thereby granting attackers long-term access to the compromised machines. While the campaign heavily targeted Chinese-speaking users, the same SEO poisoning techniques and domain impersonation tactics can be repurposed against other regions with minimal changes. Defenders should monitor for suspicious installer activity, domain impersonation patterns, COM hijacking attempts, registry changes, and outbound C2 traffic to detect and block this threat before it results in persistent compromise.
Malicious MCP Servers Open a New Supply Chain Threat in AI Ecosystems
The Model Context Protocol (MCP), introduced as an open standard by Anthropic, was designed to facilitate the easy integration of AI assistants with external tools and data sources. Instead of requiring developers to build unique integrations for each service, MCP uses a client–server model where AI clients connect to MCP servers that expose functions. This flexibility is powerful, but it also creates a new risk in the supply chain. Because MCP servers run with the same privileges as the user, an attacker who slips a malicious server into a workflow gains full access to the environment without ever dropping traditional malware. To demonstrate the danger, researchers recently published a proof-of-concept package on PyPI called “DevTools-Assistant.” On the surface, it offered project analysis and configuration checks, but hidden within the code was logic that quietly harvested sensitive files, credentials, and API keys from the developer’s system. For instance, A PyPI package disguised as a productivity tool exposed hidden code that quietly harvested sensitive files, credentials, and API keys from the developer’s machine. The PoC then disguised the outbound traffic as GitHub API requests, making the exfiltration appear to be routine development analytics and nearly invisible to monitoring tools. The broader risk is that malicious MCP servers can be weaponized through techniques that are difficult to flag as malicious. These include spoofing server names to trick clients into connecting, poisoning tool descriptions with hidden instructions, shadowing legitimate tools with attacker logic, or pushing backdoored updates after establishing initial trust. Since all of this activity runs inside expected MCP traffic, it bypasses traditional endpoint and network security controls. To mitigate this emerging vector, organizations should treat MCP servers as a supply chain component: enforce an approval workflow for new servers, sandbox them in isolated containers with limited access, and implement strict monitoring of MCP traffic. Defenders should be alert to suspicious POST requests, unexpected tool behavior, and hidden configuration changes. By applying the same rigor to MCP servers as to other third-party integrations, teams can prevent a “trusted” AI plugin from quietly becoming a data exfiltration channel.
Update: SmokeLoader’s 2025 Variants Signal the Return of a Persistent Loader Threat
SmokeLoader, also known as Dofoil, has been active since 2011 and is one of the most enduring malware loaders in the ecosystem. Its primary role is to deliver second-stage payloads, including trojans, ransomware, credential stealers, and cryptocurrency miners; however, its modular plugin design has made it adaptable to various criminal operations. After the disruption of Operation Endgame in mid-2024, SmokeLoader activity declined, only to resurface in early 2025 with a new “alpha” build followed by a hardened 2025 release. These updates fixed longstanding performance issues, improved stealth, and introduced stronger obfuscation. The stager now checks for mutexes before injection, uses new decryption functions, and incorporates 64-bit shellcode. At the same time, the main module obfuscates constants and employs additional locale checks to avoid infecting Russian systems. Together, these changes show that the author is actively maintaining the malware and preparing it for long-term use by criminal groups. The network protocol has also been updated to strengthen communications with command-and-control servers, including a new CRC32 checksum and obfuscated packet length fields that complicate passive interception. SmokeLoader’s modular plugins continue to enable credential theft, distributed denial-of-service attacks, and mining, giving threat actors flexibility to tailor campaigns to their objectives. While the alpha build remains widely observed due to compatibility with older infrastructure, the 2025 version is more advanced and is likely to see broader adoption as operators update their tooling. For defenders, this evolution reinforces the resilience of loader-based malware even after coordinated takedowns have been implemented. Organizations should monitor for behavioral signs of loader activity, including anomalous scheduled tasks, mutex-based injections into explorer[.]exe, and encrypted beacon traffic to unfamiliar endpoints. As loaders like SmokeLoader remain a cornerstone of the criminal ecosystem, proactive detection and response are essential to prevent follow-on infections that often deliver more damaging payloads.
