April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-0530 is now tracked as Storm-0530 and PLUTONIUM is now tracked as Onyx Sleet.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

A group of actors originating from North Korea that Microsoft Threat Intelligence Center (MSTIC) tracks as DEV-0530 has been developing and using ransomware in attacks since June 2021. This group, which calls itself H0lyGh0st, utilizes a ransomware payload with the same name for its campaigns and has successfully compromised small businesses in multiple countries as early as September 2021.

Along with their H0lyGh0st payload, DEV-0530 maintains an .onion site that the group uses to interact with their victims. The group’s standard methodology is to encrypt all files on the target device and use the file extension .h0lyenc, send the victim a sample of the files as proof, and then demand payment in Bitcoin in exchange for restoring access to the files. As part of their extortion tactics, they also threaten to publish victim data on social media or send the data to the victims’ customers if they refuse to pay. This blog is intended to capture part of MSTIC’s analysis of DEV-0530 tactics, present the protections Microsoft has implemented in our security products, and share insights on DEV-0530 and H0lyGh0st ransomware with the broader security community to protect mutual customers.

MSTIC assesses that DEV-0530 has connections with another North Korean-based group tracked as PLUTONIUM (aka DarkSeoul or Andariel). While the use of H0lyGh0st ransomware in campaigns is unique to DEV-0530, MSTIC has observed communications between the two groups, as well as DEV-0530 using tools created exclusively by PLUTONIUM.

As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the information they need to secure their accounts. Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing MSTIC to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

Who is DEV-0530?

DEV-0530 primarily operates ransomware campaigns to pursue financial objectives. In MSTIC’s investigations of their early campaigns, analysts observed that the group’s ransom note included a link to the .onion site hxxp://matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd[.]onion, where the attackers claim to “close the gap between the rich and poor”. They also attempt to legitimize their actions by claiming to increase the victim’s security awareness by letting the victims know more about their security posture.

Like many other ransomware actors, DEV-0530 notes on their website’s privacy policy that they would not sell or publish their victim’s data if they get paid. But if the victim fails to pay, they would publish everything. A contact form is also available for victims to get in touch with the attackers.

Affiliations with other threat actors originating from North Korea

MSTIC assesses there is likely some overlap between DEV-0530 and PLUTONIUM. PLUTONIUM is a North Korean threat actor group affiliated with clusters of activity that are also known as DarkSeoul and Andariel. Active since at least 2014, PLUTONIUM has primarily targeted the energy and defense industries in India, South Korea, and the United States using a variety of tactics and techniques.

MSTIC has observed known DEV-0530 email accounts communicating with known PLUTONIUM attacker accounts. MSTIC has also observed both groups operating from the same infrastructure set, and even using custom malware controllers with similar names.

To further assess the origin of DEV-0530 operations, MSTIC performed a temporal analysis of observed activity from the group. MSTIC estimates that the pattern of life of DEV-0530 activity is most consistent with the UTC+8 and UTC+9 time zones. UTC+9 is the time zone used in North Korea.

Despite these similarities, differences in operational tempo, targeting, and tradecraft suggest DEV-0530 and PLUTONIUM are distinct groups.

Why are North Korean actors using ransomware?

Based on geopolitical observations by global experts on North Korean affairs and circumstantial observations, Microsoft analysts assess the use of ransomware by North Korea-based actors is likely motivated by two possible objectives.  

The first possibility is that the North Korean government sponsors this activity. The weakened North Korean economy has become weaker since 2016 due to sanctions, natural disasters, drought, and the North Korean government’s COVID-19 lockdown from the outside world since early 2020. To offset the losses from these economic setbacks, the North Korean government could have sponsored cyber actors stealing from banks and cryptocurrency wallets for more than five years. If the North Korean government is ordering these ransomware attacks, then the attacks would be yet another tactic the government has enabled to offset financial losses.

However, state-sponsored activity against cryptocurrency organizations has typically targeted a much broader set of victims than observed in DEV-0530 victimology. Because of this, it is equally possible that the North Korean government is not enabling or supporting these ransomware attacks. Individuals with ties to PLUTONIUM infrastructure and tools could be moonlighting for personal gain. This moonlighting theory might explain the often-random selection of victims targeted by DEV-0530.

Although Microsoft cannot be certain of DEV-0530’s motivations, the impact of these ransomware attacks on our customers raises the importance of exposing the underlying tactics and techniques, detecting and preventing attacks in our security products, and sharing our knowledge with the security ecosystem.

Ransomware developed by DEV-0530

Between June 2021 and May 2022, MSTIC classified H0lyGh0st ransomware under two new malware families: SiennaPurple and SiennaBlue. Both were developed and used by DEV-0530 in campaigns. MSTIC identified four variants under these families – BTLC_C.exe, HolyRS.exe, HolyLock.exe, and BLTC.exe – and clustered them based on code similarity, C2 infrastructure including C2 URL patterns, and ransom note text. BTLC_C.exe is written in C++ and is classified as SiennaPurple, while the rest are written in Go, and all variants are compiled into .exe to target Windows systems. Microsoft Defender Antivirus, which is built into and ships with Windows 10 and 11, detects and blocks BTLC_C.exe as SiennaPurple and the rest as SiennaBlue, providing protection for Windows users against all known variants the H0lyGh0st malware..

SiennaPurple ransomware family: BTLC_C.exe

BLTC_C.exe is a portable ransomware developed by DEV-0530 and was first seen in June 2021. This ransomware doesn’t have many features compared to all malware variants in the SiennaBlue family. Prominently, if not launched as an administrative user, the BLTC_C.exe malware displays the following hardcoded error before exiting:

"This program only execute under admin privilege".

The malware uses a simple obfuscation method for strings where 0x30 is subtracted from the hex value of each character, such that the string “aic^ef^bi^abc0” is decoded to 193[.]56[.]29[.]123. The indicators of compromise (IOCs) decoded from the BLTC_C.exe ransomware are consistent with all malware variants in the SiennaBlue family, including the C2 infrastructure and the HTTP beacon URL structure access.php?order=AccessRequest&cmn. The BTLC_C.exe sample analyzed by MSTIC has the following PDB path: M:\ForOP\attack(utils)\attack tools\Backdoor\powershell\btlc_C\Release\btlc_C.pdb.

SiennaBlue ransomware family: HolyRS.exe, HolyLocker.exe, and BTLC.exe

Between October 2021 and May 2022, MSTIC observed a cluster of new DEV-0530 ransomware variants written in Go. We classified these variants as SiennaBlue. While new Go functions were added to the different variants over time, all the ransomware in the SiennaBlue family share the same core Go functions.

A deeper look into the Go functions used in the SiennaBlue ransomware showed that over time, the core functionality expanded to include features like various encryption options, string obfuscation, public key management, and support for the internet and intranet. The table below demonstrates this expansion by comparing the Go functions in HolyRS.exe and BTLC.exe:

MSTIC assesses DEV-0530 successfully compromised several targets in multiple countries using HolyRS.exe in November 2021. A review of the victims showed they were primarily small-to-midsized businesses, including manufacturing organizations, banks, schools, and event and meeting planning companies. The victimology indicates that these victims are most likely targets of opportunity. MSTIC suspects that DEV-0530 might have exploited vulnerabilities such as CVE-2022-26352 (DotCMS remote code execution vulnerability) on public-facing web applications and content management systems to gain initial access into target networks. The SiennaBlue malware variants were then dropped and executed. To date, MSTIC has not observed DEV-0530 using any 0-day exploits in their attacks.

After successfully compromising a network, DEV-0530 exfiltrated a full copy of the victims’ files. Next, the attackers encrypted the contents of the victim device, replacing all file names with Base64-encoded versions of the file names and renaming the extension to .h0lyenc. Victims found a ransom note in C:\FOR_DECRYPT.html, as well as an email from the attackers with subject lines such as:

!!!!We are < H0lyGh0st>. Please Read me!!!!

As seen in the screenshot below, the email from the attackers let the victim know that the group has stolen and encrypted all their files. The email also included a link to a sample of the stolen data to prove their claim, in addition to the demand for payment for recovering the files.

BTLC.exe is the latest DEV-0530 ransomware variant and has been seen in the wild since April 2022. BTLC.exe can be configured to connect to a network share using the default username, password, and intranet URL hardcoded in the malware if the ServerBaseURL is not accessible from the device. One notable feature added to BTLC.exe is a persistence mechanism in which the malware creates or deletes a scheduled task called lockertask, such that the following command line syntax can be used to launch the ransomware:

cmd.exe /Q /c schtasks /create /tn lockertask /tr [File] /sc minute /mo 1 /F /ru system 1> \\127.0.0.1\ADMIN$\__[randomnumber] 2>&1

Once the ransomware is successfully launched as an administrator, it tries to connect to the default ServerBaseURL hardcoded in the malware, attempts to upload a public key to the C2 server, and encrypts all files in the victim’s drive.

Based on our investigation, the attackers frequently asked victims for anywhere from 1.2 to 5 Bitcoins. However, the attackers were usually willing to negotiate and, in some cases, lowered the price to less than one-third of the initial asking price. As of early July 2022, a review of the attackers’ wallet transactions shows that they have not successfully extorted ransom payments from their victims.

HolyRS.exe/BTLC.exe C2 URL pattern:

• hxxp://193[.]56[.]29[.]123:8888/access.php?order=GetPubkey&cmn=[Victim_HostName]
• hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_key_add&cmn=[Victim_HostName]&type=1
• hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_key_add&cmn=[Victim_HostName]&type=2
• hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_finish&cmn=[Victim_HostName]&

Examples of HolyRS.exe/BTLC.exe ransom note metadata:

Attacker email address: H0lyGh0st@mail2tor[.]com
Image location: hxxps://cloud-ex42[.]usaupload[.]com/cache/plugins/filepreviewer/219002/f44c6929994386ac2ae18b93f8270ec9ff8420d528c9e35a878efaa2d38fb94c/1100x800_cropped.jpg
Report URL: hxxp://matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd[.]onion

Microsoft will continue to monitor DEV-0530 activity and implement protections for our customers. The current detections, advanced detections, and indicators of compromise (IOCs) in place across our security products are detailed below.

Recommended customer actions

Microsoft has implemented protections to detect these malware families as SiennaPurple and SiennaBlue (e.g., Ransom:Win32/SiennaBlue.A) via Microsoft Defender Antivirus and Microsoft Defender for Endpoint, wherever these are deployed on-premises and in cloud environments.

Microsoft encourages all organizations to proactively implement and frequently validate a data backup and restore plan as part of broader protection against ransomware and extortion threats.

The techniques used by DEV-0530 in H0lyGh0st activity can be mitigated by adopting the security considerations provided below:

• Use the included IOCs to investigate whether they exist in your environment and assess for potential intrusion.

Our blog on the ransomware as a service economy has an exhaustive guide on how to protect against ransomware threats. We encourage readers to refer to that blog for a comprehensive guide that has a deep dive into each of the following areas:

• Building credential hygiene
• Auditing credential exposure
• Prioritizing deployment of Active Directory updates
• Cloud hardening
  • Implement the Azure Security Benchmark and general best practices for securing identity infrastructure.
  • Ensure cloud admins/tenant admins are treated with the same level of security and credential hygiene as Domain Admins.
  • Address gaps in authentication coverage.
• Enforcing MFA on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times.
• Enabling passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA.
• Disabling legacy authentication.

For small or midsize companies who use Microsoft Defender for Business or Microsoft 365 Business Premium, enabling each of the features below will provide a protective layer against these threats where applicable. For Microsoft 365 Defender customers, the following checklist eliminates security blind spots:

• Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules and tamper protection.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when a non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode also blocks indicators identified proactively by Microsoft Threat Intelligence teams.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches.
• Use device discovery to increase visibility into the network by finding unmanaged devices and onboarding them to Microsoft Defender for Endpoint.
• Protect user identities and credentials using Microsoft Defender for Identity, a cloud-based security solution that leverages on-premises Active Directory signals to monitor and analyze user behavior to identify suspicious user activities, configuration issues, and active attacks.

Indicators of compromise

This list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Microsoft 365 detections

Microsoft Defender Antivirus

• Trojan:Win32/SiennaPurple.A
• Ransom:Win32/SiennaBlue.A
• Ransom:Win32/SiennaBlue.B

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication of possible attack.

• DEV-0530 activity group
• Ransomware behavior detected in the file system
• Possible ransomware infection modifying multiple files
• Possible ransomware activity

Advanced hunting queries

Microsoft Sentinel

To locate possible DEV-0530 activity mentioned in this blog post, Microsoft Sentinel customers can use the queries detailed below:

Identify DEV-0530  IOCs

This query identifies a match based on IOCs related to DEV-0530 across various Sentinel data feeds:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Dev-0530_July2022.yaml

Identify renamed file extension

DEV-0530 actors are known to encrypt the contents of the victim’s device as well as rename the file and extension. The following query detects the creation of files with .h0lyenc extension:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Dev-0530_FileExtRename.yaml

Identify Microsoft Defender Antivirus detection related to DEV-0530

This query looks for Microsoft Defender AV detections related to DEV-0530 and joins the alert with other data sources to surface additional information such as device, IP, signed-in on users, etc.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/Dev-0530AVHits.yaml

Yara rules

rule SiennaPurple 
{ 
	meta: 
        	author = "Microsoft Threat Intelligence Center (MSTIC)" 
		description = "Detects PDB path, C2, and ransom note in DEV-0530 Ransomware SiennaPurple samples" 
		hash = "99fc54786a72f32fd44c7391c2171ca31e72ca52725c68e2dde94d04c286fccd" 
	strings: 
		$s1 = "ForOP\\attack(utils)\\attack tools\\Backdoor\\powershell\\btlc_C\\Release\\btlc_C.pdb" 
		$s2 = "matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd.onion"
		$s3 = "H0lyGh0st@mail2tor.com"
		$s4 = "We are <HolyGhost>. All your important files are stored and encrypted."
		$s5 = "aic^ef^bi^abc0"
		$s6 = "---------------------------3819074751749789153841466081"

	condition: 
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 
		filesize < 7MB and filesize > 1MB and 
		all of ($s*) 
}

rule SiennaBlue 
{ 
    	meta: 
		author = "Microsoft Threat Intelligence Center (MSTIC)" 
		description = "Detects Golang package, function, and source file names observed in DEV-0530 Ransomware SiennaBlue samples" 
		hash1 = "f8fc2445a9814ca8cf48a979bff7f182d6538f4d1ff438cf259268e8b4b76f86" 
		hash2 = "541825cb652606c2ea12fd25a842a8b3456d025841c3a7f563655ef77bb67219"
	strings: 
		$holylocker_s1 = "C:/Users/user/Downloads/development/src/HolyLocker/Main/HolyLock/locker.go"
		$holylocker_s2 = "HolyLocker/Main.EncryptionExtension"
		$holylocker_s3 = "HolyLocker/Main.ContactEmail"
		$holylocker_s4 = "HolyLocker/communication.(*Client).GetPubkeyFromServer"
		$holylocker_s5 = "HolyLocker/communication.(*Client).AddNewKeyPairToIntranet"
		
		$holyrs_s1 = "C:/Users/user/Downloads/development/src/HolyGhostProject/MainFunc/HolyRS/HolyRS.go"
		$holyrs_s2 = "HolyGhostProject/MainFunc.ContactEmail"
		$holyrs_s3 = "HolyGhostProject/MainFunc.EncryptionExtension"
		$holyrs_s4 = "HolyGhostProject/Network.(*Client).GetPubkeyFromServer"
		$holyrs_s5 = "HolyGhostProject/Network.(*Client).AddNewKeyPairToIntranet"
		$s1 = "Our site : <b><a href=%s>H0lyGh0stWebsite"
		$s2 = ".h0lyenc"
		$go_prefix = "Go build ID:"
	condition: 
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 
		filesize < 7MB and filesize > 1MB and 
		$go_prefix and all of ($s*) and (all of ($holylocker_*) or all of ($holyrs_*))
}

The post North Korean threat actor targets small and midsize businesses with H0lyGh0st ransomware appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. POLONIUM is now tracked as Plaid Rain and MERCURY is now tracked as Mango Sandstorm. The DEV-#### designations are now tracked under the name Storm-#### using the same four-digit identifier. 

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Microsoft successfully detected and disabled attack activity abusing OneDrive by a previously undocumented Lebanon-based activity group Microsoft Threat Intelligence Center (MSTIC) tracks as POLONIUM.  The associated indicators and tactics were used by the OneDrive team to improve detection of attack activity and disable offending actor accounts. To further address this abuse, Microsoft has suspended more than 20 malicious OneDrive applications created by POLONIUM actors, notified affected organizations, and deployed a series of security intelligence updates that will quarantine tools developed by POLONIUM operators. Our goal with this blog is to help deter future activity by exposing and sharing the POLONIUM tactics with the community at large.

MSTIC assesses with high confidence that POLONIUM represents an operational group based in Lebanon. We also assess with moderate confidence that the observed activity was coordinated with other actors affiliated with Iran’s Ministry of Intelligence and Security (MOIS), based primarily on victim overlap and commonality of tools and techniques. Such collaboration or direction from Tehran would align with a string of revelations since late 2020 that the Government of Iran is using third parties to carry out cyber operations on their behalf, likely to enhance Iran’s plausible deniability.

POLONIUM has targeted or compromised more than 20 organizations based in Israel and one intergovernmental organization with operations in Lebanon over the past three months. This actor has deployed unique tools that abuse legitimate cloud services for command and control (C2) across most of their victims. POLONIUM was observed creating and using legitimate OneDrive accounts, then utilizing those accounts as C2 to execute part of their attack operation. This activity does not represent any security issues or vulnerabilities on the OneDrive platform. In addition, MSTIC does not, at present, see any links between this activity and other publicly documented groups linked to Lebanon like Volatile Cedar. This blog will also expose further details that show Iranian threat actors may be collaborating with proxies to operationalize their attacks. Microsoft continues to work across its platforms to identify abuse, take down malicious activity, and implement new proactive protections to discourage malicious actors from using our services.

As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the information they need to secure their accounts.

Observed actor activity

Since February 2022, POLONIUM has been observed primarily targeting organizations in Israel with a focus on critical manufacturing, IT, and Israel’s defense industry. In at least one case, POLONIUM’s compromise of an IT company was used to target a downstream aviation company and law firm in a supply chain attack that relied on service provider credentials to gain access to the targeted networks. Multiple manufacturing companies they targeted also serve Israel’s defense industry, indicating a POLONIUM tactic that follows an increasing trend by many actors, including among several Iranian groups, of targeting service provider access to gain downstream access. Observed victim organizations were in the following sectors: critical manufacturing, information technology, transportation systems, defense industrial base, government agencies and services, food and agriculture, financial services, healthcare and public health, and other business types.

POLONIUM TTPs shared with Iran-based nation-state actors

MSTIC assesses with moderate confidence that POLONIUM is coordinating its operations with multiple tracked actor groups affiliated with Iran’s Ministry of Intelligence and Security (MOIS), based on victim overlap and the following common techniques and tooling:

• Common unique victim targeting: MSTIC has observed POLONIUM active on or targeting multiple victims that MERCURY previously compromised. According to the US Cyber Command, MuddyWater, a group we track as MERCURY, “is a subordinate element within the Iranian Ministry of Intelligence and Security.”
• Evidence of possible “hand-off” operations: The uniqueness of the victim organizations suggests a convergence of mission requirements with MOIS. It may also be evidence of a ‘hand-off’ operational model where MOIS provides POLONIUM with access to previously compromised victim environments to execute new activity. MSTIC continues to monitor both actors to further verify this ‘hand-off’ hypothesis.
• Use of OneDrive for C2:  MSTIC has observed both POLONIUM and DEV-0133 (aka Lyceum) using cloud services, including OneDrive, for data exfiltration and command and control.
• Use of AirVPN: Both POLONIUM and DEV-0588 (aka CopyKittens) commonly use AirVPN for operational activity. While use of public VPN services is common across many actor sets, these actors’ specific choice to use AirVPN, combined with the additional overlaps documented above, further supports the moderate confidence assessment that POLONIUM collaborates with MOIS.

Abuse of cloud services

POLONIUM has been observed deploying a series of custom implants that utilize cloud services for command and control as well as data exfiltration. MSTIC has observed implants connecting to POLONIUM-owned accounts in OneDrive and Dropbox. These tools are detected as the following malware:

• Trojan:PowerShell/CreepyDrive.A!dha
• Trojan:PowerShell/CreepyDrive.B!dha
• Trojan:PowerShell/CreepyDrive.C!dha
• Trojan:PowerShell/CreepyDrive.D!dha
• Trojan:PowerShell/CreepyDrive.E!dha
• Trojan:MSIL/CreepyBox.A!dha
• Trojan:MSIL/CreepyBox.B!dha
• Trojan:MSIL/CreepyBox.C!dha

While OneDrive performs antivirus scanning on all uploaded content, POLONIUM is not using the cloud service to host their malware. If malware was hosted in the OneDrive account, Microsoft Defender Antivirus detections would block it. Instead, they are interacting with the cloud service in the same way that a legitimate customer would. OneDrive is partnering with MSTIC to identify and disable accounts that are linked to known adversary behavior.

CreepyDrive analysis

The CreepyDrive implant utilizes a POLONIUM-owned OneDrive storage account for command and control. The implant provides basic functionality of allowing the threat actor to upload stolen files and download files to run.

All web requests by the CreepyDrive implant use the Invoke-WebRequest cmdlet. The implant’s logic is wrapped in a while true loop, ensuring continuous execution of the implant once running. The implant contains no native persistence mechanism; if terminated it would need to be re-executed by the threat actor.

Due to the lack of victim identifiers in the CreepyDrive implant, using the same OneDrive account for multiple victims, while possible, may be challenging. It’s likely that a different threat actor-controlled OneDrive account is used per implant.

Getting an OAuth token

When run, the implant first needs to authenticate with OneDrive. The threat actor incorporated a refresh token within the implant. Refresh tokens are part of the Open Authorization 2 (OAuth) specification, allowing a new OAuth token to be issued when it expires. There are several mechanisms that make token theft difficult, including the use of the trusted platform module (TPM) to protect secrets. More information on these mechanisms can be found here.

In this instance, the protection settings tied to the OneDrive account are fully controlled by the threat actor, allowing them to disable protections that prevent the theft of the token and client secrets. As the threat actor is in full control of all secrets and key material associated with the account, their sign-in activity looks like legitimate customer behavior and is thus challenging to detect.

This token and client secret are transmitted in the body of request to a legitimate Microsoft endpoint to generate an OAuth token:

https[://]login.microsoftonline.com/consumers/oauth2/v2.0/token

This request provides the requisite OAuth token for the implant to interact with the threat actor-owned OneDrive account. Using this OAuth token, the implant makes a request to the following Microsoft Graph API endpoint to access the file data.txt:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/data.txt:/content

The file data.txt acts as the primary tasking mechanism for the implant, providing three branches of execution.

Upload

The first branch is triggered when the word “upload” is provided in the response. This response payload also contains two additional elements: a local file path to upload, and what is likely a threat actor-defined remote file name to upload the local file into. The request is structured as follows:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Uploaded/???:/content

Download

The second branch is triggered when the word “download” is provided in the response. This response payload contains a file name to download from the threat actor-owned OneDrive account. The request is structured as follows:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Downloaded/???:/content

Execute

This branch is triggered when no command is provided in the response. The response payload can contain either an array of commands to execute or file paths to files previously downloaded by the implant. The threat actor can also provide a mixture of individual commands and file paths.

Each value from the array is passed individually into the below custom function, which uses the Invoke-Expression cmdlet to run commands:

The output of each executed command is aggregated and then written back to the following location in the threat actor-owned OneDrive account:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/response.json:/content

During the execution of this mechanism, the threat actor resets the content of the original tasking file data.txt with the following request:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/data.txt:/content

Finally, the CreepyDrive implant sleeps, re-executing in a loop until the process is terminated.

Use of custom implant

POLONIUM has also been observed deploying a custom PowerShell implant detected as Backdoor:PowerShell/CreepySnail.B!dha. The C2s for observed CreepySnail implants include:

• 135[.]125[.]147[.]170:80
• 185[.]244[.]129[.]79:63047
• 185[.]244[.]129[.]79:80
• 45[.]80[.]149[.]108:63047
• 45[.]80[.]149[.]108:80
• 45[.]80[.]149[.]57:63047
• 45[.]80[.]149[.]68:63047
• 45[.]80[.]149[.]71:80

The code below demonstrates how the CreepySnail PowerShell implant, once deployed on a target network, attempts to authenticate using stolen credentials and connect to POLONIUM C2 for further actions on objectives, such as data exfiltration or further abuse as C2.

Use of commodity tools

POLONIUM has also been observed dropping a secondary payload via their OneDrive implant. POLONIUM used a common SSH tool for automating interactive sign-ins called plink to set up a redundant tunnel from the victim environment to the attacker-controlled infrastructure.

The observed C2 IP addresses for POLONIUM plink tunnels include:

• 185[.]244[.]129 [.]109
• 172[.]96[.]188[.]51
• 51[.]83 [.]246 [.]73

Exploitation

While we continue to pursue confirmation of how POLONIUM gained initial access to many of their victims, MSTIC notes that approximately 80% of the observed victims beaconing to graph.microsoft.com were running Fortinet appliances. This suggests, but does not definitively prove, that POLONIUM compromised these Fortinet devices by exploiting the CVE-2018-13379 vulnerability to gain access to the compromised organizations.

IT supply chain attacks

In one case, POLONIUM compromised a cloud service provider based in Israel and likely used this access to compromise downstream customers of the service provider. Specifically, MSTIC observed that POLONIUM pivoted through the service provider and gained access to a law firm and an aviation company in Israel. The tactic of leveraging IT products and service providers to gain access to downstream customers remains a favorite of Iranian actors and their proxies.

Microsoft will continue to monitor ongoing activity from POLONIUM and the other Iranian MOIS-affiliated actors discussed in this blog and implement protections for our customers. The current detections, advanced detections, and IOCs in place across our security products are detailed below.

Recommended customer actions

The techniques used by the actor described in the “Observed actor activity” section can be mitigated by adopting the security considerations provided below:

• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion. Microsoft Sentinel queries are provided in the advanced hunting section below.
• Confirm that Microsoft Defender Antivirus is updated to security intelligence update 1.365.40.0 or later, or ensure that cloud protection is turned on, to detect the related indicators.
• Block in-bound traffic from IPs specified in the “Indicators of compromise” table.
• Review all authentication activity for remote access infrastructure (VPNs), with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.
• Enable multifactor authentication (MFA) to mitigate potentially compromised credentials and ensure that MFA is enforced for all remote connectivity.  NOTE: Microsoft strongly encourages all customers download and use passwordless solutions like Microsoft Authenticator to secure your accounts.
• For customers that have relationships with service providers, review and audit partner relationships to minimize any unnecessary permissions between your organization and upstream providers. Microsoft recommends immediately removing access for any partner relationships that look unfamiliar or have not yet been audited.

Indicators of compromise (IOCs)

The below list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Detections

Microsoft 365 Defender

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware tools and implants used by POLONIUM starting from signature build 1.365.40.0 as the following:

• Trojan:PowerShell/CreepyDrive.A!dha
• Trojan:PowerShell/CreepyDrive.B!dha
• Trojan:PowerShell/CreepyDrive.C!dha
• Trojan:PowerShell/CreepyDrive.D!dha
• Trojan:PowerShell/CreepyDrive.E!dha
• Trojan:MSIL/CreepyBox.A!dha
• Trojan:MSIL/CreepyBox.B!dha
• Trojan:MSIL/CreepyBox.C!dha
• Trojan:MSIL/CreepyRing.A!dha
• Trojan:MSIL/CreepyWink.B!dha
• Backdoor:PowerShell/CreepySnail.B!dha

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication of possible attack. These alerts are not necessarily an indication of POLONIUM compromise:

• POLONIUM Actor Activity Detected
• PowerShell made a suspicious network connection
• Suspicious behavior by powershell.exe was observed
• Hidden dual-use tool launch attempt
• Outbound connection to non-standard port

Microsoft Defender for Cloud Apps

The OAuth apps that were created in the victim tenants were created with only two specific scope of permissions: offline_access and Files.ReadWrite.All. These applications were set to serve multi-tenant and performed only OneDrive operations. Applications accessed OneDrive workload via the Graph API, where most calls to the API from the application were made as search activities, with a few edit operations also observed.

App made numerous searches and edits in OneDrive

App governance, an add-on to Microsoft Defender for Cloud Apps, detects malicious OAuth applications that make numerous searches and edits in OneDrive. Learn how to investigate anomaly detection alerts in Microsoft Defender for Cloud Apps.

Advanced hunting queries

Microsoft Sentinel

Identify POLONIUM IOCs

This query identifies POLONIUM network IOCs within available Azure Sentinel network logging:

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/POLONIUMIPIoC.yaml

Detect CreepySnail static URI parameters

The CreepySnail tool utilizes static URI parameters that can be detected using the following query:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepySnailURLParameters.yaml

Detect Base64-encoded/transmitted machine usernames or IP addresses

CreepySnail also utilizes Base64-encoded parameters to transmit information from the victim to threat actor. The following queries detect machine usernames or IP addresses (based on Microsoft Defender for Endpoint logging) being transmitted under Base64 encoding in a web request:

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/B64UserInWebURIFromMDE.yaml

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/B64IPInURLFromMDE.yaml

Detect POLONIUM requests to predictable OneDrive file paths

The OneDrive capability that POLONIUM utilizes makes requests to predictable OneDrive file paths to access various folders and files. The following queries detect these paths in use:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepyDriveURLs.yaml

Detect sequence of request events related to unique CreepyDrive re-authentication attempts

The CreepyDrive implant makes a predictable sequence of requests to Microsoft authentication servers and OneDrive that can be detected using the following query:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepyDriveRequestSequence.yaml

Hunt for other suspicious encoded request parameters

The following hunting queries can be used to hunt for further suspicious encoded request parameters:

https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/CommonSecurityLog/B64IPInURL.yaml

https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/CommonSecurityLog/RiskyCommandB64EncodedInUrl.yaml

The post Exposing POLONIUM activity and infrastructure targeting Israeli organizations appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. ACTINIUM is now tracked as Aqua Blizzard and DEV-0586 is now tracked as Cadet Blizzard.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The Microsoft Threat Intelligence Center (MSTIC) is sharing information on a threat group named ACTINIUM, which has been operational for almost a decade and has consistently pursued access to organizations in Ukraine or entities related to Ukrainian affairs. MSTIC previously tracked ACTINIUM activity as DEV-0157, and this group is also referred to publicly as Gamaredon.

NOTE: This blog is available in Ukrainian on the Microsoft CEE Multi-Country News Center to help organizations in Ukraine implement protections against this activity: АКТИНІЙ(ACTINIUM) атакує українські організації.

In the last six months, MSTIC has observed ACTINIUM targeting organizations in Ukraine spanning government, military, non-government organizations (NGO), judiciary, law enforcement, and non-profit, with the primary intent of exfiltrating sensitive information, maintaining access, and using acquired access to move laterally into related organizations. MSTIC has observed ACTINIUM operating out of Crimea with objectives consistent with cyber espionage. The Ukrainian government has publicly attributed this group to the Russian Federal Security Service (FSB).

Since October 2021, ACTINIUM has targeted or compromised accounts at organizations critical to emergency response and ensuring the security of Ukrainian territory, as well as organizations that would be involved in coordinating the distribution of international and humanitarian aid to Ukraine in a crisis. As with any observed nation-state actor activity, Microsoft directly notifies customers of online services that have been targeted or compromised, providing them with the information they need to secure their accounts. Microsoft has shared this information with Ukrainian authorities.

ACTINIUM represents a unique set of activities separate from the destructive malware attacks by DEV-0586 described in an earlier blog post. As of this writing, MSTIC has not found any indicators correlating these two actors or their operations. The observed ACTINIUM activities detailed in this blog have been limited only to organizations within Ukraine. We have not seen this actor using any unpatched vulnerabilities in Microsoft products or services.

Given the geopolitical situation and the scale of observed activity, MSTIC is prioritizing sharing our knowledge of ACTINIUM tactics, techniques, and procedures (TTPs), along with a significant number of indicators of compromise (IOCs) from our extensive analysis. Our goal is to give organizations the latest intelligence to guide investigations into potential attacks and information to implement proactive protections against future attempts.

Activity description

Microsoft has observed a repeated set of techniques and procedures throughout operations by ACTINIUM, with several significant elements that we believe are important to understanding these activities. It’s important to note that ACTINIUM’s tactics are constantly evolving; the activities described in this blog are some of the most consistent and notable observations by Microsoft, but these are not all-encompassing of actor TTPs.

Phishing using remote templates

One of the access vectors most used by ACTINIUM is spear-phishing emails with malicious macro attachments that employ remote templates. Remote template injection refers to the method of causing a document to load a remote document template that contains the malicious code, in this case, macros. Delivery using remote template injection ensures that malicious content is only loaded when required (for example, when the user opens the document). This helps attackers to evade static detections, for example, by systems that scan attachments for malicious content. Having the malicious macro hosted remotely also allows an attacker to control when and how the malicious component is delivered, further evading detection by preventing automated systems from obtaining and analyzing the malicious component.

MSTIC has observed a range of email phishing lures used by ACTINIUM, including those that impersonate and masquerade as legitimate organizations, using benign attachments to establish trust and familiarity with the target.

Within the body of phishing messages, ACTINIUM has been observed to insert web bugs, which are small external image references that enable the actor to track when a message has been opened and rendered. These web bugs are not malicious by themselves but may indicate that the email is intended for malicious use. Here’s an example of a web bug used by ACTINIUM:

ACTINIUM’s lure documents appear to be legitimate and vary in style and content. For example, the lure document below included a remote template at the following URL: hxxp://usa-national[.]info/USA/sensible[.]dot. While a domain was used in this instance, links with static IP addresses have also been used.

ACTINIUM phishing attachments contain a first-stage payload that downloads and executes further payloads. There may be multiple subsequent “staging” scripts before a more fully-featured malicious capability is deployed to a compromised device. It’s unclear why there are often multiple stages; one hypothesis is that these staging VBScripts are easier to modify to incorporate new obfuscation or command-and-control (C2) changes. It’s also possible that ACTINIUM deploys these scripts to provide some assurance that detection systems are less likely to detect their main capabilities. These initial staging capabilities vary; examples include heavily obfuscated VBScripts, obfuscated PowerShell commands, self-extracting archives, LNK files, or a combination of these. ACTINIUM frequently relies on scheduled tasks in these scripts to maintain persistence. More information on some of the capabilities analyzed by MSTIC is included in the “Malware and capabilities” section.

ACTINIUM operational infrastructure and wordlists

MSTIC assesses that ACTINIUM maintains a large quantity and degree of variation of its operational infrastructure to evade detection. ACTINIUM’s operational infrastructure consists of many domains and hosts to facilitate payload staging and C2. In a single 30-day snapshot, MSTIC saw ACTINIUM utilizing over 25 new unique domains and over 80 unique IP addresses, demonstrating that they frequently modify or alter their infrastructure.

ACTINIUM domain name DNS records frequently change, perhaps not frequently enough to be considered “fast-flux”, but most DNS records for the domains change once a day on average. More than 70% of the recent 200+ ACTINIUM IP addresses are owned by ASN 197695 – REG.RU. Most ACTINIUM domains are also registered through the same owning company registrar (REG.RU). It is unclear why ACTINIUM appears to favor these legitimate providers.  

Malware authored by ACTINIUM often utilizes randomized subdomains for C2. These subdomains have included the use of an apparent English wordlist in their generation procedure, making the domains appear more legitimate while frustrating network defense tools that may rely on domain name blocks. A list of the most common words MSTIC has observed is included in the IOCs below. Within the last 30 days, MSTIC has observed randomized schemes being used increasingly for subdomain patterns instead of wordlists, indicating a possible shift in methodology. One example of this randomization is the effect of their PowerShell stager using the Get-Random cmdlet:’

Examples of ACTINIUM subdomains encompassing both wordlists and randomized subdomains include:

• Jealousy[.]Jonas[.]artisola[.]ru
• Deliberate[.]brontaga[.]ru
• registration83[.]alteration[.]luck[.]mirotas[.]ru
• 001912184[.]retarus[.]ru
• 637753599292688334[.]jolotras[.]ru

While the fast-flux nature of ACTINIUM infrastructure means that IP addresses are less useful IOCs, there is a clear preference for it on a specific ASN. Such preference may help defenders determine whether a domain may be more likely to be owned by ACTINIUM. A list of more recent IP addresses is included in the IOCs below.

ACTINIUM appears to employ this same wordlist to obfuscate other aspects of their attacks. For example, as previously mentioned, ACTINIUM often maintains persistence by using scheduled tasks to run their malicious payloads. The payloads are often named with seemingly random words and phrases with valid (but irrelevant) extensions. The files are then executed using scripts with the /E:VBScript flag to specify the VBScript engine (and to effectively ignore the random file extension assigned to the payload) and the /b flag to mute alerts and errors. The following is an example:

The terms deep-grounded, deerfield, and defiance above are used as the name of a scheduled task, a folder name, and a file name, respectively. Terms generated from the wordlist, like those in the example above, have been generated and used on multiple targets and are also used to generate subdomains as previously described. These generated terms may frustrate network defenders as the names of scheduled tasks, file names, and others are almost never the same for each target. We have compiled a list of the terms that MSTIC has observed in the IOCs provided below. Network defenders may be able to use the said list to determine whether a scheduled task, file, or domain is likely to warrant further investigation.

Maintaining persistence and gathering intelligence

MSTIC assesses that the primary outcome of activities by ACTINIUM is persistent access to networks of perceived value for the purpose of intelligence collection. Despite seemingly wide deployment of malicious capabilities in the region, follow-on activities by the group occur in areas of discrete interest, indicating a possible review of targeting. Following initial access, MSTIC has observed ACTINIUM deploying tools such as “Pterodo” to gain interactive access to target networks. In some cases, MSTIC has observed deployments of UltraVNC to enable a more interactive connection to a target. UltraVNC is a legitimate and fully-featured open-source remote desktop application that allows ACTINIUM to easily interact with a target host without relying on custom, malicious binaries that may be detected and removed by security products.

Malware and capabilities

ACTINIUM employs a variety of malware families with assessed objectives to deploy remotely retrieved or embedded payloads before execution. MSTIC has analyzed several of these payloads and tracks the rapidly developing binaries as the following families: DinoTrain, DesertDown, DilongTrash, ObfuBerry, ObfuMerry, and PowerPunch. The PowerPunch malware family is an excellent example of an agile and evolving sequence of malicious code and is further explained below.

The actor quickly develops new obfuscated and lightweight capabilities to deploy more advanced malware later. These are fast-moving targets with a high degree of variance. Analyzed payloads regularly place a strong emphasis on obfuscated VBScripts. As an attack, this is not a novel approach, yet it continues to prove successful as antivirus solutions must consistently adapt to keep pace with a very agile threat.

The most feature-rich malware family we track relating to ACTINIUM activity is known widely within the industry as “Pterodo”. In the following sections, we break down Pterodo further and review a binary called QuietSieve that is specifically geared toward file exfiltration and monitoring.  

PowerPunch

The droppers and downloader family names tend to be fast-moving targets due to the heavy use of obfuscation and simple functionality. For example, PowerPunch is executed from within PowerShell as a one-line command, encoded using Base64:

These binaries also exhibit features that rely on data from the compromised host to inform encryption of the next stage. PowerPunch also provides an excellent example of this. In the following code snippet, the VolumeSerialNumber of the host serves as the basis for a multibyte XOR key. The key is applied to an executable payload downloaded directly from adversary infrastructure, allowing for an encryption key unique to the target host (highlighted variables names were changed for clarity).

Ultimately, a next-stage executable is remotely retrieved and dropped to disk prior to execution.

Pterodo

MSTIC has also reviewed several variants of ACTINIUM’s more fully-featured Pterodo malware. A couple of features play a direct role in this malware’s ability to evade detection and thwart analysis: its use of a dynamic Windows function hashing algorithm to map necessary API components, and an “on-demand” scheme for decrypting needed data and freeing allocated heap space when used.

The function hashing algorithm is used to map a hash value of a given function name to its corresponding location in memory using a process known as Run-Time Dynamic Linking. Pre-computed hashes are passed to the hashing algorithm alongside the Windows library containing the related function name. Each function name within the library is hashed; when a match is found, its address is saved.

The hashing algorithm itself has historically not been terribly complex, and when considering an example such as SHA-256 51b9e03db53b2d583f66e47af56bb0146630f8a175d4a439369045038d6d2a45, it may be emulated using Python logic as follows:

When pre-computing these hashes over different Windows DLLs commonly used in schemes like this, it is possible to map out these hash values and the corresponding Windows function name using open-source tools like the MITRE malchive.

We have seen this behavior in many different malware families before. The hashing algorithm has been consistent within those families, allowing analysis like this to scale forward. Unfortunately, in Pterodo’s case, there is far too much drift in the algorithm for it to be used reliably. The algorithm has been different in many of the samples we’ve reviewed. Additionally, the application of this technique seems to vary among samples. Some samples have been observed to use it for most Windows function calls, while others have used it very sparingly.

However, Windows libraries need to be loaded before function hashes are computed. The names of these libraries and other strings required by the malware are recovered using an “on-demand” scheme that decrypts the data, uses it, and immediately frees the associated heap space once it is no longer needed.

As seen in the screenshot above, data is passed into a decryption function before being used in a call to GetModuleHandleA. Before the hashing routine uses the module handle, the decrypted string representing the function name has its associated heap space freed and may be later overwritten. However, the reconstruction of this data is  straightforward within the two core decryption algorithms we have observed. The first one relies on an encrypted blob whose first value is interpreted as the size of the decrypted data in DWORD (four-byte) chunks.

This data is decrypted four bytes at a time, with the last byte being the encrypted content. Each encrypted byte is XOR’d using a multibyte key sequence unique to each sample reviewed. In our example, the ASCII key sequence 39d84sdfjh is applied to the content above to produce the module name Kernel32.

A slight deviation from this approach was also uncovered in samples such as SHA-256 2042a2feb4d9f54d65d7579a0afba9ee1c6d22e29127991fbf34ea3da1659904, where the decryption algorithm is passed data representing two WORD values: one mapping to the offset of the encrypted content within the malware and another representing the length. These parameters are recovered, and a much longer multibyte XOR sequence is applied to the encrypted content after the starting index is computed.

Application of either approach allows us to gain a greater level of analysis into strings used by the malware. Continuing with the approach used by the previously cited example, we can apply the multibyte XOR key over the entire encrypted data space, resulting in the following content:

Pterodo has been observed to be a constantly evolving malware family with a range of capabilities intended to make analysis more difficult. By applying our understanding, we can expose more malware elements to further advance mitigation and detection efforts.

QuietSieve

The QuietSieve malware family refers to a series of heavily-obfuscated .NET binaries specifically designed to steal information from the target host. Before enumerating target files on the host, QuietSieve first checks for connectivity by sending a test ping to 8.8.8.8 (Google public DNS). The creation of the buffer for the ICMP request is done manually within QuietSieve and contains all null values for the 32-byte data portion of the ICMP packet. If this check succeeds, a randomly-generated alphanumeric prefix is created and combined with the callback domain as a subdomain before an initial request is made over HTTPS.

If the connection is successful, the following file name extensions are searched for within removable, fixed, or networked drives: doc, docx, xls, rtf, odt, txt, jpg, pdf, rar, zip, and 7z. Candidate files are queued up for upload. They are also inventoried via a specific MD5 hash value computed based on attributes of the target file and compromised host, such as the volume serial number, file size, and last write timestamp assigned to the file. Computed hashes are logged to an inventory log file that serves as a reference point checked by the malware to avoid duplicate exfiltration. QuietSieve will also take screenshots of the compromised host approximately every five minutes and save them in the user’s local Application Data folder under Temp\SymbolSourceSymbols\icons or Temp\ModeAuto\icons using the format yyyy-MM-dd-HH-mm along with the jpg file extension.

While the QuietSieve malware family is primarily geared towards the exfiltration of data from the compromised host, it can also receive and execute a remote payload from the operator. These payloads are written to the user’s Application Data folder with a random alphanumeric name and are executed in a hidden window.

Microsoft will continue to monitor ACTINIUM activity and implement protections for our customers.

Indicators of compromise (IOCs)

The following IOCs were observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

Analyst note on ACTINIUM IOCs: ACTINIUM registers and administers a large amount of infrastructure. It’s not always possible to accurately determine what malicious component connects to which C2 infrastructure. MSTIC has observed cases where the same C2 is used for different components (for example, corolain[.]ru).

Example malware samples and associated infrastructure

QuietSieve

Pterodo

Various stagers and downloaders

(DinoTrain, DilongTrash, Obfuberry, PowerPunch, DessertDown, and Obfumerry)

ACTINIUM-owned infrastructure

Domains

The following list represents the most recent domains used by ACTINIUM as of this writing. Many of ACTINIUM’s capabilities communicate with generated subdomains following the patterns discussed earlier. A list of commonly observed words in these generated names is available in the next section, although it should be noted that this list is not exhaustive.

Wordlist of observed terms

ACTINIUM likely generates strings for use in various components from a wordlist. A sample of terms observed in use by ACTINIUM can be found below. ACTINIUM has been observed to use these terms for:

• Subdomains for their C2 infrastructure
• Scheduled task names
• Folder names
• Malware file names

ACTINIUM also likely generates strings for other uses where they attempt to disguise their activities.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Detections

Microsoft 365 Defender

Microsoft Defender Antivirus

• Trojan:MSIL/QuietSieve.Gen!dha
• TrojanDownloader:VBS/ObfuMerry.A!dha
• TrojanDownloader:VBS/ObfuBerry.A!dha
• TrojanDropper:Win32/PowerPunch.A!dha
• TrojanDropper:Win32/DinoTrain.gen!dha
• TrojanDownloader:VBS/DessertDown.A!dha
• TrojanDownloader:VBS/DessertDown.B!dha
• TrojanDownloader:Win32/DilongTrash!dha
• TrojanDownloader:Win32/PterodoGen.A!dha
• TrojanDownloader:Win32/PterodoGen.B!dha
• TrojanDownloader:Win32/PterodoGen.C!dha

Microsoft Defender for Endpoint

Alerts with the following titles in the security center can indicate threat activity on your network:

• ACTINIUM activity group

The following alerts might also indicate threat activity associated with this threat. These alerts, however, may be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately given the severity of the attacks.

• Suspicious obfuscation or deobfuscation activity
• Suspicious script execution
• A script with suspicious content was observed
• PowerShell dropped a suspicious file on the machine
• Anomalous process executing encoded command
• Suspicious dynamic link library loaded
• An anomalous scheduled task was created
• An uncommon file was created and added to a Run Key
• Suspicious screen capture activity
• Staging of sensitive data
• Suspicious process transferring data to external network

Microsoft Defender for Office 365

Microsoft Defender for Office 365 customers can use the email entity page to search for and visualize the potential impact of these attacks to your organization.

The following email security alerts may indicate threat activity associated with this threat. These alerts, however, may be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately given the severity of the attacks.

• Email messages containing malicious file removed after delivery​
• Email messages containing malware removed after delivery
• Email messages removed after delivery​
• Email reported by user as malware or phish
• Malware campaign detected after delivery
• Malware campaign detected and blocked
• Malware not zapped because ZAP is disabled

Advanced hunting queries

Microsoft Sentinel

To locate possible ACTINIUM activity mentioned in this blog post, Microsoft Sentinel customers can use the queries detailed below:

Identify ACTINIUM IOCs

This query identifies a match across various data feeds for IOCs related to ACTINIUM:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/ActiniumFeb2022.yaml

Identify antivirus detection of ACTINIUM activity

This query identifies a match in the Security Alert table for Microsoft Defender Antivirus detections related to the ACTINIUM actor:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/ActiniumAVHits.yaml

Microsoft 365 Defender

To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:

Find ACTINIUM-related emails

Use this query to look for look for emails that may have been received in your environment related to ACTINIUM.

EmailEvents
| where SenderMailFromDomain =~ 'who-int.info'
    or SenderFromDomain =~ 'who-int.info'

Surface ACTINIUM-related alerts

Use this query to look for alerts related to ACTINIUM alerts.

AlertInfo
| where Title in~('ACTINIUM activity group')

Surface devices with ACTINIUM related alerts and gather additional device alert information

Use this query to look for threat activity associated with ACTINIUM alerts.

// Get any devices with ACTINIUM related Alert Activity
let DevicesACTINIUMAlerts = AlertInfo
| where Title in~('ACTINIUM activity group')
// Join in evidence information
| join AlertEvidence on AlertId
| where DeviceId != ""
| summarize by DeviceId, Title;
// Get additional alert activity for each device
AlertEvidence
| where DeviceId in(DevicesACTINIUMAlerts)
// Add additional info
| join kind=leftouter AlertInfo on AlertId
| summarize DeviceAlerts = make_set(Title), AlertIDs = make_set(AlertId) by DeviceId, bin(Timestamp, 1d)

Surface suspicious MSHTA process execution

Use this query to look for MSHTA launching with command lines referencing DLLs in the AppData\Roaming path.

DeviceProcessEvents
| where FileName =~ "mshta.exe"
| where ProcessCommandLine has_all (".dll", "Roaming") 
| where ProcessCommandLine contains @"Roaming\j"
| extend DLLName = extract(@"[jJ][a-z]{1,12}\.dll", 0, ProcessCommandLine)

Surface suspicious Scheduled Task activity

Use this query to look for Scheduled Tasks that may relate to ACTINIUM activity.

DeviceProcessEvents
| where ProcessCommandLine has_all ("schtasks.exe", "create", "wscript", "e:vbscript", ".wav")

The post ACTINIUM targets Ukrainian organizations appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-0586 is now tracked as Cadet Blizzard.

Microsoft Threat Intelligence Center (MSTIC) has identified evidence of a destructive malware operation targeting multiple organizations in Ukraine. This malware first appeared on victim systems in Ukraine on January 13, 2022. Microsoft is aware of the ongoing geopolitical events in Ukraine and surrounding region and encourages organizations to use the information in this post to proactively protect from any malicious activity.

While our investigation is continuing, MSTIC has not found any notable associations between this observed activity, tracked as DEV-0586, and other known activity groups. MSTIC assesses that the malware, which is designed to look like ransomware but lacking a ransom recovery mechanism, is intended to be destructive and designed to render targeted devices inoperable rather than to obtain a ransom.

At present and based on Microsoft visibility, our investigation teams have identified the malware on dozens of impacted systems and that number could grow as our investigation continues. These systems span multiple government, non-profit, and information technology organizations, all based in Ukraine. We do not know the current stage of this attacker’s operational cycle or how many other victim organizations may exist in Ukraine or other geographic locations. However, it is unlikely these impacted systems represent the full scope of impact as other organizations are reporting.

Given the scale of the observed intrusions, MSTIC is not able to assess intent of the identified destructive actions but does believe these actions represent an elevated risk to any government agency, non-profit or enterprise located or with systems in Ukraine. We strongly encourage all organizations to immediately conduct a thorough investigation and to implement defenses using the information provided in this post. MSTIC will update this blog as we have additional information to share.

As with any observed nation-state actor activity, Microsoft directly and proactively notifies customers that have been targeted or compromised, providing them with the information they need to guide their investigations. MSTIC is also actively working with members of the global security community and other strategic partners to share information that can address this evolving threat through multiple channels. Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing MSTIC to track it as a unique set of information until we reach a high confidence about the origin or identity of the actor behind the activity. Once it meets the criteria, a DEV is converted to a named actor or merged with existing actors.

Observed actor activity

On January 13, Microsoft identified intrusion activity originating from Ukraine that appeared to be possible Master Boot Records (MBR) Wiper activity. During our investigation, we found a unique malware capability being used in intrusion attacks against multiple victim organizations in Ukraine.

Stage 1: Overwrite Master Boot Record to display a faked ransom note

The malware resides in various working directories, including C:\PerfLogs, C:\ProgramData, C:\, and C:\temp, and is often named stage1.exe. In the observed intrusions, the malware executes via Impacket, a publicly available capability often used by threat actors for lateral movement and execution.

The two-stage malware overwrites the Master Boot Record (MBR) on victim systems with a ransom note (Stage 1). The MBR is the part of a hard drive that tells the computer how to load its operating system. The ransom note contains a Bitcoin wallet and Tox ID (a unique account identifier used in the Tox encrypted messaging protocol) that have not been previously observed by MSTIC:

Your hard drive has been corrupted.
In case you want to recover all hard drives
of your organization,
You should pay us $10k via bitcoin wallet
1AVNM68gj6PGPFcJuftKATa4WLnzg8fpfv and send message via
tox ID 8BEDC411012A33BA34F49130D0F186993C6A32DAD8976F6A5D82C1ED23054C057ECED5496F65
with your organization name.
We will contact you to give further instructions.

The malware executes when the associated device is powered down. Overwriting the MBR is atypical for cybercriminal ransomware. In reality, the ransomware note is a ruse and that the malware destructs MBR and the contents of the files it targets. There are several reasons why this activity is inconsistent with cybercriminal ransomware activity observed by MSTIC, including:

• Ransomware payloads are typically customized per victim. In this case, the same ransom payload was observed at multiple victims.
• Virtually all ransomware encrypts the contents of files on the filesystem. The malware in this case overwrites the MBR with no mechanism for recovery. 
• Explicit payment amounts and cryptocurrency wallet addresses are rarely specified in modern criminal ransom notes, but were specified by DEV-0586. The same Bitcoin wallet address has been observed across all DEV-0586 intrusions and at the time of analysis, the only activity was a small transfer on January 14.
• It is rare for the communication method to be only a Tox ID, an identifier for use with the Tox encrypted messaging protocol. Typically, there are websites with support forums or multiple methods of contact (including email) to make it easy for the victim to successfully make contact.
• Most criminal ransom notes include a custom ID that a victim is instructed to send in their communications to the attackers. This is an important part of the process where the custom ID maps on the backend of the ransomware operation to a victim-specific decryption key. The ransom note in this case does not include a custom ID.

Microsoft will continue to monitor DEV-0586 activity and implement protections for our customers. The current detections, advanced detections, and IOCs in place across our security products are detailed below.

Stage 2: File corrupter malware

Stage2.exe is a downloader for a malicious file corrupter malware. Upon execution, stage2.exe downloads the next-stage malware hosted on a Discord channel, with the download link hardcoded in the downloader. The next-stage malware can best be described as a malicious file corrupter. Once executed in memory, the corrupter locates files in certain directories on the system with one of the following hardcoded file extensions:

.3DM .3DS .7Z .ACCDB .AI .ARC .ASC .ASM .ASP .ASPX .BACKUP .BAK .BAT .BMP .BRD .BZ .BZ2 .CGM .CLASS .CMD .CONFIG .CPP .CRT .CS .CSR .CSV .DB .DBF .DCH .DER .DIF .DIP .DJVU.SH .DOC .DOCB .DOCM .DOCX .DOT .DOTM .DOTX .DWG .EDB .EML .FRM .GIF .GO .GZ .HDD .HTM .HTML .HWP .IBD .INC .INI .ISO .JAR .JAVA .JPEG .JPG .JS .JSP .KDBX .KEY .LAY .LAY6 .LDF .LOG .MAX .MDB .MDF .MML .MSG .MYD .MYI .NEF .NVRAM .ODB .ODG .ODP .ODS .ODT .OGG .ONETOC2 .OST .OTG .OTP .OTS .OTT .P12 .PAQ .PAS .PDF .PEM .PFX .PHP .PHP3 .PHP4 .PHP5 .PHP6 .PHP7 .PHPS .PHTML .PL .PNG .POT .POTM .POTX .PPAM .PPK .PPS .PPSM .PPSX .PPT .PPTM .PPTX .PS1 .PSD .PST .PY .RAR .RAW .RB .RTF .SAV .SCH .SHTML .SLDM .SLDX .SLK .SLN .SNT .SQ3 .SQL .SQLITE3 .SQLITEDB .STC .STD .STI .STW .SUO .SVG .SXC .SXD .SXI .SXM .SXW .TAR .TBK .TGZ .TIF .TIFF .TXT .UOP .UOT .VB .VBS .VCD .VDI .VHD .VMDK .VMEM .VMSD .VMSN .VMSS .VMTM .VMTX .VMX .VMXF .VSD .VSDX .VSWP .WAR .WB2 .WK1 .WKS .XHTML .XLC .XLM .XLS .XLSB .XLSM .XLSX .XLT .XLTM .XLTX .XLW .YML .ZIP

If a file carries one of the extensions above, the corrupter overwrites the contents of the file with a fixed number of 0xCC bytes (total file size of 1MB). After overwriting the contents, the destructor renames each file with a seemingly random four-byte extension. Analysis of this malware is ongoing.

Recommended customer actions

MSTIC and the Microsoft security teams are working to create and implement detections for this activity. To date, Microsoft has implemented protections to detect this malware family as WhisperGate (e.g., DoS:Win32/WhisperGate.A!dha) via Microsoft Defender Antivirus and Microsoft Defender for Endpoint, wherever these are deployed on-premises and cloud environments. We are continuing the investigation and will share significant updates with affected customers, as well as public and private sector partners, as get more information. The techniques used by the actor and described in the this post can be mitigated by adopting the security considerations provided below:

• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Review all authentication activity for remote access infrastructure, with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.
• Enable multifactor authentication (MFA) to mitigate potentially compromised credentials and ensure that MFA is enforced for all remote connectivity.  NOTE: Microsoft strongly encourages all customers download and use password-less solutions like Microsoft Authenticator to secure accounts.
• Enable Controlled folder Access (CFA) in Microsoft Defender for Endpoint to prevent MBR/VBR modification.

Indicators of compromise (IOCs)

The following list provides IOCs observed during our investigation. We encourage customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Detections

Microsoft 365 Defender

Antivirus

• DoS:Win32/WhisperGate.A!dha
• DoS:Win32/WhisperGate.C!.dha
• DoS:Win32/WhisperGate.H!dha
• DoS:Win32/WhisperGate.X!dha

The post Destructive malware targeting Ukrainian organizations appeared first on Microsoft Security Blog.

MSTIC has tracked the current NICKEL operations, including attacks against government organizations, diplomatic entities, and NGOs, since September 2019. During this time, NICKEL activity has been observed across several countries, with a large amount of activity targeting Central and South American governments. Notably, NICKEL has achieved long-term access to several targets, allowing NICKEL to conduct activities such as regularly scheduled exfiltration of data. As China’s influence around the world continues to grow and the nation establishes bilateral relations with more countries and extends partnerships in support of China’s Belt and Road Initiative, we assess that China-based threat actors will continue to target customers in government, diplomatic, and NGO sectors to gain new insights, likely in pursuit of economic espionage or traditional intelligence collection objectives. Portions of the NICKEL activity we are highlighting have also been blogged about by our colleagues at ESET.

Figure 1: NICKEL targeted countries: Argentina, Barbados, Bosnia and Herzegovina, Brazil, Bulgaria, Chile, Colombia, Croatia, Czech Republic, Dominican Republic, Ecuador, El Salvador, France, Guatemala, Honduras, Hungary, Italy, Jamaica, Mali, Mexico, Montenegro, Panama, Peru, Portugal, Switzerland, Trinidad and Tobago, United Kingdom, United States of America, Venezuela

As with any observed nation-state actor activity, Microsoft continues to notify customers that have been targeted or compromised, providing them with the information they need to help secure their organizations. To reduce the potential impact of this NICKEL activity, Microsoft encourages our customers to immediately review the activity and guidance below, then implement risk mitigations, harden environments, and investigate suspicious behaviors that match the tactics described in this blog. MSTIC will continue to observe, monitor, and notify affected customers and partners, when possible, through our nation-state notification process.

Observed activity

MSTIC has observed NICKEL actors using exploits against unpatched systems to compromise remote access services and appliances. Upon successful intrusion, they have used credential dumpers or stealers to obtain legitimate credentials, which they used to gain access to victim accounts. NICKEL actors created and deployed custom malware that allowed them to maintain persistence on victim networks over extended periods of time. MSTIC has also observed NICKEL perform frequent and scheduled data collection and exfiltration from victim networks.

NICKEL successfully compromises networks using attacks on internet-facing web applications running on unpatched Microsoft Exchange and SharePoint. They also attack remote access infrastructure, such as unpatched VPN appliances, as referenced in the FireEye April 2021 blog detailing a 0-day vulnerability in Pulse Secure VPN that has since been patched.

After gaining an initial foothold on a compromised system, the NICKEL actors routinely performed reconnaissance on the network, working to gain access to additional accounts or higher-value systems. NICKEL typically deployed a keylogger to capture credentials from users on compromised systems. We’ve observed NICKEL using Mimikatz, WDigest (an older authentication method that allows the attacker access to credentials in clear text), NTDSDump, and other password dumping tools to gather credentials on a targeted system and from target browsers.

Deploying malware for command and control
MSTIC tracks multiple malware families used by NICKEL for command and control as Neoichor, Leeson, NumbIdea, NullItch, and Rokum.

The Leeson, Neoichor, and NumbIdea malware families typically use the Internet Explorer (IE) COM interface to connect and receive commands from hardcoded C2 servers. Due to their reliance on IE, these malware families intentionally configure the browser settings by modifying the following registry entries:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
Start Page = “about:blank”
DisableFirstRunCustomize = 1
RunOnceComplete = 1
RunOnceHasShown = 1
Check_Associations = 1

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Recovery]
AutoRecover = 0

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Privacy]
ClearBrowsingHistoryOnExit = 1

[HKEY_CURRENT_USER\Software\Microsoft\Internet Connection Wizard]
Completed = 1

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]
IEHarden = 0

When connecting to the C2 servers, the URL requests follow these formats:

http[:]//<C2>?id=<5-digit-rand><system-specific-string>
http[:]//<C2>?setssion==<rand><GetTickCount>
http[:]//<C2>?newfrs%dsetssion=<rand><GetTickCount>
http[:]//<C2>/index.htm?content=<base64-system-specifc-string>&id=<num>

A typical response from the C2 server is a legitimate-looking webpage containing the string “!DOCTYPE html”, which the malware checks. The malware then locates a Base64-encoded blob, which it decodes and proceeds to load as a shellcode.

For the Neoichor family, the malware checks for internet connectivity by contacting bing.com with the request format bing.com?id=<GetTickCount> and drops files as ~atemp and ~btemp containing error codes and debug resources.

The NICKEL implants are backdoors capable of collecting system information, such as:

• IP address
• OS version
• System language ID
• Computer name
• Signed-in username

They implement basic backdoor functionalities, including:

• Launching a process
• Uploading a file
• Downloading a file
• Executing a shellcode in memory

MSTIC has observed NICKEL drop their malware into existing installed software paths. They did this to make their malware appear to be files used for an installed application. The following are example paths:

• C:\Program Files\Realtek\Audio\HDA\AERTSr.exe
• C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitRdr64.exe
• C:\Program Files (x86)\Adobe\Flash Player\AddIns\airappinstaller\airappinstall.exe
• C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd64.exe

Using compromised credentials for routine email collection

NICKEL used compromised credentials to sign into victims’ Microsoft 365 accounts through normal sign-ins with a browser and the legacy Exchange Web Services (EWS) protocol to review and collect victim emails. MSTIC has observed successful NICKEL sign-ins to compromised accounts through commercial VPN providers as well as from actor-controlled infrastructure. The activity graphed below shows NICKEL sign-in activity happening most frequently on Monday through Friday from 12:00 AM UTC (8:00 AM China Standard time) through 09:00 AM UTC (5:00 PM China Standard Time). There are also possible indications of a shift-based scheduling model based on the observed limited set of activity during a typical weekend.

Figure 2: Heatmap of observed NICKEL login activity by day of week and hour (UTC time)

Evidence of routine host data collection

In several observed cases, NICKEL was seen performing regular data collection for exfiltration purposes. Their activity included looking in directories of interest for new files added since the last time they collected data. In the example below, NICKEL was collecting data that had been created or modified multiple times over a one-month period. For instance, on October 22, NICKEL looked for files that had been created since October 19 in multiple folders. Previously, on October 20 they had done the same thing looking for files that were modified or created since October 13.

Here are recent examples of NICKEL’s routine data collection:

After collecting the data in a central directory, the attackers then used either a renamed rar.exe or 7z.exe to archive the files. NICKEL also frequently used keyboard walks as a password for their archived data collections. The following are examples of RAR archiving for exfiltration:

Here is an example of 7zip archiving for exfiltration:

Microsoft will continue to monitor NICKEL activity and implement product protections for our customers. The IOCs, current detections, and advanced protections in place across our security products are detailed below.

Recommended defenses

The following guidance can help mitigate the techniques and threat activity described in this blog:

• Block legacy authentication protocols in Azure Active Directory – especially Exchange Web Services (EWS)
• Enable multi-factor authentication to mitigate compromised credentials.
  • For Office 365 users, see multi-factor authentication support.
  • For Consumer and Personal email accounts, see how to use two-step verification.
• Use passwordless solutions like Microsoft Authenticator to secure accounts.
• Review and enforce recommended Exchange Online access policies.
  • Block ActiveSync clients from bypassing Conditional Access policies.
• Block all incoming traffic from anonymizing services, where possible.
• Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Indicators of compromise (IOCs)

Detections

Microsoft 365 Defender

Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Backdoor:Win32/Leeson
• Trojan:Win32/Kechang
• Backdoor:Win32/Nightimp!dha
• Trojan:Win32/Rokum
• TrojanSpy:Win32/KeyLogger

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate NICKEL threat activity on your network:

• NICKEL activity group
• Malware associated with NICKEL activity group
• Communication with NICKEL infrastructure

The following alerts may also indicate threat activity associated with NICKEL but may also be triggered by unrelated threat activity:

• Mimikatz credential theft tool
• Suspected credential theft activity
• Malicious credential theft tool execution detected
• Sensitive credential memory read
• Password hashes dumped from LSASS memory
• Suspicious credential dump from NTDS.dit
• Compression of sensitive data
• Staging of sensitive data
• Suspicious process transferring data to external network
• Possible data exfiltration through multiple egress points

Microsoft 365 Defender correlates related alerts into consolidated incidents to help customers determine with confidence if observed alerts are related to this activity. We also published a threat analytics report on the NICKEL activity described in this blog. Microsoft 365 Defender can use the threat analytics report to get technical information, as well as view, investigate, and respond to incidents and alerts that include any detections of related NICKEL activity.

Advanced hunting queries

Microsoft Sentinel

The indicators of compromise (IoCs) included in this blog post can be used by Microsoft Sentinel customers for detection purposes using the queries detailed below.

Match known NICKEL domains and hashes

The following query matches domain name, hash IOCs and Microsoft 365 Defender signatures related to the NICKEL activity group with CommonSecurityLog, DnsEvents, VMConnection and SecurityEvents dataTypes.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/NICKELIOCsNov2021.yaml

Identify NICKEL registry modifications patterns

The following query identifies instances where NICKEL malware intentionally configures the browser settings for its use by modifying registry entries.

https://github.com/azure/azure-sentinel/blob/master/Hunting%20Queries/MultipleDataSources/NickelRegIOCPatterns.yaml

Hunt for NICKEL Command Line Activity November 2021

The below query looks for process command line activity related to data collection and staging observed being used by NICKEL. It hunts for use of tools such as xcopy and renamed archiving tools used for data collection and staging on the hosts with signatures observed in NICKEL activity.

https://github.com/azure/azure-sentinel/blob/master/Hunting%20Queries/MultipleDataSources/NICKELCommandLineActivity-Nov2021.yaml

Microsoft 365 Defender

Surface WDigest authentication changes

Use this query to look for alerts related to enabling WDigest Authentication, which allows attackers to dump credentials in clear text. Run query

AlertInfo
| where Title == "WDigest configuration change"
| join AlertEvidence on AlertId

Surface discovery activity

Use this query to surface potential NICKEL discovery activity. Run query

DeviceProcessEvents
| where InitiatingProcessFileName =~ "rundll32.exe" and InitiatingProcessCommandLine has ",start"
| where ProcessCommandLine has_any("cmd",
"netstat", "tasklist", "dir", "del", "net use", "ipconfig", "systeminfo", "xcopy", "mkdir", ".bat")

The post NICKEL targeting government organizations across Latin America and Europe appeared first on Microsoft Security Blog.

Until July 2021, Microsoft had observed relatively little history of Iranian actors attacking Indian targets. As India and other nations rise as major IT services hubs, more nation state actors follow the supply chain to target these providers’ public and private sector customers around the world matching nation state interests.

To date this year, Microsoft has issued more than 1,600 notifications to over 40 IT companies in response to Iranian targeting, compared to 48 notifications in 2020, making this a significant increase from years past (Figure 1). The focus of several Iranian threat groups on the IT sector particularly spiked in the last six months – roughly 10-13% of our notifications were related to Iranian threat activity in the last six months, compared to two and a half percent in the six months prior (Figure 2). Most of the targeting is focused on IT services companies based in India, as well as several companies based in Israel and United Arab Emirates. Although different in technique from other recent supply chain attacks, these attacks represent another example of how nation state actors are increasingly targeting supply chains as indirect vectors to achieve their objectives.

Figure 1: Number of notifications sent to IT Services related to Iran-based actor targeting

Figure 2: Percentage of notifications per quarter sent to IT Services NSNs related to Iran-based activity

As with any observed nation state actor activity, Microsoft has directly notified customers that have been targeted or compromised, providing them with the information they need to secure their accounts. Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing MSTIC to track it as a unique set of information until we reach a high confidence about the origin or identity of the actor behind the activity. Once it meets the criteria, a DEV is converted to a named actor.

Observed activity

In July 2021, a group that MSTIC tracks as DEV-0228 and assesses as based in Iran compromised a single Israel-based IT company that provides business management software. Based on MSTIC’s assessment, DEV-0228 used access to that IT company to extend their attacks and compromise downstream customers in the defense, energy, and legal sectors in Israel. In September, we detected a separate Iranian group, DEV-0056, compromising email accounts at a Bahrain-based IT integration company that works on IT integration with Bahrain Government clients, who were likely DEV-0056’s ultimate target. DEV-0056 also compromised various accounts at a partially government-owned organization in the Middle East that provide information and communications technology to the defense and transportation sectors, which are targets of interest to the Iranian regime. DEV-0056 maintained persistence at the IT integration organization through at least October.

MSTIC detected a significant increase in these and other Iranian groups targeting IT companies based in India beginning in mid-August. From mid-August to late September, we issued 1,788 nation state notifications (NSNs) across Iranian actors to enterprise customers in India, roughly 80% of which were to IT companies, an exponential rise from the 10 notifications we issued the previous three years in response to previous Iranian targeting. Iranian cyber actors have rarely targeted India, and the lack of pressing geopolitical issues that would have prompted such a shift suggests that this targeting is for indirect access to subsidiaries and clients outside India.

Credential theft leads to downstream compromise

DEV-0228 dumped credentials from the on-premises network of an IT provider based in Israel in early July. Over the next two months, the group compromised at least a dozen other organizations, several of which have strong public relations with the compromised IT company. MSTIC assesses at least four (4) of those victims were compromised using the acquired credentials and access from the IT company in the July and August attacks. Here are two such examples:

• DEV-0228 operators compromised the on-premises network of a law firm in Israel in August through an account managed by the IT provider via PAExec (a custom version of the Windows Sysinternals tool PsExec).

Pa.exe  \\###.##.#.## -u {user name}\{domain name} -p "********" -s cmd.exe

• DEV-0228 operators also compromised a defense company in Israel by signing into an email account provisioned for the same IT provider on the victim’s Office 365 tenant. The attackers likely obtained those credentials from the initial compromise of the IT provider in July.

Custom implant to establish persistence

DEV-0228 operators used a custom implant to establish persistence on victim hosts and then dumped LSASS. The implant is a custom remote access Trojan (RAT) that uses Dropbox as a command and control (C2) channel and is disguised as RuntimeBroker.exe or svchost.exe.

Operators staged their tools in a C:\Windows\TAPI directory on the victim hosts:

• C:\Windows\TAPI\lsa.exe
• C:\Windows\TAPI\pa.exe
• C:\Windows\TAPI\pc.exe (procdump)
• C:\Windows\TAPI\Rar.exe

Microsoft will continue to monitor DEV-0228 and DEV-0056 activity and implement protections for our customers. The current detections, advanced detections, and IOCs in place across our security products are detailed below.

Indicators of compromise (IOCs)

Recommended defenses

The following guidance can mitigate the techniques described in the threat activity:

• Enable multi-factor authentication to mitigate compromised credentials.
  • For Office 365 users, see multi-factor authentication support.
  • For Consumer and Personal email accounts, see how to use two-step verification.
• Use passwordless solutions like Microsoft Authenticator to secure accounts.
• Review and enforce recommended Exchange Online access policies.
  • Block ActiveSync clients from bypassing Conditional Access policies.
• Block all incoming traffic from anonymizing services where possible.
• Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Detections

Microsoft 365 Defender

Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Backdoor:MSIL/ShellClient.A
• Backdoor:MSIL/ShellClient.A!dll
• Trojan:MSIL/Mimikatz.BA!MTB

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on the network:

• DEV-0228 actor activity
• DEV-0056 actor activity

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity, but they are listed here for reference:

• Suspicious connection to remote service
• Possible command-and-control activity
• Suspicious access to LSASS service
• Sensitive credential memory read

Figure 3: Microsoft 365 Defender alert showing credential dumping activity

Microsoft 365 Defender correlates related alerts into consolidated incidents to help customers determine with confidence if observed alerts are related to this activity. Customers using the Microsoft 365 Defender portal can view, investigate, and respond to incidents that include any detections related to the activity described in this blog.

Advanced hunting queries

Microsoft Sentinel

The indicators of compromise (IoCs) included in this blog post can be used by Microsoft Sentinel customers for detection purposes using the queries detailed below.

Command Line Activity November 2021

This hunting query looks for process command line activity related to observed activity. The query uses additional data from Microsoft Defender for Endpoint to generate a risk score associated with each result. Hosts with higher risk events should be investigated first.

https://github.com/azure/azure-sentinel/blob/master/Hunting%20Queries/MultipleDataSources/Dev-0056CommandLineActivityNovember2021.yaml

FilePath/Hashes query November 2021

This hunting query looks for file paths/hashes related to observed activity as detailed in this blog.

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/Dev-0228FilePathHashesNovember2021.yaml

In addition to these queries, there are equivalent queries that use the Advanced SIEM Information Model (ASIM) to look for the same activity.

https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/ASimProcess/imProcess_Dev-0056CommandLineActivityNovember2021-ASIM.yaml

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/ASimFileEvent/imFileEvent_Dev-0228FilePathHashesNovember2021-ASIM.yaml

Microsoft 365 Defender

To locate malicious activity related to the activity described in this blog, customers can run the following queries in Microsoft 365 Defender or Microsoft Defender for Endpoint.

Identify use of PAExec in your environment

Look for PAExec.exe process executions in your environment. Run query.

DeviceProcessEvents
| where FileName =~ "paexec.exe" or ProcessVersionInfoOriginalFileName =~ "paexec.exe"
| where not(ProcessCommandLine has_any("program files", "-service"))

Identify files created in the Windows\Tapi directory

Look for files created in the Windows\Tapi directory. Run query.

DeviceFileEvents
| where FolderPath has @"C:\Windows\TAPI"

Suspicious PowerShell commands

Look for suspicious PowerShell process execution. Run query.

DeviceProcessEvents
| where ProcessCommandLine has_any("/q /c color f7&", "Net.We$()bClient", "$b,15,$b.Length-15") or
(ProcessCommandLine has "FromBase64String" and ProcessCommandLine has_all("-nop", "iex", "(iex"))

The post Iranian targeting of IT sector on the rise appeared first on Microsoft Security Blog.

Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing MSTIC to track it as a unique set of information until they can reach high confidence about the origin or identity of the actor behind the operation. Once it meets the criteria, a DEV is converted to a named actor. As with any observed nation state actor activity, Microsoft has directly notified customers that have been targeted or compromised, providing them with the information they need to secure their accounts.

Targeting in this DEV-0343 activity has been observed across defense companies that support United States, European Union, and Israeli government partners producing military-grade radars, drone technology, satellite systems, and emergency response communication systems. Further activity has targeted customers in geographic information systems (GIS), spatial analytics, regional ports of entry in the Persian Gulf, and several maritime and cargo transportation companies with a business focus in the Middle East.

This activity likely supports the national interests of the Islamic Republic of Iran based on pattern-of-life analysis, extensive crossover in geographic and sectoral targeting with Iranian actors, and alignment of techniques and targets with another actor originating in Iran. Microsoft assesses this targeting supports Iranian government tracking of adversary security services and maritime shipping in the Middle East to enhance their contingency plans. Gaining access to commercial satellite imagery and proprietary shipping plans and logs could help Iran compensate for its developing satellite program. Given Iran’s past cyber and military attacks against shipping and maritime targets, Microsoft believes this activity increases the risk to companies in these sectors, and we encourage our customers in these industries and geographic regions to review the information shared in this blog to defend themselves from this threat.

DEV-0343 conducts extensive password sprays emulating a Firefox browser and using IPs hosted on a Tor proxy network. They are most active between Sunday and Thursday between 7:30 AM and 8:30 PM Iran Time (04:00:00 and 17:00:00 UTC) with significant drop-offs in activity before 7:30 AM and after 8:30 PM Iran Time. They typically target dozens to hundreds of accounts within an organization, depending on the size, and enumerate each account from dozens to thousands of times. On average, between 150 and 1,000+ unique Tor proxy IP addresses are used in attacks against each organization.

DEV-0343 operators typically target two Exchange endpoints – Autodiscover and ActiveSync – as  a feature of the enumeration/password spray tool they use. This allows DEV-0343 to validate active accounts and passwords, and further refine their password spray activity.

Observed behaviors

DEV-0343 uses an elaborate series of Tor IP addresses to obfuscate their operational infrastructure. Because of this, there are no static set of indicators of compromise (IOCs) for us to share tied to this activity. The list below provides a series of behaviors and tactics we have observed being used by the attackers. We encourage our customers to use this information to look for similar patterns in logs and network activity to identify areas for further investigation.

• Extensive inbound traffic from Tor IP addresses for password spray campaigns
• Emulation of FireFox (most common) or Chrome browsers in password spray campaigns
• Enumeration of Exchange ActiveSync (most common) or Autodiscover endpoints
• Use of enumeration/password spray tool similar to the ‘o365spray’ tool hosted at https://github.com/0xZDH/o365spray
• Use of Autodiscover to validate accounts and passwords
• Observed password spray activity commonly peaking between 04:00:00 and 11:00:00 UTC

Recommended defenses

The following guidance can mitigate the techniques described in the threat activity:

• Enable multifactor authentication to mitigate compromised credentials.
  • For Office 365 users, see multifactor authentication support.
  • For Consumer and Personal email accounts, see how to use two step verification.
• Microsoft strongly encourages all customers to download and use passwordless solutions like Microsoft Authenticator to secure accounts.
• Review and enforce recommended Exchange Online access policies.
  • Block ActiveSync clients from bypassing Conditional Access policies.
• Block all incoming traffic from anonymizing services where possible.

Advanced hunting queries

Microsoft 365 Defender

To locate related activity, run the following advanced hunting queries in Microsoft 365 Defender:

AlertInfo
| where Title in~('Unusual sequence of failed logons to Exchange services',
'Unusual sequence of failed logons',
'Password spraying')
| join AlertEvidence on AlertId

Azure Sentinel

Azure Sentinel customers can use the following detection queries to look for this activity:

The query below identifies evidence of password sprays activity where ClientAppUsed is either Exchange ActiveSync or Autodiscover and emulated browser is Chrome or Firefox. The query is leveraging Azure AD data to look for failures from multiple accounts from the same IP address within a time window. Details on whether there were successful authentications by the IP address within the time window are also included.  This can be an indicator that an attack was successful. The default failure account threshold is 5 and the default time window for failures is 20m.

let timeRange = 3d;
let lookBack = 7d;
let authenticationWindow = 20m;
let authenticationThreshold = 5;
let isGUID = "[0-9a-z]{8}-[0-9a-z]{4}-[0-9a-z]{4}-[0-9a-z]{4}-[0-9a-z]{12}";
let failureCodes = dynamic([50053, 50126]); // invalid password, account is locked - too many sign ins, expired password
let successCodes = dynamic([0, 50055, 50057, 50155, 50105, 50133, 50005, 50076, 50079, 50173, 50158, 50072, 50074, 53003, 53000, 53001, 50129]);
let ClientApps = dynamic(["AutoDiscover","Exchange ActiveSync"]);
let BrowserList = dynamic(["Chrome","Firefox "]);
// Lookup up resolved identities from last 7 days
let aadFunc = (tableName:string){
let identityLookup = table(tableName)
| where TimeGenerated >= ago(lookBack)
| where not(Identity matches regex isGUID)
| where isnotempty(UserId)
| summarize by UserId, lu_UserDisplayName = UserDisplayName, lu_UserPrincipalName = UserPrincipalName, Type;
// collect window threshold breaches
table(tableName)
| where TimeGenerated > ago(timeRange)
| where ResultType in(failureCodes)
| summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated), make_set(ClientAppUsed), count() by bin(TimeGenerated, authenticationWindow), IPAddress, AppDisplayName, UserPrincipalName, Type
| summarize FailedPrincipalCount = dcount(UserPrincipalName) by bin(TimeGenerated, authenticationWindow), IPAddress, AppDisplayName, Type
| where FailedPrincipalCount >= authenticationThreshold
| summarize WindowThresholdBreaches = count() by IPAddress, Type
| join kind= inner (
// where we breached a threshold, join the details back on all failure data
table(tableName)
| where TimeGenerated > ago(timeRange)
| where ResultType in(failureCodes)
| extend LocationDetails = todynamic(LocationDetails)
| extend FullLocation = strcat(LocationDetails.countryOrRegion,'|', LocationDetails.state, '|', LocationDetails.city)
| extend DeviceDetail = todynamic(DeviceDetail)
| extend Browser = DeviceDetail.browser
| summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated), make_set(ClientAppUsed), make_set(FullLocation), make_set(Browser), FailureCount = count() by IPAddress, AppDisplayName, UserPrincipalName, UserDisplayName, Identity, UserId, Type
// lookup any unresolved identities
| extend UnresolvedUserId = iff(Identity matches regex isGUID, UserId, "")
| join kind= leftouter (
identityLookup
) on $left.UnresolvedUserId==$right.UserId
| extend UserDisplayName=iff(isempty(lu_UserDisplayName), UserDisplayName, lu_UserDisplayName)
| extend UserPrincipalName=iff(isempty(lu_UserPrincipalName), UserPrincipalName, lu_UserPrincipalName)
| summarize StartTime = min(StartTime), EndTime = max(EndTime), make_set(UserPrincipalName), make_set(UserDisplayName), make_set(set_ClientAppUsed), make_set(set_Browser), make_set(set_FullLocation), make_list(FailureCount) by IPAddress, AppDisplayName, Type
| extend FailedPrincipalCount = arraylength(set_UserPrincipalName)
) on IPAddress
| project IPAddress, StartTime, EndTime, TargetedApplication=AppDisplayName, FailedPrincipalCount, UserPrincipalNames=set_UserPrincipalName, UserDisplayNames=set_UserDisplayName, ClientAppUsed=set_set_ClientAppUsed, Locations=set_set_FullLocation, FailureCountByPrincipal=list_FailureCount, WindowThresholdBreaches, Type, Browsers = set_set_Browser
| join kind= inner (
table(tableName) // get data on success vs. failure history for each IP
| where TimeGenerated > ago(timeRange)
| where ResultType in(successCodes) or ResultType in(failureCodes) // success or failure types
| summarize GlobalSuccessPrincipalCount = dcountif(UserPrincipalName, (ResultType in(successCodes))), ResultTypeSuccesses = make_set_if(ResultType, (ResultType in(successCodes))), GlobalFailPrincipalCount = dcountif(UserPrincipalName, (ResultType in(failureCodes))), ResultTypeFailures = make_set_if(ResultType, (ResultType in(failureCodes))) by IPAddress, Type
| where GlobalFailPrincipalCount > GlobalSuccessPrincipalCount // where the number of failed principals is greater than success - eliminates FPs from IPs who authenticate successfully alot and as a side effect have alot of failures
) on IPAddress
| project-away IPAddress1
| extend timestamp=StartTime, IPCustomEntity = IPAddress
};
let aadSignin = aadFunc("SigninLogs");
let aadNonInt = aadFunc("AADNonInteractiveUserSignInLogs");
union isfuzzy=true aadSignin, aadNonInt
| where Browsers has_any (BrowserList)
| where ClientAppUsed has_any (ClientApps)

One of the results that the query surfaces is the IPAddress field from where the sign-in originated. Customers can leverage their threat intel data that have details about the TOR exit nodes to join with this query and make it even higher fidelity. It is often worthwhile to have a list of all the known TOR exit nodes so that these could be used for matching with queries of Azure Sentinel, or to block sign-ins from the TOR exit nodes using conditional access. Azure Sentinel also provides playbooks that can leverage third party providers of TOR information like Big Data Cloud to synchronize the list of known TOR exit nodes on an hourly basis.  Here is the link to one such playbook: https://github.com/Azure/Azure-Sentinel/blob/master/Playbooks/Update-NamedLocations-TOR/readme.md.

Next, we have another hunting query that identifies instances where a single user account has seen a high incidence of failed attempts from highly volatile IP addresses. Changing the IP address for every password attempt is becoming a more common technique among sophisticated threat groups. Often, threat groups randomize the user agent they are using as well as IP address. This technique has been enabled by the emergence of services providing huge numbers of residential IP addresses. These services are often enabled through malicious browser plugins. This query is best executed over longer timeframes. Results with the highest “IPs”, “Failures” and “DaysWithAttempts” are good candidates for further investigation. This query intentionally does not cluster on UserAgent, IP, etc. This query is clustering on the highly volatile IP behavior.

let timeRange = 14d;
let UnsuccessfulLoginCountryThreshold = 5; // Number of failed countries attempting to login, good way to filter.
let ClientApps = dynamic(["AutoDiscover","Exchange ActiveSync"]);
let BrowserList = dynamic(["Chrome","Firefox "]);
SigninLogs
| where TimeGenerated > ago(timeRange)
// Limit to username/password failure errors, most common when bruteforcing/spraying
| where ResultType has_any("50126", "50053")
//Narrowing the result even further to clientapps and browser that are seen in this attack.
| where ClientAppUsed has_any (ClientApps)
| extend Browser = tostring(DeviceDetail.browser)
| where Browser has_any (BrowserList)
// Find instances where an IP has only been used once
| summarize IPLogins=count(), make_list(TimeGenerated) by IPAddress, Location, UserPrincipalName
| where IPLogins == 1
// We only keep instances where there is 1 event, so we know there will only be one datetime in the list
| extend LoginAttemptTime = format_datetime(todatetime(list_TimeGenerated[0]), 'dd-MM-yyyy')
// So far we've only collected failures, we join back to the log to ensure there were no successful logins from the IP
| join kind=leftouter (
SigninLogs
| where TimeGenerated > ago(timeRange)
| where ResultType == 0
| summarize count() by IPAddress, UserPrincipalNameSuccess=UserPrincipalName
) on $left.IPAddress == $right.IPAddress
// Where there have been fewer than 2 successful logins from the IP
| where count_ < 2 or isempty(count_)
// Confirm that the result is for the same account where possible
| where UserPrincipalName == UserPrincipalNameSuccess or isempty(UserPrincipalNameSuccess)
// Summarize the collected details around the users email address
| summarize IPs=dcount(IPAddress), UnsuccessfulLoginCountryCount=dcount(Location), make_list(IPAddress), make_list(Location), DaysWithAttempts=dcount(LoginAttemptTime), Failures=count() by UserPrincipalName
| project UserPrincipalName, Failures, IPs, UnsuccessfulLoginCountryCount, DaysWithAttempts, IPAddresses=list_IPAddress, IPAddressLocations=list_Location
// Join back to get countries the user has successfully authenticated from to compare with failures
| join kind=leftouter (
SigninLogs
| where TimeGenerated > ago(timeRange)
| where ResultType == 0
// If there is no location make the output pretty
| extend Location = iff(isempty(Location), "NODATA", Location)
| summarize SuccessfulLoginCountries=make_set(Location), SuccessfulLoginCountryCount=dcount(Location) by UserPrincipalName
) on $left.UserPrincipalName == $right.UserPrincipalName
| project-away UserPrincipalName1
| order by UnsuccessfulLoginCountryCount desc
// Calculate the difference between countries with successful vs. failed logins
| extend IPIncreaseOnSuccess = UnsuccessfulLoginCountryCount - SuccessfulLoginCountryCount
// The below line can be removed if the actor is using IPs in one country
| where UnsuccessfulLoginCountryCount > UnsuccessfulLoginCountryThreshold
| project UserPrincipalName, Failures, IPs, DaysWithAttempts, UnsuccessfulLoginCountryCount, UnuccessfulLoginCountries=IPAddressLocations, SuccessfulLoginCountries, FailureIPAddresses=IPAddresses

The post Iran-linked DEV-0343 targeting defense, GIS, and maritime sectors appeared first on Microsoft Security Blog.