Last Updated: 2015-05-20 19:03:17 UTC
by Brad Duncan (Version: 1)
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."  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..." 
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
ISC Handler and Security Researcher at Rackspace
Last Updated: 2015-05-20 02:47:20 UTC
by Brad Duncan (Version: 1)
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): firstname.lastname@example.org
- 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 . 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 - 18.104.22.168 port 80 - icanhazip.com - GET /
- 2015-05-19 15:16:13 UTC - 22.214.171.124 port 13410 - SYN packet to server, no response
- 2015-05-19 15:16:16 UTC - 126.96.36.199 port 443 - two SYN packets to server, no response
- 2015-05-19 15:16:58 UTC - 188.8.131.52 port 443 - two SYN packets to server, no response
- 2015-05-19 15:17:40 UTC - 184.108.40.206 port 443 - SSL traffic - approx 510 KB sent from server to infected host
- 2015-05-19 15:17:56 UTC - 220.127.116.11 port 3478 - UDP STUN traffic to: stun.sipgate.net
- 2015-05-19 15:17:58 UTC - 18.104.22.168 port 443 - SSL traffic - approx 256 KB sent from server to infected host
- 2015-05-19 15:18:40 UTC - 22.214.171.124 port 13409 - SYN packet to server, no response
In my last post about Upatre/Dyre, we saw Upatre-style HTTP GET requests to 126.96.36.199 but no HTTP response from the server . That's been the case for quite some time now. However, in this example, the infected host attempted a TCP connection to 188.8.131.52, but the connection was reset after the initial SYN packet, and an HTTP GET request was never sent.
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 . 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\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 email@example.com and ask.
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.