This post was authored by Ross Gibb with research contributions from Daphne Galme, and Michael Gorelik of Morphisec, a Cisco Security Technical Alliance partner.
Cisco has noticed an increase in infections by the banking trojan IcedID through our Advanced Malware Protection (AMP) system. Security researchers first reported a new banking Trojan known as “IcedID”  in November 2017. At the time of discovery, IcedID was being distributed by Emotet, another well-known banking trojan malware. In late February and throughout March 2018, we noticed an increase in infections from IcedID being detected throughout the AMP ecosystem. Like in November 2017, some of the infections could be traced to Emotet, but this time, many detections could instead be traced to emails with attached malicious Microsoft Word documents containing macros. When the malicious documents are opened and the macros are enabled, Rovnix, another trojan, would be downloaded and executed, which subsequently downloads IcedID. In addition to Rovnix, many of the samples downloaded a second payload, a Bytecoin miner (Bytecoin is a crypto currency similar to bitcoin).
Rovnix is financially motivated malware that is known to download and install additional modules, or other malware families. This Rovnix/IcedID attack was interesting for two reasons:
- The targeted nature of the emails that use spear-phishing techniques to entice victims into opening the malicious Microsoft Word documents.
- The minimalist code injection technique used by IcedID that improves on existing code injection techniques, and is harder to detect.
Figure 1: Malicious document that installs Rovnix and IcedID banker attached to spear-phishing emails
Use of spear-phishing emails
At first, this attack appeared to be similar to the countless malicious Microsoft Word documents with macros that Cisco blocks every day. In this case, when the documents are opened, users are enticed to enable macros in order to view the content. If the user enables macros within the document, an auto-close macro is triggered when the user closes the document that executes mshta.exe (a built-in Windows component) to download and execute a remote script. The remote script launches two instances of PowerShell to download and execute the Rovnix/IcedID and Bytecoin miner payloads.
This attack became more interesting when the targeted nature of the emails and the file names of email attachments were investigated.
Widely distributed malware families that spread over email (like Rovnix) generally send out their malicious messages in high volume. Most end-user security training programs center around helping users identify these kinds of emails, and to be suspicious of any unexpected emails. An attacker sending emails in large volumes has typically chosen email content that applies to a wide range of different recipients, but will not immediately be viewed as suspicious. For example, attackers have recently been using email content such as job applications with attached resumes, shipment delivery notifications with attached tracking information, or notices for payment with attached invoices. In contrast, spear-phishing attacks use emails that are much more targeted at the recipient, and contain information familiar to the recipient. Previously, spear-phishing was primarily used by advanced persistent threat (APT) actors who had specific targets.
Rovnix/IcedID is a clear example of the evolution of spear-phishing from exclusive use by APT actors, to use by malware families with wide distribution. For example, one of the Rovnix distribution emails had the following features:
- The email was sent to an employee of a city in the state of Arkansas.
- The email’s subject referenced a meeting relevant to city business.
- The email’s body referenced and discussed the meeting, as well as containing names of employees that work at the city.
- The name of the document attached to the email included the name of a civil engineering company local to Arkansas.
A similar example to the one above was found in a malicious email received by an electrical company in Raleigh, North Carolina. The file name of the attached document included the name of an engineering company also local to North Carolina.
Not all examples were as highly targeted to a specific business, but rather targeted users in a similar industry. For example, users with email addresses related to the automotive industry received emails with an attachment file name that referenced the name of a car dealership in Dallas, Texas.
The use of spear-phishing techniques to create emails containing references to people or businesses that the recipient is familiar with makes it more likely that the user will open the attachment and enable the macros within. Since spear-phishing emails require the attacker to create emails for each target, there is a higher cost to the attacker to launch this kind of attack, but will pay off if the attacker invests the time necessary.
Minimalist code injection
Once launched, IcedID takes advantage of an interesting technique to inject malicious code into svchost.exe — it does not require starting the target process in a suspended state, and is achieved by only using the following functions:
IcedID’s code injection into svchost.exe works as follows:
- In the memory space of the IcedID process, the function ntdll!ZwCreateUserProcess is hooked.
- The function kernel32!CreateProcessA is called to launch svchost.exe and the CREATE_SUSPENDED flag is not set.
- The hook onntdll!ZwCreateUserProcess is hit as a result of calling kernel32!CreateProcessA. The hook is then removed, and the actual function call to ntdll!ZwCreateUserProcess is made.
- At this point, the malicious process is still in the hook, the svchost.exe process has been loaded into memory by the operating system, but the main thread of svchost.exe has not yet started.
- The call to ntdll!ZwCreateUserProcess returns the process handle for svchost.exe. Using the process handle, the functions ntdll!NtAllocateVirtualMemory and ntdll!ZwWriteVirtualMemory can be used to write malicious code to the svchost.exe memory space.
- In the svchost.exe memory space, the call to ntdll!RtlExitUserProcess is hooked to jump to the malicious code already written
- The malicious function returns, which continues the code initiated by the call tokernel32!CreateProcessA, and the main thread of svchost.exe will be scheduled to run by the operating system.
- The malicious process ends.
Since svchost.exe has been called with no arguments, it would normally immediately shut down because there is no service to launch. However, as part of its shutdown, it will call ntdll!RtlExitUserProcess, which hits the malicious hook, and the malicious code will take over at this point.
Video: Identifying and analyzing IcedID’s minimalist injection technique (6:04)
Malware authors are constantly looking for more surreptitious ways to inject code into benign processes. Process doppelganging, a fileless code injection technique,  and atom bombing, a technique which uses atom tables for writing into memory of another process,  are examples of completely new classes of code injection techniques malware authors have recently found and leveraged. The minimalist process injection technique used by IcedID is an evolution of existing process injection techniques , rather than an entirely new class of technique.
Minimalist code injection does offer the following improvements over known techniques:
- Requires only four Windows API calls to achieve code injection.
- Does not require the created process to be created in a suspended state.
- Does not require new threads to be created in the target process.
Using fewer functions and less suspicious process-creation flags makes this minimalist code injection technique more difficult for security solutions to detect.
Cisco AMP for Endpoints’ new exploit prevention engine offers protection against both Rovnix and IcedID. While neither Rovnix nor IcedID contain actual exploits, both are detected and blocked by the AMP exploit prevention engine because of suspicious access to memory that each performs. In the case of Rovnix, memory manipulation done by its unpacking routine is detected. In the case of IcedID, when it performs the minimalist memory injection technique, it is detected when it attempts to place the hook on the ntdll!ZwCreateUserProcess function.
The use of spear-phishing emails targeted at specific organizations and industries by Rovnix/IcedID show that widely distributed malware families are adapting to an environment of improved defenses. As detection methods improve, and users become more skilled at identifying suspicious emails, attackers who could once send the same malicious email to all their targets are having to improve their techniques. But the use of the minimalist code injection technique by IcedID shows that attackers are changing their techniques post-infection to better hide and remain on systems that older injection techniques would likely have been detected on.
Additional ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.
CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as NGFW, NGIPS, and Meraki MX can detect malicious activity associated with this threat.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Indicators of Compromise (IOCs)
Unpacked IcedID binary demonstrating injection
(see hook on ntdll!ZwCreateUserProcess at 0x4016a6)
Additional IcedID binaries
The existence of a scheduled task at:
The “Exec” action within the scheduled task will take the command line argument “/i” and the path of the executable will be in the APPDATA directory. For example,