Jump to content

itman

Most Valued Members
  • Content Count

    7,775
  • Joined

  • Last visited

  • Days Won

    191

Everything posted by itman

  1. I received the new Eset Internet protection module, 1416, today and have no issue with either of my two e-mail providers in Thunderbird. One is using IMAPS - SSL/TLS and the other POPS - SSL/TLS. Are the people having issues using IMAP - STARTTLS or STARTSSL ?
  2. I will also add that unlike Firefox which has set preference to Win root CA certificate use by enabling this option: security.enterprise_roots.enable true Thunderbird has not done so. If the AV certificate used by Thunderbird gets corrupted or whatever, the result is what @Marcosdescribed. Disabling SSL/TLS protocol scanning and re-enabling it, repopulates the Eset certificate in Thunderbird's Authorities certificate store.
  3. Let's again review your test procedure: It appears that WD is "monitoring' Autoruns results. This makes sense since both are Microsoft base products. You then repeated the same procedure and expected Eset to trigger on Autoruns findings. Namely, the found Autoruns entries flagged and associated with this malware. The main point to emphasis here is WD's real-time behavior was identical to Eset's in regards to the original detection and removal of the malware sample. It was only after Autoruns was executed did WD become aware of the malware related registry and scheduled task
  4. Here's my take on what is going on with this malware based on the posted WD screen shot of what was cleaned. The malware is actually starting from a HKCU run key. This in effect is a UAC bypass since the bugger will run even under a standard user account. It appears the next step is it sets up the scheduled tasks and then dynamically invokes task manager to run those tasks. I believe the only reason a scheduled task related to this bugger shows in the posted Autoruns screen shot is Eset detected and deleted the app that eventually would have removed the scheduled task shown.
  5. As I recollect, older versions of WD were also quite effective at removing residual malware traces. Reason? WD's signatures used to suck big time until they finally farmed that out to a third party a while back. As such, once a sig. was created, appears Microsoft created in essence "metadata" associated with the malware to find system modifications once the malware was discovered on a device. Kaspersky deploys system snapshot capability that will rollback system modifications. However, there is a performance degradation associated with that processing. As a rule, most current AVs suc
  6. Yes. Here's a Microsoft article detailing Windows versions vulnerable to EternalBlue: https://support.microsoft.com/en-us/help/4023262/how-to-verify-that-ms17-010-is-installed Also I realized why srv.sys no longer exists on my device. Windows will auto remove SMBv1 10 days after installation if it is not used. Additionally if srv.sys exists on later Win 10 installations, you are not vulnerable since this driver has been patched against this exploit.
  7. It should also be noted that Node js can arrive on a device via legit software. Visual Studio is one example: http://jameschambers.com/2015/09/upgrading-npm-in-visual-studio-2015/ . However, it is not activated by default and some additional setup work is needed. -EDIT- Another source notorious for installing server side Node js crud is Adobe products: https://community.adobe.com/t5/photoshop/can-i-turn-off-node-js-server-side-javascript/td-p/8731592?page=1
  8. @Marcos has anyone from the Eset side explored whether using "/?/" in a firewall rule path specification would work? I mention this because I noticed some Win 10 registry entries using this path specification. Appears to be something Windows natively supports; at least for Win 10.
  9. We can also assume this Node js based crud was created prior to the Eset trial version installation. Do yourself a favor and purchase an Eset license. -EDIT- Also heed @Marcos advice about getting rid of Node Js. Its presence opens you up to ransomware attacks that deploy components of it. Ref.: https://soanvig.github.io/node-ransomware/
  10. 1. Upload in your next posting the logs @Marcos requested. 2. You can also use Win Task Manager to review task startup history related to Win startup times for suspicious task startup entries. Or, you can use SysInternals Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns to do the same which will scan all Win startup tasks. This tool can also be configured to use VirusTotal to scan all startup entries. Warning! Do not remove anything anywhere unless you know what you are doing and you have provided a recovery method to restore whatever you removed in case you
  11. The legit installation path for Node js is C:\Program Files\nodejs. However on your device, Node js is installed in C:\Program Files (x86)\nodejs. This is highly suspicious. Also it is not easy to dump a file into C:\WINDOWS\TEMP\ directory in Win 10. You don't even have read access to that directory if running under default limited admin account. As such, I believe a scheduled task was created to run with highest privileges that is running at system startup time. This task is creating the .exe in the C:\WINDOWS\TEMP\ directory that Eset is detecting. One possibility is the scheduled task
  12. I have asked in the past if an Eset export file created on a prior version or within version release would cause issues when imported to a later Eset version/release. I was told by @Marcos that this would not be an issue. Additionally, I have done this multiple times in the past w/o any apparent issues from upgraded version/release. However, I don't use the firewall in Interactive mode. As such, I never created any rules in this mode.
  13. The first question is did you purposely install Node js. Or, does any software you have installed use Node js? Ref.: https://www.geeksforgeeks.org/installation-of-node-js-on-windows/ Per the linked reference, node js is installed on your device as evidenced by the creation on this directory, C:\Program Files (x86)\nodejs. However, a malware based install of Node js can be evidenced by creation of this Windows environment variable: Also Eset's detection appears to be for this file, C:\WINDOWS\TEMP\ec4b3ab6-14a3-3a24-522c-23f67832b6d1\e4afb5cd-2616-2ade-b688-275bb99d02
  14. I believe what @Marcos stated in regards to cleaning activities applies if Eset detects the malware at execution time. If Eset never detected the malware at first execution time, it would have no way of knowing what system modifications were made. Re-executing the malware again after first execution will in all likelihood result in different behavior by the malware. Assumed is it will not perform some or all of the previous system modification activities since they are no longer needed. Did you recreate your VM test environment for each test from a totally pre-infected system state?
  15. Follow this guide: https://support.novastor.com/hc/en-us/articles/360011403653-How-to-repair-the-EFI-bootloader-on-a-GPT-HDD-for-Windows-7-8-8-1-and-10 Recommend the repair from installation media option. Note that you will have to select the USB attached drive via number assigned to it. Do not use "0" as shown below since that is most likely the Win OS boot drive: Make sure this is done: You will have to research further if EFI partition is not FAT32 formatted.
  16. Here's what happened when I repeated this: 1. First alert is from Windows Security Center. 2. Second alert is the Eset popup alert. Clicking on the Eset popup alert, opens Eset GUI showing that real-time protection is disabled. I enable it. But appears this is not enough to override Eset original protection pause status. This must be done manually via right mouse button click on Eset desktop toolbar icon and removing prior pause status. Suspect this is the source of the constant Eset popup.
  17. I can verify the tool no longer works on Win 10 20H2. Believe the issue is the driver it is attempting to verify, C:\WINDOWS\system32\Drivers\srv.sys, no longer exists. In 20H2, it is named srv2.sys. Guess tool needs to be updated in that if it can't find srv.sys, you also are not vulnerable to EternalBlue.
  18. At this stage, I would say the popup is bogus. First, the Eset GUI home screen shows no issues with Eset installation. Next is the fact the popup origin states its from eguiproxy.exe. All that program is used for is to load the Eset GUI interface shown in the posted screen shot. Check Window Security Center and validate that Eset shows as real-time and firewall protection, that both are turned on, and Windows firewall and Defender are turned off.
  19. What Windows OS version are you using? The legit version of explorer.exe is loaded and started by winlogon processing at system startup time. Appears something has created a scheduled task and it is attempting to load a hacked version of explorer.exe. Suspect other malware activity is occurring along the lines of process hollowing or like activity to explorer.exe. That is the malware is loading explorer.exe in a suspended state and injecting apparently coin miner code in to it. It then un-suspends explorer.exe allowing this hacked version to execute.
  20. According to Eset VirusRadar database, Eset has a sig. for Win32/KillFiles.NJT. The infection rate for this malware since 2016 for all Win32/KillFiles variants never exceeded .1%. In the last month, the avg. rate was .01%. In other words, the chance of getting infected by this is nill: Whatever this bugger is, its not being detected as Win32/KillFiles.NJT. My best guess is someone "tampered" with the original uninstaller to bypass sig, detection.
  21. Appears what is being said here is these uninstallers are in effect borked uninstallers. The question is if they even meet the criteria of potentially unwanted or unsafe applications. Note Eset doesn't have a category for potentially dangerous applications. The first and major issue here is the app uninstallers do not exhibit any undesirable behavior if created in their assumed default installation directory. Next, the undesirable uninstaller behavior appears to occur when the aforementioned is not the case. Finally and implied is that someone is maliciously deploying these uninstal
  22. Then I would say the issue resides in the FireFox version used on this system. On this PC and to start, temporarily disable Eset SSL/TLS protocol scanning. Report back if this resolves the issue with Firefox on this system.
  23. I don't know what you are trying to do here, but a https URL for the web site doesn't exist:
  24. Did you try to add a second exclusion for https://*/*.bat ?
×
×
  • Create New...