Houdini Worm Transformed in New Phishing Attack

By Nick Guarino and Aaron Riley

The Cofense Phishing Defense Center™ (PDC)  and Cofense Intelligence have identified a new variant of Houdini Worm targeting commercial banking customers with campaigns containing either URLs, .zip, or .mht files. This new variant is named WSH Remote Access Tool (RAT) by the malware’s author and was released on June 2, 2019. Within five days, WSH RAT was observed being actively distributed via phishing. Figure 1 shows an example message from this campaign.

Using Windows 10? It’s Becoming a Phishing Target

CISO Summary

Cofense IntelligenceTM has recently seen a complex phishing campaign that delivers a simple payload, FormGrabber keylogger malware. The targets are Windows 10 operating systems running Windows Anti-malware Scan Interface (AMSI). The phishing emails deliver a Microsoft Excel Worksheet containing a MS Word macro that initiates infection.

What’s notable: threat actors are hitting Windows 10 instead of Windows 7, a more common target. Expect to see greater abuse heaped on the newer version as more businesses adopt it. No one aspect of this campaign is novel, but the attackers easily assembled a complex infection chain using multiple obfuscation and evasion techniques—another sign of how quickly criminals innovate when motivated.

 Full Details

Cofense Intelligence recently observed a campaign where threat actors targeted Windows 10 operating systems and used a complex multi-stage campaign to deliver the relatively simple FormGrabber keylogger. The emails utilized a Microsoft Office Excel Worksheet with an Office Word macro to initiate the infection. If macros were enabled, this macro would execute a PowerShell script that compiled embedded C# code content into a .NET dll. The .NET dll was loaded as a PowerShell module that then downloaded and executed the FormGrabber keylogger. The code used in the PowerShell module specifically targets Windows 10 computers which have the Windows Anti-malware Scan Interface (AMSI) installed.


Each email identified within this campaign had two attachments: the first was a Microsoft Office Excel Worksheet, the second was an RTF document. This RTF document contained five embedded copies of the same Excel Worksheet, as shown in Figure 1.

Figure 1: Copies of the same embedded Worksheet object

When the document is opened, the victim is prompted five times (once for each of the embedded worksheets) to enable macros. After all the prompts have been responded to, the RTF document will be opened. The method used to embed the worksheet objects into the RTF document requires that the worksheet objects be displayed in some form or fashion. In most cases, threat actors will carefully attempt to hide the object to avoid tipping off victims. As shown in Figure 2, in this case the threat actors simply let the default primary worksheet display in the footer section of the document.

Figure 2: The image displayed in the footer of the RTF document

Here the threat actors repurposed a legitimate example worksheet from Carnegie Mellon University to hide malicious content. The file size and macro run by the attached and embedded Excel worksheets are different, however the end result and final payload location are the same, indicating that the two attachments were likely used for redundancy.


Automated systems often examine the macros in documents in an attempt to determine their intentions. Even if the macro is encoded or obfuscated, modern anti-virus should be capable of reversing the changes or at least detecting key malicious components without running the macro. The macros in these worksheets used a simple technique that may have allowed the threat actors to avoid some automated defenses, crafting a macro that decoded content stored in a cell on a seemingly empty page of the worksheet, as shown in Figure 3. Note that the macro (one line of which appears at the top of the image) references cell “J106” on sheet “RPNLU.” All cells in sheet “RPNLU” appear to be empty and the default page view has cell “J106” out of view, ensuring that even if manually opened, the only obvious discrepancy between the original legitimate worksheet and the malicious one is the addition of the sheet “RPNLU.”

Figure 3: Disguised data used by macro (top of image)

Once decrypted, this macro then launches a PowerShell process which contains another subsection of encrypted data, as shown in Figure 4.

Figure 4: Second stage of the PowerShell script

This PowerShell command takes the encrypted content and decrypts it into C# code, which is then compiled into a .NET dll and loaded as a PowerShell module.


The compilation and multiple layers of encryption involved in this process are all used to “bypass” AMSI. AMSI is a Windows 10 exclusive feature intended to help detect and prevent scripts and “fileless threats.” In order to “bypass” AMSI, the threat actors avoid downloading files and perform other obviously malicious activity in the code that runs in the PowerShell console. Instead they focus only on disabling AMSI by adjusting where it looks for malicious content. The code used for this is similar and almost identical in some places to the proof of concept described in this blog post. Once AMSI is properly disabled, the threat actors then load in the C# code including the explicitly malicious code compiled in a .NET dll as a PowerShell module. A relevant portion of this code can be seen in Figure 5.

Figure 5: A modified version of the original POC code to bypass AMSI

Results and a Look Ahead

Threat actors used a complex infection chain that specifically targeted a key component of Windows 10 operating systems, rather than the more common Windows 7-focused malware, to deliver FormGrabber keylogger. As more businesses switch to the Windows 10 operating system, threat actors, like the ones seen here, can be expected to switch their targets to Windows 10 as well. Although none of the techniques used in this campaign were particularly novel, the fact that it utilized multiple obfuscation and evasion techniques and was so easily assembled from already created work indicates how quickly and significantly threat actors can improve, given the proper impetus. As is usually the case when it comes to vulnerabilities in key components, a patch to prevent this method of AMSI bypass exists. However, businesses first need to be aware of the problem. Knowledge of the evolving threat landscape and the different ways that it can affect a company are key to promoting a secure environment. To improve your security posture, take preventative action by patching systems and training employees to recognize and prevent the first stage in an infection chain.


All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

Patch or Pass? CVE-2017-11882 Is a Security Conundrum

CISO Summary

Since the latter part of 2018, threat actors have increasingly exploited two Microsoft vulnerabilities: CVE-2017-11882 and CVE-2018-0802. The first of these is especially popular. Cofense IntelligenceTM has seen it surge ahead of Microsoft macros as a favorite malware delivery method.

CVE-2017-11882 is an older vulnerability that in fact has a patch. However, it presents a conundrum for security teams that haven’t addressed the problem. They can choose to skip the patching, live with the risks, and keep on using the legacy program. Or they can update, patch, and lose the application entirely to gain much better security.

In the meantime, threat actors will happily exploit every chance they get.

Full Details

The vulnerabilities in Microsoft’s Equation Editor that are exploited in CVE-2017-11882 and CVE-2018-0802 have been “patched” for over a year. However, these vulnerabilities remain popular with threat actors and have become increasingly common since their inception. There are several factors involved, but Cofense Intelligence assesses that CVE-2017-11882 is still commonly used simply because it works, reaffirming the challenges associated with patching and the risks of operating legacy platforms. CVE-2017-11882 still works as a delivery mechanism on unpatched or unsupported versions of Microsoft Office and is most commonly used to deliver simple information stealers.

The Progression

In September 2018, Cofense Intelligence covered the most common malware delivery methods and highlighted Microsoft Office macros as making up the majority of the most common malware delivery methods. Over the last six months, we have observed a sharp increase in the exploitation of CVE-2017-11882.

The threat actors who switched to using CVE-2017-11882 as their primary delivery method focused significantly on information stealers, such as Loki Bot and AZORult, which make up 33% and 16% of the malware delivered respectively. In contrast, the most common Remote Access Trojan (RAT) is NanoCore RAT, which is the fifth most frequently malware delivered at only 7%.

Figure 1: Frequency of malware family delivered by CVE-2017-11882

But You Said There is a Patch!

Cofense Intelligence assesses that the most common reason CVE-2017-11882 still works for threat actors is that the patches intended to remedy it simply are not in place on several endpoints. Rather than assuming that support teams are incompetent, given that over a year has passed since the first patch, it is more likely that companies are being faced with a product support conundrum.

Businesses must choose between two options. The first is accepting a level of risk and continuing to use legacy programs by not patching. The second is to update, patch, and in this case, allow the removal of an application entirely in order to have significantly higher security. This is much easier for large businesses with great resources to devote to upgrades and security. For smaller businesses—including boutique subsidiaries of major businesses—this is much more difficult. Again, given the amount of time that has passed, it is unlikely at this point that anybody who has not yet updated will do so any time soon, allowing threat actors continued access.

To stay ahead of emerging phishing and malware threats, sign up for free Cofense™ Threat Alerts.


All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

Pretty Pictures Sometimes Disguise Ugly Executables

CISO Summary

Reaching deep into their bag of tricks to avoid detection, threat actors are using an oldie but goodie— packing image files (think tropical beach scenes) with malicious executables, usually a .jpg. The technique allows attackers to avoid detection by some anti-virus programs that merely recognize a file as an image, but don’t check its full contents.

This vintage tactic works—threat actors still use it a lot. Anti-virus systems rely on file headers to detect malware. Tuning systems to rely less on file headers is difficult and sometimes impossible. One counter-measure that does work: educate employees not to fall for phishing emails and encourage them to report any they find suspicious.

Full Details

Cofense Intelligence™ has been tracking the ongoing usage of image files to disguise malicious executables, a technique that can easily bypass network security measures. Threat actors will use a first stage malware downloader to retrieve an image file, most often a .jpg. The malware downloader then extracts a malicious executable that is embedded within the image. Finally, the malware runs the extracted binary in memory to avoid dropping an additional executable to disk. By using this technique to download the second binary, threat actors are able to avoid detection by some anti-virus (AV) programs that can determine the downloaded file to be an image but do not check the rest of the file contents.


The malware downloader often used to deliver these types of files is an executable using the .NET framework. From May 2018 to April 2019, Cofense Intelligence saw images with embedded executables comprising more than 70% of the binaries downloaded by .NET executables. The images can be anything from famous actors to server rooms, but one of the more common ones can be seen in Figure 1.

Figure 1: Commonly seen image

The images used not only display correctly but often have additional “metadata,” an example of which can be seen in Figure 2. This metadata is not present in all cases and may be an artifact from the original image before it was modified.

Figure 2: Additional meta data included in the image


The downloaded files are treated as images because of their file header and to a lesser degree, their file extension. File headers help the operating system determine how to interpret the contents of the file and can indicate several factors, such as whether a file is an image or an executable. Figure 3 illustrates that images with the .jpg extension, also known as JPEG images, will have the characters “JFIF” near the start of the file.

Figure 3: JPEG image file header

This header is also used by most AVs to determine the file type, as it is much more reliable than a file extension. When a “JFIF” header is read by most AVs the rest of the file will be ignored as long as the image is not broken or incomplete. The subterfuge of using an image file header also enables threat actors to bypass most network security measures which, like local AV, will treat the file as an image and ignore its content. By including an image that will properly display, threat actors are able to satisfy all of the conditions required for their malicious content to be ignored by security measures and “safely” delivered to the endpoint. This also ensures that if a file is manually downloaded and opened it will appear legitimate to the end user.


Creating an image file that meets these requirements also ensures that the operating system does not recognize the file as an executable and will not execute the file, regardless of the program used to open it. This fact requires a downloader, such as a .NET executable, to “extract” the malicious executable from the image file. This can be easily done by searching the file contents for the file header representing an executable, “MZ,” as shown in Figure 4.

Figure 4: Embedded executable header

Once this header is found, the executable content is carved out and loaded into memory rather than executing a file dropped to disk. Because the content is executed in memory rather than from an actual executable file, it is less likely to be recognized by AV as malicious. Most AV solutions do not monitor the memory of a process already running, which allows the malware to perform most of its activities without being noticed.


The fact that both a downloader and an image file are required to complete the infection is an important part of the infection strategy. If an image file is run by itself in an automated environment, it will simply display an image, with the only possibility of detection relying on the image file content having suspicious text. If only the downloader is executed and the image payload is unavailable, then it may be detected as suspicious, but on its own would not provide defenders with enough information to fully combat the threat. This requirement of having both stages together helps hide from defenders using automated analysis systems that are focused on individual files.

Why It Matters

Although not a new technique, the consistent popularity and utility of this approach to malware delivery merits attention. Threat actors abuse of operating system and AV reliance on file header recognition has been and will continue to be a problem. An example of threat actors abusing this reliance to trick AV systems as well as analysts was also recently covered by CofenseTM. Tuning AV systems to detect malware without relying on file headers is difficult and, in some cases, impossible. To properly recognize threats, it is important to have a full picture of the different components involved in an attack rather than attempting to organize individual and possibly incomplete analysis. To avoid this pitfall and better protect their network environments, organizations need to ensure that employees are trained to not fall victim to the phishing emails and that defenders are ready should an incident happen.

To stay ahead of emerging phishing and malware trends, sign up for free Cofense™ Threat Alerts.


All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

Babylon RAT Raises the Bar in Malware Multi-tasking


Ancient Babylon defeated its enemies with chariots, horses, and archers. Now Cofense IntelligenceTM has analyzed a phishing campaign delivering the powerful Babylon Remote Administration Tool (RAT). This malware is an open-source tool that can handle many tasks: encrypt command-and-control communication, hide from network security controls, trigger denial of service (DOS) attacks, and last but not least, steal data. Used skillfully, Babylon RAT would make the armies of Hammurabi proud. 

Full Details

Cofense Intelligence has analyzed a phishing campaign delivering a multi-feature open source Remote Administration Tool (RAT) named Babylon RAT. Babylon RAT’s Command and Control (C2) communication is encrypted, allows for dynamic domains, and can turn a client into a reverse SOCKS proxy for further obfuscation. This weaponized RAT has many real-time client interaction methods and is capable of information theft. The administration panel has features that can allow for lateral propagation across end points on a network. This tool has enough features that, if used correctly, could devastate any organization.  

Babylon RAT’s client code is written in C# and is dependent on .NET 4.5. The administration panel (shown in Figure 1) is written in C++, and provides the functionality to manage multiple server configuration options. One option is the port number in which the administration panel will open and listen in when the server is started. Another option is a network key for authentication of the infection to the administration panel. Lastly the configurations allow for the setting of the IP version in which it will connect. The File drop down at the top provides access to the server, configurations, and the payload builder. 

Figure 1: The administration panel and the management tabs for Babylon RAT 

C2 Details 

The initial C2 connection the client binary makes after being executed is hardcoded into the binary when it is built. The building process suggests dynamic domains so that the IP address can be changed without interruption to the communication. This connection is encoded and contains fingerprinting information about the infected host. This information includes IP address, Country, Username, PC name, Operating System (OS) details, and which program window is active for the end user. After initial communication with the C2, the infected endpoint will update the administration panel every 5 seconds by default. The check-in notice sent to the server from the client consists of very small network packets, only about 4-8 bytes in size. Figure 2 shows the administration panel with the details listed above. 

Figure 2: The administration panel and the fingerprinted information as listed above for Babylon RAT 

Babylon RAT has the ability to turn an infected machine into a SOCKS proxy, specifying between version 4 or 5. The main difference in the versions: version 5 provides authentication from the client to the proxy, which helps negate abuse from unwanted parties. By creating a SOCKS proxy, the threat actors create an encrypted tunnel and can have all of the infected hosts use it as a gateway, which allows for network capturing. This can also allow for a threat actor to need only one exit point within a network, while maintaining the infection of multiple machines. Meaning, if a threat actor can maintain communication with one endpoint in a network, he can then propagate laterally and have all the traffic from the infected clients C2 network flow back out the one endpoint. With access to the command prompt and stolen credentials, this would be trivial to do. This technique would also bypass email and URL filtering of unwanted binaries. Figure 3 shows the SOCKS proxy endpoint details and the amount of traffic flowing through it. 

Figure 3: The SOCKS proxy tab and the details associated 

The client builder gives the option to use two different C2 domains for redundancy. When combining the ability to use multiple dynamic domains with a proxy server, a threat actor could effectively create layers of obfuscated traffic between the endpoint and the client through multiple channels.  

Figure 4: The surveillance options that are available to the operator 

Notice in Figure 4 the option for password recovery. The password recovery module looks through applications, including web browsers, and harvests credentials but does not gather the OS user credentials. Although one could surmise that with the username above and a couple of passwords harvested, the OS user credentials could be compromised. If the OS user credentials are compromised, it would be easy for the operator to open the remote command prompt and attempt to log in to other network machines using those credentials. If successful at logging into another machine, it is then possible for the operator to have the second machine download/execute another payload. This would need to be automated, but it does reflect a propagation method for the RAT. Figure 5 shows the system options including the remote command prompt option. 

Figure 5: The system options that allow for further interaction and detail of the infected system 


Adding to its already long list of functions, Babylon RAT has the ability to produce Denial of Service (DoS) attacks to targets from the infected hosts. The DoS feature can be set to a hostname or IP range and allows for multiple protocols to be initiated. The protocols all have thread and socket parameters that are adjustable. A threat actor can select to have the attack come from an individual protocol or all of the protocols available. Once this command is sent to a single host, the operator can easily replicate the command to the other infected hosts, effectively creating a larger Distributed Denial of Service (DDoS) attack. Figure 6 shows the configuration for the DoS attack and Figure 7 shows the machines status change to DoS. 

Figure 6: The parameters available for the DoS attack

Figure 7: The administration panel and the multiple infected hosts carrying out a DDoS attack 

In the End 

Babylon RAT is an open-source platform that allows for various misdeeds. The encrypted traffic and the ability to create SOCKS proxies can help negate network security measures. The client builder allows for Anti-Virus bypassing which helps the binary get to the endpoint safely. The processes allowing for network propagation means an infection is not limited to one endpoint. Combined with the ability to perform a DoS attack, Babylon RAT can be highly effective in the proper environment. Babylon RAT campaigns can be avoided with proper technology in place and by educating end users to recognize and report suspicious emails.  

To stay ahead of emerging phishing and malware threats, sign up for free Cofense Threat Alerts. 


All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.  

Flash Update: Emotet Gang Distributes First Japanese Campaign

Cofense Intelligence™ has identified yet another change in Emotet’s behavior, this time distributing a campaign targeting Japanese-speaking recipients. The messages, which reference potentially overdue invoices and the payments thereof, deliver a macro-laden document, as per Emotet’s modus operandi. Figure one shows an example email from this campaign.

Diversifying their target-base is the latest link in an ever-lengthening chain of updates and refinements being pushed by the actors behind Emotet. The targets in this campaign include Japanese academic institutions, demonstrating a keen interest in Emotet securing a presence in such networks worldwide.


Subject Lines

請查看和 批准。 謝謝。

 Attachment Names

878345912 99590954.doc
31021154 71136771.doc
64123575263 958618.doc
72239600 553010.doc
823522415 83838965.doc
86726152984 4077671.doc
97016848095 4035273.doc
04546449854 46414589.doc
12129058435 35307309.doc
18009110 429772.doc
19529643 07207376.doc
22789621095 667097.doc
459894237 3920280.doc
48513288 3409281.doc
514855331 4861472.doc
60475231104 37366668.doc
6325401702 834277.doc

Attachment Hashes


Payload URLS


Payload Hashes



Filename Regex


Cofense continues to closely track Emotet’s evolution. Watch this space for further updates. To stay ahead of emerging phishing and malware trends, sign up for free Cofense™ Threat Alerts.

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

Emotet Gang Switches to Highly Customized Templates Utilizing Stolen Email Content from Victims

Beginning the morning of April 9th, the Emotet gang began utilizing what appears to be the stolen emails of their victims. It was noted back in October of 2018 that a new module was added that could steal the email content on a victim’s machine. Up until now, no evidence of real widespread use was seen. This marks a major evolution in the way Emotet works.

This ‘Broken’ File Hides Malware Designed to Break Its Targets

CISO Summary

Cofense IntelligenceTM has identified a phishing campaign with a malicious attachment containing a “broken” file that actually works, in all the wrong ways. Under certain conditions, the file weaponizes in the target environment after evading both automated and manual analysis.

The “break” is the lack of a file header, engineered to fool analysts into thinking the attachment is harmless, the work of threat actors too clumsy to be taken seriously. The headless file only appears when you open the attachment or use special programs in attempting to extract it.

The campaign tries to exploit a common problem: information overload. As they process and prioritize mountains of information, analysts and automated defenses sometimes ignore faulty files because they seem to be benign. In this campaign, the file downloads a script to fix the missing header and then run the full file, if the target environment permits it.

While multi-stage evasive techniques are the exception not the rule, they can lead to devastating results. To protect against campaigns like this, it’s smart to invest in solutions that leverage both human intuition and threat automation.

Full Details

Cofense Intelligence recently observed a campaign that delivered what appeared to be a broken executable—almost certain to evade detection as malicious—only to be fully weaponized once within  the target’s environment. By delivering an apparently broken executable, threat actors were able to disguise their intentions from several different kinds of automated and manual analyses. Cursory analysis showed that the executable was missing a proper “file header.” Because of the missing file header, it was more likely that an analyst would simply dismiss the threat actors as being incompetent and ignore the campaign. In reality, the campaign was designed so that the document would download a script to fix the “file header” and run the now complete executable, if the desired conditions within the hosting environment were met.

What’s in a Header

Essentially, a file header helps the operating system determine how to interpret the contents of the file. Header information can indicate several factors, such as whether a file is an archive or an executable. In the case of most Windows executables, the file starts with the characters MZ. This MZ header is almost always present, even when executables are packed, obfuscated, or embedded. The hexadecimal content of an executable, including the MZ header, can be seen in Figure 1.

Figure 1: Hexadecimal view of an MZ file header of an executable

If this header is not present, then the executable will simply fail to run. Some analysts as well as automated analysis systems and executable extraction programs will ignore any files without an appropriate header, under the assumption that they are broken. An example of the same executable from Figure 1, but with a missing MZ header, can be seen in Figure 2.

Figure 2: The same file as Figure 1 without an MZ header

The executable from Figure 1 no longer runs without the MZ header. Conversely, all that is needed to make the executable in Figure 2 run is the addition of “MZ” to the top of the binary.

What Happened Here

In the campaign observed by Cofense Intelligence, the malicious document drops an embedded object as a partial executable—the header of this file can be seen in Figure 2. Because this executable does not have an MZ header, it is only detected by 2/58* antivirus engines on VirusTotal. It also means that analysts who see the binary and attempt to run it as an executable will be unsuccessful and may assume that the binary is broken—and be technically correct in so doing. Once the partial executable has been dropped, the malicious document then makes use of CVE-2017-11882 to download and execute the contents of an .hta file. An example is shown in Figure 3.

Figure 3: Contents of downloaded .hta file

There are four steps of interest in this script. The first step creates a file “~F9.TMP” with the contents “MZ”:

Figure 4: First step in “creating” an executable

The second step adds the contents of the new file (“MZ”) to the start of a file named “~AFER125419.TMP”. The file “~AFER125419.TMP” is actually the name of the object embedded in the original executable:

Figure 5: Second step in creating an executable

After the “MZ” header is added, the new file is the same as the one shown in Figure 1. Although the file retains the .TMP extension it can still be run as an executable from the command line:

Figure 6: Third step in creating an executable

In the final step, the binary is copied to the Windows “Startup” folder, renaming it as an executable and ensuring that it will run on the next computer startup. This provides persistence for the malware on the targeted machine.

Figure 7: Fourth step in creating an executable

How It Helps Them and Hurts Us

The malicious document used in this instance was in fact detected by antivirus companies, largely due to its use of an equation editor exploit with minimal obfuscation and an embedded object. However, when dropped to disk the embedded object is only detected by 2/58* of the antivirus companies on VirusTotal. When the object is completed by adding the “MZ header,” this detection ratio jumps to 40/71*, demonstrating that the lack of an MZ header confuses automated systems and analysts alike. The fact that the binary can run as an executable only after being modified by a downloaded script provides several layers of distraction from the actual threat.

  • First, the computer must have access to the internet; this prevents the binary from running in some sandboxes and analysis environments which by default do not have internet access. It also ensures that any manual static analysis done on the binary will determine the binary to be “broken,” increasing the likelihood that it will be ignored.
  • In order for further analyses to take place, the script must still be available. If the script is unavailable due to the threat actor taking it down or any other reason, the binary never becomes an executable and is unlikely to be detected.
  • Finally, if the script is downloaded separately and run, it will create two 2-byte files and display an error message, further reinforcing its appearance as a poorly put together malware campaign.

Why It Matters

Information overload is a serious problem for any enterprise. To quickly process and prioritize information, both analysts and technical defenses will sometimes ignore “broken” files that do not run. If these files are recognized as a threat, analysts are often still forced to prioritize more obviously damaging malware instead of fixing a “broken” sample. Even if these steps are taken, the binary delivered in this campaign was only functional if a very specific set of criteria were met. This type of multi-stage execution designed to avoid detection is infrequent yet no less dangerous. To protect themselves from similar threats, organizations need to invest in both preventative programs and training as well as resources that use human experience in addition to automated malware analysis to uncover threats.

To stay ahead of emerging phishing and malware trends, sign up for free Cofense Threat Alerts.


Table 1: File IoCs

File Name MD5 Hash
9t3R1Ng5(.hta) c0266ac68a5de7c08fee0e7bd4b3b4aa
Enerson Energy_2018&2019_quotation.doc fa447b70e2550d66f0ebfa704a4c9552
~AFER125419.tmp 32c4c5186c0affa8c5f630253bbf5acc
~191AEF9.tmp 135dedc1e10a7d78f906cb485b328145


Table 2: Network IoCs**




All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.


* These statistics were from a sample analysis done on 2019-03-25.

** pastebin[.]com is not inherently malicious

Emotet Update: New C2 Communication Followed by New Infection Chain

CISO Summary

On March 15, CofenseTM Research reported that the Emotet botnet is changing the way it communicates, in a likely attempt to evade malware detection. Since then, Cofense IntelligenceTM has seen the same trend: Geodo-Emotet isn’t relying on cookies to make certain requests, instead performing HTTP POSTs to what seems to be the C2. Baking requests into cookies is a time-honored and easily detected pattern of  behavior. Switching this up makes it harder to see when the malware is calling home.

Moreover, Geodo-Emotet is now using a new infection chain, utilizing JavaScript files as droppers instead of macro-packed Office documents. These changes in behavior and delivery methods are the threat actors’ latest attempts to keep ahead of network defenders. They will very likely require security teams to adjust—once more.

Full Details

Cofense Intelligence has observed a change in the way that the Emotet botnet communicates, along with  the use of a new infection chain. In past versions, a compromised client would typically perform a GET request with data contained in the cookie value. As of approximately 11pm UTC on March 14th, this changed. The clients have begun to perform HTTP POST’s to what appear to be their C2’s. An educated guess: the primary driver behind this transition appears to be an attempt to bypass established detection methods. In tandem with this update, Geodo has begun experimenting with delivering its binaries with JavaScript files acting as droppers, and not via Office documents laden with macros as has been most common.

Historically, Geodo has passed data to its C2 using the Cookie field of the HTTP header. Information about the system, as well as identifiers, would be encrypted, wrapped in Base64 and added to the HTTP header before transport. This was a consistent and easily identifiable pattern of behavior, which led to near universal enterprise detection. Figure 1 shows an example of this exfiltration method.

Figure 1: An example of classic Geodo C2 comms using the Cookie field. Source: app.any.run

Despite being a valid and oft-used header field, there are several other tells – such as direct communication with an IP address for which no DNS resolution was performed. This, when combined with the cookie, is an easy way to identify a Geodo infection calling home.

The latest iteration of Geodo, however, has transitioned away from this legacy method to submitting data to its C2 via HTTP POST as a form. Figure 2 shows an example of this updated communication method.

Figure 2: The new method of C2 comms

Experimenting with JavaScript

Geodo operates various tiers of payload distribution by using payload-agnostic droppers and relying on the Windows file-type handlers to correctly execute what is downloaded. This means that payloads can be hot-swapped at any point during a campaign. This behavior was observed late in 2018 when a payload location, for a short period of time, swapped a Geodo executable for that of QakBot. By making the payload system agnostic, the actors behind Geodo can experiment with varying payloads without affecting the overall integrity of the infection chain. Despite the sophistication and robustness of the Geodo delivery infrastructure, the JavaScript payload observed by Cofense Intelligence was minimally obfuscated and immediately legible to an experienced eye. If one traces the execution, though, things begin to become a little bit murky. Figure 3 shows a snippet of the obfuscated dropper, verbatim.

Figure 3: The obfuscated payload showcasing cleartext strings

After deobfuscation, the flow of the code is somewhat easier to interpret. The code is broken out into 5 distinct functions, with two anonymous functions—one at the head and one at the tail—responsible for execution. Figure 4 shows the first two functions and an array.

Figure 4: Two functions responsible for shuffling an array and retrieving an element by index, respectively.

The shuffling function is likely there to slow down manual analysis of the file. It could also be used to defeat unsophisticated emulation techniques. The second function simply returns an item from an array by its index.

The next two functions, seen in figures 5 and 6, are responsible for downloading and response code verification, and looping through available URLs, respectively.

Figure 5: The code responsible for downloading payloads and verifying the response code

Figure 6: Looping through five URLs, and attempting to execute the retrieved payload

Although the dataset is entirely too small to accept as correlation, the use of 5 payload locations is in line with the standard Geodo modus operandi. During analysis, it was noticed that one of the payloads was not like the others, however. Figure 7 shows the rather interesting subject matter returned during analysis of the payload locations.

Figure 7: A blog page returned in lieu of a binary payload.

Figure 8 shows the code responsible for finding the path of, and writing files to, the %temp% directory.

Figure 8:  The dropper generates a pseudo-random filename as which to write the file

Figure 9 is the code responsible for kicking off the main functions of the script.

Figure 9: The code responsible for starting the download and execute operations. Comments added for clarity

With routine changes in behavior and delivery methods, Geodo’s operators consistently find ways to evolve how the botnet behaves—always attempting to stay ahead of the cat-and-mouse game they play with network defenders. The change in how form data is passed will almost certainly allow Geodo to overcome certain detection technologies, requiring immediate retooling. Identifying a highly dynamic family, such as Geodo, requires highly agile security infrastructure coupled with responsive threat intelligence.

To stay ahead of emerging phishing and malware trends, sign up for free Cofense Threat Alerts.


All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

This Phishing Campaign Spoofed a CDC Warning to Deliver the Latest GandCrab Ransomware

CISO Summary

Cofense IntelligenceTM reports that threat actors have spoofed a CDC email—this one warns of a flu epidemic—to deliver an updated variant of GandCrab ransomware. Besides competing for a new low in predatory cyber-crime, the phishing campaign follows the public release of a decryptor tool for infections of recent GandCrab versions, through version 5.1. The fake CDC email contained version 5.2, which renders the decryptor tool ineffective.

Though ransomware has dropped off over the past year, the authors of GandCrab are still pushing out frequent, powerful updates.  GandCrab is the last of the infamous “ransomware as a service” threats. The extent to which its creators make upgrades, parrying and thrusting with security researchers, shows it’s still a very real weapon for revenue-hungry criminals.

Full Details

Recent updates to GandCrab Ransomware demonstrate that its operators remain committed to the malware’s effectiveness and are prepared to make urgent changes to overcome disruptions. Shortly after a coordinated public release of a decryptor tool for infections of GandCrab versions 5.0.4 through 5.1, Cofense Intelligence observed GandCrab v5.2 campaigns that rendered the tool ineffective.  In a recent phishing email delivering GandCrab, a fabricated flu epidemic alert from the Center for Disease Control (CDC) was crafted to terrify recipients into opening an attached document. Far from receiving potentially life-saving instructions, the Office document was laden with macros, coded to download and execute a copy of—you guessed it— GandCrab v5.2.

Natural disasters, global geopolitical events, and pandemics are perfect narrative drivers for threat actors seemingly devoid of conscience, tact, or taste. Self-preservation is a human imperative, and such narratives that evoke fear and urgency are potentially more effective than those exploiting greed, empathy, or curiosity, other typical phishing narratives.

Coughs and Splutters

Despite leveraging a powerful concept, the execution of the observed campaign leaves much to be desired. Figure 1 shows the body of a typical message from this campaign.

Figure 1: a typical message observed during this campaign

Ostensibly, the message is well-structured, somewhat professional and believable. However, a closer read would note the grammatical errors and unusual statements. The content of the attached document continues this trend, with such preposterously low effort as compared to the effort put into the phishing email. Figure 2 shows the content of the document, displayed to the user while the macros are busy downloading and executing GandCrab.

Figure 2: the content of the document, typically deployed as a decoy.

In scenarios that leverage weaponized documents as the attack vector, threat actors often disseminate believable content to distract the user while whatever required background processes run.

Where’s Trik?

A noticeable deviation from the recent standard GandCrab protocol is the absence of an intermediate loader. Since Feb 2019, all phishing campaigns that ultimately served GandCrab did so via Trik, a spambot with pretentions of data-stealer. Certainly not a wholly unique occurrence, it does reverse a trend that had been forming.

Despite ransomware becoming less and less lucrative, the actors behind GandCrab continue to push out extremely frequent and pertinent updates. On February 19th 2019, Bitdefender released a decryption tool for GandCrab V5.1. Later that same day, it came to light v5.2 – a version for which no available decryption utility would work – had already been released, seemingly in direct response to the decryption utility.

GandCrab is the last great bastion of the ransomware-as-a-service world. Its frequent updates, active engagement with security researchers, and novel abuse of vulnerabilities and weaknesses makes it a very real, and potentially very devastating, threat. By appealing to fear and self-preservation, this campaign highlights to what lengths threat actors will go to generate revenue.

To stay ahead of emerging phishing and malware trends, sign up for free Cofense Threat Alerts.


Flu pandemic warning.doc        054607600b11e09fa74aa39c790357d6

perdaliche.exe                         b47b281a8d1f227d6a7f48f73192e7ed






All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.