itman
-
Posts
12,200 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
6 hours ago, Marcos said:
We do not inject eamsi.dll whatsoever. If a particular process utilizes AMSI, the OS is responsible for loading the said dll into it.
OK. Let's assume eamsi.dll has been added to the list of knowndlls, etc.. In any case, it will not be loaded into any PPL process because it is not properly signed to do so. Since Microsoft is increasingly using PPL to protect its processes, Eset's monitoring capability is increasingly being diminished.
As any pen-tester "worth his salt" will attest, PPL is somewhat of a joke and multiple bypass POCs exist showing this.
-
Figured out why Eset attempts to inject its AMSI .dl into svchost.exe PPL instances is failing. Had to dive into my reference materials.
To inject code into a PPL process, the code must be signed at WindowsTCB authentication level. This is the highest signing level available. Eset signed the eamsi.dll with its regular driver certificate which is authorized for PP - Authenticode level only. Microsoft only issues one type of WindowsTCB level certificate. That is the certificate Eset used to sign its ELAM driver. Therefore it appears to me, Eset needs to sign the eamsi.dll with this certificate:
-
Also, beware of the type of attacker you are dealing with if you decide to pay the ransom:
QuoteThey gave just all the keys just for my particular infection. Thing is, for my infection, there are more than 1 keys. Promised me for everything. Then gave only one key. Then asked me for more $ because there are a total of 7 more keys to unlock all files. In the end, gave me 2 keys, where only one key worked to unlock everything
-
Also should not this registry key now be set to 0x2 since Eset's .dll is Microsoft Authenticode signed? It is still set to 0x1 on my ver. 12.2. 23 device:
QuoteAs of Windows 10, version 1903, Windows has added a way to enable Authenticode signing checks for providers. The feature is disabled by default, for both 32-bit and 64-bit processes. If you are creating a provider for test purposes, then you can enable or disable sign checks by setting the following Windows Registry value appropriately. The value is a DWORD.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBitsValue Behavior 0x1 The Authenticode-signed check is disabled. This is the default behavior. You can also use this value, temporarily, while testing. 0x2 The Authenticode-signed check is enabled. -
This appears to be Phobos ransomware. Check out this thread: https://www.bleepingcomputer.com/forums/t/699816/ive-attacked-by-ransomware-file-extension-adage/ . There appear to be a few versions that may be decryptable. Otherwise, you're out of luck.
-
Just upgraded to ver. 12.2.23.
Appears all is fixed except injection into Windows Security Center service; i.e. wscsvc. Possibly because it is running as PPL process.
-
It should be noted that it is not advisable to permanently disable Windows Defender. If there should be an issue with Eset's real-time scanning due to malfunction or other reason, Win 10 will automatically engage Windows Defender real-time protection mode.
-
To start with, you shouldn't be running both Avast and Eset with their realtime scanners enabled if that is the case. Only one AV scanner should be running with realtime enabled.
Refer to this posting: https://forum.avast.com/index.php?topic=181969.0 . Uninstall Avast using its uninstall utility . If you must, reinstall it via "custom" installation and ensure nothing related to Google is check marked during the installation process. Then disable Avast's realtime scanning option and use it as a second opinion scanner.
Also Avast's free version is very aggressive in regards to installing undesirable software. So in the free version, I am not sure the above will 100% work. Personally, I would just leave it uninstalled.
-
If you are referring to Eset's Customer Improvement program option, this can be disabled here:
-
To begin with the certificate Chrome is objecting to is associated with a private IP address:
QuotePrivate IP Addresses
Most organisations have far more computers than available IP addresses. Using private IP addresses helps to tackle this issue by allowing companies to have a single Internet gateway with a public IP address. All of the other nodes have private IP addresses. The gateway uses a Network Address Translation (NAT) server to translate the private IP addresses to an address that can be routed across the Internet.
ICANN has reserved sets of IP numbers for private use on the three classes of address. Notice how the recommendation includes non-standard subnet masks for class B and class C private IP ranges.
Private Address Ranges for class A, B and C networks Class Private IP Address Range Subnet Mask A 10.0.0.0 to 10.255.255.255 255.0.0.0 B 172.16.0.0 to 172.31.255.255 255.240.0.0 C 192.168.0.0 to 192.168.255.255 255.255.0.0 https://www.sqa.org.uk/e-learning/WebTech01CD/page_12.htm
So unless IP address, 10.10.1.69, is associated with some internal network web site/device address, you shouldn't be connecting to it in the first place. I believe in the U.S., some cable providers use the 10.xxx.xxx.xxx range for their internal network address assignments versus the 192.168.xxx.xxx range. One possibility here is the cable router, gateway device, etc. uses some type of admin utility that requires a root certificate to be installed? These type of "utility" certificates have been abused in past; e.g. Lenovo "Superfish" incident.
If this is an internal network entity, this article describes how to add the self-signed certificate used by the entity to Chrome's root CA certificate store: https://www.corvil.com/kb/how-do-you-get-chrome-to-accept-a-self-signed-certificate
Bottom line - this has nothing to do with Eset's SSL/TLS protocol scanning.
-
What is the program you are trying to "log in" to? As a rule, you don't log into apps.
-
I was able to identify one of the svchost.exe services where eamsi.dll was blocked and it is Windows Security Center. So the sooner ver 12.2 is implemented, the better.
BTW - Win 10 1903 was released in May ........................
QuoteStarting in Windows 10, version 1903, if your AMSI provider DLL is not Authenticode-signed, then it may not be loaded (depending on how the host machine is configured). For full details, see IAntimalwareProvider interface.
https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
-
This FF 68 error might be associated with Nano Defender add-on which I recently added to uBlock Origin. I saw two tmpadd-nnn files in my AppData\User\Temp directory. Have a hunch Eset B&PP "choked" when trying to remove/re-add these add-on files as part of B&PP processing.
-
59 minutes ago, cyberhash said:
I have the same but it just seems to be an informative alert rather than a genuine fault.
Not quite.
Each one of the errors indicates a process where Eset's AMSI .dll was blocked from loading. Most of the alerts relate to SIHClient.exe; i.e. service-initiated healing:
This daily task launches the SIH client (server-initiated healing) to detect and fix system components that are vital to automatic updating of Windows and Microsoft software installed on the machine. This task can go online, evaluate applicability of healing actions, download necessary payloads to execute the actions, and execute healing actions.
I am not too concerned about this one.
However, there are errors associated with svchost.exe with no detain given of associated service. These are the ones I am concerned about. As it presently stands, Eset AMSI .dll is only injected into two svchost.exe service associated processes.
-
-
Just upgraded to Win 10 x(64) 1903 yesterday.
Just noticed in my Win 10 Event Log, FireFox 68 is throwing an error every time Eset IS 12.1.34 initiates B&BP within FF 68. Eset B&PP page opens OK and web site is accessed w/o issue.
-
11 minutes ago, COStark26 said:
OK to leave SSL Filtering UN-Chk'd?
If permanently, the answer is obviously no.
Eset web filtering protection will not be done on HTTPS which is most web sites today.
-
Also, can you access this site, https://www.jhannuities.com/ , in FF 68 w/o using B&PP? You will first have to remove the URL from B&PP protected site list.
-
I added https://www.jhannuities.com/ to B&PP protected web sites and now it also opens to B&PP in FF 68.
My best guess at this point is something is messed up with your FF profile.
-
5 minutes ago, aldel said:
The problem doesnt happen sometimes for days
This is symptomatic of a hardware issue. If Eset's driver was the issue, it should manifest each time you boot.
-
On 7/13/2019 at 6:01 AM, Marcos said:
You can try temporarily uninstalling ESET Internet Security and see if it makes a difference.
Did you try this? If the type error persists with Eset unistalled, Eset is not the source of the issue.
-
In FF 68, this link, https://www.jhannuities.com/ , does not open Eset B&BP automatically. Eset is also not using the site's root CA certificate but Eset's own root CA certificate. Could not open the site in B&PP using FF 68 since my default browser is IE11. However, the site opened fine in non-B&PP FF68.
Was this site previously opening BP&P from FireFox? I had no issues accessing the site in IE11 using B&PP via manual startup. And the link shown was https://www.jhannuities.com/Marketing/default.aspxMarketing/default.aspx
Did a QUALS SSL Server scan on https://www.jhannuities.com/ and all that was shown amiss was:
Site was rated "A."
-
58 minutes ago, classiccor83 said:
The email has been sent to the email address as requested. What are the next steps?
Wait for an e-mail reply from Eset support.
Were all your backup files on the NAS storage? Backups need to be created on storage that is off-line and disconnected from your PC.
-
The current pressing issue is regards to DNS is DNS hijacking of which DoH is only marginally effective against: https://www.bleepingcomputer.com/news/security/ncsc-issues-alert-about-active-dns-hijacking-attacks/ . Immediate due diligence needs to be performed to ensure routers/gateways are properly secured.
Eset AMSI DLL Issue on Win 10 x(64) 1903
in ESET Internet Security & ESET Smart Security Premium
Posted
My take on this is this cert. can be used to sign .dlls. As you noted previously, Windows is attempting to load the AV amsi.dll into a PPL process. It wouldn't attempt it unless it assumed the .dll was properly signed.
https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html
Or alternatively, just use one of the PPL bypasses noted in the article.🙄