Jump to content

False positives - Service log files?


SWa

Recommended Posts

Five seconds after update of Detection Engine (version 20663) and Rapid Response module (version 15559), Eset's HIPS module started to generate Ransomwear-warnings, apparently when a Windows service was writing an innocent logging text to a log-file. This only happened to one service though. The service has been running for months without issues. Suspecting false positive here...

Anyone with similar issues?

BR

SWa

Link to comment
Share on other sites

I'm on Detection Engine (version 20664) and Rapid Response module (version 15560) observing no such issue. Force an Eset update and see if the problem disappears.

Link to comment
Share on other sites

  • Most Valued Members
3 hours ago, SWa said:

Five seconds after update of Detection Engine (version 20663) and Rapid Response module (version 15559), Eset's HIPS module started to generate Ransomwear-warnings, apparently when a Windows service was writing an innocent logging text to a log-file. This only happened to one service though. The service has been running for months without issues. Suspecting false positive here...

Anyone with similar issues?

BR

SWa

Which service is this?

Link to comment
Share on other sites

It's a 32-bit service made by our own company. Has been running for months with no issues. Just funny that ESET suddenly created what to me seems like obvious false positive warnings only seconds after an ESET update. The same issue occurs after update of the Detection Engine (version 20664) and Rapid Response module (version 15560) . It seems to happen only for one service and on one PC, so not much data to base any claims on. ESET seems to create warnings when a service log entry is written to C:\ProgramData\<company>\<application>\<log>\<textfile.log.txt>

Events log shows multiple entries: Time - Module: HIPS - Event: "An application (<service name>) tried to modify files on your computer in a suspicious way. This attempt was blocked." User - SYSTEM. However, our service's log file is updated with information.

No entries in other logs. Nothing in the HIPS-log either, even though the "Events" log says the event took place in the HIPS module.

Warning message says "Ransomeware shield" followed by the text in the events log entry: "An application.... tried to modify...etc."

Other services write similar log files to similar folders without issues.

When uninstalling our 32-bit service and reinstalling with a new 64-bit service, the issue disappears. 

Little data to work on, and could be due to a weakness in our service. I guess this case can be closed. Sorry for the inconvenience.

Edited by SWa
Link to comment
Share on other sites

  • Administrators

Please provide the requested logs along with quarantined files. We would like to find out what was actually detected. I can imagine the process renaming files had a low reputation in LiveGrid and the log files had a suspicious extension used by ransomware which, along with some other conditions, led to the detection by Ransomware shield.

Link to comment
Share on other sites

  • Most Valued Members
4 minutes ago, SWa said:

It's a 32-bit service made by our own company. Has been running for months with no issues. Just funny that ESET suddenly created what to me seems like obvious false positive warnings only seconds after an ESET update. The same issue occurs after update of the Detection Engine (version 20663) and Rapid Response module (version 15559) . It seems to happen only for one service and on one PC, so not much data to base any claims on. ESET seems to create warnings when a service log entry is written to C:\ProgramData\<company>\<application>\<log>\<textfile.log.txt>

Events log shows: Time - Module: HIPS - Event: "An application (<service name>) tried to modify files on your computer in a suspicious way. This attempt was blocked." User - SYSTEM. However, our service's log file is updated with information.

No entries in other logs. Nothing in the HIPS-log either, even though the "Events" log says the event took place in the HIPS module.

Warning message says "Ransomeware shield" followed by the text in the events log entry: "An application.... tried to modify...etc."

Other services write similar log files to similar folders without issues.

When uninstalling our 32-bit service and reinstalling with a new 64-bit service, the issue disappears. 

Little data to work on, and could be due to a weakness in our service. I guess this case can be closed. Sorry for the inconvenience.

I believe it was the Machine Learning module that triggered the Ransomware shield for somekind of reason or some kind of action from the Services that triggered the shield

Provide Marcos with the needed files he will be able to help you.

Link to comment
Share on other sites

12 minutes ago, SWa said:

Events log shows multiple entries: Time - Module: HIPS - Event: "An application (<service name>) tried to modify files on your computer in a suspicious way. This attempt was blocked." User - SYSTEM. However, our service's log file is updated with information.

Did you register this service?

Link to comment
Share on other sites

5 hours ago, SWa said:

Anyone with similar issues?

Absolutely.

I've been having messages pop up all day today. It's gotten so annoying that I joined the forum to add a comment to this post!

I develop desktop applications, and these are being flagged by the Ransomware Shield whenever I run them.

Detection Engine: 20664
Rapid Response module: 15560

I've run a full virus scan, but nothing's been found.

Link to comment
Share on other sites

  • Administrators
16 minutes ago, kaizohh said:

Absolutely.

I've been having messages pop up all day today. It's gotten so annoying that I joined the forum to add a comment to this post!

I develop desktop applications, and these are being flagged by the Ransomware Shield whenever I run them.

Detection Engine: 20664
Rapid Response module: 15560

I've run a full virus scan, but nothing's been found.

Please provide logs collected by ESET Log Collector.

Link to comment
Share on other sites

  • Administrators

Please provide logs collected with ESET Log Collector, not just recent records from the HIPS log.

As I already mentioned, the applications' behavior seems to trigger a new detection in the Ransomware shield but we'll need ELC logs to confirm. Since it's a behavior detection and the applications are not prevalent, you need to add them to performance exclusions to prevent detection.

Link to comment
Share on other sites

Microsoft has an article on service log creation here: https://docs.microsoft.com/en-us/dotnet/framework/windows-services/how-to-log-information-about-services . I don't see anything shown in the sample code given assuming similar code was deployed that could be interpreted as ransomware behavior. But who knows these days?

Link to comment
Share on other sites

17 hours ago, Marcos said:

Please provide the requested logs along with quarantined files. We would like to find out what was actually detected. I can imagine the process renaming files had a low reputation in LiveGrid and the log files had a suspicious extension used by ransomware which, along with some other conditions, led to the detection by Ransomware shield.

Log files have been sent. There are no recent files in quarantine.

Edited by SWa
Link to comment
Share on other sites

  • Administrators

It was confirmed that the issue affected users with custom applications who had the LiveGrid Feedback system disabled. As a result, LiveGrid had no information about the application and a new protection mechanism implemented recently in the Ransomware Shield kicked into action when a suspicious operation was attempted.

Link to comment
Share on other sites

1 hour ago, Marcos said:

LiveGrid had no information about the application and a new protection mechanism implemented recently in the Ransomware Shield kicked into action when a suspicious operation was attempted.

Glad to see such processing has finally been implemented.☺️

Perhaps the Eset alert/log entry could be embellished to add reputational language to it. This would point the user to a LiveGrid factor in the detection.

Link to comment
Share on other sites

6 hours ago, Marcos said:

@SWa and @kaizohh, was the issue that only a benign alert was generated or it actually affected the application in some way ?

@Marcos Yes, I believe the application wasn't affected, and continued to function correctly.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...