itman
-
Posts
12,199 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
What browser is this behavior being observed for? Have you tried different browsers and the same behavior manifests?
-
5 hours ago, BeanSlappers said:
Maybe a it doesn't work when parental control is on, but if that is the case, then that is the software need changing. But in saying that I have tried it with both on and off and still same thing.
The only other thing I can think of at this point is some type of man-in-the-middle is occurring. When this happens, HTTPS traffic is intercepted en-route and decrypted using the attacker's root certificate. In most cases but not always, this breaks "the chain of trust" in the browser resulting in a warning from the browser this activity has taken place.
One possibility is the MITM activity is occurring externally with the Eset root certificate being replaced with the site's original chained root certificate. Go to this web site which will validate SSL/TLS communication:
In FireFox Quantum 68 and EIS 12.1.34, the only tests shown in light red indicating a minor concern are SHA-1 Intermediate and dh1024 Crypto cypher issues. The test area to be noted is the Interception Certificates area.
-
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.
-
Ahh........... It's the obvious stuff that can "trick you up." Totally ignored that parameter under the assumption logs are created in all scanner modes.
-
@Marcos this might be the reason for the Win 7 driver errors when attempting to install Sandboxie:
QuoteSHA-2 Code Signing
For Windows 7 Users, the SHA-2 Code Signing Support becomes mandatory in July. You will need to have KB4474419 (the SHA-2 update) and KB4490628 (2019-03 Servicing Stack) installed for Win7 SP1, Server 2008 R2 SP1, and Server 2008 SP2 prior to August updates. -
Detection was had when I was signed off from Win 10. Cleaning mode is "Strict."
File was indeed quarantined but I would expect Eset to also write a Detection log entry. If one never referred to Eset Quarantine, they would never know a malware was detected and mitigated.
-
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.
QuoteTaking 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.
-
13 hours ago, Urashima Taro said:
I will report back in about a week worth of use.
No reason to wait a week.
If the Eset DBI Sandboxie exclusions are working, it would be apparent immediately by no conflict with clearing the sandbox after browser termination.
-
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.
-
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.
-
18 minutes ago, jdashn said:
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.
-
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:
QuoteBuilt-in web server ¶
WarningThis 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.
-
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.
-
These are all Fortinet IPS detections:
https://fortiguard.com/encyclopedia/ips/26339
https://fortiguard.com/encyclopedia/ips/44580
https://fortiguard.com/encyclopedia/ips/12090
The possible malware is php.malicious.shell. Per the Fortinet description indicates a malicious php script running on a php server. Do you have a php/web server installed?
-
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.
-
This suggestion was posted on the Sandboxie forum by Sophos:
QuoteSince 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-testRemove 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.
-
First, refer to this: https://help.eset.com/ees/7/en-US/idh_config_epfw_known_networks_group.html .
Next, refer to EES online help in regards to Network Authentication which might be what you are looking for.
-
10 minutes ago, Marcos said:
Yes, exactly from that link.
Try a manual download from here: https://www.sandboxie.com/AllVersions
As shown on this site, there are many vers. of Sandboxie. So far, no one has mentioned what ver. they are running or if it's 32 or 64 bit.
-
11 minutes ago, Marcos said:
Getting an error while installing the driver:
As far as I am aware of, Sandboxie's driver is validly signed. Did you download it from here: https://www.sandboxie.com/DownloadSandboxie .
-
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.
-
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.
-
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.
-
9 minutes ago, Tetranitrocubane said:
Temporarily disabling HIPS and rebooting does in fact allow me to empty the sandbox.
Continue monitoring to determine if the problem reoccurs.
-
On 7/6/2019 at 8:44 PM, BeanSlappers said:
Yeah I am pretty sure that I said that I was using firefox a lot of times. I hate edge so I wont ever use it.
Did you verify that firefox.exe is in the list of SSL filtered applications?
NOD32 Antivirus and HDDs help
in ESET NOD32 Antivirus
Posted
Switch to pre-release updating in Eset. After that processing completes, check if current version is 12.2.23. If it is not, then perform a manual update check which should download version 12.2.23.