(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.


Malicious spam (malspam) pushing the Dridex banking Trojan disappeared in mid-2016, but it reappeared in January 2017 starting with a small campaign targeting UK financial institutions [1]. Since then, weve seen a handful of reporting about Dridex, but I hadnt noticed the same large-scale distribution like we saw in 2015 and 2016. At least not until recently.

Less than two weeks ago on 2017-03-30, high-volume waves of malspam pushing Dridex reappeared [2]. Because my last in-depth look at Dridex for the ISC was in January 2016 [3], I think its high time we take a more current look at this malspam.

Thursday 2017-03-30

On Thursday 2017-03-30, we saw Dridex from at least two different waves of malspam [4]. In one wave of emails, attachments were zip archives containing a Visual Basic Script (.vbs) file. In the other wave, attachments were zip archives containing a Windows executable. border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: Extracted executable (Dridex).

nother wave of Dridex that I didnt have time to document. Attachments were now zip archives containing Word documents. These Word documents had macros designed to download and install Dridex. border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: Extracted Word document with macros designed to download/install Dridex.

nday 2017-04-10

On Monday 2017-04-10, another wave of Dridex malspam occurred. This wave of malspam tried a new tactic. Attachments from were now PDF files with embedded Word documents. These PDF files required user action to open the Word document. border-width:2px" />
Shown above: border-width:2px" />
Shown above: Opening the PDF file on a Windows host leads to the embedded Word document.

d a Windows host by opening one of the PDF files and enabling macros for the embedded Word document. Filtering on the traffic in Wireshark, youll see the initial HTTP request to download Dridex. Then youll find three different IP addresses for post-infection SSL/TLS traffic associated with Dridex.

The Dridex binary was encoded while it was sent over the network. border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: border-width:2px" />
Shown above: Certificate data associated with Dridex post-infection SSL/TLS traffic.

ng>Indicators of Compromise (IOC) from Monday 2017-04-10

The following URLs were extracted from the Word document macros seen on Monday 2017-04-10. These URLs retrieved the encoded Dridex binary. Many of these have already been taken off-line.

  • 211shap.ru - GET /874hv
  • anticon.net - GET /874hv
  • cardoso1.com - GET /874hv
  • centralsecuritybureau.com - GET /874hv
  • decadd.com - GET /874hv
  • designbyli.com - GET /874hv
  • hiddencreek.comcastbiz.net - GET /874hv
  • jheroen.nl - GET /874hv
  • kapil.50webs.com - GET /874hv
  • kpwc.comcastbiz.net - GET /874hv
  • marinusjanssen.nl - GET /874hv
  • ncdive.com - GET /874hv
  • produlav.com.br - GET /874hv
  • RussellYermal.com - GET /874hv
  • solucionesfenix.net - GET /874hv
  • super-marv.com - GET /874hv
  • trans-atm.com - GET /874hv
  • tserv.su - GET /874hv
  • usawaterproofing.com - GET /874hv
  • www.mdfond.ru - GET /874hv

Below is SSL/TLS post-infection traffic and associated certificate data from my infected Windows host on 2017-04-10:

IP address over TCP port 4743

  • countryName = ID
  • stateOrProvinceName = upind0
  • localityName = Jakarta
  • organizationName = Tbreimem SAS
  • organizationUnitName = [email protected] Cindusto Atoumo
  • commonName = halindngofol.weadtrgtutmt.gn

IP address over TCP port 4743

  • countryName = CY
  • stateOrProvinceName = Meourep Seinhadth tberese0
  • localityName = Nicosia
  • organizationName = Tteeran SNC
  • commonName = llrrofom.fo

IP address over TCP port 443:

  • countryName = JP
  • stateOrProvinceName = Thhithan
  • localityName = Tokyo
  • organizationName = Arsis SCE
  • organizationUnitName = Aputhe Tshashf and as4po
  • commonName = cakinoble.lancaster

Final words

For now, it looks like high-volume Dridex distribution through malspam is once again a feature of our current threat landscape. But how much of a threat is it?

As always, if you have a properly-configured Windows host in a well-administered environment, your risk of infection is low. But as usual, humans are the weakest link in this infection chain. If people are determined to bypass all warnings, and their systems are configured to allow it, they may very well become infected.

Emails, malware samples, and the pcap associated with 2017-04-10 Dridex malspam can be found here.

Brad Duncan
brad [at] malware-traffic-analysis.net


[1] FlashPoint: Dridex Banking Trojan Returns, Leverages New UAC Bypass Method
[2] Proofpoint: High-Volume Dridex Campaigns Return, First to Hit Millions Since June 2016
[3] SANS Internet Storm Center (ISC): Dridex malspam example from January 2016
[4] Malware-traffic-analysis.net: 2017-03-30 - Dridex malspam (2 waves)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Enlarge (credit: manley099)

Federal prosecutors say they've dealt a fatal blow to Kelihos, a network of more than 10,000 infected computers that was used to deliver spam, steal login passwords, and deliver ransomware and other types of malware since 2010.

The US Justice Department announced the takedown on Monday, one day after authorities in Spain reportedly arrested alleged Kelihos operator Pyotr Levashov, according to Reuters. The programmer and alleged botnet kingpin was apprehended after traveling with his family from their home in Russia, which doesn't have an extradition treaty with the US, to Spain, which does have such a treaty. A search warrant application unsealed Monday said prosecutors tied Levashov to Kelihos because he used the same IP address to operate Kelihos and to access his [email protected] e-mail account. The e-mail address and IP addresses were also associated with multiple online accounts in Levashov's name, including Apple iCloud and Google Gmail accounts.

On Monday, US officials also unsealed a criminal complaint against Levashov that charged him with wire fraud and unauthorized interception of electronic communications. Levashov allegedly operated Kelihos since 2010. According to authorities, he used the botnet to further a spamming operation that distributed hundreds of millions of e-mails per year pushing counterfeit drugs, work-at-home, and pump-and-dump stock scams. Prosecutors also alleged the defendant used Kelihos to install malware on end-user computers and to harvest passwords to online and financial accounts belonging to thousands of Americans.

Read 3 remaining paragraphs | Comments

Bluecoat SSL Visibility CVE-2016-10259 Denial of Service Vulnerability
Foreman CVE-2017-2672 Information Disclosure Vulnerability
[SECURITY] CVE-2017-5648 Apache Tomcat Information Disclosure
[SECURITY] CVE-2017-5651 Apache Tomcat Information Disclosure
Schneider Electric SoMachine and Modicon CVE-2017-7574 Security Bypass Vulnerability
Foxit PDF Toolkit CVE-2017-7584 Memory Corruption Vulnerability
Atlassian Confluence 'viewmyprofile.action' Cross Site Scripting Vulnerability
DefenseCode ThunderScan SAST Advisory: WordPress Tribulant Slideshow Gallery Plugin - Cross-Site Scripting Vulnerabilities
Atlassian JIRA Server CVE-2016-4319 Cross Site Request Forgery Vulnerability
Atlassian Bitbucket Server CVE-2016-4320 Directory Traversal Vulnerability
Atlassian JIRA 'project/ViewDefaultProjectRoleActors.jspa' HTML Injection Vulnerability

Enlarge (credit: NSA)

On April 8, as part of a long, awkwardly worded rant about President Donald Trump's betrayal of his "base," the individual or individuals known as the Shadow Brokers posted the password to an encrypted archive containing what appear to be components of a toolkit associated with the National Security Agency's alleged Equation Group hacking campaign. But those hoping for even more spectacular exploits than those leaked earlier by the Shadow Brokers will likely be disappointed. However, the files do include a number of tools that may still be usable, as well as significant amounts of information about systems that appear to have been hacked by the NSA.

Many information security analysts were unimpressed.

In many respects, the files leaked earlier by the Shadow Brokers—in particular Cisco router and firewall exploits—were potentially far more damaging, as in many cases they worked against currently deployed Internet infrastructure. The tools in the master file, however, appear to be much older and targeted operating systems that are generally no longer in service—though some of the systems that they were apparently used to compromise are still online.

Read 5 remaining paragraphs | Comments


Malware that WikiLeaks purports belongs to the Central Intelligence Agency has been definitively tied to an advanced hacking operation that has been penetrating governments and private industries around the world for years, researchers from security firm Symantec say.

Longhorn, as Symantec dubs the group, has infected governments and companies in the financial, telecommunications, energy, and aerospace industries since at least 2011 and possibly as early as 2007. The group has compromised 40 targets in at least 16 countries across the Middle East, Europe, Asia, Africa, and on one occasion, in the US, although that was probably a mistake.

Uncanny resemblance

Malware used by Longhorn bears an uncanny resemblance to tools and methods described in the Vault7 documents. Near-identical matches are found in cryptographic protocols, source-code compiler changes, and techniques for concealing malicious traffic flowing out of infected networks. Symantec, which has been tracking Longhorn since 2014, didn't positively link the group to the CIA, but it has concluded that the malware Longhorn used over a span of years is included in the Vault7 cache of secret hacking manuals that WikiLeaks says belonged to the CIA. Virtually no one is disputing WikiLeaks' contention that the documents belong to the US agency.

Read 7 remaining paragraphs | Comments

LibTIFF CVE-2017-7599 Denial of Service Vulnerability
LibTIFF CVE-2017-7599 Denial of Service Vulnerability
LibTIFF CVE-2017-7594 Denial of Service Vulnerability
LibTIFF CVE-2017-7601 Denial of Service Vulnerability
LibTIFF CVE-2017-7597 Integer Overflow Vulnerability
Oracle Java SE CVE-2017-3259 Remote Security Vulnerability
Oracle Java SE CVE-2017-3261 Remote Security Vulnerability
Oracle Java SE CVE-2017-3231 Remote Security Vulnerability
Microsoft Office OLE Feature Remote Code Execution Vulnerability
Dropbox Lepton CVE-2017-7448 Denial of Service Vulnerability
Foscam All networked devices, multiple Design Errors. SSL bypass.
[slackware-security] libtiff (SSA:2017-098-01)
[SECURITY] [DSA 3827-1] jasper security update
ChromeOS / ChromeBooks Persist Certain Network Settings in Guest Mode

When extracting hashes from an active directory database for password auditing purposes, it can also possible to extract hashes of a user font-size:11pt">I work for a global Fortune 500 company where employees number in the several tens of thousands. Our password policy isnt monolithic, but at the core it varies some from the nebulous industry standard. One of the elements that is different is that we ask users to rotate their passwords more frequently than most. For our most sensitive users, that is every 30 days.

ze:11pt">Password discussions are numerous out there on the internet and there have been many articles of late suggesting that frequent password rotation just causes users to iterate their passwords on the same core string. Password1 becomes Password2, then Password3 and so on. We had some spirited internal discussions about whether we should relax our policy in accordance with this guidance. Ultimately, we decided that we wanted some data on password security in our environment. People can blog all they want about opinions, but the best security decisions are made with data to support them.

font-size:11pt">So we set out to measure how often our users made use of a shared string when constructing their passwords, and also how secure our users passwords actually are. To be clear, Im using the term measure here in the sense that we are trying to reduce uncertainty about a subject, not trying to know exactly the size/shape/scope of a thing. (For more on that, I recommend How to Measure Anything font-size:11pt">Measuring passwords meant (to us) password cracking. Before going further, I want to be clear that we obtained permission from our Legal department to conduct our password auditing after satisfying them that we were taking due care with user passwords and privacy. Im not going to go into those details here, but suffice to say that permission is essential for activities like this.

font-size:11pt">One of the things that we wanted to demonstrate was the effectiveness that password cracking could have - and in what timeframe. Accordingly we built a very moderate cracking rig for both financial reasons and also to show what a simple setup could achieve. We bought a motherboard which could handle two modern graphics cards, a cheap Intel Celeron processor, and 2 GeForce GTX 1070 graphics cards. We scraped together some stray RAM, scavenged an old desktop case, and with some ingenuity, crammed the new hardware into the old case. Its a Frankensteinian monster - nothing sleek or sexy about it. But its functional and cost less than $2000 all told.

font-size:11pt">In an enterprise, the best place for a treasure trove of passwords to crack is the ntds.dit file on an Active Directory Domain Controller. That, in combination with the SYSTEM hive gives you access to all the passwords in AD. In our environment, ntds.dit turned out to be 5 GB. Thats...pretty large.

font-size:11pt">this tool). Happily, secretsdump worked much faster and gave us what we wanted within our lifetime.

font-size:11pt"> wanted to crack a password currently in use if we could help it.

font-size:11pt"> and the default rules available in hashcat for a series of hybrid attacks. We tried various iterations with that wordlist as well as some created from observations about our environment in a hybrid attack (wordlists plus rules generated by hashcat). Eventually, we turned to a little brute force cracking to bat cleanup. We brute forced all passwords from 1 through 8 characters in length in our environment. All told, we spent roughly 6 days of cracking time (several weeks of real time juggling other projects and troubleshooting this or that), 5 of which were just the straight brute force attacks.

font-size:11pt">Below are some statistics about what we learned by analyzing our cracked passwords. Please note, these observations are only on the passwords which we cracked, not the 80% which we havent (yet). By necessity, we cracked the easy ones first of course, which included the ones with shared strings. So although these observations are certainly interesting, they are necessarily skewed towards users with poor password hygiene. Just something to keep in mind.

font-size:11pt">19 characters - the longest shared strings observed. One of them was Thisisalongpassword - maybe so, but not good enough to avoid being cracked.

font-size:11pt">With the help of Didiers script, we certainly learned a lot about the use of shared strings in our users passwords. However, we were not able to find the data to conclude anything concrete about the relationship of our password rotation policy and the use of shared strings. Thats ok though, because by running through the cracking process we did show that the difference between a 30 day rotation policy and something longer is not going to make much difference.

font-size:11pt">We clearly demonstrated that a moderate cracking rig run by people who don font-size:11pt"> of them within days. No password rotation policy will stay ahead of that.

font-size:11pt">Therefore we should a)make sure that all our passwords are longer than that, b)make sure that its really really hard to crack passwords at an enterprise scale (protect your Domain Controllers!) c)adjust our password rotation cycle to ease the burden on our users and d)continue to emphasize the importance of good passwords and educate our users on how to construct them.

font-size:11pt">There are other obvious conclusions that can be made here - two-factor all the things for example. None of these conclusions are ground-breaking or anything that you, as a security professional, did not likely know before reading this article. But this wasnt really an exercise in demonstrating that passwords are dead or the weakness of relying on passwords as a sole means of authentication. It was an attempt to measure user behavior, justify security policy changes with data, and track the impact that adjusting those policies may have on our users/our security posture.

font-size:11pt">In the first two of those goals, we feel that we have succeeded well.

font-size:11pt">I said it before, but its worth saying again: thanks to Didier for his contributions to our efforts and the community at large.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status