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:
- 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\MicrosoftAntimalware\Support - Open
MPLog-XXXXXXXX-XXXXXX.logwith Notepad. - Once Notepad is open, hit CTRL-F to open the Find window.
- Type in
Threat Nameto locate a record of malware detection, and press the F3 key to move to the next instance. - Back in the Find window, enter
signature updated viato locate a record of the client's definitions updating. - Next, search for
Scan Sourceto locate a record of a scheduled scan running or record a running scan that is on demand. - Then, enter
Expensive fileto locate an instance of an expensive file detection during a scan. - 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.
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.
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
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.