You notice that the DLP agent consumes high cpu when running remote connections using Microsoft Management Console.
| INFO
| CoreServices.MessageLogger
| MESSAGETYPE_DETECTION_REQUEST {90C4C6F0-7CA5-44AA-8DF0-95E2
Request Id #297613
Detection Request Details :
Session Command : Session Continue Request
Session Id : {00ECAD59-6DBC-4E45-9B95-65405
Request Type : Data In Motion Request
Dim Detection Request Details :
Process Id : 5280
Process Path : \Device\HarddiskVolume1\Progra
Application Name : Java(TM) Web Launcher
User : gbd16bot
Domain : AD2
Time Stamp : 02/05/2019 19:08:16
Dim Event Type : HTTP(S)
HTTP(S) Details :
Network Info Details :
Source IP : 10.xx.xx.xx
Source Port : 62633
Source Domain :
Destination IP : 10..xx.xx.xx
Destination Port : 27888
Destination Host Name : hostname:27888
In the DLP agent log file you will notice references to an application known as jp2launcher.exe. When the DLP agent is running it will begin to consume several gigs of memory and this is due to the rt.jar or java runtime (or bootstrap classes which is everything java needs for web communications). The java run time (bootstrap classes) contains over 36,000 files inside it. And, it just so happens that jp launcher + rt.jar are not http events and cannot be normally excluded by the agent.
In order to exclude jar files you must exclude .zip files. Because, the DLP agent will inspect and analyze both .jar and .zip files as if they were the same.
Any of the following should resolve the issue.
1. Ignore jp2launcher.exe by adding it to global application monitoring and unchecking every box. While the resulting java application may be used for data exfiltration, it is highly unlikely the jp2launcher will be handling the actual file transfers.
2. Having a path exclusion ignoring everything in any java directory on the endpoint such as */jdk/*
3. Ignoring *.jar within the agent configuration. Note this will also ignore *.zip so use caution and only specify 'application file access' as the destination in this filter.