Microsoft attributes this activity with high confidence to Diamond Sleet, a North Korean threat actor. The second-stage payload observed in this campaign communicates with infrastructure that has been previously compromised by Diamond Sleet. More recently, Microsoft has observed Diamond Sleet utilizing trojanized open-source and proprietary software to target organizations in information technology, defense, and media.

To address the potential risk of further attacks against our customers, Microsoft has taken the following steps to protect customers in response to this malicious activity:

• Microsoft has communicated this supply chain compromise to CyberLink 
• Microsoft is notifying Microsoft Defender for Endpoint customers that have been targeted or compromised in this campaign
• Microsoft reported the attack to GitHub, which removed the second-stage payload in accordance with its Acceptable Use Policies
• Microsoft has added the CyberLink Corp. certificate used to sign the malicious file to its disallowed certificate list
• Microsoft Defender for Endpoint detects this activity as Diamond Sleet activity group.
• Microsoft Defender Antivirus detects the malware as Trojan:Win32/LambLoad.

Microsoft may update this blog as additional insight is gained into the tactics, techniques, and procedures (TTPs) used by the threat actor in this active and ongoing campaign.

Who is Diamond Sleet?

The actor that Microsoft tracks as Diamond Sleet (formerly ZINC) is a North Korea-based activity group known to target media, defense, and information technology (IT) industries globally. Diamond Sleet focuses on espionage, theft of personal and corporate data, financial gain, and corporate network destruction. Diamond Sleet is known to use a variety of custom malware that is exclusive to the group. Recent Diamond Sleet malware is described in Microsoft’s reporting of the group’s weaponization of open source software and exploitation of N-day vulnerabilities. Diamond Sleet overlaps with activity tracked by other security companies as Temp.Hermit and Labyrinth Chollima.

Activity overview

Microsoft has observed suspicious activity associated with the modified CyberLink installer file as early as October 20, 2023. The malicious file has been seen on over 100 devices in multiple countries, including Japan, Taiwan, Canada, and the United States. While Microsoft has not yet identified hands-on-keyboard activity carried out after compromise via this malware, the group has historically:

• Exfiltrated sensitive data from victim environments
• Compromised software build environments
• Moved downstream to additional victims for further exploitation
• Used techniques to establish persistent access to victim environments

Diamond Sleet utilized a legitimate code signing certificate issued to CyberLink Corp. to sign the malicious executable. This certificate has been added to Microsoft’s disallowed certificate list to protect customers from future malicious use of the certificate:

Signer: CyberLink Corp. 
Issuer: DigiCert SHA2 Assured ID Code Signing CA 
SignerHash: 8aa3877ab68ba56dabc2f2802e813dc36678aef4 
CertificateSerialNumber: 0a08d3601636378f0a7d64fd09e4a13b

Microsoft currently tracks the malicious application and associated payloads as LambLoad.

LambLoad

LambLoad is a weaponized downloader and loader containing malicious code added to a legitimate CyberLink application. The primary LambLoad loader/downloader sample Microsoft identified has the SHA-256 hash 166d1a6ddcde4e859a89c2c825cd3c8c953a86bfa92b343de7e5bfbfb5afb8be.

Before launching any malicious code, the LambLoad executable ensures that the date and time of the local host align with a preconfigured execution period.

The loader then targets environments that are not using security software affiliated with FireEye, CrowdStrike, or Tanium by checking for the following process names:

• csfalconservice.exe (CrowdStrike Falcon)
• xagt.exe (FireEye agent)
• taniumclient.exe (Tanium EDR solution)

If these criteria are not met, the executable continues running the CyberLink software and abandons further execution of malicious code. Otherwise, the software attempts to contact one of three URLs to download the second-stage payload embedded inside a file masquerading as a PNG file using the static User-Agent ‘Microsoft Internet Explorer’:

• hxxps[:]//i.stack.imgur[.]com/NDTUM.png
• hxxps[:]//www.webville[.]nethttps://www.microsoft.com/images/CL202966126.png
• hxxps[:]//cldownloader.github[.]io/logo.png

The PNG file contains an embedded payload inside a fake outer PNG header that is, carved, decrypted, and launched in memory.

When invoked, the in-memory executable attempts to contact the following callbacks for further instruction. Both domains are legitimate but have been compromised by Diamond Sleet:

• hxxps[:]//mantis.jancom[.]pl/bluemantis/image/addon/addin.php
• hxxps[:]//zeduzeventos.busqueabuse[.]com/wp-adminhttps://www.microsoft.com/js/widgets/sub/wids.php

The crypted contents of the PNG file (SHA-256: 089573b3a1167f387dcdad5e014a5132e998b2c89bff29bcf8b06dd497d4e63d) may be manually carved using the following command:

To restore the in-memory payload statically for independent analysis, the following Python script can be used to decrypt the carved contents.

To crypt and verify:

Both the fake PNG and decrypted PE payload have been made available on VirusTotal.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

• Use Microsoft Defender Antivirus to protect from this threat. Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• 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, significantly reducing alert volume.
• Take immediate action to address malicious activity on the impacted device. If malicious code has been launched, the attacker has likely taken complete control of the device. Immediately isolate the system and perform a reset of credentials and tokens.
• Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities. Ensure data integrity with hash codes.
• Turn on the following attack surface reduction rule: Block executable files from running unless they meet a prevalence, age, or trusted list criterion.

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Trojan:Win32/LambLoad.A!dha
• Trojan:Win32/LambLoad.B!dha
• Trojan:Win32/LambLoad.C!dha
• Trojan:Win64/LambLoad.D!dha
• Trojan:Win64/LambLoad.E!dha

Microsoft Defender for Endpoint

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

• Diamond Sleet activity group

The following alert might also indicate threat activity related to this threat. Note, however, that this alert can be also triggered by unrelated threat activity.

• An executable loaded an unexpected dll

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Diamond Sleet
• Diamond Sleet supply chain compromise at distributes a modified CyberLink installer

Microsoft Defender XDR Threat analytics 

• Actor profile: Diamond Sleet
• Activity profile: Diamond Sleet supply chain compromise at distributes a modified CyberLink installer

Hunting queries

Microsoft Defender XDR  

Microsoft Defender XDR (formerly Microsoft 365 Defender) customers can run the following query to find related activity in their networks:

let iocs = dynamic(["166d1a6ddcde4e859a89c2c825cd3c8c953a86bfa92b343de7e5bfbfb5afb8be",
"089573b3a1167f387dcdad5e014a5132e998b2c89bff29bcf8b06dd497d4e63d",
"915c2495e03ff7408f11a2a197f23344004c533ff87db4b807cc937f80c217a1"]);
DeviceFileEvents
| where ActionType == "FileCreated"
| where SHA256 in (iocs)
| project Timestamp, DeviceName, FileName, FolderPath, SHA256

Microsoft Defender XDR and Microsoft Sentinel

This query can be used in both Microsoft Defender XDR advanced hunting and Microsoft Sentinel Log Analytics. It surfaces devices where the modified CyberLink installer can be found.

DeviceFileCertificateInfo
| where Signer contains "CyberLink Corp"
| where CertificateSerialNumber == "0a08d3601636378f0a7d64fd09e4a13b"
| where SignerHash == "8aa3877ab68ba56dabc2f2802e813dc36678aef4"
| join DeviceFileEvents on SHA1
| distinct DeviceName, FileName, FolderPath, SHA1, SHA256, IsTrusted, IsRootSignerMicrosoft, SignerHash

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

The following YAMLs contain queries that surface activities related to this attack:

• Uncommon processes
• Windows installer packages
• Process entropy
• Rare process path
• Device network events with low-count FQDN

Indicators of compromise

The list below 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.

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

The post Diamond Sleet supply chain compromise distributes a modified CyberLink installer appeared first on Microsoft Security Blog.

In past operations, Diamond Sleet and other North Korean threat actors have successfully carried out software supply chain attacks by infiltrating build environments. Given this, Microsoft assesses that this activity poses a particularly high risk to organizations who are affected. JetBrains has released an update to address this vulnerability and has developed a mitigation for users who are unable to update to the latest software version.

While the two threat actors are exploiting the same vulnerability, Microsoft observed Diamond Sleet and Onyx Sleet utilizing unique sets of tools and techniques following successful exploitation. Based on the profile of victim organizations affected by these intrusions, Microsoft assesses that the threat actors may be opportunistically compromising vulnerable servers. However, both actors have deployed malware and tools and utilized techniques that may enable persistent access to victim environments.

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

Who are Diamond Sleet and Onyx Sleet?

Diamond Sleet (ZINC) is a North Korean nation-state threat actor that prioritizes espionage, data theft, financial gain, and network destruction. The actor typically targets media, IT services, and defense-related entities around the world. Microsoft reported on Diamond Sleet’s targeting of security researchers in January 2021 and the actor’s weaponizing of open-source software in September 2022. In August 2023, Diamond Sleet conducted a software supply chain compromise of a German software provider.

Onyx Sleet (PLUTONIUM) is a North Korean nation-state threat actor that primarily targets defense and IT services organizations in South Korea, the United States, and India. Onyx Sleet employs a robust set of tools that they have developed to establish persistent access to victim environments and remain undetected. The actor frequently exploits N-day vulnerabilities as a means of gaining initial access to targeted organizations.

Diamond Sleet attack path 1: Deployment of ForestTiger backdoor

Following the successful compromise of TeamCity servers, Diamond Sleet utilizes PowerShell to download two payloads from legitimate infrastructure previously compromised by the threat actor. These two payloads, Forest64.exe and 4800-84DC-063A6A41C5C are stored in the C:\ProgramData directory.

When launched, Forest64.exe checks for the presence of the file named 4800-84DC-063A6A41C5C, then reads and decrypts the contents of that file using embedded, statically assigned key of ‘uTYNkfKxHiZrx3KJ’:

c:\ProgramData\Forest64.exe  uTYNkfKxHiZrx3KJ

Interestingly, this same value is specified as a parameter when the malware is invoked, but we did not see it utilized during our analysis. The same value and configuration name was also referenced in historical activity reported by Kaspersky’s Securelist on this malware, dubbed ForestTiger.

The decrypted content of 4800-84DC-063A6A41C5C is the configuration file for the malware, which contains additional parameters, such as the infrastructure used by the backdoor for command and control (C2). Microsoft observed Diamond Sleet using infrastructure previously compromised by the actor for C2.

Microsoft observed Forest64.exe then creating a scheduled task named Windows TeamCity Settings User Interface so it runs every time the system starts with the above referenced command parameter “uTYNkfKxHiZrx3KJ”. Microsoft also observed Diamond Sleet leveraging the ForestTiger backdoor to dump credentials via the LSASS memory. Microsoft Defender Antivirus detects this malware as ForestTiger.

Diamond Sleet attack path 2: Deploying payloads for use in DLL search-order hijacking attacks

Diamond Sleet leverages PowerShell on compromised servers to download a malicious DLL from attacker infrastructure. This malicious DLL is then staged in C:\ProgramData\ alongside a legitimate .exe file to carry out DLL search-order hijacking. Microsoft has observed these malicious DLL and legitimate EXE combinations used by the actor:

DSROLE.dll attack chain

When DSROLE.dll is loaded by wsmprovhost.exe, the DLL initiates a thread that enumerates and attempts to process files that exist in the same executing directory as the DLL. The first four bytes of candidate files are read and signify the size of the remaining buffer to read. Once the remaining data is read back, the bytes are reversed to reveal an executable payload that is staged in memory. The expected PE file should be a DLL with the specific export named ‘StartAction’. The address of this export is resolved and then launched in memory.

While the functionality of DSROLE.dll is ultimately decided by whatever payloads it deobfuscates and launches, Microsoft has observed the DLL being used to launch wksprt.exe, which communicates with C2 domains. Microsoft Defender Antivirus detects DSROLE.dll using the family name RollSling.

Version.dll attack chain

When loaded by clip.exe, Version.dll loads and decrypts the contents of readme.md, a file  downloaded alongside Version.dll from attacker-compromised infrastructure. The file readme.md contains data that is used as a multibyte XOR key to decrypt position-independent code (PIC) embedded in Version.dll. This PIC loads and launches the final-stage remote access trojan (RAT).

Once loaded in memory, the second-stage executable decrypts an embedded configuration file containing several URLs used by the malware for command and control. Shortly after the malware beacons to the callback URL, Microsoft has observed a separate process iexpress.exe created and communicating with other C2 domains. Microsoft Defender Antivirus detects Version.dll using the family name FeedLoad.

After successful compromise, Microsoft observed Diamond Sleet dumping credentials via the LSASS memory.

In some cases, Microsoft observed Diamond Sleet intrusions that utilized tools and techniques from both paths 1 and 2.

Onyx Sleet attack path: User account creation, system discovery, and payload deployment

Following successful exploitation using the TeamCity exploit, Onyx Sleet creates a new user account on compromised systems. This account, named krtbgt, is likely intended to impersonate the legitimate Windows account name KRBTGT, the Kerberos Ticket Granting Ticket. After creating the account, the threat actor adds it to the Local Administrators Group through net use:

net  localgroup administrators krtbgt /add

The threat actor also runs several system discovery commands on compromised systems, including:

net localgroup 'Remote Desktop Users’
net localgroup Administrators
cmd.exe "/c tasklist | findstr Sec"
cmd.exe "/c whoami"
cmd.exe "/c netstat -nabp tcp"
cmd.exe "/c ipconfig /all"
cmd.exe "/c systeminfo"

Next, the threat actor deploys a unique payload to compromised systems by downloading it from attacker-controlled infrastructure via PowerShell. Microsoft observed these file paths for the unique payload:

• C:\Windows\Temp\temp.exe
• C:\Windows\ADFS\bg\inetmgr.exe

This payload, when launched, loads and decrypts an embedded PE resource. This decrypted payload is then loaded into memory and launched directly. The inner payload is a proxy tool that helps establish a persistent connection between the compromised host and attacker-controlled infrastructure. Microsoft Defender Antivirus detects this proxy tool as HazyLoad.

Microsoft also observed the following post-compromise tools and techniques leveraged in this attack path:

• Using the attacker-controlled krtbgt account to sign into the compromised device via remote desktop protocol (RDP)
• Stopping the TeamCity service, likely in an attempt to prevent access by other threat actors
• Dumping credentials via the LSASS memory
• Deploying tools to retrieve credentials and other data stored by browsers

Recommended mitigation actions

Microsoft recommends the following mitigations to reduce the impact of this threat.

• Apply the update or mitigations released by JetBrains to address CVE-2023-42793.
• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Block in-bound traffic from IPs specified in the IOC table.
• Use Microsoft Defender Antivirus to protect from this threat. Turn on cloud-delivered protection and automatic sample submission. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Take immediate action to address malicious activity on the impacted device. If malicious code has been launched, the attacker has likely taken complete control of the device. Immediately isolate the system and perform a reset of credentials and tokens.
• Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities.
• Ensure that “Safe DLL Search Mode” is set.
• Turn on the following attack surface reduction rule:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Detections

Microsoft 365 Defender

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the CVE-2023-42793 vulnerability leveraged in these attacks.

Microsoft Defender Antivirus

Microsoft Defender Antivirus customers should look for the following family names for activity related to these attacks:

• ForestTiger
• RollSling
• FeedLoad
• HazyLoad

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts could indicate activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Diamond Sleet Actor activity detected
• Onyx Sleet Actor activity detected
• Possible exploitation of JetBrains TeamCity vulnerability
• Suspicious behavior by cmd.exe was observed
• Suspicious DLL loaded by an application
• Suspicious PowerShell download or encoded command execution
• Possible lateral movement involving suspicious file
• A script with suspicious content was observed
• Suspicious scheduled task

Hunting queries

Microsoft 365 Defender

Command and control using iexpress.exe or wksprt.exe

DeviceNetworkEvents
| where (InitiatingProcessFileName =~ "wksprt.exe" and InitiatingProcessCommandLine == "wksprt.exe") 
or (InitiatingProcessFileName =~ "iexpress.exe" and InitiatingProcessCommandLine == "iexpress.exe")

Search order hijack using Wsmprovhost.exe and DSROLE.dll

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "wsmprovhost.exe"
| where FileName =~ "DSROLE.dll"
| where not(FolderPath has_any("system32", "syswow64"))

Search order hijack using clip.exe and Version.dll

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "clip.exe"
| where FileName in~("version.dll")
| where not(FolderPath has_any("system32", "syswow64", "program files", "windows defender\\platform", "winsxs", "platform",
"trend micro"))

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.  

• PowerShell downloads
• Dumping LSASS Process into a File
• Anomalous Account Creation
• RDP Rare Connection
• Anomalous RDP Activity

Indicators of compromise (IOCs)

The list below 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.

Diamond Sleet path 1

Diamond Sleet path 2

Onyx Sleet path

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

References

• Following the Lazarus group by tracking DeathNote campaign | Securelist

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Multiple North Korean threat actors exploiting the TeamCity CVE-2023-42793 vulnerability appeared first on Microsoft Security Blog.

We assessed the vulnerable component to be the Boa web server, which is often used to access settings and management consoles and sign-in screens in devices. Despite being discontinued in 2005, the Boa web server continues to be implemented by different vendors across a variety of IoT devices and popular software development kits (SDKs). Without developers managing the Boa web server, its known vulnerabilities could allow attackers to silently gain access to networks by collecting information from files. Moreover, those affected may be unaware that their devices run services using the discontinued Boa web server, and that firmware updates and downstream patches do not address its known vulnerabilities.

In this blog, we detail the risks affiliated with vulnerable components, highlighting the Boa web server, and how we suspect these components could be exploited to target critical industries. We also discuss the difficulties with identifying these components in device supply chains. To provide comprehensive protection against such attacks, we offer detection information to identify vulnerable components and guidance for organizations and network operators to improve their security posture.

Investigating the attack activity

The attack detailed in the Recorded Future report was one of several intrusion attempts on Indian critical infrastructure since 2020, with the most recent attack on IT assets confirmed in October 2022. Microsoft assesses that Boa servers were running on the IP addresses on the list of IOCs published by Recorded Future at the time of the report’s release and that the electrical grid attack targeted exposed IoT devices running Boa.

Microsoft further identified that half of the IP addresses published by Recorded Future returned suspicious HTTP response headers, which might be associated with the active deployment of the malicious tool identified by Recorded Future. The combination of Boa and suspicious response headers was identified on another set of IP addresses, displaying similar behavior to those found by Recorded Future. While these IP addresses are not confirmed as malicious, we recommend they be monitored to ensure no additional suspicious activity. Users of Microsoft Defender Threat Intelligence will find these IP addresses in the portal labeled as block-listed or suspicious:

• 122[.]117[.]212[.]65
• 103[.]58[.]93[.]133
• 125[.]141[.]38[.]53
• 14[.]45[.]33[.]239
• 14[.]55[.]86[.]138
• 183[.]108[.]133[.]29
• 183[.]99[.]53[.]180
• 220[.]94[.]133[.]121
• 58[.]76[.]177[.]166

Investigating the headers further indicated that over 10% of all active IP addresses returning the headers were related to critical industries, such as the petroleum industry and associated fleet services, with many of the IP addresses associated to IoT devices, such as routers, with unpatched critical vulnerabilities, highlighting an accessible attack vector for malware operators. Most of the suspicious HTTP response headers were returned over a short timeframe of several days, leading researchers to believe they may be associated with intrusion and malicious activity on networks.

Since the report’s publication, Microsoft researchers tracking the published IPs hosts have observed that all IP addresses have been compromised by a variety of attackers employing different malicious methods. For example, some of the IP addresses were further leveraged to download a variant of the Mirai malware family shortly following the report’s release. Microsoft also found evidence that across different devices on the IP addresses, there were attempts to connect with default credentials through brute force methods and attempts to run shell commands. Microsoft continues to see attackers attempting to exploit Boa vulnerabilities beyond the timeframe of the released report, indicating that it is still targeted as an attack vector.

Boa widespread through SDKs

The Boa web server is widely implemented across a variety of devices, including IoT devices ranging from routers to cameras, and is often used to access settings and management consoles as well as sign-in screens. The popularity of Boa web servers is especially concerning as Boa has been formally discontinued since 2005. Data from the Microsoft Defender Threat Intelligence platform identified over 1 million internet-exposed Boa server components around the world over the span of a week, as depicted in the below figure:

Boa web servers remain pervasive in the development of IoT devices, one reason for this could be its inclusion in popular SDKs, which contain essential functions that operate system on chip (SOC) implemented in microchips. Vulnerable components like Boa and SDKs are often distributed to customers within devices, contributing to supply chain vulnerabilities. Popular SDKs like those released by RealTek, are used in SOCs provided to companies that manufacture gateway devices like routers, access points, and repeaters. Critical vulnerabilities such as CVE-2021-35395, which affected the digital administration of devices using RealTek’s SDK, and CVE-2022-27255, a zero-click overflow vulnerability, reportedly affect millions of devices globally and allow attackers to launch code, compromise devices, deploy botnets, and move laterally on networks.

While patches for the RealTek SDK vulnerabilities are available, some vendors may not have included them in their device firmware updates, and the updates do not include patches for Boa vulnerabilities. Boa servers are affected by several known vulnerabilities, including CVE-2009-4496, which could allow attackers to execute code remotely. Additional vendor and device specific vulnerabilities exist across a range of devices including routers.

The popularity of the Boa web server displays the potential exposure risk of an insecure supply chain, even when security best practices are applied to devices in the network. Updating the firmware of IoT devices does not always patch SDKs or specific SOC components and there is limited visibility into components and whether they can be updated. The known CVEs impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials. In critical infrastructure networks, being able to collect information undetected prior to the attack allows the attackers to have much greater impact once the attack is initiated, potentially disrupting operations that can cost millions of dollars and affect millions of people.

Recommendations

As attackers seek new footholds into increasingly secure devices and networks, identifying and preventing distributed security risks through software and hardware supply chains, like outdated components, should be prioritized by organizations. This case displays the importance of proactive cyber security practices and the need to identify vulnerable components that may be leveraged by attackers.

Microsoft recommends that organizations and network operators follow best practice guidelines for their networks:

• Patch vulnerable devices whenever possible to reduce exposure risks across your organization.
• Utilize device discovery and classification to identify devices with vulnerable components by enabling vulnerability assessments, which identifies unpatched devices in the organizational network and set workflows for initiating appropriate patch processes with solutions like Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with Microsoft Defender for IoT .
• Extend vulnerability and risk detection beyond the firewall with platforms like Microsoft Defender External Attack Surface Management. Customers can identify internet-exposed infrastructure running Boa web server components in their inventory and use the insights tile under the Attack Surface Summary dashboard to surface assets vulnerable to CVE-2009-4496. The insight can be found under High Severity Observations.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices in the network. Apply network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT and critical device networks should be isolated with firewalls.
• Use proactive antivirus scanning to identify malicious payloads on devices.
• Configure detection rules to identify malicious activity whenever possible. Security personnel can use our snort rule below to configure security solutions to detect CVE-2022-27255 on assets using the RealTek SDK.

alert udp any any -> any any (msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; content: "invite"; depth: 6; nocase;  content: "sip:"; content: "m=audio "; isdataat: 128,relative;   content:!"|0d|"; within: 128;sid:20221031;)

• Adopt a comprehensive IoT and OT solution like Microsoft Defender for IoT to monitor devices, respond to threats, and increase visibility in order to detect and alert when IoT devices with Boa are used as an entry point to a network and protect critical infrastructure. 

Adam Castleman, Jordan Herman, Microsoft Defender Threat Intelligence
Rotem Sde Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center

The post Vulnerable SDK components lead to supply chain risks in IoT and OT environments appeared first on Microsoft Security Blog.

The attack brings to light the risk of threat actors gaining access to industrial control system (ICS) environments. According to reports, a group associated with the Cl0p ransomware claimed responsibility for the attack, which followed a familiar extortion model wherein attackers extort the target for exfiltrated data without encrypting the organization’s files. After the attack, confidential documents, along with screenshots of the supervisory control and data acquisition (SCADA) system used by water treatment plants were leaked.

As details of the attack and the vector used to access South Staffordshire PLC’s networks are limited, the Microsoft Defender for IoT research team did further research on techniques used by threat actors in similar attacks. Microsoft researchers have previously observed activity relating to internet-exposed IoT devices across different industries, which may be used as a potential foothold into OT networks. Threat actors gain access by deploying malware on information technology (IT) devices and then crossing the boundary to the operational technology (OT) part of the network to target high-value operational assets, or by compromising unmanaged, usually less secure IoT and OT devices.

IoT devices in critical infrastructure networks

IoT devices offer significant value to organizations and extend beyond environmental monitoring sensors to common office equipment and network devices. However, IoT devices in critical infrastructure networks, if not properly secured, increase the risk of unauthorized access to operational assets and networks. Improper configurations such as default credentials and unpatched vulnerabilities are often abused by threat actors to gain network or device access. Once access is established, attackers could identify other assets on the same network, perform reconnaissance, and plan large-scale attacks on sensitive equipment and devices.

In monitoring threats against critical infrastructure and utilities, Microsoft researchers investigated water utility providers in the United Kingdom with exposed IoT devices within their networks. Using open-source intelligence (OSINT) and Microsoft Defender Threat Intelligence data, the team searched for exposed IoT devices integrated into the networks of water utility providers and found that such facilities were using Draytek Vigor routers, which are intended for home use.

With difficult-to-patch devices such as printers, cameras, routers, and gateway devices overlooked as potential footholds into networks, they are often left exposed. In analyzing Microsoft threat intelligence, Microsoft researchers observed threat actors abusing a known remote code execution vulnerability in Draytek Vigor devices (CVE-2020-8515) to deploy the Mirai botnet. Once attackers establish device access, remote code execution vulnerabilities such as CVE-2020-8515 can then allow attackers to run malicious commands on devices, move laterally within the network, and access other vulnerable devices which were not directly exposed to the internet such as SCADA systems. 

In water treatment applications, SCADA systems allow water plants to monitor levels of specific chemicals and toxins and to collect records of the systems. While the attack against South Staffordshire PLC does not appear to have included the abuse of these devices, the release of files pertaining to OT systems constitutes a high-risk to operations and highlights the importance of network segmentation to protect devices and networks from lateral movement.

Defending critical networks

Attacks on utility providers’ OT networks and devices are high-risk events that can range from data theft to the manipulation of devices controlling the operations. Such events can lead to the interruption of operations, or in severe cases, potential harm to individuals and customers (For example, when hackers gained access to the water system of one Florida city as reported in February 2021).

Given the severity of these attacks and their potential impact on the utility providers’ operations and even the safety of their customers, it becomes crucial to recognize the importance of proper security practices around IoT & OT unmanaged devices to ensure that such attacks do not happen. Defenses set up for OT networks must be comprehensive, able to prevent unauthorized system access and should include detections for abnormal, unfamiliar, and malicious behaviors after a breach.

It is important to protect assets and have strict security protocols in place for how and when devices and data can be accessed. We recommend the following defense strategies for organizations with both IoT and OT devices within their networks:  

• Adopt a comprehensive IoT and OT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft Defender 365.
• Enable vulnerability assessments to identify unpatched devices in the organizational network and set workflows for initiating appropriate patch processes through  Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with the Microsoft Defender for IoT add-on.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices and OT control systems. Implement Zero Trust practices by applying network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT devices and OT networks should be isolated from IT and OT networks with firewalls. Extend vulnerability and exposure control beyond the firewall with Microsoft Defender External Attack Surface Management. Turn on attack surface reduction rules in Microsoft Defender for Endpoint to prevent common attack techniques such as those used by ransomware groups.
• Increase network security by enforcing multi factor authentication (MFA) methods such as Azure Active Directory MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

David Atch, Ilana Sivan, and Mae Dotan, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)
Jaclyn Blumenfield, Microsoft Defender Threat Intelligence

The post Securing IoT devices against attacks that target critical infrastructure appeared first on Microsoft Security Blog.

Our investigation of this new Android malware version started from our receipt of an SMS message containing a malicious link that led us to the download of a fake banking rewards app. The fake app, detected as TrojanSpy:AndroidOS/Banker.O, used a different bank name and logo compared to a similar malware reported in 2021. Moreover, we found that this fake app’s command and control (C2) server is related to 75 other malicious APKs based on open-source intelligence. Some of the malicious APKs also use the same Indian bank’s logo as the fake app that we investigated, which could indicate that the actors are continuously generating new versions to keep the campaign going.

This blog details our analysis of the recent version’s capabilities. We strongly advise users never to click on unknown links received in SMS messages, emails, or messaging apps. We also recommend seeking your bank’s support or advice on digital options for your bank. Further, ensure that your banking apps are downloaded from official app stores to avoid installing malware.

Observed activity

What the user sees

We have seen other campaigns targeting Indian banks’ customers based on the following app names:

• Axisbank_rewards.apk
• Icici_points.apk
• Icici_rewards.apk
• SBI_rewards.apk

Our investigation focused on icici_rewards.apk (package name: com.example.test_app), which presents itself as ICICI Rewards. The SMS campaign sends out messages containing a malicious link that leads to installing a malicious APK on a target’s mobile device. To lure users into accessing the link, the SMS claims that the user is being notified to claim a reward from a known Indian bank.

Upon user interaction, it displays a splash screen with the bank logo and proceeds to ask the user to enable specific permissions for the app.

The fake app asks for credit card information upon being granted all permissions. This should raise users’ suspicions on the app’s motive as apps typically ask for sensitive information only through user-driven transactions like paying for purchases.

The app displays another fake screen with further instructions to add to its legitimacy once users supply the information needed.

What happens in the background

Analyzing the XML file AndroidManifest further identifies the entry points of the malware along with the permissions requested. It also defines services that can run in the background without user interaction. The app uses the following permissions:

• READ_PHONE_STATE
• ACCESS_NETWORK_STATE
• READ_SMS
• RECEIVE_SMS
• READ_CALL_LOG
• FOREGROUND_SERVICE
• MODIFY_AUDIO_SETTINGS
• READ_CONTACTS
• RECEIVE_BOOT_COMPLETED
• WAKE_LOCK

The malware uses MainActivity, AutoStartService, and RestartBroadCastReceiverAndroid functions to carry out most of its routines. These three functions interact to ensure all the malware’s routines are up and running and allow the app to remain persistent on the mobile device.

MainActivity

MainActivity, also called the launcher activity, is defined under com.example.test_app.MainActivity. It is launched first after installation to display the fake app’s ICICI splash screen. This launcher activity then calls OnCreate() method to check the device’s internet connectivity and record the timestamp of the malware’s installation, and Permission_Activity to launch permission requests. Once the permissions are granted, Permission_Activity further calls AutoStartService and login_kotak.

The class login_kotak is responsible for stealing the user’s card information. It shows the fake credit card input page (Figure 5) and temporarily stores the information in the device while waiting for commands from the attacker.

AutoStartService

AutoStartService, themain handler of the malware, functions based on the commands it receives. The handler provides the malware with the following capabilities:

Enforcing its RAT commands

This malware’s new version adds several RAT capabilities that expands its information stealing. It enables the malware to add call log uploading, SMS message and calls interception, and card blocking checks.

These commands are described below.

The silent command, which the malware uses to keep the remote attacker’s SMS sending activities undetected, stands out from the list of commands. Many banking apps require two-factor authentication (2FA), often sent through SMS messages. This malware enabling an infected device’s silent mode allows attackers to catch 2FA messages undetected, further facilitating information theft.

Encryption and decryption of SMS messages

In addition to encrypting all data it sends to the attacker, the malware also encrypts the SMS commands it receives from the attacker. The malware decrypts the commands through its decryption and decoding modules. The malware uses a combination of Base64 encoding/decoding and AES encryption/decryption methods.

Stealing SMS messages

The malware steals all SMS messages from the mobile device’s inbox. It collects all received, sent, read, and even unread messages. Collecting all SMS messages might allow attackers to use the data to expand their stealing range, especially if any messages contain other sensitive information such as SMS-based 2FA for email accounts, one’s personal identification like the Aadhar card commonly used in India, or other financial-related information.

Uploading all call logs

The malware also uploads call logs stored on the mobile device. This data may be used for the attacker’s surveillance purposes.

Communicating with its C2

This malware uses the open-source library socket.io to communicate with its C2 server.

RestartBroadCastReceiver

The malware also uses the Android component RestartBroadcastReceiver, which functions based on the type of events received by the mobile device. This receiver launches a job scheduler named JobService, which eventually calls AutoStartService in the background. The receiver reacts when the device is restarted, if the device is connected to or disconnected from charging, when the device’s battery status changes, and changes in the device’s Wi-Fi state.  RestartBroadcastReceiver ensures that the main command handler AutoStartService is always up and running.

Mitigating the fake app’s unwanted extras

This malware’s continuing evolution highlights the need to protect mobile devices. Its wider SMS stealing capabilities might allow attackers to the stolen data to further steal from a user’s other banking apps. Its ability to intercept one-time passwords (OTPs) sent over SMS thwarts the protections provided by banks’ two-factor authentication mechanisms, which users and institutions rely on to keep their transactions safe. Its use of various banking and financial organizations’ logos could also attract more targets in the future.

App installation on Android is relatively easy due to the operating system’s open nature. However, this openness is often abused by attackers for their gain. Apart from exercising utmost care when clicking on links in messages and installing apps, we recommend that users follow these steps to protect their devices from fake apps and malware:

• Download and install applications only from official app stores.
• Android device users can keep the Unknown sources option disabled to stop app installation from unknown sources.
• Use mobile solutions such as Microsoft Defender for Endpoint on Android to detect malicious applications.

Appendix

Indicators of compromise

MITRE ATT&CK techniques

Shivang Desai, Abhishek Pustakala, and Harshita Tripathi
Microsoft 365 Defender Research Team

The post Rewards plus: Fake mobile banking rewards apps lure users to install info-stealing RAT on Android devices appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack. While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.

While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack. The addition of a few benign-looking lines of code into a single DLL file spelled a serious threat to organizations using the affected product, a widely used IT administration software used across verticals, including government and the security industry. The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.

The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code. As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.

In many of their actions, the attackers took steps to maintain a low profile. For example, the inserted malicious code is lightweight and only has the task of running a malware-added method in a parallel thread such that the DLL’s normal operations are not altered or interrupted. This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code. The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.

Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines. It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain. This is another way the attackers try to evade detection.

With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions. As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally. Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.

Figure 1. Solorigate malware infection chain

The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.

We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat. In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments. We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint. In another blog, we discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities. Read: Using Microsoft 365 Defender to protect against Solorigate.

Where it all starts: A poisoned code library

The attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a code library belonging to the SolarWinds Orion Platform. The attackers had to find a suitable place in this DLL component to insert their code. Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running. Such a suitable location turns out to be a method named RefreshInternal.

Figure 2: The method infected with the bootstrapper for the backdoor

Figure 3: What the original method looks like

The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.

Why was this method chosen rather than other ones? A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class. The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks. Among those tasks is Background Inventory, which ultimately starts the malicious code.

Figure 4. The inserted malicious code runs within a parallel thread

The functionality of the backdoor resides entirely in the class OrionImprovementBusinessLayer, comprising 13 subclasses and 16 methods. Its name blends in with the rest of the legitimate code. The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon. At first glance, the code in this DLL looks normal and doesn’t raise suspicions, which could be part of the reason why the insertion of malicious code was undetected for months, especially if the code for this DLL was not frequently updated.

To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.

Figure 5: Example of obfuscated strings

Initial reconnaissance

The Initialize method is the de facto execution entry point of the backdoor. It carries out several checks to verify that it is running in a real victim’s environment:

• It verifies that the process hosting the malicious DLL is named solarwinds.businesslayerhost.exe
• It checks that the last write-time of the malicious DLL is at least 12 to 14 days earlier
• It delays execution by random amounts of time
• It verifies that the domain name of the current device meets the following conditions:
  • The domain must not contain certain strings; the check for these strings is implemented via hashes, so at this time the domain names that are block-listed are unknown
  • The domain must not contain “solarwinds”
  • The domain must not match the regular expression (?i)([^a-z]|^)(test)([^a-z]|$), or in simpler terms, it must not look like a test domain
• It checks that there are no running processes related to security-related software (e.g., Windbg, Autoruns, Wireshark)
• It checks that there are no drivers loaded from security-related software (e.g., groundling32.sys)
• It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)
• It checks that the host “api.solarwinds.com” resolves to an expected IP address

If any of these checks fail, the backdoor terminates. All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.

The backdoor

After the extensive validation described above, the backdoor enters its main execution stage. At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information. The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.

In its first step, the backdoor initiates a connection to a predefined C2 server to report some basic information about the compromised system and receive the first commands. The C2 domain is composed of four different parts: three come from strings that are hardcoded in the backdoor, and one component is generated dynamically based on some unique information extracted from the device. This means that every affected device generates a different subdomain to contact (and possibly more than one). Here’s an example of a generated domain:

Figure 6: Dynamically generated C2 domain

The dynamically generated portion of the domain is the interesting part. It is computed by hashing the following data:

• The physical address of the network interface
• The domain name of the device
• The content of the MachineGuid registry value from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography

The backdoor also generates a pseudo-random URI that is requested on the C2 domain. Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out. Possible URIs that can be generated follow these formats:

• pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings:
  • “-root”
  • “-cert”
  • “-universal_ca”
  • “-ca”
  • “-primary_ca”
  • “-timestamp”
  • “-global”
  • “-secureca”
• fonts/woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings:
  • “Bold”
  • “BoldItalic”
  • “ExtraBold”
  • “ExtraBoldItalic”
  • “Italic”,
  • “Light”
  • “LightItalic”
  • “Regular”
  • “SemiBold”
  • “SemiBoldItalic”
  • “opensans”
  • “noto”
  • “freefont”
  • “SourceCodePro”
  • “SourceSerifPro”
  • “SourceHanSans”
  • “SourceHanSerif”
• swip/upd/<random components>, where <random components> can be one or more of the following strings:
  • “SolarWinds”
  • “.CortexPlugin”
  • “.Orion”
  • “Wireless”
  • “UI”
  • “Widgets”
  • “NPM”
  • “Apollo”
  • “CloudMonitoring”
  • “Nodes”,
  • “Volumes”,
  • “Interfaces”,
  • “Components”
• swip/Upload.ashx
• swip/Events

Here are examples of final URLs generated by the backdoor:

• hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
• hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl
• hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2

Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields. It then sends this JSON document to the C2 server.

Figure 7: Example of data generated by the malware

If the communication is successful, the C2 responds with an encoded, compressed buffer of data containing commands for the backdoor to execute. The C2 might also respond with information about an additional C2 address to report to. The backdoor accepts the following commands:

• Idle
• Exit
• SetTime
• CollectSystemDescription
• UploadSystemDescription
• RunTask
• GetProcessByDescription
• KillTask
• GetFileSystemEntries
• WriteFile
• FileExists
• DeleteFile
• GetFileHash
• ReadRegistryValue
• SetRegistryValue
• DeleteRegistryValue
• GetRegistrySubKeyAndValueNames
• Reboot
• None

In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit. The command CollectSystemDescription retrieves the following information:

• Local Computer Domain name
• Administrator Account SID
• HostName
• Username
• OS Version
• System Directory
• Device uptime
• Information about the network interfaces

Resulting hands-on-keyboard attack

Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets. To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.

C:\Windows\system32\cmd.exe /C csrss.exe -h breached.contoso.com -f (name=”Domain Admins”) member -list | csrss.exe -h breached.contoso.com -f objectcategory=* > .\Mod\mod1.log

Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity:

$scheduler = New-Object -ComObject (“Schedule.Service”);$scheduler.Connect($env:COMPUTERNAME);$folder = $scheduler.GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.GetTask(“EventCacheManager”);$definition = $task.Definition;$definition.Settings.ExecutionTimeLimit = “PT0S”;$folder.RegisterTaskDefinition($task.Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F /tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr “C:\Windows\SoftwareDistribution\EventCacheManager.exe” /sc ONSTART /ru system /S [machine_name]

Persistence is achieved via backdoors deployed via various techniques:

1. PowerShell:

Powershell -nop -exec bypass -EncodedCommand

The –EncodedCommand, once decoded, would resemble:

Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName WORKSTATION

2. Rundll32:

C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.NET\Framework64\[malicious .dll file], [various exports]

With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.

The backdoor also allows the attackers to deliver second-stage payloads, which are part of the Cobalt Strike software suite. We continue to investigate these payloads, which are detected as Trojan:Win32/Solorigate.A!dha, as the situation continues to unfold.

Microsoft Defender for Endpoint product and hardening guidance

Supply chain compromise continues to be a growing concern in the security industry. The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks. We continue to urge customers to:

• Isolate and investigate devices where these malicious binaries have been detected
• Identify accounts that have been used on the affected device and consider them compromised
• Investigate how those endpoints might have been compromised
• Investigate the timeline of device compromise for indications of lateral movement

Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations. On top of that, comprehensive visibility into system and network activities drive the early detection of anomalous behaviors and potential signs of compromise. More importantly, the ability to correlate signals through AI could surface more evasive attacker activity.

Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain. These detections raise alerts that inform security operations teams about the presence of activities and artifacts related to this incident. Given that this attack involves the compromise of legitimate software, automatic remediation is not enabled to prevent service interruption. The detections, however, provide visibility into the attack activity. Analysts can then use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.

Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat. This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains. Security operations teams can then hunt using this rich threat data and gain insights for hardening networks from compromise. Read: Using Microsoft 365 Defender to protect against Solorigate.

Figure 8. Microsoft Defender for Endpoint detections across the Solorigate attack chain

Several Microsoft Defender for Endpoint capabilities are relevant to the Solorigate attack:

Next generation protection

Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines malware, even if the process is running.

Detection for backdoored SolarWinds.Orion.Core.BusinessLayer.dll files:

• Trojan:MSIL/Solorigate.BR!dha

Detection for Cobalt Strike fragments in process memory and stops the process:

• Trojan:Win32/Solorigate.A!dha
• Behavior:Win32/Solorigate.A!dha

Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.

• Trojan:Win64/Solorigate.SA!dha

Detection for the PowerShell payload that grabs hashes and SolarWinds passwords from the database along with machine information:

• Trojan:PowerShell/Solorigate.H!dha

Figure 9. Microsoft Defender for Endpoint prevented malicious binaries

Endpoint detection and response (EDR)

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network:

• SolarWinds Malicious binaries associated with a supply chain attack
• SolarWinds Compromised binaries associated with a supply chain attack
• Network traffic to domains associated with a supply chain attack

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later. These alerts can also be associated with other malicious threats.

• ADFS private key extraction attempt
• Masquerading Active Directory exploration tool
• Suspicious mailbox export or access modification
• Possible attempt to access ADFS key material
• Suspicious ADFS adapter process created

Figure 10. Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction

Figure 11. Microsoft Defender for Endpoint alert description and recommended actions for possible attempt to access ADFS key material

Our ability to deliver these protections through our security technologies is backed by our security experts who immediately investigated this attack and continue to look into the incident as it develops. Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor. In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.

Threat analytics report

We published a comprehensive threat analytics report on this incident. Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses.

Figure 12. Threat analytics report on the Solorigate attack

Advanced hunting

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.

Malicious DLLs loaded into memory

To locate the presence or distribution of malicious DLLs loaded into memory, run the following query

DeviceImageLoadEvents 
| where SHA1 in ("d130bd75645c2433f88ac03e73395fba172ef676",
"1acf3108bf1e376c8848fbb25dc87424f2c2a39c","e257236206e99f5a5c62035c9c59c57206728b28",
"6fdd82b7ca1c1f0ec67c05b36d14c9517065353b","2f1a5a7411d015d01aaee4535835400191645023",
"bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387","16505d0b929d80ad1680f993c02954cfd3772207",
"d8938528d68aabe1e31df485eb3f75c8a925b5d9","395da6d4f3c890295f7584132ea73d759bd9d094",
"c8b7f28230ea8fbf441c64fdd3feeba88607069e","2841391dfbffa02341333dd34f5298071730366a",
"2546b0e82aecfe987c318c7ad1d00f9fa11cd305","e2152737bed988c0939c900037890d1244d9a30e") 
or SHA256 in ("ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6",
"dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b",
"eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed",
"ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c",
"019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134",
"c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77",
"0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589",
"e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d",
"20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9",
"2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d",
"a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d",
"92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690",
"a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2",
"cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6")

Malicious DLLs created in the system or locally

To locate the presence or distribution of malicious DLLs created in the system or locally, run the following query

DeviceFileEvents 
| where SHA1 in ("d130bd75645c2433f88ac03e73395fba172ef676",
"1acf3108bf1e376c8848fbb25dc87424f2c2a39c","e257236206e99f5a5c62035c9c59c57206728b28",
"6fdd82b7ca1c1f0ec67c05b36d14c9517065353b","2f1a5a7411d015d01aaee4535835400191645023",
"bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387","16505d0b929d80ad1680f993c02954cfd3772207",
"d8938528d68aabe1e31df485eb3f75c8a925b5d9","395da6d4f3c890295f7584132ea73d759bd9d094",
"c8b7f28230ea8fbf441c64fdd3feeba88607069e","2841391dfbffa02341333dd34f5298071730366a",
"2546b0e82aecfe987c318c7ad1d00f9fa11cd305","e2152737bed988c0939c900037890d1244d9a30e") 
or SHA256 in ("ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6",
"dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b",
"eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed",
"ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c",
"019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134",
"c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77",
"0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589",
"e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d",
"20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9",
"2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d",
"a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d",
"92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690",
"a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2",
"cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6")

SolarWinds processes launching PowerShell with Base64

To locate SolarWinds processes spawning suspected Base64-encoded PowerShell commands, run the following query 

DeviceProcessEvents
| where InitiatingProcessFileName =~ "SolarWinds.BusinessLayerHost.exe"
| where FileName =~ "powershell.exe"// Extract base64 encoded string, ensure valid base64 length| extend base64_extracted = extract('([A-Za-z0-9+/]{20,}[=]{0,3})', 1, ProcessCommandLine)| extend base64_extracted = substring(base64_extracted, 0, (strlen(base64_extracted) / 4) * 4)| extend base64_decoded = replace(@'\0', '', make_string(base64_decode_toarray(base64_extracted)))//
| where notempty(base64_extracted) and base64_extracted matches regex '[A-Z]' and base64_extracted matches regex '[0-9]'

SolarWinds processes launching CMD with echo

To locate SolarWinds processes launching CMD with echo,  run the following query 

DeviceProcessEvents
| where InitiatingProcessFileName =~ "SolarWinds.BusinessLayerHost.exe"
| where FileName == "cmd.exe" and ProcessCommandLine has "echo"

C2 communications

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceEvents
| where ActionType == "DnsQueryResponse" //DNS Query Responseand AdditionalFields has ".avsvmcloud"

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceNetworkEvents
| where RemoteUrl contains 'avsvmcloud.com'
| where InitiatingProcessFileName != "chrome.exe"
| where InitiatingProcessFileName != "msedge.exe"
| where InitiatingProcessFileName != "iexplore.exe"
| where InitiatingProcessFileName != "firefox.exe"
| where InitiatingProcessFileName != "opera.exe"

Find SolarWinds Orion software in your enterprise

To search for Threat and Vulnerability Management data to find SolarWinds Orion software organized by product name and ordered by how many devices the software is installed on, run the following query 

DeviceTvmSoftwareInventoryVulnerabilities
| where SoftwareVendor == 'solarwinds'
| where SoftwareName startswith 'orion'
| summarize dcount(DeviceName) by SoftwareName
| sort by dcount_DeviceName desc

ADFS adapter process spawning

DeviceProcessEvents
| where InitiatingProcessFileName =~"Microsoft.IdentityServer.ServiceHost.exe"
| where FileName in~("werfault.exe", "csc.exe")
| where ProcessCommandLine !contains ("nameId")

Appendix

MITRE ATT&CK techniques observed

This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.

Initial Access

T1195.001 Supply Chain Compromise

Execution

T1072 Software Deployment Tools

Command and Control

T1071.004 Application Layer Protocol: DNS

T1071.001 Application Layer Protocol: Web Protocols

T1568.002 Dynamic Resolution: Domain Generation Algorithms

T1132 Data Encoding

Persistence

T1078 Valid Accounts 

Defense Evasion

T1480.001 Execution Guardrails: Environmental Keying

T1562.001 Impair Defenses: Disable or Modify Tools

Collection

T1005 Data From Local System 

Additional malware discovered

In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor. The malware consists of a small persistence backdoor in the form of a DLL file named App_Web_logoimagehandler.ashx.b6031896.dll, which is programmed to allow remote code execution through SolarWinds web application server when installed in the folder “inetpub\SolarWinds\bin\”. Unlike Solorigate, this malicious DLL does not have a digital signature, which suggests that this may be unrelated to the supply chain compromise.  Nonetheless, the infected DLL contains just one method (named DynamicRun), that can receive a C# script from a web request, compile it on the fly, and execute it.

Figure 13: Original DLL

Figure 14: The malicious addition that calls the DynamicRun method

This code provides an attacker the ability to send and execute any arbitrary C# program on the victim’s device. Microsoft Defender Antivirus detects this compromised DLL as Trojan:MSIL/Solorigate.G!dha.

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft 365 Defender tech community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers appeared first on Microsoft Security Blog.

Figure 1: Increased attacks on critical infrastructure

This is the third and final post in the “Defending the power grid against supply chain attacks” series. In the first blog I described the nature of the risk. Last month I outlined how utility suppliers can better secure the devices they manufacture. Today’s advice is directed at the utilities. There are actions you can take as individual companies and as an industry to reduce risk.

Implement operational technology security best practices

According to Verizon’s 2019 Data Breach Investigations Report, 80 percent of hacking-related breaches are the result of weak or compromised passwords. If you haven’t implemented multi-factor authentication (MFA) for all your user accounts, make it a priority. MFA can significantly reduce the likelihood that a user with a stolen password can access your company assets. I also recommend you take these additional steps to protect administrator accounts:

• Separate administrative accounts from the accounts that IT professionals use to conduct routine business. While administrators are answering emails or conducting other productivity tasks, they may be targeted by a phishing campaign. You don’t want them signed into a privileged account when this happens.
• Apply just-in-time privileges to your administrator accounts. Just-in-time privileges require that administrators only sign into a privileged account when they need to perform a specific administrative task. These sign-ins go through an approval process and have a time limit. This will reduce the possibility that someone is unnecessarily signed into an administrative account.

Figure 2: A “blue” path depicts how a standard user account is used for non-privileged access to resources like email and web browsing and day-to-day work. A “red” path shows how privileged access occurs on a hardened device to reduce the risk of phishing and other web and email attacks. 

• You also don’t want the occasional security mistake like clicking on a link when administrators are tired or distracted to compromise the workstation that has direct access to these critical systems.  Set up privileged access workstations for administrative work. A privileged access workstation provides a dedicated operating system with the strongest security controls for sensitive tasks. This protects these activities and accounts from the internet. To encourage administrators to follow security practices, make sure they have easy access to a standard workstation for other more routine tasks.

The following security best practices will also reduce your risk:

• Allow list approved applications. Define the list of software applications and executables that are approved to be on your networks. Block everything else. Your organization should especially target systems that are internet facing as well as Human-Machine Interface (HMI) systems that play the critical role of managing generation, transmission, or distribution of electricity
• Regularly patch software and operating systems. Implement a monthly practice to apply security patches to software on all your systems. This includes applications and Operating Systems on servers, desktop computers, mobile devices, network devices (routers, switches, firewalls, etc.), as well as Internet of Thing (IoT) and Industrial Internet of Thing (IIoT) devices. Attackers frequently target known security vulnerabilities.
• Protect legacy systems. Segment legacy systems that can no longer be patched by using firewalls to filter out unnecessary traffic. Limit access to only those who need it by using Just In Time and Just Enough Access principles and requiring MFA. Once you set up these subnets, firewalls, and firewall rules to protect the isolated systems, you must continually audit and test these controls for inadvertent changes, and validate with penetration testing and red teaming to identify rogue bridging endpoint and design/implementation weaknesses.
• Segment your networks. If you are attacked, it’s important to limit the damage. By segmenting your network, you make it harder for an attacker to compromise more than one critical site. Maintain your corporate network on its own network with limited to no connection to critical sites like generation and transmission networks. Run each generating site on its own network with no connection to other generating sites. This will ensure that should a generating site become compromised, attackers can’t easily traverse to other sites and have a greater impact.
• Turn off all unnecessary services. Confirm that none of your software has automatically enabled a service you don’t need. You may also discover that there are services running that you no longer use. If the business doesn’t need a service, turn it off.
• Deploy threat protection solutions. Services like Microsoft Threat Protection help you automatically detect, respond to, and correlate incidents across domains.
• Implement an incident response plan: When an attack happens, you need to respond quickly to reduce the damage and get your organization back up and running. Refer to Microsoft’s Incident Response Reference Guide for more details.

Speak with one voice

Power grids are interconnected systems of generating plants, wires, transformers, and substations. Regional electrical companies work together to efficiently balance the supply and demand for electricity across the nation. These same organizations have also come together to protect the grid from attack. As an industry, working through organizations like the Edison Electric Institute (EEI), utilities can define security standards and hold manufacturers accountable to those requirements.

It may also be useful to work with The Federal Energy Regulatory Committee (FERC), The North American Electric Reliability Corporation (NERC), or The United States Nuclear Regulatory Commission (U.S. NRC) to better regulate the security requirements of products manufactured for the electrical grid.

Apply extra scrutiny to IoT devices

As you purchase and deploy IoT devices, prioritize security. Be careful about purchasing products from countries that are motivated to infiltrate critical infrastructure. Conduct penetration tests against all new IoT and IIoT devices before you connect them to the network. When you place sensors on the grid, you’ll need to protect them from both cyberattacks and physical attacks. Make them hard to reach and tamper-proof.

Collaborate on solutions

Reducing the risk of a destabilizing power grid attack will require everyone in the utility industry to play a role. By working with manufacturers, trade organizations, and governments, electricity organizations can lead the effort to improve security across the industry. For utilities in the United States, several public-private programs are in place to enhance the utility industry capabilities to defend its infrastructure and respond to threats:

• Cyber Risk Information Sharing Program
• Enhanced Cybersecurity – https://www.cisa.gov/enhanced-cybersecurity-services-ecs
• Electric Information Sharing and Analysis Center – https://www.eisac.com/
• Grid Security Exercise
• Cyber Mutual Assistance Program – https://www.eei.org/issuesandpolicy/Documents/Cyber%20Mutual%20Assistance%20Program.pdf

Read Part 1 in the series: “Defending the power grid against cyberattacks”

Read “Defending the power grid against supply chain attacks: Part 2 – Securing hardware and software”

Read how Microsoft Threat Protection can help you better secure your endpoints.

Learn how MSRC developed an incident response plan

Bookmark the Security blog to keep up with our expert coverage on security matters. For more information about our security solutions visit our website. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Defending the power grid against supply chain attacks: Part 3 – Risk management strategies for the utilities industry appeared first on Microsoft Security Blog.

In the first blog in the “Defending the power grid against cyberattacks” series, I walked through how the accelerated adoption of the Internet of Things (IoT) puts utilities and citizens at risk of attack from nation state actors. In this post, I’ll provide guidance for how utilities manufacturers can better protect the connected devices that are deployed in the energy industry.

Protect identities

If your organization supplies the energy industry, you may be targeted by adversaries who want to disrupt the power supply. One way they will try to access your company resources is by stealing or guessing user credentials with tactics like password spray or phishing. According to Verizon’s 2019 Data Breach Investigations Report, 80 percent of breaches are the result of weak or compromised passwords. Attackers target multiple people at a time, but they only need to succeed once to gain access.

Securing your company starts with safeguarding your identities. At the bare minimum, you should apply multi-factor authentication (MFA) to your administrative accounts. A better option is to require all users to authenticate using MFA. MFA requires that users sign in with more than just a password. The second form of authentication can be a one-time code from a mobile device, biometrics, or a secure FIDO2 key, among other options. MFA reduces your risk significantly because it’s much harder for an attacker to compromise two or more authentication factors.

Figure 1: You can use Conditional Access policies to define when someone is promoted to sign in with MFA.

Secure privileged access

In a supply chain attack, adversaries attack your organization to gain access to data and applications that will allow them to tamper with your product or service before it reaches its intended destination. Bad actors want to infiltrate your build environment or the servers that you use to push software updates. To accomplish this, they often target administrator accounts. Securing your administrative accounts is critical to protect your company resources. Here are a few steps you can take to safeguard these accounts:

• Separate administrative accounts from the accounts that IT professionals use to conduct routine business. While administrators are answering emails or conducting other productivity tasks, they may be targeted by a phishing campaign. You don’t want them signed into a privileged account when this happens.
• Apply just-in-time privileges to you administrator accounts. Just-in-time privileges require that administrators only sign into a privileged account when they need to perform a specific administrative task. These sign-ins go through an approval process and have a time limit. This will reduce the possibility that someone is unnecessarily signed into an administrative account.

Figure 2: A “blue” path depicts how a standard user account is used for non-privileged access to resources like email and web browsing and day-to-day work. A “red” path shows how privileged access occurs on a hardened device to reduce the risk of phishing and other web and email attacks.

• Set up privileged access workstations for administrative work. A privileged access workstation provides a dedicated operating system with the strongest security controls for sensitive tasks. This protects these activities and accounts from the internet. To encourage administrators to follow security practices, make sure they have easy access to a standard workstation for other more routine tasks.

Safeguard your build and update environment

Bad actors don’t just target user accounts. They also exploit vulnerabilities in software. Many attacks take advantage of known vulnerabilities for which there are available patches. Keep software and operating systems up-to-date and patched to reduce your risk. Retire any technology that is no longer supported by the publisher and implement mandatory integrity controls to ensure only trusted tools run.

You also need to protect the software that your team writes. A proven and robust Secure Development Lifecycle (SDL) will guide your developers to build software that includes fewer vulnerabilities. Microsoft’s SDL includes 12 practices. For example, Microsoft SDL recommends that security and privacy requirements be defined at the beginning of every project. The guidelines also provide tips for managing the security risk of third-party software, performing threat modeling, and penetration testing, among other recommendations. By building security into the entire software process, the software you release will be more secure and less vulnerable to attack.

Assume breach

My recommendations will reduce your risk, but they won’t eliminate it entirely. To protect your company and customers, you’ll need to adopt an assume breach mindset. It’s not a matter of if you’ll be breached but when. Once you’ve accepted that you can’t prevent all attacks, put processes and tools in place that enable you to detect and respond to an incident as quickly as possible.

Endpoint detection and response solutions, like Microsoft Threat Protection, leverage AI to automate detection and response and correlate threats across domains. When incidents are detected, you will need an appropriate response. The National Institute of Standards and Technology (NIST) provides an incident response guide. You can also learn from Microsoft’s Security Response Center (MSRC), which shared how it developed an incident response plan.

Figure 3: An overview of an incident in Microsoft Threat Protection.

A good communication plan is an important component of a response plan. You will need to let customers know there was an incident and how you plan to address it. As the MSRC notes, “Clear, accurate communication builds confidence in the incident response process, maintains trust with customers, protects your brand, and is essential for fast effective response.”

Centralized IoT device management

In addition to operating a number of generation plants, utilities operate a network of thousands of substations and hundreds of thousands of miles of transmission and distribution lines. This requires them to deploy a large number of IoT devices to safely and efficiently deliver electricity to their customers. To effectively manage this network of IoT devices, suppliers should provide their customers with centralized IoT device management to update firmware, install security updates, and manage accounts and passwords.

Build trust

Protecting critical infrastructure from a destabilizing attack will require collaboration among utilities and suppliers in the industry. Device manufacturers and software publishers have a vital role to play in protecting critical infrastructure. By instituting and maintaining the security practices that I’ve recommended, you can dramatically reduce the risk to your organization and to the power grid.

Stay tuned for the final post in this series, “Part 3: Risk management strategies for the utilities industry,” where I’ll provide recommendations specifically for utilities.

• Learn more about securing your administrator accounts.
• Read how Microsoft Threat Protection can help you better secure your endpoints.
• Read the first blog in this series.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Defending the power grid against supply chain attacks—Part 2: Securing hardware and software appeared first on Microsoft Security Blog.

Figure 1. Microsoft Defender ATP data showing revival of Astaroth campaigns

Figure 2. Geographic distribution of Astaroth campaigns this year, with majority of encounters recorded in Brazil

When we first blogged about Astaroth’s methods, we noted how it completely lived off the land to avoid detection: only system tools that are already existing on the machine are ever executed. In fact, it was an unusual spike in activities related to Windows Management Instrumentation Command-line (WMIC) that prompted our investigation and eventually exposed the Astaroth campaign.

Astaroth now completely avoids the use of WMIC and related techniques to bypass existing detections. Instead, the attackers introduced new techniques that make the attack chain even stealthier:

• Abusing Alternate Data Streams (ADS) to hide malicious payloads
• Abusing the legitimate process ExtExport.exe, a highly uncommon attack vector, to load the payload

Astaroth exemplifies how living-off-the-land techniques have become standard components of today’s attacks intent on evading security solutions. However, as we mentioned in our previous blog on Astaroth, fileless threats are very much observable. These threats still leave a great deal of memory footprint that can be inspected and blocked as they happen. Next-generation protection and behavioral containment and blocking capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) lead the charge in exposing threats like Astaroth.

In this blog, we’ll share our technical analysis of the revamped Astaroth attack chain and demonstrate how specific Microsoft technologies tackle the multiple advanced components of the attack.

Dismantling the new Astaroth attack chain

The attackers were careful to ensure the updates didn’t make Astaroth easier to detect; on the contrary, the updates only make Astaroth’s activities even more invisible.

One of the most significant updates is the use of Alternate Data Stream (ADS), which Astaroth abuses at several stages to perform various activities. ADS is a file attribute that allows a user to attach data to an existing file. The stream data and its size are not visible in File Explorer, so attacks abuse this feature to hide malicious code in plain sight.

Figure 2. Astaroth attack chain 2020

In the case of Astaroth, attackers hide binary data inside the ADS of the file desktop.ini, without changing the file size. By doing this, the attackers create a haven for the payloads, which are read and decrypted on the fly.

Figure 3. Desktop.ini before and after infection

The complex attack chain, which involves the use of multiple living-off-the-land binaries (LOLBins), results in the eventual loading of the Astaroth malware directly in memory. When running, Astaroth decrypts plugins that allow it to steal sensitive information, like email passwords and browser passwords.

In the succeeding sections, we describe each step of Astaroth’s attack chain in detail.

Arrival

The attack begins with an email with a message in Portuguese that translates to: “Please find in the link below the STATEMENT #56704/2019 AND LEGAL DECISION, for due purposes”. The email contains a link that points to URL hosting an archive file, Arquivo_PDF_<date>.zip, which contains a LNK file with a similarly misleading name. When clicked, the LNK file runs an obfuscated BAT command line.

Figure 4. Sample email used in latest Astaroth attacks

The BAT command drops a single-line JavaScript file to the Pictures folder and invokes explorer.exe to run the JavaScript file.

The dropped one-liner script uses the GetObject technique to fetch and run the much larger main JavaScript directly in memory:

BITSAdmin abuse

The main script then invokes multiple instances of BITSAdmin using a benign looking command-line to download multiple binary blobs from a command-and-control (C2) server:

The downloaded payloads are encrypted and have the following file names:

• masihaddajjaldwwn.gif
• masihaddajjalc.jpg
• masihaddajjala.jpg
• masihaddajjalb.jpg
• masihaddajjaldx.gif
• masihaddajjalg.gif
• masihaddajjalgx.gif
• masihaddajjali.gif
• masihaddajjalxa.~
• masihaddajjalxb.~
• masihaddajjalxc.~
• masihaddajjal64w.dll
• masihaddajjal64q.dll
• masihaddajjal64e.dll

Alternate Data Streams abuse

As mentioned, the new Astaroth attacks use a clever technique of copying downloaded data to the ADS of desktop.ini. For each download, the content is copied to the ADS, and then the original content is deleted. These steps are repeated for all downloaded payloads.

Another way that Astaroth abuses ADS is when it runs a script to find installed security products. A malicious script responsible for enumerating security products is dropped and then copied as an ADS to an empty text file. The execution command-line looks like this:

ExtExport.exe abuse

The main script combines three separately downloaded binary blobs to form the first-stage malware code:

The script then uses a LOLBin not previously seen in Astaroth attacks to load the first-stage malware code: ExtExport.exe, which is a legitimate utility shipped as part of Internet Explorer. Attackers can load any DLL by passing an attacker-controlled path to the tool. The tool searches for any DLL with the following file names: mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll. Attackers need only to rename the malicious payload to one of these names, and it is loaded by ExtExport.exe.

Userinit.exe abuse

The newly loaded DLL (mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll) is a proxy that reads three binary ADS streams (desktop.ini:masihaddajjalxa.~, desktop.ini:masihaddajjalxb.~, and desktop.ini:masihaddajjalxc.~) and combines these into a DLL. The newly formed DLL is the second-stage malware code and is loaded in the same process using the reflective DLL loading technique.

The newly loaded DLL is also a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalgx.gif) into a DLL. This DLL is injected into userinit.exe using the process hollowing technique.

The newly loaded DLL inside userinit.exe is again a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalg.gif) into a DLL. This DLL is the malicious info-stealer known as Astaroth and is reflectively loaded inside userinit.exe. Hence, Astaroth never touches the disk and is loaded directly in memory, making it very evasive.

Astaroth payload

When running, the Astaroth payload then reads and decrypts more components from the ADS stream of desktop.ini (desktop.ini:masihaddajjaldwwn.gif, desktop.ini:masihaddajjalc.jpg, desktop.ini:masihaddajjala.jpg, desktop.ini:masihaddajjalb.jpg, and desktop.ini:masihaddajjali.gif).

Some of these components are credential-stealing plugins hidden inside the ADS stream of desktop.ini. Astaroth abuses these plugins to steal information from compromised systems:

• NirSoft’s MailPassView – an email client password recovery tool
• NirSoft’s WebBrowserPassView – a web browser password recovery tool

As mentioned, Astaroth also finds installed security products. It then attempts to disable these security products. For Microsoft Defender Antivirus customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Comprehensive, dynamic protection against living-off-the-land, fileless, and other sophisticated threats with Microsoft Threat Protection

Attackers are increasingly turning to living-off-the-land techniques to attempt running undetected for as long as possible on systems. Because these attacks use multiple executables that are native to the system and have legitimate uses, they require a comprehensive, behavior-based approach to detection.

Microsoft Threat Protection combines and orchestrates into a single solution the capabilities of multiple Microsoft security services to coordinate protection, detection, response, and prevention across endpoints, email, identities, and apps.

In the case of Astaroth, Office 365 ATP detects the malware delivery via email. Using detonation-based heuristics and machine learning, Office 365 ATP inspects links and attachments to identify malicious artifacts.

On endpoints, next-generation protection capabilities in Microsoft Defender ATP detect and prevent some components of Astaroth’s new attack chain. Notably, through Antimalware Scan Interface (AMSI), Microsoft Defender ATP can inspect the encrypted malicious scripts used in the initial stages of the attack.

For the more sophisticated sections of the attack chain, behavioral blocking and containment capabilities provide dynamic protection that can stop malicious behaviors and process trees. Behavior-based protections are key to exposing living-off-the-land threats that abuse and hide behind legitimate processes. These protections identify suspicious behavior sequences and advanced attack techniques observed on the client, which are used as triggers to analyze the process tree using real-time machine learning models in the cloud.

Figure 5. Preventive and behavior-based blocking & containment protections against Astaroth

These behavior-based detections raise alerts in Microsoft Defender Security Center. With behavioral blocking and containment, not only are evasive threats exposed, detected, and stopped; security operations personnel are also notified so they can thoroughly investigate and remediate the root cause.

Figure 6. Sample Microsoft Defender ATP alerts on behavior-based detections of Astaroth’s activities

Microsoft Defender ATP’s EDR capabilities also have very strong coverage of advanced techniques employed by Astaroth, including cross-process migration, code injection, and use of LOLBins.

Figure 7. Sample Microsoft Defender ATP EDR alert and process tree on Astaroth’s behaviors

We expect Astaroth to further develop and increase in complexity, as long-running malware campaigns do. We will continue to watch this evolving threat and ensure that customers are protected from future updates through durable behavior-based protections.

Hardik Suri

Microsoft Defender ATP Research Team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Latest Astaroth living-off-the-land attacks are even more invisible but not less observable appeared first on Microsoft Security Blog.

In the U.S. Department of Defense’s Defense Federal Acquisition Regulation Supplement, a supply chain risk is defined as “the risk that an adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of a covered system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of such system.”

If you rely on a web of software providers, it’s important that you understand and mitigate your risk. This Part 3 of our five-part blog series entitled “Guarding against supply chain attacks” illustrates how software supply chain attacks are executed and offers best practices for improving the quality of the software that undergirds your applications and business.

Examples of software supply chain attacks with global reach

Starting in 2012 the industry began to see a marked increase in the number of attacks targeted at software supply chains each year. Like other hacking incidents, a well-executed software supply chain attack can spread rapidly. The following examples weaponized automatic software updates to infect computers in large and small companies in countries all over the world and highlight how they have evolved over time.

• The Flame malware of 2012 was a nation-state attack that tricked a small number of machines in the Middle East into thinking that a signed update had come from Microsoft’s trusted Windows Update mechanism, when in fact it had not. Flame had 20 modules that could perform a variety of functions. It could turn on your computer’s internal microphone and webcam to record conversations or take screenshots of instant messaging and email. It could also serve as a Bluetooth beacon and tap into other devices in the area to steal info. Believed to come from a nation state, Flame sparked years of copycats. While Flame was a supply chain “emulation” (it only pretended to be trusted), the tactic was studied and adopted by both nation states and criminals, and included noted update attacks like Petya/NotPetya (2017), another nation-state attack, which hit enterprises in over 20 countries. It included the ability to self-propagate (like worms) by building a list of IP addresses to spread to local area networks (LANS) and remote IPs.
• CCleaner affected 2.3 million computers in 2018, some for more than a month. Nation-state actors replaced original software versions with malware that had been used to modify the CCleaner installation file used by customers worldwide. Access was gained through the Piriform network, a company that was acquired by Avast before the attack was launched on CCleaner users. As Avast says in a blog on the subject, “Attackers will always try to find the weakest link, and if a product is downloaded by millions of users it is an attractive target for them. Companies need to increase their attention and investment in keeping the supply chain secure.”
• In May 2017, Operation WilySupply compromised a text editor’s software updater to install a backdoor on target organizations in the financial and IT sectors. Microsoft Defender Advanced Threat Protection (ATP) discovered the attack early and Microsoft worked with the vendor to contain the attack and mitigate the risk.

Implanting malware

There are three primary ways that malicious actors infect the software supply chain:

• Compromise internet accessible software update servers. Cybercrooks hack into the servers that companies use to distribute their software updates. Once they gain access, they replace legitimate files with malware. If an application auto-updates, the number of infections can proliferate quickly.
• Gain access to the software infrastructure. Hackers use social engineering techniques to infiltrate the development infrastructure. After they’ve tricked users into sharing sign-in credentials, the attackers move laterally within the company until they are able to target the build environment and servers. This gives them the access needed to inject malicious code into software before it has been complied and shipped to customers. Once the software is signed with the digital signature it’s extremely difficult to detect that something is wrong.
• Attack third-party code libraries. Malware is also delivered through third-party code, such as libraries, software development kits, and frameworks that developers use in their applications.

Safeguarding your software supply chain

There are several steps you can take to reduce the vulnerabilities in your software. (We’ll address the vulnerabilities and mitigation strategies related to people and processes in our next post.):

• Much like the hardware supply chain, it’s important to inventory your software suppliers. Do your due diligence to confirm there are no red flags. The NIST Cyber Supply Chain Best Practices provide sample questions that you can use to screen your software suppliers, such as what malware protection and detection are performed and what access controls—both cyber and physical—are in place.
• Set a high standard of software assurance with partners and suppliers. Governmental organizations such as the Department of Homeland Security, SafeCODE, the OWASP SAMM, and the U.K. National Cyber Security Centre’s Commercial Product Assurance (CPA) provide a model. You can also refer to Microsoft’s secure development lifecycle (SDL). The SDL defines 12 best practices that Microsoft developers and partners utilize to reduce vulnerabilities. Use the SDL to guide a software assurance program for your engineers, partners, and suppliers.
• Manage security risks in third-party components. Commercial and open-source libraries and frameworks are invaluable for improving efficiency. Engineers shouldn’t create a component from scratch if a good one exists already; however, third-party libraries are often targeted by bad actors. Microsoft’s open source best practices can help you manage this risk with four steps:
  1. Understand what components are in use and where.
  2. Perform security analysis to confirm that none of your components contain vulnerabilities
  3. Keep components up to date. Security fixes are often fixed without explicit notification.
  4. Establish an incident response plan, so you have a strategy when a vulnerability is reported.

Learn more

“Guarding against supply chain attacks” is a five-part blog series that decodes supply chain threats and provides concrete actions you can take to better safeguard your organization. Previous posts include an overview of supply chain risks and an examination of vulnerabilities in the hardware supply chain.

We also recommend you explore NIST Cybersecurity Supply Chain Risk Management.

Stay tuned for these upcoming posts as we wrap up our five-part series:

• Part 4—Looks at how people and processes can expose companies to risk.
• Part 5—Summarizes our advice with a look to the future.

In the meantime, bookmark the Security blog to keep up with our expert coverage on security matters. For more information about Microsoft Security solutions, visit our website: http://approjects.co.za/?big=en-us/security/business. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Guarding against supply chain attacks—Part 3: How software becomes compromised appeared first on Microsoft Security Blog.