How to utilize SEP 12.1 for Incident Response - PART 7

This article is the seventh installment in an on-going series of articles on how to utilize SEP 12.1 for Incident Response. Links to the previous six are below:

1. How to utilize SEP 12.1 for Incident Response - PART 1
2. How to utilize SEP 12.1 for Incident Response - PART 2
3. How to utilize SEP 12.1 for Incident Response - PART 3
4. How to utilize SEP 12.1 for Incident Response - PART 4
5. How to utilize SEP 12.1 for Incident Response - PART 5
6. How to utilize SEP 12.1 for Incident Response - PART 6

In this article I will explain and demonstrate the use of an Application and Device Control policy to monitor all file and registry activity of a system. Most likely you've heard of the Sysinternals Process Monitor utility? It's possible to use SEP 12.1 to perform the same functions. This is especially useful if you are in an Incident Response situation and you do not have local access to a machine. Not to mention the SEPM will take the logs and process them for you which will make them much more easily readable.

The first step is to ensure you have the Application and Device Control component installed as part of the 12.1 client. Without it, this obviously will not work.

The SEPM  does not easily identify for you if ADC is installed on clients but Steven Kintakas posted an excellent query that you can run against your SEPM DB here:

https://www-secure.symantec.com/connect/forums/zer...

The best example for this case is during an incident response. You've determined that you have a machine on the network that is infected but traditional AV signatures are not detecting anything. You need to segregate this machine from the rest of the pack and determine what exactly it's doing. So let's get started...

Login to your SEPM and go to the Policies page and select the Application and Device Control policy tab. Click "Add and Application and Device Control"

A new policy will be created so you can open it up and select the "Application Control" tab. Delete all rule sets so you can start with a fresh slate.

Click "Add" and you will have the option to add conditions. We will add two, one for "Monitor File Activity" and a second for "Monitor Registry Activity." I decided to keep these separate in case you only want to monitor file activity or registry activity but not both. Final result is below:

Let's review each rule set in detail. First is the "Monitor File Activity" rule set. This rule set will apply to all processes:

We need to add a new condition to monitor file and folder access attempts. Again, this will also apply to all files and folders:

Now, we jump over to the Actions tab. Because we're only monitoring activity, we leave it at log for read, create, delete, or write attempt:

That's it for file monitoring. Now Let's look at the second rule set "Monitor Registry Activity:"

We want this rule set to apply to all processes:

Now we need to add a condition to monitor all registry activity. It needs to apply to all of the Registry hives:

Lastly, because we're monitoring, leave it at log only:

The policy has been created, simply save and apply to your Incident Response group.

*Note* You are going to get a lot of logs using this particular policy as it has been configured to show all activity on a system. If you're familiar with process monitor, you will know what I'm talking about. I would only keep this policy applied for as long as you need it then withdraw once completed.

To view the logs simply go in to the Monitors page of the SEPM and set a log like so:

You will now be able to see everything! This is only a small look obviously:

Application and Device Control is an awesome feature and really has no limits to what it can do for you during an incident response. Hopefully, this will help you and perhaps give you some other ideas of how to best use it. Feel free to comment below with any feedback or reach out to me privately. I also welcome any suggestions for future articles.

Thanks!