itman
-
Posts
12,466 -
Joined
-
Last visited
-
Days Won
329
Posts posted by itman
-
-
On 11/6/2018 at 5:06 PM, CSA cucuta said:
I tried to delete it manually by removing the root folder from this but it comes back and the only solution I found was to install the Malwarebytes and place it to scan if it detects and it finishes but when removing or stopping the malwarebytes this virus comes back.
Hopefully you still have your MBAM logs? If so, check if MBAM recorded the hash value for agent.exe in the log file. If this hash exists, please post it in a forum reply. We can then check out actually what MBAM is detecting.
-
19 hours ago, TomFace said:
Well changing the task to the logon/dial up setting did not make any changes
.
Short of Eset adding a trigger event to the Scheduler to detect establishment of a broadband network connection which I honestly don't believe is going to happen, what you could do is the following. Once you establish your broadband network connection after boot time, logoff and then logon on again to Windows. This should trigger the existing Eset scheduler rule to check for updates at logon time.
-
Assuming this malware was a result of an endpoint user download and installation, I will state this.
Regardless of how the user responded to the Eset PUA alert in corporate environments, users need to be prevented from installing software directly or indirectly via appropriate Windows software restriction polices to prevent this activity.
-
A bit more detail on this.
Per Trend Micro, Eset did detect an earilier version as Win32/Dexon.A; as a PUA: https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/pua_dexon .
So a couple of possibilities as to this infection:
1. This is a new undetected variant.
2. Eset PUA protection was not enabled on the endpoint devices.
3. The delivery payload was a worm. It infected the server and spread Dexon via SMB. Likewise, it could have been PUA software installed on an endpoint and spread via SMB.
My money is on number 3).
Based on the modifications this malware makes to Win system directories and registry, extensive cleaning will be required to remove it.
-
1 hour ago, kapela86 said:
And it doesn't on mine, also Win 10 x64 1803 Pro connected to Active Directory, tested with an account that is only standard user. I will test this later at home on Win 7 x64 Home Premium and 10 x64 1803 Home
I stand corrected. You can write to that directory w/o issue; at least with limited admin privileges.
For some reason, I got a admin popup when testing which might be due to the Eset HIPS rule I created to monitor write activity to the directory.
-
Just now, kapela86 said:
No it doesn't.
It does on my Win 10 x(64) 1803 build.
-
I believe if Edge is set as the default browser and BP&P is started manually, there are no issues. At least, I could do this in prior Eset vers.. I have not tested same on ver. 12.
However, a protected BP&P web site will not auto trigger BP&P startup in Edge due to enhance the AppContainer protection it uses preventing the necessary BP&P .dll injection.
-
7 hours ago, kapela86 said:
you put lnk files in C:\Users\you\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ they will launch at user login
This directory requires admin privileges to write to. Eset's historical stance has been this is sufficient protection.
If you have Eset Endpoint, a HIPS rule to prevent *.lnk file creation in the directory could be created. Unfortunately, like HIPS wildcard capability still doesn't exist in the retail versions to do the same; despite repeated user requests for it over the years.
-
This might be how the .lnk file ran at startup:
Quote3: StartupAutorun
If the resource 105 begins with the dword value “3”, a LNK file will be created in the Start Menu. The resource will also provide a description for the shortcut file, the path for the target and the filename for the LNK.
The IShellLink interface is used to create the shell link.
https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf
-
17 minutes ago, chockomonkey said:
However, why wouldn't this show up in ERA or local logs?
Can't comment on ERA since I am not familiar with.
As far as not showing in the local logs, I suspect that depends on the action selected. Were all the detections shown manually blocked?
-
4 hours ago, kapela86 said:
Yeah I removed it, but there would be no harm leaving it as it is harmless on its own, it was obvious it's not a standard system key, I even gogled mssccfile, only 1 result was found
As far as I am aware, a .lnk file cannot be run directly from a startup directory. For example, .lnk files are present in the Windows Accessories directory, etc.
From this Sentinel article:
QuoteMethods for Using Windows Shortcut File or .LNK
Windows shortcut files are not only valued for deception capabilities, but also for the flexibility in delivering malicious payloads. .LNK can be used to:
- Run CodeIn the case of Stuxnet (CVE-2010-2568 and MS10-046), the .LNK files were used to start running the Stuxnet code. The only requirement was that the icon simply appeared, whether from an infected USB drive, a network share, malicious website, or packaged into a document. Even without clicking on the icon, it was able to deliver the malware’s payload.
https://www.sentinelone.com/blog/windows-shortcut-file-lnk-sneaking-malware/
It does not state icons on the desktop for example. So it would be informative to know just how this .lnk file was executed.
-
See this thread for reference: https://forum.eset.com/topic/17439-scrinjectb/
-
Getting back on topic, one noted security researcher has strongly hinted that a bypass of WD's sandbox is possible. He also issued a call to penetration testers to do just that. Now its just a matter of time, not long I suspect, that we will have a bypass POC to review:
QuoteDon't run the sandbox as the SYSTEM user would be a good start :-D In all seriousness this is good work on the sandbox but running under SYSTEM risks hitting bad coding patterns which only check the authentication ID, for example the exploit for https://bugs.chromium.org/p/project-zero/issues/detail?id=1439 …https://twitter.com/epakskape/status/1055909122057457664 …
James
-
11 minutes ago, TomFace said:
What I just did was to change the the update setting (see below). Maybe this will help (I do not have a dial up connection, but did not see another connection choice in creating a new task).
I believe that option only applies to a dial-up connection. That is why it is disabled by default.
The Eset task that controls updating at boot time is "Automatic update after user logon."
-
1 minute ago, kapela86 said:
Well it's in HKEY_CURRENT_USER so current user has rights to edit it and any malware run from that account can also do it.
What I meant was the key needs to be removed. It doesn't exist on my Win 10 x(64) 1803 build.
-
Must say this one is a bit unique in the combination of using a .lnk file from the startup folder pointing to Powershell to run something from the registry. Normally .lnk malware attacks are e-mail based: https://blog.trendmicro.com/trendlabs-security-intelligence/rising-trend-attackers-using-lnk-files-download-malware/
The first concern would be it appears that malware was able to create this registry key, HKCU\Software\Classes\mssccfile, which needs to be addressed.
Also if PowerShell was set to "Constrained Language" mode, the attack would have failed since PowerShell is calling a .Net subassembly which would not be allowed in this Language mode.
-
44 minutes ago, Rami said:
It's funny when the AV is relying more on the cloud more than the local virus database , so when having a PC without internet some AVs fail to do it's job because they rely on the cloud.
As evidenced by Panda and TrendMicro offline detection rates which are heavily cloud based solutions.
What might puzzle some is WD's 78.6% offline detection rate. No surprise here in that WD's signatures are not on par with the other major vendors. WD's block at first sight uses the cloud. Also SmartScreen which is WD's blacklist detection only updates periodically and also goes to the cloud for most recent updates. Add to this SmartScreen is most effective against phishing and substandard on everything else. I have used it on IE11 for years and can count on one hand the number of alerts I ever received from it. Non-browser based Win 10 native SmartScreen runs as an unprotected medium integrity process and as such, can be easily disabled by malware. At least now, the kernel will detect this and restart it but malware only needs microseconds to run itself.
Bottom line is offline protection capability is extremely important since the first thing any decent malware will do is to try to tamper with your network settings.
-
3 hours ago, cutting_edgetech said:
Eset is no longer blocking my schools login screen, or the login itself when using Interactive Mode. Also, i'm able to download resources on Blackboard again.
I have made no changes. I don't know if Eset made any changes/fixes or not.
Good to hear the problem has been resolved.
-
Another disturbing trend in AV lab testing in regards to WD is its not running with default settings. This is after the fact evidence of Microsoft's "influence" over the labs.
First, a bit of supplementary information about most AV realtime tests. The majority of AV labs do not penalize for false positives on these tests. The labs do penalize for then on their more advanced "full spectrum" tests that are performed less frequently.
I know of at least two AV labs that have modified WD's "block at first sight" option to run at the highest, or maximum protection level, on their realtime tests. With this setting, WD will block almost all unknown processes. This setting also significantly raises the number of false positives by WD.
Starting "to get the big picture" folks of what is going on?
Next is the most recent SE Labs realtime test where WD tied both Eset and Symantec for second place standings. You have to dig in to the Appendix section of the test report to find that WD was using the recently introduced WD plug-in for Chrome; the browser selected for the test. This plug-in is for all practical purposes the same as the SmartScreen option that is auto enabled in both IE11 and Edge. The problem here is this is not a default configuration for Chrome. The user must first know the option exists and then, configure Chrome to use the plug-in. Again, we see evidence of Microsoft's "influence" against this lab.
Starting "to get the big picture" folks of what is going on?
-
3 minutes ago, Rami said:
Weird thing is that I do use Firefox at Home , while being at Interactive and then to Automatic I didn't have any problems with it and with ESET v12
As far as the OP's issue, I also suspect Eset's Network, Application Experience, option might be a factor. Application Experience is only active when the firewall is in Interactive mode. Its purpose is to alert you when a program's hash value changes such as would happen as a result of a program update. It also checks existing firewall rules for the program and warns of insecure existing rules. I have seen this feature perform strangely, warning of existing rules that were OK and then deleting those rules. One option would be to temporarily disable Application Experience and see if that resolves the issue.
I didn't mention this option previously because the OP stated he had reinstalled Eset and the Firefox issue persisted. What I didn't ask was if @Berez imported his previous Eset settings after reinstallation? Do you do that @Berez?
-
4 hours ago, Rami said:
Did you try to uninstall Firefox and remove all settings and re-install it and see if ESET prompts you to allow/block it if you are running in interactive , or it Automatic it should automatically allow it.
I also was going to recommend this as the next step.
It appears Firefox is the only browser where you are having issues when run in the firewall's Interactive mode. If there was any browser that would show problems, I would expect that to be Chrome which you stated alerts fine in Interactive mode. Also, prior to reinstalling Firefox, manually delete any existing firewall rules for it.
Further support for a Firefox reinstall is when you manually create a firewall rule for Firefox's outbound activity, Firefox still doesn't connect.
Another thing you can also do is check your Windows Audit Failure Event log for blocked Firefox connections. This should shed some light on what is actually blocking Firefox outbound connections.
-
15 minutes ago, novice said:
I am talking about decency here....
That's a moral concept. Business ethics is for all practical purposes today some archaic concept delegated to the dung heap.
-
5 minutes ago, novice said:
It is not about liking or disliking ESET, but comments from a senior contributor ,
The problem, my man, is you're fixated on AV lab tests as being the "ultimate authority" in security product capability. You seem to forget they are nothing more than just that …. tests. And many of those "tests" are currently being closely scrutinized by the security community for impartiality.
To add to my "propaganda" comment in regards to Microsoft is no other security vendor has close to the financial resources and the resultant influence those resources can gain than Microsoft has.
-
1 hour ago, Marcos said:
Even after disabling web protection new variants are detected as Suspicious object
Well, now I am confused, Isn't this how, and now thankfully, Eset would detect new malware for which there isn't an existing code signature for? I assume a behavior signature was triggered by the process's activity. Granted Eset's DNA signatures are pretty good against variants but the code could have been altered. Then the malware perpetrator tested against major AV detection.
.
Virus Dexon Agent.exe no detectado por el antivirus ESET Endpoint (Dexon Agent.exe virus not detected by ESET)
in Malware Finding and Cleaning
Posted
Researching this a bit further confirmed my suspicion that there is a worm version of Dexon. When it surfaced in 2016, Microsoft was the only major AV vendor that detected it: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Worm:Win32/Spraxeth.A
This lead me to the OPSWAT site that yielded the following file hash:
https://metadefender.opswat.com/results#!/file/e34f6c0712ca497582bd47adb92b9639/regular/overview
Submitting that file hash to VirusTotal yields that Eset does not detect it there: https://www.virustotal.com/#/file/dcab729a04d58c0b1d4971a75f9a2410bcbee117f8346db25aee0794bebc1611/detection
Something for Eset to check out if the OP can submit a sample of it.