‘Tis the season…for ransomware! Crooks, just like everyone else, are looking to make a little bit of extra money this holiday season so they can get their kids that GI Joe with the Kung-Fu grip (points for whoever gets the movie reference). Recently, I have been pushed to really pay attention to the Trojan/Ransomware landscape, and it has been an eye-opening experience, to say the least. Some of these things are really nasty and are huge headaches for organizations that get hit with them. Ransomware, in particular. If system admins have not done due diligence with their backups, they are in for a world of hurt and organizations can find themselves paying the ransom for a decryptor which may or may not work.
For an example of how bad ransomware can be one needs to only look at the State of Louisiana, which has had a rough 2019. Louisiana has been wrestling with Ryuk since July of this year: the school districts first and then the state government in November. It was bad enough that parts of the state government’s infrastructure were taken offline during the event. Louisiana isn’t the only southern U.S. state that has fallen victim to Ryuk, either. Georgia’s court systems were hit in July of 2019 and two Florida cities in June.
Ryuk is one of the active ransomware strains out in the wild. It has been around for a little over a year now, and has become one of the more-frequently seen pieces of ransomware. In addition to being the name of a ransomware strain, Ryuk is also the name of a Shinigami (a Japanese god of death) from the manga series Death Note. In that series the character, out of boredom, drops a death note which allows anyone who finds it to kill other people by knowing their name and face. So, the naming for both the ransomware and character is appropriate.
Ryuk needs help to get on to a system/into an environment, so it usually arrives towards the end of a campaign after attackers have compromised an environment and have been in it for some amount time. Lately, it has been seen after attackers have introduced Emotet and/or Trickbot into an environment, conducted some reconnaissance, moved around laterally, and escalated their privileges. Once they have gained administrative privileges and done whatever it is they were planning to do, attackers will use Powershell to spread Ryuk across hosts in an environment.
Attackers have added a new method of spreading Ryuk. The State of Louisiana attack involved the use of Group Policy Objects (GPOs), which is yet another way attackers are living off the (Windows) land. While I was participating in an investigation into a particular matter I noticed there was little information about how the GPOs were actually used in this attack methodology and what evidence is left behind after such an attack. So, just as I did with Snapchat earlier this year, I thought I would pass along some information in the hopes that others may find it useful.
A few notes. First, I am not, in any fashion, affiliated with the organization(s) that investigated any of the incidents I have mentioned in this post. I have, however, participated in a few investigations lately that involved Ryuk and GPOs. Second, while I have done some research on GPOs for both the investigations and this post, I am not a GPO person. So, if you find something that is incorrect, please contact me and let me know so I can correct it. Third, there was some luck involved that resulted in being able to write this blog post, I will be the first to admit it.
Finally, I do not know if this is how GPOs were used in the State of Louisiana incident or other incidents in which GPOs were utilized. It is just how they were utilized during the incidents I have been involved with, so your mileage may vary. You may or may not find any/all of the files described here.
THE SETUP
For this attack methodology to work, attackers need administrative-level access to a domain controller(s), which, from my understanding, was something they were already getting, so this part is not new. What is new is what they are doing when the get access to the domain controller. Before this methodology was used the attacker dropped two folders on to the domain controller. While I haven’t been doing this too terribly long, what I have seen is that attackers utilize the C:\temp folder. They could potentially utilize any directory; however, C:\temp is hardcoded in the Powershell scripts (discussed shortly), so changing directories would require a small amount of re-tuning. Figure 1 shows the content of the C:\temp folder.
Because some of the file and folder names are somewhat unique, I am redacting when needed and using color coding to help keep things straight. This attack methodology occurs in two stages, with the tools for the first stage in the RED folder. The first stage requires changing the settings of endpoints so that Ryuk can easily be executed. A GPO is created to change those settings, and attackers appear to be creating this GPO using a template. I found the same registry settings in multiple matters. A registry.pol is found in the C:\temp\%REDBOX%\DomainSysvol\GPO\ directory. Registry.pol files are normally created after an administrative template is added within a GPO; the settings are stored in the registry.pol file. Figure 2 shows the registry settings in the policy file found here.
As can be seen, many settings are changed, including:
– Enable Powershell Scripts
– Change Powershell Execution Policy to Unrestricted
– Disables Logon Script Delay
– Sets the Group Policy refresh interval
– Allows Unencrypted WinRM client traffic
– Enables HTTP and HTTPS WinRM listeners
– Allows for WinRM Remote Shell Access
– Disables spyware, real-time monitoring, Microsoft Security Center, and Windows Defender
– Allows Unlisted Programs to run in Terminal Services
These settings were found in the file “gpreport.xml,” which was found in C:\temp\%REDBOX%\DomainSysvol. I suspect attackers may be importing this xml file with the associated registry.pol file, but this is mere speculation as I have no domain controller on which to test this. Examining gpreport.xml finds there are comments for each setting. Figures 3, 4, 5, and 6 are excerpts of the contents of this file.
Once this first-round GPO is created, it is pushed to machines and endpoints across the domain. Machines in the environment that apply this policy are defenseless. Literally.
To ease the pain of cross-domain GPO deployment where multiple domains are present, attackers are utilizing migration tables (.migtable files). By using migration tables, attackers can easily map the malicious GPO to any environment, even when that environment has multiple domains/forests. This allows attackers to specifically craft attacks for the environments they may find themselves in. (Un)Luckily, the attackers have a Powershell script at their disposal that can create the .migtable files for them in addition to creating the GPO. Check out the contents of the RED folder in Figure 7.
The name of the Powershell script (%red box%.ps1) is so unique, I am redacting it. Just know the name of that script was an obvious clue that immediately caught my attention. Figure 8 shows the contents of the script. The script can, obviously, be named anything. Here, the attacker was nice enough to name it something that was eye-catching.
The script does two main things. First, it takes the file “GPO.migtable,” pulls the information for the current domain (i.e. where the attacker is and and wants to attack), and creates a new .migtable file “1.migtable.” See Figures 9 and 10 for those files, respectively.
Note that in this particular .migtable file, the attacker did not change the destination folder “\share11,” but it could be named anything.
The second thing the script does is create the GPO.
If you recall, I mentioned the .pol file seen in Figure 2 sets the Group Policy refresh interval, which specifies how often domain clients will look to update their Group Policies. Going back to the gpreport.xml file, one will find these values. In Figure 11, the refresh interval is enabled, and in Figure 12, the interval setting causes the domain clients to refresh their Group Policies every 30 minutes. Figure 12 also shows a random interval value of 10 minutes, which is time added to the refresh interval to keep the domain controllers from getting hit by every client in the domain at the same time looking for Group Policy updates.
The GPO refresh interval is only changed after its been pushed to the clients, which begs the question “when do these settings take effect?” That part I am uncertain of, but there was evidence of attackers executing the Group Policy Management Console tool on a domain controller shortly after compromise, which lends me to speculate the attackers may be using that tool to push down this initial round of changes in addition to importing their malicious settings.
THE EXECUTION
Now that the domain controller is compromised and the domain clients have their defenses down, it’s time to execute Ryuk, right? Well, almost. There is one more Group Policy that needs to be created and distributed. If you were paying attention to Figure 1, you would remember there is another folder present…the BLUE one. This folder contains all of the files needed for the second stage of this attack. Figure 13 shows the contents.
Just as before, there is a Powershell script (ending in _01a.ps1) that helps the attacker create the needed files, the GPO, and set the stage for final deployment. See Figure 14.
There are a few things happening in this script. First, the directory C:\temp\system is created, designated as “share$” (green box), and the v2.exe and v2c.exe files are placed in it. Next, another gpreport.xml file is created, but this time it is in a different directory (blue box). The file gpreport1.xml is used as a template. As before, I suspect attackers are importing this second gpreport.xml file into Group Policy Management Console once all the necessary dependicies are created. Figure 15 shows the top of gpreport1.xml. Note the name in the red box.
Further down in the file are the GPO settings for the client to update their C:\temp folders with the Ryuk executable. See Figure 16.
If you noticed all the way at the bottom of Figure 16 you’ll see the tag “Name” and the value of “Files.” Let’s get back to the Powershell script for just a second. See Figure 17.
The red box in Figure 17 is fetching the contents of Files1.xml, replacing some data, and creating Files.xml (from the name tag I just mentioned). Figure 18 shows the contents of Files1.xml. Note that the actions are the same (in the red boxes).
The green box in Figure 17 refers to the file “ScheduledTasks1.xml.” The script fetches the contents of that file and spits out ScheduledTasks.xml for the machine portion of the GPO. See Figure 19 for ScheduledTasks1.xml.
While I am not showing it here, just know the names, settings, executable paths, etc. in this file all came from the previously referenced gpreport1.xml file. I should note it appears this task is run under the NT AUTHORITY\SYSTEM account.
But, just to make sure things go according to plan, there is another scheduled task that is setup, which I think may be a fail safe in the event the first scheduled task fails for any reason. Back in Figure 17 you’ll notice the purple box with ScheduledTasks12.xml. Figure 20 show its contents, and, as you can see, it is mostly the same as the previous scheduled task, with the only substantial difference being the executable runs as the logged in user.
Just as with the settings in ScheduledTasks1.xml, these settings also come from the gpreport1.xml file, and will also produce a ScheduledTasks.xml file for the user settings portion of the GPO.
With the GPO created and deployed, it is just a matter of time before Ryuk is unleashed in the environment.
THE AFTERMATH
One of the few questions that is always asked is how was Ryuk spread by the attacker during the incident. It generates another question for examiners: “What should examiners look for to make this determination?” Well the answer is not as simple as “look for x.” As with anything we investigate, there are multiple artifacts left behind that, collectively, paint the picture of the incident and help us understand what happened.
As an example, while examining event logs in one incident I noticed a few scheduled tasks that fired off just before the ransom note files started appearing in the $MFT. Walking back a bit on the $MFT I found the “Files.xml” and “ScheduedTasks.xml” files landed on the machine before the scheduled tasks started. Pulling those files pointed me to a domain controller from where the client machine had updated its C:\temp folder. Visiting the C:\temp and C:\share$ folders on the domain controller found the files discussed in this post, and shellbag data saw at least two trips to those directories during the event window. $MFT data saw the creation of the attacker tools in those directories, too. User Assist data on that domain controller found the execution of the Group Policy Management Console . I could go on, but you get the gist. At that point the picture started to come into focus.
Obviously, it will not be like this every time this methodology is used. Again, these files may or may not be present. And, while GPO use isn’t new (BitPaymer has been using GPOs for over a year now), it is a bit of a change for Ryuk. Even though it is a change, it is not impossible to detect. In fact, I would be willing to bet someone out there has already developed a better way to identify it and a way to prevent it. The lesson here is that examiners should always be vigilant for when attackers make hard left turns and change up their methodologies.
And Finally…
I want to thank everyone who has visited my blog over the past year and hope there was at least one thing that was helpful. I hope everyone had a great holiday season and wish everyone a very happy year!
2 thoughts on “Ryuk and GPOs and Powershell, Oh My!”