Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Some type of worm using psexec and mimikatz?


  • Please log in to reply
7 replies to this topic

#1 itasor

itasor

  • Members
  • 6 posts
  • OFFLINE
  •  
  • Local time:11:29 AM

Posted 30 March 2015 - 09:43 AM

Has anyone experienced this or similar recently? We've seen multiple unrelated clients get hit with something that resembles a worm. It appears to use mimikatz to steal passwords for the currently logged on user (Active Directory) and then reaches out to other PCs on the network and uses psexec to run something. I assume it's trying to steal the next computer's username/password and so on. Processes can be seen in Task Manager running under other user accounts that are NOT logged into the PC. The users (which have never otherwise logged into the PC) then have profiles in C:\users. This process leaves the PSEXECSVC Windows service (visible in services.msc) and saves mimikatz.exe and other random KB_______.exe and ms_______.exe files in C:\ProgramData and C:\users\username\appdata\roaming and \appdata\local\temp. It seems to disable the Windows Firewall and Windows Update services, and it breaks Show Hidden Files so it can't be turned on or off.

 

Users have complained of audio/music playing in the background, and we've found .mp3 files in c:\users\username\appdata\roaming. It's hard to recover from this because cleaning the PCs one by one is great until an infected one is turned back on with network connectivity and hits all the cleaned/rebuilt ones again.

 

The thing that's most worrying to me is that I can't find much about this online. This appears to be the closest thing: http://blog.cylance.com/operation-cleaver-net-crawler

 

Any ideas what this could be? It seems to be getting more popular last week and this week, as I've never seen anything like it before and now have multiple cases.

 

Edited to add: It seems that Hitman Pro finds a dro[1].exe file on many of the infected PCs. It's in a Temporary Internet Files folder.


Edited by itasor, 30 March 2015 - 10:35 AM.


BC AdBot (Login to Remove)

 


#2 JohnnyJammer

JohnnyJammer

  • Members
  • 1,116 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:QLD Australia
  • Local time:01:29 AM

Posted 30 March 2015 - 06:44 PM

First thing first, it would have to eb running at domain adminlevel to execute through psexec, so change the administrators password pronto.

Also setup a group policy to disallow psexec.exce from running on C:\*

Thirdly make sure no user account has admin rights, ecspecially global admin rights or local admin rights.

If its conencting to each amchine IPC$ then im assuming it has the Domain\Administrator account token/password.



#3 itasor

itasor
  • Topic Starter

  • Members
  • 6 posts
  • OFFLINE
  •  
  • Local time:11:29 AM

Posted 30 March 2015 - 07:07 PM

This particular environment has Domain Users added to each PCs local Administrators group, so I don't think it would necessarily need to be running as a Domain Admin. With that configuration, each regular user has full admin access to all PCs.

The users it was running psexec as are regular domain users, so that backs up my thoughts above. Removing Domain Users from local Admins is probably the first step to prevent spreading.

GPO to disallow psexec is a good idea. Thanks! It's disturbing that I can't find other cases of this online.

#4 JohnnyJammer

JohnnyJammer

  • Members
  • 1,116 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:QLD Australia
  • Local time:01:29 AM

Posted 30 March 2015 - 08:52 PM

No, their Local admins which emans if they tried to net use \\workstation3\ipc$ if would fail.

So this leads me to believe it is replicatign using the Domain Admins group.

Can i also ask why you would allow local admin rights for users? this is a big no no in any enviroment mate.

 

Any execution would be elevated to Admin on each node mate.



#5 itasor

itasor
  • Topic Starter

  • Members
  • 6 posts
  • OFFLINE
  •  
  • Local time:11:29 AM

Posted 30 March 2015 - 09:01 PM

No, their Local admins which emans if they tried to net use \\workstation3\ipc$ if would fail.

So this leads me to believe it is replicatign using the Domain Admins group.

Can i also ask why you would allow local admin rights for users? this is a big no no in any enviroment mate.

 

Any execution would be elevated to Admin on each node mate.

 

Didn't build or manage the environment -- just cleaning this mess. However, I've seen plenty of cases where specific software only works with users being local admins and some even require UAC to be disabled. Ridiculous for sure, but sometimes you can't control what these software vendors require. Just try to make the best of it.

 

They're local admins, BUT if "Domain Users" group is added to a PC's local admins group, that makes the user on workstation2 also an administrator of workstation3. I haven't tried it, but I think that would mean that the administrative shares like ipc$ are accessible. Probably a good reason to just add a specific user account to each PC's local admins group if an exception is needed (or for software compatibility).



#6 psloss

psloss

  • Members
  • 8 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:29 AM

Posted 30 March 2015 - 09:29 PM

This particular environment has Domain Users added to each PCs local Administrators group, so I don't think it would necessarily need to be running as a Domain Admin. With that configuration, each regular user has full admin access to all PCs.

The users it was running psexec as are regular domain users, so that backs up my thoughts above. Removing Domain Users from local Admins is probably the first step to prevent spreading.

GPO to disallow psexec is a good idea. Thanks! It's disturbing that I can't find other cases of this online.

Well, I can't imagine many organizations are anxious to publicly disclose that they were compromised.  (Which might indicate that they could still be compromised.)  There are certainly some legal requirements to do so, though.



#7 psloss

psloss

  • Members
  • 8 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:29 AM

Posted 30 March 2015 - 09:45 PM

 

No, their Local admins which emans if they tried to net use \\workstation3\ipc$ if would fail.

So this leads me to believe it is replicatign using the Domain Admins group.

Can i also ask why you would allow local admin rights for users? this is a big no no in any enviroment mate.

 

Any execution would be elevated to Admin on each node mate.

 

Didn't build or manage the environment -- just cleaning this mess. However, I've seen plenty of cases where specific software only works with users being local admins and some even require UAC to be disabled. Ridiculous for sure, but sometimes you can't control what these software vendors require. Just try to make the best of it.

 

They're local admins, BUT if "Domain Users" group is added to a PC's local admins group, that makes the user on workstation2 also an administrator of workstation3. I haven't tried it, but I think that would mean that the administrative shares like ipc$ are accessible. Probably a good reason to just add a specific user account to each PC's local admins group if an exception is needed (or for software compatibility).

 

Microsoft recently (within the last year or so) added additional controls to prevent these common lateral movement cases:

http://blogs.technet.com/b/pfesweplat/archive/2014/10/17/prevent-lateral-movement-using-local-accounts-with-the-new-groups.aspx

 

A very common "as designed" case is also something that Microsoft talked about mitigating, which is where either "the" local admin account (RID = 500) or a local admin account with the same user name has the same password across many machines.  From the first version of "Mitigating Pass-the-Hash Attacks...":

http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating%20Pass-the-Hash%20(PtH)%20Attacks%20and%20Other%20Credential%20Theft%20Techniques_English.pdf

 

in addition, many organizations have deployment and operational processes that result in defining the same administrative local account and password on many computers.  Maintaining identical passwords makes it significantly easier for attackers to compromise all computers that use them and obtain all credentials stored on these computers.

 

If "the same administrative account" is used across many computers, then if an attacker can get into the LSASS process on just one computer with mimikatz (local admin access is enough), they can then pass the hash for that account to all the other computers with that account.  Lateral movement can also lead to higher privilege escalation -- they might get lucky and one of those computers might have a "live" domain admin login or token.  (Or logon/token from another high-privilege domain account.)


Edited by psloss, 30 March 2015 - 09:48 PM.


#8 Didier Stevens

Didier Stevens

  • BC Advisor
  • 2,658 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:05:29 PM

Posted 31 March 2015 - 11:37 AM

1) do you have AV detections for this (apart from Milikatz and psexec)?
2) did you submit dro[1].exe to VirusTotal? Can you post the links to the analysis report?

Didier Stevens
http://blog.DidierStevens.com
http://DidierStevensLabs.com

SANS ISC Handler
Microsoft MVP 2011-2016 Consumer Security, Windows Insider MVP 2016-2018
MVP_Horizontal_BlueOnly.png

 

If you send me messages, per Bleeping Computer's Forum policy, I will not engage in a conversation, but try to answer your question in the relevant forum post. If you don't want this, don't send me messages.

 

Stevens' law: "As an online security discussion grows longer, the probability of a reference to BadUSB approaches 1.0"





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users