Just rolled out McAfee and have 1000's of hits on this too.
3/3/2016 12:28:46 PM Would be blocked by Access Protection rule (rule is currently not enforced) <domain>\<user> C:\PROGRAM FILES (X86)\INTERNET EXPLORER\IEXPLORE.EXE C:\Users\<user>\AppData\Local\MICROSOFT\Windows\TEMPORARY INTERNET FILES\counters.dat Common Standard Protection:Prevent common programs from running files from the Temp folder Action blocked : Read
So what is everyone doing on this? Or is this a virus in my environment?
Not a virus. It is noise.
The bane and boon of Access Protection is that it cannot tell you if you have a virus or not, it can only tell you of behaviors it is seeing.
And, the behaviors it tells you about are the ones configured, enabled.
In this case, IExplore, the browser process, is accessing a file with READ privilege, and that file resides in a folder matching the **\TEMP*\** criteria.
To your point, you're wondering why this is showing up now and not in earlier patches - because the earlier patches did not qualify this rule in the same manner; the underlying technology has changed.
For how to respond to this, the simple option is to disable the report option on the rule. By default it is only set to report anyway, so it's not providing any security - it's purpose in life is to tell you when certain programs are reading from a TEMP folder; it doesn't do anything about it unless you change the configuration to also BLOCK.
So your advising the "solution" is to disable the report option?
In our environment, we also block this aswell.
In the past, we had a cryptolocker outbreak which was "reported" by this rule.
I think it's obvious to not only report this but block it aswell because our infection was triggered by this rule.
The problem is with these 1000+ false positives, we don't see the actual interesting alerts coming through which is a huge problem.
With your justification for keeping the rule, the remaining option is to disable the Reporting to avoid the noise. Access Protection (in VSE) doesn't have other alternatives for the configuration.
Access Protection in ENS 10.1 does have other alternatives. You can build more complex rules in Endpoint Security 10.1 such that the established-as-safe behavior could be excluded.
Do decide quickly, because Access Protection "noise" can easily overwhelm a SQL server.
Mcafee, stop it now right here and take customers serious.
How can anybody in 2016 with Ransomware all over tell customers to exclude an Event in fully. 40% of the Post in this thread a large customer who bulk bring cash to mcafee?
We have this NEW with an Enterprise customer.
* And NO we don't want do disable the EVENT or the REPORTING n days of Ransomware (This is by the way a customer who has TIE and an ATD SANDBOX for USD 150'000.- in place)
* And i personal have that alert since years on one of my working machines and i personal jump around when the M-Symbol gets red. Everytime i look at it and see it's the counter.dat error i have a bad vibe...
Mcafee, Please advice on how to exclude that SINGLE alert or with which P6/P7 this is solved?
|McAfee DXL Client||220.127.116.11|
|Threat Intelligence Exchange module for VSE||18.104.22.168||22.214.171.1243|
|Detecting Prod ID (deprecated):||VIRUSCAN8800|
|Detecting Product Name:||VirusScan Enterprise|
|Detecting Product Version:|
|Threat Source Process Name:||C:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE|
|Threat Source URL:|
|Threat Target Host Name:||WS******|
|Threat Target IPv4 Address:||192.168.*.*|
|Threat Target IP Address:||192.168.*.*|
|Threat Target MAC Address:|
|Threat Target User Name:||****\****|
|Threat Target Port Number:|
|Threat Target Network Protocol:|
|Threat Target Process Name:|
|Threat Target File Path:||C:\Users\*****\AppData\Local\MICROSOFT\Windows\TEMPORARY INTERNET FILES\counters.dat|
|Event Category:||'File' class or access|
|Threat Name:||Common - Standardschutz:Ausführen von Dateien im Temp-Ordner für häufig genutzte Programme verhindern|
Why don't you take a look at testing with the latest patch?
It sounds like you have an environment that readily reproduces the symptom, so you should be able to quickly gauge the success/failure of any changes.
Otherwise, I do not see a need to repeat myself.
I complete disagree not from a technical but a sales view....
Testing is something that MCAFEE (INTEL) has to do for the customer (The company who pay money) not the other side.
The end customer has to do testing as soon as he mixes products. Like Mcafee and Trend or other special things.
There is high amount of False/Positive within Mcafee products related to other Mcafee products. It seems that they don't even test their own products against each other. Maybe on team is in India the other in CA?
We did hope that will and have to be better with TIE where every file has to be approved and i hope i never will see a false positive on any Mcafee DLL?
An end customer who buys Mcafee because their main sales argument is "That all is from one hand and runs in 1 EPO-console" can assume that all Products DLP/TIE/VSE/HIPS are working together without ANY False/Positive alerts.
Mcafee SHOULD releaseversion a whitelist like VMWARE or NETAPP does where you what Releases the Enterprise customer should run and is best practice.
The enterprise customer in here clearly stated THAT they are unable to see real Alerts or Outbreak Alerts because of the amount they will see with the false positive. Take that serious please.
To be fair
* When a new Fortigate Release comes out Engineers aks often "Do they test that in any form?"
* Mcafee is currently under merge with INTEL and the WISH to have all in one console can lead to complex integration. (Like the mess they made with Inetgration of DLP9.3 in 9.4 )
* We have huge virtual test labs but if something is from one producer they shall test. Otherwise pay they partner.
Here we go again...
|Threat Source Process Name:||C:\PROGRAM FILES\MCAFEE\TIEM\TIESTATUS.EXE|