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.
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.
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:
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:
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:
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.
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.
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:
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.