Book Image

Microsoft System Center 2012 Endpoint Protection Cookbook

By : Andrew J Plue
Book Image

Microsoft System Center 2012 Endpoint Protection Cookbook

By: Andrew J Plue

Overview of this book

Microsoft System Center 2012 Endpoint Protection (previously known as Forefront Endpoint Protection 2012) protects client and server operating systems against threats with leading malware detection technologies. Built on Configuration Manager, it provides a unified infrastructure for client security and compliance management and "Microsoft System Center 2012 Endpoint Protection Cookbook" will help you get to grips with vital tasks for implementing this security tool. With the release of System Center 2012 Endpoint Protection, Microsoft is continuing its commitment to offering a cutting edge, enterprise- ready Anti-Virus solution. With its practical and easy to follow recipes, "Microsoft System Center 2012 Endpoint Protection Cookbook" fully prepares you for a simple, headache-free migration. This hands-on, practical cookbook will have you equipped with the knowledge to install and manage System Center 2012 Endpoint Protection like a pro in no time by following step by step recipes. You'll gain insight into a wide range of management tasks, such as building your SCEP infrastructure, deploying SCEP clients and building the perfect AV policies for your workstation and servers. You'll also benefit from a complete SCEP walk-through in a bonus appendix chapter. With "Microsoft System Center 2012 Endpoint Protection Cookbook" in hand, you will have the confidence to tackle essential tasks like deployment, policy and much more for SCEP.
Table of Contents (17 chapters)
Microsoft System Center 2012 Endpoint Protection Cookbook
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Locating and interrupting client-side SCEP logs


Primarily, reporting data is accessed through the SCEP dashboard within your SCCM console, or by executing SCEP reports in SQL Server Reporting Services. However, you may find yourself attempting to troubleshoot a malware issue on a client PC without an access to either of those resources. This is when you come to know where to find your SCEP client-side logs, and understand how to interrupt them, which will prove very useful.

In this section, you'll be working with the most vital SCEP log, which is known as the MPLog and using it quickly will locate pertinent information, such as definition update history and malware detection history.

Getting ready

The local SCEP client logs are stored in the program data folder. Keep in mind, this directory is hidden by default and you will not be able to browse to it without enabling view hidden files, folders, and drives in Windows Explorer. A log parsing utility, such as Microsoft's Trace32 or the new version that comes with SCCM 2012 CMTrace, can be utilized to expedite the process of locating data inside the MPLog, but in the following example, we will be utilizing Notepad.

How to do it...

Follow these steps:

  1. 1. To locate your SCEP client-side logs on a Windows 7, Vista, or Windows Server 2008 system, navigate to the following path: %systemdrive%\ProgramData\Microsoft\Microsoft Antimalware\Support

  2. 2. Open MPLog-XXXXXXXX-XXXXXX.log with Notepad.

  3. 3. Once Notepad is open, hit CTRL-F to open the Find window.

  4. 4. Type in Threat Name to locate a record of malware detection, and press the F3 key to move to the next instance.

  5. 5. Back in the Find window, enter signature updated via to locate a record of the client's definitions updating.

  6. 6. Next, search for Scan Source to locate a record of a scheduled scan running or record a running scan that is on demand.

  7. 7. Then, enter Expensive file to locate an instance of an expensive file detection during a scan.

  8. 8. Click on File from the menu bar and select Exit to close the logfile.

How it works...

While the MPLog contains an abundance of data, the keywords we searched for will allow you to quickly locate some of the most pertinent data.

SCEP supports multiple definition update methods, which will be discussed later. Although the SCEP reports will show you which definition version a client is running, it does not reflect where a client receives its update. You should be able to find entries similar to this: Signature updated via InternalDefinitionUpdateServer on Sun Jan 02 2011 21:33:50.

In this case, InternalDefinitionUpdateServer would indicate that the definition update was pulled from a WSUS/SUP server within your corporate network.

In addition to this, there are several other entries you may find, such as Signature updated via MicrosoftUpdateServer on Sat Mar 12 2011 17:54:56. This would indicate that a definition was pulled from Microsoft Updates over the Internet. This should be common for remote users. Signature updated via UNC \\Server name\share indicates that an update was pulled from a UNC file share.

The MPLog also records any malware incidents the client has detected. If the client has experienced a virus detection, you will find an entry similar to Threat Name:VirTool:JS/Obfuscator. The following lines can provide some more background information about the virus detection, for example:

Threat Name:VirTool:JS/Obfuscator
ID:2147632206
Severity:5
Number of Resources:2
Resource Schema:file
Resource
Path:C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\OG2NNMHR\badwebpage.htm

The resource path can provide some very useful information when determining the attack vector or source of an outbreak. In the previous example, the malware was detected in the user's temporary internet files, indicating the attempted infection likely occurred when the user browsed to a website containing malicious code.

To find out what actions the client took after detecting the malware, continue to scroll downwards a few lines, where you'll locate an entry similar to the following:

Beginning threat actions
Start time:‎Fri ‎May ‎13 ‎2011 15:41:51
Threat Name:Virus:DOS/EICAR_Test_File
Threat ID:2147519003
Action:remove
File to act on SHA1:3395856CE81F2B7382DEE72602F798B642F14140
File cleaned/removed successfully
File Name:C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\X2GCUOEX\eicar[1].com
Resource action complete:Removal

In this case, the infected file was successfully removed.

The MPLog also records detections of what are known as Expensive Files. These are files which take the SCEP client an abnormally long amount of time to scan. Knowing what files are considered expensive can be valuable when tuning your SCEP policies for optimized scanning performance. If your SCEP client has detected expensive files during a scan, you may find a log entry similar to the following:

!WARNING
Expensive file
File Name:C:\Program Files (x86)\Program\largefile.exe
File Size:107374882
Time:6552

If you know whether this is a safe and valid file, you may consider adding a custom exclusion for this file in your SCEP policy.

There's more…

In addition to the uses outlined in the recipe, there are other logs generated by the SCEP client that may prove useful to you.

More details about the MPLog

The MPLog is the primary client side log for SCEP. It will contain information on almost every aspect of a SCEP client. The MPLog will have a filename that matches to the following criteria: MPLog-01012011-174035.log. In this example, the value 01012011-174035 corresponds to the date and time the logfile was first created, January 1, 2011 at 5:40 pm. Typically the MPLog is created during the installation of the SCEP client.

Other useful client-side logs

The MPLog is not the only logfile which SCEP writes events to; MPDetection-XXXXXXXX-XXXXXX.log records an event every time malware is detected.

NisLog.txt

If you've enabled the Network Inspection System (NIS) component of SCEP in your SCEP policy, then it will append data to NisLog.txt.

NIS is the network monitoring component of SCEP. It creates a logfile in the following directory: C:\ProgramData\Microsoft\Microsoft Antimalware\Network Inspection System\Support

Note

If you've chosen to utilize NIS monitoring, the NISLog on your clients is important, because events generated by the NIS service are not sent to the SCEP infrastructure and therefore, cannot be viewed in SCEP reports.

The NIS service starts during bootup, and creates log entries similar to the following sample:

01/03/11-11:23:10] *********************************************
[01/03/11-11:23:10] Network Inspection System service starting.
[01/03/11-11:23:10] Built on "Nov 11 2010" "14:31:02"
[01/03/11-11:23:10] Version: 3.0.8107.0
[01/03/11-11:23:10] *********************************************
[01/03/11-11:23:10] Updating configuration
[01/03/11-11:23:10] [Load  ] Consumer: {fc9058d8-dc9f-4416-bad1-09a6ad347c2a} IpsConsumer.dll (Type: 1)
[01/03/11-11:23:10] Loading engine from folder c:\ProgramData\Microsoft\Microsoft Antimalware\Definition Updates\{1BF8C8F4-9AA1-42A8-87CA-F1A9D94E1034}, fAllowEngineReload=0
[01/03/11-11:23:12] --Signature list start--
[01/03/11-11:23:12] [Off] Sig {887ab750-5912-11dd-ae16-0800200c9a66} Plcy:Win/SMTP.DNSLookups.RCE!2004-0840 - Signature not Host-Detect or Host-Block

What you can see from this entry is that the NIS service started successfully and loaded its signatures. If the system running SCEP is fully patched, it will not be uncommon to see the most, if not all, of the modules are set to [Off].

NIS is designed to monitor for known network-based exploits and to cease monitoring for a given exploit, once the corresponding Hotfix is installed. In other words, NIS is aware of the patch level of the OS it is running on and will not waste resources scanning for attacks, despite the OS being no longer vulnerable.