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.

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.

IoCs

Flu pandemic warning.doc        054607600b11e09fa74aa39c790357d6

perdaliche.exe                         b47b281a8d1f227d6a7f48f73192e7ed

hxxp://gandcrabmfe6mnef[.]onion/

hxxps://www[.]kakaocorp[.]link/data/images/kadeheme[.]jpg

hxxp://www[.]kakaocorp[.]link/news/image/kazuzu[.]bmp

hxxp://210[.]16[.]102[.]43/perdaliche[.]exe

 

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.

 

Uncomfortable Truth #4 about Phishing Defense

Part 4 of a 5-part series.  

I’m not going to beat around the bush here. Uncomfortable Truth #4 is quite simple: 

Users are NOT the problem. 

There. I said it. If this statement seems at odds with your current thinking, don’t close this browser window just yet. Stick with me, and the effectiveness of your phishing defense programs could be changed for the better. 

Let’s illustrate with a story from Malcolm Gladwell.  

In his book ‘Blink’, Malcolm Gladwell tells of the Getty Museum in New York buying an ancient Greek Kouros statue—a tale of man triumphing over machine, as it turned out 

To cut a long story short, the museum was offered what they considered to be one of the finest examples of a Greek Kouros statue the world had seen. They were understandably excited, but cautious – the asking price was $10m – a lot of money now, but a more considerable amount in 1982.   

The statue was borrowed, and tests were organised to verify authenticity. The stone was analysed, providing its age and an assertion to where it came from. Scientists confirmed that the calcification on the stone was merely the result of being in the ground for hundreds of years. The accompanying paperwork checked out, and the museum agreed to the purchase.  

But despite the museum’s checks, upon viewing the statue, many art historians and specialists had the same reaction. An ‘intuitive repulsion’ in the first few seconds of seeing it that led them to react –  “it’s a fake. None of the doubters could quite put their finger on what specifically it was about the statue that made them react so quickly the way they did, other than it just didn’t look right.  

What does a story about a Greek statue have to do with phishing defense?  

The museum relied on technology and science to confirm authenticity. However, subsequent analysis based on human intuition found that (1) the calcification of the stone could be replicated with potato mould, and (2) addresses on the supplied paperwork just didn’t exist when the documents were claimed to have been created. Despite all the available technology and science, gut reaction yielded a better conclusion 

Harnessing this intuition can be transformational to phishing defense. Rather than try to cut our users out of the loop and rely upon technology to keep us safe from phishing threats, we must exploit this natural intuition or gut feel. We have to recruit our users into a network of human sensors to provide visibility to phishing attacks that have made it to the inbox. Afterall, if the user doesn’t tell us, nothing will.  

Your users can and should help detect real attacks. 

Phishing simulation is an essential element of an overall phishing defense strategy, but it should never be used to ‘test’ our users – phish testing is the antithesis of phishing defense. Phishing simulation must be used to keep the threat of phishing front and center in users’ minds and keep them conditioned to constantly evolving threat actor tactics and techniques – particularly those specific tactics and techniques that we see being used against our organisations.  

The primary outcome of phishing simulation should be ensuring that users understand the role they play in protecting the organisation by providing visibility of phishing attacks. Like most users, I occasionally receive emails that don’t look right. I could just delete them. However, that action protects me as an individual, but it doesn’t protect the organisation as a whole. To do this, I must sound the alarm, and help our security teams get visibility of an attack, so they can take the actions to disrupt it.  

I can do this because I’ve been enabled to recognize something as suspicious, and it’s been made easy for me to report it. A single click of a button within the email client ensures that there is no process to forget, and if I really do catch one, I get timely feedback thanking me. I pat myself on the back, and am motivated and more inclined to report in the future as I know I’m making a difference. 

Next and last in this series, we’ll look at Uncomfortable Truth #5 – Most organizations are unable to effectively respond to phishing attacks. Until then, you can learn more about our holistic phishing detection and response (PDR) solution 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.

Uncomfortable Truth #3 about Phishing Defense

Part 3 of a 5-part series.

In part 1 and part 2, we discussed the Uncomfortable Truths that no matter how good your perimeter controls, malicious emails still reach the inbox, and that security teams cannot defend against attacks they cannot see. While some still hold next-gen technologies in almost exalted status, many organizations are beginning to accept that phishing threats still reach user inboxes and that these users will be tempted to click.

To address this risk, significant investments are made in awareness activities, including phishing simulation. Commonly, the primary goal or success metric of these activities is a reduction in susceptibility, or click rate. However, before we commit to a low click-rate as an indicator of improved security posture, and thus an ability to better defend against phishing threats, let’s consider…

Uncomfortable Truth #3 – The best security awareness program in the world will NEVER deliver a zero click rate.

As the pioneers of phishing simulation used to educate employees, we at Cofense™ know quite a bit about it. Effective phishing simulation (i.e. a phishing simulation program that actually conditions the desired behavior in a REAL attack situation) is more than just sending a few spoofed emails to users to see who clicks and who doesn’t.

While lower overall susceptibility, or click rate, is a desirable benefit, it should not be the primary objective. When reviewing data based on >2000 enterprise customers using the Cofense PhishMeTM phishing simulation platform over the last few years, we’ve seen average susceptibility flatten at about 11.5%. Here’s how the math works out:

Imagine a phishing attack that targets 1000 employees in the same organization (attacks like this are common). With an average susceptibility rate of 11.5%, this attack could easily net the threat actor 115 sets of credentials, or 115 endpoints compromised with malware. Even an industry-leading susceptibility rate of 3% in simulations results in a compromise of 30 individuals – more than enough to cause significant disruption and damage, such as Man in The Inbox attacks directed at business partners and customers. And if security teams are not aware of the attack, how can they stop it?

When investing time, effort and resources in phishing simulation activities, it’s critical to remember that REAL phish are the REAL problem. While the CISO, security awareness, and security operations stakeholders might have differing day to day responsibilities, they all have the overarching responsibility to improve organizational security posture. By breaking down silos and working more closely together, they can challenge current thinking and ask, “How can we ensure our phishing simulation activities are truly representative of the actual threats we receive?”

When you approach your program this way, you can encourage the right user behavior. Click rate alone becomes less important, and you begin to wrestle back an element of control in how users respond to real attacks.

In part 4, we’ll take a look at perhaps the most contentious uncomfortable truth of all: Users are NOT the Problem. We will attempt to bust the myth that the problem exists between the keyboard and chair.

Until then, learn more about anti-phishing trends in our State of Phishing Defense 2018 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.

Flash Bulletin: Emotet Epoch 1 Changes its C2 Communication

We are currently noticing a change in the way that the Emotet botnet, specifically the epoch 1 variant, is communicating with the C2.  In past versions, the client would typically perform a GET request with data contained in the cookie value. As of approximately 11pm UTC on March 14, this changed. The clients have begun to perform HTTP POSTs to what appear to be their C2s.  The URI’s contacted contain variable words in the paths.  We are seeing form data passed with a name variable and data.  This change will break researchers as well as certain detection technologies while they scurry to retool.  We will continue to track this change and analyze what this means. Further details to come.

IOC’s

Emotet E1 Client hash: e0f04e2fbf3beed2dc836567006890f6f0442db78248cc2fd049437547be462e

Seen POST Uri’s

178[.]78[.]64[.]80:8443/usbccid/
82[.]78[.]228[.]57:443/attrib/
82[.]78[.]228[.]57:443/taskbar/
139[.]59[.]19[.]157/acquire/results/
139[.]59[.]19[.]157/add/between/taskbar/merge/
139[.]59[.]19[.]157/attrib/img/report/
139[.]59[.]19[.]157/badge/sess/devices/enabled/
139[.]59[.]19[.]157/chunk/
139[.]59[.]19[.]157/codec/
139[.]59[.]19[.]157/devices/
139[.]59[.]19[.]157/free/add/report/merge/
139[.]59[.]19[.]157/glitch/
139[.]59[.]19[.]157/health/merge/
139[.]59[.]19[.]157/health/tlb/splash/
139[.]59[.]19[.]157/iab/report/between/merge/
139[.]59[.]19[.]157/jit/entries/enabled/
139[.]59[.]19[.]157/loadan/
139[.]59[.]19[.]157/loadan/child/odbc/
139[.]59[.]19[.]157/pdf/entries/entries/merge/
139[.]59[.]19[.]157/pnp/
139[.]59[.]19[.]157/prep/
139[.]59[.]19[.]157/prov/taskbar/entries/
139[.]59[.]19[.]157/prov/usbccid/
139[.]59[.]19[.]157/report/taskbar/
139[.]59[.]19[.]157/report/window/arizona/merge/
139[.]59[.]19[.]157/ringin/bml/health/
139[.]59[.]19[.]157/schema/iab/
139[.]59[.]19[.]157/scripts/usbccid/
139[.]59[.]19[.]157/sess/jit/usbccid/merge/
139[.]59[.]19[.]157/srvc/glitch/
139[.]59[.]19[.]157/srvc/pdf/
139[.]59[.]19[.]157/stubs/between/entries/merge/
139[.]59[.]19[.]157/teapot/arizona/splash/enabled/
139[.]59[.]19[.]157/tlb/srvc/schema/enabled/
139[.]59[.]19[.]157/usbccid/entries/site/
139[.]59[.]19[.]157/vermont/mult/
139[.]59[.]19[.]157/walk/between/
139[.]59[.]19[.]157/walk/enable/iplk/
139[.]59[.]19[.]157/walk/taskbar/
139[.]59[.]19[.]157/window/between/enabled/
152[.]171[.]65[.]137:8090/psec/rtm/vermont/enabled/
152[.]171[.]65[.]137:8090/splash/arizona/
165[.]227[.]213[.]173:8080/attrib/schema/vermont/enabled/
165[.]227[.]213[.]173:8080/ban/iab/
165[.]227[.]213[.]173:8080/ban/nsip/taskbar/
165[.]227[.]213[.]173:8080/bml/mult/prov/enabled/
165[.]227[.]213[.]173:8080/child/
165[.]227[.]213[.]173:8080/cookies/json/
165[.]227[.]213[.]173:8080/enabled/
165[.]227[.]213[.]173:8080/entries/srvc/
165[.]227[.]213[.]173:8080/loadan/loadan/
165[.]227[.]213[.]173:8080/prep/loadan/symbols/
165[.]227[.]213[.]173:8080/schema/iab/
165[.]227[.]213[.]173:8080/sess/
165[.]227[.]213[.]173:8080/site/bml/forced/merge/
165[.]227[.]213[.]173:8080/splash/enable/prov/enabled/
165[.]227[.]213[.]173:8080/sym/tpt/nsip/enabled/
165[.]227[.]213[.]173:8080/symbols/badge/
165[.]227[.]213[.]173:8080/tlb/nsip/
165[.]227[.]213[.]173:8080/usbccid/prov/sess/
173[.]248[.]147[.]186/attrib/usbccid/entries/
173[.]248[.]147[.]186/iab/odbc/forced/
173[.]248[.]147[.]186/mult/tlb/
173[.]248[.]147[.]186/mult/window/enabled/
173[.]248[.]147[.]186/pnp/taskbar/splash/
173[.]248[.]147[.]186/publish/
173[.]248[.]147[.]186/schema/mult/arizona/
173[.]248[.]147[.]186/teapot/acquire/
173[.]248[.]147[.]186/teapot/usbccid/
178[.]78[.]64[.]80:8443/acquire/entries/
178[.]78[.]64[.]80:8443/acquire/merge/forced/enabled/
178[.]78[.]64[.]80:8443/attrib/usbccid/
178[.]78[.]64[.]80:8443/devices/between/devices/enabled/
178[.]78[.]64[.]80:8443/devices/free/report/merge/
178[.]78[.]64[.]80:8443/devices/free/schema/enabled/
178[.]78[.]64[.]80:8443/json/sess/attrib/
178[.]78[.]64[.]80:8443/raster/
178[.]78[.]64[.]80:8443/tpt/
181[.]16[.]4[.]180/attrib/entries/report/
181[.]16[.]4[.]180/attrib/scripts/
181[.]16[.]4[.]180/between/scripts/child/enabled/
181[.]16[.]4[.]180/cookies/symbols/arizona/merge/
181[.]16[.]4[.]180/dma/
181[.]16[.]4[.]180/loadan/raster/
181[.]16[.]4[.]180/publish/child/tlb/merge/
181[.]16[.]4[.]180/raster/
181[.]16[.]4[.]180/window/tlb/symbols/enabled/
181[.]56[.]165[.]97:53/balloon/enabled/mult/
181[.]56[.]165[.]97:53/child/merge/chunk/enabled/
181[.]56[.]165[.]97:53/iplk/teapot/forced/
181[.]56[.]165[.]97:53/pdf/json/tlb/
181[.]61[.]221[.]146/chunk/iplk/
181[.]61[.]221[.]146/forced/attrib/enable/enabled/
186[.]137[.]133[.]132:8080/ringin/entries/
186[.]138[.]205[.]189/child/devices/add/enabled/
186[.]138[.]205[.]189/stubs/taskbar/
186[.]3[.]188[.]74/arizona/
186[.]3[.]188[.]74/cookies/scripts/arizona/
186[.]3[.]188[.]74/entries/
186[.]3[.]188[.]74/json/health/odbc/
186[.]3[.]188[.]74/prep/window/
186[.]3[.]188[.]74/results/attrib/
186[.]3[.]188[.]74/schema/badge/
186[.]3[.]188[.]74/srvc/report/forced/enabled/
186[.]3[.]188[.]74/stubs/scripts/vermont/enabled/
189[.]208[.]239[.]98:443/enable/raster/prep/
189[.]208[.]239[.]98:443/pdf/cookies/
189[.]208[.]239[.]98:443/scripts/entries/mult/enabled/
190[.]117[.]206[.]153:443/attrib/loadan/
190[.]117[.]206[.]153:443/badge/ban/vermont/
190[.]117[.]206[.]153:443/devices/
190[.]117[.]206[.]153:443/iplk/pnp/
190[.]117[.]206[.]153:443/merge/window/
190[.]117[.]206[.]153:443/publish/
190[.]117[.]206[.]153:443/ringin/odbc/
190[.]117[.]206[.]153:443/sess/balloon/glitch/
190[.]117[.]206[.]153:443/symbols/
190[.]146[.]86[.]180:443/child/odbc/forced/enabled/
190[.]146[.]86[.]180:443/enabled/devices/enabled/merge/
190[.]146[.]86[.]180:443/guids/between/devices/
190[.]146[.]86[.]180:443/guids/site/splash/enabled/
190[.]146[.]86[.]180:443/merge/balloon/
190[.]146[.]86[.]180:443/mult/badge/glitch/merge/
190[.]146[.]86[.]180:443/pnp/
190[.]146[.]86[.]180:443/raster/badge/odbc/enabled/
190[.]146[.]86[.]180:443/srvc/json/
190[.]15[.]198[.]47/arizona/pnp/
190[.]15[.]198[.]47/balloon/cookies/devices/enabled/
190[.]15[.]198[.]47/cab/sess/
190[.]15[.]198[.]47/guids/acquire/splash/
190[.]15[.]198[.]47/img/balloon/
190[.]15[.]198[.]47/schema/report/vermont/enabled/
190[.]15[.]198[.]47/scripts/
190[.]15[.]198[.]47/site/enabled/
190[.]15[.]198[.]47/vermont/
192[.]155[.]90[.]90:7080/acquire/
192[.]155[.]90[.]90:7080/free/prov/chunk/
192[.]155[.]90[.]90:7080/prep/stubs/
192[.]163[.]199[.]254:8080/add/enable/symbols/enabled/
192[.]163[.]199[.]254:8080/balloon/balloon/
192[.]163[.]199[.]254:8080/report/
192[.]163[.]199[.]254:8080/report/acquire/schema/enabled/
192[.]163[.]199[.]254:8080/rtm/srvc/
192[.]163[.]199[.]254:8080/scripts/health/results/
208[.]180[.]246[.]147/add/forced/mult/enabled/
208[.]180[.]246[.]147/tlb/window/
208[.]180[.]246[.]147/usbccid/results/chunk/enabled/
23[.]254[.]203[.]51:8080/acquire/scripts/iab/enabled/
23[.]254[.]203[.]51:8080/arizona/ban/symbols/
23[.]254[.]203[.]51:8080/forced/merge/enable/enabled/
23[.]254[.]203[.]51:8080/json/
5[.]9[.]128[.]163:8080/devices/tpt/
5[.]9[.]128[.]163:8080/enable/sess/tlb/merge/
5[.]9[.]128[.]163:8080/odbc/odbc/enable/enabled/
50[.]246[.]45[.]249:7080/cookies/rtm/
50[.]246[.]45[.]249:7080/dma/cookies/
50[.]246[.]45[.]249:7080/loadan/codec/
51[.]255[.]50[.]164:8080/arizona/srvc/
51[.]255[.]50[.]164:8080/attrib/schema/results/enabled/
51[.]255[.]50[.]164:8080/ban/symbols/acquire/merge/
51[.]255[.]50[.]164:8080/enabled/
51[.]255[.]50[.]164:8080/iab/prep/scripts/
51[.]255[.]50[.]164:8080/iplk/
51[.]255[.]50[.]164:8080/loadan/
51[.]255[.]50[.]164:8080/pdf/psec/schema/
51[.]255[.]50[.]164:8080/publish/
51[.]255[.]50[.]164:8080/site/xian/
51[.]255[.]50[.]164:8080/splash/symbols/acquire/merge/
51[.]255[.]50[.]164:8080/srvc/publish/forced/
51[.]255[.]50[.]164:8080/taskbar/scripts/json/
51[.]255[.]50[.]164:8080/walk/tlb/raster/merge/
51[.]255[.]50[.]164:8080/window/
66[.]209[.]69[.]165:443/between/symbols/
66[.]209[.]69[.]165:443/enabled/walk/
66[.]209[.]69[.]165:443/prep/cone/enable/enabled/
69[.]163[.]33[.]82:8080/add/psec/
69[.]163[.]33[.]82:8080/cookies/splash/chunk/enabled/
69[.]163[.]33[.]82:8080/loadan/badge/publish/enabled/
69[.]163[.]33[.]82:8080/sess/vermont/
69[.]163[.]33[.]82:8080/srvc/
70[.]28[.]22[.]105:8090/arizona/
70[.]28[.]22[.]105:8090/report/tpt/chunk/
70[.]28[.]22[.]105:8090/stubs/balloon/enable/
72[.]47[.]248[.]48:8080/balloon/report/iab/
72[.]47[.]248[.]48:8080/img/raster/arizona/
72[.]47[.]248[.]48:8080/results/merge/symbols/
72[.]47[.]248[.]48:8080/vermont/results/
82[.]78[.]228[.]57:443/acquire/
82[.]78[.]228[.]57:443/arizona/nsip/balloon/
82[.]78[.]228[.]57:443/badge/cookies/teapot/enabled/
82[.]78[.]228[.]57:443/balloon/
82[.]78[.]228[.]57:443/ban/
82[.]78[.]228[.]57:443/between/
82[.]78[.]228[.]57:443/child/usbccid/loadan/
82[.]78[.]228[.]57:443/chunk/health/forced/
82[.]78[.]228[.]57:443/codec/
82[.]78[.]228[.]57:443/devices/
82[.]78[.]228[.]57:443/devices/vermont/
82[.]78[.]228[.]57:443/dma/ringin/enabled/
82[.]78[.]228[.]57:443/enable/entries/
82[.]78[.]228[.]57:443/enabled/child/json/
82[.]78[.]228[.]57:443/glitch/
82[.]78[.]228[.]57:443/iab/scripts/add/enabled/
82[.]78[.]228[.]57:443/mult/publish/sym/
82[.]78[.]228[.]57:443/pdf/arizona/balloon/
82[.]78[.]228[.]57:443/pdf/site/
82[.]78[.]228[.]57:443/prov/enable/splash/enabled/
82[.]78[.]228[.]57:443/schema/publish/vermont/
82[.]78[.]228[.]57:443/site/entries/
82[.]78[.]228[.]57:443/site/glitch/
82[.]78[.]228[.]57:443/stubs/ban/ban/merge/
82[.]78[.]228[.]57:443/taskbar/entries/
82[.]78[.]228[.]57:443/tlb/
82[.]78[.]228[.]57:443/tpt/arizona/child/merge/
82[.]78[.]228[.]57:443/walk/
82[.]78[.]228[.]57:443/xian/

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.

Uncomfortable Truth #2 about Phishing Defense

In Part 1, we explored the uncomfortable truth that no matter how good your perimeter controls, malicious emails still reach the inbox. While security technologies do a great job of telling us about the attacks they have stopped, they do a poor job of telling us about the threats they have let through. This segues nicely into: 

Uncomfortable Truth #2: You cannot defend against attacks you cannot see. 

Visibility is a core tenet of any security operations center. Afterall, if a SOC has no visibility of an attack, they cannot mitigate it.  As the threat landscape evolves, organizations deploy more and more layers of technology – panacea-promising point products aimed at the threat du jour. Sometimes these products generate so much noise they create a fog that obscures the threat. Sometimes they just don’t realize it’s there at all. 

If some of the controls we have in place to protect us from phishing threats are failing to deliver on their promises, what next? I’m certainly not advocating that we rip out our secure email gateways and ditch them into the dumpster of derision. As I said in part 1, they do a good job of stopping known threats and patterns, and I for one am grateful for them stopping unwanted and unsolicited spam reaching my inbox 

Yet I’ve had many conversations with people who are placing blind faith in the promises of technical controls to keep them safe from phishing. While such enthusiasm is admirable, in this context it’s misplaced. The scale and sheer pace of evolution within the phishing threat landscape means that like any other control, it’s not going to be 100% effective. Bad stuff will get through, right under your noses. 

Therefore, we have to remember that when technology fails, the only sensor that can give us visibility of attacks that have bypassed perimeter controls is the recipient themselves. Yet visibility of an attack is more than merely getting a report of a suspicious email from an end user. In future posts, we’ll look at this in more detail, and discuss enabling and empowering users to report suspicious emails, along with the capabilities needed to get visibility of phishing attacks. 

 Next up: Uncomfortable Truth #3 – The best security awareness program in the world will NEVER deliver a zero click rate. Until then, learn more about the expertise of Cofense Phishing Defense Center.  

 

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.  

‘Read the Manual’ Bot Gives This Phishing Campaign a Promising Future

CISO Summary

Cofense IntelligenceTM has spotted a surgical phishing campaign whose targets could easily broaden, given the sophisticated development of its tactics. For now, it’s taking aim at financial departments in Russia and neighboring countries, using the Read the Manual (RTM) Bot to deliver a banking trojan.

Among other capabilities, the malware steals data from accounting software and harvests smart card information. The newest version uses The Onion Router (TOR) communication protocol, whose privacy and extra encryption are signs the threat actors could be serious about developing the banking trojan for future campaigns.

Technical controls can help combat this threat, for example, blocking connections to TOR nodes and inspecting network traffic for connections attempts. More proactively, educate end users on evolving phishing tactics.

Full Details

Cofense IntelligenceTM has analyzed a phishing campaign delivering a banking trojan and targeting Russia and neighboring countries. Read The Manual (RTM) Bot is created by a cyber group known by the same name. The RTM group is targeting the financial departments within different industry sectors. This modular banking trojan has many unique features, such as stealing data from accounting software and harvesting smart card information. This newest version uses The Onion Router (TOR) communication protocol. These campaigns are typically written in Cyrillic and use the Monthly Payment lure. Figure 1 shows an email associated with this campaign.

Figure 1: An email associated with this phishing campaign

RTM Bot targets accounting software while initially scanning the drive of the endpoint. The scan looks for any items related to the Russian remote banking system and relays the information found to the C2 for further instructions. RTM Bot scours the web browser history, and can access currently opened tabs, looking for any banking URL patterns. After the initial scan, the banking trojan then gathers information, effectively fingerprinting the machine. Figure 2 shows the accounting software strings found in the memory of this sample.

Figure 2: Strings associated with accounting software

Some accounting software requires the use of a smart card to authenticate to the software and access data associated with it. RTM Bot attempts to locate these smart card readers by scanning the registry and attached devices. If a smart card is found, the banking trojan then interacts with the Winscard API function to harvest information. The harvested information is then held within the memory buffer until it is sent to the C2. Figure 3 shows some memory strings associated with the smart card search and API interaction.

Figure 3: Memory strings associated with the smart card search and API interaction

Before attempting to exfiltrate the gathered information, the banking trojan will look up the host’s external IP address and add the value to its collection. It uses a GET request to the website hxxp://myip[.]ru/index_small[.]php to gather the external IP of the infected machine. Figure 4 shows the GET request.

Figure 4: The GET request for the external IP of the machine

Other values collected by RTM Bot during the fingerprinting of the machine include:

  • Username
  • Machine name
  • Logged on user privileges
  • OS version
  • Anti-virus installed
  • Time zone
  • Default language

Previous iterations of this malware used Blockchain Domain Name Services (BDNS) for its C2 infrastructure. The biggest change in the new version is the switch to using The Onion Router (TOR) communication protocol for its C2 infrastructure. Note that RTM Bot does not install a TOR client. Instead it uses the onion libraries, which are often called TOR SOCKS. By not installing a client onto the machine, RTM Bot minimizes its chances of being detected by anti-virus manipulating the Operating System (OS). Figure 5 shows memory strings associated with the TOR C2 infrastructure.

Figure 5: Memory strings associated with the TOR C2 infrastructure

Using the TOR protocol for communication helps threat operators in many ways. The first is that the communication is encrypted at the application layer of the OSI model, which adds an extra layer of encryption to the traffic. Another reason is the privacy that the TOR network affords the threat actors. This is done by passing the data through a network of relay points using layers of encryption. Each relay point decrypts a layer that reveals the next destination and routes the packet respectively. The relay point, however, does not know the next destination or the final destination the packet should reach. This routing scheme helps eliminate eavesdropping, because the router doesn’t know the end to end connections created, as well as the obfuscation by multiple layers of encryption.

RTM Bot has many of the common capabilities of banking trojans, including keylogging and screen captures. The malware can be pre-compiled with modules or it can download and execute the modules as instructed by the C2. The RTM cyber group focuses on financial departments within business in specific countries but can very easily shift its aim.

The newest version using the TOR communication protocol shows the group is actively developing this banking trojan for the future. Blocking connections to TOR nodes and inspecting network traffic for connection attempts will help mitigate the exfiltration of information. However, educating end users about phishing campaign threats and maintaining the threat knowledge base is the key to avoiding these threats.

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.

Uncomfortable Truth #1 about Phishing Defense

Part 1 of a 5-Part Series   

The threat posed by phishing is not new. For many years, the media and research papers have been littered with examples of data breaches that have been traced back to phishing attacks.  

Organizations have attempted to tackle the threat through investments in next-gen technologies and increased employee awareness training. Despite these efforts, the threat has not receded, in fact, it’s become more sophisticated and more effective.  

It’s time for organizations to accept some uncomfortable truths about routine approaches to phishing defence and think differently – understanding that REAL phish are the REAL problem. In this blog series, we’ll explore these uncomfortable truths and perhaps challenge conventional thinking. Ultimately, we’ll aim to equip you with a refreshed perspective on how to stop phishing attacks in their tracks. 

 Uncomfortable Truth #1 – No matter how good your perimeter defenses, phishing emails are still reaching the inbox. 

Contrary to much of the marketing hype we see in the cybersecurity industry, technology does not, and cannot, stop all phishing emails from reaching a user’s inbox. Sure, technologies like secure email gateways do a good job at stopping known threats and risk patterns, and machine learning and artificial intelligence may live up to expectations for certain attack types such as business email compromise.  

But, and it’s a big but, as defensive technologies become more pervasive, threat actors simply evolve their tactics and techniques to neutralise them. Added to that, any security control is a balance of protection over usability – i.e. being frictionless to the user. Here at Cofense, we see this every day.  

The Cofense Phishing Defense Center currently receives and analyzes suspicious emails from some 2 million enterprise users globally. That’s quite a network of human sensors. 1 in 7 of the emails reported by these users is found to have malicious content. The important thing to remember is that every email our analysts examine has bypassed one or more layers of technical controls that were put in place to prevent threats from reaching the inbox. 

The tactics and techniques used to maximize chances of successful delivery and payload execution are evolving all the time. Some of these tactics pit technology against technology, while others remain surprisingly low tech.  

Waxing Lyrical about the Brazilian Phish.  

Recently, the Cofense Phishing Defense Center began receiving reported emails that followed the somewhat unimaginative but proven theme of ‘Attached Invoice.’ Upon analysis, the attachment appeared benign – no malicious behavior was observed.  

However, it had all the hallmarks of a phish, and the analysts could see more reports arriving – all from Brazil. With this in mind, they put on their metaphorical Brazilian hat, and gave their analysis workstation a Brazilian IP address.   

This time, upon execution, the analysts observed different behavior with the attachment. A connection was made to payload infrastructure, and a malicious script was downloaded. The script didn’t execute, but deeper analysis identified further location validation checks. After configuring the analysis workstation with a Brazilian locale and keyboard layout, the sample was executed again, and, voila, IOCs were captured. The net result? Automated analysis would have had a hard time identifying this threat, as this customer’s perimeter controls clearly did.  

Zombie Apocalypse. Now. 

Here’s another example of how phishing tactics evolve. Out of nowhere, someone responds to an email conversation that wrapped up months ago. It’s a real conversation that actually happened. Maybe it’s about a meeting, a job opportunity, or a reply to that problem you had over a year ago; this email is highly relevant to you. But something is off, the topic of the email is months out of date, and now there is a weird error message. 

Meet the Zombie Phish, a devious tactic that revives a long-dead email conversation.
Fraudsters hijack a compromised email account, and using that account’s inbox, reply to dormant conversations with a phishing link or malicious attachment. Because the subject of the email is directly relevant to the victim, a curious click is highly likely to occur. 

These types of attacks are dangerous as they can involve internaltointernal communication, or communication between trusted third parties. When combined with other techniques such as malicious content being hosted in cloud-sharing services like Dropbox, OneDrive, or Sharepoint.com, inline controls can be rendered ineffective. Learn more about this attack in this Cofense blog: Re: The Zombie Phish

Next in this series: Uncomfortable Truth #2: You cannot defend against attacks you cannot see. In the meantime, learn more about the expertise of Cofense Phishing Defense Center.  

 

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.