Endpoint Protection Anti-Tamper Remediation (SCEP 2012)

SCEP 2012 SP1 introduced anti-tamper features into the product. The ability to stop or restart the Microsoft Antimalware Service has been disabled. http://blogs.technet.com/b/mspfe/archive/2013/02/19/anti-tampering-for-the-antimalware-service-in-system-center-endpoint-protection-2012-sp1.aspx

What happens though if a user has access to uninstall SCEP from Add/Remove programs? SCCM client actions will run and determine that the application has been removed and then re-mediate this by re-installing. It’s not instant and the device is vulnerable whilst the service is removed.

Every 4/5 hours the ConfigMgr client action for Endpoint deployment re-evaluation will run on a client. Take a look at the scheduler.log file on a client.

Search for the line ‘Sending message for schedule ‘Machine/{00000000-0000-0000-0000-000000000221}’ (Target: ‘direct:EndpointProtectionAgent’, Name: ”)’

On my particular client I can see this entry is repeated at the following times:

10:34, 13:58, 18:00, 22:09, 03:01, 08:18, 11:13, 12:56 etc

Once the EndpointProtectionAgent is triggered re-install will occur.

I can trigger the action manually to show the process of the reinstall. To do this I have modified a PowerShell script located here. Thanks to Trevor Stuart for providing this to the Community.

I modified the script to remove the reference to the Machine Policy Retrieval & Evaluation Cycle and replaced with the EndPointProtectionAgent trigger. (For a list of trigger actions check here)

So my new code looks like this.

#Beginning of a new function cmdlet. 
function Invoke-SCCMSchedule 
{ 
 [CmdletBinding()] 
 Param( 
 [String]$ComputerName = ".", 
 [Parameter(Mandatory = $true)] 
 [string]$ScheduleID 
 
 ) 
 
 $ScheduleIds = @{ 
 EndPointProtectionAgentCycle = "{00000000-0000-0000-0000-000000000221}"; # EndPointProtectionAgent
 } 
 
 if(Test-Connection -Computer $ComputerName) { 
 Try { 
 $SmsClient = [wmiclass]"\\$ComputerName\root\ccm:SMS_Client" 
 $SmsClient.TriggerSchedule($ScheduleIds.$ScheduleID) 
 } 
 Catch { 
 Write-Host "Trigger Schedule Method failed" -ForegroundColor RED 
 } 
 Finally { 
 Write-Host "ScheduleID trigger has been confirmed." -ForegroundColor Green 
 } 
 } 
 else { 
 Write-Host "Computer may be offline or please check Windows Firewall settings" -ForegroundColor Red 
 } 
} 
#End of the function, now invoke the function. 
Try { 
Invoke-SCCMSchedule -ScheduleID "EndPointProtectionAgentCycle" 
 } 
 Catch { 
 Write-Host "Cannot trigger action" -ForegroundColor Red 
 } 
 Finally { 
 Write-Host "Successfully triggered the desired action." -ForegroundColor Green 
 } 
 
#End invoke, validate results in SCCM console.<span style="font-family: 'Courier 10 Pitch', Courier, monospace; font-size: 13px; font-style: normal; line-height: 1.5;">

Initially I can uninstall the SCEP client from Add/Remove Programs

My endpoint device is now vulnerable

I can confirm that in ProgramData\Microsoft\Microsoft Antimalware the application has been removed.

If I check the scheduler.log file my last Endpoint Protection client action ran at 10:30 this morning, it’s now almost mid-day so the system will be vulnerable for approx another 2 hours. To speed things up I am going to run the PowerShell above and manually trigger the action

The PowerShell has been executed

Almost instantly SCEP is re-installed onto the system.

Let’s take a look at the EndPointProtectionAgent.log on the client in the %WINDIR%\CCM\Logs folder.

I see that the Endpoint action has been triggered and that the EP client detection reports that the client is not installed. Finally SCEP client will be installed since it is not present.

In the MaintenanceCoordinator.log file I can see a task is signalled to kick start SCEP install.

A request is sent to the WSUS server to obtain the SCEP installation – LocationServices.log (Package {8C070591-B909-46FC-A48C-B0121073974D}).

The StateMessage.log reports back SCEP deployment state and updates this through the installation process.

Note that at EP Deployment State is updated in the StateMessage.log at 11:52:48. This coincides with updates in the EndPointProtectionAgent.log. Note also that the state (3) matches in both log files (11:52:46 in logs above and below).

The SCEP icon is back in the System Tray

and the programs are back in the ProgramData\Microsoft\Microsoft Antimalware folder.

SCEP application remediation has taken place. Policies are applied to the client very quickly. The  EndPointProtectionAgent.log confirms this