This week, the CERT.eu[1] organized its yearly conference in Brussels. Across many interesting presentations, one of them covered what they called the "cat’n’mouse" game that Blue and Red teams are playing continuously. When the Blue team has detected an attack technique, they write a rule or implement a new control to detect or block it. Then, the Red team has to find an alternative attack path, and so one… A classic example is the detection of malicious via parent/child process relations. It’s quite common to implement the following simple rule (in Sigma[2] format):

logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage:
      - '*\WINWORD.EXE'
      - '*\EXCEL.EXE'
      - '*\POWERPNT.exe'
      - '*\MSPUB.exe'
      - '*\VISIO.exe'
      - '*\OUTLOOK.EXE'
    Image:
      - ‘*\powershell.exe'
    condition: selection
fields:
  - CommandLine
  - ParentCommandLine
falsepositives:
  - unknown
level: high

How to read this rule: Generate an alert when a process 'powershell.exe' is launched and its parent process is a Microsoft Office tool. To bypass this, the Red team or attackers now can use an alternative path:

Office > WMI > Powershell

Microsoft tools are wonderful because they can be used in many alternative ways and diverted from their main use. Example, to pause a script for 10”, use the ping command:

C:\ISC\> ping -n 10 127.0.0.1 >NUL:

Much better than using a sleep() function in a malicious script that could trigger a sandbox alert.

How to become “stealthier” (from a network point of view!) when you need to download files from the wild Internet? How to grab files when you don't have access to a regular browser? Most of the Microsoft tools accept URLs as file names.

Let’s load a text file via Excel. It accepts filenames as argument and filenames can be URLs:

C:\Program Files (x86)\Microsoft Office\root\Office16>excel.exe https://blog.rootshell.be/robots.txt

All text files are directly loaded into Excel cells (1 line = 1 cell):

It is also possible to download binary files :

C:\Program Files (x86)\Microsoft Office\root\Office16>excel.exe https://blog.rootshell.be/wp-content/uploads/2015/12/isc.jpg

When the binary file is loaded in Excel, you can't “see” it:

But the good news, a copy of the file is saved locally in the following directory:

%USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache\IE\...

Tip: Those directories are hidden!

From a network evidence point of view, the HTTP request is performed with a specific User-Agent:

<redacted> - - [07/Nov/2019:16:40:38 +0100] “GET /wp-content/uploads/2015/12/isc.jpg HTTP/1.1" 200 5031 "-" "Microsoft Office Excel 2014”

If you try to fetch a more sensitive file like a PE file, you will get a warning from Excel:

C:\Program Files (x86)\Microsoft Office\root\Office16>excel.exe https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe

But the file will be downloaded anyway and available in the same directory!

No magic behind this, all Microsoft apps are compatible with HTTP objects and can GET/PUT/POST data. It's not bullet-proof and can be easily detected but, as I said above, it means more work for the Blue team that needs to track this behavior. It's an easy way to bypass a light AppLocker setup that would prevent users to execute a browser on a sensitive workstation.

[1] https://cert.europa.eu
[2] https://github.com/Neo23x0/sigma

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