Archive for January 18th, 2021

Gordon for fast cyber reputation checks, (Tue, Jan 19th)

Gordon quickly provides threat & risk information about observables

Gordon is a great website for security analysis and threat intelligence practitioners courtesy of Marc-Henry Geay of France.
It’s a fine offering that quickly provides threat and risk information about observables such as IPv4 addresses, URLs, Domains/FQDNs, MD5, SHA-1, SHA-256 hashes, or email addresses.

All aspirations and architecture for Gordon are available in Marc-Henry’s Medium post, as well as his About content.
You really need only know the following in any detail:

  • Gordon submits your observables (IOCs) to multiple sources (30+ engines) to ensure good coverage.
  • Observables are only searched in open security databases’ existing records (passive).
  • Results can be viewed and shared for up to 3 days, thereafter they are deleted, Marc-Henry has EU privacy regulations to contend with.
  • Results are available as Summary Reports with risk-based coloration for some engines, and can be exported as PDF, CSV, and XLSX.

I gave Gordon a quick test using IPv4 IOCs from the Cisco Talos Threat Advisory: SolarWinds supply chain attack. Gordon limits you to 15 observables at most, and note that it favors non-Microsoft browsers, so I experimented via Firefox. Using ten IP IOCs, separated one per line, I received swift results as seen in Figure 1.


Figure 1: Gordon IPv4 SUNBURST results

As noted, Figure 1: shows IPvs SUNBURST IOC results that are precise and color coded by risk.
Using ten SHA-256 hashes from the Talos report for my next query I opted to export the results as an Excel document, then sorted by malicious results only.


Figure 2: Gordon SHA-256 query results

Again, the SUNBURST SHA-256 IOC results are robust and detailed. I’ve certainly added Gordon to my favorites list and suggest you consider doing the same.

Cheers…until next time.

(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) →

Doc & RTF Malicious Document, (Mon, Jan 18th)

A reader pointed us to a malicious Word document.

First, I run my command on it, with option -a to get statistics (see my diary entry “Strings 2021“).

There aren’t any long strings in this file (the longest is 33 characters). So there isn’t a payload here that we can extract directly, like we did in diary entry “Maldoc Strings Analysis“.

Let’s check if there are URLs in this file, by grepping for http:

Unfortunately, none.

Let’s take a look at the longest strings (-n 20: strings at least 20 characters long):

If you are a bit familiar with the internals of Word documents, you might recognize this as the name of XML files found inside OOXML files (.docx, .docm, .xlsx, …).

Let’s try

This means that there are no OLE files inside this OOXML file, hence no VBA macros.

Since an OOXML is an OPC file, e.g. a ZIP container, let’s take a look with my tool

It looks like this OOXML file only contains XML files (extensions .xml and .rels). Let’s verify by getting statistics of the content of the contained files, by using option -e:

Here is a close look on the statisctics:

All contained files starts with = 127).

So we have no binary files in here, just text files. One possible scenario, is that this .docx file contains a reference (URL) to a malicious payload.

Next step, is to extract all files and search for URLs in them. Now, in Office OOXML files, you will find a lot of legitimate URLs. To get an idea of what type of URLs we have in this document, we use my tool to extract URLs, and display a unique list of hostnames found in these URLS, like this:

The following hostnames are legitimate, and found in Office OOXML files:

But the IP address is not. So let’s extract the full URLs now, and grep for 104:

I downloaded this document. Let’s start again with strings:

4555 characters long: this might be a payload. Let’s take a look:

This looks like a lot of hexadecimal data. That’s interesting. And notice the 3 curly braces at the end. Hexadecimal data and curly braces: this might be a malicious RTF document. Let’s check with the file command (I use my tool on Windows):

This is indeed an RTF file. RTF files can not contain VBA code. If they are malicious, they often contain an exploit, stored as (obfuscated) hexadecimal characters inside the RTF file. Hence the strings command will not be of much use.

I recently updated my tool to make analysis of embedded objects (like malicious payloads) easier. We use the new option -O to get an overview of all objects found inside this RTF file:

There’s one object with name equation… . It’s very likely that this is an exploit for the equation editor, and that we have to extract and analyze shellcode.

Let’s extract this payload and write it to a file:

Let’s see if there are some intesting strings:

Nothing interesting.

The equation editor that is targeted here, only exists as a 32-bit executable. Hence the shellcode must also be 32-bit, and we can use the shellcode emulator scdbg to help us.

We use option -f findsc to let scdbg search for entrypoints, option -r to produce a report, and -f shellcode to pass the shellcode file for analysis:

The shellcode emulator found 4 entry points (numbered 0 to 3). I select entry point 0. This results in the emulation of shellcode, that calls the Win32 API (GetProcAddress, …). This is clearly 32-bit Windows shellcode. And it decodes itself into memory. We can use option -d to dump the decoded shellcode:

This creates a file: shellcode.unpack. Let’s use strings again on this file:

This looks more promising. What are the longest strings:

And finally, we have our URL.




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