sunspot-solarwinds

SolarWinds supply chain attacks continue to track progress

Introduction

This article summarizes the progress of SolarWinds supply chain attacks, mainly including the interpretation of newly discovered technical points and the latest developments related to the attack.

1 Phase of obtaining initial permissions

1.1 Event progress

On January 7, the US Cybersecurity and Infrastructure Security Agency (CISA) updated its investigation report on supply chain attacks, “Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations.” The report pointed out that before the attackers implanted the SUNBURST backdoor into SolarWinds, they used password guessing and password spraying techniques to compromise its cloud infrastructure.

Volexity disclosed the technical details of SolarWinds’s Outlook Web App (OWA) mail system’s multi-factor authentication (MFA) was bypassed, the Exchange server was compromised by a vulnerability (CVE-2020-0688), and specific emails were stolen. Because they have the same TTP, it is believed that this supply chain attack was done by the same organization.

1.2 Analysis of technical points

Password guessing and password spraying

Password guessing is a common attack method, which is to continuously try different passwords for the username of an account until the guess is successful. Attackers usually choose system default passwords, commonly used weak passwords, or password dictionaries generated based on target-related information for password blasting attacks. Password spraying is also called reverse password guessing. Its attack method is the opposite of traditional password guessing. Password spraying uses the same password to guess different user names and see which user uses the password. Password guessing is that the user name is fixed, and the password is traversed first; the password spraying is the password is fixed, and the user name is blasted first. Password spraying is more effective for systems that use wrong passwords to lock user mechanisms.

The following screenshots of the test attack on OWA illustrate the difference between password guessing and password spraying. It can be seen that the password spraying will not cause the user to lock out, so the set time interval is not used, and the blasting speed is very fast; and the password guessing, after guessing the password, wait for a time interval (here set to one minute) to avoid causing The account is locked, the figure below shows password guessing and password spraying.

clip_image001

clip_image002

OWA Duo MFA bypass

Volexity’s investigation gave some technical details of the OWA server protected by the attacker bypassing Duo MFA.

From the log of the Exchange server, the attacker used a username and password to log in, but did not enter Duo’s second authentication factor. Judging from the logs of the Duo server, there was no request for secondary authentication using Duo. Through the memory exported by the OWA server, Volexity can determine that the user’s session has not been hijacked, but the attacker directly used the legitimate Duo MFA Cookie parameter duo-sid.

How is this done?

First, the attacker obtained the key (akey) for Duo integrated authentication in the OWA server. Then, the attacker uses this secret key to construct a calculated cookie parameter duo-sid. Finally, the attacker uses the user name and password to log in, and uses duo-sid to authenticate the Duo MFA check, thereby achieving the final successful login.

The attacker used the mechanism of MFA itself, not a loophole, so no security protection mechanism was triggered.

CVE-2020-0688

Microsoft Exchange Control Panel (ECP) Vulnerability CVE-2020-0688 is a serious vulnerability in Exchange server in 2020. As long as an attacker has a user right, he can completely control the Exchange server, which is easy to exploit and serious. The figure below is the result of the local test.

clip_image004

For more details about the vulnerability, please refer to the ZDI vulnerability link at the end of the article.

OWA mail theft

Volexity pointed out that after the attackers took control of the Exchange server, they did a lot of operations until they dragged away the mails of the specified users. The vast majority of operations are performed through PowerShell. Here are a few more critical operations.

# Get the Exchange server user name and role

C:\Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command "Get-ManagementRoleAssignment -GetEffectiveUsers | select Name,Role,EffectiveUserName,AssignmentMethod,IsValid | ConvertTo-Csv -NoTypeInformation |% {$_ -replace'`n','_'} | Out-File C:\temp\1.xml"

# Query organization management members, sqlceip.exe is actually ADFind.exe

C:\Windows\ system32\cmd.exe /C sqlceip.exe -default -f (name=”Organization Management”) member -list | sqlceip.exe -f objectcategory=*> .\SettingSync\log2.txt

# Steal the mail of the specified user

C:\ Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command “New-MailboxExportRequest -Mailbox [email protected] -ContentFilter {(Received -ge '03/01/2020')} -FilePath'\ \\c$\temp\b.pst'”

# Packaged into an encrypted compressed package

C:\Windows\system32\cmd.exe /C .\7z.exe a -mx9 -r0 -p[33_char_password] "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Redir .png” C:\Temp\b.pst‍‍‍

# Download the compressed package

https://owa.organization.here/owa/auth/Redir.png

# Clear traces

C:\Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command "Get-MailboxExportRequest -Mailbox [email protected] | Remove-MailboxExportRequest -Confirm:$False"

2 Backdoor implantation stage

2.1 About SUNSPOT

Event follow-up

The various behaviors of the SUNBURST backdoor discovered by FireEye have been analyzed very clearly, but how the SUNBURST backdoor was implanted has always been a mystery. Recently, CrowdStrike and another company made new discoveries when investigating supply chain attacks. They found another malware and named it SUNSPOT. The function of the malware is to modify the construction process of SolarWinds’ Orion product, replacing the normal code with the code of the SUNBURST backdoor, thereby infecting the Orion product and forming the final supply chain attack.

The main features of SUNSPOT can be summarized as follows:

· The purpose of SUNSPOT is to implant the SUNBURST backdoor in Orion IT management products.

· SUNSPOT monitors the compiler of Orion products in real time. During the process of compiling Orion products, one of the source code files will be replaced with the code of the SUNBURST backdoor, so that the compiled products have backdoors.

· SUNSPOT has some protection mechanisms to avoid compilation errors caused by code replacement, so it will not be noticed by developers.

Regarding the SUNBURST backdoor, we already know that it was implanted by the SUNSPOT malware, but how is SUNSPOT implanted? This requires the relevant investigation team to continue to follow up.

Technical point analysis

According to CrowdStrike’s disclosure, the technical points used by SUNSPOT can be summarized as the following process:

Initialization and logging phase

· The file name of SUNSPOT on the disk is taskhostsvc.exe, which is named taskhostw.exe internally by the developer. SUNSPOT is added to the scheduled task to ensure that it starts automatically after booting, so as to maintain the authority.

· When SUNSPOT is executed, it will first create a mutex named {12d61a41-4b74-7610-a4d8-3028d2f56395} to ensure that it has only one running instance. Create an encrypted log, the path is C:\Windows\Temp\vmware-vmdmp.log, disguised as a vmware log file.

·The log is encrypted with a hard-coded secret key FC F3 2A 83 E5 F6 D0 24 A6 BF CE 88 30 C2 48 E7 combined with the RC4 algorithm. A sample format of the log after decryption is as follows:

0.000 START

22.781[3148] + 'msbuild.exe' [6252] 181.421[3148] - 0

194.343[3148] -

194.343[13760] + 'msbuild.exe' [6252] 322.812[13760] - 0

324.250[13760] -

324.250[14696] + 'msbuild.exe' [6252] 351.125[14696] - 0

352.031[14176] + 'msbuild.exe' [6252] 369.203[14696] -

375.093[14176] - 0

376.343[14176] -

376.343[11864] + 'msbuild.exe' [6252] 426.500[11864] - 0

439.953[11864] -

439.953[9204] + 'msbuild.exe' [6252] 485.343[9204] Solution directory: C:\Users\User\Source

485.343[ERROR] Step4('C:\Users\User\Source\Src\Lib\SolarWinds.Orion.Core.BusinessLayer\BackgroundInventory\InventoryManager.cs') fails

· SUNSPOT will obtain SeDebugPrivilege privileges to facilitate subsequent reading of other process memory.

Hijacking the software build phase

· Similarly SUNBURST back door, SUNSPOT hash algorithm using a self-defined string handling, to find MsBuild.exe process.

· SUNSPOT uses the NtQueryInformationProcess method to query the PEB of the MsBuild.exe process, obtains its parameters through the _RTL_USER_PROCESS_PARAMETERS structure, and determines whether it is the construction process of the Orion product through the parsed parameters. If so, proceed to the next source code replacement.

· SUNSPOT finds the project file path of the Orion product solution in the MsBuild.exe process, and only replaces the content of the InventoryManager.cs file with the code of the SUNBURST backdoor.

· In order to prevent its own SUNBURST backdoor code from being modified and causing compilation errors, SUNSPOT will also perform MD5 verification on it. The MD5 value is 5f40b59ee2a9ac94ddb6ab9e3bd776ca.

· SUNSPOT saves the normal code file as

InventoryManager.bk, name the SUNBUIRST backdoor code InventoryManager.tmp, and replace the original InventoryManager.cs file. Once the Orion product containing the backdoor has been built, restore InventoryManager.bk to the normal InventoryManager.cs file.

· In order to prevent code compiling warning messages caused by code compatibility, attackers add #pragma warning disable and #pragma warning statements to the modified code to avoid warning messages and attract the attention of developers.

· During the entire process, SUNSPOT will check another mutex {56331e4d-76a3-0390-a7ee-567adf5836b7}, and if there is a program, it will exit actively to avoid affecting the build process.

2.2 About SUNBURST

Event follow-up

The latest research by Securonix Threat Research explains from another aspect why the backdoor in SolarWinds Orion products has not been discovered for a long time.

In the announcement of SolarWinds, users are recommended to do the following.

clip_image005

The SUNBURST backdoor is loaded and executed by the SolarWinds.BusinessLayerHost.exe process in the Orion folder under the SolarWinds folder, but because the SolarWinds Orion product itself is a monitoring software, in order to run better by itself, the official recommendation is to add the AV/EDR white List. Attackers use this to greatly reduce the possibility of being detected by security software. Coupled with the strict inspection of the operating environment when the SUNBURST backdoor is running, it is almost impossible to detect it only by AV/EDR.

A suggestion given by Securonix Threat Research called “Watch the Watcher” is very meaningful. The SolarWinds Orion product itself is monitoring software and a watcher. We should monitor its behavior. Otherwise, once an attack similar to this one occurs –The harm caused by the “rebellion” from trusted software may be magnified many times.

Technical point analysis

3 Privilege escalation and privilege maintenance phase

3.1 Incident follow-up

During the privilege escalation and privilege maintenance phase, CISA discovered that the attack added additional authentication credentials, including Azure and Microsoft 365 (M365) tokens and certificates. The authentication token should be generated by abusing Security Assertion Markup Language (SAML) in the AD FS environment. Microsoft has added the corresponding detection script to its Azure detection tool Azure-Sentinel. For details, see the reference link at the end of the article.

3.2 Analysis of technical points

Golden SAML

The technique used by the attacker is often referred to as Golden SAML.

A normal SAML authentication process is as follows:

clip_image006

Picture from Sygnia

· Users access specific services, such as AWS, Office 365.

· The service is redirected to ADFS for authentication.

· Users use domain policy authentication.

· ADFS returns the signed SAML token to the user.

· Users use signed SAML tokens to access specific services.

The attack process of Golden SAML is as follows:

clip_image007

Picture from Sygnia

The attacker accesses the ADFS server and exports its private key and certificate.

The attacker accesses specific services, such as AWS, Office 365.

· The service is redirected to ADFS for authentication.

The attacker directly generates a signed SAML token through the obtained private key, eliminating the need for ADFS authentication.

The attacker uses the signed SAML token to access specific services.

The Golden SAML attack against AD FS and the Golden Ticket attack against AD DS have similar processes and purposes. The purpose is to construct high-privileged credentials, bypass some access restrictions, and achieve the purpose of maintaining permissions.

Solarleaks public sales data

On January 13, an organization claiming to be a SolarWinds supply chain attack registered a website to publicly sell the data they obtained. Including part of Microsoft’s source code, SolarWinds product source code, product source code and FireEye red team tools.

Website: http://solarleaks.net/

clip_image008

Judging from the update of the website, there are still many people trying to buy the data. The attacker said that he wants to see the sample file to determine the authenticity of the data, and he needs to pay 100 XMR first. As shown below.

clip_image009

Looking at the DNS data of solarleaks.net, you can find that the domain name resolution is registered by NJALLA, which is also the registrar used by the Russian organizations Fancy Bear and Cozy Bear. Among them, the SQA record even shows that people have nowhere to find the meaning You Can Get No Info.

clip_image010

The attackers claimed on the website that the clues about how they obtained the data are related to the hash value 25b23446e6c29a8a1a0aac37fc3b65543fae4a7a385ac88dc3a5a3b1f42e6a9e, but there are no public documents related to this hash value.

If these data are true and are used by other APT organizations or black production organizations, then the impact of this supply chain attack may continue to the next attack.