koolholio

d.ermisvc.com links to a no-ip dynamic dns address,.. which is indeed connected to a Google Cloud ip address...

This is where the codebase usually comes into detection: it's detected as a software bundler malware family: Unwaders.C ... occamy.C for the appleversions.dll, and it goes by a few other names... We'll have to wait and see I guess!

Look for files modified at the same time as the malware file dates... include the time and that narrows it a little...

We're talking about events that apparently took place between 11/04/2018 (file date of the malware) and 05/2018... (OS Install month)... this is almost dating back to the Creators update... Haven't even touched the 1809 update! (for it's delete bug...)

Creation of eventvwr files, gave me a quick indication of when I had a corrupted config registry hive... systeminfo confirms the eventvwr dates match...

Going purely by modification and creation date, it appears there were alot of sxs and windows updates with the same modification time as the malware...! this includes some dism, trustedinstaller, SAM and other reg hives... I'm just waiting to hear that Microsoft has had a public WSUS breach... say it isn't true!!! That's strange, my OS install date is about a month and a half after the malware!

That seems to mainly rely on RPC API calls, this appears different by facts that our malware to my knowledge installs an Apple push service masquerader under a Fake google update task possibly executed on boot.

I'm part of the Administrators group, where does it include the 'limited admins'?

c:\Windows\System32\Tasks\ is not accessible by default for admins? C:\WINDOWS\System32\tasks\Microsoft\Windows\Google exists though The job file shows the author as NT Authority system and user of was local system... <Author>SYSTEM</Author> (truncated) <UserId>S-1-5-18</UserId> <RunLevel>HighestAvailable</RunLevel>

There are a few ways of obtaining SYSTEM privileges, these include, impersonation, directly via the kernel, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS API call, msiexec method (which one of the exe files requires admin privileges in it's manifest), Some results may vary but here is a demonstration of the kernel method, showing cmd.exe being elevated from a low level user, to SYSTEM privileges:: Compatibility mode is useful for all users, thus the SYSWOW64 emulator requires permissions for all... COM objects would only be made if there was a GUID being triggered, the scheduled task cache uses an unknown GUID: 51A69099-BB83-4EDA-B253-9EFE17334209 which translates to what object? (as per @kevinbb 's task scheduler entry) DLL injection into explorer is quite a dirty method, but can be achieved, dllhost mainly deals with COM objects Looking at my COM objects 85187E17-383D-4EC5-B8D6-D9466EE3DD92 is the official GUID for the genuine APSDaemon.exe. I also found a seemingly invalid SID, with custom permissions applied to the genuine COM object!... https://social.technet.microsoft.com/Forums/ie/en-US/3e7d85e3-d0e1-4e79-8141-0bbf8faf3644/windows-10-anniversary-update-the-case-of-the-mysterious-account-sid-causing-the-flood-of-dcom?forum=win10itprosetup

how it got SYSTEM privileges is still a mystery... the running user was SYSTEM so I presume we're all talking post-intrusion and post privilege escalation for it to hide itself from Administrators using icacls, or it would cut it's own nose off, preventing itself from running... If it was executed by an administrator, it would have privileges of that administrator, but it's beyond a default Administrator privileges...

to gain any privileges to bury and hide itself, an exploit would have had to have been employed, it's not like impersonation could be used, I didn't end up running a VBscript? as the log states: URL;Application;User; list-cloud.icu;C:\Windows\SysWOW64\Microsoft\Protect\S-1-59-50\RB_1.4.76.74.exe;NT AUTHORITY\SYSTEM; There's a privilege escalation in there somewhere... to gain permissions...

I only had access to it in Sysinternals' Autoruns, it was hidden from view in task scheduler itself... and the entry has been removed now, i'd have also have had to decode the binary format of the entry in order to understand how it was configured to run... CVE-2018-6084 is a good example of how little permissions can escalate, it shows a local exploit can be used to gain privileges in mac google products... I wonder if anyone has created one for windows yet? Since 23-10-2018, There is also an exploit in the wild that has 4 imports and 3 defines, that allows a program to bypass UAC and gain an admin command prompt! And on that same day another submission was that, Chrome's debugger is supposedly too powerful for it's own good, a dodgy chrome extension with debugger permission is all it requires. I'm as of today running version 70.0.3538.77 of chrome.

GoogleUpdateTaskMachineUA is listed at the root folder of task scheduler, which makes a difference, it doesn't try to wrongly associate windows and google products The reason why it's so stealthy is because it's using authentic software with probably genuine API calls, but in a hacked about fashion, there's very little to distinguish legitimate HTTP packet analysis... It's only a presumption that a Google update product may have been breached, the google updater is in all google products for windows and from what I remember doesn't uninstall itself after you uninstall all their products, saying that, the entry vector could also be the Apple software updater or even windows updates or any other updater that we all have in common

It's scope appears (to me) that of a script kiddie that either found some source online or mashed together a few exploits that they found... they seemingly weren't experts at coding, for most of it, if they coded any of it at all, what reputable state sponsored hacker leaves a readable string behind and mashes up their dll file resources? and including a known riskware as heavily as they did? as for the executable packaging, surely they could have done better than they did with that too ? You can try for most privileges by using lots of scripts, take installers and wmi actions as an example... using just a couple of API calls which could be hijacked by other processes, it doesn't take much for script kiddies to follow suit quickly... even quicker in this day and age seemingly it may have attempted to access the SAM file or SAM registry keys but incorrectly generates an SID that isn't of use to gain permissions? (if it was a valid SID i'd have given it due credit) Whether there are any other associated hacks or exploits, is probably still yet to be determined, it's scope was pretty limited and seemingly quite isolated compared to some of what I've encountered before