Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
sdunn
Employee Alumnus
Employee Alumnus

AW keeps deleting Dameware Service

We have been working with Check Point on this issue nearing 3 months. 

Despite all of the exclusions and updates we have made, the Anti-Malware Blade insists that the Solarwinds: Dameware Mini Remote Control service is malicious and deletes the corresponding .exe files. 

   -DWRCS.exe

   -DWRCST.exe

   -DWRCSET.dll

   -LogAdjuster.exe

What we've done:

-Followed ALL of the steps in sk13132

-Analyzed the forensics reports and made suggestions for new exclusions 

-Tested several "new" AW policies that Check Point suggested

-Selected "Skip File" under "Riskware Treatment"

-Updated our SmartEndpoint (R77.30.03-990003009, e80.86 version)

-Tested the software on different client versions (Same result between e80.70-e80.86)

-Applied the necessary hotfixes to the Smart Endpoint

-Added Dameware as a whitelisted application under "Application Control"

-Sent various updates and cpinfo's, logs, and screenshots to Check Point

-Reached out to SolarWinds for advice (No such luck)

Was wondering if anyone else has experience with the Dameware service while using Checkpoint Endpoint Protection and whether or not they need exclusions/if their exclusions are working properly?

I realize that there are businesses in the same boat as us and that this may be a shot in the dark, but I thought it was worth a try.

20 Replies
PhoneBoy
Admin
Admin

What SRs have you opened on this issue?

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Currently, I have 3-0414220611 open in regards to this. 

(This is an amalgamation of calls, chats, and other various SR's compounded.)

In the past, I've had: 
3-0535640411 (Concerning what the special client version build did to our computers in a test environment.)

and a few various other SR's in relation to the behavior/ how the suggested actions have affected us.

0 Kudos
Alex_Weldon
Contributor

We use DameWare and simply edited the "Scan all files upon access" section and added the following:

Seems to work fine for us. R77.30.03

sdunn
Employee Alumnus
Employee Alumnus

How we have ours set.

So yours is working with the following exclusions:

   -C:\Windows\DWRCS\DWRCSET.dll

   -C:\Windows\DWRCS\DWRCST.exe

   -C:\Windows\DWRCS\SolarwindsDiagnostic.exe

   -C:\Windows\DWRCS\DameWare.LogAdjuster.exe

Ours has:

   -C:\Windows\DWRCS\DWRCSET.dll

   -C:\Windows\DWRCS\DWRCST.exe

   -C:\Windows\DWRCS\SolarwindsDiagnostic.exe

   -C:\Program Files\SolarWinds\DameWare Mini Remote Control    x64\solarwindsdiagnostic.exec:\windows\dwrcs\DameWare.LogAdjuster.exe

(Based on what was given in their sk for this issue.)

Sounds like I need to take out the last exclusion and add C:\Windows\DWRCS\DameWare.LogAdjuster.exe instead. 

"C:\Program Files\SolarWinds\DameWare Mini Remote Control    x64\solarwindsdiagnostic.exec:\windows\dwrcs\DameWare.LogAdjuster.exe" is literally how they have it listed in their sk. As well as "DWRCSET.exe" which is incorrect.

Thank you so much for your insight!

0 Kudos
Alex_Weldon
Contributor

Not a problem. I did some more digging and found we did put in an exception in quarantine as well. Picture below.

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Thank you! Those are the exceptions we have in place there, as well. 

Our dameware exceptions.

We also have these exclusions under "Scheduled Scan Targets":
DWRCS
SolarWinds

I made the adjustments to the "Scan on Access" section and hope that changes things. It mirrors what you have in that respect now. (@Alex Weldon)

sdunn
Employee Alumnus
Employee Alumnus

We're still experiencing this issue, even after the changes I made similar to yours. Quick question: Are you using R77.30.03?

0 Kudos
Alex_Weldon
Contributor

Hi Stacey, I am using R77.30.03 on a standalone vmware server.

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Thank you, we were wondering if perhaps R80.20 was a solution. 

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

The changes seem to have helped significantly, but we are still getting scattered deletions that are failing to report to our email alerts. 

I am wondering if adding "C:\Windows\dwrcs\dwrcs.exe" will help.

0 Kudos
Katelyn_Eubanks
Contributor

We are having this exact same issue as well. All the exclusions are added above as you have in your setup, but sporadically we are still seeing dameware files removed from endpoints. We had a ticket opened and closed but I think its about time to open one up again.  

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Yeah, seemingly it was working for a period of time. But, we are still getting scattered deletions. (My own laptop deleted it this morning upon startup.)

Do you mind if I asked why the ticket was closed? Was it believed to have been solved?

0 Kudos
Katelyn_Eubanks
Contributor

So, when we were seeing the issue of dameware being removed we had whitelisted all of the above folders and .exe that you all have gone over above. I thought it was possible that it was removing the dameware product before it was gathering the policy, like on a new install of checkpoint client on an endpoint. Meaning it would scan and remove before gathering our default policy. Checkpoint said it was how the product behaved where it would take up to five minutes to gather policy so we closed the ticket. However now we are seeing like 5 or 6 computers a day where dameware is still getting removed, yet their policies should be current. Not really sure where to go from here. Another ticket I suppose

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Yes! That's exactly where we are with it. We've had the same ticket open this entire time, though. I appreciate your comments. It's good to know we aren't the only ones this is happening to. 

0 Kudos
Katelyn_Eubanks
Contributor

Currently I have gone back over and made the changes recommended from sk131312 exactly, and removed any other additions we had added for dameware. Going to watch for updates and probably open another ticket. 

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

They've built a client version for us to test specifically for this issue. (It's an e80.85 EPS.msi, strictly for 64 bit machines.)

Thus far, I haven't had the best of luck with it, but I'm going to test it on an old laptop I have sitting in my office. The first time I deployed it to my production laptop, it crashed it and I had to completely blow it away and re-image it. Lesson learned: I will never test any software outside of a VM or test environment again. Hahaha. 

I'll let you know if we have any progress or hear of any news. 

0 Kudos
sdunn
Employee Alumnus
Employee Alumnus

Update: We still haven't made any traction. I have been instructed to implement the test client they have provided on to production PC's to further test. 

0 Kudos
Katelyn_Eubanks
Contributor

Stacy,

We have since reopened our ticket on this issue as we have not made any headway either. Will keep you updated.

Katelyn_Eubanks
Contributor

Update, after opening a ticket we were told that the fix was to update our fleet to 80.85 version of the endpoint so we are working on that now. I will let you know if it makes a difference. 

sdunn
Employee Alumnus
Employee Alumnus

The special build seemed to have worked for us, as well. I was told there was going to be an addition that included whatever helped fix it in the newest client release.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events