Driverstore updates get blocked

Every now and than a bunch of blocking events drop in my mailbox, such as:

Event: execution_denied
File (Full Path): C:\windows\system32\drivers\awon4hcv.sys
Program (Full Path): System
Registry Key:
System Name: LAPTOP10
User: NT AUTHORITY\SYSTEM

I have tried to figure out what is causing this by looking in the windows event log. After all, I would think an application that tries to update my drivers would normally log an error if it fails to do so.... Guess what: no events besides the mcafee ones:

McAfee Solidifier prevented an attempt to modify file 'C:\windows\system32\driverstore\infstrng.dat' by process C:\Windows\System32\services.exe (Process Id: 564, User: NT AUTHORITY\SYSTEM).

Basically something has updated a driver and tries to store the information in de driverstore, I assume. A pitty though that I cannot figure out what is causing this driver update. I (once again) assume it is Windows Update, as I have just ran the .lnk emergency update that came from windows update yesterday. The update itself is allowed because Windows Update is trusted, however I think the procedures that come afterwards don't.

I might want to create an extra exception for this, or maybe simply make sure I do "sadmin bu" before I run the update.

In a corporate network you could implement a workflow to centrally schedule the "sadmin bu" when whatever Maintenance Window is planned.

Conclusion: using application control == implement maintenance windows

Ehh why did outlook.exe try to execute mtail.exe?

In ePO I have created an automatic response to send an email to me of every blocked execution. So I was scrolling through my email, which always contain some of those responses. Most of them are driver updates which seem to appear because of windows update, still figuring this out, but now I noticed the execution denial for mtail.exe.

Mtail.exe is a freeware tool to open a .log file and monitor it at realtime. I use it every now and than for troubleshooting, but never installed it on my laptop.

This was the body of the email:

Event: execution_denied
File (Full Path): \\server\c$\users\erik\desktop\mtail.exe
Program (Full Path): C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE
Registry Key:
System Name: LAPTOP
User: DOMAIN\Erik

So basically Application Control on my laptop blocked outlook.exe from executing mtail.exe somewhere on a server?!?!? Looks scary!

I remember I have attached something from my desktop which was stored on that server, so that I have opened that particular location from outlook is true, but i certainly did not run mtail.exe at that point. That is: not deliberately :)

I just tried to reproduce the execution and it does not occur when I try to add mtail.exe as an attachment to an email (neither by drag&dropping nor by inserting it through outlook toolbar). It really only gets blocked this way when I click to attach a file in outlook, than browse to that directory and than richt-click mtail.exe and choose to open instead of select. That obviously is not something I think I could have done accidently, so this behaviour still is pretty peculiar: still don't have an explanation to it... If you do: please reply :)

If any such events reoccurs i'll let you know!

Trusted Users

It appeared to me I earlier misunderstood the Trusted User policy option. I thought it allowed certain users to install new applications or run unknown executables, but it does not.

Instead, a Trusted User is allowed to unlock the CLI and enable the update mode, without having to type a password.

The command:
CLI > sadmin recover

Is to unlock Solidcore. Afterwards the update mode can be initiated by "sadmin bu" (shortcut for begin-update). "sadmin recover" prompts for a password that can be set in ePO. The password prompt is thus disabled for trusted users, so they can do "sadmin bu" at any time.

Hashtab is great

During the Webinar Joe spoke about Hashtab to easily calculate a files fingerprint. It is possible to allow a file based on it's checksum (SHA-1), but how to calculate it?

Install Hashtab, than right-click the required file, and click the tab "Hash Values". Right-click the Hash Value of SHA-1, an choose Copy. Now you can paste it into ePO while creating an allowed Binary, or do it locally through the CLI. Offcourse the fingerprint can also be used to blacklist a certain file.

sadmin auth -a -c 2F6D10AF4CA263B762BA5749827017D4

Webinar by Joe McMahon

Today Mr. Joe McMahon of McAfee presented a webinar for Medusoft's customers on SolidCore products, specifically about Application Control. We recorded it and it is available for download from Medusoft's website:

Webinar Application Control.

Heatwave

Yesterday I got so frustrated with my laptop! It was in my docking station at home and at one point it started to run at high CPU usage, like continuously 100%. I watched my task manager to find out there really wasn't one application causing this but several in turn. So I started to get worried this had something to do with Application Control, which from my point of view is basically keeping an eye on every application. So first I enabled the update mode CLI "sadmin bu" (shortcut for begin-update) with no result. Than I even disabled it alltogether, CLI "sadmin disable". This required a reboot after which high cpu usage started again, so no result as well.

I couldn't figure out what was happening, so I took out the laptop from my dock, and that was when I felt it: HEAT! It was ready to bake an egg on it... After a while of working on it outside the dock the fans did their work and it cooled down. After which the CPU usage itself also turned back to like 3%. Conclusion: False Alarm :)



I have re-enabled it by CLI "sadmin enable" (both enable and disable require a reboot by the way). The software still hasn't let me down yet. You can imagine I am waiting for the moment I come across an issue but it still did not occur...

Back to work :)

Discovering the CLI

Suddenly I remembered I didn't install UltraEdit yet, my favorite text editor. I realized I came across a Command-Line Interface reference somewhere and decided to go and find out how this CLI could be used for one-time installations. And guess what: it worked out fine :)

These are the steps I took to be able to install UltraEdit:
1. Allow access to CLI (Is restricted by default, needs to be opened up using an ePO task)
2. From CLI: "sadmin begin-update". This enabled the update mode locally
3. Installed the software
4. From CLI: "sadmin end-update"

Using "sadmin help" shows instructions on the available commands, but there is also a comprehensive pdf available covering the CLI.

I am still thinking what the real risk level would be of keeping the CLI opened up continuously. I guess it is a risk that shouldn't be taken, and as opening up the CLI can only be done from ePO I guess to install new software that is not allowed fromone of the exception rules requires you to logon to ePO and open up the CLI from there.

Furthermore I found there is a bit of a flaw to installations that are distributed as an .msi, such as UltraEdit. Before I used the CLI, I tried to install it from a trusted (local) directory by double clicking the .msi. My Trusted Directory however did not have any effect because an .msi file is run by msiexec.exe, which offcourse is not stored in this trusted local directory. Application Control thus still blocked the installation.