An Overview of the New Rhysida Ransomware Targeting the Healthcare Sector

By: Trend Micro Research
August 09, 2023
Read time: 7 min (1966 words)

Updated on August 9, 2023, 9:30 a.m. EDT: We updated the entry to include an analysis of current Rhysida ransomware samples’ encryption routine.  
Updated on August 14, 2023, 6:00 a.m. EDT: We updated the entry to include Trend XDR workbench alerts for Rhysida and its components.

Introduction

On August 4, 2023, the HHS’ Health Sector Cybersecurity Coordination Center (HC3) released a security alert about a relatively new ransomware called Rhysida (detected as Ransom.PS1.RHYSIDA.SM), which has been active since May 2023. In this blog entry, we will provide details on Rhysida, including its targets and what we know about its infection chain.

Who is behind the Rhysida ransomware?

Not much is currently known about the threat actors behind Rhysida in terms of origin or affiliations. According to the HC3 alert, Rhysida poses itself as a “cybersecurity team” that offers to assist victims in finding security weaknesses within their networks and system. In fact, the group’s first appearance involved the use of a victim chat support portal.

Who are Rhysida’s targets?

As mentioned earlier, Rhysida, which was previously known for targeting the education, government, manufacturing, and tech industries, among others — has begun conducting attacks on healthcare and public health organizations. The healthcare industry has seen an increasing number of ransomware attacks over the past five years.  This includes a recent incident involving Prospect Medical Holdings, a California-based healthcare system, that occurred in early August (although the group behind the attack has yet to be named as of writing).

Data from Trend Micro™ Smart Protection Network™ (SPN) shows a similar trend, where detections from May to August 2023 show that its operators are targeting multiple industries rather than focusing on just a single sector.

The threat actor also targets organizations around the world, with SPN data showing several countries where Rhysida binaries were detected, including Indonesia, Germany, and the United States.

Figure 1. The industry and country detection count for Rhysida ransomware based on Trend SPN data from May to August 2023
Figure 1. The industry and country detection count for Rhysida ransomware based on Trend SPN data from May to August 2023
Figure 1. The industry and country detection count for Rhysida ransomware based on Trend SPN data from May to August 2023

How does a Rhysida attack proceed?

Figure 2. The Rhysida ransomware infection chain
Figure 2. The Rhysida ransomware infection chain

Rhysida ransomware usually arrives on a victim’s machine via phishing lures, after which Cobalt Strike is used for lateral movement within the system.

Additionally, our telemetry shows that the threat actors execute PsExec to deploy PowerShell scripts and the Rhysida ransomware payload itself. The PowerShell script (g.ps1), detected as Trojan.PS1.SILENTKILL.A, is used by the threat actors to terminate antivirus-related processes and services, delete shadow copies, modify remote desktop protocol (RDP) configurations, and change the active directory (AD) password.

Interestingly, it appears that the script (g.ps1) was updated by the threat actors during execution, eventually leading us to a PowerShell version of the Rhysida ransomware.

Rhysida ransomware employs a 4096-bit RSA key and AES-CTR for file encryption, which we discuss in detail in a succeeding section. After successful encryption, it appends the .rhysida extension and drops the ransom note CriticalBreachDetected.pdf.

This ransom note is fairly unusual — instead of an outright ransom demand as seen in most ransom notes from other ransomware families, the Rhysida ransom note is presented as an alert from the Rhysida “cybersecurity team” notifying victims that their system has been compromised and their files encrypted. The ransom demand comes in the form of a “unique key” designed to restore encrypted files, which must be paid for by the victim.

Summary of malware and tools used by Rhysida

  • Malware: RHYSIDA, SILENTKILL, Cobalt Strike
  • Tools: PsExec
Initial AccessPhishingBased on external reports, Rhysida uses phishing lures for initial access
Lateral MovementPsExecMicrosoft tool used for remote execution
Cobalt Strike3rd party tool abused for lateral movement
Defense EvasionSILENTKILLMalware deployed to terminate security-related processes and services, delete shadow copies, modify RDP configurations, and change the AD password
ImpactRhysida ransomwareRansomware encryption
Table 1. A summary of the malware, tools, and exploits used by Rhysida

A closer look at Rhysida’s encryption routine 
After analyzing current Rhysida samples, we observed that the ransomware uses LibTomCrypt, an open-source cryptographic library, to implement its encryption routine. Figure 3 shows the procedures Rhysida follows when initializing its encryption parameters. 

Figure 3. Rhysida’s parameters for encryption
Figure 3. Rhysida’s parameters for encryption

Rhysida uses LibTomCrypt’s pseudorandom number generator (PRNG) functionalities for key and initialization vector (IV) generation. The init_prng function is used to initialize PRNG functionalities as shown in Figure 4. The same screenshot also shows how the ransomware uses the library’s ChaCha20 PRNG functionality.

rhysida_fig4
Figure 4. Rhysida’s use of the “init_prng” function

After the PRNG is initialized, Rhysida then proceeds to import the embedded RSA key and declares the encryption algorithm it will use for file encryption:

  •  
  • It will use the register_cipher function to “register” the algorithm (in this case, aes), to its table of usable ciphers.
  •  
  • It will use the find_cipher function to store the algorithm to be used (still aes), in the variable CIPHER.

Afterward, it will proceed to also register and declare aes for its Cipher Hash Construction (CHC) functionalities. 

Based on our analysis, Rhysida’s encryption routine follows these steps:

  1. After it reads file contents for encryption, it will use the initialized PRNG’s function, chacha20_prng_read, to generate both a key and an IV that are unique for each file.
  2. It will use the ctr_start function to initialize the cipher that will be used, which is aes (from the variable CIPHER), in counter or CTR mode.
  3. The generated key and IV are then encrypted with the rsa_encrypt_key_ex function.
  4. Once the key and IV are encrypted, Rhysida will proceed to encrypt the file using LibTomCrypt’s ctr_encrypt function.
Figure 5. Rhysida’s encryption routine
Figure 5. Rhysida’s encryption routine

Unfortunately, since each encrypted file has a unique key and IV — and only the attackers have a copy of the associated private key — decryption is currently not feasible.

How can organizations protect themselves from Rhysida and other ransomware families?

Although we are still in the process of fully analyzing Rhysida ransomware and its tools, tactics, and procedures (TTPs), the best practices for defending against ransomware attacks still holds true for Rhysida and other ransomware families.

Here are several recommended measures that organizations implement to safeguard their systems from ransomware attacks:

  • Create an inventory of assets and data
  • Review event and incident logs
  • Manage hardware and software configurations.
  • Grant administrative privileges and access only when relevant to an employee’s role and responsibilities.
  • Enforce security configurations on network infrastructure devices like firewalls and routers.
  • Establish a software whitelist permitting only legitimate applications
  • Perform routine vulnerability assessments
  • Apply patches or virtual patches for operating systems and applications
  • Keep software and applications up to date using their latest versions
  • Integrate data protection, backup, and recovery protocols
  • Enable multifactor authentication (MFA) mechanisms
  • Utilize sandbox analysis to intercept malicious emails
  • Regularly educate and evaluate employees’ security aptitude
  • Deploy security tools (such as XDR) which are capable of detecting abuse of legitimate applications

Indicators of compromise

Hashes

The indicators of compromise for this entry can be found here.

MITRE ATT&CK Matrix

Initial AccessT1566 PhishingBased on external reports, Rhysida uses phishing lures for initial access.
ExecutionT1059.003 Command and Scripting Interpreter: Windows Command ShellIt uses cmd.exe to execute commands for execution.
T1059.001 Command and Scripting Interpreter: PowerShellIt uses PowerShell to create scheduled task named Rhsd pointing to the ransomware.
PersistenceT1053.005 Scheduled Task/Job: Scheduled TaskWhen executed with the argument -S, it will create a scheduled task named Rhsd that will execute the ransomware
Defense EvasionT1070.004 Indicator Removal: File DeletionRhysida ransomware deletes itself after execution. The scheduled task (Rhsd) created would also be deleted after execution.
T1070.001 Indicator Removal: Clear Windows Event LogsIt uses wevtutil.exe to clear Windows event logs.
DiscoveryT1083 File and Directory DiscoveryIt enumerates and looks for files to encrypt in all local drives.
T1082 System Information DiscoveryObtains the following information:Number of processorsSystem information
ImpactT1490 Inhibit System RecoveryIt executes uses vssadmin to remove volume shadow copies
T1486 Data Encrypted for ImpactIt uses a 4096-bit RSA key and Cha-cha20 for file encryption.It avoids encrypting files with the following strings in their file name:.bat.bin.cab.cmd.com.cur.diagcab.diagcfg.diagpkg.drv.dll.exe.hlp.hta.ico.msi.ocx.ps1.psm1.scr.sys.ini.Thumbs.db.url.isoIt avoids encrypting files found in the following folders:$Recycle.BinBootDocuments and SettingsPerfLogsProgramDataRecoverySystem Volume InformationWindows$RECYCLE.BINApzDataIt appends the following extension to the file name of the encrypted files:.rhysidaIt encrypts all system drives from A to Z.It drops the following ransom note:{Encrypted Directory}\CriticalBreachDetected.pdf
T1491.001 Defacement: Internal DefacementIt changes the desktop wallpaper after encryption and prevents the user from changing it back by modifying the NoChangingWallpaper registry value.

Trend Micro Solutions

Trend solutions such as Apex One Deep Security,  Cloud One Workload SecurityWorry-Free Business Security,  Deep Discovery Web InspectorTitanium Internet Security, and Cloud Edge can help protect against attacks employed by the Rhysida ransomware.

The following solutions protect Trend customers from Rhysida attacks:

Trend Micro solutionsDetection Patterns / Policies / Rules
Trend Micro Apex OneTrend Micro Deep SecurityTrend Micro Titanium Internet SecurityTrend Micro Cloud One Workload Security Trend Micro Worry-Free Business Security ServicesRansom.Win64.RHYSIDA.SMRansom.Win64.RHYSIDA.THEBBBCRansom.Win64.RHYSIDA.THFOHBCTrojan.PS1.SILENTKILL.SMAJCTrojan.PS1.SILENTKILL.A
Trend Micro Apex OneTrend Micro Deep SecurityTrend Micro Worry-Free Business Security ServicesTrend Micro Titanium Internet Security
 
RAN4056TRAN4052T
Trend Micro Apex OneTrend Micro Deep Discovery Web InspectorDDI Rule ID: 597 – “PsExec tool detected”DDI Rule ID: 1847 – “PsExec tool detected – Class 2″DDI Rule ID: 4524 – “Possible Renamed PSEXEC Service – SMB2 (Request)”DDI Rule ID: 4466 – “PsExec Clones – SMB2 (Request)”DDI Rule ID: 4571 – “Possible Suspicious Named Pipe – SMB2 (REQUEST)”DDI Rule ID: 4570 – “COBALTSTRIKE – DNS(RESPONSE)”DDI Rule ID: 4152 – “COBALTSTRIKE – HTTP (Response)”DDI Rule ID: 4469 – “APT – COBALTSRIKE – HTTP (RESPONSE)”DDI Rule ID: 4594 – “COBALTSTRIKE – HTTP(REQUEST) – Variant 3″DDI Rule ID: 4153 – “COBALTSTRIKE – HTTP (Request) – Variant 2″DDI Rule ID: 2341 – “COBALTSTRIKE – HTTP (Request)”DDI Rule ID: 4390 – “CobaltStrike – HTTPS (Request)”DDI Rule ID: 4870 – “COBEACON DEFAULT NAMED PIPE – SMB2 (Request)”DDI Rule ID: 4861 – “COBEACON – DNS (Response) – Variant 3″DDI Rule ID: 4860 – “COBEACON – DNS (Response) – Variant 2″DDI Rule ID: 4391 – “COBEACON – DNS (Response)”
Trend Micro Apex OneTrend Micro Deep Security Trend Micro Worry-Free Business Security ServicesTrend Micro Titanium Internet SecurityTrend Micro Cloud EdgeTroj.Win32.TRX.XXPE50FFF071

Trend Micro XDR uses the following workbench alerts to protect customers from Rhysida-related attacks:

Cobalt Strike

Workbench AlertID
Anomalous Regsvr32 Execution Leading to Cobalt Strike63758d9f-4405-4ec5-b421-64aef7c85dca
COBALT C2 Connectionafd1fa1f-b8fc-4979-8bf7-136db80aa264
Early Indicator of Attack via Cobalt Strike0ddda3c1-dd25-4975-a4ab-b1fa9065568d
Lateral Movement of Cobalt Strike Beacon5c7cdb1d-c9fb-4b1d-b71f-9a916b10b513
Possible Cobalt Strike Beacon45ca58cc-671b-42ab-a388-d972ff571d68
Possible Cobalt Strike Beacon Active Directory Database Dumping1f103cab-9517-455d-ad08-70eaa05b8f8d
Possible Cobalt Strike Connection85c752b8-93c2-4450-81eb-52ec6161088e
Possible Cobalt Strike Privilege Escalation Behavior2c997bac-4fc0-43b4-8279-6f2e7cf723ae
Possible Fileless Cobalt Strikecf1051ba-5360-4226-8ffb-955fe849db53

PsExec

Workbench AlertID
Possible Credential Access via PSEXESVC Command Execution0b870a13-e371-4bad-9221-be7ad98f16d7
Possible Powershell Process Injection via PSEXEC7fe83eb8-f40f-43be-8edd-f6cbc1399ac0
Possible Remote Ransomware Execution via PsExec47fbd8f3-9fb5-4595-9582-eb82566ead7a
PSEXEC Execution By Processe011b6b9-bdef-47b7-b823-c29492cab414
Remote Execution of Windows Command Shell via PsExecb21f4b3e-c692-4eaf-bee0-ece272b69ed0
Suspicious Execution of PowerShell Parameters and PSEXEC26371284-526b-4028-810d-9ac71aad2536
Suspicious Mimikatz Credential Dumping via PsExec8004d0ac-ea48-40dd-aabf-f96c24906acf

SILENTKILL

Workbench AlertID
Possible Disabling of Antivirus Software64a633e4-e1e3-443a-8a56-7574c022d23f
Suspicious Deletion of Volume Shadow Copy5707562c-e4bf-4714-90b8-becd19bce8e5

Rhysida

Workbench AlertID
Ransom Note Detection (Real-time Scan)16423703-6226-4564-91f2-3c03f2409843
Ransomware Behavior Detection6afc8c15-a075-4412-98c1-bb2b25d6e05e
Ransomware Detection (Real-time Scan)2c5e7584-b88e-4bed-b80c-dfb7ede8626d
Scheduled Task Creation via Command Line05989746-dc16-4589-8261-6b604cd2e186
System-Defined Event Logs Clearing via Wevtutil639bd61d-8aee-4538-bc37-c630dd63d80f

Trend Micro Vision One hunting query

Trend Vision One customers can use the following hunting query to search for Rhysida within their system:

processCmd:”powershell.exe*\\*$\?.ps1″ OR (objectFilePath:”?:*\\??\\psexec.exe” AND processCmd:”*cmd.exe*\\??\\??.bat”)

Source :
https://www.trendmicro.com/en_us/research/23/h/an-overview-of-the-new-rhysida-ransomware.html

What does the Allow, Deny & Discard do on an Sonicwall Access Rule?

Last Update : 07/25/2022

Description

This article explains the 3 Actions available on an access rule

Resolution

Firewall rules, in general, based on concept of Implicit Deny.  Implicit Deny basically means that the default answer to whether a communication is allowed to transit the firewall is always No or Deny.  Therefore, the majority of Access Rules tend to be Allow.  A firewall will process a communication, inbound or outbound, based on the highest priority rule to the lowest.  Once a rule is found with conditions that match, that rule is executed by the firewall.  Allow, Deny & Discard is the action that the firewall will take for any communication that meets the conditions of a particular Access Rule.  Should a communication come into the firewall and no Access Rule meets the condition to allow it through, the firewall will Drop the communication.

Gen7 Add access rule dialog box

Image

Allow – This means that the firewall will permit the communication to continue through the firewall to its destination.

 NOTE: When creating a new access rule, the default Action on your firewall is set to Allow. 

Gen6 Add access rule dialog box

Deny – This means that when a communication is found to match the conditions of an Access Rule with the Deny action, the communication will not be permitted to proceed.  The communication is Dropped by the firewall.  A RST (reset) packet sent back to the originating device and the communication will be ended.  The RST packet is a communication that goes back to the originator of the traffic stating that the connection has been closed.  Under most circumstances, you should not have to write a Deny rule as Deny is the default action as described above.

 NOTE: Be advised that the RST packet is a normal part of network communications and is not unique to the SonicWall.

Discard – This option is much like Deny in that it will stop and drop the communication.  In this instance, the firewall will not send a RST packet as described in the Deny action above.  When the RST packet does not go back as with Deny, the originator has no confirmation that there is a device to respond at the IP address that is trying to reach.  Even if the originator suspects that it is a security function that is stopping it, they will still not know anything for sure.  This is essentially Stealth Mode applied at the Access Rule level.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/what-does-the-allow-deny-discard-do-on-an-access-rule/220725123655973/

Accessing Safemode when Sonicwall firewall is not reachable via CLI or GUI

Last Update : 05/09/2023

Description

This article describes how to put a SonicWall into safe mode through the GUI or through the command line interface (CLI).

You may require to follow this article for the following:

  • Firewall not accessible any longer due to configuration issues or other causes
  • Perform a firmware upgrade when it fails via normal means.
  • Perform a ROM/Safemode version upgrade.
  • Viewing the bootlogs or other diagnostic information.

 NOTE: Factory Reset via safemode is a required step when the device turns on but it is not reachable. A backup of the settings will be required after the factory reset or the firewall has to be reconfigured from scratch.

Resolution

ACCESSING SAFEMODE WHEN FIREWALL IS NOT REACHABLE VIA CLI/UI:

  1. Using a paperclip or similarly sized object, press and hold down the RST button located in the small hole on the front or back of the device (depending on the appliance) for at least 60 Seconds. Once the test light on the device becomes solid or begins to blink then the SonicWall is in safe mode.

     NOTE: On an NSsp 13700 or NSa Series appliance, press the button, but you do not need to hold it down.
  2. Connect a computer directly to the following Interface, depending on what model SonicWall you have, via an ethernet cable.
    1. Manually assign a static IP / subnet mask and Gateway (gateway will be the safemode firewall IP) on the connected computers NIC depending on the SonicWall appliance.
    2. Open the browser on the client connected to the firewall and go to: http://Enterherethe_Safemode_Firewall_IP

      Generation/ModelInterface to be used while in SafemodeSafemode Firewall IPRecommended IP to be set on clientGeneration 5X0192.168.168.168192.168.168.10 | 255.255.255.0Generation 6 & 7 | SOHO & TZ Devices
      X0192.168.168.168192.168.168.10 |  255.255.255.0Generation 6 & 7 | NSa/SM/NSsp DevicesMGMT Interface192.168.1.254192.168.1.10 | 255.255.255.0 CAUTION: Safemode is only available via HTTP so you have to manually type http:// otherwise the browser will automatically take you to https://.

       NOTE: For new safe mode options on Gen7, please refer: Safemode options on SonicWall Gen 7 devices

ACCESSING SAFEMODE VIA CLI

 NOTE: There is an E-CLI command safemode that restarts the firewall in SafeMode for Generation 7 (NSsp 13700 or NSa).

  1.  If you’re unfamiliar with how to access the SonicWall management using CLI please reference How to login to the appliance using the Command Line Interface (CLI).
  2. Once logged into the CLI, input the following commands.

    Safemode
    yes
  3. The SonicWall will reboot and enter safe mode.
    Image
  4. Reference the steps above to login to the safe mode GUI, beginning with “Connect a computer directly to the following Interface…”

Below you can find some additional information about what you can do in SafeMode:

Reset your firewall to Factory Default

  1. Select Current Firmware with Factory Default Settings and confirm.
  2. Your firewall will restart to factory default.
  3. After the reboot, login to the SonicWall management GUI via X0 Interface on the default firewall IP (192.168.168.168).
     NOTE: Make sure to modify the NIC Settings of the client connected to X0 to match the new firewall default settings (Gateway: 192.168.168.168 and NetMask: 255.255.255.0).

    Image

Upgrading the Gen 6 Firmware or ROM Version from Safe Mode

  1. Download the desired firmware version from MySonicWall.com or have the desired ROM Version on hand. ROM Packs are only available via SonicWall technical support.
     NOTE: Upgrading the ROM version only applies to Generation 6 NSA SonicWalls – 2600, 3600, 4600, 5600, and 6600. Unless you have been requested to upgrade the ROM version by SonicWall technical support do not attempt to do so.  
  2. Select Upload New Firmware and follow the prompt in the pop-up window to upload the firmware or ROM version to the SonicWall.
  3. You should now see the New Firmware or Uploaded ROM Pack on the safe mode GUI. You can boot to the new firmware or ROM by clicking the boot icon on the far right.
     NOTE: Booting to a new firmware or ROM version will reboot the SonicWall and exit safe mode. Make sure you’re completely finished with the SonicWall’s safe mode before selecting boot. 
  4. After the reboot, login to the SonicWall management GUI as you normally would. Navigate to Monitor | Current Status | System Status.
  5. On the Status screen you should see the new firmware version listed under Firmware Version or the new ROM version listed under Safemode Version.

Gen 7 (Using SafeMode to Upgrade Firmware):

  1. Once we enter the url in the web browser to get to the safe mode page on SonicWall Gen 7 devices, we need to authenticate using Maintenance Key.
  2. In the Maintenance Key prompt, type in or paste the key you got from MySonicWall and then click Authenticate. If your appliance is running SonicOS 7.0.1 and is not yet registered, use its Auth Code as the key. (To find the Maintenance key, please refer to: Safemode options on SonicWall Gen 7 devices)
    Image

  3. Safe mode page is displayed

    Image
  4. Click Upload Image, and then browse to the location where you saved the SonicOS firmware image, select the file, and click Upload.
  5. Click the Boot button in the row for Available Image Version and select one of the following:
    1. Boot Available Image with Current Configuration: Use this option to restart the appliance with your current configuration settings.
    2. Boot Available Image with Factory Default Configuration: Use this option to restart the appliance with factory default configuration settings. The configuration settings revert to default values, but logs and local backups remain in place.
    3. Boot Available Image with Backup Configuration: Use this option to restart the appliance with saved backup configuration settings. You can choose which backup to use. 

      Image
  6. In the confirmation dialog, click Boot to proceed.
  7. Wait while the firmware is installed, then booted. 
  8. Login to the SonicWall management GUI as you normally would.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/accessing-safemode-when-firewall-is-not-reachable-via-cli-or-gui/170507123738054/

How can I access the SonicWall Management Interface?

Last Update: 03/13/2023

Description

The SonicWall UTM appliance has a web-based graphical user interface for configuring the security appliance. This is the primary means of configuring the device.

Resolution

By default all the interfaces (ports like WAN,OPT or X1,X2) are unconfigured except the LAN or X0 interface. The LAN or X0 interface is pre-configured with an ip address of 192.168.168.168 and subnet mask of 255.255.255.0.

You could also determine the LAN or X0 interface IP address by using the Setup Tool (Windows SetupTool – https://software.sonicwall.com/UtilityTools/SetupTool.exe)

Image
Your UTM appliance package will contain, among other things, an Ethernet cable. Connect one end of the cable to the LAN or X0 interface of the SonicWall and the other end to a computer. Make sure the LED alongside LAN or X0 is lit solid.

As the UTM appliance is not pre-configured with DHCP, the computer connected to it must be configured with a static IP address. Set the computer IP address in the same subnet as the SonicWall LAN or X0.

 EXAMPLE:192.168.168.2 with subnet mask of 255.255.255.0.

Open an Internet browser and enter 192.168.168.168 in the address bar.

As this is the first time you are accessing the SonicWall UTM management interface, you will be presented with a wizard. You could follow the wizard to set a new admin password and other information. You could skip the wizard and login directly to the interface by clicking the click here link in the wizard prompt. 

Quick Configuration for Gen6 Appliances with SonicOS 6.5 & above.
Image

When attempting to login directly you will be prompted for a username and password. By default the username is admin and the password is password. Once successfully logged in you can change the password under Manage | Appliance | Base Settings | Administrator Name & Password.

Further configuration of the device can be done either manually, by navigating the tabs on the left-hand side of the interface, or by using the wizard. The wizard can be accessed by clicking on the Wizards icon at the top of the interface.

TROUBLESHOOTING
  • Make sure there is physical connectivity between the computer and the SonicWall.
  • It is always recommended to connect the computer directly to SonicWall instead of through a switch or hub.
  • The LAN or X0 interface LED should be lit solid. If the computer is a PC, the Network Connection Status should show connected.
  • Although SonicWall is Auto DBX capable, try a cross-over cable.
     TIP: If physical connection has been established but the user is unable to access the management interface try doing a ping to the IP address 192.168.168.168 from the computer.
    If the ping test passes and the user is unable to open the interface page in the browser,  try the following:
  1.  Reboot the SonicWall.
  2.  Clear the browser cache.

See also:

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/how-can-i-access-the-sonicwall-management-interface/170503695604558/

Sonicwall Application Rule Common Configurations

Last Update 03/26/2020

Description

This document explains in detail how the SonicWall rulebase works and provides common configurations.

Topics include:

  • Application Rule tips
  • The SonicOS rulebase
  • App Rules positive matching
  • Inspection of encrypted traffic
  • Methods of designing a rulebase

Resolution

The SonicOS Rulebase
SonicWall has two rulebases, one for Stateful Packet Inspection (SPI), and one for Deep Packet Inspection (DPI). The SPI rulebase deals with socket filters that are defined between source and destination address objects to a combination of destination port and protocol, or a range of ports, called a service. Optionally, source ports can also be defined within the service which is more useful for legacy UDP services than for modern services that randomize the source port. A connection is established with the first UDP packet, or after a successful TCP handshake. All other protocols behave like UDP and establish a connection with the first packet.

App Rules, in contrast, monitor traffic of established connections. When an application is detected and a rule matches, the rule action is applied such as dropping the connection.
Access Rules are processed top-down, which means that on the first rule that is matched, (counted from the top) the rule action is applied, and the rulebase is exited. No further rulebase processing follows. This is the industry standard implementation for SPI rules. In contrast, no industry standard implementation exists for App Rules. In addition to standard top-down behavior known from SPI rules, some vendors match top down, but do not drop out with the first match. SonicOS does something in-between: rule order is non-deterministic because rules are internally optimized for processing speed. App Rules cannot overlap. Per definition, only one rule can match. If a matching rule is found, the rule action is applied.

Access Rules have Allowed, Deny, and Discard actions. The difference between Deny and Discard is that Deny sends a segment with TCP RST flag back, whereas Discard silently drops the packet. It is best to use Discard in most cases, unless that breaks something like long living dormant TCP connections that lack higher layer health monitoring as can be found in some legacy custom applications. Both actions terminate the connection and remove it from the connection table. App Rules can apply various actions but Allowed is not one of them. The reason is that App Rules check on an already established connection. By the very nature on how DPI works, the connection has to be established so that the DPI engine can look for clues within the data traffic to determine the application.

Access Rules are enforced between zones that have interfaces assigned. One zone may match to one or multiple interfaces. App Rules are enforced on ingress of a zone, or globally. Both Access Rules and App Rules can be assigned address objects and address groups. Only one object can be assigned per rule. If multiple objects in a rule are desired, a group needs to be created. Groups can be nested.
In addition to defining source and destination address objects in App Rules, source address exclusions can be defined so that App Rules do not overlap. Both Access Rules and App Rules can have socket services assigned. In contrast to Access Rules, App Rules cannot have service groups. Services are less often used in App Rules because App Signatures generally match independent of sockets. The reason to assign a service is to limit application matches to one specific socket, such as an Application on a cleartext HTTP socket that needs to be dropped. App Rules also may match on indirect traffic such as DNS when inspecting a Web session on an HTTP socket. This is often not obvious. In addition to dropping the connection that carries the service, control connections, or peripheral connections like DNS can be targeted by signatures within one App. This is a reason that one typically wants to leave the socket out of the match criteria for an App Rule.

App Rules match on applications which is the main difference to Access Rules that only match on a socket. A variety of match objects can be defined to match within a certain context such as file names, as well as categories, applications, and application sub lists like Social Networking, Facebook, and Like button. The same connection can match many different applications such as HTTP and Netflix. Users are treated as a filter – after a rule was matched. Users are not part of the match criteria of the rule itself. Vendors are not consistent in the implementation of users. Many implement it like SonicWall but some also make the user a match criteria. In SonicOS, an action is applied to all include users minus those users that overlap with exclude users. There is only one rule check; no other rule check is performed regardless whether the user matches or not. Access Rules and App Rules are similar in their behavior to unmatched users. Access Rules apply the inverse of the action such as Deny instead of Allowed, or vice versa. App Rules do not have an Allowed action by their very nature. Unmatched users are simply not applied any action. If the action is Drop, not matched traffic is simply passed without logging. The same is true for the No Action that produces a log for matched users. Remember that not matched users include all user(s) in exclude and all other users not in include. In other words, a rule is applied only to all include users that are not in exclude. All non-defined users are treated as not matching.

Exclude is a concept present in many objects in SonicOS. An exclude is a minus to an include, which means applied to the rule is only what is left of the include, once the exclude was subtracted. No matching of the rule applies to anything in the exclude. This is a bit complicated, but exclude users only matters if also at least partially part of the include. An exclude that does not overlap with an include has no function. This is the same behavior for other object types.

The user concept in SonicOS is a filter after a rule match was made. Only the leftover of include users after subtracting excluded users is applied to that particular matched rule. Users that do not match are no longer processed in the rulebase. This is important to understand.

Image

App Rules
IF source:

  • src-zone
  • src-ip MINUS excluded src-ip

AND IF destination:

  • dst-ip

AND IF application:

  • Apps identified by DPI MINUS excluded Apps, limited to socket

THEN

  • user MINUS excluded users filter
  • action: Drop, BWM, no-DPI, log, nothing

App Rules Positive Matching

While an Access Rule can determine the socket within the first one to three segments within a connection, App Rules match can only be determined deeper into the connection life, after the connection was established. This puts positive matching at a conundrum. How for instance do you permit a connection with Netflix, before you even know that the connection carries Netflix? And how do you make sure after Netflix in a connection stream was detected, that it does not carry other traffic, such as tunneled VPN traffic?

These are interesting questions, and essentially, there is no precise solution. Vendors differ in the implementation of App Rules. Some vendors focus on winning over firewall operators that are used to
maintaining SPI rulebases with hundreds or thousands of simple rules, by hiding the abstracts of an App Rules under the hood. The nice thing is that operators can treat App Rules the same way as Access Rules. It is also nice that migrating an Access Rule base into next-gen land is as easy as swapping socket service objects for App objects. The big disadvantage of this approach is that this is a very rough interface abstraction. A hacker who studies that specific interface abstraction can make traffic look like Netflix and tunnel malicious traffic through a rule that allows Netflix traffic.

SonicWall decided for the sake of efficacy not to implement such user interface abstraction. With SonicOS App Rules follow very closely the inner working of the DPI engine. If an App is detected, the operator can decide what to do about traffic following the detection. If we want to allow Netflix traffic, we really do not care about detecting Netflix at all. We care about detecting traffic that is NOT Netflix so that we can drop this. Whatever we do not drop, is implicitly allowed at the end of the App Rule base. This is the opposite from an Access Rule base where everything is implicitly dropped at the end of the rulebase. Rules are written in a way to disallow all the things that we do not want in our network excluding those Apps that we want. The easiest way to do this is per category. We drop traffic for instance from the entire Multimedia category, with the exclusion of Netflix that we are allowing. This would drop any traffic for which an App Signature exists in the category Multimedia that is NOT Netflix. At the same time, we still can drop traffic from other categories such as Proxies and protect ourselves from an evasion attack.

Inspection of Encrypted Traffic

Access Rules work the same whether traffic is cleartext or encrypted – unless traffic is tunneled within an encrypted connection. For App Rules, all encrypted traffic looks like tunneled as the App detection has to happen within the encrypted traffic stream.
SonicOS solves this problem via DPI-SSL. DPI-SSL client-side intercepts traffic from a client, decrypts it, scans it, re-encrypts it and sends it off on its way to the server. On the return wing, the opposite happens. Vendors who do not implement such functionality fly blind. They have devices that can be easily evaded by SSL or SSH encrypted traffic that already today makes up over 60% of the Internet traffic.

Methods of Designing a Rulebase

The first decision that is made is whether a rule should be an Access Rule or an App Rule. If a rule does not contain a service, or a socket can be clearly defined, then an Access Rule is the better approach. If a rule uses a generic socket, or can run on dynamic sockets, then an Access Rule needs to be chosen. As described above, Access Rules can be negative or positive, hence explicitly permit traffic, or drop traffic. App Rules by design can only be negative. Also, remember that App Rules cannot overlap, hence unlike with Access Rules, rule order does not matter. The author prepared a worksheet where you can turn a positive match into a negative match for an entire category. To allow an application, you deny the entire App Category with the exception of the allowed application. This is a simple approach to configure a positive match on an App Rule.

When you design rules with users, make sure to summarize users into user groups for common applications that are dropped. Again, focus on what is dropped. If you have a combination of networks with users, and networks without users, make sure that you put these networks without users in the src-ip exclude field when referencing a user. Because if you do not do that, the rule is skipped as networks without users would not match any include users, the rule is skipped, and you drop out of the rulebase. Everything that you do not explicitly deny in an App Rules is automatically allowed, just the opposite from an Access Rule where everything that is not explicitly allowed is implicitly denied at the end of the rulebase.

Examples
Admin: YouTube, Vudu, Hulu
Faculty: YouTube and Vudu
Students: YouTube
Nobody: Netflix
Rule 1: Netflix DENY Admin, Faculty, Students
Rule 2: Hulu DENY Faculty, Students
Rule 3: Vudu: DENY Students
Rule 4: MULTIMEDIA except Netflix, Hulu, Vudu DENY all-users

Make use of the spreadsheet to carefully plan out your rulebase before configuring it. On Tab Applications, chose a category in column B. Then in columns D through H check the field to TRUE for the users you want this application allowed. If you do not use users, simply use column D only. Columns J through N is the negative representation, converting a positive match to a negative match as it is entered in an App Rule. App Rules can only drop a connection AFTER an App was recognized. Hence, we cannot permit an App explicitly. Create an App Rule where you deny all users that show TRUE in columns J through N for that application. Put those apps that are allowed, FALSE in J through N, into the exclude Apps. Keep in mind that in SonicOS App Rules cannot overlap. Create non-overlapping rules with the help of excludes. In App Rules, the user group is only applied to include users. All users that are not in include, or excluded, are dropping out of the rule base without any action, and the packet is allowed. If you need a final explicit deny rule, you build rules with all app categories that are not users and simply drop this traffic.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/application-rule-common-configurations/180208123013371/

Enable Remote Desktop (Windows 10, 11, Windows Server)

Last Updated: June 22, 2023 by Robert Allen

In this guide, you will learn how to enable Remote Desktop on Windows 10, 11, and Windows Server. I’ll also show you on to enable RDP using PowerShell and group policy.

Tip: Use a remote desktop connection manager to manage multiple remote desktop connections. You can organize your desktops and servers into groups for easy access.

Table of contents

In the diagram below, my admin workstation is PC1. I’m going to enable RDP on PC2, PC3, and Server1 so that I can remotely connect to them. RDP uses port TCP 3389. You can change the RDP listening port by modifying the registry.

Enable Remote Desktop on Windows 10

In this example, I’m going to enable remote desktop on PC2 that is running windows 10.

Step 1. Enable Remote Desktop

Right click the start menu and select system.

Under related settings click on Remote desktop.

Click the slider button to enable remote desktop.

You will get a popup to confirm that you want to enable Remote desktop. Click confirm.

Next, Click on Advanced Settings.

Make sure “Require computers to use Network Level Authentication to connect” is selected.

This setting will force the user to authenticate before it will start a remote desktop session. This setting will enable a layer of security and prevent unauthorized remote connections.

Step 2. Select Users Accounts

The next step is to ensure only specific accounts can use RDP.

By default, only members of the local administrators group will be allowed to connect using remote desktop.

To add or remove user accounts click on “select users that can remotely access this PC”.

To add a user click the Add button and search for the username.

In this example, I’m going to add a user Adam A. Anderson.

Tip. I recommend creating a domain group to allow RDP access. This will make it easier to manage and audit RDP access.

That was the last step, remote desktop is now enabled.

Let’s test the connection.

From PC1 I open Remote Desktop Connection and enter PC2.

I am prompted to enter credentials.

Success!

I now have a remote desktop connection to PC2.

In the screenshot below you can see I’m connected via console to PC1 and I have a remote desktop connection open to PC2.

Damware Mini Remote Control

Multiple monitor support. Reboot and wake sleeping computers remotely.

Remote access to Windows, Linux, and Mac OS X operating systems. In session chat, remote screenshot, file transfer, and more.

Download 14 Day Free Trial

Enable Remote Desktop on Windows 11

In this example, I’ll enable remote desktop on my Windows 11 computer (PC3).

Step 1. Enable Remote Desktop

Click on search.

Enter “remote desktop” and click on “Remote desktop settings”

Click the slider to enable remote desktop. You will get a popup to confirm.

Click the down arrow and verify “Require devices to use Network Level Authentication to connect” is enabled.

Remote Desktop is now enabled. In the next step, you will select which users are allowed to use remote desktop.

Step 2. Remote Desktop Users

By default, only members of the local administrators group can use remote desktop. To add additional users follow these steps.

Click on “Remote Desktop users”

Click on add and search or enter a user to add. In this example, I’ll add the user adam.reed.

Now I’ll test if remote desktop is working.

From my workstation PC1 I’ll create a remote desktop connection to PC3 (windows 11).

Enter the password to connect.

The connection is good!

You can see in the screenshot below I’m on the console of PC1 and I have a remote desktop connection to PC3 that is running Windows 11.

Enable Remote Desktop on Windows Server

In this example, I’ll enable remote desktop on Windows Server 2022.

Step 1. Enable Remote Desktop.

Right click the start menu and select System.

On the settings screen under related settings click on “Remote desktop”.

Click the slider button to enable remote desktop.

You will get a popup to confirm that you want to enable Remote desktop. Click confirm.

Click on Advanced settings.

Make sure “Require computers to use Network level Authentication to connect” is enabled.

Remote desktop is now enabled, the next step is to select users that can remotely access the PC.

Step 2. Select User accounts

By default, only members of the local administrators group will be allowed to connect using remote desktop.

To add additional users click on click on “select users that can remotely access this pc”.

Next, click add then enter or search for users to add. In this example, I’ll add the user robert.allen. Click ok.

Now I’ll test if remote desktop is working on my Windows 2022 server.

From my workstation (pc2) I open the remote desktop connection client and enter srv-vm1and click connect. Enter my username and password and click ok.

Awesome, it works!

I’ve established a remote session to my Windows 2022 server from my Windows 10 computer.

PowerShell Enable Remote Desktop

To enable Remote Desktop using PowerShell use the command below. This will enable RDP on the local computer.

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

You can use the below PowerShell command to check if remote desktop is enabled.


if ((Get-ItemProperty "hklm:\System\CurrentControlSet\Control\Terminal Server").fDenyTSConnections -eq 0) { write-host "RDP is Enabled" } else { write-host "RDP is NOT enabled" }

To enable remote desktop remotely you can use the invoke-command. This requires PS remoting to be enabled, check out my article on remote powershell for more details.

In this example, I’ll enable remote desktop on the remote computer PC2.

invoke-command -ComputerName pc2 -scriptblock {Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0} 

Group Policy Configuration to allow RDP

If you need to enable and manage the remote desktop settings on multiple computers then you should use Group Policy or intune.

Follow the steps below to create a new GPO.

Step 1. Create a new GPO

Open the group policy management console and right click the OU or root domain to create a new GPO.

In this example, I’m going to create a new GPO on my ADPPRO Computers OU, this OU has all my client computers.

Give the GPO a name.

Edit the GPO and browse to the following policy setting.

Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections;

Enable the policy setting -> Allow users to connect remotely by using Remote Desktop Services

That is the only policy setting that needs to be enabled to allow remote desktop

Step 2. Update Computer GPO

The GPO policies will auto refresh on remote computers every 90 minutes.

To manually update GPO on a computer run the gpupdate command.

When remote desktop is managed with group policy the settings will be greyed out. This will allow you to have consistent settings across all your computers. It will also prevent users or the helpdesk from modifying the settings.

That’s a wrap.

I just showed you several ways to enable remote desktop on Windows computers. If you are using Active Directory with domain joined computers then enabling RDP via group policy is the best option.

Related Articles

Recommended: Active Directory Permissions Reporting Tool

The ARM Permissions Reporting Tool helps you monitor, analyze, and report on the permissions assigned to users, groups, computers, and organizational units in your Active Directory

You can easily identify who has what permissions, where they came from, and when they were granted or revoked. You can also generate compliance-ready reports for various standards and regulations, such as HIPAA, PCI DSS, SOX, and GDPR

Get instant visibility into user and group permissions.

Download Free Trial

Source :
https://activedirectorypro.com/enable-remote-desktop-windows/

Configuring Azure AD Password Policy

July 12, 2023

The Azure Active Directory password policy defines the password requirements for tenant users, including password complexity, length, password expiration, account lockout settings, and some other parameters. In this article, we’ll take a look into how to manage a password policy in Azure AD.

Azure AD has a default password policy applied to all accounts that are created in the cloud (not synchronized from on-premises Active Directory via Azure AD Connect).

It defines the following settings that cannot be changed by the Azure/Microsoft 365 tenant administrator:

  • Allowed characters: A-Z , a-z , 0-9 , space and special symbols @ # $ % ^ & * – _ ! + = [ ] { } | \ : ‘ , . ? / ` ~ ” ( )
  • Password complexity: at least 3 out of 4 character groups (uppercase, lowercase, numbers, and symbols)
  • Password length: minimum 8, maximum 256 characters
  • The user cannot use the previous password

Contents:

How to Change Password Expiration Policy in Azure AD

By default, a user’s password never expires in Azure AD (Microsoft 365). But you can enable the password expiration through the Microsoft 365 Admin Center:

  1. Go to Microsoft 365 Admin Center -> Settings -> Security & Privacy -> Password expiration policy;
  2. Disable the option Set password to never expire (recommended)Enable password expiration in Azure AD
  3. In this case:
    Password expiration set to 90 days
    The notification to change your password will start to be displayed 14 days before the expiry date.

Microsoft recommends that you do not enable password expiration if your Azure users use Multi-Factor Authentication (MFA).

You can use the MSOnline PowerShell module to change user password expiration settings. Just install the module (if needed) and connect to your tenant:

Install-Module MSOnline
Connect-MsolService

Check the current password expiration policy settings in Azure AD:

Get-MsolPasswordPolicy -DomainName woshub.com

ExtensionData NotificationDays ValidityPeriod
System.Runtime.Serialization.ExtensionDataObject 14 2147483647
Get-MsolPasswordPolicy: check password expiration settings powershell

You can change the password expiration policy and notification settings in Azure AD with PowerShell:

Set-MsolPasswordPolicy -DomainName woshub.com -ValidityPeriod 180 -NotificationDays 21

You can manage password expiration settings for a specific user using the Azure AD module:

Connect-AzureAD

Enable the Password never expires option for a specific user:

Set-AzureADUser -ObjectId "maxadm@woshub.com" -PasswordPolicies DisablePasswordExpiration

View the user’s password expiration date:

Get-AzureADUser -ObjectId "maxadm@woshub.com"|Select-Object @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

Set an individual user's password to never expire in Azure AD
PasswordNeverExpires
--------------------
True

Enable password expiration for the user:

Set-AzureADUser -ObjectId "maxadm@woshub.com" -PasswordPolicies None

Account Lockout Settings in Azure AD

One more parameter of the Azure password policy available for the administrator to configure is the user lockout rules in case of entering an incorrect password. By default, an account is locked for 1 minute after 10 failed attempts to authenticate using an incorrect password. Note that the lockout time is extended following each next unsuccessful sign-in attempt.

You can configure the lockout settings in the following section of the Azure Portal -> Azure Active Directory -> Security -> Authentication methods —> Password protection.

The options available for you to change are:

  • Lockout threshold – the number of unsuccessful sign-in attempts before the account is locked out (10 by default);
  • Lockout duration in seconds – 60 seconds by default.
Configure Password Protection in Azure

If their account is locked out, an Azure user will see the following notification:

Your account is temporarily locked to prevent unauthorized use. Try again later, and if you still have trouble, contact your admin.
Your Microsoft account is temporarily locked to prevent unauthorized use

Learn how to check user sign-in logs in Azure AD.

Prevent Using Weak and Popular Passwords in Azure AD

There is a separate Azure AD Password Protection feature that allows you to block the use of weak and popular passwords (such as P@ssw0rdPa$$word, etc.).

You can use the DSInternals PowerShell module to check the on-premises Active Directory for weak user passwords.

You can define your own list of weak passwords in Azure Active Directory -> Security -> Authentication methods —> Password protection. Enable the option Enforce custom list and add a list of passwords you want to ban (up to 1000 passwords).

When an Azure AD user attempts to change their password to one of the banned list, a notification is displayed:

Unfortunately, you can’t use that password because it contains words or characters that have been blocked by your administrator. Please try again with a different password.
Unfortunately, you can’t use that password because it contains words or characters that have been blocked by your administrator

These settings are applied by default only to cloud users in Azure.

If you want to apply a banned password list to the local Active Directory DS users, here’s what you need to do:

  1. Make sure you have Azure AD Premium P1 or P2 subscription;
  2. Enable the option Enable password protection on Windows Server Active Directory;
  3. The default configuration enables only the audit of the prohibited password use. So, after the testing, switch the Mode option to Enforced;
  4. Deploy the Azure AD Password Protection Proxy Service (AzureADPasswordProtectionProxySetup.msi) on one of the on-premises hosts;
  5. Install Azure AD Password Protection (AzureADPasswordProtectionDCAgentSetup.msi) on all the ADDS domain controllers.

If you want the Azure password policy to be applied to users synchronized from AD DS via Azure AD Connect, you must enable the option EnforceCloudPasswordPolicyForPasswordSyncedUsers:

Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers -Enable $true

Ensure that you have configured a sufficiently strong domain password policy in your on-premises Active Directory. Otherwise, synchronized users can set any password, including those that are weak and insecure.

In this case, when a user’s password is changed or reset in on-premises Active Directory, the user is checked against the list of banned passwords in Azure.

If you have Azure AD Connect sync enabled, you can use your own password policies from on-premises Active Directory to apply to cloud users. To do this, you need to create a Fine Grained Security password policy in the on-premises AD and link it to a group containing the users synchronized with the cloud. In this case, Azure Active Directory will follow the password policy of your local domain.

Source :
https://woshub.com/azure-ad-password-policy/

The five-day job: A BlackByte ransomware intrusion case study

July 6, 2023

As ransomware attacks continue to grow in number and sophistication, threat actors can quickly impact business operations if organizations are not well prepared. In a recent investigation by Microsoft Incident Response (previously known as Microsoft Detection and Response Team – DART) of an intrusion, we found that the threat actor progressed through the full attack chain, from initial access to impact, in less than five days, causing significant business disruption for the victim organization.

Our investigation found that within those five days, the threat actor employed a range of tools and techniques, culminating in the deployment of BlackByte 2.0 ransomware, to achieve their objectives. These techniques included:

  • Exploitation of unpatched internet-exposed Microsoft Exchange Servers
  • Web shell deployment facilitating remote access
  • Use of living-off-the-land tools for persistence and reconnaissance
  • Deployment of Cobalt Strike beacons for command and control (C2)
  • Process hollowing and the use of vulnerable drivers for defense evasion
  • Deployment of custom-developed backdoors to facilitate persistence
  • Deployment of a custom-developed data collection and exfiltration tool
BlackByte 2.0 ransomware attack chain by order of stages: initial access and privilege escalation, persistence and command and control, reconnaissance, credential access, lateral movement, data staging and exfiltration, and impact.
Figure 1. BlackByte 2.0 ransomware attack chain

In this blog, we share details of our investigation into the end-to-end attack chain, exposing security weaknesses that the threat actor exploited to advance their attack. As we learned from Microsoft’s tracking of ransomware attacks and the cybercriminal economy that enables them, disrupting common attack patterns could stop many of the attacker activities that precede ransomware deployment. This case highlights that common security hygiene practices go a long way in preventing, identifying, and responding to malicious activity as early as possible to mitigate the impact of ransomware attacks. We encourage organizations to follow the outlined mitigation steps, including ensuring that internet-facing assets are up to date and configured securely. We also share indicators of compromise, detection details, and hunting guidance to help organizations identify and respond to these attacks in their environments.  

Forensic analysis

Initial access and privilege escalation

To obtain initial access into the victim’s environment, the threat actor was observed exploiting the ProxyShell vulnerabilities CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207 on unpatched Microsoft Exchange Servers. The exploitation of these vulnerabilities allowed the threat actor to:

  • Attain system-level privileges on the compromised Exchange host
  • Enumerate LegacyDN of users by sending Autodiscover requests, including SIDs of users
  • Construct a valid authentication token and use it against the Exchange PowerShell backend
  • Impersonate domain admin users and create a web shell by using the New-MailboxExportRequest cmdlet
  • Create web shells to obtain remote control on affected servers

The threat actor was observed operating from the following IP to exploit ProxyShell and access the web shell:

  • 185.225.73[.]244

Persistence

Backdoor

After gaining access to a device, the threat actor created the following registry run keys to run a payload each time a user signs in:

Registry keyValue nameValue data
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run  MsEdgeMsErundll32 C:\Users\user\Downloads\api-msvc.dll,Default  
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run  MsEdgeMsErundll32 C:\temp\api-msvc.dll,Default  
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run  MsEdgeMsErundll32 C:\systemtest\api-system.png,Default

The file api-msvc.dll (SHA-256: 4a066569113a569a6feb8f44257ac8764ee8f2011765009fdfd82fe3f4b92d3e) was determined to be a backdoor capable of collecting system information, such as the installed antivirus products, device name, and IP address. This information is then sent via HTTP POST request to the following C2 channel:

  • hxxps://myvisit[.]alteksecurity[.]org/t

The organization was not using Microsoft Defender Antivirus, which detects this malware as Trojan:Win32/Kovter!MSR, as the primary antivirus solution, and the backdoor was allowed to run.

An additional file, api-system.png, was identified to have similarities to api-msvc.dll. This file behaved like a DLL, had the same default export function, and also leveraged run keys for persistence.

Cobalt Strike Beacon

The threat actor leveraged Cobalt Strike to achieve persistence. The file sys.exe (SHA-256: 5f37b85687780c089607670040dbb3da2749b91b8adc0aa411fd6280b5fa7103), detected by Microsoft Defender Antivirus as Trojan:Win64/CobaltStrike!MSR, was determined to be a Cobalt Strike Beacon and was downloaded directly from the file sharing service temp[.]sh:

  • hxxps://temp[.]sh/szAyn/sys.exe

This beacon was configured to communicate with the following C2 channel:

  • 109.206.243[.]59:443

AnyDesk

Threat actors leverage legitimate remote access tools during intrusions to blend into a victim network. In this case, the threat actor utilized the remote administration tool AnyDesk, to maintain persistence and move laterally within the network. AnyDesk was installed as a service and was run from the following paths:

  • C:\systemtest\anydesk\AnyDesk.exe
  • C:\Program Files (x86)\AnyDesk\AnyDesk.exe
  • C:\Scripts\AnyDesk.exe

Successful connections were observed in the AnyDesk log file ad_svc.trace involving anonymizer service IP addresses linked to TOR and MULLVAD VPN, a common technique that threat actors employ to obscure their source IP ranges.

Reconnaissance

We found the presence and execution of the network discovery tool NetScan being used by the threat actor to perform network enumeration using the following file names:

  • netscan.exe (SHA-256:1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e)
  • netapp.exe (SHA-256:1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e)

Additionally, execution of AdFind (SHA-256: f157090fd3ccd4220298c06ce8734361b724d80459592b10ac632acc624f455e), an Active Directory reconnaissance tool, was observed in the environment.

Credential access

Evidence of likely usage of the credential theft tool Mimikatzwas also uncovered through the presence of a related log file mimikatz.log. Microsoft IR assesses that Mimikatz was likely used to attain credentials for privileged accounts.

Lateral movement

Using compromised domain admin credentials, the threat actor used Remote Desktop Protocol (RDP) and PowerShell remoting to obtain access to other servers in the environment, including domain controllers.

Data staging and exfiltration

In one server where Microsoft Defender Antivirus was installed, a suspicious file named explorer.exe was identified, detected as Trojan:Win64/WinGoObfusc.LK!MT, and quarantined. However, because tamper protection wasn’t enabled on this server, the threat actor was able to disable the Microsoft Defender Antivirus service, enabling the threat actor to run the file using the following command:

explorer.exe P@$$w0rd

After reverse engineering explorer.exe, we determined it to be ExByte, a GoLang-based tool developed and commonly used in BlackByte ransomware attacks for collection and exfiltration of files from victim networks. This tool is capable of enumerating files of interest across the network and, upon execution, creates a log file containing a list of files and associated metadata. Multiple log files were uncovered during the investigation in the path:

  • C:\Exchange\MSExchLog.log

Analysis of the binary revealed a list of file extensions that are targeted for enumeration.

Figure-2.-Binary-analysis-showing-file-extensions-enumerated-by-explorer.exe_
Figure 2. Binary analysis showing file extensions enumerated by explorer.exe

Forensic analysis identified a file named data.txt that was created and later deleted after ExByte execution. This file contained obfuscated credentials that ExByte leveraged to authenticate to the popular file sharing platform Mega NZ using the platform’s API at:

  • hxxps://g.api.mega.co[.]nz
Figure 3. Binary analysis showing explorer.exe functionality for connecting to file sharing service MEGA NZ

We also determined that this version of Exbyte was crafted specifically for the victim, as it contained a hardcoded device name belonging to the victim and an internal IP address.

ExByte execution flow

Upon execution, ExByte decodes several strings and checks if the process is running with privileged access by reading \\.\PHYSICALDRIVE0:

  • If this check fails, ShellExecuteW is invoked with the IpOperation parameter RunAs, which runs explorer.exe with elevated privileges.

After this access check, explorer.exe attempts to read the data.txt file in the current location:

  • If the text file doesn’t exist, it invokes a command for self-deletion and exits from memory:
C:\Windows\system32\cmd.exe /c ping 1.1.1.1 -n 10 > nul & Del <PATH>\explorer.exe /F /Q
  • If data.txt exists, explorer.exe reads the file, passes the buffer to Base64 decode function, and then decrypts the data using the key provided in the command line. The decrypted data is then parsed as JSON below and fed for login function:
{    “a”:”us0”,    “user”:”<CONTENT FROM data.txt>”}

Finally, it forms a URL for sign-in to the API of the service MEGA NZ:

  • hxxps://g.api.mega.co[.]nz/cs?id=1674017543

Data encryption and destruction

On devices where files were successfully encrypted, we identified suspicious executables, detected by Microsoft Defender Antivirus as Trojan:Win64/BlackByte!MSR, with the following names:

  • wEFT.exe
  • schillerized.exe

The files were analyzed and determined to be BlackByte 2.0 binaries responsible for encryption across the environment. The binaries require an 8-digit key number to encrypt files.

Two modes of execution were identified:

  • When the -s parameter is provided, the ransomware self-deletes and encrypts the machine it was executed on.
  • When the -a parameter is provided, the ransomware conducts enumeration and uses an Ultimate Packer Executable (UPX) packed version of PsExec to deploy across the network. Several domain admin credentials were hardcoded in the binary, facilitating the deployment of the binary across the network.

Depending on the switch (-s or -a), execution may create the following files:

  • C:\SystemData\M8yl89s7.exe (UPX-packed PsExec with a random name; SHA-256: ba3ec3f445683d0d0407157fda0c26fd669c0b8cc03f21770285a20b3133098f)
  • C:\SystemData\wEFT.exe (Additional BlackByte binary)
  • C:\SystemData\MsExchangeLog1.log (Log file)
  • C:\SystemData\rENEgOtiAtES (A vulnerable (CVE-2019-16098) driver RtCore64.sys used to evade detection by installed antivirus software; SHA-256: 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd)
  • C:\SystemData\iHu6c4.ico (Random name – BlackBytes icon)
  • C:\SystemData\BB_Readme_file.txt (BlackByte ReadMe file)
  • C:\SystemData\skip_bypass.txt (Unknown)

BlackByte 2.0 ransomware capabilities

Some capabilities identified for the BlackByte 2.0 ransomware were:

  • Antivirus bypass
    • The file rENEgOtiAtES created matches RTCore64.sys, a vulnerable driver (CVE-2049-16098) that allows any authenticated user to read or write to arbitrary memory
    • The BlackByte binary then creates and starts a service named RABAsSaa calling rENEgOtiAtES, and exploits this service to evade detection by installed antivirus software
  • Process hollowing
    • Invokes svchost.exe, injects to it to complete device encryption, and self-deletes by executing the following command:
      • cmd.exe /c ping 1.1.1.1 -n 10 > Nul & Del “PATH_TO_BLACKBYTE” /F /Q
  • Modification / disabling of Windows Firewall
    • The following commands are executed to either modify existing Windows Firewall rules, or to disable Windows Firewall entirely:
      • cmd /c netsh advfirewall set allprofiles state off
      • cmd /c netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes
      • cmd /c netsh advfirewall firewall set rule group=”Network Discovery” new enable=Yes
  • Modification of volume shadow copies
    • The following commands are executed to destroy volume shadow copies on the machine:
      • cmd /c vssadmin Resize ShadowStorge /For=B:\ /On=B:\ /MaxSize=401MB
      • cmd /c vssadmin Resize ShadowStorage /For=B:\ /On=B:\ /MaxSize=UNBOUNDED
  • Modification of registry keys/values
    • The following commands are executed to modify the registry, facilitating elevated execution on the device:
      • cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
      • cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLinkedConnections /t REG_DWORD /d 1 /f
      • cmd /c reg add HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
  • Additional functionality
    • Ability to terminate running services and processes
    • Ability to enumerate and mount volumes and network shares for encryption
    • Perform anti-forensics technique timestomping (sets the file time of encrypted and ReadMe file to 2000-01-01 00:00:00)
    • Ability to perform anti-debugging techniques

Recommendations

To guard against BlackByte ransomware attacks, Microsoft recommends the following:

  • Ensure that you have a patch management process in place and that patching for internet-exposed devices is prioritized; Understand and assess your cyber exposure with advanced vulnerability and configuration assessment tools like Microsoft Defender Vulnerability Management
  • Implement an endpoint detection and response (EDR) solution like Microsoft Defender for Endpoint to gain visibility into malicious activity in real time across your network
  • Ensure antivirus protections are updated regularly by turning on cloud-based protection and that your antivirus solution is configured to block threats
  • Enable tamper protection to prevent components of Microsoft Defender Antivirus from being disabled
  • Block inbound traffic from IPs specified in the indicators of compromise section of this report
  • Block inbound traffic from TOR exit nodes
  • Block inbound access from unauthorized public VPN services
  • Restrict administrative privileges to prevent authorized system changes

Conclusion

BlackByte ransomware attacks target organizations that have infrastructure with unpatched vulnerabilities.  As outlined in the Microsoft Digital Defense Report, common security hygiene practices, including keeping systems up to date, could protect against 98% of attacks.

As new tools are being developed by threat actors, a modern threat protection solution like Microsoft 365 Defender is necessary to prevent and detect the multiple techniques used in the attack chain, especially where the threat actor attempts to evade or disable specific defense mechanisms. Hunting for malicious behavior should be performed regularly in order to detect potential attacks that could evade detections, as a complementary activity for continuous monitoring from security tools alerts and incidents.

To understand how Microsoft can help you secure your network and respond to network compromise, visit https://aka.ms/MicrosoftIR.

Microsoft 365 Defender detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

  • Trojan:Win32/Kovter!MSR
  • Trojan:Win64/WinGoObfusc.LK!MT
  • Trojan:Win64/BlackByte!MSR
  • HackTool:Win32/AdFind!MSR
  • Trojan:Win64/CobaltStrike!MSR

Microsoft Defender for Endpoint

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

  • ‘CVE-2021-31207’ exploit malware was detected
  • An active ‘NetShDisableFireWall’ malware in a command line was prevented from executing.
  • Suspicious registry modification.
  • ‘Rtcore64’ hacktool was detected
  • Possible ongoing hands-on-keyboard activity (Cobalt Strike)
  • A file or network connection related to a ransomware-linked emerging threat activity group detected
  • Suspicious sequence of exploration activities
  • A process was injected with potentially malicious code
  • Suspicious behavior by cmd.exe was observed
  • ‘Blackbyte’ ransomware was detected

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

  • CVE-2021-34473
  • CVE-2021-34523
  • CVE-2021-31207
  • CVE-2019-16098

Hunting queries

Microsoft 365 Defender

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

ProxyShell web shell creation events

DeviceProcessEvents| where ProcessCommandLine has_any ("ExcludeDumpster","New-ExchangeCertificate") and ProcessCommandLine has_any ("-RequestFile","-FilePath")

Suspicious vssadmin events

DeviceProcessEvents| where ProcessCommandLine has_any ("vssadmin","vssadmin.exe") and ProcessCommandLine has "Resize ShadowStorage" and ProcessCommandLine has_any ("MaxSize=401MB"," MaxSize=UNBOUNDED")

Detection for persistence creation using Registry Run keys

DeviceRegistryEvents | where ActionType == "RegistryValueSet" | where (RegistryKey has @"Microsoft\Windows\CurrentVersion\RunOnce" and RegistryValueName == "MsEdgeMsE")      or (RegistryKey has @"Microsoft\Windows\CurrentVersion\RunOnceEx" and RegistryValueName == "MsEdgeMsE")    or (RegistryKey has @"Microsoft\Windows\CurrentVersion\Run" and RegistryValueName == "MsEdgeMsE")| where RegistryValueData startswith @"rundll32"| where RegistryValueData endswith @".dll,Default"| project Timestamp,DeviceId,DeviceName,ActionType,RegistryKey,RegistryValueName,RegistryValueData

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.

Indicators of compromise

The table below shows IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

IndicatorTypeDescription
4a066569113a569a6feb8f44257ac8764ee8f2011765009fdfd82fe3f4b92d3eSHA-256api-msvc.dll (Backdoor installed through RunKeys)
5f37b85687780c089607670040dbb3da2749b91b8adc0aa411fd6280b5fa7103SHA-256sys.exe (Cobalt Strike Beacon)
01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fdSHA-256rENEgOtiAtES (Vulnerable driver RtCore64.sys created by BlackByte binary)
ba3ec3f445683d0d0407157fda0c26fd669c0b8cc03f21770285a20b3133098fSHA-256[RANDOM_NAME].exe (UPX Packed PsExec created by BlackByte binary)
1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738eSHA-256“netscan.exe”, “netapp.exe (Netscan network discovery tool)
f157090fd3ccd4220298c06ce8734361b724d80459592b10ac632acc624f455eSHA-256AdFind.exe (Active Directory information gathering tool)
hxxps://myvisit[.]alteksecurity[.]org/tURLC2 for backdoor api-msvc.dll
hxxps://temp[.]sh/szAyn/sys.exeURLDownload URL for sys.exe
109.206.243[.]59IP AddressC2 for Cobalt Strike Beacon sys.exe
185.225.73[.]244IP AddressOriginating IP address for ProxyShell exploitation and web shell interaction

NOTE: These indicators should not be considered exhaustive for this observed activity.

Appendix

File extensions targeted by BlackByte binary for encryption:

.4dd.4dl.accdb.accdc.accde.accdr.accdt.accft
.adb.ade.adf.adp.arc.ora.alf.ask
.btr.bdf.cat.cdb.ckp.cma.cpd.dacpac
.dad.dadiagrams.daschema.db.db-shm.db-wal.db3.dbc
.dbf.dbs.dbt.dbv. dbx. dcb. dct. dcx
. ddl. dlis. dp1. dqy. dsk. dsn. dtsx. dxl
. eco. ecx. edb. epim. exb. fcd. fdb. fic
. fmp. fmp12. fmpsl. fol.fp3. fp4. fp5. fp7
. fpt. frm. gdb. grdb. gwi. hdb. his. ib
. idb. ihx. itdb. itw. jet. jtx. kdb. kexi
. kexic. kexis. lgc. lwx. maf. maq. mar. masmav
. mdb. mpd. mrg. mud. mwb. myd. ndf. nnt
. nrmlib. ns2. ns3. ns4. nsf. nv. nv2. nwdb
. nyf. odb. ogy. orx. owc. p96. p97. pan
. pdb. pdm. pnz. qry. qvd. rbf. rctd. rod
. rodx. rpd. rsd. sas7bdat. sbf. scx. sdb. sdc
. sdf. sis. spg. sql. sqlite. sqlite3. sqlitedb. te
. temx. tmd. tps. trc. trm. udb. udl. usr
. v12. vis. vpd. vvv. wdb. wmdb. wrk. xdb
. xld. xmlff. abcddb. abs. abx. accdw. and. db2
. fm5. hjt. icg. icr. kdb. lut. maw. mdn
. mdt       

Shared folders targeted for encryption (Example: \\[IP address]\Downloads):

UsersBackupVeeamhomeshome
mediacommonStorage ServerPublicWeb
ImagesDownloadsBackupDataActiveBackupForBusinessBackups
NAS-DCDCBACKUPDirectorFilesshare 

File extensions ignored:

.ini.url.msilog.log.ldf.lock.theme.msi
.sys.wpx.cpl.adv.msc.scr.key.ico
.dll.hta.deskthemepack.nomedia.msu.rtp.msp.idx
.ani.386.diagcfg.bin.mod.ics.com.hlp
 .spl.nls.cab.exe.diagpkg.icl.ocx.rom
.prf.thempack.msstyles.icns.mpa.drv.cur.diagcab
.cmd.shs      

Folders ignored:

windowsbootprogram files (x86)windows.oldprogramdata
intelbitdefendertrend microwindowsappsappdata
application datasystem volume informationperflogsmsocache 

Files ignored:

bootnxtntldrbootmgrthumbs.db
ntuser.datbootsect.bakautoexec.baticoncache.db
bootfont.bin   

Processes terminated:

teracopyteamviewernsservicensctrluranium
processhackerprocmonpestudioprocmon64x32dbg
x64dbgcff explorerprocexppslisttcpview
tcpvcondbgviewrammaprammap64vmmap
ollydbgautorunsautorunsscfilemonregmon
idaqidaq64immunitydebuggerwiresharkdumpcap
hookexplorerimportrecpetoolslordpesysinspector
proc_analyzersysanalyzersniff_hitwindbgjoeboxcontrol
joeboxserverresourcehackerfiddlerhttpdebuggerdumpit
rammaprammap64vmmapagntsvccntaosmgr
dbeng50dbsnmpencsvcinfopathisqlplussvc
mbamtraymsaccessmsftesqlmspubmydesktopqos
mydesktopservicemysqldmysqld-ntmysqld-optNtrtscan
ocautoupdsocommocssdonenoteoracle
outlookPccNTMonpowerpntsqbcoreservicesql
sqlagentsqlbrowsersqlservrsqlwritersteam
synctimetbirdconfigthebatthebat64thunderbird
tmlistenvisiowinwordwordpadxfssvccon
zoolz    

Services terminated:

CybereasonRansomFreevnetdbpcdSamSsTeraCopyService
msftesqlnsServiceklvssbridge64vapiendpointShMonitor
SmcinstSmcServiceSntpServicesvcGenericHostSwi_
TmCCSFtmlistenTrueKeyTrueKeySchedulerTrueKeyServiceHelper
WRSVCMcTaskManagerOracleClientCache80mfefirewbengine
mfemmsRESvcmfevtpsacsvrSAVAdminService
SepMasterServicePDVFSServiceESHASRVSDRSVCFA_Scheduler
KAVFSKAVFS_KAVFSGTkavfsslpklnagentmacmnsvc
masvcMBAMServiceMBEndpointAgentMcShieldaudioendpointbuilder
AntivirusAVPDCAgentbedbgEhttpSrv
MMSekrnEPSecurityServiceEPUpdateServicentrtscan
EsgShKernelmsexchangeadtopologyAcrSch2SvcMSOLAP$TPSAMAIntel(R) PROSet Monitoring
msexchangeimap4ARSMunistoresvc_1af40aReportServer$TPSMSOLAP$SYSTEM_BGC
W3SvcMSExchangeSRSReportServer$TPSAMAZoolz 2 ServiceMSOLAP$TPS
aphidmonitorserviceSstpSvcMSExchangeMTAReportServer$SYSTEM_BGCSymantec System Recovery
UI0DetectMSExchangeSAMSExchangeISReportServerMsDtsServer110
POP3SvcMSExchangeMGMTSMTPSvcMsDtsServerIisAdmin
MSExchangeESEraserSvc11710Enterprise Client ServiceMsDtsServer100NetMsmqActivator
stc_raw_agentVSNAPVSSPDVFSServiceAcrSch2SvcAcronis
CASAD2DWebSvcCAARCUpdateSvcMcAfeeavpsusDLPAgentService
mfewcBMR Boot ServiceDefWatchccEvtMgrccSetMgr
SavRoamRTVsc screenconnectransomsqltelemetrymsexch
vncteamviewermsolapveeambackup
sqlmemtasvsssophossvc$
mepocswuauserv   

Drivers that Blackbyte can bypass:

360avflt.sys360box.sys360fsflt.sys360qpesv.sys5nine.cbt.sys
a2acc.sysa2acc64.sysa2ertpx64.sysa2ertpx86.sysa2gffi64.sys
a2gffx64.sysa2gffx86.sysaaf.sysaalprotect.sysabrpmon.sys
accessvalidator.sysacdriver.sysacdrv.sysadaptivaclientcache32.sysadaptivaclientcache64.sys
adcvcsnt.sysadspiderdoc.sysaefilter.sysagentrtm64.sysagfsmon.sys
agseclock.sysagsyslock.sysahkamflt.sysahksvpro.sysahkusbfw.sys
ahnrghlh.sysaictracedrv_am.sysairship-filter.sysajfsprot.sysalcapture.sys
alfaff.sysaltcbt.sysamfd.sysamfsm.sysamm6460.sys
amm8660.sysamsfilter.sysamznmon.sysantileakfilter.sysantispyfilter.sys
anvfsm.sysapexsqlfilterdriver.sysappcheckd.sysappguard.sysappvmon.sys
arfmonnt.sysarta.sysarwflt.sysasgard.sysashavscan.sys
asiofms.sysaswfsblk.sysaswmonflt.sysaswsnx.sysaswsp.sys
aszfltnt.sysatamptnt.sysatc.sysatdragent.sysatdragent64.sys
aternityregistryhook.sysatflt.sysatrsdfw.sysauditflt.sysaupdrv.sys
avapsfd.sysavc3.sysavckf.sysavfsmn.sysavgmfi64.sys
avgmfrs.sysavgmfx64.sysavgmfx86.sysavgntflt.sysavgtpx64.sys
avgtpx86.sysavipbb.sysavkmgr.sysavmf.sysawarecore.sys
axfltdrv.sysaxfsysmon.sysayfilter.sysb9kernel.sysbackupreader.sys
bamfltr.sysbapfecpt.sysbbfilter.sysbd0003.sysbddevflt.sys
bdfiledefend.sysbdfilespy.sysbdfm.sysbdfsfltr.sysbdprivmon.sys
bdrdfolder.sysbdsdkit.sysbdsfilter.sysbdsflt.sysbdsvm.sys
bdsysmon.sysbedaisy.sysbemk.sysbfaccess.sysbfilter.sys
bfmon.sysbhdrvx64.sysbhdrvx86.sysbhkavka.sysbhkavki.sys
bkavautoflt.sysbkavsdflt.sysblackbirdfsa.sysblackcat.sysbmfsdrv.sys
bmregdrv.sysboscmflt.sysbosfsfltr.sysbouncer.sysboxifier.sys
brcow_x_x_x_x.sysbrfilter.sysbrnfilelock.sysbrnseclock.sysbrowsermon.sys
bsrfsflt.sysbssaudit.sysbsyaed.sysbsyar.sysbsydf.sys
bsyirmf.sysbsyrtm.sysbsysp.sysbsywl.sysbwfsdrv.sys
bzsenspdrv.sysbzsenth.sysbzsenyaradrv.syscaadflt.syscaavfltr.sys
cancelsafe.syscarbonblackk.syscatflt.syscatmf.syscbelam.sys
cbfilter20.syscbfltfs4.syscbfsfilter2017.syscbfsfilter2020.syscbsampledrv.sys
cdo.syscdrrsflt.syscdsgfsfilter.syscentrifyfsf.syscfrmd.sys
cfsfdrvcgwmf.syschange.syschangelog.syschemometecfilter.sys
ciscoampcefwdriver.sysciscoampheurdriver.sysciscosam.sysclumiochangeblockmf.syscmdccav.sys
cmdcwagt.syscmdguard.syscmdmnefs.syscmflt.syscode42filter.sys
codex.sysconduantfsfltr.syscontainermonitor.syscpavfilter.syscpavkernel.sys
cpepmon.syscrexecprev.syscrncache32.syscrncache64.syscrnsysm.sys
cruncopy.syscsaam.syscsaav.syscsacentr.syscsaenh.sys
csagent.syscsareg.syscsascr.syscsbfilter.syscsdevicecontrol.sys
csfirmwareanalysis.syscsflt.syscsmon.syscssdlp.sysctamflt.sys
ctifile.sysctinet.sysctrpamon.sysctx.syscvcbt.sys
cvofflineflt32.syscvofflineflt64.syscvsflt.syscwdriver.syscwmem2k64.sys
cybkerneltracker.syscylancedrv64.syscyoptics.syscyprotectdrv32.syscyprotectdrv64.sys
cytmon.syscyverak.syscyvrfsfd.syscyvrlpc.syscyvrmtgn.sys
datanow_driver.sysdattofsf.sysda_ctl.sysdcfafilter.sysdcfsgrd.sys
dcsnaprestore.sysdeepinsfs.sysdelete_flt.sysdevmonminifilter.sysdfmfilter.sys
dgedriver.sysdgfilter.sysdgsafe.sysdhwatchdog.sysdiflt.sys
diskactmon.sysdkdrv.sysdkrtwrt.sysdktlfsmf.sysdnafsmonitor.sys
docvmonk.sysdocvmonk64.sysdpmfilter.sysdrbdlock.sysdrivesentryfilterdriver2lite.sys
drsfile.sysdrvhookcsmf.sysdrvhookcsmf_amd64.sysdrwebfwflt.sysdrwebfwft.sys
dsark.sysdsdriver.sysdsfemon.sysdsflt.sysdsfltfs.sys
dskmn.sysdtdsel.sysdtpl.sysdwprot.sysdwshield.sys
dwshield64.syseamonm.syseaseflt.syseasyanticheat.syseaw.sys
ecatdriver.sysedevmon.sysednemfsfilter.sysedrdrv.sysedrsensor.sys
edsigk.syseectrl.syseetd32.syseetd64.syseeyehv.sys
eeyehv64.sysegambit.sysegfilterk.sysegminflt.sysegnfsflt.sys
ehdrv.syselock2fsctldriver.sysemxdrv2.sysenigmafilemondriver.sysenmon.sys
epdrv.sysepfw.sysepfwwfp.sysepicfilter.sysepklib.sys
epp64.sysepregflt.syseps.sysepsmn.sysequ8_helper.sys
eraser.sysesensor.sysesprobe.sysestprmon.sysestprp.sys
estregmon.sysestregp.sysestrkmon.sysestrkr.syseventmon.sys
evmf.sysevscase.sysexcfs.sysexprevdriver.sysfailattach.sys
failmount.sysfam.sysfangcloud_autolock_driver.sysfapmonitor.sysfarflt.sys
farwflt.sysfasdriverfcnotify.sysfcontrol.sysfdrtrace.sys
fekern.sysfencry.sysffcfilt.sysffdriver.sysfildds.sys
filefilter.sysfileflt.sysfileguard.sysfilehubagent.sysfilemon.sys
filemonitor.sysfilenamevalidator.sysfilescan.sysfilesharemon.sysfilesightmf.sys
filesystemcbt.sysfiletrace.sysfile_monitor.sysfile_protector.sysfile_tracker.sys
filrdriver.sysfim.sysfiometer.sysfiopolicyfilter.sysfjgsdis2.sys
fjseparettifilterredirect.sysflashaccelfs.sysflightrecorder.sysfltrs329.sysflyfs.sys
fmdrive.sysfmkkc.sysfmm.sysfortiaptfilter.sysfortimon2.sys
fortirmon.sysfortishield.sysfpav_rtp.sysfpepflt.sysfsafilter.sys
fsatp.sysfsfilter.sysfsgk.sysfshs.sysfsmon.sys
fsmonitor.sysfsnk.sysfsrfilter.sysfstrace.sysfsulgk.sys
fsw31rj1.sysgagsecurity.sysgbpkm.sysgcffilter.sysgddcv.sys
gefcmp.sysgemma.sysgeprotection.sysggc.sysgibepcore.sys
gkff.sysgkff64.sysgkpfcb.sysgkpfcb64.sysgofsmf.sys
gpminifilter.sysgroundling32.sysgroundling64.sysgtkdrv.sysgumhfilter.sys
gzflt.syshafsnk.syshbflt.syshbfsfltr.syshcp_kernel_acq.sys
hdcorrelatefdrv.syshdfilemon.syshdransomoffdrv.syshdrfs.sysheimdall.sys
hexisfsmonitor.syshfileflt.syshiofs.syshmpalert.syshookcentre.sys
hooksys.syshpreg.syshsmltmon.syshsmltwhl.syshssfwhl.sys
hvlminifilter.sysibr2fsk.sysiccfileioad.sysiccfilteraudit.sysiccfiltersc.sys
icfclientflt.sysicrlmonitor.sysiderafilterdriver.sysielcp.sysieslp.sys
ifs64.sysignis.sysiguard.sysiiscache.sysikfilesec.sys
im.sysimffilter.sysimfilter.sysimgguard.sysimmflex.sys
immunetprotect.sysimmunetselfprotect.sysinisbdrv64.sysino_fltr.sysintelcas.sys
intmfs.sysinuse.sysinvprotectdrv.sysinvprotectdrv64.sysionmonwdrv.sys
iothorfs.sysipcomfltr.sysipfilter.sysiprotect.sysiridiumswitch.sys
irongatefd.sysisafekrnl.sysisafekrnlmon.sysisafermonisecureflt.sys
isedrv.sysisfpdrv.sysisirmfmon.sysisregflt.sysisregflt64.sys
issfltr.sysissregistry.sysit2drv.sysit2reg.sysivappmon.sys
iwdmfs.sysiwhlp.sysiwhlp2.sysiwhlpxp.sysjdppsf.sys
jdppwf.sysjkppob.sysjkppok.sysjkpppf.sysjkppxk.sys
k7sentry.syskavnsi.syskawachfsminifilter.syskc3.syskconv.sys
kernelagent32.syskewf.syskfac.syskfileflt.syskisknl.sys
klam.sysklbg.sysklboot.syskldback.syskldlinf.sys
kldtool.sysklfdefsf.sysklflt.sysklgse.sysklhk.sys
klif.sysklifaa.sysklifks.sysklifsm.sysklrsps.sys
klsnsr.sysklupd_klif_arkmon.syskmkuflt.syskmnwch.syskmxagent.sys
kmxfile.syskmxsbx.sysksfsflt.sysktfsfilter.sysktsyncfsflt.sys
kubwksp.syslafs.syslbd.syslbprotect.syslcgadmon.sys
lcgfile.syslcgfilemon.syslcmadmon.syslcmfile.syslcmfilemon.sys
lcmprintmon.sysldsecdrv.syslibwamf.syslivedrivefilter.sysllfilter.sys
lmdriver.syslnvscenter.syslocksmith.syslragentmf.syslrtp.sys
magicbackupmonitor.sysmagicprotect.sysmajoradvapi.sysmarspy.sysmaxcryptmon.sys
maxproc64.sysmaxprotector.sysmbae64.sysmbam.sysmbamchameleon.sys
mbamshuriken.sysmbamswissarmy.sysmbamwatchdog.sysmblmon.sysmcfilemon32.sys
mcfilemon64.sysmcstrg.sysmearwfltdriver.sysmessage.sysmfdriver.sys
mfeaack.sysmfeaskm.sysmfeavfk.sysmfeclnrk.sysmfeelamk.sys
mfefirek.sysmfehidk.sysmfencbdc.sysmfencfilter.sysmfencoas.sys
mfencrk.sysmfeplk.sysmfewfpk.sysminiicpt.sysminispy.sys
minitrc.sysmlsaff.sysmmpsy32.sysmmpsy64.sysmonsterk.sys
mozycorpfilter.sysmozyenterprisefilter.sysmozyentfilter.sysmozyhomefilter.sysmozynextfilter.sys
mozyoemfilter.sysmozyprofilter.sysmpfilter.sysmpkernel.sysmpksldrv.sys
mpxmon.sysmracdrv.sysmrxgoogle.sysmscan-rt.sysmsiodrv4.sys
msixpackagingtoolmonitor.sysmsnfsflt.sysmspy.sysmssecflt.sysmtsvcdf.sys
mumdi.sysmwac.sysmwatcher.sysmwfsmfltr.sysmydlpmf.sys
namechanger.sysnanoavmf.sysnaswsp.sysndgdmk.sysneokerbyfilter
netaccctrl.sysnetaccctrl64.sysnetguard.sysnetpeeker.sysngscan.sys
nlcbhelpi64.sysnlcbhelpx64.sysnlcbhelpx86.sysnlxff.sysnmlhssrv01.sys
nmpfilter.sysnntinfo.sysnovashield.sysnowonmf.sysnpetw.sys
nprosec.sysnpxgd.sysnpxgd64.sysnravwka.sysnrcomgrdka.sys
nrcomgrdki.sysnregsec.sysnrpmonka.sysnrpmonki.sysnsminflt.sys
nsminflt64.sysntest.sysntfsf.sysntguard.sysntps_fa.sys
nullfilter.sysnvcmflt.sysnvmon.sysnwedriver.sysnxfsmon.sys
nxrmflt.sysoadevice.sysoavfm.sysoczminifilter.sysodfsfilter.sys
odfsfimfilter.sysodfstokenfilter.sysoffsm.sysomfltlh.sysosiris.sys
ospfile_mini.sysospmon.sysparity.syspassthrough.syspath8flt.sys
pavdrv.syspcpifd.syspctcore.syspctcore64.syspdgenfam.sys
pecfilter.sysperfectworldanticheatsys.syspervac.syspfkrnl.syspfracdrv.sys
pgpfs.syspgpwdefs.sysphantomd.sysphdcbtdrv.syspkgfilter.sys
pkticpt.sysplgfltr.sysplpoffdrv.syspointguardvista64f.syspointguardvistaf.sys
pointguardvistar32.syspointguardvistar64.sysprocmon11.sysproggerdriver.syspsacfileaccessfilter.sys
pscff.syspsgdflt.syspsgfoctrl.syspsinfile.syspsinproc.sys
psisolator.syspwipf6.syspwprotect.syspzdrvxp.sysqdocumentref.sys
qfapflt.sysqfilter.sysqfimdvr.sysqfmon.sysqminspec.sys
qmon.sysqqprotect.sysqqprotectx64.sysqqsysmon.sysqqsysmonx64.sys
qutmdrv.sysranpodfs.sysransomdefensexxx.sysransomdetect.sysreaqtor.sys
redlight.sysregguard.sysreghook.sysregmonex.sysrepdrv.sys
repmon.sysrevefltmgr.sysreveprocprotection.sysrevonetdriver.sysrflog.sys
rgnt.sysrmdiskmon.sysrmphvmonitor.sysrpwatcher.sysrrmon32.sys
rrmon64.sysrsfdrv.sysrsflt.sysrspcrtw.sysrsrtw.sys
rswctrl.sysrswmon.sysrtologon.sysrtw.sysruaff.sys
rubrikfileaudit.sysruidiskfs.sysruieye.sysruifileaccess.sysruimachine.sys
ruiminispy.sysrvsavd.sysrvsmon.sysrw7fsflt.sysrwchangedrv.sys
ryfilter.sysryguard.syssafe-agent.syssafsfilter.syssagntflt.sys
sahara.syssakfile.syssakmfile.syssamflt.syssamsungrapidfsfltr.sys
sanddriver.syssanta.syssascan.syssavant.syssavonaccess.sys
scaegis.sysscauthfsflt.sysscauthiodrv.sysscensemon.sysscfltr.sys
scifsflt.syssciptflt.syssconnect.sysscred.syssdactmon.sys
sddrvldr.syssdvfilter.sysse46filter.syssecdodriver.syssecone_filemon10.sys
secone_proc10.syssecone_reg10.syssecone_usb.syssecrmm.syssecufile.sys
secure_os.syssecure_os_mf.syssecurofsd_x64.syssefo.syssegf.sys
segiraflt.syssegmd.syssegmp.syssentinelmonitor.sysserdr.sys
serfs.syssfac.syssfavflt.syssfdfilter.syssfpmonitor.sys
sgresflt.sysshdlpmedia.sysshdlpsf.syssheedantivirusfilterdriver.syssheedselfprotection.sys
shldflt.syssi32_file.syssi64_file.syssieflt.syssimrep.sys
sisipsfilefiltersk.sysskyamdrv.sysskyrgdrv.sysskywpdrv.sys
slb_guard.syssld.syssmbresilfilter.syssmdrvnt.syssndacs.sys
snexequota.syssnilog.syssnimg.syssnscore.syssnsrflt.sys
sodatpfl.syssoftfilterxxx.syssoidriver.syssolitkm.syssonar.sys
sophosdt2.syssophosed.syssophosntplwf.syssophossupport.sysspbbcdrv.sys
spellmon.sysspider3g.sysspiderg3.sysspiminifilter.sysspotlight.sys
sprtdrv.syssqlsafefilterdriver.syssrminifilterdrv.syssrtsp.syssrtsp64.sys
srtspit.sysssfmonm.sysssrfsf.sysssvhook.sysstcvsm.sys
stegoprotect.sysstest.sysstflt.sysstkrnl64.sysstoragedrv.sys
strapvista.sysstrapvista64.syssvcbt.sysswcommfltr.sysswfsfltr.sys
swfsfltrv2.sysswin.syssymafr.syssymefa.syssymefa64.sys
symefasi.syssymevent.syssymevent64x86.syssymevnt.syssymevnt32.sys
symhsm.syssymrg.syssysdiag.syssysmon.syssysmondrv.sys
sysplant.sysszardrv.sysszdfmdrv.sysszdfmdrv_usb.sysszedrdrv.sys
szpcmdrv.systaniumrecorderdrv.systaobserveflt.systbfsfilt.systbmninifilter.sys
tbrdrv.systdevflt.systedrdrv.systenrsafe2.systesmon.sys
tesxnginx.systesxporter.systffregnt.systfsflt.systgfsmf.sys
thetta.systhfilter.systhreatstackfim.systkdac2k.systkdacxp.sys
tkdacxp64.systkfsavxp.systkfsavxp64.systkfsft.systkfsft64.sys
tkpcftcb.systkpcftcb64.systkpl2k.systkpl2k64.systksp2k.sys
tkspxp.systkspxp64.systmactmon.systmcomm.systmesflt.sys
tmevtmgr.systmeyes.systmfsdrv2.systmkmsnsr.systmnciesc.sys
tmpreflt.systmumh.systmums.systmusa.systmxpflt.sys
topdogfsfilt.systrace.systrfsfilter.systritiumfltr.systrpmnflt.sys
trufos.systrustededgeffd.systsifilemon.systss.syststfilter.sys
tstfsredir.syststregredir.systsyscare.systvdriver.systvfiltr.sys
tvmfltr.systvptfile.systvspfltr.systwbdcfilter.systxfilefilter.sys
txregmon.sysuamflt.sysucafltdriver.sysufdfilter.sysuncheater.sys
upguardrealtime.sysusbl_ifsfltr.sysusbpdh.sysusbtest.sysuvmcifsf.sys
uwfreg.sysuwfs.sysv3flt2k.sysv3flu2k.sysv3ift2k.sys
v3iftmnt.sysv3mifint.sysvarpffmon.sysvast.sysvcdriv.sys
vchle.sysvcmfilter.sysvcreg.sysveeamfct.sysvfdrv.sys
vfilefilter.sysvfpd.sysvfsenc.sysvhddelta.sysvhdtrack.sys
vidderfs.sysvintmfs.sysvirtfile.sysvirtualagent.sysvk_fsf.sys
vlflt.sysvmwvvpfsd.sysvollock.sysvpdrvnt.sysvradfil2.sys
vraptdef.sysvraptflt.sysvrarnflt.sysvrbbdflt.sysvrexpdrv.sys
vrfsftm.sysvrfsftmx.sysvrnsfilter.sysvrsdam.sysvrsdcore.sys
vrsdetri.sysvrsdetrix.sysvrsdfmx.sysvrvbrfsfilter.sysvsepflt.sys
vsscanner.sysvtsysflt.sysvxfsrep.syswats_se.syswbfilter.sys
wcsdriver.syswdcfilter.syswdfilter.syswdocsafe.syswfp_mrt.sys
wgfile.syswhiteshield.syswindbdrv.syswindd.syswinfladrv.sys
winflahdrv.syswinfldrv.syswinfpdrv.syswinload.syswinteonminifilter.sys
wiper.syswlminisecmod.syswntgpdrv.syswraekernel.syswrcore.sys
wrcore.x64.syswrdwizfileprot.syswrdwizregprot.syswrdwizscanner.syswrdwizsecure64.sys
wrkrn.syswrpfv.syswsafefilter.syswscm.sysxcpl.sys
xendowflt.sysxfsgk.sysxhunter1.sysxhunter64.sysxiaobaifs.sys
xiaobaifsr.sysxkfsfd.sysxoiv8x64.sysxomfcbt8x64.sysyahoostorage.sys
yfsd.sysyfsd2.sysyfsdr.sysyfsrd.syszampit_ml.sys
zesfsmf.syszqfilter.syszsfprt.syszwasatom.syszwpxesvr.sys
zxfsfilt.syszyfm.syszzpensys.sys  

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

Source :
https://www.microsoft.com/en-us/security/blog/2023/07/06/the-five-day-job-a-blackbyte-ransomware-intrusion-case-study/

Analysis of Storm-0558 techniques for unauthorized email access

July 14, 2023

Executive summary

On July 11, 2023, Microsoft published two blogs detailing a malicious campaign by a threat actor tracked as Storm-0558 that targeted customer email that we’ve detected and mitigated: Microsoft Security Response Center and Microsoft on the Issues. As we continue our investigation into this incident and deploy defense in depth measures to harden all systems involved, we’re providing this deeper analysis of the observed actor techniques for obtaining unauthorized access to email data, tools, and unique infrastructure characteristics. 

As described in more detail in our July 11 blogs, Storm-0558 is a China-based threat actor with espionage objectives. Beginning May 15, 2023, Storm-0558 used forged authentication tokens to access user email from approximately 25 organizations, including government agencies and related consumer accounts in the public cloud. No other environment was impacted. Microsoft has successfully blocked this campaign from Storm-0558. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Since identification of this malicious campaign on June 16, 2023, Microsoft has identified the root cause, established durable tracking of the campaign, disrupted malicious activities, hardened the environment, notified every impacted customer, and coordinated with multiple government entities. We continue to investigate and monitor the situation and will take additional steps to protect customers.

Actor overview

Microsoft Threat Intelligence assesses with moderate confidence that Storm-0558 is a China-based threat actor with activities and methods consistent with espionage objectives. While we have discovered some minimal overlaps with other Chinese groups such as Violet Typhoon (ZIRCONIUM, APT31), we maintain high confidence that Storm-0558 operates as its own distinct group.

Figure 1 shows Storm-0558 working patterns from April to July 2023; the actor’s core working hours are consistent with working hours in China, Monday through Friday from 12:00 AM UTC (8:00 AM China Standard time) through 09:00 AM UTC (5:00 PM China Standard Time).

Heatmap showing observed Storm-0558 activity by day of the week (x-axis) and hour (y-axis).
Figure 1. Heatmap of observed Stom-0558 activity by day of week and hour (UTC).

In past activity observed by Microsoft, Storm-0558 has primarily targeted US and European diplomatic, economic, and legislative governing bodies, and individuals connected to Taiwan and Uyghur geopolitical interests. 

Historically, this threat actor has displayed an interest in targeting media companies, think tanks, and telecommunications equipment and service providers. The objective of most Storm-0558 campaigns is to obtain unauthorized access to email accounts belonging to employees of targeted organizations. Storm-0558 pursues this objective through credential harvesting, phishing campaigns, and OAuth token attacks. This threat actor has displayed an interest in OAuth applications, token theft, and token replay against Microsoft accounts since at least August 2021. Storm-0558 operates with a high degree of technical tradecraft and operational security. The actors are keenly aware of the target’s environment, logging policies, authentication requirements, policies, and procedures. Storm-0558’s tooling and reconnaissance activity suggests the actor is technically adept, well resourced, and has an in-depth understanding of many authentication techniques and applications.

In the past, Microsoft has observed Storm-0558 obtain credentials for initial access through phishing campaigns. The actor has also exploited vulnerabilities in public-facing applications to gain initial access to victim networks. These exploits typically result in web shells, including China Chopper, being deployed on compromised servers. One of the most prevalent malware families used by Storm-0558 is a shared tool tracked by Microsoft as Cigril. This family exists in several variants and is launched using dynamic-link library (DLL) search order hijacking.

After gaining access to a compromised system, Storm-0558 accesses credentials from a variety of sources, including the LSASS process memory and Security Account Manager (SAM) registry hive. Microsoft assesses that once Storm-0558 has access to the desired user credentials, the actor signs into the compromised user’s cloud email account with the valid account credentials. The actor then collects information from the email account over the web service.

Initial discovery and analysis of current activity

On June 16, 2023, Microsoft was notified by a customer of anomalous Exchange Online data access. Microsoft analysis attributed the activity to Storm-0558 based on established prior TTPs. We determined that Storm-0558 was accessing the customer’s Exchange Online data using Outlook Web Access (OWA). Microsoft’s investigative workflow initially assumed the actor was stealing correctly issued Azure Active Directory (Azure AD) tokens, most probably using malware on infected customer devices. Microsoft analysts later determined that the actor’s access was utilizing Exchange Online authentication artifacts, which are typically derived from Azure AD authentication tokens (Azure AD tokens). Further in-depth analysis over the next several days led Microsoft analysts to assess that the internal Exchange Online authentication artifacts did not correspond to Azure AD tokens in Microsoft logs.

Microsoft analysts began investigating the possibility that the actor was forging authentication tokens using an acquired Azure AD enterprise signing key. In-depth analysis of the Exchange Online activity discovered that in fact the actor was forging Azure AD tokens using an acquired Microsoft account (MSA) consumer signing key. This was made possible by a validation error in Microsoft code. The use of an incorrect key to sign the requests allowed our investigation teams to see all actor access requests which followed this pattern across both our enterprise and consumer systems. Use of the incorrect key to sign this scope of assertions was an obvious indicator of the actor activity as no Microsoft system signs tokens in this way. Use of acquired signing material to forge authentication tokens to access customer Exchange Online data differs from previously observed Storm-0558 activity. Microsoft’s investigations have not detected any other use of this pattern by other actors and Microsoft has taken steps to block related abuse.

Actor techniques

Token forgery

Authentication tokens are used to validate the identity of entities requesting access to resources – in this case, email. These tokens are issued to the requesting entity (such as a user’s browser) by identity providers like Azure AD. To prove authenticity, the identity provider signs the token using a private signing key. The relying party validates the token presented by the requesting entity by using a public validation key. Any request whose signature is correctly validated by the published public validation key will be trusted by the relying party. An actor that can acquire a private signing key can then create falsified tokens with valid signatures that will be accepted by relying parties. This is called token forgery.

Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected.

As part of defense in depth, we continuously update our systems. We have substantially hardened key issuance systems since the acquired MSA key was initially issued. This includes increased isolation of the systems, refined monitoring of system activity, and moving to the hardened key store used for our enterprise systems. We have revoked all previously active keys and issued new keys using these updated systems. Our active investigation indicates these hardening and isolation improvements disrupt the mechanisms we believe the actor could have used to acquire MSA signing keys. No key-related actor activity has been observed since Microsoft invalidated the actor-acquired MSA signing key. Further, we have seen Storm-0558 transition to other techniques, which indicates that the actor is not able to utilize or access any signing keys. We continue to explore other ways the key may have been acquired and add additional defense in depth measures.

Identity techniques for access

Once authenticated through a legitimate client flow leveraging the forged token, the threat actor accessed the OWA API to retrieve a token for Exchange Online from the GetAccessTokenForResource API used by OWA. The actor was able to obtain new access tokens by presenting one previously issued from this API due to a design flaw. This flaw in the GetAccessTokenForResourceAPI has since been fixed to only accept tokens issued from Azure AD or MSA respectively. The actor used these tokens to retrieve mail messages from the OWA API. 

Actor tooling

Microsoft Threat Intelligence routinely identifies threat actor capabilities and leverages file intelligence to facilitate our protection of Microsoft customers. During this investigation, we identified several distinct Storm-0558 capabilities that facilitate the threat actor’s intrusion techniques. The capabilities described in this section are not expected to be present in the victim environment.

Storm-0558 uses a collection of PowerShell and Python scripts to perform REST API calls against the OWA Exchange Store service. For example, Storm-0558 has the capability to use minted access tokens to extract email data such as:

  • Download emails
  • Download attachments
  • Locate and download conversations
  • Get email folder information

The generated web requests can be routed through a Tor proxy or several hardcoded SOCKS5 proxy servers. The threat actor was observed using several User-Agents when issuing web requests, for example:

  • Client=REST;Client=RESTSystem;;
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.52
  • “Microsoft Edge”;v=”113″, “Chromium”;v=”113″, “Not-A.Brand”;v=”24″

The scripts contain highly sensitive hardcoded information such as bearer access tokens and email data, which the threat actor uses to perform the OWA API calls. The threat actor has the capability to refresh the access token for use in subsequent OWA commands.

Screenshot of Python code snippet of the token refresh functionality
Figure 2. Python code snippet of the token refresh functionality used by the threat actor.
Screenshot of PowerShell code snippet of OWA REST API
Figure 3. PowerShell code snippet of OWA REST API call to GetConversationItems.

Actor infrastructure

During significant portions of Storm-0558’s malicious activities, the threat actor leveraged dedicated infrastructure running the SoftEther proxy software. Proxy infrastructure complicates detection and attribution of Storm-0558 activities. During our response, Microsoft Threat Intelligence identified a unique method of profiling this proxy infrastructure and correlated with behavioral characteristics of the actor intrusion techniques. Our profile was based on the following facets:

  1. Hosts operating as part of this network present a JARM fingerprint consistent with SoftEther VPN: 06d06d07d06d06d06c42d42d000000cdb95e27fd8f9fee4a2bec829b889b8b.
  2. Presented x509 certificate has expiration date of December 31, 2037.
  3. Subject information within the x509 certificate does not contain “softether”.

Over the course of the campaign, the IPs listed in the table below were used during the corresponding timeframes.

IP addressFirst seenLast seenDescription
51.89.156[.]1533/9/20237/10/2023SoftEther proxy
176.31.90[.]1293/28/20236/29/2023SoftEther proxy
137.74.181[.]1003/31/20237/11/2023SoftEther proxy
193.36.119[.]454/19/20237/7/2023SoftEther proxy
185.158.248[.]1594/24/20237/6/2023SoftEther proxy
131.153.78[.]1885/6/20236/29/2023SoftEther proxy
37.143.130[.]1465/12/20235/19/2023SoftEther proxy
146.70.157[.]455/12/20236/8/2023SoftEther proxy
185.195.200[.]395/15/20236/29/2023SoftEther proxy
185.38.142[.]2295/15/20237/12/2023SoftEther proxy
146.70.121[.]445/17/20236/29/2023SoftEther proxy
31.42.177[.]1815/22/20235/23/2023SoftEther proxy
185.51.134[.]526/7/20237/11/2023SoftEther proxy
173.44.226[.]706/9/20237/11/2023SoftEther proxy
45.14.227[.]2336/12/20236/26/2023SoftEther proxy
185.236.231[.]1096/12/20237/3/2023SoftEther proxy
178.73.220[.]1496/16/20237/12/2023SoftEther proxy
45.14.227[.]2126/19/20236/29/2023SoftEther proxy
91.222.173[.]2256/20/20237/1/2023SoftEther proxy
146.70.35[.]1686/22/20236/29/2023SoftEther proxy
146.70.157[.]2136/26/20236/30/2023SoftEther proxy
31.42.177[.]2016/27/20236/29/2023SoftEther proxy
5.252.176[.]87/1/20237/1/2023SoftEther proxy
80.85.158[.]2157/1/20237/9/2023SoftEther proxy
193.149.129[.]887/2/20237/12/2023SoftEther proxy
5.252.178[.]687/3/20237/11/2023SoftEther proxy
116.202.251[.]87/4/20237/7/2023SoftEther proxy
185.158.248[.]936/25/202306/26/2023SoftEther proxy
20.108.240[.]2526/25/20237/5/2023SoftEther proxy
146.70.135[.]1825/18/20236/22/2023SoftEther proxy

As early as May 15, 2023, Storm-0558 shifted to using a separate series of dedicated infrastructure servers specifically for token replay and interaction with Microsoft services. It is likely that the dedicated infrastructure and supporting services configured on this infrastructure offered a more efficient manner of facilitating the actor’s activities. The dedicated infrastructure would host an actor-developed web panel that presented an authentication page at URI /#/login. The observed sign-in pages had one of two SHA-1 hashes: 80d315c21fc13365bba5b4d56357136e84ecb2d4 and 931e27b6f1a99edb96860f840eb7ef201f6c68ec.

Screenshot of the token web panel sign-in page
Figure 4. Token web panel sign-in page with SHA-1 hashes.

As part of the intelligence-driven response to this campaign, and in support of tracking, analyzing, and disrupting actor activity, analytics were developed to proactively track the dedicated infrastructure. Through this tracking, we identified the following dedicated infrastructure.

IP addressFirst seenLast seenDescription
195.26.87[.]2195/15/20236/25/2023Token web panel
185.236.228[.]1835/24/20236/11/2023Token web panel
85.239.63[.]1606/7/20236/11/2023Token web panel
193.105.134[.]586/24/20236/25/2023Token web panel
146.0.74[.]166/28/20237/4/2023Token web panel
91.231.186[.]2266/29/20237/4/2023Token web panel
91.222.174[.]416/29/20237/3/2023Token web panel
185.38.142[.]2496/29/20237/2/2023Token web panel

The last observed dedicated token replay infrastructure associated with this activity was stood down on July 4, 2023, roughly one day following the coordinated mitigation conducted by Microsoft. 

Post-compromise activity

Our telemetry and investigations indicate that post-compromise activity was limited to email access and exfiltration for targeted users.

Mitigation and hardening

No customer action is required to mitigate the token forgery technique or validation error in OWA or Outlook.com. Microsoft has mitigated this issue on customers’ behalf as follows:

  • On June 26, OWA stopped accepting tokens issued from GetAccessTokensForResource for renewal, which mitigated the token renewal being abused.
  • On June 27, Microsoft blocked the usage of tokens signed with the acquired MSA key in OWA preventing further threat actor enterprise mail activity.
  • On June 29, Microsoft completed replacement of the key to prevent the threat actor from using it to forge tokens. Microsoft revoked all MSA signing which were valid at the time of the incident, including the actor-acquired MSA key. The new MSA signing keys are issued in substantially updated systems which benefit from hardening not present at issuance of the actor-acquired MSA key:
    • Microsoft has increased the isolation of these systems from corporate environments, applications, and users.Microsoft has refined monitoring of all systems related to key activity, and increased automated alerting related to this monitoring.
    • Microsoft has moved the MSA signing keys to the key store used for our enterprise systems.
  • On July 3, Microsoft blocked usage of the key for all impacted consumer customers to prevent use of previously-issued tokens.

Ongoing monitoring indicates that all actor activity related to this incident has been blocked. Microsoft will continue to monitor Storm-0558 activity and implement protections for our customers.

Recommendations

Microsoft has mitigated this activity on our customers’ behalf for Microsoft services. No customer action is required to prevent threat actors from using the techniques described above to access Exchange Online and Outlook.com.

Indicators of compromise

IndicatorTypeFirst seenLast seenDescription
d4b4cccda9228624656bff33d8110955779632aaThumbprint  Thumbprint of acquired signing key
195.26.87[.]219IPv45/15/20236/25/2023Token web panel
185.236.228[.]183IPv45/24/20236/11/2023Token web panel
85.239.63[.]160IPv46/7/20236/11/2023Token web panel
193.105.134[.]58IPv46/24/20236/25/2023Token web panel
146.0.74[.]16IPv46/28/20237/4/2023Token web panel
91.231.186[.]226IPv46/29/20237/4/2023Token web panel
91.222.174[.]41IPv46/29/20237/3/2023Token web panel
185.38.142[.]249IPv46/29/20237/2/2023Token web panel
51.89.156[.]153IPv43/9/20237/10/2023SoftEther proxy
176.31.90[.]129IPv43/28/20236/29/2023SoftEther proxy
137.74.181[.]100IPv43/31/20237/11/2023SoftEther proxy
193.36.119[.]45IPv44/19/20237/7/2023SoftEther proxy
185.158.248[.]159IPv44/24/20237/6/2023SoftEther proxy
131.153.78[.]188IPv45/6/20236/29/2023SoftEther proxy
37.143.130[.]146IPv45/12/20235/19/2023SoftEther proxy
146.70.157[.]45IPv45/12/20236/8/2023SoftEther proxy
185.195.200[.]39IPv45/15/20236/29/2023SoftEther proxy
185.38.142[.]229IPv45/15/20237/12/2023SoftEther proxy
146.70.121[.]44IPv45/17/20236/29/2023SoftEther proxy
31.42.177[.]181IPv45/22/20235/23/2023SoftEther proxy
185.51.134[.]52IPv46/7/20237/11/2023SoftEther proxy
173.44.226[.]70IPv46/9/20237/11/2023SoftEther proxy
45.14.227[.]233IPv46/12/20236/26/2023SoftEther proxy
185.236.231[.]109IPv46/12/20237/3/2023SoftEther proxy
178.73.220[.]149IPv46/16/20237/12/2023SoftEther proxy
45.14.227[.]212IPv46/19/20236/29/2023SoftEther proxy
91.222.173[.]225IPv46/20/20237/1/2023SoftEther proxy
146.70.35[.]168IPv46/22/20236/29/2023SoftEther proxy
146.70.157[.]213IPv46/26/20236/30/2023SoftEther proxy
31.42.177[.]201IPv46/27/20236/29/2023SoftEther proxy
5.252.176[.]8IPv47/1/20237/1/2023SoftEther proxy
80.85.158[.]215IPv47/1/20237/9/2023SoftEther proxy
193.149.129[.]88IPv47/2/20237/12/2023SoftEther proxy
5.252.178[.]68IPv47/3/20237/11/2023SoftEther proxy
116.202.251[.]8IPv47/4/20237/7/2023SoftEther proxy

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

Source :
https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

How to Disable NTLM Authentication in Windows Domain

February 28, 2023

NTLM (NT LAN Manager) is a legacy Microsoft authentication protocol that dates back to Windows NT. Although Microsoft introduced the more secure Kerberos authentication protocol back in Windows 2000, NTLM (mostly NTLMv2) is still widely used for authentication on Windows domain networks. In this article, we will look at how to disable the NTLMv1 and NTLMv2 protocols, and switch to Kerberos in an Active Directory domain.

Contents:

The key NTLMv1 problems:

  • weak encryption;
  • storing password hash in the memory of the LSA service, which can be extracted from Windows memory in plain text using various tools (such as Mimikatz) and used for further attacks using pass-the-has scripts;
  • the lack of mutual authentication between a server and a client, leading to data interception and unauthorized access to resources (some tools such as Responder can capture NTLM data sent over the network and use them to access the network resources);
  • and other vulnerabilities.

Some of these have been in the next version NTLMv2 which uses more secure encryption algorithms and allows to prevent of common NTLM attacks. NTLMv1 and LM authentication protocols are disabled by default starting with Windows 7 and Windows Server 2008 R2.

How to Enable NTLM Authentication Audit Logging?

Before completely disabling NTLM in a domain and switching to Kerberos, it is a good idea to ensure that there are no applications in the domain that require and use NTLM auth. There may be legacy devices or services on your network that still use NTLMv1 authentication instead of NTLMv2 (or Kerberos).

To track accounts or apps that use NTLM authentication, you can enable audit logging policies on all computers using GPO. Open the Default Domain Controller Policy, navigate to the Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options section, find and enable the Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy and set its value to Enable all.

Network Security: Restrict NTLM: Audit NTLM authentication in this domain

In the same way, enable the following policies in the Default Domain Policy:

  • Network Security: Restrict NTLM: Audit Incoming NTLM Traffic – set its value to Enable auditing for domain accounts
  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: set Audit all
Network Security: Restrict NTLM: Audit Incoming NTLM Traffic

Once these policies are enabled, events related to the use of NTLM authentication will appear in the Application and Services Logs-> Microsoft -> Windows -> NTLM section of the Event Viewer.

You can analyze the events on each server or collect them to the central Windows Event Log Collector.

You need to search for the events from the source Microsoft-Windows-Security-Auditing with the Event ID 4624 – “An Account was successfully logged on“. Note the information in the “Detailed Authentication Information” section. If there is NTLM in the Authentication Package value, then the NTLM protocol was used to authenticate this user.

Look at the value of Package Name (NTLM only). This line shows which protocol (LM, NTLMv1, or NTLMv2) was used for authentication. So you need to identify any servers/applications that are using the legacy protocol.

eventid 4624 source Microsoft-Windows-Security-Auditing ntlm usage

Also, if NTLM is used for authentication instead of Kerberos, Event ID 4776 will appear in the log:

The computer attempted to validate the credentials for an account
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

For example, to search for all NTLMv1 authentication events on all domain controllers, you can use the following PowerShell script:

$ADDCs = Get-ADDomainController -filter
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:\Events\$($Yesterday.ToString('yyyyddMM'))_AD_NTLMv1_events.log"
function GetEvents($DC){
Write-Host "Searching log on " $DC.HostName
$Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*NTLM V1*" -instanceid 4624
foreach($Event in $Events){
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append
}
}
foreach($DC in $ADDCs){GetEvents($DC)}

Once you have identified the users and applications that use NTLM in your domain, try switching them to use Kerberos (possibly using SPN). To use Kerberos authentication, some applications need to be slightly reconfigured (Kerberos Authentication in IISConfigure different browsers for Kerberos authenticationCreate a Keytab File Using Kerberos Auth). From my own experience, I see that even large commercial products are still using NTLM instead of Kerberos, some products require updates or configuration changes. The idea is to identify which applications use NTLM authentication, and now you have a way to identify that software and devices.

Small open-source products, old models of various network scanners (which store scans in shared network folders), some NAS devices and other old hardware, legacy software and operating systems are likely to have authentication problems when NTLMv1 is disabled.

Those apps that cannot use Kerberos can be added to the exceptions. This allows them to use NTLM authentication even if it is disabled at the domain level. To do it, the Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain policy is used. Add the names of the servers (NetBIOS names, IP addresses, or FQDN), on which NTLM authentication can be used, to the list of exceptions as well. Ideally, this exception list should be empty. You can use the wildcard character *.

GPO: Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain

To use Kerberos authentication in an application, you must specify the DNS name of the server, instead of its IP address. If you specify an IP address when connecting to your resources, NTLM authentication will be used.

Configuring Active Directory to Force NTLMv2 via GPO

Before completely disabling NTLM in an AD domain, it is recommended that you first disable its more vulnerable version, NTLMv1. The domain administrator needs to make sure that their network does not allow the use of NTLM or LM for authentication, as in some cases an attacker can use special requests to get a response to an NTLM/LM request.

You can set the preferred authentication type using the domain GPO. Open the Group Policy Management Editor (gpmc.msc) and edit the Default Domain Controllers Policy. Go to the GPO section Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options and find the policy Network Security: LAN Manager authentication level.

Network Security: LAN Manager authentication level - disable ntlm v1 and lm

There are 6 options to choose from in the policy settings::

  • Send LM & NTLM responses;
  • Send LM & NTLM responses – use NTLMv2 session security if negotiated;
  • Send NTLM response only;
  • Send NTLMv2 response only;
  • Send NTLMv2 response only. Refuse LM;
  • Send NTLMv2 response only. Refuse LM& NTLM.

The NTLM authentication options are listed in the order of their security improvement. By default, Windows 7 and later operating systems use the option Send NTLMv2 response only. If this option is enabled, client computers use NTLMv2 authentication, but AD domain controllers accept LM, NTLM, and NTLMv2 requests.

NTLMv2 can be used where the Kerberos protocol has failed and for some operations (for example, managing local groups and accounts on the domain-joined computers) or in workgroups.

You can change the policy value to the most secure option 6 : “Send NTLMv2 response only. Refuse LM & NTLM”. This policy causes domain controllers to reject LM and NTLM requests as well.

You can also disable NTLMv1 through the registry. To do this, create a DWORD parameter with the name LmCompatibilityLevel with a value between 0 and 5 under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Value 5 corresponds to the policy option “Send NTLMv2 response only. Refuse LM NTLM”.

Make sure that the Network security: Do not store LAN Manager hash value on next password change policy is enabled in the same GPO section. It is enabled by default starting with Windows Vista / Windows Server 2008 and prevents the creation of an LM hash.

Network security: Do not store LAN Manager hash value on next password change

Once you have ensured that you are not using NTLMv1, you can go further and try to disable NTLMv2. NTLMv2 is a more secure authentication protocol but loses significantly to Kerberos in terms of security (although there are fewer vulnerabilities in NTLMv2 than in the NTLMv1, but there is still a chance of capturing and reusing data, as well as it doesn’t support mutual authentication).

The main risk of disabling NTLM is the potential use of legacy or misconfigured applications that may still be using NTLM authentication. If this is the case, they will need to be updated or specially configured to switch to Kerberos.

If you have a Remote Desktop Gateway server on your network, you will need to make an additional configuration to prevent clients from connecting using NTLMv1. Create a registry entry:

REG add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core" /v EnforceChannelBinding /t REG_DWORD /d 1 /f

Restrict NTLM Completely and Use Kerberos Authentication in an AD

To check how authentication works in different applications in a domain without using NTLM, you can add the accounts of the required users to the Protected Users domain group (it is available since the Windows Server 2012 R2 release). Members of this security group can only authenticate using Kerberos (NTLM, Digest Authentication, or CredSSP are not allowed). This allows you to verify that Kerberos user authentication is working correctly in different apps.

Then you can completely disable NTLM on the Active Directory domain using the Network Security: Restrict NTLM: NTLM authentication in this domain policy.

The policy has 5 options:

  • Disable: the policy is disabled (NTLM authentication is allowed in the domain);
  • Deny for domain accounts to domain servers: the domain controllers reject NTLM authentication attempts for all servers under the domain accounts, and the “NTLM is blocked” error message is displayed;
  • Deny for domain accounts: the domain controllers are preventing NTLM authentication attempts for all domain accounts, and the “NTLM is blocked” error appears;
  • Deny for domain servers: NTLM authentication requests are denied for all servers unless the server name is on the exception list in the “Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain” policy;
  • Deny all: the domain controllers block all NTLM requests for all domain servers and accounts.
GPO: Network Security: Restrict NTLM: NTLM authentication in this domain

Although NTLM is now disabled on the domain, it is still used to process local logins to computers (NTLM is always used for local user logons).

You can also disable incoming and outgoing NTLM traffic on domain computers using separate Default Domain Policy options:

  • Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts
  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all

After enabling auditing, Event Viewer will also display EventID 6038 from the LsaSRV source when using NTLM for authentication:

Microsoft Windows Server has detected that NTLM authentication is presently being used between clients and this server. This event occurs once per boot of the server on the first time a client uses NTLM with this server.
NTLM is a weaker authentication mechanism. Please check:
Which applications are using NTLM authentication?
Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication?
If NTLM must be supported, is Extended Protection configured?
eventid 6038 from lsasrv source: NTLM authentication is presently being used between clients and this server

You can check that Kerberos is used for user authentication with the command:

klist sessions

klist session - check authentication protocol used

This command shows that all users are Kerberos-authenticated (except the built-in local Administrator, who is always authenticated using NTLM).

If you are experiencing a lot of user account lockout events after disabling NTLM, take a close look at the events with ID 4771 (Kerberos pre-authentication failed). Check the Failure Code in the error description. This will indicate the reason and source of the lock.

To further improve Active Directory security, I recommend reading these articles:


Source :
https://woshub.com/disable-ntlm-authentication-windows/