Jump to content

itman

Most Valued Members
  • Posts

    12,210
  • Joined

  • Last visited

  • Days Won

    321

Everything posted by itman

  1. Eset staff, @JamesR , wrote the code. He only infrequently visits the forum. You should PM him about your issue for a faster response.
  2. This is usually indicative of a coin miner. You can also try SysInternals Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns. Download and unzip the folder; no installation required. Click on the WMI tab and see if anything is shown.
  3. Unfortunately, no decrypter currently exists for the 5.2 version as far as I am aware of.
  4. One final comment. What you are doing is ill advised to say the least. Refer to the LoJax mitigation section of the Eset .pdf link I posted previously. Re-flashing the UEFI doesn't always remove LoJax in which case, the only alternative is to replace the motherboard.
  5. Continuing my prior posting, I realized I didn't answer your question why Eset is detecting LoJax on some network notebook devices but not others. My best guess is: 1. The attacker entered your network remotely; most likely via RDP. 2. The attacker dropped an undetected worm into the network. In either case, the attacker was able to infect devices currently attached to the network. So my assumption as to why some devices were not infected with LoJax is they were not actively connected to the network at the time of the attack. Another possibility is the uninfected devices are newer Lenovo notebooks. Lenovo has patched the UEFI to prevent a LoJax infection although I have no direct knowledge this is the case.
  6. Slightly change existing run time. I changed mine from 6:00:15 PM to 6:00:16 for example. Save you change. The Log maintenance scan will immediately start running since its missed scan option is set to run ASAP. Believe this is also a bug but doesn't cause any harm. Thereafter, the scan will run at its scheduled time.
  7. One benign reason is the software is trying to update itself. It should have an option to change/disable auto updating. Disable auto update and if the outbound connections cease, you have resolved the issue. If the outbound connections persist, it could be indicative of malicious or other undesirable activity.
  8. @Marcos, "playing" with the scheduled scan time setting did the trick. Log maintenance scan ran at its scheduled time:
  9. Appears it boils down to what is Eset detecting when it pertains to LoJax: https://www.eset.com/us/about/newsroom/corporate-blog/what-you-need-to-know-about-lojax-the-new-stealthy-malware-from-fancy-bear/. In the Lenovo forum link I previously posted, Absolute, the software vendor, discusses how Computrace functions. Without its monitoring service: it appears the code implemented in the UEFI firmware does nothing. Assumed is the code in the firmware will only connect to Absolute's monitoring servers. Note that the legit version of Computrace's firmware code is named LoJack. The malicious version is named LoJax. Here's an Eset technical write up on LoJax: https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf . Bottom line - just because there are settings in a device's UEFI indicating Computrace is installed does not mean that you are infected with the LoJax malware.
  10. Appear the IPs are associated with a domain server - per Robtex: That server appears to have one or more malicious domains associated with the domains it is hosting:
  11. You also need to post the IP addresses associated with these alerts. It's possible a redirect is going on.
  12. My question is why is this type of software attempting to connect to the Internet with the activity you posted? It is basically just software to create a .iso file for the most part. At most, the only outbound connection it would need is to the vendor's server for software updates.
  13. You might want to export your existing settings. Then download the offline installer for 12.1.31. Uninstall Eset. Reinstall 12.1.31 and see if that resolves your existing scan missing log issue.
  14. It only occurred with the "unscheduled" scan as a result of time change. The legit scheduled scan showed the animation.
  15. No problem with my Eset installation with scheduled scan logging as the below screen shot shows. Also I was wrong about my prior statement about scan starting immediately after a time change. It did start running and worse, it does not now show the scan is running via Eset desktop toolbar icon animation!
  16. Are you stating your log file issue has been resolved?
  17. OK. I just modified my scheduled scan to run today at 11:25 AM. Will report back after scan runs if it created a log entry with details provided. A short time ago, I received a modules update. What I now observe when modifying an existing scan run time is it doesn't start running the scan immediately when saving my changes. So it appears Eset fixed that issue.
  18. I am trying "to get a grip" on what you are describing. Are you stating that you are not receiving any detail log information in ver. 12.1.31 as my below screen shot shows for my EIS installation?
  19. What your narrative describes is akin to something out of a malware sci-fi horror movie. Are you stating that every device you have connented to your network in the last 10 years has been affected by what you posted?
  20. Again, not on my Eset installation. Perhaps Eset not in sync with U.S. DST? -EDIT- Just occurred to me the problem might only manifest with scans that existed prior to the 12.1.31 upgrade. You created a new scan to test. I will edit the Log maintenance scan and see it that eliminates the problem.
  21. Well, daylight savings time is now in effect. Wanted to see if this resolved the default log maintenance scan running an hour ahead of schedule as noted in the above linked posting. It did not. That scan ran an hour ahead of schedule today. Definitely appears their is some type of time issue between Eset scheduler and system clock.
  22. Below is a screen shot of what is shown from Eset desktop toolbar icon when my scheduled scan is running in ver. 12.1.31:
  23. Appears to me is what you are observing is Eset's default scheduled scan after every module update:
×
×
  • Create New...