Threat Level: green Handler on Duty: Renato Marinho

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


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

Obfuscated DNS Queries

Published: 2021-01-15
Last Updated: 2021-01-16 17:35:00 UTC
by Guy Bruneau (Version: 1)
0 comment(s)

This week I started seeing some URL with /dns-query?dns in my honeypot[1][2]. The queries obviously did not look like a standard DNS queries, this got me curious and then proceeded to investigate to determine what these DNS query were trying to resolve.

But before proceeding, I have logs going back to May 2018 and reviewed the logs to see when this activity was first captured. The first time the honeypot logged something similar was in February 2020 with one long query that was different to all other queries. All the logs are targeting TCP/443 and are unencrypted.

Using base64 URL safe option in CyberChef, I was able to decode the DNS information for the 3 different queries. The first query captured in February 2020 appears to be a test (see decoded information below). The other two resolve to a URL: one as a test (www.example[.]com) and the other to Baidu search engine (www.baidu[.]com).

Sample Logs

  • tcp-honeypot-20200212-195552.log:20200226-230039: 192.168.25.9:443-54.153.67.242:59822 data 'GET /dns-query?dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.30.102.198:443\r\nConnection: close\r\nAccept-Encoding: gzip\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36\r\n\r\n'
  • tcp-honeypot-20200413-081332.log:20200413-171212: 192.168.25.9:443-195.37.190.77:40634 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1\r\nHost: XX.30.102.198\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

[...]

  • 20210112-110540: 192.168.25.9:443-39.96.138.251:60736 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'
  • 20210113-040125: 192.168.25.9:443-161.117.239.46:49778 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

Base64 Decoded Queries

  • AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ .............a>62characterlabel-makes-base64url-distinct-from-standard-base64.example.com.....
  • AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ   .............www.baidu.com.....
  • AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB .............www.example.com.....

DNS Queries by Base64 String

  • IP Activity resolving to www.example[.]com has been active since April 2020 with 2 packets per month.
  • User-Agent → Mozilla/5.0 (compatible; DNSResearchBot/2.1; +http://195.37.190.77)

195.37.190[.]77

====================

  • IP Activity resolving to www.baidu[.]com only started in December 2020 and has been active since then.
  • User-Agent → Go-http-client/1.1

39.96.138[.]251
39.96.139[.]173
39.96.139[.]223
39.96.140[.]32
47.74.84[.]52
47.241.66[.]187
54.153.67[.]242

====================

  • IP Activity resolving to 62characterlabel-makes-base64url-distinct-from-standard-base64.example.com only seen once in February 2020 which appears to be only a test.
  • Something interesting, 62characterlabel-makes-base64url-distinct-from-standard-base64 is equal to 62 characters
  • User-Agent → Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

161.117.239[.]46

====================

Do you have similar obfuscated DNS queries in your logs? Please use our comment form to share them.

Update 1: @DissectMalware pointed out these queries are DNS Queries over HTTPS (DoH) matching RFC 8484

[1] https://github.com/DidierStevens/Beta/blob/master/tcp-honeypot.py
[2] https://www.inetsim.org/documentation.html
[3] https://gchq.github.io/CyberChef/
[4] https://tools.ietf.org/html/rfc8484
[5] https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF
[6] https://isc.sans.edu/forums/diary/Is+it+Possible+to+Identify+DNS+over+HTTPs+Without+Decrypting+TLS/25616/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

0 comment(s)

Throwback Friday: An Example of Rig Exploit Kit

Published: 2021-01-15
Last Updated: 2021-01-15 03:18:01 UTC
by Brad Duncan (Version: 1)
0 comment(s)

Introduction

As this week winds down, I wanted to highlight a threat that's significantly diminished in recent years.  For today's #ThrowbackFriday, I'm reviewing an example of Rig exploit kit (EK) generated yesterday on Thursday 2021-01-14.

History of Rig EK

EKs are a malware distribution method.  They're channels to send malware to vulnerable Windows hosts.  An EK's payload is Windows-based malware.

Rig EK was discovered in 2014, back when EKs were much more common than today.  Like other EKs in 2014, Rig exploited Internet Explorer (IE) and browser-based applications that worked with IE like Java, Flash, and Silverlight.  Since then, people have increasingly moved to other browsers like FireFox and Chrome.  Because of this, EK activity began to decline.

Windows 10 was introduced in 2015 with Microsoft Edge as its default browser.  As more people switched to Windows 10, some EKs disappeared.  Rig EK continued to decline, with a substantial drop in 2017.  By 2018, Rig EK was one of only a few remaining EKs.  Today, people still discover examples of Rig EK, but it's only effective against out-of-date hosts running Windows 7 and using IE.

To prepare for throwback Friday, I fired up a vulnerable Windows 7 host, opened IE 11, and entered a URL that led to Rig EK.

Gate to Rig EK

An HTTPS gate that leads to Rig EK has been active since December 2020:

  • hxxps://anklexit[.]online/twDGMjtfsacfa3e

On 2020-12-24, @nao_sec tweeted an example of Rig EK pushing SmokeLoader that contained the above URL.  Earlier this month, Rig EK from the same gate pushed Dridex.

URLs like this act as a gate to an EK.  This gate wouldn't direct me to Rig EK when I tried it through a VPN.  However, tethering through my phone worked.  These gates are somewhat picky.  Use the gate once, and it might work.  But try it again from the same IP address, and it prevents you from reaching the EK again.  You generally have to wait 12 to 24 hours before the gate will work again, if you're coming from the same IP address.

Traffic from an infection

See the below images for traffic from the infection.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Rig EK landing page shown in an HTTP stream.


Shown above:  Dridex installer EXE sent by Rig EK as an encrypted binary.


Shown above:  Certificate issuer data for HTTPS traffic generated by Dridex installer.

To get a better understanding of Dridex infection traffic, see this Wireshark tutorial I wrote about it last year.

Forensics on an infected Windows host

While the Rig EK payload (an EXE to install Dridex) generated HTTPS command and control (C2) traffic, it wasn't able to install Dridex on the victim host.  So I only saw the Dridex installer EXE.  I also captured a small file (approx 1 kB) of JavaScript text used by Rig EK before it was deleted during the infection process.


Shown above:  Artifacts from the infection caused by Rig EK.

Indicators of Compromise (IOCs)

The following are indicators from this infection.

Traffic from an infected Windows host:

  • 188.225.75[.]54 port 443 - anklexit[.]online - HTTPS URL - gate to Rig EK
  • 188.227.106[.]164 port 80 - 188.227.106[.]164 - Rig EK
  • 162.241.44[.]26 port 9443 - HTTPS traffic caused by Dridex installer
  • 185.184.25[.]234 port 4664 - attempted TCP connection caused by Dridex installer
  • 138.201.138[.]91 port 3389 - attempted TCP connection caused by Dridex installer

Certificate issuer data from Dridex HTTPS traffic to 162.241.44[.]26 over TCP port 9443:

  • id-at-countryName=DS
  • id-at-stateOrProvinceName=Tholend finck4
  • id-at-localityName=Khartoum
  • id-at-organizationName=Antymasu PEEC
  • id-at-commonName=anompatof.rip

Malware/artifacts from the infected Windows 7 host:

SHA256 hash: 209093c71d0e87df00a290c588a5147e1e14023402f317d7903c6402d52a87ee

  • File size: 98,819 bytes
  • File location: hxxp://188.227.106[.]164/?MzA1NTIz&pwDDc&AcAZl=pinny.866&shghfg[long string]
  • File description: HTML for Rig EK landing page

SHA256 hash: f14c7ba0240be3456164dd63f53dd4bc7eb34bcdb1ac26e98a623edc0390b56b

  • File size: 1,152 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\3.tMp
  • File description: JavaScript text file dropped by Rig EK

SHA256 hash: 0376f97c21d2f00bc9c0919ce108ef14a2b3b1b356b2caa502a6cae81c7798f2

  • File size: 1,198,592 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\jv9qx.exe
  • File description: Rig EK payload, Windows EXE to install Dridex malware

Final Words

Pcap and malware/artifacts for this diary can be found here.

I wonder how it long this method of malware distribution will remain profitable.  Apparently, enough people currently use out-of-date vulnerable Windows hosts.  I guess this presents a big enough target base for the people behind Rig EK.

Every time I find Rig EK, I think back to all the entries I posted on my blog from 2013 through 2016 featuring Rig and other EK infections.  That's why I consider today's diary a #ThrowbackFriday.

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

0 comment(s)
Diary Archives