Andrew3000
-
Posts
15 -
Joined
-
Last visited
Posts posted by Andrew3000
-
-
Is it normal with Microsoft EDGE that LiveGuard sends the cache and .crdownload files to the sandbox?
-
6 hours ago, Marcos said:
Please check if the issue with the delay in sending files to LiveGuard persists after switching to the pre-release channel in the advanced update setup.
I switched to the pre-release and so far it seems to be working, if not I'll let you know!
-
The bug that doesn't send files to LiveGuard happens to me too.
The file is pro-actively blocked but no analysis in progress is notified (yes if you try to access the file). No files sent appear in the logs.
After a while it appears, "ESET LiveGuard takes longer to analyse the file..." -
It's probably the download cache
-
About the fact that many users decide to keep LiveGrid disabled is a problem, for you but for all users.
Now I don't remember well, is LiveGrid disabled by default? If yes could it be enabled by default?
I think the main concern of users is privacy, you should work on that! Awareness campaigns? Could LiveGuard be used to spur users on? -
In my opinion LG/EDTD should be implemented also in the EIS version. Only as addons or implemented in ESSP would not increase your sales since the price is higher than your other products but especially compared to your competitors on the market. Implementing it in EIS would certainly increase the load on your servers but you would also have a better and more updated cloud network to defeat new malware since the result of the sandbox process is then transmitted to all devices that have enabled the feedback system. Also because LiveGrid in its current state takes a long time, LG/EDTD 5 minutes and spreads the result to everyone.
-
For Eset business beta testing is it enough to just install the software? Is it possible to integrate it with eset protect cloud?
For Eset Internet Security 15 beta testing, is it still possible to join the insiders program? -
1 hour ago, NewbyUser said:
Already read and I don't see any differences with EDTD. So they are the same thing but with different names?
-
5 hours ago, Marcos said:
It's basically whitelisted files, files signed by Microsoft, files not carrying malware, such as text files, etc. that are not submitted so any file that might be potentially malicious should be submitted. Below is a screenshot of what happens if you attempt to run a new malware extracted from an archive:
Differences with EDTD?
-
Are there any betas for non-ARM devices?
-
Mmm i don't have any beta projects
-
I've two problems:
First:
File exclusion does not work with a normal scan, custom scan or inactivity scan.
I added files to exclude but Eset still detects them as dangerous. It's frustrating every time I have to check which Eset files might be deleted by mistake.
Exclusions only work for real-time protection but not for scans.Second:
When malicious software is found, the "add to exclusion is not clickable (grayed)" option (see image below).
-
8 minutes ago, itman said:
Let's get back to the methodology employed in this test namely:
There are only three ways a Python script can be executed on a user device:
1. The user manually installed Python.
2. The attack involved downloading Python and installing it.
3. As posted previously, the attacker created an executable with the Python engine component and malicious script contained within.
Methods 1). and 2). are not viable scenarios since most users do not install Python and malware installation of it would be extremely "noisy."
That leaves number 3). as the most likely way Python based malware would be deployed. And this method needs attention by Eset and other AV vendors. Also this is not an easy mitigation in that the presence of the Python engine code within the .exe is in itself not malicious. It is the code within the script that is malicious. And, it is a given that the script code will be hidden and will not reveal itself until the executable unhides the script code in memory prior to executing it via the Python engine. Compounding the issue is Python scripts cannot be examined by the Win 10 AMSI interface when executed this way; even if it did so which BTW, it does not. This leads to two possible detection scenarios:
1. Improved sandboxing analysis for any executable that contains Python engine code remnants and detection of script code malware after it is unhidden in memory.
2. After sandbox detection of Python engine code remnants, alerting the user of possible suspicious process activity. This alerting could be conditioned upon a number of factors such as process reputation status; e.g. unknown, signing status; e.g. unsigned, etc..
I believe number 2). is the only viable solution given the capability of Python script code executed this way. Also it is not the norm for legit application software to be developed this way.
What's wrong with you? The python script is a simple file executer nothing else, it's like double clicking with the mouse but the process is automatted
-
I don't want blame Eset or anything else, but I think Eset Failed hard. However, this should make us reflect as TPSC has also been surprised by the result. The pro active defense is one of the highest he has tested but despite this the PC was infected. At this point a question arises: what is the problem of Eset? In my opinion, it can not stop the execution of Malware that bypasses the protection by infecting the device
Eset and Task manager conflict or bug?
in ESET Internet Security & ESET Smart Security Premium
Posted
It happens to me too