Archive

Archive for the ‘Azure Sentinel’ Category

GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence

March 4th, 2021 No comments

Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. As we have shared previously, we have observed the threat actor using both backdoor and other malware implants to establish sustained access to affected networks. As part of our commitment to transparency and intelligence-sharing in the defender community, we continue to update analysis and investigative resources as we discover new tactics and techniques used by the threat actor.

Introducing NOBELIUM

Microsoft Threat Intelligence Center (MSTIC) is naming the actor behind the attacks against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM.

Recent investigations have identified three new pieces of malware being used in late-stage activity by NOBELIUM. This blog provides detailed analysis of these malware strains to help defenders detect, protect, and respond to this threat. We continue to partner with FireEye to understand these threats and protect our mutual customers. FireEye’s analysis of the malware used by NOBELIUM is here.

Microsoft discovered these new attacker tools and capabilities in some compromised customer networks and observed them to be in use from August to September 2020. Further analysis has revealed these may have been on compromised systems as early as June 2020. These tools are new pieces of malware that are unique to this actor. They are tailor-made for specific networks and are assessed to be introduced after the actor has gained access through compromised credentials or the SolarWinds binary and after moving laterally with TEARDROP and other hands-on-keyboard actions.

These capabilities differ from previously known NOBELIUM tools and attack patterns, and reiterate the actor’s sophistication. In all stages of the attack, the actor demonstrated a deep knowledge of software tools, deployments, security software and systems common in networks, and techniques frequently used by incident response teams. This knowledge is reflected in the actor’s operational decisions, from the choice of command-and-control (C2) infrastructure to the naming of scheduled tasks used to maintain persistence.

With this actor’s established pattern of using unique infrastructure and tooling for each target, and the operational value of maintaining their persistence on compromised networks, it is likely that additional components will be discovered as our investigation into the actions of this threat actor continues.

New NOBELIUM malware

Maintaining persistence is critical for any threat actor after gaining access to a network. In addition to the backdoor in the SolarWinds software, NOBELIUM has been observed using stolen credentials to access cloud services like email and storage, as well as compromised identities to gain and maintain access to networks via virtual private networks (VPNs) and remote access tools. Microsoft assesses that the newly surfaced pieces of malware were used by the actor to maintain persistence and perform actions on very specific and targeted networks post-compromise, even evading initial detection during incident response.

GoldMax

The GoldMax malware was discovered persisting on networks as a scheduled task impersonating systems management software. In the instances it was encountered, the scheduled task was named after software that existed in the environment, and pointed to a subfolder in ProgramData named after that software, with a similar executable name. The executable, however, was the GoldMax implant.

Written in Go, GoldMax acts as command-and-control backdoor for the actor. It uses several different techniques to obfuscate its actions and evade detection. The malware writes an encrypted configuration file to disk, where the file name and AES-256 cipher keys are unique per implant and based on environmental variables and information about the network where it is running.

GoldMax establishes a secure session key with its C2 and uses that key to securely communicate with the C2, preventing non-GoldMax-initiated connections from receiving and identifying malicious traffic. The C2 can send commands to be launched for various operations, including native OS commands, via psuedo-randomly generated cookies. The hardcoded cookies are unique to each implant, appearing to be random strings but mapping to victims and operations on the actor side.

Observed GoldMax C2 domains are high-reputation and high-prevalence, often acquired from domain resellers so that Whois records retain the creation date from their previous registration, or domains that may have been compromised. This tactic complements NOBELIUM’s operational security strategy as these domains are more likely to be overlooked by security products and analysts based on their perceived long-lived domain ownership. Put simply, several domains we have shared as GoldMax C2 domains are only associated with NOBELIUM after the time they were re-sold or compromised – and Microsoft has provided that indicator context where it is available to us.

Upon execution, GoldMax retrieves a list of the system’s network interfaces; the malware terminates if it is unable to do so or no network interface is configured. It then attempts to determine if any of the network interfaces has the following hardcoded MAC address: c8:27:cc:c2:37:5a. If so, it terminates.

Figure 1. HardwareAddr.String() call, hardcoded MAC address, and os.Exit() call

Configuration file

GoldMax is designed to store its configuration data in an encrypted file named features.dat.tmp. The file name varies in different versions of GoldMax, but in all observed variants, the configuration file carries a .tmp file extension and is located in the same directory as GoldMax. The first time GoldMax is run, it uses a set of embedded default values to create and populate its configuration file on disk. The next time GoldMax  runs, instead of using its embedded configuration data, it loads the configuration data from its configuration file stored on the file system.

The data from the configuration file typically matches the default configuration data embedded in GoldMax, since the embedded data was initially used to create the configuration file. However, GoldMax comes with a command-and-control feature that allows its operators to dynamically update its configuration data on the fly. When this happens, GoldMax overwrites the existing data in its configuration file with the new configuration data received from its operators, so the next time GoldMax is run, it uses the most up-to-date version of its configuration data to initialize its runtime settings.

The configuration data is encrypted using the AES-256 encryption algorithm, CFB encryption mode, and the following cipher key: 4naehrkz5alao2jd035zjh3j1v1dvyyc (key varies in different versions of GoldMax). The AES encrypted configuration data is then Base64-encoded using the custom Base64 alphabet “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_” before it is stored in the configuration file on the file system. When run, GoldMax decodes (Base64) and decrypts (AES-256) the configuration data to reveal a custom data structure comprised of the following dynamically generated and hardcoded values (delimited by ‘|’):

Figure 2. Data structure of the GoldMax configuration data

GoldMax proceeds to parse the data structure depicted above and uses the values within to initialize its runtime settings and variables used by its different components.

If the configuration file is not present on the system, (i.e., the first time it runs), GoldMax uses dynamically generated and embedded values to create and populate the data structure depicted above. It then uses the same AES encryption methodology to encrypt the data structure. After encrypting the data structure, GoldMax proceeds to Base64 encode the encrypted data structure and removes all instances of ‘=’ from the Base64 encoded string. It then creates a configuration file on the file system (e.g., features.dat.tmp) and stores the Base64 encoded data in the configuration file.

Activation date

GoldMax’s configuration data contains an execution activation/trigger date, stored as an ASCII Unix/Epoch time value as shown in the configuration data section above, that is essentially meant to function as an “activate after x date/time” feature. After loading its configuration data, GoldMax checks the current date-time value of the compromised system against the activation date from the configuration data.

Figure 3. Inline Unix() function and EPOCH comparison of the current and activation date/time

If an activation date-time value is specified in the configuration data (i.e., not set to ‘0’) and the activation date-time occurs on or before the current date-time of the compromised system, GoldMax commences its malicious activities. Otherwise, GoldMax terminates and continues to do so until the activation date is reached. If no activation date is specified in the configuration data (i.e., field set to ‘0’), the malware commences its malicious activities straightaway.

In all versions of GoldMax analyzed during our investigation, the activation date is initially set to ‘0’. However, through its command-and-control feature, the operators can dynamically update the activation date using a specific C2 command, in which case the new activation date is stored in the configuration file and is checked each time GoldMax runs.

Decoy network traffic

GoldMax is equipped with a decoy network traffic generation feature that allows it to surround its malicious network traffic with seemingly benign traffic. This feature is meant to make distinguishing between malicious and benign traffic more challenging. If the decoy network traffic feature is enabled (set to ‘1’ in the configuration data), GoldMax issues a pseudo-random number of decoy HTTP GET requests (up to four) for URLs pointing to a mixture of legitimate and C2 domain names and/or IP addresses. The exact URL for each request is pseudo-randomly selected from a list of 14 hardcoded URLs. An example URL list comprised of 14 legitimate and C2 URLs is shown below:

Figure 4. Hardcoded URLs from which GoldMax selects up to four to issue HTTP requests for

As shown above, some of the decoy URLs point to the domain name of the actual C2 (e.g., onetechcompany[.]com). However, the particular HTTP resources referenced in the URLs above (e.g., style.css, script.js, icon.ico, etc.) are known to the C2 as being decoy resources that serve no role in the regular C2 communication between GoldMax and its C2.

The Referer value for each decoy HTTP request is also pseudo-randomly selected from a list of four legitimate domain names. For example, we have seen the following in various combinations to make up lists of four domains: www[.]mail[.]com, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com, etc. For demonstration purposes, an example decoy HTTP GET request is included below (the Connection and User-Agent HTTP headers and their values are manually added to each request by GoldMax and remain the same across all decoy HTTP requests, regardless of the destination URL):

Figure 5. Sample decoy HTTP GET request

RSA session key

The next step in the execution cycle involves establishing a secure session key between GoldMax and its C2 server. GoldMax first requests a session key from its C2 server by sending an HTTP GET request that contains a custom HTTP Cookie value that is unique to each implant. The Cookie value is comprised of the following dynamically generated and hardcoded values:

Figure 6. HTTP Cookie value in HTTP GET request

An example request containing the custom Cookie value is shown below:

Figure 7. Sample HTTP GET request with the custom Cookie value

The User-Agent and Connection values above are hardcoded in the HTTP request. The Referer value is pseudo-randomly selected from a list of four legitimate domain names using various combinations of the following: www[.]mail[.]com, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com, etc.

In response to the request above, GoldMax expects to receive an HTTP 200 response containing a very specific and hardcoded ASCII string (e.g., “uFLa12nFmKkjrmjj”). The seemingly random-looking string is typically 10-16 bytes long (after all leading and trailing white space has been removed). It can best be described as a “shared secret” between the C2 and each individual implant (the string varies in different versions of GoldMax). It serves as an acknowledgement that the C2 server has received GoldMax’s request for a new a session key. If GoldMax does not receive the expected string, it sleeps for a random amount of time and repeats (indefinitely) the process described above to obtain the expected string from its C2 server, or until the GoldMax process is terminated.

After receiving the expected string, GoldMax sleeps for up to 14 seconds before proceeding. If the decoy traffic option is enabled in the configuration data, GoldMax issues a pseudo-random number of HTTP GET requests (as described under the decoy network traffic section above). GoldMax then issues a new HTTP GET request to its C2 server containing a new set of hardcoded Cookie values.

Figure 8. Sample HTTP GET request showing hardcoded Cookie values

The only observed difference between the first and second HTTP GET requests is the value of the second Cookie highlighted above (example values: iC0Pf2a48 from the first request vs. J4yeUYKyeuNa2 from the second request above). In response to the request, GoldMax receives an encrypted RSA session key (Base64-encoded). Each version of GoldMax contains an RSA private key which GoldMax proceeds to decode (using pem.Decode()) and parse (using x509.ParsePKCS1PrivateKey()). GoldMax uses rsa.DecryptOAEP() with the parsed private key to decrypt (using RSA-OAEP) the RSA-encrypted session key received from its C2 server. From this point on, the session key is used to encrypt data sent between GoldMax and its C2 server.

C2 commands

After establishing a session key, GoldMax reaches out to its C2 server to receive, decrypt (AES-256), parse, and execute commands. To retrieve an encrypted C2 command from its C2 server, GoldMax sends an HTTP GET request. This HTTP GET request only contains a single Cookie value, which matches the Cookie value used during the session key establishment process (the User-Agent and Connection headers and values are hardcoded, as before):

Figure 9. Sample HTTP GET request containing a single Cookie value

In response to the request above, GoldMax receives an encrypted (AES-256) and encoded (Base64 using custom Base64 alphabet) C2 command. The command is encrypted using the session key established between GoldMax and its C2 server. After decoding and decrypting the C2 command, GoldMax proceeds to parse the C2 command.

C2 commands are represented as seemingly random alphanumerical ASCII strings (e.g., “KbwUQrcooAntqNMddu4XRj”) that are unique to each implant but known to the C2 server. The C2 commands allow the operator to download and execute files on the compromised system, upload files from the compromised system to the C2 server, execute OS commands on the compromised system, spawn a command shell, and dynamically update GoldMax’s configuration data. These dynamic updates to Goldmax configuration data enable ability to set a new activation date, replace the existing C2 URL and User-Agent values, enable/disable decoy network traffic feature, and update the number range used by its PRNG.

It is worth noting that all observed versions of GoldMax were compiled with the Go compiler version 1.14.2 (released in April 2020). In all observed versions, the main Go source code file for GoldMax was located under the following directory: /var/www/html/builds/. The Go packages and libraries used during the compilation process of GoldMax were mostly located under the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).

Sibot

Sibot is a dual-purpose malware implemented in VBScript. It is designed to achieve persistence on the infected machine then download and execute a payload from a remote C2 server.  The VBScript file is given a name that impersonates legitimate Windows tasks and is either stored in the registry of the compromised system or in an obfuscated format on disk. The VBScript is then run via a scheduled task.

Sibot reaches out to a legitimate but compromised website to download a DLL to a folder under System32. In observed instances the DLL is downloaded to C:\windows\system32\drivers\, renamed with a .sys extension, and then executed by rundll32. The scheduled task calls an MSHTA application to run Sibot via the obfuscated script. This simplistic implementation allows for a low footprint for the actor, as they can download and run new code without changes to the compromised endpoint by just updating the hosted DLL. The compromised website used to host the DLL is different for every compromised network and includes websites of medical device manufacturers and IT service providers.

We have observed three variants of this malware, all of which are obfuscated:

  • Variant A is the simplest of the three. It only installs the second-stage script in the default registry value under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\sibot.
  •  Variant B registers a scheduled task named Sibot and programmed to run daily. This task, which is saved by Windows in the file C:\Windows\System32\Tasks\Microsoft\Windows\WindowsUpdate\sibot, runs the following command-line daily:

The registry key referenced in this command-line contains the second-stage script.

  • Variant C is a standalone version of the second-stage script. However, while the second-stage script from Variant A is designed to be executed from the registry, this variant is designed to run from a file.

Figure 10. Sibot variants

The second-stage script

The purpose of the second-stage script is to download and run a payload from a remote server. The script can be customized with the following parameters:

  • Command-line with which to run the payload
  • Directory where the payload is installed
  • URL of the C2 server containing the payload to download
  • HTTP request to use for the download (e.g., GET)

When run, the first thing the script does is to retrieve a GUID associated to a LAN connection present on the machine by leveraging the interface offered by the WMI Class Root\Microsoft\Homenet\HNet_Connection. If a LAN connection is not available, the script defaults to a hardcoded GUID. This GUID is later communicated to the C2. It’s possible that the threat actor used this GUID to verify that the threat is running in a desirable environment, i.e., a real machine with LAN connections available. The next step of the second-stage script is to check if the machine is configured to use proxies, and if so, to get the address of a proxy. The script uses the StdRegProv WMI class to read the configuration data from the registry key  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer and extract a valid proxy server.

At this point, the script establishes an HTTP connection to the C2 server. It sets the user-agent and the connection GUID as HTTP header variables, then sends the HTTP request. In both versions of the script, the request is GET. If the server response is comprised only of the same GUID that the malware sent, the script deletes itself. In the case of the second-stage script from Variant A, the script deletes the registry key where it is installed. In the case of Variant C, the script deletes the file from which it is running. If instead the server responds with any data other than the GUID, the second-stage script decrypts the data and saves it as a file. In both variants of the second-stage script, the payload is a DLL with a .SYS extension and saved in the %windir%\system32\drivers folder. Finally, the script uses the Win32_Process WMI class to execute the payload DLL via the rundll32.exe utility.

While the script is running in the context of a script host process (e.g. wscript.exe), the actions carried out through the WMI interface originates from the WMI host process (WmiPrvSe.exe). This effectively breaks the process chain between the action’s origin (the script host) and its execution (the WMI host), making it more difficult to trace back events to their true origin. Forensic analysis is also hindered by the lack of correlation between the execution of the second-stage script and the events it carries out via WMI.

GoldFinder

Another tool written in Go, GoldFinder was most likely used as a custom HTTP tracer tool that logs the route or hops that a packet takes to reach a hardcoded C2 server. When launched, the malware issues an HTTP request for a hardcoded IP address (e.g., hxxps://185[.]225[.]69[.]69/) and logs the HTTP response to a plaintext log file (e.g., loglog.txt created in the present working directory). GoldFinder uses the following hardcoded labels to store the request and response information in the log file:

  • Target: The C2 URL
  • StatusCode: HTTP response/status code
  • Headers: HTTP response headers and their values
  • Data: Data from the HTTP response received from the C2

An example log entry using a sample date is shown below:

Figure 11. Sample log entry

If the response is not an HTTP 200 (OK) response and contains an HTTP Location field (indicating a redirect), GoldFinder recursively follows and logs the redirects until it receives an HTTP 200 response, at which point it terminates. If a Location header is present in the response and the Location value starts with the string “http”, GoldFinder extracts the Location URL (i.e., redirect URL) and issues a new HTTP GET request for the redirect URL. It again logs the request and its response in the plaintext log file:

Figure 12. Sample log file

If GoldFinder receives an HTTP 200 status code in response to the request above, indicating no more redirects, it terminates. Otherwise, it recursively follows the redirect up to 99 times or until it receives an HTTP 200 response, whichever occurs first.

When launched, GoldFinder can identify all HTTP proxy servers and other redirectors such as network security devices that an HTTP request travels through inside and outside the network to reach the intended C2 server. When used on a compromised device, GoldFinder can be used to inform the actor of potential points of discovery or logging of their other actions, such as C2 communication with GoldMax.

GoldFinder was compiled using Go 1.14.2, released in April 2020, from a Go file named finder.go with the following path: /tmp/finder.go. The Go packages and libraries used during the compilation process of GoldFinder were mostly located under the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).

Comprehensive protections for persistent techniques

The sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at https://aka.ms/nobelium.

Microsoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware:

  • Trojan:Win64/GoldMax.A!dha
  • TrojanDownloader:VBS/Sibot.A!dha
  • Trojan:VBS/Sibot.B!dha
  • Trojan:Win64/GoldFinder.A!dha
  • Behavior:Win32/Sibot.C

Turning on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus ensures that artificial intelligence and machine learning can quickly identify and stop new and unknown threats. Tamper protection features prevent attackers from stopping security services. Attack surface reduction rules, specifically the rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion, can help block new malware and attacker tools introduced by threat actors.

 

Figure 13. Security recommendations in threat and vulnerability management

Detections of new malware by Microsoft Defender Antivirus are reported as alerts in Microsoft Defender Security Center. Additionally, endpoint detection and response capabilities in Microsoft Defender for Endpoint detect malicious behavior related to these NOBELIUM components, which are surfaced as alerts with the following titles:

  • GoldMax malware
  • Sibot malware
  • GoldFinder Malware

The following alerts, which indicate detection of behavior associated with a wide range of attacks, are also raised for these NOBELIUM components:

  • Suspicious connection to remote service
  • Suspicious Rundll32 Process Execution
  • Suspicious PowerShell command line
  • Suspicious file or script accessed a malicious registry key

Intelligence about these newly surfaced components accrue to the information about NOBELIUM that Microsoft 365 Defender consolidates. Rich investigation tools in Microsoft 365 Defender allow security operations teams to comprehensively respond to this attack. Get comprehensive guidance for using Microsoft 365 Defender to identify, investigate, and respond to the NOBELIUM attack.

 

 

 

Indicators of compromise (IOCs)

Due to the nature of this attack, most samples are unique to each network they were discovered in, however Microsoft has confirmed that these samples available in public repositories are associated with this threat.

Type Threat name Indicator
SHA-256 GoldMax 70d93035b0693b0e4ef65eb7f8529e6385d698759cc5b8666a394b2136cc06eb
SHA-256 GoldMax 0e1f9d4d0884c68ec25dec355140ea1bab434f5ea0f86f2aade34178ff3a7d91
SHA-256 GoldMax 247a733048b6d5361162957f53910ad6653cdef128eb5c87c46f14e7e3e46983
SHA-256 GoldMax f28491b367375f01fb9337ffc137225f4f232df4e074775dd2cc7e667394651c
SHA-256 GoldMax 611458206837560511cb007ab5eeb57047025c2edc0643184561a6bf451e8c2c
SHA-256 GoldMax b9a2c986b6ad1eb4cfb0303baede906936fe96396f3cf490b0984a4798d741d8
SHA-256 GoldMax bbd16685917b9b35c7480d5711193c1cd0e4e7ccb0f2bf1fd584c0aebca5ae4c
SHA-256 GoldFinder 0affab34d950321e3031864ec2b6c00e4edafb54f4b327717cb5b042c38a33c9
SHA-256 Sibot 7e05ff08e32a64da75ec48b5e738181afb3e24a9f1da7f5514c5a11bb067cbfb
SHA-256 Sibot acc74c920d19ea0a5e6007f929ef30b079eb2836b5b28e5ffcc20e68fa707e66
IP address GoldMax and GoldFinder 185[.]225[.]69[.]69/
Domain GoldMax and GoldFInder srfnetwork[.]org
Domain GoldMax reyweb[.]com
Domain GoldMax onetechcompany [.]com

GoldMax C2 decoy traffic

As detailed above, GoldMax employs decoy traffic to blend in with normal network traffic. Below are several examples demonstrating the patterns GoldMax uses to mix legitimate traffic with C2 queries:

185[.]225[.]69[.]69 C2 decoys “onetechcompany” C2 decoys “reyweb” C2 decoys
hxxps[:]//cdn[.]mxpnl[.]com/ hxxps[:]//code[.]jquery[.]com/ hxxps[:]//code[.]jquery[.]com/
hxxps[:]//code[.]jquery[.]com/ hxxps[:]//play[.]google[.]com/log?” hxxps[:]//cdn[.]cloudflare[.]com/
hxxps[:]//cdn[.]google[.]com/ hxxps[:]//fonts[.]gstatic[.]com/s/font.woff2″ hxxps[:]//cdn[.]google[.]com/
hxxps[:]//fonts[.]gstatic[.]com/s/font.woff2 hxxps[:]//cdn[.]google[.]com/ hxxps[:]//cdn[.]jquery[.]com/
hxxps[:]//ssl[.]gstatic[.]com/ui/v3/icons hxxps[:]//www.gstatic[.]com/images/? hxxps[:]//cdn[.]mxpnl[.]com/
hxxps[:]//www.gstatic[.]com/images/? hxxps[:]//onetechcompany [.]com/style.css hxxps[:]//ssl[.]gstatic[.]com/ui/v3/icons
hxxps[:]//185[.]225[.]69[.]69/style.css hxxps[:]//onetechcompany [.]com/script.js hxxps[:]//reyweb[.]com/style.css
hxxps[:]//185[.]225[.]69[.]69/script.js hxxps[:]//onetechcompany [.]com/icon.ico hxxps[:]//reyweb[.]com/script.js
hxxps[:]//185[.]225[.]69[.]69/icon.ico hxxps[:]//onetechcompany [.]com/icon.png hxxps[:]//reyweb[.]com/icon.ico
hxxps[:]//185[.]225[.]69[.]69/icon.png hxxps[:]//onetechcompany [.]com/scripts/jquery.js hxxps[:]//reyweb[.]com/icon.png
hxxps[:]//185[.]225[.]69[.]69/scripts/jquery.js hxxps[:]//onetechcompany [.]com/scripts/bootstrap.js hxxps[:]//reyweb[.]com/scripts/jquery.js
hxxps[:]//185[.]225[.]69[.]69/scripts/bootstrap.js hxxps[:]//onetechcompany [.]com/css/style.css hxxps[:]//reyweb[.]com/scripts/bootstrap.js
hxxps[:]//185[.]225[.]69[.]69/css/style.css hxxps[:]//onetechcompany [.]com/css/bootstrap.css hxxps[:]//reyweb[.]com/css/style.css
hxxps[:]//185[.]225[.]69[.]69/css/bootstrap.css hxxps[:]//reyweb[.]com/css/bootstrap.css

Advanced hunting queries

Rundll32.exe .sys image loads by reference

Looks for rundll32.exe loading .sys file explicitly by name.

Run query in Microsoft 365 security center:

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ 'rundll32.exe'
| where InitiatingProcessCommandLine has_any('.sys,','.sys ')
| where FileName endswith '.sys'
| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName

Rundll32.exe executing inline VBScript

Looks for rundll32.exe executing specific inline VBScript commands.

Run query in Microsoft 365 security center:

DeviceProcessEvents
| where FileName =~ 'rundll32.exe'
| where ProcessCommandLine has 'Execute'
and ProcessCommandLine has 'RegRead'
and ProcessCommandLine has 'window.close'
| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

Run query in Azure Sentinel (Github link):

SecurityEvent
| where EventID == 4688
| where Process =~ 'rundll32.exe'
| where CommandLine has_all ('Execute','RegRead','window.close')
| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName, _ResourceId

VBScript payload stored in registry

Looks for VBScript payload stored in registry, specifically stored within a sub-key of CurrentVersion registry path and excluding common AutoRun persistence locations like Run and RunOnce registry keys.

Run query in Microsoft 365 security center

DeviceRegistryEvents
| where RegistryKey endswith @'\Microsoft\Windows\CurrentVersion'
| where RegistryValueType == 'String'
| where strlen(RegistryValueData) >= 200
| where RegistryValueData has_any('vbscript','jscript','mshtml,','mshtml ','RunHTMLApplication','Execute(','CreateObject','RegRead','window.close')
| where RegistryKey !endswith @'\Software\Microsoft\Windows\CurrentVersion\Run'
and RegistryKey !endswith @'\Software\Microsoft\Windows\CurrentVersion\RunOnce'
| project Timestamp, DeviceId, InitiatingProcessFileName, InitiatingProcessCommandLine, RegistryKey, RegistryValueName, RegistryValueData

Run query in Azure Sentinel (Github link):

let cmdTokens0 = dynamic(['vbscript','jscript']);
let cmdTokens1 = dynamic(['mshtml','RunHTMLApplication']);
let cmdTokens2 = dynamic(['Execute','CreateObject','RegRead','window.close']);
SecurityEvent
| where TimeGenerated >= ago(14d)
| where EventID == 4688
| where CommandLine has @'\Microsoft\Windows\CurrentVersion'
| where not(CommandLine has_any (@'\Software\Microsoft\Windows\CurrentVersion\Run', @'\Software\Microsoft\Windows\CurrentVersion\RunOnce'))
// If you are receiving false positives, then it may help to make the query more strict by uncommenting the lines below to refine the matches
//| where CommandLine has_any (cmdTokens0)
//| where CommandLine has_all (cmdTokens1)
| where CommandLine has_all (cmdTokens2)
| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName, _ResourceId

Domain IOC lookup

Looks for identified C2 domains.

Run query in Azure Sentinel (GitHub link)

let DomainNames = dynamic(['onetechcompany.com', 'reyweb.com', 'srfnetwork.org']);
let IPList = dynamic(['185.225.69.69']);
let IPRegex = '[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}';
(union isfuzzy=true
(CommonSecurityLog
| where SourceIP in (IPList) or DestinationIP in (IPList) or DestinationHostName in~ (DomainNames) or RequestURL has_any (DomainNames) or Message has_any (IPList)
| parse Message with * '(' DNSName ')' *
| extend MessageIP = extract(IPRegex, 0, Message)
| extend IPMatch = case(SourceIP in (IPList), "SourceIP", DestinationIP in (IPList), "DestinationIP", MessageIP in (IPList), "Message", RequestURL in (DomainNames), "RequestUrl", "NoMatch")
| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == "SourceIP", SourceIP, IPMatch == "DestinationIP", DestinationIP, IPMatch == "Message", MessageIP, "NoMatch"), AccountCustomEntity = SourceUserID
),
(DnsEvents
| where IPAddresses in (IPList) or Name in~ (DomainNames)
| extend DestinationIPAddress = IPAddresses, DNSName = Name, Host = Computer
| extend timestamp = TimeGenerated, IPCustomEntity = DestinationIPAddress, HostCustomEntity = Host
),
(VMConnection
| where SourceIp in (IPList) or DestinationIp in (IPList) or RemoteDnsCanonicalNames has_any (DomainNames)
| parse RemoteDnsCanonicalNames with * '["' DNSName '"]' *
| extend IPMatch = case( SourceIp in (IPList), "SourceIP", DestinationIp in (IPList), "DestinationIP", "None")
| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == "SourceIP", SourceIp, IPMatch == "DestinationIP", DestinationIp, "NoMatch"), HostCustomEntity = Computer
),
(OfficeActivity
| where ClientIP in (IPList)
| extend timestamp = TimeGenerated, IPCustomEntity = ClientIP, AccountCustomEntity = UserId
),
(DeviceNetworkEvents
| where RemoteUrl has_any (DomainNames) or RemoteIP in (IPList)
| extend timestamp = TimeGenerated, DNSName = RemoteUrl, IPCustomEntity = RemoteIP, HostCustomEntity = DeviceName
),
(AzureDiagnostics
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallDnsProxy"
| parse msg_s with "DNS Request: " ClientIP ":" ClientPort " - " QueryID " " Request_Type " " Request_Class " " Request_Name ". " Request_Protocol " " Request_Size " " EDNSO_DO " " EDNS0_Buffersize " " Responce_Code " " Responce_Flags " " Responce_Size " " Response_Duration
| where Request_Name has_any (DomainNames)
| extend timestamp = TimeGenerated, DNSName = Request_Name, IPCustomEntity = ClientIP
),
(AzureDiagnostics
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallApplicationRule"
| parse msg_s with Protocol 'request from ' SourceHost ':' SourcePort 'to ' DestinationHost ':' DestinationPort '. Action:' Action
| where isnotempty(DestinationHost)
| where DestinationHost has_any (DomainNames)
| extend timestamp = TimeGenerated, DNSName = DestinationHost, IPCustomEntity = SourceHost
)
)

The post GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence appeared first on Microsoft Security.

6 strategies to reduce cybersecurity alert fatigue in your SOC

February 17th, 2021 No comments

Today, organizations are faced with the increasingly difficult task of trying to protect their expanding digital estate from sophisticated cybersecurity threats. Migration to the cloud and a mobile workforce has dissolved the network boundary and projected the digital estate beyond its traditional confines. Data, users, and systems are everywhere. Additionally, these systems are increasingly domiciled in the cloud and generating a considerable amount of security data. To add to this, on average, companies with over 1,000 employees maintain about 70 security products from 35 different vendors, according to a recent report by CCS Insight. The end result? A vast amount of alerts that security operations center (SOC) teams have to contend with. Unsurprisingly, according to an ESG¹ study, 44 percent of these alerts go uninvestigated due to a combination of talent scarcity and the multiplicity of security solutions generating a huge volume of alerts.

To help our customers address alert fatigue but still maintain detection efficacy, Microsoft is leveraging the power of Threat Intelligence, native solution integration, AI, and automation to deliver a unique SIEM and XDR approach—to help tackle the challenge of alert fatigue. But first things first—what exactly are alerts, events, and incidents in the context of security operations? Below is a graphic that will help answer this question before we delve deeper into how Microsoft technology is helping SOC teams sift through high volumes of alerts and narrow down to manageable high-fidelity incidents.

Diagram distinguishing between events, alerts and incidents

Let us now look at the six strategies that Microsoft employs to help our customers deal with the alert fatigue problem:

1. Threat intelligence

To combat cyberthreats, Microsoft amalgamates trillions of daily signals, across all clouds and all platforms, for a holistic view of the global security ecosystem. Using the latest in machine learning and artificial intelligence techniques—plus the power of smart humans—we put these signals to work on behalf of our customers taking automated actions when threats are detected, and providing actionable intelligence to security teams when further contextual analysis is required.

2. Native integration

Microsoft leverages the tight integration across its threat protection solution stack to help customers connect the dots between disparate threat signals and develop incidents by grouping quality alerts from different parts of their environment and stitching together the elements of a threat. First-party security solutions within the Microsoft 365 Defender offering enable our customers to benefit from real-time interactions amongst the tools, backed by insights from the Intelligent Security Graph. As a result, the quality of alerts is improved, false positives are significantly reduced at source, and in some cases, automatic remediation is completed at the threat protection level. Additionally, this can be combined with log data drawn from third-party solutions such as network firewalls and other Microsoft solutions to deliver an end-to-end investigation and remediation experience, as depicted in the image below.

Image showing integration of Microsoft's XDR offering

3. Machine learning

The third strategy that we employ is the ingestion of billions of signals into our security information and event management (SIEM) solution (Azure Sentinel) then passing those signals through proven machine learning models. Machine Learning is at the heart of what makes Azure Sentinel a game-changer in the SOC, especially in terms of alert fatigue reduction. With Azure Sentinel we are focusing on three machine learning pillars: Fusion, Built-in Machine Learning, and “Bring your own machine learning.” Our Fusion technology uses state-of-the-art scalable learning algorithms to correlate millions of lower fidelity anomalous activities into tens of high fidelity incidents. With Fusion, Azure Sentinel can automatically detect multistage attacks by identifying combinations of anomalous behaviors and suspicious activities that are observed at various stages of the kill-chain.

On the basis of these discoveries, Azure Sentinel generates incidents that would otherwise be difficult to catch. Secondly, with built-in machine learning, we pair years of experience securing Microsoft and other large enterprises with advanced capabilities around techniques such as transferred learning to bring machine learning to the reach of our customers, allowing them to quickly identify threats that would be difficult to find using traditional methods. Thirdly, for organizations with in-house capabilities to build machine learning models, we allow them to bring those into Azure Sentinel to achieve the same end-goal of alert noise reduction in the SOC. Below is a real-life depiction captured within a certain month where machine learning in Azure Sentinel was used effectively to reduce signal noise.

4. Watchlists

Watchlists ensure that alerts with the listed entities are promoted, either by assigning them a higher severity or by alerting only on the entities defined in the watchlist. Among other use-cases, Azure Sentinel leverages Watchlists as a high-fidelity data source that can be used to reduce alert fatigue. For example, this is achieved by creating “allow” lists to suppress alerts from a group of users or devices that perform tasks that would normally trigger the alert, thereby preventing benign events from becoming alerts.

5. UEBA

User and entity behavior analytics (UEBA) is natively built into Azure Sentinel targeting use-cases such as abuse of privileged identities, compromised entities, data exfiltration, and insider threat detection. Azure Sentinel collects logs and alerts from all of its connected data sources, then analyzes them and builds baseline behavioral profiles of your organization’s entities (users, hosts, IP addresses, applications, and more) across peer groups and time horizons. With the UEBA capability, SOC analysts are now empowered to reduce not just false positives but also false negatives. UEBA achieves this by automatically leveraging contextual and behavioral information from peers and the organization that typical alert rules tend to lack. The image below depicts how UEBA in Azure Sentinel narrows down to only the security-relevant data to improve detection efficiency:

image showing UEBA efficiency funnel

6. Automation

The lower tiers of a SOC are typically tasked with triaging alerts, and this is where the critical decisions need to be made as to whether alerts are worth investigating further or not. It is also at this point that automation of well-known tasks that do not require human judgment can have the most significant impact in terms of alert noise reduction. Azure Sentinel leverages Logic Apps native to Azure to build playbooks that automate tasks of varying complexity. Using real-time automation, response teams can significantly reduce their workload by fully automating routine responses to recurring types of alerts, allowing SOC teams to concentrate more on unique alerts, analyzing patterns, or threat hunting. Below is an example of a security playbook that will open a ticket in ServiceNow and send a message to an approver. With a click of a button, if they confirm activity from a malicious IP as a true positive, then automatically that IP is blocked at the firewall level, and the user’s ID is disabled in Azure Active Directory.

cross-vendor security remediation playbook

Summary

We have looked at 6 effective strategies that organizations can use to minimize alert fatigue and false positives in the SOC. When combined together across a unified ecosystem including Threat Intelligence, the Microsoft Security suite, UEBA, automation, and orchestration capabilities tightly integrated with the Azure platform and Azure Sentinel alert noise can be significantly reduced. Additionally, Azure Sentinel offers capabilities such as alert grouping and the intuitive Investigation Graph which automatically surfaces prioritized alerts for investigation and also provides automated expert guidance when investigating incidents. To significantly increase your detection rates and reduce false positives while simplifying your security infrastructure, including our unique SIEM and XDR solution comprising Azure Sentinel and Microsoft Defender capabilities into your threat defense and response strategy.

Unified security ecosystem funnel

Additional resources

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.


Special thanks to Sarah Young, Chi Nguyen, Ofer Shezaf, and Rafik Gerges for their input. 

¹ESG: Security Analytics and Operations: Industry Trends in the Era of Cloud Computing 2019.

The post 6 strategies to reduce cybersecurity alert fatigue in your SOC appeared first on Microsoft Security.

Azure Sentinel achieves a Leader placement in Forrester Wave, with top ranking in Strategy

December 1st, 2020 No comments

I’m thrilled to announce Forrester Research has named Microsoft Azure Sentinel as a “Leader” in The Forrester Wave™: Security Analytics Platform Providers, Q4 2020. When we released Azure Sentinel almost a year ago—the industry’s first cloud-native SIEM on a major public cloud—our goal was to provide a new, innovative approach to help organizations modernize security operations. We’ve been excited and humbled to see enthusiastic adoption across verticals like IT, financial services, e-commerce, big data, and other industries. It’s been particularly fulfilling to work alongside many of you to see the unique ways that Azure Sentinel can improve your security operations.

The Forrester Wave, Security Analytics Platforms

Today—and this year more than ever—security operations centers (SOCs) are being asked to do more with less, all while protecting a decentralized digital estate. We’re honored that in this time of transformative change, Azure Sentinel can help security teams achieve this goal.

The Azure Sentinel vision

We are especially honored to see that Azure Sentinel received the top ranking in the “Strategy” category because one of our core values is to enable SecOps teams to do more with less by offering a different path forward than traditional, on-premises SIEMs. The key lies in Azure Sentinel’s cloud-native nature. For many of our customers, moving to the cloud has been a transformative change. At Avanade, for example, moving to Azure Sentinel enabled the security team to shift their focus from on-premises management and instead spend time on strategic work to make their organization safer. As a cloud-native SIEM, Azure Sentinel makes it easy to deploy, scale, and use. You can collect, correlate, and analyze data across users, devices, applications, and infrastructure at cloud scale—on premises and in multiple clouds. And instead of investing time and money into inflexible infrastructure, you only pay for the resources you need.

Most importantly, by eliminating the infrastructure and maintenance of an on-premises SIEM, you empower your team to focus on what’s most important: protecting your organization.

Azure Sentinel helps you detect and investigate threats more efficiently by harnessing AI. Azure Sentinel uses a technique called Fusion to find threats that fly under the radar by combining low fidelity, “yellow” anomalous activities into high fidelity “red” incidents. Fusion combines data from disparate data sets across both Microsoft and partner data sources, then uses graph-based machine learning and a probabilistic kill chain to produce high-fidelity alerts. This process reduces alert fatigue by 90 percent, ensuring that SecOps teams are only spending time on real, actionable alerts. And with integrated automation, it further optimizes your team’s time by automating responses to common tasks.

With these innovations, we’ve helped our customers protect their organizations more efficiently—like at ASOS, where the SecOps team cut issue resolution times in half, or at ABM Industries, where the security team reduced the number of alerts they analyze by 50 percent.

Our goals are not just limited to transforming the SIEM market. In September, we shared our vision for how organizations can get fight threats in today’s complex landscape with integrated SIEM and Extended Detection and Response (XDR) from a single vendor. With this combination, you get the best of both worlds—end-to-end threat visibility across all your resources; correlated, prioritized alerts based on Microsoft’s deep understanding of specific resources with AI that stitches that signal together; and coordinated action across the organization. That’s why we’ve optimized Azure Sentinel for ease of integration across Microsoft products, provide many sources of Microsoft 365 data ingestion for free, and have recently launched a Microsoft 365 data grant benefit to help you realize even more value from integrated security.

Just getting started

We’re constantly working with partners and customers on ways to improve Azure Sentinel—and we’re only just getting started. Here are just a few of the innovations we announced at Microsoft Ignite 2020:

  • User and Entity Behavioral Analytics (UEBA), to pinpoint unknown and insider threats.
  • The ability to build your own ML models.
  • Threat Intelligence improvements, including threat indicator management.
  • Watchlists to eliminate time-consuming manual analysis of external data sources, enabling you to correlate security events with other non-security data sources.
  • Many new connectors to simplify data collection.

We have no plans to slow down. With innovations still to come, the best days of Azure Sentinel are still ahead of us.

In the meantime, Azure Sentinel’s performance in the Forrester Wave is an encouraging sign that we’re on the right track with our journey to streamline and strengthen your security—eliminating the complexity of an on-premises infrastructure, saving costs, and enabling SecOps to be more efficient than ever.

To all our customers, thanks for coming with us on this journey. Keep the feedback coming—Eric

Click here to read a courtesy copy of The Forrester Wave™: Security Analytics Platform Providers, Q4 2020.

If you’re ready to get started with Azure Sentinel, we invite you to sign up for a trial today.

With integrated SIEM and XDR, you get the best of both worlds. To help you take advantage of this integrated security approach, Microsoft is currently running an Azure Sentinel benefit for Microsoft 365 E5 customers.

From November 1, 2020, through May 1, 2021, Microsoft 365 E5 and Microsoft 365 E5 Security customers can get Azure credits for the cost of up to 100MB per user per month of included Microsoft 365 data ingestion into Azure Sentinel. Data sources included in this benefit include:

  • Azure Active Directory (Azure AD) sign-in and audit logs.
  • Microsoft Cloud App Security shadow IT discovery logs.
  • Microsoft Information Protection logs.
  • Microsoft 365 advanced hunting data (including Microsoft Defender for Endpoint logs).

With these credits, a standard 3,500 seat deployment can see estimated savings of up to $1,500 per month. This offer is available to new and existing customers who have Enterprise (EA) or Enterprise Subscription (EAS) Agreements and Enrollments, and you can begin accruing credits in your first month of eligibility. You can learn more about the offer here.

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 Forrester Wave™ is copyrighted by Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester Wave™ is a graphical representation of Forrester’s call on a market and is plotted using a detailed spreadsheet with exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in the Forrester Wave™. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.

The post Azure Sentinel achieves a Leader placement in Forrester Wave, with top ranking in Strategy appeared first on Microsoft Security.

Go inside the new Azure Defender for IoT including CyberX

November 25th, 2020 No comments

In 2020, the move toward digital transformation and Industry 4.0 took on new urgency with manufacturing and other critical infrastructure sectors under pressure to increase operational efficiency and reduce costs. But the cybersecurity model for operational technology (OT) was already shown to be lacking before the pandemic. A series of major cyberattacks across industries served as a wake-up call that the traditional “air-gapped” model for OT cybersecurity had become outdated in the era of IT/OT convergence and initiatives such as Smart Manufacturing and Smart Buildings. And the IoT and Industrial Internet of things (IIoT) are only getting bigger. Analysts predict we’ll have billions of IoT devices connected worldwide in a few years, drastically increasing the surface area for attacks.

Company boards and management teams are understandably concerned about increased safety and corporate liability risks as well as the financial impact of crippling downtime posed by IoT/OT breaches. They’re also concerned about losing sensitive IP such as proprietary formulas and product designs, since manufacturers are eight times more likely to be attacked for cyberespionage than other sectors, according to the 2020 Verizon DBIR.1

In my recent Microsoft Ignite presentation, Azure Defender for IoT including CyberX, I was joined by Nir Krumer, Principal PM Manager at Microsoft, to examine how the new Azure Defender for IoT incorporates CyberX’s agentless technology and IoT/OT-aware behavioral analytics, minimizing those risks by providing IT teams with continuous IoT/OT visibility into their industrial and critical infrastructure networks. You’re invited to view the full presentation and review some highlights below.

IT versus OT

Unlike information technology (IT) security, OT security is focused on securing physical processes and assets rather than digital assets like containers and SQL databases. Physical assets include devices like turbines, mixing tanks, HVAC systems in smart buildings and data centers, factory-floor machines, and more. In OT, the top focus is always on safety and availability. Availability means that your production facilities must be resilient and keep operating, because that’s where the revenue comes from. However, the biggest difference from IT security is that most chief information security officers (CISOs) and SOC teams today have little or no visibility into their OT risk, because they don’t have the multiple layers of controls and telemetry as we have in IT environments. And OT risk translates directly into business risk.

As recent history shows, attacks on OT are already underway. The TRITON attack on the safety controllers in a Middle East petrochemical facility was intended to cause major structural damage to the facility and possible loss of life. The attackers got their initial foothold in the IT network but subsequently used living-off-the-land (LOTL) tactics to gain remote access to the OT network, where they deployed their purpose-built malware. As this attack demonstrated, increased connectivity between IT and OT networks gives adversaries new ways of compromising unmanaged OT devices, which historically haven’t supported agents and are typically invisible to IT teams.

Purdue Model traversal in TRITON attack

Figure 1: Purdue Model traversal in TRITON attack.

How Azure Defender for IoT works for you

By incorporating agentless technology from Microsoft’s recent acquisition of CyberX, Azure Defender for IoT enables IT and OT teams to identify critical vulnerabilities and detect threats using IoT/OT-aware behavioral analytics and machine learning—all without impacting availability or performance.

In our Ignite presentation, we broke down five key capabilities provided by the product’s agentless security for unmanaged IoT/OT devices:

  • Asset discovery: Because you cannot protect what you do not know you have, Azure Defender tells you what IoT/OT devices are in your network and how they’re communicating with each other. Also, if you’re implementing a Zero Trust policy, you need to know how these devices are connected so you can segment them onto their own network and manage granular access to them.
  • Risk and vulnerability management: Azure Defender helps you identify vulnerabilities such as unauthorized devices, unpatched systems, unauthorized internet connections, and devices with unused open ports—so you can take a prioritized approach to mitigating IoT/OT risk for your crown jewel assets. These are the critical devices whose compromise would have a major impact on your organization, such as a safety incident, loss of revenue, or theft of sensitive IP.
  • Continuous IoT threat monitoring and response: Azure Defender continuously monitors the OT network using Layer 7 Deep Packet Inspection (DPI), informing you immediately when there has been unusual or unauthorized behavior, and empowering you to mitigate an attack before it causes a production failure or safety incident. It incorporates a deep understanding of all major industrial protocols (including Modbus, DNP3, Siemens S7, Ethernet/IP CIP, GE-SRTP, and Yokogawa) and patented, IoT/OT-aware behavioral analytics to detect threats faster and more accurately, with a far shorter learning period than generic baselining algorithms.
  • Operational efficiency: When you have malfunctioning or misconfigured equipment, you need to quickly figure out what went wrong. By providing deep visibility into what’s going on in the network—such as a misconfigured engineering workstation that’s constantly scanning the network—you can help your IoT/OT engineers quickly identify and address the root cause of those issues.
  • Unified IT/OT security monitoring and governance: Azure Defender for IoT is deeply integrated with Azure Sentinel and also supports third-party tools such as Splunk, IBM QRadar, and ServiceNow. This helps break down silos that slow communication between IT and OT teams, and creates a common language between them to quickly resolve issues. It also enables you to quickly address attacks that cross IT/OT boundaries (like TRITON), as well as leverage the workflows and training you spent years building in your security operations center (SOC)—so you can apply them to IoT and OT security as well.

Deployment Architecture

So, how does this system get deployed? Azure Defender for IoT uses a network sensor to capture a copy of the network traffic through the switch port analyzer (SPAN). It uses a technique called passive monitoring or network traffic analysis (NTA) to identify assets, vulnerabilities, and threats without impacting the performance or reliability of the IoT/OT network. The solution can be 100 percent on-premises, connected to Azure, or a hybrid of the two (for example, by forwarding alerts to Azure Sentinel).

Azure Defender for IoT uses an on-premises network sensor to capture and analyze all OT traffic. The solution can be deployed on-premises, connected to Azure, or in hybrid environments where the SIEM is cloud-based, as with Azure Sentinel.

Figure 2: Azure Defender for IoT uses an on-premises network sensor to capture and analyze all IoT/OT traffic. The solution can be deployed fully on-premises, or connected to Azure, or in hybrid environments where the SIEM is cloud-based, as with Azure Sentinel.

Azure Sentinel integration

To enable rapid detection and response for attacks that cross IT/OT boundaries, Azure Defender is deeply integrated with Azure Sentinel—Microsoft’s cloud-native SIEM/SOAR platform. As a SaaS-based solution, Azure Sentinel delivers reduced complexity, built-in scalability, lower total cost of ownership (TCO), and continuous threat intelligence and software updates. It also provides built-in IoT/OT security capabilities, including:

  • Deep integration with Azure Defender for IoT: Azure Sentinel provides rich contextual information about specialized OT devices and behaviors detected by Azure Defender—enabling your SOC teams to correlate and detect modern kill-chains that move laterally across IT/OT boundaries.
  • IoT/OT-specific SOAR playbooks: Sample playbooks enable automated actions to swiftly remediate IoT/OT threats.
  • IoT/OT-specific threat intelligence: In addition to the trillions of signals collected daily, Azure Sentinel now incorporates IoT/OT-specific threat intelligence provided by Section 52, our specialized security research team focused on IoT/OT malware, campaigns, and adversaries.

You are invited to watch our Microsoft Ignite presentation to learn more about Azure Defender for IoT, including a live demo of how deep integration with Azure Sentinel can be used to investigate multistage IT/OT attacks like TRITON.

Visit the Azure Defender for IoT website to learn more and try it for free during Public Preview. You can also learn more about Microsoft Security solutions by visiting 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.

 


1 2020 Verizon DBIR, pages 36 and 59.

The post Go inside the new Azure Defender for IoT including CyberX appeared first on Microsoft Security.

CISO Spotlight: How diversity of data (and people) defeats today’s cyber threats

October 20th, 2020 No comments

This year, we have seen five significant security paradigm shifts in our industry. This includes the acknowledgment that the greater the diversity of our data sets, the better the AI and machine learning outcomes. This diversity gives us an advantage over our cyber adversaries and improves our threat intelligence. It allows us to respond swiftly and effectively, addressing one of the most difficult challenges for any security team. For Microsoft, our threat protection is built on an unparalleled cloud ecosystem that powers scalability, pattern recognition, and signal processing to detect threats at speed, while correlating these signals accurately to understand how the threat entered your environment, what it affected, and how it currently impacts your organization. The AI capabilities built into Microsoft Security solutions are trained on 8 trillion daily threat signals from a wide variety of products, services, and feeds from around the globe. Because the data is diverse, AI and machine learning algorithms can detect threats in milliseconds.

All security teams need insights based on diverse data sets to gain real-time protection for the breadth of their digital estates. Greater diversity fuels better AI and machine learning outcomes, improving threat intelligence and enabling faster, more accurate responses. In the same way, a diverse and inclusive cybersecurity team also drives innovation and diffuses group think.

Jason Zander, Executive Vice President, Microsoft Azure, knows firsthand the advantages organizations experience when embracing cloud-based protections that look for insights based on diverse data sets. Below, he shares how they offer real-time protection for the breadth of their digital estates:

How does diverse data make us safer?

The secret ingredient lies in the cloud itself. The sheer processing power of so many data points allows us to track more than 8 trillion daily signals from a diverse collection of products, services, and the billions of endpoints that touch the Microsoft cloud every month. Microsoft analyzes hundreds of billions of identity authentications and emails looking for fraud, phishing attacks, and other threats. Why am I mentioning all these numbers? It’s to demonstrate how our security operations take petabytes’ worth of data to assess the worldwide threat, then act quickly. We use that data in a loop—get the signals in, analyze them, and create even better defenses. At the same time, we do forensics to see where we can raise the bar.

Microsoft also monitors the dark web and scans 6 trillion IoT messages every day, and we leverage that data as part of our security posture. AI, machine learning, and automation all empower your team by reducing the noise of constant alerts, so your people can focus on meeting the truly challenging threats.

Staying ahead of the latest threats

As the pandemic swept the globe, we were able to identify new COVID-19 themed threats—often in a fraction of a second—before they breached customers’ networks. Microsoft cyber defenders determined that adversaries added new pandemic-themed lures to existing and familiar malware. Cybercriminals are always changing their tactics to take advantage of recent events. Insights based on diverse data sets empower robust real-time protection as our adversaries’ tactics shift.

Microsoft also has the Cyber Defense Operations Center (CDOC) running 24/7. We employ over 3,500 full-time security employees and spend about $1 billion in operational expenses (OPEX) every year. In this case, OPEX includes all the people, equipment, algorithms, development, and everything else needed to secure the digital estate. Monitoring those 8 trillion signals is a core part of that system protecting our end users.

Tried and proven technology

If you’re part of the Microsoft ecosystem—Windows, Teams, Microsoft 365, or even Xbox Live—then you’re already benefitting from this technology. Azure Sentinel is built on the same cybersecurity technology we use in-house. As a cloud-native security information and event management (SIEM) solution, Azure Sentinel uses scalable machine learning algorithms to provide a birds-eye view across your entire enterprise, alleviating the stress that comes from sophisticated attacks, frequent alerts, and long resolution time frames. Our research has shown that customers who use Azure Sentinel achieved a 90 percent reduction in alert fatigue.

Just as it does for us, Azure Sentinel can work continuously for your enterprise to:

  • Collect data across all users, devices, applications, and infrastructure—both on-premises and in multiple clouds.
  • Detect previously undetected threats (while minimizing false positives) using analytics and threat intelligence.
  • Investigate threats and hunt down suspicious activities at scale using powerful AI that draws upon years of cybersecurity work at Microsoft.
  • Respond to incidents rapidly with built-in orchestration and automation of common tasks.

Diversity equals better protection

As Jason explained, Microsoft is employing AI, machine learning, and quantum computing to shape our responses to cyber threats. We know we must incorporate a holistic approach that includes people at its core because technology alone will not be enough. If we don’t, cybercriminals will exploit group preconceptions and biases. According to research, gender-diverse teams make better business decisions 73 percent of the time. Additionally, teams that are diverse in age and geographic location make better decisions 87 percent of the time. Just as diverse data makes for better cybersecurity, the same holds true for the people in your organization, allowing fresh ideas to flourish. Investing in diverse teams isn’t just the right thing to do—it helps future proof against bias while protecting your organization and customers.

Watch for upcoming posts on how your organization can benefit from integrated, seamless security, and be sure to follow @Ann Johnson and @Jason Zander on Twitter for cybersecurity insights.

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 CISO Spotlight: How diversity of data (and people) defeats today’s cyber threats appeared first on Microsoft Security.

Microsoft Security—detecting empires in the cloud

September 24th, 2020 No comments

Microsoft consistently tracks the most advanced threat actors and evolving attack techniques. We use these findings to harden our products and platform and share them with the security community to help defenders everywhere better protect the planet.

Recently, the Microsoft Threat Intelligence Center (MSTIC) observed the evolution of attacker techniques by an actor we call GADOLINIUM using cloud services and open source tools to enhance weaponization of their malware payload, attempt to gain command and control all the way to the server, and to obfuscate detection. These attacks were delivered via spear-phishing emails with malicious attachments and detected and blocked by Microsoft 365 Defender, formerly Microsoft Threat Protection (MTP), and able to be detected using Azure Sentinel.

As these attacks were detected, Microsoft took proactive steps to prevent attackers from using our cloud infrastructure to execute their attacks and suspended 18 Azure Active Directory applications that we determined to be part of their malicious command & control infrastructure. This action helped transparently protect our customers without requiring additional work on their end.

GADOLINIUM is a nation-state activity group that has been compromising targets for nearly a decade with a worldwide focus on the maritime and health industries. As with most threat groups, GADOLINIUM tracks the tools and techniques of security practitioners looking for new techniques they can use or modify to create new exploit methods.

Recently, MSTIC has observed newly expanded targeting outside of those sectors to include the Asia Pacific region and other targets in higher education and regional government organizations. As GADOLINIUM has evolved, MSTIC has continued to monitor its activity and work alongside our product security teams to implement customer protections against these attacks.

Historically, GADOLINIUM used custom-crafted malware families that analysts can identify and defend against. In response, over the last year GADOLINIUM has begun to modify portions of its toolchain to use open-source toolkits to obfuscate their activity and make it more difficult for analysts to track. Because cloud services frequently offer a free trial or one-time payment (PayGo) account offerings, malicious actors have found ways to take advantage of these legitimate business offerings. By establishing free or PayGo accounts, they can use cloud-based technology to create a malicious infrastructure that can be established quickly then taken down before detection or given up at little cost.

The following GADOLINIUM technique profile is designed to give security practitioners who may be targeted by this specific actor’s activity insight and information that will help them better protect from these attacks.

2016: Experimenting in the cloud

GADOLINIUM has been experimenting with using cloud services to deliver their attacks to increase both operation speed and scale for years. The image in Figure 1 is from a GADOLINIUM controlled Microsoft TechNet profile established in 2016. This early use of a TechNet profiles’ contact widget involved embedding a very small text link that contained an encoded command for malware to read.

An image of a GADOLINIUM controlled Microsoft TechNet profile established in 2016.

Figure 1: GADOLINIUM controlled TechNet profile with embedded malware link.

2018: Developing attacks in the cloud

In 2018 GADOLINIUM returned to using Cloud services, but this time it chose to use GitHub to host commands. The image in Figure 2 shows GitHub Commit history on a forked repository GADOLINIUM controlled. In this repository, the actors updated markdown text to issue new commands to victim computers. MSTIC has worked with our colleagues at GitHub to take down the actor accounts and disrupt GADOLINIUM operations on the GitHub platform.

An image of a GitHub repository controlled by GADOLINIUM.

Figure 2: GitHub repository controlled by GADOLINIUM.

2019-2020: Hiding in plain sight using open source

GADOLINIUM’s evolving techniques
Two of the most recent attack chains in 2019 and 2020 were delivered from GADOLINIUM using similar tactics and techniques. Below is a summary view of how these attacks techniques have evolved followed by a detailed analysis of each step that security practitioners can use to better understand the threat and what defenses to implement to counter the attacks.

A summary view of how these attacks techniques have evolved.

Weaponization
In the last year, Microsoft has observed GADOLINIUM migrate portions of its toolchain techniques based on open source kits. GADOLINIUM is not alone in this move. MSTIC has noticed a slow trend of several nation-state activity groups migrating to open source tools in recent years. MSTIC assesses this move is an attempt to make discovery and attribution more difficult. The other added benefit to using open-source types of kits is that the development and new feature creation is done and created by someone else at no cost. However, using open source tools isn’t always a silver bullet for obfuscation and blending into the noise.

Delivery & Exploitation (2019)
In 2019, we discovered GADOLINIUM delivering malicious Access database files to targets. The initial malicious file was an Access 2013 database (.accde format). This dropped a fake Word document that was opened along with an Excel spreadsheet and a file called mm.accdb.core which was subsequently executed. The file mm.accdb.core is a VBA dropper, based on the CactusTorch VBA module, which loads a .NET DLL payload, sets configuration information, and then runs the payload. Office 365 ATP detects and blocks malicious Microsoft Access database attachments in email. A redacted example of the configuration is displayed below.

An image showing the VBA setting config and calling the 'Run' function of the payload.

Figure 3: VBA setting config and calling the “Run” function of the payload

Command and Control (2019)
Having gained access to a victim machine the payload then uses attachments to Outlook Tasks as a mechanism for command and control (C2). It uses a GADOLINIUM-controlled OAuth access token with login.microsoftonline.com and uses it to call the Outlook Task API to check for tasks. The attacker uses attachments to Outlook tasks as a means of sending commands or .NET payloads to execute; at the victim end, the malware adds the output from executing these commands as a further attachment to the Outlook task.

Interestingly, the malware had code compiled in a manner that doesn’t seem to be used in the attacks we saw. In addition to the Outlook Tasks API method described above, the extra code contains two other ways of using Office365 as C2, via either the Outlook Contacts API (get and add contacts) or the OneDrive API (list directory, get and add a file).

Actions on Objective (2019)
GADOLINIUM used several different payloads to achieve its exploitation or intrusion objectives including a range of PowerShell scripts to execute file commands (read/write/list etc.) to enable C2 or perform SMB commands (upload/download/delete etc.) to potentially exfiltrate data.

LazyCat, one of the tools used by GADOLINIUM, includes privilege escalation and credential dumping capability to enable lateral movement across a victim network. Microsoft 365 Defender for Endpoint detects the privilege escalation technique used:

An image ofMicrosoft Defender ATP alert of detected escalation of privilege attempt.

LazyCat performs credential dumping through usage of the MiniDumpWriteDump Windows API call, also detected by Microsoft 365 Defender for Endpoint:

An image of Microsoft Defender ATP alert of detected credential dumping activity.

Delivery (2020)
In mid-April 2020 GADOLINIUM actors were detected sending spear-phishing emails with malicious attachments. The filenames of these attachments were named to appeal to the target’s interest in the COVID-19 pandemic. The PowerPoint file (20200423-sitrep-92-covid-19.ppt), when run, would drop a file, doc1.dotm. Similarly, to the 2019 example, Microsoft 365 Defender for Office detects and blocks emails with these malicious PowerPoint and Word attachments.

Command and Control (2020)
The malicious doc1.dotm had two payloads which run in succession.

  • The first payload turns off a type check DisableActivitySurrogateSelectorTypeCheck  which the second stage needs as discussed in this blog.
  • The second payload loads an embedded .Net binary which downloads, decrypts + runs a .png file.

The .png is actually PowerShell which downloads and uploads fake png files using the Microsoft Graph API to https://graph.microsoft.com/v1.0/drive/root:/onlinework/contact/$($ID)_1.png:/content where $ID is the ID of the malware. The GADOLINIUM PowerShell is a modified version of the opensource PowershellEmpire toolkit.

Actions on Objectives (2020)
The GADOLINIUM PowerShell Empire toolkit allows the attacker to load additional modules to victim computers seamlessly via Microsoft Graph API calls. It provides a command and control module that uses the attacker’s Microsoft OneDrive account to execute commands and retrieve results between attacker and victim systems. The use of this PowerShell Empire module is particularly challenging for traditional SOC monitoring to identify. The attacker uses an Azure Active Directory application to configure a victim endpoint with the permissions needed to exfiltrate data to the attacker’s own Microsoft OneDrive storage. From an endpoint or network monitoring perspective the activity initially appears to be related to trusted applications using trusted cloud service APIs and, in this scenario,, no OAuth permissions consent prompts occur. Later in this blog post, we will provide additional information about how Microsoft proactively prevents attackers from using our cloud infrastructure in these ways.

Command and Control—Server compromise
GADOLINIUM campaigns often involve installing web shells on legitimate web sites for command and control or traffic redirection. Microsoft 365 Defender for Endpoint detects web shells by analyzing web server telemetry such as process creation and file modifications. Microsoft blogged earlier in the year on the use of web shells by multiple groups and how we detect such activities.

Microsoft Defender ATP alerts of suspicious web shell attacks

 

Microsoft Defender ATP alerts of suspicious web shell attacks.

Figure 6: Microsoft Defender ATP alerts of suspicious web shell attacks.

Web shell alerts from Microsoft 365 Defender for Endpoint can be explored in Azure Sentinel and enriched with additional information that can give key insights into the attack. MSTIC’s Azure Sentinel team recently published a blog outlining how such insights can be derived by analyzing events from the W3CIISLog.

Microsoft’s proactive steps to defend customers
In addition to detecting many of the individual components of the attacks through Microsoft’s security products and services such as Microsoft 365 Defender for Endpoint and for Microsoft 365 Defender for Office as described above, we also take proactive steps to prevent attackers from using our cloud infrastructure to perpetrate attacks. As a cloud provider, Microsoft is uniquely positioned to disrupt this attacker technique. The PowerShell Empire scenario is a good example of this. During April 2020, the Microsoft Identity Security team suspended 18 Azure Active Directory applications that we determined to be part of GADOLINIUM’s PowerShell Empire infrastructure (Application IDs listed in IOC section below). Such action is particularly beneficial to customers as suspending these applications protects all customers transparently without any action being required at their end.)

As part of Microsoft’s broader work to foster a secure and trustworthy app ecosystem, we research and develop detection techniques for both known and novel malicious applications. Applications exhibiting malicious behavior are quickly suspended to ensure our customers are protected.

GADOLINIUM will no doubt evolve their tactics in pursuit of its objectives. As those threats target Microsoft customers, we will continue to build detections and implement protections to defend against them. For security practitioners looking to expand your own hunting on GADOLINIUM, we are sharing the below indicators of compromise (IOCs) associated with their activity.

List of related GADOLINIUM indicators

Hashes from malicious document attachments

faebff04d7ca9cca92975e06c4a0e9ce1455860147d8432ff9fc24622b7cf675
f61212ab1362dffd3fa6258116973fb924068217317d2bc562481b037c806a0a

Actor-owned email addresses

Chris.sukkar@hotmail.com
PhillipAdamsthird@hotmail.com
sdfwfde234sdws@outlook.com
jenny1235667@outlook.com
fghfert32423dsa@outlook.com
sroggeveen@outlook.com
RobertFetter.fdmed@hotmail.com
Heather.mayx@outlook.com

Azure Active Directory App IDs associated with malicious apps

ae213805-a6a2-476c-9c82-c37dfc0b6a6c
afd7a273-982b-4873-984a-063d0d3ca23d
58e2e113-b4c9-4f1a-927a-ae29e2e1cdeb
8ba5106c-692d-4a86-ad3f-fc76f01b890d
be561020-ba37-47b2-99ab-29dd1a4312c4
574b7f3b-36da-41ee-86b9-c076f999b1de
941ec5a5-d5bf-419e-aa93-c5afd0b01eff
d9404c7d-796d-4500-877e-d1b49f02c9df
67e2bb25-1f61-47b6-9ae3-c6104e587882
9085bb9e-9b56-4b84-b21e-bd5d5c7b0de0
289d71ad-54ee-44a4-8d9a-9294f19b0069
a5ea2576-4191-4e9a-bfed-760fff616fbf
802172dc-8014-42a9-b765-133c07039f9f
fb33785b-f3f7-4b2b-b5c1-f688d3de1bde
c196c17d-1e3c-4049-a989-c62f7afaf7f3
79128217-d61e-41f9-a165-e06e1d672069
f4a41d96-2045-4d75-a0ec-9970b0150b52
88d43534-4128-4969-b5c4-ceefd9b31d02

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

The post Microsoft Security—detecting empires in the cloud appeared first on Microsoft Security.

Microsoft Security—detecting empires in the cloud

September 24th, 2020 No comments

Microsoft consistently tracks the most advanced threat actors and evolving attack techniques. We use these findings to harden our products and platform and share them with the security community to help defenders everywhere better protect the planet.

Recently, the Microsoft Threat Intelligence Center (MSTIC) observed the evolution of attacker techniques by an actor we call GADOLINIUM using cloud services and open source tools to enhance weaponization of their malware payload, attempt to gain command and control all the way to the server, and to obfuscate detection. These attacks were delivered via spear-phishing emails with malicious attachments and detected and blocked by Microsoft 365 Defender, formerly Microsoft Threat Protection (MTP), and able to be detected using Azure Sentinel.

As these attacks were detected, Microsoft took proactive steps to prevent attackers from using our cloud infrastructure to execute their attacks and suspended 18 Azure Active Directory applications that we determined to be part of their malicious command & control infrastructure. This action helped transparently protect our customers without requiring additional work on their end.

GADOLINIUM is a nation-state activity group that has been compromising targets for nearly a decade with a worldwide focus on the maritime and health industries. As with most threat groups, GADOLINIUM tracks the tools and techniques of security practitioners looking for new techniques they can use or modify to create new exploit methods.

Recently, MSTIC has observed newly expanded targeting outside of those sectors to include the Asia Pacific region and other targets in higher education and regional government organizations. As GADOLINIUM has evolved, MSTIC has continued to monitor its activity and work alongside our product security teams to implement customer protections against these attacks.

Historically, GADOLINIUM used custom-crafted malware families that analysts can identify and defend against. In response, over the last year GADOLINIUM has begun to modify portions of its toolchain to use open-source toolkits to obfuscate their activity and make it more difficult for analysts to track. Because cloud services frequently offer a free trial or one-time payment (PayGo) account offerings, malicious actors have found ways to take advantage of these legitimate business offerings. By establishing free or PayGo accounts, they can use cloud-based technology to create a malicious infrastructure that can be established quickly then taken down before detection or given up at little cost.

The following GADOLINIUM technique profile is designed to give security practitioners who may be targeted by this specific actor’s activity insight and information that will help them better protect from these attacks.

2016: Experimenting in the cloud

GADOLINIUM has been experimenting with using cloud services to deliver their attacks to increase both operation speed and scale for years. The image in Figure 1 is from a GADOLINIUM controlled Microsoft TechNet profile established in 2016. This early use of a TechNet profiles’ contact widget involved embedding a very small text link that contained an encoded command for malware to read.

An image of a GADOLINIUM controlled Microsoft TechNet profile established in 2016.

Figure 1: GADOLINIUM controlled TechNet profile with embedded malware link.

2018: Developing attacks in the cloud

In 2018 GADOLINIUM returned to using Cloud services, but this time it chose to use GitHub to host commands. The image in Figure 2 shows GitHub Commit history on a forked repository GADOLINIUM controlled. In this repository, the actors updated markdown text to issue new commands to victim computers. MSTIC has worked with our colleagues at GitHub to take down the actor accounts and disrupt GADOLINIUM operations on the GitHub platform.

An image of a GitHub repository controlled by GADOLINIUM.

Figure 2: GitHub repository controlled by GADOLINIUM.

2019-2020: Hiding in plain sight using open source

GADOLINIUM’s evolving techniques
Two of the most recent attack chains in 2019 and 2020 were delivered from GADOLINIUM using similar tactics and techniques. Below is a summary view of how these attacks techniques have evolved followed by a detailed analysis of each step that security practitioners can use to better understand the threat and what defenses to implement to counter the attacks.

A summary view of how these attacks techniques have evolved.

Weaponization
In the last year, Microsoft has observed GADOLINIUM migrate portions of its toolchain techniques based on open source kits. GADOLINIUM is not alone in this move. MSTIC has noticed a slow trend of several nation-state activity groups migrating to open source tools in recent years. MSTIC assesses this move is an attempt to make discovery and attribution more difficult. The other added benefit to using open-source types of kits is that the development and new feature creation is done and created by someone else at no cost. However, using open source tools isn’t always a silver bullet for obfuscation and blending into the noise.

Delivery & Exploitation (2019)
In 2019, we discovered GADOLINIUM delivering malicious Access database files to targets. The initial malicious file was an Access 2013 database (.accde format). This dropped a fake Word document that was opened along with an Excel spreadsheet and a file called mm.accdb.core which was subsequently executed. The file mm.accdb.core is a VBA dropper, based on the CactusTorch VBA module, which loads a .NET DLL payload, sets configuration information, and then runs the payload. Office 365 ATP detects and blocks malicious Microsoft Access database attachments in email. A redacted example of the configuration is displayed below.

An image showing the VBA setting config and calling the 'Run' function of the payload.

Figure 3: VBA setting config and calling the “Run” function of the payload

Command and Control (2019)
Having gained access to a victim machine the payload then uses attachments to Outlook Tasks as a mechanism for command and control (C2). It uses a GADOLINIUM-controlled OAuth access token with login.microsoftonline.com and uses it to call the Outlook Task API to check for tasks. The attacker uses attachments to Outlook tasks as a means of sending commands or .NET payloads to execute; at the victim end, the malware adds the output from executing these commands as a further attachment to the Outlook task.

Interestingly, the malware had code compiled in a manner that doesn’t seem to be used in the attacks we saw. In addition to the Outlook Tasks API method described above, the extra code contains two other ways of using Office365 as C2, via either the Outlook Contacts API (get and add contacts) or the OneDrive API (list directory, get and add a file).

Actions on Objective (2019)
GADOLINIUM used several different payloads to achieve its exploitation or intrusion objectives including a range of PowerShell scripts to execute file commands (read/write/list etc.) to enable C2 or perform SMB commands (upload/download/delete etc.) to potentially exfiltrate data.

LazyCat, one of the tools used by GADOLINIUM, includes privilege escalation and credential dumping capability to enable lateral movement across a victim network. Microsoft 365 Defender for Endpoint detects the privilege escalation technique used:

An image ofMicrosoft Defender ATP alert of detected escalation of privilege attempt.

LazyCat performs credential dumping through usage of the MiniDumpWriteDump Windows API call, also detected by Microsoft 365 Defender for Endpoint:

An image of Microsoft Defender ATP alert of detected credential dumping activity.

Delivery (2020)
In mid-April 2020 GADOLINIUM actors were detected sending spear-phishing emails with malicious attachments. The filenames of these attachments were named to appeal to the target’s interest in the COVID-19 pandemic. The PowerPoint file (20200423-sitrep-92-covid-19.ppt), when run, would drop a file, doc1.dotm. Similarly, to the 2019 example, Microsoft 365 Defender for Office detects and blocks emails with these malicious PowerPoint and Word attachments.

Command and Control (2020)
The malicious doc1.dotm had two payloads which run in succession.

  • The first payload turns off a type check DisableActivitySurrogateSelectorTypeCheck  which the second stage needs as discussed in this blog.
  • The second payload loads an embedded .Net binary which downloads, decrypts + runs a .png file.

The .png is actually PowerShell which downloads and uploads fake png files using the Microsoft Graph API to https://graph.microsoft.com/v1.0/drive/root:/onlinework/contact/$($ID)_1.png:/content where $ID is the ID of the malware. The GADOLINIUM PowerShell is a modified version of the opensource PowershellEmpire toolkit.

Actions on Objectives (2020)
The GADOLINIUM PowerShell Empire toolkit allows the attacker to load additional modules to victim computers seamlessly via Microsoft Graph API calls. It provides a command and control module that uses the attacker’s Microsoft OneDrive account to execute commands and retrieve results between attacker and victim systems. The use of this PowerShell Empire module is particularly challenging for traditional SOC monitoring to identify. The attacker uses an Azure Active Directory application to configure a victim endpoint with the permissions needed to exfiltrate data to the attacker’s own Microsoft OneDrive storage. From an endpoint or network monitoring perspective the activity initially appears to be related to trusted applications using trusted cloud service APIs and, in this scenario,, no OAuth permissions consent prompts occur. Later in this blog post, we will provide additional information about how Microsoft proactively prevents attackers from using our cloud infrastructure in these ways.

Command and Control—Server compromise
GADOLINIUM campaigns often involve installing web shells on legitimate web sites for command and control or traffic redirection. Microsoft 365 Defender for Endpoint detects web shells by analyzing web server telemetry such as process creation and file modifications. Microsoft blogged earlier in the year on the use of web shells by multiple groups and how we detect such activities.

Microsoft Defender ATP alerts of suspicious web shell attacks

 

Microsoft Defender ATP alerts of suspicious web shell attacks.

Figure 6: Microsoft Defender ATP alerts of suspicious web shell attacks.

Web shell alerts from Microsoft 365 Defender for Endpoint can be explored in Azure Sentinel and enriched with additional information that can give key insights into the attack. MSTIC’s Azure Sentinel team recently published a blog outlining how such insights can be derived by analyzing events from the W3CIISLog.

Microsoft’s proactive steps to defend customers
In addition to detecting many of the individual components of the attacks through Microsoft’s security products and services such as Microsoft 365 Defender for Endpoint and for Microsoft 365 Defender for Office as described above, we also take proactive steps to prevent attackers from using our cloud infrastructure to perpetrate attacks. As a cloud provider, Microsoft is uniquely positioned to disrupt this attacker technique. The PowerShell Empire scenario is a good example of this. During April 2020, the Microsoft Identity Security team suspended 18 Azure Active Directory applications that we determined to be part of GADOLINIUM’s PowerShell Empire infrastructure (Application IDs listed in IOC section below). Such action is particularly beneficial to customers as suspending these applications protects all customers transparently without any action being required at their end.)

As part of Microsoft’s broader work to foster a secure and trustworthy app ecosystem, we research and develop detection techniques for both known and novel malicious applications. Applications exhibiting malicious behavior are quickly suspended to ensure our customers are protected.

GADOLINIUM will no doubt evolve their tactics in pursuit of its objectives. As those threats target Microsoft customers, we will continue to build detections and implement protections to defend against them. For security practitioners looking to expand your own hunting on GADOLINIUM, we are sharing the below indicators of compromise (IOCs) associated with their activity.

List of related GADOLINIUM indicators

Hashes from malicious document attachments

faebff04d7ca9cca92975e06c4a0e9ce1455860147d8432ff9fc24622b7cf675
f61212ab1362dffd3fa6258116973fb924068217317d2bc562481b037c806a0a

Actor-owned email addresses

Chris.sukkar@hotmail.com
PhillipAdamsthird@hotmail.com
sdfwfde234sdws@outlook.com
jenny1235667@outlook.com
fghfert32423dsa@outlook.com
sroggeveen@outlook.com
RobertFetter.fdmed@hotmail.com
Heather.mayx@outlook.com

Azure Active Directory App IDs associated with malicious apps

ae213805-a6a2-476c-9c82-c37dfc0b6a6c
afd7a273-982b-4873-984a-063d0d3ca23d
58e2e113-b4c9-4f1a-927a-ae29e2e1cdeb
8ba5106c-692d-4a86-ad3f-fc76f01b890d
be561020-ba37-47b2-99ab-29dd1a4312c4
574b7f3b-36da-41ee-86b9-c076f999b1de
941ec5a5-d5bf-419e-aa93-c5afd0b01eff
d9404c7d-796d-4500-877e-d1b49f02c9df
67e2bb25-1f61-47b6-9ae3-c6104e587882
9085bb9e-9b56-4b84-b21e-bd5d5c7b0de0
289d71ad-54ee-44a4-8d9a-9294f19b0069
a5ea2576-4191-4e9a-bfed-760fff616fbf
802172dc-8014-42a9-b765-133c07039f9f
fb33785b-f3f7-4b2b-b5c1-f688d3de1bde
c196c17d-1e3c-4049-a989-c62f7afaf7f3
79128217-d61e-41f9-a165-e06e1d672069
f4a41d96-2045-4d75-a0ec-9970b0150b52
88d43534-4128-4969-b5c4-ceefd9b31d02

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

The post Microsoft Security—detecting empires in the cloud appeared first on Microsoft Security.

STRONTIUM: Detecting new patterns in credential harvesting

September 10th, 2020 No comments

Microsoft has tied STRONTIUM to a newly uncovered pattern of Office365 credential harvesting activity aimed at US and UK organizations directly involved in political elections. Analysts from Microsoft Threat Intelligence Center (MSTIC) and Microsoft Identity Security have been tracking this new activity since April 2020. Credential harvesting is a known tactic used by STRONTIUM to obtain valid credentials that enable future surveillance or intrusion operations. Subsequent analysis revealed that between September 2019 and June 2020, STRONTIUM launched credential harvesting attacks against tens of thousands of accounts at more than 200 organizations. In the two weeks between August 18 and September 3, the same attacks targeted 6,912 accounts belonging to 28 organizations. None of these accounts were successfully compromised.

Not all the targeted organizations were election-related. However, we felt it important to highlight a potential emerging threat to the 2020 US Presidential Election and future electoral contests in the UK.

Microsoft CVP Customer Security and Trust, Tom Burt provided some additional details on this campaign in his recent On The Issues blog post. The purpose of this post is to provide defenders in any organization, but especially those directly or indirectly affiliated with electoral systems, insight into the technical nature of this activity. By providing these details, we hope to enable better defense against future attacks and share best practices for securing cloud environments against this type of activity.

Tactical Details

STRONTIUM relied heavily upon spear phishing in its credential harvesting efforts leading up to the 2016 US presidential election. In 2016, spear-phishing was the most common tactic for stealing credentials from targeted accounts. This time around, STRONTIUM appears to be taking a different approach, namely, brute-force/password-spray tooling. This shift in tactics, also made by several other nation-state actors, allows them to execute large-scale credential harvesting operations in a more anonymized manner. The tooling STRONTIUM is using routes its authentication attempts through a pool of approximately 1,100 IPs, the majority associated with the Tor anonymizing service. This pool of infrastructure has evolved over time, with an average of approximately 20 IPs added and removed from it per day. STRONTIUM’s tooling alternates its authentication attempts amongst this pool of IPs approximately once per second. Considering the breadth and speed of this technique, it seems likely that STRONTIUM has adapted its tooling to use an anonymizer service to obfuscate its activity, evade tracking, and avoid attribution.

During the two-week period, August 19 – September 3, STRONTIUM’s credential harvesting tooling utilized a daily average of 1,294 IPs associated with 536 netblocks and 273 ASNs. Of these netblocks, some were much more heavily utilized by the tooling than others, both in terms of the total number of authentications attempted from them and the total number of IPs utilized within them. Figure 1 below represents the 5 netblocks from which the highest number of total auth attempts were observed. As highlighted in the table, several of these netblocks had much higher IP utilization rates than the rest. This observed behavior indicates that the underlying anonymization services providing the infrastructure backbone for STRONTIUM auth attempts are, in a sense, over-serving IPs in these specific netblocks.

Figure 1: Highest volume netblocks used in STRONTIUM auth attempts.

Figure 1: Highest volume netblocks used in STRONTIUM auth attempts.

The fact that the anonymization service is over-serving specific netblocks gives defenders an opportunity to hunt for activity associated both with this STRONTIUM activity or other malicious tooling that is utilizing the same anonymization service. The following Azure Sentinel query (GitHub link) is designed to identify failed authentication attempts from the three highest-signal, highest-utilization netblocks highlighted above, and group the results by UserAgent.

An image of code.

Microsoft Threat Protection (MTP) also provides a platform for users to identify failed authentication attempts. The following query will give MTP users the ability to hunt and address these threats as well:

An image of code. MSTIC has observed that the STRONTIUM tooling operates in two modes when targeting accounts: brute-force and password-spray.

In password-spray mode, the tooling attempts username: password combinations in a ‘low-‘n-slow’ manner. Organizations targeted by the tooling running in this mode typically see approximately four authentication attempts per hour per targeted account over the course of several days or weeks, with nearly every attempt originating from a different IP address.

In brute-force mode, the tooling attempts many username: password attempts very rapidly for a much shorter time period. Organizations targeted by the tooling running in this mode typically see over 300 authentication attempts per hour per targeted account over the course of several hours or days.

Tooling Operating Mode Avg ## of Attempts Per Account Per Hour Avg # Of IPs Utilized for Auth Attempts Per Account Per Hour Avg Length of Attack
Password-Spray 4 4 Days-Weeks
Brute-Force 335 200 Hours-Days

Organizations targeted by STRONTIUM using this tooling saw auth attempts against an average of 20% of their total accounts. In some instances, MSTIC assesses the tooling may have discovered these accounts simply by attempting authentications against a large number of possible account names until it found ones that were valid.

Guidance: Proactive defense 

There are some very simple steps businesses and targeted individuals can take to significantly improve the security of their accounts and make these types of attacks much more difficult.

1. Enable multi-factor authentication

We have seen clear proof that enabling multi-factor authentication (MFA) across both business and personal email accounts successfully thwarts the majority of credential harvesting attacks. Our colleagues in Azure Active Directory put it more precisely—

“… doing any form of MFA takes you out of reach of most attacks. MFA (using any mechanism) is just too costly to break – unless a highly motivated attacker is after that high-value account or asset.”

However, most enterprise accounts have not implemented this simple protection:

“When we evaluate all the tokens issued with MFA claims, we see that less than 10% of users use MFA per month in our enterprise accounts (and that includes on-premises and third-party MFA). Until MFA is more broadly adopted, there is little reason for attackers to evolve.”

2. Actively monitor failed authentications

When monitoring login activity in your accounts, look for any type of discernable patterns in these failed authentications and track them over time. Password spray is an increasingly common tactic of nation-state actors.

You can also maintain broader visibility into behavioral anomalies like failed login attempts by running detections and monitoring using Microsoft Cloud App Security (MCAS) which monitors user sessions for third-party cloud apps, including G-Suite, AWS, and Salesforce. The MCAS detection engine looks for anomalous user activity for indicators of compromise. One indicator, “multiple failed login attempts,” can be used to create a dynamic baseline per user, across the tenant, and alert on anomalous login behavior that may represent an active brute force or password spray attack.

Microsoft Threat Protection (MTP) can help to automatically track and rebuild the Incident view of all the compromised identities by password-spray leveraged later by the attacker to expand the breach to endpoint or cloud assets.

3. Test your organization’s resilience

Attack Simulator in Office 365 ATP lets you run realistic, but simulated phishing and password attack campaigns in your organization. Pick a password and then run the campaign against as many users as you want. The results will let you know how many people are using that password. Use the data to train users and build your custom list of banned passwords.

The post STRONTIUM: Detecting new patterns in credential harvesting appeared first on Microsoft Security.

Accelerate your adoption of SIEM using Azure Sentinel and a new offer from Microsoft

September 8th, 2020 No comments

Take advantage of the efficiency benefits of Cloud-native SIEM using Azure Sentinel

Today, security needs are evolving faster than ever—and the importance of being agile and cost-effective has never been clearer. Security teams need to get more done, faster, with less budget. On-premises security information and event management (SIEM) solutions can’t keep up with these demands and are expensive to maintain. By embracing a cloud-native SIEM like Azure Sentinel, you can save money and enable your security operations team to be more effective.

According to an IDG survey of IT leaders, cloud-based SIEM solutions cost 11 percent less to support than on-premises solutions, since they drastically reduce infrastructure, licensing, and labor costs. Plus, that same survey found that cloud-based SIEM users missed fewer threats—only 43 percent of cloud SIEM users reported concerns about missed threats, compared to 66 percent of traditional SIEM users. This is likely because cloud adopters were twice as likely to utilize automation.

We know that right now, security operations teams need these cost savings and efficiency benefits more than ever. To help accelerate your move to the cloud, we’re pleased to announce an Azure Credit offer from Microsoft. For a limited time, get $25,000 of Azure credits when you ingest an average of 50GB/day into Azure Sentinel for three consecutive months.

This offer allows you to experience the benefits of the cloud firsthand by scaling up your Azure Sentinel deployment or accelerating your migration from an on-premises SIEM. With Azure Sentinel, you can get enterprise-wide intelligent security analytics, eliminate security infrastructure setup and maintenance, and elastically scale to meet your security needs – all while reducing IT costs.

Details of the $25,000 Azure Credit Offer

This offer is available for qualified customers starting September 1, for a limited time.

Customers must fulfill all the requirements below to be eligible for inclusion into the program:

  • Must have a Microsoft Enterprise Agreement
  • Must be a new Azure Sentinel customer or an existing customer ingesting less than an average of 5 GB of data per day over the last 6 months
  • Must have access to a minimum of 10 E5 security suite licenses or component licenses. Qualifying products include:
    • Microsoft 365 E5
    • Microsoft 365 E5 security
    • Standalone products including Microsoft Defender Advanced Threat Protection, Office Advanced Threat Protection, Azure Advanced Threat Protection, Microsoft Cloud App Security (MCAS), Azure Active Directory P2, Advanced Threat Protection Plan 1, Advanced Threat Protection Plan 2
    • Other suites that include some of the standalone components above, such as Office 365 E5, Windows E5, Enterprise Mobility and Security E5

In order to qualify for the $25,000 Azure Credit Offer, customers must ingest an average of 50GB per day or more into Azure Sentinel for three consecutive full months (measured out of the previous four months to accommodate billing cycle alignment) following their inclusion into the program. This consumption excludes data consumption from other free offers, such as trials, Azure Pass, Azure Access Sponsorship, or ACO, as well as the free data sources offered in Sentinel.

Once a customer’s eligibility to receive the offer has been verified, the customer will receive the Azure credits within two billing cycles. The Azure credits will be available until either the next enrollment anniversary or the end of the customer’s EA term – whichever comes first.

Get started today

Contact your Microsoft representative to learn more about the qualification criteria and how to take advantage of this offer. Or, if you don’t have a Microsoft representative, reach out to sales to learn more about Azure Sentinel.

Visit our website to learn more about Azure Sentinel or Microsoft Security solutions. 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 Accelerate your adoption of SIEM using Azure Sentinel and a new offer from Microsoft appeared first on Microsoft Security.