The SolarWinds exploits have been widely reported, fully covered, and basically as we would say in Aussie – Done to Death Mate.

But some of the info got me thinking, especially this article from my buddies at Microsoft which gives some great background and flows for that how the attacks were actually working.

I’ve been working with Ivanti Application Control – formerly AppSense Application Manager for over 17 years. I luv it 😊

I’ve installed it in hundreds and hundreds and hundreds of Customer sites and trained hundreds of people on its use.

Even then, some new use cases come up, and some if its features lend themselves to protecting against new and old styles of attacks, as the world and our hackers evolve.

How did the Attack work, What can we do?

So, let me give you my spin on what the attack style and steps mean to me, through the lens of someone who helps customers with Ivanti Application Control (AC).

  1. Trusted Applications can still do bad stuff. Yes, I know it may be hard to believe and hard to stomach, but trusted applications can be hacked. Exhibit A is of course the SolarWinds attack. We know that the process SolarWinds.BusinessLayerHost.exe downloaded a compromised dll, which then created a couple of files on the disk. After some jiggery, pokery in the registry, script files were then kicked off by dllhost.exe – a very valid system process. Rundll32.exe – another well trusted system process - was also roped in to go and run some of the dodgy files as part of the attack and cleanup.
  2. Tracing and Hunting is great, but prevention is even better. It’s great to have visibility, and capture traffic running around your network, and calls out to hacker sites, but my view has always been - I like to see security issues blocked at the source. Two philosophies in Security, fix it fast when it breaks, or stop it breaking in the first place. I am very firmly in the second camp there, let’s stop things first.
  3. Know what your Apps should and shouldn’t be doing.   Do Trusted Applications really need to be executing batch files and VB or PowerShell scripts? Under what circumstances should that be allowed. A little testing and planning will give you visibility, and from there you can make some informed decisions, and take some protective steps.

3 Ways Ivanti Application Control can Help.

Given all that info above, here’s 3 areas of Ivanti Application Control configuration that can help you protect yourself against compromised TRUSTED applications – DISCLAIMER – PLEASE TEST ANY OF THESE RULES FIRST IN AUDIT ONLY MODE IN YOUR ENVIRONMENT BEFORE DEPLOYING:

  1. Remove SYSTEM as a Trusted Owner. Out of the box, SYSTEM is added as a Trusted Owner. Now that might seem logical, and you might even think that is a 100% no brainer requirement – not so fast Mate. I remember back when I was doing my GCIH certification training    with SANS, and we were using Metasploit to attack a Windows Spooler service and drop a copy of netcat.exe on a server, the context of the service we were attacking was SYSTEM. Which meant, when the file hit the disk, it was owned by SYSTEM. Removing SYSTEM from the AC config would block the execution of any file copied to the disk as part of a compromised service. The Instructor was very impressed!
  2. Add Microsoft Recommended Blocks. Now his one is mandatory for level 2 and 3 Maturity levels for the ASCS Essential 8 “Application Control’. The listed applications are ones that have security implications or are just downright dangerous. The current list can be found here. One I wasn’t initially aware of was good old BGInfo.exe (prior to version 4.22), until a Customer asked me about it and I then realised it could be used to run VB scripts and bypass the built in Windows VB compiler. We found that by blocking the relevant dll’s you could stop the VBScript backdoor, but as it was on the Blocked App list, it’s safer to just block it. BGInfo version 4.22 fixed this issue so you could use that version if you really need to.
  3. Process Rules are your Friend. Yes, one of my favourite functions in Ivanti Application Control is the ability to run Process Rules. So, with these, you would lock down the .exe with metadata, or even in some cases a signature, and then create a rule allowing that exe to either run or be blocked from calling additional components. So you could say – I trust the exe, so let it run .dll’s, BUT there is never any circumstance where it should run a .bat, .vbs, or .PS1 file so block those, and throw in blocking Powershell.exe while you’re at it. This could even be implemented across the platform as a blanket rule, and only allowed on a “Need to Run” basis.

Implementing the above rules will stop attacks like the SolarWinds one in its tracks.

SYSTEM processes will not be able to create their own files and execute them, any dangerous system tools listed on the MS Recommended Blocks will be denied, and valuable system process like dllhost.exe and Rundll32.exe can be locked down to stop them kicking off batch files, VB or PowerShell scripts.

Thanks for tuning in.

I’m one of those Weird People who “Eat their own Dog Food” or “Drink their own Champagne” so I have all these rules on my laptop 😊

It runs fully locked down Application Control and I only ever log on as a standard user. Our Privilege Management functionality elevates the things I need to do my job at Ivanti and protects me against any credentials compromise.

I hope that helps give you a bit on an insight into where Ivanti Application Control might help, and if you have any questions please feel free to reach out to me.

Thanks for tuning in and to be clear, Solarwinds is not affiliated with Ivanti and does not support or endorse Ivanti, Ivanti IAC, or any other Ivanti solutions.