The cyberpoppers, the security fix, and … the Other guys

May 10, 2017 in Preaching

Cyberpopping is a term I coined for the lack of a better word to describe any vague and most of the time responsibility-free activity that is either used and/or abused to sell and market IT security in whatever form and shape possible. Yup, the activity where the seller is not being necessarily responsible for overseeing that security to the remediation/closure/assurance phase.

We all practice it.

There are various cyberpoppers out there:

  • 0days
  • APT
  • Dumps
  • Security Certificates
  • Security Conferences
  • Social media, including Twitter and blogs (including yours truly)
  • Periodical reports from vendors and Gartner
  • Compliance requirements (PCI DSS, ISO)
  • Groups, forums
  • etc.

At every step of this journey the ego and schadenfreude prevails. We all know better. And anytime we find something new and cool, the Champagne cork pops and we get the fix. I love it, you love it. We are one big family of security enfants terrible 🙂

As I get older though and get more and more insight into the less flashy part of the security world – one where the security is actually being implemented – it becomes more and more apparent to me that none of these things really help the Other guys. If you watched the movie you know who I am talking about. These poor creatures that sit in the backend offices, spend hours on the calls, actually talk to business people and clients, speak to non-technical people, and ensure the stuff that we are all breaking, or talk about breaking – is actually fixed. This is not a fun job, it’s error-prone, it ricochets when they screw up (it often costs big bucks!), it is long hours, and on-calls where the big decisions are made. I just want to take the moment today to say thank you to all engineers, admins, firewall guys, architects, customer-facing security guys, vulnerability management teams, and ISOs and any other guys who actually deal with the _real_ world aspects of IT security.

Copyright note: the pic adapted from the one posted on wikipedia

Comments Off on The cyberpoppers, the security fix, and … the Other guys

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!

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

← Previous Entries