Jump to content

m0unds

Member
  • Posts

    138
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by m0unds

  1. I tried capturing the file, but the installer extracts, executes and deletes it faster than I can grab a copy. Additionally, EAM fails to quarantine it but blocks the autorun modification attempt. Would be helpful if EAM would write the SHA-1/MD5/SHA-256 hash to the forensic log. The BB dialog is blank except for the action the file is taking. Here you go: https://www.virustotal.com/en/file/95705ae60a89adbf2b06534d52cb1817080d4480e1a5cc89f15d2a4dd7a096df/analysis/ file shows as NVI2.dll, but it had the same hash as the one being executed by the installer process after the install was complete (guessing it's registering the nv stuff to start w/the computer)
  2. I just updated my NV drivers using GeForce Experience - that particular file is signed by NV but tries to modify an autorun entry. It also had no reputation on the anti-malware network, so I'm guessing the combination of the two things caused the BB popup.
  3. Hi, No problem at all. Glad to hear it'll be fixed. Thanks, Chris
  4. It's been a month. Any luck reproducing this?
  5. alrighty then. figured another datapoint would be helpful. good luck, i guess.
  6. I'm on the same OS build as you and same product build and it created a rule for me when I ran it (literally just downloaded + ran it)
  7. yea, I run HMP.alert w/EIS and have no issues. the only thing I do is exclude hmpalert.exe from monitoring within EIS.
  8. I performed some more testing and took additional screenshots w/the security and maintenance cpanel open, since that's how you guys were diagnosing whether EIS was working. It does indeed show EIS is working, but port scanning still shows inbound filtering is borked. Outbound filtering by EIS seems to work though, but profile changes are impacted while in the "Failed" state. See below for screenshots and more info. Additional info: Outbound traffic control by EIS remains in whatever profile the product is set to when I toggle EIS' firewall off/on (causing the Firewall status issue w/Windows Security Center and Windows Firewall cpanel). If EIS is set to Public and I toggle the firewall off, it will still control outbound traffic, but inbound is no longer filtered. If I change the profile to private while in the "failed" state, and use "turn on" in Windows Security Center to turn the Windows firewall back on, it will still filter traffic according to EIS' Public network profile UNTIL I change the profile in EIS to Public, and then back to Private. Likewise, if EIS is set to Private and I toggle the firewall off, it will still apply the product's rules for Private networks and inbound traffic will no longer be filtered (ports that have no explicit ruleset are open, just like on Public mode w/the firewall broken) If I change the profile to Public while in the "failed" state, and use "turn on" in WSC to turn the Windows firewall back on, it will still filter inbound traffic according to EIS' Private network profile UNTIL I change the profile in EIS to Private and then back to Public. @Andrew F. - I collected more logs and uploaded them with a text file that outlines the test cases I used while the log collection was running. Let me know if you need any additional testing. I hope this helps.
  9. Sure thing. I sent debug logs the day before yesterday using the support function in EIS, when I posted the issue, but I can generate more and send them if you need me to. I'm positive I didn't test my router - the device I was using to test is in the rack under my desk, and is connected to my wired LAN I've seen the bug and this seems different because it's not only occurring within security center, but also in maintenance and security as well as the firewall snap-in itself. I'll keep an eye out for that bug fix when it's available Thanks! Chris
  10. Hi Andrew, That's actually what I was trying to illustrate - showing the ports that are expected to be open in public and private network firewall profiles, and then showing what happens when Windows says the firewall is in a "disabled" state. The problem isn't that the ruleset is changing - the problem is that when Windows indicates the firewall is disabled, EIS' inbound filtering seems to not be working, which leads me to think something might be amiss with both Windows and EIS. That's why I included different nmap results with different profiles active (done from within my LAN, so directly testing the system with EIS installed). When Windows indicates the firewall isn't working and I change EIS from private to public, the open ports I see are the same regardless. If use the firewall snap-in in Windows or the Security Center to re-enable the firewall, then I see the ports open that should be. i.e. Private - sharing, RDP, etc ports should be open if the svcs are active on the system. Public - nothing should really show up because ostensibly the network is untrusted. When Windows says the firewall is enabled, and there's no "failure" state, it works exactly like that. If I trigger the inconsistency, it doesn't matter which profile I select, because EIS is allowing all inbound traffic (as evidenced by my nmap screenshots). Thanks, Chris
  11. I've also managed to replicate a similar situation on a fully patched machine running Win10 without the creators update. Installed EIS 7538 Rebooted Verified EIS firewall profile for the network is set to private Execute port scan of the system, observe open ports (135,139,445,2869,3389,5357 - machine is behind NAT, RDP doesn't matter) Toggle firewall off in EIS, wait 30 seconds Execute port scan of the system, observe open ports again (135,139,445,2869,3389,5357) Toggle firewall back on and switch profile to "public network", wait 30 seconds Execute port scan of system, observe open ports again (135,139,445,2869,3389,5357) Reboot system with EIS still set to public network Execute portscan, all ports show closed/filtered
  12. Hi Frank, That's not the case. As I mentioned, the security center *and* windows itself (firewall snap-in) indicate the firewall is off. EIS says it's enabled. I just performed portscans of the machine with EIS firewall in the following states: Private network, Public network, Broken Private Network (EIS on, but windows saying the fw is off) and Broken Public Network (EIS on, but windows saying the fw is off) and it's plain to see EIS isn't blocking inbound traffic like it should be in this state. I'm attaching screenshots for illustrative purposes: I sent in diagnostic logs referencing this thread using the support tool in EIS. I hope this added info helps to clarify the issue I'm seeing EDIT: Also, whatever the profile EIS sets for outbound FW processing when the windows FW dies is how the product remains after the FW dies. E.g., during my test, I broke the FW with EIS set to public network. In the "failed" state, my machine can't reach network shares (indicating public network mode in EIS). Switching EIS back to "private network" while in the broken state doesn't fix it. If I then go to the firewall snap-in or security center and let windows "Fix" the firewall, THEN reset the profile to Private, everything is back to working. If I switch EIS from Public to Private in the broken state then let windows "Fix" the firewall, it stays in public mode until I manually switch it from Public to Private. Thanks, Chris
  13. Yeah, but the windows firewall snap-in also shows the firewall is off. I sent in logs last night after reproducing the failure w/the current beta release. I included a screenshot of the windows security center, windows firewall snap-in and EIS product firewall state *EDIT* my phone didn't load the second screenshot when i viewed it - the second screenshot in my case shows the firewall is off.
  14. haha, yeah - I'm already collecting, just wanted to be sure before I uploaded or whatever
  15. Hey, Someone in the stable product forum posted about an issue with Windows' firewall status being misreported post-creators-update. I ran into an issue with the current beta (.7538) wherein EIS reports the product firewall is functioning, Windows says: 1. Emsisoft isn't mentioned as product managing the firewall, 2. The Windows firewall is off. (reported by both Windows Security center and the Windows Firewall applet itself). In this state, the firewall is actually stopped and EIS' firewall doesn't do anything to inbound packets (I'm able to ping the system despite explicitly blocking ICMP echo for testing purposes) Would you guys like me to see if I can reproduce this and provide logs, or is it something you're already aware of & tracking? Thanks Chris
  16. Improvement request: tell the user if the debug logs are too large to send so we don't come to the forum to tell you we sent them when we didn't Anyway, I'll zip and upload when I have a moment and ping you after. Thanks
  17. Nope, haven't had time to reproduce yet. Lots of traveling this week for work. Thanks
  18. Sorry for the delayed response. Yeah, I'll enable debug logging, reboot and try to reproduce. Thanks
  19. Hey, I sort of reproduced it and sent the logs. It's hard to cause the issue intentionally. That being said, EIS crashed when I tried turning off diagnostic logging, so I'm not entirely sure they actually sent before it crashed. Thanks
  20. Do you need any logs from me? I can provide some if it would help nail down the cause of this. I've been able to trigger it on both my workstation and laptop. I found I could trigger the issue more quickly by lowering the update check interval to 30 minutes, so I miss more scheduled updates before closing out the game I test with.
×
×
  • Create New...