Storm-0501: Unveiling the Tactics Behind Multi-Stage Hybrid Cloud Attacks

Introduction

The global cloud services market, valued at $551.8 billion in 2021, is projected to reach $2.5 trillion by 2031. This explosive growth makes cloud environments a prime target for cyber criminals. One such group is Storm-0501, an extortion-orientated cyber crime group that’s been conducting multi-stage attacks against hybrid cloud environments in government, manufacturing, transportation, and law enforcement. Since its inception in 2021, Storm-0501 has changed its operations, shifting from targeting U.S. school districts to running RaaS operations. This blog post explains the tactics, techniques and procedures (TTPs) of the group to help improve organizational defenses with mitigation strategies.

Storm-0501 TTPs: Steal Technique

Initial Compromise and Discovery

Storm-0501 has traditionally obtained initial access using compromised credentials or exploitation of known vulnerabilities in systems with widespread use. In a recent campaign, Storm-0501 exploited known vulnerabilities in Zoho, ManageEngine (CVE-2022-47966), Citrix, NetScaler (CVE-2023-4966), and ColdFusion (possibly CVE-2023-29300 or CVE-2023-38203). After gaining entry into the target network, it conducts extensive exploration using several tools to find high-value assets, obtain credentials, and increase privileges.

Lateral Movement and Credential Theft

Storm-0501 uses Impacket’s SecretsDump and Cobalt Strike to move laterally across the network grabbing credentials to compromise additional devices. They target the administrative accounts, mostly utilizing password reuse or weak credentials, accessing both their on-premises and cloud environments. Using cloud session hijacking, especially in Microsoft Entra, they establish persistent backdoor access into the target systems.

From Ground to Cloud: Storm-0501’s Cross-Environment Exploits

One of the most significant tactics Storm-0501 uses is the exploitation of the Microsoft Entra Connect Sync service by doing synchronization of credentials between the on-premises AD and cloud. The attackers escalate the privileges in both environments after compromising the sync accounts to have control over the cloud environment and for a persistent backdoor for the next attack.

Storm 0501 Exploit
Credit: Microsoft

Aftermath of the Storm-0501 Attack

The aftermath of a Storm-0501 attack can be devastating, with the group often gaining control over both on-prem and cloud environments, exfiltrating sensitive data, deploying ransomware, and tampering with security products to avoid detection. The threat will only increase with the new deployment of Embargo ransomware, where victim data is encrypted and sensitive information leaked unless a ransom is paid.

Such attacks would lead to the stealing of credentials, data breaches, service disruptions, and heavy financial losses. Storm-0501 pays extra attention to sensitive sectors such as hospitals, which raises stakes not only on data security but also public safety.

Mitigation

Hybrid Cloud Security Enhancement

While Microsoft has implemented restricted permissions on DSA roles in Entra Connect Sync and Entra Cloud Sync, defending Storm-0501 needs a robust, multi-layered approach. Conditional Access policy can further harden access to cloud services from non-verified devices and locations as a risk mitigation approach.

Harden Cloud Security Measures

Even solutions proposed by today’s market leaders such as Microsoft are still often based on passwords in most cases and, hence, would probably fail to deliver proper authentication in a much-enlarged, cloud-to-on-premises environment. Therefore, organizations should embrace solutions such as PureAUTH IAM Firewall that come with the strongest security and reliability against attacks exploiting credentials and even zero-day vulnerabilities. Built on a zero-trust architecture, it provides reliable, passwordless protection, further enhancing resilience against sophisticated threats.

Conclusion

Organizations need to move away from convenient and conventional IAM solutions and start interacting with leading edge defenses, such as passwordless authentication. Enhancing cloud security policies and infrastructure defenses will enable enterprises to withstand new cyber threats.

Solutions like PureAUTH will help organizations build a far more robust infrastructure that is not only adaptable but will also neutralize the most sophisticated cyber threats in existence.

Read Also

Microsoft Entra ID Vulnerabilities: Pass-Through Authentication Risks

Storm-0501: Ransomware attacks expanding to hybrid cloud environments

The achilles’ heel of cloud security: Why two-factor authentication isn’t enough

How Hackers Exploit Active Directory Certificate Services for Long-Term Persistence

Introduction

Active Directory Certificate Services (AD CS) may seem like a helpful gatekeeper for managing digital certificates and encryption, but if it’s not configured just right, it can leave the door wide open for hackers. AD CS is often overlooked when it comes to security, making it a perfect treasure trove for attackers. And once they’re in, they can sneak around undetected, establishing long-term persistence in your network like they’re on an extended vacation.

Meme :  AD Certificate Services
Credit: Medium

In this blog, we’ll break down how hackers exploit AD CS, dive into some clever tactics from recent findings, and most importantly, explain what you can do to keep them out.

Hackers in the Shadows: How AD CS Is Exploited

AD CS is Microsoft’s Public Key Infrastructure (PKI) solution for issuing and managing digital certificates in Active Directory environments. When configured correctly, it helps secure network communications. But if misconfigured, AD CS can quickly become a hacker’s best friend, enabling them to access networks, steal credentials, and stay hidden for the long haul.

Key Attack Vectors

  1. Stealing Certificates: Imitation is the Best (Criminal) Strategy
    Hackers can grab user or machine certificates, along with private keys, and use them to impersonate legitimate users or machines. This is like copying someone’s ID, if the certificate remains valid, they can continue authenticating, even after passwords change.
  2. Requesting Fake Certificates: Elevation Without the Effort
    Imagine asking for a regular office key but getting access to the CEO’s office instead. Similarly, if there are any misconfigured certificate templates, low-privileged users can request certificates that grant admin-like privileges.
  3. Misconfigured Certificate Templates: Unintentional Free Pass
    Certificate templates can be dangerous when they allow attackers to specify Subject Alternative Names (SANs). This essentially hands over the keys to high-level users’ certificates—like getting access to a domain admin’s credentials. Templates that aren’t secured give attackers serious access.
  4. CA Private Key Theft: A Permanent Invitation
    If an attacker can get their hands on a Certificate Authority (CA) private key, they can generate certificates for any user in the domain. This grants them persistent access that’s nearly impossible to revoke.
  5. Become a Shadow CA
    If an attacker can get a certificate signing request (CSR) signed by CA, which has constraint isCA is set to True, and allowed its use for signing other certificates, then the issue\d certificate makes the attacker a Parallel CA, which can independently generate any arbitrary certificates which will be considered as valid.
How to exploit AD Certificate Services

Tools of the Trade: Certify and ForgeCert

Hackers aren’t going in blind—they’ve got tools that make exploiting AD CS a breeze. The whitepaper by Will Schroeder and Lee Christensen highlights two key tools:

  • Certify: This tool scans for AD CS misconfigurations and assists attackers in requesting malicious certificates. It functions like a vulnerability scanner specifically designed for certificates.
  • ForgeCert: Attackers use this tool to create fake certificates with a stolen CA private key. By forging these certificates, they gain permanent access to your network, making detection much more challenging.
 Certify tool to exploit AD Certificate Services

Mitigation: Fortify Your AD CS Before It’s Too Late

So, how can companies stop attackers from abusing AD CS? It’s all about treating your certificates like they’re gold and your CAs like they’re Fort Knox. Here’s a breakdown of what you need to do:

  1. Treat CAs as Critical Assets
    Your CA servers should be protected like domain controllers (or fort knox), lock them down and apply Tier 0 security controls. These systems are high-value targets, and attackers know it.
  2. Audit and Harden Certificate Templates
    Regularly audit your certificate templates and remove any unnecessary features, like SAN customization, which could give attackers an easy way in. Ensure templates are configured for minimum privilege.
  3. Secure CA Private Keys
    Store CA private keys in hardware security modules (HSMs). This keeps them away from prying hands and makes it significantly harder for attackers to steal them.
  4. Monitor Certificate Activity
    Keep an eye on your certificate enrolments, authentications, and template modifications. If something seems off, it probably is. Proactive monitoring can be your early warning system.

Conclusion

Active Directory Certificate Services isn’t inherently insecure, but its complexity makes it ripe for misconfiguration. When that happens, hackers can sneak in, steal credentials, and establish persistence that’s incredibly tough to detect and eliminate. As the Certified Pre-Owned whitepaper highlights, understanding the risks and securing AD CS is key to preventing these kinds of attacks.

To learn more about Secure usage & management of X509 Certificates, you can refer to this in depth Practitioners Guide authored by our founder Ajit Hatti as part of Null Cipher Security Club

In short, if you’re not securing AD CS, hackers might just settle in and stick around your network for longer than you’d like.

Read Also

Certified Pre-Owned: Abusing Active Directory Certificate Services

Microsoft Entra ID Vulnerabilities: Pass-Through Authentication Risks

Microsoft Reveals Russian Hack: Executives’ Emails Compromised

Secure Usage & Management of X509 Certificate

Microsoft Entra ID Vulnerabilities: Pass-Through Authentication Risks

Introduction to Microsoft Entra ID and Pass-Through Authentication

Microsoft Entra ID, previously known as Azure Active Directory (Azure AD), provides a unified identity management solution for both on-premises and cloud-based applications. One key feature of Entra ID Pass-Through Authentication (PTA), which allows users to sign in using the same password for both environments. This setup aims to enhance user experience and reduce IT support costs.

How Pass-Through Authentication Works

In PTA, the system validates users’ passwords against the on-premises Active Directory (AD) instead of storing them in the cloud. When a user tries to log in, Azure AD redirects them, and they enter their credentials. The system encrypts these credentials and sends them to a queue. An on-premises PTA agent retrieves the credentials from the queue, decrypts them, and checks them against the on-prem AD. The agent then sends the result back to Azure AD to complete the login process.

Microsoft Entra ID vulnerabilities: How PTA Works
Credit – Cymulate

Recent Vulnerabilities and Exploits

A recent vulnerability has exposed critical flaws in Microsoft Entra ID’s PTA mechanism. Researchers have discovered that attackers with local administrative privileges on a PTA agent can bypass authentication controls. This flaw allows attackers to impersonate any synchronised user without knowing their actual password.

This vulnerability effectively turns the PTA agent into a “Double Agent,” granting unauthorised access to any user account, including those with elevated privileges. If exploited, attackers could potentially gain full network privileges across the enterprise, posing significant risks.

Attack Methods and Implications

  1. Compromising the PTA Agent: Attackers who gain administrative access to the PTA agent can use tools to install a backdoor. This backdoor enables the attacker to authenticate as any user and even retrieve passwords in clear text.
  2. Seamless SSO Vulnerabilities: Seamless Single Sign-On (SSO) can also be used in coexistence with PTA, which introduces additional risks. Exploiting these vulnerabilities can further compromise an organisation’s security.
  3. Lateral Movement: Once inside the network, attackers can exploit the PTA vulnerability to move laterally across different domains and departments, increasing the scope of the attack.

Mitigation Strategies

To mitigate these risks, Microsoft suggested treating the Entra Connect server as a Tier 0 component, along with hardening the Microsoft Entra Connect server as a Control Plane asset.

Additionally, organizations should implement several key security measures:

  • Restrict Access: Limit access to PTA agent servers to prevent unauthorised modifications.
  • Robust Password Policies: Enforce strong password policies to enhance security.
  • Multi-Factor Authentication (MFA): Require MFA to add an additional layer of security and prevent lateral movement.
  • Monitor Authentication Logs: Implement encrypted authentication logs with detection alerts to identify and respond to potential breaches quickly.

Secure Authentication with PureAUTH

Time and again we have seen Microsoft and other traditional IAM solution providers rely on passwords & fail to provide secure authentication across cloud and on premise environments.

For more secure & reliable authentication, enterprises can depend on PureAUTH IAM firewall which protects enterprises from all credential based attacks and such 0 day vulnerabilities.

Conclusion

The Microsoft Entra ID vulnerability highlights the importance of securing authentication mechanisms and understanding potential weaknesses in identity management systems. With the constantly changing best practices implementing secure authentication is difficult. Organisations must constantly work to protect themselves from such threats.

For more details, refer to the Cymulate blog post and Microsoft’s official security advisories.

CVE-2024-6387: RegreSSHion Vulnerability in OpenSSH

Introduction

On July 1, 2024, the cybersecurity community was alerted to a significant vulnerability within OpenSSH, dubbed “regreSSHion” (CVE-2024-6387). This critical flaw, discovered by the Qualys Threat Research Unit (TRU), allows unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems. The vulnerability, which affects the default configuration of OpenSSH’s server (sshd), poses a severe security risk due to its potential for complete system compromise without user interaction.

What is regreSSHion?

regreSSHion
Credit: Qualys

RegreSSHion, tracked as CVE-2024-6387, is an unauthenticated RCE vulnerability in OpenSSH’s server (sshd). This flaw grants attackers full root access, making it a high-severity threat with a CVSS score of 8.1. The vulnerability affects versions 8.5p1 to 9.8p1 of OpenSSH, as well as versions earlier than 4.4p1 if not patched for previous vulnerabilities (CVE-2006-5051 and CVE-2008-4109). The issue arises from a signal handler race condition that can be exploited by failing to authenticate within a set time period (LoginGraceTime).

Background and Discovery

The Qualys TRU discovered that this vulnerability is a regression of a previously patched flaw, CVE-2006-5051, reported 18 years ago. A regression in this context means that a previously fixed issue has reappeared in a subsequent software release. This often occurs due to changes that inadvertently reintroduce the problem. The regression was introduced in October 2020 with OpenSSH version 8.5p1, highlighting the importance of thorough regression testing to prevent the reintroduction of known vulnerabilities.

Technical Details

The vulnerability involves a specific sequence of function calls and interactions between the signal handler and the main program logic. Here’s a breakdown of the critical components:

Function Call Chain:

  • __localtime64_r calls __tz_convert.
  • __tz_convert calls tzset_internal.
  • tzset_internal calls __tzfile_read.

Heap Allocation Issues:

  • __tzfile_read involves a call to fopen to read timezone files.
  • fopen allocates a FILE structure on the heap.

Exploit Strategy:

  • The attacker exploits the race condition by manipulating heap memory.
  • By carefully timing the SIGALRM signal, they can interrupt the malloc operation, leaving the heap in an inconsistent state.
  • This allows the attacker to control the FILE structure, leading to arbitrary code execution.

Impact and Exploitation Process

The regreSSHion vulnerability impacts glibc-based Linux systems running vulnerable versions of OpenSSH. Exploitation of this flaw can result in complete system takeover, allowing attackers to execute arbitrary code with root privileges. The attacker leverages the predictable heap layout and timing to achieve arbitrary code execution:

Heap Layout Manipulation:

  • The attacker creates a specific heap layout with controlled memory holes.
  • They send a series of crafted public-key packets to OpenSSH, forcing specific malloc and free operations.

Signal Timing:

  • The attacker sends a SIGALRM signal at a precise moment during the malloc operation.
  • This interrupts the malloc, leaving the heap in a vulnerable state.

Arbitrary Code Execution:

  • By overwriting parts of the FILE structure, the attacker redirects execution to their controlled function pointers.
  • This allows them to execute arbitrary code with the privileges of the OpenSSH process.

While successful exploitation has been demonstrated under lab conditions, it typically requires 6-8 hours of continuous connections. This makes mass exploitation challenging but not impossible.

Affected Versions

The vulnerability affects the following OpenSSH versions:

  • OpenSSH versions earlier than 4.4p1, if not patched for CVE-2006-5051 or CVE-2008-4109
  • OpenSSH versions from 8.5p1 up to, but not including, 9.8p1
Credit – PaloAlto

OpenBSD systems are not vulnerable due to their use of an async-signal-safe version of syslog(), which mitigates the race condition.

Mitigation and Recommendations

To protect against the regreSSHion vulnerability, it is recommended to:

  1. Update OpenSSH: Upgrade to the latest version, which is 9.8p1 or later.
  2. Network Controls: Limit SSH access through network-based controls to restrict unauthorised access.
  3. Micro Segmentation : Products like XShield by ColorTokens help in segmenting critical servers and containing access to them based on policies & detection of anomalies.

Workarounds

If you cannot apply the patch immediately, consider the following workarounds:

  1. Configuration Change:
    • Set LoginGraceTime to 0 in the OpenSSH configuration file. This eliminates the vulnerable window but may lead to denial of service by exhausting all available connections.
  2. Code Modification:
    • Temporarily comment out or remove the async-signal-unsafe code from the sshsigdie function in OpenSSH source code and recompile.

Current Status and Observations

As of July 2, 2024, there is no known activity in the wild exploiting this vulnerability. While proof-of-concept (PoC) code exists, it has not been successfully used to achieve remote code execution in testing environments. However, the potential for targeted attacks remains, and organizations are urged to apply patches and implement mitigation promptly.

Conclusion

The regreSSHion vulnerability in OpenSSH (CVE-2024-6387) underscores the critical need for rigorous regression testing and prompt security updates. By understanding the nature of this threat and taking proactive measures, organizations can mitigate the risks associated with this severe vulnerability and protect their systems from potential exploitation.

Stay informed and vigilant, and ensure your systems are updated to safeguard against this and other emerging cybersecurity threats.

Read More

Qualys Technical Paper

PuTTY Vulnerability Exposes Private Keys

Introduction: Understanding the PuTTY Vulnerability

PuTTY, a widely-used SSH and Telnet client, contains a critical vulnerability, tracked as CVE-2024-31497, affecting versions 0.68 through 0.80. This flaw allows threat actors to potentially recover private keys used for cryptographic signatures, posing significant security risks. 

Exploring the Vulnerability: How Attackers Exploit PuTTY

The vulnerability arises from the biased generation of ECDSA nonces for the NIST P-521 curve, used in SSH authentication. Attackers can leverage this flaw to recover private keys by collecting cryptographic signatures, enabling unauthorised access to SSH servers or the ability to sign commits masquerading as legitimate users.

PuTTY Vulnerability Exposes Private Keys

Expert’s Insights

“PuTTY’s technique worked by making a SHA-512 hash and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY’s technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later), it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.”

“In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.”

-PuTTY security advisory.

Impact and Implications: Risks Posed by the Flaw

The exploitation of this vulnerability can lead to severe consequences, including unauthorised access to sensitive systems, data breaches, and potential supply chain attacks. Affected software includes FileZilla, WinSCP, TortoiseGit, and TortoiseSVN, urging users to take immediate action.

The following software that uses the vulnerable PuTTY is confirmed as impacted:

  • FileZilla 3.24.1 – 3.66.5 (fixed in 3.67.0)
  • WinSCP 5.9.5 – 6.3.2 (fixed in 6.3.3)
  • TortoiseGit 2.4.0.2 – 2.15.0 (fixed in 2.15.0.1)
  • TortoiseSVN 1.10.0 – 1.14.6 (mitigation possible by configuring TortoiseSVN to use Plink from the latest PuTTY 0.81 release)

Mitigation and Resolution: Steps to Address the Vulnerability

In light of the vulnurability, users are advised do the following:

  1. Improved Randomness: Enhance the randomness of nonce generation by integrating a more robust cryptographic random number generator (RNG). This ensures nonces with sufficient entropy to prevent bias and enhances overall security.
  2. Different Hashing Algorithm: Consider utilising a different hashing algorithm or a combination of algorithms suitable for the NIST P-521 curve. Selecting a hash function compatible with curve parameters can mitigate bias introduced by modulo “q” reduction.
  3. Nonce Generation Scheme: Implement a nonce generation scheme independent of reducing the hash value modulo “q.” Develop a method to directly produce nonces within the defined range of “q” to preserve randomness and prevent bias.
  4. Comprehensive Review: Conduct a thorough review of the nonce generation process and cryptographic operations in PuTTY. Collaborate with security experts to identify and address any additional vulnerabilities or weaknesses, ensuring the fix is robust and effective.
  5. Update and Patch: Once a fix is developed, PuTTY would release a patch. Encourage users to upgrade to the latest version promptly to mitigate the vulnerability and enhance the security of their SSH connections.

Conclusion: Ensuring Security in SSH Environments

The PuTTY vulnerability underscores the importance of robust security measures in SSH environments. By staying informed and implementing necessary updates and precautions, organizations can bolster their defence against potential threats.

Read Also

Unveiling Terrapin: A New Threat to SSH Security

Investigating Fidelity Investments Life Insurance Data Breach: A Closer Look

In recent weeks, Fidelity Investments Life Insurance has come under scrutiny following a significant data breach affecting thousands of customers. Here’s what you need to know about the incident:

1. Data Breach Details:

  • The breach, which occurred between October 29 and November 2, 2023, stemmed from an unauthorised party accessing sensitive consumer data held by Fidelity Investments Life Insurance.
  • Approximately 28,000 customers were impacted by the breach, with their personal information compromised.
  • The breached data includes names, social security numbers, dates of birth, states of residence, and financial information, particularly bank account and routing numbers used for premium payments on life insurance policies.
  • This data can contribute to an increase in phishing attacks, and uplift the risk of identity theft or financial fraud for the customers.

2. Third-Party Involvement:

  • The breach was traced back to Infosys McCamish Systems, a third-party service provider utilised by Fidelity Investments Life Insurance.
  • Infosys McCamish notified Fidelity Investments of the breach in early November, prompting an investigation into the incident.

3. Ongoing Investigation:

  • Infosys McCamish has engaged external experts to conduct a thorough investigation into the breach.
  • While the investigation is ongoing, Fidelity Investments Life Insurance officials believe that a range of sensitive customer data was compromised during the breach.

4. Customer Notifications:

  • Fidelity Investments Life Insurance has begun notifying affected customers about the breach and the potential exposure of their personal information.
  • The company emphasises its commitment to protecting customer data and pledges to take appropriate actions in collaboration with Infosys McCamish.

5. Prior Incidents:

  • This isn’t the first time Infosys McCamish has caused security breaches.
  • In a separate incident, Infosys McCamish notified Bank of America about a breach affecting over 57,000 customers enrolled in deferred compensation plans.

6. Response and Assurance:

  • Fidelity Investments Life Insurance reassures customers that they have not impacted their systems by the breach and that they have detected no related activity within Fidelity’s environment.

7. Legal Investigation:

  • The law firm of Federman & Sherwood has initiated an investigation into the data breach at Fidelity Investments Life Insurance, aiming to assess the impact on affected individuals.

8. Call for Action: Implementing Zero Trust Measures

  • To mitigate the risk of data breaches like this in the future, companies can adopt a zero trust approach.
  • By implementing strict access controls, continuous monitoring, and least privilege access policies, organizations can significantly reduce the likelihood of unauthorised access to sensitive data, hence lowering the risk of data and reputation loss because of a third party vendor breach.

As the investigation unfolds and affected customers are notified, Fidelity Investments Life Insurance remains focused on addressing the breach, safeguarding customer data, and ensuring transparency throughout the process.

Stay tuned for further updates as the situation develops.

#getzerotrust #gopasswordless

Okta Breach Part 2: Unveiling the Full Scope and Impact

Introduction

In late October, Okta, reported a cybersecurity breach that initially appeared to affect less than 1% of its customers. However, recent revelations indicate a far-reaching impact, affecting 99.6% of users in the customer support system. This blog post delves into the broader implications of this

The True Scope Revealed

Contrary to initial estimates downplaying, it has now been disclosed that hackers successfully ran a report on September 28, 2023. It contained sensitive information about all Okta customer support system users. The compromised data had names, email addresses, company names, contact phone numbers, and other details, Impacting 100% of Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers. The only exception being those in highly sensitive environments such as the government.

Financial Impact on Okta

Despite the significant dip in Okta’s stock prices when the breach was first reported in October, resulting in a temporary loss of approximately $2 billion in market capitalisation, the financial fallout seems to be hovering in the single digits. Okta’s latest quarterly financial report indicates a more than 20% increase in revenues for the quarter ending October 31, demonstrating a robust financial performance despite the security incident.

Customer Trust at Stake

The discrepancy between the initially reported 1% impact and the actual 99.6% of affected users reveals a concerning lapse in transparency. Okta customers are now grappling with the realization that threat actors may have access to their names and email addresses, exposing them to the risk of phishing and social engineering attacks. While Okta assures that there is no direct evidence of exploitation, they urge customers to remain vigilant. This stolen information could be weaponized for targeted cyber scams.

Phishing and Social Engineering Threat

With 99.6% of users having their names and email addresses exposed. These stolen data poses a heightened risk of phishing and social engineering attacks.

Okta Phishing

Cyber security experts emphasise the need for Okta customers, especially administrators, to enforce multi-factor authentication (MFA) and consider the use of phishing-resistant authentication. The potential for threat actors to exploit this information for targeted attacks underscores the importance of proactive security measures on the customer’s end.

Conclusion

In the aftermath of the Okta breach, customer trust in identity management systems faces a critical test. As emphasised by the mantra “The ‘S’ in IAM stands for Security”, the true scale of the incident challenges the reliance on auto-saved passwords, demonstrating the vulnerability of conventional systems. We urgently advocate for the adoption of passwordless authentication. For those catching up, our previous post details the Okta breach, highlighting the imperative to #gopasswordless . This approach not only addresses current vulnerabilities but also aligns with the evolving demands of a secure digital landscape.

SUNBURST: A Vital Case Study of Supply Chain Attack

About SolarWinds:

SolarWinds is an American company that provides IT management and administration software that can be used by the Sysadmins and IT administrators in their organization. The reach of the SolarWinds Products is quite high and their products are used by many fortune-500 companies, spreading across the globe.

What is Supply Chain Attack:

Supply Chain Attack is a type of attack in which adversaries can modify the product provided by third-party associates in various ways to compromise multiple targets. The below image provides a visualization of the definition of the supply chain attack.

SoloriGate/Sunburst: SolarWinds Supply Chain Attack 

SolarWinds supply chain attack first came into the radar of the information security communities when Fireeye was found affected by this supply chain attack. Fireeye was very open & transparent about getting breached in this supply chain attack. Fireeye has been tracking the threat actors behind this global intrusion campaign as UNC2452. There was not much damage done to the organization as only their Red Assessment Tools were leaked in the whole scenario. Fireeye Reported that the tools which were stolen by the attackers did not contain zero-day exploits. Many other big organizations like Microsoft, VMware as well as US Government agencies like the US Department of State, Department of Homeland Security, and many more were found breached by this supply chain attack.

Technical Analysis of the SoloriGate Attack:

SolarWinds was reportedly breached first and the reason was most likely the weak password they were using for one of their access/update servers. The threat actors involved in this global intrusion campaign targeted multiple victims using infected SolarWinds Orion IT management & monitoring software updates. Note that most of the analysis that has been demonstrated in this blog is based on Microsoft’s and Fireeye’s Blog.

Note that most of the analysis that has been demonstrated in this blog is based on Microsoft’s and Fireeye’s Blog.

The infectious update was delivered as a Microsoft standard Windows Installer Patch file (SolarWinds-Core-v2019.4.5220-Hotfix5) which included the malicious DLL (Dynamic Link Library) named as SolarWinds.Orion.Core.BusinessLayer.dll which acts like a backdoor on the Attack Surface. The infected SolarWinds Orion IT management & monitoring software update and DLL was digitally signed and due to which it was highly evasive on the attack surface.

Figure: Digital Signature Details of Patch File

Figure: Digital Signature Details of SolarWinds.Orion.Core.BusinessLayer.dll

In order to know the internal working of the Sunburst/SolariGate Malware let’s decompile the malicious SolarWinds.Orion.Core.BusinessLayer.dll. The Malware samples related to the Sunburst attack can be found here.

In order to analyze the dll, open the file named under the directory APT_Backdoor_SUNBURST “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” (Which is basically named after the SHA256 hash of the SolarWinds.Orion.Core.BusinessLayer.dll) in the dnSpy. The infected code was found under the namespace “SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory” and more specifically in the “InventoryManager” class. 

Image: Decompilation of Malicious DLL.(Identifying the BackgroundInventory Namespace)

Image: Decompilation of Malicious DLL (Going through the InventoryManager Class under the Namespace)

Now this class has a “RefershInternal()” method that creates a new thread which calls the Malicious OrionImprovementBusinessLayer class where all the backdoor magic happens.

Image: Analyzing the RefreshInternal Method

The image below sums up the flow of the infected SolarWinds.Orion.BusinessLayer.dll.

Image: Malicious DLL process flow diagram

To be more evasive on the attack surface the malware code in the DLL runs various checks to make sure that it is not being analyzed using some programs. That is why, hash of the processes, services and drivers on windows is calculated and checked with the blacklisted hashes of the same, and if none of the blacklisted hashes are found on the system then only backdoor code gets activated.

Adversaries in this case used DGA (Domain Generation Algorithms) to dynamically build and resolve the subdomain of avsvmcloud.com. The C2 domain consist of two static and two variable parts which is illustrated in the image below.

Image Source: Microsoft

After the malware has made a successful connection to the C2 server the SoloriGate malware performs the primitive lateral movement, credential abuse, and privilege escalation techniques for further infrastructure exploration. 

The image below from Microsoft illustrates the whole process of SoloriGate Malware infection.

Image Source: Microsoft

According to Microsoft the threat actors are targeting to steal the SAML token signing certificates, using which attackers can easily forge the SAML tokens and access the resources. 

Here is the elaborated descriptive blog post about the SolariGate identity IOC’s.

Defense against SUNBURST/SoloriGate:

  • Fireeye Team uploaded a List of IOC’s and signatures which can be used by organizations for identifying the backdoor.  The GitHub repository of Fireeye countermeasures can be found here.
  • It is also recommended by SolarWinds to go through this advisory page and also upgrade their Orion platform to Orion Platform release 2020.2.1 HF 1.
  • MITRE ATT&CK Techniques related to SolariGate/SUNBURST:
IDDescription
T1012Query Registry
T1027Obfuscated Files or Information
T1057Process Discovery
T1070.004File Deletion
T1071.001Web Protocols
T1071.004Application Layer Protocol: DNS
T1083File and Directory Discovery
T1105Ingress Tool Transfer
T1132.001Standard Encoding
T1195.002Compromise Software Supply Chain
T1518Software Discovery
T1518.001Security Software Discovery
T1543.003Windows Service
T1553.002Code Signing
T1568.002Domain Generation Algorithms
T1569.002Service Execution
T1584Compromise Infrastructure
Table: MITRE ATT&CK Techniques

Conclusion:

This SolarWinds Supply Chain Attack is surely raising the eyebrows of people in the IT industry and also outside the IT industry. Right from STUXNET to NotPetya we have seen many supply chain attacks that were found devastating. In 2017-18 NotPetya was found to have cost  10 Billion Dollars in damages. The evasive Behaviour of the attack made it so hard to be identified in the wild.  Currently, SolarWinds Orion Platform is used by 300,000 customers and out of which 18,000 have downloaded the malicious update.

I hope this blog provided you with a better view of the SoloriGate and SUNBURST attack.

References:

https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/understanding-quot-solorigate-quot-s-identity-iocs-for-identity/bc-p/2009890#M3044

https://labs.sentinelone.com/solarwinds-sunburst-backdoor-inside-the-stealthy-apt-campaign/