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/

Shared Storage and Monitoring for VMware vSphere Cluster as a base building block with Software Defined Storage from StarWind

By Vladan SEGET | Last Updated: July 31, 2023

Shared storage is a critical component of a VMware vSphere cluster. In a vSphere cluster, multiple hosts are grouped together to provide a pool of computing resources that can be used to run virtual machines. These hosts are connected to shared storage, which provides a centralized location for storing virtual machine files, such as virtual disks and configuration files. This shared storage is accessible to all hosts in the cluster, allowing virtual machines to be migrated between hosts without the need to copy files between them.

Shared storage is a base building block without which most (if not all) cluster services will not work. Shared storage is a requirement for vSphere HA, DRS, FT or other cluster services.

What are the benefits of shared storage?

There are several benefits to using shared storage in a vSphere cluster. One of the most significant benefits is the ability to migrate virtual machines between hosts using vMotion. vMotion allows virtual machines to be moved between hosts without any downtime, allowing administrators to perform maintenance tasks or balance the load on the hosts without impacting the availability of virtual machines. This is possible because the virtual machine files are stored on shared storage, which is accessible to all hosts in the cluster.

Another benefit of shared storage is the ability to use advanced features such as High Availability (HA) and Distributed Resource Scheduler (DRS). HA provides automatic failover of virtual machines in the event of a host failure, while DRS provides load balancing of virtual machines across hosts in the cluster. Both of these features rely on shared storage to function properly.
There are several types of shared storage that can be used in a vSphere cluster, including Fibre Channel, iSCSI, and NFS. Each of these storage types has its own advantages and disadvantages, and the choice of storage type will depend on factors such as performance requirements, budget, and existing infrastructure.

In addition to choosing the right type of shared storage, it is also important to properly configure and manage the storage environment. This includes tasks such as setting up storage arrays, configuring storage networking, and monitoring storage performance. VMware provides a number of tools and best practices to help administrators manage shared storage in a vSphere cluster, including the vSphere Storage APIs, vSphere Storage DRS, and the vSphere Web Client.

StarWind SAN and NAS has another advantage over a hardware based storage array. This is cost. In addition, storage array, despite that you can have multiple PSUs or multiple CPUs or controller cards or NICs, you can only have a single motherboard, which is a still single point of failureStarWind SAN and NAS, that is a software based, is configured to run on at least 2-nodes where each node participate with its internal disks and RAM, to the storage pool created by StarWind. As a result, when you have a 1 host failure, the other host still has your VM file as the storage is simply mirrored. If you have vSphere HA, the restart of VMs on the remaining host is done automatically. Without vSphere HA you simply start those VMs manually from your remaining host.

What is StarWind SAN and NAS?

StarWind SAN and NAS is a software that turns your server or a group of servers into a powerful and easy-to-use storage appliance. It eliminates the need for expensive and complex storage hardware and provides a cost-effective and scalable storage solution for your virtualized environment.

Benefits of StarWind SAN and NAS for VMware vSphere

High Availability – StarWind SAN and NAS provides high availability by creating a redundant storage pool that can withstand hardware failures. It uses synchronous replication to keep the data in sync between the nodes, ensuring that there is no data loss in case of a failure.

Scalability – StarWind SAN and NAS is highly scalable and can be easily expanded by adding more nodes to the storage pool. This allows you to scale your storage capacity as your business grows, without having to invest in expensive hardware.

Cost-Effective – StarWind SAN and NAS is a cost-effective storage solution that eliminates the need for expensive hardware. It uses commodity hardware and turns it into a powerful storage appliance, reducing the overall cost of ownership.

Easy to Use – StarWind SAN and NAS is easy to use and can be set up in minutes. It comes with a user-friendly web-based interface that allows you to manage your storage pool and monitor its performance.

Performance – StarWind SAN and NAS provides high-performance storage that can meet the demands of your virtualized environment. It uses advanced caching algorithms to optimize the performance of your storage pool, ensuring that your virtual machines run smoothly.

Integration with VMware vSphere – StarWind SAN and NAS integrates seamlessly with VMware vSphere, providing a powerful and scalable storage solution for your virtualized environment. It supports all the features of VMware vSphere, including vMotion, High Availability, and Distributed Resource Scheduler.

StarWind Virtual SAN – StarWind Virtual SAN is a software that eliminates the need for physical shared storage by simply “mirroring” internal hard disks and flash between hypervisor servers. It creates a VM-centric and high-performing storage pool for a VMware cluster. This allows you to create a highly available and scalable storage solution for your virtualized environment.

Quote:

StarWind SAN & NAS supports hardware and software-based storage redundancy configurations. The solution allows turning your server with internal storage into a redundant storage array presented as NAS or SAN, exposing standard protocols such as iSCSI, SMB, and NFS. It features Web-based UI, Text-based UI, vCenter Plugin, and Command-line interface for your cluster-wide operations.

A while back, we have created a short video from the deployment process for vSphere. However, please note that this product is evolving and today, it might look a bit different. Check the latest StarWind SAN and NAS version here.

https://www.youtube.com/embed/4Wzzk-d_BOM
How about vCenter server appliance on 2-hosts config?

Note: in 2-node config, your vCenter server appliance (VCSA) should be stored on shared storage. If you running your VCSA from local storage on one of your ESXi hosts, you risking the downtime of your VCSA in case this particular host fails. This does not mean, however, that vSphere HA or other cluster services will fail. Not at all, as VCSA is used only to configure vSphere HA, not responsible in triggering the actual HA event! It mean you can perfectly “lose” your VCSA and still have your VMs restarted on the remaining host automatically.

Performance Improvements of vSphere cluster

StarWind SAN and NAS can improve the performance of VMware vSphere in several ways. One of the main ways is through the use of StarWind Virtual SAN for vSphere, which creates a VM-centric and high-performing storage pool for a VMware cluster. This allows for faster data access and improved performance for virtual machines. StarWind SAN and NAS also uses advanced caching algorithms to optimize the performance of the storage pool. This ensures that frequently accessed data is stored in cache, reducing the time it takes to access the data and improving overall performance.

In addition, StarWind SAN and NAS provides high availability and redundancy, which can improve performance by reducing downtime and ensuring that data is always available. This is achieved through synchronous replicationwhich keeps the data in sync between the nodes, ensuring that there is no data loss in case of a failure. It supports all the features of VMware vSphere, including vMotion, High Availability, and Distributed Resource Scheduler, which can further improve performance by allowing for workload balancing and resource optimization.

Final Words

In conclusion, shared storage is a critical component of a VMware vSphere cluster. It provides a centralized location for storing virtual machine files, allowing virtual machines to be migrated between hosts without downtime and enabling advanced features such as HA and DRS. Properly configuring and managing shared storage is essential for ensuring the availability and performance of virtual machines in a vSphere cluster.

StarWind SAN and NAS is a powerful and cost-effective storage solution that can be used with VMware vSphere. It provides high availability, scalability, and performance, making it an ideal storage solution for virtualized environments. Its seamless integration with VMware vSphere and support for all its features make it a must-have for any virtualized environment.

More posts about StarWind on ESX Virtualization:

More posts from ESX Virtualization:

PHD Virtual Backup 6.0

By Vladan SEGET | Last Updated: June 28, 2023

PHD Virtual Backup 6.0 – Backup, Restore, Replication and Instant recovery. PHD Virtual has released their new version of backup software for VMware vSphere environments. PHD Virtual backup 6.0 comes up with several completely new features. Those features that are specific to virtualized environments. In this review I’ll focus more on those new features instead on the installation process, which is fairly simple. This review contains images, which can be clicked and enlarged (most of them) to see all the details from the UI.

Now first something that I was not aware of. Even if I work as a consultant, I must say I focus most of the time on the technical side of a solution which I’m implementing and I leave the commercial (licensing) part to vendors or resellers.  But with this review I would like to point out that PHD Virtual Backup 6.0 is licensed on a per-host basis. Not CPU Socket like some vendors do, but also not per site like other vendors do. As a result, their price is a fraction of the cost of competitive alternatives.

Introduction of PHD Virtual Backup and Recovery 6.0

The PHD Virtual Backup 6.0 comes up with quite a few new features that I will try to cover in my review. One of them is the Instant Recovery, which enables to run VM directly from a backup location and initiate storage vMotion from within VMware vSphere to move the VM back to your SAN.

But PHD Virtual goes even further by developing a proprietary function to initiate the move of the VM by using PHD Motion. What is it? It’s an alternative for SMB users which does not have VMware Enterprise and Enterprise Plus License, which includes storage vMotion.

PHD Motion does not require VMware’s storage vMotion in order to work. It leverages multiple streams, intelligent data restore, direct storage recovery to copy a running state of a VM back to the SAN, while the VM still runs in the sandbox at the storage location. Therefore, it is much faster at moving the data back to production than storage vMotion.

The delta changes to the VM are maintained in another, separate temporary location.  So the final switch back to SAN happens fairly quickly since only the deltas of changes between the VM which runs from the backup and the VM which is located back on SAN, are quickly copied. So small planned downtime (about the time for a VM reboot) is necessary.

Installation of the Software

PHD Virtual Backup 6.0

The installation will take like 5 minutes, just to deploy the OVF into vCenter and configure the network interface, storage …. and that’s it. Pretty cool!

One of those differences from previous version of PHD Virtual backup is the Instant Recovery Configuration TAB, since this feature has just been introduced in the PHD Virtual Backup 6.0.

The Instant recovery feature is available for Virtual Full backups only. The full/incremental backup types are not currently supported for instant recovery, so if you select the full/incremental option, you might see that the Instant Recovery option isn’t available. Use Virtual Full option when configuring your backup jobs to take benefit of Instant recovery.

PHD Virtual Backup and Replication 6.0 If you choose the full/incremental backup type, the Instant VM recovery isn't currently supported

PHD Virtual backup 6.0 – Replication of VMs.

Replication – This feature requires at least one PHD VBA installed and configured with access to both environments – but if you will be using replication in larger environments, you may need additional PHD VBAs. For instance, one PHD VBA deployed at the primary site would be configured to run regular backups of your VMs while a second PHD VBA could be deployed to the DR site configured to replicate VMs from the primary site to the secondary location.

The replication of VMs is functionality that is very useful for DR plans. You can also configure the replication within the same site as well, and choose a different datastore ( and ESXi host) as a destination. This is my case, because I wanted to test this function, since my lab don’t have two different locations.

The replication job works the way that only the first replica is full copy. PHD VM replication takes data from existing backups and replicates those to a cold standby VM. After the VM is initially created during the first pass, PHD uses its own logic to transfer only the changes from the previous run.

You can see the first and second job, when finishes on the image below. The latter one took only 51 s.

PHD Virtual Backup 6.0 - Replication Jobs

Testing Failover – After the replica VM is created, you have the option to test each replica to validate your standby environment or to failover to your replicated VMs. There is a Start Test button in order to proceed.

PHD Virtual 6.0 - testing failover button

What’s happening during the test. At first, another snapshot is created of the Replica VM. This is only to have the ability to get back to the state before the test. See the image below.

PHD Virtual Backup 6.0 - Testing the Replication with the Failover Test Button

This second snapshot is deleted the moment when you’re done with the testing of that failover VM, you tested that the application is working etc…. The VM is powered off and it is rolled back to the state it was in prior to testing mode.

So when you click the Stop Test button (it changed text), the replica Status is changed back to STANDBY, once again click Refresh button to refresh the UI.

If you lose your primary site, you can go to the PHD console at the DR site and failover the VMs which has been replicated there.  You can recover your production environment there by starting the VMs that has been replicated.  And now, when you run your production (or at least the most critical VMs) from DR site, and because you don’t have a failover site anymore, you should consider start backing up those VMs in failover mode….. it will be helpful when failing back to the main primary site, when damages there gets repaired.

Why one would have to start doing backups as soon as the VMs are in failover state ? …. Here is a quick quote from the manual:

When ending Failover, any changes made to the replica VM will be lost the next time replication runs. To avoid losing changes, be sure to fail back the replica VM (backup and restore) to a primary site prior to ending Failover mode.

I can only highly recommend to read the manual where you’ll find all the step-by-steps and all those details. In this review I can’t focus to provide all those step-by-step procedures. The manual is a PDF file very good quality, with many screenshots and walk through guides. In addition, there are some nice FAQ which were certainly created as a result of feedback from customer’s sites. One of them is for example a FAQ for increasing backup storage and the step-by-step follows. Nice.

You can see the possibility to end the failover test with the Stop Test button.

PHD Virtual Backup 6.0 - end falover test.

Seeding – If you have some huge amount of data to replicate for the DR site you can seed the VMs data before configuring the replication process. The seeding process is process when you pre-populate the VMs to the DR site first. This can be done through removable USB drives, or small NAS device. When the seeding is complete, you can start creating the replication jobs to move only the subsequent changes.

In fact the seeding process is fairly simple. Here is the outline. First create full backup of VMs > copy those backups to NAS or USB for transport >  Go to the DR site and deploy PHD VBA and add the data that you have with you as a replication datastore > create and run replication job to replicate all the VMs from the NAS (USB) to your DR site > Remove the replication datastore and the NAS and create the replication job where you specify the the primary site datastore as a source. Only the small, incremental changes will be replicated and sent over the WAN.

PHD Virtual Backup 6.0 – File level Recovery

File level recovery is a feature that is used at most in virtual environments, when it comes to console manipulations. I think, since more frequently you (or your users) are in need for file restore, than VM crashes or corruption, so the full VM needs to be restored.

I’ve covered the the FLR process in the 5.1 version by creating an iSCSI target and then mounting the volume as an additional disk in computer management, but the option was greatly simplified in PHD Virtual Backup 6.0. In fact when you run the assistant, you have the now a choice between the creation of iSCSI target and create windows share. I took the option Create Windows share.

All the backup/recovery/replication tasks are done through assistants. The task is composed with just few steps:

First selecting the recovery point , then create a windows share (or iSCSI target) > and mount this share to finally be able to copy-paste the files that needs to be restored from withing that particular VM.

The process is fast and direct. It takes few clicks to get the files back to the user’s VM. You can see the part of the process on the images at left and bellow.

PHD Virtual Backup and Replication 6.0 - file level restore final shot - you can than easily copy paste the files you need

PHD Virtual Backup 6.0 – Instant VM Recovery and PHD Motion – as said in the beginning of my review, the PHD virtual backup 6.0 has the ability to run VMs directly from backup location.

The Instant VM Recovery works out of the box without further necessity to setup the temporarily storage location, but if needed, the location for temporary changes can be changed from the defaults. But there is usually no need to do so.

You can do it in Configuration > Instant VM Recovery.

There is a choice between the attached virtual disk and VBA’s backup storage.

PHD Virtual Backup 6.0 - configuration of temporary storage location for Instant VM recovery

Then we can have a look and see how the Instant VM recovery option works. Let’s start by selecting the recovery point that we would want to use for that. An XP VM which I backed up earlier will do. Right Click the point in time from which one you want to recover (usually the latest), and choose recover.

PHD Virtual Backup 6.0 - Instant VM Recovery

At the next screen there is many options. I checked the Power On VM after recovery and Recover using original storage and network settings from backup. Like this the VM is up and running with network connectivity as soon as possible. I did also checked the option to Automatically start PHD Motion Seeding, which will start copying the VM back to my SAN.

When the copy finishes I’ll receive a confirmation e-mail…..  Note that you have a possibility to schedule this task as well.

PHD Virtual Backup 6.0 - Instant VM recovery and PHD Motion

On the next screen you can see the final screen before you hit the submit button. You can make changes there if you want.

PHD Virtual Backup 6.0 - Instant VM recovery and PHD Motion

The VM is registered in my vCenter and started from the backup location. 1 min later my VM was up. The VM was running from temporary storage created by PHD Virtual backup 6.0. The temporary storage that I configured before, when setting up the software.

You can see on the image below which tasks are performed by PHD Virtual backup 6.0 in the background.

PHD Virtual Backup 6.0 - Instant VM Recovery with PHD Motion

So, we have the Instant VM Recovery tested and our VM is up and running. Now there are two options, depending if you have storage vMotion licensed or not.

With VMware Storage vMotion – If that’s the case, you can initiate storage vMotion from the temporary datastore created by PHD Virtual back to your datastore located on your SAN.

When the migration completes, open the PHD Console and click Instant VM Recovery. In the Current tab, select the VM that
you migrated and click End Instant Recovery to remove the VM from the list.

Using PHD Motion – If you don’t have storage vMotion, you can use PHD Motion. How it works… Let’s see. You remember that during the assistant launching the Instant VM recovery, we selected an option to start PHD Motion seeding.

This option will start to copy the whole VM back to the datastore on the SAN (in my case it’s the Freenas datastore). I checked that option to start Automatically PHD Motion seeding when setting up the job, remember?

You can see it in the properties of the VM being run in the Instant VM recovery mode. On the image below you can see the temporary datastore (PHDIR-423…….) and the final destination’s datastore of the VM (the Freenas datastore).

PHD Virtual Backup 6.0 - Instant VM Recovery and PHD Motion

This process will take some time. So when you go back to the PHD Virtual console, you choose the Instant VM Recovery Menu option > Current Tab, you’ll see that Complete PHD Motion is grayed out. That’s because of the above mentioned copy hasn’t finished. Well it really does not matter, since you (or your users) can still work and use the VM.

PHD Virtual Backup 6.0 - Instant VM Recovery and PHD Motion

And you can see on the image below that when the seeding process has finished, the button Complete PHD Motion became activ. (In fact, the software drops you an e-mail that the seeding process has finished copying

PHD Virtual Backup 6.0 - PHD Motion

And then, after few minutes the VM dissapears from this tab. The process has finished the copy of the deltas and the VM can be powered back on. It’s definitely a time saver, and when no storage vMotion licenses (in SMBs) are available, this solution can cut the the downtime quite impressively. The History tab shows you the details.

PHD Virtual Backup 6.0 - Instant VM recovery with PHD Motion

PHD Virtual Backup 6.0 – The E-mail Reporting Capabilities.

PHD Virtual Backup 6.0 has got the possibility to report on backup/replication jobs success (failure). The configuration of it it’s made mores simpler now than in previous release, since there is a big Test button there in order to send test e-mail. I haven’t had any issues after entering the information for my e-mail server, but in case you’re using different ports or you’re behind a firewall, this option is certainly very useful.

PHD Virtual Backup 6.0 - E-mail Reporting Capabilities

In v6, PHD made the email reports WAY more attractive.  They have a great job summary at the job and lots of great information in a nicely formatted chart that shows details for each VM and each virtual disk.  They even color code errors and warnings.  Very cool.

PHD Virtual Backup 6.0 - E-mail reports

PHD Exporter

PHD Virtual Backup .60 has also few tools bundled within the software suite which can be useful. PHD Exporter is one of them. This application can help when you need to archive VMs with data. Usually you would want to install this software on physical windows server which has got a tape library attached. It’s great because you can schedule existing backups to be exported as compressed OVF files. So if you ever had to recover from an archive, you wouldn’t even need PHD to do the recovery.

The tool basically connects itself to the location where the backups are stored and through an internal processing does extract those backup files to be stored temporary in a location that you configure when you setting up – it’s called staging location. Usually it’s a local storage. Then the files are sent to tape for archiving purposes.

Through the console you configure exporting jobs where the VM backups are exported to staging location.

PHD Exporter - Tool to export backups to Tape for archiving purposes

PHD Virtual Backup 6.0 is Application Aware Backup Solution

PHD virtual Backup 6.0 can make a transactionally-consistent backups of MS Exchange with the possibility to truncate the logs. Log truncation is supported for Microsoft Exchange running on Windows 2003 Server 64 bit SP2 and later and Windows Server 2008 R2 SP1 and later.

When an application aware backup is started, PHD Guest Tools initiates the quiesce process and an application-consistent VSS snapshot is created on the VM. The backup process continues and writes the data to the backup store while this snapshot exists on disk. When the backup process completes, post-backup processing options are executed and the VSS snapshot is removed from the guest virtual machine.

PHD Virtual Backup 6.0 provides small agent called PHD Guest Tools, which is installed inside of the VM.  This application performs the necessary application aware functions, including Exchange log truncation. Additionally, you can add your own scripts to perform tasks for other applications. Scripts can be added before and after a snapshot, and after a backup completes. So it looks like they’ve got all the bases covered for when you might want to execute something on your own. I’ve tested with an Exchange 2010 VM and it worked great!

I was nicely surprised with the deduplication performance at the destination datastore. Here is a screenshot from the dashboard where you can see that the Dedupe ration is 33:1 and saved space 1.4 TB.

PHD Virtual Backup 6.0 - The dashboard

During the few days that I had the chance and time to play with the solution in my lab I did not have to look often in the manual, but if you do plan using the replication feature with several remote sites, I highly recommend to read the manual which is as I already told you, good quality.

PHD Virtual Backup 6.0 provides many features that are useful and provide real value for VMware admins. Replication and Instant Recovery are features which becomes a necessity providing short RTO.

PHD Virtual Backup 6.0  is an agent-less backup solution (except VMs which needs Application aware backups) which don’t use physical hardware, but runs as a virtual appliance with 1CPU and 1Gigs of RAM.  This backup software solution can certainly have its place in today’s virtualized infrastructures running VMware vSphere.

Please note that this review was sponsored by PHD Virtual.

Source :
https://www.vladan.fr/phd-virtual-backup-6-0/

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/

8 Essential Tips for Data Protection and Cybersecurity in Small Businesses

Michelle Quill — June 6, 2023

Small businesses are often targeted by cybercriminals due to their lack of resources and security measures. Protecting your business from cyber threats is crucial to avoid data breaches and financial losses.

Why is cyber security so important for small businesses?

Small businesses are particularly in danger of cyberattacks, which can result in financial loss, data breaches, and damage to IT equipment. To protect your business, it’s important to implement strong cybersecurity measures.

Here are some tips to help you get started:

One important aspect of data protection and cybersecurity for small businesses is controlling access to customer lists. It’s important to limit access to this sensitive information to only those employees who need it to perform their job duties. Additionally, implementing strong password policies and regularly updating software and security measures can help prevent unauthorized access and protect against cyber attacks. Regular employee training on cybersecurity best practices can also help ensure that everyone in the organization is aware of potential threats and knows how to respond in the event of a breach.

When it comes to protecting customer credit card information in small businesses, there are a few key tips to keep in mind. First and foremost, it’s important to use secure payment processing systems that encrypt sensitive data. Additionally, it’s crucial to regularly update software and security measures to stay ahead of potential threats. Employee training and education on cybersecurity best practices can also go a long way in preventing data breaches. Finally, having a plan in place for responding to a breach can help minimize the damage and protect both your business and your customers.

Small businesses are often exposed to cyber attacks, making data protection and cybersecurity crucial. One area of particular concern is your company’s banking details. To protect this sensitive information, consider implementing strong passwords, two-factor authentication, and regular monitoring of your accounts. Additionally, educate your employees on safe online practices and limit access to financial information to only those who need it. Regularly backing up your data and investing in cybersecurity software can also help prevent data breaches.

Small businesses are often at high risk of cyber attacks due to their limited resources and lack of expertise in cybersecurity. To protect sensitive data, it is important to implement strong passwords, regularly update software and antivirus programs, and limit access to confidential information.

It is also important to have a plan in place in case of a security breach, including steps to contain the breach and notify affected parties. By taking these steps, small businesses can better protect themselves from cyber threats and ensure the safety of their data.

Tips for protecting your small business from cyber threats and data breaches are crucial in today’s digital age. One of the most important steps is to educate your employees on cybersecurity best practices, such as using strong passwords and avoiding suspicious emails or links.

It’s also important to regularly update your software and systems to ensure they are secure and protected against the latest threats. Additionally, implementing multi-factor authentication and encrypting sensitive data can add an extra layer of protection. Finally, having a plan in place for responding to a cyber-attack or data breach can help minimize the damage and get your business back on track as quickly as possible.

Small businesses are attackable to cyber-attacks and data breaches, which can have devastating consequences. To protect your business, it’s important to implement strong cybersecurity measures. This includes using strong passwords, regularly updating software and systems, and training employees on how to identify and avoid phishing scams.

It’s also important to have a data backup plan in place and to regularly test your security measures to ensure they are effective. By taking these steps, you can help protect your business from cyber threats and safeguard your valuable data.

To protect against cyber threats, it’s important to implement strong data protection and cybersecurity measures. This can include regularly updating software and passwords, using firewalls and antivirus software, and providing employee training on safe online practices. Additionally, it’s important to have a plan in place for responding to a cyber attack, including backing up data and having a designated point person for handling the situation.

In today’s digital age, small businesses must prioritize data protection and cybersecurity to safeguard their operations and reputation. With the rise of remote work and cloud-based technology, businesses are more vulnerable to cyber attacks than ever before. To mitigate these risks, it’s crucial to implement strong security measures for online meetings, advertising, transactions, and communication with customers and suppliers. By prioritizing cybersecurity, small businesses can protect their data and prevent unauthorized access or breaches.

Here are 8 essential tips for data protection and cybersecurity in small businesses.

8 Essential Tips for Data Protection and Cybersecurity in Small Businesses

1. Train Your Employees on Cybersecurity Best Practices

Your employees are the first line of defense against cyber threats. It’s important to train them on cybersecurity best practices to ensure they understand the risks and how to prevent them. This includes creating strong passwords, avoiding suspicious emails and links, and regularly updating software and security systems. Consider providing regular training sessions and resources to keep your employees informed and prepared.

2. Use Strong Passwords and Two-Factor Authentication

One of the most basic yet effective ways to protect your business from cyber threats is to use strong passwords and two-factor authentication. Encourage your employees to use complex passwords that include a mix of letters, numbers, and symbols, and to avoid using the same password for multiple accounts. Two-factor authentication adds an extra layer of security by requiring a second form of verification, such as a code sent to a mobile device, before granting access to an account. This can help prevent unauthorized access even if a password is compromised.

3. Keep Your Software and Systems Up to Date

One of the easiest ways for cybercriminals to gain access to your business’s data is through outdated software and systems. Hackers are constantly looking for vulnerabilities in software and operating systems, and if they find one, they can exploit it to gain access to your data. To prevent this, make sure all software and systems are kept up-to-date with the latest security patches and updates. This includes not only your computers and servers but also any mobile devices and other connected devices used in your business. Set up automatic updates whenever possible to ensure that you don’t miss any critical security updates.

4. Use Antivirus and Anti-Malware Software

Antivirus and anti-malware software are essential tools for protecting your small business from cyber threats. These programs can detect and remove malicious software, such as viruses, spyware, and ransomware before they can cause damage to your systems or steal your data. Make sure to install reputable antivirus and anti-malware software on all devices used in your business, including computers, servers, and mobile devices. Keep the software up-to-date and run regular scans to ensure that your systems are free from malware.

5. Backup Your Data Regularly

One of the most important steps you can take to protect your small business from data loss is to back up your data regularly. This means creating copies of your important files and storing them in a secure location, such as an external hard drive or cloud storage service. In the event of a cyber-attack or other disaster, having a backup of your data can help you quickly recover and minimize the impact on your business. Make sure to test your backups regularly to ensure that they are working properly and that you can restore your data if needed.

6. Carry out a risk assessment

Small businesses are especially in peril of cyber attacks, making it crucial to prioritize data protection and cybersecurity. One important step is to assess potential risks that could compromise your company’s networks, systems, and information. By identifying and analyzing possible threats, you can develop a plan to address security gaps and protect your business from harm.

For Small businesses making data protection and cybersecurity is a crucial part. To start, conduct a thorough risk assessment to identify where and how your data is stored, who has access to it, and potential threats. If you use cloud storage, consult with your provider to assess risks. Determine the potential impact of breaches and establish risk levels for different events. By taking these steps, you can better protect your business from cyber threats

7. Limit access to sensitive data

One effective strategy is to limit access to critical data to only those who need it. This reduces the risk of a data breach and makes it harder for malicious insiders to gain unauthorized access. To ensure accountability and clarity, create a plan that outlines who has access to what information and what their roles and responsibilities are. By taking these steps, you can help safeguard your business against cyber threats.

8. Use a firewall

For Small businesses, it’s important to protect the system from cyber attacks by making data protection and reducing cybersecurity risk. One effective measure is implementing a firewall, which not only protects hardware but also software. By blocking or deterring viruses from entering the network, a firewall provides an added layer of security. It’s important to note that a firewall differs from an antivirus, which targets software affected by a virus that has already infiltrated the system.

Small businesses can take steps to protect their data and ensure cybersecurity. One important step is to install a firewall and keep it updated with the latest software or firmware. Regularly checking for updates can help prevent potential security breaches.

Conclusion

Small businesses are particularly vulnerable to cyber attacks, so it’s important to take steps to protect your data. One key tip is to be cautious when granting access to your systems, especially to partners or suppliers. Before granting access, make sure they have similar cybersecurity practices in place. Don’t hesitate to ask for proof or to conduct a security audit to ensure your data is safe.

Source :
https://onlinecomputertips.com/support-categories/networking/tips-for-cybersecurity-in-small-businesses/

Tailing Big Head Ransomware’s Variants, Tactics, and Impact

By: Ieriz Nicolle Gonzalez, Katherine Casona, Sarah Pearl Camiling
July 07, 2023

We analyze the technical details of a new ransomware family named Big Head. In this entry, we discuss the Big Head ransomware’s similarities and distinct markers that add more technical details to initial reports on the ransomware.

Reports of a new ransomware family and its variant named Big Head emerged in May, with at least two variants of this family being documented. Upon closer examination, we discovered that both strains shared a common contact email in their ransom notes, leading us to suspect that the two different variants originated from the same malware developer. Looking into these variants further, we  uncovered a significant number of versions of this malware. In this entry, we go deeper into the routines of these variants, their similarities and differences, and the potential impact of these infections when abused for attacks.

Analysis

In this section, we go expound on the three samples of Big Head we found, as well as their distinct functions and routines. While we continue to investigate and track this threat, we also highly suspect that all three samples of the Big Head ransomware are distributed via malvertisement as fake Windows updates and fake Word installers.

First sample

fig1-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 1. The infection routine of the first Big Head ransomware sample

The first sample of Big Head ransomware (SHA256: 6d27c1b457a34ce9edfb4060d9e04eb44d021a7b03223ee72ca569c8c4215438, detected by Trend Micro as Ransom.MSIL.EGOGEN.THEBBBC) featured a .NET compiled binary file. This binary checks the mutex name 8bikfjjD4JpkkAqrz using CreateMutex and terminates itself if the mutex name is found.

fig2-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 2. Calling CreateMutex function
fig3-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 3. MTX value “8bikfjjD4JpkkAqrz”

The sample also has a list of configurations containing details related to the installation process. It specifies various actions such as creating a registry key, checking the existence of a file and overwriting it if necessary, setting system file attributes, and creating an autorun registry entry. These configuration settings are separated by the pipe symbol “|” and are accompanied by corresponding strings that define the specific behavior associated with each action.

fig4-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 4. List of configurations

The format that the malware adheres to in terms of its behavior upon installation is as follows:

[String ExeName] [bool StartProcess] [bool CheckFileExists] [bool SetSystemAttribute] [String FilePath] [bool SetRegistryKey] [None]

Additionally, we noted the presence of three resources that contained data resembling executable files with the “*.exe” extension:

  • 1.exe drops a copy of itself for propagation. This is a piece of ransomware that checks for the extension “.r3d” before encrypting and appending the “.poop” extension.
  • Archive.exe drops a file named teleratserver.exe, a Telegram bot responsible for establishing communication with the threat actor’s chatbot ID.
  • Xarch.exe drops a file named BXIuSsB.exe, a piece of ransomware that encrypts files and encodes file names to Base64. It also displays a fake Windows update to deceive the victim into thinking that the malicious activity is a legitimate process.

These binaries are encrypted, rendering their contents inaccessible without the appropriate decryption mechanism.

fig5-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 5. Three resources found in the main sample
fig6-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 6. The encrypted content of one of the files located within the resource section (“1.exe”)

To extract the three binaries from the resources, the malware employs AES decryption with the electronic codebook (ECB) mode. This decryption process requires an initialization vector (IV) for proper decryption.

It is also noteworthy that the decryption key used is derived from the MD5 hash of the mutex 8bikfjjD4JpkkAqrz. This mutex is a hard-coded string value wherein its MD5 hash is used to decrypt the three binaries 1.exe, archive.exe, and Xarch.exe. It is important to note that the MTX value and the encrypted resources are different per sample.

We manually decrypted the content within each binary by exclusively utilizing the MD5 hash of the mutant name. Once this step was completed, we proceeded with the AES decryption to decrypt the encrypted resource file. 

fig7-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 7. Code for decrypting the three binaries (top) and the decrypted binary file that came from the parent file (bottom)

The following table shows the details of the binaries dropped by the decrypted malware using the MTX value 8bikfjjD4JpkkAqrz. These three binaries exhibit similarities with the parent sample in terms of code structure and binary extraction:

File nameBytesDropped file
1.exe2334881.exe
archive.exe12843536teleratserver.exe
Xarch.exe65552BXIuSsB.exe
fig8-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 8. 1.exe (left), teleratserver.exe (middle), and BXIuSsB.exe (right)

Binaries

This section details the binaries dropped, as identified from the previous table, and the first binary, 1.exe, was dropped by the parent sample.

            1.      Binary: 1.exe
                    Bytes: 222224
                    MTX value that was used to decrypt this file: 2AESRvXK5jbtN9Rvh

Initially, the file will hide the console window by using WinAPI ShowWindow with SW_HIDE (0). The malware will create an autorun registry key, which allows it to execute automatically upon system startup. Additionally, it will make a copy of itself, which it will save as discord.exe in the <%localappdata%> folder in the local machine.

fig9-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 9. ShowWindow API code hides the window of the current process (top) and the creation of the registry key and drops a copy of itself as “discord.exe” (bottom)

The Big Head ransomware checks for the victim’s ID in %appdata%\ID. If the ID exists, the ransomware verifies the ID and reads the content. Otherwise, it creates a randomly generated 40-character string and writes it to the file %appdata%\ID as a type of infection marker to identify its victims.

fig10-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 10. Randomly generating the 40-character string ID (top) and file named ID saved in the “<%appdata%>” folder (bottom)

The observed behavior indicates that files with the extension “.r3d” are specifically targeted for encryption using AES, with the key derived from the SHA256 hash of “123” in cipher block chaining (CBC) mode. As a result, the encrypted files end up having the “.poop” extension appended to them.

fig11-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 11. The malware checks for the extension that contains “.r3d” before encrypting and appending the ”.poop” extension (top) and the file encryption process when the file extension “.r3d” exists (bottom).

In this file, we also observed how the ransomware deletes its shadow copies. The command used to delete shadow copies and backups, which is also used to disable the recovery option is as follows:

/c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

It drops the ransom note on the desktop, subdirectories, and the %appdata% folder. The Big Head ransomware also changes the wallpaper of the victim’s machine. 

fig12-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 12. Ransom note of the “1.exe” binary
fig13-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 13. The wallpaper that appears on the victim’s machine

Lastly, it will execute the command to open a browser and access the malware developer’s Telegram account at hxxps[:]//t[.]me/[REDACTED]_69. Our analysis showed no particular action or communication being exchanged with this account in addition to the redirection.

        2.     Binary: teleratserver.exe
                Bytes: 12832480
                MTX value that was used to decrypt this file: OJ4nwj2KO3bCeJoJ1

Teleratserver is a 64-bit Python-compiled binary that acts as a communication channel between the threat actor and the victim via Telegram. It accepts the commands “start”, “help”, “screenshot”, and “message”.

fig14-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 14. Decompiled Python script from the binary

    3.      Binary: BXIuSsB.exe
             Bytes: 54288
             MTX value that was used to decrypt this file: gdmJp5RKIvzZTepRJ

The malware displays a fake Windows Update UI to deceive the victim into thinking that the malicious activity is a legitimate software update process, with the percentage of progress in increments of 100 seconds.

fig15-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 15. The code responsible for fake update (left) and the fake update shown to the user (right)

The malware terminates itself if the user’s system language matches the  Russian, Belarusian, Ukrainian, Kazakh, Kyrgyz, Armenian, Georgian, Tatar, and Uzbek country codes. The malware also disables the Task Manager to prevent users from terminating or investigating its process.

fig16-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 16. The “KillCtrlAltDelete” command responsible for disabling the Task Manager

The malware drops a copy of itself in the hidden folder <%temp%\Adobe> that it created, then creates an entry in the RunOnce registry key, ensuring that it will only run once at the next system startup.

fig17-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 17. Creation of AutoRun registry

The malware also randomly generates a 32-character key that will later be used to encrypt files. This key will then be encrypted using RSA-2048 with a hard-coded public key.

The ransomware then drops the ransom note that includes the encrypted key.

fig18-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 18. The ransom note

The malware avoids the directories that contain the following substrings:

  • WINDOWS or Windows
  • RECYCLER or Recycler
  • Program Files
  • Program Files (x86)
  • Recycle.Bin or RECYCLE.BIN
  • TEMP or Temp
  • APPDATA or AppData
  • ProgramData
  • Microsoft
  • Burn

By excluding these directories from its malicious activities, the malware reduces the likelihood of being detected by security solutions installed in the system and increases its chances of remaining undetected and operational for a longer duration. The following are the extensions that the Big Head ransomware encrypts:

“.mdf”, “.db”, “.mdb”, “.sql”, “.pdb”, “.pdb”, “.pdb”, “.dsk”, “.fp3”, “.fdb”, “.accdb”, “.dbf”, “.crd”, “.db3”, “.dbk”, “.nsf”, “.gdb”, “.abs”, “.sdb”, “.sdb”, “.sdb”, “.sqlitedb”, “.edb”, “.sdf”, “.sqlite”, “.dbs”, “.cdb”, “.cdb”, “.cdb”, “.bib”, “.dbc”, “.usr”, “.dbt”, “.rsd”, “.myd”, “.pdm”, “.ndf”, “.ask”, “.udb”, “.ns2”, “.kdb”, “.ddl”, “.sqlite3”, “.odb”, “.ib”, “.db2”, “.rdb”, “.wdb”, “.tcx”, “.emd”, “.sbf”, “.accdr”, “.dta”, “.rpd”, “.btr”, “.vdb”, “.daf”, “.dbv”, “.fcd”, “.accde”, “.mrg”, “.nv2”, “.pan”, “.dnc”, “.dxl”, “.tdt”, “.accdc”, “.eco”, “.fmp”, “.vpd”, “.his”, “.fid”

The malware also terminates the following processes:

“taskmgr”, “sqlagent”, “winword”, “sqlbrowser”, “sqlservr”, “sqlwriter”, “oracle”, “ocssd”, “dbsnmp”, “synctime”, “mydesktopqos”, “agntsvc.exeisqlplussvc”, “xfssvccon”, “mydesktopservice”, “ocautoupds”, “agntsvc.exeagntsvc”, “agntsvc.exeencsvc”, “firefoxconfig”, “tbirdconfig”, “ocomm”, “mysqld”, “sql”, “mysqld-nt”, “mysqld-opt”, “dbeng50”, “sqbcoreservice”

The malware renames the encrypted files using Base64. We observed the malware using the LockFile function which encrypts files by renaming them and adding a marker. This marker serves as an indicator to determine whether a file has been encrypted. Through further examination, we saw the function checking for the marker inside the encrypted file. When decrypted, the marker can be matched at the end of the encrypted file.

fig19-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 19. The LockFile function
fig20-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 20. Checking for the marker “###” (top) and finding the marker at the end of the encrypted file (bottom)

The malware targets the following languages and region or local settings of the current user’s operating system as listed in the following:

“ar-SA”, “ar-AE”, “nl-BE”, “nl-NL”, “en-GB”, “en-US”, “en-CA”, “en-AU”, “en-NZ”, “fr-BE”, “fr-CH”, “fr-FR”, “fr-CA”, “fr-LU”, “de-AT”, “de-DE”, “de-CH”, “it-CH”, “it-IT”, “ko-KR”, “pt-PT”, “es-ES”, “sv-FI”, “sv-SE”, “bg-BG”, “ca-ES”, “cs-CZ”, “da-DK”, “el-GR”, “en-IE”, “et-EE”, “eu-ES”, “fi-FI”, “hu-HU”, “ja-JP”, “lt-LT”, “nn-NO”, “pl-PL”, “ro-RO”, “se-FI”, “se-NO”, “se-SE”, “sk-SK”, “sl-SI”, “sv-FI”, “sv-SE”, “tr-TR”

The ransomware checks for strings like VBOX, Virtual, or VMware in the disk enumeration registry to determine whether the system is operating within a virtual environment. It also scans for processes that contain the following substring: VBox, prl_(parallel’s desktop), srvc.exe, vmtoolsd.

fig21-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 21. Checking for virtual machine identifiers (top) and processes (bottom)

The malware identifies specific process names associated with virtualization software to determine if the system is running in a virtualized environment, allowing it to adjust its actions accordingly for better success or evasion. It can also proceed to delete recovery backup available by using the following command line:

vssadmin delete shadows /all /quiet & bcdedit.exe /set {default} recoveryenabled no & bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures

After deleting the backup, regardless of the number available, it will proceed to delete itself using the SelfDelete() function. This function initiates the execution of the batch file, which will delete the malware executable and the batch file itself.

fig22-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 22. SelfDelete function

Second sample

The second sample of the Big Head ransomware we observed (SHA256: 2a36d1be9330a77f0bc0f7fdc0e903ddd99fcee0b9c93cb69d2f0773f0afd254, detected by Trend as Ransom.MSIL.EGOGEN.THEABBC) exhibits both ransomware and stealer behaviors.

fig23-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 23. The infection routine of the second sample of the Big Head ransomware

The main file drops and executes the following files:

  • %TEMP%\runyes.Crypter.bat
  • %AppData%\Roaming\azz1.exe
  • %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Server.exe

The ransomware activities are carried out by runyes.Crypter.bat and azz1.exe, while Server.exe is responsible for collecting information for stealing.

The file runyes.Crypter.bat drops a copy of itself and Cipher.psm1 and then executes the following command to begin encryption:

cmd  /c powershell -executionpolicy bypass -win hidden -noexit -file cry.ps1

The malware employs the AES algorithm to encrypt files and adds the suffix “.poop69news@[REDACTED]” to the encrypted files. It specifically targets files with the following extensions:

*.aif ,*.cda ,*.mid ,*.midi ,*.mp3 ,*.mpa ,*.ogg ,*.wav ,*.wma ,*.wpl ,*.7z ,*.arj ,*.deb ,*.pkg ,*.rar ,*.rpm ,*.tar ,*.gz ,*.z ,*.zip ,*.bin ,*.dmg ,*.iso ,*.toas ,*.vcd ,*.csv  ,*.dat ,*.db ,*.dbf ,*.log ,*.mdb ,*.sav ,*.sql ,*.tar ,*.xml ,*.email ,*.eml ,*.emlx ,*.msg ,*.oft ,*.ost ,*.pst ,*.vcf ,*.apk ,*.bat ,*.bin ,*.cgi ,*.pl ,*.com ,*.exe ,*.gadget ,*.jar ,*.msi ,*.py ,*.wsf ,*.fnt ,*.fon ,*.otf ,*.ttf ,*.ai ,*.bmp ,*.gif ,*.ico ,*.jpeg ,*.jpg ,*.png ,*.ps ,*.psd ,*.svg ,*.tif ,*.tiff ,*.asp ,*.aspx ,*.cer ,*.cfm ,*.cgi ,*.pl ,*.css ,*.htm ,*.html ,*.js ,*.jsp ,*.part ,*.php ,*.py ,*.rss ,*.xhtml ,*.key ,*.odp ,*.pps ,*.ppt ,*.pptx ,*.c ,*.class ,*.cpp ,*.cs ,*.h ,*.java ,*.pl ,*.sh ,*.swift ,*.vb ,*.ods ,*.xls ,*.xlsm ,*.xlsx ,*.bak ,*.cab ,*.cfg ,*.cpl ,*.cur ,*.dll ,*.dmp ,*.drv ,*.icns ,*.icoini ,*.lnk ,*.msi ,*.sys ,*.tmp ,*.3g2 ,*.3gp ,*.avi ,*.flv ,*.h264 ,*.m4v ,*.mkv ,*.mov ,*.mp4 ,*.mpg ,*.mpeg ,*.rm ,*.swf ,*.vob ,*.wmv ,*.doc ,*.docx ,*.odt ,*.pdf ,*.rtf ,*.tex ,*.txt ,*.wpd ,*.ps1 ,*.cmd ,*.vbs ,*.vmxf ,*.vmx ,*.vmsd ,*.vmdk ,*.nvram ,*.vbox

The file azz1.exe, which is also involved in other ransomware activities, establishes a registry entry at <HKCU\Software\Microsoft\Windows\CurrentVersion\Run>. This entry ensures the persistence of a copy of itself. It also drops a file containing the victim’s ID and a ransom note:

fig24-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 24. The ransom note for the second sample of the Big Head ransomware

Like the first sample, the second sample also changes the victim’s desktop wallpaper. Afterward, it will open the URL hxxps[:]//github[.]com/[REDACTED]_69 using the system’s default web browser. As of this writing, the URL is no longer available.

Other variants of this ransomware used the dropper azz1.exe as well, although the specific file might differ in each binary. Meanwhile, Server.exe, which we have identified as the WorldWind stealer, collects the following data:

  • Browsing history of all available browsers
  • List of directories
  • Replica of drivers
  • List of running processes
  • Product key
  • Networks
  • Screenshot of the screen after running the file

Third sample

The third sample (SHA256: 25294727f7fa59c49ef0181c2c8929474ae38a47b350f7417513f1bacf8939ff, detected by Trend as Ransom.MSIL.EGOGEN.YXDEL) includes a file infector we identified as Neshta in its chain.

fig25-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 25. The infection routine of the third sample of the Big Head ransomware

Neshta is a virus designed to infect and insert its malicious code into executable files. This malware also has a characteristic behavior of dropping a file called directx.sys, which contains the full path name of the infected file that was last executed. This behavior is not commonly observed in most types of malware, as they typically do not store such specific information in their dropped files.

Incorporating Neshta into the ransomware deployment can also serve as a camouflage technique for the final Big Head ransomware payload. This technique can make the piece of malware appear as a different type of threat, such as a virus, which can divert the prioritization of security solutions that primarily focus on detecting ransomware.

Notably, the ransom note and wallpaper associated with this binary are different from the ones previously mentioned.

fig26-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 26. Wallpaper (top) and ransom note (bottom) used in the victim’s machine post infection

The Big Head ransomware exhibits unique behaviors during the encryption process, such as displaying the Windows update screen as it encrypts files to deceive users and effectively locking them out of their machines, renaming the encrypted files using Base64 encoding to provide an extra layer of obfuscation, and as a whole making it more challenging for users to identify the original file names and types of encrypted files. We also noted the following significant distinctions among the three versions of the Big Head ransomware:

  • The first sample incorporates a backdoor in its infection chain.
  • The second sample employs a trojan spy and/or info stealer.
  • The third sample utilizes a file infector. 

Threat actor

The ransom note clearly indicates that the malware developer utilizes both email and Telegram for communication with their victims. Upon further investigation with the given Telegram username, we were directed to a YouTube account.

The account on the platform is relatively new, having joined on April 19, 2023, With a total of 12 published videos as of this writing. This YouTube channel showcases demonstrations of the piece of malware the cybercriminals have. We also noted that in a pinned comment on each of their videos, they explicitly state their username on Telegram. 

fig27-big-head-ransomware-variants-tactics-impact-worldwind-stealer-neshta
Figure 27. A new YouTube account with a number of videos featuring pieces of malware (top) and a Telegram username pinned in the comments section for all videos (bottom)

While we suspect that this actor engages in transactions on Telegram, it is worth noting that the YouTube name “aplikasi premium cuma cuma” is a phrase in Bahasa that translates to “premium application for free.” While it is possible, we can only speculate on any connection between the ransomware and the countries that use the said language.

Insights

Aside from the specific email address to tie all the samples of the Big Head ransomware together, the ransom notes from the samples have the same bitcoin wallet and drops the same files. Looking at the samples altogether, we can see that all the routines have the same structure in the infection process that it follows once the ransomware infects a system.

The malware developers mention in the comment section of their YouTube videos that they have a “new” Telegram account, indicative of an old one previously used. We also checked their Bitcoin wallet history and found transactions made in 2022. While we’re unaware of what those transactions are, the history implies that these cybercriminals are not new at this type of threats and attacks, although they might not be sophisticated actors as a whole.

The discovery of the Big Head ransomware as a developing piece of malware prior to the occurrence of any actual attacks or infections can be seen as a huge advantage for security researchers and analysts. Analysis and reporting of the variants provide an opportunity to analyze the codes, behaviors, and potential vulnerabilities. This information can then be used to develop countermeasures, patch vulnerabilities, and enhance security systems to mitigate future risks.

Moreover, advertising on YouTube without any evidence of “successful penetrations or infections” might seem premature promotional activities from a non-technical perspective. From a technical point of view, these malware developers left recognizable strings, used predictable encryption methods, or implementing weak or easily detectable evasion techniques, among other “mistakes.”

However, security teams should remain prepared given the malware’s diverse functionalities, encompassing stealers, infectors, and ransomware samples. This multifaceted nature gives the malware the potential to cause significant harm once fully operational, making it more challenging to defend systems against, as each attack vector requires separate attention.

Indicators of Compromise (IOCs)

You can download the IOCs here

Tailing Big Head Ransomware’s Variants, Tactics, and Impact

Indicators of Compromise (IOCs)

Filename				SHA256									Detection			Description
Read Me First!.txt			Ransom note
1.exe 					6d27c1b457a34ce9edfb4060d9e04eb44d021a7b03223ee72ca569c8c4215438	Ransom.MSIL.EGOGEN.THEBBBC 	First sample
1.exe 					226bec8acd653ea9f4b7ea4eaa75703696863841853f488b0b7d892a6be3832a	Ransom.MSIL.EGOGEN.YXDFE	
123yes.exe 				ff900b9224fde97889d37b81855a976cddf64be50af280e04ce53c587d978840	Ransom.MSIL.EGOGEN.YXDEO	
archive.exe 				cf9410565f8a06af92d65e118bd2dbaeb146d7e51de2c35ba84b47cfa8e4f53b	Ransom.MSIL.EGOGEN.YXDFZ	
azz1.exe, discord.exe 			1c8bc3890f3f202e459fb87acec4602955697eef3b08c93c15ebb0facb019845	Ransom.MSIL.EGOGEN.YXDEW	
BXIuSsB.exe 				64246b9455d76a094376b04a2584d16771cd6164db72287492078719a0c749ab	Ransom.MSIL.EGOGEN.YXDEL	
ConsoleApp2.exe 			0dbfd3479cfaf0856eb8a75f0ad4fccb5fd6bd17164bcfa6a5a386ed7378958d	Ransom.MSIL.EGOGEN.YXDEW	
cry.ps1 				6698f8ffb7ba04c2496634ff69b0a3de9537716cfc8f76d1cfea419dbd880c94	Ransom.PS1.EGOGEN.YXDFV	
Cipher.psm1, 													Ransom.PS1.EGOGEN.YXDFZ	
discord.exe 				b8e456861a5fb452bcf08d7b37277972a4a06b0a928d57c5ec30afa101d77ead	Ransom.MSIL.EGOGEN.YXDEL	
discord.exe 				6b3bf710cf4a0806b2c5eaa26d2d91ca57575248ff0298f6dee7180456f37d2e	Ransom.MSIL.EGOGEN.YXDEL	
docx.Crypter.bat, runyes.Crypter.bat 	6b771983142c7fa72ce209df8423460189c14ec635d6235bf60386317357428a	Ransom.BAT.EGOGEN.YXDFZ 	
event-stream.exe 			627b920845683bd7303d33946ff52fb2ea595208452285457aa5ccd9c01c3b0a	HackTool.Win32.EventStream.A	
l.bat 					40d11a20bd5ca039a15a0de0b1cb83814fa9b1d102585db114bba4c5895a8a44	Ransom.BAT.EGOGEN.YXDFZ	
Locker.ps1 				159fbb0d04c1a77d434ce3810d1e2c659fda0a5703c9d06f89ee8dc556783614	Ransom.PS1.EGOGEN.YXDEL	
locker.ps1 				9aa38796e0ce4866cff8763b026272eb568fa79d8a147f7d61824752ad6d8f09	Ransom.PS1.EGOGEN.YXDFZ	
program.exe 				39caec2f2e9fda6e6a7ce8f22e29e1c77c8f1b4bde80c91f6f78cc819f031756	Ransom.MSIL.EGOGEN.YXDEP	
Prynts.exe 				1ada91cb860cd3318adbb4b6fd097d31ad39c2718b16c136c16407762251c5db	TrojanSpy.MSIL.STORMKITTY.D	
r.pyw 					be6416218e2b1a879e33e0517bcacaefccab6ad2f511de07eebd88821027f92d	Ransom.Python.EGOGEN.YXDFZ 	
Server.exe 				9a7889147fa53311ba7ec8166c785f7a935c35eba4a877c1313a8d2e80e3230d	TrojanSpy.MSIL.WORLDWIND.A	Dropped WorldWind Stealer
Server.exe  				f6a2ec226c84762458d53f5536f0a19e34b2a9b03d574ae78e89098af20bcaa3	PE_NESHTA.A	
sfchost.exe, 12.exe 			1942aac761bc2e21cf303e987ef2a7740a33c388af28ba57787f10b1804ea38e	Ransom.MSIL.EGOGEN.YXDEL	
slam.exe 				f354148b5f0eab5af22e8152438468ae8976db84c65415d3f4a469b35e31710f	Ransom.MSIL.EGOGEN.YXDE4	
ssissa.Crypter.bat  			037f9434e83919506544aa04fecd7f56446a7cc65ee03ac0a11570cf4f607853	Ransom.BAT.EGOGEN.YXDFZ	
svchost.com 				980bac6c9afe8efc9c6fe459a5f77213b0d8524eb00de82437288eb96138b9a2	PE_NESHTA.A-O	
teleratserver.exe 			603fcc53fd7848cd300dad85bef9a6b80acaa7984aa9cb9217cdd012ff1ce5f0	Backdoor.WIn64.TELERAT.A	
Xarch.exe     				bcf8464d042171d7ecaada848b5403b6a810a91f7fd8f298b611e94fa7250463	Ransom.MSIL.EGOGEN.YXDEV	
XarchiveOutput.exe			64aac04ffb290a23ab9f537b1143a4556e6893d9ff7685a11c2c0931d978a931	Ransom.MSIL.EGOGEN.YXDEV	
Xatput.exe 				f59c45b71eb62326d74e83a87f821603bf277465863bfc9c1dcb38a97b0b359d	Ransom.MSIL.EGOGEN.YXDEV	
Xserver.exe 				2a36d1be9330a77f0bc0f7fdc0e903ddd99fcee0b9c93cb69d2f0773f0afd254	Ransom.MSIL.EGOGEN.THEABBC	Second sample
Xsput.exe 				66bb57338bec9110839dc9a83f85b05362ab53686ff7b864d302a217cafb7531	Ransom.MSIL.EGOGEN.YXDEV	
Xsuut.exe 				806f64fda529d92c16fac02e9ddaf468a8cc6cbc710dc0f3be55aec01ed65235	Ransom.MSIL.EGOGEN.YXDEV	
Xxut.exe 				9c1c527a826d16419009a1b7797ed20990b9a04344da9c32deea00378a6eeee2	Ransom.MSIL.EGOGEN.YXDEO 	
iXZAF					40e5050b894cb70c93260645bf9804f50580050eb131e24f30cb91eec9ad1a6e	Ransom.MSIL.EGOGEN.THFBIBC	
XBtput.exe 				25294727f7fa59c49ef0181c2c8929474ae38a47b350f7417513f1bacf8939ff	Ransom.MSIL.EGOGEN.YXDEL	Third sample
XBtput2.exe 				dcfa0fca8c1dd710b4f40784d286c39e5d07b87700bdc87a48659c0426ec6cb6	Ransom.MSIL.EGOGEN.YXDEO	

Source :
https://www.trendmicro.com/it_it/research/23/g/tailing-big-head-ransomware-variants-tactics-and-impact.html

Part 2: Rethinking cache purge with a new architecture

21/06/2023

In Part 1: Rethinking Cache Purge, Fast and Scalable Global Cache Invalidation, we outlined the importance of cache invalidation and the difficulties of purging caches, how our existing purge system was designed and performed, and we gave a high level overview of what we wanted our new Cache Purge system to look like.

It’s been a while since we published the first blog post and it’s time for an update on what we’ve been working on. In this post we’ll be talking about some of the architecture improvements we’ve made so far and what we’re working on now.

Cache Purge end to end

We touched on the high level design of what we called the “coreless” purge system in part 1, but let’s dive deeper into what that design encompasses by following a purge request from end to end:

Step 1: Request received locally

An API request to Cloudflare is routed to the nearest Cloudflare data center and passed to an API Gateway worker. This worker looks at the request URL to see which service it should be sent to and forwards the request to the appropriate upstream backend. Most endpoints of the Cloudflare API are currently handled by centralized services, so the API Gateway worker is often just proxying requests to the nearest “core” data center which have their own gateway services to handle authentication, authorization, and further routing. But for endpoints which aren’t handled centrally the API Gateway worker must handle authentication and route authorization, and then proxy to an appropriate upstream. For cache purge requests that upstream is a Purge Ingest worker in the same data center.

Step 2: Purges tested locally

The Purge Ingest worker evaluates the purge request to make sure it is processible. It scans the URLs in the body of the request to see if they’re valid, then attempts to purge the URLs from the local data center’s cache. This concept of local purging was a new step introduced with the coreless purge system allowing us to capitalize on existing logic already used in every data center.

By leveraging the same ownership checks our data centers use to serve a zone’s normal traffic on the URLs being purged, we can determine if those URLs are even cacheable by the zone. Currently more than 50% of the URLs we’re asked to purge can’t be cached by the requesting zones, either because they don’t own the URLs (e.g. a customer asking us to purge https://cloudflare.com) or because the zone’s settings for the URL prevent caching (e.g. the zone has a “bypass” cache rule that matches the URL). All such purges are superfluous and shouldn’t be processed further, so we filter them out and avoid broadcasting them to other data centers freeing up resources to process more legitimate purges.

On top of that, generating the cache key for a file isn’t free; we need to load zone configuration options that might affect the cache key, apply various transformations, et cetera. The cache key for a given file is the same in every data center though, so when we purge the file locally we now return the generated cache key to the Purge Ingest worker and broadcast that key to other data centers instead of making each data center generate it themselves.

Step 3: Purges queued for broadcasting

purge request to small colo, ingest worker sends to queue worker in T1

Once the local purge is done the Purge Ingest worker forwards the purge request with the cache key obtained from the local cache to a Purge Queue worker. The queue worker is a Durable Object worker using its persistent state to hold a queue of purges it receives and pointers to how far along in the queue each data center in our network is in processing purges.

The queue is important because it allows us to automatically recover from a number of scenarios such as connectivity issues or data centers coming back online after maintenance. Having a record of all purges since an issue arose lets us replay those purges to a data center and “catch up”.

But Durable Objects are globally unique, so having one manage all global purges would have just moved our centrality problem from a core data center to wherever that Durable Object was provisioned. Instead we have dozens of Durable Objects in each region, and the Purge Ingest worker looks at the load balancing pool of Durable Objects for its region and picks one (often in the same data center) to forward the request to. The Durable Object will write the purge request to its queue and immediately loop through all the data center pointers and attempt to push any outstanding purges to each.

While benchmarking our performance we found our particular workload exhibited a “goldilocks zone” of throughput to a given Durable Object. On script startup we have to load all sorts of data like network topology and data center health–then refresh it continuously in the background–and as long as the Durable Object sees steady traffic it stays active and we amortize those startup costs. But if you ask a single Durable Object to do too much at once like send or receive too many requests, the single-threaded runtime won’t keep up. Regional purge traffic fluctuates a lot depending on local time of day, so there wasn’t a static quantity of Durable Objects per region that would let us stay within the goldilocks zone of enough requests to each to keep them active but not too many to keep them efficient. So we built load monitoring into our Durable Objects, and a Regional Autoscaler worker to aggregate that data and adjust load balancing pools when we start approaching the upper or lower edges of our efficiency goldilocks zone.

Step 4: Purges broadcast globally

multiple regions, durable object sends purges to fanouts in other regions, fanout sends to small colos in their region

Once a purge request is queued by a Purge Queue worker it needs to be broadcast to the rest of Cloudflare’s data centers to be carried out by their caches. The Durable Objects will broadcast purges directly to all data centers in their region, but when broadcasting to other regions they pick a Purge Fanout worker per region to take care of their region’s distribution. The fanout workers manage queues of their own as well as pointers for all of their region’s data centers, and in fact they share a lot of the same logic as the Purge Queue workers in order to do so. One key difference is fanout workers aren’t Durable Objects; they’re normal worker scripts, and their queues are purely in memory as opposed to being backed by Durable Object state. This means not all queue worker Durable Objects are talking to the same fanout worker in each region. Fanout workers can be dropped and spun up again quickly by any metal in the data center because they aren’t canonical sources of state. They maintain queues and pointers for their region but all of that info is also sent back downstream to the Durable Objects who persist that data themselves, reliably.

But what does the fanout worker get us? Cloudflare has hundreds of data centers all over the world, and as we mentioned above we benefit from keeping the number of incoming and outgoing requests for a Durable Object fairly low. Sending purges to a fanout worker per region means each Durable Object only has to make a fraction of the requests it would if it were broadcasting to every data center directly, which means it can process purges faster.

On top of that, occasionally a request will fail to get where it was going and require retransmission. When this happens between data centers in the same region it’s largely unnoticeable, but when a Durable Object in Canada has to retry a request to a data center in rural South Africa the cost of traversing that whole distance again is steep. The data centers elected to host fanout workers have the most reliable connections in their regions to the rest of our network. This minimizes the chance of inter-regional retries and limits the latency imposed by retries to regional timescales.

The introduction of the Purge Fanout worker was a massive improvement to our distribution system, reducing our end-to-end purge latency by 50% on its own and increasing our throughput threefold.

Current status of coreless purge

We are proud to say our new purge system has been in production serving purge by URL requests since July 2022, and the results in terms of latency improvements are dramatic. In addition, flexible purge requests (purge by tag/prefix/host and purge everything) share and benefit from the new coreless purge system’s entrypoint workers before heading to a core data center for fulfillment.

The reason flexible purge isn’t also fully coreless yet is because it’s a more complex task than “purge this object”; flexible purge requests can end up purging multiple objects–or even entire zones–from cache. They do this through an entirely different process that isn’t coreless compatible, so to make flexible purge fully coreless we would have needed to come up with an entirely new multi-purge mechanism on top of redesigning distribution. We chose instead to start with just purge by URL so we could focus purely on the most impactful improvements, revamping distribution, without reworking the logic a data center uses to actually remove an object from cache.

This is not to say that the flexible purges haven’t benefited from the coreless purge project. Our cache purge API lets users bundle single file and flexible purges in one request, so the API Gateway worker and Purge Ingest worker handle authorization, authentication and payload validation for flexible purges too. Those flexible purges get forwarded directly to our services in core data centers pre-authorized and validated which reduces load on those core data center auth services. As an added benefit, because authorization and validity checks all happen at the edge for all purge types users get much faster feedback when their requests are malformed.

Next steps

While coreless cache purge has come a long way since the part 1 blog post, we’re not done. We continue to work on reducing end-to-end latency even more for purge by URL because we can do better. Alongside improvements to our new distribution system, we’ve also been working on the redesign of flexible purge to make it fully coreless, and we’re really excited to share the results we’re seeing soon. Flexible cache purge is an incredibly popular API and we’re giving its refresh the care and attention it deserves.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet applicationward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you’re looking for a new career direction, check out our open positions.

Source :
https://blog.cloudflare.com/rethinking-cache-purge-architecture/

Exit mobile version