1/ @deBridgeFinance has been the subject of an attempted cyberattack, apparently by the Lazarus group.
PSA for all teams in Web3, this campaign is likely widespread.
2/ The attack vector was via email, with several of our team receiving a PDF file named “New Salary Adjustments” from an email address spoofing mine.
3/ We have strict internal security policies and continuously work on improving them as well as educating the team about possible attack vectors.
Most of the team members immediately reported the suspicious email, but one colleague downloaded and opened the file
4/ This made us investigate the attack vector to understand how exactly it was supposed to work and what the consequences would be.
Attack won’t infect macOS users: opening this link on a Mac leads to zip archive with the normal PDF file Adjustments.pdf (md5: 15a4…39c2)
5/…while opening this link on Windows systems leads to an archive with password-protected pdf with the same name (md5: 0038…8bc4), and an additional file named Password.txt.lnk (md5: 2eaa…6a30)
6/ The attack vector is as follows: user opens link from email -> downloads & opens archive -> tries to open PDF, but PDF asks for a password -> user opens password.txt.lnk and infects the whole system.
7/ We’ve inspected password.txt.lnk and here's a brief description of its contents/actions.
LnkParse shows us that clicking the lnk file will execute a cmd.exe command.
8/ Long story short, this command performs the following actions:
9/ Opening the link in the browser won’t give any content, so we tried to simulate mshta.exe headers with cUrl and it worked!
10/ Moving deeper into the rabbit hole reveals what this script does:
1. Show notepad.exe with “pdf password”: Salary2022 2. Check if Antivirus processes are active (ekrn - Eset, qqpcrtp - Tencent, bdagent - BitDefender)
11/ 3. If no AV processes are found: save the generated malicious file named Box.lnk into autostart folder 4. Decode Base64-encoded backdoor from var lp, save it into a file with a random name
Here is how it looks:
12/ This simple script sends repetitive requests to the attacker command center (CnC) in order to receive instructions.
Replacing eval with logging/echo in the code allowed us to receive malicious instructions from the CnC and analyze them without execution.
13/ After a series of empty responses we were finally able to receive the next part.
Fast analysis showed that received code collects A LOT of information about the PC and exports it to CnC: username, OS info, CPU info, network adapters, and running processes.
14/ System is considered compromised at the moment because any code from CnC can be performed on the infected machine.
It’s interesting that only a few anti-virus solutions mark these files as malicious.
17/ Indicators of Compromise: CnC: www[.]googlesheet[.]info
New Salary Adjustments.pdf (clean): 15a42f76f41c8f4bab828160e4fd39c2
New Salary Adjustments.pdf (with password): 00380fcbb2af75ec177301d44d658bc4
password.txt.lnk: 2eaa53ccb43cd38a1f0a28abcd7f6a30
18/ TL;DR: Never open email attachments without verifying the sender’s full email address, and have an internal protocol for how your team shares attachments!
Please stay SAFU and share this thread to let everyone know about potential attacks 🔐 🤝
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/ ETH devs, have you ever seen a discrepancy between the gas amount estimated by an arbitrary @ethereum node and the amount the transaction actually consumed? We’ve faced underestimations of 2-3x, but deBridge Solidity lead @alexeychr made an interesting discovery. A 🧵⤵️
2/ Years ago, two major implementations (geth, ganache) were performing transaction executions during the eth_estimateGas call to obtain the amount of gas consumed.
This approach may have led to underestimation because of internal gas refunds.
3/ A gas refund may occur in multiple ways, e.g. when the called contract writes data to a storage variable (which costs some gas) and later reverts the variable to its initial value.
1/ A quick analysis of what happened with Optimism and how the hacker managed to create a @gnosisSafe wallet in @optimismPBC with the same address as Wintermute has on Ethereum 🧵
2/ @wintermute_t Gnosis Safe wallet was created on the Ethereum chain 561 days ago through the old Gnosis factory contract 0x76E2c (version 1.1.1). The addresses of all wallets created through this version of the factory only depended on its' nonce (the serial number).
3/ If a transaction of your Gnosis Safe wallet deployment was 5th on the factory contract, then anyone who will be 5th to create Safe on another chain will get the same address — only if the addresses of the factory contracts are the same (0x76E2c) in different chains
2/ deSwap Widget is a capital-efficient solution allowing you to easily offer cross-chain swaps + transfers of arbitrary assets from within your app or site.
Integration is as simple as injecting the Widget code, and then customizing the appearance/chains/tokens desired.
3/ The Widget can drive a range of new UX improvements for your users, packing multiple cross-chain interactions into a single transaction.
For instance, swap Token X on Chain A to Token Y on Chain B and supply liquidity to a smart contract — with one signature!
1/ Since the @wormholecrypto vulnerability was patched here are some details that our Rust team discovered. The attack was performed through Rust contracts in Solana. This is the transaction where the attacker minted ETH tokens solscan.io/tx/2zCz2GgSoSS…
2/ This is the transaction where signatures verification was performed for this minting: solscan.io/tx/25Zu1L2Q9uk…
3/ By design, @solana has a special sysvar::instructions that provides information about previously executed instructuctions. github.com/solana-labs/so…
Quick view in the Wormhole code. There is a public method `publishMessage` that makes validators sign any arbitrary payload. Theoretically, an attacker could form a payload that withdraws a specific token and get it signed through this function
The only protection from that is this verifyBridgeVM check during the claim, which validates the correctness of the address that initiated this message. It seems that the hacker managed to make Solana Smart Contract sign a message on behalf of the contract dashboard.tenderly.co/tx/mainnet/0x2…
3/ Here is the same post_message function in the Rust program for Solana