Stuxnet source code published on GitHub as npm worm slips past new scan

Reverse-engineered Stuxnet source code published on GitHub

An unknown security researcher has published a reverse-engineered version of the Stuxnet source code on GitHub, complete with build instructions. Running it requires a Windows XP or Windows 7 virtual machine with no network connectivity, and observing the full payload effects rather than just the spreading mechanisms requires the appropriate Siemens software and ideally hardware. Stuxnet targeted Siemens industrial controllers reportedly used at Iran’s Natanz nuclear enrichment plant, manipulating the frequency converters in centrifuges to subtly damage rotors while reporting normal operation to plant staff. It is believed to be the first digital worm to cause direct physical damage.

The worm spread through three mechanisms: USB sticks using Windows shortcuts and autorun.inf files that triggered infection via a zero-day when a user viewed the drive contents, autonomous network spreading through a zero-day Windows Print Spooler vulnerability that let an attacker write system files to any machine sharing a printer, and copies placed in accessible network shares. To evade driver signature checks it used two digital certificates stolen from Realtek and JMicron, and it injected itself into Siemens software through the WinCC SQL Server database and Step 7 project files that ran automatically when engineers opened them. The final stage injected malicious code into the Programmable Logic Controllers to stealthily manipulate the rotors.

Stuxnet was part of Operation Olympic Games, an alleged coordinated effort between the U.S. and Israel to curb Iran’s nuclear progress at Natanz, reportedly developed by the Pentagon and Israel’s Unit 8200 and credited with bringing down about 10% of Natanz’ centrifuges by damaging their rotors. The worm lacked sufficient checks on its environment and failed to notice when it left a local network, so when engineers took laptops home it escaped to the internet. It contained a hard-coded self-destruct date set for June 24, 2012.

Researcher reverse-engineers infamous Stuxnet malware source code, publishes it on Github for all — attack targeted Iranian nuclear facilities and was the first software of its type to cause physical damage →

Shai-Hulud npm worm returns with identical payload, bypassing new scanning

The Shai-Hulud npm worm has resurfaced months after it was believed inactive, slipping past the publish-time malware scanning npm introduced in response to the original wave. In May, a compromised maintainer account pushed 639 malicious versions of @antv packages to npm within a single hour before the attack was halted. npm’s new scanning holds every package for five to 15 minutes while an automated system checks it before it becomes installable, but researchers at Aikido Security identified a worm that got through the triage queue. Four packages were uploaded within one hour after a 111-day gap: [email protected], [email protected], [email protected], and [email protected].

Aikido Security’s Charlie Eriksen said the payload had the same hash as the @AntV wave and the same payload, adding that the gap between what registry-level scanning claims to do and what a hash-identical reactivation shows it actually caught is the real story. Indicators of compromise include the command-and-control domain associated with the original May wave, t[.]m-kosche[.]com; the hash of the reused payload, e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6; the index.js root-level payload file; the preinstall command bun run index.js; and persistence files .vscode/tasks.json and claude/settings.json. Behavioral indicators include outbound validation calls against the npm registry using stolen tokens, tarball download, payload injection, version bump, republish cycle, and mass creation of GitHub repositories with Dune-themed naming and reversed Shai-Hulud strings in descriptions.

Eriksen said a file hash match is a lookup, not a hard problem, requiring no behavioral analysis, sandboxing, or reasoning about obfuscated code’s intent, and that the payload was not novel, repacked, or even lightly modified to dodge signature matching. While multi-stage loaders, dependency confusion, and runtime-triggered payloads are genuinely hard problems, he called an exact hash match to a worm that made international security news four months ago the floor of what publish-time scanning is supposed to catch. ITPro approached npm for comment but did not receive a response by time of publication.

Is Shai-Hulud back? Researchers spot ‘wormy boy’ slipping past npm malware scanning features →

Empty return address defeats Microsoft’s Reject Direct Send anti-spoofing setting

Security firm ReliaQuest published research on Thursday showing that attackers can bypass Microsoft’s Reject Direct Send setting, released in April 2025 to block external emails disguised as internal, by leaving the return address — a field the recipient never sees — empty. An otherwise identical message gets turned away. The technique requires no stolen password, no compromised account, no multifactor authentication bypass and no network compromise, so defenses built around protecting logins do not address it. The setting governs Direct Send, a Microsoft 365 feature that lets printers, scanners and other equipment drop mail into a company’s system without logging in, which attackers abused to make external email look internal.

One of the primary risks is business email compromise, fraud in which an employee is talked into wiring money or handing over credentials, often starting with an email that appears to come from IT or a company executive. In some cases ReliaQuest described, spoof messages landed in the junk folder rather than the inbox, but most reached the target inbox. One route to the inbox was exception lists — overrides administrators configure so mail from an approved sender skips the spam filter. In one case, a message failed every sender authentication check and Microsoft’s filtering classified it as phishing, yet it landed in the target inbox because an approved-sender list included the executive the spoof email impersonated. ReliaQuest characterized the finding as a limit on the scope of Reject Direct Send, not a flaw in Microsoft’s software.

Microsoft acknowledged this kind of limitation when it announced the setting in April 2025, explaining that it evaluates the return address on the envelope, not the sender address a reader sees. Asked in an FAQ whether customers need Reject Direct Send to consider themselves protected, Microsoft answered No, saying the setting joins many layers of protection in Microsoft 365. Microsoft’s documentation says most customers do not need Direct Send in the first place, recommends it only for legacy equipment, and says the company is working on an option to disable Direct Send by default. ReliaQuest sells detection software and some of its recommendations point toward its own products. One defense stopped every attempt ReliaQuest tried: a restricted inbound connector that accepts mail only from approved machines, blocking spoof emails regardless of their envelope contents. Institutions that already restrict which machines can deliver mail are not exposed. For everyone else, ReliaQuest recommends reviewing every configured spam override, noting which entries cover an executive or a manager, and deleting the ones the company cannot justify.

Researchers find a hole in Microsoft’s anti-spoofing fix →

India’s Financial Fraud Risk Indicator blocks ₹5,043 crore in suspected fraud

India’s Financial Fraud Risk Indicator has helped financial institutions prevent suspected cyber-fraud transactions worth ₹5,043.73 crore by August 2026. Launched on May 22, 2025 by the Department of Telecommunications, the system had prevented about ₹660 crore in its first six months, with more than ₹2,000 crore prevented in just four months from April 2026 as adoption by banks and payment platforms expanded. FRI is developed under DoT’s Digital Intelligence Platform and assesses the likelihood that a mobile number is associated with financial fraud, classifying it as Medium, High or Very High risk. It draws on reports on DoT’s Sanchar Saathi platform, the Indian Cybercrime Coordination Centre’s National Cybercrime Reporting Portal, information from telecom operators, banks and financial institutions, and other telecom-related parameters.

Banks, NBFCs, UPI applications and other financial institutions can incorporate the resulting intelligence into their fraud-control systems, enabling them to warn customers, introduce additional verification, delay a transaction or, in sufficiently high-risk cases, decline it. When FRI was introduced, DoT said PhonePe was using Very High-risk classifications to decline transactions and issue alerts, while leading UPI platforms including PhonePe, Paytm and Google Pay had begun integrating DIP intelligence into their systems. More than 1,600 organisations are now connected to DIP, compared with more than 1,200 reported in February 2026, and DoT says it has conducted over 25 training sessions covering 1,500 banks, financial institutions and regulators. Under the Allocation of Business Rules, cybercrime falls within the Ministry of Home Affairs’ domain, while police and public order are State subjects; DoT’s role is to provide telecom intelligence rather than investigate crime, and DIP enables bi-directional information sharing with stakeholders including MHA’s I4C.

As of January 31, 2026, the Citizen Financial Cyber Fraud Reporting and Management System had helped save more than ₹8,690 crore across over 24.65 lakh complaints, and I4C’s Suspect Registry had shared information on 27.37 lakh Layer-1 mule accounts, with participating institutions declining transactions worth ₹9,518.91 crore. The Reserve Bank of India, in proposing a Digital Payments Intelligence Platform, argued that maintaining confidence in digital payments requires network-level intelligence and real-time data sharing across payment systems. DoT states: Every rupee stopped at source is a fraud that never happened. Open questions remain around independent evaluation of the risk engine, including how many transactions classified as Very High risk ultimately prove fraudulent, how many legitimate numbers are incorrectly flagged, what proportion of alerts result in abandoned transactions by genuine customers, and how quickly an incorrectly classified number can be reviewed and restored. A false positive embedded in real-time financial infrastructure can prevent a citizen or business from receiving money, and if multiple banks and payment platforms rely on the same risk classification, an erroneous signal could propagate across the financial ecosystem, creating a need for a governance framework around classification, review and grievance redressal.

₹5043 crore saved: How India is building a real-time defence against digital fraud →

Cisco links Ukrainian government breach to Russian actor using fake CAPTCHA

A cyberattack targeting a Ukrainian government organisation has been linked to Moscow, according to a report by Cisco. Cisco’s cybersecurity researchers noticed unusual activity in the organisation’s computer systems in April and assessed with moderate confidence that a Russian threat actor carried out the attack. Researchers found malware known as Amatera running on the system, capable of stealing sensitive information, and it was also used to install software that could give an attacker access to the computer, including the ability to inspect files, transfer data and run commands. The software was configured to connect to a server with an IP address based in Russia. It could not be verified whether any information was actually stolen, whether hackers actively used that access, or how the computer was initially infected. Cisco researchers assessed the attack was part of a broader operation designed to steal cryptocurrency and credentials, and the report said it was not clear what started the execution chain.

In the Ukrainian system, researchers saw a malicious file disguised with the name verification.google but could not trace what caused it to run. Searching for similar attacks, they found another infection involving the same Amatera malware, traced to compromised websites showing fake versions of Google’s CAPTCHA verification check. Instead of asking users to tick a box or identify images, the fake check told them to open a window on their computer and paste in text that would run malware. In that infection, Amatera was also used to install a program designed to steal cryptocurrency, which could monitor cryptocurrency wallet addresses victims copied and replace them with addresses controlled by the attackers, potentially redirecting payments. Cisco said similarities between the infections suggest the attack against Ukraine may have started in the same way, but researchers could not confirm that the two infections began the same way or that the same group carried them out.

Russian hackers may have used fake CAPTCHA to hack Ukrainian government computers →