Application Control Logs

Hi isoffice 

If a controlled application has been detected on the network, the event is generated in application control event logs which can be viewed from the Sophos Enterprise console. You can also set up alerts to be sent to your chosen recipients when an application control event has occurred. Let me know if this helps. 

Hi Shweta,

Thank you for your prompt reply.

I have seen the entries in the Application Control Event Logs as described by you. However, I am trying to dig a bit deeper and see if I can determine what actually triggered the launch of the Powershell application on the client PC in the first place.

I was hoping that a raw log file would exist (on the client or server hosting Enterprise Console) which gave me a bit more information.

Any further information would be much appreciated.

John P

Hi John, 

For Endpoint Security and Control clients managed by Enterprise Console, there may be more detail for Application Control detections in the SAV.txt logs (Anti-virus logs). 

On a client machine SAV.txt can be found in the following folder: C:\ProgramData\Sophos\Sophos Anti-Virus\logs

Please let us know if you have any further questions. 

Regards, 

Hello John P,

the more detail  RodS mentions does not include a potential caller. An Application Control event doesn't even denote the launch of [an] application. It's a by-product of scanning (On-Access or also on-demand/scheduled). AFAIK SAV doesn't log the process accessing a file but maybe it can. Anyway, you can use Process Monitor to find, if not the what, at least the immediate caller.
Coincidentally the other day I had HPMal alerts for a Powershell invocation. Turned out the caller was wscript.exe executing a .vbs. wscript in turn was started by a scheduled task. In this case I filtered File System Activity, Path ends with powershell.exe. This not only showed that the caller was wscript.exe but that it was called by taskeng.exe that also accessed the .vbs. In case there's another intermediate you'd need an additional ends with but that's a no-brainer.

Christian

Hello John P,

the more detail  RodS mentions does not include a potential caller. An Application Control event doesn't even denote the launch of [an] application. It's a by-product of scanning (On-Access or also on-demand/scheduled). AFAIK SAV doesn't log the process accessing a file but maybe it can. Anyway, you can use Process Monitor to find, if not the what, at least the immediate caller.
Coincidentally the other day I had HPMal alerts for a Powershell invocation. Turned out the caller was wscript.exe executing a .vbs. wscript in turn was started by a scheduled task. In this case I filtered File System Activity, Path ends with powershell.exe. This not only showed that the caller was wscript.exe but that it was called by taskeng.exe that also accessed the .vbs. In case there's another intermediate you'd need an additional ends with but that's a no-brainer.

Christian

Hi guys,

Many thanks for your input, it has proven quite helpful.

The SAV.txt does indeed log the instance of powershell.exe being blocked by Application Control, but not the caller. I was a little hesitant in deploying this particular policy as I was concerned that a legitimate powershell instance would be blocked. We use Microsoft System Centre Configuration Manager (SCCM) to deploy software packages and OS updates and I have a suspicion (may well be unfounded as I haven't the slightest clue about SCCM) that some of these deployments may require powershell to complete.

Anyhoo, I'll leave it in place for the time being and monitor our SCCM server to see if it has any future issues in relation to patch/software deployment.

Thanks again,

John P

Hello John P,

dunno (as I'm not using it) if SCCM uses Powershell on the clients for deployment - it shouldn't be too hard to find out from correlating SCCM activity with the events.

Anyway, just want to mention that Application Control is unconditional, i.e. it's you who classifies an application as "good" or "bad", not Sophos based on what an application does. As said, rogue scripts (in the case I've mentioned it was passed via command line, not as file) might trigger alerts. EXP (the Exploit Prevention add-on, HitmanPro.Alert) should [I say should, no first-hand experience]  provide better protection against "illegitimate" Powershell invocations.

Christian

Hi Christian,

Many thanks for the update. Curiously enough, we are looking at expanding our Enterprise Console installation to include Exploit Prevention. Let the joys of Procurement commence!!

Best regards,

John P