Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts 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. 15 minutes ago, hjlbx said:

    EIS 2017.5.0.7538

    Windows 10 Pro Version 1703 OS Build 15063.332 64-bit

    Process Hacker 2 (https://www.isthisfilesafe.com/?md5=B365AF317AE730A67C936F21432B9C71)

    Since some vendors treat Process Hacker as potentially malicious, it is possible that the behavior below is intended - so I'm not sure if it is a bug

    * * * * *

    1.  Launch Process Hacker 2

    2.  processhacker.exe shows in the Behavior Blocker list

    3.  A rule for processhacker.exe is never created in the Applications Rules list



    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)


  3. 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.

  4. 3 hours ago, Andrew F. said:

    Thanks for explanation.

    Would it be possible to reproduce this and get a set of debug logs?

    (Please make sure to reboot after enabling debug logging).

    (Thank you in advance).

    But again... did you make sure that you didn't test your router ?

    About what windows shows - there's a bug with displaying the status of our firewall module in the windows defender,

    so the information there isn't correct.

    I believe there will be a notice in the changelist when this will be fixed.

    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




  5. 50 minutes ago, Andrew F. said:


    Thank you for the input.

    EIS should block those ports for public networks only. Technically, when you switch the network type - you tell the firewall core

    which rules should be active. For example - rules blocking those tcp/udp ports are "enabled" for the public networks only.

    This means, that the rule should work for the public networks and shouldn't for the private ones.

    So, the ports being seen as open while in "private" network - is an expected situation.

    About the nmap.org and other tests from outside - did you make sure that you didn't actually test your router ?

    (by either connecting the system directly to the internet, or by setting up your router to forward the ports being tested)

    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).



  6. I've also managed to replicate a similar situation on a fully patched machine running Win10 without the creators update.

    1. Installed EIS 7538
    2. Rebooted
    3. Verified EIS firewall profile for the network is set to private
    4. Execute port scan of the system, observe open ports (135,139,445,2869,3389,5357 - machine is behind NAT, RDP doesn't matter)
    5. Toggle firewall off in EIS, wait 30 seconds
    6. Execute port scan of the system, observe open ports again (135,139,445,2869,3389,5357)
    7. Toggle firewall back on and switch profile to "public network", wait 30 seconds
    8. Execute port scan of system, observe open ports again (135,139,445,2869,3389,5357)
    9. Reboot system with EIS still set to public network
    10. Execute portscan, all ports show closed/filtered
  7. 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.





  8. 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.



  9. 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?




  10. Our developers let me know that the debug logs did not contain information about the problem. They believe that if you restart your computer after turning on debug logging, and then try to reproduce the issue, that the logs that are saved after the reboot will contain more information. Would it be possible to try that and get us new debug logs?


    Sorry for the delayed response. Yeah, I'll enable debug logging, reboot and try to reproduce.



  • Create New...