This week, the CERT.eu 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 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 OfficerootOffice16>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 OfficerootOffice16>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:
Tip: Those directories are hidden!
From a network evidence point of view, the HTTP request is performed with a specific User-Agent:
- - [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 OfficerootOffice16>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.
Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.