Connect with us

Infosecurity

AWS Points Finger at North Korean Hackers Behind Axios and Other npm Attacks

Published

on

npm supply chain attacks

A Familiar Name in a New Light

If you’ve written JavaScript in the last five years, you’ve probably used axios. It’s everywhere — over 100 million downloads a week. So when a malicious version of it quietly slipped out in early 2025, the ripple effect was felt across countless development teams.

Now we know who was likely behind it. AWS published a blog post on July 29 attributing the axios compromise — along with attacks on debug, chalk, and typo-crypto — to a North Korean state-sponsored hacking group tracked as Saphire Sleet, also known as BlueNoroff.

The connection wasn’t obvious at first. But Amazon Threat Intelligence dug into the tactics, techniques, and procedures (TTPs) across all four incidents and found striking similarities: trojanized npm packages, post-install hooks that execute automatically, and reused code.

“Amazon Threat Intelligence identified shared TTPs across these supply-chain campaigns, including trojanized NPM packages, use of post-install hooks, and code reuse,” said CJ Moses, CISO and VP of security engineering at Amazon. “Based on analysis of command-and-control indicators and TTPs, we assess with medium confidence that these campaigns are attributable to the DPRK-linked threat actor tracked as Saphire Sleet.”

Medium confidence. That’s a careful word choice — attribution is rarely a slam dunk. But the pattern is compelling.

The Same Playbook, Repeated

Here’s how the attacks unfolded. The group would socially engineer a package maintainer, gain their trust, and then publish a “legitimate” update that actually contained malicious code. Any organization that auto-updated dependencies received the compromised version without a second thought.

Moses said the typo-crypto compromise in March 2025 was likely a dry run. The real damage came later. In a two-hour window, roughly 10% of cloud environments pulled the compromised debug and chalk packages. Axios, being one of the most popular JavaScript libraries on the planet, amplified the reach even further.

The math is simple. “By compromising a small number of highly popular packages, the group gains potential access to thousands of downstream environments simultaneously,” Moses explained. For a financially motivated actor, that’s far more efficient than picking off targets one by one.

How Attacker Tradecraft Is Evolving

AWS didn’t just stop at attribution. The blog post also detailed how these attackers are getting smarter, and the list is sobering:

  • Splitting malicious workflows across several innocent-looking packages to evade detection.
  • Playing the long game — acting like real maintainers for weeks or months before dropping the malicious update.
  • Keeping package contents benign, while the real danger hides in external scripts, config files, and remote endpoints.
  • Using advanced obfuscation: AES-GCM encrypted blobs gated by passphrases, RC4-style string arrays with per-call keys, layered XOR over base64, and native loaders.
  • Designing payloads to evade sandbox analysis.
  • Slopsquatting — registering package names that AI coding tools hallucinate, tricking developers into installing malware.

That last one is particularly nasty. Developers increasingly rely on AI assistants to generate code, and those tools sometimes suggest package names that don’t exist. Attackers register those names first. You can see how that ends.

Should We Care Who’s Behind It?

Not everyone agrees that attribution matters much for defenders. Cris Thomas, security advocate at Semgrep, argues the focus should be elsewhere.

“Defenders should not concern themselves too much with who is performing an attack and more with knowing likely techniques of a specific attacker. Distinguishing between one group and another can be helpful for defense teams, knowing whether it is North Korea or Canada is less relevant.”

His advice? Defense in depth. “If one defense doesn’t find them, another one will. The goal isn’t to prevent successful attacks but to identify, limit, block, and correct attacks as soon as possible.”

That’s a fair point. Knowing the attacker’s name doesn’t patch your dependencies. But understanding their TTPs — the post-install hooks, the social engineering, the slopsquatting — gives you something concrete to defend against.

Practical Steps for Developers

So what can you actually do? A few things:

  • Audit your dependencies regularly. Tools like npm audit and software supply chain security scanners can flag suspicious packages.
  • Lock your versions. Don’t auto-update blindly. Pin versions and review changes before upgrading.
  • Beware of new packages. Especially ones that sound plausible but are slightly off — that’s slopsquatting territory.
  • Monitor post-install scripts. These run automatically and are a favorite vector for attackers.

The axios npm attack is a reminder that open source is both a gift and a risk. The ecosystem runs on trust. When that trust is weaponized, the fallout is massive.

For more on how platforms are responding, check out our coverage of GitHub’s npm security updates.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Infosecurity

CISA warns of spike in attacks on water systems as Minnesota incidents probed

Published

on

attacks on water systems

CISA issues urgent alert over water utility intrusions

The federal cybersecurity agency is reporting a “significant increase” in malicious activity aimed at water utilities, as investigators are reportedly trying to determine whether recent incidents in Minnesota might be the work of Iran-linked hackers.

The Cybersecurity and Infrastructure Security Agency said in a public alert on Thursday that facilities should “remove publicly exposed PLCs and other operational technology (OT) from the internet as soon as possible.” PLCs — programmable logic controllers — are at the core of processes in multiple industries.

Multiple news outlets reported that state and federal investigators were working to determine whether disruptions to water systems in Minnesota earlier this month were connected to Iran. Wired magazine reported that a memo from the WaterISAC, the industry’s cybersecurity information-sharing body, said the attacks were tied to Iran.

What happened in Minnesota?

Minnesota’s state IT agency said earlier this week that “more than 30 Minnesota community water systems” were affected by a coordinated cyberattack beginning July 26. The threat actor is “targeting water entities of all sizes,” CISA said.

The intruders “have modified passwords to lock out operators and disconnected the PLCs by changing their IP addresses,” CISA said. “This activity has resulted in boil water notices and sustained manual operations.”

CISA, the FBI and the Environmental Protection Agency are all involved in the response. The FBI said “utility companies in at least seven states” have reported incidents involving PLCs to the bureau.

Iran connection remains unclear

At a Cabinet meeting at Camp David on Friday, President Donald Trump placed the blame on Minnesota’s Democratic government. “Iran’s got bigger problems than worrying about Minnesota,” he said.

Earlier this month, CISA updated previous warnings that industrial OT was facing malicious activity linked to Iran. Thursday’s alert does not mention Iran.

“Even water organizations with mature cybersecurity processes should validate their external connections, as this targeting activity includes cellular modems installed by operators, vendors, or system integrators that may not be documented or included in routine attack surface scans,” CISA said. “OT assets exposed to the internet have an increased risk of defacement, configuration changes, operational disruptions, and, in severe cases, physical damage.”

Broader context: OT security under siege

Hostilities continued around the Strait of Hormuz on Friday, as oil companies reported massive profits related to the conflict’s effects on energy prices.

This wave of intrusions fits a troubling pattern. Operational technology security has become a prime target for state-sponsored groups, and water utilities — often running on aging infrastructure — are particularly exposed.

For utilities, the immediate takeaway is clear: audit every internet-facing device, including those cellular modems that might have slipped off the radar. Document all external connections. And if you find a PLC exposed, don’t wait — pull it offline.

For more on how cybercriminals are exploiting industrial systems, see our explainer on PLC cyberattack vectors. And for a broader look at how federal agencies are responding, check out CISA’s evolving role in critical infrastructure defense.

Continue Reading

Infosecurity

NCSC Pushes Device Makers to Build Forensic Observability Into Every Network Product

Published

on

Why the NCSC Is Turning Up the Heat on Device Vendors

When a firewall gets compromised, the clock starts ticking. Incident responders need to know exactly what happened, how deep the intrusion goes, and whether the device can ever be trusted again. But too often, that evidence is locked away inside proprietary hardware and software.

The UK’s National Cyber Security Centre (NCSC) has had enough. In a blog post on July 29, Chris A, the agency’s technical director for networking and infrastructure, laid out a clear demand: device manufacturers must embed forensic observability into their products from the ground up.

Firewalls, VPN gateways, and other network appliances are prime targets for attackers. When they fall, organizations are left scrambling. “When incidents occur, organizations need reliable ways to understand what happened and assess whether a device can still be trusted,” Chris A wrote. “This is why forensic observability matters.”

The concept is straightforward: give defenders supported, built-in capabilities to investigate a compromise, rather than forcing them to reverse-engineer the device or hunt for vulnerabilities just to collect basic forensic data. That’s still the norm in many shops, and it’s a costly, time-consuming nightmare.

What Forensic Observability Actually Means

According to the NCSC, forensic observability isn’t a single feature. It’s a bundle of capabilities that should be baked into every network device:

  • Comprehensive telemetry and structured logging
  • Access to configuration state
  • Ability to collect forensic data from memory and data at rest
  • Transparency about the software running on the device, either via version info or a software bill of materials (SBOM)

That last point matters more than most people realize. If you don’t know exactly what software is on a device, you can’t assess its exposure to known vulnerabilities. An SBOM changes that equation entirely.

Chris A emphasized that investigating a compromised device “should not require discovering or exploiting vulnerabilities in the product itself.” Instead, manufacturers should provide supported mechanisms for gathering evidence, assessing impact, and restoring trust in affected systems.

The NCSC isn’t asking for the moon here. “Small design decisions can significantly reduce the time needed to triage and investigate incidents,” he noted.

Three Myths That Hold Vendors Back

The NCSC’s technical director also took aim at misconceptions that keep manufacturers from making these design improvements. These myths, he argued, are preventing progress in network device security.

Myth 1: Observability Helps Attackers

Some vendors worry that exposing telemetry gives attackers a roadmap. The NCSC disagrees. Well-designed features like structured logging, authenticated collection mechanisms, and clearly defined forensic interfaces strengthen security rather than undermine it. Attackers don’t need your logs to exploit your device; they need your vulnerabilities.

Myth 2: Customers Will React Negatively

The fear here is that customers will see forensic features as complexity or backdoors. The reality, per the NCSC, is the opposite. Clear telemetry and forensic capabilities build trust through improved visibility. Buyers want to know what their devices are doing, especially after an incident.

Myth 3: It’s Too Difficult to Build

Yes, forensic observability requires careful engineering. But it’s absolutely achievable, especially when prioritized early in the design process. Waiting until after a product ships makes it exponentially harder — and far more expensive.

What Vendors and Buyers Should Do Now

The NCSC isn’t just publishing blog posts and walking away. The agency released formal guidance on building forensic observability into products back in February 2025. Now it’s pushing vendors to follow it.

Chris A also had a message for IT buyers: push your vendors. If you’re procuring firewalls, VPN gateways, or any other network appliance, ask what forensic capabilities are built in. Demand SBOMs. Make forensic observability a checkbox in your procurement process.

In parallel, the NCSC is working with global partners to develop a reference architecture for forensic observability in network appliances. Once finalized, this should give manufacturers a blueprint for providing “safe, reliable forensic access” without weakening the security of their products.

For incident response teams, this shift can’t come soon enough. The gap between what attackers exploit and what defenders can investigate is a serious problem. Forensic observability closes that gap — but only if vendors actually build it.

Want to dig deeper into related topics? Check out our coverage of Android spyware forensics tools and the broader push for software bill of materials adoption in enterprise security.

Continue Reading

Infosecurity

LogoKit Phishing Kit Now Screenshots Your Real Website to Build Fake Login Pages

Published

on

LogoKit phishing kit

The Hook: A Login Page That Looks Exactly Like Yours

Imagine getting a phishing email that warns your password is about to expire. You click the link. The login page that loads isn’t a generic clone — it’s a real-time screenshot of your company’s actual website, complete with your logo, your branding, even your latest announcements. That’s not hypothetical. That’s what the LogoKit phishing kit is doing right now.

Researchers at Barracuda published findings on July 29 detailing how this phishing-as-a-service platform has evolved. It no longer relies on static templates. Instead, it builds a unique login page for each victim on the fly, pulling live data from commercial web services.

From Brand Impersonation to Environment Impersonation

The shift is subtle but significant. Older phishing kits tried to copy a brand’s look. LogoKit goes further — it recreates parts of the victim’s genuine web environment. Barracuda calls this “environment impersonation.” The page doesn’t just look like the brand; it looks like your specific instance of that brand.

Here’s how it works, step by step:

  1. The phishing URL contains the victim’s email address.
  2. The kit extracts that address and identifies the victim’s employer from the domain.
  3. It calls Clearbit to fetch the company’s official logo.
  4. It uses Thum.io, a commercial screenshot service, to capture a live image of the victim’s actual website.
  5. Additional APIs — Google Favicon, ImageKit, Microlink — load more authentic imagery as the page renders.

The result? A login page that mirrors the real thing down to the pixel. No two victims see the same page.

Legitimate Services Doing the Heavy Lifting

What makes this particularly sneaky is the reliance on reputable third-party services. Thum.io isn’t a malicious tool — it’s a legitimate screenshot API used by developers worldwide. Clearbit is a standard data enrichment service. By piggybacking on these platforms, the kit avoids hosting its own infrastructure.

This isn’t entirely new. RiskIQ first named LogoKit back in 2021, noting it already pulled logos from Clearbit and embedded victim email addresses in URLs. What’s new is the live screenshot element and the scale of customization.

The Lures: Boring but Effective

The bait itself is routine. Barracuda observed campaigns covering password expiry warnings, certificate expirations, access restrictions, delivery failures, timesheet updates, and ICANN verification notices. Nothing exotic — just the everyday anxieties that push people to act fast.

The emails appeared in six languages: English, German, French, Spanish, Chinese, and Korean. That’s a global operation, not a hobbyist experiment.

No Server, No Template, No Signature

Here’s the part that keeps security teams up at night. Credential harvesting doesn’t go to an attacker-controlled backend. It goes to a Telegram bot. After the victim submits their password, they’re redirected to the real website — where they likely assume they mistyped their password the first time. The attacker is already gone with the credentials.

Because there’s no static template, there’s no signature for antivirus or URL filters to fingerprint. Each page is assembled at request time from live data. Blocklisting a domain? Useless. The same problem was flagged with the Starkiller phishing kit back in February, which also bypasses MFA.

How to Defend Against LogoKit and Its Ilk

Barracuda’s recommendations are straightforward but require commitment:

  • Deploy phishing-resistant MFA. FIDO2 security keys and passkeys bind authentication to the legitimate domain. A fake page can’t present the correct cryptographic challenge, so stolen passwords become useless.
  • Use conditional access rules. Restrict logins based on location, device compliance, and risk signals.
  • Consider browser isolation. Render web content in a sandboxed environment so malicious pages never touch the user’s device.
  • Filter URLs aggressively. Flag newly registered domains and links that contain an email address in the path — a telltale sign of this kit.

The bigger lesson? Traditional phishing defenses are crumbling. Static analysis, reputation lists, and user training alone won’t cut it. Attackers have moved to dynamic, per-victim campaigns that look exactly like the real thing. Your defense needs to move just as fast.

For more on how phishing kits are evolving, check out our coverage of phishing kit evasion techniques and MFA bypass attacks.

Continue Reading

Trending