Hey! I know I’ve never talked to you before – but can you send some money – QUICK!

Business Email Compromise (BEC), also known as CEO Fraud, is a type of phishing email designed to impersonate an executive. In a BEC campaign, the “executive” urgently instructs an employee to wire money, sometimes lots of money, to a bank account. The FBI reports that BEC scams hit businesses to the tune of $12.5 billion annually.

What makes BEC campaigns different?

In a BEC attack, the weapon of choice is simple words. Instead of tricking people into clicking a malicious link or attachment, a BEC attack tries to lure recipients into taking action. The threat actor will spend time researching the organization, identifying execs whose high-priority messages would make employees respond ASAP.

Though this type of threat is fairly new in the phishing landscape, it is very successful. Actors have been able to make off with millions of dollars, using networks of mules to move the money back to the mothership.

In recent months, there has been a shift in the type of currency requested—gift cards. They’re easy to obtain and, if requested in smaller amounts, can go unnoticed but still add up. Researchers have also been doing their work, hunting these criminal groups with much success. Last summer the FBI announced the arrest of 74 fraudsters, all related to BEC. When an organization realizes it’s been hit with a BEC attack, it can reach out to the FBI, which will work with financial institutions to block the transfer of funds.

What can you do? A few tips.

I remember a few years back when this threat started to surface. I couldn’t help but think back to my days in finance and IT compliance, with a focus on Sarbanes-Oxley, and think about the controls breakdown BEC triggers. Here are some ways to KEEP control.

First and foremost, train your employees to be on the lookout for these types of messages. Secondly, implement controls within your payment process to require a secondary signature for release of funds. When I worked in the treasury department for a retail chain, there were many days I would have to walk to the Controller’s or CFO’s office to get a REAL signature on a check greater than $50,000 or a request for a direct wire. Also, look to the gateway controls and implement DMARC /DKIM as discussed in our previous blog post.

There is another control that is starting to become a best practice—tagging external messages in the subject line or message body and letting your employees know the message originated outside the organization. This tag is helpful in spotting BEC messages. Many times, executives or high value targets are reading their messages on mobile devices. The mail client on these devices doesn’t display the fully qualified email address, making it difficult to assess the validity of the message sender.

A BEC sample:

The importance of tagging for viewing on a mobile device – mail client vs mobile:

If your organization becomes the victim of a BEC scam, report it quickly to help the authorities stop the funds from going through. Reporting also provides law enforcement with more information about the threat actor, which further helps to fight these crimes.

Learn more about phishing threats and protection in the Cofense State of Phishing Defense report.

 

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.

Cofense Announces Key Additions to Leadership Team

New Hires to Fuel Company Growth in All Aspects of Sales, Marketing, and Product Development

Leesburg, Va. – April 18, 2019 – Today Cofense™, the global leader in intelligent phishing defense solutions, announced the addition of four security leaders to their executive team. Kevin Fliess joins Cofense as Senior Vice President of Marketing; Keith Ibarguen, as Chief Product Officer; Marcus Conroy, as Vice President of Americas Sales; and David Janson has been promoted to Vice President of International Sales from his previous position as Vice President of European Sales. Following the strongest fourth quarter (2018) and first quarter (2019) in company history, these additions will contribute to Cofense’s leadership and culture as the company executes the next phase of its growth strategy and expansion.

Cofense To Host Fourth Annual Phishing Defense Summit and User Conference

Cofense Submerge features industry expert speakers, including a keynote by FireEye CEO,
and sessions focused on latest security threats and incident response trends

Leesburg, Va. – April 16, 2019 – Today Cofense™, the global leader in intelligent phishing defense solutions, announced that registration is open for the fourth annual Submerge phishing defense summit and user conference. The event, set to take place Sept. 23-24, 2019 in Orlando, Fl., will bring together industry experts with practitioners who are on the front lines to discuss the security threat landscape and share phishing defense strategies. Featured speakers include Kevin Mandia, CEO of FireEye as a keynote, along with Cofense’s Co-Founders, Rohyt Belani, CEO, and Aaron Higbee, CTO.

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.

Appendix

Subject Lines

特別請求書
三月發票
確認して承認してください。
請查看和 批准。 謝謝。
請求書

 Attachment Names

878345912 99590954.doc
953830038_784779.doc
125469441531_79909831.doc
1379110773-877347.doc
1994740003_23358762.doc
24239118_62193073.doc
31021154 71136771.doc
35404060839-51945433.doc
517044779-87996292.doc
64123575263 958618.doc
72239600 553010.doc
75446103-4089070.doc
7690905434_609835.doc
823522415 83838965.doc
86726152984 4077671.doc
97016848095 4035273.doc
00209430800-791240.doc
01341161_9221765.doc
04546449854 46414589.doc
10433741_1976807.doc
1105119866-989027.doc
12129058435 35307309.doc
1375335111_2342554.doc
13826610090_89267548.doc
18009110 429772.doc
18965548-228698.doc
19529643 07207376.doc
20080657431-132300.doc
2094899952-633559.doc
22789621095 667097.doc
28025325_9781072.doc
31555902_50732534.doc
329298339962-7428084.doc
3405249239-0494889.doc
3696903556_82472490.doc
369955609499_6558583.doc
39032869312-95552314.doc
424078934718-386196.doc
4302447799_071604.doc
44498431-49581333.doc
445993000_8728570.doc
459894237 3920280.doc
48513288 3409281.doc
51036407549_224907.doc
514855331 4861472.doc
5256872379_032431.doc
52981800501_34239839.doc
59622012497-3273399.doc
60475231104 37366668.doc
6325401702 834277.doc

Attachment Hashes

27605401f9d2948e6a86c98457485dd7
4694bfed342c109a9bc54319a93a40bf
51177c2465eec69dc1a7c3cecaafd541
0fedcdc0d340a47555676f25ee12e8a2
691b1890521138b049edbf0e6cb09e7b
6f96482f2d2a78b02686efbcfae8138b
48f66f4b02fbe277282bac5467aba344
9b3aa6c52c788d356ab032d342270eed
1090395626b52579023a1cfd87a48dd9
3ad0040b48e62e9ca22d52a68de0966e
4dc61c605083d3fd32d69529ea14d0db
5c5d24b49c33b147a0344229a127b1cd
249dd3be9d101354015460ead19f0fa3
929116540242d88367af42f66e1a0336
ccfec8b2f804b553deb2193772e03785

Payload URLS

hxxp://garammatka[.]com/cgi-bin/o569U/
hxxp://rinconadarolandovera[.]com/calendar/5n5WY/
hxxp://gamvrellis[.]com/MEDIA/heuMx/
hxxp://hadrianjonathan[.]com/floorplans/vOec/
hxxp://warwickvalleyliving[.]com/images/wmGN/

Payload Hashes

69a5838744d6aa7b8f1d08b6e36d6844

C2s

187.188.166.192:80
88.215.2.29:80
187.137.162.145:443
65.49.60.163:443
45.33.35.103:8080
43.229.62.186:8080
165.227.213.173:8080
210.2.86.72:8080
192.155.90.90:7080
88.97.26.73:50000
190.117.206.153:443
185.86.148.222:8080
187.189.210.143:80
67.241.81.253:8443
200.114.142.40:8080
107.159.94.183:8080
190.147.116.32:21
138.68.139.199:443
219.94.254.93:8080
77.44.16.54:465
200.90.201.77:80
71.11.157.249:80
192.163.199.254:8080
144.76.117.247:8080
69.163.33.82:8080
109.73.52.242:8080
5.9.128.163:8080
189.225.119.52:990
62.75.143.100:7080
109.104.79.48:8080
181.29.186.65:80
200.28.131.215:443
190.192.113.159:21
89.211.193.18:80
189.205.185.71:465
181.29.101.13:80
176.58.93.123:8080
82.226.163.9:80
196.6.112.70:443
92.48.118.27:8080
72.47.248.48:8080
200.107.105.16:465
23.254.203.51:8080
154.120.228.126:8080
213.172.88.13:80
51.255.50.164:8080
201.217.108.155:21
197.248.67.226:8080
139.59.19.157:80
66.209.69.165:443
91.205.215.57:7080
99.243.127.236:80
136.49.87.106:80
186.139.160.193:8080

Filename Regex

\d{6,12}[-_\s]\d{6,12}\.doc

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.

When You Unsubscribe to these Emails, You ‘Subscribe’ to the Loda RAT

CISO Summary

It’s critical that anti-phishing programs reflect the latest threats. Cofense IntelligenceTM has recently observed a phishing campaign that illustrates why. It entices users to download a malicious document from a seemingly legitimate source, an insurance company whose roots go back to 1896. Through a complex chain of abuse, including the exploitation of a legit subdomain hosted by Microsoft, this threat is capable of tricking users unfamiliar with wrinkles like multiple links to the same source and malicious “unsubscribe” links. If successful, the attack activates the Loda Remote Access Trojan, underscoring the importance of educating users to stop phishing emails.

Full Details

Cofense Intelligence recently observed a campaign that used convincing emails to entice recipients into downloading a malicious document from a seemingly legitimate source. These attention-grabbing emails contained multiple links to the same source, which was hosted on a subdomain of the legitimate Microsoft-owned domain azurewebsites[.]net. This source URL downloaded a Microsoft Word document that abused an object relationship to then download and open an RTF document. The RTF document abused CVE-2017-11882 to download the multi-functional Loda Remote Access Trojan. By taking advantage of users’ assumption that unsubscribe links are legitimate, along with their trust in verification, threat actors were able to craft a campaign capable of fooling even users with basic security awareness training.

What a Deal…

The emails used in this campaign have several attributes that give the appearance of legitimacy. The first email, the top of which is shown in Figure 1, impersonates Fidelity Life and claims to offer a good deal on life insurance.

 Figure 1: Body of the email spoofing Fidelity

In this email, the only actual text present is the unsubscribe information at the bottom of the email shown in Figure 2.

Figure 2: Unsubscribe section of the email spoofing Fidelity

The top three paragraphs in Figure 2 are in fact an image, while the bottom paragraph (with a pointer hovering over it) is searchable text that appears to have been added by the threat actor. All of the image shown in Figure 1 is a clickable link leading to the same URL as the unsubscribe link, hxxps://onlinefinances[.]azurewebsites[.]net/mowgli/fidelity_insurance[.]docx.

Verification Passed

If users who have been trained to be suspicious of links were to first visit the website by typing the URL into an internet browser and looking at the webpage information, they would see the information shown in Figure 3.

If users are particularly security conscious, they might even look up the domain on a website with tools that check for legitimacy. However, this would likely give them the same information as what is shown in Figure 3, because most tools will check the root domain, in this case azurewebsites[.]net, which is a completely legitimate domain owned by Microsoft. The only easily recognized indicator of malicious content is the prompt when a file is downloaded from an unsubscribe link.

Double Interest

The second email, shown in Figure 4, pretends to be a relatively benign “news” email from the company Livenlonpro about a new Amazon policy.

Figure 4: Body of the email spoofing Livenlonpro

In this case all links and images download a file from hxxps://onlinefinances[.]azurewebsites[.]net/mowgli/Amazon_Cancelled_order[.]docx. With this approach, any user that attempts to unsubscribe from what appears to be a spam email will instead download malware. Although differently named, the downloaded file is the same for both emails.

Actual Goal

Once the file is downloaded and opened, it attempts to use an object relationship to download a document with CVE-2017-11882 which, in turn, downloads the multi-functional Loda malware. Loda is capable of acting stealthily to download additional malware or provide the threat actor with full remote access to the victim’s computer.

Direct Importance

Attacks such as this demonstrate threat actors ability to adapt to changing circumstances and training methods. Organizations often focus employee training on the philosophy “don’t click suspicious links or open attachments.” While usually effective, this method can fall prey to creative threat actors. Using a training method that encourages employees to think critically can help protect organizations by avoiding situations where employees make assumptions about the nature of a link and act accordingly.

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.

DMARC Is NOT a Fail-Safe Defense against Phishing Attacks

DMARC, or Domain-based Authentication Reporting & Conformance, is an email authentication, policy and reporting protocol. It was conceived to prevent impersonation-based phishing attacks, but it doesn’t protect you 100%. Let’s examine why.

What DMARC Can Do

DMARC builds on the existing and widely deployed SPF and DKIM protocols. All mechanisms to protect the email infrastructure we so heavily rely upon should be gratefully received, but as with everything the benefits and limitations should be fully understood. It is this understanding that allows us to optimize our defenses against the perpetual menace of phishing attacks.

DMARC has most promise to help organisations defend against Business Email Compromise (BEC) type attacks, as successful impersonation can be an imperative for success. As a result, DMARC should be evaluated as a mitigating control for these types of attacks, protecting both outbound as well as inbound email.

DMARC aims to get email senders and receivers working together in a standardized, coordinated way to determine whether a given email is legitimately from the sender—and the actions to be taken if it isn’t.

Therefore, if alice@sender.com sends an email to bob@receiver.com, appropriate DMARC policies can help remove the guesswork and answer the question “Has this email really been sent by alice@sender.com?”. By protecting their messages with SPF and DKIM, and using DMARC, sender.com can tell receiver.com what to do if these authentication methods fail, for example, reject the message.

What DMARC CAN’T Do

It all sounds good, but what if the email comes from alice@sendr.com, or alice@sencler.com—does DMARC help then? Unfortunately, not. What about if the message is sent by alice@sendr.com, but the From: field has been modified to look like it comes from alice@sender.com—does DMARC keep Bob safe? No again.

While display-name abuse and adjacent-domain abuse are well recognized, there’s another growing phishing tactic that neutralizes DMARC completely. DMARC has capabilities to validate the sender’s authenticity, but it has no capability to validate the authenticity, of the email content.

Recently, the Cofense™ Phishing Defense Center has seen a significant rise in Man-in-the-Inbox style attacks. These attacks typically occur when user credentials have been compromised and are used to gain access to the compromised user’s mailbox and send malicious emails. These emails might be sent internally (no DMARC there…) or to a trusted third-party (DMARC might be configured, but as the message is coming from a legitimate user, SPF and DKIM check out, and the message is delivered…). The recent PDC zombie phish blog post discusses one style of Man-In-The-Inbox attack in more detail.

Given this, it’s important that emails teams don’t expect more from DMARC. It’s equally important that security teams ensure that end users are empowered to be “human sensors,” to identify and report emails that look suspicious. Users need to be alert to visual clues, such as adjacent sender domains, peculiar content, or unusual or unexpected emails, even if the emails come from internal senders or trusted third-parties.

We all need to remember that real phish are the real problem. This means knowing what real phish look like as they evolve day to day—and not expecting DMARC to do more than it really can.

Want to learn more about the DMARC protocol? Take a look at https://dmarc.org for the juicy details.

 

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 ‘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**

URLs
hxxp://37[.]49[.]225[.]195/hook/logs/fre[.]php
hxxps://pastebin[.]com/raw/9t3R1Ng5

 

 

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

Uncomfortable Truth #5 about Phishing Defense

Last in a 5-part series. 

In this blog series we’ve explored the Uncomfortable Truths about phishing defense that relate to the problem of over-relying on technology to keep us safe. We’ve also seen how empowered users can give Security Operations teams desperately needed visibility into phishing threats. This leads us to our fifth and final Uncomfortable Truth:  

Most organizations are unable to effectively respond to phishing attacks.  

Before you get offended and say “Hey, that doesn’t apply to me, our SOC is awesome,” stick with me on this. The reasons for ineffective phishing incident response are many and varied, but in my experience, tend to fall into one of two buckets: 

  1. Not enough time 
  2. Not enough experience/understanding

Not enough time  

This is already well understood. SOC teams are perpetually spinning multiple plates, trying to make sense of the stream of data they are presented with from an abundance of tools. This problem can be compounded when users are empowered and enabled to report suspicious emails. The CofenseTM Phishing Defense Center (PDC) sees differing reporting volumes across the customers who use us for phishing email analysis. While reported mail volumes differ, they tend to fall within common low and high watermarks – equivalent to around 10% and 35% of users reporting at least one email per month.  

For every 1,000 users, that’s the SOC having to consume and analyze between 100 and 350 reported emails per month. The PDC also observes that 1 in 7 of the emails reported to us contain malicious content. Therefore, 6 out of 7 are false positives, or noise. The largely unstructured nature of these reported emails and the sheer volume of noise can make analysis a thankless task that gets de-focused in favour of other more immediate priorities.  

Not enough experience/understanding 

Effective phishing email analysis is much harder than many people imagine. One of the biggest issues that organizations face is the risk of false-negative results, post-analysis. These false negatives occur when a reported phishing email is considered to be benign, and is returned to the reporting user with a message that says, “Thanks for reporting, this email was found to be safe.” The subsequent click delivers a missed payload and compromise occurs.  

To remain razor sharp in your analysis skills, you have to maintain an understanding of the constantly evolving threat landscape and threat actor TTPs. All too often, I see organizations relying on an already overburdened service desk to perform initial, or complete, analysis of reported phishing emails. Without adequate skills, they rely on tools such as VirusTotal to tell them whether something is bad or not. However, as useful as these tools are for information and context, they should never be considered a source of absolute truth.   

Effective phishing analysis and response 

Simply sending a file or URL to a sandbox or checking online threat analysis tools and databases is not good enough. SOC teams and threat analysts must be able to consume reports of suspicious emails from users and turn them into actionable intelligence quickly.  

This means they must be able to prioritize what is being reported to cut through the noise of false-positives, such as legitimate marketing or internal emails, and automatically be able to understand risk based on: the attributes of the email content and any attachments; the status of the user reporting the email (are they high-risk employees with access to sensitive information or processes); the reputation of the user (have they demonstrated an ability to identify and report suspicious emails in the past – essential to help prioritize zero-day threats); and use information from third-party threat analysis tools to help build a fuller picture  

Once a threat is analyzed and understood, SOC teams need to be able to quickly hunt for the threat within all user mailboxes and quarantine it when found. In addition, they must be able to communicate IOCs to other teams, such as those responsible for proxies, mail gateways, and endpoint security tools, to take further defensive or mitigating actions. Finally, they must close the loop by providing timely feedback to users to encourage further reporting behavior, thus supporting awareness activities. 

The Cofense Phishing Defense Center can help.  

For organizations who still struggle to devote the time to phishing email analysis, but who recognize the need to regain visibility of threats that bypass perimeter controls, the Cofense Phishing Defense Center can help. Operating 24×7, the PDC is staffed by experienced phishing threat analysts to handle all elements of analysis of reported emails.   

Supported by Cofense Research and Intelligence teams, the PDC is able to utilize as needed an array of proprietary, open source, and commercial threat analysis tools. Benefitting from a global perspective of threats across all PDC customers, our analysts are able to maintain the most up to date understanding of evolving phishing threat actor tactics, along with techniques for capturing all IOCs, even when automated approaches fail.  

Once threats have been identified, actionable intelligence is passed to customer teams. By utilizing the PDC, organizations can focus their resource-constrained SOC teams on mitigation and proactive protection, versus phishing email analysis. Learn more about the Cofense Phishing Defense Center here. 

 

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 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.