OpenMetadata is an open-source platform designed to manage metadata across various data sources. It serves as a central repository for metadata lineage, allowing users to discover, understand, and govern their data. On March 15, 2024, several vulnerabilities in OpenMetadata platform were published. These vulnerabilities (CVE-2024-28255, CVE-2024-28847, CVE-2024-28253, CVE-2024-28848, CVE-2024-28254), affecting versions prior to 1.3.1, could be exploited by attackers to bypass authentication and achieve remote code execution. Since the beginning of April, we have observed exploitation of this vulnerability in Kubernetes environments.

Microsoft highly recommends customers to check clusters that run OpenMetadata workload and make sure that the image is up to date (version 1.3.1 or later). In this blog, we share our analysis of the attack, provide guidance for identifying vulnerable clusters and using Microsoft security solutions like Microsoft Defender for Cloud to detect malicious activity, and share indicators of compromise that defenders can use for hunting and investigation.

Attack flow

For initial access, the attackers likely identify and target Kubernetes workloads of OpenMetadata exposed to the internet. Once they identify a vulnerable version of the application, the attackers exploit the mentioned vulnerabilities to gain code execution on the container running the vulnerable OpenMetadata image.

After establishing a foothold, the attackers attempt to validate their successful intrusion and assess their level of control over the compromised system. This reconnaissance step often involves contacting a publicly available service. In this specific attack, the attackers send ping requests to domains that end with oast[.]me and oast[.]pro, which are associated with Interactsh, an open-source tool for detecting out-of-band interactions.

OAST domains are publicly resolvable yet unique, allowing attackers to determine network connectivity from the compromised system to attacker infrastructure without generating suspicious outbound traffic that might trigger security alerts. This technique is particularly useful for attackers to confirm successful exploitation and validate their connectivity with the victim, before establishing a command-and-control (C2) channel and deploying malicious payloads.

After gaining initial access, the attackers run a series of reconnaissance commands to gather information about the victim environment. The attackers query information on the network and hardware configuration, OS version, active users, etc.

As part of the reconnaissance phase, the attackers read the environment variables of the workload. In the case of OpenMetadata, those variables might contain connection strings and credentials for various services used for OpenMetadata operation, which could lead to lateral movement to additional resources.

Once the attackers confirm their access and validate connectivity, they proceed to download the payload, a cryptomining-related malware, from a remote server. We observed the attackers using a remote server located in China. The attacker’s server hosts additional cryptomining-related malware that are stored, for both Linux and Windows OS.

The downloaded file’s permissions are then elevated to grant execution privileges. The attacker also added a personal note to the victims:

Next, the attackers run the downloaded cryptomining-related malware, and then remove the initial payloads from the workload. Lastly, for hands-on-keyboard activity, the attackers initiate a reverse shell connection to their remote server using Netcat tool, allowing them to remotely access the container and gain better control over the system. Additionally, for persistence, the attackers use cronjobs for task scheduling, enabling the execution of the malicious code at predetermined intervals.

How to check if your cluster is vulnerable

Administrators who run OpenMetadata workload in their cluster need to make sure that the image is up to date. If OpenMetadata should be exposed to the internet, make sure you use strong authentication and avoid using the default credentials.

To get a list of all the images running in the cluster:

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep 'openmetadata'

If there is a pod with a vulnerable image, make sure to update the image version for the latest version.

How Microsoft Defender for Cloud capabilities can help

This attack serves as a valuable reminder of why it’s crucial to stay compliant and run fully patched workloads in containerized environments. It also highlights the importance of a comprehensive security solution, as it can help detect malicious activity in the cluster when a new vulnerability is used in the attack. In this specific case, the attackers’ actions triggered Microsoft Defender for Containers alerts, identifying the malicious activity in the container. In the example below, Microsoft Defender for Containers alerted on an attempt to initiate a reverse shell from a container in a Kubernetes cluster, as happened in this attack:

To prevent such attacks, Microsoft Defender for Containers provides agentless vulnerability assessment for Azure, AWS, and GCP, allowing you to identify vulnerable images in the environment, before the attack occurs.  Microsoft Defender Cloud Security Posture Management (CSPM) can help to prioritize the security issues according to their risk. For example, Microsoft Defender CSPM highlights vulnerable workloads exposed to the internet, allowing organizations to quickly remediate crucial threats.

Organizations can also monitor Kubernetes clusters using Microsoft Sentinel via Azure Kubernetes Service (AKS) solution for Sentinel, which enables detailed audit trail for user and system actions to identify malicious activity.

Indicators of compromise (IoCs)

Hagai Ran Kestenberg, Security Researcher
Yossi Weizman, Senior Security Research Manager

Learn more

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 LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Attackers exploiting new critical OpenMetadata vulnerabilities on Kubernetes clusters appeared first on Microsoft Security Blog.

In attacks observed by Microsoft Threat Intelligence, threat actors launched phishing or password spraying attacks to compromise user accounts that did not have strong authentication mechanisms and had permissions to create or modify OAuth applications. The threat actors misused the OAuth applications with high privilege permissions to deploy virtual machines (VMs) for cryptocurrency mining, establish persistence following business email compromise (BEC), and launch spamming activity using the targeted organization’s resources and domain name.

Microsoft continuously tracks attacks that misuse of OAuth applications for a wide range of malicious activity. This visibility enhances the detection of malicious OAuth applications via Microsoft Defender for Cloud Apps and prevents compromised user accounts from accessing resources via Microsoft Defender XDR and Microsoft Entra Identity Protection. In this blog post, we present cases where threat actors compromised user accounts and misused OAuth applications for their financially driven attacks, outline recommendations for organizations to mitigate such attacks, and provide detailed information on how Microsoft detects related activity:

• OAuth applications to deploy VMs for cryptomining
• OAuth applications for BEC and phishing
• OAuth applications for spamming activity
• Mitigation steps
• Detections for related techniques
• Hunting guidance

OAuth applications to deploy VMs for cryptomining

Microsoft observed the threat actor tracked as Storm-1283 using a compromised user account to create an OAuth application and deploy VMs for cryptomining. The compromised account allowed Storm-1283 to sign in via virtual private network (VPN), create a new single-tenant OAuth application in Microsoft Entra ID named similarly as the Microsoft Entra ID tenant domain name, and add a set of secrets to the application. As the compromised account had an ownership role on an Azure subscription, the actor also granted ‘Contributor’ role permission for the application to one of the active subscriptions using the compromised account.

The actor also leveraged existing line-of-business (LOB) OAuth applications that the compromised user account had access to in the tenant by adding an additional set of credentials to those applications. The actor initially deployed a small set of VMs in the same compromised subscriptions using one of the existing applications and initiated the cryptomining activity. The actor then later returned to deploy more VMs using the new application. Targeted organizations incurred compute fees ranging from 10,000 to 1.5 million USD from the attacks, depending on the actor’s activity and duration of the attack.

Storm-1283 looked to maintain the setup as long as possible to increase the chance of successful cryptomining activity. We assess that, for this reason, the actor used the naming convention [DOMAINNAME]_[ZONENAME]_[1-9] (the tenant name followed by the region name) for the VMs to avoid suspicion.  

One of the ways to recognize the behavior of this actor is to monitor VM creation in Azure Resource Manager audit logs and look for the activity “Microsoft.Compute/virtualMachines/write” performed by an OAuth application. While the naming convention used by the actor may change in time, it may still include the domain name or region names like “east|west|south|north|central|japan|france|australia|canada|korea|uk|poland|brazil”

Microsoft Threat Intelligence analysts were able to detect the threat actor’s actions and worked with the Microsoft Entra team to block the OAuth applications that were part of this attack. Affected organizations were also informed of the activity and recommended further actions.

OAuth applications for BEC and phishing

In another attack observed by Microsoft, a threat actor compromised user accounts and created OAuth applications to maintain persistence and to launch email phishing activity. The threat actor used an adversary-in-the-middle (AiTM) phishing kit to send a significant number of emails with varying subject lines and URLs to target user accounts in multiple organizations. In AiTM attacks, threat actors attempt to steal session tokens from their targets by sending phishing emails with a malicious URL that leads to a proxy server that facilitates a genuine authentication process.

We observed the following email subjects used in the phishing emails:

• <Username> shared “<Username> contracts” with you.
• <Username> shared “<User domain>” with you.
• OneDrive: You have received a new document today
• <Username> Mailbox password expiry
• Mailbox password expiry
• <Username> You have Encrypted message
• Encrypted message received

After the targets clicked the malicious URL in the email, they were redirected to the Microsoft sign-in page that was proxied by the threat actor’s proxy server. The proxy server set up by the threat actor allowed them to steal the token from the user’s session cookie. Later, the stolen token was leveraged to perform session cookie replay activity. Microsoft was able to confirm during further investigation that the compromised user account was flagged for risky sign-ins when the account was used to sign in from an unfamiliar location and from an uncommon user agent.

For persistence following business email compromise

In some cases, following the stolen session cookie replay activity, the actor leveraged the compromised user account to perform BEC financial fraud reconnaissance by opening email attachments in Microsoft Outlook Web Application (OWA) that contain specific keywords such as “payment” and “invoice”. This action typically precedes financial fraud attacks where the threat actor seeks out financial conversations and attempts to socially engineer one party to modify payment information to an account under attacker control.

Later, to maintain persistence and carry out malicious actions, the threat actor created an OAuth application using the compromised user account. The actor then operated under the compromised user account session to add new credentials to the OAuth application.  

For email phishing activity

In other cases, instead of performing BEC reconnaissance, the threat actor created multitenant OAuth applications following the stolen session cookie replay activity. The threat actor used the OAuth applications to maintain persistence, add new credentials, and then access Microsoft Graph API resource to read emails or send phishing emails.

At the time of analysis, we observed that threat actor created around 17,000 multitenant OAuth applications across different tenants using multiple compromised user accounts. The created applications mostly had two different sets of application metadata properties, such as display name and scope:

• Malicious multitenant OAuth applications with the display name set as “oauth” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.read; people.read” and access to Microsoft Graph API and read emails.
• Malicious multitenant OAuth applications with the display name set as “App” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.send” and access to Microsoft Graph API to send high volumes of phishing emails to both intra-organizational and external organizations.

In addition, we observed that the threat actor, before using the OAuth applications to send phishing emails, leveraged the compromised user accounts to create inbox rules with suspicious rule names like “…” to move emails to the junk folder and mark them as read. This is to evade detection by the compromised user that the account was used to send phishing emails.

Based on the email telemetry, we observed that the malicious OAuth applications created by the threat actor sent more than 927,000 phishing emails. Microsoft has taken down all the malicious OAuth applications found related to this campaign, which ran from July to November 2023.

OAuth applications for spamming activity

Microsoft also observed large-scale spamming activity through OAuth applications by a threat actor tracked as Storm-1286. The actor launched password spraying attacks to compromise user accounts, the majority of which did not have multifactor authentication (MFA) enabled. We also observed the user agent BAV2ROPC in the sign-in activities related to the compromised accounts, which indicated the use of legacy authentication protocols such as IMAP and SMTP that do not support MFA.

We observed the actor using the compromised user accounts to create anywhere from one to three new OAuth applications in the targeted organization using Azure PowerShell or a Swagger Codegen-based client. The threat actor then granted consent to the applications using the compromised accounts. These applications were set with permissions like email, profile, openid, Mail.Send, User.Read and Mail.Read, which allowed the actor to control the mailbox and send thousands of emails a day using the compromised user account and the organization domain. In some cases, the actor waited for months after the initial access and setting up of OAuth applications before starting the spam activity using the applications. The actor also used legitimate domains to avoid phishing and spamming detectors.

In previous large-scale spam activities, we observed threat actors attempting to compromise admin accounts without MFA and create new LOB applications with high administrative permissions to abuse Microsoft Exchange Online and spread spam. While the activity of the actor then was limited due to actions taken by Microsoft Threat Intelligence such as blocking clusters of the OAuth applications in the past, Storm-1286 continues to try new ways to set a similar high-scale spamming platform in victim organizations by using non-privileged users.

Mitigation steps

Microsoft recommends the following mitigations to reduce the impact of these types of threats.

Mitigate credential guessing attacks risks

A key step in reducing the attack surface is securing the identity infrastructure. The most common initial access vector observed in this attack was account compromise through credential stuffing, phishing, and reverse proxy (AiTM) phishing. In most cases the compromised accounts did not have MFA enabled. Implementing security practices that strengthen account credentials such as enabling MFA reduced the chance of attack dramatically.

Enable conditional access policies

Conditional access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies for User and Sign-in Risk, device compliance and trusted IP address requirements. If your organization has a Microsoft-Managed Conditional Access policy, make sure it is enforced.

Ensure continuous access evaluation is enabled

Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Enable security defaults

While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.

Enable Microsoft Defender automatic attack disruption

Microsoft Defender automatic attack disruption capabilities minimize lateral movement and curbs the overall impact of an attack in its initial stages.

Audit apps and consented permissions

Audit apps and consented permissions in your organization ensure applications are only accessing necessary data and adhering to the principles of least privilege. Use Microsoft Defender for Cloud Apps and its app governance add-on for expanded visibility into cloud activity in your organization and control over applications that access your Microsoft 365 data. 

Educate your organization on application permissions and data accessible by applications with respective permissions to identify malicious apps. 

Enhance suspicious OAuth application investigation with the recommended approach to investigate and remediate risky OAuth apps.

Enable “Review admin consent requests” for forcing new applications review in the tenant.

In addition to the recommendations above, Microsoft has published incident response playbooks for App consent grant investigation and compromised and malicious applications investigation that defenders can use to respond quickly to related threats.

Secure Azure Cloud resources

Deploy MFA to all users, especially for tenant administrators and accounts with Azure VM Contributor privileges. Limit unused quota and monitor for unusual quota increases in your Azure subscriptions, with an emphasis on the resource’s originating creation or modification. Monitor for unexpected sign-in activity from IP addresses associated with free VPN services on high privilege accounts. Connect Microsoft Defender for Cloud Apps connector to ARM or use Microsoft Defender for ARM

With the rise of hybrid work, employees might use their personal or unmanaged devices to access corporate resources, leading to an increased possibility of token theft. To mitigate this risk, organizations can enhance their security measures by obtaining complete visibility into their users’ authentication methods and locations. Refer to the comprehensive blog post Token tactics: How to prevent, detect, and respond to cloud token theft. 

Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links upon time of click and delete sent mail in response to newly acquired threat intelligence. Turn on Safe Attachments policies to check attachments in inbound emails. 

Detections for related techniques

Leveraging its cross-signal capabilities, Microsoft Defender XDR alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, Microsoft Defender for Cloud, and Microsoft Entra ID Protection to detect the techniques covered in the attack through the attack chain. Each product can provide a different aspect for protection to cover the techniques observed in this attack:

Microsoft Defender XDR

Microsoft Defender XDR detects threat components associated with the following activities:

• User compromised in AiTM phishing attack
• User compromised via a known AiTM phishing kit
• BEC financial fraud-related reconnaissance
• BEC financial fraud

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors for Microsoft 365 and Azure, Microsoft Defender XDR raises the following alerts:

• Stolen session cookie was used
• Activity from anonymous IP address
• Activity from a password-spray associated IP address
• User added or updated a suspicious OAuth app
• Risky user created or updated an app that was observed creating a bulk of Azure virtual machines in a short interval
• Risky user updated an app that accessed email and performed email activity through Graph API
• Suspicious creation of OAuth app by compromised user
• Suspicious secret addition to OAuth app followed by creation of Azure virtual machines
• Suspicious OAuth app creation
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app-related activity by compromised user
• Suspicious user signed into a newly created OAuth app
• Suspicious addition of OAuth app permissions
• Suspicious inbox manipulation rule
• Impossible travel activity
• Multiple failed login attempts

App governance

App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Online administrative activities along with other threat detection alerts. Activity related to this campaign triggers the following alerts:

• Entra Line-of-Business app initiating an anomalous spike in virtual machine creation
• OAuth app with high scope privileges in Microsoft Graph was observed initiating virtual machine creation
• Suspicious OAuth app used to send numerous emails

To receive this alert, turn on app governance for Microsoft Defender for Cloud Apps.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• User restricted from sending email
• Email sending limit exceeded

Microsoft Defender for Cloud

Microsoft Defender for Cloud detects threat components associated with the activities outlined in this article with the following alerts:

• Azure Resource Manager operation from suspicious proxy IP address
• Crypto-mining activity
• Digital currency mining activity
• Suspicious Azure role assignment detected
• Suspicious creation of compute resources detected
• Suspicious invocation of a high-risk ‘Execution’ operation by a service principal detected
• Suspicious invocation of a high-risk ‘Execution’ operation detected
• Suspicious invocation of a high-risk ‘Impact’ operation by a service principal detected

Microsoft Entra Identity Protection

Microsoft Entra Identity Protection detects the threats described with the following alerts:

• Anomalous Token
• Unfamiliar sign-in properties
• Anonymous IP address
• Verified threat actor IP
• Atypical travel

Hunting guidance

Microsoft 365 Defender

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

OAuth application interacting with Azure workloads

let OAuthAppId = <OAuth app ID in question>;
CloudAppEvents
| where Timestamp >ago (7d)  
| where AccountId == OAuthAppId 
| where AccountType== "Application"
| extend Azure_Workloads = RawEventData["operationName"]
| distinct Azure_Workloads by AccountId

Password spray attempts

This query identifies failed sign-in attempts to Microsoft Exchange Online from multiple IP addresses and locations.

IdentityLogonEvents
| where Timestamp > ago(3d)
| where ActionType == "LogonFailed" and LogonType == "OAuth2:Token" and Application == "Microsoft Exchange Online"
| summarize count(), dcount(IPAddress), dcount(CountryCode) by AccountObjectId, AccountDisplayName, bin(Timestamp, 1h)

Suspicious application creation

This query finds new applications added in your tenant.

CloudAppEvents
| where ActionType in ("Add application.", "Add service principal.")
| mvexpand modifiedProperties = RawEventData.ModifiedProperties
| where modifiedProperties.Name == "AppAddress"
| extend AppAddress = tolower(extract('\"Address\": \"(.*)\",',1,tostring(modifiedProperties.NewValue)))
| mvexpand ExtendedProperties = RawEventData.ExtendedProperties
| where ExtendedProperties.Name == "additionalDetails"
| extend OAuthApplicationId = tolower(extract('\"AppId\":\"(.*)\"',1,tostring(ExtendedProperties.Value)))
| project Timestamp, ReportId, AccountObjectId, Application, ApplicationId, OAuthApplicationId, AppAddress

Suspicious email events

NOTE: These queries need to be updated with timestamps related to application creation time before running.

//Identify High Outbound Email Sender
EmailEvents 
| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId)
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| sort by UniqueEmailSentCount desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender sent more than the threshold
//| take 100 //Optional, return only top 100
 
//Identify Suspicious Outbound Email Sender
EmailEvents 
//| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId, 
    DetectionMethods,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId),
    SuspiciousEmailCount = dcountif(NetworkMessageId,isnotempty(DetectionMethods))
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| extend SuspiciousEmailPercentage = SuspiciousEmailCount/UniqueEmailSentCount * 100 //Calculate the percentage of suspicious email compared to all email sent
| sort by SuspiciousEmailPercentage desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender suspicious email percentage is more than the threshold
//| take 100 //Optional, return only top 100

//Identify Recent Emails Sent by Restricted Email Sender
AlertEvidence
| where Title has "User restricted from sending email"
| project AccountObjectId //Identify the user who are restricted to send email
| join EmailEvents on $left.AccountObjectId == $right.SenderObjectId //Join information from Alert Evidence and Email Events
| project
    Timestamp,
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    SenderIPv4,
    Subject,
    UrlCount,
    AttachmentCount,
    DetectionMethods,
    AuthenticationDetails, 
    NetworkMessageId
| sort by Timestamp desc 
//| take 100 //Optional, return only first 100

BEC recon and OAuth application activity

//High and Medium risk SignIn activity
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode==0
| where RiskLevelDuringSignIn >= 50
| project
    AccountUpn,
    AccountObjectId,
    SessionId,
    RiskLevelDuringSignIn,
    ApplicationId,
    Application

//Oauth Application creation or modification by user who has suspicious sign in activities
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode == 0
| where RiskLevelDuringSignIn >= 50
| project SignInTime=AccountUpn, AccountObjectId, SessionId, RiskLevelDuringSignIn, ApplicationId, Application
| join kind=leftouter (CloudAppEvents | where Timestamp > ago(7d)
| where ActionType in ("Add application.", "Update application.", "Update application – Certificates and secrets management ")
| extend appId = tostring(parse_json(RawEventData.Target[4].ID))
| project
    Timestamp,
    ActionType,
    Application,
    ApplicationId,
    UserAgent,
    ISP,
    AccountObjectId,
    AppName=ObjectName,
    OauthApplicationId=appId,
    RawEventData ) on AccountObjectId
| where isnotempty(ActionType)

 
//Suspicious BEC reconnaisance activity 
let bec_keywords = pack_array("payment", "receipt", "invoice", "inventory"); 
let reconEvents = 
    CloudAppEvents
    | where Timestamp >ago (7d)
    | where ActionType in ("MailItemsAccessed", "Update")
    | where AccountObjectId in ("<Impacted AccountObjectId>")
    | extend SessionId = tostring(parse_json(RawEventData.SessionId))
    | project
        Timestamp,
        ActionType,
        AccountObjectId,
        UserAgent,
        ISP,
        IPAddress,
        SessionId,
        RawEventData;
reconEvents;
let updateActions = reconEvents
    | where ActionType == "Update" 
    | extend Subject=tostring(RawEventData["Item"].Subject)
    | where isnotempty(Subject)
    | where Subject has_any (bec_keywords)
    | summarize UpdateCount=count() by bin (Timestamp, 15m), Subject, AccountObjectId, SessionId, IPAddress;
updateActions;
let mailItemsAccessedActions = reconEvents 
    | where ActionType == "MailItemsAccessed" 
    | extend OperationCount = toint(RawEventData["OperationCount"])
    | summarize TotalCount = sum(OperationCount) by bin (Timestamp, 15m), AccountObjectId, SessionId, IPAddress;
mailItemsAccessedActions;
 
//SignIn to newly created app within Risky Session
AADSignInEventsBeta
| where Timestamp >ago (7d) 
| where AccountObjectId in ("<Impacted AccountObjectId>") and 
SessionId in ("<Risky Session Id>")
| where ApplicationId in ("<Oauth appId>") // Recently added or modified App Id
| project
    AccountUpn,
    AccountObjectId,
    ApplicationId,
    Application,
    SessionId,
    RiskLevelDuringSignIn,
    RiskLevelAggregated,
    Country

// To check suspicious Mailbox rules
CloudAppEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours, usually before spam emails sent
| where AccountObjectId in ("<Impacted AccountObjectId>")
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox", "Set-TransportRule", "New-TransportRule", "Enable-InboxRule", "UpdateInboxRules")
| where isnotempty(IPAddress)
| mvexpand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
| project Timestamp, ReportId, ActionType, AccountObjectId, IPAddress, ISP, RuleName

// To check any suspicious Url clicks from emails before risky signin by the user
UrlClickEvents
| where Timestamp between (start .. end) //Timestamp around time proximity of Risky signin by user
| where AccountUpn has "<Impacted User’s UPN or Email address>" and ActionType has "ClickAllowed"
| project Timestamp,Url,NetworkMessageId

// To fetch the suspicious email details
EmailEvents
| where Timestamp between (start .. end) //Timestamp lookback to be increased gradually to find the email received
| where EmailDirection has "Inbound"
| where RecipientEmailAddress has "<Impacted User’s UPN or Email address>" and NetworkMessageId == "<NetworkMessageId from UrlClickEvents>"
| project SenderFromAddress,SenderMailFromAddress,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount
    
    
// To check if suspicious emails sent for spamming (with similar email subjects, urls etc.)
EmailEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours upto 24 hours or more
| where EmailDirection in ("Outbound","Intra-org")
| where SenderFromAddress has "<Impacted User’s UPN or Email address>"  or SenderMailFromAddress has "<Impacted User’s UPN or Email address>"
| project RecipientEmailAddress,RecipientObjectId,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount,NetworkMessageId

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.

Analytic rules:

• Phishing Link Execution Observed
• Possible AiTM Phishing Attempt Against AAD
• Successful Signins from a Phishing Link
• Signin Password Spray
• Malicious Inbox Rule
• BEC Mailbox Rule

Hunting queries:

• Open Email Link
• Creation of an anomalous number of resources
• Creation of expensive computes in Azure

Learn more

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 LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Threat actors misuse OAuth applications to automate financially driven attacks appeared first on Microsoft Security Blog.

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

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

Over the past several years, the cryptocurrency market has considerably expanded, gaining the interest of investors and threat actors. Cryptocurrency itself has been used by cybercriminals for their operations, notably for ransom payment in ransomware attacks, but we have also observed threat actors directly targeting organizations within the cryptocurrency industry for financial gain. Attacks targeting this market have taken many forms, including fraud, vulnerability exploitation, fake applications, and usage of info stealers, as attackers attempt to get their hands on cryptocurrency funds.

We are also seeing more complex attacks wherein the threat actor shows great knowledge and preparation, taking steps to gain their target’s trust before deploying payloads. For example, Microsoft recently investigated an attack where the threat actor, tracked as DEV-0139, took advantage of Telegram chat groups to target cryptocurrency investment companies. DEV-0139 joined Telegram groups used to facilitate communication between VIP clients and cryptocurrency exchange platforms and identified their target from among the members. The threat actor posed as representatives of another cryptocurrency investment company, and in October 2022 invited the target to a different chat group and pretended to ask for feedback on the fee structure used by cryptocurrency exchange platforms. The threat actor had a broader knowledge of this specific part of the industry, indicating that they were well prepared and aware of the current challenge the targeted companies may have.

After gaining the target’s trust, DEV-0139 then sent a weaponized Excel file with the name OKX Binance & Huobi VIP fee comparision.xls which contained several tables about fee structures among cryptocurrency exchange companies. The data in the document was likely accurate to increase their credibility. This weaponized Excel file initiates the following series of activities:

1. A malicious macro in the weaponized Excel file abuses UserForm of VBA to obfuscate the code and retrieve some data.
2. The malicious macro drops another Excel sheet embedded in the form and executes it in invisible mode. The said Excel sheet is encoded in base64, and dropped into C:\ProgramData\Microsoft Media\ with the name VSDB688.tmp
3. The file VSDB688.tmp downloads a PNG file containing three executables: a legitimate Windows file named logagent.exe, a malicious version of the DLL wsock32.dll, and an XOR encoded backdoor.
4. The file logagent.exe is used to sideload the malicious wsock32.dll, which acts as a DLL proxy to the legitimate wsock32.dll. The malicious DLL file is used to load and decrypt the XOR encoded backdoor that lets the threat actor remotely access the infected system.

Further investigation through our telemetry led to the discovery of another file that uses the same DLL proxying technique. But instead of a malicious Excel file, it is delivered in an MSI package for a CryptoDashboardV2 application, dated June 2022. This may suggest other related campaigns are also run by the same threat actor, using the same techniques.

In this blog post, we will present the details uncovered from our investigation of the attack against a cryptocurrency investment company, as well as analysis of related files, to help similar organizations understand this kind of threat, and prepare for possible attacks. Researchers at Volexity recently published their findings on this attack as well.

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

Initial compromise

To identify the targets, the threat actor sought out members of cryptocurrency investment groups on Telegram. In the specific attack, DEV-0139 got in touch with their target on October 19, 2022 by creating a secondary Telegram group with the name <NameOfTheTargetedCompany> <> OKX Fee Adjustment and inviting three employees. The threat actor created fake profiles using details from employees of the company OKX. The screenshot below shows the real accounts and the malicious ones for two of the users present in the group.

It’s worth noting that the threat actor appears to have a broad knowledge of the cryptocurrency industry and the challenges the targeted company may face. The threat actor asked questions about fee structures, which are the fees used by crypto exchange platforms for trading. The fees are a big challenge for investment funds as they represent a cost and must be optimized to minimize impact on margin and profits. Like many other companies in this industry, the largest costs come from fees charged by exchanges. This is a very specific topic that demonstrates how the threat actor was advanced and well prepared before contacting their target.

After gaining the trust of the target, the threat actor sent a weaponized Excel document to the target containing further details on the fees to appear legitimate. The threat actor used the fee structure discussion as an opportunity to ask the target to open the weaponized Excel file and fill in their information.

Weaponized Excel file analysis

The weaponized Excel file, which has the file name OKX Binance & Huobi VIP fee comparision.xls (Sha256: abca3253c003af67113f83df2242a7078d5224870b619489015e4fde060acad0), is well crafted and contains legitimate information about the current fees used by some crypto exchanges. The metadata extracted showed that the file was created by the user Wolf:

The macro is obfuscated and abuses UserForm (a feature used to create windows) to store data and variables. In this case, the name of the UserForm is IFUZYDTTOP, and the macro retrieves the information with the following code IFUZYDTTOP.MgQnQVGb.Caption where MgQnQVGb is the name of the label in the UserForm and .caption allows to retrieve the information stored into the UserForm.

The table below shows the data retrieved from the UserForm:

The macro retrieves some parameters from the UserForm as well as another XLS file stored in base64. The XLS file is dropped into the directory C:\ProgramData\Microsoft Media as VSDB688.tmp and runs in invisible mode.

Additionally, the main sheet in the Excel file is protected with the password dragon to encourage the target to enable the macros. The sheet is then unprotected after installing and running the other Excel file stored in Base64. This is likely used to trick the user to enable macros and not raise suspicion.

Extracted worksheet

The second Excel file, VSDB688.tmp (Sha256: a2d3c41e6812044573a939a51a22d659ec32aea00c26c1a2fdf7466f5c7e1ee9), is used to retrieve a PNG file that is parsed later by the macro to extract two executable files and the encrypted backdoor. Below is the metadata for the second worksheet:

The table below shows the deobfuscated data retrieved from the UserForm:

The macro retrieves some parameters from the UserForm then downloads a PNG file from hxxps://od.lk/d/d021d412be456a6f78a0052a1f0e3557dcfa14bf25f9d0f1d0d2d7dcdac86c73/Background.png. The file was no longer available at the time of analysis, indicating that the threat actor likely deployed it only for this specific attack.

The PNG is then split into three parts and written in three different files: the legitimate file logagent.exe, a malicious version of wsock32.dll, and the XOR encrypted backdoor with the GUID (56762eb9-411c-4842-9530-9922c46ba2da). The three files are used to load the main payload to the target system.

Loader analysis

Two of the three files extracted from the PNG file, logagent.exe and wsock32.dll, are used to load the XOR encrypted backdoor. The following sections present our in-depth analysis of both files.

Logagent.exe

Logagent.exe (Hash: 8400f2674892cdfff27b0dfe98a2a77673ce5e76b06438ac6110f0d768459942) is a legitimate system application used to log errors from Windows Media Player and send the information for troubleshooting.

The file contains the following metadata, but it is not signed:

The logagent.exe imports function from the wsock32.dll which is abused by the threat actor to load malicious code into the targeted system. To trigger and run the malicious wsock32.dll, logagent.exe is run with the following arguments previously retrieved by the macro: 56762eb9-411c-4842-9530-9922c46ba2da /shadow. Both arguments are then retrieved by wsock32.dll. The GUID 56762eb9-411c-4842-9530-9922c46ba2da is the filename for the malicious wsock32.dll to load and /shadow is used as an XOR key to decrypt it. Both parameters are needed for the malware to function, potentially hindering isolated analysis.

Wsock32.dll

The legitimate wsock32.dll is the Windows Socket API used by applications to handle network connections. In this attack, the threat actor used a malicious version of wsock32.dll to evade detection. The malicious wsock32.dll is loaded by logagent.exe through DLL side-loading and uses DLL proxying to call the legitimate functions from the real wsock32.dll and avoid detection. DLL proxying is a hijacking technique where a malicious DLL sits in between the application calling the exported function and a legitimate DLL that implements that exported function. In this attack, the malicious wsock32.dll acts as a proxy between logagent.exe and the legitimate wsock32.dll.

It is possible to notice that the DLL is forwarding the call to the legitimate functions by looking at the import address table:

When the malicious wsock32.dll is loaded, it first retrieves the command line, and checks if the file with the GUID as a filename is present in the same directory using the CreateFile API to retrieve a file handle.

The malicious wsock32.dll loads and decodes the final implant into the memory with the GUID name which is used to remote access the infected machine.

Once the file is loaded into the memory, it gives remote access to the threat actor. At the time of the analysis, we could not retrieve the final payload. However, we identified another variant of this attack and retrieved the payload, which is discussed in the next section. Identified implants were connecting back to the same command-and-control (C2) server.

Related attack

We identified another file using a similar mechanism as logagent.exe and delivering the same payload. The loader is packaged as an MSI package and as posed an application called CryptoDashboardV2 (Hash: e5980e18319027f0c28cd2f581e75e755a0dace72f10748852ba5f63a0c99487). After installing the MSI, it uses a legitimate application called tplink.exe to sideload the malicious DLL called DUser.dll and uses  DLL proxying as well.

Once the package is installed, it runs and side-loads the DLL using the following command: C:\Users\user\AppData\Roaming\Dashboard_v2\TPLink.exe” 27E57D84-4310-4825-AB22-743C78B8F3AA /sven, where it noticeably uses a different GUID.

Further analysis of the malicious DUser.dll showed that its original name is also HijackingLib.dll, same as the malicious wsock32.dll. This could indicate the usage of the same tool to create these malicious DLL proxies. Below are the file details of DUser.dll:

Once the DLL is running, it loads and decodes the implant in the memory and starts beaconing the same domain. In that case, the implant is using the GUID name 27E57D84-4310-4825-AB22-743C78B8F3AA and the XOR key /sven.

Implant analysis

The payload decoded in the memory by the malicious DLL is an implant used by the threat actor to remotely access the compromised machine. We were able to get the one from the second variant we uncovered. Below are the details of the payload:

First, the sample retrieves some information from the targeted system. It can connect back to a remote server and receive commands from it.

Infrastructure

It is interesting to notice that the threat actor abused OpenDrive in one of the variants to deliver the payload. The OpenDrive account has been set up quickly for a one shot, indicating that it was created for only one target.

We identified one domain used as C2 server, strainservice[.]com and connected back to the two implants. This domain was registered on June 26 on Namecheap, just before the distribution of the first variant. At the time of the attack, the server had port 80, 443, and 2083. The implants were communicated on port 443.

Defending against targeted attacks

In this report we analyzed a targeted attack on cryptocurrency investment fund startups. Such companies are relatively new, but manage hundreds of millions of dollars, raising interest by threat actors.   

In this attack we identified that the threat actor has broad knowledge of the cryptocurrency industry as well as the challenges their targets may face, increasing the sophistication of the attack and their chance of success. The threat actor used Telegram, an app widely used in the field, to identify the profile of interest, gained the target’s trust by discussing relevant topics, and finally sent a weaponized document that delivered a backdoor through multiple mechanisms. Additionally, the second attack identified was luring a fake crypto dashboard application.

The cryptocurrency market remains a field of interest for threat actors. Targeted users are identified through trusted channels to increase the chance of success. While the biggest companies can be targeted, smaller companies can also be targets of interest. The techniques used by the actor covered in this blog can be mitigated by adopting the security considerations provided below:

• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Educate end users about protecting personal and business information in social media, filtering unsolicited communication (in this case, Telegram chat groups), identifying lures in spear-phishing email and watering holes, and reporting of reconnaissance attempts and other suspicious activity.
• Educate end users about preventing malware infections, such as ignoring or deleting unsolicited and unexpected emails or attachments sent via instant messaging applications or social networks. Encourage end users to practice good credential hygiene and make sure the Microsoft Defender Firewall (which is enabled by default) is always on to prevent malware infection and stifle propagation.
• Change Excel macro security settings to control which macros run and under what circumstances when you open a workbook. Customers can also stop malicious XLM or VBA macros by ensuring runtime macro scanning by Antimalware Scan Interface (AMSI) is on. This feature—enabled by default—is on if the Group Policy setting for Macro Run Time Scan Scope is set to “Enable for All Files” or “Enable for Low Trust Files”.
• Turn on attack surface reduction rules to prevent common attack techniques observed in this threat:
  • Block Office applications from creating executable content
  • Block Office communication application from creating child processes
  • Block Win32 API calls from Office macros
• Ensure that Microsoft Defender Antivirus is up to date and that real-time behavior monitoring is enabled.

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• TrojanDownloader:O97M/Wolfic.A
• TrojanDownloader:O97M/Wolfic.B
• TrojanDownloader:O97M/Wolfic.C
• TrojanDownloader:Win32/Wolfic.D
• TrojanDownloader:Win32/Wolfic.E
• Behavior:Win32/WolficDownloader.A
• Behavior:Win32/WolficDownloader.B

Microsoft Defender for Endpoint

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

• An executable loaded an unexpected dll
• DLL search order hijack
• ‘Wolfic’ malware was prevented

Advanced hunting queries

The following hunting queries locate relevant activity.

Query that looks for Office apps that create a file within one of the known bad directories:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "outlook" "powerpnt")
| where ActionType == "FileCreated"
| where parse_path( FolderPath ).DirectoryPath has_any(
    @"C:\ProgramData\Microsoft Media",
    @"C:\ProgramData\SoftwareCache",
    @"Roaming\Dashboard_v2"
    )
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName, SHA256, InitiatingProcessAccountName, InitiatingProcessAccountDomain

Query that looks for Office apps that create a file within an uncommon directory (less that five occurrences), makes a set of each machine this is seen on, and each user that has executed it to help look for how many users/hosts are compromised:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "outlook", "powerpnt")
| where ActionType == "FileCreated"
| extend Path = tostring(parse_path(FolderPath).DirectoryPath)
| summarize PathCount=count(), DeviceList=make_set(DeviceName), AccountList=make_set(InitiatingProcessAccountName) by FileName, Path, InitiatingProcessFileName, SHA256
| where PathCount < 5

Query that summarizes child process of Office apps, looking for less than five occurrences:

DeviceProcessEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| summarize ProcessCount=count(), DeviceList=make_set(DeviceName), AccountList=make_set(InitiatingProcessAccountName) by FileName, FolderPath, SHA256, InitiatingProcessFileName
| where ProcessCount < 5

Query that lists of all executables with Microsoft as ProcessVersionInfoCompanyName, groups them together by path, then looks for uncommon paths, with less than five occurrences:

DeviceProcessEvents
| where ProcessVersionInfoCompanyName has "Microsoft"
| extend Path = tostring(parse_path(FolderPath).DirectoryPath)
| summarize ProcessList=make_set(FileName) by Path
| where array_length( ProcessList ) < 5

Query that searches for connections to malicious domains and IP addresses:

DeviceNetworkEvents
| where (RemoteUrl has_any ("strainservice.com")) 
     or (RemoteIP has_any ("198.54.115.248"))

Query that searches for files downloaded from malicious domains and IP addresses.

DeviceFileEvents
| where (FileOriginUrl  has_any ("strainservice.com")) 
     or (FileOriginIP  has_any ("198.54.115.248"))

Query that searchers for Office apps downloading files from uncommon domains, groups users, filenames, and devices together:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| where ActionType == "FileCreated"
| where isnotempty( FileOriginUrl ) or isnotempty( FileOriginIP )
| summarize DomainCount=count(), UserList=make_set(InitiatingProcessAccountName), DeviceList=make_set(DeviceName),
    FileList=make_set(FileName) by FileOriginUrl, FileOriginIP, InitiatingProcessFileName

Looks for downloaded files with uncommon file extensions, groups remote IPs, URLs, filenames, users, and devices:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt", "outlook")
| where ActionType == "FileCreated"
| where isnotempty( FileOriginUrl ) or isnotempty( FileOriginIP )
| extend Extension=tostring(parse_path(FolderPath).Extension)
| extend  Path=tostring(parse_path(FolderPath).DirectoryPath)
| summarize ExtensionCount=count(), IpList=make_set(FileOriginIP), UrlList=make_set(FileOriginUrl), FileList=make_set(FileName),
    UserList=make_set(InitiatingProcessAccountName), DeviceList=make_set(DeviceName) by Extension, InitiatingProcessFileName

Looks for Office apps that have child processes that match the GUID command line, with a check for Microsoft binaries to reduce the results before the regex:

DeviceProcessEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| where ProcessVersionInfoCompanyName has "Microsoft"
| where ProcessCommandLine matches regex 
    @"[A-Za-z0-9]+\.exe [A-Za-z0-9]{8}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{12} /[A-Za-z0-9]$"

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious IP and 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. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

To supplement this indicator matching customers can use the Advanced Hunting queries listed above against Microsoft 365 Defender data ingested into their workspaces as well as the following Microsoft Sentinel queries:

• Least common parent and child process pairs: https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Windows%20Security%20Events/Hunting%20Queries/Least_Common_Parent_Child_Process.yaml

• Detect anomalous process trees: https://github.com/Azure/Azure-Sentinel/blob/46906229919827bffa14211341f52dd68e27ad81/Hunting%20Queries/Microsoft%20365%20Defender/Execution/detect-anomalous-process-trees.yaml

Indicators of compromise

MITRE ATT&CK techniques

The post DEV-0139 launches targeted attacks against the cryptocurrency industry appeared first on Microsoft Security Blog.

To provide advanced protection against these increasingly complex and evasive threats, Microsoft Defender Antivirus uses various sensors and detection technologies, including its integration with Intel® Threat Detection Technology (TDT), which applies machine learning to low-level CPU telemetry to detect threats even when the malware is obfuscated and can evade security tools.

Using this silicon-based threat detection, Defender analyzes signals from the CPU performance monitoring unit (PMU) to detect malware code execution “fingerprint” at run time and gain unique insights into malware at their final execution point, the CPU. The combined actions of monitoring at the hardware level, analyzing patterns of CPU usage, and using threat intelligence and machine learning at the software level enable the technology to defend against cryptojacking effectively.

In this blog post, we share details from our monitoring and observation of cryptojackers and how the integration of Intel TDT and Microsoft Defender Antivirus detects and blocks this complex threat.

Looking at the current cryptojacker landscape

There are many ways to force a device to mine cryptocurrency without a user’s knowledge or consent. The three most common approaches used by cryptojackers are the following:

• Executable: These are typically potentially unwanted applications (PUAs) or malicious executable files placed on the devices and designed to use system resources to mine cryptocurrencies.
• Browser-based: These miners are typically in the form of JavaScript (or similar technology) and perform their function in a web browser, consuming resources for as long as the browser remains open on the website where they are hosted. These miners are commonly injected into legitimate websites without the owner’s knowledge or consent. In other cases, the miners are intentionally included in attacker-owned or less reputable websites that users might visit.
• Fileless: These cryptojackers perform mining in a device’s memory and achieve persistence by misusing legitimate tools and LOLBins.

The executable and browser-based approaches involve malicious code that’s present in either the filesystem or website that can be relatively easily detected and blocked. The fileless approach, on the other hand, misuses local system binaries or preinstalled tools to mine using the device’s memory. This approach allows attackers to achieve their goals without relying on specific code or files. Moreover, the fileless approach enables cryptojackers to be delivered silently and evade detection. These make the fileless approach more attractive to attackers.

While newer cryptojackers use the fileless approach, its engagement of the hardware, which it relies on for its mining algorithm, becomes one of the ways to detect cryptojacking activities.

Misuse of LOLBins in recent cryptojacking campaigns

Through its various sensors and advanced detection methodologies, including its integration with Intel TDT, Microsoft Defender Antivirus sees cryptojackers that take advantage of legitimate system binaries on more than 200,000 devices daily.

Attackers heavily favor the misuse of notepad.exe among several legitimate system tools in observed campaigns.

We analyzed an interesting cryptojacking campaign abusing notepad.exe and several other binaries to carry out its routines. This campaign used an updated version of the cryptojacker known as Mehcrypt. This new version packs all of its routines into one script and connects to a command-and-control (C2) server in the latter part of its attack chain, a significant update from the old version, which ran a script to access its C2 and download additional components that then perform malicious actions.

The threat arrives as an archive file containing autoit.exe and a heavily obfuscated, randomly named .au3 script. Opening the archive file launches autoit.exe, whichdecodes the .au3 script in memory. Once running, the script further decodes several layers of obfuscation and loads additional decoded scripts in memory.

The script then copies itself and autoit.exe in a randomly named folder in C:\ProgramData. The script creates a scheduled task to delete the original files and adds autostart registry entries to run the script every time the device starts.

After adding persistence mechanisms, the script then loads malicious code into VBC.exe via process hollowing and connects to a C2 server to listen for commands. Based on the C2 response, the script loads its cryptojacking code into notepad.exe, likewise via process hollowing.

At this point, as the threat starts its cryptojacking operation via malicious code injected into notepad.exe, a huge jump in CPU usage can be observed:

This high CPU usage anomaly is analyzed in real-time by both Intel TDT and Microsoft Defender Antivirus. Based on Intel TDT’s machine learning-based correlation of CPU telemetry and other suspicious activities like process injection into system binaries, Microsoft Defender Antivirus blocks the process execution (Behavior:Win32/CoinMiner.CN!tdt), and Microsoft Defender for Endpoint raises an alert.  

Advanced threat detection technology helps stop cryptojacking activities

To detect evasive cryptojackers, Microsoft Defender Antivirus and Intel TDT work together to monitor and correlate hardware and software threat data. Intel TDT leverages signals from the CPU, analyzing these signals to detect patterns modeled after cryptojacking activity using machine learning. Microsoft Defender Antivirus then uses these signals and applies its threat intelligence and machine learning techniques to identify and block the action at the software level.  

Intel TDT has added several performance improvements and optimizations, such as offloading the machine learning inference to Intel’s integrated graphics processing unit (GPU) to enable continuous monitoring. This capability is available on Intel Core™ processors and Intel vPro® branded platforms from the 6^th generation onwards. By design, Microsoft Defender Antivirus leverages these offloading capabilities where applicable.

In addition to industry partnerships, Microsoft’s consistent monitoring of the threat landscape powers the threat intelligence that feeds into products like Microsoft Defender Antivirus and Microsoft Defender for Endpoint, where knowledge is translated to customer protection in real-time.

Suriyaraj Natarajan, Andrea Lelli, Amitrajit Banerjee
Microsoft 365 Defender Research Team

The post Hardware-based threat defense against increasingly complex cryptojackers appeared first on Microsoft Security Blog.

Cryware are information stealers that collect and exfiltrate data directly from non-custodial cryptocurrency wallets, also known as hot wallets. Because hot wallets, unlike custodial wallets, are stored locally on a device and provide easier access to cryptographic keys needed to perform transactions, more and more threats are targeting them.

Cryware signifies a shift in the use of cryptocurrencies in attacks: no longer as a means to an end but the end itself. Before cryware, the role of cryptocurrencies in an attack or the attack stage where they figured varied depending on the attacker’s overall intent. For example, some ransomware campaigns prefer cryptocurrency as a ransom payment. However, that requires the target user to manually do the transfer. Meanwhile, cryptojackers—one of the prevalent cryptocurrency-related malware—do try to mine cryptocurrencies on their own, but such a technique is heavily dependent on the target device’s resources and capabilities.

With cryware, attackers who gain access to hot wallet data can use it to quickly transfer the target’s cryptocurrencies to their own wallets. Unfortunately for the users, such theft is irreversible: blockchain transactions are final even if they were made without a user’s consent or knowledge. In addition, unlike credit cards and other financial transactions, there are currently no available mechanisms that could help reverse fraudulent cryptocurrency transactions or protect users from such.

To find hot wallet data such as private keys, seed phrases, and wallet addresses, attackers could use regular expressions (regexes), given how these typically follow a pattern of words or characters. These patterns are then implemented in cryware, thus automating the process. The attack types and techniques that attempt to steal these wallet data include clipping and switching, memory dumping, phishing, and scams.

As cryptocurrency investing continues to trickle to wider audiences, users should be aware of the different ways attackers attempt to compromise hot wallets. They also need to protect these wallets and their devices using security solutions like Microsoft Defender Antivirus, which detects and blocks cryware and other malicious files, and Microsoft Defender SmartScreen, which blocks access to cryware-related websites. For organizations, data and signals from these solutions also feed into Microsoft 365 Defender, which provides comprehensive and coordinated defense against threats—including those that could be introduced into their networks through user-owned devices or non-work-related applications.

In this blog, we provide details of the different attack surfaces targeting hot wallets. We also offer best practice recommendations that help secure cryptocurrency transactions.

From cryptojackers to cryware: The growth and evolution of cryptocurrency-related malware

The emergence and boom of cryptocurrency allowed existing threats to evolve their techniques to target or abuse cryptocurrency tokens. The threats that currently leverage cryptocurrency include:

• Cryptojackers. One of the threat types that surfaced and thrived since the introduction of cryptocurrency, cryptojackers are mining malware that hijacks and consumes a target’s device resources for the former’s gain and without the latter’s knowledge or consent. Based on our threat data, we saw millions of cryptojacker encounters in the last year.
• Ransomware. Some threat actors prefer cryptocurrency for ransom payments because it provides transaction anonymity, thus reducing the chances of being discovered.
• Password and info stealers. Apart from sign-in credentials, system information, and keystrokes, many info stealers are now adding hot wallet data to the list of information they search for and exfiltrate.
• ClipBanker trojans. Another type of info stealer, this malware checks the user’s clipboard and steals banking information or other sensitive data a user copies. ClipBanker trojans are also now expanding their monitoring to include cryptocurrency addresses.

The increasing popularity of cryptocurrency has also led to the emergence of cryware like Mars Stealer and RedLine Stealer. These threats aim to steal cryptocurrencies through wallet data theft, clipboard manipulation, phishing and scams, or even misleading smart contracts. For example, RedLine has even been used as a component in larger threat campaigns. The graph below illustrates the increasing trend in unique cryware file encounters Microsoft Defender for Endpoint has detected in the last year alone.

Cryware could cause severe financial impact because transactions can’t be changed once they’re added to the blockchain. As mentioned earlier, there also are currently no support systems that could help recover stolen cryptocurrency funds.

For example, in 2021, a user posted about how they lost USD78,000 worth of Ethereum because they stored their wallet seed phrase in an insecure location. An attacker likely gained access to the target’s device and installed cryware that discovered the sensitive data. Once this data was compromised, the attacker would’ve been able to empty the targeted wallet.

With the growing popularity of cryptocurrency, the impact of cryware threats have become more significant. We’ve already observed campaigns that previously deployed ransomware now using cryware to steal cryptocurrency funds directly from a targeted device. While not all devices have hot wallets installed on them—especially in enterprise networks—we expect this to change as more companies transition or move part of their assets to the cryptocurrency space. Users and organizations must therefore learn how to protect their hot wallets to ensure their cryptocurrencies don’t end up in someone else’s pockets.

Hot wallet attack surfaces

To better protect their hot wallets, users must first understand the different attack surfaces that cryware and related threats commonly take advantage of.

Hot wallet data

During the creation of a new hot wallet, the user is given the following wallet data:

• Private key. The key that’s required to access the hot wallet, sign or authorize transactions, and send cryptocurrencies to other wallet addresses.
• Seed phrase. A mnemonic phrase is a human-readable representation of the private key. It’s another form of a private key that’s easier to remember. Bitcoin Improvement Proposal: 39 (BIP39) is currently the most common standard used to generate seed phrases consisting of 12-14 words (from a predefined list of 2,048).
• Public key. The public address of the wallet that users must enter as the destination address when sending funds to other wallets.
• Wallet password (optional). A standard user account password that some wallet applications offer as an additional protection layer.

Attackers try to identify and exfiltrate sensitive wallet data from a target device because once they have located the private key or seed phrase, they could create a new transaction and send the funds from inside the target’s wallet to an address they own. This transaction is then published to the blockchain of the cryptocurrency of the funds contained in the wallet. Once this action is completed, the target won’t be able to retrieve their funds as blockchains are immutable (unchangeable) by definition.

To locate and identify sensitive wallet data, attackers could use regexes, which are strings of characters and symbols that can be written to match certain text patterns. The following table demonstrates how regexes can be used to match wallet string patterns:

Cryware attack scenarios and examples

Once sensitive wallet data has been identified, attackers could use various techniques to obtain them or use them to their advantage. Below are some examples of the different cryware attack scenarios we’ve observed.

Clipping and switching

In clipping and switching, a cryware monitors the contents of a user’s clipboard and uses string search patterns to look for and identify a string resembling a hot wallet address. If the target user pastes or uses CTRL + V into an application window, the cryware replaces the object in the clipboard with the attacker’s address.

Figure 4, which is a code based on an actual clipper malware we’ve seen in the wild, demonstrates the simplest form of this attack. This code uses regexes to monitor for copied wallet addresses and then swaps the value to be pasted.

While this technique is not new and has been used in the past by info stealers, we’ve observed its increasing prevalence. The technique’s stealthy nature, combined with the length and complexity of wallet addresses, makes it highly possible for users to overlook that the address they pasted does not match the one they originally copied.

Memory dumping

Another technique is memory dumping, which takes advantage of the fact that some user interactions with their hot wallet could display the private keys in plaintext. This critical information might remain in the memory of a browser process performing these actions, thus compromising the wallet’s integrity. Such a scenario also allows an attacker to dump the browser process and obtain the private key.

The screenshot below illustrates such an example. When a private key was exported through a web wallet application, the private key remained available in plaintext inside the process memory while the browser remained running.

Wallet file theft

While more sophisticated cryware threats use regular expressions, clipboard tampering, and process dumping, a simple but effective way to steal hot wallet data is to target the wallet application’s storage files. In this scenario, an attacker traverses the target user’s filesystem, determines which wallet apps are installed, and then exfiltrates a predefined list of wallet files.

Target files and information include the following:

• Web wallet files. Some hot wallets are installed as browser extensions with a unique namespace identifier to name the extension storage folder. A web wallet’s local vault contains the encrypted private key of a user’s wallet and can be found inside this browser app storage folder. Attackers target this vault as it can be brute-forced by many popular tools, such as Hashcat.
  • Example targeted MetaMask vault folder in some web browsers: “Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn”
• Desktop wallet files. Other hot wallets are installed on a user’s desktop device. The private keys are encrypted and stored locally in application storage files specific to each wallet. Attackers could determine which desktop wallet is installed on a target device when stealing information from it. As with the web wallet vaults, wallet storage files containing encrypted private keys provide an excellent opportunity for brute-force attacks.
  • Example targeted Exodus storage files: “Exodus\passphrase.json”, “Exodus\seed.seco”
• Wallet passwords. Some wallet applications require passwords as an additional authentication factor when signing into a wallet. Some users store these passwords and seed phrases or private keys inside password manager applications or even as autofill data in browsers. Attackers could traverse an affected device to discover any password managers installed locally or exfiltrate any browser data that could potentially contain stored passwords.
  • Example targeted browser data: “\Cookies\”, “\Autofill\”

Mars Stealer is a notable cryware that steals data from web wallets, desktop wallets, password managers, and browser files. The snippet below was taken from a section of Mars Stealer code aimed to locate wallets installed on a system and steal their sensitive files:

Mars Stealer is available for sale on hacking forums, as seen in an example post below. The post describes the cryware’s capabilities of stealing sensitive data from multiple wallets and app storage files from an affected device. Mars Stealer then bundles the stolen data and exfiltrates it to an attacker-controlled command-and-control (C2) server via HTTP POST.

Keylogging

Keylogging is another popular technique used by cryware. Like other information-stealing malware that use this technique, keylogging cryware typically runs in the background of an affected device and logs keystrokes entered by the user. It then sends the data it collects to an attacker controlled C2 server.

For attackers, keyloggers have the following advantages:

• No need for brute forcing. Private keys, seed phrases, and other sensitive typed data can be stolen in plaintext.
• Difficult to detect. Keyloggers can run undetected in the background of an affected device, as they generally leave few indicators apart from their processes.
• Stolen data can live in memory. Attackers don’t have to write stolen user data to disk. Instead, they can store the data in process memory before uploading it to the server.

Even users who store their private keys on pieces of paper are vulnerable to keyloggers. Copying and pasting sensitive data also don’t solve this problem, as some keyloggers also include screen capturing capabilities.

Phishing sites and fake applications

To fool users into entering their private keys, attackers create malicious applications that spoof legitimate hot wallets. Unfortunately, determining which app is malicious or legitimate can be challenging because importing an existing wallet does require the input of a private key.

Since a user needs to go to a hot wallet website to download the wallet app installer, attackers could use one of the two kinds of methods to trick users into downloading malicious apps or giving up their private keys:

• Typosquatting: Attackers purchase domains that contain commonly mistyped characters.
• Soundsquatting: Attackers purchase domains with names that sound like legitimate websites.

The screenshot below shows a spoofed MetaMask website. While the domain contains the word “MetaMask,” it has an additional one (“suspend”) at the beginning that users might not notice. This could easily trick a user into entering their private keys to supposedly import their existing wallet, leading to the theft of their funds instead.

Phishing websites may even land at the top of search engine results as sponsored ads. In February 2022, we observed such ads for spoofed websites of the cryptocurrency platform StrongBlock. The topmost fake website’s domain appeared as “strongsblock” (with an additional “s”) and had been related to phishing scams attempting to steal private keys. Note that these ads no longer appear in the search results as of this writing. It’s common practice for internet search engines (such as Google and Edge) to regularly review and remove ad results that are found to be possible phishing attempts.

Some spoofed wallet websites also host fake wallet apps that trick users into installing them. Figure 10 shows an example of a fake wallet app that even mimics the icon of the legitimate one. Like phishing websites, the fake apps’ goal is to trick users into providing sensitive wallet data.

Apart from credential-based phishing tactics in websites and apps, Microsoft security researchers also noted a technique called “ice phishing,” which doesn’t involve stealing keys. Rather, it attempts to trick users into signing a transaction that delegates approval of the target user’s tokens to an attacker. More information about ice phishing can be found in this blog.

Scams and other social engineering tactics

Cryptocurrency-related scams typically attempt to lure victims into sending funds of their own volition. One such scam we’ve seen uses prominent social media personalities who seemingly endorse a particular platform. The scammers promise to “donate” funds to participants who send coins to a listed wallet address. Unfortunately, these promises are never fulfilled.

Social media content creators are also becoming the targets of scam emails. The email messages attempt to trick targets into downloading and executing cryware on their devices by purporting promotional offers and partnership contracts.

In such cases, the downloaded or attached cryware masquerades as a document or a video file using a double extension (for example, .txt.exe) and a spoofed icon. Thus, target users who might be distracted by the message content might also forget to check if the downloaded file is malicious or not.

Defending against cryware

Cryptocurrency crime has been reported to have reached an all-time high in 2021, with over USD10 billion worth of cryptocurrencies stored in wallets associated with ransomware and cryptocurrency theft. This shows that just as large cryptocurrency-related entities get attacked, individual consumers and investors are not spared.  

Cryptocurrency trading can be an exciting and beneficial practice, but given the various attack surfaces cryware threats leverage, users and organizations must note the multiple ways they can protect themselves and their wallets. They should have a security solution that provides multiple layers of dynamic protection technologies—including machine learning-based protection.

Microsoft Defender Antivirus offers such protection. Its endpoint protection capabilities detect and block many cryware, cryptojackers, and other cryptocurrency-related threats. Meanwhile, Microsoft Defender SmartScreen in Microsoft Edge and other web browsers that support it blocks phishing sites and prevents downloading of fake apps and other malware. Signals from these solutions, along with threat data from other domains, feed into Microsoft 365 Defender, which provides organizations with comprehensive and coordinated threat defense and is backed by a global network of security experts who monitor the continuously evolving threat landscape for new and emerging attacker tools and techniques.

Users and organizations can also take the following steps to defend against cryware and other hot wallet attacks:

• Lock hot wallets when not actively trading. This feature in most wallet applications can prevent attackers from creating transactions without the user’s knowledge.
• Disconnect sites connected to the wallet. When a user isn’t actively doing a transaction on a decentralized finance (DeFi) platform, a hot wallet’s disconnect feature ensures that the website or app won’t interact with the user’s wallet without their knowledge.

• Refrain from storing private keys in plaintext. Never store seed phrases on the device or cloud storage services. Instead, write them down on paper (or something equivalent) and properly secure them.
• Be attentive when copying and pasting information. When copying a wallet address for a transaction, double-check if the value of the address is indeed the one indicated on the wallet.
• Ensure that browser sessions are terminated after every transaction. To minimize the risk of cryware process dumpers, properly close or restart the browser’s processesafterimporting keys. This ensures that the private key doesn’t remain in the browser process’s memory.
• Consider using wallets that implement multifactor authentication (MFA). This prevents attackers from logging into wallet applications without another layer of authentication.
• Be wary of links to wallet websites and applications. Phishing websites often make substantial efforts to appear legitimate, so users must be careful when clicking links in emails and messaging apps. Consider manually typing or searching for the website instead and ensure that their domains are typed correctly to avoid phishing sites that leverage typosquatting and soundsquatting.
• Double-check hot wallet transactions and approvals. Ensure that the contract that needs approval is indeed the one initiated.
• Never share private keys or seed phrases. Under no circumstances will a third party or even the wallet app developers need these types of sensitive information.
• Use a hardware wallet unless it needs to be actively connected to a device. Hardware wallets store private keys offline.
• Reveal file extensions of downloaded and saved files. On Windows,turn on File Name Extensions under View on file explorer to see the actual extensions of the files on a device.

Learn how you can stop attacks through automated, cross-domain security with Microsoft 365 Defender.

Berman Enconado and Laurie Kirk
Microsoft 365 Defender Research Team

Appendix

Microsoft 365 Defender detections

Microsoft Defender Antivirus

• Trojan:Win32/Azorult.RMA!MTB
• PWS:MSIL/RedLine.GG!MTB
• Trojan:Win32/ArkeiStealer.DB!MTB
• Trojan:Win32/Raccoon.AD!MTB
• Trojan:AndroidOS/FakeWallet.A!MTB

The post In hot pursuit of ‘cryware’: Defending hot wallets from attacks appeared first on Microsoft Security Blog.

As containers become a major part of many organizations’ IT workloads, it becomes crucial to consider the unique security threats that target such environments when building security solutions. The first step in this process is understanding the relevant attack landscape.

The MITRE ATT&CK® team has received frequent questions from the community about if or when ATT&CK would include coverage for adversary behavior in containers. Previous iterations of ATT&CK have included references to containers (for example, Resource Hijacking) and some clearly container-relevant techniques (for example, Implant Internal Image), but the coverage was insufficient to provide network defenders a holistic view of how containers are being targeted in enterprise environments.

Addressing the need for a common framework for understanding container threats

Given clear community interest, inspiration from Microsoft’s work on the threat matrix for Kubernetes, and the publication of research from other teams, the Center for Threat-Informed Defense launched an investigation (sponsored by several Center members including Microsoft) that examined the viability of adding containers content to ATT&CK. The purpose of the Container Techniques project was to investigate adversarial behavior in containerization technologies and determine whether there was enough open-source intelligence to warrant the creation of an ATT&CK for Containers matrix, resulting in either new ATT&CK content or a report on the state of in-the-wild Container-based tactics, techniques, and procedures (TTPs). The Center’s research team quickly concluded that there was more than enough open-source intelligence to justify technique development, ultimately resulting in the new matrix.

As of the ATT&CK v9 release, the ATT&CK for Containers matrix is officially available. More details about the Containers matrix can be found in MITRE-Engenuity’s announcement blog. Some highlights of the new matrix include related software entries, procedure examples to help network defenders better understand new container-centric techniques, data sources to match the recent ATT&CK data sources refactor, and many others.

Figure 1. ATT&CK for Containers matrix.

Evolving the threat matrix

MITRE ATT&CK has become the common vocabulary for describing real-world adversary behavior. ATT&CK offers organizations a method to measure their defenses against threats that impact their environment and identify possible gaps. With ATT&CK’s approach of methodically outlining the possible threats, Microsoft built the threat matrix for Kubernetes, which was one of the first attempts to systematically map the attack surface of Kubernetes. An updated version of the matrix was released earlier in 2021.

Figure 2: Threat matrix for Kubernetes.

Microsoft took part in the Center’s project and contributed knowledge that the company gained in the field of container security. Microsoft’s unparalleled visibility into threats helps to identify real-world attacks against containerized workloads and provide information about tactics and techniques used in those attacks. One example of such an attack is a cryptocurrency mining campaign that targeted Kubernetes. In this incident, Microsoft saw evidence of the following techniques from the Microsoft threat matrix:

• Exposed sensitive interfaces
• New container
• Pod/container name similarity
• List Kubernetes secrets
• Access Kubernetes API server
• Resource Hijacking

The techniques that went into ATT&CK for Containers are different from those in the Microsoft threat matrix. As described in a blog post by the Center, it was preferable to use an existing ATT&CK technique rather than create a new one when possible. Therefore, several techniques from the threat matrix were mapped into existing Enterprise ATT&CK techniques. For example, in the techniques listed above, “Exposed sensitive interfaces” from the threat matrix is equivalent to ATT&CK’s “External Remote Services.”

The Center’s process for leveraging Microsoft’s Kubernetes threat matrix was as follows:

• Cross-referencing threat intelligence with the techniques in the Kubernetes threat matrix.
• Determining whether techniques with sufficient intelligence backing were already covered by existing Enterprise ATT&CK techniques, or whether they justified the creation of one or more new techniques or sub-techniques.

Considering Microsoft’s tactics mapping for specific techniques and how they fit within ATT&CK’s Enterprise, Cloud, and Containers matrix scoping, as in the case of multiple forms of “lateral movement,” the Center instead identified pivots from one ATT&CK platform matrix to another (for example, Containers to Cloud).

The following are examples of techniques from Microsoft’s matrix that were re-scoped to fit into existing Enterprise ATT&CK techniques:

Meanwhile, the following are examples of techniques from the Microsoft threat matrix that were re-scoped based on the Center’s platform decisions and additional open-source intelligence, with additional detail on each technique/sub-technique available in its description within ATT&CK for Containers:

Not all the techniques and tactics that appear in the Microsoft threat matrix went into the new ATT&CK matrix. ATT&CK focuses on real-world techniques that are seen in the wild. In contrast, many of the techniques in the threat matrix were observed during research work and not necessarily as part of an active attack. For example, “CoreDNS poisoning” from the updated matrix is a possible attack vector but hasn’t been seen in the wild yet.

ATT&CK is dynamic

ATT&CK for Containers is by no means finished, and we look forward to future additions based on new intelligence and further community contributions. Before the public release of ATT&CK for Containers, Microsoft released an updated version of the threat matrix for Kubernetes, which speaks to the fast-paced evolution of this technology space and the need to keep up with new adversary behaviors.

The next step for the ATT&CK team is to assess the new content in Microsoft’s matrix and consider it for potential future inclusion in ATT&CK based on the factors described above. Microsoft and the ATT&CK team will continue to collaborate to ensure that container techniques coverage in ATT&CK is up-to-date and can continue to serve the need of the community.

With the completion of this Center project, ATT&CK for Containers will be maintained by the ATT&CK team, who would love your continuous feedback and contribution! Let the team know what you think, what could be improved, and most importantly what you see adversaries doing in the wild related to containers. Feel free to send an email at any time to attack@mitre.org. If you have ideas for other research and development projects that the Center should consider, please send an email to ctid@mitre-engenuity.org.

Learn more

To learn how Microsoft can help you protect containers and relevant technologies today, read about Microsoft Defender for Endpoint and Azure Defender.

To learn more about Microsoft Security solutions, visit our website. 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 The evolution of a matrix: How ATT&CK for Containers was built appeared first on Microsoft Security Blog.

In addition, with malware evolving over the years to evade typical anti-malware defenses, detecting coin miners has become increasingly more challenging.

This rising threat is why Microsoft and Intel have been partnering to deliver technology that uses silicon-based threat detection to enable endpoint detection and response (EDR) capabilities in Microsoft Defender for Endpoint to better detect cryptocurrency mining malware, even when the malware is obfuscated and tries to evade security tools.

Intel Threat Detection Technology in Microsoft Defender for Endpoint

Today, we are announcing the integration of Intel Threat Detection Technology (TDT) into Microsoft Defender for Endpoint, an addition that enhances the detection capability and protection against cryptojacking malware. This builds on our existing partnership and prior collaboration to integrate Intel’s Accelerated Memory Scanning with Defender.

Figure 1: CoinMiner alert from Microsoft Defender for Endpoint.

Intel TDT applies machine learning to low-level hardware telemetry sourced directly from the CPU performance monitoring unit (PMU) to detect the malware code execution “fingerprint” at runtime with minimal overhead. TDT leverages a rich set of performance profiling events available in Intel SoCs (system-on-a-chip) to monitor and detect malware at their final execution point (the CPU). This happens irrespective of obfuscation techniques, including when malware hides within virtualized guests, without needing intrusive techniques like code injection or performing complex hypervisor introspection. TDT can further offload machine learning inference to the integrated graphics processing unit (GPU), enabling continuous monitoring with negligible overhead. While we haven’t seen any performance issues with the current deployments, we plan to enable the GPU offloading capabilities of Intel TDT in the near future.

This technology is based on telemetry signals coming directly from the PMU, the unit that records low-level information about performance and microarchitectural execution characteristics of instructions processed by the CPU. Coin miners make heavy use of repeated mathematical operations and this activity is recorded by the PMU, which triggers a signal when a certain usage threshold is reached. The signal is processed by a layer of machine learning which can recognize the footprint generated by the specific activity of coin mining. Since the signal comes exclusively from the utilization of the CPU, caused by execution characteristics of malware, it is unaffected by common antimalware evasion techniques such as binary obfuscation or memory-only payloads.

Figure 2: Diagram showing how Intel TDT and Microsoft Defender detect and remediate malware.

Even though we have enabled this technology specifically for cryptocurrency mining, it expands the horizons for detecting more aggressive threats like side-channel attacks and ransomware. Intel TDT already has the capabilities for such scenarios, and machine learning can be trained to recognize these attack vectors.

Figure 3: Intel TDT and Microsoft Defender detect malware. The user is notified of a threat via a Windows Security notification.

Figure 4: Windows security protection history showing CoinMiner threat blocked. Detected with Intel TDT and Microsoft Defender.

This technology doesn’t require any additional investments, IT configuration, or installation of agents. The Microsoft Defender for Endpoint and Intel TDT integrated solution works natively with Intel® Core™ processors and the Intel vPro® platform, 6th Generation or later.

Since the main signal used for this detection capability comes right from the hardware (the Intel CPU), it can detect coin miners running inside unprotected virtual machines and other containers. This demo video showcases how, in such a scenario, Microsoft Defender for Endpoint can stop the virtual machine itself or report virtual machine abuse, thus preventing the spread of an attack as well as saving resources. This is one step towards agentless malware detection, where the “protector” can protect the asset from the “attacker” without having to be in the same OS.

As we enable the technology on more and more supported platforms, we are getting valuable machine learning telemetry back, which informs and makes the existing models better and more effective.

As organizations look to simplify their security investments, we’re committed to our focus on built-in platform-based security technologies, delivering a best-of-breed and streamlined solution that empowers defenders to elevate their security and protect their organizations. This partnership is part of Microsoft’s investment into collaborations with original equipment manufacturers (OEMs) and technology partners. We’re working closely with chipmakers to always explore new possibilities for hardware-based defense hardening and deliver robust and resilient protection against cyber threats.

Learn more

For additional details, please read Intel’s News Byte.

Microsoft Defender for Endpoint is an industry-leading, cloud-powered endpoint security solution offering vulnerability management, endpoint protection, endpoint detection and response, and mobile threat defense. With our solution, threats are no match. If you are not yet taking advantage of Microsoft’s unrivaled threat optics and proven capabilities, sign up for a free trial of Microsoft Defender for Endpoint today.

To learn more about Microsoft Security solutions visit our website. 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.

Amitrajit Banerjee, Andrea Lelli, Gowtham Animi Reddy, Karthik Selvaraj, Kelvin Chan, Shweta Jha

Microsoft Defender for Endpoint Team

The post Defending against cryptojacking with Microsoft Defender for Endpoint and Intel TDT appeared first on Microsoft Security Blog.

The MagBo marketplace, which sells access to more than 43,000 hacked servers, exemplifies the ever-expanding cybercrime threat. Compromised servers are being exploited to mine cryptocurrency and are being hit with ransomware attacks. Meanwhile, IoT vulnerabilities are on the rise, with more than half of IoT devices deemed susceptible to attack. In addition to these risks, companies often struggle with a lack of expertise and familiarity with security standards as well as complex regulations like the IoT Cybersecurity Improvement Act of 2020.

Given these factors, continuing to raise the security bar for critical infrastructure against attackers and also make it easy for organizations to hit that higher bar is a clear priority for both customers and Microsoft. As systems like the Xbox show, successfully protecting systems requires a holistic approach that builds security from the chip to the cloud across hardware, firmware, and the operating system. Using our learnings from the Secured-core PC initiative, Microsoft is collaborating with partners to expand Secured-core to Windows Server, Azure Stack HCI, and Azure-certified IoT devices, as well as bring the Secured-core values of advanced hardware-based protection and simpler security enablement to the server and IoT ecosystem.

Powerful protection with Secured-core Server and Edge Secured-core

Following Secured-core PC, we are introducing Secured-core Server which is built on three key pillars: simplified security, advanced protection, and preventative defense. Secured-core Servers come with the assurance that manufacturing partners have built hardware and firmware that satisfy the requirements of the operating system (OS) security features. Like Secured-core PC and Secured-core Server, Edge Secured-core advances built-in security for IoT devices running a full OS. Edge Secured-core also expands Secured-core coverage to Linux, in addition to Windows platforms.

Simplified security

New functionality in the Windows Admin Center makes it easy for customers to configure the OS security features of Secured-core for Windows Server and Azure Stack HCI systems. The new Windows Admin Center security functionality will allow enabling advanced security with a click of the button from a web browser anywhere in the world. With integrated Azure Stack HCI systems, manufacturing partners can also enable OS features, further simplifying the configuration experience for customers so that Microsoft’s best server security is available right out of the box. For Windows Server and validated Azure Stack HCI solutions, customers can look for Secured-core certified systems to simplify acquiring secure hardware platforms.

The Azure Certified Device program already helps customers find the right edge and IoT solutions for their needs. We are adding the Edge Secured-core public preview to the Azure Certified Device program. Edge Secured-core devices meet extra security requirements around device identity, secure boot, OS hardening, device updates, data protection, and vulnerability disclosures, which will be uniquely identifiable on the Azure Certified Device catalog.

Advanced protection

Secured-core Servers maximize hardware, firmware, and OS capabilities to help protect against current and future threats. These safeguards create a platform with added security for critical applications and data used on the server. Secured-core functionality spans the following areas:

• Hardware root-of-trust: Trusted Platform Module 2.0 (TPM 2.0) comes standard with Secured-core Servers, providing a protected store for sensitive keys and data, such as measurements of the components loaded during boot. Being able to verify that firmware that runs during boot is validly signed by the expected author and not tampered with helps improve supply chain security. This hardware root-of-trust elevates the protection provided by capabilities like BitLocker, which uses the TPM 2.0 and facilitates the creation of attestation-based workflows that can be incorporated into zero-trust security strategies.
• Firmware protection: In the last few years, there has been a significant uptick in firmware vulnerabilities, in large part due to the higher level of privileges that firmware runs combined with limited visibility into firmware by traditional anti-virus solutions. Using processor support for Dynamic Root of Trust of Measurement (DRTM) technology, Secured-core systems put firmware in a hardware-based sandbox helping to limit the impact of vulnerabilities in millions of lines of highly privileged firmware code.
• Virtualization-based security (VBS): Secured-core Servers support VBS and hypervisor-based code integrity (HVCI). The cryptocurrency mining attack mentioned earlier leveraged the EternalBlue exploit. VBS and HVCI help protect against this entire class of vulnerabilities by isolating privileged parts of the OS, like the kernel, from the rest of the system. This helps to ensure that servers remain devoted to running critical workloads and helps protect related applications and data from attack and exfiltration.

Edge Secured-core devices come with a built-in security agent, a zero-trust attestation model, and security by default, delivering on the following security features:

• Hardware-based device identity.
• Capable of enforcing system integrity.
• Stays up to date and is remotely manageable.
• Provides protection for data at rest and data in transit.
• Built-in security agent and hardening.

Preventative defense

Secured-core Servers and Edge Secured-core have security mitigations built into the hardware and OS platform to help thwart common attack vectors. Secured-core functionality helps proactively close the door on the many paths that attackers may try to exploit, and it allows IT and SecOps teams to optimize their time across other priorities.

Coming soon, with the support of the ecosystem

Secured-core Servers across Windows Server 2022 and Azure Stack HCI will help customers stay ahead of attackers and help protect their infrastructure across hardware, firmware, and operating systems. Supported hardware will be available in future product generations from Intel, AMD, and our vibrant OEM ecosystem.

“Continuing the rich tradition of innovation in hardware security, AMD is excited to partner with Microsoft to enable Secured-core Server with its future EPYC processors”, said Akash Malhotra, AMD director, security product management. “With attacks on firmware increasing, a tight integration between AMD hardware security features and the Windows Server operating system will benefit users across the ecosystem.”

“Today’s distributed world demands a new era of security. Intel and Microsoft are working together to provide innovative levels of security controls that provide customers with unified, integrated protection,” said Jeremy Rader, General Manager, Intel Cloud and Enterprise Group. “We’re combining the power of Secured core server with our 3rd Gen Intel Xeon Scalable processors (code-named Ice Lake) that creates a chain of trust across all layers of compute, from the hardware, to the firmware to the OS. Customers get a seamless root of trust that combines the most advanced security with management ease.”

You can learn more about Secured-core Servers and Windows Server 2022 security in the related blog.

To get started with Edge Secured-core certification, browse the following resources:

• Learn more about Edge Secured-core.
• Learn more about the launch of the Azure Certified Device program.
• Easily find Edge Secured-core certified devices on the Azure Certified Device Catalog using pre-built certification filters.
• Visit the Azure Certified Device submission portal (requires Microsoft Partner Network membership).

To learn more about Secured-core Servers and Edge Secured-core, be sure to join us during Microsoft Ignite from March 2-4, 2021.

The post Microsoft brings advanced hardware security to Server and Edge with Secured-core appeared first on Microsoft Security Blog.

BISMUTH, which shares similarities with OceanLotus or APT32, has been running increasingly complex cyberespionage attacks as early as 2012, using both custom and open-source tooling to target large multinational corporations, governments, financial services, educational institutions, and human and civil rights organizations. But in campaigns from July to August 2020, the group deployed Monero coin miners in attacks that targeted both the private sector and government institutions in France and Vietnam.

Because BISMUTH’s attacks involved techniques that ranged from typical to more advanced, devices with common threat activities like phishing and coin mining should be elevated and inspected for advanced threats. More importantly, organizations should prioritize reducing attack surface and hardening networks against the full range of attacks. In this blog, we’ll provide in-depth technical details about the BISMUTH attacks in July and August 2020 and mitigation recommendations for building organizational resilience.

While this actor’s operational goals remained the same—establish continuous monitoring and espionage, exfiltrating useful information as is it surfaced—their deployment of coin miners in their recent campaigns provided another way for the attackers to monetize compromised networks. Considering some of the group’s traditional targets are human and civil rights organizations, BISMUTH attacks demonstrate how attackers give little regard to services they impact.

The use of coin miners by BISMUTH was unexpected, but it was consistent with the group’s longtime methods of blending in. This pattern of blending in is particularly evident in these recent attacks, starting from the initial access stage: spear-phishing emails that were specially crafted for one specific recipient per target organization and showed signs of prior reconnaissance. In some instances, the group even corresponded with the targets, building even more believability to convince targets to open the malicious attachment and start the infection chain.

The other way that BISMUTH attempted to blend in and hide in plain sight was the heavy use of DLL side-loading, a technique in which a legitimate DLL is replaced with a malicious one so that the latter is loaded when the associated application is run. In their recent attacks, BISMUTH utilized copies of various legitimate software to load malicious DLL files and perform tasks in the context of these legitimate applications. To perform DLL sideloading, BISMUTH introduced outdated versions of various applications, including Microsoft Defender Antivirus. They also leveraged the Sysinternals DebugView tool, the McAfee on-demand scanner, and Microsoft Word 2007.

Blending in was important for BISMUTH because the group spent long periods of time performing discovery on compromised networks until they could access and move laterally to high-value targets like servers, where they installed various tools to further propagate or perform more actions. At this point in the attack, the group relied heavily on evasive PowerShell scripts, making their activities even more covert.

The coin miners also allowed BISMUTH to hide its more nefarious activities behind threats that may be perceived to be less alarming because they’re “commodity” malware. If we learned anything from “commodity” banking trojans that bring in human-operated ransomware, we know that common malware infections can be indicators of more sophisticated cyberattacks and should be treated with urgency and investigated and resolved comprehensively.

Initial access

BISMUTH attempted to gain initial access by sending specially crafted malicious emails from a Gmail account that appears to have been made specifically for this campaign. It’s likely the group conducted reconnaissance using publicly available sources and chose individual targets based on their job function. Each email was sent to only one recipient at each target organization and used tailored subject lines and lure themes, for example:

• Dự thảo hợp đồng (translates from Vietnamese to “Draft Contract”)
• Ứng tuyển – Trưởng ban nghiên cứu thị trường (translates from Vietnamese to “Application form – Head of Market Research”)

Of note, the group sent several replies to one of these emails, which indicated that they corresponded with some targets before convincing them to open the malicious document attachment and inadvertently launch the payload. When opened, the malicious .doc file dropped several files in the hidden ProgramData folder: (1) MpSvc.dll, a malicious DLL with the same name as a legitimate Microsoft Defender Antivirus DLL, and (2) a copy of MsMpEng.exe the legitimate Microsoft Defender Antivirus executable.

The malicious document then added a scheduled task that launched the MsMpEng.exe copy and sideloaded the malicious MpSvc.dll. Because the latest versions of Microsoft Defender Antivirus are no longer susceptible to DLL sideloading, BISMUTH used an older copy to load the malicious DLL and establish a persistent command-and-control (C2) channel to the compromised device and consequently the network.

Using the newly established channel, the group dropped several files for the next stages of the attack, including a .7z archive, a copy of Word 2007, and another DLL, wwlib.dll. While it used the same name as a legitimate Microsoft Word DLL, wwlib.dll was a copy of KerrDown, a family of custom malware exclusive to BISMUTH. This file was subsequently sideloaded by the dropped copy of Word 2007—a technique used by BISMUTH extensively to load malicious code from a DLL file in the context of a legitimate process like winword.exe.

BISMUTH established another persistence method by dropping another copy of Word 2007 in a subfolder in ProgramData. The group then created a scheduled task that launched that copy in the same malicious manner every 60 minutes – further increasing their chances of going undetected and maintaining their presence.

Discovery

Once established as a scheduled task, the co-opted Word 2007 process dropped and loaded a scanning tool popular among attackers, NbtScan.exe. BISMUTH then immediately used the scanning tool to scan an IP address range within the organization. Following this network scan, the Word 2007 process launched a malicious script using a living-off-the-land-binary, rundll32.exe, resulting in a scan on a myriad of common ports, including 21, 22, 389, 139, and 1433. BISMUTH listed devices with open ports in a .csv file.

While network scanning was underway, the group performed other reconnaissance activities. They gathered information about domain and local administrators, checked whether users had local administrative privileges, and collected device information—aggregating results in a .csv for exfiltration. In addition, the group once again used MsMpEng.exe with the malicious sideloaded DLL to connect to another device that appears to have been designated by BISMUTH at some point during the attack as an internal C2 foothold and exfiltration staging device.

Continued lateral movement, discovery, and intel gathering

After a month of continual discovery on compromised devices, the group moved laterally to a server and copied over a malicious DLL that masqueraded as the system file mpr.dll and a copy of the Sysinternals DebugView tool. They dropped the tool onto different devices using SMB remote file copy, using file names related to popular Japanese video game characters and a seemingly random word. The actors then registered and launched malicious services multiple times, launching DebugView tool to connect to multiple Yahoo websites and confirm Internet connectivity, followed by a connection to their C2 infrastructure.

At this point, BISMUTH switched to running their attacks using PowerShell, quickly launching multiple script cmdlets. First, they dumped credentials from the Security Account Manager (SAM) database using the Empire PowerDump command and then quickly deleted PowerShell event logs to erase records generated by Script Block Logging. They then continued their discovery efforts using a PowerShell script that gathered user and group information and sent the gathered data to .csv files.

The script collected the following information about each user:

description, distinguishedname, lastlogontimestamp, logoncount, mail, name, primarygroupid, pwdlastset, samaccountname, userprincipalname, whenchanged, whencreated

And the following information about each domain group:

adspath, description, distinguishedname, groupType, instancetype, mail, member, memberof, name, objectsid, samaccountname,whenchanged, whencreated

Next, the group exported directory forest and domain organizational unit (OU) information. They then started connecting to dozens of devices using WMI. Following that, they collected credentials by dumping security logs under Event ID 680, possibly targeting logs related to NTLM fallbacks. Lastly, the group used the system tool Nltest.exe to gather domain trust info and pinged multiple servers they have identified by name during reconnaissance. Some of these servers appear to be database and file servers that could have contained high-value information for espionage objectives typically pursued by BISMUTH.

BISMUTH then installed a Cobalt Strike beacon. The group dropped a .rar file and extracted its contents—McOds.exe, which is a copy of the McAfee on-demand scanner, and a malicious DLL—into the SysWOW64 folder. The group then created a scheduled task that launched the copy of the McAfee on-demand scanner with SYSTEM privileges and sideloaded the malicious DLL. This persistence mechanism established a connection to their Cobalt Strike server infrastructure. To clean up evidence, they deleted the dropped McAfee binary.

In terms of targets for this campaign, there were some commonalities among targets located in Vietnam that Microsoft has assessed to be tied to their previous designation as state-owned enterprises (SOEs). The observed BISMUTH activity in Vietnam targeted organizations that included former SOEs previously operated by the government of Vietnam, entities that have acquired a significant portion of a former SOE, and entities that conduct transactions with a Vietnamese government agency. Although the group’s specific objectives for these recent attacks cannot be defined with high confidence, BISMUTH’s past activities have included operations in support of broader espionage goals.

Coin miner deployment and credential theft

As mentioned, BISMUTH deployed coin miners during these attacks. To do this, they first dropped a .dat file and loaded the file using rundll32.exe, which in turn downloaded a copy of the 7-zip tool named 7za.exe and a ZIP file. They then used 7-Zip to extract a Monero coin miner from the ZIP file and registered the miner as a service named after a common Virtual Machine process. Each coin miner they deployed had a unique wallet address that earned over a thousand U.S. dollars combined during the attacks.

After deploying coin miners as their distraction technique, BISMUTH then focused much of its efforts on credential theft. They registered multiple malicious services that used %comspec%—a relative reference to cmd.exe commonly used by attackers—to run the renamed DebugView tool while loading a malicious DLL. The group used DebugView and the malicious DLL in a fairly unexpected fashion to launch Base64-encoded Mimikatz commands using one of several Windows processes: makecab.exe, systray.exe, w32tm.exe, bootcfg.exe, diskperf.exe, esentutl.exe, and typeperf.exe.

They ran the following Mimikatz commands that require SYSTEM or Debug privileges:

• sekurlsa::logonpasswords full–lists all account and user password hashes, typically user and computer credentials for recently logged on users
• lsadump::lsa /inject—injects LSASS to retrieve credentials and request the LSA Server to grab credentials from the Security Account Manager (SAM) database and Active Directory (AD)

After running these commands, the co-opted DebugView tool connected to multiple attacker-controlled domains, likely to exfiltrate stolen credentials.

As the affected organizations worked to evict BISMUTH from their networks, Microsoft security researchers saw continued activity involving lateral movement to other devices, credential dumping, and planting of multiple persistence methods. This highlights the complexity of responding to a full-blown intrusion and the significance of taking quick action to resolve alerts that flag initial stages of an attack.

Building organizational resilience against attacks that blend in

BISMUTH attacks put strong emphasis on hiding in plain sight by blending in with normal network activity or common threats that attackers anticipate will get low-priority attention. The combination of social engineering and use of legitimate applications to sideload malicious DLLs entail multiple layers of protection focused on stopping threats at the earliest possible stage and mitigating the progression of attacks if they manage to slip through. Here are mitigation recommendations that organizations can implement to limit exposure:

Limit the attack surface that attackers can leverage for initial access:

• Educate end users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing email, and reporting of reconnaissance attempts and other suspicious activity.
• Configure Office 365 email filtering settings to ensure blocking of phishing & spoofed emails, spam, and emails with malware. Set Office 365 to recheck links on click and delete sent mail to benefit from newly acquired threat intelligence.
• Turn on attack surface reduction rules, including rules that can block advanced macro activity, executable content, process creation, and process injection initiated by Office applications.
• Disallow macros or allow only macros from trusted locations. See the latest security baselines for Office and Office 365.
• Check perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Such restrictions help inhibit malware downloads and command-and-control activity.

Build credential hygiene to reduce risk during discovery stage:

• Enforce strong, randomized local administrator passwords. Use tools like LAPS.
• Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts.
• Require multi-factor authentication through Windows Hello.

Stop attack sprawl and contain attacker movement:

• 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.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Monitor for clearing of event logs. Windows generates security event ID 1102 when this occurs.
• Determine where highly privileged accounts are logging on and exposing credentials. Monitor and investigate logon events (event ID 4624) for logon type attributes. Highly privileged accounts should not be present on workstations.
• Utilize the Microsoft Defender Firewall, intrusion prevention devices, and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.

To better defend organizations against attacks that do everything to blend in once they gain access to a network, organizations can build defenses for preventing and blocking attacks at the initial access stage. Microsoft Defender for Office 365 provides defense capabilities that protect organizations from threats like credential phishing, business email compromise, and cyberattacks that begin with spear-phishing emails. Safe attachments and Safe links provide real-time protection using a combination of detonation, automated analysis, and machine learning, which are especially useful for highly targeted, specially crafted emails. Campaign views show the complete picture of email campaigns, including timelines, sending patterns, impact to the organization, and details like IP addresses, senders, URLs.

The broader Microsoft 365 Defender presents cross-domain threat intelligence and actionable information in consolidated incidents view, empowering security operations teams to comprehensively respond to attacks. For critical threats like BISMUTH campaigns, Microsoft researchers publish threat analytics reports that contain technical details, detection info, and mitigation status. Investigation tools like advanced hunting allow security teams to perform additional inspection of the environment for related or similar threats. Threat and vulnerability management data show mitigation recommendations, including enabling relevant attack surface reduction rules, that organizations can take to reduce risks.

These industry-leading capabilities in Microsoft 365 Defender are backed by Microsoft’s network of researchers and security experts who monitor the threat landscape and track threat actors like BISMUTH. Through Microsoft 365 Defender, we transform threat intelligence into protections and rich investigation tools that organizations can use to build organizational resilience. Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Microsoft 365 Defender Threat Intelligence Team

with Microsoft Threat Intelligence Center (MSTIC)

MITRE ATT&CK techniques observed

Initial access

• 001 Phishing: Spearphishing Attachment| Emails containing malicious Word documents with specific lure themes and subject lines for each target

Execution

• 002 System Services: Service Execution| Use of Service Control Manager (services.exe) to launch Sysinternals dbgview.exe
• 001 Command and Scripting Interpreter: PowerShell| Use of PowerShell to run cmdlets used for data exfiltration and lateral movement

Persistence

• T1053 Scheduled Task/Job| Scheduled task to execute payload every 60 minutes

Privilege escalation

• 002/003 Valid Accounts: Local and Domains Accounts| Credentials stolen for privilege escalation using Mimikatz

Defense evasion

• T1070 Indicator Removal on Host| Stopping of malicious tasks after data exfiltration or payload retrieval, deleting dropped malware from the disk, and clearing of PowerShell event logs
• 002 Hijack Execution Flow: DLL Sideloading| Using winword.exe, dbgview.exe, msmpeng.exe to load malicious DLLs

Credential access

• T1003Credential Dumping | Use of Mimikatz to dump credentials

Discovery

• T1033 System Owner/User Discovery, T1049 System Network Connections Discovery| Use of whoami, netstat, ipconfig
• T1016System Network Configuration Discovery | Use of modified nbtscan
• 002 Permission Groups Discovery: Domain Groups| Discovering domain groups with net users /domain

Collection

• 001 Data Staging: Local Data Staging| Storing harvested credentials and user/group information in a local CSV file

Data exfiltration

• T1041 Exfiltration Over C2 Channel| Data exfiltration to a C2 server established in the compromised network

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 Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them appeared first on Microsoft Security Blog.

In cybersecurity, whether we are talking about cryptocurrency mining, supply chain attacks, attacks against IoT, or COVID-19-related phishing lures, we know that gaining the advantage over our adversaries requires greater diversity of data to improve our threat intelligence. If we are to future proof bias in tech however, our teams must also be as diverse, as the problems we are trying to solve.

Unfortunately, our cybersecurity teams don’t reflect this reality. A 2019 report by (ISC)² found that less than 25 percent of cybersecurity professionals are women. People of color and women aren’t paid as well as white men and are underrepresented in management. Time and again, studies have found that gender-diverse teams make better business decisions 73 percent of the time. What’s more, teams that are also diverse in age and geographic location make better decisions 87 percent of the time. With a talent shortfall estimated between 1.5 million and 3.5 million, we must recruit, train, and retain cyber talent from a wide variety of backgrounds in order to maintain our advantage.

Diversity fuels innovation

You can see the evidence that diversity drives innovation when you look at artificial intelligence (AI) and machine learning. The AI capabilities built into Microsoft Security solutions are trained on 8 trillion daily threat signals from a wide variety of products, services, and feeds from around the globe (see Figure 1). Because the data is diverse, AI and machine learning algorithms can detect threats in milliseconds.

Figure 1: Trillions of signals from around the globe allow Microsoft Security solutions to rapidly detect and respond to threats.

Just last year, the World Economic Forum compiled several studies that provide further evidence that diversity sparks innovation. Cities with large immigration populations tend to have higher economic performance. Businesses with more diverse management teams have higher revenues. A C-suite with more women is likely to be more profitable. When people with different backgrounds and experiences collaborate, unique ideas can flourish. What’s more, if you want to build technology solutions that are inclusive of everyone, diverse teams help avoid bias and develop features that meet the needs of more people.

So how do you increase the diversity of your team? Expand the pipeline. Invest in your team. And create an inclusive culture.

Expand the pipeline

To recruit the very best people from all backgrounds, start by prioritizing unique perspectives. Machine learning, artificial intelligence, and quantum computing hold promise for addressing cyber threats; however, technology is not enough. Some problems can only be solved by people. You need teams that can anticipate what’s next and respond quickly in high-stress situations.

If everybody on the team has similar skills and backgrounds, you risk group think and a lack of creativity. It’s why diverse teams make better decisions than individuals 87 percent of the time (all-male teams only make better decisions than individuals 58 percent of the time).

To attract the diverse talent you need, expand your criteria. Look beyond the typical degrees, experience level, and certifications that you typically recruit for. Leverage training programs that help people acquire the technical skills you need. For example, BlackHoodie is a reverse engineering program for women. Consider people without college degrees, veterans, and people looking to switch careers. Work with colleges and other groups that represent disadvantaged communities, such as historically black colleges and universities.

Invest in your team

Cybersecurity teams around the globe are understaffed, while the amount of work continues to grow. Security operation center (SOC) analysts suffer from alert fatigue because they must monitor thousands of alerts—many of them false positives. Stress levels are high, and individuals work long hours. These work conditions can lead to burnout, which makes people less effective.

Reduce routine tasks with AI, machine learning, and automation. AI, machine learning, and automation can empower your team by reducing the noise, so people can focus on challenging threats that are, frankly, more fun. Azure Sentinel is a cloud-native SIEM that uses state of the art, scalable machine learning algorithms to correlate millions of low fidelity anomalies to present a few high-fidelity security incidents to analysts. Our research has shown that customers who use Azure Sentinel achieved a 90 percent reduction in alert fatigue.

Figure 2: Azure Sentinel makes it easy to collect security data across your entire hybrid organization from devices, to users, to apps, to servers on any cloud.

Provide growth opportunities and training. The threat landscape changes rapidly requiring security professionals to continuously upgrade their skills. Human beings also need new challenges to stay engaged. Provide opportunities for everyone to use creative problem-solving skills. Encourage individuals to learn from each other, such as through an apprenticeship program. Offer regular training for people at all levels of your organization. The Microsoft SOC focuses its training programs on three key areas:

• Technical tools/capabilities.
• Our organization (mission and assets being protected).
• Attackers (motivations, tools, techniques, habits, etc.).

Take care of employees’ mental health. Stress is driving too many people to leave cybersecurity. In fact, stress has motivated 66 percent of IT professionals to look for a new job. Fifty-one percent would be willing to take a pay cut for less stress. Late nights and high-pressure incident response take a toll on employees. In these circumstances, it’s important to respect time off. People should be able to enjoy their days off without worrying about work. A collaborative culture that is forgiving of mistakes can also reduce the pressure. Ask your team how they are doing and really listen when they tell you. Their answers may trigger a great idea for alleviating stress.

Create an inclusive culture

People go where they are invited, but they stay where they are welcome. As you bring new people into your security organization, foster an environment where everybody feels accepted. All ideas should be listened to and considered. People who express ideas that challenge old methods can lead to breakthroughs and creativity. Here are a few ideas for making sure everyone feels included:

• Solicit input from everybody, so you don’t just hear from those that are comfortable speaking up.
• Provide mentorship and sponsorship programs for women and other underrepresented groups to help prepare them for advancement
• Expand your definition of diversity to include neuro atypical, nonbinary, LGBTQ, religious affiliation, and education level in addition to race and gender.
• Make a conscious effort to evaluate performance, not communication or presentation style.
• Hold leadership and vendors accountable for diversity metrics.

As we look past the COVID-19 pandemic, we can expect that cybersecurity challenges will continue to evolve. AI, machine learning, and quantum computing will shape our response, but technology will not be enough. We need creative people to build our products, design our security programs, and respond to threats. We need teams that are diverse as the problems we face.

To learn more about Microsoft Security solutions visit our website.  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 Microsoft Security: How to cultivate a diverse cybersecurity team appeared first on Microsoft Security Blog.