APT38 DYEPACK Framework used to Steal over $1.1 BILLION from SWIFT Banking Servers
by AKM
Posted on March 20, 2019 at 12:46 PM
Source: https://www.gtreview.com/wp-content/uploads/2018/10/Modern-bank-heist-graphic.jpg
Waterholing Style Attacks
In the natural world, predators lurk around regions full of resources that the victim feast on. They wait, they watch, then attack.
Similar to how watering hole attacks on financial firms work, as recent incidents … ;
- attackers identify numerous resources (like forums, subdomains, employee portals, et al)
- identify key vulnerabilities that allow them to burrow deep and then move laterally
- then use exploits upload specific payloads to these gateways in high hopes that an employee would execute them.
The rest is history. Like so with the prey and predator analogy, this also occurs naturally every day in organizations worldwide.
(If you're more interested on the "Watering-hole" attack style, check out this research I conducted for APT32 a.k.a. OceanLotus).
APT38 and its North Korean Attributes
So why financial firms in particular? Because they are the most profitable to any lone wolf or organized cybercrime unit. Take a look at APT38, a North Korean threat group that focuses on targeting financial institutions for profit.
According to a report conducted by FireEye, the funds APT38 gains from all their cyber heists go directly to the DPRK state interests as a result from all the economically damaging sanctions. APT38 is no threat to be taken lightly; as a collective, they’ve attempted to steal more than $1.1 billion dollars.
Here are some financial institutions that APT38 has targeted in the past:
- Vietnam TP Bank (December 2015)
- Bangladesh Bank (February 2016)
- Far Eastern International Bank in Taiwan (October 2017)
- Bancomext (January 2018)
- Banco de Chile (May 2018)
Source: https://content.fireeye.com/apt/rpt-apt38
One identified key operative (according to the FBI) is Park Jin Hyuk, a North Korean national with ties to APT38 and the well known "Lazarus Group" (also involved in engineering the WannaCry ransomware). Operatives like this are usually identified and tied through other hacker organizations via toolset overlaps. This usually occurs when the threat actor within the group uses the same libraries/scripts to create new tools.
A bank can sound very out of reach for any would be attacker. What does it take? Where does one start? You’d be surprised how easy it is to empty out an entire bank and leave almost no traces behind. Let’s take a closer look.
APT38 - Picking the right target to attack
APT38 starts off by gathering information on the target, this can be information on either third party vendors or the institution’s own personnel. This stage is the most important.
Like any hacker’s thought process, you don’t want to break in not knowing how the network infrastructure works (especially in a well "protected", alarm raising system like a bank), intelligence gathering and reconnaissance requires a lot of work, it can either break your operation completely and land you behind bars or leave you drowning in the riches.
Some information that may be useful for a heist like this is the bank’s daily routine, who’s in charge of what, what kind of software the employees use. Technical insider knowledge, how does the bank send out international transactions, what type of servers belonging to them are exposed to the internet, this type of data can easily be found with a little google dorking and/or company support pages/handbooks for employees (some banks have this material stored "securely" online).
APT38 has been spotted in the wild using email accounts like wangchung01@gmail.com and campbelldavid793@gmail.com to send spear-phishing emails to banks, using employee specific details obtained from LinkedIn by simply sending invitations to create and distribute phishing content in high hopes the target doesn’t check the integrity and validity of the email. Perhaps think twice next time you accept someone to your connections, you never know it could just be a North Korean state-sponsored hacker and not your long lost colleague.
If that doesn’t work, APT38 begins looking at numerous servers belonging to the organization for vulnerabilities. Vulnerabilities that reside in things like insecure Apache Struts2 servers, because once they have remote code execution capabilities, they can commandeer the network which will allow them to bring inside their own arsenal of tools like DYEPACK. The lesson here is simple: update, update, update.
Think of subdomains, areas in which that are used for support, backends that are exposed to the internet, outdated, forgotten and vulnerable endpoints. Once a vulnerability is found, they compromise the server and try to pivot even deeper into the internal network. (Pivoting is when you gain access to a system on the outside and use it to poke at things on the inside).
APT38 then looks for one specific node once inside an internal network, a SWIFT system. For readers who don’t know, SWIFT stands for Society of Worldwide Interbank Financial Telecommunications. It is an essential server in many financial systems worldwide responsible for sending and receiving financial instructions.
Each financial organization has a unique 8 or 11 character code called BIC (bank identifier code) set by the SWIFT network. SWIFT sets up the BIC like so;
- First 4 characters are the institute’s code
- Next 2 characters are the country code
- Last 3 are for the individual branch identifier (optional)
Source: https://www.investopedia.com/articles/personal-finance/050515/how-swift-system-works.asp
The BIC is used similarly to a phone or fax number, to connect and send instructions to other banks internationally. SWIFT is only a messaging system, it holds no funds or anything of that nature. It can only communicate with other SWIFT servers for receiving and sending transaction details. Banks are not the only type of institute that take advantage of SWIFT, other places include exchanges, money brokers, et al.
Once located within the network, APT38 uses the SWIFT system to then empty the compromised bank. It then takes counter measures to destroy all the evidence and leaves with all the funds sent to numerous undisclosed bank accounts. Sounds fictional but it’s very real and a quite common occurrence.
This is a code segment taken from one of the de-compiled binaries APT38 uses to intercept SWIFT statements. It stores all the statement numbers and transaction output in an array which it will use with another framework to assess. It also traverses in directories located in ‘C:\Users\[ADMIN_USERNAME]\Local\[ANY_DIRECTORY]\’
This would mean that APT38 has admin access to the system prior to releasing their arsenal of bank pwning toolkits. Obviously the reconnaissance and research they’ve done prior to emptying out the bank has paid off, because in the next stages you’ll see how they use system internal information to move laterally in the network and destroy evidence along with the SWIFT transaction information obtained from this executable.
[3a94c39632fe6b055eb90497b4d2763576d5d89b12ad3f23bfa0e85542b28ab1] Reverse Engineered DYEPACK with some interesting strings like ‘FEDERAL RESERVE BANK’ and ‘Debit’, ‘Credit’ transaction histories.
To accomplish this complicated stage, APT38 uses malware framework like DYEPACK to manipulate data in the SWIFT servers. DYEPACK ensures that bank employees do not find out about any fraudulent transactions made within the SWIFT system. It does this by modifying the database(s) that keep track of such records by issuing SQL commands to detect and delete rows associated with the fraudulent activity.
This DYEPACK sample is the same piece used in the Bangladesh Bank (February 2016) heist. The binary was compiled using Visual C++ (Thu Feb 04 13:45:39 2016). The file was originally 孟加拉樣本 which is Chinese for “Bangladesh sample”. The compile time and sample name (along with the contents) is enough evidence to show that this is indeed the DYEPACK framework used by APT38.
The attackers left these binaries behind even after the heist was complete - bad OpSec? Let’s take a closer look at the technical aspect:
These are the SQL statements DYEPACK executes, 'SELECT * FROM (SELECT JRNL_DISPLAY_TEXT, JRNL_DATE_TIME FROM SAAO)'. These are databases in which the SWIFT system uses to keep track of transactions. What the statement is doing is retrieving the transaction and date it occured on.
Why would DYEPACK want that information? Because if you’re going to empty out a bank, you want to delete all the transactions you’ve made using SWIFT. And so once the malware retrieves those logs using the transacted date, it deletes them like so:
In this data segment, DYEPACK begins destroying all financial transactions that have occured during that time frame. The SQL statement “DELETE FROM SAAOWNER.TEXT_%s WHERE TEXT_S_UMID = ..” is deleting rows by table name, in this case SAAOWNER.TEXT_%s is the table name where %s is just a string (meaning there are multiple areas within the SWIFT server that have that exact table name, followed by some sort of ID). Then the variable UMID which is more than likely the transaction number that DYEPACK wants to delete.
Because it doesn’t use the SWIFT framework to delete records, there are no logs from within it. If one where to investigate the integrity of the local database, they wouldn’t suspect a thing unless they dig deep in the server logs and see which SQL statements where executed (which requires the skills of a technician and not your average Joe banker).
So what about printed copies?
Here is the code segment in which the malware actively looks in the network to control incoming printers. Yea, this piece of malware doesn’t really like staying on one side of the network, it likes to interact with all the other devices on the network!
Once detected, the printers are issued a command. Where might that command be used in? In intercepting SWIFT messages from earlier SQL statement results that are then forwarded to a printer.
Here’s a decompiled version of DYEPACK’s printer interception function. The command carries through to an open printer on the network, and executes the new command rather than the one issued by the SWIFT service. So ideally, the transactions are changed in the database, and any printed copy requests are also intercepted and modified with the new modified data. Rendering new printed copies of transactions unreliable.
According to FireEye, one victim didn’t use printed copies to keep track of all the transactions, instead they relied on PDF documents. With their heavy researching capabilities, APT38 knew about this and went forth modifying their version of DYEPACK to have the ability to read and modify all PDF documents opened by the bankers.
Which PDF Documents Did the Bank Open?
How did the attackers know which documents were opened in order to modify them and rid of all transaction for good? They discovered that this specific branch used a particular PDF reader (Foxit PDF reader) to open their PDF documents.
All the intruders had to do now was finding out where this reader kept all the logs of recently opened documents and voila - remove all the present transactions as they’re being opened.
To support its evasion techniques, DYEPACK includes a self-destruct module that comes with a predefined day in which the malware removes itself and all the service entries associated with it. This makes it even harder for forensic analyst to reconstruct.
Evasion? Or shit code?
When I conducted the malware analysis of DYEPACK, I came across another binary that seems to make a ping request to the IP address 0.0.0.0. This is a common evasion technique used to determine whether or not network traffic is being manipulated (by making all addresses valid, you can see the information being transmitted across the network when running dynamic analysis on the samples). The idea here is that if 0.0.0.0 (an invalid address) makes a reply, then the malware is in an environment that’s being analyzed. From there the framework can decide to self-destruct, not executing what it should.
Occasionally, the APT38 group doesn’t take advantage of its own toolkits. Instead, the attackers use what’s already present in the system. Taking advantage of internal tools within the environment allows them to draw less attention, better understand the internal network structure, and get an idea how operations are conducted under user policies and management. This approach also enables the intruder to appear like a normal employee.
Does this sound like like a spy movie? As you can tell, the technicality of it is not so complex, rather the level of information gathering is the only barrier that stops any would-be attacker from emptying out an entire bank.
Prevention Techniques
In all water-hole style attacks, there was one persistent attribute that allowed the compromise to be pulled off: data. Sure the servers here and there were outdated, sure the employee clicked on the attachment in the email, but had it not been for clever reconnaissance and information gathering, none of this would have been possible.
So what’s the takeaway here? It’s the same old advice everyone’s been telling you: be careful what you put online. Literally. Keep internal stuff, internal. Don’t open servers that are only meant for personnel on the internet. Don’t give access to anyone information on about who you know, who your manager is, et al. That’s all information that makes spear phishing easy to pull off.
And yes. Update all your systems in a timely manner. Don’t think that no one will know about that one hidden vulnerability that you have been waiting on to patch, there are scanners for that. People will find out. Don’t just push every patch to one big update in months to come, release small minor updates here and there.
If utilities like full disk encryption, firewall managers, even antivirus, benefit your organization then deploy them! Sure they won’t stop once they’re in, but it can make it harder for them to progress and move laterally.
Source Files
I’ve uploaded the samples and RE’d counterparts in this repository. If I've missed something here that you've found in the live binaries, feel free to reach out to me.
InfoSec Related