Archive

Archive for the ‘Microsoft Defender for Endpoint’ Category

Detecting and preventing privilege escalation attacks leveraging Kerberos relaying (KrbRelayUp)

On April 24, 2022, a privilege escalation hacking tool, KrbRelayUp, was publicly disclosed on GitHub by security researcher Mor Davidovich. KrbRelayUp is a wrapper that can streamline the use of some features in Rubeus, KrbRelay, SCMUACBypass, PowerMad/SharpMad, Whisker, and ADCSPwn tools in attacks.

Although this attack won’t function for Azure Active Directory (Azure AD) joined devices, hybrid joined devices with on-premises domain controllers remain vulnerable. Microsoft Defender for Identity detects activity from the early stages of the attack chain by monitoring anomalous behavior as seen by the domain controller. In addition, signals from Defender for Identity also feed into Microsoft 365 Defender, providing organizations with a comprehensive solution that detects and blocks suspicious network activities, malicious files, and other related components of this attack. Microsoft Defender Antivirus detects this attack tool as the malware family HackTool:MSIL/KrbUpRly.

Microsoft encourages customers to update Domain Controller: LDAP server signing requirements to Require signing as detailed in this advisory and enable Extended Protection for Authentication (EPA) as detailed in this blog.

Originally, KrbRelayUp supported only one method that’s based on taking advantage of resource-based constrained delegation (RBCD); it later added several additional attack methods. In this blog, we discuss RBCD to provide further insights into how the initial KrbRelayUp attack method works. We also detail the stages that make up the said attack. Finally, we provide recommendations and guidelines that can help organizations strengthen their device configurations and defend their networks from attacks that use this tool.

Understanding the attack: What is resource-based constrained delegation?

Resource-based constrained delegation (RBCD) represents the key to this attack method, enabling the tool to impersonate an administrator and eventually run a code as the SYSTEM account of a compromised device.

Authentication protocol basics

An authentication protocol verifies the legitimacy of a resource or identity. When a user signs into a website, that website uses a methodology to confirm the authenticity of the resource requesting access. In simpler terms, the authentication process involves signing in with a password—made possible by the user knowing the password anticipated by the website. The Kerberos protocol serves as the main authentication framework for this process in on-premises Active Directory.

Delegation

Sometimes, however, a resource needs to request access to another resource on behalf of a different identity. A common example of this is mail delegation, wherein executives often give delegation rights to their executive assistants to send and receive emails on their behalf without providing the assistant with the executive’s password. The executive assistant isn’t authenticating as the executive; the executive has just allowed the assistant’s account to “pretend” that they are.

Resource-based constrained delegation

Initially, only users with the SeEnableDelegation role could configure delegation, typically domain admins. These domain admins can manage resources and dictate which identities can act on behalf of a different resource. They achieve this by updating the msDS-AllowedToDelegateTo property of a user account or device. This property contains a list of all the unique identifiers (service principal names, or SPNs) to which this object can delegate or act on behalf of.

However, as organizations expanded, administrators struggled to manage all the delegation requirements, raising the need for a new type of delegation: resource-based. For instance, in an organization with several file servers that all trust a web server for delegation, an admin would have to change the msDS-AllowedToDelegateTo priority in all of the different file servers to introduce a second web server. With resource-based delegation, the list of trusted computers is held on the receiving end. Thus, in our example, only the newly created server would require a change of settings.

Unsigned LDAP and relay attacks

For the RBCD method of the KrbRelayUp tool to work, the LDAP protocol must not use signing to communicate between LDAP clients and domain controllers. While this setting is still the default on Windows, as of 2019 Microsoft recommends configuring LDAP to use LDAP channel binding and signing.

LDAP is one of the main protocols that directory services tools, such as Active Directory, use to query and access directory information. By default, LDAP is vulnerable to credential relaying attacks. For example, in a credential relaying attack, a web server requesting a password to sign in would have its request relayed by an attacker to an authorized client. The attacker then relays the client reply containing the correct password back to the server, thus signing in. Once the attacker is signed in, they have the same permissions as the user whose credentials were relayed.

If LDAP signing is required, each request to the server needs to be cryptographically signed. In this case, the attacker would still be able to relay the sign-in request and reply, but all further requests from the attacker would be disregarded because each request must be signed, and the attacker doesn’t have the proper keys to do the signing.

Ms-DS-MachineAccountQuota

The final key concept behind the RBCD method of KrbRelayUp tool is the ms-DS-MachineAccountQuota attribute, which all User Active Directory objects have. This attribute is set to 10 by default, which means that any user in Active Directory can create up to 10 computer accounts associated with them. The legitimate usage of this attribute is to allow users to have multiple devices on a network that belong to them that they can then manage. However, if a compromised user doesn’t have 10 actual devices associated with their account, an attacker can create an account for a non-existing device that will be an object in Active Directory. This fake computer account isn’t associated with a real device but can perform Active Directory authentication requests as if it were.

Initially, the ability to obtain such an account was a prerequisite for this attack method, but since the release of the tool, other security researchers found ways to get around this requirement.

KrbRelayUp attack flow

To launch an attack using the RBCD method of KrbRelayUp, an attacker performs four main steps:

Step 1: Acquisition of a suitable resource

The attacker first obtains a resource suitable to be the source of an RBCD. There are several ways to obtain such a resource; the most straightforward way is to create a new computer account as discussed above.

Step 2: Modification of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute

Next, the attacker adds their resource to the current device’s list of trusted resources. To do this, the attacker starts an LDAP session and relays the credentials of the current device to the LDAP server.

The new KrbRelayUp tool implements this step with these two smaller consecutive actions:

  1. Authenticates to the LDAP service by triggering and performing a Kerberos relay attack
  2. Edits the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to add the attacker’s resource to the list of entities permitted to delegate the target device.

Step 3: Privileged ticket acquisition

Here, the attacker leverages their control over their resource gained through the first step with the trust for their resource gained through the second step. As such, the local device trusts the attacker’s resource to request a ticket addressed to the host SPN as the domain administrator. The request is made by first pretending to be the attacker’s resource and consists of three requests:

  1. AS-Req – A request to generate a Ticket Granting Ticket (TGT) for the attacker’s impersonated resource.
  2. S4U2self – A request to generate a Ticket Granting Service (TGS) ticket from an administrator to the resource.
  3. S4U2proxy – A request to generate a TGS ticket for the host SPN as an administrator delegating their access via the impersonated resource.

After this step, the attacker has a valid ticket for the local device that allows the administrator to be impersonated.

Step 4: Privileged ticket leverage

The last step leverages the attacker’s newly acquired ticket to run code on the device. In the attack, as it’s published online, the Service Control Manager (SCM) is asked to create a new service with SYSTEM permissions.

Protecting against KrbRelayUp attacks through coordinated threat defense

It’s important to note that KrbRelayUp cannot be used in attacks against organizations that are only using Azure AD. However, in hybrid identity environments where organizations synchronize their domain controllers with Azure AD, if an attacker compromises an Azure virtual machine using a synchronized account, they’ll receive SYSTEM privileges on the virtual machine.

To reduce the impact of this threat, organizations should apply the mitigations below. Microsoft 365 Defender customers can check the recommendations card for the deployment status of monitored mitigations.

Detection details

Organizations should also deploy a comprehensive security solution like Microsoft 365 Defender to detect and block this threat across the stages of the attack chain. Microsoft 365 Defender has multiple layers of dynamic protection technologies, including machine learning-based protection, and correlates threat data from email, endpoints, identities, and cloud apps to provide in-depth and coordinated threat defense. All of these are backed by threat experts who continuously monitor the threat landscape for new attacker tools and techniques.

Microsoft Defender for Identity detects activity from the first three steps of the attack flow by monitoring anomalous behavior as seen by the domain controller. Starting in version 2.180, Defender for Identity has two detections that raise an alert when this attack is attempted:

  • Suspicious Kerberos delegation attempt by a newly created computer.
  • Suspicious edit of the Resource Based Constrained Delegation Attribute by a machine account (KrbRelayUp).
This image displays an alert in Microsoft Defender for Identity. The title states "Suspicious Kerberos delegation attempt by a newly created computer" followed by the subtitle "Administrator on evilcomputer5 used a ticket to delegate access to ATTACKER." Below the titles displays an administrator icon on the left and an attacker icon on the right, with an arrow pointing from the admin to the attacker stating "delegated a ticket with access to". The evidence includes "resource based constrained delegation is configured on the resource with the Administrator as allowed to delegate", "evilcomputer5 was created on May 19 2022 at 8:45 PM", and "this alert is associated with the KrbRelayUp exploitation".
Figure 1. ‘Suspicious Kerberos delegation attempt by a newly created computer’ alert in Microsoft Defender for Identity

Microsoft Defender for Endpoint includes new and enhanced network inspection capabilities to correlate network and endpoint signals and emit high-confidence alerts. Defender for Endpoint leverages these network signals and looks for suspicious LDAP and Kerberos requests to Active Directory domain controllers to accurately detect attacks using KrbRelayUp. Defender for Endpoint also detects suspicious Kerberos sign-ins and service creations.

This image displays an alert in Microsoft Defender for Endpoint titled "Possible Kerberos local privilege escalation relay attack." The alert story displays a detailed timeline of the various detections, including "Defender detected active 'HackTool:MSIL/KrbUpRly.A!dha' in process 'Test.exe'". Under the detection includes detailed insight into the alert "Possible Kerberos local privilege escalation relay attack", such as the alert state, MITRE ATT&CK Techniques, detection information, last activity, and more.
Figure 2. ‘Possible Kerberos local privilege escalation relay attack’ alert in Microsoft Defender for Endpoint

Microsoft Defender Antivirus detects a threat from the KrbRelayUp tool as the following malware:

Microsoft 365 Defender customers may refer to the threat analytics report to determine if this threat is present in their network and to get additional details and recommendations. Threat analytics enables organizations to assess the impact of a threat to their network, review exposure and resilience, and perform mitigation, recovery, or prevention actions to stop or contain active attacks.

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

Zeev Rabinovich and Ofir Shlomo
Microsoft 365 Defender Research Team

Resources

The post Detecting and preventing privilege escalation attacks leveraging Kerberos relaying (KrbRelayUp) appeared first on Microsoft Security Blog.

Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn

April 26th, 2022 No comments

Microsoft has discovered several vulnerabilities, collectively referred to as Nimbuspwn, that could allow an attacker to elevate privileges to root on many Linux desktop endpoints. The vulnerabilities can be chained together to gain root privileges on Linux systems, allowing attackers to deploy payloads, like a root backdoor, and perform other malicious actions via arbitrary root code execution. Moreover, the Nimbuspwn vulnerabilities could potentially be leveraged as a vector for root access by more sophisticated threats, such as malware or ransomware, to achieve greater impact on vulnerable devices.

We discovered the vulnerabilities by listening to messages on the System Bus while performing code reviews and dynamic analysis on services that run as root, noticing an odd pattern in a systemd unit called networkd-dispatcher. Reviewing the code flow for networkd-dispatcher revealed multiple security concerns, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues, which could be leveraged to elevate privileges and deploy malware or carry out other malicious activities. We shared these vulnerabilities with the relevant maintainers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for these vulnerabilities, now identified as CVE-2022-29799 and CVE-2022-29800, have been successfully deployed by the maintainer of the networkd-dispatcher, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of networkd-dispatcher are encouraged to update their instances.

As organizational environments continue to rely on a diverse range of devices and systems, they require comprehensive solutions that provide cross-platform protection and a holistic view of their security posture to mitigate threats, such as Nimbuspwn. The growing number of vulnerabilities on Linux environments emphasize the need for strong monitoring of the platform’s operating system and its components. Microsoft Defender for Endpoint enables organizations to gain this necessary visibility and detect such threats on Linux devices, allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.

In this blog post, we will share some information about the affected components and examine the vulnerabilities we uncovered. Detailing how our cross-domain visibility helps us uncover new and unknown threats to continually improve security, we are also sharing details from our research with the larger security community to underscore the importance of securing platforms and devices.

Background – D-Bus

D-Bus (short for “Desktop-Bus”) is an inter-process communication channel (IPC) mechanism developed by the freedesktop.org project. D-Bus is a software-bus and allows processes on the same endpoint to communicate by transmitting messages and responding to them. D-Bus supports two main ways of communicating:

  1. Methods – used for request-response communications.
  2. Signals – used for publish/subscribe communications.

An example of D-Bus usage would be receiving a video chat by a popular video conferencing app–once a video is established, the video conferencing app could send a D-bus signal publishing that a call has started. Apps listening to that message could respond appropriately–for example, mute their audio.

There are many D-Bus components shipped by default on popular Linux desktop environments. Since those components run at different privileges and respond to messages, D-Bus components are an attractive target for attackers. Indeed, there have been interesting vulnerabilities in the past related to buggy D-Bus services, including USBCreator Elevation of Privilege, Blueman Elevation of Privilege by command injection, and other similar scenarios.

D-Bus exposes a global System Bus and a per-session Session Bus. From an attacker’s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.

D-Bus name ownership

When connecting to the D-Bus, components are assigned with a unique identifier, which mitigates against attacks abusing PID-recycling. The unique identifier starts with a colon and has numbers in it separated by dots, such as “:1.337”. Components can use the D-Bus API to own identifiable names such as “org.freedesktop.Avahi” or “com.ubuntu.SystemService”. For D-Bus to allow such ownership, the requesting process context must be allowed under the D-Bus configuration files. Those configuration files are well documented and maintained under /usr/local/share/dbus-1/system.conf and /usr/local/share/dbus-1/session.conf (on some systems under /usr/local/dbus-1 directly). Specifically, the default system.conf does not allow ownership unless specified otherwise in other included configuration files (commonly under /etc/dbus-1/system.d).

Figure 1 displays different ownership policies for the System Bus and the Session Bus;
Figure 1: Different ownership policies for the System Bus and the Session Bus

Additionally, if the name requested already exists–the request will not be granted until the owning process releases the name.

Vulnerability hunting

Our team has started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis. We have reported two information leak issues as a result:

  1. Directory Info Disclosure in Blueman
  2. Directory Info Disclosure in PackageKit (CVE-2022-0987)

While these are interesting, their severity is low – an attacker can list files under directories that require high permissions to list files under. Then we started noticing interesting patterns in a systemd unit called networkd-dispatcher. The goal of networkd-dispatcher is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:

Figure 2 displays networkd-dispatcher running as root.
Figure 2: networkd-dispatcher running as root

Code flow for networkd-dispatcher

Upon examination of the networkd-dispatcher source code, we noticed an interesting flow:

  1. The register function registers a new signal receiver for the service “org.freedesktop.network1” on the System Bus, for the signal name ”PropertiesChanged”.
  2. The ”_receive_signal“ signal handler will perform some basic checks on the object type being sent, concludes the changed network interface based on the object path being sent, and then concludes its new states–“OperationalState” and “AdministrativeState”–each fetched from the data. For any of those states–if they aren’t empty–the “handle_state” method will get invoked.
  3. The “handle_state” method simply invokes “_handle_one_state“ for each of those two states.
  4. _handle_one_state” validates the state isn’t empty and checks if it’s different than the previous state. If it is, it will update the new state and invoke the “_run_hooks_for_state” method, which is responsible of discovering and running the scripts for the new state.
  5. _run_hooks_for_state” implements the following logic:
    • Discovers the script list by invoking the “get_script_list” method (which gets the new state as a string). This method simply calls “scripts_in_path” which is intended to return all the files under “/etc/networkd-dispatcher/<state>.d” that are owned by the root user and the root group, and are executable.
    • Sorts the script list.
    • Runs each script with subprocess.Popen while supplying custom environment variables.
Figure 3 displays a snippet of the _run_hooks_for_state source code.
Figure 3: _run_hooks_for_state source code – some parts omitted for brevity

Step 5 has multiple security issues:

  1. Directory traversal (CVE-2022-29799): none of the functions in the flow sanitize the OperationalState or the AdministrativeState. Since the states are used to build the script path, it is possible that a state would contain directory traversal patterns (e.g. “../../”) to escape from the “/etc/networkd-dispatcher” base directory.
  2. Symlink race: both the script discovery and subprocess.Popen follow symbolic links.
  3. Time-of-check-time-of-use (TOCTOU) race condition (CVE-2022-29800): there is a certain time between the scripts being discovered and them being run. An attacker can abuse this vulnerability to replace scripts that networkd-dispatcher believes to be owned by root to ones that are not.
Figure 4 displays building the script list in the "scripts_in_path" method, including the vulnerable code with "subdir" poisoned, which is highlighted with a red box over the text reading "os.path.join(one path, subdir, filename)".
Figure 4: Building the script list in the “scripts_in_path” method, including the vulnerable code with “subdir” poisoned.

Exploitation

Let us assume an adversary has a malicious D-Bus component that can send an arbitrary signal. An attacker can therefore do the following:

  1. Prepare a directory ”/tmp/nimbuspwn” and plant a symlink ”/tmp/nimbuspwn/poc.d“ to point to “/sbin”. The “/sbin” directory was chosen specifically because it has many executables owned by root that do not block if run without additional arguments. This will abuse the symlink race issue we mentioned earlier.
  2. For every executable filename under “/sbin” owned by root, plant the same filename under “/tmp/nimbuspwn”. For example, if “/sbin/vgs” is executable and owned by root, plant an executable file “/tmp/nimbuspwn/vgs” with the desired payload. This will help the attacker win the race condition imposed by the TOCTOU vulnerability.
  3. Send a signal with the OperationalState “../../../tmp/nimbuspwn/poc”. This abuses the directory traversal vulnerability and escapes the script directory.
  4. The networkd-dispatcher signal handler kicks in and builds the script list from the directory “/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d”, which is really the symlink (“/tmp/nimbuspwn/poc.d”), which points to “/sbin”. Therefore, it creates a list composed of many executables owned by root.
  5. Quickly change the symlink “/tmp/nimbuspwn/poc.d” to point to “/tmp/nimbuspwn”. This abuses the TOCTOU race condition vulnerability–the script path changes without networkd-dispatcher being aware.
  6. The dispatcher starts running files that were initially under “/sbin” but in truth under the “/tmp/nimbuspwn” directory. Since the dispatcher “believes” those files are owned by root, it executes them blindly with subprocess.Popen as root. Therefore, our attacker has successfully exploited the vulnerability.

Note that to win the TOCTOU race condition with high probability, we plant many files that can potentially run. Our experiments show three attempts were enough to win the TOCTOU race condition.

Figure 5 displays a flow-chart of the attack in 3 stages. The first 3 steps are depicted in the top image, displaying the attacker's initial steps. The 4th step is depicted in the middle image, displaying how networkd-dispatcher processes the attacker's modifications. Steps 5 and 6 are depicted in the final image, displaying how the attacker abuses the TOCTOU race condition flaw so that the dispatcher ultimately permits the Nimbuspwn exploit.
Figure 5: Flow-chart of the attack in three stages

Since we do not wish to run the exploit every time we want to run as root, the payload that we ended up implementing leaves a root backdoor as such:

  1. Copies /bin/sh to /tmp/sh.
  2. Turns the new /tmp/sh it into a Set-UID (SUID) binary.
  3. Run /tmp/sh -p. The “-p” flag is necessary since modern shells drop privileges by design.

Owning the bus name

The astute reader will notice that the entire exploit elevates privileges assuming our exploit code can own the “org.freedesktop.network1” bus name. While this sounds non-trivial, we have found several environments where this happens. Specifically:

  1. On many environments (e.g. Linux Mint) the service systemd-networkd that normally owns the “org.freedesktop.network1” bus name does not start at boot by default.
  2. Using advanced hunting in Microsoft Defender for Endpoint we were able to spot several processes running as the systemd-network user (which is permitted to own the bus name we require) running arbitrary code from world-writable locations. These include several gpgv plugins (launched when apt-get installs or upgrades) as well as the Erlang Port Mapper Daemon (epmd) which allows running arbitrary code under some scenarios.

The query we used can also be run by Microsoft Defender for Endpoint customers:

DeviceProcessEvents
| where Timestamp > ago(5d)
    and AccountName == "systemd-network"
    and isnotempty(InitiatingProcessAccountName)
    and isnotempty(FileName)
| project DeviceId, FileName, FolderPath, ProcessCommandLine

We were therefore able to exploit these scenarios and implement our own exploit:

Figure 6 displays our successfully implemented exploit after winning the TOCTOU race condition. The title reads "Nimbuspwn: networkd-dispatcher Linux EoP by Jonathan Bar Or ('JBO')". The processes are then displayed, reading top to bottom: "Attempting to own dbus name org.freedesktop.network1", "Validating name patterns", "Planting base directory", "Planting symlink", "Planting payload", it then takes four attempts to "win the (TOCTOU) race" condition before stating "Great, we now have a root backdoor. Hurray! Enjoy your root privileges".
Figure 6: Our exploit implemented and winning the TOCTOU race

While capable of running any arbitrary script as root, our exploit copies /bin/sh to the /tmp directory, sets /tmp/sh as a Set-UID (SUID) executable, and then invokes “/tmp/sh -p”. Note that the “-p” flag is necessary to force the shell to not drop privileges.

Hardening device security and detection strategy

Despite the evolving threat landscape regularly delivering new threats, techniques, and attack capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems, networks, and sensitive information for malicious purposes. This constant bombardment of attacks spanning a wide range of platforms, devices, and other domains emphasizes the need for a comprehensive and proactive vulnerability management approach that can further identify and mitigate even previously unknown exploits and issues.

Microsoft’s threat and vulnerability management capabilities help organizations monitor their overall security posture, providing real-time insights into risk with continuous vulnerability discovery, contextualized intelligent prioritization, and seamless one-click flaw remediation. Leveraging our research into the Nimbuspwn vulnerabilities to improve solutions, our threat and vulnerability management already covers CVE-2022-29799 and CVE-2022-29800 and indicates such vulnerable devices in the threat and vulnerability module in Microsoft Defender for Endpoint.

To address the specific vulnerabilities at play, Microsoft Defender for Endpoint’s endpoint detection and response (EDR) capabilities detect the directory traversal attack required to leverage Nimbuspwn. Additionally, the Microsoft Defender for Endpoint detection team has a generic detection for suspicious Set-UID process invocations, which detected our exploit without prior knowledge.

Figure 7 displays Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit - including the alert story and details of the detected activity.
Figure 7: Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit

Defending against the evolving threat landscape requires the ability to protect and secure users’ computing experiences, be it a Windows or non-Windows device. Microsoft continuously enriches our protection technologies through robust research that protects users and organizations across all the major platforms every single day. This case displayed how the ability to coordinate such research via expert, cross-industry collaboration is vital to effectively mitigate issues, regardless of the vulnerable device or platform in use. By sharing our research and other forms of threat intelligence, we can continue to collaborate with the larger security community and strive to build better protection for all.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn appeared first on Microsoft Security Blog.

Detect active network reconnaissance with Microsoft Defender for Endpoint

February 7th, 2022 No comments

The Microsoft Compromise Recovery Security Practice has observed how the security industry has evolved over the last few years as consumers, businesses, and industry professionals continue to adapt to the changing landscape. We have seen the emergence of new frameworks, such as the Cybersecurity Framework by the National Institute of Standards and Technology (NIST), which can empower us to build scalable programs and accelerate the transition to a Zero Trust workplace. We have also witnessed the rise and prominence of human-operated ransomware, which continues to subvert traditional security defenses and assert control over our information assets.1

Many of our customers have placed their trust in Microsoft Defender for Endpoint in order to help them protect, detect, and respond to threats that have emerged throughout this period of change. It is a diverse landscape that forces us to reconsider how we protect our most prized assets from borderless threat actors in IT environments that can no longer remain exclusively protected behind a network perimeter.

Threat actor tactics and techniques

With the current levels of diversity and the continued evolution of IT services, it is important to take a moment and consider how attackers might think in terms of the tactics and techniques required to successfully target and infiltrate a network. For example, HAFNIUM performed active reconnaissance before choosing to exploit a zero-day vulnerability within Microsoft Exchange Server to assert control over their chosen target’s information systems.

Bar chart of Miter Att&ck Framework with first part highlighted in red showing impact.

The objective was to develop a network map or diagram of possible endpoints which could be successfully exploited as part of a targeted campaign. This highlights the significance of reconnaissance and demonstrates the critical role it plays in assisting threat actors in achieving their goals and objectives, such as active directory domain dominance.

Spending quality time on reconnaissance is guaranteed to pay dividends at subsequent stages of the cybersecurity kill chain and is a crucial indicator from which to detect malicious activity at the earliest possible stages of an attack. Unfortunately, it is also a focus area that is overlooked by security professionals in favor of exotic phases of an attack such as weaponization, delivery, and exploitation. This is because it can be notoriously difficult to detect reconnaissance attacks—as they are often passive—executed in the public domain and external to the victim’s network. Job postings, domain registrars, and financial reporting are great resources to gain context on a target, but due to their nature, it can be a challenge to even seasoned security operations teams to detect and investigate this type of attack. Fortunately, there is a certain point where passive activities can have diminishing returns as the data points produced can be too broad to act upon. This can drive an attacker to consider the use of active reconnaissance which has dependencies on the endpoint or human interaction. For defenders, this is good news as it increases the likelihood that security services will be able to capture indicators of attack (IOA) in event logs, providing intelligence that can be analyzed and used to execute an informed response. For the remainder of the blog post, we will look more directly at active network reconnaissance using a well-known utility.

Active network reconnaissance

Active network reconnaissance is an art form and a somewhat divisive topic. A typical approach is to perform network scanning against a network address range or host IP address to elicit information about the target under evaluation. A wide variety of utilities can scan and enumerate data from a network, but for many Nmap (Network Mapper) remains the premier choice in developing time-sensitive network intelligence. Originally released 24 years ago, Nmap has been actively maintained and is available for Microsoft Windows, Linux, and macOS making it accessible to network auditors and security professionals regardless of their preferred choice of operating system.

Nodes on a network can be probed for information using network scan utilities and services.

At its heart, the utility enumerates critical information about the target. It does this by sending specially crafted network probes to elicit a response from a scanned host. These responses are analyzed and provide data points about the ports, services, and operating system versions which exist on the target under evaluation. This information is valuable to a threat actor, as it defines how to approach the weaponization, delivery, and exploitation phases of the attack lifecycle, providing insight into critical areas of interest, such as determining what types of vulnerabilities can be exploited to gain entry. Equally, this can be of significant interest to a defender as it can be used to identify weaknesses in the attack surface which require further investigation to protect—often considered a pivotal component of threat and vulnerability management programs. The utility can also quickly determine which hosts may be active at any given time, ensuring that deeper analysis is performed directly on responding endpoints.

Knowing which hosts are online facilitates this narrowing of reconnaissance investigation effort to specific endpoints where more time and care can be taken to determine the most effective path to exploitation. Gaining intelligence on which hosts are online enables the development of a structured attack strategy, which significantly increases the chance of success and ensures energy is concentrated exclusively on these endpoints—leading to interesting information about their status and configuration. Let’s illustrate this in a real-world scan using Nmap in a controlled environment.

Nmap scan use case

In our lab environment, Nmap has been configured to send probes to an individual IP address from an unauthenticated client. The results, albeit constrained to a specific scan type, return a plethora of information that can aid an attacker in building a profile about a discovered host. An example scan can be seen in the screenshot below, which includes data points on:

  • The online status of a scanned endpoint.
  • The role or services, which are found to be running on the endpoint.
  • The possible version of the operating system installed on the endpoint.
Example of a real world N M A P scan within a controlled Lab Environment showcasing the metadata which could be of interest to Attackers and Defenders when performing active reconnaissance

This type of information is vital as it will help to steer an attacker towards further research on the specific vulnerabilities which can be exploited to successfully compromise the version of the operating system or combination of windows services running on the scanned endpoint.

The valuable point to take away is that whilst this information is of interest to a threat actor, the scan has a dependence on endpoint interaction which can leave behind breadcrumbs within security services such as Windows Defender Firewall with Advanced Security which can be reviewed for anomalous network traffic.

Defend against active network reconnaissance with Windows Defender Firewall

Windows Defender Firewall with Advanced Security is a service that is built directly into Windows and, given its proximity to the host, can detect active network reconnaissance attacks against an active network interface in real-time. Unfortunately for Microsoft’s Compromise Security Recovery Practice, the service is often found to be in a disabled state because of perceived complexity or operational overhead, but it is a proven solution that is effective in both the detection and prevention of active reconnaissance attacks and should not be overlooked as part of any defense-in-depth security strategy.

Returning to our lab, NMAP had been used to target an endpoint where the Windows Defender Firewall with Advanced Security service was active allowing for the capture of network events within localized log files. This file can be parsed to identify anomalies in network communications such as those of a singular IP being linked to a port scan against numerous TCP ports in a short time span. The Windows Defender Firewall with Advanced Security logfile confirms that the scan came from a host that is resident on the same network segment as the target endpoint.

Windows Defender Firewall log which is typically found here when enabled.

This is important as whilst enterprise firewalls provide visibility of threats at the outermost boundary of a company network environment, they are not always positioned to detect threats within the same network segment. In this case, it is possible that security operations will not be able to identify and act upon these types of threats. By ensuring that Defender for Endpoint with Advanced Security is enabled and capable of collecting network security events, you will be able to perform effective host-based investigations, confirm the presence of active network reconnaissance, and take appropriate action to disrupt an attack at the start of the kill chain.

Enterprise-wide visibility with Microsoft Defender for Endpoint

Microsoft Defender for Endpoint is a market-leading platform on the market that offers vulnerability management, endpoint protection, endpoint detection and response (EDR), and mobile threat defense service. It is a true game-changer in the security services industry and one that provides visibility in a uniform and centralized reporting platform. Defender for Endpoint can be quickly scaled on-demand across heterogeneous network environments and to begin collating telemetry data directly from managed endpoints for true enterprise-wide visibility.

While we had highlighted the value of parsing Windows Defender Firewall with Advanced Security log files on an endpoint, the approach provides a somewhat limited view of the overall threat landscape. Microsoft Defender for Endpoint can overcome these constraints as it continuously collects a wide variety of telemetry data from all managed endpoints. A security operations analyst can use this telemetry data to create detailed custom reports which can scale across the enterprise, empowering the team to perform rapid and effective isolation of malicious hosts in the network.

Advanced threat hunting with Defender for Endpoint

The Microsoft Defender for Endpoint advanced threat hunting feature can be used to detect network reconnaissance by searching for common characteristics of a scan such as those of time, source address, destination address, TCP/IP port, and network type. For example, we can check whether a single IP address is attempting to connect to a wide range of ports on a specific host in a short period of time in much the same way as found within Windows Defender Firewall with Advanced Security—except we now have enterprise-wide coverage within an instant. It is an extremely flexible solution that can be tailored to support almost any use case.

If we look closely at the results, we can see that an endpoint is attempting to connect to endpoints on TCP/IP ports which are representative of a default Nmap scan. This type of detection method is useful when the attacker is using a workstation that is not managed within Microsoft Defender for Endpoint but resident on the network.

Advanced Threat Hunting Queries can be produced to provide enterprise-wide visibility on potential port scan threat activity.

In a situation where all hosts have been onboarded into Defender for Endpoint, you could detect the same threat using an alternative method such as running an advanced threat hunting query to detect all instances where the Nmap process has been invoked from the command line. In our example, the query references the DeviceProcessEvents table to generate a tabular report which can detect the invocation of nmap.exe from a parent process such as cmd.exe. The core value is that you customize advanced threat hunting queries within Defender for Endpoint to fit your threat scenario, truly ensuring that no stone is left unturned during your investigations.

As shown, the results table provides us with clear attribution towards suspicious endpoints without the need to drill down into the data to filter out legitimate versus malicious network traffic. The information provided accurately illustrates what type of scan <-sS, -T4> has been executed but provides a clear indicator of the targets of the attack such as the 172.16.0.0/24 subnet. This level of detail can be critical when looking to make an informed decision on how best to isolate, eradicate and recover from this type of attack scenario.

A simple query used within Advanced Threat Hunting to identify hosts which have executed n map from c m d within the last 30 days.

The results table provides us with clear attribution towards a suspicious endpoint which minimizes the need for further analysis. The information provided accurately illustrates what type of scan <-sS, -T4> has been executed by the suspicious workstation but also helps us concentrate our investigation on exposed targets of the attack <172.16.0.0/24>. This level of detail can be critical when looking to make an informed decision on how best to respond to the attack.

Screen view of parent and chile process command codes.

As shown in our lab examples, advanced threat hunting is a versatile and effective means to quickly detect active network reconnaissance attacks such as those performed using Nmap, and a great focus area to develop and mature your security operations capabilities. The queries can be tailored for almost any use case and can help us investigate an issue from multiple perspectives, allowing for a custom-specific target response to an attack. Defender for Endpoint includes a great number of useful queries to help you get started in the built-in repository but many more can be sourced from online communities or public repositories such as those from GitHub. These can act as great references that can help you to accelerate your development of the native Kusto Query Language (KQL) and are a fantastic point from which to start your journey in being able to detect and respond to advanced persistent threats.

Proactively seek out active reconnaissance

Back in 2020, it was reported that it can take up to 228 days to identify a breach. This is an incredible time period and one we all must aim to reduce to an absolute minimum to ensure the threat is contained at the earliest possible stages of the kill chain. Security operations teams must consider this when aiming to improve their operational performance along with adopting an assume breach mindset. To minimize the time-to-detect, one must place a greater emphasis on the detection of reconnaissance attacks through the adoption and use of continuous monitoring solutions like Defender for Endpoint. This means taking the initiative to proactively seek out active reconnaissance in all its forms, on the broadest possible scale, with the best tools available. It is, therefore, imperative to enable key log sources, like those found within Windows Defender Firewall to gain greater visibility into localized IOA for deep analysis while embracing Defender for Endpoint to scale on-demand and secure a complete horizontal view of the threats to your managed environment.

Microsoft Compromise Recovery Security Practice uses Defender for Endpoint every day as a part of our proactive and reactive investigations. It has proven to be critical to the fast and successful recovery of service for our customers and a significant contributor to our goal to assist our customers in accelerating transformation programs and achieving the desired target of a secure modern workplace.

Overview of the Cyber Security Kill Chain as aligned to the Mitre Att&ck Framework Tactic at the core of our blog posting.

Through this experience, we encourage our customers to act first, act fast, and prevent an attack at the earliest possible phases of the kill chain.  

We believe that Microsoft Defender For Endpoint is a great place to start and one which could prove to be the difference between disrupting an attacker from performing active network reconnaissance and being the victim of a malicious zero-day targeted attack.

Learn more

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.


1 Human-operated ransomware, January 11, 2022

The post Detect active network reconnaissance with Microsoft Defender for Endpoint appeared first on Microsoft Security Blog.

Behind the scenes of business email compromise: Using cross-domain threat data to disrupt a large BEC campaign

June 14th, 2021 No comments

Microsoft 365 Defender researchers recently uncovered and disrupted a large-scale business email compromise (BEC) infrastructure hosted in multiple web services. Attackers used this cloud-based infrastructure to compromise mailboxes via phishing and add forwarding rules, enabling these attackers to get access to emails about financial transactions.

In this blog, we’ll share our technical analysis and journey of unraveling this BEC operation, from the phishing campaign and compromised mailboxes to the attacker infrastructure. This threat highlights the importance of building a comprehensive defense strategy, which should include strong pre-breach solutions that can prevent attackers from gaining access and creating persistence on systems in the first place, as well as advanced post-breach capabilities that detect malicious behavior, deliver rich threat data, and provide sophisticated hunting tools for investigating and resolving complex cyberattacks.

This investigation also demonstrates how cross-domain threat data, enriched with expert insights from analysts, drives protection against real-world threats, both in terms of detecting attacks through products like Microsoft Defender for Office 365, as well as taking down operations and infrastructures.

The use of attacker infrastructure hosted in multiple web services allowed the attackers to operate stealthily, characteristic of BEC campaigns. The attackers performed discrete activities for different IPs and timeframes, making it harder for researchers to correlate seemingly disparate activities as a single operation. However, even with the multiple ways that the attackers tried to stay under the radar, Microsoft 365 Defender’s cross-domain visibility uncovered the operation.

Figure 1. Signals from Microsoft 365 Defender services that researchers correlated to expose the BEC attack

This depth and breadth of this visibility is especially critical in detecting and stopping BEC because these attacks have minimal footprint, create very low signals that don’t rise to the top of a defender’s alert list, and tend to blend in with the usual noise of corporate network traffic. BEC attacks unfortunately can stay undetected until they cause real monetary loss because of limited or partial visibility provided by security solutions that don’t benefit from comprehensive visibility into email traffic, identities, endpoints, and cloud behaviors, and the ability to combine together isolated events and deliver a more sophisticated cross-domain detection approach.  Armed with intelligence on phishing emails, malicious behavior on endpoints, activities in the cloud, and compromised identities, Microsoft researchers connected the dots, gained a view of the end-to-end attack chain, and traced activities back to the infrastructure.

Disrupting BEC operations is one of the areas of focus of Microsoft’s Digital Crimes Unit (DCU), which works with law enforcement and industry partners to take down operational infrastructure used by cybercriminals. For the specific BEC operation discussed in this blog, industry partnership was critical to the disruption. As our research uncovered that attackers abused cloud service providers to perpetrate this campaign, we worked with Microsoft Threat Intelligence Center (MSTIC) to report our findings to multiple cloud security teams, who suspended the offending accounts, resulting in the takedown of the infrastructure.

Initial access via phishing

Using Microsoft 365 Defender threat data, we correlated the BEC campaign to a prior phishing attack. The credentials stolen at this stage are used by the attackers to access target mailboxes. It’s important to note that multi-factor authentication (MFA) blocks attackers from signing into mailboxes. Attacks like this can be prevented by enabling MFA.

Our analysis shows that shortly before the forwarding rules were created, the mailboxes received a phishing email with an HTML attachment. The phishing emails used the typical voice message lure. The emails originated from an external cloud provider’s address space.

Figure 2. Sample phishing email used to steal credential to be used for BEC attack

The HTML attachment contained JavaScript that dynamically decoded an imitation of the Microsoft sign-in page, with the username already populated.

Figure 3. Phishing page with user name prepopulated

When the target user entered their password, they were presented with animations and, eventually, a “File not found message”.

Figure 4. Phishing page with animation before eventually serving a fake error

Meanwhile, in the background, the JavaScript transmitted the credentials to the attackers via a redirector also hosted by an external cloud provider.

Figure 5. JavaScript code used to send stolen credentials to attackers

Persistence and exfiltration

Having already gained access to mailboxes via the credential phishing attack, attackers gained persistent data exfiltration channel via email forwarding rules (MITRE T114.003). During the course of our investigation of this campaign, we saw hundreds of compromised mailboxes in multiple organizations with forwarding rules consistently fitting one of patterns below:

 

Mailbox rule name Condition
o365 default If Body contains

  • invoice
  • payment
  • statement

Forward the email to
ex@exdigy[.]net

o365 (del) If Body contains ex@exdigy[.]net delete message

 

Mailbox rule name Condition
o365 default If Body contains

  • invoice
  • payment
  • statement

Forward the email to
in@jetclubs[.]biz

o365 (del) If Body contains in@jetclubs[.]biz delete message

These forwarding rules allowed attackers to redirect financial-themed emails to the attacker-controlled email addresses ex@exdigy.net and in@jetclubs.biz. The attackers also added rules to delete the forwarded emails from the mailbox to stay stealthy.

Figure 6. Alert in Microsoft 365 security center showing detection of forwarding rule creation

BEC infrastructure in the cloud

Our analysis revealed that the attack was supported by a robust cloud-based infrastructure. The attackers used this infrastructure to automate their operations at scale, including adding the rules, watching and monitoring compromised mailboxes, finding the most valuable victims, and dealing with the forwarded emails.

The attackers took steps to make it harder for analysts to connect their activities to one operation, for example, running distinct activities for different IPs and timeframes. The attack, however, was conducted from certain IP address ranges. We saw these commonalities in the user agents:

  • Credentials checks with user agent “BAV2ROPC”, which is likely a code base using legacy protocols like IMAP/POP3, against Exchange Online. This results in an ROPC OAuth flow, which returns an “invalid_grant” in case MFA is enabled, so no MFA notification is sent.
  • Forwarding rule creations with Chrome 79.
  • Email exfiltration with an POP3/IMAP client for selected targets.

We observed the above activities from IP address ranges belonging to an external cloud provider, and then saw fraudulent subscriptions that shared common patterns in other cloud providers, giving us a more complete picture of the attacker infrastructure.

The attackers used a well-defined worker structure in the VMs, where each VM executed only a specific operation, which explains why activities originated from different IP sources. The attackers also set up various DNS records that read very similar to existing company domains. These are likely used to blend into existing email conversations or used for more tailored phishing campaign against specific targets.

The attackers pulled various tools on the VMs. One of the tools was called “EmailRuler”, a C# application that uses ChromeDriver to automatically manipulate the compromised mailboxes. The stolen credentials and the state of the mailbox compromised are stored in a local MySQL database as well as the state of the mailbox compromise.

Figure 7. Decompilation of EmailRuler tool

In addition, we also observed that on selected compromised user accounts, the attacker attempted to pull emails from the mailbox. A tool called “Crown EasyEmail” in the attacker’s VMs was likely used for this activity, consistent with the observation of using a POP3/IMAP client.

Defending against BEC and cloud-based attacker infrastructure with Office 365

Business email compromise is a constant threat to enterprises. As this research shows, BEC attacks are very stealthy, with attackers hiding in plain sight by blending into legitimate traffic using IP ranges with high reputation and by conducting discrete activities at specific times and connections.

Microsoft empowers organizations to comprehensively defend multiplatform and multicloud environments against these types of attacks through a wide range of cross-domain solutions that include advanced pre-breach and post-breach protection capabilities. External email forwarding is now disabled by default in Office 365, significantly reducing the threat of BEC campaigns that use this technique, while giving organizations the flexibility to control external forwarding. Organizations can further reduce their attack surface by reducing or disabling the use of  legacy protocols like POP3/IMAP and enable multi-factor authentication for all users.

As BEC attacks continue to increase in scope and sophistication, organizations need advanced and comprehensive protection like that provided by Microsoft Defender for Office 365. Microsoft Defender for Office 365 protects against email threats using its multi-layered email filtering stack, which includes edge protection, sender intelligence, content filtering, and post-delivery protection. It uses AI and machine learning to detect anomalous account behavior, as well as emails that utilize user and domain impersonation. In addition to disabling external forwarding by default, Microsoft Defender for Office 365 raises alerts for detected suspicious forwarding activity, enabling security teams to investigate and remediate attacks. Features like Attack simulation training further helps organizations improve user awareness on phishing, BEC, and other threats.

Figure 8. Sample suspicious email forwarding activity alert in Microsoft Defender for Office 365

Signals from Microsoft Defender for Office 365 informs Microsoft 365 Defender, which correlates cross-domain threat intelligence to deliver coordinated defense. Expert insights from researchers who constantly monitor the threat landscape help enrich this intelligence with an understanding of attacker behaviors and motivations. AI and machine learning technologies in our security products use this intelligence to protect customers. These signals and insights also enable us to identify and take action on threats abusing cloud services.  The resulting takedown of this well-organized, cross-cloud BEC operation by multiple cloud security teams stresses the importance of industry collaboration in the fight against attacks and improving security for all.

Learn how Microsoft is combating business email compromise, one of the costliest security threats.

Stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

 

Stefan Sellmer, Microsoft 365 Defender Research Team

Nick Carr, Microsoft Threat Intelligence Center (MSTIC)

 

Advanced hunting query

Run the following query to locate forwarding rules:

let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| where Timestamp between(startTime .. endTime)
| where ActionType == "New-InboxRule"
| where (RawEventData contains "ex@exdigy.net" or RawEventData contains "in@jetclubs.biz")
or
(RawEventData has_any("invoice","payment","statement") and RawEventData has "BodyContainsWords")
| project Timestamp, AccountDisplayName, AccountObjectId, IPAddress

The post Behind the scenes of business email compromise: Using cross-domain threat data to disrupt a large BEC campaign appeared first on Microsoft Security.

Behind the scenes of business email compromise: Using cross-domain threat data to disrupt a large BEC campaign

June 14th, 2021 No comments

Microsoft 365 Defender researchers recently uncovered and disrupted a large-scale business email compromise (BEC) infrastructure hosted in multiple web services. Attackers used this cloud-based infrastructure to compromise mailboxes via phishing and add forwarding rules, enabling these attackers to get access to emails about financial transactions.

In this blog, we’ll share our technical analysis and journey of unraveling this BEC operation, from the phishing campaign and compromised mailboxes to the attacker infrastructure. This threat highlights the importance of building a comprehensive defense strategy, which should include strong pre-breach solutions that can prevent attackers from gaining access and creating persistence on systems in the first place, as well as advanced post-breach capabilities that detect malicious behavior, deliver rich threat data, and provide sophisticated hunting tools for investigating and resolving complex cyberattacks.

This investigation also demonstrates how cross-domain threat data, enriched with expert insights from analysts, drives protection against real-world threats, both in terms of detecting attacks through products like Microsoft Defender for Office 365, as well as taking down operations and infrastructures.

The use of attacker infrastructure hosted in multiple web services allowed the attackers to operate stealthily, characteristic of BEC campaigns. The attackers performed discrete activities for different IPs and timeframes, making it harder for researchers to correlate seemingly disparate activities as a single operation. However, even with the multiple ways that the attackers tried to stay under the radar, Microsoft 365 Defender’s cross-domain visibility uncovered the operation.

Figure 1. Signals from Microsoft 365 Defender services that researchers correlated to expose the BEC attack

This depth and breadth of this visibility is especially critical in detecting and stopping BEC because these attacks have minimal footprint, create very low signals that don’t rise to the top of a defender’s alert list, and tend to blend in with the usual noise of corporate network traffic. BEC attacks unfortunately can stay undetected until they cause real monetary loss because of limited or partial visibility provided by security solutions that don’t benefit from comprehensive visibility into email traffic, identities, endpoints, and cloud behaviors, and the ability to combine together isolated events and deliver a more sophisticated cross-domain detection approach.  Armed with intelligence on phishing emails, malicious behavior on endpoints, activities in the cloud, and compromised identities, Microsoft researchers connected the dots, gained a view of the end-to-end attack chain, and traced activities back to the infrastructure.

Disrupting BEC operations is one of the areas of focus of Microsoft’s Digital Crimes Unit (DCU), which works with law enforcement and industry partners to take down operational infrastructure used by cybercriminals. For the specific BEC operation discussed in this blog, industry partnership was critical to the disruption. As our research uncovered that attackers abused cloud service providers to perpetrate this campaign, we worked with Microsoft Threat Intelligence Center (MSTIC) to report our findings to multiple cloud security teams, who suspended the offending accounts, resulting in the takedown of the infrastructure.

Initial access via phishing

Using Microsoft 365 Defender threat data, we correlated the BEC campaign to a prior phishing attack. The credentials stolen at this stage were used by the attackers to access target mailboxes. It’s important to note that multi-factor authentication (MFA) blocks attackers from signing into mailboxes. Attacks like this can be prevented by enabling MFA.

Our analysis shows that shortly before the forwarding rules were created, the mailboxes received a phishing email with the typical voice message lure and an HTML attachment. The emails originated from an external cloud provider’s address space.

Figure 2. Sample phishing email used to steal credential to be used for BEC attack

The HTML attachment contained JavaScript that dynamically decoded an imitation of the Microsoft sign-in page, with the username already populated.

Figure 3. Phishing page with user name prepopulated

When the target user entered their password, they were presented with animations and, eventually, a “File not found message”.

Figure 4. Phishing page with animation before eventually serving a fake error

Meanwhile, in the background, the JavaScript transmitted the credentials to the attackers via a redirector also hosted by an external cloud provider.

Figure 5. JavaScript code used to send stolen credentials to attackers

Persistence and exfiltration

Having already gained access to mailboxes via the credential phishing attack, attackers gained persistent data exfiltration channel via email forwarding rules (MITRE T114.003). During the course of our investigation of this campaign, we saw hundreds of compromised mailboxes in multiple organizations with forwarding rules consistently fitting one of patterns below:

 

Mailbox rule name Condition
o365 default If Body contains

  • invoice
  • payment
  • statement

Forward the email to
ex@exdigy[.]net

o365 (del) If Body contains ex@exdigy[.]net delete message

 

Mailbox rule name Condition
o365 default If Body contains

  • invoice
  • payment
  • statement

Forward the email to
in@jetclubs[.]biz

o365 (del) If Body contains in@jetclubs[.]biz delete message

These forwarding rules allowed attackers to redirect financial-themed emails to the attacker-controlled email addresses ex@exdigy.net and in@jetclubs.biz. The attackers also added rules to delete the forwarded emails from the mailbox to stay stealthy.

Figure 6. Alert in Microsoft 365 security center showing detection of forwarding rule creation

BEC infrastructure in the cloud

Our analysis revealed that the attack was supported by a robust cloud-based infrastructure. The attackers used this infrastructure to automate their operations at scale, including adding the rules, watching and monitoring compromised mailboxes, finding the most valuable victims, and dealing with the forwarded emails.

The attackers took steps to make it harder for analysts to connect their activities to one operation, for example, running distinct activities for different IPs and timeframes. The attack, however, was conducted from certain IP address ranges. We saw these commonalities in the user agents:

  • Credentials checks with user agent “BAV2ROPC”, which is likely a code base using legacy protocols like IMAP/POP3, against Exchange Online. This results in an ROPC OAuth flow, which returns an “invalid_grant” in case MFA is enabled, so no MFA notification is sent.
  • Forwarding rule creations with Chrome 79.
  • Email exfiltration with an POP3/IMAP client for selected targets.

We observed the above activities from IP address ranges belonging to an external cloud provider, and then saw fraudulent subscriptions that shared common patterns in other cloud providers, giving us a more complete picture of the attacker infrastructure.

The attackers used a well-defined worker structure in the VMs, where each VM executed only a specific operation, which explains why activities originated from different IP sources. The attackers also set up various DNS records that read very similar to existing company domains. These are likely used to blend into existing email conversations or used for more tailored phishing campaign against specific targets.

The attackers pulled various tools on the VMs. One of the tools was called “EmailRuler”, a C# application that uses ChromeDriver to automatically manipulate the compromised mailboxes. The stolen credentials and the state of the mailbox compromised are stored in a local MySQL database as well as the state of the mailbox compromise.

Figure 7. Decompilation of EmailRuler tool

In addition, we also observed that on selected compromised user accounts, the attackers attempted to pull emails from the mailbox. A tool called “Crown EasyEmail” in the attacker’s VMs was likely used for this activity, consistent with the observation of using a POP3/IMAP client.

Defending against BEC and cloud-based attacker infrastructure with Office 365

Business email compromise is a constant threat to enterprises. As this research shows, BEC attacks are very stealthy, with attackers hiding in plain sight by blending into legitimate traffic using IP ranges with high reputation and by conducting discrete activities at specific times and connections.

Microsoft empowers organizations to comprehensively defend multiplatform and multicloud environments against these types of attacks through a wide range of cross-domain solutions that include advanced pre-breach and post-breach protection capabilities. External email forwarding is now disabled by default in Office 365, significantly reducing the threat of BEC campaigns that use this technique, while giving organizations the flexibility to control external forwarding. Organizations can further reduce their attack surface by reducing or disabling the use of  legacy protocols like POP3/IMAP and enable multi-factor authentication for all users.

As BEC attacks continue to increase in scope and sophistication, organizations need advanced and comprehensive protection like that provided by Microsoft Defender for Office 365. Microsoft Defender for Office 365 protects against email threats using its multi-layered email filtering stack, which includes edge protection, sender intelligence, content filtering, and post-delivery protection. It uses AI and machine learning to detect anomalous account behavior, as well as emails that utilize user and domain impersonation. In addition to disabling external forwarding by default, Microsoft Defender for Office 365 raises alerts for detected suspicious forwarding activity, enabling security teams to investigate and remediate attacks. Features like Attack simulation training further helps organizations improve user awareness on phishing, BEC, and other threats.

Figure 8. Sample suspicious email forwarding activity alert in Microsoft Defender for Office 365

Signals from Microsoft Defender for Office 365 informs Microsoft 365 Defender, which correlates cross-domain threat intelligence to deliver coordinated defense. Expert insights from researchers who constantly monitor the threat landscape help enrich this intelligence with an understanding of attacker behaviors and motivations. AI and machine learning technologies in our security products use this intelligence to protect customers. These signals and insights also enable us to identify and take action on threats abusing cloud services.  The resulting takedown of this well-organized, cross-cloud BEC operation by multiple cloud security teams stresses the importance of industry collaboration in the fight against attacks and improving security for all.

Learn how Microsoft is combating business email compromise, one of the costliest security threats.

Stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

 

Stefan Sellmer, Microsoft 365 Defender Research Team

Nick Carr, Microsoft Threat Intelligence Center (MSTIC)

 

Advanced hunting query

Run the following query to locate forwarding rules:

let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| where Timestamp between(startTime .. endTime)
| where ActionType == "New-InboxRule"
| where (RawEventData contains "ex@exdigy.net" or RawEventData contains "in@jetclubs.biz")
or
(RawEventData has_any("invoice","payment","statement") and RawEventData has "BodyContainsWords")
| project Timestamp, AccountDisplayName, AccountObjectId, IPAddress

The post Behind the scenes of business email compromise: Using cross-domain threat data to disrupt a large BEC campaign appeared first on Microsoft Security Blog.

Microsoft Defender for Endpoint now supports Windows 10 on Arm devices

April 5th, 2021 No comments

Today, we are excited to announce that Microsoft Defender for Endpoint support of Windows 10 on Arm devices is generally available. This expanded support is part of our continued efforts to extend Microsoft Defender for Endpoint capabilities across all the endpoints defenders need to secure.

Arm technology is enabling the digital transformation with innovative new form factors, better connectivity and mobile possibilities, instant-on technology, and amazing battery life. These elements also empower organizations to support the shift to remote and fluid work environments – a shift that requires a security-first mindset. As we continue to move forward in a new hybrid work environment, security needs to be an integral part of that change. Microsoft is committed to empowering defenders in their daily efforts to protect their organizations’ data and employees. This commitment is deeply ingrained in our DNA and reflected in the product investments that we make.

Microsoft’s investment in Windows 10 on Arm offers powerful, highly-mobile experiences, with security at the core. These devices are designed to take full advantage of the built-in protections available in Windows 10 such as encryption, data protection, and next gen antivirus and antimalware capabilities. Microsoft Defender for Endpoint compliments these security features with an industry leading, unified, cloud powered enterprise endpoint security platform that helps security teams prevent, detect, investigate and respond to advanced threats, while delivering secure and productive end user security experiences.

Security teams will find that there are no changes to the experience with regards to Arm based PCs. All the data, insights, and functionality in Microsoft Defender for Endpoint is exactly the same as its always been including things like device inventory, alerts, response actions, advanced hunting, and more, including the onboarding experience.

As always, many of our feature and capability enhancements and investments are driven by customer feedback. We thank our customers for their continued journey with us.

 

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

The post Microsoft Defender for Endpoint now supports Windows 10 on Arm devices appeared first on Microsoft Security.

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.