Blog

Archive for December 2nd, 2019

Ursnif infection with Dridex, (Tue, Dec 3rd)

Introduction

I frequently see indicators of malicious spam (malspam) pushing Ursnif malware.  Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host.  The password has usually been 777 for the zip attachments.  Word documents contained within those zip archives follow a specific naming convention.  For example, a Word document from this campaign on December 2nd would be named info_12_02.doc.

Today’s diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd.

The malspam and initial infection

Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild.  Since these are possibly real people, I’ve redacted any sensitive information in the images below.  As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host.  In this case, enabling macros on the Word document dropped a script file in the C:WindowsTemp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.


Shown above:  An example of malspam pushing Ursnif malware.


Shown above:  Opening a zip archive from this type of malspam requires a password stated in the email.


Shown above:  Microsoft Word document extracted from the attached zip archive.


Shown above:  Malware note on the infected Windows host after enabling macros.

The infection traffic

Traffic generated by Ursnif infections follows relatively consistent patterns.  During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host.  In this case, it was Dridex.  The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.


Shown above:  Traffic from an infection filtered in Wireshark, highlighting the URL that returned the initial Ursnif EXE.


Shown above:  Later in the infection traffic, we see indicators of the victim host being infected with Dridex.

Post-infection forensics

Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE.  Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process.  Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.


Shown above:  Ursnif persistent on my infected Windows host.


Shown above:  Dridex persistent as DLL file called by the Windows registry.


Shown above:  Dridex was also persistent through a DLL file called by a scheduled task.


Shown above:  Dridex also persistent as a DLL called by a Windows shortcut in the Startup folder.

Indicators of Compromise (IoCs)

URL that retrieved initial Windows executable file for Ursnif:

  • 188.120.241[.]200 port 80 – ragenommad[.]com – GET /edgron/siloft.php?l=utowen4.cab

URLs generated by initial Windows executable file for Ursnif:

  • 23.202.231[.]167 port 80 – nxbpierrecjf[.]com – GET /images/[long string].avi
  • 23.202.231[.]167 port 80 – spt71igina[.]com – GET /images/[long string].avi
  • 109.196.164[.]8 port 80 – jyomacktom[.]top – GET /images/[long string].avi

Post-infection traffic after Ursnif has established persistence:

  • 194.61.1[.]178 port 443 – m38kxy54t[.]com – HTTPS/SSL/TLS traffic generated by Ursnif

URLs generated by Ursnif-infected host to obtain follow-up malware:

  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/2unovarios.rar
  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/unovarios.rar

Post-infection traffic caused by Dridex:

  • 5.134.119[.]57 port 443 – HTTPS/SSL/TLS traffic generated by Dridex
  • 89.100.104[.]62 port 3443 – HTTPS/SSL/TLS traffic generated by Dridex

Malware and artifacts

SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5

  • File size: 57,450 bytes
  • File name: [name redacted].zip
  • File description: password-protected zip archive from malspam (password: 777)

SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd

  • File size: 63,466 bytes
  • File name: info_12_02.doc
  • File description: Word doc with macro for Ursnif

SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88

  • File size: 238,080 bytes
  • File location: hxxp://ragenommad[.]com/edgron/siloft.php?l=utowen4.cab
  • File location: C:WindowsTempainJ45.exe
  • File description: Initial Ursnif EXE retrieved after enabling Word macro

SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f

  • File size: 495,616 bytes
  • File location: C:Windowssystem3241ftQHUxTheme.dll
  • File description: Dridex DLL persistent on the infected Windows host (1 of 3)

SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72

  • File size: 499,712 bytes
  • File location: C:Users[username]AppDataRoamingJC85wnMFPlat.DLL
  • File description: Dridex DLL persistent on the infected Windows host (2 of 3)

SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a

  • File size: 491,520 bytes
  • File location: C:Users[username]AppDataRoamingL3CfQGVERSION.dll
  • File description: Dridex DLL persistent on the infected Windows host (3 of 3)

Final words

A pcap of the infection traffic and the associate malware can be found here.


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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Next up, what's up with TCP port 26?, (Mon, Dec 2nd)

Whenever I sign up for another shift, if I don’t already have a diary topic in mind, I take a look at the top 10 ports in the dashboard when I login to isc.sans.edu. For the last few weeks, I’ve noticed %%port:26%% showing up, so I decided to see if I could figure out what was going on there.

In this case much of the top 10 is stuff to be expected, port 445 is perpetually near or at the top of this chart (please don’t leave it open to the internet), port 23 has been there since Mirai first hit more than 3 years ago, 80 and 8080 are web servers and proxies, port 22 (ssh) is not at all unusual, port 5555 is the Android Debug Bridge which has been popular for a few months, but that port 26 just is really strange and it is sitting at number 5. So, let’s take a look at the last year of port 26 traffic and see what we can see.

Okay, with the exception of a brief spike in targets last January, there was hardly any traffic on port 26 until September and even then, the number of sources was very small until about the second week of November. So what are they looking for? Well, there is no service officially assigned that port by IANA, so my next thought was to take a look at Shodan and see, what tends to be running there. A quick look there suggests that port 26 is most often used as an alternate SMTP port.

Okay, I suppose there might be reasons for that, you often find web servers running on port 81, so why not SMTP on port 26? In fact, most often it is Exim which has had a couple of vulnerabilities lately. Most recently, a remote code execution vulnerability in September. So, maybe the attackers are looking for vulnerable Exim servers. Now that I have an hypothesis, it is time to test it. A few weeks ago, when I noticed the increase in traffic on %%port:853%%, I wasn’t able to setup a honeypot before my shift to try to capture some of the traffic, but this time, since I actually noticed this several weeks ago and signed up for the shift last week, I figured I should actually capture some of the traffic to test my hypothesis. I decided to try out fellow handler, Didier Steven’s tcp-honeypot (something I’ve been meaning to play with for months). So, I set it up on a couple of VPSen that I have scattered around and… things didn’t work. So, I talked to Didier and discovered that despite the comments in the code to the contrary, the version currently in github (as of 30 Dec 2019 anyway) did not, in fact, work with Python 3. Oops, he’ll get that straightened out shortly. Fortunately, it worked with Python 2 (>= 2.7.12, anyway, didn’t seem to work with 2.7.8). Okay, that allowed me to fire up several honeypots scattered around where I figured they would get scanned. I copied the config for port 25 and modified it to send back the Exim banners that I saw on Shodan, like these 

And… I didn’t get (much) SMTP scanning. In fact, I got exactly 1 SMTP probe, 2 SSH probes (from the connection string, it looks like python scripts using paramiko) and lots and lots of apparent telnet connections (IPs obscured to protect the guilty).

I’m not sure what this tells us. There must be some devices out there that are running telnet (or similar) on port 26 because there is a whole lot of scanning and brute force password guessing going on there, but apparently it isn’t attempting to take advantage of and Exim RCE vulnerabilities. If any of our dear readers know what they are actually looking for, I’d love to hear about it, you can let us know in the comments below, via e-mail, or via our contact page, Now that I see it is apparently telnet, I’m very tempted to put up a cowrie instance and see what they do once they get in, but I’ll save that for a weekend where I don’t have other stuff going on.

—————
Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →