skip to Main Content

Cybercrime, IcedID banking Trojan is evolved with substantial changes

IBM X-Force: The IcedID banking Trojan is evolved and has made substantial changes

The IcedID banking Trojan is evolved and has made substantial changes. It has been discovered by IBM X-Force cyber security experts, who identified the malware for the first time in 2017. At that time, it targeted banks, payment card providers, mobile services providers, payroll, webmail and e-commerce sites, mainly in the U.S. Since then, the malicious code continued to evolve, until it’s latest version. Inside, changes have been applied in:

  1. New anti-debugging and anti-VM checks.
  2. Modified infection routine and file location on disk.
  3. Hiding encrypted payload in .png file (steganography).
  4. Modification of code injection tactics.
  5. Modified cryptographic functions.

The cyber security experts: The malware spread via malspam with Office attachments. Files boobytrapped with malicious macros that launch infection routine, fetch and run the payload

According to the cyber security experts, IcedID is spread via malspam emails typically containing Office file attachments. Cybercrime boobytrapped the files with malicious macros that launch the infection routine, fetch and run the payload. In February 2020 campaigns, maldocs spread in spam first dropped the OStap malware, which then dropped IcedID. OStap was also a vehicle for TrickBot infections in recent months. IcedID has a connection to the Emotet gang, having been dropped by Emotet in the past. The malware’s targeting has been consistent since it emerged. Its focus remains on the North American financial sector, e-commerce, and social media. IcedID targets business users and business banking services.

How the infection chain works

IcedD begins by loading encrypted code from the resource section, decrypts it and executes. As part of the code being executed, the loader uses some newly added anti-VM & anti-debugging techniques in order to check if it’s being run in a VM or a sandbox. The output of these checks, alongside other parameters, is then sent to the attacker’s C2 server to determine if the victim’s machine should be infected or not. If “yes”, the C2 server sends back the necessary files to execute, like the malware’s configuration file, the actual malicious payload and a few other accompanying files. The loader then copies itself into two locations. Next, in order to maintain persistency on the victim’s machine, it creates a task in the task scheduler triggering a run of the loader at log on and every hour. Then, it executes couple of anti-VM and anti-debugging checks to allow the C2 to ‘approve’ proceeding to infect the machine. The loader downloads all the necessary files in order to execute.

Back To Top