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.

What to do at one-time emergency installation?

Yesterday I was at-the-office and for some reason my Domain Policy kicked in and first removed my Microsoft Office installation, afterwards trying to deploy it again. The deployment failed partially ending up in a misconfigured installation. I tryed to figure out what specifically was blocked from the Windows Eventviewer and ePO. They both indeed held the blocking events. But when I used the logged info to allow the installation (again by trusted directory) after a reboot it still was blocked.

Because I had limited time at that moment I went looking for a way to temporarily disable Application Control, and found that there is quite a nice way to do so: in ePO there is a client task type named "SC: Start Update Mode" and "SC: End Update Mode". They pretty much do what they say, Update Mode being a time window in which one is allowed to make changes to the system, so after starting the update mode on my computer I was simply able to recover the Office installation and it's running smooth now.

Afterwards I offcourse "ended" the Update Mode, and I will try to find out what is a more comprehensive way to allow AD deployed software.