Archive

Archive for December, 2020

Microsoft Internal Solorigate Investigation Update

December 31st, 2020 No comments

As we said in our recent blog, we believe the Solorigate incident is an opportunity to work together in important ways, to share information, strengthen defenses and respond to attacks. Like other SolarWinds customers, we have been actively looking for indicators of the Solorigate actor and want to share an update from our ongoing internal …

Microsoft Internal Solorigate Investigation Update Read More »

Categories: Investigation, SolarWinds, Solorigate Tags:

Using Microsoft 365 Defender to protect against Solorigate

December 28th, 2020 No comments

Microsoft security researchers continue to investigate and respond to the sophisticated cyberattack known as Solorigate (also referred to as Sunburst by FireEye) involving a supply chain compromise and the subsequent compromise of cloud assets. While the related investigations and impact assessments are ongoing, Microsoft is providing visibility into the attack chains and related threat intelligence to the defender community as early as possible so organizations can identify and take action to stop this attack, understand the potential scope of its impact, and begin the recovery process from this active threat. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.

This blog is a comprehensive guide for security operations and incident response teams using Microsoft 365 Defender to identify, investigate, and respond to the Solorigate attack if it’s found in your environment. The description of the attack in this blog is based on current analysis and investigations by researchers across Microsoft, our partners, and the intelligence community who are actively collaborating to respond to the attack. This is an active threat that continues to evolve, and the findings included here represent what we know at the time of publishing. We continue to publish and update intelligence, indicators, tactics, techniques, and procedures (TTPs), and related details as we discover them. The report from the Microsoft Security Response Center (MSRC) includes the latest analysis of this threat, known indicators of compromise (IOCs), and initial recommended defenses, and will be updated as new data becomes available.

This blog covers:

Tracking the cross-domain Solorigate attack from endpoint to the cloud

The Solorigate attack is an example of a modern cross-domain compromise. Since these kinds of attacks span multiple domains, having visibility into the entire scope of the attack is key to stopping and preventing its spread.

This attack features a sophisticated technique involving a software supply chain compromise that allowed attackers to introduce malicious code into signed binaries on the SolarWinds Orion Platform, a popular IT management software. The compromised application grants attackers “free” and easy deployment across a wide range of organizations who use and regularly update the application, with little risk of detection because the signed application and binaries are common and are considered trusted. With this initial widespread foothold, the attackers can then pick and choose the specific organizations they want to continue operating within (while others remain an option at any point as long as the backdoor is installed and undetected). Based on our investigations, the next stages of the attack involve on-premises activity with the goal of off-premises access to cloud resources through the following steps:

  1. Using the compromised SolarWinds DLL to activate a backdoor that enables attackers to remotely control and operate on a device
  2. Using the backdoor access to steal credentials, escalate privileges, and move laterally to gain the ability to create valid SAML tokens using any of two methods:
    1. Stealing the SAML signing certificate (Path 1)
    2. Adding to or modifying existing federation trust (Path 2)
  3. Using attacker-created SAML tokens to access cloud resources and perform actions leading to the exfiltration of emails and persistence in the cloud

Diagram of the high-level Solorigate attack chain

Figure 1. High-level end-to-end Solorigate attack chain

This attack is an advanced and stealthy campaign with the ability to blend in, which could allow attackers to stay under the radar for long periods of time before being detected. The deeply integrated cross-domain security capabilities in Microsoft 365 Defender can empower organizations and their security operations (SOC) teams to uncover this attack, scope out the end-to-end breach from endpoint to the cloud, and take action to block and remediate it. This blog will offer step-by-step guidance to do this by outlining:

  • How indicators of attack show up across endpoints, identity, and the cloud
  • How Microsoft 365 Defender automatically combines alerts across these different domains into a comprehensive end-to-end story
  • How to leverage the powerful toolset available for deep investigation, hunting, and response to enable SOCs to battle the attackers and evict these attackers from both on-premises and cloud environments

Threat analytics: Understanding and responding to active attacks

As soon as this attack was discovered, Microsoft researchers published two threat analytics reports to help organizations determine if they are affected, assess the impact of the attack, and identify actions to contain it.

The reports are published in Microsoft 365 security center, available to all Microsoft Defender for Endpoint customers and Microsoft 365 Defender early adopters. In addition to detailed descriptions of the attack, TTPs, and indicators of compromise (IoCs), the reports provide real-time data aggregated from signals across Microsoft 365 Defender, indicating the all-up impact of the threat to the organization, as well as details about relevant incidents and alerts to initiate investigation on. These reports continue to be updated as additional information becomes available.

Given the significance of this threat, we are making similar relevant Microsoft threat intelligence data, including the updated list of IOCs, available to everyone publicly.  A comprehensive list of guidance and insights is available at https://aka.ms/solorigate.

Screenshot of threat analytics report on Soloriage in Microsoft Defender Security Center

Figure 2. Threat analytics report on Solorigate attack

We recommend Microsoft 365 Defender customers to start their investigations here. After gaining deep understanding of the threat and getting the latest research findings, you can take the following recommended steps:

Find devices with the compromised SolarWinds Orion application

The threat analytics report uses insights from threat and vulnerability management to identify devices that have the compromised SolarWinds Orion Platform binaries or are exposed to the attack due to misconfiguration.

From the Vulnerability patching status chart in threat analytics, you can view the mitigation details to see a list of devices with the vulnerability ID TVM-2020-0002, which was added specifically to help with Solorigate investigations:

Threat and vulnerability management insights on impact of Solorigate

Figure 3. Threat and vulnerability management data shows data on exposed devices

Threat and vulnerability management provides more info about the vulnerability ID TVM-2020-0002, as well as all relevant applications, via the Software inventory view. There are also multiple security recommendations to address this specific threat, including instructions to update the software versions installed on exposed devices.

Screenshot of security recommendations for Solorigate in Microsoft Defender Security Center

Figure 4. Security recommendations from threat and vulnerability management

Investigate related alerts and incidents

From the threat analytics report, you can quickly locate devices with alerts related to the attack. The Devices with alerts chart identifies devices with malicious components or activities known to be directly related to Solorigate. Click through to get the list of alerts and investigate.

Some Solorigate activities may not be directly tied to this specific threat but will trigger alerts due to generally suspicious or malicious behaviors. All alerts in Microsoft 365 Defender provided by different Microsoft 365 products are correlated into incidents. Incidents help you see the relationship between detected activities, better understand the end-to-end picture of the attack, and investigate, contain, and remediate the threat in a consolidated manner.

Review incidents in the Incidents queue and look for those with alerts relevant to this attacker’s TTPs, as described in the threat analytics report (also listed at the end of this blog).

Screenshot of Microsoft Defender Security Center incidents view for Solorigate

Figure 5. Consolidated Incident view for Solorigate

Some alerts are specially tagged with Microsoft Threat Experts to indicate malicious activities that Microsoft researchers found in customer environments during hunting. As part of the Microsoft Threat Experts service, researchers investigated this attack as it unfolded, hunting for associated attacker behaviors, and sent targeted attack notifications. If you see an alert tagged with Microsoft Threat Experts, we strongly recommend that you give it immediate attention.

Screenshot of Microsoft Defender Security Center showing Microsoft Threat Experts detections

Figure 6. Microsoft Threat Experts targeted attack notification

Additionally, Microsoft Threat Experts customers with Experts on demand subscriptions can reach out directly to our on-demand hunters for additional help in understanding the Solorigate threat and the scope of its impact in their environments.

Hunt for related attacker activity

The threat analytics report also provides advanced hunting queries that can help analysts locate additional related or similar activities across endpoint, identity, and cloud. Advanced hunting uses a rich set of data sources, but in response to Solorigate, Microsoft has enabled streaming of Azure Active Directory (Azure AD) audit logs into advanced hunting, available for all customers in public preview. These logs provide traceability for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD, such as adding or removing users, apps, groups, roles, and policies.  Customers who do not have Microsoft Defender for Endpoint or are not early adopters for Microsoft 365 Defender can see our recommended advanced hunting queries.

Currently, this data is available to customers who have Microsoft Cloud App Security with the Office365 connector. Our intent is to expand availability to more Microsoft 365 Defender customers. The new log data is available in the CloudAppEvents table:

CloudAppEvents
| where Application == “Office 365”

The log data contains activity logs useful for investigating and finding Azure AD-related activities. This data further enriches the CloudAppEvents table, which also has Exchange Online and Microsoft Teams activities.

As part of making this new data available, we also published a handful of relevant advanced hunting queries, identified by the suffix [Solorigate], to the GitHub repo.

Here’s an example query that helps you see when credentials are added to an Azure AD application after ‘Admin Consent’ permissions were granted:

CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Consent to application.”
| where RawEventData.ModifiedProperties[0].Name == “ConsentContext.IsAdminConsent” and RawEventData.ModifiedProperties[0].NewValue == “True”
| extend spnID = tostring(RawEventData.Target[3].ID)
| parse RawEventData.ModifiedProperties[4].NewValue with * “=> [[” dummpy “Scope: ” After “]]” *
| extend PermissionsGranted = split(After, “]”,0)
| project ConsentTime = Timestamp , AccountDisplayName , spnID , PermissionsGranted
| join (
CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Add service principal credentials.” or ActionType == “Update application – Certificates and secrets management “
| extend spnID = tostring(RawEventData.Target[3].ID)
| project AddSecretTime = Timestamp, AccountDisplayName , spnID
) on spnID
| where ConsentTime < AddSecretTime and AccountDisplayName <> AccountDisplayName1

Microsoft 356 Defender advanced hunting can also assist in many of the recommended incident investigation tasks outlined in the blog, Advice for incident responders on recovery from systemic identity compromises.

In the remaining sections, we will discuss select examples of alerts raised by Microsoft 365 solutions that monitor and detect Solorigate activities across the attack chain on endpoint, identity, and the cloud. These are alerts you may encounter when investigating incidents in Microsoft 365 security center if your organization is affected by this threat. We will also indicate activities which are now blocked by Microsoft 365 Defender. Lastly, each section contains examples of hunting queries you will find useful for hunting for various attacker activities in your environment.

Detecting and blocking malware and malicious behavior on endpoints

Diagram showing attack chain on endpoints involving the Solorigate malware

Figure 7. Solorigate attack chain: Initial access and command-and-control

Discovering and blocking backdoor activity

When the compromised SolarWinds binary SolarWinds.Orion.Core.BusinessLayer.dll gets loaded on a device through normal update channels, the backdoor goes through an extensive list of checks to ensure it’s running in an actual enterprise network and not on an analyst’s machine. It then contacts a command-and-control (C2) server using a subdomain that is generated partly with information gathered from the affected device, which means a unique subdomain is generated for each affected domain. The backdoor allows the attackers to remotely run commands on the device and move to the next stages of the attack. For more information, read our in-depth analysis of the Solorigate malware.

Microsoft Defender for Endpoint delivers comprehensive protection against this threat (see full list of detection and protection alerts at the end of this blog). Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines the malware, even if the process is running.

Screenshot of Microsoft Defender Security Center showing alert for blocking of Solorigate malware

Figure 8. Microsoft Defender for Endpoint blocks malicious binaries

If the malicious code is successfully deployed, the backdoor lies dormant for up to two weeks. It then attempts to contact numerous C2 domains, with the primary domain being *.avsvmcloud[.]com. The backdoor uses a domain generation algorithm to evade detection. Microsoft 365 Defender detects and blocks this behavior.

Screenshot of Microsoft Defender Security Center showing alert for malicious network connection

Figure 9. Microsoft Defender for Endpoint prevented malicious C2 callback

Discovering potentially tampered devices

To evade security software and analyst tools, the Solorigate malware enumerates the target system looking for certain running processes, loaded drivers, and registry keys, with the goal of disabling them.

The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable. Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including “Attempt to stop Microsoft Defender for Endpoint sensor”, “Tampering with Microsoft Defender for Endpoint sensor settings”, or “Possible sensor tampering in memory”.

Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities. However, the multitude of signals reported into Microsoft 365 Defender provides a unique opportunity to hunt for systems where the tampering technique used might have been successful. The following advanced hunting query can be used to locate devices that should be reporting but aren’t:

// Times to be modified as appropriate
let timeAgo=1d;
let silenceTime=8h;
// Get all silent devices and IPs from network events
let allNetwork=materialize(DeviceNetworkEvents
| where Timestamp > ago(timeAgo)
and isnotempty(LocalIP)
and isnotempty(RemoteIP)
and ActionType in (“ConnectionSuccess”, “InboundConnectionAccepted”)
and LocalIP !in (“127.0.0.1”, “::1”)
| project DeviceId, Timestamp, LocalIP, RemoteIP, ReportId);
let nonSilentDevices=allNetwork
| where Timestamp > ago(silenceTime)
| union (DeviceProcessEvents | where Timestamp > ago(silenceTime))
| summarize by DeviceId;
let nonSilentIPs=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by LocalIP;
let silentDevices=allNetwork
| where DeviceId !in (nonSilentDevices)
and LocalIP !in (nonSilentIPs)
| project DeviceId, LocalIP, Timestamp, ReportId;
// Get all remote IPs that were recently active
let addressesDuringSilence=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by RemoteIP;
// Potentially disconnected devices were connected but are silent
silentDevices
| where LocalIP in (addressesDuringSilence)
| summarize ReportId=arg_max(Timestamp, ReportId), Timestamp=max(Timestamp), LocalIP=arg_max(Timestamp, LocalIP) by DeviceId
| project DeviceId, ReportId=ReportId1, Timestamp, LocalIP=LocalIP1

Microsoft is continuously developing additional measures to both block and alert on these types of tampering activities.

Detecting hands-on-keyboard activity within an on-premises environment

Diagram showing Solorigate hands-on-keyboard attack on premises

Figure 11. Solorigate attack chain: Hands-on-keyboard attack on premises

After establishing a backdoor connection on an affected device, the attacker’s next goal is to achieve off-premises access to the organization’s cloud services. To do this, they must find a way to gain permissions to those services. One technique we have seen the attackers use is to go after the organization’s Active Directory Federation Services (AD FS) server to obtain the proverbial “keys” to the identity kingdom. AD FS enables federated identity and access management by securely sharing digital identity and entitlement rights across security and enterprise boundaries; effectively, it is the “LSASS for the cloud.” Among other things, AD FS stores the Security Assertion Markup Language (SAML) token signing certificate, which is used to create authorization tokens for users or services in the organization so they can access cloud applications and resources after authentication.

To attack the AD FS infrastructure, the attackers must first obtain appropriate domain permissions through on-premises intelligence gathering, lateral movement, and credential theft. Building from the backdoor described above, the attackers leverage fileless techniques for privilege escalation, persistence, and lateral movement, including evading analysis by using system binaries and exploration tools that masquerade as other benign binaries. The attackers also carefully chose organization-specific command-and-control (C2) domains and use custom organization-specific tool naming and locations.

Microsoft Defender for Endpoint detects a wide array of these attack techniques, allowing SOC teams to track the attacker’s actions in the environment and take actions to contain the attack. The following section covers detections for the techniques used by the attackers to compromise the AD FS infrastructure.

Identifying attacker reconnaissance

Attackers collect data from Active Directory using a renamed version of the utility ADFind, running queries against Domain Controllers as part of the reconnaissance stage of the attack. Microsoft Defender for Endpoint detects this behavior and allows the SOC analyst to track compromised devices at this stage to gain visibility into the information the attacker is looking for.

Screenshot of Microsoft Defender Security Center alert for detection of exploration tools

Figure 12. Microsoft Defender for Endpoint detects usage of masquerading exploration tools

Screenshot of Microsoft Defender Security Center alert for detection of LDAP queries

Figure 13. Microsoft Defender for Endpoint detects usage LDAP query for reconnaissance.

Stopping lateral movement and credential theft

To gain access to a highly privileged account needed for later steps in the kill chain, the attackers move laterally between devices and dump credentials until an account with the needed privileges is compromised, all while remaining as stealthy as possible.

A variety of credential theft methods, such as dumping LSASS memory, are detected and blocked by Microsoft Defender for Endpoint. The example below shows the detection of lateral movement using Windows Management Instrumentation (WMI) to run the attacker’s payload using the Rundll32.exe process.

Screenshot of Microsoft Defender Security Center alert for detection of remote WMI execution

Figure 14. Microsoft Defender for Endpoint alert for suspicious remote WMI execution highlighting the attacker’s device and payload

Microsoft Defender for Identity also detects and raises alerts on a variety of credential theft techniques. In addition to watching for alerts, security analysts can hunt across identity data in Microsoft 365 Defender for signs of identity compromise. Here are a couple of example Microsoft Defender for Identity queries looking for such patterns:

Enumeration of high-value DC assets followed by logon attempts to validate stolen credentials in time proximity

let MaxTime = 1d;
let MinNumberLogon = 5;
//devices attempting enumeration of high-value DC
IdentityQueryEvents
| where Timestamp > ago(30d)
| where Application == “Active Directory”
| where QueryTarget in (“Read-only Domain Controllers”)
//high-value RODC assets
| project Timestamp, Protocol, Query, DeviceName, AccountUpn
| join kind = innerunique (
//devices trying to logon {MaxTime} after enumeration
IdentityLogonEvents
| where Timestamp > ago(30d)
| where ActionType == “LogonSuccess”
| project LogonTime = Timestamp, DeviceName, DestinationDeviceName) on DeviceName
| where LogonTime between (Timestamp .. (Timestamp + MaxTime))
| summarize n=dcount(DestinationDeviceName), TargetedDC = makeset(DestinationDeviceName) by Timestamp, Protocol, DeviceName
| where n >= MinNumberLogon

High-volume of LDAP queries in short time filtering for non-DC devices

let Threshold = 12;
let BinTime = 1m;
//approximate list of DC
let listDC=IdentityDirectoryEvents
| where Application == “Active Directory”
| where ActionType == “Directory Services replication”
| summarize by DestinationDeviceName;
IdentityQueryEvents
| where Timestamp > ago(30d)
//filter out LDAP traffic across DC
| where DeviceName !in (listDC)
| where ActionType == “LDAP query”
| parse Query with * “Search Scope: ” SearchScope “, Base Object:” BaseObject “, Search Filter: ” SearchFilter
| summarize NumberOfDistinctLdapQueries = dcount(SearchFilter) by DeviceName, bin(Timestamp, BinTime)
| where NumberOfDistinctLdapQueries > Threshold

At this point, SOC teams can take containment measures within the Microsoft 365 security center, for example, using indicators to isolate the devices involved and block the remotely executed payload across the environment, as well as mark suspect users as compromised.

Detecting and remediating persistence

Microsoft Defender for Endpoint also detects the advanced defense evasion and masquerading techniques used by the attackers to make their actions as close to normal as possible, such as binding a WMI event filter with a logical consumer to remain persistent. Follow the recommended actions in the alert to remove persistence and prevent the attacker’s payload from loading after reboot.

Screenshot of Microsoft Defender Security Center alert for detection of WMI event filter bound to suspicious consumer

Figure 15. Microsoft Defender for Endpoint alert for WMI event filter bound to a suspicious consumer showing the persistence and the scheduled command line

Catching AD FS compromise and the attacker’s ability to impersonate users in the cloud

The next step in the attack focuses on the AD FS infrastructure and can unfold in two separate paths that lead to the same outcome—the ability to create valid SAML tokens allowing impersonation of users in the cloud:

  • Path 1 – Stealing the SAML signing certificate: After gaining administrative privileges in the organization’s on-premises network, and with access to the AD FS server itself, the attackers access and extract the SAML signing certificate. With this signing certificate, the attackers create valid SAML tokens to access various desired cloud resources as the identity of their choosing.
  • Path 2 – Adding to or modifying existing federation trust: After gaining administrative Azure Active Directory (Azure AD) privileges using compromised credentials, the attackers add their own certificate as a trusted entity in the domain either by adding a new federation trust to an existing tenant or modifying the properties of an existing federation trust. As a result, any SAML token they create and sign will be valid for the identity of their choosing.

In the first path, obtaining the SAML signing certificate normally entails first querying the private encryption key that resides on the AD FS container and then using that key to decrypt the signing certificate. The certificate can then be used to create illicit but valid SAML tokens that allow the actor to impersonate users, enabling them to access enterprise cloud applications and services.

Microsoft Defender for Endpoint and Microsoft Defender for Identity detect the actions that attackers take to steal the encryption key needed to decrypt the SAML signing certificate. Both solutions leverage unique LDAP telemetry to raise high-severity alerts highlighting the attacker’s progress towards creating illicit SAML tokens.

Screenshot of Microsoft Defender Security Center alert for LDAP query and AD FS private key extraction 

Figure 16. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted AD FS private key extraction

Figure 17. Microsoft Defender for Identity detects private key extraction via malicious LDAP requests

For the second path, the attackers create their own SAML signing certificate outside of the organization’s environment. With Azure AD administrative permissions, they then add the new certificate as a trusted object. The following advanced hunting query over Azure AD audit logs shows when domain federation settings are changed, helping to discover where the attackers configured the domain to accept authorization tokens signed by their own signing certificate. As these are rare actions, we advise verifying that any instances identified are the result of legitimate administrative activity.

ADFSDomainTrustMods

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType =~ “Set federation settings on domain.”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetDisplayName = targetDetails.Name
| extend resultStatus = extractjson(“$.ResultStatus”, tostring(RawEventData), typeof(string))
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, targetDisplayName, resultStatus, InitiatingIPAddress=IPAddress, UserAgent

If the SAML signing certificate is confirmed to be compromised or the attacker has added a new one, follow the best practices for invalidating through certificate rotation to prevent further use and creation of SAML tokens by the attacker. Additionally, affected AD FS servers may need to be isolated and remediated to ensure no remaining attacker control or persistence.

If the attackers accomplish either path, they gain the ability to create illicit SAML tokens for the identities of their choosing and bypass multifactor authentication (MFA), since the service or application accepting the token assumes MFA is a necessary previous step in creating a properly signed token. To prevent attackers from progressing to the next stage, which is to access cloud resources, the attack should be discovered and remediated at this stage.

Detecting the hands-on-keyboard activity in the cloud environment

Diagram of hands-on-keyboard attacks in the cloud

Figure 18. Solorigate attack chain: Hands-on-keyboard attack in the cloud

With the ability to create illicit SAML tokens, the attackers can access sensitive data without having to originate from a compromised device or be confined to on-premises persistence. By abusing API access via existing OAuth applications or service principals, they can attempt to blend into the normal pattern of activity, most notably apps or service principals with existing Mail.Read or Mail.ReadWrite permissions to read email content via Microsoft Graph from Exchange Online. If the application does not already have read permissions for emails, then the app may be modified to grant those permissions.

Identifying unusual addition of credentials to an OAuth app

Microsoft Cloud App Security (MCAS) has added new automatic detection of unusual credential additions to an OAuth application to alert SOCs about apps that have been compromised to extract data from the organization. This detection logic is built on an anomaly detection engine that learns from each user in the environment, filtering out normal usage patterns to ensure alerts highlight real attacks and not false positives. If you see this alert in your environment and confirm malicious activity, you should take immediate action to suspend the user, mark the user as compromised, reset the user’s password, and remove the credential additions. You may consider disabling the application during investigation and remediation.

Figure 19. Microsoft Defender Cloud App Security alert for unusual addition of credentials to an OAuth app

SOCs can use the following Microsoft 365 Defender advanced hunting query over Azure AD audit logs to examine when new credentials have been added to a service principle or application. In general, credential changes may be rare depending on the type and use of the service principal or application. SOCs should verify unusual changes with their respective owners to ensure they are the result of legitimate administrative actions.

NewAppOrServicePrincipalCredential

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType in (“Add service principal.”, “Add service principal credentials.”, “Update application – Certificates and secrets management “)
| extend RawEventData = parse_json(RawEventData)
| where RawEventData.ResultStatus =~ “success”
| where AccountDisplayName has “@”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetId = targetDetails.Id
| extend targetType = targetDetails.Type
| extend targetDisplayName = targetDetails.Name
| extend keyEvents = RawEventData.ModifiedProperties
| where keyEvents has “KeyIdentifier=” and keyEvents has “KeyUsage=Verify”
| mvexpand keyEvents
| where keyEvents.Name =~ “KeyDescription”
| parse keyEvents.NewValue with * “KeyIdentifier=” keyIdentifier:string “,KeyType=” keyType:string “,KeyUsage=” keyUsage:string “,DisplayName=” keyDisplayName:string “]” *
| parse keyEvents.OldValue with * “KeyIdentifier=” keyIdentifierOld:string “,KeyType” *
| where keyEvents.OldValue == “[]” or keyIdentifier != keyIdentifierOld
| where keyUsage == “Verify”
| project-away keyEvents
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, InitiatingIPAddress=IPAddress, UserAgent, targetDisplayName, targetId, targetType, keyDisplayName, keyType, keyUsage, keyIdentifier

Discovering malicious access to mail items

OAuth applications or service principals with Mail.Read or Mail.ReadWrite permissions can read email content from Exchange Online via the Microsoft Graph. To help increase visibility on these behaviors, the MailItemsAccessed action is now available via the new Exchange mailbox advanced audit functionality. See if this feature is enabled by default for you. Important note for customers: If you have customized the list of audit events you are collecting, you may need to manually enable this telemetry.

If more than 1,000 MailItemsAccessed audit records are generated in less than 24 hours, Exchange Online stops generating auditing records for MailItemsAccessed activity for 24 hours and then resumes logging after this period. This throttling behavior is a good starting point for SOCs to discover potentially compromised mailboxes.

MailItemsAccessedThrottling

let starttime = 2d;
let endtime = 1d;
CloudAppEvents
| where Timestamp between (startofday(ago(starttime))..startofday(ago(endtime)))
| where ActionType == “MailItemsAccessed”
| where isnotempty(RawEventData[‘ClientAppId’]) and RawEventData[‘OperationProperties’][1] has “True”
| project Timestamp, RawEventData[‘OrganizationId’],AccountObjectId,UserAgent

In addition to looking for throttled telemetry, you can also hunt for OAuth applications reading mail via the Microsoft Graph API whose behavior has changed prior to a baseline period.

OAuthGraphAPIAnomalies

//Look for OAuth App reading mail via GraphAPI — that did not read mail via graph API in prior week
let appMailReadActivity = (timeframeStart:datetime, timeframeEnd:datetime) {
CloudAppEvents
| where Timestamp between (timeframeStart .. timeframeEnd)
| where ActionType == “MailItemsAccessed”
| where RawEventData has “00000003-0000-0000-c000-000000000000” // performance check
| extend rawData = parse_json(RawEventData)
| extend AppId = tostring(parse_json(rawData.AppId))
| extend OAuthAppId = tostring(parse_json(rawData.ClientAppId)) // extract OAuthAppId
| summarize by OAuthAppId
};
appMailReadActivity(ago(1d),now()) // detection period
| join kind = leftanti appMailReadActivity(ago(7d),ago(2d)) // baseline period
on OAuthAppId

Microsoft 365 Defender’s cross-domain XDR correlation enables stronger response to critical security incidents

Like the rest of the security industry, Microsoft continues to track the Solorigate attack, an active threat that continues to unfold as well as evolve. As part of empowering our customers and the larger security community to respond to this attack through sharing intelligence and providing advice, this blog serves to guide Microsoft 365 customers to take full advantage of the comprehensive visibility and the rich investigation tools available in Microsoft 365 Defender. This blog shows that many of the existing capabilities in Microsoft 365 Defender help address this attack, but the unique scenarios created by the threat resulted in some Solorigate-specific detections and other innovative protections, including ones that are made possible by deeply integrated cross-domain threat defense.

For additional information and further guidance, refer to these Microsoft resources:

Microsoft will continue to provide public information about the patterns and techniques of this attack and related intelligence for customers to defend themselves, in addition to enhancing the protection capabilities of Microsoft security solutions.

 

Appendix: Additional details for detection and hunting

Detection details

Attack stage Microsoft 365 Defender detection or alert
Initial access Microsoft Defender for Endpoint:

  • ‘Solorigate’ high-severity malware was detected/blocked/prevented (Trojan:MSIL/Solorigate.BR!dha)
  • SolarWinds Malicious binaries associated with a supply chain attack
Execution and persistence Microsoft Defender for Endpoint:

Command and Control Microsoft Defender for Endpoint:

Defense evasion Microsoft Defender for Endpoint:

  • Suspicious audit policy tampering
Reconnaissance Microsoft Defender for Endpoint:

  • Masquerading Active Directory exploration tool
  • Suspicious sequence of exploration activities
  • Execution of suspicious known LDAP query fragments
Credential access Microsoft Defender for Endpoint:

  • Suspicious access to LSASS (credential access)
  • AD FS private key extraction attempt
  • Possible attempt to access ADFS key material
  • Suspicious ADFS adapter process created

Microsoft Defender for Identity:

  • Unusual addition of permissions to an OAuth app
  • Active Directory attributes Reconnaissance using LDAP

Microsoft Cloud App Security:

  • Unusual addition of credentials to an OAuth app
Lateral movement Microsoft Defender for Endpoint

  • Suspicious file creation initiated remotely (lateral movement)
  • Suspicious Remote WMI Execution (lateral movement)
Exfiltration Microsoft Defender for Endpoint

  • Suspicious mailbox export or access modification
  • Suspicious archive creation

Advanced hunting queries

Attack stage Query link in GitHub repo
General Microsoft Defender for Endpoint Threat and Vulnerability Management:

Initial access Microsoft Defender for Endpoint:

Execution Microsoft Defender for Endpoint:

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

Command and Control Microsoft Defender for Endpoint

Credential access Azure Active Directory (Microsoft Cloud App Security):

Exfiltration Exchange Online (Microsoft Cloud App Security):

The post Using Microsoft 365 Defender to protect against Solorigate appeared first on Microsoft Security.

December 21st, 2020 – Solorigate Resource Center

December 22nd, 2020 No comments

Alongside our industry partners and the security community, Microsoft continues to investigate the extent of the recent nation-state attack on SolarWinds. Our goal is to provide the latest threat intelligence, Indicators of Compromise (IOC)s, and guidance across our products and solutions to help the community respond, harden infrastructure, and begin to recover from this unprecedented attack. As new information becomes available, we will make updates to this article at https://aka.ms/solorigate   Executive Summary and Background Information  …

December 21st, 2020 – Solorigate Resource Center Read More »

Categories: Uncategorized Tags:

Advice for incident responders on recovery from systemic identity compromises

December 21st, 2020 No comments

As Microsoft alongside our industry partners and the security community continues to investigate the extent of the Solorigate attack, our goal is to provide the latest threat intelligence including IOCs and guidance across our products and solutions to help the community fight back against, harden your infrastructure, and begin to recover from this attack of unprecedented scale. As new information becomes available, we will make updates to this article.

This blog will outline lessons learned from this and other incident response to date in on-premises and cloud environments. This latest guidance is for customers looking to re-establish trusted identities for credentials that are suspected of compromise by Solorigate malware.

This article is intended to give experienced incident responders some advice on techniques to consider when helping an organization respond to a suspected systemic identity compromise, like we’re seeing in some victims of the Solorigate malware, based on our experience in the field in similar scenarios. Re-establishing trust in the organization’s on-premises and cloud environments with minimal business impact requires in-depth investigation and an understanding of potential methods of persistence. While not meant to cover every possible scenario, this guidance is intended to summarize our experience with similar customer breaches and will be updated if we learn of new information that would help with successful recovery. Please review the resources referenced at the end of this article for additional information. This information is provided as-is and constitutes generalized guidance; the ultimate determination about how to apply this guidance to your IT environment and tenant(s) must consider your unique environment and needs, which each Customer is in the best position to determine.

The Solorigate investigation referenced in this guidance is ongoing at the time of publication and our teams continue to act as first responders to these attacks. As new information becomes available, we will make updates through our Microsoft Security Response Center (MSRC) blog.

Overview of the intrusion

As described in this Microsoft blog post, the hallmarks of this actor’s activity include, but are not limited to, the following techniques that are likely to result in systemic identity compromise:

  • An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Read our in-depth technical analysis of the Solorigate malware.
  • An intruder using administrative permissions (acquired through an on-premises compromise) to gain access to an organization’s trusted SAML token-signing certificate. This enables them to forge SAML tokens to impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens signed with a compromised token-signing certificate, which can be used against any on-premises resources (regardless of identity system or vendor) as well as against any cloud environment (regardless of vendor) because they have been configured to trust the certificate. An organization may miss the use of illegitimate SAML tokens because they are signed with a legitimate certificate.
  • The use of highly privileged accounts (acquired through the technique above or other means) to add illegitimate credentials to existing application service principals, enabling the attacker to call APIs with the permission assigned to that application.

Overview of response objectives

Organizations that have experienced systemic identity compromise need to start recovery by re-establishing trustworthy communications. This will enable effective triage and coordination of business operations recovery.

Many organizations have complex internal and external interdependencies. Core business processes and applications in an organization are likely to be temporarily impacted during recovery efforts until trust within your environment is re-established. Microsoft recommends that Incident Responders establish secure communications with key organizational personnel as the first step toward organizational recovery. If your investigation indicates that the attacker has used techniques outside of identity compromise at lower levels of your organizations’ infrastructure, such as hardware or firmware attacks, you will need to address those threats to reduce the risk of re-compromise.

Response objectives in approximate order:

  1. Establish secure communications for personnel key to the investigation and response effort.
  2. Investigate the environment for persistence and initial access point, while establishing continuous monitoring operations during recovery efforts.
  3. Regain and retain administrative control of your environment and remediate or block possible persistence techniques and initial access exploits.
  4. Improve posture by enabling security features and capabilities following best practice recommendations.

We recommend that incident responders review and digest the entirety of this guidance before taking action, as the specific order of actions taken to achieve the response objectives is very situational and depends heavily on the results (and completeness) of investigation and the business constraints of the specific organization. The following sections describe the incident Response techniques we recommend you consider for each of the above objectives.

Establish secure communications and productivity

Successful response requires being able to communicate without the attacker eavesdropping on your communications. Until you have achieved assurance in the privacy of your communications on your current infrastructure, use completely isolated identities and communication resources to coordinate your response and discuss topics that could potentially tip off the attacker to your investigation. Until your investigation has achieved assurance in actor eviction, we strongly recommend that you keep all incident-related comms isolated to enable you to have the element of surprise when taking remediation actions.

  • Initial one-on-one and group communications can be achieved through phone (PSTN) calling, conference bridges not connected to the corporate infrastructure, and end-to-end encrypted messaging solutions.
  • One way that many customers have established secure productivity and collaboration is to create a new Office 365 tenant which is completely isolated from the organization’s production tenant and create accounts only for the key personnel needed, and any incident response vendors or partners who need to be part of the response.
    • Make sure to follow best practices for securing this tenant, especially administrative accounts and rights by default. The new tenant should be limited on Administrative rights along with no trusts with outside applications or vendors. If you need further assistance or want information on hardening Microsoft 365, you can review the guidance here.

Investigate your environment

Once your incident responders and key personnel have a secure place to collaborate, the next step is to investigate the suspected compromised environment. Successful investigation will be a balance between getting to the bottom of every anomalous behavior to fully scope the extent of attacker activity and persistence and taking action quickly to stop any further activity on objectives by the attacker. Successful remediation requires as complete an understanding of the initial method of entry and persistence mechanisms controlled by the attacker as possible. Any persistence mechanisms missed could result in continued access by the attacker and potential for re-compromise.

  • Investigate and review cloud environment logs for suspicious actions and attacker IOCs, including:
    • Unified Audit Logs (UAL).
    • Azure Active Directory (Azure AD) logs.
    • Active Directory logs.
    • Exchange on-prem logs.
    • VPN logs.
    • Engineering systems logging.
    • Antivirus and endpoint detection logging.
  • Review endpoint audit logs for changes from on-premises for actions including, but not limited to, the following:
    • Group membership changes.
    • New user account creation.
    • Delegations within Active Directory.
    • Along with other typical signs of compromise or activity.
  • Review Administrative rights in your environments
    • Review privileged access in the cloud and remove any unnecessary permissions. Implement Privileged Identity Management (PIM); setup Conditional Access policies to limit administrative access during hardening.
    • Review privileged access on-premise and remove unnecessary permissions. Reduce membership of built-in groups, verify Active Directory delegations, harden Tier 0 environment, and limit who has access to Tier 0 assets.
    • Review all Enterprise Applications for delegated permissions and consent grants that allow (sample script to assist):
      • Modification of privileged users and roles.
      • Reading or accessing all mailboxes.
      • Sending or forwarding email on behalf of other users.
      • Accessing all OneDrive or SharePoint sites content.
      • Adding service principals that can read/write to the Directory.
    • Review access and configuration settings for the following Office 365 products:
      • SharePoint Online Sharing
      • Teams
      • PowerApps
      • OneDrive for Business
    • Review user accounts
      • Review and remove guest users that are no longer needed.
      • Review email configurations using Hawk or something similar.
        • Delegates
        • Mailbox folder permissions
        • ActiveSync mobile device registrations
        • Inbox Rules
        • Outlook on the Web Options
      • Validate that both MFA and self-service password reset (SSPR) contact information for all users is correct.

You may find that one or more of the logging sources above are data sources that the organization does not currently include in its security program. Some of them, especially the logging available in the cloud, are available only if configured and we recommend that you configure them as soon as possible to enable both the detections in the next section and forensics review of logs going forward. Make sure to configure your log retention to support your organization’s investigation goals going forward and retain evidence, if needed for legal, regulatory, or insurance purposes.

Establish continuous monitoring

There are many ways to detect activity associated with this campaign. Exactly how your organization will detect attacker behavior depends on which security tools you have available, or choose to deploy in response. Microsoft has provided examples publicly for some of the core security products and services that we offer and are continually updating those documents as new threat intelligence is identified related to this attacker. If you use other vendor’s products, review your vendor’s recommendations, and review the Microsoft documentation below to understand the detection techniques if you need to implement analogous detections in your environment on your own.

For readers using Azure Sentinel in their environments, review SolarWinds Post-Compromise Hunting guidance.

For readers using Microsoft Defender for Endpoint, review our guidance here, and review Microsoft Defender Antivirus guidance.

Azure Active Directory sign-ins

You can view this information from the Azure Active Directory Sign-in blade by selecting an appropriate time window and then downloading the report as either a CSV or JSON file. NOTE: You can download interactive, as well as non-interactive, sign-in reports via this interface. Once you have downloaded the results, look for the value “MFA requirement satisfied by claim in the token” in the “MFA result” field.

You can also use the Get-AzureADAuditSignInLogs cmdlet (see the details here) and filter the results to only return entries that match this field value, as seen in this example:

Get-AzureADAuditSignInLogs -All:$true -Filter "createdDateTime gt <startdate> and createdDateTime lt <enddate>"  | where {$_.Status.AdditionalDetails -eq "MFA requirement satisfied by claim in the token"} | select-object CreatedDateTime, IpAddress,UserAgent, ResourceDisplayName, CorrelationId, RequestId, UserPrincipalName -ExpandProperty Status

If your ADFS environment is configured to send a claim for MFA being satisfied, this may not be a strong signal. However, for many organizations using ADFS, and this claim is not included per your configuration; in those cases, the presence of this claim may be a strong indicator of attacker activity. You may also wish to add additional filters or conditions in the where clause to further improve your signal to noise ratio, such as only surfacing results from domains that are federated.

If suspicious sign-ins are detected, you can further pivot your investigation based on IP addresses identified, user accounts identified, and/or other indicators such as the UserAgent string and client operating system observed, if based on your knowledge of your environment these appear to be strong indicators.

Analysis of risky sign-in events

In some cases, Azure Active Directory and its Identity Protection platform will generate risk events associated with the use of attacker generated SAML tokens. These can be labeled as “unfamiliar properties”, “anonymous IP address”, “impossible travel” and the other risk events as described here.

Closely analyze all risk events associated with accounts that have administrative privileges. It is also important to analyze events that have been dismissed or remediated as some of these actions are done automatically. For example, a risk event for an anonymous IP address can be automatically remediated because the user passed MFA.

Detection of domain authentication properties

The attacker may attempt to manipulate the domain authentication policies which are recorded in the Azure Active Directory Audit Logs and reflected in the Unified Audit Log. An attacker who has gained access with Global Administrator privileges can modify the domains that are federated and/or trusted. Review any events associated with “Set domain authentication” in either the Unified Audit Log, Azure AD Audit Logs, and/or your SIEM environment. Verify that all activities were expected and planned.

The sample command below returns the entries from the Unified Audit Log which were associated with manipulation of domain authentication settings.

Search-UnifiedAuditLog -StartDate <startdate> -EndDate <enddate> -ResultSize 5000 -Operations "Set domain authentication"

Detection of credentials to a service principal associated with an OAuth application

If the attacker has gained control of a credential with sufficient privileges, the attack pattern includes locating an application that has been granted the ability to access any user’s e-mail in the organization and adding attacker controlled credentials to that application. In some cases, the attacker has modified these applications granting them additional rights such as access to all e-mail in the organization.

The following are operations that would be consistent with attacker behavior:

  • Add service principal credentials.
  • Update application- certificates and secrets management.
  • Update service principal.
  • Add app role assignment to service principal.
  • Add app role assignment grant to user.
  • Add OAuth2PermissionGrant.

Detection e-mail access by applications

Detection of access to e-mail by applications can be achieved using the Advanced Auditing capabilities of Office 365. Access to messages inside of Office 365 is audited via the MailItemsAccessed capability.

Analyze events in the Unified Audit Log for the Operation of MailItemsAccessed.

Detection of non-interactive sign-ins to service principals

Azure Active Directory in the Sign-In reports provides reporting of non-interactive sign-ins using credentials issued to service principals (as was observed in this attack). Analyzing the sign-ins for service principals reports can provide valuable data such as the IP Address the attacker was using to access the applications for e-mail access.

If there is evidence found that uncovers administrative permissions acquired through the on-premises compromise to gain access to your organization’s global administrator account and/or trusted SAML token signing certificate, Microsoft recommends taking the following immediate actions:

Remediate and retain administrative control

Regaining and retaining administrative control of your environment

If your investigation has identified that the attacker has administrative control in the organization’s cloud environment and/or on-prem, it’s critical to regain control in such a way as to ensure that the attacker isn’t persistent. Exactly which steps you will take depend both on what persistence you discovered in your investigation, and your level of confidence in the completeness of that investigation and discovery of all possible methods of entry and persistence. While it is possible to regain control with high confidence, even in the face of an incomplete investigation, doing so requires significant impact to business operations, so most organizations choose to remediate based on the results of the investigation in our experience.

We recommend you consider the following steps when building your administrative control recovery plan, but the exact order and timing should be planned based on the results of your investigation and understanding of adversary owned administrative assets and methods of persistence.

  • Ensure that any actions described here are performed from a trusted device built from a clean source, such as a privileged access workstation.
  • If the organization has lost control of its token signing certificates or federated trust the highest assurance approach is to remove trust and switch to cloud mastered identity while remediating on-prem. A detailed plan for doing so is beyond the scope of this document and requires careful planning and understanding of the business operations impacts of isolating identity. Review the Azure Active Directory guidance or key considerations.
  • Should your organization choose not to break trust while recovering administrative control on-prem, you’ll need to rotate your SAML token signing certificate once you have regained administrative control on-prem and blocked the attacker’s ability to access the signing certificate again. It’s critical that your organization follow the certificate rotation instructions below to ensure that the attacker doesn’t maintain the ability to forge tokens for your domain.

Rotation of ADFS token signing certificate

For a compromised or potentially compromised ADFS Token Signing certificate, rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work. The rationale for this is to permit a grace period to update your Relying Party Trusts prior to expiration of the certificate during normal rotation of the signing certificate.

If instead of rolling the Token Signing Certificate your organization feels the need to replace the ADFS servers with known clean systems, you can follow steps to remove the existing ADFS from your environment and build a new one.

Delete Azure AD Cloud Provisioning agent configuration.

Should your organization decide to rotate the certificate on your current ADFS servers, follow these steps in the below order, from the ADFS server:

  1. Check to make sure that your AutoCertificateRollover is set to True.
    Get-AdfsProperties | FL AutoCert*, Certificate*
    • If it is not, you can set it with this command:
      Set-ADFSProperties -AutoCertificateRollover $true
  2. Connect to the Microsoft Online Service
    Connect-MsolService
  3. Document both your on-premise and cloud Token Signing Certificate thumbprint and expiration dates.
    Get-MsolFederationProperty -DomainName <domain>
    
  4. Replace the primary Token Signing certificate using the -Urgent switch to cause ADFS to replace the primary certificate immediately without making it a Secondary certificate.
    Update-AdfsCertificate -CertificateType Token-Signing -Urgent
  5. Create a secondary Token Signing certificate without using the -Urgent switch to allow for two on-premise Token Signing certificates, before syncing with Azure cloud.
    Update-AdfsCertificate -CertificateType Token-Signing
    
  6. Update the cloud environment with both the primary and secondary certificates on-premise to immediately remove the cloud published token signing certificate. If this step is not completed using this method you leave the potential for the old token signing certificate to still authenticate users.
    Update-MsolFederatedDomain -DomainName <domain>
     
    
  7. Verification that you completed the above steps and removed the certificate that was displayed in Step 3 above.
    Get-MsolFederationProperty -DomainName <domain>
    
  8. Revoke refresh tokens via PowerShell, information can be found here and you can also reference how to “Revoke user access in Azure Active Directory.”
    • Note: This will log users out of their phone, current webmail sessions, along with other items that are using Tokens and Refresh Tokens.

Additional cloud remediation activities to complete

  • Reset passwords on any break-glass accounts and reduce the number of break-glass accounts to the absolute minimum required.
  • We recommend that service and user accounts with Privileged access should be Cloud Only accounts and not use on-premise accounts synced or federated to Azure Active Directory.
  • Enforce Multi-Factor Authentication (MFA) across all elevated users in the tenant. We recommend enforcing MFA across all users in the tenant.
  • Implement Privileged Identity Management (PIM) and conditional access to limit administrative access.
    • For Office 365 users, implement Privileged Access Management (PAM) to limit access to sensitive capabilities (including eDiscovery, Global Admin, Account Administration, and more).
  • Review and reduce all Enterprise Applications delegated permissions or consent grants that allow such as:
    • Modification of privileged users and roles.
    • Reading, sending email, or accessing all mailboxes.
    • Accessing OneDrive, Teams, or SharePoint content.
    • Adding of Service Principals that can read/write to the Directory.
    • Application Permissions versus Delegated Access.

Additional on-premises remediation activities to complete

  • Rebuild systems that were identified as compromised by the attacker during your investigation.
  • Remove unnecessary members from Domain Admins, Backup Operators, and Enterprise Admin groups. Reference Microsoft’s Securing Privileged Access.
  • Reset passwords of all privileged accounts in the environment.
    • Privilege accounts are not limited to Built-In groups but can also be groups that are delegated access to Server Administration / Workstation Administration and other aspects of your environment.
  • Reset the krbtgt account using this script twice.
    • Note: If you are using Read-Only Domain Controllers, you will need to run the script for Read-Write Domain Controllers and Read-Only Domain Controllers.
  • After you validate that no persistence mechanisms created by the attacker exist or remain on your system, schedule a restart. This can assist with removing memory resident malware.
  • Reset each domain controller’s DSRM (Directory Services Restore Mode) password to something unique and complex.

Remediate or block persistence discovered during investigation

Remediate the persistence techniques identified in your investigation stage earlier. Investigation is an iterative process and you’ll need to balance the organizational desire to remediate as you identify anomalies and the chance that remediation will alert the attacker of your detection and cause them to react by changing techniques or creating additional persistence. For Office 365 accounts, automatically remediate known persistence techniques, if any are discovered, using the scripts described

Remediate user and service account access

Some of the user-level actions we recommend were described above already, specifically in terms of ensuring that MFA is enabled and running specific remediation scripts to clean up known persistence techniques. Here are some additional steps you should consider taking to remediate and restore user accounts:

  • Enforce conditional access based on trusted device.
    • If possible, enforce location-based conditional access that suits your organizational requirements.
  • For any user accounts suspected of being compromised, immediately reset passwords after eviction; make sure you also implement a mid-term plan to reset credentials for all accounts in your directory.
  • After credential rotation, use PowerShell to revoke refresh tokens immediately. More information can be found here and additional resources can be found at Revoke user access in an emergency in Azure Active Directory | Microsoft Docs.

Improve security posture

After a security event is a good time for organizations to reflect on their security strategy and priorities. Incident Responders are often asked to provide recommendations after an event on what investments the organization should prioritize now that it’s been faced with new threats. In addition to the recommendations documented earlier, we recommend you consider these areas of focus for your post-incident review recommendations that are responsive to the post-exploitation techniques used by this attacker and the common security posture gaps that enable them.

General security posture

  • Review Microsoft Secure Score for security fundamentals recommendations customized for the Microsoft products and services you consume.
  • Ensure that your organization has EDR and SIEM solutions in place.
  • Review Microsoft’s Enterprise access model.

Identity

  1. Review Five steps to securing your identity infrastructure and prioritize steps as appropriate for your Identity architecture.
  2. Consider migrating to Azure AD Security Defaults for your authentication policy- details can be found here.
  3. Eliminate your organization’s use of legacy authentication, if systems or applications still require it- review the guidance here.
    • As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate but provide complementary features. We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020. We will provide notifications via Message Center posts before we disable Basic Authentication for any tenant.
  4. In order to help protect your ADFS/Azure AD Connect systems, beyond the ADFS guidance located, we recommend that you consider the following actions:
    • Treat your ADFS infrastructure and AD Connect infrastructure as a Tier 0 asset.
    • Restrict local administrative access to the system, including the account that is used to run the ADFS service.
      • The least privilege necessary for the account running ADFS is the Log on as a Service User Right Assignment.
    • Restrict administrative access to limited users and from limited IP address ranges by leveraging Windows Firewall policies for Remote Desktop.
      • It is recommended to set up a Tier 0 jump box or equivalent system.
    • Block all inbound SMB access to the systems from anywhere in the environment. See this resource for further details.
      • Get the Windows Firewall logs to a SIEM for historical and proactive monitoring.
    • If you are using a Service Account and your environment supports it, migrate from a Service Account to a group Managed Service Account (gMSA). If you cannot move to a gMSA, rotate the password on the Service Account to a complex password.
    • Ensure Verbose logging is enabled on your ADFS systems by executing the following commands:
Set-AdfsProperties -AuditLevel verbose
Restart-Service -Name adfssrv
Auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

Contributors: We thank the team at FireEye for their contributions and review.

The post Advice for incident responders on recovery from systemic identity compromises appeared first on Microsoft Security.

Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect

December 18th, 2020 No comments

We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack. While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result.

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

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

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

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

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

 

Figure 1. Solorigate malware infection chain

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

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

Where it all starts: A poisoned code library

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

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

Figure 3: What the original method looks like

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

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

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

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

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

Figure 5: Example of obfuscated strings

Initial reconnaissance

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

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

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

The backdoor

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

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

Figure 6: Dynamically generated C2 domain

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

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

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

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

Here are examples of final URLs generated by the backdoor:

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

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

Figure 7: Example of data generated by the malware

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

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

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

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

Resulting hands-on-keyboard attack

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

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

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

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

Persistence is achieved via backdoors deployed via various techniques:

  1. PowerShell:

Powershell -nop -exec bypass -EncodedCommand

The –EncodedCommand, once decoded, would resemble:

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

  1. Rundll32:

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

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

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

Microsoft Defender for Endpoint product and hardening guidance

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

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

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

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

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

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

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

Next generation protection

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

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

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

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

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

Figure 9. Microsoft Defender for Endpoint prevented malicious binaries

Endpoint detection and response (EDR)

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

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

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

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

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

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

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

Threat analytics report

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

Figure 12. Threat analytics report on the Solorigate attack

Advanced hunting

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

Malicious DLLs loaded into memory

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

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

Malicious DLLs created in the system or locally

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

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

SolarWinds processes launching PowerShell with Base64

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

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

SolarWinds processes launching CMD with echo

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

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

C2 communications

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

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

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

DeviceNetworkEvents| where RemoteUrl contains ‘avsvmcloud.com’| where InitiatingProcessFileName != “chrome.exe”| where InitiatingProcessFileName != “msedge.exe”| where InitiatingProcessFileName != “iexplore.exe”| where InitiatingProcessFileName != “firefox.exe”| where InitiatingProcessFileName != “opera.exe”

Find SolarWinds Orion software in your enterprise

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

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

ADFS adapter process spawning

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

 

Appendix

MITRE ATT&CK techniques observed

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

Initial Access

T1195.001 Supply Chain Compromise

Execution

T1072 Software Deployment Tools

Command and Control

T1071.004 Application Layer Protocol: DNS

T1017.001 Application Layer Protocol: Web Protocols

T1568.002 Dynamic Resolution: Domain Generation Algorithms

T1132 Data Encoding

Persistence

T1078 Valid Accounts 

Defense Evasion

T1480.001 Execution Guardrails: Environmental Keying

T1562.001 Impair Defenses: Disable or Modify Tools

Collection

T1005 Data From Local System 

Additional malware discovered

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

Figure 13: Original DLL

Figure 14: The malicious addition that calls the DynamicRun method

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

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

Categories: cybersecurity Tags:

Collaborative innovation on display in Microsoft’s insider risk management strategy

December 17th, 2020 No comments

The disrupted work environment, in which enterprises were forced to find new ways to enable their workforce to work remotely, changed the landscape for operations as well as security. One of the top areas of concern is effectively managing insider risks, a complex undertaking even before the pandemic, and even more so in the new remote or hybrid work environment.

Because its scope goes beyond security, insider risk management necessitates diverse perspectives and thus inherently requires collaboration among key stakeholders in the organization. At Microsoft, our insider risk management strategy was built on insights from legal, privacy, and HR teams, as well as security experts and data scientists, who use AI and machine learning to sift through massive amounts of signals to identify possible insider risks.

It was also important for us to extend this collaboration beyond Microsoft. For example, for the past few years, Microsoft has partnered with Carnegie Mellon University to bring in their expertise and experience in insider risks and provide insights about the nature of the broader landscape.

Our partnership with Carnegie Mellon University has helped shape our mindset and influenced our Insider Risk Management product, a Microsoft 365 solution that enables organizations to leverage machine learning to detect, investigate, and act on malicious and unintentional activities. Partnering with organizations like Carnegie Mellon University allows us to bring their rich research and insights to our products and services, so customers can fully benefit from our breadth of signals.

This research partnership with Carnegie Mellon University experiments with innovative ways to identify indicators of insider risk. The output of these experiments become inputs to our research-informed product roadmap. For example, our data scientists and researchers have been looking into using threat data from Microsoft 365 Defender to gain insights that can be used for managing insider risks. Today, we’d like to share our progress on this research in the form of Microsoft 365 Defender advanced hunting queries, now available in a GitHub repo:

  1. Detection Exfiltration to Competitor Organization: This query helps enterprises detect instances of a malicious insider creating a file archive and then emailing that archive to an external “competitor” organization. Effective query use requires prior knowledge of email addresses that may pose a risk to the organization if data is sent to those addresses.
  2. Detecting exfiltration after termination: This query explores instances in which a terminated individual (i.e., one who has an impending termination date, but has not left the company) downloads many files from a non-domain network address.
  3. Detecting steganography exfiltration: This query detects instances of malicious users who attempt to create steganographic images and then immediately browse to a webmail URL. It requires additional investigation to determine indication of a malicious event through the co-occurrence of a) generating a steganographic image; and b) browsing to a webmail URL

As these queries demonstrate, industry partnerships allow us to enrich our own intelligence with other organizations’ depth of knowledge, helping us address some of the bigger challenges of insider risks through the product, while bringing scientifically proven solutions to our customers more quickly through this open-source library.

Microsoft will continue investing in partnerships like Carnegie Mellon University to learn from experts and deliver best-in-class intelligence to our customers. Follow our insider risk podcast and join us in our Insider Risk Management journey!

The post Collaborative innovation on display in Microsoft’s insider risk management strategy appeared first on Microsoft Security.

Security baseline (FINAL) for Windows 10 and Windows Server, version 20H2

December 17th, 2020 No comments

We are pleased to announce the final release of the for Windows 10 and Windows Server, version 20H2 (a.k.a. October 2020 Update) security baseline package!


 


Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize and implement as appropriate. If you have questions or issues, please let us know via the Security Baseline Community.


 


This Windows 10 feature update brings very few new policy settings, which we list in the accompanying documentation. At this point, no new 20H2 policy settings meet the criteria for inclusion in the security baseline, but there are a few policies we are going to be making changes to, which we highlight below along with our recommendations.


 


Tip: If you read the Draft release, we will save you another read. There are no changes since the draft to the actual settings. There were two small changes to the package though; the Baseline-LocalInstall.ps1 script has a change to error handling (thanks to a community member’s suggestion) and second, we neglected to include the custom ADMX/L files in the GP Reports so they showed up as additional registry keys which is now fixed also.


 


Block at first sight


We started the journey for cloud protection several years ago. Based on our analysis of the security value versus the cost of implementation, we feel it’s time to add Microsoft Defender Antivirus’ Block At First Sight (BAFS) feature to the security baseline. BAFS was first introduced in Windows 10, version 1607 and allows new malware to be detected and blocked within seconds by leveraging various machine learning techniques and the power of our cloud.


 


BAFS currently requires 6 settings to be configured. Our baseline already sets 2 of them, Join Microsoft MAPS and Send file sample when further analysis is required. We are now recommending the addition of the following settings to enable BAFS:


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MAPS\Configure the ‘Block at first sight’ feature set to Enabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Scan all downloaded files and attachments set to Enabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Turn off real-time protection set to Disabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MPEngine\Select cloud protection level set to High blocking level


 


These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.


 


Additional details on BAFS can be found here.


 


Attack Surface Reduction Rules


We routinely evaluate our Attack Surface Reduction configuration, and based on telemetry and customer feedback we are now recommending configuring two additional Attack Surface Reduction controls: Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Microsoft Defender Exploit Guard\Attack Surface Reduction\Configure Attack Surface Reduction rules: Use advanced protection against ransomware and Block persistence through WMI event subscription.


 


Introduced in Windows 10, version 1709 the Use advanced protection against ransomware rule will scan any executable files and determine, using advanced cloud analytics, if the file looks malicious .  If so, it will be blocked unless that file is added to an exclusion list. This rule does have a cloud dependency, so you must have Join Microsoft MAPS also configured (which is already part of the security baseline).


 


Block persistence through WMI event subscription is a rule that was released in Windows 10, version 1903. This rule attempts to ensure WMI persistence is not achieved – a common technique adversaries use to evade detection. Unlike many of the other ASR rules, this rule does not allow any sort of exclusions since it is solely based on the WMI repository.


 


A friendly reminder that the security baselines set all ASR rules to block mode. We recommend first configuring them to audit mode, then testing to ensure you understand the impacts these rules will have in your environment, and then configuring them to block mode. Microsoft Defender for Endpoints (formally Microsoft Defender Advanced Threat Protection, MDATP) will greatly enhance the experience of testing, deployment, and operation of ASR rules. We would encourage you to look at evaluating, monitoring and customizing links to better prepare your environment.


 


These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.


 


UEFI MAT


You might recall in the draft release of our security baseline for Windows 10, version 1809 we enabled UEFI Memory Attributes Tables, but based on your feedback we removed that recommendation from the final version. After further testing and discussions, we are recommending that you enable Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security\Require UEFI Memory Attributes Table.


 


Microsoft Edge


Starting with Windows 10, version 20H2 the new Microsoft Edge (based on Chromium) is now installed as part of the operating system. Please ensure you are applying the security baseline for Microsoft Edge to your Windows 10, version 20H2 machines. We have gotten questions about including it on the Windows security baseline, but since Microsoft Edge is a cross platform product and has a different release cadence, we are going to keep it a separate security baseline.


 


As always, please let us know your thoughts by commenting on this post.

Categories: Uncategorized Tags:

A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture

December 17th, 2020 No comments

In the last post, we discussed Office 365 and how enabling certain features without understanding all the components can lead to a false sense of security. We demonstrated how implementing a break glass account, multi-factor authentication (MFA), and the removal of legacy authentication can help secure your users and point your organization’s security posture in the right direction. While implementing those controls is an excellent start to hardening your environment, it is just the beginning. Read that blog here.

Security is critical, and any way that we can expedite threat prevention is highly welcomed. What if there was a way to get into a more secure state quickly.  How much time would this give you back to focus your attention on other tasks like actual customers (user base, clients)?

Do you wish there was a quick approach for security configurations in Azure Active Directory (Azure AD) and Office 365? I know I do, and thankfully we have some options here, and they are Secure Score and security defaults. Many of our customers are not aware that these features exist, or if they are aware, they fail to take advantage of using them.

“This blog post will provide an overview of Microsoft Secure Score and security defaults—two features that are easy to utilize and can significantly improve your security in Azure AD and Office 365 configurations.” 

What is Microsoft Secure Score? I am glad you asked

Microsoft Secure Score is a measurement developed to help organizations understand where they are now and the steps needed to improve their security posture. Microsoft Secure Score summarizes the different security features and capabilities currently enabled and provides you with the ability to compare your Score with other companies like yours and identify recommendations for areas of improvement.

Microsoft Secure Score screen image

Figure 1: Microsoft Secure Score screen image

How does Secure Score help organizations?

Secure Score provides recommendations for protecting your organization from threats. Secure Score will:

  • Objectively measure your identity security posture.
  • Plan for security improvements.
  • Review the success of your improvements.
  • The Score can also reflect third-party solutions that have been implemented and have addressed recommended actions.
  • The Secure Score reflects new services, thus keeping you up to date with new features and security settings that should be reviewed and if action on your part.

How is the Score determined?

Secure Score compares your organization’s configuration against anonymous data from other organizations with similar features to your organization, such as company size. Each improvement action is worth ten points or less, and most are scored in a binary fashion. If you implement the improvement action, like require MFA for Global Administrators or create a new policy or turn on a specific setting, you get 100 percent of the points. For other improvement actions, points are given as a percentage of the total configuration.

For example, an improvement action states you get ten points by protecting all your users with multi-factor authentication. You only have 50 of 100 total users protected, so that you would get a partial score of five points.

Additionally, your score will drop if routine security tasks are not completed regularly or when security configurations are changed. It will provide directions to the security team about what has changed and the security implications of those changes.

What are security defaults?

Security defaults, a one-click method for enabling basic identity security in an organization, are pre-configured security settings that help defend organizations against frequent identity-related attacks, such as password spray, replay, and phishing. Some of the critical features of Security Defaults include:

  • Requiring all users to register for Azure AD Multi-Factor Authentication (MFA) using the Microsoft Authenticator app.
  • Requiring administrators to perform multi-factor authentication.
  • Blocking legacy authentication protocols.
  • Requiring users to perform multi-factor authentication when necessary.
  • Protecting privileged activities like access to the Azure portal.

When should you use security defaults?

It would be best if you used security defaults in the following cases:

  • If you want to increase the overall security posture and don’t know how or where to start, security defaults are for you.
  • If you are using the free tier of Azure Active Directory licensing, security defaults are for you.

How is the Score determined?

Microsoft Secure Score has recently added improvement actions to support security defaults in Azure Active Directory, making it easier to help protect your organization with pre-configured security settings for frequent attack vectors.

When you turn on security defaults, you will be awarded full points for the following improvement actions:

  • Ensure all users can complete multi-factor authentication for secure access (nine points).
  • Require MFA for administrative roles (ten points).
  • Enable policy to block legacy authentication (seven points).

Get Started with Microsoft Secure Score and security defaults

Microsoft organizes Secure Score improvement actions into groups to help you focus on what you need to address for your organization:

  • Identity (Azure AD accounts and roles).
  • Data (Microsoft Information Protection).
  • Device (Microsoft Defender ATP, known as Configuration score).
  • Application (email and cloud apps, including Office 365 and Microsoft Cloud App Security).
  • Infrastructure (no improvement actions for now).

Secure Score

  • Start by logging into your Secure Score.
  • View your scores and where you need to improve.
  • Export all recommendations for your organization and turn this into an attack plan.
  • Prioritize the recommendations you will implement over the next 30, 60, 90, and 180 days.
  • Pick the tasks that are priorities for your organization and work these into your change control processes.

Security defaults

  • Start by logging in to your  Azure portal as a security administrator, Conditional Access administrator, or global administrator.
  • Browse to Azure Active Directory, and then Properties.
  • Select Manage security defaults.
  • Set the Enable security defaults, then toggle to Yes.
  • Select Save.

Enabling security defaults

Figure 2:  Enabling security defaults

There are many security enhancements that keep coming to Microsoft’s Cloud stack, so be sure you check your secure Score weekly. As the days go by and new security settings appear, your secure Score will reflect these changes. It is critical to check back often to ensure you are addressing any further recommendations.

Bumps in the road

Microsoft Secure Score and security defaults are straight forward ways to evaluate and improve your Azure AD and Office 365 configurations’ security. Security defaults help implement industry recommended practices, while Microsoft Secure Score creates a hands-on interface that simplifies the ongoing process of security assessment and improvement.

Our upcoming blog will explore the necessary built-in Azure tooling and open-source options that an organization can employ during investigative scenarios.

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 A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture appeared first on Microsoft Security.

A breakthrough year for passwordless technology

December 17th, 2020 No comments

As 2020 draws to a close, most of us are looking forward to putting this year in the rearview mirror. Since we depend even more on getting online for everything in our lives, we’re more than ready to be done with passwords. Passwords are a hassle to use, and they present security risks for users and organizations of all sizes, with an average of one in every 250 corporate accounts compromised each month. According to the Gartner Group, 20 to 50 percent of all help desk calls are for password resets. The World Economic Forum (WEF) estimates that cybercrime costs the global economy $2.9 million every minute, with roughly 80 percent of those attacks directed at passwords.

In November 2019 at Microsoft Ignite, we shared that more than 100 million people were already using Microsoft’s passwordless sign-in each month. In May of 2020, just in time for World Password Day, that number had already grown to more than 150 million people, and the use of biometrics to access work accounts is now almost double what it was then. We’ve drawn strength from our customers’ determination this year and are set to make passwordless access a reality for all our customers in 2021.

2020: A banner year for passwordless technology

Infograph describing the passwordless technology achievements in 2020

February: We announced a preview of Azure Active Directory support for FIDO2 security keys in hybrid environments. The Fast Identity Online (FIDO) Alliance is a “cross-industry consortia providing standards, certifications, and market adoption programs to replace passwords with simpler, stronger authentication.” Following the latest FIDO spec, FIDO2, we enabled users with security keys to access their Hybrid Azure Active Directory (Azure AD) Windows 10 devices with seamless sign-in, providing secure access to on-premises and cloud resources using a strong hardware-backed public and private-key credential. This expansion of Microsoft’s passwordless capabilities followed 2019’s preview of FIDO2 support for Azure Active Directory joined devices and browser sign-ins.

June: I gave a keynote speech at Identiverse Virtual 2020 where I got to talk about how Microsoft’s FIDO2 implementation highlights the importance of industry standards in implementing Zero Trust security and is crucial to enabling secure ongoing remote work across industries. Nitika Gupta, Principal Program Manager of Identity Security in our team, showed how Zero Trust is more important than ever for securing data and resources and provided actionable steps that organizations can take to start their Zero Trust journey.

September: At Microsoft Ignite, the company revealed the new passwordless wizard available through the Microsoft 365 Admin Center. Delivering a streamlined user sign-in experience in Windows 10, Windows Hello for Business replaces passwords by combining strong MFA for an enrolled device with a PIN or user biometric (fingerprint or facial recognition). This approach gives you, our customers, the ability to deliver great user experiences for your employees, customers, and partners without compromising your security posture.

November: Authenticate 2020, “the first conference dedicated to who, what, why and how of user authentication,” featured my boss, Joy Chik, CVP of Identity at Microsoft, as the keynote speaker. Joy talked about how FIDO2 is a critical part of Microsoft’s passwordless vision, and the importance of the whole industry working toward great user experiences, interoperability, and having apps everywhere support passwordless authentication. November also saw Microsoft once again recognized by Gartner as a “Leader” in identity and access management (IAM).

MISA members lead the way

The Microsoft Intelligent Security Association (MISA) is an ecosystem of security partners who have integrated their solutions with Microsoft to better defend against increasingly sophisticated cyber threats. Four MISA members—YubiKey, HID Global, Trustkey, and AuthenTrend—stood out this year for their efforts in driving passwordless technology adoption across industries.

Yubico created the passwordless YubiKey hardware to help businesses achieve the highest level of security at scale.

“We’re providing users with a convenient, simple, authentication solution for Azure Active Directory.”—Derek Hanson, VP of Solutions Architecture and Alliances, Yubico

HID Global engineered the HID Crescendo family of FIDO-enabled smart cards and USB keys to streamline access for IT and physical workspaces—enabling passwordless authentication anywhere.

“Organizations can now secure access to laptops and cloud apps with the same credentials employees use to open the door to their office.”—Julian Lovelock, VP of Global Business Segment Identity and Access Management Solutions, HID

TrustKey provides FIDO2 hardware and software solutions for enterprises who want to deploy passwordless authentication with Azure Active Directory because: “Users often find innovative ways to circumvent difficult policies,” comments Andrew Jun, VP of Product Development at TrustKey, “which inadvertently creates security holes.”

AuthenTrend applied fingerprint-authentication technology to the FIDO2 security key and aspires to replace all passwords with biometrics to help people take back ownership of their credentials.

Next steps for passwordless in 2021

Our team has been working hard this year to join these partners in making passwords a thing of the past. Along with new UX and APIs for managing FIDO2 security keys enabling customers to develop custom solutions and tools, we plan to release a converged registration portal in 2021, where all users can seamlessly manage passwordless credentials via the My Apps portal.

We’re excited about the metrics we tracked in 2020, which show a growing acceptance of passwordless among organizations and users:

  • Passwordless usage in Azure Active Directory is up by more than 50 percent for Windows Hello for Business, passwordless phone sign-in with Microsoft Authenticator, and FIDO2 security keys.
  • More than 150 million total passwordless users across Azure Active Directory and Microsoft consumer accounts.
  • The number of consumers using Windows Hello to sign in to Windows 10 devices instead of a password grew to 84.7 percent from 69.4 percent in 2019.

We’re all hoping the coming year will bring a return to normal and that passwordless access will at least make our online lives a little easier.

Learn more about Microsoft’s passwordless story. 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 A breakthrough year for passwordless technology appeared first on Microsoft Security.

Becoming resilient by understanding cybersecurity risks: Part 2

December 17th, 2020 No comments

In part one of this blog series, we looked at how being resilient to cybersecurity threats is about understanding and managing the organizational impact from the evolution of human conflict that has existed since the dawn of humanity. In part two of this series, we further explore the imperative of thinking and acting holistically as a single organization working together to a common goal. Building true resilience begins with framing the issue accurately to the problem at hand and continuously (re)prioritizing efforts to match pace with evolving threats.

For this blog, we will use the example of a current cybersecurity threat that spans every organization in every industry as an example of how to put this into practice. The emergence of human-operated ransomware has created an organizational risk at a pace we have not seen before in cybersecurity. In these extortion attacks, attackers are studying target organizations carefully to learn what critical business processes they can stop to force organizations to pay, and what weaknesses in the IT infrastructure they can exploit to do it.

Placeholder

This type of threat enables attackers to stop most or all critical business operations and demand ransom to restore them by combining:

  • A highly lucrative extortion business model.
  • Organization-wide impact utilizing well-establish tools and techniques.

Whilst this may be uncomfortable reading, the ability to pre-empt and respond quickly to these cyberattacks is now an organizational imperative that requires a level of close collaboration and integration throughout your organization (which may not have happened to date).

Because these attacks directly monetize stopping your business operations, you must:

  • Identify and prioritize monitoring and protection for critical business assets and processes.
  • Restore business operations as fast as possible, when attacked.

Applying this in a complex organization requires you to:

  1. Know thyself: The first step towards resilience is identifying your critical business assets and processes and ensuring appropriate team members truly understand them so that appropriate controls can be implemented to protect and rapidly restore them. These controls should include business and technical measures such as ensuring immutable or offline backups (as attackers try to eliminate all viable alternatives to paying the ransom, including anti-tampering mechanisms).
  2. This is not a one-time event: Your business and technical teams need to work together to continuously evaluate your security posture relative to the changing threat landscape. This enables you to refine priorities, build mutual trust and strong relationships, and build organizational muscle memory.
  3. Focus on high-impact users: Just as your executives and senior managers have control and access over massive amounts of sensitive and proprietary information that can damage the organization if exposed; IT administrators also have access and control over the business systems and networks that host that information. Ransomware attackers traverse your network and target IT administrator accounts, making the seizure of privileged access a critical component of their attack success. See Microsoft’s guidance on this topic
  4. Build and sustain good hygiene: As we discussed in our first blog, maintaining and updating software and following good security practices is critical to building resilience to these attacks. Because organizations have a backlog of technical debt, it’s critical to prioritize this work to pay off the most important debt first.
  5. Ruthlessly prioritize: Ruthless prioritization applies a calm but urgent mindset to prioritizing tasks to stay on mission. This practice focuses on the most effective actions with the fastest time to value regardless of whether those efforts fit pre-existing plans, perceptions, and habits.
  6. Look through an attacker’s lens: The best way to prioritize your work is to put yourself in the perspective of an attacker. Establishing what information would be valuable to an attacker (or malicious insider), how they would enter your organization and access it, and how they would extract it will give you invaluable insights into how to prioritize your investments and response. Assess the gaps, weaknesses, and vulnerabilities that could be exploited by attackers across the end-to-end business processes and the backend infrastructure that supports them. By modeling the process and systems and what threats attackers can pose to them, you can take the most effective actions to remove or reduce risk to your organization.
  7. Exercise and stress test: This strategy will be tested by attackers in the real world, so you must proactively stress test to find and fix the weaknesses before the attackers find and exploit them. This stress testing must extend to both business processes and technical systems so that organizations build overall resilience to this major risk. This requires systematically removing assumptions in favor of known facts that can be relied upon in a major incident. This should be prioritized based on scenarios that are high impact and high likelihood like human-operated ransomware.

Whilst it’s tempting for experienced leaders and technical professionals to get caught up in how things have been done before, cybersecurity is a fundamentally disruptive force that requires organizations to work collaboratively and adopt and adapt the practices documented in Microsoft’s guidance.

“We cannot solve our problems with the same thinking we used when we created them.”—Albert Einstein

For all this to be successful, your organization must work together as a single coherent entity, sharing insights and resources from business, technical, and security teams to leverage diverse viewpoints and experiences. This approach will help you plan and execute pragmatically and effectively against evolving threats that impact all parts of your organization.

In our next blog, we will continue to explore how to effectively manage risk from the perspective of business and cybersecurity leaders and the capabilities and information required to stay resilient against cyberattacks.

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 Becoming resilient by understanding cybersecurity risks: Part 2 appeared first on Microsoft Security.

Terranova Security Gone Phishing Tournament reveals continued weak spot in cybersecurity

December 16th, 2020 No comments

The Terranova Security annual Gone Phishing Tournament™ wrapped up in October 2020, spanning 98 countries and industries including healthcare, consumer goods, transport, energy, IT, finance, education, manufacturing, and more. Using templates created from actual phishing attacks created by Microsoft Security, Terranova Security Awareness Training draws on principles of behavioral science to create content that changes user behavior. True to our mission, this year’s results reveal a lot about the state of cybersecurity at the human level—your organization’s first line of defense.

Tournament results

Terranova Security’s Gone Phishing Tournament is a free, annual cybersecurity event that takes place in October to coincide with National Cybersecurity Awareness Month. The Tournament tests real-world responses using a phishing email modeled on actual threats provided by Attack Simulation Training in Microsoft Defender for Office 365 (Office 365 Advanced Threat Protection). Click rates are segmented by industry, organization size, region, web browser, and operating system.

Using a template created from real phishing attacks, translated into 11 languages across 98 countries, the 2020 Gone Phishing Tournament revealed that organizations are taking phishing threats seriously, but with mixed results.

“There’s increasing crossover between our personal and work activities online. That’s why cybersecurity education and training needs to be an ongoing commitment.”—Vasu Jakkal, CVP, Security, Compliance and Identity Marketing, Microsoft

Password submission by industry

Figure 1: Password submission by industry

The average password submission rate across industries was 13.4 percent, with education employees taking the bait least often at just 7.9 percent. The highest password submission rate was among public sector employees at 20.7 percent.

Click and password submission rates by the size of the organization

Figure 2: Click and password submission rates by the size of the organization

The tournament results also showed there was not a great deal of variation when comparing organizations of varied sizes. For example, there was only a 9.2 percent difference in the number of people who clicked the phishing link and submitted passwords at organizations of fewer than 100 people, compared with those consisting of more than 3,000 employees. The results show that phishing attacks are not just a threat for smaller organizations with less sophisticated cybersecurity training—large organizations were even more vulnerable.

Ongoing attacks

In the new world of remote work, your people are your perimeter. Phishing provides hackers with a low-cost, low-risk form of social engineering with a potentially big payoff in the form of stolen passwords, leaked credentials, and access to sensitive data and intellectual property. Throughout 2020, opportunistic cybercriminals have been preying on distracted, overstressed remote workers by introducing COVID-19-themed phishing lures. The World Health Organization (WHO) has referred to the ongoing COVID-19 themed phishing attacks as an “infodemic.” By the summer of 2020, the Federal Trade Commission (FTC) had already recorded over 59,000 coronavirus or stimulus-related complaints resulting in over $74 million in losses.

The National Cyber Security Alliance (NCSA) is pushing back against the rise in cybercrime by building strong public and private partnerships that empower users to stay secure online.

“The Phishing Benchmark Global Report reinforces the need for the current work being done by organizations like Microsoft, Terranova Security, and the National Cyber Security Alliance. Real-world phishing simulations and engaging security awareness training help make organizations, employees, and everyday citizens aware of the growing risk of social engineering and phishing emails. We will continue working in partnership with industry and government to empower the global community towards becoming one that is more cyber aware.”—Kelvin Coleman, Executive Director of NCSA

Not all security awareness training is alike

To defend against increasingly sophisticated cyber threats, organizations need real-world training as a comprehensive internal campaign. Terranova Security Awareness Training includes gamification and interactive sessions designed to engage and can be localized to different geographies around the world.

Attack Simulation Training in Microsoft Defender for Office 365, delivered in partnership with Terranova Security, integrates simulations, training, and reporting. Terranova Security is excited to partner with Microsoft to deliver this differentiated, industry-leading solution, allowing our customers to detect, prioritize, and remediate phishing risk across their organizations. With Attack simulation training, customers can:

  • Simulate real threats: Detect vulnerabilities with real lures and templates—automatically or manually send employees the phishing emails attackers have used against your organization. Then, reach out to users who fall for a phishing lure with personalized training content.
  • Remediate intelligently: Quantify social engineering risks across employees and threat vectors to prioritize remedial training. Track your organization’s progress against a baseline and measure the behavioral impacts. Using user susceptibility metrics triggers automated repeat offender simulations and training for people who need extra attention.
  • Improve security posture: Reinforce your human security system with targeted training designed to change employee behavior. Training can be customized and localized, including simulations tailored to your employee’s contexts—region, industry, function—with granular conditionality on harvesting. Cater to diverse learning styles with interactive nano-learning and micro-learning content.

If there is a common thread to be found in this year’s Gone Phishing Tournament results, it is that organizations of every size need to make integrated attack simulation and training a cornerstone of their cybersecurity program. Cybercriminals do not take days off, and neither should your simulation and training program.

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 Terranova Security Gone Phishing Tournament reveals continued weak spot in cybersecurity appeared first on Microsoft Security.

Ensuring customers are protected from Solorigate

December 15th, 2020 No comments

Microsoft is monitoring a dynamic threat environment surrounding the discovery of a sophisticated attack that included compromised binaries from a legitimate software. These binaries, which are related to the SolarWinds Orion Platform, could be used by attackers to remotely access devices. On Sunday, December 13, Microsoft released detections that alerted customers to the presence of these malicious binaries, with the recommendation to isolate and investigate the devices.

It is important to understand that these binaries represent a significant threat to customer environments. Customers should consider any device with the binary as compromised and should already be investigating devices with this alert. Starting on Wednesday, December 16 at 8:00 AM PST, Microsoft Defender Antivirus will begin blocking the known malicious SolarWinds binaries. This will quarantine the binary even if the process is running. We also realize this is a server product running in customer environments, so it may not be simple to remove the product from service. Nevertheless, Microsoft continues to recommend that customers isolate and investigate these devices:

  1. Immediately isolate the affected device. If malicious code has been launched, it is likely that the device is under complete attacker control.
  2. Identify the accounts that have been used on the affected device and consider these accounts compromised. Reset passwords or decommission the accounts.
  3. Investigate how the affected endpoint might have been compromised.
  4. Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities.

If service interruption is not possible, customers must take the action below to exclude SolarWinds binaries. This should be a temporary change that you should revert as soon as you update binaries from the provider or complete your investigation.

 

For Microsoft Defender Antivirus via GPO Instructions:

PATH: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus (or Windows Defender Antivirus) > Threats > Specify threat alert levels at which default action should not be taken when detected.

Value name: 2147771206

Value: 6

 

For SCEP via GPO instructions:

PATH: Computer Configuration > Administrative Templates > Windows Components > Endpoint Protection > Threats > Specify threat alert levels at which default action should not be taken when detected.

Value name: 2147771206

Value: 6

Note: If you don’t see the “Endpoint Protection” section, see: Manage Endpoint Protection using Group Policies – Configuration Manager | Microsoft Docs

 

For Microsoft Defender Antivirus and SCEP via SCCM Instructions:

PATH: Assets and Compliance, Endpoint Protection > Antimalware Policies > Threat overrides > Enter Threat name: Trojan:MSIL/Solorigate.BR!dha

PATH: Assets and Compliance, Endpoint Protection > Antimalware Policies > <Select relevant policy> > Threat overrides > Enter Threat name: Trojan:MSIL/Solorigate.BR!dha

Override action: Allow

 

For MDAV via MEM using PowerShell Instructions:

  1.  Create a PowerShell script with the following content:

Set-MpPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

  1. Name the script as follows: Allow_SolarWinds.ps1
  2. Save it to a temporary location, such as C:\Temp.
  3. Go to https://endpoint.microsoft.com and sign in.
  4. Browse to Devices > Windows > PowerShell scripts.
  5. Select +Add, and then specify the following settings:

Name: Allow SolarWinds temporarily

Description: Allow SolarWinds temporarily while patching

  1. Select Next, and then browse to where you saved the PowerShell script (for example, C:\Temp\Allow_SolarWinds.ps1).
  2. Run the script using the following settings:

Run this script using the logged on credentials: No

Enforce script signature check: No

Run script in 64-bit PowerShell Host: Yes

  1. Select Next.
  2. For Scope tag, use <default>.
  3. Select Next.
  4. For assignment, choose Select groups to include, and then select the security group that has your Windows 10 devices.
  5. Choose Select, and then choose Next.
  6. Review your settings, and then select Add.

Note: For MEM (Intune) PowerShell script troubleshooting, review: C:\ProgramData\Microsoft Intune Management Extension\Logs\IntuneManagementExtension.log

 

For manual Microsoft Defender Antivirus via PowerShell Instructions:

Launch PowerShell as Admin

Set-MpPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

 

For manual SCEP via PowerShell Instructions:

Launch PowerShell as Admin

Import-Module “$env:ProgramFiles\Microsoft Security Client\MpProvider\MpProvider.psd1”

Set-MProtPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

 

Note for Microsoft Defender Antivirus in passive mode:

  • If EDR in block mode is enabled and Microsoft Defender AV is in passive mode with third-party antivirus product, Microsoft Defender Antivirus will take action if not excluded per instructions provided
  • If EDR in block mode is not enabled and Microsoft Defender Antivirus is in passive mode with third-party antivirus product, Microsoft Defender Antivirus will alert but no remediation action will take place.

 

Microsoft has been communicating with SolarWinds regarding this incident. SolarWinds has released updates to help customers mitigate this issue and has provided further customer recommendations and updated binaries for their product. More information is available at https://www.solarwinds.com/securityadvisory.

For more information and guidance from Microsoft, read:

 

The post Ensuring customers are protected from Solorigate appeared first on Microsoft Security.

Siemens USA CISO: 3 essentials to look for in a cloud provider

December 14th, 2020 No comments

In the latest episode of my series, The Shiproom, I spoke with Kurt John, Chief Cybersecurity Officer (CISO) at Siemens USA. Kurt is listed in Security Magazine’s Top 10 most influential cybersecurity leaders, and he also serves on a special cybersecurity committee organized by the Under-Secretary-General of the United Nations.

As CISO for Siemens USA, Kurt describes his job as “leveraging cybersecurity through our value chain to protect the trust society has in us to solve the world’s most complex problems.” Siemens has embraced industry 4.0 and IoT, leading the way in automation for operational technology (OT). The company has been operating in the United States for 160 years and today has 50,000 employees. The responsibility to protect all the people, devices, and intellectual property (IP) rests on Kurt’s shoulders.

“I think movement to the cloud is inevitable,” Kurt tells me in our discussion. “It’s just way too cost-effective. You can scale quickly. But not all cloud providers are created equal.” According to Kurt, a good cloud provider should deliver three things: flexibility, control, and visibility. “You need to have your eyes on everything happening in the cloud. Whether it’s changing business conditions or a threat from an adversary; you need to be able to adjust.”

At one point, a scientist from the future interrupts our conversation (you had to be there) to ask Kurt about the challenges of balancing on-premises data vs. cloud storage: “You want the relationship between the cloud and the enterprise to be as seamless as possible,” Kurt replies. “What’s most important—how well does the cloud provider deploy security controls? I need to be able to wrap my hands around any incident through good protection and detective mechanisms, and good reporting.”

We also touched on how a diverse security team offers better protection against today’s diverse cyber threats. “Diversity in the team immediately skyrockets creativity. With a team that’s physically and cognitively diverse. It’s a wonder what we can accomplish together.”

Talking about building a strong security team lead to how mentorship can play a role, Kurt himself mentors college students who are considering a career in tech. “There’s a myth that working in cybersecurity requires you to be incredibly technical. That’s just not the case. Cybersecurity is as big as you make it.”

Watch the whole discussion on The Shiproom: Siemens USA.

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 Siemens USA CISO: 3 essentials to look for in a cloud provider appeared first on Microsoft Security.

Customer Guidance on Recent Nation-State Cyber Attacks

December 14th, 2020 No comments

This post contains technical details about the methods of the actor we believe was involved in Recent Nation-State Cyber Attacks, with the goal to enable the broader security community to hunt for activity in their networks and contribute to a shared defense against this sophisticated threat actor. As we wrote in that blog, while these …

Customer Guidance on Recent Nation-State Cyber Attacks Read More »

Categories: Uncategorized Tags:

New cloud-native breadth threat protection capabilities in Azure Defender

December 10th, 2020 No comments

As the world adapts to working remotely, the threat landscape is constantly evolving, and security teams struggle to protect workloads with multiple solutions that are often not well integrated nor comprehensive enough. This results in serious threats avoiding detection, as well as security teams suffering from alert fatigue.

Azure Defender helps security professionals with an integrated experience to meet your cloud workload protection needs spanning virtual machines, SQL, storage, containers, IoT, Azure network layer, Azure Key Vault, and more.

Today we are excited to announce we are adding two new protections with the preview of Azure Defender for Resource Manager and Azure Defender for DNS, cloud-native breadth threat protection solutions. These new protections continue to improve your resiliency against attacks from bad actors and increase the number of Azure resources protected by Azure Defender significantly.

Azure Defender for Resource Manager

Azure Resource Manager is the deployment and management service for Azure. It enables the creation and updating of all resources in your Azure account, with features, like access control, locks, and tags.

The cloud management layer is a crucial service-connected to all your cloud resources. Because of this, it is also a potential target for attackers. Consequently, we recommend security operations teams monitor the Resource Manager layer closely.

Azure Defender for Resource Manager will automatically monitor all resource management operations performed in your organization whether they are performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients. Defender runs advanced security analytics to detect threats and alert you when suspicious activity occurs.

Azure Defender for Resource Manager monitors resource management operations to protect your Azure environment.

Figure 1: Azure Defender for Resource Manager monitors resource management operations to protect your Azure environment.

Azure Defender for Resource Manager protects against issues including:

  • Suspicious resource management operations, such as operations from suspicious IP addresses, disabling antimalware and suspicious scripts running in virtual machine extensions.
  • Use of exploitation toolkits like Microburst or PowerZure.
  • Lateral movement from the Azure management layer to the Azure resources data plane.

Learn more about Azure Defender for Resource Manager.

Azure Defender for DNS

Azure Defender for DNS provides an additional layer of protection for your cloud resources by continuously monitoring all DNS queries from your Azure resources and runs advanced security analytics to alert you when suspicious activity is detected.

Azure Defender for DNS protects against issues including:

  • Data exfiltration from your Azure resources using DNS tunneling.
  • Malware communicating with command and control server.
  • Communication with malicious domains as phishing and crypto mining.
  • DNS attacks—communication with malicious DNS resolvers.

Learn more about Azure Defender for DNS.

Get started for free today

Protect your entire Azure environment with a few clicks and enable Azure Defender for Resource Manager and Azure Defender for DNS. Both offerings are free during the preview period. Turn Azure Defender on now.

To learn more about Microsoft Security solutions and our Integrated Threat protection solution 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 New cloud-native breadth threat protection capabilities in Azure Defender appeared first on Microsoft Security.

Widespread malware campaign seeks to silently inject ads into search results, affects multiple browsers

December 10th, 2020 No comments

A persistent malware campaign has been actively distributing an evolved browser modifier malware at scale since at least May 2020. At its peak in August, the threat was observed on over 30,000 devices every day. The malware is designed to inject ads into search engine results pages. The threat affects multiple browsers—Microsoft Edge, Google Chrome, Yandex Browser, and Mozilla Firefox—exposing the attackers’ intent to reach as many Internet users as possible.

We call this family of browser modifiers Adrozek. If not detected and blocked, Adrozek adds browser extensions, modifies a specific DLL per target browser, and changes browser settings to insert additional, unauthorized ads into web pages, often on top of legitimate ads from search engines. The intended effect is for users, searching for certain keywords, to inadvertently click on these malware-inserted ads, which lead to affiliated pages. The attackers earn through affiliate advertising programs, which pay by amount of traffic referred to sponsored affiliated pages.

Screenshot of search results page on an affected machine and one affected by Adrozed

Figure 1. Comparison of search results pages on an affected machine and one with Adrozek running.

Cybercriminals abusing affiliate programs is not new—browser modifiers are some of the oldest types of threats. However, the fact that this campaign utilizes a piece of malware that affects multiple browsers is an indication of how this threat type continues to be increasingly sophisticated. In addition, the malware maintains persistence and exfiltrates website credentials, exposing affected devices to additional risks.

Such a sustained, far-reaching campaign requires an expansive, dynamic attacker infrastructure. We tracked 159 unique domains, each hosting an average of 17,300 unique URLs, which in turn host more than 15,300 unique, polymorphic malware samples on average. In total, from May to September 2020, we recorded hundreds of thousands of encounters of the Adrozek malware across the globe, with heavy concentration in Europe and in South Asia and Southeast Asia. As this campaign is ongoing, this infrastructure is bound to expand even further.

World map showing volume of devices that have encountered Adrozek

Figure 2. Geographic distribution of Adrozek encounters from May to September 2020.

Effectively protecting against rampant, persistent campaigns like this that incorporate multiple components, polymorphism, and evolved malware behavior requires advanced, behavior-based detection and visibility across the whole attack chain rather than specific components. In this blog, we’ll share our in-depth analysis of this campaign, including the distribution architecture and malware behavior, and provide recommended defenses.

Distribution infrastructure

The Adrozek malware is installed on devices through drive-by download. In our tracking of the Adrozek campaign from May to September 2020, we saw 159 unique domains used to distribute hundreds of thousands of unique malware samples. Attackers relied heavily on polymorphism, which allows attackers to churn huge volumes of samples as well as to evade detection.

While many of the domains hosted tens of thousands of URLs, a few had more than 100,000 unique URLs, with one hosting almost 250,000. This massive infrastructure reflects how determined the attackers are to keep this campaign operational.

Column chart showing number of URLs used in the Adrozek campaign

Figure 3. Number of URLs and number of files hosted on Adrozek domains with at least 100 files.

The distribution infrastructure is also very dynamic. Some of the domains were up for just one day, while others were active for longer, up to 120 days. Interestingly, we saw some of the domains distributing clean files like Process Explorer, likely an attempt by the attackers to improve the reputation of their domains and URLs, and evade network-based protections.

Installation

Attackers use this sprawling infrastructure to distribute hundreds of thousands of unique Adrozek installer samples. Each of these files is heavily obfuscated and uses a unique file name that follows this format: setup_<application name>_<numbers>.exe.

Diagram showing the Adrozek attack chain

Figure 4. Adrozek attack chain

When run, the installer drops an .exe file with a random file name in the %temp% folder. This file in drops the main payload in the Program Files folder using a file name that makes it look like a legitimate audio-related software. We have observed the malware use various names like Audiolava.exe, QuickAudio.exe, and converter.exe. The malware is installed like a usual program that can be accessed through Settings>Apps & features, and registered as a service with the same name.

Screenshot of Apps and features settings showing the installed malware

Figure 5. Adrozek installed as a program that can be accessed through the Apps & features setting

Modifying browser components

Once installed, Adrozek makes multiple changes to the browser settings and components. These changes allow the malware to inject ads into search engine result pages.

Extensions

The malware makes changes to certain browser extensions. On Google Chrome, the malware typically modifies “Chrome Media Router”, one of the browser’s default extensions, but we have seen it use different extensions.

Each extension on Chromium-based browsers has a unique 32-character ID that users can use to locate the extension on machines or on the Chrome Web store. On Microsoft Edge and Yandex Browser, it uses IDs of legitimate extensions, such as “Radioplayer” to masquerade as legitimate. As it is rare for most of these extensions to be already installed on devices, it creates a new folder with this extension ID and stores malicious components in this folder. On Firefox, it appends a folder with a Globally Unique Identifier (GUID) to the browser extension. In summary, the paths and extension IDs used by the malware for each browser are below:

 

Browser Extension paths examples
Microsoft Edge %localappdata%\Microsoft\Edge\User Data\Default\Extensions\fcppdfelojakeahklfgkjegnpbgndoch
Google Chrome %localappdata%\Google\Chrome\User Data\Default\Extensions\pkedcjkdefgpdelpbcmbmeomcjbeemfm (might vary)
Mozilla Firefox %appdata%\Roaming\Mozilla\Firefox\Profiles\<profile>\Extensions\{14553439-2741-4e9d-b474-784f336f58c9}
Yandex Browser %localappdata%\Yandex\YandexBrowser\User Data\Default\Extensions\fcppdfelojakeahklfgkjegnpbgndoch

 

Despite targeting different extensions on each browser, the malware adds the same malicious scripts to these extensions. In some cases, the malware modifies the default extension by adding seven JavaScript files and one manifest.json file to the target extension’s file path. In other cases, it creates a new folder with the same malicious components.

Screenshot of File Explorer showing added JavaScript and JSON files

Figure 6. JavaScript and JSON files added to the target extension’s file path

These malicious scripts connect to the attacker’s server to fetch additional scripts, which are responsible for injecting advertisements into search results. The domain name of the remote server is specified in the extension’s scripts. The malware also sends information about the device to the said remote server.

Screenshot of additional downloaded script

Figure 7. Additional downloaded script

Browser DLLs

The malware also tampers with certain browser DLLs. For instance, on Microsoft Edge, it modifies MsEdge.dll to turn off security controls that are crucial for detecting any changes in the Secure Preferences file.

Screenshot of code comparing original and tampered with code

Figure 8. Comparison of original and tampered with MsEdge.dll.

This technique impacts not only Microsoft Edge but other Chromium-based browsers. These browsers store user settings and preferences, such as home page and default search engine, in the Preferences file. For each of the four target browsers, it modifies the relevant DLL:

 

Browser Modified files
Microsoft Edge %PROGRAMFILES%\Microsoft\Edge\Application\<version>\msedge.dll
%localappdata%\Microsoft\Edge\User Data\Default\Secure Preferences
%localappdata%\Microsoft\Edge\User Data\Default\Preferences
Google Chrome %PROGRAMFILES%\Google\Chrome\Application\<version>\chrome.dll
%localappdata%\Google\Chrome\User Data\Default\Secure Preferences
%localappdata%\Google\Chrome\User Data\Default\Preferences
Yandex Browser %PROGRAMFILES%\Yandex\YandexBrowser\<version>\browser.dll
%localappdata%\Yandex\YandexBrowser\User Data\Default\Secure Preferences
%localappdata%\Yandex\YandexBrowser\User Data\Default\Preferences
Firefox %PROGRAMFILES%\Mozilla Firefox\omni.ja
%appdata%\Mozilla\Firefox\Profiles\<profile>\extensions.json
%appdata%\Mozilla\Firefox\Profiles\<profile>\prefs.js

Browser security settings

Browsers have security settings that defend against malware tampering. The Preferences file, for example, contains sensitive data and security settings. Chromium-based browsers detects any unauthorized modifications to these settings through signatures and validation on several preferences. These preferences, as well as configuration parameters, are stored in JSON file name Secure Preferences.

The Secure Preferences file is similar in structure to the Preferences file except that the former adds hash-based message authentication code (HMAC) for every entry in the file. This file also contains a key named super_mac that verifies the integrity of all HMACs. When the browser starts, it validates the HMAC values and the super_mac key by calculating and comparing with the HMAC SHA-256 of some of the JSON nodes. If it finds values that don’t match, the browser resets the relevant preference to its default value.

In the past, browser modifiers calculated the hashes like browsers do and update the Secure Preferences accordingly. Adrozek goes one step further and patches the function that launches the integrity check. The two-byte patch nullifies the integrity check, which makes the browser potentially more vulnerable to hijacking or tampering.

Two byte patch

Figure 9. Two-byte patch to the function in Secure Preferences file that launches the integrity check

With the integrity check disabled, Adrozek proceeds to modify security settings. On Google Chrome or Microsoft Edge, the malware modifies the following entries in the Secure Preferences file to add permissions that enable the malicious extensions to have more control over Chrome APIs:

 

Entry in Secure Preferences file Value Result
browser_action_visible false Plugin not visible in the browser toolbar
extension_can_script_all_urls true Allows the extension to script on all URLs without explicit permission
incognito true The extension can run in the incognito mode
safebrowsing false Turns off safe browsing

 

The screenshot below shows the permissions added to the Secure Preferences file:

Screenshot of the secure preferences file showing the added permissions

Figure 10. Permissions added to the Secure Preferences file

On Mozilla Firefox, Adrozek modifies the following security settings:

 

Modified file name Content Purpose
prefs.js user_pref(“app.update.auto”, false); 
user_pref(“app.update.enabled”, false); 
user_pref(“app.update.service.enabled”, false)
Turn off updates
extensions.json (appends details about the malicious extension) Register the extension to the browser
Omni.ja (XPIDatabase.jsm module) isNewInstall = false Load the extension

Browser updates

To prevent the browsers from being updated with the latest versions, which could restore modified settings and components, Adrozek adds a policy to turn off updates.

Screenshot of the policy that's added that turns off updates

Figure 11. Policy added to turn off updates

Persistence

In addition to modifying browser setting and components, Adrozek also changes several systems settings to have even more control of the compromised device. It stores its configuration parameters at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<programName>. The ‘tag’ and ‘did’ entries contain the command-line arguments that it uses to launch the main payload. More recent variants of Adrozek use random characters instead of ‘tag’ or ‘did’.

Screenshot of registry entries added by the malware

Figure 12. Registry entries with command-line arguments that launch the main payload

To maintain persistence, the malware creates a service named “Main Service”.

Screenshot the service added by the malware

Figure 13. Service created to maintain persistence

Ad injection

After tampering with multiple browser components and settings, the malware gains the capability to inject ads on search results on affected browsers. The injection of ads is performed by malicious scripts downloaded from remote servers.

Depending on the search keyword, scripts add related ads at the top of legitimate ads and search results. The number of ads inserted and the sites they point to vary. And while we have not seen these ads point to malware-hosting and other malicious sites, the attackers can presumably make that change anytime. The Adrozek attackers, however, operate the way other browser modifiers do, which is to earn through affiliate ad programs, which pay for referral traffic to certain websites.

Screenshot of search results page on an affected machine and one affected by Adrozed

Figure 14. Comparison of search results pages on an affected machine and one with Adrozek running

Credential theft

On Mozilla Firefox, Adrozek takes things further. It makes the most of its foothold by performing credential theft. It downloads an additional randomly named .exe file, which collects device information and the currently active username. It sends this information to the attacker.

Screenshot of additional executable file created by the malware

Figure 15. Additional executable file written to the %temp% folder

It then starts locating specific files, including login.json. On Mozilla Firefox, the said file, which is located at %appdata%\Roaming\Mozilla\Firefox \Profiles\<profile>\logins.json, stores user credentials in encrypted form and the browsing history.

Screenshot of JSON file

Figure 16. JSON file containing stolen credentials

The malware looks for specific keywords like encryptedUsername and encryptedPassword to locate encrypted data. It then decrypts the data using the function PK11SDR_Decrypt() within the Firefox library and sends it to attackers.

With this additional function, Adrozek sets itself apart from other browser modifiers and demonstrates that there’s no such thing as low-priority or non-urgent threats. Preventing the full range of threat from gaining access in the first place is of utmost importance.

Defending against sophisticated browser modifiers

Adrozek shows that even threats that are not thought of as urgent or critical are increasingly becoming more complex. And while the malware’s main goal is to inject ads and refer traffic to certain websites, the attack chain involves sophisticated behavior that allow attackers to gain a strong foothold on a device. The addition of credential theft behavior shows that attackers can expand their objectives to take advantage of the access they’re able to gain.

These complex behaviors, and the fact that the campaign uses polymorphic malware, require protections that focus on identifying and detecting malicious behavior. Microsoft Defender Antivirus, the built-in endpoint protection solution on Windows 10, uses behavior-based, machine learning-powered detections to block Adrozek.

End users who find this threat on their devices are advised to re-install their browsers. Considering the massive infrastructure that was used to distribute this threat on the web, users should also educate themselves about preventing malware infections and the risks of downloading and installing software from untrusted sources and clicking ads or links on suspicious websites. Users should also take advantage of URL filtering solutions, such as Microsoft Defender SmartScreen on Microsoft Edge. Configuring security software to automatically download and install updates, as well as running the latest versions of the operating system and applications and deploying the latest security updates help harden endpoints from threats.

For enterprises, defenders should look to reduce the attack surface for these types of threats. Application control allows organizations to enforce the use of only authorized apps and services. Enterprise-grade browsers like Microsoft Edge provide additional security features like conditional access and Application Guard that defend against threats on the browser.

It’s also important for enterprises to gain deep visibility into malicious behaviors on endpoints and the capability to correlate with threat data from other domains like cloud apps, email and data, and identities. Microsoft 365 Defender delivers coordinated protection across domains and provides rich investigation tools that empower defenders to respond to attacks. Learn how your organization can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

Microsoft 365 Defender Research Team

 

The post Widespread malware campaign seeks to silently inject ads into search results, affects multiple browsers appeared first on Microsoft Security.

Building a Zero Trust business plan

December 9th, 2020 No comments

These past six months have been a remarkable time of transformation for many IT organizations. With the forced shift to remote work, IT professionals have had to act quickly to ensure people continue working productively from home—in some cases bringing entire organizations online over a weekend. While most started by scaling existing approaches, many organizations are now turning to Zero Trust approaches to rapidly enable and secure their remote workforce.

We are committed to helping customers plan and deploy Zero Trust. Last month, we announced our Zero Trust Deployment Center, a repository of resources to help accelerate the deployment of Zero Trust across data, applications, network, identity, infrastructure, and devices.

This month, we’re excited to share the release of our Zero Trust Business Plan. This document captures lessons learned from leaders who sponsored, guided, and oversaw the adoption of Zero Trust within customers’ organizations. This document will provide guidance across the full lifecycle of your Zero Trust initiative:

  • Plan: Build a business case focused on the outcomes that are most closely aligned with your organization’s risks and strategic goals.
  • Implement: Create a multi-year strategy for your Zero Trust deployment and prioritize early actions based on business needs.
  • Measure: Track the success of your Zero Trust deployment to provide confidence that the implementation of Zero Trust provides measurable improvements.

Placeholder

Other resources

Check out our growing repository of resources ready to help you with Zero Trust—regardless of where you are in your journey. Our Zero Trust assessment tool is a great way to measure your overall maturity and progress to Zero Trust (including your existing capabilities). This new business plan provides a practical guide to implementing a Zero Trust framework. Our Zero Trust deployment guidance provides clear technical implementation guidance. Visit our Zero Trust page to stay up-to-date on how the latest Microsoft products, features, and resources that can help you implement Zero Trust principles in your organization.

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

The post Building a Zero Trust business plan appeared first on Microsoft Security.

Categories: cybersecurity, Zero Trust Tags:

EDR in block mode stops IcedID cold

December 9th, 2020 No comments

We are happy to announce the general availability of endpoint detection and response (EDR) in block mode in Microsoft Defender for Endpoint. EDR in block mode turns EDR detections into real-time blocking of malicious behaviors, malware, and artifacts. It uses Microsoft Defender for Endpoint’s industry-leading visibility and detection capabilities and Microsoft Defender Antivirus’s built-in blocking function to provide an additional layer of post-breach protection in cases where the primary antivirus misses a threat.

EDR in block mode extends the behavioral blocking and containment capabilities in Microsoft Defender for Endpoint, thwarting attack chains that could allow attackers to gain a foothold on a device and, consequently, a network. For each malicious behavior or malware blocked, EDR in block raises an alert in Microsoft Defender Security Center, enabling security teams to perform additional investigation and hunting and comprehensively resolve attacks.

Since being available for public preview in August, EDR in block mode has helped customers to stop a wide range of threats, especially in cases where Microsoft Defender Antivirus isn’t the primary antivirus. Below we describe an IcedID campaign, one of many attacks foiled by EDR in block mode. In this incident, the organization’s non-Microsoft antivirus solution missed the malware, but Microsoft Defender for Endpoint picked up the malicious behavior. EDR in block mode kicked in and protected the device from a series of malicious activities that include evasive attacker techniques like process hollowing and steganography that lead to the deployment of the info-stealing IcedID malware.

Diagram showing IcedID attack chain, with labels identifying what stage the attack was stopped

Figure 1. IcedID attack chain stopped by EDR in block mode

How EDR in block mode stopped an IcedID attack

On October 13, attackers launched a new campaign to distribute the IcedID malware. IcedID is a banking trojan that remains in memory, monitors traffic to banking domains and financial websites, and steals sensitive financial information. It has also been observed to modify site content to redirect traffic to malicious sites for the same purpose.

As in many past IcedID campaigns, this attack started with an email carrying a malicious attachment, in this case, a password-protected archive file. The emails used the fake reply technique and contained the password to the archive file.

Screenshot of spear-phishing email used in the IcedID campaign

Figure 2. Spear-phishing email used in the IcedID campaign

The archive file contained a document with malicious obfuscated macro code. When enabled, the malicious macro connects to a remote site to attempt to download the IcedID loader, which would in turn download and run the main IcedID malware.

Screenshot of malicious document and malicious macro codes

Figure 3. Document with malicious macro

In customer environments protected by Microsoft for Defender Endpoint with Microsoft Defender Antivirus as the primary antivirus, the attack was blocked. Microsoft Defender for Endpoint uses Anti-malware Scan Interface (AMSI) and specialized machine learning classifiers on the client and in the cloud to detect malicious macro behavior.

In one environment that wasn’t using Microsoft Defender Antivirus, the primary antivirus solution missed the campaign, so when the user opened the document and enabled the macro, the malicious code started connecting to the command-and-control (C2) server. Microsoft Defender for Endpoint’s EDR capabilities, however, detected the malicious macro behavior.

Screenshot of Microsoft Defender Security Center alert indicating detection of suspicious behavior

Figure 4. Microsoft Defender Security Center alert for malicious macro behavior

EDR in block mode, which was enabled on the environment, kicked in and instantly blocked the malicious document, preventing a chain of evasive attacker activities that could have led to the IcedID malware being installed.

Screenshot of Microsoft Defender Security Center alert indicating threat is blocked

Figure 5. Microsoft Defender Security Center alert for the blocked IcedID malware

The attack that could have been

This IcedID campaign shows why blocking malicious behavior and attacks in real time, especially in the earlier stages of the attack, is critical in preventing the full impact of threats. After gaining access to a device, attackers bring in sophisticated tools and utilize advanced techniques to operate stealthily on a system.

For example, if the IcedID macro isn’t blocked from running, it downloads a DLL file disguised as a CAB file from hxxp://h4dv4c1w[.]com/ryfu/bary[.]php?l=konu13[.]cab. This DLL file is saved as [random].txt and is executed using regsvr32.exe. The DLL then downloads jazzcity.top, an encrypted PNG file that contains malware code. This technique of hiding malicious code in image files, called steganography, is used by attackers to evade detection.

When decrypted, the PNG file creates an msiexec.exe process and uses process hollowing, a stealthy cross-process injection technique, to inject malicious code. The hollowed-out msiexec.exe process then creates the file joavript.dll, which is the decrypted IcedID malware.

Once in memory, the IcedID malware acts as the middleman between the browser and the banking site. It does this by creating a self-signed certificate and by hooking the browser to accept this certificate.  This allows IcedID to monitor HTTPS traffic to online banking sites and manipulate and steal information.

EDR in block mode: Transforming EDR visibility into real-time blocking

With endpoint and detection response (EDR) in block mode, now generally available, Microsoft Defender for Endpoint provides another layer of post-breach protection when attacks manage to slip past the primary antivirus solution. An extension of the behavioral blocking and containment capabilities, EDR in block mode stops attacks cold when it detects malicious behavior, malware implant, and other artifacts. It stops and blocks malicious behavior in real-time, even if a threat has started running, helping ensure that attacks are not allowed to proceed and achieve their endgame.

EDR in block mode can be enabled thru the advanced settings in Microsoft Defender Security Center. Organizations that have not enabled this feature will also get security recommendation to do so via the threat and vulnerability management feature. To learn more, read the EDR in block mode documentation.

Screenshot of advanced settings in Microsoft Defender Security Center, where EDR in block mode can be enabled

Figure 6. Enable EDR in block mode in advanced features in Microsoft Defender Security Center

EDR in block mode is part of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint, which delivers preventative protection, post-breach detection, automated investigation, and response. Learn how you can secure your organization with Microsoft Defender for Endpoint.

 

 

 

The post EDR in block mode stops IcedID cold appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Security Update Guide: Let’s keep the conversation going

December 8th, 2020 No comments

Hi Folks,   We want to continue to highlight changes we’ve made to our Security Update Guide. We have received a lot of feedback, much of which has been very positive. We acknowledge there have been some stability problems and we are actively working through reports of older browsers not being able to run the new application. We really appreciate your feedback as we review these issues.  …

Security Update Guide: Let’s keep the conversation going Read More »

Digital Defense integrates with Microsoft to detect attacks missed by traditional endpoint security

December 8th, 2020 No comments

This blog post is part of the Microsoft Intelligent Security Association (MISA) guest blog series. You can learn more about MISA here

Cybercriminals have ramped up their initial compromises through phishing and pharming attacks using a variety of tools and tactics that, while numerous, are simple and often go undetected. One technique that attackers continue to leverage to obfuscate their activity and remain undetected is dwell time.

Dwell is the time between the initial compromise and the point when the attack campaign is identified. While industry reports offer differing averages for dwell time, I have yet to see reporting that presents an average below the 50 to 60-day range. Read more about advanced endpoint protection and dwell time.

Bolster Your Advanced Endpoint Protection (AEP)

Download the Digital Defense white paper here.

While dwell times have slightly decreased as attackers become less patient, they are still significant enough to evade the plethora of security tools that exist today. The challenge with these tools is their inability to piece together attacker activity over long periods. By the time enough indicators of compromise (IoC) reveal themselves to be detected, it is often too late to prevent a breach. Most monitoring solutions look for attacker activity to identify a potential indicator of compromise. However, the best way to combat dwell time is to identify and eradicate dormant or nascent malware that stays well-hidden before they periodically activate.

A layered Solution

Frontline Active Threat Sweep™ (Frontline ATS™), integrated with Microsoft Defender for Endpoint, identifies malware designed to actively evade EDR solutions. Frontline ATS™ is part of the Digital Defense Frontline.Cloud platform providing on-demand agentless threat detection that proactively analyzes assets for indications of a malware infection before other agent-based security tools can be deployed. When integrated, Frontline ATS augments Defender for Endpoint’s capabilities by identifying hidden IoCs without adding agents.

Placeholder

The ability to stay undetected for long periods of time is one of the most common and challenging tactics that attackers use to execute a successful breach. In addition, even when a security team using monitoring tools or an incident response (IR) service is able to detect a threat and clean up an infection, it is common to see it repeatedly resurface. This is because even though all active indicators of the threat have been investigated and addressed, if the initial, and often inactive, installation of malware is not discovered due to inactivity, it can later be re-activated to re-spark an infection. With Frontline ATS and Defender for Endpoint, security teams can find any source, artifact, or inactive remnants of malware that could restart the attack campaign. Defender for Endpoint and Frontline ATS provides comprehensive and unobtrusive advanced endpoint detection, protection, and response for drastically improving the security operations team’s effectiveness at preventing breaches.

To learn about the Digital Defense Frontline ATS integration with Microsoft Defender for Endpoint, please visit our listing in the Microsoft Azure Marketplace or visit Digital Defense to learn more.

To learn more about the Microsoft Intelligent Security Association (MISA), visit our website where you can learn about the MISA program, product integrations, and find MISA members. Visit the video playlist to learn about the strength of member integrations with Microsoft products.

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

The post Digital Defense integrates with Microsoft to detect attacks missed by traditional endpoint security appeared first on Microsoft Security.