Category: Sophos

Ransomware operators are always on the lookout for a way to take their ransomware to the next level. That’s particularly true of the gang behind LockBit. Following the lead of the Maze and REvil ransomware crime rings, LockBit’s operators are now threatening to leak the data of their victims in order to extort payment. And the ransomware itself also includes a number of technical improvements that show LockBit’s developers are climbing the ransomware learning curve—and have developed an interesting technique to circumvent Windows’ User Account Control (UAC).

Because of recent dynamics in the ransomware world, we suspect that this privilege-escalation technique will pop up in other ransomware families in the future. We’ve seen a surge in “imposter” ransomware that are essentially rebranded variants of already-existing ransomware. Not a single day goes by where a new brand of ransomware does not come out. It has become surprisingly easy to clone ransomware and release it, with small modifications, under a different umbrella.

The Ransomware Learning Curve

Before we jump into the synopsis of LockBit, let’s take a moment to look at how ransomware is developed, in general. Many families follow a common timeline when it comes to the techniques and procedures ransomware developers implement at each stage. This appears to stem from the learning curve involved in creating ransomware, and the iteration of the malware as the developer builds his or her related knowledge of the malware craft.

Each ransomware seems to have an “infancy phase,” where the developer implements TTPs hastily just so the “product” can come out and start gaining its reputation. In this phase, the simplest ideas are implemented first, strings are usually plain text, the encryption is implemented in a way that only a single-thread is used, and LanguageID checks are in place to avoid encrypting computers in CIS countries. and avoid attracting unwanted attention from CIS law enforcement agencies.

After about 2 months into the ransomware operation, the developer starts implementing more sophisticated elements. They may introduce multi-threading, establish a presence in underground forums, obfuscate or encrypt strings in the binary, and there is usually a skip list/kill list for services and processes.

Around 4 months into the ransomware’s life, we start seeing things get more serious. The business model may now switch to Ransomware as a Service (RaaS), putting an Affiliate program in place. Oftentimes, binaries are cryptographically signed with valid, stolen certificates. There is a possibility that the ransomware developer starts implementing UAC bypasses at this stage. This appears to be the stage the LockBit group is entering.

Advertising the goods

As with most ransomware, LockBit maintains a forum topic on a well-known underground web board to promote their product. Ransomware operators maintain a forum presence mainly to advertise the ransomware, discuss customer inquiries and bugs, and to advertise an affiliate program through which other criminals can lease components of the ransomware code to build their own ransomware and infrastructure.

In January, LockBit’s operators created a new thread in the web board’s marketplace forum, announcing the “LockBit Cryptolocker Affiliate Program” and advertising the capabilities of their malware. The post claims that the new version had been in development since September of 2019, and emphasizes the performance of the encryptor and its lower use of system resources to prevent its detection.

LockBit’s post indicates that “we do not work in the CIS,” meaning that the ransomware will not target victims in Russia and other Commonwealth of Independent States countries. This comes as no surprise—as we have seen previously, CIS authorities don’t bother investigating these groups unless they are operating against targets in their area of jurisdiction.

That does not mean that the LockBit group won’t do business with other CIS-based gangs. In fact, they won’t work with English-speaking developers without a Russian-speaking “guarantor” to vouch for them.

Escalating the extortion

In this most recent evolution of LockBit, the malware now drops a ransom note that threatens to leak data the malware has stolen from victims: “!!! We also download huge amount of your private data, including finance information, clients personal info, network diagrams, passwords and so on. Don’t forget about GDPR.”

If the threat were to be carried out, it might result in real-world sanctions against the ransomware victims from regulators or privacy authorities—for example, for violating the European Union’s General Data Privacy Rules (GDPR) that make companies responsible for securing sensitive customer data in their possession.

An increasing number of ransomware gangs use extortion that threatens the release of private data, which might include sensitive customer information, trade secrets, or embarrassing correspondence to incentivize victims to pay the ransom, even if they have backups that prevented data loss. The data leak threat has become a signature of the REvil and Maze ransomware gangs; the Maze group has gone as far as to publicly publish chunks of data from victims who fail to pay by the deadline, taking down the dumps when they are finally paid.

Picking through LockBit’s code

From a first glance at the recent LockBit sample with a reverse-engineering tool, we can tell that the program was written primarily in C++ with some additions made using Assembler. For example, a few anti-debug techniques employ the fs:30h function call to manually check the PEB (Process Environment Block) for the BeingDebugged flag, instead of using IsDebuggerPresent().

The first thing the ransomware does at execution is to check whether the sample was executed with any parameters added from the command line. Usually, this is done to check for whether the sample is being executed in a sandbox environment. Contemporary malware often requires that the command to run the malware use specific parameters to prevent the malware from being analyzed by an automated sandbox, which often execute samples without parameters. But the LockBit sample we examined doesn’t do that—it won’t execute if there is any parameter entered from the command line. If there are no arguments in the command that executes it, Lockbit hides its console output, where the malware prints debug messages, and proceeds to do its job.

This could be intended to detect if the sample was executed in a sandbox environment. But it’s possible that either the malware author made a mistake in the implementation of the check (and wanted to check the other way around), or that this behavior is just a placeholder, and future versions will introduce different logic.

Hiding strings

LockBit’s author also used several techniques to make it more difficult to reconstruct the code behind it. The Portable Executable (PE) binary shows signs of being heavily optimized, as well as some efforts by the group to cover their coding tracks—or at least get rid of some of the low-hanging fruit that reverse engineering tools look for, such as unencrypted text strings.

Those heavy optimizations also increase LockBit’s performance. The binary makes heavy use of Intel’s SSE instruction set and architecture-specific features to boost its performance. That includes the use of multiple XMM registers used to store and decrypt the service names, process names and other strings used to interact with the operating system that are unique to the ransomware.

These string variables get decrypted on the fly with a 1-byte XOR key unique to each string: the first hex byte of every variable.

Almost all the functions contain a small routine that loops around and is in charge of decrypting hidden strings. In this case, we can see that how the original MSSQLServerADHelper100 service name gets de-obfuscated: the malware leverages a one-byte “0A” XOR key to decrypt the plaintext service name.

Check your privilege

To ensure that it can do the most damage possible, LockBit has a procedure to check whether its process has Administrator privileges. And if it doesn’t, it uses a technique that is growing in popularity among malware developers: a Windows User Account Control (UAC) bypass.

Leveraging OpenProcessToken, it queries the current process via a TOKEN_QUERY access mask. After that, it calls CreateWellKnownSid to create a user security identifier (SID) that matches the administrator group (WinBuiltinAdministratorsSid), so now the malware has a reference it can use for comparisons. Finally, it checks whether the current process privileges are sufficient for Administrator rights, with a call to CheckTokenMembership.

If the current process does not have Admin privileges, the ransomware tries to sidestep Windows UAC with a bypass. In order for that to succeed, a Windows COM object needs to auto-elevate to Admin-level access first.

To make this possible, LockBit calls a procedure called supMasqueradeProcess upon process initialization. Using supMasqueradeProcess allows LockBit to conceal its process’ information by injecting into a process running in a trusted directory. And what better target is there for that than explorer.exe?

The source code for the masquerade procedure can be found in a Github repository.

With the use of IDA Pro’s COM helper tool, we see two CLSIDs—globally unique identifiers that identify COM class object—that LockBit’s code references. CLSIDs, represented as 128-bit hexadecimal numbers within a pair of curly braces, are stored in the Registry path HKEY_LOCAL_MACHINESoftwareClassesCLSID.

Looking up these reveals that the two CSLIDS belong to IColorDataProxy and ICMLuaUtil—both undocumented COM interfaces that are prone to UAC bypass.

Masquerading as explorer.exe, LockBit calls CoInitializeEx to initialize the COM library, with COINIT_MULTITHREADED and COINIT_DISABLE_OLE1DDE flags to set the concurrency model. The hex values here (CLSIDs) are then moved and aligned into the stack segment register, and the next function call (lockbit.413980) will further use them.

Lockbit.413980 hosts the COM elevation moniker, which allows applications that are running under user account control (UAC) to activate COM classes (via the following format: Elevation:Administrator!new:{guid} ) with elevated privileges.

The malware adds the 2 previously seen CLSIDs to the moniker and executes them.

Now, the privilege has been successfully elevated with the UAC bypass and the control flow is passed back to the ransomware. We also notice two events and a registry key change during the execution:

Kill or skip

LockBit enumerates the currently running processes and started services via the API calls CreateToolhelp32Snapshot, Process32First, Process32Next and finally OpenProcess, and compares the names against an internal service and process list. If one process matches with one on the list, LockBit will attempt to terminate it via TerminateProcess.

The procedure to kill a service is a bit different. The malware will first connect to the Service Control Manager via OpenSCManagerA. It then attempts to check whether a service from the list exists via OpenServiceA. If the targeted service is present, it then tries to determine its state by calling to QueryServiceStatusEx. Based on the status returned, it will call ControlService with the parameter SERVICE_CONTROL_STOP (0x00000001) on the specific service to stop it. But before that, another function (0x40F310) will cycle through all dependent services in conjunction with the target service, so dependencies are stopped too. The malware will initiate calls to EnumDependentServicesA to achieve this.

The services that the malware tries to stop include anti-virus software (to avoid detection) and backup solution services. (Sophos is not affected by this attempt.) Other services are stopped because they might lock files on the disk, and might make it more difficult for the ransomware to easily acquire handles to files—stopping them improves LockBit’s effectiveness.

Some of the services of note that the ransomware attempts to stop, in the order they are coded into the ransomware, are:

In addition to the list of services to kill, LockBit also carries a list of things not to encrypt, including certain folders, specific files and files with certain extensions that are important to the operating system—since disabling the operating system would make it difficult for the victim to receive and act upon the ransom note. These are stored in obfuscated lists within the code (shown below), A function within LockBit uses the FindFirstFileExW and FindNextFileW API calls to read through the file names and folder names on the targeted disk, and then a simple lstrcmpiW function is called to compare the hardcoded list with those names.

This slideshow requires JavaScript.

Accelerating file encryption

Recently, we have seen ransomware groups taking more advanced concepts and applying it to their craft. One of these advanced concepts applied in LockBit is the use of Input/Output Completion Ports (IOCPs).

IOCPs are a model for creating a queue to efficient threads to process multiple asynchronous I/O requests. They allow processes to handle many concurrent asynchronous I/O more quickly and efficiently without having to create new threads each time they get an I/O request.

That capability makes them well-suited to ransomware. The sole purpose of ransomware is to encrypt as many delicate files as possible, rendering the user’s data useless. REvil (Sodinokibi) ransomware also uses IOCPs to achieve higher encryption performance.

LockBit’s aim was to be much faster than any other multi-threaded locker. The group behind the ransomware claims to have used the following methods to boost the performance of their file encryption:

• Open files with the FILE_FLAG_NO_BUFFERING flag, write by sector size
• Transfer work with files to Native API
• Use asynchronous file I/O
• Use I/O port completion
• Pass control to the kernel yourself, google KiFastSystemCall

Once a file is marked for encryption—meaning, it did not match entries on the skip-list—a LockBit routine checks whether the file already has a .lockbit extension. If it does not, it encrypts the file and appends the .lockbit extension to the end of the filename.

Lockbit relies on LoadLibraryA and GetProcAddress to load bcrypt.dll and import the BCryptGenRandom function. If the malware successfully imports that DLL, it uses BCRYPT_USE_SYSTEM_PREFERRED_RNG which means use the system-preferred random number generator algorithm. If the malware was unsuccessful calling bcrypt.dll, it invokes CryptAcquireContextW and CryptGenRandom to invoke the Microsoft Base Cryptographic Provider v1.0 and generates 32 bytes of random data to use as a seed.

Also, at this stage, the hardcoded ransom note, Restore-My-Files.txt, gets de-obfuscated and the ransomware drops the .txt file in every directory that contains at least one encrypted file.

Victim ID

LockBit creates 2 registry keys with key blobs as values under the following registry hive: HKEY_CURRENT_USERSoftwareLockBit

The two registry keys are:

LockBitfull
LockBitPublic

These registry keys correlate with the Victim ID, file markers, and the unique TOR URL ID that LockBit builds for each system it takes down.

Let’s take the unique TOR URL from the ransom note:

In this example, the 16 byte long unique ID is at the end of the URL, http://lockbitks2tvnmwk[.]onion/?A0C155001DD0CB01AE0692717A2DB14A :

The file marker (0x10 long) is divided into 2 sections:

A0C155001DD0CB01

The first 8 bytes of the file marker and the first 8 bytes of the TOR unique URL ID.

D4EA7A79A0835006

The second 8 bytes are same for all encrypted files in a given run

Also, the value of the full registry key (0x500 long, starting as 1A443C7179498278B40DC082FCF8DE26… in this example) is also present in every encrypted file, just before the file marker.

Share enumeration

For a successful ransomware hit and run, the goal is to encrypt as many files as possible. So naturally, LockBit scans for network shares and other attached drives with the help of the following API calls.

First, the malware enumerates the available drive letters with a call to GetLogicalDrives, then it cycles through the found drives and uses a call to GetDriveTypeW to determine whether the drive letters it finds are network shares by comparing the result with 0x4 (DRIVE_REMOTE).

Once it finds a networked drive, it calls WNetGetConnectionW to get the name of the share, then recursively enumerates all the folders and files on the share using the WNetOpenEnumW, WNetEnumResourceW API calls.

The ransomware can also enter network shares that might require user credentials. LockBit uses the WNetAddConnection2W API call with parameters lpUserName = 0 and lpPassword = 0, which (counterintuitively) transmits the username and password of the current, logged in user to connect to the given share. Then it can enumerate the share using the NetShareEnum API call.

Don’t quit just yet

I an attempt to ensure that LockBit would not be kept from finishing its job by a system shutdown, the developers of this ransomware implemented a small routine that uses a call to ShutdownBlockReasonCreate.

The developers didn’t try to conceal the ransomware as the cause of the shutdown block: the ransomware sets the message for blocking shutdown as LockBit Ransom. Computer users would also see the message LockBit Ransom under the process’ name.

SetProcessShutdownParameters is also called to set the shutdown order level of the ransomware’s process to 0, the lowest level, so that the ransomware’s parent process will be active as long as it can, before a shutdown terminates the process.

If the system is shut down, the malware also has capability to persist after a reboot. LockBit creates a registry key to restart itself under HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun, called XO1XADpO01.

Stop me if you’ve heard this before

LockBit prevents multiple ransomware instances on a single system by way of a hardcoded mutex: Global{BEF590BE-11A6-442A-A85B-656C1081E04C}. Before LockBit starts encrypting, the ransomware checks that the mutex does not already exist by calling OpenMutexA, and calls ExitProcess if it does.

As soon as the ransomware is mapped into memory and the encryption process finishes, the sample will execute the following command to maintain a stealthy operation:

• exe /C ping 1.1.1.1 -n 22 > Nul & ”%s” (earlier version of LockBit)
• exe /C ping 127.0.0.7 -n 3 > Nul & fsutil file setZeroData offset=0 length=524288 “%s” & Del /f /q “%s” (recent version of LockBit)

The ping command at the front is used because the sample can’t delete itself, due to the fact that it is locked. Once ping terminates, the command can delete the executable.

We clearly see an evolution to the applied technique here: in the earlier versions, the sample was missing a Del procedure at the end, so the ransomware would not delete itself.

In the recent version, the crooks had decided to use fsutil to basically zero out the initial binary to perhaps throw off forensic analysis efforts. After the file is zeroed out, the now null-file is deleted also, making double-sure the malware is not forensically recoverable.

Language matters

As we noted earlier, LockBit’s developers wanted to avoid having their ransomware hit victims in Commonwealth of Independent States (CIS) countries. The mechanism used by the ransomware to achieve this calls GetUserDefaultLangID and looks for specific language identifier constants in the region format setting for the current user. If the current user’s language setting matches any of the values below, the ransomware exits and does not start the encryption routine.

Changing the wallpaper

To get the affected user’s attention, the malware (as is typical) creates and displays a ransom note wallpaper. A set of API calls are involved in this process, listed below.

The created wallpaper gets stored under %APPDATA%LocalTempA7D8.tmp.bmp.

In the meantime, the malware also sets a few registry keys so that the wallpaper is not tiled, and the image is stretched out to fill the screen:

HKEY_CURRENT_USERControl PanelDesktop

• TileWallpaper=0 – (No tile)
• WallpaperStyle=2 – (Stretch and fill)

Stack Exchange for crooks

LockBit leverages a very similar service-list to MedusaLocker ransomware. It comes as no surprise that crooks copy these lists, so they don’t have to reinvent the wheel.

The unique Registry run key and ransom note filename that was written by LockBit—XO1XADpO01 and Restore-My-Files.txt — were also seen being used by Phobos, and by a Phobos imposter ransomware. This would suggest that there is a connection between these families, but without further evidence that is hard to justify.

The future for LockBit

A recent Twitter post demonstrates what the future looks like for LockBit. In a recent LockBit attack, the MBR was overwritten with roughly 2000 bytes; The infected machine would not boot up unless a password is supplied. The hash of this sample is currently not known.

The e-mail used for extortion [email protected] was also seen with STOP ransomware—an uncanny connection. The group behind might be related.

There is also speculation that application Diskcryptor was combined with the ransomware to add this extra lockdown layer. The MAMBA ransomware was also using this technique, leveraging Diskcryptor to lock the victim machine. DiskCryptor is currently being detected as AppC/DCrpt-Gen by Sophos Anti-Virus.

A list of the indicators of compromise (IoCs) for this post have been published to the SophosLabs Github.

Acknowledgments

The author would like to acknowledge the public contributions of @demonslay335 and @hfiref0x.

Did you know that the Yubico Authenticator app is available for desktops as well as mobile devices? Today, we are excited to announce the support of the Yubico Authenticator desktop versions on their respective platform stores (Mac App Store, Microsoft and Snapcraft). 

Achieving strong protection with authenticator apps  

Authentication mechanisms today need to be highly secure, usable and portable, and these are the exact same principles we used to build Yubico Authenticator. Similar to other authenticator apps, Yubico Authenticator generates a one-time code used to verify your identity as you’re logging into various services. However, unlike other authenticator apps, the secrets are stored in the YubiKey rather than in the app itself, making it necessary for a user’s YubiKey to be physically present to receive the time-based codes. 

Because secrets are stored on your YubiKey, if you change phones or laptops, there is no porting or re-registering of accounts required, regardless of operating system. Furthermore, the secrets cannot be stolen from the hardware key. 

Yubico Authenticator advantages for desktop users

With recent availability of Yubico Authenticator on the Mac, Windows, and Linux app stores, we are able to seamlessly deliver the same security, portability and usability benefits of the product to desktop users. Besides simplifying and accelerating the authentication experience across many services and platforms, Yubico Authenticator for desktop carries specific advantages. It enables two-factor authentication (2FA) across unique environments including: 

Desktop VPN authentication 

Yubico Authenticator for desktop enables seamless VPN integrations by generating one-time codes with desktop VPN clients such as Cisco Anyconnect, Pulse Secure, or AuthLite. With the recent influx of remote workers, this is particularly useful in helping to secure employees who are working from home. 

Mobile-restricted environments 

Not all corporate setups allow for the use of mobile devices, making it impossible to use mobile-based authentication methods such as SMS or authenticator apps. Since Yubico Authenticator stores secrets on the YubiKey, users are able to replicate the same time-based codes that would be on a mobile device, on the desktop. This is particularly advantageous for corporate setups where mobile devices are restricted, such as call centers or doctor’s shared devices. 

Multi-device sign in 

In a recent survey from Ponemon Institute, individuals use an average of 5 devices to access online accounts. With a YubiKey and Yubico Authenticator, the same secrets are accessible on desktop computers as well as mobile devices. This makes it easy to authenticate without needing to re-register every service with the authenticator app on different platforms. 

Setting up Yubico Authenticator for desktop 

Simply download the app for Windows, macOS, or Linux depending on the machine you’re using. Open the app, insert your YubiKey, and begin adding the accounts you wish to protect by scanning the QR code provided by each service. Yubico Authenticator is also available for download on iOS (iPhones and iPads) and Android operating systems. 

Now you’re all set! Start using the Yubico Authenticator app and your YubiKey to securely login as a second factor to your services. 

For added convenience, head over to the Yubico store to pick up a YubiKey 5Ci for seamless authentication across desktop and mobile devices!  

Millions of “sextortion” spam messages sent between September 1, 2019 and January 31, 2020 generated nearly a half-million US dollars in profits for Internet criminals. The messages told recipients that their computers had been hacked, that the sender had captured video of them visiting pornographic websites, and threatened to share the video with the targets’ “friends” if they didn’t pay—asking for as much as $800 USD worth of Bitcoin (BTC) to be transferred to a wallet address.

The flow of that digital currency reveals that many of the operators behind these sextortion scams are connected to a much larger criminal digital economy. Though there were some smaller players involved in these spam campaigns, the movement of the BTC deposited in many of those wallets shows the campaigns were linked to other criminal enterprises—either funding other illicit activity or providing a way to convert the BTC to hard cash.

We shared wallet data extracted from these spam campaigns with CipherTrace, Inc., to get more insight into the flow of digital currency connected to them. The wallet addresses used by the scammers to extract payments from victims were found to have made transactions with dark web marketplaces, stolen credit card data hawkers, and other elements of the cybercriminal economy. Other funds were quickly moved through a series of wallet addresses to be consolidated, put through “mixers” in an attempt to launder the transactions, and converted to cash, goods and services through other channels.

While the sextortion scams themselves were hardly innovative, the cryptocurrency flow wasn’t the only thing that suggested a certain sophistication behind some of the attackers. Many of the messages relied on a number of technically interesting obfuscation methods to try to slip by spam filters. And while the vast majority of recipients either never saw the messages or didn’t pay, enough saw and fell for the ploy that wallets associated with the messages pulled in 50.98 BTC during the five month period. That amounts to roughly $473,000, based on the average daily price at the times the payments were made, and an average of $3,100 a day.

It’s raining spam

Sextortion messages are a staple of low-level Internet scammers. They require relatively little technical skill to send, and do not require the actual compromise of the target’s computer. That is because the email addresses targeted by the scam and the passwords sent as proof to the victims are collected from published usernames and  passwords from old website breaches, widely published on the Internet. (Using password managers, not re-using passwords across accounts, and using services such as HaveIBeenPwned.com or Google’s Password Checkup can protect people from the use of old passwords by attackers.)

Compared to sophisticated ransomware campaigns (which can bring in millions of US dollars worth of cryptocurrency from a single victim), the return from sextortion scams is relatively small. But they are still a significant source of income for the spammers behind them, and cost relatively little to run. They also provide a steady stream of income for the botnet operators whose networks of compromised computers act as the launchpad for these campaigns.

During the period between September 1, 2019 and January 31, 2020, we witnessed a series of unusual spikes in sextortion spam message traffic. As with many other types of spam campaigns, the sextortion messages came in relative short bursts instead of a continuous stream of messages. But these particular bursts made up a outsized proportion of the spam traffic we observed during the period observed. While sextortion made up an average of 4.23% of all our observed spam traffic over the period, there were five days when it made up over a fifth of all spam we observed. And the sextortion emails on just three days in October accounted for over 15 percent of all spam between September and January.

We observed around a dozen “spikes,” most of them during the autumn. These spikes usually lasted 1-3 days, and more than half of them happened on weekends (Friday, Saturday and Sunday). Another sign that the scammers behind these messages prefer to send their messages when their targets might not be at work: while the campaigns were largely low-volume during December, they picked up between the 24th and 26th. There were some outliers, however, including a spike on January 8 that consisted largely of a campaign with extortion messages written in German.

As with many spam campaigns, the sextortion messages were launched from botnets using compromised personal computers all around the world, with PCs in Vietnam providing the greatest single share (7%).  Some of the messages demonstrated some new methods being used by sophisticated spammers to evade filtering software.

While we had seen previous campaigns use images to display the extortion demand in order to evade text detection, we found few examples of image-based obfuscation in September to January waves. Instead, the spammers used a variety of other techniques to hide the text of their messages from simple parsers:

• Breaking up the words with invisible, random strings

  

• Using encoded non-ASCII characters (such as Cyrillic letters) that look similar to “regular” characters to humans, completely different when read by a machine:

  

• Using invisible white garbage text to break up the message text.

  

• In one message (the example shown earlier in this report) the message text  was “concealed” in HTML style tags outside of the body of the message.

  

Cashing in on fear

In addition to the often-obfuscated threat, each of these emails carried a Bitcoin wallet address for victims to use in directing payments. Clearly, the majority of these individual efforts to scare targets into paying was in vain—while we found nearly 50,000 unique Bitcoin wallet addresses in the sextortion messages we intercepted, only 328 received payments at any point in time until early February—meaning only a half a percent of each message volley convinced recipients to pay.

While a relatively tiny fraction of the total, these wallet addresses received more than 96 BTC, which is (or was) worth a few hundred thousand US dollars, depending on when we check the price of BTC/USD. Some of this activity predates the spam campaigns, however.

Looking at the payments made during the sextortion campaigns may give a more accurate picture of what they yielded. During the five month period, 261 of the wallet addresses received 50.98 BTC . Multiplied by the average of the daily price on the day the payments were made, that comes to $472,740.99, which is as close to the actual amount of victims paid as we can get. On average, the active wallets received 0.19534962 Bitcoin per address, or $1,811.27.

The operators regularly cycled through new wallet addresses with each new campaign.The average “lifespan” of all the addresses found within sextortion messages was 2.6 days before they disappeared from observed spam. The 328 “successful” wallets—those that received payments— had more extended lives, lasting 15 days on average.

Through our collaboration with CipherTrace, we were able to determine that the 328 Bitcoin addresses with a history of payments were connected to 162 clusters of addresses tied to individual Bitcoin wallets. While a majority of these wallets only had one address, there were 4 wallets that had more than 10 addresses from our list associated with them.

Let the BTC flow

Of the 328 “active” addresses we identified, CipherTrace connected 12 to online cryptocurrency exchanges or other wallet services. Some of the exchanges had been previously identified by CipherTrace as “high risk” exchange services with little in the way of the “know your customer” requirements, making them well-suited as cryptocurrency laundering points for criminals. These previously attributed addresses were not used in further tracing the flow of funds from the campaigns, because exchanges often combine customer funds together in their deposit pool—making it untenable to track specific blockchain transactions further.

The CipherTrace Inspector product identified 476 output transactions from the 316 addresses. The most frequent destinations for transactions were:

• Binance, a global BTC exchange  (70 transactions).
• LocalBitcoins, another BTC exchange (48 transactions).
• Coinpayments, a BTC payment gateway (30 transactions).
• Other wallets within the sextortion scheme, consolidating funds (45 transactions).
• There were 54 transactions to addresses that could not be attributed—likely private non-hosted wallets.

It’s important to point out that the exchanges mentioned above (as well as other exchanges) are unknowing participants in these deposits of funds. Because of the way blockchains are designed, there is no way for exchanges to block deposits to their addresses.

Overall, the payments from sextortion wallets were distributed as shown below:

CipherTrace performed further analysis on the 316 addresses by tracing the other addresses connected to them by transactions, going out a maximum of 3 transaction “hops” from the original address. Of those addresses, 305 had at least one outbound transaction. The trace of those transactions revealed 7 distinct groups of address clusters within the group, tied together by transactions. In some cases, those clusters were connected to other criminal transactions:

There were 13 addresses among the 328 passed to CipherTrace that did not have traceable outbound transactions. But for the remainder, whoever was behind the wallets did not let their cryptocurrency spoils sit for long. Based on the date of the first input (when the first extortion payment transaction occurred) and of the last output (when the last of the value of the wallet’s Bitcoin was drained) from each of the remaining 305 wallets, CipherTrace calculated an average “lifespan” of approximately 32.28 days.

Removing the most long-lived outlier wallets from the group—9 addresses that persisted for more than 200 days—the majority of the addresses had an average lifespan of 19.93 days. For 143 of the addresses, where there was only one input and one output transaction, the wallets were cashed out on average within 8 days—with the exception of two that were left untouched for over 100 days.

Where’s the money now?

Tracking where physically in the world the money went from these sextortion scams is a difficult endeavor. Out of the 328 addresses provided, CipherTrace determined that 20 of the addresses had IP data associated with them, but those addresses were connected to VPNs or Tor exit nodes—so they were not useful in geo-locating their owners.

Where wallet-emptying deposits occur can sometimes offer a hint to the location of scammers, because some exchanges restrict what Internet address blocks they can be accessed from. But even geographic restrictions on some of the exchanges used are ineffective for locating the people behind the wallets, much for the same reason—VPNs or Tor could be used to bypass IP-based restrictions to those exchanges. Most of the deposits went into global exchanges.

Given that some of the transfers were used to obtain stolen credit card data or other criminal services—probably including more botnet services for sending spam—the payouts from the sextortion campaigns are funding yet another round of scams and fraud. After all, even in the criminal world, you have to spend money to make money.

Sophos would like to acknowledge the contributions of analysts at CipherTrace, Inc. , to this report.

The workplace is evolving and expanding well beyond the four walls of a corporate office, and with this expansion comes new questions about how to secure employee login. In 2019, fifty-one percent (51%) of IT professionals said their organization experienced a phishing attack, making it dire for organizations to identify solutions that employees can use to access critical workplace systems and data while staying safe from rising attacks.

As your organization is on the path to modernizing workplace login, security at the individual user level is more critical than ever. Secure login is fundamental to preventing unauthorized access, and when done really well, results in: 

Through our extensive partner network, Yubico offers organizations a broad range of choices in the way users can securely log into their workstations and computers. Whether aiming for a cloud-first or hybrid environment, strong authentication can be implemented to protect access everywhere, all based on the systems users need to access.

Last month, we shared 5 ways the YubiKey can protect your remote workforce from phishing and other attacks. This month, we are featuring five of our partners to share tips on how our joint technologies can enable your organization to modernize the login experience to desktops and laptops as well as cloud-based apps and services. 

Intercede

“Strong authentication is fundamental to modernizing the workplace. YubiKeys provide seamless multi-factor authentication (MFA), while systems like MyID give IT teams the control they need to issue and manage YubiKeys simply and at scale.” – Allen Storey, Chief Product Officer, Intercede

Microsoft

“The best experience you can give your users is one that doesn’t require them to learn new ways or new habits. Rather than distributing new usernames and passwords, you can leverage the credentials they already use to sign in to their devices.”- Sue Bohn, Director of Program Management, Microsoft 

OneLogin

“MFA doesn’t have to be difficult. OneLogin’s Trusted Experience Platform enables users to leverage WebAuthn with hardware-backed YubiKey MFA for access to enterprise apps and services. With our integration, companies can reduce MFA friction with OneLogin SmartFactor, and increase their overall security posture.” – Brandon Simons, Director of Product Management, OneLogin

SecureW2

“By partnering with Yubico, we’re making it easy to deploy the YubiKey as a smart card using our onboarding software plus PKI Services to secure app authentication, VPN, desktop logon, and more.” – Tom Rixom, CTO,  SecureW2

Bottom line: Organizations undergoing digital transformation require modern, secure, and flexible authentication approaches to protect critical data. Whether you’re considering MFA by adding another layer of protection on top of a username and password, or potentially replacing passwords altogether, the multi-protocol YubiKey is equipped to handle it all. 

Join our upcoming partner roundtable discussions to hear expert insights and best practices on modernizing workplace login. Use the links below to sign up now! 

There’s a lot of uncertainty in the world, but the one thing you can be sure of is that COVID-19 has and will continue to create a situation that hasn’t been seen in three generations, certainly not in living memory.

In a matter of weeks, response to the pandemic has reshaped our global economy and societies in ways that will touch everyone. How we work, shop, get educated, travel, exercise, care for each other, and socialize has changed radically, and with ferocious speed. And the pandemic has created new classes of both villains and heroes.

While many of the changes to interpersonal interactions have been rough, there are some silver linings to these difficult circumstances. One of the brightest spots is how the coronavirus has roused many in the security industry to action, for many of the same reasons why some people enlist in the military during wartime: out of a sense of duty and a desire to protect others. Only this time, the enemy is cybercrime itself.

The collective sense of duty, coupled with a visceral reaction to criminals exploiting the world’s fears of an invisible killer, led to the spontaneous formation of several working groups to combat these threats.

There is much that is remarkable about these initiatives, but one characteristic that stands out is how militia-like these groups are, from the way that they have self-organized in a matter of days, with distributed (decentralized) structures, to how they are positioning themselves to aid our “conventional” forces, including individual cybersecurity companies.

Among these new working groups, which include the CTI League and Cyber Volunteers 19, is an initiative called the COVID-19 Cyber Threat Coalition (or CCTC).

What began with a simple call by Sophos Chief Scientist Joshua Saxe for analysts to join forces has turned, in a matter of just a few weeks, into an operation numbering more than 3,000 volunteers, comprising people from a broad range of industries and organizations around the world, working with a single purpose and goal.

The all-volunteer effort of the CCTC has self-organized around the goal of creating a shared pool of real-time data and threat intelligence about attacks in which the attackers have in some way exploited the COVID-19 pandemic, and making that output freely available to anyone who has a use for it.

The outpouring of data from volunteers was matched with generous offers from tech firms to provide the organization with the tools and technology they need to accomplish the mission, at no cost. The charitableness of the volunteers with their time, and of businesses with their products and infrastructure has been heartening in these trying times.

The collaboration, spirit of teamwork, and feedback among CCTC volunteers has been impressive, as well. Participants organized into teams that rapidly devised systems to collect volumes of threat intelligence along with automation to vet the data, reducing the likelihood of spreading inaccuracies. Others are consumers of this data, using it to strengthen our collective infosec immune system and suggesting different ways to produce output they can use with less effort.

The spontaneous genesis of these groups represents a statement that, collectively, information security specialists will no longer tolerate business as usual from criminal groups that, even in the best of times, can ruin lives and harm or destroy businesses or organizations.

At a time when the fabric of our very society seems strained almost to the breaking point, a ransomware attack against a medical facility or other critical infrastructure could cost actual lives.

The tragedies and trauma of a global pandemic will shape a post-COVID world that may not look very different to what came before but will be very different under the hood. Those who protect us have a renewed sense of purpose and collective mission, unencumbered by pre-existing affiliations. We should embrace that.

There are some things that shouldn’t fully snap back to the way they were, and a group of cyber-minutemen who rise up to defend us all against enemies who act with depraved indifference to the needs of civilization might just be what the doctor ordered.

For the April edition of Patch Tuesday, Microsoft repaired a total of 110 security vulnerabilities across their product line. Included in this count are 37 remote code execution bugs, and 33 elevation of privilege bugs. The company rated eighteen of the vulnerabilities “Critical.”

This release’s most notable item is the follow-up to last month’s announcement, “Cybercriminals are exploiting two unpatched zero-day flaws affecting all supported versions of Windows“. At the time, the company advised a workaround for mitigating the risk. Today, the fix for the two vulnerabilities went live.

Here are the patch highlights:

Adobe Font Manager Library Remote Code Execution

CVE-2020-0938, CVE-2020-1020

Two font vulnerabilities are present in the handling of the old and obsolete Type 1 (PostScript) font standard that makes use of file extensions .PFB and .PFM.

If an attacker is able to manipulate an unpatched Windows system into handling and displaying a malicious Type 1 font file (crafted by the attacker), the bugs could be exploited to compromise the system.

On Windows versions prior to Windows 10, the code responsible for handling fonts is running in high-privileged kernel mode. This makes the impact much more severe on older editions, such as (the now unsupported) Windows 7, or Windows 8.1 – the bugs can be used to perform an elevation of privilege attack, in addition to remote code execution.

Thankfully, on Windows 10 systems the same code has been moved to be running in a low-privileged, sandboxed user mode process. This hardening measure limits the bugs’ usefulness for elevation of privilege attacks. However, they still expose the system to a remote code execution scenario.

Normally, an attacker can take advantage of a font vulnerability to achieve remote code execution by enticing a victim to open a web page or document that has the malicious font embedded in them.

In the case of web pages, the “CSS Web fonts” feature can be used for embedding. Office documents and PDF documents also have support for embedding fonts in them.

Fortunately, due to the Type 1 font standard falling from favor, and being replaced by the newer TrueType and OpenType standards, many software do not support the embedding of Type 1 fonts. This is true for example in web browsers and Office software, so it can be said that the remote code execution attack scope for Type 1 bugs is somewhat limited in comparison to bugs affecting TrueType fonts.

Windows Elevation of Privilege Vulnerabilities

Elevation of Privilege (EoP) vulnerabilities could permit an attacker with limited access to a Windows system to gain more control over it, typically allowing for “escaping” a low integrity or sandboxed process by exploiting such a vulnerability, and subsequently gaining unlimited permissions to the system.

This month’s EoP bugs affect an assortment of Windows components, among them: Win32k (Graphics), Push Notification Service, DirectX, and amusingly enough, two of the bugs were discovered in Windows Defender – the built-in anti-malware component of Windows.

SharePoint Remote Code Execution Vulnerability

CVE-2020-0920, CVE-2020-0929, CVE-2020-0931, CVE-2020-0932, CVE-2020-0971, CVE-2020-0974

Out of a total of 20(!) different bugs affecting SharePoint, 6 are classified Remote Code Execution.

SharePoint is a web-based collaborative platform. It is almost always used by organizations, not individuals. There wasn’t any detailed technical information about any of the bugs that were found, so it’s unclear whether these bugs affect users of SharePoint Server or SharePoint Online (or both).

However from the sheer amount of fixes being deployed for this product, it’s safe to assume the bugs as a whole constitute a high risk of compromise, and therefore this month’s patch is definitely not something to disregard if you use SharePoint.

Sophos detection guidance

Sophos has released following detection to address the following vulnerabilities. Please note that this is not an exhaustive list of protection measures Sophos has implemented, and that additional vulnerabilities and corresponding detection may be released in the future.

Unscrupulous marketers and cyber-criminals have seized upon concerns over the emergence of the COVID-19 global pandemic as bait for spam, phishing attacks and malware. In recent weeks, the use of “coronavirus” and “COVID-19” in domain names, potentially unwanted email messages, and phishing and malware delivery schemes has skyrocketed. As of April 14, Sophos has identified over 1,700 malicious domains using “corona” or “covid” in their names, of which 1,200 are currently active.

We’re continuing to work to identify, detect and block these threats. We’re also engaging with the security community to help defend more broadly against the surge in COVID-19 related threats. Joshua Saxe, Sophos’ chief scientist, has launched a Slack channel for open collaboration on taking on pandemic-themed threats. [Update, April 20: The Slack channel now has over 3,400 members from security firms, as well as private and government organizations.]

We’re also publishing indicators of compromise we discover for related threats in a public GitHub. In this report, we’ll examine some of the trends we’re seeing in pandemic-themed spam and scams. The data we present here is just a portion of what we’ve seen so far, and we continue to assess intelligence data as it becomes available.

The surge of spam

The spam we found to be carrying an installer for Trickbot malware earlier this month was just one example of how spammers and criminals are using hunger for information about the pandemic to lure in their targets.

While COVID-19 emerged as a crisis in China in December, references to the virus in spam and phishing emails only really began to emerge in January—and like the virus itself, they grew exponentially. By early March, COVID-19 and Coronavirus already represented a significant percentage of the spam traffic we measured.

Spam campaigns detected by Sophos included:

• A sextortion scheme threatening to infect the target’s family with COVID-19 if they didn’t pay.
• A scam purporting to be a fundraising plea from the World Health Organization, asking for donations in Bitcoin to fund COVID-19 research.
• Messages purportedly from WHO, but carrying documents with dropper malware.
• Marketing for “emergency supplies,” including filter masks.
• A sales pitch for a $37 video download, purporting to offer insider information from a “military source” on how to survive Coronavirus
• [Update, March 27) We’re continuing to see new COVID-19 related extortion scams. Here’s another we’ve detected and blocked:

Building spamming and phishing infrastructure

COVID-19 has left a huge mark on the Internet’s namespace over the past two months. Certificate transparency log data from the major certificate authorities has shown a significant rise in the number of SSL certificates registered for sites using “corona” or “covid” in their names.

To get a sense of how big that change has been, we looked at  log data over the past six months for new certificates issued for hostnames with “corona” or “covid-19” in them. To establish a baseline from before the outbreak became global news, we looked at the same period a year ago (September 2018 to March 2019) for comparison.

Before January, most certificates that contained “corona” referred to a locality, service or legitimate brand name. These accounted for an average of 288 certificates activated per month.  References to “covid” did not exist in any certificate registrations we could find record of prior to 2020, and the only domain that really stands out belongs to Arizona-based A/V accessory manufacturer COVID, which owns the .com domain.

The pandemic changed the equation. Starting in January of 2020, there was an exponential rise in new certificates carrying these terms, nearly doubling from the norm to 558 for that month, and then nearly doubling again in February to 868. In the first two-thirds of March, over  6,086 new  certificates bearing host names with “covid” and “corona” were issued—nearly a 20-time increase over the year before.

Over 65% of these new domains were programmatically registered for free through Let’s Encrypt, and another 5% used Cloudflare as a Certificate Authority (Cloudflare provides free SSL for sites that use its content delivery network).

By no means are all of these malicious, but many are suspicious—particularly since they include an abundance of sites that were bulk-configured using site templates, domains configured through low-cost registrars or subdomains configured on potentially compromised domains.

One host serving as home for a number of “covid-19” related web addresses—associated with a service that offers free websites and low cost domain name registration—had 11,322 domain names associated with it. Those domains appear to have been programmatically created and registered for certificates, as they follow the same naming pattern {covid-19[additional search keyword].com).

The raw number of domain names we’ve observed being registered that are related to the COVID-19 pandemic is even larger. On March 20, the peak day (so far), people registered 3011 new domains that contained the text “covid” or “corona,” in the four largest top-level domains (TLDs) we monitor (.com, .us. .org, and .info). Since February 8, we’ve observed 42,578 (as of midnight, March 24) newly-registered covid or corona domain names.

While some of these domains may have been registered for benign or even beneficial purposes, many are simply parked, while others are displaying basic, mostly empty website content as placeholders for some promised future content. Part of the collaboration on the Slack channels and with our partners at the Cyber Threat Alliance involves sorting out the useful and legitimate sites that may have been registered by legitimate health authorities from the dark humor, spammy, or actively malicious ones. It’s hard to know the intent of a domain registrant when there’s no content in—just for one weird example, there’s coronavirusshaquilleoneal[.]com.

Sophos has identified over 60 domains as actively malicious, though some of those domains have gone dark since we first detected them. The following specific sites have been linked to malware downloads, and are potential network indicators of compromise, but they are likely just the tip of the iceberg as far as malicious domains go:

corona-masr21.com
netflixcovid19s.com
chasecovid19v.com
chasecovid19t.com
chasecovid19s.com
corona-masr2.com
chase7-covid.com
masry-corona51.com
corona-virusapps.com
coronavirus-realtime.com
covid-19-gov.claims
corona-virus-map.net
corona-map-data.com
coronavirus-apps.com
childcarecorona.com
impots-covid19.com
corona-apps.com
coronaviruscovid19-information.com
coronations.usa.cc

[Update, March 27] One domain we’ve investigated, covid19hacks[.]com, is acting as a redirector gateway to a series of deceptive and potentially malicious download sites, including fake software update pages:

These pages are the end of a trail of forwarding HTTPS pages, on domains including:

covid19hacks.com
yourbig-prizenow2.life
mobile-app-market-here1.life
best.prizedea2040.info

[Update, 4/08]

One of the most prevalent scams related to COVID-19 are sites offering supplies or medicine to prevent or fight infections.  Several are picking up on the promotion by some of Hydroxycloroquine and Azithromycin as drugs to help fight COVID-19 infections.

.Some of these sites forward to overseas pharmaceutical sites or to web stores offering filter masks; others have skeletal WordPress installations that appear to be placeholders for future phishing or spam sites. One offers a $9 book on how to create a “do-it-yourself vaccine” for coronavirus.

curecorona.co
zithromaxcovid19.com
jesse.hydroxychloroquinecovid-19cure.com
www.hydroxychloroquine-coronavirus.com
coronacurethon.org 
diyvaccinecurecoronavirus.com
covidrx.ca
covidizerx.pl
corona-vaccine-info.com
corona-virus-vaccine.com

Others we’ve found are simply registered and parked, in the hope of selling them as part of the coronavirus “gold rush.”

The following sites were registered and park through reg.ru, a Russian domain registry, and may be potential pharmacy scam sites in the future:

covid-pharma.net
covid-pharma.net 
covid-pharma.net 
covid-pharma.org
covid-pharma.ru

Malware abusing anxiety over COVID

We’ve identified multiple malware families and potentially unwanted applications thus far communicating with COVID-19 related domains in some way. There are also ransomware that reference coronavirus in the ransom notes.

For example, three different versions of the DownloadGuide adware PUA  were detected connecting to domains containing “COVID” or “Corona”. These may have been advertisements pushed to the adware randomly.

Additionally, a group of malicious files used the web host coronavirusstatus[.]space to host payloads or as a C2 server. They include:

• An AutoIT dropper script, which we identify as Troj/AutoIt-CYW.
• Corona.exe  and isoburn.exe, both of which which we identify as Troj/PWS-CJJ and Troj/Steal-JZ.
• Corona-virus-Map.com.exe (which we identify as Troj/MSIL-NZP).
• The file aut6C13.tmp (which we identify as Troj/PWS-CJJ malware).

In addition to communicating with the host, this malware group also connects to the Telegram encrypted communications API server.

These and additional IOCs will be added to our GitHub repository.

And it was inevitable that someone would eventually create a ransomware and call it Coronavirus.

Acknowledgments

SophosLabs wishes to acknowledge the efforts of Richard Cohen, Brett Cove, Krisztián Diriczi, Fraser Howard, Tamás Kocsír, and Chet Wisniewski to track down various threats, and the efforts of the Cyber Threat Alliance and the community of threat researchers on the COVID-19 Cyber Threat Coalition Slack channel for sharing a wide range of attack data with the wider community of security researchers and SOC analysts.

We’ve released XG Firewall v18 MR1.

Enhancements

• Supports new SD-RED 20 and SD-RED 60 devices.
• XG Firewall web console now shows granular reasons for firmware upload failure
• Plus, more than 45 issues resolved in this release (refer Issues Resolved section below)
• With the tremendous need for VPN connectivity in this challenging time, we have put together some important information here for you to achieve your networking needs:
  1. To configure VPN Remote Access on your Sophos XG Firewall. Check out this useful Community post!
  2. To substitute XG for RED devices via Light-Touch deployment from Sophos Central. Check out this useful Community post!

Note: Upgrade from SF 17.5 MR11 to v18.0 MR1 is now supported.

More on XG Firewall v18

Please refer XG Firewall v18 highlights for more details on all-new Xstream Architecture delivering extreme new levels of visibility, protection and performance. Also, check out our XG Firewall v18 playlist on YouTube to find out what’s new in XG Firewall v18!

Get it now!

As usual, this firmware update is no charge for all licensed XG Firewall customers. The firmware will be rolled-out automatically to all systems over the coming weeks but you can access the firmware anytime to do a manual update through Licensing Portal. You can refer this article for more information on How to upgrade the firmware.

For fresh installations, we will update this post with installer download links soon.

Things to know before upgrading

Issues Resolved

• NC-30903 [Authentication] STAS configuration is editable via GUI on AUX machine
• NC-50703 [Authentication] Access server restarted with coredump using STAS and Chrome SSO
• NC-50716 [Authentication] Cannot import LDAP server via XMLAPI if client cert is “None”
• NC-54689 [Authentication] Support download certificate for iOS 13 and above
• NC-55277 [Authentication] Service “Chromebook SSO” is missing on Zone page
• NC-51660 [Backup-Restore] Restore failed using a backup of XG135 on SG230 appliance
• NC-55015 [Bridge] Wifi zone is not displayed while creating bridge
• NC-55356 [Bridge] TCP connection fails for VLAN on bridge with HA Active-Active when source_client IP address is odd
• NC-52616 [Certificates] Add support for uploading of CRLs in DER format
• NC-55739 [Certificates] EC certificate shows up as “RSA” in SSLx CA cert dropdowns
• NC-55305 [CM (Zero Touch)] System don’t restart on changing time zone while configured through ZeroTouch
• NC-55617 [CM (Zero Touch)] Getting wrong error message in log viewer after ZeroTouch process
• NC-55909 [Core Utils] Unable to see application object page on SFM
• NC-30452 [CSC] Dynamic interface addresses not showing on Aux after failover
• NC-54233 [CSC] EpollWorker coredump
• NC-55386 [Dynamic Routing (PIM)] PIM-SM import fails with LAG as dependent entity
• NC-55625 [Dynamic Routing (PIM)] In HA with multicast interface, routes are not getting updated in the Aux routing table
• NC-55461 [Email] After adding/edit FQDN host with smarthost, it is not displayed on the list until refresh the page
• NC-58898 [Email] Potential RCE through heap overflow in awarrensmtp (CVE-2020-11503)
• NC-55635 [Firewall] Display filter for forwarded is not working properly on packet capture page
• NC-55657 [Firewall] HA backup restore fails when port name is different in backup and appliance
• NC-55884 [Firewall] IPS policy id and appfilter id not displaying in firewall allow log in logviewer
• NC-55943 [Firewall] Failed to resume existing connection after removal of heartbeat from firewall configuration
• NC-57084 [Firewall] Custom DMZ not listed in dedicated link HA configuration
• NC-44938 [Firmware Management, UX] Web UI does not surface reasons for firmware upload failure
• NC-55756 [Gateway Management] Gateway isn’t deleted from SFM UI after deleting it from SFM
• NC-55552 [HA] WWAN interface showing in HA monitoring ports
• NC-55281 [Import-Export Framework] Full configuration import fails when using third party certificate for webadmin setting
• NC-55171 [Interface Management] VLAN Interface IP is not assigned via DHCP when gateway name uses some special characters
• NC-55442 [Interface Management] DNS name lookup showing incorrect message
• NC-55462 [Interface Management] Import fails on configuring Alias over VLAN
• NC-55659 [Interface Management] Invalid gateway IP and network IP configured using API for IPv6
• NC-56733 [Interface Management] Patch PPPd (CVE-2020-8597)
• NC-51776 [IPS Engine] Edit IPS custom rule protocol doesn’t work after creation
• NC-51558 [IPsec] Add warning message before deleting xfrm ipsec tunnel
• NC-55309 [Logging] Local acl rule not created through log viewer for IPv4 and IPv6
• NC-50413 [Logging Framework] Gateway up event log for PPPoE interface not always shown in logviewer
• NC-55346 [Logging Framework] Clear All for “Content filtering” does not clear SSL/TLS filter option
• NC-56831 [Policy Routing] SIP traffic sometimes not working with SDWAN policy route
• NC-46009 [SecurityHeartbeat] Spontaneous reconnects of many endpoints
• NC-51562 [SecurityHeartbeat] Heartbeat service not started after HA failover
• NC-52225 [Synchronized App Control] SAC page loading issues as the list of apps increases
• NC-54078 [UI Framework] Internet Explorer UI issue on certain rules and policies pages
• NC-56821 [Up2Date Client] SSL VPN downloading with the 0KB
• NC-54007 [Web] File type block messages sometimes contain mimetype rather than file type

Making the most of your new XG Firewall features

Free Online Training

• Available for free for all XG Firewall customers, our delta training program will help you make the most of the new features in XG Firewall v18.
• This online program walks you through the key enhancements since v17.5 and takes about 90 minutes to complete.

Customer Resources and How-To Videos

• Also be sure to visit the Customer Resource Center for the latest How-To Videos and links to documentation, the community forums, training and other resources.

Take advantage of Partner and Sophos Professional Services

• To augment your local Sophos partner’s services, we offer services to help you getting up and running and make the most of your XG Firewall, including the latest capabilities in v18.
• While Sophos Professional Services can help with any task, here are the most common services they provide:
  • XG Firewall deployment and setup
  • XG Firewall v18 DPI, FastPath and SSL Engine Optimization
  • XG Firewall Health Checks

Here are some direct links to helpful resources:

New to XG Firewall?

If you’re new to XG Firewall, see how it provides the world’s best network visibility, protection and response on the new XG Firewall website.