Jump to content

itman

Most Valued Members
  • Posts

    12,170
  • Joined

  • Last visited

  • Days Won

    319

Posts posted by itman

  1. 35 minutes ago, BeanSlappers said:

    Makes no difference even with the update.

    Did you try @Sammo suggestion of setting firefox.exe in Eset's SSL/TLS filtered applications to "Scan" versus the default setting of "Auto?" While in that section, make sure that there are not multiple firefox.exe applications listed. You should have only one entry for Firefox and its path specification is C:\Program Files\Mozilla Firefox\firefox.exe assuming your using Win 10 x(64).

    Next in the Web Access protection section, open the Web Protocols section and verify that only port 443 is shown in the HTTPS Scanner Setup section.

  2. Quote

    NOTE: If a folder includes both EXE and COM files with the same filename (e.g., run.exe and run.com), the DOS or Windows command prompt will run the COM file if you type the filename without the extension.

    https://fileinfo.com/extension/com

    In other words, malware runs via a batch script.

    Quote

    Taking advantage of this default behaviour, virus writers and other malicious programmers have used names like notepad.com for their creations, hoping that if it is placed in the same directory as the corresponding EXE file, a command or batch file may accidentally trigger their program instead of the text editor notepad.exe. Again, these .com files may in fact contain a .exe format executable.

    On Windows NT and derivatives (Windows 2000, Windows XP, Windows Vista, and Windows 7), the PATHEXT variable is used to override the order of preference (and acceptable extensions) for calling files without specifying the extension from the command line. The default value still places .com files before .exe files. This closely resembles a feature previously found in JP Software's line of extended command line processors 4DOS, 4OS2, and 4NT.

    https://en.wikipedia.org/wiki/COM_file

  3. It is possible that two startup scans could be run at system boot or logon time. Such would be the case if the PC was idle long enough that Eset would push a module update after either of these events.

    The main startup scan will scan all files run after user logon at normal priority. The after module update startup scan will scan commonly used files; whatever those may be, at low priority. Since both these scans have the same name associated with them, it would be impossible to determine which scan was running by mouse hovering over the Eset taskbar icon.

    What might be observed by the OP is the running of the module update scan. Assuming a lower processing capacity PC and that the scan is running at low priority, it might run long enough to be observable via icon taskbar activity. In any case if this scan was running, it should have no impact on normal system activities since the scan is running at low priority.

  4. On 7/8/2019 at 4:39 PM, BeanSlappers said:

    It is indeed.

    FireFox just released ver. 68. This is the ver. that will use the Win root CA store if Eset's certificate is not added to FireFox's Authorities certificate store for some reason. If FireFox hasn't auto updated to ver. 68, do so manually.

    Now perform the AMTSO tests and see if Eset if still not detecting those.

  5. 18 minutes ago, jdashn said:

    @itman

    thats only for the webserver built into PHP (that is designed for app dev, and shouldn't be forwarded to the net), not PHP it's self, right?

    I believe that is correct.

    But in this case, it appears the php server was not locked down; was hacked to deploy a malicious script; and that script is now attacking the internal network. 

  6. A few comments about php server use. It was designed for internal development usage and definitely should not be allowed access to the external network:

    Quote

    Built-in web server

    Warning

    This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

  7. 1 hour ago, Tetranitrocubane said:

    I've tried adding the exception for Deep Behavior Inspection in ESET, but unfortunately the behavior seems to be persisting.

    The only other culprit I can think of is the Advanced Machine Leaning module. This also was just introduced into Eset.

    Also, it appears there is no way to add exceptions to it or disable it short of completely disabling the HIPS.

  8. Make sure that "Enable Smart Optimization" is check marked in ThreatSense settings for the Startup Scan.

    Open Eset GUI. Then select Setup. Then select Advanced Setup. Under Detection Engine, select Malware Scans. Click on the "+" for STARTUP SCAN to expose the ThreatSense settings.

    As a test, I disabled it and then rebooted. I then observed same behavior with the scan taking approx. 3 mins. to run.

  9. This suggestion was posted on the Sandboxie forum by Sophos:

    Quote

    Since you mentioned Ekrn.exe , you may want to try blocking that file in the Sandbox and test what happens (it may or may not work, as it it may trigger error messages).

    Right-click on your Sandbox
    Sandbox settings---> Resource Access ---> File Access --> Blocked access
    Add the following entry:
    *\ekrn.exe
    Ok and Apply
    Re-test

    Remove the changes if they don't help/cause problems.

    This coupled with excluding Sandboxie processes or entire directory as noted above, might do the trick.

    Personally, I suspect Eset might go "bonkers" if its access was denied to Sandboxie system use areas.

  10. 1 hour ago, vs2018sv said:

    I am trying to have ESET block the computer from joining/authenticating to a 3rd party foreign wireless and wired network.

    Don't know quite what you mean here.

    By default, Eset Network Protection will only connect to the Network's gateway device if using the Public profile. Or and additionally,  other devices within the local network if using the Private profile.

    The gateway reference here is usually a router. Once communication reaches the router, it is 100% under its control from that point on.

  11. Try this.

    1. Open the Eset GUI and via Setup selection, navigate to the Network Protection section.

    2. In the "Troubleshooting Wizard" section, determine if the "Recently blocked applications or devices" count is a non-zero value. If it is, open the wizard and search for blocked connection entries related to your VPN network access. Click on the "Allow" tab for those entries and the wizard will create the appropriate Eset firewall rule to allow the VPN network connection.

  12. Believe I know what might be the "culprit" here.

    Eset recently implemented "Deep Behavior Inspection" in the HIPS. For anyone having this issue with Sandboxie, do the following:

    1. Open the Eset GUI and navigate to the HIPS section.

    2. Verify that a Deep Behavior Inspection section exists there. If so, add exceptions for all of Sandboxie's executables there. -EDIT- Or alternatively, just whitelist Sandboxie's entire directory using the "\*.*" notation.

    Hopefully, this will resolve the registry access issues with Sandboxie.

  13. 4 hours ago, ssmuu said:

    In case anyone encounter same problem here is my fix. Completely uninstall ESET. Remove all previous installation files. Then completely activate Windows Defender. Restart and update Defender. After letting Defender be the main virus software of the OS, install ESET with using offline installation package. I dont know but this worked some how.

    I was going to suggest this.

    Appears in the upgrade to Win 10 1903, Windows Security Center internal settings in regards to use of a third party AV realtime solution got borked somehow. Externally, all appeared OK in that WSC showed Eset as realtime solution.

×
×
  • Create New...