Jump to content

0xDEADBEEF

Most Valued Members
  • Posts

    361
  • Joined

  • Days Won

    3

Posts posted by 0xDEADBEEF

  1. 15 minutes ago, itman said:

    Hybird-Analysis found the installer clean but noted this:

    I feel many open sandboxs' malicious rule matchers are dumb. You can throw in a slightly modified ccleaner and it will also trigger many "malicious behaviors".

     

    Here it is just the driver file that gets detected by the scanner. The original installer is just a game downloader, after you install the downloader and download the game, the driver will be released to the installation directory and get quarantined by the scanner. There are indeed "legitimate" drivers using weird ways to achieve some questionable goals, and sometimes those even make system vulnerable to rootkit infection. I am not sure what's the issue in this file though.

  2. Decided to post here because this has already been reported to the eset's lab email for several days but it has not been processed (or at least, the FP is still there). 

     

    password: "infected"

     

    the driver is from the installer downloaded here: https://honkaiimpact3.mihoyo.com/asia/en-us

    sample.zip

  3. 48 minutes ago, Marcos said:

    The problem with UAC must be caused by something else. If you empty the quarantine, then let ESET detect eicar and then open quarantine, you are not prompted by UAC?

    Yes, so if I empty the quarantine, re-add 1~2 malware to it, and open the quarantine in egui, the UAC prompt won't happen.

    48 minutes ago, Marcos said:

    As for ransomware instructions, each file would have to be unique in order to be quarantined. I for one don't recall ransomware that would create thoudands of unique files with instructions.

    That's valid, but still certain cases will have output encrypted files quarantined (usually if detected by AMS and failed to clean the main process). Just want to see ESET being robust in handling such extreme but possible cases. 

  4. 43 minutes ago, Marcos said:

    The total size of files in quarantine is typically relatively small. The product was not built to handle GB of files in quarantine; enumeration in such case may take a lot of time. I assume that you do not use the machine in a normal way and often scan and clean various malware files out of which many are quite big. In such case make sure to empty the quarantine on a regular basis.

    not necessarily. It is not the first time that I saw ESET move thousands filecoder encrypted files to the quarantine, and those can exceed GBs (and users definitely don't want to empty the quarantine in this case). In other cases I once saw that the ransomware may repeatedly release thousands of ransomnotes because ESET repeatedly move it to the quarantine. In such case the quarantine will be "broken" unless the user manually empty that directory.

    I think the bottom line is to add a load progress bar so that users are not confused. Plus I don't think repeatedly prompting UAC is considered "normal" when handling a large number of entries/large files.

  5. 56 minutes ago, Marcos said:

    Does uninstalling ESET and installing the latest Endpoint 7.2 from scratch make a difference?

    Also check permissions for C:\Users\%user%\AppData\Local\ESET\ESET Security\Quarantine. It should have full permissions set for: system, Administrators and the current user.

    I have found a way to reproduce this issue. After emptying the C:\Users\%user%\AppData\Local\ESET\ESET Security\Quarantine, the quarantine page is back to normal. After re-copying the quarantine files back, the same UAC issue appeared. I have sent you a private message containing those quarantine files. I hope those can help the devs identify the bug.

    Previously I've heard similar complaints about "bugs" in quarantine and log files: when there are too many entries in these sections, using egui to view them will display blank page. The solution is to empty them.... In this case, my quarantine is pretty large (> 2GB). I feel the QA may need to do some tests to cover such extreme cases.

  6. 45 minutes ago, Marcos said:

    Are you logged in as an administrator? An UAC prompt window should pop up only after you select to restore a file, not when you open the quarantine window.

    Yes, I am using admin account. This is the weird part.

    The only non default setting on my computer:

    1) UAC level is set to the highest

    2) Local security policy - UAC Behavior of the elevation prompt for administrators in Admin Approval Mode is set to "Prompt for credentials"

    But I don't think these two will cause this issue.

  7. System: Windows 10 Pro x64

    EES Version: 7.2.2055

    When trying to access the quarantine, a UAC prompt will show up (eecInt.exe). However, after granting the UAC elevation request, the quarantine page is still blank. Meanwhile the UAC elevation will prompt indefinitely. Not sure what kind of diagnostic info I should provide to help debug this issue.

  8. 2 hours ago, itman said:

    This might also be related to "Great Firewall" activity: https://en.wikipedia.org/wiki/Great_Firewall

    theoretically ESET should have update/livegrid servers in the "wall". So I guess this is more of a routing logic issue within the product. Previously users there try to modify host to force redirect the update server to the local ones. However I believe this had better be eventually fixed by ESET...

  9. 14 minutes ago, Marcos said:

    There have been no issues with ESET's update servers for years. Please carry on as follows:

    It is about ISP connectivity. The update can work but with high chance of failure during the download process. This issue has been there for some mainland Chinese users with certain ISPs for years. I've heard numerous users there in the past complained that they had difficulty updating the virus db (the download being extremely slow or the download failed in the middle)  or connecting to Livegrid. That's why I am providing the network dump here.

  10. 9 minutes ago, Marcos said:

    It's caused by obfuscation that the txt file was not detected.

    I think the sample I provided (not the one in this thread) is not even obfuscated. I don't know how the scanner actually does signature matching with text files but it is definitely not only the obfuscation's fault.

     

    Anyway I sincerely hope that this could be addressed in an elegant way in the near future :)

  11. 6 minutes ago, itman said:

    The first is about Eset being able to detect the malware script when it is created on the local device in .ps1 format. Appears that advanced hueristics will actual run the script via Powershell in its sandbox. This will allow for examination via AMSI. In this case, Eset will detect the malware and can delete and quarantine it.

    I am not sure if the detection from realtime scanner utilizes the AMSI or not. AMSI to me is like AMS to PE scanning, which will only be triggered upon execution.

    10 minutes ago, itman said:

    Definitely the answer is no if its encrypted with a strong cypher.

    I think the core problem here is to detect what type of script the txt file is in (e.g. js, powershell, or anything else). And this may be non trivial. Apparently there are samples which can even trick AMSI, however here with unobfuscated code the only possible explanation is that the scanner doesn't even bother to check if txt file is actually js or something else.

    12 minutes ago, itman said:

    From what I can tell from this analysis to date, there appears to be a deficiency in the Eset file scanning whitelist processing

    This is what I am thinking :)

    The subtle thing here is that if people want to optimize the realtime scan performance with aggressive caching, they had better make sure all possible ways of execution can be guarded to avoid leakage. For example, what if there are 3rd party interpreters that is not going through AMSI? In the old days, people have tried to use some installer's interpreter to bypass the "guards". There are many possibilities here. 

    18 minutes ago, itman said:

    One solution would be for the HIPS to monitor for existing file renaming where the extension was changed to .ps1. When this occurs, the original whitelist status would be removed. It appears that Eset presently special cases .ps1 files overall in that these files are indeed always re scanned . But it appears so only if they were originally scanned as .ps1 files.

    I was thinking about this before I start this thread. However, it is not an elegant solution, and there may be other possibilities to bypass with similar principles..

  12. 22 minutes ago, itman said:

    PowerShell never started execution and Eset detected the malicious script via AMSI scanning:

    even in 1903 this is the case. So apparently AMSI is working fine in 1903.

    This is the most trivial case and I'd be surprised if this can bypass the protection

  13. 2 minutes ago, itman said:

    Please do as you theorized; rename in another script the .txt script to a .js script and execute it. Does Eset now detect it?

    for powershell script, I have already given you the answer in the prev replies:

    On 7/3/2019 at 3:57 PM, 0xDEADBEEF said:

    Another thing to note is that even though such case may "slip through" the realtime protection, when actually executing it, the engine will anyway inspect it again. So if this is indeed something unexpected, at least it is not something really bad so far.

    Of course I said this after doing the actual experiment. However, it is not always the case (I can enumerate at least 2 other possible ways but I've yet tested them)

  14. 6 minutes ago, itman said:

    As I stated in a previous post, this is due to the fact the .txt file contains obfuscated code. Additionally, if the script was packed or encrypted, Eset would not detect it on download or subsequent scanning. This is because the script will only decloke when loaded into memory at execution time. This is what Microsoft created the AMSI interface for. It is a memory sandbox where the script code can be examined by AV solutions after it has been decloked, but prior to actual execution.

    See my PM. I'm not going to discuss it here before they say it is expected and acceptable

  15. 36 minutes ago, Marcos said:

    That is my understanding as well; with AMSI-enabled OS's the file should be detected on execution of the interpreter (haven't tested it though but in theory it should work).  Also if such file is included in an archive, it would be scanned by web protection and would be detected regardless of the extension.

    However in my test this is not the case. My test env is Win10 1903 so AMSI is enabled. I did no source code change to the payload. What's worth noting is that I cannot reproduce the case on EES. Only EIS has such issue.

    I also uploaded the sample to a webhost to simulate the user download scenario with a different hash, still no luck...

×
×
  • Create New...