Jump to content

Warning about "https://list-cloud.com"


Ian Ng

Recommended Posts

On ‎10‎/‎23‎/‎2018 at 3:06 PM, koolholio said:

still trying to figure out where it was getting list-cloud from... If anyone has the command line arguments for the scheduled task, it might hold some insight into how they operated this hacked together piece of malware

Using SysInternals Autorun's look for any registry references for C:\Windows\SysWOW64\Microsoft\Protect\S-1-96-82 or any subdirectory of it. Also when you run Autoruns, click on the Options tab and ensure the following are not check marked:

  • Hide Microsoft entries
  • Hide Windows entries

Then, do a refresh to display all those entries.

If you find something of interest, make sure you left mouse click on it. It's properties will be shown in the lower window. The bottom line will show any parameters the entry is using when it loads. For example, the scheduled Windows host process task, rundll32.exe ,on my Win 10 x(64) 1803 build is actually running:

"%windir%\system32\rundll32.exe" sysmain.dll,PfSvWsSwapAssessmentTask

Edited by itman
Link to comment
Share on other sites

theres no registry references relating to data.dll

correction, i found these under scheduled tasks: 

\Microsoft\Windows\Google\GoogleUpdateTaskMachineUP            File not found: C:\WINDOWS\SysWOW64\Microsoft\Protect\S-1-59-50\RB_1.4.76.74.exe  

I can confirm there is no SID belonging to that supposed SID...

 

According to this then, we can presume it was Google update service that was hijacked (a plausible entry method) acting as an Apple Push Service masquerader... I wouldn't call this work of state sponsored hackers except maybe the encoding of resource108 of data.dll, seemingly the rest was operated by script kiddies...

Edited by koolholio
Link to comment
Share on other sites

11 hours ago, koolholio said:

According to this then, we can presume it was Google update service that was hijacked (a plausible entry method) 

The legit Google updater is: \Microsoft\Windows\Google\GoogleUpdateTaskMachineUA .

Also, this hack is more sophisticated than you're giving it credit for. Anything that can access protected Windows directories, change their permissions, create scheduled tasks and services, etc. is something to be reckoned with in my book. Finally, the fact the bugger was running undetected for other than a suspicious outbound connection Eset detected also adds merit to its potency. 

Link to comment
Share on other sites

3 minutes ago, itman said:

The legit Google updater is: \Microsoft\Windows\Google\GoogleUpdateTaskMachineUA .

Also, this hack is more sophisticated than you're giving it credit for. Anything that can access protected Windows directories, change their permissions, create scheduled tasks and services, etc. is something to be reckoned with in my book. Finally, the fact the bugger was running undetected for other than a suspicious outbound connection Eset detected also adds merit to its potency. 

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

Link to comment
Share on other sites

Now that I am on my third cup of coffee and fully awake, I think we cab "piece together" the elements of this attack.

I believe everyone that has posted in this thread was using Chrome. Is not GoogleUpdateTaskMachineUA Chrome's update process? Appears somehow the attacker was able to hijack the legit version and replace it with a bogus GoogleUpdateTaskMachineUP version. It also appears that this bogus version is "flying under the radar" of most if not all of the major AV's.

So my previous suspicion about a hijacked updater was on target.

Link to comment
Share on other sites

There is also an interesting older posting about how GoogleUpdateTaskMachineUP ended up being installed on a corp. network and the admin noting that no Google software had been explicitly installed: https://community.spiceworks.com/topic/596095-what-should-i-do-about-googleupdatetaskuser-in-scheduled-tasks

Appears in true Google invasion fashion the bugger can be installed for anything that is Google related.

Edited by itman
Link to comment
Share on other sites

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

Edited by koolholio
Link to comment
Share on other sites

13 minutes ago, koolholio said:

GoogleUpdateTaskMachineUA is listed at the root folder of task scheduler, which makes a difference

Did you check what the scheduled task settings were? If it was running with "highest" privileges, the only way that could be done is if the attacker knew the user's logon password.

The scheduled task placement in the root folder would indicate that the task was created standalone and only admin privileges would be needed.

Link to comment
Share on other sites

 

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.

Edited by koolholio
Link to comment
Share on other sites

You don't need an exploit to escalate privileges. Best way to do so is an UAC bypass using "one of those" Windows trusted utility processes. Since most user's run with default UAC settings, if they haven't disabled it altogether, the bypass will succeed,

Link to comment
Share on other sites

1 hour ago, itman said:

You don't need an exploit to escalate privileges. Best way to do so is an UAC bypass using "one of those" Windows trusted utility processes. Since most user's run with default UAC settings, if they haven't disabled it altogether, the bypass will succeed,

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...

Edited by koolholio
Link to comment
Share on other sites

1 hour ago, koolholio said:

There's a privilege escalation in there somewhere... to gain permissions...

If the scheduled task was created with "highest privileges" assigned, that equates to NT AUTHORITY\SYSTEM privileges.

Link to comment
Share on other sites

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...

Edited by koolholio
Link to comment
Share on other sites

This is an eye opener. Note I am running Win 10 x(64) 1803.

Running as a limited admin, I was able to create a new folder in C:\Windows\SysWOW64\. Of course I received the usual UAC prompt to escalate to admin level. But a simple UAC bypass could circumvent that if you weren't running with UAC set to maximum level.

So much for Win 10's improved system directory protections.

Now this one is strange. When performing the above activity, I was using Win explorer; i.e. explorer.exe. I monitor any modification to it with Eset HIPS rules including termination/suspension. Well, I did get an alert from Eset that COM was trying to do just that to explorer.exe; terminate or suspend it. The interesting part was that the real source process was dllhost.exe as shown by the below screen shot:

Eset_dllhost.png.76c7a23b6b54e2e4753bb28f01b32ff2.png 

Link to comment
Share on other sites

7 hours ago, itman said:

I was able to create a new folder in C:\Windows\SysWOW64\. Of course I received the usual UAC prompt to escalate to admin level. But a simple UAC bypass could circumvent that if you weren't running with UAC set to maximum level.

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:: 

 

Quote

So much for Win 10's improved system directory protections.

Now this one is strange. When performing the above activity, I was using Win explorer; i.e. explorer.exe. I monitor any modification to it with Eset HIPS rules including termination/suspension. Well, I did get an alert from Eset that COM was trying to do just that to explorer.exe; terminate or suspend it. The interesting part was that the real source process was dllhost.exe

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

Edited by koolholio
Link to comment
Share on other sites

As far as this malware running with system privileges, it appears my comment about the scheduled task running with "highest privileges" didn't register as how this is done.

Here is a detailed example:

Quote

I found a malware sample that uses a simple Microsoft .job files to implement persistence. A Job file[1] is a special XML file that contains all the details to configure a scheduled task on a Microsoft Windows host. More technical details about this file format can be found here: https://www.forensicswiki.org/wiki/Windows_Job_File_Format

The .job file is created in C:\Windows\tasks, the standard location of scheduled jobs. The corresponding command follows:

"C:\WINDOWS\system32\SchTasks.exe" /Create /SC HOURLY /MO 12 /TN "Belgningsstuens" \
     /TR "reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" \
     /v "\""Belgningsstuens"\"" /f /t REG_SZ /d "\""C:\Documents and Settings\John\Application Data\kinglike.exe" \
     /RU SYSTEM

Basically, the malware drops a PE file %APPDATA%\kinglike.exe (SHA256:eb62ceaf85055120714d9b82b8da39e7d08a95ebb1763b03009511532c40c7d3) and schedules a unique task (see the flag “TASK_FLAG_DELETE_WHEN_DONE”) that will make it start again at the next boot (registry key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run”).

In the example above, the scheduled task is configured to run with ‘system’ privileges (“/RU SYSTEM”) but any user can create scheduled tasks. An authenticated user has rights to create scheduled tasks and to write into the C:\Windows\Tasks directory as shows the SetACL:

c:\Windows\System32\Tasks\

   Owner: Administrators

   DACL(protected+auto_inherited):

   Administrators               full   allow   container_inherit
   Administrators               write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   SYSTEM                            full   allow   container_inherit
   SYSTEM                            write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   Authenticated Users     read   allow   container_inherit+object_inherit
   LOCAL SERVICE              read   allow   container_inherit+object_inherit
   NETWORK SERVICE       read   allow   container_inherit+object_inherit
   CREATOR OWNER          full   allow   container_inherit+object_inherit+inherit_only

https://isc.sans.edu/forums/diary/Adding+Persistence+Via+Scheduled+Tasks/23633/

Edited by itman
Link to comment
Share on other sites

17 hours ago, itman said:

As far as this malware running with system privileges, it appears my comment about the scheduled task running with "highest privileges" didn't register as how this is done.

Here is a detailed example:

https://isc.sans.edu/forums/diary/Adding+Persistence+Via+Scheduled+Tasks/23633/

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>

Edited by koolholio
Coherence
Link to comment
Share on other sites

35 minutes ago, koolholio said:

c:\Windows\System32\Tasks\ is not accessible by default for admins?

Limited admins - yes. Admins have full control:

Eset_admins.thumb.png.025d8495dc78e57d65173d9461212df1.png

But most important as pointed out in the article is Authenticated Users have write and folder creation special privileges:

Eset_Auth.thumb.png.0942bccc35ac64e81e5791690e11abfe.png

 

Edited by itman
Link to comment
Share on other sites

1 minute ago, itman said:

Limited admins - yes. Admins have full control:

But most important as pointed out in the article is Authenticated Users have write and folder creation special privileges:

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

Link to comment
Share on other sites

Note the SANS POC article was written using Win XP where the owner of c:\Windows\System32\Tasks\ was Administrator. I also believe this is the case for Win 7.

Win 10 and possibly Win 8.1 now make this attack a bit more difficult in that the owner of c:\Windows\System32\Tasks\ is now System as shown in my screen shot. I do believe the Authenticated User bypass is still applicable however.

Link to comment
Share on other sites

Here's some detail on how malware can create a scheduled task running with system privileges. Reference for what I will be quoting from is: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks

 

Quote

Remarks

SchTasks.exe performs the same operations as Scheduled Tasks in Control Panel. You can use these tools together and interchangeably.

Permissions for schtasks:

  • You must have permission to run the command. Any user can schedule a task on the local computer, and they can view and change the tasks that they scheduled. Members of the Administrators group can schedule, view, and change all tasks on the local computer.
  • To schedule, view, or change a task on a remote computer, you must be member of the Administrators group on the remote computer, or you must use the /u parameter to provide the credentials of an Administrator of the remote computer.
  • You can use the /u parameter in a /create or /change operation only when the local and remote computers are in the same domain or the local computer is in a domain that the remote computer domain trusts. Otherwise, the remote computer cannot authenticate the user account specified and it cannot verify that the account is a member of the Administrators group.
  • The task must have permission to run. The permissions required vary with the task. By default, tasks run with the permissions of the current user of the local computer, or with the permissions of the user specified by the /u parameter, if one is included. To run a task with permissions of a different user account or with system permissions, use the /ru parameter

To run a task with system permissions example

The following command schedules the MyApp program to run on the local computer with permissions of the System account. In this example, the task is scheduled to run on the fifteenth day of every month, but you can use any schedule type for a task run with system permissions.

The command uses the /ru System parameter to specify the system security context. Because system tasks do not use a password, the /rp parameter is omitted.

  • schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /d 15 /ru System

In response, SchTasks.exe displays an informational message and a success message. It does not prompt for a password.

  • INFO: The task will be created under user name ("NT AUTHORITY\SYSTEM").
    SUCCESS: The Scheduled task "My App" has successfully been created.

 

Edited by itman
Link to comment
Share on other sites

Hum ……….. There was a Task Scheduler 0-day exploit that wasn't patched until Sept., 2018 cumulative update. And guess what? This did target Google's updater.

https://www.bleepingcomputer.com/news/security/windows-task-scheduler-zero-day-exploited-by-malware/

Perhaps we finally found the smoking gun?

-EDIT- Of note is Eset was on top of this as evidenced by this blog posting date 9/5/2018: https://www.welivesecurity.com/2018/09/05/powerpool-malware-exploits-zero-day-vulnerability/ . So it may be people nailed by this were before Eset mitigations were in place. Or God forbid, we are looking at new variant that is "flying under the radar" that embeded itself prior to exploit patching that is using an undetected backdoor.

Edited by itman
Link to comment
Share on other sites

4 hours ago, itman said:

Hum ……….. There was a Task Scheduler 0-day exploit that wasn't patched until Sept., 2018 cumulative update. And guess what? This did target Google's updater.

https://www.bleepingcomputer.com/news/security/windows-task-scheduler-zero-day-exploited-by-malware/

Perhaps we finally found the smoking gun?

-EDIT- Of note is Eset was on top of this as evidenced by this blog posting date 9/5/2018: https://www.welivesecurity.com/2018/09/05/powerpool-malware-exploits-zero-day-vulnerability/ . So it may be people nailed by this were before Eset mitigations were in place. Or God forbid, we are looking at new variant that is "flying under the radar" that embeded itself prior to exploit patching that is using an undetected backdoor.

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.

Link to comment
Share on other sites

This recent task manager vulnerability is far from the only one being discovered. They have been others. Here's one from 2015 that also affected Win10: https://vuldb.com/?id.77634 . Also since the CVE for this one was issue in 3/2015, it took Microsoft 6 months to patch this one ………….

The problem is when exploit POC code is released prior to a patch being deployed as was this case, it is "Christmas Day" for the hackers.

Also per the Eset malware discovery in this recent case, there was a period of a few days where this exploit was in the wild. So it is possible there are still devices with malware delivered during that period. Luckily, the use of this recent exploit was not widely dispersed.

Edited by itman
Link to comment
Share on other sites

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!

Edited by koolholio
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...