How does the Lazarus Group achieve precision APT infiltration attacks targeting exchanges?

Author: Haotian

In the last AMA, there was a brief discussion about whether it was a potential APT advanced penetration attack and @benbybit's boss, but there was no clear conclusion on whether it was an internal penetration attack. However, if the investigation results indicate so, according to the latest report from Slow Mist, how did the North Korean hacker organization Lazarus Group achieve precise APT penetration attacks targeting exchanges? Below is a brief explanation of the logic:

Social Engineering Attacks:

1) Hackers first disguise themselves as project parties, investors, third-party partners, etc., to contact the company's developers; (this kind of social engineering tactic is very common)

2) They induce employees to run malicious programs under the pretext of debugging code or recommending development testing tools, market analysis programs, etc.; (there is a possibility of being deceived or being coerced)

3) Once the malicious program is successfully infiltrated, they can gain remote code execution permissions and further induce employees to escalate permissions and conduct lateral penetration;

Internal Network Penetration Process:

1) Utilize single-point breakthrough internal network nodes to scan internal systems, steal SSH keys from key servers, and use whitelist trust relationships to move laterally, gaining more control permissions and expanding the coverage of the malicious program;

(The question is, if exchanges have strict protective systems, why were there no alerts for anomalies during the entire penetration process? Slow Mist's conclusion is that they utilized the internal infrastructure of the enterprise to bypass most security device detections. It seems that the internal network systems need to strengthen red-blue team exercises to prevent penetration?)

2) Through continuous internal network penetration, ultimately gain access to the target wallet-associated server, and modify the backend smart contract program as well as the multi-signature UI frontend, achieving a switcheroo;

(Both the frontend and backend were tampered with, raising questions about how they bypassed the entire log data? Additionally, how did the hackers accurately ascertain which wallets were about to consolidate for large transfers? There are many doubts, making it easy to suspect that there might be "insiders" cooperating?)

Lazarus APT Advanced Persistent Penetration Attack Principles, Simplified Version:

Imagine the exchange's cryptocurrency cold wallet as a special vault located on the top floor of a high-end office building.

Under normal circumstances, this vault has strict security measures: there is a display screen to show each transaction's information, and each operation requires multiple executives to be present simultaneously to confirm the information displayed on the screen (for example, "Transferring XXX amount of ETH to XX address"), and only after all executives confirm it can the transfer be completed.

However, hackers, through meticulously planned penetration attacks, first used social engineering to obtain the building's "access card" (i.e., they invaded the initial computer). After successfully blending into the building, they managed to copy a core developer's "office key" (gaining important permissions). With this "key," hackers could quietly infiltrate more "offices" (conduct lateral penetration within the system to gain control of more servers).

Ultimately, they reached the core system controlling the vault. The hackers not only altered the display program (tampered with the multi-signature UI interface) but also modified the internal transfer program of the vault (changed the smart contract), so when the executives saw the information on the display, they were actually looking at tampered false information, while the real funds were transferred to an address controlled by the hackers.

Note: The above is just a common APT penetration attack method used by the Lazarus hacker organization. The @Bybit_Official incident currently does not have a final conclusive analysis report, so it should only be taken as a reference and not be taken personally!

However, I would still like to give @benbybit's boss a suggestion: Safe, which is more suitable for DAO organizations' asset management, only manages normal execution calls without verifying the legality of the calls. There are many better local internal control system management solutions on the market, such as FireBlocks and RigSec, which will perform better in terms of asset security, permission control, and operational auditing.