Two H1 2026 attack chains

Gen Threat Labs followed two H1 2026 campaigns where attackers used legitimate accounts, browser settings and blockchain data as part of the attack path.

The Gen Threat Report is a twice-yearly examination of the biggest cyber threats shaping the digital landscape, offering an in-depth look at the trends affecting consumers around the world. Gen’s H1 2026 Threat Report has its share of headline numbers.

Scams accounted for almost 46% of Gen threat detections in the first half of the year. Malvertising represented almost another 30%. Gen blocked 114.2 million e-shop scam attacks and 20.3 million tech support scam attacks during the same period.

Those figures are useful, but they compress very different attacks into a handful of categories. A detection count does not show how the first lure became script execution, how the script became a browser or proxy change, or how a wallet address was replaced before the victim signed a transaction.

Two H1 investigations are worth looking at in detail. In the first, a banking-malware campaign started with compromised corporate mailboxes and ended with proxy and browser manipulation.

In the second, a cryptocurrency campaign used a Rust-based clipper and retrieved command-and-control infrastructure pointers from Binance Smart Chain.

The payloads were different, but neither campaign depended on breaking the trusted system in front of the user. The banking campaign used a legitimate account to deliver the lure. The clipper let the blockchain record a valid transaction after changing the destination address locally.

The business email really came from a business

The banking campaign targeted users in Czechia, Slovakia, Poland and Lithuania. The lures looked like normal business emails: shipment notices, invoice-related messages and scanned document notifications. One simply told the recipient that a scanned copy of a shipment was attached.

In several cases, the messages were sent from compromised corporate mailboxes. The email was not made to look like it came from a legitimate company. It came from a legitimate account that attackers had already taken over.

SPF and DKIM can still pass when a message is sent through authorized infrastructure, while reputation systems may see a sender with a legitimate history. 

The attachment launched a JavaScript dropper. From there, the chain moved through PowerShell stages before reaching shellcode and banking functionality. The available indicators pointed towards GepyS.

The malware modified proxy settings and installed a browser add-on, placing itself close to the victim’s banking session. 

At a simplified level, the chain looked like this: compromised mailbox -> JavaScript dropper -> PowerShell stages -> shellcode loader -> proxy and browser manipulation.

One stage-three payload used a 32-bit position-independent loader. Static analysis showed MMX and SSE junk instructions, jumps into the middle of instructions, and a decryption routine based on an LFSR-generated keystream followed by XOR.

None of those techniques was new, but together they added enough friction to make a quick static pass less productive.

Across the chain, the email only had to get the user to open the attachment. JavaScript and PowerShell handled the staging, the loader slowed analysis, and the proxy and browser changes moved the operation into the banking session.

Comparable H1 campaigns used similar regional and operational patterns with different payloads. In Italy, fake invoice PDFs, including Booking.com-themed lures, led to Vercel-hosted scripts with per-victim JavaScript obfuscation, Blogspot-hosted PowerShell stages and XWorm.

In Poland, invoice-themed phishing delivered a steganographic .NET loader that installed Remcos RAT.

The clipboard was the payment layer

The second campaign abused a much smaller user interaction: copying and pasting a cryptocurrency address.

The final payload was a Rust-compiled clipboard hijacker. It monitored copied content for wallet addresses across 21 blockchain types, including BTC, ETH and LTC. When the malware recognized a supported address, it replaced it with an attacker-controlled one.

From the victim’s point of view, the transaction could still look normal: copy an address, paste it into a wallet or exchange, and approve the payment.

The blockchain was not compromised and the wallet’s cryptography was not broken. The transaction itself was valid, but the destination had already been changed locally before signing.

Wallet addresses are long, visually noisy strings and difficult for humans to verify. Many users check only the first and last few characters, giving attackers room to use replacement addresses that survive a quick glance.

The command-and-control design added another layer. The malware used Binance Smart Chain as part of its C2 resolution through EtherHiding. It did not store the full backend on-chain. Instead, it read infrastructure pointers from data stored in a smart contract and used them to reach attacker-controlled infrastructure.

The resolved domain, URL or IP address could be blocked, taken down or replaced. The smart-contract data remained publicly readable, useful as an investigative pivot and harder to remove through normal takedown processes.

A simple network IoC list therefore aged quickly in this setup.

The contract address, the method used to read its data, the returned value and the infrastructure reached afterwards belonged in the same investigation.

Detection has to follow the sequence

For the banking chain, sender authentication needs to be paired with post-delivery telemetry. An attachment launching JavaScript, PowerShell retrieving additional stages, shellcode execution, proxy changes and a new browser extension should be correlated as one sequence rather than handled as unrelated events.

A sender’s legitimate history should not lower the priority of that activity when the mailbox itself may be compromised.

Where operationally possible, organizations can restrict script interpreters for users who do not need them, apply application-control policies to downloaded attachments and alert on unexpected proxy or browser-extension changes.

Monitoring for mailbox takeover remains part of the same detection problem because the compromised account is also the delivery infrastructure.

For the crypto campaign, defenders can monitor clipboard-modifying processes, wallet-address pattern matching and blockchain queries from applications that have no reason to make them. The smart-contract pointer and the infrastructure it resolves should be tracked together rather than treating the current C2 domain as the complete indicator set.

Users making cryptocurrency payments should verify the full destination shown by the signing device or wallet immediately before approval.

Address books or allowlists reduce repeated manual entry, while first-time or changed destinations deserve a full comparison rather than a check of only the opening and closing characters.

In both campaigns, the first trust decision could look legitimate while the surrounding workflow had already been changed. Detection and verification need to cover the steps between the authenticated email, the copied value and the final action.

Gen’s H1 2026 Threat Report covers the broader picture across scams, malware, identity exposure, privacy and AI-driven attacks.

Read the full report here: Gen H1 2026 Threat Report.

Sponsored and written by Gen Digital.