Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service, and it supports multiple authentication methods. The premium version of Azure AD also supports Conditional Access policies (CAPs) that grant or block access based on defined criteria, such as device compliance or user location. Azure AD stores the settings for the authentication methods and CAPs. CAPs can be modified via the Azure AD portal, PowerShell, and API calls.

In May 2022, Secureworks® Counter Threat Unit (CTU) researchers investigated which APIs allow editing of CAP settings and identified three: the legacy Azure AD Graph (also known as AADGraph), Microsoft Graph, and an undocumented Azure IAM API. AADGraph was the only API that allowed modification of all CAP settings, including the metadata. This capability lets administrators tamper with all CAP settings, including the creation and modification timestamps. Modifications made using AADGraph are not properly logged, endangering integrity and non-repudiation of Azure AD policies.

CTU researchers shared these findings with Microsoft on May 26, 2022. Microsoft confirmed the findings a month later but stated that it is expected behavior. On May 11, 2023, Microsoft notified CTU researchers of planned changes to improve audit logs and restrict CAP updates via AADGraph.

Azure AD CAPs

Azure AD CAPs allow organizations to grant or block access to services protected by Azure AD. They can also be used for session monitoring and limiting a session lifetime. CAPs are enforced during the Azure AD authentication process. Azure AD uses the following common signals to make a policy decision:

• User or group membership
• IP location information
• Device
• Application

Only users with specific roles can access CAPs in the Azure AD portal (see Table 1).

Table 1. Azure AD roles required to access CAPs.

Figure 1 shows an example CAP that requires all users to perform multi-factor authentication (MFA). The policy is not enabled in this example; it is set to Report-only mode. This mode allows organizations to assess the impact of the CAP before enforcing it.

Figure 1. Sample CAP. (Source: Secureworks)

The Azure AD portal displays the name, state, and creation and modification timestamps (see Figure 2).

Figure 2. List of CAPs. (Source: Secureworks)

The Azure AD portal reflects changes whenever the CAP is modified (see Figure 3).

Figure 3. Modified CAP. (Source: Secureworks)

Azure AD audit logs captures CAP creation and modification events (see Figure 4).

Figure 4. Azure AD audit logs listing CAP creation events (highlighted in red (bottom)) and CAP modification events (highlighted in green (top)). (Source: Secureworks)

Both the ‘Add conditional access policy’ and ‘Update conditional access policy’ events include details of the modified properties (see Figure 5). This feature provides a full audit trail and includes modified settings.

Figure 5. Audit log details for the ‘Update conditional access policy’ event. (Source: Secureworks)

Modifying Conditional Access with API calls

The Azure AD portal is a graphical user interface (GUI) that allows administrators to create and maintain CAPs via a browser. GUIs can perform ad-hoc tasks but not automation and programmatic access. To address those needs, Microsoft provides three APIs that can interact with CAPs:

• Azure AD IAM
• MS Graph
• Azure AD Graph (AADGraph)

Azure AD IAM API

The Azure AD portal uses an undocumented Azure AD IAM API to create, view, and edit CAPs. The API is available at https ://main . iam . ad . ext . azure . com/api/Policies/Policies. Because the Azure AD portal uses Azure AD IAM APIs, access requires the permissions listed in Table 1. The API returns a list of CAPs as a JSON object (see Figure 6).

Figure 6. Azure AD IAM API response. (Source: Secureworks)

When the API opens a CAP for editing, it returns the CAP details as a JSON object (see Figure 7). This returned JSON object has many fields, which correspond to the CAP settings available in the Azure AD portal. The response also includes creation and modification timestamps.

Figure 7. Response returned by the Azure AD IAM API call. (Source: Secureworks)

Modifying a CAP sends a JSON object to https: //main . iam . ad . ext . azure . com/api/Policies/ConvertPolicyMsGraph as an HTTP POST request. Figure 8 shows a JSON object where the CAP state was changed from Off to Report-only. Only the modified data and not the metadata is sent to Azure AD.

Figure 8. Azure AD IAM API CAP modification request. (Source: Secureworks)

MS Graph API

MS Graph API support for conditional access is well-documented, Microsoft also published examples for creating and editing CAPs. Table 2 lists the required permissions to access CAPs via MS Graph API.

Table 2. MS Graph API permissions required for CAPs.

Users or applications with these permissions can list CAPs by calling the API at https: //graph . Microsoft . com/v1.0/identity/conditionalAccess/policies. The API returns all CAPs and details as a JSON object (see Figure 9).

Figure 9. MS Graph API response. (Source: Secureworks)

Creating or modifying a CAP uses the same API endpoint:

Only the modified data is sent to Azure AD. The metadata is not included.

Azure AD Graph API (AADGraph)

Microsoft has attempted to deprecate the AADGraph API for years. As of this publication, its retirement is scheduled to occur sometime after June 30, 2023. Microsoft has removed public AADGraph API documentation to discourage its use.

CAPs can be accessed using the AADGraph API at https: //graph . windows . net/<tenant>/policies?api-version=<api version>, where <tenant> is the Azure AD tenant and <api version> is the desired AADGraph API version. Using 1.6 as the API version returns some Azure AD policies that the user can access if they have appropriate permissions, but CAPs are not listed. However, using 1.61-internal as the version returns all Azure AD policies, including CAPs, regardless of the user’s permissions. As a result, any user of the tenant can list CAPs and bypass the role requirements.

The API returns all policies as JSON objects. Figure 11 shows a CAP policy (indicated by the policyType of 18).

Figure 11. AADGraph API response. (Source: Secureworks)

The CAP settings and metadata are stored in the policyDetail attribute as a JSON object (see Figure 12). Administrators with permissions to modify CAPs can edit this attribute, enabling them to tamper with the CAP conditions and metadata.

Figure 12. CAP settings in policyDetail attribute. (Source: Secureworks)

Updating an existing CAP with the AADGraph API involves an HTTP PATCH request to https: //graph . windows . net/<tenant>/policies/<objectid>?api-version=1.61-internal, where <objectid> is the object ID of the CAP to be modified. The content of the request is a JSON object that only includes the policyDetail attribute (see Figure 13).

Figure 13. Updating CAP using the AADGraph API. (Source: Secureworks)

Tampering with Conditional Access policies

CTU researchers used the AADInternals toolkit to tamper with CAPs. Administrators or threat actors can leverage the AADGraph API to make changes that are not properly logged.

1. We retrieved the current policyDetail value of the example CAP:
   1. Acquired an access token for an administrator with permissions to modify CAPs
   2. Saved the example CAP to a variable
   3. Extracted the policyDetail value and copy the data to the clipboard (see Figure 14)

      
      Figure 14. Getting current CAP policyDetail using AADInternals. (Source: Secureworks)

2. We pasted the policyDetail value into a text editor and reformatted the JSON for readability (see Figure 15). We then emptied the ModifiedDateTime attribute (see line 4) and changed the State attribute from Reporting to Disabled. The modified JSON was flattened and copied to the clipboard.

   
   Figure 15. Modified CAP policyDetail. (Source: Secureworks)

3. We used the modified policyDetail from the clipboard to update the CAP (see Figure 16).

   
   Figure 16. Updating the CAP policyDetail attribute via AADInternals. (Source: Secureworks)

   The Azure AD portal updated the modifications within a minute (see Figure 17).

   
   Figure 17. Modified CAP in Azure AD portal. (Source: Secureworks)

When CAPs are updated via the AADGraph API, the ‘Update conditional access policy’ event is not generated in the audit logs (see Figure 18). As a result, there is an incomplete audit trail on what modifications were made.

Figure 18. CAP modification via AADGraph does not create the Update conditional access event. (Source: Secureworks)

Threat actors with administrator permissions can leverage this omission to obscure CAPs. For instance, the PowerShell script in Figure 19 removes the timestamps and display names of all CAPs.

Figure 19. PowerShell scipt to remove CAP display name and timestamps. (Source: Secureworks)

After running the script, CAPs are fully functional. However, the Azure AD portal cannot open or edit them (see Figure 20).

Figure 20. Azure AD portal after removing CAP display names and timestamps. (Source: Secureworks)

Administrators can still delete CAPs and make duplicates to view existing CAP settings. If organizations keep audit logs for a longer period of time, they may be able to restore CAP names and timestamps based on historical audit log data.

Communication with Microsoft

CTU researchers reported the metadata editing and logging issues to the Microsoft Security Response Center (MSRC) on May 20, 2022. These issues were reported as tampering and elevation of privilege, as administrators are also able to modify the metadata. The MSRC responded on June 26:

We confirm the following behaviors when a Conditional Access Policy is modified via Azure AD Graph APIs (or PowerShell modules based on AAD Graph APIs):

Only Core Directory service Audit Log item is present in the Audit Logs, while the corresponding Conditional Access service Audit Log item is missing.

Details of the changed properties and values are not present in the Core Directory service Audit Log item.

Modified Date information of the edited policy object is not updated on the Conditional Access Azure Portal page.

We analyzed the scenario, and established that:

There is no escalation of privileges: only users with the required permissions are allowed to access or modify policy objects.

Investigations of malicious Conditional Access Policies are not affected due to relevant information present in the sign-in logs.

Date, Activity, Target, and Actor information of policy changes are present in the Activity Logs, allowing admins to audit who changed a policy and when.

On August 23, 2022, CTU researchers notified the MSRC that all users can read conditional access. This issue was reported as elevation of privilege, as any user can read CAPs without administrator permissions. The MSRC responded on February 2, 2023:

There are several known experiences where an authenticated and authorized user is able to read specific data pertaining to an Azure AD configuration such as an authentication policy or other similar configurations.

These cases are by design: the user is authorized, the data is read-only and doesn’t contain any specific user information.

While reading data such as an authentication policy is not perceived as a security breach, we do have optimizations in Azure AD to allow other data or configurations to only be read or changed based on admin roles with specific edit / create/ delete rights for security purposes.

On May 11, 2023, the MSRC informed the CTU research team of planned changes to address these issues:

1. Improve audit logs to reflect the type of policy being updated when CA policies are updated through AAD Graph.
2. We will prevent admins from using AAD Graph to make updates to CA policies.

In addition to these improvements, AAD Graph is set to be retired.

Conclusion

Administrators can use the AADGraph API to change CAPs. The API does not properly log changes, and the lack of an audit trail breaks integrity and non-repudiation of CAPs. As a result, organizations cannot trust CAP information shown in the Azure AD portal or in directory audit logs. In addition, any tenant user can view CAPs without administrator permissions. This ability allows low-privileged threat actors to identify gaps in CAPs or target them for future modification. Third-party tools such as ROADTools and TSxAzureADExport exploit this ability.

CTU researchers recommend that organizations store Azure AD audit logs in the Log Analytics workspace or in other storage solutions such as Secureworks Taegis XDR. Organizations can detect CAP modifications via the AADGraph API by monitoring audit logs for an ‘Update policy’ event that does not have a corresponding ‘Update conditional access policy’ event within two seconds.

Appendix

The following script can restore the names and modification dates of CAPs that have been created or modified using the Azure AD portal or the MS Graph API:

# Read legit CAP events from the audit log
$CAPEvents=Get-AADIntAzureAuditLog -Export                    `
            | Where-Object activityDisplayName -in            `
                "Add conditional access policy",              `
                "Update conditional access policy"            `
            | Select-Object "activityDateTime" -ExpandProperty "targetResources" `
            | Select-Object "id","displayName","activityDateTime"
 
# Loop through the events to get the first (latest) update
$CAPInfos=@{}
foreach($CAPEvent in $CAPEvents)
{
    if(!$CAPInfos.ContainsKey($CAPEvent.id))
    {
        $CAPInfos[$CAPEvent.id] = [pscustomobject]@{
                "displayName"      = $CAPEvent.displayName
                "modifiedDateTime" = $CAPEvent.activityDateTime
            }
    }
}
 
# Read current CAPs
$CAPs = Get-AADIntConditionalAccessPolicies
 
# Loop through CAPs
foreach($CAP in $CAPs)
{
    # Create the return value
    $retVal = [pscustomobject][ordered]@{
        "id"      = $CAP.objectId
        "isEmpty" = [string]::IsNullOrWhiteSpace($CAP.displayName)
        "success" = $null
        "name"    = $CAP.displayName
    }
 
    # Check whether the displayName is empty
    if($retVal.isEmpty)
    {
        # Check whether we found the old information
        if($CAPInfo = $CAPInfos[$retVal.id])
        {
            # Get policyDetails and fix Modified Date
            $policyDetail = $CAP.policyDetail[0] | ConvertFrom-Json 
            try
            {
                $policyDetail.ModifiedDateTime = $CAPInfo.modifiedDateTime
            }
            catch{}
 
            $newPolicyDetail = $policyDetail | ConvertTo-Json -Depth 10 -Compress
 
            # Replace name with the old displayName
            $retVal.name = $CAPInfo.displayName
            try
            {
                Set-AADIntAzureADPolicyDetails  -ObjectId     $retVal.id       `
                                                -PolicyDetail $newPolicyDetail `
                                                -DisplayName  $retVal.name     `
                                                | Out-Null
 
                $retVal.success = $true
            }
            catch
            {
                # Failed
                $retVal.success = $false
                $retVal.name = $CAP.displayName
            }
        }
    }
    # Return
    $retVal
} 

The following KQL query can be used to identify ‘Update policy’ events that do not have a corresponding ‘Update conditional access policy’ event within two seconds:

AuditLogs 
| where OperationName == "Update policy"
| mv-expand TargetResources
| where TargetResources.displayName != "Default Policy"
| mv-expand InitiatedBy
| project PolicyName = TargetResources.displayName, PolicyId = tostring(TargetResources.id), UserPrincipalName = InitiatedBy.user.userPrincipalName, UserId = tostring(InitiatedBy.user.id), OperationName, Time = bin(TimeGenerated, 2s), TimeGenerated, CorrelationId
|join kind=leftanti (AuditLogs
        | where OperationName == "Update conditional access policy"
        | mv-expand TargetResources
        | mv-expand InitiatedBy
        | project PolicyId = tostring(TargetResources.id), UserId = tostring(InitiatedBy.user.id), Time = bin(TimeGenerated, 2s)) on PolicyId,UserId,Time
| order by TimeGenerated

The post Tampering with Conditional Access Policies Using Azure AD Graph API appeared first on Online Pitstop.

Secureworks® Counter Threat Unit (CTU) researchers have observed infostealers (also known as stealers) playing an increasingly important role in the cybercrime ecosystem. This type of malware can steal sensitive information such as login credentials, financial details, and personal data from compromised computers and networks. Infostealers can be installed on a computer or device via phishing attacks, infected websites, and malicious software downloads. Once installed, they can execute and exit very quickly; many infostealers finish collecting and transmitting stolen data within several seconds to a minute of total runtime. The data is then packaged and sold as logs. Threat actors could use stolen credentials in these logs to gain unauthorized access to enterprise networks via remote access services such as virtual private networks (VPNs) and Microsoft Office Web Access (OWA). This unauthorized access can result in the exfiltration of sensitive data or the deployment of ransomware, which can cause significant financial loss and reputational damage. Although the name ‘infostealer’ implies data theft, this malware has evolved over time to include deployment of additional tools and malware.

Underground forums and marketplaces

Infostealers are often sold as a monthly subscription service. The price can range from $50 to over $1,000 USD per month for access to a stealer command and control (C2) server operated by the developer. The service often features a range of support functions, including multiple ways to view, download, and share stolen data. Self-hosted stealer C2 servers are also available and are usually sold for a flat fee.

Underground forums provide a shared space for threat actors to discuss ongoing projects, request new features, and provide malware reviews. They also offer a marketplace to advertise new and existing stealers. Underground forums such as XSS . is and exploit . in are popular with threat actors involved in the development and deployment of infostealers.

These forums consist of subforums and sections that host a range of topics. They also contain administrative areas to control announcements, sales, and memberships. Many underground forums have a dedicated marketplace and enforce stringent rules to sell illegal products such as infostealers. Larger, high-profile forums offer an escrow service to mediate transactions between vendors and customers, building trust in the marketplace and providing a degree of control over interactions.

Stealer logs are available from underground forums, marketplaces, and other online platforms that cater to threat actors interested in obtaining credentials, financial information, personal data, banking details, cryptocurrency wallets, and other sensitive, secret, or valuable information. These marketplaces are often only accessible through Tor or the Invisible Internet Project (I2P) anonymity services and usually have strict rules and regulations regarding the types of information that can be traded. The offerings are typically only accessible to members who have been approved by the marketplace’s administrators or who pay an entry fee. Some marketplaces only sell infostealer logs and have built their infrastructure to facilitate these transactions. Other forums offer many illicit wares for sale and have sections that include logs obtained from infostealers.

A burgeoning market also exists for after-action tools. Infostealers can lower the bar for entry to cybercrime, but the uninitiated can find the logs to be challenging to parse. Multiple vendors sell tools to assist in log parsing, enabling cybercriminals to extract data of interest from the raw logs.

Russian Market

Russian Market is by far the biggest underground marketplace for infostealer logs, and it has ties to the now-defunct Amigos Marketplace. As of this publication, Russian Market offers over five million logs for sale, which is roughly ten times more than its nearest rival. Historically, the marketplace predominantly sold logs obtained through five infostealers: RedLine, Raccoon, Vidar, Taurus, and AZORult. As of late February 2023, it stopped carrying Taurus and AZORult logs. Since December 2022, researchers observed RisePRO infostealer logs for sale through the marketplace, although total offerings remain low. Table 1 lists the number of infostealer logs for sale on Russian Market as of the end of February 2023.

Table 1. Number of infostealer logs available for purchase on Russian Market as of the end of February 2023.

In October 2022, Russian Market changed its operating model to allow users to preorder credentials (see Figure 1). This feature requires that buyers deposit $1,000 USD into the site’s escrow system. Buyers can then request credentials based on a domain name (from a specific organization) or a ‘mask’ (from a specific application). Although there are no guarantees that preorders will be fulfilled, this feature could lead to specific targeting of organizations and sectors rather than relying just on opportunistic attacks.

Figure 1. Russian Market interface for preorder logs. (Source: Secureworks)

Genesis Market

Genesis Market is an invitation-only marketplace that specializes in the sale of bots rather than logs. Bots are computers that were infected with infostealer malware to steal information and the browser fingerprint from a victim’s web browser. The browser fingerprint can be used to impersonate the victim and access the victim’s bank accounts, take over accounts, and make fraudulent purchases. A threat actor who purchases a bot has exclusive access to the data, including updates of the victim’s data from the infected device.

Genesis Market provides a custom browser plugin to customers and distinguishes itself among the competition by including more automation for site users. These features effectively render the bots as logs, removing the need to manually parse details and lowering the technical bar to entry. As of February 2023, Genesis Market listed over 450,000 bots from nearly every country (see Figure 2).

Figure 2. Number of available bots for sale on Genesis Market as of February 2023. (Source: Secureworks)

On April 4, 2023, Genesis Market was the target of a coordinated international law enforcement action led by the U.S. Federal Bureau of Investigation (FBI). Despite the arrests of multiple users and the takedown of 11 domains, Operation Cookie Monster did not completely shutter the marketplace. As of this publication, the Tor version of Genesis Market remains operational. Logs have been added for sale since the takedown, albeit at a slower rate than usual.

2easy

The 2easy marketplace has rapidly grown since it was established in 2018. Like Genesis Market, 2easy is automated, allowing buyers to add money to wallets and purchase logs without directly interacting with the seller. Unlike other sites, 2easy does not provide samples or previews. However, logs are reportedly less expensive than those on Genesis Market and Russian Market.

Threat actors who purchase logs through the 2easy marketplace receive an archive file from the selected bot. The file’s content depends on the stealer and its unique capabilities. RedLine has historically been the favorite infostealer for threat actors selling logs through 2easy, but the marketplace also sells Raccoon, Vidar, and AZORult logs. As of February 2023, 2easy offered over 750,000 logs for sale (see Figure 3).

Figure 3. Logs for sale on the 2easy marketplace. (Source: Secureworks)

Telegram

As demonstrated by the April 2023 Genesis Market takedown, one of the risks to sellers using traditional forums and marketplaces is the threat of law enforcement action. Another example was RaidForums, which was established in 2015 and became one of the most popular criminal marketplaces offering credentials and infostealers. In 2022, a coordinated international law enforcement investigation dubbed Operation TOURNIQUET resulted in the seizure of three domains and the arrest of RaidForums’s founder and chief administrator. In addition, several cybercrime forums were breached in 2021 and their user data was stolen and either leaked or sold online. These takedowns and breaches undermine the security and integrity of the platforms and can degrade sellers’ confidence in the anonymity offered by the forums. As a result, many cybercriminals use the Telegram messaging platform to advertise their services.

Telegram is a multi-platform messaging service that has an estimated 700 million monthly users. Benefits of this platform for cybercriminals include its focus on privacy, encryption, and an open-source application programming interface (API) that allows ‘unofficial clients’ (alternative messaging apps that use Telegram’s API) to communicate with the official app and web interface. The end-to-end encryption and support for private and anonymous channels are ideal for selling and trading stolen data and information. Telegram users can subscribe to channels on which owners can post content, or they can become members of groups and participate in discussions. Cybercriminals use these channels and groups to sell infostealers such as Titan Stealer. Some channels are hidden and require specific invitations or permissions to access. There has reportedly been a significant increase in the use of Telegram to sell illicit goods and services. Over 120,000 messages were published across more than 300 Telegram public channels and groups between the beginning of 2019 and the second quarter of 2022. RedLine, Anubis, SpiderMan, Oski Stealer, and Loki Stealer are prominently represented on Telegram. RaccoonV2 operators extensively use Telegram for announcements, business discussions, and reporting stolen data.

Despite the simplicity of selling goods over Telegram, it remains more popular for selling illicit goods such as drugs rather than for selling malware due to its primary function as a messaging platform. This limitation makes it difficult for sellers to migrate from traditional underground forums and marketplaces that feature advanced search capabilities and a way for sellers to build reputation, which is important when establishing trust with buyers. CTU researchers have observed scammers on Telegram mimicking real threat actors by creating fake profiles based on listings from forums such as Breached. This lack of reputation status and the prevalence of scammers is likely to undermine trust, preventing threat actors from fully adopting Telegram.

Infostealer variants

Infostealers rose to prominence in 2006 with the ZeuS trojan, which targeted online banking credentials. After the ZeuS source code was leaked in March 2011, the creation of multiple variants boosted the popularity of this type of malware and inspired the development of infostealers with increasingly sophisticated capabilities. Some infostealers can be tailored or customized for specific targets and goals. For example, LokiBot has been prominent since 2016 and was one of the first infostealers that targeted the Android operating system. The Ducktail infostealer was first observed in 2022 and specifically targeted Facebook business accounts. Infostealers such as BHUNT specialize in stealing cryptocurrency, while state-sponsored threat groups such as IRON TILDEN use custom versions to conduct espionage.

CTU researchers analyzed the Russian Market marketplace to understand each infostealer’s properties and capabilities. The table in the Appendix compares features of the most common infostealers in 2022 but may not be a comprehensive view. Much of the information related to targeted browser extensions and applications is only found through the infostealer configurations. These configurations specify what information to extract from a compromised system, but they frequently change.

RedLine

RedLine emerged in March 2020, and its logs are the best seller on Russian Market. RedLine is sold standalone or as a subscription. As of March 2023, standalone copies (the ‘PRO’ version) were advertised on Telegram for $900 USD, with subscriptions available for $150 per month or $400 for three months (see Figure 4). This malware steals information from web browsers, including saved credentials, autocomplete data, credit card information, and cryptocurrency wallets. While running on an infected system, RedLine takes a system inventory of the username, location data, hardware configuration, and installed security software.

Figure 4. RedLine Telegram channel listing prices and deals. (Source: Secureworks)

RedLine is distributed via cracked games, applications, and services, as well as via phishing campaigns and malicious ads. CTU researchers have observed multiple instances of threat actors using malicious Microsoft OneNote files to deliver RedLine. RedLine has also been observed using YouTube for self-propagation and has been linked by CTU researchers to SM Viewbot malware. SM Viewbot promotes YouTube videos to lure users who are searching for cracked software. Victims who download installers advertised in the video descriptions may infect their systems with infostealers.

RedLine’s execution process is straightforward. Once executed, the malware decodes XOR-encoded data such as the C2 server IP address and a unique ID. After the decoding process, RedLine requests configuration data from the C2 server, which instructs RedLine on what information to collect from the compromised system. Information related to the configuration data is then collected from the compromised system, converted into XML format, and transmitted to the C2 server via a Simple Object Access Protocol (SOAP) message.

Raccoon

The original Raccoon Stealer emerged in 2019. It operated as a malware-as-a-service (MaaS) model and was advertised on underground forums. The cost was $75 USD per week or $200 per month. It did not include a distribution mechanism, so customers had to devise a method to install the infostealer on compromised systems. The Raccoon Stealer panel was hosted on a Tor site.

Following Russia’s invasion of Ukraine in early 2022, the threat actors responsible for Raccoon Stealer announced that they were shutting down their operations, implying that a group member had died. However, the threat actors released a new version of the malware named RaccoonV2 in May 2022 (see Figure 5). While Raccoon Stealer and RaccoonV2 share similar functionality, CTU analysis confirms that RaccoonV2 represents a significant rewrite of the malware.

Figure 5. Raccoon Stealer Telegram channel giving details of the new build. (Source: Secureworks)

RaccoonV2 remains under active development as of this publication. The developers encoded more of the code strings in later versions and changed the encoding method, moving from Base64 to XOR. They continually alter elements of the malware to improve defense evasion, including changes to the User-Agents and mutexes, presumably to circumvent indicator-based detections. To hinder static and dynamic analysis, updates included intermixing chunks of code with thousands of bytes of opcodes from superfluous Windows API function calls.

The RaccoonV2 infostealer obtains its configuration file from a hard-coded C2 server. This file specifies what data the malware should steal (e.g., password files, credit card information, web browser data, email messages, cryptocurrency wallets, browser cookies). This data is stored as individual files in the %APPDATA%LocalLow directory before it is sent to the malware C2 server via an HTTP POST request.

RaccoonV2 has occasionally been deployed alongside other infostealers such as RedLine. It has been observed downloading and executing malware such as SmokeLoader, cryptocurrency wallet hijackers, Amadey, Remcos, AZORult, Allcome Clipper, SystemBC, and cryptocurrency miners.

Vidar

Vidar primarily operates as an infostealer but has also been used to deploy ransomware. The malware was first observed in 2019 during a prolific malvertising campaign where threat actors used the Fallout exploit kit to distribute Vidar and GandCrab as secondary payloads. Vidar is sold on underground forums and Telegram channels (see Figure 6) as a standalone product, usually for between $130 USD per week to $750 for three months. Vidar provides an admin panel that lets customers configure the malware and monitor infections (see Figure 7).

Figure 6. Vidar Telegram channel. (Source: Secureworks)

Figure 7. Vidar infostealer admin panel. (Source: Secureworks)

Vidar is a Windows-based stealer that is written in C++ and based on the Arkei stealer. It steals system data such as machine ID, operating system, computer name, display resolution, keyboard language, hardware information, network information, and a list of installed software. Vidar can extract browser artifacts, the contents of some cryptocurrency wallets, PayPal data, session data, and screenshots.

In addition to stealing sensitive data, Vidar can deliver secondary payloads such as the SystemBC proxy malware. Because Vidar is available to any paying threat actor, the delivery method varies and may include phishing emails or pirated software.

In early 2022, CTU researchers observed Vidar creating profiles on the Mastodon social networking platform to obtain and post C2 IP addresses. The Mastodon sites used by Vidar have thousands of members, and it is unlikely that the threat actors manage or control the infrastructure. Vidar verifies that the compromised system is not located in the Commonwealth of Independent States (CIS) by checking the computer language and keyboard settings. It then contacts the C2 server, which responds with the malware configuration. Vidar exfiltrates host and system information from infected devices and sends the data to the C2 server via HTTP form data POST requests.

Taurus

The ‘Taurus Project,’ as the infostealer was named by its developers, was first observed in the second quarter of 2020. It is the fourth-most prolific stealer on Russian Market, even though it has been inactive since late 2021. Taurus was primarily advertised on Russian-language forums and will not execute within CIS countries. There are indications that the group responsible for this malware was also responsible for the ‘Predator the Thief’ infostealer, either directly or through the sale of the original software to a third party. Taurus can steal VPN credentials, social media details, cryptocurrency credentials; take screenshots of the victim’s desktop; and exfiltrate the system’s software installation and configuration information. This data can be used to further exploit the compromised system. Taurus includes a dashboard that lets threat actors monitor infections by geographic region and customize the malware configuration to specify targeted information.

Taurus was predominantly distributed via spam emails containing a malicious attachment. Opening the attached document prompts the victim to enable macros, which then executes a PowerShell script that initiates the download of additional payloads. Stolen data is exfiltrated as a ZIP file to a C2 server whose URL is built at runtime. Figure 8 shows the infection process.

Figure 8. Infection process for the Taurus infostealer. (Source: Secureworks)

Rhadamanthys

The Rhadamanthys infostealer was first observed in the third quarter of 2022. It quickly established its reputation on underground forums due to the active development and deployment of user-friendly features that align with market demands. Rhadamanthys targets a wide range of applications, wallets, and user data on an infected device. The developers appear receptive to suggestions for regular updates and enhancements (see Figure 9). Rhadamanthys operates using a MaaS model and has been observed using phishing emails and Google Ads as the initial infection vector.

Figure 9. Forum post announcing Rhadamanthys updates. (Source: Secureworks)

CTU researchers observed a threat actor named “kingcrete2022” advertising Rhadamanthys in September 2022 for $250 USD for 30 days or $550 for 90 days, payable in Monero or Bitcoin. In November 2022, a threat actor named ‘Kingcrete’ uploaded two videos to Vimeo. One video was an overview of the ‘v0.3.2 updates.’ The second video was named ‘Wallter Crack and Customized Dictionaries’ and showed how the infostealer targets cryptocurrency wallets. Both videos show details of the Rhadamanthys admin panel and a walkthrough of how it is used.

Rhadamanthys is written in C++. It evades detection by operating in system memory and by creating a mutex to ensure that only one instance is running. It uses the Al-Khaser anti-analysis tool to detect and avoid running in researcher sandboxes and virtual machines (VMs). Rhadamanthys is custom-packed with several stages that include dropping a custom loader DLL that decodes and executes an encoded payload via a command-line argument. The custom loader executes shellcode in a novel way by abusing the callback mechanism of the Windows CryptEnumIdOidInfo() function and masquerades as a Nullsoft Scriptable Install System (NSIS) installer running the PrintUIEntry export (see Figure 10).

Figure 10. Example of Rhadamanthys masquerading as an NSIS installer. (Source: Secureworks)

Rhadamanthys decodes the C2 URL used for initial communication using a generated 128-byte XOR key. The configuration file it receives from the C2 server is disguised as a JFIF image via steganography. The infostealer uses the WebSocket protocol to encrypt post-infection traffic, which includes stolen and exfiltrated data. Rhadamanthys can also be configured to run arbitrary executables.

State-sponsored stealers

Infostealers are not exclusively used by cybercriminals. Because infostealers can discreetly and efficiently exfiltrate sensitive data from targeted systems, they are commonly and effectively used by state-sponsored threat groups that focus on cyberespionage operations. During the conflict in Ukraine, Russian threat actors deployed the Graphiron infostealer to target Ukrainian organizations. This infostealer is similar to the GraphSteel malware previously used against Ukraine but includes enhanced capabilities. Graphiron is Go-based malware that can steal system and application data, screenshots, account credentials, and private keys. It consists of a downloader and a secondary information-stealing payload. The downloader checks for various security software and malware analysis tools before downloading the payload. Graphiron uses AES encryption with hard-coded keys to communicate with the C2 server through port 443.

Chinese state-sponsored threat groups have also been observed using infostealers in pursuit of their objectives. Reports of a 2022 espionage campaign targeting various government and public entities in Asia identified a custom Infostealer.Logdatter infostealer that logged keystrokes, captured screenshots, stole clipboard data, downloaded files, injected code, and both connected to and queried SQL databases. This campaign has been attributed to the BRONZE ATLAS threat group.

The infostealer ecosystem

Much like the general cybercriminal ecosystem, the successful development and deployment of infostealers relies on individuals with a broad range of skills, roles, and responsibilities. These individuals include developers, initial access brokers (IABs), and customers (see Figure 11). The rise of MaaS operations has lowered the technical barrier to entry into cybercrime. It has also fostered innovation among developers as they improve their products and appeal to a broad audience of potential customers on underground forums and marketplaces.

Figure 11. An overview of roles and relationships in the infostealer ecosystem. (Source: Secureworks)

Developers

Malware developers are responsible for writing and maintaining the code that will be packaged and sold on underground forums, typically to IABs. With MaaS being the most common business model in the infostealer marketplace, developers can dedicate more time and effort to ensuring their malware contains a range of features, taking feedback from users, and iterating the malware to constantly evolve and improve. Forums allow customers to leave feedback, enhancing the seller’s reputation and potentially increasing the popularity of the malware.

Initial access brokers

IABs are individuals or groups that rent access to tools from MaaS operators on underground forums and marketplaces. They then deploy these infostealers via phishing or malicious ad campaigns to infect systems. These infostealers steal data from the compromised system and exfiltrate it to a C2 server. This stolen data, typically including credentials for services such as Remote Desktop Protocol (RDP), VPNs, email accounts, and cryptocurrency wallets, is then sold to threat actors who use it for malicious purposes.

Customers

Due to diverse types of data that infostealers can obtain from a compromised system, threat actors often purchase the data for a wide range of purposes. Financially motivated cybercriminals may purchase credentials for cryptocurrency wallets, online banking, or other financial services and abuse them to make fraudulent withdrawals or transactions. Ransomware groups commonly seek infostealer logs, as credentials for RDP, VPNs, and corporate accounts can provide initial access into enterprises prior to data exfiltration and encryption. The value of infostealers to ransomware groups has increased with the success of the ransomware-as-a-service (RaaS) model and the growth of ‘hack-and-leak’ sites. For example, the LockBit ransomware operators reportedly offered to purchase the Raccoon Stealer source code.

Specialist log parsers

Log marketplaces such as Genesis Market have built-in parsing as a browser extension, which allows customers to seamlessly access device fingerprints and victim data. Other marketplaces like Russian Market and 2easy sell raw logs that require parsing to interpret and use the content. Parsing infostealer logs purchased from a underground marketplace can be a complex task, as the logs are often in various formats and contain a large amount of data. This challenge has created a secondary market for individuals selling parser tools to customers who have either deployed the infostealers and want to sell structured data or to buyers in possession of bulk raw logs (see Figures 12 and 13).

Figure 12. Threat actor offering to parse stealer logs to find specific links. (Source: Secureworks)

Figure 13. Threat actor selling a parser for large batches of stealer logs. (Source: Secureworks)

Conclusion

In 2022, stolen credentials featured heavily in Secureworks incident response engagements. Infostealer malware poses a significant threat to individuals and organizations. Its ability to steal sensitive information such as passwords and financial information has far-reaching consequences for victims. This type of malware is becoming increasingly sophisticated, making it more difficult for victims to detect and remove. Additionally, the evolution of criminal marketplaces allows relatively low-skilled threat actors to access tools with advanced capabilities to attack many victims.

The migration to remote work driven by the COVID-19 pandemic and sustained post-pandemic exposes users and organizations to even greater risk from infostealers. Bring your own device (BYOD) policies that let users access corporate assets from infected personal devices can lead to compromises of corporate systems.

To mitigate this threat, individuals and organizations must take proactive steps to secure their systems. These steps include keeping software up to date, using strong and unique passwords that must not be stored in web browsers, and being wary of suspicious emails or downloads. It is also crucial to invest in security solutions that can detect and block infostealer malware. By taking these actions, individuals and organizations can reduce their risk of compromise.

References

Abrams, Lawrence. “Raccoon Stealer malware suspends operations due to war in Ukraine.” Bleeping Computer. March 25, 2022. https://www.bleepingcomputer.com/news/security/raccoon-stealer-malware-suspends-operations-due-to-war-in-ukraine/

Arghire, Ionut. “Someone Is Hacking Cybercrime Forums and Leaking User Data.” SecurityWeek. March 5, 2021. https://www.securityweek.com/someone-hacking-cybercrime-forums-and-leaking-user-data/

Armer, Jon, et al. “New Malware Variant: Project Taurus Infostealer Follows in Predator the Thief’s Footprints.” Infoblox. 2019. https://www.infoblox.com/wp-content/uploads/threat-intelligence-report-project-taurus-infostealer-follows-in-predator-the-thiefs-footprints.pdf

Ceci, L. “Telegram messenger global MAU 2014-2022.” Statista. November 7, 2022. https://www.statista.com/statistics/234038/telegram-messenger-mau-users/

Cyble Research & Intelligence Labs. “Rhadamanthys: New Stealer Spreading Through Google Ads.” January 12, 2023. https://blog.cyble.com/2023/01/12/rhadamanthys-new-stealer-spreading-through-google-ads/

Dewan, Tarun and Chaturvedi, Stuti. “New PHP Variant of Ducktail Infostealer Targeting Facebook Business Accounts.” Zscaler. October 13, 2022. https://www.zscaler.com/blogs/security-research/new-php-variant-ducktail-infostealer-targeting-facebook-business-accounts

eSentire. “eSentire Threat Intelligence Malware Analysis: Raccoon Stealer v2.0.” August 31, 2022. https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-raccoon-stealer-v2-0

Europol. “One of the world’s biggest hacker forums taken down.” April 12, 2022. https://www.europol.europa.eu/media-press/newsroom/news/one-of-world%E2%80%99s-biggest-hacker-forums-taken-down

Flashpoint. “RisePro” Stealer and Pay-Per-Install Malware “PrivateLoader.” December 19, 2022. https://flashpoint.io/blog/risepro-stealer-and-pay-per-install-malware-privateloader/

Joe Sandbox Cloud. “Windows Analysis Report IuXJUPoEo6.exe.” Accessed March 30, 2022. https://www.joesandbox.com/analysis/464621/0/html

Kathiresan, Karthikkumar. “The Titan Stealer: Notorious Telegram Malware Campaign – Uptycs.” Uptycs. January 23, 2023. https://www.uptycs.com/blog/titan-stealer-telegram-malware-campaign

Kingcrete. Rhadamanthys walkthrough videos. Vimeo. Accessed March 30, 2023. https://vimeo.com/user185512701

Kupreev, Oleg. “Self-spreading stealer attacks gamers via YouTube.” Kaspersky. September 15, 2022. https://securelist.com/self-spreading-stealer-attacks-gamers-via-youtube/107407/

Leyden, John. “ZeuS cybercrime cookbook on sale in underground forums.” The Register. March 23, 2011. https://www.theregister.com/2011/03/23/zeus_source_code_sale/

Malware-Traffic-Analysis.net. “RHADAMANTHYS STEALER.” January 3, 2023. https://www.malware-traffic-analysis.net/2023/01/03/index.html

Mandiant Threat Intelligence. “Evacuation and Humanitarian Documents used to Spear Phish Ukrainian Entities.” November 25, 2022. https://www.mandiant.com/resources/blog/spear-phish-ukrainian-entities

Muncaster, Phil. “New Info-Stealer Discovered as Russia Prepares Fresh Offensive.” Infosecurity Magazine. February 9, 2023. https://www.infosecurity-magazine.com/news/new-infostealer-discovered-russia/

Positive Technologies. “Positive Technologies: cybercrime market in Telegram is growing.” November 18, 2022. https://www.ptsecurity.com/ww-en/about/news/positive-technologies-cybercrime-market-in-telegram-is-growing/

Secureworks. “BRONZE ATLAS.” Accessed March 30, 2023. https://www.secureworks.com/research/threat-profiles/bronze-atlas

Secureworks. “IRON TILDEN.” Accessed March 30, 2023. https://www.secureworks.com/research/threat-profiles/iron-tilden

Secureworks. “Learning from Incident Response: 2022 Year in Review.” March 16, 2023. https://www.secureworks.com/resources/rp-irs-learning-from-incident-response-team-2022-year-in-review

Secureworks. “ZeuS Banking Trojan Report.” March 10, 2010. https://www.secureworks.com/research/zeus

Segura, Jerome. “Vidar and GandCrab: stealer and ransomware combo observed in the wild.” Malwarebtes. January 4, 2019. https://www.malwarebytes.com/blog/news/2019/01/vidar-gandcrab-stealer-and-ransomware-combo-observed-in-the-wild

Threat Hunter Team. “New Wave of Espionage Activity Targets Asian Governments.” Symantec. September 13, 2022. https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/espionage-asia-governments

Toulas, Bill. “2easy now a significant dark web marketplace for stolen data.” Bleeping Computer. December 21, 2021. https://www.bleepingcomputer.com/news/security/2easy-now-a-significant-dark-web-marketplace-for-stolen-data/

Toulas, Bill. “New BHUNT malware targets your crypto wallets and passwords.” Bleeping Computer. January 19, 2022. https://www.bleepingcomputer.com/news/security/new-bhunt-malware-targets-your-crypto-wallets-and-passwords/

U.S. Cybersecurity & Infrastructure Security Agency. “LokiBot Malware.” October 24, 2020. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-266a

U.S. Department of Justice. “Criminal Marketplace Disrupted in International Cyber Operation.” April 5, 2023. https://www.justice.gov/opa/pr/criminal-marketplace-disrupted-international-cyber-operation

Appendix — Infostealer comparison

The following chart compares five of the most common infostealers in 2022.

The post The Growing Threat from Infostealers appeared first on Online Pitstop.

Amazon Web Service (AWS) Lambda is a serverless event-driven compute service. It is a function as a service (FaaS) that allows users to deploy application functionality without the complexity of maintaining the underlying infrastructure. Lambda executions can be triggered by events from other AWS services or software-as-a-service (SaaS) applications.

Inside the Lambda execution environment is a set of AWS Security Token Service (AWS STS) temporary and limited-privilege credentials for AWS Identity and Access Management (IAM). An attacker may be able to steal these credentials via a user application vulnerability or resource misconfiguration. The attacker could then use these credentials to escalate privileges, maintain persistence, or move laterally through an organization’s AWS account or accounts.

Secureworks® Counter Threat Unit (CTU) researchers have developed a technique using AWS CloudTrail to detect the use of stolen credentials. Every time an AWS Lambda executes, it generates an AWS CloudTrail logging event that can be used to establish a baseline for normal operation. The use of stolen credentials can then be detected when a logging event deviates from the baseline. A similar approach could be applied to detect AWS credentials stolen from other services. Although Amazon GuardDuty detects EC2 instance credentials used from another AWS account, it does not apply to Lambda or any other services nor does it detect credentials being used within the same account.

AWS Lambda execution and event logging

Understanding the detection logic technique requires some knowledge of the AWS Lambda architecture, operation, and management API calls.

AWS CloudTrail

AWS CloudTrail monitors and records account activity and API usage across all AWS accounts. By default, CloudTrail records a 90-day history of management events and makes this data freely available to AWS customers. Customers may optionally enable data event logging that includes AWS Lambda execution and Invoke events, but this feature is an additional cost. Because not all AWS customers may enable this feature, the detections need to rely on the management events captured in all environments.

Lambda microVMs and Workers

According to AWS, “Lambda will create its execution environments on a fleet of Amazon EC2 instances called AWS Lambda Workers. Workers are […] launched and managed by Lambda in a separate isolated AWS account which is not visible to customers. Workers have one or more hardware-virtualized micro virtual machines [(microVMs)] created by Firecracker.” Figure 1 shows the isolation of two customers’ Lambda functions on shared infrastructure.

Figure 1. Isolation model for AWS Lambda Workers. (Source: AWS)

Lambda execution environment lifecycle

The standard lifecycle of the execution environment includes three primary phases (see Figure 2).

Figure 2. Lambda execution environment lifecycle. (Source: AWS)

1. Init — Lambda creates or unfreezes an execution environment with the configured resources, downloads the code for the function and all layers, initializes extensions, initializes the runtime, and then runs the function’s initialization code (i.e., the code outside the main handler). The Init phase happens either during the first invocation or in advance of function invocations if provisioned concurrency is enabled. The Init phase is split into three sub-phases: Extension init, Runtime init, and Function init. These sub-phases ensure that all extensions and the runtime complete their setup tasks before the function code runs.

   When a Lambda creates an execution environment during the Init phase, it is commonly referred to as the ‘cold start.’ When an already initialized environment is invoked again before shutdown is triggered, it is called a ‘warm start.’

2. Invoke — Lambda invokes the function handler. After the function runs to completion, Lambda prepares to handle another function invocation.
3. Shutdown — This phase is triggered if the Lambda function does not receive any invocations for a period of time. It is unclear what logic AWS uses to calculate this timeframe. In the Shutdown phase, Lambda shuts down the runtime, alerts the extensions to let them stop cleanly, and then removes the environment.

According to AWS, Workers have a maximum lease time of 14 hours. However, CTU researchers observed much shorter lifecycles. The AWS STS credentials used by the Worker have a default expiration of 12 hours, so it is probable that the credentials are still valid after a Worker is shut down.

AWS introduced Lambda SnapStart for Java 11 runtime in November 2022. Its lifecycle is slightly different from the standard Lambda lifecycle. However, the standard lifecycle is suitable for this analysis because CTU researchers observed no differences in the detection logic.

Lambda initialization and logging

Every Lambda cold start records two CloudTrail events: AssumeRole and CreateLogStream (see Figure 3).

Figure 3. API calls during Lambda initialization. (Source: Secureworks)

1. The AssumeRole event is recorded when the customer-defined Lambda identity access management (IAM) execution role requests AWS STS credentials from the invoke service. The timing of this event in the execution lifecycle is unclear, but CTU research shows it occurs prior to initialization of the Lambda Worker.
2. The Lambda Worker makes an API call and attempts to create a CloudWatch log stream. If the CloudWatch log group does not exist, then the first Lambda execution’s CreateLogStream API call fails with error code ResourceNotFoundException. The Lambda Worker then attempts to call CreateLogGroup, followed by a successful CreateLogStream call.

The detection outlined in this analysis relies on the following assumptions:

• The Lambda execution IAM role is configured with permissions to log to CloudWatch. The AWS managed policy that is typically used, AWSLambdaBasicExecutionRole, includes these permissions.
• If the CloudWatch log group exists but the Lambda execution role does not have logging permission, then CloudTrail will still log the failed events.
• If the log group does not exist and the execution role does not have logging permission, then CreateLogStream generates no CloudTrail events.

Because the Lambda Worker is the source of the CreateLogStream event, the event includes the AWS region and source IP address where the customer’s Lambda function executes. The source of the AssumeRole event is outside the Worker and therefore does not contain this information. Invoke events are data events and are labeled in Figure 3 for completeness, but they are excluded from the following detection logic because they may not exist in all environments.

Figure 4 lists an example AssumeRole event created during the Lambda Init phase.

Figure 4. AssumeRole CloudTrail event. (Source: Secureworks)

Figure 5 lists an example CreateLogStream event.

Figure 5. CreateLogStream CloudTrail event. (Source: Secureworks)

Concurrency

Sometimes multiple CreateLogStream events possess the same access key ID. These events possibly represent the Lambda Worker starting multiple processes with the same STS credentials. Figure 6 shows the diff command output where two event keys match but the IP addresses are different.

Figure 6. Output of diff command comparing CreateLogStream events. (Source: Secureworks)

Figure 7 is an example of a Lambda initialization with concurrency.

Figure 7. API calls during Lambda initialization with concurrent execution. (Source: Secureworks)

AWS STS key reuse

CTU researchers discovered that AWS STS access keys can be reused over time and associated with unrelated events. The two events in Figure 8 possess the same STS access key ID (accessKeyId), but the credentials were assumed by different user identities that had different IAM roles. The principalId and userName fields are different components of the IAM role’s Amazon resource names (ARNs). The time difference (‘creationDate’) is only 11 days. It is possible that the AWS account ID is used as input to the access key generation process.

Figure 8. Output of diff command comparing CloudTrail events for different roles with the same access key ID. (Source: Secureworks)

Amazon Virtual Private Cloud (VPC) access

A Lambda function runs inside a VPC owned by the Lambda service. Lambdas can use an elastic network interface (ENI) to connect from the AWS-managed Lambda VPC to private subnets in a customer-managed VPC. When a Lambda is configured to access resources in a customer VPC and security groups are configured to allow egress, the CreateLogStream event’s source IP address will not match the public source IP address of other events.

Figure 9 is an example of a complete Lambda configuration with VPC access. Each number corresponds to a different source IP address in the CloudTrail event logs. CreateNetworkInterface and AllocateAddress events are generated by the Lambda Worker when connecting to the customer VPC. Other source IP addresses may appear in CloudTrail when a Lambda function interacts with other AWS resources. The source IP address for a request to AWS S3 via a VPC gateway endpoint is the private IP address assigned to the ENI. The request to DynamoDB routes via the internet, and the source is the public IP address assigned to the NAT gateway.

Figure 9. API calls during Lambda initialization with VPC access. (Source: Secureworks)

The VPC access scenario uses AllocateAddress events instead of CreateLogStream to find the public IP address, specifically the responseElements.publicIp field (see Figure 10).

Figure 10. AllocateAddress CloudTrail event. (Source: Secureworks)

Proof-of-concept detection

The proof-of-concept detection uses Amazon Athena to identify CloudTrail events associated with the use of stolen Lambda credentials. This detection is portable and can be used ad-hoc in any AWS account, such as during an incident response investigation.

Detection logic

The first step in building the detector is to extract metadata from the CreateLogStream events. These events are generated by the Workers during the Init phase of the Lambda execution lifecycle. The CloudTrail logs are filtered on the following fields:

• eventName — Filter for the ‘CreateLogStream’ value, which the Worker uses to set up CloudWatch logging
• userAgent — Filter for strings that contain the ‘awslambda-worker’ value (e.g., awslambda-worker/1.0 rusoto/0.48.0 rust/1.67.1 linux)

A table is created using these events to form a baseline of standard operation. The table is populated with the following metadata fields:

• eventTime — timestamp of the CreateLogStream event (This event occurs seconds after the related AssumeRole event and can be used to infer when the STS credentials were generated.)
• userIdentity.accessKeyId — AWS STS access key ID used by the Worker and Lambda function
• userIdentity.arn — ARN of the IAM role associated with the access credentials, used to deconflict when STS access key IDs are reused
• sourceIPAddress — source IP address of the event (When Lambda concurrency is enabled, multiple IP addresses associated with Lambda executions use the same credentials.)
• awsRegion — geographical location of the AWS region where the event originated (This location provides additional information to disambiguate events.)

A second table is created that contains all customer-allocated public IP addresses. These are IP addresses that have been associated with a resource in an AWS account, such as a NAT gateway or EC2 instance. CloudTrail logs are filtered for ‘AllocateAddress’ events, and the following fields are extracted:

• publicIp — IP address allocated to an AWS resource
• allocationId — unique identifier for the original AllocateAddress event
• ·networkBorderGroup — location where the IP address was allocated within an AWS region

To determine if credentials have been exfiltrated or used outside the standard Lambda execution, a query is run against all CloudTrail events. It looks for events where the access key ID exist in the baseline Lambda events table and where the following criteria is met:

• The sourceIPAddress is different from the IP addresses used by the Lambda Worker in the Init phase.
• The userIdentity.arn is the same as the ARN used by the Lambda.
• The eventName is not Decrypt. AWS Key Management Service (KMS) generates decrypt events if enabled. This detector ignores these events.
• The eventTime is more recent than the Lambda Init phase.
• The sourceIPAddress has not been observed in the account. False positives could occur if sourceIPAddresses are very old and are not within the log retention period. This condition should not be an issue with this detector because the address gets allocated to the ENI at approximately the same time as the CreateLogStream event.

Applying the detection using Amazon Athena

Before AWS CloudTrail logs can be queried with Amazon Athena, the following prerequisites are required:

• Configure a trail to write logs to an S3 bucket if one does not already exist. AWS recommends this process as best security practice to store and retain events longer than 90 days. For the detection to be accurate, the trail should be configured to collect logs from all enabled AWS regions.
• Create an Athena table for CloudTrail logs. The default table name is ‘cloudtrail_logs’. If a different table name is used, the FROM statements in the Athena queries needs to be updated with the revised name.

When the prerequisites are completed, Amazon Athena can search CloudTrail events for use of stolen credentials. The Appendix of this analysis includes these Athena queries in plain text for researchers who want to replicate the detection.

1. Create a separate table containing the CreateLogStream events (see Figure 11). The query will retrieve the earliest eventTime value and combine the source IP addresses from concurrent execution environments into an array.
   
   
   Figure 11. Athena query to create table for CreateLogStream events. (Source: Secureworks)
   
2. Create another table containing all of the public IP addresses associated with customer resources (e.g., internet gateway) (see Figure 12).
   
   
   Figure 12. Athena query to create table for customer-allocated IP addresses. (Source: Secureworks)
   
3. Query for events using stolen Lambda credentials (see Figure 13).
   
   Figure 13. Athena query to select events using stolen credentials. (Source: Secureworks)

Figure 14 shows an example GetCallerIdentity event found with this detection.

Figure 14. Event detected using stolen credentials. (Source: Secureworks)

The following values should immediately flag this event as suspicious:

• awsRegion “us-east-1” does not match “us-west-2”
• eventName “GetCallerIdentity” is unlikely to be run by legitimate Lambda
• sourceIPAddress “203 . 0 . 113 . 9” does not match “34 . 220 . 84 . 211”
• sourceIPAddress “203 . 0 . 113 . 9” is not within the AWS IP address space

Taking the detector further

AWS publishes its public IP address ranges using Classless Inter-Domain Routing (CIDR) notation in JSON format. This data could increase detection logic efficiency by first checking if an IP address exists outside AWS, and then using more computationally expensive logic to check other conditions.

Similar detection logic could be applied to other services within AWS. Primary candidates would be AWS Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS). Both services can leverage the AWS Fargate serverless compute engine, which is built on the same Firecracker microVM as the Lambda Worker.

Caveats

Lambda pricing is calculated per one million requests. Cold starts in environments with a high frequency of executions happen less often. However, real-time detection could generate a large quantity of detector database inserts and result in a large table size.

The detection logic described in this analysis relies on an undocumented feature. At any time, AWS could change how Lambda executes.

Conclusion

AWS CloudTrail is a rich source of management events. Network defenders can use specific events in the AWS Lambda operating environment to provide a baseline or context for other events. The proof-of-concept detector using Athena can effectively search events for malicious behavior.

Appendix — Athena queries

Text versions of the Athena queries used in the detection proof of concept are provided for convenience to other researchers who want to explore this functionality.

Create table for CreateLogStream events

CREATE TABLE "lambda_coldstart" AS
SELECT 
    useridentity.accessKeyId as accesskeyid, 
    -- Source IP can be different for the same access key id due to Lambda concurrency
    array_agg(sourceipaddress) as sourceipaddresses, 
    awsregion,
    useridentity.arn as arn,
    array_agg(useragent) as useragents,
    MIN(eventtime) as eventtime
FROM cloudtrail_logs WHERE
    eventname = 'CreateLogStream' AND 
    useragent LIKE 'awslambda-worker%'
GROUP BY 1, 3, 4

Create table for customer-allocated IP addresses

CREATE TABLE allocated_addresses AS
SELECT 
    json_extract_scalar(responseelements, '$.publicIp') as publicip,
    json_extract_scalar(responseelements, '$.allocationId') as allocationid,
    -- this is region name
    json_extract_scalar(responseelements, '$.networkBorderGroup') as networkbordergroup
FROM 
    "cloudtrail_logs" 
WHERE 
    eventname = 'AllocateAddress';

Select events using stolen credentials

SELECT
    lcs.accesskeyid,
    lcs.sourceipaddresses,
    lcs.awsregion,
    ct.useridentity.accessKeyId,
    ct.sourceipaddress, 
    ct.awsregion,
    ct.eventname,
    ct.eventid
FROM cloudtrail_logs ct, lambda_coldstart lcs WHERE
    lcs.accesskeyid = ct.useridentity.accessKeyId AND
    not contains(lcs.sourceipaddresses, ct.sourceipaddress) AND
    -- Exclude AWS managed services
    ct.sourceipaddress != 'AWS Internal' AND
    -- access keys can be reused to make sure it's the same ARN (which will differ)
    ct.useridentity.arn = lcs.arn AND
    -- Decrypt is noisy for the purposes of this detector
    ct.eventname != 'Decrypt' AND
    ct.eventtime > lcs.eventtime AND
    -- Lookup IP addresses that have been allocated to account and exclude if they match
    NOT EXISTS (SELECT 1 FROM allocated_addresses aa WHERE aa.publicip = ct.sourceipaddress);

The post Detecting the Use of Stolen AWS Lambda Credentials appeared first on Online Pitstop.

In August 2022, Secureworks® Counter Threat Unit (CTU) researchers discovered a vulnerability in Azure Active Directory (Azure AD) that allowed a user to retain access to a targeted Security Assertion Markup Language (SAML) application after the user assignment was removed. Using a backdoor application that was given consent to access the SAML application, a malicious user could request SAML tokens despite the user assignment removal. By exploiting this vulnerability, a malicious user could establish persistence and elevate privileges on targeted SAML applications.

CTU researchers reported these findings to Microsoft on August 4. Microsoft addressed the issue with mitigations initially deployed on October 25.

Attack overview

Azure AD offers the option to configure SAML-based single sign-on (SSO) for multiple pre-integrated and customer-developed services (i.e., applications). When user assignment is required, users and groups must first be assigned to the application before they can access it.

When exploiting this vulnerability, the most lucrative target for a malicious user would be a SAML application that relies solely on Azure AD’s user assignment setting. In this scenario, the absence of user assignment enforcement in the SAML application could be exploited to provision a new user for the malicious user in the target service.

The flaw was triggered when chaining sign-in with additional application and certain parameters in the token request (see Figure 1). This use case was originally intended so that backend SAML APIs could be called from an OAuth 2.0 application.

Figure 1. Attack process. (Source: Secureworks)

1. The malicious user requests an Azure AD access token for the additional application.

2. The additional application requests a token for the SAML application using on-behalf-of flow. The request payload includes the parameters listed in Figure 2.

   
   Figure 2. Parameters included in request payload. (Source: Secureworks)

   Chaining steps 1 and 2 bypasses the user assignment setting. The token generated in step 1 is used in the ‘assertion’ parameter.

3. The request response emits the SAML token.

Proof of concept

In the proof-of-concept (PoC) scenario, a malicious user leverages a backdoor application to access any existing SAML applications that the malicious user was assigned when the backdoor application was configured. The malicious user retains access via the backdoor to any SAML application after their access is removed.

1. The malicious user creates a new Azure AD application to use as the backdoor. They then consent it to any existing SAML application for which they want to receive tokens after the user assignment is removed. In the example shown in Figure 3, the malicious user uses a backdoor application named “UnPrivilegedUserSAMLattack2” to access a generic application called “SAML app” for which the malicious user had an existing user assignment.

   
   Figure 3. Using a backdoor to compromise a SAML application. (Source: Secureworks)

2. The application administrator removes the malicious user from the user assignment in the existing SAML application (see Figure 4).

   
   Figure 4. Removing the malicious user from the SAML application user assignment. (Source: Secureworks)

3. The malicious user requests tokens for the SAML application using the application configured in step 1.

The backdoor application used in this PoC requests tokens by leveraging an unrelated app retrofitted with malicious code added to its getCode.js file. The lines referencing the requested token contain the following vulnerable parameter combination that bypasses the user assignment verification:

"requested_token_type":"urn:ietf:params:oauth:token-type:saml2",

"requested_token_use":"on_behalf_of"

Evaluation of SAML tokens

The objective of the attack is to acquire a SAML token with a valid signature, issuer, audience, and claims (see Figure 5). The malicious user receives a SAML token comparable to one that is emitted using a legitimate access pattern, despite the lack of user assignment for the application. Testing concluded that additional claims configured for the SAML application, such as groups, were included in the maliciously obtained SAML token.

Figure 5. Attributes of a maliciously acquired SAML token. (Source: Secureworks)

Exploitation requirements

While the vulnerability was trivially exploitable, the malicious user needed a deep understanding of Azure AD applications and their configurations. The malicious user had to backdoor applications while they possessed a valid user assignment. The following knowledge is required to exploit this issue:

• Understanding on-behalf-of flows in Azure AD.
• Understanding the use of non-standard flows to request a SAML token with a JWT.
• Understanding Azure AD application consents and application permissions.
• Understanding the use of SAML tokens outside the normal use pattern. The PoC code abuses a CLI application with device code flow to gain a JWT, and later exchanges it for a SAML token using the on-behalf-of pattern “<->”. This technique differs from the typical use case of having a web browser receive the SAML token via interfacing directly the browser application.

Communication with Microsoft

CTU researchers reported their initial findings about this vulnerability to Microsoft on August 4, 2022 and provided additional details on October 7. Microsoft confirmed the attack pattern on October 10 and categorized it as an “important” elevation of privilege issue. Microsoft addressed the issue in mitigations initially deployed on October 25 and provided the following response:

Microsoft has fixed an issue in the Azure Active Directory (Azure AD) OAuth2.0 protocol access token request when those requests are made by middle-tier applications who in turn use Security Assertion Markup Language (SAML) based authorization to access back-end APIs. Under certain circumstances, this issue would allow users within a tenant inappropriate access to back-end application functionality.

Microsoft has fixed the issue. Only correctly configured users will have access to the functionality of the back-end application.

Conclusion

This flaw allowed a previously assigned user within the tenant boundary to retain access to an application via a backdoor application, even after the user assignment was removed. This behavior was only possible if the user had valid access when the backdoor application was configured.

The following mitigating factors applied to this vulnerability:

• Applications that support IdP-initiated SSO were affected. Applications that only support SP-initiated SSO were not affected because SP-initiated SSO requires the “inResponseTo” attribute in the SAML response.
• Applications that perform additional checks for user permissions or roles when receiving the token could prevent access even if the malicious user was able to bypass the user assignment on Azure AD.

To reduce risk to similar threats, CTU researchers recommend that organizations prevent users from registering their own applications in the Azure AD tenant.

The post Azure Active Directory Flaw Allowed SAML Persistence appeared first on Online Pitstop.

Pass-through authentication (PTA) is one of the Azure Active Directory (Azure AD) hybrid identity authentication methods. PTA relies on PTA agents installed on one or more on-premises servers. Azure AD uses a certificate-based authentication (CBA) to identify each agent. In May 2022, Secureworks® Counter Threat Unit (CTU) researchers analyzed how the protocols used by PTA could be exploited. The researchers determined that threat actors could steal the identity of the PTA agent by exporting the certificate used for CBA. The compromised certificate can be used with the attacker-controlled PTA agent to create an undetectable backdoor, allowing threat actors to log in using invalid passwords, gather credentials, and perform remote denial of service (DoS) attacks. Attackers can renew the certificate when it expires to maintain persistence in the network for years. A compromised certificate cannot be revoked by an organization’s administrators.

CTU researchers shared their findings with Microsoft on May 10, 2022. Microsoft responded on July 2 that PTA is working as intended and gave no indication of plans to address the reported flaws.

Azure AD hybrid identity authentication options

Azure AD supports three authentication options for hybrid identities (see Figure 1). Microsoft recommends using password-hash synchronization (PHS) for authentication. Identity federation and PTA are options for organizations that cannot or choose not to synchronize password hashes to the cloud, or organizations that need stronger authentication controls. Identity federation is usually implemented with the Microsoft Active Directory Federation Services (AD FS), which is included in Windows Server operating systems. PTA is often promoted as being preferable to identity federation, as AD FS has been targeted in attacks such as Solorigate (using a technique known as Golden SAML). In these attacks, threat actors can export the token-signing certificate from a compromised AD FS server and use it to forge SAML tokens to impersonate users.

Figure 1. Azure AD hybrid identity authentication options. (Source: Secureworks)

PTA relies on PTA agents installed on one or more on-premises servers. Microsoft recommends installing a minimum of three agents for high availability. Each tenant can have a maximum of 40 agents. Figure 2 illustrates the high-level PTA architecture.

Figure 2. High-level PTA architecture. (Source: Secureworks)

1. A user accesses a service that uses the Azure AD identity platform (e.g., Microsoft 365) and provides their username and password.
2. Azure AD encrypts the credentials and sends an authentication request to one or more PTA agents.
3. The PTA agent decrypts the user’s credentials, attempts to log in to Active Directory with decrypted credentials, and returns results to Azure AD.

Installation

During the installation of a PTA agent, a certificate signing request (CSR) is sent to the Azure AD https: //<tenant ID> . registration . msappproxy . net/register/RegisterConnector endpoint (see Figure 3). The response includes a certificate signed by Azure AD.

Figure 3. PTA agent registration request. (Source: Secureworks)

The certificate is issued by HISconnectorRegistrationCA . his . msappproxy . net, and the certificate subject is the Azure AD tenant ID (see Figure 4). The agent ID is a globally unique identifier (GUID), which is encoded in object identifier (OID) value 1.3.6.1.4.1.311.82.1 as a byte array. The certificate is valid for six months.

Figure 4. PTA agent certificate information and details. (Source: Secureworks)

The list of PTA agents and their associated IP address and status is stored in Azure SQL Database and is available in the Azure AD portal (see Figure 5). The list does not display the agent IDs.

Figure 5. List of PTA agents in the Azure AD portal. (Source: Secureworks)

Administrators can use the MS Graph API or tools such as AADInternals to view agents’ IDs. For example, Figure 6 lists two agents and their IDs. The first ID matches the certificate in Figure 4, but each segment of the ID lists the values of the certificate in reverse order as described in RFC4122.

Figure 6. Using AADInternals to list PTA agents. (Source: Secureworks)

The PTA agent ID is included on the Authentication Details tab in the Azure AD sign-ins log details. It identifies which agent was used to authenticate the user. For example, Figure 7 shows that the second agent listed in Figure 6 performed the authentication.

Figure 7. Authentication details in the Azure AD sign-ins log. (Source: Secureworks)

The thumbprint of the certificate used by the PTA agent is located on disk in a configuration file named C:ProgramDataMicrosoftAzure AD Connect Authentication AgentConfigTrustSettings.xml (see Figure 8).

Figure 8. PTA agent configuration file. (Source: Secureworks)

The certificate, including the private key protected by the data protection API (DPAPI), can be exported with tools such as AADInternals and Mimikatz. AADInternals exports the certificate as a PFX file named as <computer full name>_<tenant ID>_<agent ID>.pfx (see Figure 9).

Figure 9. Exporting PTA agent certificate using AADInternals. (Source: Secureworks)

PTA agent startup

The main technical components involved with PTA are Azure AD, Azure Service Bus, and the Azure AD Connect Authentication Agent (PTA agent). The agent searches for a “bootstrap” document that specifies settings and a list of command and control (C2) channels that enable the PTA to establish WebSocket connections to identified endpoints (see Figure 10).

Figure 10. PTA agent startup sequence. (Source: Secureworks)

1. The PTA agent connects to https: //<tenant ID> . pta . bootstrap . his . msappproxy . net/ConnectorBootstrap and uses CBA to identify itself.
2. Azure AD sends an HTTP redirect to the PTA agent for the regional endpoint.
3. The PTA agent connects to the regional endpoint at https: //bootstrap-<xxxn> . his . msappproxy . net/ConnectorBootstrap. The <xxxn> variable includes three alphabetical characters and one number.
4. Azure AD returns a “bootstrap” XML document containing several settings and a list of signaling listener endpoints geographically close to the PTA agent (see Figure 11). This document instructs the PTA agent to connect to and listen on specific command and control (C2) channels via the Azure Service Bus.


Figure 11. Excerpt of bootstrap file. (Source: Secureworks)

5. The PTA agent establishes a WebSocket connection to each signaling listener endpoint and is ready to receive authentication requests. Endpoints are implemented using Azure Service Bus.
   

The PTA agent repeats steps 1 through 4 every ten minutes to refresh the bootstrap. The agent reconnects to the signaling listener endpoints defined in the bootstrap XML data (step 5) as needed.

PTA authentication process

PTA leverages Azure Service Bus, Azure Relay, and Azure AD Application Proxy services during the authentication process (see Figure 12). These elements deliver authentication requests from Azure AD to PTA agents, and authentication responses from the PTA agents to Azure AD.

Figure 12. PTA authentication process. (Source: Secureworks)

1. Azure AD sends a notification to all connected agents via Azure Service Bus. The notification includes an address of the Azure Relay.
2. The PTA agent establishes a WebSocket connection to the Azure Relay.
3. Azure AD sends an authentication request to the PTA agent via Azure Relay.
4. The PTA agent attempts to log in to the on-premises Active Directory domain. It sends the authentication results to Azure Web Application Proxy via an HTTP POST request.

The established WebSocket connections are not closed. This means that subsequent authentication requests are faster, as not all steps are needed. Requests can be sent using the already established connection to the relay.

The authentication request sent in step 3 is an XML file (see Figure 13). The EncryptedData element contains an array of credentials encrypted using different certificates. The key identifier is in the format <agent ID>_<certificate thumbprint>. This format allows each PTA agent to decrypt the appropriate credentials entry.

Figure 13. Authentication request. (Source: Secureworks)

After signing in using the provided credentials, the PTA agent sends a response message to Azure AD via the proxy. The response is a JSON file that includes two claims. In a successful response (see Figure 14), the “http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication” claim is set to true and the “http:// schemas . xmlsoap . org/ws/2002/05/identity/claims/name” claim is set to the user’s username. Azure AD does not check the validity of the username.

Figure 14. Response for successful authentication. (Source: Secureworks)

In the failed response (see Figure 15), the “http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication” claim is set to false and the “http: //schemas . xmlsoap . org/ws/2002/05/identity/claims/validationfailurereasoning” claim contains the error code. For instance, error 1327 means “Account restrictions are preventing this user from signing in.”

Figure 15. Response for failed authentication. (Source: Secureworks)

Custom PTA agent

After studying the protocols used by PTA agents, CTU researchers implemented a proof-of-concept custom PTA agent that leverages the certificate of an existing PTA agent. After startup, the custom PTA agent connects to Azure AD and waits for authentication requests. Figure 16 shows the agent connecting to Azure AD using the provided certificate, decrypting credentials, and displaying the plaintext user password. The custom agent can accept or deny all requests regardless of whether the password is valid. Threat actors can create a similar custom PTA agent to harvest credentials, establish a backdoor, or conduct a DoS attack by denying authentication requests containing valid credentials.

Figure 16. Custom PTA agent. (Source: Secureworks)

CTU researchers observed that the PTA agent’s IP address changed in the Azure AD portal when the custom PTA agent started (see Figure 17). However, after the original PTA agent fetched the bootstrap during its next ten-minute cycle, the IP address reverted. This behavior implies that the IP address is populated every time a PTA agent fetches the bootstrap. When CTU researchers pointed the custom PTA agent to an existing bootstrap file on the system, the agent’s IP address did not change on the portal. This result suggests that connecting directly to signaling listener endpoints does not affect the IP address. As such, threat actors can use an existing bootstrap to connect to Azure AD undetected.

Figure 17. PTA agent IP address change. (Source: Secureworks)

The certificate used to authenticate the PTA agent is valid for six months. The PTA agent cannot decrypt passwords when its certificate expires or if the agent has been inactive for ten days. In these cases, the PTA agent can “renew” the trust with Azure AD by making a HTTP POST request to the trust renew endpoint defined in the bootstrap file. The expired certificate can be used for CBA with this endpoint, and Azure AD returns a new certificate. Renewing trust does not populate the PTA agent’s IP address or invalidate the previous certificate, so a single agent can possess multiple valid certificates. CTU researchers observed that if a PTA agent possesses more than ten active certificates, the authentication requests contain passwords encrypted with the ten newest certificates. Threat actors can perform DoS attacks by renewing the certificate of the compromised agent ten or more times, making the original agent unable to decrypt credentials.

Because the information available from the Azure AD portal for administrators is populated when the bootstrap XML is requested, impersonating a PTA agent using the compromised certificate cannot be detected using Microsoft administrator tools. The Secureworks custom PTA agent can dump all active agents and certificates (Figure 18), helping administrators detect and identify compromised agents.

Figure 18. Secureworks custom PTA agent dumping active agents. (Source: Secureworks)

The PTA agent exports agent IDs and certificate thumbprints for all active certificates to a text file. Figure 19 shows that the PTA agent with ID 672843e0-8b25-434f-93e2-5d5071139e09 possesses three active certificates, which indicates that a compromised agent certificate was used to renew the certificate twice. The renewed certificates’ active status means that they were used by a threat actor during the last ten days.

Figure 19. List of active agents and certificates. (Source: Secureworks)

Unlike AD FS token-signing certificates, PTA agent certificates cannot be explicitly revoked. Administrators can remove PTA agents from servers but cannot directly remove PTA agents from the Azure SQL Database. Agents can only be removed from the database by keeping them inactive for ten days, after which they are automatically removed by Microsoft. If a threat actor is actively using any certificate associated with the compromised PTA agent, the agent never becomes inactive.

Communication with Microsoft

CTU researchers reported their initial findings to the Microsoft Security Response Center (MSRC) on May 10, 2022 and submitted additional findings related to undetectable access on May 16. The MSRC responded to the CTU research team on July 7:

Our team completed the assessment for this issue and we understand that the attack surface for this requires compromising a high security asset by gaining administrative access in the first place. If the customer followed our hardening guidance but the attacker still has access to the server that runs the PTA agent then they already had access to the user credentials, hence we believe this vulnerability in itself does not pose an additional risk. As a mitigation mechanism, we do have the ability to block agents on the server side based on customer escalations and furthermore we are looking into ways to improve our audit logs as an improved detection mechanism.

Conclusion

A compromised PTA agent certificate gives threat actors persistent and undetectable access to a target organization. Threat actors can use the compromised certificate to conduct the following activities:

• Harvest credentials
• Create a backdoor
• Conduct DoS attacks by rejecting valid passwords or by renewing the certificate ten or more times

CTU researchers recommend that organizations perform the following actions to protect their tenants:

• Treat all on-premises hybrid identity components, including servers with PTA agents, as tier 0 servers.
• Consider using other hybrid authentication methods, such as PHS or identity federation, until Microsoft addresses these security issues.
• Monitor for suspicious activity, such as logins using an incorrect password. Sign-in activity is available in the Azure AD portal and via the ‘beta’ version of the Microsoft Graph sign-ins report. If there are any indications of a compromised PTA agent, immediately create a support request in the Azure AD portal to invalidate the agent.
• Use multi-factor authentication to prevent threat actors from using a PTA agent as a backdoor.

The post Azure Active Directory Pass-Through Authentication Flaws appeared first on Online Pitstop.

DarkTortilla is a complex and highly configurable .NET-based crypter that has possibly been active since at least August 2015. It typically delivers popular information stealers and remote access trojans (RATs) such as AgentTesla, AsyncRat, NanoCore, and RedLine. While it appears to primarily deliver commodity malware, Secureworks® Counter Threat Unit (CTU) researchers identified DarkTortilla samples delivering targeted payloads such as Cobalt Strike and Metasploit. It can also deliver “addon packages” such as additional malicious payloads, benign decoy documents, and executables. It features robust anti-analysis and anti-tamper controls that can make detection, analysis, and eradication challenging.

From January 2021 through May 2022, an average of 93 unique DarkTortilla samples per week were uploaded to the VirusTotal analysis service. Code similarities suggest possible links between DarkTortilla and other malware: a crypter operated by the RATs Crew threat group, which was active between 2008 and 2012, and the Gameloader malware that emerged in 2021.

Delivery

CTU analysis of VirusTotal samples revealed numerous campaigns delivering DarkTortilla via malicious spam (malspam). The emails typically use a logistics lure and include the malicious payload in an archive attachment with file types such as .iso, .zip, .img, .dmg, and .tar. The language of the email message is customized to the victim, and CTU researchers observed samples in English, German, Romanian, Spanish, Italian, and Bulgarian. Figure 1 shows a German-language malspam sample. The redacted filename of the attached ISO image archive file (.iso) includes the name of the organization the email was sent from. It is unclear if that organization was compromised. The archive file contains a single executable with the same filename but the .exe extension. This executable is a DarkTortilla initial loader sample.

Figure 1. DarkTortilla malspam containing malicious archive attachment. (The German text translates to “Good morning, Please give us your best price offer for our attached order. Awaiting your kind reply. Kind regards”). (Source: Secureworks)

CTU researchers also identified malicious documents (maldocs) delivering DarkTortilla. Most of these maldocs embed the DarkTortilla initial loader executable as a Packager Shell Object. Figure 2 shows a sample that prompts the victim to double-click the embedded Packager Shell Object, which executes the payload. Inspection of the Packager Shell Objects properties revealed that it is an executable named RFQ-010129H.exe, which is a DarkTortilla initial loader sample. Other analyzed maldocs use different approaches, such as leveraging embedded macros to automatically execute the Packager Shell Object when a victim opens the document and enables macros.

Figure 2. Maldoc sample delivering DarkTortilla. (Source: Secureworks)

High-level execution flow

DarkTortilla consists of two components that rely on each other to successfully detonate payloads: a .NET-based executable (initial loader) and a .NET-based DLL (core processor). The typical high-level execution flow for a DarkTortilla payload starts with execution of the initial loader. The initial loader then retrieves its encoded core processor. While the encoded core processor is typically embedded within the .NET resources of the initial loader, CTU researchers identified initial loaders that retrieved their core processor from public paste sites such as pastebin . pl, textbin . net, and paste . ee.

The initial loader decodes, loads, and executes the core processor. When executed, the core processor extracts, decrypts, and parses its configuration. The encrypted configuration is stored within the .NET resources of the initial loader as bitmap images. Depending on DarkTortilla’s configuration, the core processor performs the following actions:

• Displays a fake message box
• Performs anti-virtual machine checks
• Performs anti-sandbox checks
• Implements persistence
• Migrates execution to the Windows %TEMP% directory by using the “Melt” configuration element
• Processes addon packages
• Migrates execution to its install directory

The core processor then injects and executes its configured main payload within the context of the configured subprocess. Finally, if configured, the core processor implements anti-tamper controls to prevent interference with execution of the initial loader, core processor, injected subprocess, and WatchDog executable.

Figure 3 illustrates this high-level DarkTortilla execution flow.

Figure 3. High-level execution flow for DarkTortilla infection. (Source: Secureworks)

Initial loader

Initial loader samples analyzed by CTU researchers were obfuscated using the DeepSea .NET code obfuscator. As a result, many aspects of the original code have been altered to thwart analysis. For example, namespace, class, function, and property names were renamed from their original descriptive values to random characters. Figure 4 shows an example of these obfuscated values within the code decompiled by the dnSpy .NET analysis tool.

Figure 4. Obfuscated DarkTortilla initial loader sample. (Source: Secureworks)

In addition to name obfuscation, DeepSea applies switch dispatch control flow obfuscation to DarkTortilla’s initial loader. This technique restructures the original linear code into switch statements that transfer execution in a seemingly unpredictable pattern, making analysis difficult. Figure 5 shows a switch statement at the entry point of a DarkTortilla sample. In this example, the value stored in the “num” variable controls which code gets executed next. This value is obfuscated and is often the result of a conditional or mathematical expression calculated at runtime, such as “((!flag) ? 15 : 9)” or “Math.Abs(num2 * 25 * 25)“.

Figure 5. Switch dispatch control flow obfuscation applied to DarkTortilla initial loader. (Source: Secureworks)

The initial loader stores DarkTortilla’s encrypted configuration as bitmap images. Figure 6 lists the partial resource section of one sample consisting of over 700 of these images.

Figure 6. Encrypted configuration stored as bitmap images within the .NET resources of DarkTortilla initial loader. (Source: Secureworks)

The initial loader’s execution flow typically starts by checking for internet connectivity by issuing HTTP GET requests. In samples that implement this check, the initial loader attempts to retrieve content from google . com, bing . com, or both. Some samples store the URLs in the executable as plain text (see Figure 7), but most samples encode them. If the check fails, the initial loader retries the request(s) until all are successful.

Figure 7. Internet connectivity check in DarkTortilla initial loader. (Source: Secureworks)

The initial loader generates a 16-byte key to decode the core processor. This key is based on an initial hard-coded value multiplied by the index value of its location in the destination array. Because the values are stored as single bytes, the maximum value for an element in the array is 0xFF (255 decimal). For example, the decode key array for an initial hard-coded value of 0x6E (110 decimal) is [0x00,0x6E,0xDC,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF].

The initial loader then retrieves the encoded core processor data. This data commonly resides within the .NET resources of the initial loader binary. Figure 8 shows encoded core processor data residing within the “pnj” .NET resource of a DarkTortilla sample.

Figure 8. Encoded core processor data stored within the .NET resources of DarkTortilla initial loader. (Source: Secureworks)

The initial loader decodes the core processor data by applying the following algorithm to each byte:

	enc_byte ^ (dec_key_arr[idx % len(dec_key_arr)] ^ (idx + (seed_byte % 
	len(dec_key_arr)) & seed_byte)

• enc_byte: The core processor byte array value being decoded
• idx: The encoded byte index in the core processor byte array
• dec_key_arr: The generated 16-byte decode key byte array
• seed_byte: The fourth byte of the 16-byte decode key byte array

The initial loader loads the decoded core processor assembly code and executes its pre-determined entry point function.

Initial loader variant with externally hosted core processor

Initial loader variants that retrieve the encoded core processor from public paste sites first decode the URL where the core processor is hosted. The encoding logic applied to the URL varies across analyzed DarkTortilla samples, making analysis and detection difficult. Figure 9 shows a DarkTortilla sample that encodes the URL (https: //pastebin . pl/view/raw/60b6b03b) by prepending and appending random text.

Figure 9. DarkTortilla initial loader variant that retrieves encoded core processor data from public paste site. (Source: Secureworks)

The initial loader retrieves an encoded string hosted at the decoded URL. This string represents the encoded core processor data. The string consists of fake XML tags, integer values encoded with a shift cipher, and delimiters comprised of random letters (see Figure 10). The downloaded data is stored in memory and is never saved to the filesystem.

Figure 10. Encoded DarkTortilla core processor data hosted on public paste site. (Source: Secureworks)

The initial loader decodes the string by first removing the fake XML tags. The string is converted into an array of integers by replacing the random letter character delimiters with a consistent letter and then using that letter to split the string into integers. The last step is to iterate through the integer array and subtract a pre-defined value. This value changes across samples.

In the Figure 10 example (<xml>1002k1015U1069k925E928s925U925E925g929E925…</xml>), the consistent letter delimiter is “k” and the pre-defined subtracted value is 925:

1. Remove XML tags: 1002k1015U1069k925E928s925U925E925g929E925…
2. Replace random letters with consistent character: 1002k1015k1069k925k928k925k925k925k929k925…
3. Split into integer array: [1002, 1015, 1069, 925, 928, 925, 925, 925, 929, 925, …]
4. Subtract pre-defined value from each integer: [77, 90, 144, 0, 3, 0, 0, 0, 4, 0, …]

The hex representation of the final integer array for this example is [4D, 5A, 90, 00, 03, 00, 00, 00, 04, 00, …]. This decoded data is the core processor DLL (see Figure 11).

Figure 11. Decoded DarkTortilla core processor DLL. (Source: Secureworks)

Core processor

The core processor contains DarkTortilla’s primary functionality. From at least June 2020 to March 2022, the malware author transitioned through a limited number of filenames for this DLL that appeared to relate to a function or purpose (Deserialize.dll, SHCore1.dll, PVCore1.dll, and SHCore2.dll). In March 2022, the names began to change more frequently to seemingly random names (e.g., BRIN.dll, UKRUSAIN.dll, KNIFALL.dll, NullSBAS.dll).

Configuration processing

The core processor identifies the following resources in the initial loader that are associated with the encrypted configuration:

• The bitmap image resource(s) containing the encrypted configuration data
• The binary resource specifying the total number of images to process
• The resource folder containing these images and binary resources

The names of these resources are calculated using the compile timestamp listed in the initial loader (which is not the file’s actual compile timestamp) and two hard-coded values that represent an initialization value and the length of the resource name. The hard-coded initialization and name length values were consistent across all DarkTortilla samples analyzed by CTU researchers (see Table 1).

Table 1. Values used to derive initial loader resource names.

These names are calculated via the following process:

1. Divide the compile timestamp by <initialization value>.
2. Round the result using the Math.Round() function.
3. Pass the result to the Random.Random() function as a seed value. By using a precalculated seed value, the malware author can generate a predictable 16-byte value.
4. Convert the 16-byte value to a GUID using the Guid.Guid() function, which transposes the byte order.
5. Remove dash characters (‘-‘) added during the GUID conversion.
6. Truncate the value to <resource name length> characters.

For example, the following calculation generates the resource folder name of a sample with a compile timestamp of “Sun May 26 23:57:08 1985” (integer: 486014228):

1. 486014228 / 5 = 97202845.6
2. Math.Round(97202845.6) = 97202846
3. Random.Random(97202846) = d00bee25fa9dc9024fdf632727286708
4. Guid.Guid(d00bee25fa9dc9024fdf632727286708) = 25ee0bd0-9dfa-02c9-4fdf-632727286708
5. Remove dashes = 25ee0bd09dfa02c94fdf632727286708
6. Truncate to 12 characters = 25ee0bd09dfa

Applying the same calculation to the other components reveals that the image count resource name for this sample is “cd6935eb” and the image base name is “d390ea32”. The bitmap-formatted image names follow the pattern <image_base_name><image_index>, where the <image_index> value ranges from 0 to the value specified in the image count resource. In this sample, the image count resource value is 0x2D4 (integer: 724), which means DarkTortilla attempts to process 725 bitmap-formatted images with the names d390ea320, d390ea321, d390ea322, …, d390ea32723, d390ea32724.

To extract the encrypted configuration, the core processor iterates through each of the image resources in order, extracts the pixel data, and concatenates the pixel data into a byte array (see Figure 12).

Figure 12. Logic for extracting encrypted configuration from bitmap images. (Source: Secureworks)

The resulting byte array is decrypted using the Rijndael cipher (also known as the Advanced Encryption Standard (AES)) with Electronic Code Book (ECB) block cipher mode and ISO10126 padding configured. The ISO10126 standard was withdrawn in 2007, so the use of this padding could indicate that DarkTortilla’s origins date back to 2007 or earlier. The key used to decrypt this data is stored as the hard-coded integer array [81, 42, 59, 7, 27, 70, 83, 13, 71, 75, 17, 9, 39, 64, 3, 2] (see Figure 13).

Figure 13. Hard-coded key to decrypt DarkTortilla configuration. (Source: Secureworks)

DarkTortilla parses the decrypted configuration data into a structure so that its elements can be easily referenced. Table 2 lists the potential configuration elements contained within DarkTortilla’s decrypted configuration. Entries in bold indicate configuration elements that were consistently present in all samples analyzed by CTU researchers.

Table 2. DarkTortilla configuration elements. Bold text indicates elements that appear in all analyzed samples.

Fake message display

DarkTortilla can be configured to display a message box when executed. The threat actor can customize message box characteristics such as the display message, message box title, and the icon and button configuration. Threat actors use fake message boxes to make victims think that execution failed or that a legitimate application is loading and installing. Table 3 lists the configuration elements and values in one DarkTortilla sample.

Table 3. Fake message box-related configuration elements.

Figure 14 shows the message box for the DarkTortilla sample configured with the values in Table 3. The %MessageRepetition% configuration element controls whether the message box will continue to be displayed upon execution after DarkTortilla is installed and persistent on the compromised system.

Figure 14. Fake message box. (Source: Secureworks)

“Melt” execution migration

If the %Melt% configuration element is set to true, the core processor moves the initial loader executable to the Window’s %TEMP% directory. It uses the %MeltName% configuration element value as the executable filename (e.g., java.exe, PDF.exe, cookies.exe). The core processor runs the new executable and then terminates the original initial loader executable. However, the %TEMP% directory may not be the final destination for the initial loader. The executable could migrate again if the %Installation% configuration element is set to true.

Installation

The %Installation% configuration element controls whether DarkTortilla installs itself on a system. If set to true, the core processor moves the current DarkTortilla executable into the directory specified by the configuration. Table 4 lists the values stored in one DarkTortilla sample.

Table 4. Installation configuration elements with example values.

The integer value assigned to the %InstallationDirectory% configuration element represents a CSIDL value associated with a special folder on the system. In Table 4, the value 38 corresponds to the Windows Program Files directory. Based on this configuration, the full install path and filename for this DarkTortilla sample is “C:Program FilesWindowsPowerShellPowerShellInfo.exe”.

To install, the core processor terminates the currently running DarkTortilla executable. It copies the executable to the configured installation path and filename, and then executes the installed executable via Process.Start().

Persistence

Persistence is controlled by the %Installation% configuration element in combination with the %Hidden% and %StartupFolder% configuration elements. DarkTortilla uses the logic in Table 5 to determine the persistence type.

Table 5. Configuration elements determining the persistence type.

A bug in the code causes the %StartupFolder% logic to override the %Hidden% logic if both configuration elements are set to true. The malware author erroneously used an “if” statement instead of “else if” in the logic setting the persistence type (see Figure 15).

Figure 15. Error in persistence code. (Source: Secureworks)

For Windows startup folder persistence, the core processor uses the WshShortcut COM object to create a .lnk shortcut file in the Windows startup folder. This file points to the configured installation path and filename of DarkTortilla’s initial loader executable (see Figure 16).

Figure 16. COM object that drops shortcut file in Windows startup folder for persistence. (Source: Secureworks)

DarkTortilla features standard and hidden techniques for implementing persistence via the Windows registry. Both options implement persistence in the HKEY_CURRENT_USER (HKCU) hive as a hard-coded value in the core processor code. This persistence results in the installed DarkTortilla initial loader executable being run every time the user logs in.

RunPE process injection

DarkTortilla can execute its payloads using process injection. With this method, the payload resides only in memory and never accesses the filesystem. The %HostIndex% configuration element defines which legitimate process to target for process injection (see Table 6).

Table 6. %HostIndex% values and corresponding target processes used for payload injection.

Prior to setting the target process name, the core processor checks for active processes named “avp”. The avp.exe process is part of the Kaspersky Anti-Virus suite. If the core processor detects this process, it overrides the %HostIndex% value and sets the target process name to the name of the initial loader executable. When the %HostIndex% value is 1-6, the core processor attempts to copy the legitimate target executable file to the Windows %TEMP% directory.

DarkTortilla uses a .NET-based DLL named “RunPe6” for process injection. This DLL is embedded within the core processor as an encoded byte array (see Figure 17).

Figure 17. Encoded RunPe6 DLL stored as byte array within DarkTortilla core processor. (Source: Secureworks)

To decode each byte, the core processor uses the following equation with <xor_key> as the hard-coded integer array [45, 89, 125, 69, 250, 222, 111] and <seed> as the hard-coded integer 99:

decoded_byte = encoded_byte ^ (<xor_key>[(idx * <seed>) % xor_key.Length])

The core processor loads RunPe6 and calls its ‘Runn’ function to execute the malicious payload within the context of the configured target subprocess. The core processor does not directly reference this function. Rather, it references the index values for the target class (18) and function (0). Figure 18 displays PowerShell code developed by CTU researchers to replicate the core processor’s target function identification logic.

Figure 18. Custom PowerShell script to identify RunPe6 function used for payload process injection. (Source: Secureworks)

Addon package processing

DarkTortilla can be configured with zero or more payloads known as addon packages. These addons are in addition to the main payload that DarkTortilla is tasked with delivering. Observed addons include benign decoy documents, legitimate executables, keyloggers, clipboard stealers, cryptocurrency miners, and additional DarkTortilla payloads. Each addon package possesses a set of configuration elements composed of a static “F” character, an integer “{0}” that represents the index value indicating the position of the addon in the package array, and a character representing a particular property associated with the package.

The %FilesNum% configuration element defines the number of addon packages to process. For example, if the %FilesNum% value is 3, the configuration elements are F.0.<addon property>, F.1.<addon property>, and F.2.<addon property>.

The F.{0}.D (data) configuration element contains the addon package payload binary data. The core processor checks the %Compress% configuration element to determine if the stored data is compressed. If the element is set to true, the core processor decompresses the data before processing it.

The core processor next determines if it should process the addon package by inspecting the initial loader’s installation state and the addon package’s F.{0}.R (run) value. Table 7 lists the criteria and their result.

Table 7. Criteria for processing addon package.

If configured to process the addon package, the core processor inspects the F.{0}.O (operation) configuration element value to determine how to execute its payload. This value can be any integer but is typically 0, 1, or 2. If the value is set to 0 or any value other than 1 or 2, the core processor saves the payload to disk but does not execute it. If the value is 1, the core processor saves the payload to disk and executes it. If the value is 2, the core processor executes the payload in memory via the same RunPE process injection technique and target process it uses for the main payload.

If the payload is saved to disk, the location is specified by the addon path (F.{0}.P), subfolder (F.{0}.F), and filename (F.{0}.N) configuration elements. The F.{0}.P integer value represents a CSIDL value associated with a special folder on the system. For example, the value 2 corresponds to the Windows Start Menu/Programs folder. The full path of an analyzed sample containing a F.{0}.P value of 2, an empty string for F.{0}.F, and a value of sertif.exe for F.{0}.N is “C:Users<username>AppDataRoamingMicrosoftWindowsStart MenuProgramssertif.exe”.

Main payload processing

After processing addon packages and installing the initial loader executable if appropriate, DarkTortilla processes its main payload. This main payload is typically a commodity information stealer or remote access trojan (RAT). DarkTortilla stores the binary data for the main payload in the %MainFile% configuration element. Processing this payload consists of two steps:

1. The core processor queries the %Compress% configuration element to determine if the binary data in the %MainFile% configuration element is compressed. If set to true, the core processor decompresses the data.
2. The core processor executes the main payload via RunPE process injection. Unlike the addon payloads, there is no option to save the main payload to the filesystem. Therefore, the main payload resides only in memory. The target process used for injection is the same as the addon packages and is defined by the %HostIndex% configuration element.

Anti-analysis controls

DarkTortilla core processor samples analyzed by CTU researchers were obfuscated using the ConfuserEx code obfuscator. In addition to the obfuscator altering namespace, class, function, and property names, CTU researchers identified multiple samples where it injected specially crafted code that did not affect execution but inhibited decompilation by tools such as dnSpy (see Figure 19). Bypassing this anti-analysis control requires removing the code that caused the decompiler to break, identifying another sample that does not implement this control, or piecing together analysis from multiple samples to understand the code.

Figure 19. Broken dnSpy decompilation of DarkTortilla core processor. (Source: Secureworks)

The core processor includes code that that detects profilers and debuggers, but these anti-analysis controls are not called. To detect profiling, the code verifies if the COR_ENABLE_PROFILING environment variable is present and sets to the value of 1. To detect debuggers, the code spawns a thread (see Figure 20) that continuously checks the Debugger.IsAttached property and the Debugger.IsLogging method. If the core processor identifies a debugger or if the thread performing the checks is terminated, the code terminates the initial loader process. It is unclear if this code was added by ConfuserEx or the malware author.

Figure 20. Debugger detection performed by DarkTortilla core processor. (Source: Secureworks)

The core processor implements string encoding to obscure important strings such as the configuration keys. Figure 21 shows a code excerpt that passes the string length (17), character index array ([26,8,13,18,19,0,11,11,0,19,8,14,13,17,4,6,26]), and capital letter index array ([8,17]) to the decode function.

Figure 21. DarkTortilla core processor string obfuscation example. (Source: Secureworks)

This function decodes the string by iterating through each value in the character index array and retrieving the corresponding character at the specified index in a hard-coded character array (see Figure 22).

Figure 22. Character array used by string decoding logic. (Source: Secureworks)

Figure 21 shows that the example’s first three values of the character index array passed to the decode function are 26, 8, and 13. These values correspond to the characters “%”, “i”, and “n” in the hard-coded character array shown in Figure 22. The values passed in the capital letter index array (8, 17) indicate which characters should be capitalized (“I” and “R” in this example). Processing the character index array results in the decoded string “%InstallationReg%”.

The %VM% configuration element enables DarkTortilla’s anti-virtual machine (anti-VM) controls. If set to true, the core processor obtains information about the system by querying the following Windows Management Instrumentation (WMI) objects:

The core processor also retrieves information about the system’s running processes and services. It then inspects this data for strings associated with Hyper-V, QEMU, Virtual PC, VirtualBox, and VMware. If any of the case-insensitive data matches the criteria in Table 8, the core processor terminates the initial loader process.

Table 8. DarkTortilla core processor anti-VM detections.

The %SB% configuration element enables DarkTortilla’s anti-sandbox control. This control only detects the Sandboxie sandbox. The core processor terminates the initial loader process if it detects a running process named “sandboxierpcss” in the current session.

Anti-tamper controls

DarkTortilla’s anti-tamper controls are the last step in its execution chain and occur after the main payload is executed. The four controls ensure that nothing interferes with DarkTortilla’s execution of its critical components.

1. The first anti-tamper control is employed by the core processor and ensures that the injected subprocess running the main payload is immediately rerun if terminated. The %InjectionPersist% configuration element regulates this control. If set to true, the core processor starts a thread that monitors the state of the injected subprocess. If the subprocess is terminated, this anti-tamper control automatically respawns the configured target subprocess, re-injects the main payload, and executes it within the context of the subprocess.

2. The second anti-tamper control ensures that the initial loader executable is immediately rerun if terminated. DarkTortilla implements this functionality with a secondary .NET-based executable that it refers to as “WatchDog”. The %InjectionPersist% configuration element regulates this control. If set to true, the core processor drops the WatchDog executable and its configuration file to the Windows %TEMP% directory. It then executes the WatchDog executable, which monitors the initial loader process.

   The WatchDog executable bytes are stored in the DarkTortilla %WatchDogBytes% configuration element, and the filename is stored in %WatchDogName%. Prior to processing, the core processor decompresses the WatchDog executable’s bytes if the %Compress% configuration element is set to true. Every WatchDog executable dropped by DarkTortilla was identical:

   • MD5 hash: 0e362e7005823d0bec3719b902ed6d62
   • SHA1 hash: 590d860b909804349e0cdc2f1662b37bd62f7463
   • SHA256 hash: 2d0dc6216f613ac7551a7e70a798c22aee8eb9819428b1357e2b8c73bef905ad

   If an executable with the configured WatchDog name already exists in the Windows %TEMP% directory, the core processor removes the existing executable’s Zone.Identifier Alternate Data Stream (ADS), which strips the executable of any existing URL security zones. It then overwrites the existing executable with the new WatchDog executable.

   The WatchDog configuration file dropped to the filesystem shares the same name as the WatchDog executable but uses a .txt file extension. For example, the configuration filename for “WatchDog.exe” is “WatchDog.txt”. This configuration file contains three lines representing the following values:

   • The process ID of the initial loader executable
   • The path and filename of the initial loader executable
   • The process ID for the WatchDog executable

   If the initial loader process terminates, the WatchDog process reruns it and refreshes the contents of the WatchDog configuration text file with the new process ID information.

3. The third anti-tamper control is employed by the core processor and ensures that the dropped WatchDog executable continues to execute. The core processor retrieves the WatchDog executable process ID from the WatchDog configuration file once per second and verifies that the corresponding process is running. If the WatchDog process terminates, the core processor breaks the loop, drops a new WatchDog configuration file, and reruns the WatchDog executable.

4. The fourth anti-tamper control is employed by the core processor and maintains persistence for the initial loader. The %StartupPersist% configuration element regulates this control. If set to true, the core processor starts a thread that sets persistence every 30 seconds using the persistence type defined in the DarkTortilla configuration. The control does not contain validation logic to check the persistence status, so it repeats the process indefinitely.

Delayed execution

The core processor implements the kernel32.dll Sleep function to delay execution at the following stages of the process. The length of delay is typically controlled by the value in the %Delay% configuration element. CTU researchers observed values ranging from 0 seconds to 300 seconds.

• Prior to implementing persistence, the core processor sleeps for the number of seconds specified by the %Delay% configuration element.
• Prior to processing addon packages, the core processor sleeps for the number of seconds specified by the %Delay% configuration element.
• The core processor sleeps for a hard-coded 5 seconds after copying the source executable to the install directory but before running the executable.

The number of delays increases if the %Melt% and %Installation% configuration elements are set to true, as the delays are processed each time the executable migrates. These delays can impede detection in sandbox environments if they exceed the maximum wait time.

Possible malware connections

DarkTortilla code shares similarities to other malware. For example, payload compression, junk code inclusion, and payload execution via RunPe6 are also features of a RATs Crew crypter last updated in 2016. DarkTortilla could represent an evolution of that crypter. Additionally, the Gameloader malware uses similar malspam lures and archive files as DarkTortilla. It also leverages .NET resources to store encoded DLLs and encrypted bitmap images and delivers similar commodity malware payloads. However, there is insufficient evidence as of this publication to definitively link these malware families or threat actors to DarkTortilla.

Conclusion

Researchers often overlook DarkTortilla and focus on its main payload. However, DarkTortilla is capable of evading detection, is highly configurable, and delivers a wide range of popular and effective malware. Its capabilities and prevalence make it a formidable threat.

Threat indicators

The threat indicators in Table 9 can be used to detect activity related to DarkTortilla. The URL may contain malicious content, so consider the risks before opening it in a browser.

Table 9. Indicators for this threat.

References

Arntz, Pieter. “Explained: Packer, Crypter, and Protector.” Malwarebytes Labs. March 27, 2017. https://blog.malwarebytes.com/cybercrime/malware/2017/03/explained-packer-crypter-and-protector/

Hasherezade. “Rainbows, Steganography and Malware in a new .NET cryptor.” Malwarebytes Labs. March 30, 2016. https://blog.malwarebytes.com/threat-analysis/2015/08/rainbows-steganography-and-malware-in-a-new-net-cryptor/

“RATs Crew.” Hack Forums. June 21, 2021. https://wiki.hackforums.net/RATs_Crew

GoSecure Titan Labs. “New Malware ‘Gameloader’ in Discord Malspam Campaign.” GoSecure. November 2, 2021. https://www.gosecure.net/blog/2021/11/02/new-malware-gameloader-in-discord-malspam-campaign-identified-by-gosecure-titan-labs/

The post DarkTortilla Malware Analysis appeared first on Online Pitstop.

Since at least 2015, threat actors have used HUI Loader to load remote access trojans (RATs) on compromised hosts. Secureworks® Counter Threat Unit (CTU) researchers link two HUI Loader activity clusters exclusively to China-based threat groups. The BRONZE RIVERSIDE threat group is likely responsible for one cluster, which focuses on stealing intellectual property from Japanese organizations. The other cluster involves deployment of LockFile, AtomSilo, Rook, Night Sky, and Pandora post-intrusion ransomware. CTU researchers attribute this activity to the Chinese BRONZE STARLIGHT threat group.

The victimology, short lifespan of each ransomware family, and access to malware used by government-sponsored threat groups suggest that BRONZE STARLIGHT’s main motivation may be intellectual property theft or cyberespionage rather than financial gain. The ransomware could distract incident responders from identifying the threat actors’ true intent and reduce the likelihood of attributing the malicious activity to a government-sponsored Chinese threat group.

HUI Loader overview

HUI Loader is a custom DLL loader whose name is derived from a string in the loader (see Figure 1). The malware is loaded by legitimate programs that are vulnerable to DLL search order hijacking. HUI Loader decrypts and loads a third file containing an encrypted payload that is also deployed to the compromised host. CTU researchers have observed HUI Loader loading RATs such as SodaMaster, PlugX, Cobalt Strike, and QuasarRAT.

Figure 1. String that starts with ‘HUI’ in HUI Loader samples. (Source: Secureworks)

Since early 2021, CTU researchers observed threat actors deploying HUI Loader in a cluster of activity associated with intellectual property theft. This A41APT campaign primarily targets Japanese organizations and uses HUI Loader to load the SodaMaster RAT. The victimology and tactics, techniques, and procedures (TTPs) in this campaign align with BRONZE RIVERSIDE activity. In mid-2021, CTU researchers began tracking a second cluster of activity that uses HUI Loader to load Cobalt Strike Beacon and deploy ransomware. CTU researchers attribute this second cluster of activity to the BRONZE STARLIGHT threat group. Figure 2 compares the clusters linked to HUI Loader.

Figure 2. Diamond model comparing HUI Loader clusters. (Source: Secureworks)

HUI Loader-linked ransomware activity

HUI Loader samples that load Cobalt Strike Beacon have been linked to LockFile, AtomSilo, Rook, Night Sky, and Pandora ransomware activity (see Table 1).

Table 1. HUI Loader and Cobalt Strike Beacon samples linked to ransomware activity.

In March 2022, CTU researchers analyzed an updated version of HUI Loader that uses the RC4 cipher to decrypt the payload. The malware sample also attempts to circumvent host-based detection and protection measures by disabling Windows Event Tracing for Windows (ETW), disabling Antimalware Scan Interface (AMSI) functions, and hooking Windows API calls (see Figure 3). CTU researchers identified code overlap between the updated HUI Loader samples and the Pandora ransomware.

Figure 3. Updated HUI Loader code that disables ETW. (Source: Secureworks)

Ransomware C2 infrastructure

Analysis of the Cobalt Strike Beacon samples loaded by HUI Loader revealed a link between AtomSilo, Night Sky, and Pandora ransomware. The Cobalt Strike Beacons were configured with an uncommon HTTP POST URI beginning with /rest/2/meetings and a watermark value of 0 (see Figure 4). As of this publication, CTU researchers have only observed this configuration in Cobalt Strike Beacons associated with these ransomware families.

Figure 4. Cobalt Strike payload configuration information. (Source: Secureworks)

The configuration of these Cobalt Strike payloads is likely based on a modified version of a public C2 malleable profile that configures the HTTP GET request URI as ‘/functionalstatus’ and the HTTP POST URI as ‘/rest/2/meetings’. Table 2 compares the three Cobalt Strike Beacons.

Table 2. Cobalt Strike Beacon sample configuration information linked to ransomware activity.

In a January 2022 Secureworks incident response (IR) engagement, CTU researchers observed a threat actor compromising a ManageEngine ADSelfService Plus server. The threat actor exploited an authentication bypass vulnerability (CVE-2021-40539) and deployed a Meterpreter reverse shell that communicated with a C2 IP address (172 . 105 . 229 . 30). They then deployed three files to the compromised host: a legitimate Microsoft Defender executable vulnerable to DLL search order hijacking, a HUI Loader sample (mpclient.dll) that is loaded by the executable, and an encrypted Cobalt Strike Beacon (dlp.ini). CTU researchers did not observe follow-on activity.

The C2 server also hosted a legitimate VMware executable (VMwareXferlogs.exe) vulnerable to DLL search order hijacking. This executable loads a DLL (glib-2.0.dll) from the same directory. CTU researchers were unable to obtain glib-2.0.dll from this C2 server but identified other glib-2.0.dll HUI Loader samples that could be sideloaded by VMwareXferlogs.exe. An April 2022 third-party report links glib-2.0.dll HUI Loader samples that load Cobalt Strike to LockBit ransomware. However, there is not enough evidence in the report for CTU researchers to validate this claim.

The VirusTotal analysis service revealed URLs indicating the presence of glib-2.0.dll files on two servers (45 . 32 . 101 . 191 and 45 . 61 . 139 . 38). Passive DNS data shows that 45 . 61 . 139 . 38 hosted sc . microsofts . net, which is a C2 domain that third-party reporting links to LockFile ransomware activity. The 45 . 32 . 101 . 191 IP address hosted api . openssl-digicert. xyz, which has sibling domain (peek . openssl-digicert . xyz) that is linked to Pandora ransomware.

While CTU researchers do not have access to these servers, timeline analysis suggests that two HUI Loader samples uploaded to VirusTotal may have been hosted on these servers. Both samples have compile timestamps that are the close to the ‘URL first seen’ timestamp listed on VirusTotal (see Table 3). Although threat actors can trivially modify compile timestamps, the timeframe of the associated intrusion activity makes it unlikely that these timestamps were altered. The two HUI Loader samples that were possibly hosted on these servers share code with the Pandora ransomware.

Table 3. HUI Loader samples likely hosted on servers linked to ransomware activity.

Ransomware TTPs and code overlap

CTU analysis indicates that the five ransomware families linked to HUI Loader were developed from two distinct codebases: one for LockFile and AtomSilo, and the other for Rook, Night Sky, and Pandora. Based on the order in which these ransomware families appeared starting in mid-2021, the threat actors likely first developed LockFile and AtomSilo and then developed Rook, Night Sky, and Pandora.

Third-party researchers leveraged code overlap between LockFile and AtomSilo to release a decryptor for files encrypted with these ransomware families in October 2021. Other third-party reporting describes TTP overlap in LockFile and AtomSilo intrusion activity. The overlap includes identical filenames for the ransomware executable and components of the Kernel Driver Utility.

Table 4 lists feature similarities across Rook, Night Sky, and Pandora. These ransomware families appear to leverage the Babuk ransomware source code. The Babuk source code was reportedly leaked in September 2021, a few months before Rook operations began in December 2021.

Table 4. Similarities across Rook, Night Sky, and Pandora ransomware.

The use of HUI Loader to load Cobalt Strike Beacon, the Cobalt Strike Beacon configuration information, the C2 infrastructure, and the code overlap suggest that the same threat group is associated with these five ransomware families. It is likely that BRONZE STARLIGHT is responsible for LockFile, AtomSilo, Rook, Night Sky, and Pandora intrusion activity.

Connections to China

As of this publication, CTU researchers have not linked HUI Loader to publicly available code and have only observed HUI Loader usage in the A41APT campaign linked to BRONZE RIVERSIDE and the post-intrusion ransomware activity linked to BRONZE STARLIGHT. BRONZE RIVERSIDE (also known as APT10) is associated with the Chinese Ministry of State Security (MSS). A third-party report attributes LockFile, AtomSilo, Rook, and Night Sky ransomware activity to a Chinese threat group it calls DEV-0401. The discovery of links to PlugX and Chinese-language resources associated with the ransomware activity further support the likelihood that BRONZE STARLIGHT is based in China.

CTU analysis revealed four HUI Loader samples that decrypt and load PlugX RAT payloads. PlugX is used by multiple Chinese threat groups. One of the HUI Loader-linked PlugX samples communicates with hr . indiabullamc . com, which is a sibling domain of a BRONZE STARLIGHT Cobalt Strike C2 domain (servers . indiabullamc . com). This Cobalt Strike Beacon sends HTTP GET requests to /static/js/siteanalyze_2392.js (see Figure 5). CTU researchers identified four additional Cobalt Strike Beacons that send HTTP GET requests to the same URI. One of these Cobalt Strike Beacons communicates with cs . microsofts . net, which is a sibling of a Cobalt Strike C2 domain (sc . microsofts . net) used by LockFile.

Figure 5. Configuration information for Cobalt Strike Beacon linked to PlugX sample. (Source: Secureworks)

The indiabullamc . com domain likely masquerades as the legitimate website for an India-based company. A ransomware note uploaded to VirusTotal suggests that a company with a similar name was a LockFile victim in July 2021. Analysis of the indiabullamc . com PlugX payload revealed that it replaces the MZ signature in the MS-DOS header and the portable executable (PE) signature in the PE header with ‘XV’. This PlugX variant uses the hard-coded value 0x20140307 to generate a key to XOR-decrypt the PlugX configuration information (see Figure 6).

Figure 6. Analysis of PlugX sample linked to LockFile ransomware activity. (Source: Secureworks)

PlugX ‘XV’ samples can be grouped into sub-versions based on the hard-coded value in the decryption routine. One of the other PlugX payloads loaded by HUI Loader was uploaded to VirusTotal in 2017 and was not the same sub-version as the indiabullamc . com payload. The remaining two samples were the same sub-version as the indiabullamc . com payload and were observed in attacks targeting Southeast Asian organizations in April 2019. CTU researchers are unable to corroborate the BRONZE RIVERSIDE attribution based on the information in the report, but the TTPs align with Chinese threat group activity.

PlugX source code has allegedly been leaked online. However, it is unclear which variant was leaked and if it has been used by threat groups outside of China. It is unlikely that the indiabullamc .com PlugX sub-version is used widely across distinct threat groups or even across multiple Chinese threat groups. The links connecting LockFile ransomware activity, HUI Loader, and a specific PlugX sub-version associated with Chinese threat group activity suggest that the threat group responsible for the HUI Loader-linked ransomware activity has access to malware developed by Chinese government-sponsored threat groups.

During an October 2021 Secureworks incident response engagement, CTU researchers observed likely ransomware precursor activity that overlapped with third-party reporting of LockFile activity. The engagement revealed that the threat actors exploited the ProxyShell vulnerabilities in a Microsoft Exchange server to deploy a web shell. They then ran a PowerShell wget command to download an unidentified file from a server at IP address 45 . 91 . 83 . 176, which the third-party report links to LockFile activity. This server with this IP address reportedly used a Chinese-language configuration during the LockFile ransomware campaign. Although CTU researchers cannot corroborate this claim, VirusTotal reported that the server returned a web page displaying an error message in Chinese.

CTU researchers identified additional artifacts that indicate attribution to a Chinese-speaking threat group. The inclusion of uncommon Subject DN and Issuer DN fields in an SSL certificate associated with Pandora ransomware C2 infrastructure suggest it was likely generated following instructions on a Chinese-language blog for setting up Cobalt Strike SSL certificates. CTU researchers also detected a Chinese character font in a ransom note dropped by Night Sky ransomware (see Figure 7).

Figure 7. Reference to a Chinese font family in a Night Sky ransom note. (Source: Secureworks)

Links between BRONZE STARLIGHT and BRONZE UNIVERSITY

A January 2022 Secureworks incident response engagement revealed that BRONZE STARLIGHT compromised a server running ManageEngine ADSelfService Plus and deployed HUI Loader with a Cobalt Strike Beacon. CTU researchers observed the Chinese BRONZE UNIVERSITY threat group active on the same network with overlapping timeframes. Around mid-November 2021, BRONZE UNIVERSITY compromised this server to deploy ShadowPad malware and stayed active on the network until January 2022. In addition to deploying ShadowPad, BRONZE UNIVERSITY harvested credentials, moved laterally within the network, and compressed sensitive data for exfiltration. The intrusion activity attributed to BRONZE STARLIGHT began in late November 2021 and ended in early December 2021.

CTU researchers did not observe additional BRONZE STARLIGHT activity after the threat actors deployed and executed HUI Loader to load a Cobalt Strike Beacon. It is unclear why BRONZE STARLIGHT suspended its intrusion activity. The simultaneous and continued operations by another Chinese threat group on the same network suggests that the two groups may have deconflicted their post-intrusion activity. This scenario assumes collaboration and knowledge sharing between the groups. It could indicate that BRONZE STARLIGHT participates in government-sponsored intelligence-gathering efforts rather than being a purely financially motivated threat group.

Targeting and victimology

The operational cadence and victimology of LockFile, AtomSilo, Rook, Night Sky, and Pandora deployments do not align with conventional financially motivated cybercrime operations. In each case, the ransomware targets a small number of victims over a relatively brief period of time before it ceases operations, apparently permanently (see Figure 8). The number of victims is unclear, as leak sites often do not list victims who pay ransoms early.

Figure 8. Timeline of ransomware activity and number of victims listed on each ransomware leak site. (Source: Secureworks)

Cybercrime groups sometimes rebrand their ransomware, often in response to law enforcement or government actions. For example, the GOLD WATERFALL threat group rebranded its Darkside ransomware to BlackMatter likely as a result of law enforcement scrutiny following the Colonial Pipeline attack. Similarly, GOLD DRAKE made several changes to its Hades ransomware to hinder attribution and enable victims to circumvent payment sanctions imposed by the U.S. Treasury Department. Due to the overhead associated with retooling and the impact on revenue, cybercriminals tend to only make these adjustments when they are necessary for continued operations. These pressures typically do not apply to the BRONZE STARLIGHT ransomware families. While the release of an AtomSilo and LockFile decryptor may have prompted the group to create a ransomware family based on Babuk’s source code, the decision to limit the ransomware use to brief, targeted deployments is likely to prevent security researchers from clustering activity and identifying trends. The rapid changes in the ransomware landscape make it unlikely that researchers will investigate obsolete ransomware.

BRONZE STARLIGHT operated LockFile as a traditional ransomware scheme but adopted the name-and-shame model for the other ransomware operations. It is possible that the change provided a more plausible means of exfiltrating data. The threat actors may also have decided that the public profile would be more effective as a distraction from their true operational objectives. Pandora is the only ransomware with a leak site as of April 14, 2022, listing five victims. Two earlier victims were removed. Descriptions of each company include anonfiles . com links to ZIP files containing allegedly stolen data.

As of mid-April, a total of 21 victims had been listed across the AtomSilo, Rook, Night Sky, and Pandora leak sites. CTU researchers estimate that approximately 75% would be of interest to Chinese government-sponsored groups focused on espionage based on the victims’ geographic locations and industry verticals. The victims include pharmaceutical companies in Brazil and the U.S., a U.S.-based media organization with offices in China and Hong Kong, electronic component designers and manufacturers in Lithuania and Japan, a law firm in the U.S., and an aerospace and defense division of an Indian conglomerate. The five victims that were not likely targeted for espionage include two real estate companies in the Americas, two small financial institutions in the U.S., and a small interior design company in Europe. One victim of Rook ransomware was a bank in Kazakhstan, which strongly suggests that the threat actors are not based in the Commonwealth of Independent States (CIS). There is an unspoken universal agreement among Russian-speaking ransomware groups not to target entities in those jurisdictions.

The number and nature of LockFile victims is unclear. Third-party reporting suggests that victims represented verticals such as manufacturing, financial services, legal, and engineering, and that most were located in the U.S. and Asia. CTU researchers identified two victims that are consistent with the targeting of a Chinese government-sponsored espionage-focused threat group: a financial services organization in India and a local government entity in the U.S.

Victimology does not provide conclusive attribution. Chinese government-sponsored threat groups have broad targeting, so any ransomware operation could include victims of potential Chinese interest. Conversely, Chinese government-sponsored groups using ransomware as a distraction would likely make the activity resemble financially motivated ransomware deployments. However, the combination of victimology and the overlap with infrastructure and tooling associated with government-sponsored threat group activity indicate that BRONZE STARLIGHT may deploy ransomware to hide its cyberespionage activity. While Chinese government-sponsored groups have not historically used ransomware, there is precedent in other countries. For example, North Korea deployed WCry (also known as WannaCry) for financial gain, the Russian IRON VIKING threat group used NotPetya for its destructive capabilities, and the Iranian COBALT FOXGLOVE threat group used Pay2Key and N3tw0rm ransomware as a destructive wiper against entities in Israel.

BRONZE STARLIGHT likely uses ransomware in these incidents to achieve the following tactical objectives:

• Destroy evidence: Encrypting data destroys forensic evidence of espionage activities, making it much more challenging for victims to properly assess the threat and protect themselves.
• Distract investigators: Ransomware can significantly impact a compromised organization and can consume all incident response efforts. Pressure to return to normal business operations could prevent victims from detecting suspicious activity that does not directly relate to the ransomware.
• Exfiltrate data: Name-and-shame ransomware exfiltrates data, with an emphasis on proprietary or sensitive information. As this data is also targeted in espionage operations, the ransomware operation could mask the threat actors’ motivation.

Conclusion

BRONZE STARLIGHT compromises networks by exploiting vulnerabilities in network perimeter devices, including known vulnerabilities for which patches are available. The threat actors deploy HUI Loader to decrypt and execute a Cobalt Strike Beacon for command and control. They then deploy ransomware and exfiltrate sensitive data from the victim’s environment.

Both the exploitation of known vulnerabilities and the use of the Cobalt Strike for command and control provide opportunities to detect and prevent BRONZE STARLIGHT intrusion activity before exfiltration or ransomware deployment. Network defenders should implement a robust patch management process to address network perimeter vulnerabilities in a timely manner. However, breaches can occur even with preventative measures in place. Reactive measures such as a robust and tested incident response plan, real-time network monitoring and alerting, and an extended detection and response (XDR) solution are crucial for minimizing the impact of ransomware and other malicious activity.

Threat indicators

The threat indicators in Table 7 can be used to detect activity related to BRONZE STARLIGHT. Note that IP addresses can be reallocated. The domains and IP addresses may contain malicious content, so consider the risks before opening them in a browser.

Table 5. Indicators for this threat.

References

Abrams, Lawrence. “Babuk ransomware’s full source code leaked on hacker forum.” Bleeping Computer. September 3, 2021. https://www.bleepingcomputer.com/news/security/babuk-ransomwares-full-source-code-leaked-on-hacker-forum/

Avast. “Avast releases decryptor for Atom Silo and LockFile ransomware.” October 27, 2021. https://decoded.avast.io/threatintel/decryptor-for-atomsilo-and-lockfile-ransomware/

Gallagher, Sean and Singh, Vikas. “Atom Silo ransomware actors use Confluence exploit, DLL side-load for stealthy attack.” SOPHOS Labs. October 4, 2021. https://news.sophos.com/en-us/2021/10/04/atom-silo-ransomware-actors-use-confluence-exploit-dll-side-load-for-stealthy-attack/

Gatlan, Sergiu. “Free decryptor released for Atom Silo and LockFile ransomware.” Bleeping Computer. October 27, 2021. https://www.bleepingcomputer.com/news/security/free-decryptor-released-for-atom-silo-and-lockfile-ransomware/

Hunter, Ben. “Uncovering New Activity By APT10.” Fortinet. October 15, 2019. https://www.fortinet.com/blog/threat-research/uncovering-new-activity-by-apt-

Jie, Ji. “Insights into Ransomware Spread Using Exchange 1-Day Vulnerabilities 1-2.” NSFOCUS. September 26, 2021. https://nsfocusglobal.com/insights-into-ransomware-spread-using-exchange-1-day-vulnerabilities-1-2/

Kersten, Max and Elias, Marc. “PlugX: A Talisman to Behold.” March 28, 2022. https://www.trellix.com/en-us/about/newsroom/stories/threat-labs/plugx-a-talisman-to-behold.html

Microsoft Threat Intelligence Center (MSTIC). “Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability.” December 11, 2021. https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

S2W Talon. “Atomsilo x Lockfile: Atomsilo copied BlackMatter and Cerber for operating the double extortion site.” September 24, 2021. https://medium.com/s2wblog/atomsilo-x-lockfile-atomsilo-copied-blackmatter-and-cerber-for-operating-the-double-extortion-site-7fb5aaac5f21

Symantec. “LockFile: Ransomware Uses PetitPotam Exploit to Compromise Windows Domain Controllers.” August 20, 2021. https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/lockfile-ransomware-new-petitpotam-windows

Tsai, Orange. “From Pwn2Own 2021: A New Attack Surface on Microsoft Exchange – ProxyShell!” August 18, 2021. https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell

United States Department of Justice. “Two Chinese Hackers Associated With the Ministry of State Security Charged with Global Computer Intrusion Campaigns Targeting Intellectual Property and Confidential Business Information.” December 20, 2018. https://www.justice.gov/opa/pr/two-chinese-hackers-associated-ministry-state-security-charged-global-computer-intrusion

Wosar, Fabian (@fwosar). “BlackMatter decryptor characteristics indicate a Darkside rebrand.” Twitter. July 31, 2021, 12:15 pm. https://twitter.com/fwosar/status/1421504819890634754

Yanagishita, Hajime, et al. “What We Can Do against the Chaotic A41APT Campaign.” Japan Security Analyst Conference 2022. January 27, 2022. http://jsac.jpcert.or.jp/archive/2022/pdf/JSAC2022_9_yanagishita-tamada-nakatsuru-ishimaru_en.pdf

The post BRONZE STARLIGHT Ransomware Operations Use HUI Loader appeared first on Online Pitstop.

Microsoft Azure Active Directory (Azure AD) is an identity and access management solution used by over 88 percent of Fortune 500 companies as of this publication. This market penetration makes Azure AD a lucrative target for threat actors. In the second half of 2021, Secureworks® Counter Threat Unit (CTU) researchers analyzed Azure AD tenants and were able to extract open-source intelligence (OSINT) about organizations. Threat actors frequently use OSINT to perform reconnaissance. CTU researchers identified several application programming interfaces (APIs) that access internal information of any organization that uses Azure AD. Collected details included licensing information, mailbox information, and directory synchronization status.

CTU researchers shared their findings with Microsoft, and all but two of the issues have been mitigated as of this publication. Microsoft applied the updates automatically to all Azure AD tenants, so there are no actions required for Azure AD administrators. Microsoft classified the unmitigated issues as “by-design.” The first issue allows anyone to query the directory synchronization status. In some scenarios, Azure AD reveals the name of the high-privileged account used for synchronization. The second issue could reveal internal information about the target Azure AD tenant, including the technical contact’s full name and phone number. The technical contact usually holds Azure AD Global Administrator privileges.

OSINT details in Azure AD

Tools such as AADInternals gather OSINT from Azure AD using unauthenticated APIs. This OSINT includes the target tenant’s registered domains and types, tenant name and ID, and seamless single sign-on status (also known as DesktopSSO). Figure 1 lists Invoke-AADIntReconAsOutsider command output that contains OSINT information about the organization.

Figure 1. Invoke-AADIntReconAsOutsider output listing OSINT from unauthenticated APIs. (Source: Secureworks)

In addition to the unauthenticated APIs, there are authenticated APIs that can only be used after logging into an Azure AD tenant. Figure 2 lists the information that any user can access from their own tenant. Administrator privileges are not required. CTU researchers discovered authenticated APIs that could access information about any tenant, not just the authenticated user’s tenant.

Figure 2. Invoke-AADIntReconAsInsider output listing data from authenticated APIs. (Source: Secureworks)

Diagnostics API

Microsoft uses the undocumented Diagnostics API with the Support and Recovery Assistant (SaRA) tool to help the logged-in user diagnose and solve problems when accessing Microsoft cloud services. In 2019, CTU researchers observed SaRA using an analysis API endpoint. The traffic between the SaRA client and the analysis endpoint used the process in Figure 3.

Figure 3. Diagnostics API analysis endpoint process. (Source: Secureworks)

1. A user opens SaRA, enters symptoms, and starts the diagnostic.
2. SaRA makes an initial HTTP POST request to the analysis endpoint (see Figure 4). The request contains an AnalyzerId and DiagnosisInfo.

   
   Figure 4. Diagnostics API analysis endpoint initial request. (Source: Secureworks)

3. The response returns the SessionId to SaRA.
4. The Diagnostics API backend starts the analyzer to explore the defined user’s tenant and mailbox.
5. SaRA uses an HTTP GET request and the SessionId to poll the analysis status (see Figure 5).

   
   Figure 5. Diagnostics API analysis endpoint poll request. (Source: Secureworks)

6. The Diagnostics API returns analysis results to SaRA.
7. SaRA displays the results to the user.

The AnalyzerId represents an analyzer containing the diagnostic instructions that SaRA tasks the Diagnostics API to perform on the user’s behalf. The SaRA client source code contains a list of analyzers (see Figure 6).

Figure 6. Sample of SaRA analyzer IDs and names from the analyzer list in the source code. (Source: Secureworks)

CTU researchers identified the cloud-related analyzers from this list (see Table 1).

Table 1. Cloud-related Diagnosis API analysis endpoint analyzers.

The SaRA client uses the DiagnosisInfo structure to pass parameters to analyzers. Figure 7 lists the parameters used by each of the cloud-related analyzers.

Figure 7. DiagnosisInfo content for each cloud-related analyzer. (Source: Secureworks)

The results contain user information, including full licensing information, Office versions enabled in the tenant, the organization’s Exchange hybrid configuration and external relationships, user mailbox information, and Messaging Application Programming Interface (MAPI) status (see Figure 8).

Figure 8. Information returned by Diagnostics API analysis endpoint. (Source: Secureworks)

The SaRA client extracts the logged-in user’s email address from their OAuth token (see Figure 9) and uses that as the target SmtpAddress in the DiagnosisInfo parameter.

Figure 9. OAuth token for Diagnostics API. (Source: Secureworks)

The Diagnostics API does not validate whether the SmtpAddress matches the logged-in user. It is possible to retrieve information for any user from any tenant by replacing the SmtpAddress with the email address of the target user. If the target user does not exist but the domain is correct, the API returns all tenant-related information. This information is valuable to threat actors. For instance, the licensing information shows which protective components the target tenant could be using. Moreover, the organizational relationships identify additional individuals that could be targeted in phishing attacks to gain access to a tenant.

CTU researchers reported this vulnerability to Microsoft on September 7, 2021. On September 22, Microsoft responded that the issue was resolved. CTU researchers confirmed that the resolution included two modifications:

• Denies access to other users’ information (see Figure 10).
  
  Figure 10. ‘You don’t have access to given user’ response. (Source: Secureworks
• Invalidates all AnalyzerIDs, making the analysis endpoint obsolete (see Figure 11).
  
  Figure 11. ‘Unknown analyzer id’ response. (Source: Secureworks)

In 2021, CTU analysis of SaRA version 17.0.7.7119.4 revealed the client using the cloudcheck endpoint instead of the analysis endpoint. Figure 12 depicts the cloudcheck endpoint process.

Figure 12. Diagnostics API cloudcheck endpoint process. (Source: Secureworks)

1. A user opens SaRA, enters symptoms, and starts the diagnostic.
2. SaRA makes an initial HTTP POST request to the cloudcheck endpoint (see Figure 13).

   
   Figure 13. Diagnostics API cloudcheck endpoint initial request. (Source: Secureworks)

   The request contains the Symptom and Parameters details (see Figure 14) the user entered in Step 1.
   
   Figure 14. Information sent to cloudcheck endpoint. (Source: Secureworks)

3. The response returns the RequestId to SaRA (see Figure 15).

   
   Figure 15. Diagnostics API initial response. (Source: Secureworks)

4. The diagnosis API backend starts the diagnostics to explore the defined user’s tenant and mailbox.
5. SaRA uses an HTTP GET request and the RequestId to poll the analysis status (see Figure 16).

   
   Figure 16. Diagnostics API v1 poll request. (Source: Secureworks)

6. The cloudcheck endpoint returns diagnostic results to SaRA.
7. SaRA displays the results to the user.

The SaRA client revealed the following symptoms that could retrieve similar diagnostic information as the analysis endpoint:

• CasMailbox
• DirSyncCheck
• ExchangeHybridTenant
• GetUserDiagnostic
• TenantUserInfo

Figure 17 lists the parameters used by the DirSyncCheck symptom.

Figure 17. Parameter values for DirSyncCheck request. (Source: Secureworks)

Like the analysis endpoint, the UserUpn and UserSMTPEmail attributes in the initial request were the same as the user principal name of the bearer token used to access the API. As with the analysis endpoint, it was possible to retrieve information for other users and tenants by replacing the values with the email address of the target user. After Microsoft addressed the analysis endpoint issue, the logged-in user could only retrieve CasMailBox information for users of the same tenant. However, all other information could still be requested from any tenant.

CTU researchers reported this vulnerability to Microsoft on September 23, 2021. On December 2, 2021, Microsoft applied an update. CTU researchers confirmed that everything except the directory synchronization status issue was addressed. On January 28, 2022, Microsoft closed the issue as fixed, leaving the synchronization status intact.

Table 2 lists the directory synchronization status values. While all status information is important for threat actors, the password expiration message is the most valuable as it reveals the account name used for synchronization. This account has high privileges in the target tenant. It can be used to create, edit, and delete users in all tenants, and to reset users’ passwords in some tenants. By default, the synchronization account’s password is generated during the configuration and is not set to expire. For security purposes, some organizations configure the password to expire in their tenants, which could expose the account name. The password expiration reminder can be configured to be sent 1 to 30 days prior to the expiration date.

Table 2. Directory synchronization status messages.

Organization information

Azure AD collects information when a representative from an organization signs up for a new Microsoft 365 or Azure AD environment or tenant. The form collects the full name and phone number of this representative (see Figure 18), and that person becomes the technical contact of the tenant.

Figure 18. Office 365 signup form. (Source: Secureworks)

After signing up, this technical contact can edit their contact details in the Microsoft 365 admin center (see Figure 19). The company name and phone number are pre-populated from the original signup form.

Figure 19. Organization information in the admin center. (Source: Secureworks)

Microsoft business partners offer services to customer organizations that use Microsoft cloud services such as Microsoft 365 and Azure AD. Azure AD administrators in customer organizations can authorize these partners to access their tenants, which creates a partner relationship in the customer’s tenant. These partner relationships can only be accessed via the Microsoft 365 admin center. Only administrators have access to the admin center.

CTU researchers discovered an API (see Figure 20) used by the admin center to retrieve details regarding the partner’s organization. Although the API is exclusively used by the admin center, it does not require administrative permissions to be accessed. The API requires the partner’s tenant ID as an input.

Figure 20. Admin API request for partner details. (Source: Secureworks)

The response (see Figure 21) contains contact data from the organization information and signup form. After the initial signup, the first and last name can only be changed by Microsoft. Those fields cannot be viewed or modified in the admin center.

Figure 21. Partner information returned by admin API. (Source: Secureworks)

CTU researchers verified that this API could retrieve this information for any tenant, regardless of their partner status. CTU researchers reported this vulnerability to Microsoft on December 14, 2021. On January 12, 2022, Microsoft stated that “this information is expected to be shown” and did not mitigate the issue.

Conclusion

A threat actor can gather a significant amount of OSINT from an Azure AD tenant. Microsoft addressed all but two of the issues CTU researchers identified:

• The tenant’s synchronization status can reveal if the synchronization is configured, if is it operational, the time of the last synchronization, and the synchronization account’s name. Attackers can use this information for social engineering (leveraging the synchronization error data) and targeted brute-force attacks (using the account name).
• The organization information could expose the name and phone number of the tenant’s Global Administrator. This information can be abused for social engineering, spearphishing, and targeted brute-force attacks.

CTU researchers recommend the following actions to protect tenants from OSINT abuse:

• Organizations should ensure that their directory synchronization can perform the synchronization within the defined timeframes to avoid exposing details in error messages. Administrators receive an email if synchronization has not been successful in more than 24 hours, but the error message is displayed after three hours of inactivity.
• Organizations that implement an expiration for a directory synchronization account password should reset the password before Azure AD displays the expiration reminder to prevent exposure of the directory synchronization account name.
• Organizations should change the details associated with their tenant to general labels (e.g., “IT Department”) rather than personally identifiable data. Using a generic term prevents exposing the name of the potential Global Administrator account. An organization can modify some fields (e.g., phone number), but must create a support request in the Azure portal to change the first and last name of the technical contact.

The post Azure Active Directory Exposes Internal Information appeared first on Online Pitstop.

The ShadowPad advanced modular remote access trojan (RAT) has been deployed by the Chinese government-sponsored BRONZE ATLAS threat group since at least 2017. A growing list of other Chinese threat groups have deployed it globally since 2019 in attacks against organizations in various industry verticals. Secureworks® Counter Threat Unit (CTU) analysis of ShadowPad samples revealed clusters of activity linked to threat groups affiliated with the Chinese Ministry of State Security (MSS) civilian intelligence agency and the People’s Liberation Army (PLA).

Some clusters that target China’s ‘near abroad’ appear to be linked to PLA theater commands. These theater commands were introduced in the PLA reforms announced in 2015. Evidence of infrastructure and malware crossover among threat groups likely operating within the same theater command suggests that PLA reforms could be facilitating collaboration among these groups.

ShadowPad is decrypted in memory using a custom decryption algorithm. CTU researchers have identified multiple ShadowPad versions based on these distinct algorithms. ShadowPad extracts information about the host, executes commands, interacts with the file system and registry, and deploys new modules to extend functionality. CTU researchers discovered that ShadowPad payloads are deployed to a host either encrypted within a DLL loader or within a separate file alongside a DLL loader. These DLL loaders decrypt and execute ShadowPad in memory after being sideloaded by a legitimate executable vulnerable to DLL search order hijacking.

ShadowPad DLL loader execution

The majority of ShadowPad samples analyzed by CTU researchers were two-file execution chains: an encrypted ShadowPad payload embedded in a DLL loader. ShadowPad DLL loaders are sideloaded by a legitimate executable vulnerable to DLL search order hijacking. The DLL loader then decrypts and executes the embedded ShadowPad payload in memory using a custom decryption algorithm specific to the malware version. Table 1 lists legitimate executable and malicious DLL pairs that CTU researchers observed in analyzed samples.

Table 1. Legitimate executable and DLL loader filenames used to load ShadowPad.

CTU researchers identified ShadowPad execution chains involving a third file that contains the encrypted ShadowPad payload. These chains execute the legitimate executable (usually renamed), sideload the ShadowPad DLL loader, and load and decrypt the third file. CTU researchers observed threat actors using BDReinit.exe or Oleview.exe as initial files in the three-file ShadowPad execution chain. The third file in the BDReinit.exe execution chain is log.dll.dat; in the Oleview.exe execution chain, it is iviewers.dll.dat. CTU researchers have attributed campaigns using these execution chains to the Chinese BRONZE UNIVERSITY threat group, which has targeted transportation, natural resource, energy, and non-governmental organizations. Third-party researchers have also identified three-file ShadowPad execution chains that begin with consent.exe (followed by secur32.dll and secur32.dll.dat) and AppLaunch.exe (followed by mscoree.dll and mscoree.dll.dat). Additionally, CTU analysis revealed a sample that used AppLaunch.exe followed by mscoree.dll and mscoree.dll.mui.

Other ShadowPad samples from 2018 also deviated from the typical two-file execution chain. Those samples, which used the filename TSVIPSrv.DLL, are placed in the Windows System32 directory and are loaded by the Windows SessionEnv Service, which is vulnerable to DLL hijacking. CTU researchers observed BRONZE ATLAS using this technique in 2021 to load other payloads via this filename, including Cobalt Strike.

CTU researchers discovered ShadowPad samples sharing behavioral similarities such as injecting the decrypted ShadowPad payload into a newly launched target process and establishing persistence on a compromised host specified in the configuration settings. Figure 1 lists configuration information for a ShadowPad sample that reveals command and control (C2) details, the process injection target, and persistence via creation of a service and a registry Run key.

Figure 1. ShadowPad sample configuration information. (Source: Secureworks)

As part of the execution chain, ShadowPad copies the legitimate binary and sideloaded DLL to a subdirectory specific to each sample. Most analyzed samples were copied to a subdirectory under C:ProgramData, C:Users<username>Roaming, or C:Program Files. In three-file execution chains, the third file (e.g., log.dll.dat, iviewers.dll.dat) is typically deleted and the ShadowPad DLL loader is padded to over 50MB, likely to evade antivirus software. As part of this process, an encrypted payload is usually saved to a registry key under HKLMSOFTWAREClassesCLSID{GUID}<eight-character hexadecimal string> (see Figure 2).

Figure 2. Sample ShadowPad encrypted payload location. (Source: Secureworks)

After the initial setup the legitimate executable is launched as a Windows service. This service initiates the ShadowPad execution chain. The ShadowPad payload is injected into a child process of the service process that is specified in the ShadowPad configuration information. Figure 3 shows the timeline of a ShadowPad execution chain (i.e., log.exe -> log.dll -> log.dll.dat), followed by the service creation and execution of the copied files (log.exe renamed to reg.exe), and the payload injection.

Figure 3. Observed timeline of ShadowPad execution, service creation, and payload injection on a compromised network. (Source: Secureworks)

CTU researchers observed threat actors interacting with ShadowPad malware on compromised hosts. In one incident, multiple cmd.exe child processes were launched via hands-on-keyboard activity (see Figure 4).

Figure 4. Threat actor interaction with ShadowPad malware. (Source: Secureworks)

Identifying characteristics

The following file structures and behaviors can indicate a ShadowPad compromise:

• A subdirectory within C:ProgramData, C:Users<username>Roaming, or C:Program Files that contains a legitimate executable (likely renamed) and one of the known ShadowPad DLL loader filenames from Table 1 (see Figure 5)

  
  Figure 5. Example legitimate executable and ShadowPad DLL loader in C:ProgramData subdirectory. (Source: Secureworks)

• A Windows service that launches the legitimate executable from that subdirectory (see Figure 6)

  
  Figure 6. Example of installed Windows service for ShadowPad persistence. (Source: Secureworks)

• Process telemetry showing the Windows service creating an unusual child process (e.g., svchost.exe), which in turn creates multiple dllhost.exe and cmd.exe child processes

The BRONZE ATLAS/Chengdu 404 nexus

ShadowPad gained notoriety in 2017 after it was deployed in software supply chain attacks involving CCleaner, NetSarang, and ASUS Live Update utility. These campaigns were attributed to the BRONZE ATLAS threat group.

A 2017 Microsoft complaint and U.S. Department of Justice (DOJ) indictments unsealed in 2020 provide additional information on ShadowPad’s connection to BRONZE ATLAS. The Microsoft complaint alleges that BRONZE ATLAS (also known as Barium) deployed ShadowPad in 2017 to steal intellectual property and personally identifiable information (PII). At the time, the malware was used only by BRONZE ATLAS. The DOJ indictments allege that Chinese nationals working for the Chengdu 404 network security company deployed ShadowPad in a global campaign attributed to BRONZE ATLAS.

A related DOJ indictment revealed that these Chinese nationals collaborated with another Chinese national known by the handle ‘Rose’ (sometimes known as Withered Rose and Wicked Rose), using similar tactics, techniques, and procedures (TTPs) and sharing malware. The indictment describes this individual as a sophisticated threat actor who committed computer intrusion offenses targeting high-technology organizations globally. Campaigns linked to Rose were tracked as Barium.

A third-party report claimed that Rose likely co-developed malware with an associate named ‘whg,’ who has been linked to the development of the PlugX malware. PlugX is used by multiple Chinese threat groups. Third-party researchers also identified string and code overlap between PlugX and ShadowPad. This overlap suggests close links between the ShadowPad and PlugX developers. ShadowPad may have been developed by an individual or group affiliated with BRONZE ATLAS. One possibility is that Chengdu 404 originally developed ShadowPad, as the individuals named in the DOJ indictments were allegedly involved with developing malware used in their campaigns.

It is likely that only BRONZE ATLAS used ShadowPad until approximately 2019. Most of the ShadowPad DLL loader samples can be clustered based on compile timestamps, C2 infrastructure, payload versions, DLL loader code overlap, and likely victimology. CTU researchers identified multiple ShadowPad clusters used in campaigns since 2019 and attributed these clusters to distinct threat groups. These groups include BRONZE ATLAS and BRONZE UNIVERSITY, whose targeting suggests affiliation with the MSS. A third-party report suggests that BRONZE UNIVERSITY (referred to in the report as Earth Lusca) may be operating near to Chengdu in China after operational security mistakes revealed China-based infrastructure. Other ShadowPad clusters appear to reflect targeting aligned with PLA theater command areas of responsibility.

PLA reforms

In late 2015, PRC leader Xi Jinping announced widespread reforms to the PLA that included the establishment of the Strategic Support Force (PLASSF or SSF). This new branch focuses on modernizing the PLA’s capabilities in strategic frontiers of space, cyberspace, and the electromagnetic domain. The impact on the PLA’s cyberespionage mission has been extensive. Many organizations responsible for cyberespionage and signals intelligence (SIGINT) associated with the Third Department of the PLA’s General Staff Department (commonly known as 3PLA) have been absorbed into the SSF Network Systems Department (NSD). The SSF NSD is also believed to be responsible for a broad range of information warfare capabilities beyond cyberespionage, coordinating electronic countermeasures as well as offensive and defensive cyber projects. Figure 7 shows the likely SSF organizational structure.

Figure 7. PLA SSF likely organizational structure. (Source: Institute for National Strategic Studies)

As part of the modernization, the PLA replaced its seven military regions with five theater commands: Eastern, Southern, Western, Northern, and Central (see Figure 8). These theater commands orchestrate ground, naval, air, and conventional missile forces for military operations in their geographic area of responsibility. While the exact area of responsibility for each theater command is ambiguous, they are broadly responsible for specific threats within their respective regions:

• Eastern Theater Command: Taiwan strait and East China sea
• Southern Theater Command: South China sea
• Northern Theater Command: Russia and the Korean peninsula
• Western Theater Command: Central Asia and the Sino-Indian border
• Central Theater Command: defends the capital and possibly provides support to other theater commands

Figure 8. PLA theater command structure. (Source: The Jamestown Foundation)

Prior to the PLA reforms, each military region maintained at least one Technical Reconnaissance Bureau (TRB) to handle SIGINT and cyberespionage activities focused on the military region’s area of responsibility. The TRBs were distinct from the former 3PLA units that were located across China, but they may have been tasked by the 3PLA.

The relationship between the TRBs and the theater commands is unclear. The TRBs may have been consolidated under the SSF NSD alongside former 3PLA units. It is also possible that they continue to target countries in their area of responsibility but under the command and control of the SSF NSD.

Connections to PLA-linked threat groups

CTU researchers grouped distinct ShadowPad activity clusters by targeted geographic regions. Clusters align with the documented area of responsibility for three of the theater commands: Northern, Southern, and Western. CTU researchers attribute some of the ShadowPad activity to Chinese threat groups that have been publicly linked to specific PLA units located in the corresponding theater commands:

• Northern Theater Command: CTU researchers linked ShadowPad activity to BRONZE HUNTLEY and BRONZE BUTLER, which are reportedly located in the Northern Theater Command. These threat groups deployed ShadowPad against targets in South Korea, Russia, Japan, and Mongolia. These regions align with the Northern Theater Command’s focus. In 2021, CTU researchers observed malware and infrastructure overlap between the two threat groups, suggesting close collaboration.
• Western Theater Command: Some ShadowPad activity primarily targeted countries neighboring China’s western border, such as India and Afghanistan. CTU researchers clustered this activity based on attacker-controlled infrastructure, ShadowPad DLL loader variants such as ICEKILLER, and contextual information from third-party sources. Third-party researchers linked some of these campaigns to an individual working on behalf of the Western Theater Command. CTU analysis did not reveal sufficient evidence to corroborate these claims, but the locations and victimology are consistent with threat actors operating on behalf of the Western Theater Command.
• Southern Theater Command: CTU researchers identified activity that used a specific ShadowPad version to target organizations in the South China Sea region. BRONZE GENEVA is likely responsible for part of this activity based on overlap between the C2 infrastructure for the Nebulae malware family associated with BRONZE GENEVA and a ShadowPad sample analyzed by CTU researchers.

This attribution of ShadowPad campaigns to theater commands is based on the submitter’s location for ShadowPad malware samples uploaded to the VirusTotal analysis service (potentially indicating the victim’s country), the C2 domain names that appear to reference specific regions (e.g., cloudvn. info suggests Vietnam targeting), contextual information regarding the activity and victimology, and the absence of evidence that ShadowPad samples with the same attributes were deployed in other regions.

Conclusion

Evidence available as of this publication suggests that ShadowPad has been deployed by MSS-affiliated threat groups, as well as PLA-affiliated threat groups that operate on behalf of the regional theater commands. The malware was likely developed by threat actors affiliated with BRONZE ATLAS and then shared with MSS and PLA threat groups around 2019. Given the range of groups leveraging ShadowPad, all organizations that are likely targets for Chinese threat groups should monitor for TTPs associated with this malware. Organizations with operations in or connections to geographic regions covered by the regional theater commands should specifically monitor for known TTPs associated with threat groups likely affiliated with the relevant theater command.

Threat indicators

The threat indicators in Table 2 can be used to detect activity related to this threat. Note that IP addresses can be reallocated. The IP addresses and domains may contain malicious content, so consider the risks before opening them in a browser.

Table 2. Indicators for this threat.

References

Threat Intelligence Team. “New investigations into the CCleaner incident point to a possible third stage that had keylogger capacities.” Avast. March 8, 2018. https://blog.avast.com/new-investigations-in-ccleaner-incident-point-to-a-possible-third-stage-that-had-keylogger-capacities

Dr Web. “Study of the ShadowPad APT backdoor and its relation to PlugX.” October 26, 2020. https://st.drweb.com/static/new-www/news/2020/october/Study_of_the_ShadowPad_APT_backdoor_and_its_relation_to_PlugX_en.pdf

Fraser, Nalani and Vanderlee, Kelli. “Achievement Unlocked: Chinese Cyber Espionage Evolves to Support Higher Mission Levels.” FireEye. October 10, 2019. https://www.fireeye.com/content/dam/fireeye-www/summit/cds-2019/presentations/cds19-executive-s08-achievement-unlocked.pdf

Headquarters, Department of the Army (U.S.). “Chinese Tactics.” August 9, 2021. https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN33195-ATP_7-100.3-000-WEB-1.pdf

Hsieh, Yi-Jhen and Chen, Joey. “ShadowPad: A Masterpiece of Privately Sold Malware in Chinese Espionage.” Sentinel Labs. August 19, 2020. https://assets.sentinelone.com/c/Shadowpad?x=P42eqA

Insikt Group. “Threat Activity Group RedFoxtrot Linked to China’s PLA Unit 69010; Targets Bordering Asian Countries.” Recorded Future. June 16, 2021. https://www.recordedfuture.com/redfoxtrot-china-pla-targets-bordering-asian-countries/

Kaspersky. “ShadowPad: How Attackers hide Backdoor in Software used by Hundreds of Large Companies around the World.” August 15, 2017. https://www.kaspersky.com/about/press-releases/2017_shadowpad-how-attackers-hide-backdoor-in-software-used-by-hundreds-of-large-companies-around-the-world

Ni, Adam and Gill, Bates. “The People’s Liberation Army Strategic Support Force: Update 2019.” The Jamestown Foundation. May 29, 2019. https://jamestown.org/program/the-peoples-liberation-army-strategic-support-force-update-2019

Prescott, Adam. “Chasing Shadows: A deep dive into the latest obfuscation method being used by ShadowPad.” PwC. December 8, 2021. https://www.pwc.co.uk/issues/cyber-security-services/research/chasing-shadows.html

Recorded Future. “Threat Activity Group RedFoxtrot Linked to China’s PLA Unit 69010; Targets Bordering Asian Countries.” June 16, 2021. https://go.recordedfuture.com/hubfs/reports/cta-2021-0616.pdf

Stokes, Mark A.; Lin Jenny; and Hsiao, L.C. Russell. “The Chinese People’s Liberation Army Signals Intelligence and Cyber Reconnaissance Infrastructure.” Project 2049 Institute. November 11, 2011. https://project2049.net/wp-content/uploads/2018/05/pla_third_department_sigint_cyber_stokes_lin_hsiao.pdf

United States Department of Justice. “Seven International Cyber Defendants, Including ‘Apt41’ Actors, Charged In Connection With Computer Intrusion Campaigns Against More Than 100 Victims Globally.” September 16, 2020. https://www.justice.gov/opa/pr/seven-international-cyber-defendants-including-apt41-actors-charged-connection-computer

United States District Court for the District of Columbia. “United States of America v. Zhang Haoran, Tan Dailin, Defendants.” May 7, 2019. https://www.justice.gov/opa/press-release/file/1317216/download

United States District Court for the Eastern District of Virginia. “Civil Action No: 1:17-cv-01224.” October 26, 2017. https://www.noticeofpleadings.net/barium/files/COMPLAINT_AND_SUMMONS/Complaint.pdf

Wuthnow, Joel and Saunders, Phillip C. “Chinese Military Reforms in the Age of Xi Jinping: Drivers, Challenges, and Implications.” Institute for National Strategic Studies. March 2017. https://ndupress.ndu.edu/Portals/68/Documents/stratperspective/china/ChinaPerspectives-10.pdf

Zetter, Kim. “Hackers Hijacked ASUS Software Updates to Install Backdoors on Thousands of Computers.” Vice. March 25, 2019. https://www.vice.com/en/article/pan9wn/hackers-hijacked-asus-software-updates-to-install-backdoors-on-thousands-of-computers

The post ShadowPad Malware Analysis appeared first on Online Pitstop.

In late June 2021, Secureworks® Counter Threat Unit (CTU) researchers discovered a flaw in the protocol used by the Azure Active Directory Seamless Single Sign-On feature. This flaw allows threat actors to perform single-factor brute-force attacks against Azure Active Directory (Azure AD) without generating sign-in events in the targeted organization’s tenant.

CTU researchers reported the flaw to Microsoft on June 29. Microsoft confirmed the behavior on July 21 but ruled that it was “by design.” As a result, it is unclear if or when the flaw will be fixed. In the meantime, organizations are vulnerable to stealthy brute-force attacks.

Azure AD Seamless Single Sign-On

The Azure AD Seamless Single Sign-On (SSO) improves the user experience of services using the Azure AD identity platform, such as Microsoft 365. When Seamless SSO is configured, users logged in to their domain-joined computer are automatically logged into Azure AD.

The Seamless SSO feature uses the Kerberos protocol, which is the standard authentication method of Windows networks. During the Seamless SSO configuration, a computer object named AZUREADSSOACC is created in the on-premises Active Directory (AD) domain and is assigned the service principal name (SPN) “https: //autologon . microsoftazuread-sso . com”. That name and the password hash of the AZUREADSSOACC computer object are sent to Azure AD. The following autologon windowstransport endpoint accepts Kerberos tickets:

https: //autologon . microsoftazuread-sso . com//winauth/trust/2005/windowstransport

The Seamless SSO occurs automatically without any user interaction (see Figure 1).

Figure 1. Typical Seamless SSO process. (Source: Secureworks)

1. A user tries to access Azure AD.
2. Azure AD recognizes that user’s tenant is configured to use Seamless SSO and redirects the user’s browser to autologon.
3. The user’s browser tries to access Azure AD.
4. Autologon sends a Kerberos authentication challenge.
5. The user’s browser tries to authenticate as the logged-in user and requests a Ticket Granting Ticket (TGT).
6. The on-premises AD sends a TGT to the user’s browser.
7. The user’s browser requests autologon access from the on-premises AD and provides the TGT as proof of identity.
8. The on-premises AD locates a corresponding computer object and creates a service ticket (ST), which is encrypted using the AZUREADSSOACC computer account’s password hash.
9. The user’s browser makes another request to autologon and provides the ST in the request’s Authorization header.
10. Autologon decrypts the ST using the AZUREADSSOACC computer account’s password hash, issues a DesktopSSOToken access token for the user, and sends this token to user’s browser via a redirect request to Azure AD. DesktopSSOToken is an opaque blob encrypted by Microsoft, so the actual content is unknown.
11. The user’s browser makes another request to Azure AD using the DesktopSSOToken as the Security Assertion Markup Language (SAML) assertion.

Flaw in the protocol

In addition to the windowstransport authentication endpoint, there is an usernamemixed endpoint for username and password authentication:

https: //autologon . microsoftazuread-sso . com//winauth/trust/2005/usernamemixed

Figure 2 shows the username and password login process.

Figure 2. Autologon username and password login process. (Source: Secureworks)

1. An XML file containing the username and password are sent to the usernamemixed endpoint (see Figure 3).


Figure 3. XML file containing username and password. (Source: Secureworks)

2. Autologon tries to authenticate to Azure AD with the provided credentials.
3. If authentication is successful, autologon issues an XML file containing a DesktopSSOToken access token (see Figure 4). If authentication is unsuccessful, autologon generates an error (see Figure 5).


Figure 4. XML file containing the DesktopSSOToken. (Source: Secureworks)


Figure 5. Authentication error message. (Source: Secureworks)

4. If authentication is successful, the DesktopSSOToken access token is sent to Azure AD.

Table 1 lists the possible returned error codes. Not all error codes indicate brute-force attempts. For instance, error AADSTS50053 indicates that the username and password were correct, but the account was locked.

Table 1. Autologon error codes.

CTU researchers observed that successful authentication events generate sign-ins logs in step 4. However, autologon’s authentication to Azure AD (step 2) is not logged. This omission allows threat actors to utilize the usernamemixed endpoint for undetected brute-force attacks.

Conclusion

Threat actors can exploit the autologon usernamemixed endpoint to perform brute-force attacks. This activity is not logged in Azure AD sign-ins logs, enabling it to remain undetected. As of this publication, tools and countermeasures to detect brute-force or password spray attacks are based on sign-ins log events.

CTU analysis indicates that the autologon service is implemented with Azure Active Directory Federation Services (AD FS). Microsoft AD FS documentation recommends disabling internet access to the windowstransport endpoint. However, that access is required for Seamless SSO. Microsoft indicates that the usernamemixed endpoint is only required for legacy Office clients that predate the Office 2013 May 2015 update.

The exploitation is not limited to organizations using Seamless SSO. Threat actors can exploit the autologon usernamemixed endpoint in any Azure AD or Microsoft 365 organization, including organizations that use Pass-through Authentication (PTA). Users without an Azure AD password are not affected.

As of this publication, there are no known mitigation techniques to block use of the autologon usernamemixed endpoint. Multi-factor authentication (MFA) and conditional access (CA) do not prevent exploitation because they are applied after successful authentication.

The post Undetected Azure Active Directory Brute-Force Attacks appeared first on Online Pitstop.