Beyond Fear

December 22, 2020 in Preaching

In his book Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Bruce Schneier tells us that:

a) 9/11 was a evilish, but brilliant plan,
b) risk assessment is hard, but most importantly,
c) У страха глаза велики (Fear Has Big Eyes).

SolarWinds hack is a evil genius, and even if the fallout is going to last for months we do need to pause to contemplate the technical capability involved. If you follow me on Twitter or read my stuff here, you know that I absolutely detest the word capability. It is a buzzword of people who don’t understand technology, and anti-buzzword for people like me – who are civilians, never served and can’t think in strategic, military terms, but are at least bad programmers.

The capability is not coding per se, of course. It is not even staying under radar of security solutions for a few months, or even for more than a year. The real capability is making the backdoor code seamlessly integrated with a code base so that it can be compiled with no errors, and/or compiling your own version of the binary and swapping it at a right time so that it can be signed by the building environment.

The finesse of this maneuver cannot be understated / overlooked.

Now… malicious modification of a source code is actually not that uncommon and not that hard to pull off. Every web site defacement of the past included changing some source files (HTML /ok, not code, but always/, PHP, ASP, etc.). Many e-commerce hacks, especially within PCI space include some sort of modification of the web site’s source code (e.g. add event handler to form submission events to steal credit card details, etc.). Zeus and other infostealers’ injects were genius too.

BUT

Somehow, code modification of the standalone, non-web site component, that is, a source code that is compiled into a binary executable is much harder. You know that if you ever tried to compile a source code taken from github or Code Project. So many things can go wrong. I have yet to encounter a source code that compiles on my box w/o any error from a compiler. To make FaaS work it took me good 3 days of troubleshooting.

This brings me back to capability. The surgical operation that (according to what is known) relies on a code injection into a pretty large software source code live branch – source code that changes constantly and is very dynamic in nature, is the skill and tradecraft one has to respect. Is it on the same level as Stuxnet? Definitely not, but it is way above your average red team pay grade.

People coding botnets, rogue anti-spyware, bank infostealers are good malware programmers. People developing 0days and injecting source code into live code branches are very good malware programmers. There is just a few in the world that can really offer this capability. It’s sad, because they will never be able to travel, live in other places, and enjoy any sort of freedom we average people enjoy.

Kowtow and RIP – you will be pwned one day.

Propagate, Ribbonate

December 22, 2020 in Anti-Forensics, Code Injection, Forensic Analysis, Malware Analysis

I thought Propagate technique is a dead horse. Described, implemented, used in malware.

But.

There is perhaps one more possibility, or four.

When you open Windows Explorer and Ribbons are enabled:

the UIRibbon.dll DLL gets loaded into this process address space:

One of the things the DLL does is setting properties of its internal windows using the following methods:

  • HWndContainer::Build(HWND hWnd, char a2, struct HWndContainer **a3)
    • Property:0xA91C
  • OfficeSpace::Root::SetEventLogger(OfficeSpace::Root *this, struct IUIEventLogger *a2)
    • Property: 0xBCDE
  • NetUI::SetCommandManager(HWND hWnd, HWND hData, struct NetUI::ICommandManager *a3)
    • Property:0xBCDF
  • UXHwndEffectsManager::FInitialize@(HANDLE hData@, HWND hWnd@, bool a3, bool a4, bool a5)
    • Property (atom name): SCENIC_UXHWNDEFFECTSMANAGER_WINDOW_PROP

Example:

So, what do we do with this?

These are all possible targets for a Propagate code injection as all these properties appear to be holding virtual table pointers…