You are browsing the archive for Incident Response.

Running programs via Proxy & jumping on a EDR-bypass trampoline

May 1, 2017 in Anti-*, EDR, Incident Response

The parent-child process relationship is very helpful when it comes to defining detection rules and watchlists. For instance, anytime a winword.exe spawns a cmd.exe, powershell.exe, cscript.exe, wscript.exe, mshta.exe it is an obvious anomaly that may be a sign of an Office macro-based infection.

However, insert an unexpected process in-between and the rule/watchlist fails. Perhaps for this reason, it would be nice to have EDR rulesets that can refer not only to parents, but also to ancestors of the process.

Since this relationship is prone to manipulation let’s  have a look at a couple of possible examples:

  • rundll32 url.dll, OpenURL file://c:\windows\system32\calc.exe
  • rundll32 url.dll, OpenURLA file://c:\windows\system32\calc.exe
  • rundll32 url.dll, FileProtocolHandler calc.exe
  • rundll32 zipfldr.dll, RouteTheCall calc.exe

Running any of these commands will launch calc.exe with the rundll32.exe as a parent.

Obviously, rundll32.exe is an obvious  bad guy too. What about we copy it first?

copy c:\windows\system32\rundll32.exe %appdata%\Adobe\adobe.exe

Now, we can launch:

  • %appdata%\adobe\adobe.exe url.dll, OpenURL file://c:\windows\system32\calc.exe
  • %appdata%\adobe\adobe.exe url.dll, OpenURLA file://c:\windows\system32\calc.exe
  • %appdata%\adobe\adobe.exe url.dll, FileProtocolHandler calc.exe
  • %appdata%\adobe\adobe.exe zipfldr.dll, RouteTheCall calc.exe

And get the very same result, this time, with the parent process being adobe.exe.

If you know any other EXE/DLL combo that can act as a proxy, I’d be grateful if you could let me know. Thanks!

Beyond good ol’ Run key, Part 62

April 19, 2017 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

Update

This is not an RCE. If it was, I would not publish it on this blog 🙂

Turns out “Simpsons already did it” and as pointed out by @arekfurt a normal template-based persistence is already implemented in EmpireProject and is based on awesome work of @enigma0x3. Interestingly, enabling macros is not needed to deliver the same functionality (as explained below).

Dropping any macro sheet inside the XLSTART folder and opening it from there will not show the macro warning 🙂

Old Post

Every once in a while we come across weird things that we not only discover accidentally, but are finding hard to understand. Today I was playing around with Word Macros and to my surprise I was able to accidentally run one, while my Macro Options were set to Disable all macros with notification.

Intrigued, I quickly realized that instead of adding it to a test word document, I accidentally added it to the normal template file.

Could it be… ?

I rushed to add the AutoOpen macro to the normal template that will launch the Calculator anytime the template is used:

Now I only needed to open some word document…

How nice!

Interestingly, the Security Warning appears ONLY after I visit options while the document is open.

Swap calculator with anything else, and a new stealth persistence mechanism is born…

Now, what about Excel?

Excel doesn’t have the Normal template equivalent by default, but you can add one. To do so, you just need to record any macro named Auto_Open and store it inside a personal template (by choosing ‘Store macro in Personal Macro Workbook‘):

(alternatively, you can create a personal template directly on the system by placing a prepared XLSB file in a following location: c:\Users\<USER>\AppData\Roaming\Microsoft\Excel\XLSTART\PERSONAL.XLSB)

Then switch to the macro editor, and write the code as below:

This will ensure the Calculator will be executed anytime someone opens Excel, even if the macros are *cough* *cough* disabled…