Archive for May, 2019

Retrieving Second Stage Payload with Ncat, (Fri, May 31st)

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 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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Analyzing First Stage Shellcode, (Thu, May 30th)

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

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

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 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 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

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 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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Behavioural Malware Analysis with Microsoft ASA, (Wed, May 29th)

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:UsersREMAppDataRoamingbrbconfig.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].


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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Office Document & BASE64? PowerShell!, (Tue, May 28th)

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 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

That can also do the decoding:

You can find the reader’s analysis here.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»