itman
-
Posts
12,197 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
-EDIT- Posting removed.
It also would only work for LTSB OS versions only.
Microsoft has removed from the Windows Catalog all KB's for EOL OS's with ACS support other than those for LTSB versions.
-
Eset needs to modify its posting: https://support-eol.eset.com/en/trending_weol2023_10_2022.html to note the following.
In regards to reference to required KB updates to support Azure Code Signing: https://support.microsoft.com/en-us/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 , these updates can only be applied;
1. If the OS version is not end-of-life status.
2. If OS version is end-of-life status , it has extended support status.
In all other cases, these KB updates will fail. In this instance, the only alternative available is to upgrade the OS to a supported version if end-of-service status; purchase extended support if that option is still available; or purchase a new OS license for a supported version,
-
5 minutes ago, LesRMed said:
I had the same issue on two of my computers that were on 1909. I was able to resolve it by using the media creation tool here: https://www.microsoft.com/en-us/software-download/windows10. Click the Download Now and do the upgrade (you don't actually have to create the media).
Yes, this is a safer way to go. I never had a feature upgrade fail using the Media Creation tool.
-
According to this article: https://www.manageengine.com/patch-management/upgrade-windows-10-eol-versions.html , you should be able to perform a feature update on a Win 10 EOL version via Win Updates. It is possible that is busted on your Win 10 installation.
You can also try the article's referenced Patch Management software: https://www.manageengine.com/patch-management/ . However, this software might only work for Win 10 Pro+ versions.
-
8 hours ago, LT-SYSadmin said:
I already try to install the 22h2 but i cannot from the Microsoft updates or with the Installing Microsoft Support and Recovery Wizard or via the Microsoft Update Catalog.I believe that Win 10 22H2 will have to be installed
from scratchupgrade option in the case of a Win 10 EOL version. 22H2 can be download from here: https://www.microsoft.com/en-in/software-download/windows10 .You can research this issue further on the web.
-EDIT- It's been a while since I did a feature upgrade via ISO download. You mount the ISO file and run setup.exe from there. I believe one of the options presented is to retain existing files and apps and that is what you want to select. After the upgrade to 22H2 completes, you might have to reinstall a few apps, one of them being possibly Eset. I would export your Eset existing settings, if modified, prior to Win 10 upgrade so they can be reapplied if Eset needs to be reinstalled.
-
10 minutes ago, LT-SYSadmin said:
So, If I understand correctly there is no workaround for the moment ?
You will have to update your Win 10 version to 22H2.
-
@LesRMed been pondering if there is a way "to fake out" Windows in regards to this KB5006728 rollback issue. Perhaps disable Win Updating prior its installation? Something is informing Windows that this KB can't be installed due to lack of ESU support. This implies some type of communication to Microsoft servers. It also might be a license status lookup.
My reasoning is it appears on Win Server 2008 R2 at least, current license status is not available from the Win installation itself. If it was, KB5006728 would not have been allowed to be installed in the first place.
-
6 hours ago, Marcos said:
What about installing just KB5005624?
It can only installed on Win 10 1909 if extended support licensing was purchased. As the OP's previous screen shot shows. this is not the case. Ditto for any other EOL Win OS version.
-
17 hours ago, Marcos said:
If the AcsSupport registry value exists, the ACS test passed and you should have no problems upgrading ESET to the very latest version now or after December.
It appears Eset must be performing additional validations. Perhaps to verify that the applicable KB has been installed. Note that in @LesRMed installations, KB5006728 update was subsequently rolled back by Windows.
-
3 hours ago, murko said:
Thanks for clarification. About the ver. 16.2 - I am bit confused, as our ESET Endpoint Security shows latest ver. 10.1.2050.0.
Sorry about that. The same firewall rule child process option also now exists in EES 10.1.2050.0.
-
1 hour ago, murko said:
In such case, would the firewall/ids rules be still effective?
Yes, because as far as Windows is concerned, it is conhost.exe doing the network communication.
Now infected conhost.exe could spawn a malicious child process that could perform network communication, but that's another discussion. However, since ver. 16.2 firewall includes child process option, you're covered.
-
Referring to the command line string associate with conhost.exe, it looks like packed code to me. If that's the case, no code injection occurred to conhost.exe. When conhost.exe loaded, the packed code loaded into its memory space. Then the attacker unpacked it in memory and executed it.
-
Just now, murko said:
Btw, is there some kind of scan option in Eset Endpoint, which could find all files containing such malware, based on some kind of its fingerprint? (layman speaking)
LoL! I can only dream of such capability.
-
4 minutes ago, murko said:
Already checked, nothin there. Also scanned all drives for such files/folders, nothing except the mentioned before
My best guess at this point is it arrived as part of another app installer.
-
36 minutes ago, murko said:
Nice summary. As a preventive measure, its good to block that conhost.exe, but it doesnt solve the root of the issue - where does it came from/what causes exactly/how to detect it beforehand imho.
This puppy has been flying under the radar for some time. The Reddit article is 10 months old.
Out of curiosity, check Win add/remove programs and see if there is an entry for WindowsMalwareProtection or MicrosoftMalwareProtection
-
Another important detail from the Reddit article I forgot to post. It is conhost.exe that is performing the remote communication;
QuoteAnother thing that made me suspect is that it periodically opens and close a TCP connection with some server that appears located in Ukraine.
Makes sense since conhost is what contains the malware code. So I will add an Eset firewall rule to block conhost.exe communication.
-
49 minutes ago, LesRMed said:
KB5006728 still fails,
As noted previously, this fails because Windows checks for ESU support. Without it, Windows won't allow the KB update to remain installed.
49 minutes ago, LesRMed said:as does an update task
Eset must be checking for something other than if this reg key value exists; HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1. Of note is this reg key value does not exist on my Win 10 22H2 build.
-
Another posting about this bugger on Reddit;
QuoteI think I have found it. It is an executable called MicrosoftMalwareProtection.exe under C:/Program Files/ WindowsMalwareProtection/config. Everything in this folder is signed by Microsoft except for that one. It is executed at start up and a conhost with that weird command is called by it. 99% it is a malware. I'll try to reverse engineering it to find out what it does.
Yesterday I opened the task manager and noticed an unusually high RAM usage. I went in the processes list and nothing, everything looked fine. So I started digging a little and found out that there is a conhost process that is using around 2.5 GB of RAM and that doesn't show up in the task manager. Here is a picture with the details.
https://www.reddit.com/r/techsupport/comments/zaqigb/is_this_a_maleware/
The interesting part is most of its binaries are Microsoft signed. It also appears the payload is embedded within conhost.exe. Based on what was recently posted in this thread, it appears cmd.exe was started or conhost.exe standalone; most likely in suspended mode, then process hollowing and/or command line modification was done on conhost.exe, and conhost.exe was started.
Perhaps its time Eset start setting deep behavior inspection hooks into conhost.exe as it does for cmd.exe.
-
Let's "take it from the top."
QuoteThe /INTEGRITYCHECK linker option provides Windows kernel digital signature verification for user mode Portable Executables (PE) files. This linker option is required for anti-malware and anti-cheat scenarios to register components with the Windows Security Center.
You must sign IntegrityCheck-linked user mode PEs using Azure Code Signing (ACS). The cross-signing program is deprecated and new signing certificates will not be issued. Windows will continue to trust the existing binaries signed by the cross-signing program.
First, we are talking about AV WSC initialization processing only as I see it.
Could this whole issue be simply resolved by installing the Microsoft Identity Verification Root Certificate Authority 2020 certificate?
Or, is what these KB patches do is modify existing INTEGRITYCHECK processing? Let's check that out;
QuoteBy default,
/INTEGRITYCHECKis off.The
/INTEGRITYCHECKlinker option sets a flag,IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY, in the PE header of the DLL file or executable file. This flag tells the memory manager to check for a digital signature in order to load the image in Windows. This option must be set for both 32-bit and 64-bit DLLs that certain Windows features load. It's recommended for all device drivers on Windows Vista, Windows Server 2008, and all later versions of Windows and Windows Server. Versions of Windows prior to Windows Vista ignore this flag. For more information, see Forced Integrity Signing of Portable Executable (PE) files.Signing
/INTEGRITYCHECKfilesMicrosoft has new signing guidance for DLL and executable files linked by using
/INTEGRITYCHECK. The guidance used to recommend a cross-signed certificate from the cross-signing program. However, the cross-signing program is now deprecated. You must now sign your/INTEGRITYCHECKfiles by using the Microsoft Azure Code Signing program instead.Based on the above, I don't see any changes in INTEGRITYCHECK processing other than the ACS signing requirement. So I assume these required KB's modified INTEGRITYCHECK to do this.
Putting it all together, Windows requires this INTEGRITYCHECK modification for AV's to register in WSC. Without the KB's being applied, Eset won't be able register in WSC. I assume this means Eset will run concurrently with Microsoft Defender. Is this really a problem?
-
17 minutes ago, Marcos said:
It is weird that the Windows update failed though.
Was this certificate added: https://forum.eset.com/topic/38212-install-failing-on-2008r2-servers-with-acs-support/?do=findComment&comment=173230 ?
I assume Eset ACS signed binaries need that Win root CA cert.?
-
As far as Autoruns goes of note is this from the Malwarebytes posting;
QuoteI have disabled 2 scheduled tasks and removed triggers for now:
System32\Tasks\MicrosoftMalwareProtection
System32\Tasks\systemresetRun Autoruns64.exe. Once it fully initializes, search for MicrosoftMalwareProtection and systemreset. Take a screenshot of the section where they are located. Don't modify anything yet.
-
Here's Malwarebytes remediation of the bugger: https://forums.malwarebytes.com/topic/297568-program-fileswindowsmalwareprotection-systemresetexe-malware-removal/ . Problem is the fixlist isn't available.
-
You might want to check out this posting: https://forum.eset.com/topic/36845-eset-endpoint-products-compatibility-issue-with-azure-code-signing-acs-program/?do=findComment&comment=173276 . OP indicates ESET Server Security 9.0.12017 works w/o KB update.
-
Prior incidents of PowerShell/Agent.AEW trojan in the forum usually involved the creation of a Win service: https://forum.eset.com/topic/32255-powershellagentaew-trojan-keeps-coming-back-after-cleaning-and-reboot/?do=findComment&comment=150342 ; the service running SyncAppvPublishingServer.vbs; with the service being started via scheduled task.
This current instance is different. It appears explorer.exe connects to the domain in question to either download the PowerShell malware or to run it remotely. In a remote PowerShell attack, the script being deployed must exist on the target device. So it is possible what is attempting to download from this domain is the script.
SysInternal's Autoruns migh be of assistance here looking for suspect explorer.exe task running at system startup time.
Windows Defender Advanced Threat Protection service running in background
in General Discussion
Posted · Edited by itman
The problem might be that Eset is not properly registered in Windows Security Center. To verify it is, refer to this posting: https://forum.eset.com/topic/38127-antimalware-service-executable-still-runs-after-nod32-install/?do=findComment&comment=172860. Eset Security and firewall should be shown as "On" and Microsoft Defender and Windows firewall shown as "Off."