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

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.  

Lime RAT: Why It Caught Our Eye and How this Versatile Malware Works

CISO Summary

Cofense IntelligenceTM has spotted a phishing campaign using the Lime remote administration tool (RAT), whose versatility makes it an especially dangerous malware type. Lime RAT is a mash-up of ransomware, cryptominer, stealer, worm, and keylogger. When skillfully deployed, it can filch a wide range of information, encrypt computers for ransom, or transform the target host into a bot.

Lime RAT appeals to novice and seasoned threat actors alike, thanks to its anti-virus evasion techniques, anti-virtual machine features, small footprint, and encrypted communications. Threat analysts will want to read the full analysis below. Security awareness managers will want to educate employees by simulating phishing emails containing diverse malware threats.

Full Details

Cofense IntelligenceTM analyzed a phishing campaign that delivered an all-in-one ransomware/cryptominer/stealer/worm/keylogger called Lime Remote Administration Tool (RAT). Lime RAT’s code is written in C# and is dependent on .NET 4.0. Lime RAT is part of a malware library which includes Lime_Miner, Lime_Crypter, and Lime_USB. This malware is open source and touts itself as a teaching tool for .NET malware. But being feature-rich and well-documented, Lime RAT can also be used for nefarious actions by malicious operators.

An interesting feature of this malware family is the use of multiple ports for communication, which establishes redundancy for the communication channels. The initial setup of the Lime RAT building platform and panel needs only two things: port numbers and an AES (Advanced Encryption Standard) 128-bit encryption key. The port number is used to open a port to listen on the server. The AES key is used to encrypt all communication between the client and the server. Figure 1 shows the initial setup pane with the ports and AES key as discussed above.

Figure 1: Setup process for Lime RAT

The builder for the payloads is simply comprised of checkboxes and text input fields that even the most novice operators can use to produce effective, malicious binaries. This panel allows you to customize the payload with different features and icons. It also allows you to set the Command and Control (C2) infrastructure and the location for the persistent drop file on the targeted machine. Figure 2 shows the features available to customize each payload, including the anti-virtual machine option.

Figure 2: Features available to the Lime RAT payloads

When the Lime RAT payload has been created, sent to and executed on a target machine, the binary connects to the panel. When the client connects, it sends information to the control panel and includes details about the operating system, CPU, user, country, and more. The control panel gives the option to automatically assign a task for the client, for example, downloading and executing a specific file. Figure 3 shows the control panel populated with information from the connected client, while Figure 4 shows the ‘OnConnect’ automatic tasking panel.

Figure 3: Control panel view of an infected client machine connected to the C2 infrastructure

Figure 4: ‘OnConnect’ automatic tasking options

The control panel allows the operator to manipulate the target by right-clicking on the selected machine and choosing a command. This is where the operator can specify the method of attack: initiate the encryption for ransomware, drop a Monero miner, enable Remote Desktop Protocol (RDP), steal information/cryptocurrency, and more. Figures 5 and 6 show the options available to the operator for a given target.

Figure 5: Ransomware and other plugins for the target machine

Figure 6: Keylogging and persistence options for the targeted machine

The ransomware feature lets you customize the message as well as the image displayed. When the targeted host is encrypted with the ransomware aspect of this RAT, the file extensions are turned to ‘.Lime’. Figure 7 shows the customizable message and default image that displays to the client after the encryption has been initiated.

Figure 7: Lime RAT’s default ransomware message

The keylogging feature is not very advanced in what it collects. It can only collect what is entered by the keyboard and not what is auto-filled or added from the clipboard. The keylogger output does show a timestamp and which application the text was written in. Figure 8 shows the control panel output of a running keylogger module on a client infected with Lime RAT.

Figure 8: Collection of text from the keylogger module

As shown earlier in Figure 2, Lime RAT can spread like a worm. When the payload is built, the operator can specify the ‘USB spreading’ and ‘pinned task bar application spreading’ features be included within the payload. The USB spreading feature looks for any connected type 2 device and then attempts to replace any file with an executable version of Lime RAT. When doing this, Lime RAT will keep the original icon for the file that has now been infected. The spreading through the pinned task bar applications takes it one step further by replacing the shortcut path to which those icons are linked.

The ‘Thumbnail’ tab (Figure 9) within the control panel of Lime RAT is a screengrab of the infected machine. This screengrab can be turned on or off and has a timer that defaults to 5 seconds between screen grabs.

Figure 9: ‘Thumbnail’ tab that holds the screen grabs of the infected machines

Logging in Lime RAT is not nearly as advanced as we’ve seen in other RATs. As shown in the Figure 10, the ‘Logs’ tab only logs timestamps and IPs of connections and disconnections.

Figure 10: ‘Logs’ tab and the connections made

Lime RAT is an open source, well documented, .NET framework malware suite with multiple features that make it devastating when properly used. The ability for this malware to steal a wide range of valuable information, encrypt for ransom, and/or turn the target host into a bot with basic capabilities, mixed with an intuitive control panel display, makes it a likely choice for novice operators. The anti-virus evasion, anti-virtual machine feature, the small footprint, and encrypted communications would appeal to threat actors across the capability spectrum. The number one way to keep multivariate threats like Lime RAT from infecting a machine via a phishing campaign is to educate the end user on suspicious emails and attachments.

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.

Finding the Whole Phishing Attack: Problems and Solution

Mitigating a phishing attack is a little like zapping termites. If you don’t eliminate the whole problem, trouble continues to breed.

To help, CofenseTM has announced the general availability of Cofense VisionTM. We knew that existing email search and quarantine tools weren’t fast enough, making it hard for the SOC to find and remove every phish.

Integrated with the latest release of Cofense TriageTM, Cofense Vision lets incident responders see the entire phishing attack, including emails not reported by users. With a single click, the SOC can quarantine every bad email and stop the attack in its tracks.

Cofense Vision copies and stores all emails in the customer’s cloud, so the SOC can look for a phishing campaign without creating more work for the email team. The solution also provides a compliant, auditable workflow.

Let’s take a closer look at some of the problems it solves.

“Searching takes too long.”

Every day, phishing emails bypass perimeter defenses to land in users’ inboxes. As the Cofense Phishing Defense Center has reported, 1 in 7 reported emails is malicious. In 2018 alone, for example, our team found over 55,000 credential phishing attacks. A single well-crafted phish can cost a business big. It’s critical to perform searches quickly and efficiently, especially since threat actors are more creative in evading network security with polymorphism, encryption, and obfuscated malware.

But traditional native tools, Powershell, for instance, make email searching complex and extremely time-consuming. To search and purge with Powershell you’re limited to 50,000 mailboxes. If the mail environment is larger, you have to create multiple searches.

You also have to build searches for multiple senders or multiple subject lines, which complicates the hunt and slows it even more. It’s also tough to know that you’re hitting every mailbox and not missing any threats.

In old-school searching, emails are grouped together, or “clustered,” based on an exact match to criteria like sender and subject. This allows you to find emails that match criteria you know about. However, such an approach to clustering doesn’t account for the way malware morphs and avoids exact matching, in some cases changing the sender, subject, or content for each recipient.

“We create more work for the email team.”

Traditionally, every step described above is handled by the IT team that owns the email platform—not by the SOC, the team responsible for stopping attacks. There’s a built-in conflict, one of competing priorities. The messaging team needs to make sure legitimate emails go through, while the SOC is trying to defend the business by mitigating attacks.

In this set-up, the messaging team is doing its day job AND handling SOC requests to find and quarantine phishing emails. The issues detailed in the previous section—the limits of native search tools and the inadequacies of old-school clustering—make life even more difficult for the messaging team. They’re asked to perform searches that (a) take a lot of time because they’re so complex and (b) get in the way of their regular duties.

Without a solution that empowers the SOC to search and quarantine on its own—with no heavy lift from the messaging team besides determining the fate of quarantined emails—the hunt for phishing threats is going to be inefficient. It’s a lot easier to send a command than to make a request.

With Cofense Vision, operators search an offline copy of the email environment hosted in their own cloud. There is thorough and strict auditing of who is searching for what. The SOC team gets what it needs while the mail team doesn’t have to hand over the keys to the kingdom.

If complicated email searching is slowing your phishing response, get more details on Cofense Vision. Learn more 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.

Efficient Phishing Programs: 3 Common Problems and 1 Awesome Solution

By Kaustubh Jagtap

You hear it all the time. Teams tasked with improving phishing defense aren’t sure how many employees see, or even receive, the simulations they send.

It’s why CofenseTM has introduced the Cofense PhishMe Responsive Delivery™ capability in Cofense PhishMe™ Enterprise edition. This capability allows operators to send a phishing simulation only when targeted employees are actively using email. It also delivers the phishing simulation directly to the employee inbox, thereby bypassing any technical issues including gateway configuration changes and whitelisting complications. Additionally, having this capability adds another layer of automation to your phishing program, making it more effective and efficient to manage.

Following are 3 of the problems this new feature addresses. If you manage an anti-phishing program, these will surely sound familiar.

“Whitelisting really complicates delivery and reporting.”

Sometimes your email gateway is a blessing and a curse. Though it doesn’t catch every real phishing email, it’s configured to stop the majority—and in doing so occasionally also catches some of your simulations.

That’s a two-fold problem. Too often employees miss out on the chance to test their ability to catch a phish, which hurts your organization’s overall resiliency to phishing attacks.

Also, your anti-phishing program’s metrics get thrown off. Say you phish 500 employees. If 250 report the email and 250 fall susceptible, you wind up with a 1:1 ratio, which is pretty decent. But what if, thanks to whitelisting, 75 employees never got the email? Mathematically, your reporting is fine, but your employees’ true readiness will remain unclear.

 “We’re global, so scheduling is tough.”

We hear this one a lot. Eastern Time, Pacific Time, London, Tokyo, and Sydney times—when you want simulations to arrive when global employees are at work, scheduling can get complicated.

It’s one more thing to worry about, one more drain on your time. Running simulations across multiple time zones, cultures, and languages is daunting enough. Having to untangle time zones only adds to the headaches.

“If people aren’t on email when we send, we might miss them.”

Everyone is snowed under by emails these days. So when somebody isn’t on email for even a couple of hours, he or she may have 20 or 30 messages stacked up.

It’s easy for that person to miss the simulation you sent—the one you carefully crafted and scheduled, the one whose results you were eager to see. The teachable moment may have passed. If there’s no “evidence of life” on the email account, a simulation could be dead on arrival. Can you say “inefficient?”

The new Cofense PhishMe Responsive Delivery in Cofense PhishMe addresses these common delivery hassles. Give it a try! Don’t have it and interested? Learn more. 

 

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.