Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2015-05-20 InfoSec Handlers Diary Blog


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

Logjam - vulnerabilities in Diffie-Hellman key exchange affect browsers and servers using TLS

Published: 2015-05-20
Last Updated: 2015-05-20 19:03:17 UTC
by Brad Duncan (Version: 1)
11 comment(s)

There's a new vulnerability in town...   "The new bug, dubbed LogJam, is a cousin of Freak. But it’s in the basic design of TLS itself, meaning all Web browsers, and some email servers, are vulnerable." [1]  According to the article, "Internet-security experts crafted a fix for a previously undisclosed bug in security tools used by all modern Web browsers. But deploying the fix could break the Internet for thousands of websites."

Logjam attack can allow an attacker "to significantly weaken the encrypted connection between a user and a Web or email server..." [2]

From: https://weakdh.org/

Diffie-Hellman key exchange is a popular cryptographic algorithm that allows Internet protocols to agree on a shared key and negotiate a secure connection. It is fundamental to many protocols including HTTPS, SSH, IPsec, SMTPS, and protocols that rely on TLS.

We have uncovered several weaknesses in how Diffie-Hellman key exchange has been deployed...

We're starting to see news coverage from other outlets, and we're sure more analysis will emerge.  However, at this time your best source for more information on this bug is at weakdh.org.

For now, ensure you have the most recent version of your browser installed, and check for updates frequently.  If you’re a system administrator, please review the Guide to Deploying Diffie-Hellman for TLS at https://weakdh.org/sysadmin.html

--
Brad Duncan
ISC Handler and Security Researcher at Rackspace

References:

[1] http://www.wsj.com/articles/new-computer-bug-exposes-broad-security-flaws-1432076565
[2] http://www.pcworld.com/article/2924532/new-encryption-flaw-logjam-puts-web-surfers-at-risk.html

11 comment(s)

Upatre/Dyre malspam - Subject: eFax message from "unknown"

Published: 2015-05-20
Last Updated: 2015-05-20 02:47:20 UTC
by Brad Duncan (Version: 1)
5 comment(s)

Introduction

Yesterday on 2015-05-19, I attended a meeting from my local chapter of the Information Systems Security Association (ISSA).  During the meeting, one of the speakers discussed different levels of incident response by Security Operations Center (SOC) personnel.  For non-targeted issues like botnet-based malicious spam (malspam) infecting a Windows host, you probably won't waste valuable time investigating every little detail.  In most cases, you'll probably start the process to re-image the infected computer and move on.  Other suspicious events await, and they might reveal a more serious, targeted threat.

However, we still recover information about these malspam campaigns.  Traffic patterns evolve, and changes should be documented.

Today's example of malspam

Searching through my employer's blocked spam filters, I found the following Upatre/Dyre wave of malspam:

  • Date/Time: 2015-05-19 from from 12:00 AM to 5:47 AM CST
  • Number of messages: 20
  • Sender (spoofed): sent@efax-mail.co.uk
  • Subject: eFax message from "unknown" - [random number] page(s)
  • Attachment: Fax_ewew_43434.zip

As shown in the above image, these messages were tailored for the recipients.  You'll also notice some of the recipient email addresses contain random characters and numbers.  Nothing new here.  It's just one of the many waves of malspam our filters block every day.  I reported a similar wave earlier this month [1].  Let's look at the malware.

The attachment is a typical example of Upatre, much like we've seen before.  Let's see what this malware does in a controlled environment.

Indicators of compromise (IOC)

I ran the malware on a physical host and generated the following traffic:

  • 2015-05-19 15:16:12 UTC - 166.78.246.145 port 80 - icanhazip.com - GET /
  • 2015-05-19 15:16:13 UTC - 91.211.17.201 port 13410 - SYN packet to server, no response
  • 2015-05-19 15:16:16 UTC - 80.233.179.250 port 443 - two SYN packets to server, no response
  • 2015-05-19 15:16:58 UTC - 85.67.42.40 port 443 - two SYN packets to server, no response
  • 2015-05-19 15:17:40 UTC - 188.127.129.48 port 443 - SSL traffic - approx 510 KB sent from server to infected host
  • 2015-05-19 15:17:56 UTC - 217.10.68.152 port 3478 - UDP STUN traffic to: stun.sipgate.net
  • 2015-05-19 15:17:58 UTC - 62.122.69.132 port 443 - SSL traffic - approx 256 KB sent from server to infected host
  • 2015-05-19 15:18:40 UTC - 91.211.17.201 port 13409  - SYN packet to server, no response

In my last post about Upatre/Dyre, we saw Upatre-style HTTP GET requests to 91.211.17.201 but no HTTP response from the server [1].  That's been the case for quite some time now.  However, in this example, the infected host attempted a TCP connection to 91.211.17.201, but the connection was reset after the initial SYN packet, and an HTTP GET request was never sent.


Shown above: An example of Upatre-style HTTP GET requests from my previous ISC Diary on Upatre/Dyre


Shown above: Attempted TCP connections to the same IP address now reset (RST) by the server

How can we tell this is Upatre?  The malware checks for an IP address, and header lines in the associated HTTP GET request fit the pattern for Upatre.

As I've mentioned before, icanhazip.com is a service run by one of my fellow Rackspace employees [2].  By itself, it's not malicious.  Unfortunately, malware authors use this and similar services to check an infected computer's IP address.

What alerts trigger on this traffic?  See the image below for Emerging Threats-based Snort events on the infection traffic using Security Onion.

Related files on the infected host include:

  • C:\Users\username\AppData\Local\PwTwUwWTWcqBhWG.exe (Dyre)
  • C:\Users\username\AppData\Local\ne9bzef6m8.dll
  • C:\Users\username\AppData\Local\Temp\~TP95D5.tmp (encrypted or otherwise obfuscated)
  • C:\Users\username\AppData\Local\Temp\Jinhoteb.exe (where Upatre copied itself after it was run)

Some Windows registry changes for persistence:

  • Key name: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • Key name: HKEY_USERS\S-1-5-21-52162474-342682794-3533990878-1000\Software\Microsoft\Windows\CurrentVersion\Run
  • Value name: GoogleUpdate
  • Value type: REG_SZ
  • Value data: C:\Users\username\AppData\Local\PwTwUwWTWcqBhWG.exe

A pcap of the infection traffic is available at:

A zip file of the associated Upatre/Dyre malware is available at:

The zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

Final words

This was yet another wave of Upatre/Dyre malspam.  No real surprises, but it's always interesting to note the small changes from these campaigns.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://isc.sans.edu/diary/UpatreDyre+the+daily+grind+of+botnetbased+malspam/19657
[2] https://major.io/icanhazip-com-faq

Keywords:
5 comment(s)
Diary Archives