Jump to content
jbennin

Continous Notifications from Server

Recommended Posts

We had a confirmed false positive against a client that we've since EXCLUDED and repaired the known safe application.  We also weren't receiving NOTIFICATIONS from the Anti-ransomware module and upon restoral,  we seem to be getting a large backlog of notices on the event from 1 day ago.  Every notice has a varying number of notices which all have the same TIME | HOSTNAME | IP ADDRESS etc...  Is their a backed up queue we can clear in order to get rid of this situation and resume receiving legitimate notices for the module?

 

Any assistance is greatly appreciated.  Server reboot was already done. 

Share this post


Link to post
Share on other sites

Update - doing some digging on the client,  I was able to delete a .JSON file that was located in the ArwDetections path shown below.  This stopped the continuous notifications from occuring.  What would have caused this?

 

image.png.1b2e33dd9afeea392cf17e2d66950fe2.png

Share this post


Link to post
Share on other sites

Greetings,

My suspicion is that perhaps the client hadn't checked in with the server for a while and because it stores the notifications to have them queued up, by the time it finally checked in you were seeing the notifications that had stacked up from the previous detections before you dealt with the issue by creating the exclusions.  Similar events occur with blocked websites whenever the Web Protection component blocks multiple connection attempts to a blacklisted site or server; it will log and often display multiple 'duplicate' alerts due to the number of connection attempts (this will often occur because of the way most browsers, and I believe even Windows itself, will automatically retry a failed connection attempt to a server/website).

I notice in the entry you posted that it shows the clean result as 'DORQUEUED' which I believe means the object was not actually removed, but was queued for DOR (Delete on Reboot), likely because the file/process was active in memory and I don't believe that Malwarebytes will terminate an already running process (and since Ransomware Protection looks at application behavior, it is far more reactive than proactive in that it acts more like a manual scan does with regards to detection and threat quarantine than the other more proactive components that intercept threats pre-execution) which would explain why multiple alerts/notifications were observed since the process continued running and continued exhibiting the behavior for which it was identified as possible ransomware, and as each of those continued detections occurred Malwarebytes continued to log each event/detection and queued up all those alerts to send to the server/console.  I'd imagine after running for quite a while in that state that it would amass a rather large backlog of detections/events to send notifications for.  I suspect they may end up having to implement a threshold to handle duplicate events/alerts like this where they might have it not display an alert/notification for the same item being detected n# of times within the space of a set timeframe and that could resolve the problem, and perhaps send aggregate alerts/event notifications to the console stating something like "This event has occurred n# times" or similar to sum up the activity/event rather than spamming countless stacked alerts/events to the console/server.  That would at least be one way to solve it, though obviously that is up to the Product team and Developers.

I will document this for the Product team to make them aware of it and hopefully we will see a resolution in an upcoming release, assuming I am correct in my analysis of what's going on and why it happened.

Share this post


Link to post
Share on other sites

Hi @jbennin,

@exile360 is correct that the notifications from the detections had stacked up. Depending on the amount of detections made for the false positive, you could continue to get notifications well after the event until they've all been reported. The solution to stop the continued reporting is to remove the detection history from the managed client, as you found. Let us know if you have any further trouble or questions!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.