Jump to content


Most Valued Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by itman

  1. @foneil , this Eset KB: https://support.eset.com/en/kb6121-windows-backup-failing-error-message?ref=esf , needs to be revised. It should state that diskpart via command line prompt needs to be run to determine which volume the backup drive actually resides on. Then the drive letter associated with that volume number used in creating Eset exclusions for Win7 Backup utility.
  2. The following confirms my suspicion of what is occurring in firewall Automatic mode in regards to Application Modification detection: Here's a firewall rule alert for explorer.exe for cert. data download on Aug. 3: Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;SHA1;User 8/3/2020 8:53:01 AM;Decision on allowing communication delegated to user;Delegated to user;192.168.1.XX:58387;;TCP;Block outgoing explorer.exe x(64) communication;C:\Windows\explorer.exe;9BF023766E369E6F6DE45F0C349749E6FC8ABDAC; Here's a firewall rule alert for explorer.exe f
  3. Show the full path name for the .exe Application Modification is throwing an alert on.
  4. Do you have the Application Modification setting of "Allow modification of signed (trusted) applications" enabled? On the other hand, the UWP app might not be signed.
  5. The only time it appears for explorer.exe is when I am verifying a cert. for an .exe and explorer.exe has to connect w/Microsoft servers to download cert. data. This certainly would not cause explorer.exe to be modified in any way.
  6. I also believe this doesn't work right in Automatic mode. The only time I have seen it trigger is in regards to explorer.exe. I have firewall rules that monitor; Ask mode, any outbound communication from it. Every once in a while, I get this an Application Modification detection alert after my firewall Ask rule has triggered. Believe this occurs when I manually allow the outbound traffic. I really could never figure out why that Application Modification alert appears. This certainly isn't because the explorer.exe rule is a "permissive" rule.
  7. Application Modification Detection only works if the firewall is set to Interactive mode. As such, no need to add exceptions to it unless the firewall is set to this mode.
  8. Of note is the IP address for your managed switch does not show in either xARP or wnetwatcher output display. It really appears to me that xARP is falsely identifying the switch as source of the ARP spoofing attack. You can try to enter: arp -a from a command prompt window and see if it shows the MAC for the managed switch. One possibility is the physical placement of the managed switch behind the unmanaged one is hiding it from the router.
  9. It also appears that diskpart via command prompt is the easiest to use to determine correct volume number. As shown below, my Win OS is actually on volume 4.
  10. The only thing I see here is you connected your managed switch to your unmanaged one. This adds zip security-wise since all packet are auto forwarded unrestricted by the unmanaged switch. You need to search the web on how to properly secure your managed switch. This first thing would be to ditch Telnet in favor of SSH if there is any remote access to the switch.
  11. This article shows how to determine which volume the OS actually resides on: https://superuser.com/questions/1058217/list-every-device-harddiskvolume . It is this volume that must be specified in Eset exclusions.
  12. Do you have multiple hard drives installed on your PC? Depending on cable connections, the Win boot drive might not be actually Disk 0 as per my below screen shot. Appears the Eset KB article assumes a single drive system as far as exclusions go. Also, the KB article is date April, 2020. This is prior to the Win 10 2004 release. This release might have added additionally EFI files and the like that need exclusion.
  13. Read through this: http://articles.manugarg.com/arp_spoofing.pdf . As far as I am aware of, a switch can only be compromised to conduct ARP spoofing from another compromised device on your LAN. Also, it is debatable if Eset's ARP spoofing protection can detect switch ARP spoofing. As I interpret it, it is designed to detect spoofing activities at the gateway/router level. You can verify xARP's findings using another utility from Nirsoft: https://www.nirsoft.net/utils/wireless_network_watcher.html . Although designed for wireless networks, it also works for small wired networks.
  14. Then it appears you have nothing to be concerned about.
  15. Ever play this online game: https://dragcave.net/view/j7niC ? Also the device shown appears to be a Smartphone. Samsung does make a Galaxy J7 phone model. As far as Smartphone devices showing up on your Wi-FI network connection that you don't recognize, assume someone either internally or externally is able to hack your Wi-FI connection.
  16. The Eset alert clearly indicates its source is IDS protection where ARP poisoning monitoring is enabled by default. I can see how a switch will be problematic to Eset's ARP poisioning protection. First, read this: https://community.fs.com/blog/switch-mac-address-whats-it-and-how-does-it-work.html for all the "nitty gritty" details of switches and MAC. Of note: I suspect your switch is set to dynamically store device MAC's it encounters in it's internal MAC table. Eset's IDS appears to treating this as some type of MAC spoofing activity. The solution here is to exclude the
  17. Via Win 10 Settings, verify that Eset Proxy GUI setting is enabled in "Select which icons appear on the taskbar" section:
  18. What is showing that you are protected? If this is an Eset display, this would indicate Eset has been installed.
  19. Are you stating that WD is blocking the download or installation of Eset? Did you download Eset from here: https://www.eset.com/us/download/home/
  20. Believe you are referring to this article: https://www.bleepingcomputer.com/news/microsoft/malware-can-no-longer-disable-microsoft-defender-via-the-registry/ As stated: Additional stated is that WD should have never been permanently disabled previously since it serves as a real-time AV backup in the event the third party AV becomes inoperable for some reason.
  21. To begin, the Eset firewall and IDS are separate components within its Network Protection component. IDS is conditioned by network packet filtering rules and like intrusion detection rules that monitor for abuse of protocols commonly used by remote attackers. The Eset firewall component monitoring parallels that of the Win firewall in that app network use of protocols and ports are being monitored. It differs from the Win firewall in that it has full user interaction capability of outbound Internet traffic whereas the Win firewall only supports logging capability. In Eset default configur
  22. Correct. These are process signed with the TCB component specification as shown in the linked Google article: However, this is not an issue with eamsi.dll code integrity errors since the processes being injected are not TCB protected: Note that SIHClient.exe does not have the Windows TCB Component specification associated with it: I really can't see what Eset has to lose by testing what I proposed. Eset being a large organization appears to be struck in bureaucratic inertia when it comes to "thinking outside of the security box" in regards to new ideas.
  23. I am going to get right to the point on this. The eamsi.dll hash code integrity errors are being generated because Eset is trying to inject the .dll into Protected Process - Light (PPL) processes. I might be missing something in this Google Project Zero article which BTW is about bypassing PPL protection: https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html . However if Eset used it's anti-malware vendor cert; the one used to sign its ELAM driver, to also sign eamsi.dll, this should allow for eamsi.dll to be injected into a PPL process. @Marcos ,
  24. Read this article as to the impact of blocking CDPSvc service or its inbound/outbound traffic: https://teckangaroo.com/what-is-connected-devices-platform-service/ . If this is acceptable to you and you are willing to live with the system impacts of blocking all connected devices platform traffic, then also disable the CDPSvc service. This should totally shutdown all connected devices platform activity. Note that I don't recommend doing this. Don't do this. It will probably bust your network connection. As it stands presently, there is no way to block outbound network traffic from thi
  • Create New...