Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Dridex Phishing Campaign uses Malicious Word Documents

Published: 2014-12-01
Last Updated: 2014-12-01 17:48:11 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

This is a guest diary submitted by Brad Duncan.

During the past few months, Botnet-based campaigns have sent waves of phishing emails associated with Dridex.  Today, we'll examine a wave that occurred approximately 3 weeks ago.  The emails contained malicious Word documents, and with macros enabled, these documents infected Windows computers with Dridex malware.

Various people have posted about Dridex [1] [2], and some sites like Dynamoo's blog [3] and TechHelpList [4] often report on these and other phishing campaigns.

Let's take a closer look at one of the November phishing waves.

On 11 Nov 2014, I saw at least 60 emails with Duplicate Payment Received in the subject line.  This appeared to be a botnet-based campaign from compromised hosts at various locations across the globe.

These messages had an HTML component, and some also had an image displaying a written signature.

After opening the attached Word document on a Windows host, Dridex was downloaded if macros were enabled.  Post-infection traffic began shortly after the download.

Shown above: infection traffic as seen in Wireshark.

Monitoring the infection traffic on Security Onion, we found alerts for Dridex traffic from the EmergingThreats signature set (ET TROJAN Dridex POST Checkin) [5]

Shown above: events from Sguil in Security Onion.

File hashes changed during this wave of emails, indicating at least 3 different Word documents were used.  During this phishing run, Dridex malware came from IP addresses in the 62.76.185.0/24 block.  The following were samples were found:

Example of malicious Word document from 11 Nov 2014 phishing email:

https://malwr.com/analysis/M2M2ZDQxM2M2NzFhNDllZDhjMjQzMjAyYzRkNWZhYTA/

Example of Dridex malware downloaded by the above Word document:

https://malwr.com/analysis/YzA3ZDY0ODE2ZjY5NDE3NTlhZjkyNTg3NTIwNDljM2I/

References:

[1] http://stopmalvertising.com/malware-reports/analysis-of-dridex-cridex-feodo-bugat.html
[2] http://www.abuse.ch/?p=8332
[3] http://blog.dynamoo.com/
[4] https://techhelplist.com/index.php/spam-list/
[5] http://doc.emergingthreats.net/2019478

----------
Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at http://www.malware-traffic-analysis.net

Keywords:
2 comment(s)

Flushing out the Crypto Rats - Finding "Bad Encryption" on your Network

Published: 2014-12-01
Last Updated: 2014-12-01 14:45:43 UTC
by Rob VandenBrink (Version: 1)
4 comment(s)

Just when folks get around to implementing SSL, we need to retire SSL!  Not a week goes buy that a client isn't asking me about SSL (or more usually TLS) vulnerabilities or finding issues on their network.

In a recent case, my client  had just finished a datacenter / PCI audit, and had one of his servers come up as using SSL 2.0, which of course has been deprecated since 1996 - the auditor's recommendation was to update to SSL 3.0 (bad recommendation, keep reading on).  When he then updated to SSL 3.0 and was re-scanned, the scanner of course found problems with *that* too - and the recommendation changed to update to TLS 1.1 or 1.2 - SSL 3.0 has its own set of issues, including the furor around the recent POODLE vulnerability.

This shows two things actually:

1/ W-a-a-a-y too many assessments consist of scanning the target, and pasting the output of the scanning tool into the final report.  

2/ In this case, the person writing the report had either not read the text they were pasting, or was not knowledgeable enough to understand that updating from SSL 2 to SSL 3 wasn't going to get to a final "good" state.  Shame on them either way!

As a side note, if the site (it was on an internal network remember) was running plain old HTTP, then  the scanner would not have identified a problem, and the person behind the scanner would very likely have missed this completely! (OOPS)

Anyway, my client's *real* question was "how can we scan our network for vulnerable SSL versions and ciphers, but not pay big bucks for an enterprise scanning tool or a consultant?"

My answer was (that day) - NMAP of course!

To check for weak or strong ciphers on a server or subnet, use the script "ssl-enum-ciphers"

nmap -Pn -p443 isc.sans.edu --script=ssl-enum-ciphers  (Bojan covered this one in some detail in August, at https://isc.sans.edu/diary/18513 )

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 09:42 Eastern Standard Time

Nmap scan report for isc.sans.edu (66.35.59.249)
Host is up (0.097s latency).
rDNS record for 66.35.59.249: isc.sans.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 34.63 seconds

You can scan specifically for SSHv2 devices using the script "sshv2.nse"

nmap -Pn -p443 --open  192.168.122.0/24 --script=sslv2

Oops - this scan found a server admin card (an iLO equivalent) on my home network that I thought that I had updated (my bad)

Nmap scan report for 192.168.122.246
Host is up (0.029s latency).
PORT    STATE SERVICE
443/tcp open  https
| sslv2:
|   SSLv2 supported
|   ciphers:
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|_    SSL2_RC4_128_EXPORT40_WITH_MD5
MAC Address: 00:E0:81:CE:9E:74 (Tyan Computer)

NMAP also has scripts ssl-heartbleed script (if you're still focused on that), and has an ssl-poodle script, but you'll need to download that one from their script page at http://nmap.org/nsedoc/scripts/  - it's not in the base installation.

While you're at it, take a look at cipher support on any SSH enabled devices on your network - you are likely to be surprised at what you find.  For instance, this is the management interface of my home firewall - I'm not thrilled with the 3des-cbc and MD5 support, but I guess that's why there's a new firewall in a box, just waiting for a free day for me to swap it in I guess.

nmap -Pn -p22 192.168.122.1 --script=ssh2-enum-algos.nse

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 17:02 Eastern Standard Time

Nmap scan report for 192.168.122.1
Host is up (0.0020s latency).
PORT   STATE SERVICE
22/tcp open  ssh
| ssh2-enum-algos:
|   kex_algorithms: (1)
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (1)
|       ssh-rsa
|   encryption_algorithms: (4)
|       aes128-cbc
|       3des-cbc
|       aes192-cbc
|       aes256-cbc
|   mac_algorithms: (4)
|       hmac-sha1
|       hmac-sha1-96
|       hmac-md5
|       hmac-md5-96
|   compression_algorithms: (1)
|_      none
MAC Address: C8:4C:75:DA:31:E3 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 47.39 seconds

Or, for a real eye-opener, scan your subnet for SSHv1 enabled devices - note that this scan (and the previous one) assumes that your SSH service is on port 22.  In a "zero knowledge" scan, you'd of course scan a wider range of ports (all of them if there's time for that):

nmap -Pn -p22 192.168.122.0/24 --script=sshv1.nse

This scan didn't find anything at my house, but it *always* finds stuff at client sites!

What crypto support issues have you found when you scanned for them?  And how long do you thing these problems were there?  Please, share your story using our comment link!

===============
Rob VandenBrink
Metafore

Keywords:
4 comment(s)

Do you have a Data Breach Response Plan?

Published: 2014-12-01
Last Updated: 2014-12-01 00:12:10 UTC
by Guy Bruneau (Version: 1)
1 comment(s)

The Ponemon Institute conducted and released a paper in September on its second annual study on data breaches. Some of the data collected shows interesting results. Based on their survey, 68% of respondents don't believe their company would know how to deal with negative public opinion and 67% think their organization does not understands what to do after a data breach occurs.[page 3] If either one occurs, it usually impact the brand, it can lead to lost of customers and shake business partners' trust and confidence in the company.

They also found that more companies now have a data breach response plan 73% in 2014 compared to 61% last year. According to this survey, only ~30% of the response plans are effective or very effective.[page 4] The report suggest to be effective, the organization must provide training to its employees, to make them aware of their responsibilities on how to protect customer information when a data breach occurs.

There are several template of data breach response plan freely available to get you started. If you have one in place, how often is it reviewed and exercised? Do your receive training on how to properly safeguard customers' sensitive data? The study can be downloaded here.

[1] http://www.experian.com/assets/data-breach/brochures/2014-ponemon-2nd-annual-preparedness.pdf [page 3,4]
[2] https://privacyassociation.org/resources/article/security-breach-response-plan-toolkit/
[3] http://www.cica.ca/resources-and-member-benefits/privacy-resources-for-firms-and-organizations/docs/item48785.pdf
[4] http://www.justice.gov/sites/default/files/opcl/docs/breach-procedures.pdf
[5] http://www.securingthehuman.org

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

1 comment(s)
Diary Archives