Agent Tesla v4: A Smarter, Sneakier Infostealer

There’s a new version of Agent Tesla malware making the rounds, and it’s brought some tricks that should worry anyone in finance. Researchers at KnowBe4 just published a deep dive on Agent Tesla v4, an infostealer that’s been spotted arriving via a business email compromise (BEC) lure aimed squarely at accounting departments.

The headline feature? Unicode emoji characters scattered through the malicious code. Hearts, water droplets, the works. It sounds almost playful, until you realize what those little symbols are doing: breaking string-based signature matching and making the code noisy enough to slip past casual review.

This isn’t your run-of-the-mill credential stealer. It’s designed to evade detection at every turn, and it’s good at it.

How the Attack Unfolds

The delivery mechanism is a JScript dropper, which can be launched with a simple open-with dialog. The email itself is a forwarded thread, made to look like internal correspondence. The recipient is brought in late, told to confirm an attached document, and reply. Classic social engineering, executed well.

The attackers spoofed the address of Metropolitan Bank and Trust Company, a legitimate Philippines-based commercial bank. The whole thread feels like an in-progress discussion you’ve just been pulled into. That urgency, that sense of being out of the loop—it works.

The Emoji Obfuscation Trick

Once the JScript dropper runs, it writes two files to C:UsersPublicLibraries. One is a decoy. The other passes the payload into DonutLoader shellcode for reflective PE injection. That means the final Agent Tesla binary never touches the filesystem. File-based scanners? Useless.

The emoji characters are interleaved directly through the script body. They disrupt signature matching and make the code visually noisy. A human glancing at it in a text editor sees a mess. An automated scanner sees something it doesn’t recognize. Both are defeated.

KnowBe4’s researchers note that any YARA rule looking for the Unicode code points alongside JScript-specific patterns will catch this family. A rule matching both the emoji distribution pattern and WScript.Shell or CreateObject calls will do it. That’s the mitigation playbook, in a nutshell.

Evasion Techniques That Go Beyond Emojis

The obfuscation doesn’t stop at the dropper. Agent Tesla v4 is scrambled with ConfuserEx, an obfuscator tool that makes the assembly nearly unreadable. Its embedded metadata presents the malware as a Python installer. A little misdirection, a little disguise.

The malware also checks for debuggers using a standard Windows function. If it detects one, it stops running. No analysis, no sample collection, no fun for researchers.

Before harvesting anything, it creates a persistent hardware fingerprint. That lets attackers track victims across OS reinstalls and IP rotations. Even if you rebuild your machine, they know it’s you.

It also disables validation for all outgoing connections, ensuring smooth communication with C2 infrastructure without triggering security alerts or errors. Persistence is the name of the game.

Credential Theft and Data Exfiltration

Once it’s settled in, Agent Tesla v4 sweeps credentials from more than 40 applications. Web browsers, messaging platforms, native Windows credential repositories—it’s all fair game. It also has a keylogger and clipboard tool for intercepting keystrokes and copied text.

All exfiltrated files carry a system fingerprint header: timestamp, username, computer name, OS name, CPU, RAM, public IP, and the MD5 hardware ID. That’s a lot of identifying information, all packaged neatly for the attacker.

The credential dump lands on the attacker’s FTP server within seconds of execution. No delayed staging, no waiting around. The whole operation is fast, efficient, and ruthless.

What Security Teams Should Do

KnowBe4’s advice is straightforward: update email security rules to catch Agent Tesla before it can harvest credentials. The emoji obfuscation doesn’t survive YARA rules that look for the specific Unicode code points used alongside JScript patterns.

For defenders, that means:

• Deploy YARA rules that match emoji distribution patterns combined with WScript.Shell or CreateObject calls.
• Monitor for unusual JScript activity, especially in environments where it’s rarely used.
• Train finance teams to recognize BEC lures, even when they look like internal threads.
• Keep an eye on outbound FTP traffic to unknown domains.

Agent Tesla has been around for years, but this version shows the threat is evolving. Emoji obfuscation is a new twist on an old problem. The fundamentals, though, remain the same: verify before you click, and keep your email filters sharp.

For more on defending against credential theft, check out our guide on phishing email detection best practices and learn how to secure your email gateway against BEC attacks.

A day of digital chaos in Norway

For more than 30 hours, a relentless DDoS attack has been hammering the digital infrastructure that Norwegians rely on for everything from logging into government portals to picking up prescriptions. The Norwegian Digitalisation Agency, known as Digdir, confirmed that the attack began on Monday and has continued with varying intensity, leaving a trail of disrupted services in its wake.

This isn’t just a minor inconvenience. Ten digital services have been affected, including the critical ID-porten system, which serves as a gateway to thousands of government services. With over 4.5 million users, ID-porten is the digital key to Norway’s public sector, and its downtime has sent ripples across the country.

What exactly was hit?

The attack targeted the infrastructure of Vivicta, Digdir’s IT partner. According to Digdir’s status page, the affected services include identity verification, login systems, data exchange between government agencies and businesses, access to public records, and employee access management. That’s a broad swath of the digital public sphere.

One of the most concerning knock-on effects was on Norway’s health infrastructure. Several health services depend on ID-porten for authentication, meaning patients faced potential problems accessing online pharmacies and the country’s electronic prescription system. For a nation that prides itself on digital efficiency, this was a stark reminder of how fragile that efficiency can be.

Not the first time, and getting bigger

This is the third DDoS incident to hit Digdir’s services since June, according to Norwegian media. But it’s not just a repeat performance. Are Kvistad, a press officer at Digdir, told public broadcaster NRK that this attack is “two to three times larger than what we experienced last time.” That’s a significant escalation, and it raises questions about whether these incidents are connected or part of a broader campaign targeting Norway.

So far, no group has claimed responsibility, and it’s unclear who’s behind the assault or whether the recent incidents are linked. What is clear is that the attackers didn’t manage to breach sensitive data. Digdir has stated that no sensitive information stored in the affected systems was compromised. That’s a small comfort, but a comfort nonetheless.

What’s being done about it?

Digdir is working closely with Vivicta to stabilize the systems and bring services back online. As of Tuesday morning, some services were gradually returning, but the attack was still affecting others. The response has been a mix of technical mitigation and public communication, with Digdir keeping a status page updated for concerned citizens.

For those watching from the sidelines, this is a textbook case of how a DDoS attack works: flood the servers with traffic until they can’t handle legitimate requests. It’s a blunt instrument, but it can be devastatingly effective when aimed at critical infrastructure.

The bigger picture: A trend or a one-off?

The repeated nature of these attacks on Digdir’s services is worrying. Three incidents since June suggests a pattern, even if the motives remain unclear. Could this be a test of Norway’s defenses? A political statement? Or just a particularly persistent group of cybercriminals? Without more information, it’s hard to say.

What is certain is that Norway isn’t alone in facing this threat. DDoS attacks on government services have become a common tool for hacktivists and state-sponsored actors alike. The recent incidents in Norway could be a sign of things to come, not just for the country but for the region.

What should citizens expect?

For now, the advice is to be patient. Digdir is working to restore full functionality, but it’s a process. If you’re in Norway and need to access public services, it’s worth checking the status page before trying to log in. And if you’re waiting for a prescription, you might want to give it a little more time.

The attack may be over soon, but its implications will linger. This incident has exposed vulnerabilities in Norway’s digital infrastructure that will likely require a hard look at how such services are protected. For a country that has embraced digitalization so fully, the stakes are high.

As the situation develops, one thing is clear: the digital age has brought immense convenience, but it has also opened the door to new kinds of chaos. Norway is now learning that lesson firsthand.

The Day a Trusted Maintainer’s Account Went Rogue

On August 20, someone quietly slipped into a well-known open-source maintainer’s account on crates.io, the official package registry for the Rust programming language. They didn’t cause a scene. Instead, they updated three legitimate crates — arrayref, internment, and append-only-vec — with a hidden backdoor. By the time the security team at Wiz noticed, the damage was already spreading.

This wasn’t a random act of digital vandalism. Wiz researchers Rami McCarthy and Benjamin Read tied the attack to state-sponsored North Korean threat actors, a group Microsoft tracks under the name Sapphire Sleet. The same infrastructure and tactics were used in earlier campaigns against the Mastra framework and npm packages targeting the Axios library.

The Rust supply chain attack is a stark reminder that open-source ecosystems are now a primary battlefield for nation-state espionage.

How the Backdoor Worked Without Touching Source Code

Here’s the sneaky part: the attackers didn’t inject malicious code directly into the crates’ source. Instead, they tweaked the package manifests to pull in an external, typosquatted dependency called proc-macro1. That rogue package exploited Rust’s build process — the very automation that developers rely on to compile projects quickly.

When a developer ran cargo build, the malicious payload executed automatically. No user interaction needed. No suspicious binary to spot. Just a normal build that silently triggered a download and ran unauthorized code in the background.

“Because build scripts run during compilation, building an affected project was sufficient to execute the payload,” the Wiz researchers explained.

That means even if the resulting software was never deployed or run, the machine that compiled it was already compromised. For security teams, this is the nightmare scenario: a supply chain infection that happens before the code even exists as a final product.

What the Malware Was After

Once triggered, the malicious binary went hunting for sensitive data. Its targets included:

• Stored web browser credentials
• Cryptocurrency wallet extensions
• Developer environment secrets, like API keys and cloud tokens

It’s a classic espionage playbook — steal credentials that can be used to pivot deeper into corporate networks.

The Blast Radius: 75% of Cloud Environments With Rust Apps

The scale of this Rust supply chain attack is sobering. According to Wiz telemetry, arrayref alone was present in roughly 75% of cloud environments running Rust applications. At the time of writing, that crate had over 245 million downloads on crates.io. The other two compromised crates, internment and append-only-vec, had 14.4 million and 4.5 million downloads respectively.

Those numbers put the potential exposure in the hundreds of thousands of developer machines and CI pipelines. Wiz’s report, published just hours after the campaign began, highlighted how a single compromised maintainer account could ripple across the entire ecosystem.

Why Rust Builds Made This Attack So Effective

Rust’s build system is powerful — but that power comes with risk. Build scripts run arbitrary code by design, which is how the proc-macro1 dependency executed its payload. For developers, this means the trust model of open-source dependencies is now under direct attack.

Security teams need to understand that a compromised dependency in a build pipeline is just as dangerous as a runtime vulnerability. In some ways, it’s worse, because the infection happens before security tools have a chance to inspect the final binary.

Strong North Korean Ties and the Sapphire Sleet Connection

The Wiz investigation didn’t stop at the malicious code. They traced the command-and-control (C2) infrastructure and found clear fingerprints of known North Korean operations. The network communication patterns, server setups, and specific endpoint paths were nearly identical to those used in previous campaigns.

Microsoft and other threat intelligence teams have attributed these operations to Sapphire Sleet, a North Korean state-sponsored group with a history of targeting software supply chains. The Wiz researchers noted that “the arrayref infrastructure substantially overlaps with operations attributed to recent North Korean actors.”

This is part of a broader trend: state-sponsored adversaries are increasingly weaponizing developer ecosystems to gain initial access to downstream enterprise networks. They’re not just attacking companies directly — they’re attacking the tools those companies build with.

What to Do If You Compiled the Tainted Crates

The Rust Security Response Team acted quickly after Wiz reported the issue. They revoked the compromised maintainer’s credentials and removed the malicious crate versions from crates.io. But for anyone who built projects during the affected window, the cleanup is more involved.

Because the payload executed during the build phase, the infection isn’t limited to the final software. Any system that compiled the tainted crates should be treated as potentially compromised. Security teams are urged to:

1. Inspect dependency lockfiles for the affected crate versions
2. Treat any machine that built these crates as compromised
3. Rotate credentials, cloud secrets, and API keys accessible on those systems

This incident is a reminder that supply chain security isn’t just about scanning for known vulnerabilities. It’s about monitoring build processes, auditing dependencies, and preparing for the worst. For a deeper look at how similar attacks have targeted other ecosystems, check out our analysis of npm supply chain attacks and the broader software supply chain security risks facing modern development teams.

The Rust supply chain attack may be contained, but the lessons it leaves behind are permanent. Trust in open-source code is precious — and increasingly, it’s being exploited.