QR codes link the offline to the online. What started as a way to streamline manufacturing in the automotive industry is now a widespread technology helping connect the physical world to digital content. And as the world embraced remote, no-touch solutions during the Covid pandemic, QR codes became especially popular. QR codes offer convenience and immediacy for businesses and consumers, but cybercriminals also take advantage of them. Here’s what you need to know about QR codes and how to stay safe when using them.
Why QR codes?
Due to their size and structure, the two-dimensional black and white barcodes we call QR codes are very versatile. And since most people carry a smartphone everywhere, they can quickly scan QR codes with their phone’s camera. Moreover, since QR codes are relatively easy to program and accessible for most smartphone users, they can be an effective communication tool.
They also have many uses. For example, QR codes may link to a webpage, start an app or file download, share contact information, initiate a payment, and more. Covid forced businesses to be creative with touchless experiences, and QR codes provide a convenient way to transform a physical touchpoint into a digital interaction. During Covid, QR codes became a popular way to look at restaurant menus, communicate Covid policies, check in for an appointment, and view marketing promotions, among other scenarios.
As a communication tool, QR codes can transmit a lot of information from one person to another, making it easy for someone to take action online and interact further with digital content.
What hackers do with QR codes
QR codes are inherently secure, and no personally identifiable information (PII) is transmitted while you’re scanning them. However, the tricky part about QR codes is that you don’t know what information they contain until you scan them. So just looking at the QR code won’t tell you if it’s entirely trustworthy or not.
For example, cybercriminals may try to replace or sticker over a QR code in a high-traffic, public place. Doing so can trick people into scanning a malicious QR code. Or, hackers might send malicious QR codes digitally by email, text, or social media. The QR code scam might target a specific individual, or cybercriminals may design it to attract as many scans as possible from a large number of people.
Once scanned, a malicious QR code may take you to a phishing website, lead you to install malware on your device, redirect a payment to the wrong account, or otherwise compromise the security of your private information.
In the same way that cybercriminals try to get victims to click phishing links in email or social media, they lure people into scanning a QR code. These bad actors may be after account credentials, financial information, PII, or even company information. With that information, they can steal your identity or money or even break into your employer’s network for more valuable information (in other words, causing a data breach).
Pay attention to context. Where is the code available? What does the code claim to do (e.g., will it send you to a landing page)? Is there someone you can ask to confirm the purpose of the QR code? Did someone send it unprompted? Is it from a business or individual you’ve never heard of? Just like with phishing links, throw it out when in doubt.
Look closely at the code. Some codes may have specific colors or branding to indicate the code’s purpose and destination. Many codes are generic black and white designs, but sometimes there are clues about who made the code.
Check the link before you click. If you scan the QR code and a link appears, double-check it before clicking. Is it a website URL you were expecting? Is it a shortened link that masks the full URL? Is the webpage secure (HTTPS)? Do you see signs of a phishing attack (branding is slightly off, strange URL, misspelled words, etc.)? If it autogenerates an email or text message, who is the recipient and what information is it sending them? If it’s a payment form, who is receiving the payment? Read carefully before taking action.
Practice password security. Passwords and account logins remain one of the top targets of cyber attacks. Stolen credentials give cybercriminals access to valuable personal and financial information. Generate every password for every account with a random password generator, ideally built into a password manager for secure storage and autofill. Following password best practices ensures one stolen password results in minimal damage.
Layer with MFA. Adding multi-factor authentication to logins further protects against phishing attacks that steal passwords. With MFA in place, a hacker still can’t access an account after using a stolen password. By requiring additional login data, MFA can prevent cybercriminals from gaining access to personal or business accounts.
QR codes remain a popular marketing and communication tool. They’re convenient and accessible, so you can expect to encounter them occasionally. Though cyber attacks via QR codes are less common, you should still stay vigilant for signs of phishing and social engineering via QR codes. To prevent and mitigate attacks via QR codes, start by building a solid foundation of digital security with a trusted password manager.
“Luck favors the prepared,” as the saying goes. The maxim is true in cyber security, too. We all know about data breaches. We know they’re alarmingly common; more common than ever, if you can believe it. We know they can be costly, time-consuming, and disruptive. And yet, what do we know of mentally and emotionally preparing for an attack to happen to us?
A cyber attack can have a tremendous negative psychological impact, the effects of which victims can feel for weeks and months. Understanding the emotions you might feel during and after an attack can help you better prepare for and handle a cyber attack if/when it happens to you. Here’s what you need to know about the potential psychological impact of cyber attacks and what to do in advance so you can deal with one calmly and rationally.
During a cyber attack
Cyber attacks can happen suddenly. For example, you might get a random text or email about new account activity or a changed password. A service might inform you of a money transfer you didn’t approve, a purchase you didn’t make, or an account change you weren’t expecting. Or the next time you try to log in to an account, you find yourself locked out. Or your data is suddenly gone and held hostage by a cyber-criminal demanding a ransom. Or you just hung up the phone with someone who claimed to be tech support, and now you’re watching someone else control your computer without your consent.
No matter how it happens, panic often sets in once you find yourself suffering a cyber attack. It’s common to feel intense fear; fear for what will happen to your money and your personal information and the unknown impact the attack will have on your life. You might panic about what to do, how to regain control, and how to get help. You might feel violated, like someone has invaded your personal space and upended your sense of safety. In some ways, a cyber attack can feel like the digital equivalent of being robbed, with a corresponding wave of anxiety and dread.
Anxiety, panic, fear, and frustration – even intense anger – are common emotional responses when experiencing a cyber attack. While expected, these emotions can paralyze you and prolong or worsen a cyber attack. The combination of not knowing what to do and being paralyzed with fear can keep you from taking quick, effective action against a cyber attack. Preparing in advance can help you move through these intense emotions and respond productively.
During an attack, your focus should be on regaining control of the situation. Do you still have access to the account/device under attack? Immediately change passwords, remove unauthorized locations, notify customer service, check all security settings and do everything you can to lock out access to any third parties while beefing up security (including enabling two-factor authentication). On a trusted device (e.g., not a compromised device), change passwords for other high-value accounts like email, banking/financial, and social media. A password manager can help you change passwords quickly to new, random ones. You need to act fast while staying focused on the actions most likely to stop or at least slow down an attack.
Immediately after an attack
At some point, the attack will be over. Either you shut down the attack or the attackers “win,” and you find yourself dealing with the aftermath. Regardless, the emotional and mental impact may continue. A cyber attack can leave you with tough questions despite the initial relief when the immediate threat is over.
Self-pity and rumination are typical responses in the immediate wake of an attack. Why me? Did I draw their attention? Did I make a mistake? Why was my data/money/account/device worth stealing? Could I have done something different to prevent it? What if I had done x or y? Are they going to strike again? And on and on. You might find yourself overthinking and overanalyzing everything leading up to the attack. You might obsess over your actions during the attack and criticize yourself excessively for what you did or didn’t do.
Again, all of the above are understandable responses to a cyber attack. But these negative emotions can drag you down. If you’re mentally stuck, you’ll struggle to clean up after the attack and prepare for future incidents.
After an attack, your focus should be on analyzing how the attack happened and closing those “gaps” in your cyber security. Scan your devices for malware and change passwords. Turn on two-factor authentication, remove unknown and unused apps/browser extensions/software/files, and review the security settings for important accounts like email and financials. If the cybercriminals stole money, you’d need to follow any options for recourse against theft. You might also need to cancel a card, close an account, or freeze your credit to prevent further abuse. In sum, your goal immediately after an attack is over should be to identify weaknesses in your online security and eliminate or minimize them to prevent further problems.
Long-term impact
Unfortunately, negative emotions can persist weeks and months after a cyber attack, especially when the attack results in the theft of data, money, or other personal property. You’ll likely feel embarrassed about what happened, maybe even ashamed. You may worry about what others think if they find out the details. Sometimes, workplace security mistakes can lead to loss of employment, which can devastate one’s mental and physical wellbeing.
Avoidance is common, too; if you feel uncomfortable thinking about the cyber attack, you might use your discomfort as an excuse to avoid improving your cyber security. Ignoring your feelings, though, can keep you from processing what happened and doing what you must to ensure it doesn’t happen again.
Will it happen again? Apprehension is understandable in the wake of a cyber attack. You’ve been through a roller coaster of emotions, and the attack has forever shattered your sense of digital safety. Anxiety and worry about future attacks are normal but use those feelings as motivation to improve your cyber security strategy. There is never a “done” when it comes to cyber security. Hackers are constantly evolving their methods, and your cyber security strategy needs to keep up.
How to minimize psychological distress
Whether or not you’ve been the victim of a cyber attack, there are things you can do to stop or minimize future attacks. Building a solid foundation of cyber security requires doing the basics well. It’s not hard, but it takes a little time and commitment to improving your digital practices. The good news is that once you make these changes, you’ll find they can improve your online experience and help you feel better prepared for cyber attacks.
Prioritize good password hygiene. Weak, reused, guessable passwords contribute to account takeovers and online theft. Replace passwords with generated ones that are genuinely random and strong enough to withstand cracking. Enable two-factor authentication wherever it’s available; some two-factor apps make it easier to log in to an account.
Safeguard accounts with a password manager. A password manager stores credentials for your online accounts, enters your info when you need to log in, and ensures every password is unique and random. It simplifies strong password security and takes the hassle out of logging in.
Keep a clean machine. Don’t click random links. Don’t download strange attachments. Don’t install unverified apps and extensions. Don’t give strangers your login information, SSN, or other data. Don’t answer the phone for “tech support” – no tech support or police department or bank will ever call you to deal with a “security issue” or “software problem.”
Stay cyber aware. Watch for suspicious online account activity and take action at the first sign of something strange. Turn on account alerts to your phone or email. Enable dark web monitoring and follow up immediately on publicized data breaches. Know the signs of phishing and social engineering attacks, and scrutinize every text/email/phone call/social media message for signs of fraud.
Seek support and professional advice. You don’t have to suffer alone. Like other traumatic life events, a therapist or other qualified mental health professional can help you process after you’re the victim of cybercrime. When necessary, digital forensics and information security professionals can also help investigate and resolve a digital crime. Don’t hesitate to seek personal and professional support when needed.
Cybercriminals like to go after easy targets. Building a solid foundation with cyber security basics can prevent cyber attacks by making it too difficult or costly for criminals to go after your accounts. It can also buy you time to react immediately when an attack starts.
Cyber attacks can cause intense, paralyzing emotions. The more you educate yourself and prepare in advance, the more likely you are to work around those emotions during and after an attack. Don’t just assume you’ll deal with it and figure everything out in the moment. Do the work now to prepare so you’re not overwhelmed mentally by a cyber attack. Getting started with a password manager will help you build stronger, more effective online security habits. When you feel confident handling a cybersecurity incident, you’ll minimize the psychological impact of these scary events and more effectively navigate the challenges they can bring.
In this article, we take a look at the computing world’s arch nemesis – the ‘blue screen of death’. But is it as bad as you think? Here we share how the BSOD can actually help you get back online quicker.
We’ve all been there. You’re in the middle of typing a document or watching a movie and a sea of blue descends upon your screen. It may be iconic, but it’s possibly the most frustrating thing since dial-up. So exactly what is the Windows blue screen of death? And how has it evolved over the years?
Simply put, BSOD is a sign that all is not well with your computer.
Microsoft first introduced the BSOD in Windows 95. The original iteration primarily offered some cryptic words alluding to the issue, but not a lot more. When Windows 2000 was launched, the BSOD had also evolved to include a list of troubleshooting ideas that users could try to identify and fix the issue. Fast-forward to Windows XP, and users receive yet more advice on the BSOD, providing error codes you could Google for more information. Windows 8 saw the addition of an emoji – the ‘sad face’ to demonstrate empathy with how the user would feel after having their session rudely interrupted. And that’s largely where things have stayed…until now.
The blue screen of death in Windows 11
The introduction of Windows 11 saw a major transformation as the BSOD turned black to coincide with its logon and shut-down screens.
Or at least it was black for a few months. In a patch that was released not long after the black screen of death was introduced, Microsoft said:
“We changed the screen color to blue when a device stops working or a stop error occurs as in previous versions of Windows.”
While it wasn’t made clear what was going on or why the outcome is still the same – all is not well with your computer. Putting colors to one side, let’s consider what the BSOD is trying to tell you:
Stop code: similar to the error code, the stop code makes it a little easier to start identifying what the type of fault is, for example, ‘CRITICAL_PROCESS_DIED’.
QR code: introduced in Windows 8, the QR code directs you straight to the right support page.
Memory dump: Windows 11 introduced a new feature, which automatically generates a file named ‘minidump’ following a crash to help IT professionals establish the root cause.
So what should you do when faced with the BSOD?
It may sound cliché, but turn your computer off and on again. This usually resets the PC and sorts out whatever caused the device to crash. However, if the problem persists, reboot your PC into Safe Mode and try the following fixes:
How to boot into Safe Mode
Reboot your PC.
When you see the Windows Logo, reboot it again.
Repeat this step two more times, and it should place you in the automatic repair environment.
Once the system has rebooted, press F4 to enable Safe Mode.
Fix 1: run Windows Memory Diagnostic Tool
In the Search box type ‘Windows Memory Diagnostic’.
Click Restart now and check for problems (recommended).
Wait for the system to reboot and the tests to complete.
Restart the PC to check whether the problem is fixed.
Fix 2: update device drivers
Press Windows X and select Device Manager.
Choose a device category and select the drivers.
Right-click on the Driver and open Properties.
Navigate to the Driver tab and click Update Driver.
Update the driver.
Restart the PC to check whether the problem is fixed.
Once done, restart your system to check if the BSOD error is gone.
Fix 3: run SFC scan
Run Command Prompt utility as Administrator.
In the command prompt window, type SFC/scannow and press Enter.
Wait until the process is complete, and restart the PC to check whether the problem is fixed.
Fix 4: scan PC for malware
Open System Settings.
Go to Update & Security > Windows Security > Virus & threat protection.
Go to Windows security and select virus and threat protection.
If the Windows Defender antivirus program detects any virus, follow the instructions to remove it from your system.
Fix 5: perform a system restore
In the Windows Search box, type Create a restore point to open it.
Under System Protection, click System Restore.
Click Next > Next and select the restore point.
Click Scan for affected programs.
The process will scan for the programs, apps, and files that will be affected due to this process.
Once complete, click Next > Finish to end it.
Potential causes for the BSOD
Perhaps the most annoying thing about the BSOD is its unpredictability since it can appear at any time without warning. However, intelligence gathered from Microsoft suggests there are times when users are more prone to encounter the nasty interruption:
Recent computer changes: it’s common for new programs, hardware, and system updates to trigger the BSOD. If this occurs simply roll back the changes made.
Hard drive space: when the hard disk has less than 15% of its capacity free, it increases the likelihood of an incident.
Malware and viruses: if the master boot record becomes infected, start the PC in Safe Mode and perform a full scan using the antivirus software.
Hardware driver updates: already Windows 11 is notorious for triggering the BSOD after rolling out updates, like KB5012643 and KB5013943.
Recover data after a Blue Screen of Death with Ontrack
If your machine is not recoverable following the BSOD, Ontrack can help. The industry leader in data recovery, we have 35 years of experience, performed 600k+ recoveries, and have a 90% success rate.
If data can be stored on it, we can recover it any time, anywhere – and we tailor our data recovery services to suit customers ranging from home users to large enterprises.
This article addresses some common questions about WSUS maintenance for Configuration Manager environments.
Original product version: Windows Servers, Windows Server Update Services, Configuration Manager Original KB number: 4490644
Introduction
Questions are often along the lines of How should I properly run this maintenance in a Configuration Manager environment, or How often should I run this maintenance. It’s not uncommon for conscientious Configuration Manager administrators to be unaware that WSUS maintenance should be run at all. Most of us just set up WSUS servers because it’s a prerequisite for a software update point (SUP). Once the SUP is set up, we close the WSUS console and pretend it doesn’t exist. Unfortunately, it can be problematic for Configuration Manager clients, and the overall performance of the WSUS/SUP server.
With the understanding that this maintenance needs to be done, you’re wondering what maintenance you need to do and how often you need to be doing it. The answer is that you should perform monthly maintenance. Maintenance is easy and doesn’t take long for WSUS servers that have been well maintained from the start. However, if it has been some time since WSUS maintenance was done, the cleanup may be more difficult or time consuming the first time. It will be much easier or faster in subsequent months.
Maintain WSUS while supporting Configuration Manager current branch version 1906 and later versions
If you are using Configuration Manager current branch version 1906 or later versions, we recommend that you enable the WSUS Maintenance options in the software update point configuration at the top-level site to automate the cleanup procedures after each synchronization. It would effectively handle all cleanup operations described in this article, except backup and reindexing of WSUS database. You should still automate backup of WSUS database along with reindexing of the WSUS database on a schedule.
For more information about software update maintenance in Configuration Manager, see Software updates maintenance.
Before you start the maintenance process, read all of the information and instructions in this article.
When using WSUS along with downstream servers, WSUS servers are added from the top down, but should be removed from the bottom up. When syncing or adding updates, they go to the upstream WSUS server first, then replicate down to the downstream servers. When performing a cleanup and removing items from WSUS servers, you should start at the bottom of the hierarchy.
WSUS maintenance can be performed simultaneously on multiple servers in the same tier. When doing so, ensure that one tier is done before moving onto the next one. The cleanup and reindex steps described below should be run on all WSUS servers, regardless of whether they are a replica WSUS server or not. For more information about determining if a WSUS server is a replica, see Decline superseded updates.
Ensure that SUPs don’t sync during the maintenance process, as it may cause a loss of some work already done. Check the SUP sync schedule and temporarily set it to manual during this process.
If you have multiple SUPs of the primary site or central administration sit (CAS) which don’t share the SUSDB, consider the WSUS server that syncs with the first SUP on the site as residing in a tier below the site. For example, my CAS site has two SUPs:
The one named New syncs with Microsoft Update, it would be my top tier (Tier1).
The server named 2012 syncs with New, and it would be considered in the second tier. It can be cleaned up at the same time I would do all my other Tier2 servers, such as my primary site’s single SUP.
Perform WSUS maintenance
The basic steps necessary for proper WSUS maintenance include:
Back up the WSUS database (SUSDB) by using the desired method. For more information, see Create a Full Database Backup.
Create custom indexes
This process is optional but recommended, it greatly improves performance during subsequent cleanup operations.
If you are using Configuration Manager current branch version 1906 or a later version, we recommend that you use Configuration Manager to create the indexes. To create the indexes, configure the Add non-clustered indexes to the WSUS database option in the software update point configuration for the top-most site.
If you use an older version of Configuration Manager or standalone WSUS servers, follow these steps to create custom indexes in the SUSDB database. For each SUSDB, it’s a one-time process.
Make sure that you have a backup of the SUSDB database.
Use SQL Management Studio to connect to the SUSDB database, in the same manner as described in the Reindex the WSUS database section.
Run the following script against SUSDB, to create two custom indexes:SQLCopy-- Create custom index in tbLocalizedPropertyForRevision USE [SUSDB] CREATE NONCLUSTERED INDEX [nclLocalizedPropertyID] ON [dbo].[tbLocalizedPropertyForRevision] ( [LocalizedPropertyID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] -- Create custom index in tbRevisionSupersedesUpdate CREATE NONCLUSTERED INDEX [nclSupercededUpdateID] ON [dbo].[tbRevisionSupersedesUpdate] ( [SupersededUpdateID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] If custom indexes have been previously created, running the script again results in an error similar to the following one:Msg 1913, Level 16, State 1, Line 4 The operation failed because an index or statistics with name ‘nclLocalizedPropertyID’ already exists on table ‘dbo.tbLocalizedPropertyForRevision’.
The steps to connect to SUSDB and perform the reindex differ, depending on whether SUSDB is running in SQL Server or Windows Internal Database (WID). To determine where SUSDB is running, check value of the SQLServerName registry entry on the WSUS server located at the HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup subkey.
If the value contains just the server name or server\instance, SUSDB is running on a SQL Server. If the value includes the string ##SSEE or ##WID in it, SUSDB is running in WID, as shown:
If SUSDB was installed on WID
If SUSDB was installed on WID, SQL Server Management Studio Express must be installed locally to run the reindex script. Here’s an easy way to determine which version of SQL Server Management Studio Express to install:
For Windows Server 2012 or later versions:
Go to C:\Windows\WID\Log and find the error log that contains the version number.
Go to C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG and open up the last error log with Notepad. At the top, there will be a version number (for example 9.00.4035.00 x64). Look up the version number in How to determine the version, edition and update level of SQL Server and its components. This version number tells you what Service Pack level it’s running. Include the SP level when searching the Microsoft Download Center for SQL Server Management Studio Express.
After installing SQL Server Management Studio Express, launch it, and enter the server name to connect to:
If the OS is Windows Server 2012 or later versions, use \\.\pipe\MICROSOFT##WID\tsql\query.
If the OS is older than Windows Server 2012, enter \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.
For WID, if errors similar to the following occur when attempting to connect to SUSDB using SQL Server Management Studio (SSMS), try launching SSMS using the Run as administrator option.
If SUSDB was installed on SQL Server
If SUSDB was installed on full SQL Server, launch SQL Server Management Studio and enter the name of the server (and instance if needed) when prompted.
Tip
Alternatively, a utility called sqlcmd can be used to run the reindex script. For more information, see Reindex the WSUS Database.
Running the script
To run the script in either SQL Server Management Studio or SQL Server Management Studio Express, select New Query, paste the script in the window, and then select Execute. When it’s finished, a Query executed successfully message will be displayed in the status bar. And the Results pane will contain messages related to what indexes were rebuilt.
Decline superseded updates
Decline superseded updates in the WSUS server to help clients scan more efficiently. Before declining updates, ensure that the superseding updates are deployed, and that superseded ones are no longer needed. Configuration Manager includes a separate cleanup, which allows it to expire superseded updates based on specified criteria. For more information, see the following articles:
The following SQL query can be run against the SUSDB database, to quickly determine the number of superseded updates. If the number of superseded updates is higher than 1500, it can cause various software update related issues on both the server and client sides.
SQLCopy
-- Find the number of superseded updates
Select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded=1 and Declined=0
If you are using Configuration Manager current branch version 1906 or a later version, we recommend that you automatically decline the superseded updates by enabling the Decline expired updates in WSUS according to supersedence rules option in the software update point configuration for the top-most site.
When you use this option, you can see how many updates were declined by reviewing the WsyncMgr.log file after the synchronization process finishes. If you use this option, you don’t need to use the script described later in this section (either by manually running it or by setting up as task to run it on a schedule).
If you are using standalone WSUS servers or an older version of configuration Manager, you can manually decline superseded updates by using the WSUS console. Or you can run this PowerShell script. Then, copy and save the script as a Decline-SupersededUpdatesWithExclusionPeriod.ps1 script file.
Note
This script is provided as is. It should be fully tested in a lab before you use it in production. Microsoft makes no guarantees regarding the use of this script in any way. Always run the script with the -SkipDecline parameter first, to get a summary of how many superseded updates will be declined.
If Configuration Manager is set to Immediately expire superseded updates (see below), the PowerShell script can be used to decline all superseded updates. It should be done on all autonomous WSUS servers in the Configuration Manager/WSUS hierarchy.
You don’t need to run the PowerShell script on WSUS servers that are set as replicas, such as secondary site SUPs. To determine whether a WSUS server is a replica, check the Update Source settings.
If updates are not configured to be immediately expired in Configuration Manager, the PowerShell script must be run with an exclusion period that matches the Configuration Manager setting for number of days to expire superseded updates. In this case, it would be 60 days since SUP component properties are configured to wait two months before expiring superseded updates:
The following command lines illustrate the various ways that the PowerShell script can be run (if the script is being run on the WSUS server, LOCALHOST can be used in place of the actual SERVERNAME):
Running the script with a -SkipDecline and -ExclusionPeriod 60 to gather information about updates on the WSUS server, and how many updates could be declined:
Running the script with -ExclusionPeriod 60, to decline superseded updates older than 60 days:
The output and progress indicators are displayed while the script is running. Note the SupersededUpdates.csv file, which will contain a list of all updates that are declined by the script:
After superseded updates have been declined, for best performance, SUSDB should be reindexed again. For related information, see Reindex the WSUS database.
Run the WSUS Server Cleanup Wizard
WSUS Server Cleanup Wizard provides options to clean up the following items:
Unused updates and update revisions (also known as Obsolete updates)
Computers not contacting the server
Unneeded update files
Expired updates
Superseded updates
In a Configuration Manager environment, Computers not contacting the server and Unneeded update files options are not relevant because Configuration Manager manages software update content and devices, unless either the Create all WSUS reporting events or Create only WSUS status reporting events options are selected under Software Update Sync Settings. If you have one of these options configured, you should consider automating the WSUS Server Cleanup to perform cleanup of these two options.
If you are using Configuration Manager current branch version 1906 or a later version, enabling the Decline expired updates in WSUS according to supersedence rules option handles declining of Expired updates and Superseded updates based on the supersedence rules that are specified in Configuration Manager. Enabling the Remove obsolete updates from the WSUS database option in Configuration Manager current branch version 1906 handles the cleanup of Unused updates and update revisions (Obsolete updates). It’s recommended to enable these options in the software update point configuration on the top-level site to allow Configuration Manager to clean up the WSUS database.
If you’ve never cleaned up obsolete updates from WSUS database before, this task may time out. You can review WsyncMgr.log for more information, and manually run the SQL script that is specified in HELP! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out once, which would allow subsequent attempts from Configuration Manager to run successfully. For more information about WSUS cleanup and maintenance in Configuration Manager, see the docs.
For standalone WSUS servers, or if you are using an older version of Configuration Manager, it is recommended that you run the WSUS Cleanup wizard periodically. If the WSUS Server Cleanup Wizard has never been run and the WSUS has been in production for a while, the cleanup may time out. In that case, reindex with step 2 and step 3 first, then run the cleanup with only the Unused updates and update revisions option checked.
If you have never run WSUS Cleanup wizard, running the cleanup with Unused updates and update revisions may require a few passes. If it times out, run it again until it completes, and then run each of the other options one at a time. Lastly make a full pass with all options checked. If timeouts continue to occur, see the SQL Server alternative in HELP! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out. It may take multiple hours or days for the Server Cleanup Wizard or SQL alternative to run through completion.
The WSUS Server Cleanup Wizard runs from the WSUS console. It is located under Options, as shown here:
After it reports the number of items it has removed, the cleanup finishes. If you do not see this information returned on your WSUS server, it is safe to assume that the cleanup timed out. In that case, you will need to start it again or use the SQL alternative.
After superseded updates have been declined, for best performance, SUSDB should be reindexed again. See the Reindex the WSUS database section for related information.
Troubleshooting
HELP! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out
There are two different options here:
Reinstall WSUS with a fresh database. There are a number of caveats related to this, including length of initial sync, and full client scans against SUSDB, versus differential scans.
Ensure you have a backup of the SUSDB database, then run a reindex. When that completes, run the following script in SQL Server Management Studio or SQL Server Management Studio Express. After it finishes, follow all of the above instructions for running maintenance. This last step is necessary because the spDeleteUpdate stored procedure only removes unused updates and update revisions.
DECLARE @var1 INT
DECLARE @msg nvarchar(100)
CREATE TABLE #results (Col1 INT)
INSERT INTO #results(Col1) EXEC spGetObsoleteUpdatesToCleanup
DECLARE WC Cursor
FOR
SELECT Col1 FROM #results
OPEN WC
FETCH NEXT FROM WC
INTO @var1
WHILE (@@FETCH_STATUS > -1)
BEGIN SET @msg = 'Deleting' + CONVERT(varchar(10), @var1)
RAISERROR(@msg,0,1) WITH NOWAIT EXEC spDeleteUpdate @localUpdateID=@var1
FETCH NEXT FROM WC INTO @var1 END
CLOSE WC
DEALLOCATE WC
DROP TABLE #results
Running the Decline-SupersededUpdatesWithExclusionPeriod.ps1 script times out when connecting to the WSUS server, or a 401 error occurs while running
If errors occur when you attempt to use the PowerShell script to decline superseded updates, an alternative SQL script can be run against SUDB.
If Configuration Manager is used along with WSUS, check Software Update Point Component Properties > Supersedence Rules to see how quickly superseded updates expire, such as immediately or after X months. Make a note of this setting.
Use SQL Server Management Studio to connect to SUSDB.
Run the following query. The number 90 in the line that includes DECLARE @thresholdDays INT = 90 should correspond with the Supersedence Rules from step 1 of this procedure, and the correct number of days that aligns with the number of months that is configured in Supersedence Rules. If this is set to expire immediately, the value in the SQL query for @thresholdDays should be set to zero.SQLCopy-- Decline superseded updates in SUSDB; alternative to Decline-SupersededUpdatesWithExclusionPeriod.ps1 DECLARE @thresholdDays INT = 90 -- Specify the number of days between today and the release date for which the superseded updates must not be declined (i.e., updates older than 90 days). This should match configuration of supersedence rules in SUP component properties, if ConfigMgr is being used with WSUS. DECLARE @testRun BIT = 0 -- Set this to 1 to test without declining anything. -- There shouldn't be any need to modify anything after this line. DECLARE @uid UNIQUEIDENTIFIER DECLARE @title NVARCHAR(500) DECLARE @date DATETIME DECLARE @userName NVARCHAR(100) = SYSTEM_USER DECLARE @count INT = 0 DECLARE DU CURSOR FOR SELECT MU.UpdateID, U.DefaultTitle, U.CreationDate FROM vwMinimalUpdate MU JOIN PUBLIC_VIEWS.vUpdate U ON MU.UpdateID = U.UpdateId WHERE MU.IsSuperseded = 1 AND MU.Declined = 0 AND MU.IsLatestRevision = 1 AND MU.CreationDate < DATEADD(dd,-@thresholdDays,GETDATE()) ORDER BY MU.CreationDate PRINT 'Declining superseded updates older than ' + CONVERT(NVARCHAR(5), @thresholdDays) + ' days.' + CHAR(10) OPEN DU FETCH NEXT FROM DU INTO @uid, @title, @date WHILE (@@FETCH_STATUS > - 1) BEGIN SET @count = @count + 1 PRINT 'Declining update ' + CONVERT(NVARCHAR(50), @uid) + ' (Creation Date ' + CONVERT(NVARCHAR(50), @date) + ') - ' + @title + ' ...' IF @testRun = 0 EXEC spDeclineUpdate @updateID = @uid, @adminName = @userName, @failIfReplica = 1 FETCH NEXT FROM DU INTO @uid, @title, @date END CLOSE DU DEALLOCATE DU PRINT CHAR(10) + 'Attempted to decline ' + CONVERT(NVARCHAR(10), @count) + ' updates.'
To check progress, monitor the Messages tab in the Results pane.
What if I find out I needed one of the updates that I declined?
If you decide you need one of these declined updates in Configuration Manager, you can get it back in WSUS by right-clicking the update, and selecting Approve. Change the approval to Not Approved, and then resync the SUP to bring the update back in.
If the update is no longer in WSUS, it can be imported from the Microsoft Update Catalog, if it hasn’t been expired or removed from the catalog.
Automating WSUS maintenance
Note
If you are using Configuration Manager version1906 or a later version, automate the cleanup procedures by enabling the WSUS Maintenance options in the software update point configuration of the top-level site. These options handle all cleanup operations that are performed by the WSUS Server Cleanup Wizard. However, you should still automatically back up and reindex the WSUS database on a schedule.
WSUS maintenance tasks can be automated, assuming that a few requirements are met first.
If you have never run WSUS cleanup, you need to do the first two cleanups manually. Your second manual cleanup should be run 30 days from your first since it takes 30 days for some updates and update revisions to age out. There are specific reasons for why you don’t want to automate until after your second cleanup. Your first cleanup will probably run longer than normal. So you can’t judge how long this maintenance will normally take. The second cleanup is a much better indicator of what is normal for your machines. This is important because you need to figure out about how long each step takes as a baseline (I also like to add about 30-minutes wiggle room) so that you can determine the timing for your schedule.
If you have downstream WSUS servers, you will need to perform maintenance on them first, and then do the upstream servers.
To schedule the reindex of the SUSDB, you will need a full version of SQL Server. Windows Internal Database (WID) doesn’t have the capability of scheduling a maintenance task though SQL Server Management Studio Express. That said, in cases where WID is used you can use the Task Scheduler with SQLCMD mentioned earlier. If you go this route, it’s important that you don’t sync your WSUS servers/SUPs during this maintenance period! If you do, it’s possible your downstream servers will just end up resyncing all of the updates you just attempted to clean out. I schedule this overnight before my AM sync, so I have time to check on it before my sync runs.
Setting up the WSUS Cleanup task in Task Scheduler
Note
As mentioned previously, if you are using Configuration Manager current branch version 1906 or a later version, automate the cleanup procedures by enabling the WSUS Maintenance options in the software update point configuration of the top-level site. For standalone WSUS servers or older versions of Configuration Manager, you can continue to use the following steps.
The Weekend Scripter blog post mentioned in the previous section contains basic directions and troubleshooting for this step. However, I’ll walk you through the process in the following steps.
Open Task Scheduler and select Create a Task. On the General tab, set the name of the task, the user that you want to run the PowerShell script as (most people use a service account). Select Run whether a user is logged on or not, and then add a description if you wish.
Under the Actions tab, add a new action and specify the program/script you want to run. In this case, we need to use PowerShell and point it to the PS1 file we want it to run. You can use the WSUS Cleanup script. This script performs cleanup options that Configuration Manager current branch version 1906 doesn’t do. You can uncomment them if you are using standalone WSUS or an older version of Configuration Manager. If you would like a log, you can modify the last line of the script as follows:PowerShellCopy[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(); $cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope; # $cleanupScope.DeclineSupersededUpdates = $true # Performed by CM1906 # $cleanupScope.DeclineExpiredUpdates = $true # Performed by CM1906 # $cleanupScope.CleanupObsoleteUpdates = $true # Performed by CM1906 $cleanupScope.CompressUpdates = $true $cleanupScope.CleanupObsoleteComputers = $true $cleanupScope.CleanupUnneededContentFiles = $true $cleanupManager = $wsus.GetCleanupManager(); $cleanupManager.PerformCleanup($cleanupScope) | Out-File C:\WSUS\WsusClean.txt; You’ll get an FYI/warning in Task Scheduler when you save. You can ignore this warning.
On the Triggers tab, set your schedule for once a month or on any schedule you want. Again, you must ensure that you don’t sync your WSUS during the entire cleanup and reindex time.
Set any other conditions or settings you would like to tweak as well. When you save the task, you may be prompted for credentials of the Run As user.
You can also use these steps to configure the Decline-SupersededUpdatesWithExclusionPeriod.ps1 script to run every three months. I usually set this script to run before the other cleanup steps, but only after I have run it manually and ensured it completed successfully. I run at 12:00 AM on the first Sunday every three months.
Setting up the SUSDB reindex for WID using SQLCMD and Task Scheduler
Schedule this task to start about 30 minutes after you expect your cleanup to finish running. My cleanup is running at 1:00 AM every first Sunday. It takes about 30 minutes to run and I am going to give it another 30 minutes before starting my reindex. It means I would schedule this task for every first Sunday at 2:00 AM, as shown here:
Select the action to Start a program. In the Program/script box, type the following command. The file specified after the -i parameter is the path to the SQL script you saved in step 1. The file specified after the -o parameter is where you would like the log to be placed. Here’s an example:"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt
You’ll get a warning, similar to the one you got when creating the cleanup task. Select Yes to accept the arguments, and then select Finish to apply:
You can test the script by forcing it to run and reviewing the log for errors. If you run into issues, the log will tell you why. Usually if it fails, the account running the task doesn’t have appropriate permissions or the WID service isn’t started.
Setting up a basic Scheduled Maintenance Task in SQL for non-WID SUSDBs
Note
You must be a sysadmin in SQL Server to create or manage maintenance plans.
Open SQL Server Management Studio and connect to your WSUS instance. Expand Management, right-click Maintenance Plans, and then select New Maintenance Plan. Give your plan a name.
Select subplan1 and then ensure your Toolbox is in context:
Drag and drop the task Execute T-SQL Statement Task:
Right-click it and select Edit. Copy and paste the WSUS reindex script, and then select OK:
Schedule this task to run about 30 minutes after you expect your cleanup to finish running. My cleanup is running at 1:00 AM every first Sunday. It takes about 30 minutes to run, and I am going to give it another 30 minutes before starting reindex. It means I would schedule this task to run every first Sunday at 2:00 AM.
While creating the maintenance plan, consider adding a backup of the SUSDB into the plan as well. I usually back up first, then reindex. It may add more time to the schedule.
Putting it all together
When running it in a hierarchy, the WSUS cleanup run should be done from the bottom of the hierarchy up. However, when using the script to decline superseded updates, the run should be done from the top down. Declining superseded updates is really a type of addition to an update rather than a removal. You’re actually adding a type of approval in this case.
Since a sync can’t be done during the actual cleanup, it’s suggested to schedule/complete all tasks overnight. Then check on their completion via the logging the following morning, before the next scheduled sync. If something failed, maintenance can be rescheduled for the next night, once the underlying issue is identified and resolved.
These tasks may run faster or slower depending on the environment, and timing of the schedule should reflect that. Hopefully they are faster since my lab environment tends to be a bit slower than a normal production environment. I am a bit aggressive on the timing of the decline scripts. If Tier2 overlaps Tier3 by a few minutes, it will not cause a problem because my sync isn’t scheduled to run.
Not syncing keeps the declines from accidentally flowing into my Tier3 replica WSUS servers from Tier2. I did give myself extra time between the Tier3 decline and the Tier3 cleanup since I definitely want to make sure the decline script finishes before running my cleanup.
It brings up a common question: Since I’m not syncing, why shouldn’t I run all of the cleanups and reindexes at the same time?
The answer is that you probably could, but I wouldn’t. If my coworker across the globe needs to run a sync, with this schedule I would minimize the risk of orphaned updates in WSUS. And I can schedule it to rerun to completion the next night.
Time
Tier
Tasks
12:00 AM
Tier1-Decline
12:15 AM
Tier2-Decline
12:30 AM
Tier3-Decline
1:00 AM
Tier3 WSUS Cleanup
2:00 AM
Tier3 Reindex
Tier2 WSUS Cleanup
3:00 AM
Tier1-Cleanup
Tier2 Reindex
4:00 AM
Tier1 Reindex
Note
If you’re using Configuration Manager current branch version 1906 or a later version to perform WSUS Maintenance, Configuration Manager performs the cleanup after synchronization using the top-down approach. In this scenario, you can schedule the WSUS database backup and reindexing jobs to run before the configured sync schedule without worrying about any of the other steps, because Configuration Manager will handle everything else.
For more information about SUP maintenance in Configuration Manager, see the following articles:
Password-protected ZIP archives are common means of compressing and sharing sets of files—from sensitive documents to malware samples to even malicious files (i.e. phishing “invoices” in emails).
But, did you know it is possible for an encrypted ZIP file to have two correct passwords, with both producing the same outcome when the ZIP is extracted?
A ZIP file with two passwords
Arseniy Sharoglazov, a cybersecurity researcher at Positive Technologies shared over the weekend a simple experiment where he produced a password-protected ZIP file called x.zip.
The password Sharoglazov picked for encrypting his ZIP was a pun on the 1987 hit that’s become a popular tech meme:
But the researcher demonstrated that when extracting x.zip using a completely different password, he received no error messages.
In fact, using the different password resulted in successful extraction of the ZIP, with original contents intact:
pkH8a0AqNbHcdw8GrmSp
Two different passwords for same ZIP file result in successful extraction (Sharoglazov)
BleepingComputer was able to successfully reproduce the experiment using different ZIP programs. We used both p7zip (7-Zip equivalent for macOS) and another ZIP utility called Keka.
Like the researcher’s ZIP archive, ours was created with the aforementioned longer password, and with AES-256 encryption mode enabled.
While the ZIP was encrypted with the longer password, using either password extracted the archive successfully.
How’s this possible?
Responding to Sharoglazov’s demo, a curious reader, Rafaraised an important question, “How????”
Twitter user Unblvr seems to have figured out the mystery:
When producing password-protected ZIP archives with AES-256 mode enabled, the ZIP format uses the PBKDF2 algorithm and hashes the password provided by the user, if the password is too long. By too long, we mean longer than 64 bytes (characters), explains the researcher.
Instead of the user’s chosen password (in this case “Nev1r-G0nna-G2ve-…”) this newly calculated hash becomes the actual password to the file.
When the user attempts to extract the file, and enters a password that is longer than 64 bytes (“Nev1r-G0nna-G2ve-… “), the user’s input will once again be hashed by the ZIP application and compared against the correct password (which is now itself a hash). A match would lead to a successful file extraction.
The alternative password used in this example (“pkH8a0AqNbHcdw8GrmSp“) is in fact ASCII representation of the longer password’s SHA-1 hash.
SHA-1 checksum of “Nev1r-G0nna-G2ve-…” = 706b4838613041714e62486364773847726d5370.
This checksum when converted to ASCII produces: pkH8a0AqNbHcdw8GrmSp
Note, however, that when encrypting or decrypting a file, the hashing process only occurs if the length of the password is greater than 64 characters.
In other words, shorter passwords will not be hashed at either stage of compressing or decompressing the ZIP.
This is why when picking the long “Nev1r-G0nna-G2ve-… ” string as the password at the encryption stage, the actual password being set by the ZIP program is effectively the (SHA1) hash of this string.
At the decryption stage, if you were to enter “Nev1r-G0nna-G2ve-…,” it will be hashed and compared against the previously stored password (which is the SHA1 hash). However, entering the shorter “pkH8a0AqNbHcdw8GrmSp” password at the decryption stage will have the application directly compare this value to the stored password (which is, again the SHA1 hash).
The HMAC collisions subsection of PBKDF2 on Wikipedia provides some more technical insight to interested readers.
“PBKDF2 has an interesting property when using HMAC as its pseudo-random function. It is possible to trivially construct any number of different password pairs with collisions within each pair,” notes the entry.
“If a supplied password is longer than the block size of the underlying HMAC hash function, the password is first pre-hashed into a digest, and that digest is instead used as the password.”
But, the fact that there are now two possible passwords to the same ZIP does not represent a security vulnerability, “as one still must know the original password in order to generate the hash of the password,” the entry further explains.
Arriving at a perfect password
An interesting key aspect to note here is, ASCII representations of every SHA-1 hash need not be alphanumeric.
In other words, let’s assume we had chosen the following password for our ZIP file during this experiment. The password is longer than 64 bytes:
It’s SHA-1 checksum comes out to be: bd0b8c7ab2bf5934574474fb403e3c0a7e789b61
And the ASCII representation of this checksum looks like a gibberish set of bytes—not nearly elegant as the alternative password generated by the researcher for his experiment:
ASCII representation of SHA-1 hash of Bl33pingC0mputer… password
BleepingComputer asked Sharoglazov how was he able to pick a password whose SHA-1 checksum would be such that its ASCII representation yields a clean, alphanumeric string.
“That’s why hashcat was used,” the researcher tells BleepingComputer.
By using a slightly modified version of the open source password recovery tool, hashcat, the researcher generated variations of the “Never Gonna Give You Up…” string using alphanumeric characters until he arrived at a perfect password.
“I tested Nev0r, Nev1r, Nev2r and so on… And I found the password I need.”
And, that’s how Sharoglazov arrived at a password that roughly reads like “Never Gonna Give You Up…,” but the ASCII representation of its SHA-1 checksum is one neat alphanumeric string.
For most users, creating a password-protected ZIP file with a choice of their password should be sufficient and that is all they would need to know.
But should you decide to get adventurous, this experiment provides a peek into one of the many mysteries surrounding encrypted ZIPs, like having two passwords to your guarded secret.
Before COVID-19, most corporate employees worked in offices, using computers connected to the internal network. Once users connected to these internal networks, they typically had access to all the data and applications without many restrictions. Network architects designed flat internal networks where the devices in the network connected with each other directly or through a router or a switch.
But while flat networks are fast to implement and have fewer bottlenecks, they’re extremely vulnerable — once compromised, attackers are free to move laterally across the internal network.
Designing flat networks at a time when all the trusted users were on the internal networks might have been simpler and more efficient. But times have changed: Today, 55% of those surveyed say they work more hours remotely than at the physical office. Due to the rapid evolution of the way we work, corporations must now contend with:
Multiple network perimeters at headquarters, in remote offices and in the cloud
Applications and data scattered across different cloud platforms and data centers
Users who expect the same level of access to internal networks while working remotely
While this is a complex set of issues, there is a solution. Network segmentation, when implemented properly, can unflatten the network, allowing security admins to compartmentalize internal networks and provide granular user access.
What is network segmentation?
The National Institute of Standards and Technology (NIST) offers the following definition for network segmentation: “Splitting a network into sub-networks; for example, by creating separate areas on the network which are protected by firewalls configured to reject unnecessary traffic. Network segmentation minimizes the harm of malware and other threats by isolating it to a limited part of the network.”
The main principle of segmentation is making sure that each segment is protected from the other, so that if a breach does occur, it is limited to only a portion of the network. Segmentation should be applied to all entities in the IT environment, including users, workloads, physical servers, virtual machines, containers, network devices and endpoints.
Connections between these entities should be allowed only after their identities have been verified and proper access rights have been established. The approach of segmenting with granular and dynamic access is also known as Zero Trust Network Access (ZTNA).
As shown in Figure 1, instead of a network with a single perimeter, inside which entities across the network are freely accessible, a segmented network environment features smaller network zones with firewalls separating them.
Achieving network segmentation
Implementing segmentation may seem complex, and figuring out the right place to start might seem intimidating. But by following these steps, it can be achieved rather painlessly.
1. Understand and Visualize
Network admins need to map all the subnets and virtual local area networks (VLANs) on the corporate networks. Visualizing the current environment provides a lot of value right away in understanding both how to and what to segment.
At this step, network and security teams also need to work together to see where security devices such as firewalls, IPS and network access controls are deployed in the corporate network. An accurate map of the network and a complete inventory of security systems will help tremendously in creating efficient segments.
2. Segment and Create Policies
The next step in the process is to create the segments themselves: Large subnets or zones should be segmented, monitored and protected with granular access policies. Segments can be configured based on a variety of categories, including geo-location, corporate departments, server farms, data centers and cloud platforms.
After defining segments, create security policies and access-control rules between those segments. These polices can be created and managed using firewalls, VLANs or secure mobile access devices. In most cases, security admins can simply use existing firewalls or secure mobile access solutions to segment and create granular policies. It’s best for administrators to ensure that segments and policies are aligned with business processes.
3. Monitor and Enforce Policies
After creating segments and policies, take some time to monitor the traffic patterns between those segments. The first time the security policies are enforced, it may cause disruption to regular business functions. So it’s best to apply policies in non-blocking or alert mode and monitor for false positives or other network errors.
Next, it’s the time to enforce policies. Once the individual policies are pushed, each segment is protected from cyber attackers’ lateral movements and from internal users trying to reach resources they are not authorized to use. It’s a good idea to continuously monitor and apply new policies as needed whenever there are changes to networks, applications or user roles.
Policy-based segmentation: A way forward for distributed networks
What today’s enterprises require is a way to deliver granular policy enforcement to multiple segments within the network. Through segmentation, companies can protect critical digital assets against any lateral attacks and provide secure access to remote workforces.
The good news is that, with the power and flexibility of a next-generation firewall (NGFW) and with other technologies such as secure mobile access and ZTNA solutions, enterprises can safeguard today’s distributed networks by enforcing policy-based segmentation.
SonicWall’s award-winning hardware and advanced technologies include NGFWs, Secure Mobile Access and Cloud Edge Secure Access. These solutions are designed to allow any network— from small businesses to large enterprises, from the datacenter to the cloud — to segment and achieve greater protection with SonicWall.
The oil and gas industry continues to be a prime target for threat actors who want to disrupt the operation and wreak havoc. In part two, we discussed various threats that can affect an oil and gas company, including ransomware, DNS tunneling, and zero-day exploits. For the final installment of the series, we’ll investigate the APT33 case study—a group generally considered to be responsible for many spear-phishing campaigns targeting the oil industry and its supply chain. We’ll also lay out several recommendations to better strengthen the cybersecurity framework of oil and gas companies.
APT33: a case study
The group APT33 is known to target the oil supply chain, the aviation industry, and military and defense companies. Our team observed that the group has had some limited success in infecting targets related to oil, the U.S. military, and U.S. national security. In 2019, we found that the group infected a U.S. company providing support services to national security.
APT33 has also compromised oil companies in Europe and Asia. A large oil company with a presence in the U.K. and India had concrete APT33-related infections in the fall of 2018. Some of the IP addresses of the oil company communicated with the C&C server times-sync.com, which hosted a so-called Powerton C&C server from October to December 2018, and then again in 2019. A computer server in India owned by a European oil company communicated with a Powerton C&C server used by APT33 for at least three weeks in November and December 2019. We also observed that a large U.K.-based company offering specialized services to oil refineries and petrochemical installations was likely compromised by APT33 in the fall of 2018.
APT33’s best-known infection technique has been using social engineering through emails. It has been using the same type of lure for several years: a spear-phishing email containing a job opening offer that may look quite legitimate. There have been campaigns involving job openings in the oil and aviation industries.
The email contains a link to a malicious .hta file, which would attempt to download a PowerShell script. This would then download additional malware from APT33 so that the group could gain persistence in the target network. Table 1 lists some of the campaigns we were able to recover from data based on feedback from the Trend Micro™ Smart Protection Network™ infrastructure. The company names in the campaigns are not necessarily targets in the campaign, but they are usually part of the social lure used in the campaigns.
Figure 1. PHP mailer script probably used by APT33. The script was hosted on the personal website of a European senator who had a seat on his nation’s defense committee.
The job opening social engineering lures are used for a reason: Some of the targets actually get legitimate email notifications about job openings for the same companies used in the spear-phishing emails. This means that APT33 has some knowledge of what their targets are receiving from legitimate sources.
APT33 is known to be related to the destructive malware called StoneDrill and is possibly related to attacks involving Shamoon, although we don’t have solid evidence for the latter. Besides the relatively aggressive attacks of APT33 on the supply chain, we found that APT33 has been using several C&C domains, listed in Table 2, for small botnets composed of about a dozen bots each. It appears that APT33 has taken special care to make tracking more difficult.
The C&C domains are hosted on cloud-hosted proxies. These proxies relay URL requests from the infected bots to back-ends at shared web servers that may host thousands of legitimate domains. These back-ends are protected with special software that detects unusual probing from researchers. The back-ends report bot data back to a dedicated aggregator and bot control server on a dedicated IP address. The APT33 actors connect to these aggregators via a private VPN with exit nodes that are changed frequently. Using these VPN connections, the APT33 actors issue commands and retrieve data from the bots.
Figure 2. Schema showing the multiple obfuscation layers used by APT33
Regarding APT33, we were able to track private VPN exit nodes for more than a year. We could cross relate the exit nodes with admin connections to servers controlled by APT33. It appears that these private VPN exit nodes are also used for reconnaissance of networks that are relevant to the supply chain of the oil industry. More concretely, we witnessed IP addresses that we believe are under the control of APT33 doing reconnaissance on the networks of an oil exploration company in the Middle East, an oil company in the U.S., and military hospitals in the Middle East.
Table 2. IP addresses associated with a few private VPN exit nodes connected to APT33
Table 2 shows a list of IP addresses that have been used by APT33. The IP addresses are likely to have been used for a longer time than the time frames indicated in the table. The data can be used to determine whether an organization was on the radar of APT33 for, say, reconnaissance or concrete compromises.
Security recommendations
Here are several general tips that may help companies in the oil and gas industry combat threat actors:
Perform data integrity checks While there may not be an immediate need for encrypting all data communications in an oil and gas company, there is some merit in taking steps to ensure data integrity. For example, regarding the information from the different sensors at oil production sites, the risk of tampering with oil production can be reduced by at least making sure that all data communication is signed. This can greatly decrease the risk of man-in-the-middle attacks where sensor values could be changed or where a third party could alter commands or inject commands without authorization.
Implement DNSSEC We have noticed that many oil and gas companies don’t have Domain Name System Security Extensions (DNSSEC) implemented. DNSSEC means digitally signing the DNS records of a domain name at the authoritative nameserver with a private key. DNS resolvers can check whether DNS records are properly signed.
Lock down domain names Domain names can potentially be taken over by a malicious actor, for example, through an unauthorized change in the DNS settings. To prevent this, it is important to use only a DNS service provider that requires two-factor authentication for any changes in the DNS settings of the domains of an organization.
Monitor SSL certificates For the protection of a brand name and for early warnings of possible upcoming attacks, it is important to monitor newly created SSL certificates that have certain keywords in the Common Name field.
Look out for business email compromise Protection against business email compromise (BEC) is possible through spam filtering, user training for spotting suspicious emails, and AI techniques that will recognize the writing styles of individuals in the company.
Require at least two-factor authentication for webmail A webmail hostname might get DNS-hijacked or hacked because of a vulnerability in the webmail software. And webmail can also be attacked with credential-phishing attacks; a well-prepared credential-phishing attack can be quite convincing. The risk of using webmail can be greatly reduced by requiring two-factor authentication (preferably with a physical key) and corporate VPNs for webmail access.
Hold employee training sessions for security awareness It is important to have regular training sessions for all employees. These sessions may include awareness training on credential phishing, spear phishing, social media use, data management, privacy policies, protecting intellectual property, and physical security.
Monitor for data leaks Watermarks make it easier to find leaked documents since the company can constantly monitor for these specific marks. Some companies specialize in finding leaked data and compromised credentials; through active monitoring for leaks, potential damage to the company can be mitigated earlier.
Keep VPN software up to date Several weaknesses in VPN software were found in recent years.36, 37 For various reasons, some companies do not update their VPN software immediately after patches become available. This is particularly dangerous since APT actors start to probe for vulnerable VPN servers (including those of oil companies) as soon as a vulnerability becomes public.
Review the security settings of cloud services Cloud services can boost efficiency and reduce cost, but companies sometimes forget to effectively use all security measures offered by cloud services. Some services help companies with cloud infrastructure security.
The Russia-Ukraine war has posed threats to the oil and gas industry. Our team even uncovered several alleged attacks perpetrated by various groups during a March 2022 research. In part one, we exhibit how a typical oil and gas company works and why it can be susceptible to cyberattacks. We also explain different threats that can disrupt its operation.
In part two, let’s continue identifying threats that pose great risk to an oil and gas company.
Threats
Ransomware Ransomware remains a serious threat to oil and gas companies. Targeting individuals using ransomware is fairly easy for cybercriminals, even for those with a lower level of computer knowledge. The easiest business model consists of subscribing to ransomware-as-a-service (RaaS) offers on underground cybercrime marketplaces.18 Any fraudster can buy such a service and start delivering ransomware to thousands of individuals’ computers by using exploit kits or spam emails.
During our research, we found that a U.S. oil and natural gas company was hit by ransomware, infecting three computers and its cloud backups. The computers that were targeted contained essential data for the company, and the estimated total loss was more than US$30 million. While we do not have additional details on this case, we believe the attackers did plan this attack carefully and were able to target a few strategic computers rather than hitting the company with a massive infection.
Malware Various kinds of malware serve different purposes, functioning and communicating between the infected computers and the C&C servers. Compromising and planting malware inside a target network is just the initial stage for attackers. Yet for several reasons, these actions can be detected after a while or even just deleted automatically by any antivirus or security solution.
To avoid being kicked off from the network when the only available access is via their malware, attackers generally choose to regularly update their malware. And if possible, they use different malware families so that they have more than one way to access the compromised network.
Webshells Webshells are tiny files, generally written in PHP, ASP, or JavaScript language, that have been fraudulently uploaded to a web server belonging to a targeted entity. An attacker just needs to browse it to get access to the web server. Most common options for webshells provide upload or download file operations, command line (shell), and dump databases.
Threat actors sometimes utilize webshells to ease their operations. They can use webshells to:
Download or upload files to the compromised web server;
Run other tools (such as credential stealers);
Maintain persistence on the compromised infrastructure;
Bounce to other servers and move on with more compromises; or
Steal information.
Cookies Cookies are small files sent from web servers and stored in the browser of an internet user. They serve different legitimate purposes, such as allowing a browser to know if the user is logged in or not (as in the case of authentication cookies) or storing stateful information (like items in shopping carts).
Some variants of the backdoor BKDR64_RGDOOR22 used cookies23 to handle communications between the malware and its C&C server. They used the string “RGSESSIONID=” followed by encrypted content. Careful cookie field monitoring in HTTP traffic can help detect this kind of activity.
DNS tunnelling The most common way for malware to communicate with its C&C server is by using HTTP or HTTPS protocol. However, some attackers allow their malware to communicate via DNS tunnelling. In this content, DNS tunnelling exploits the DNS protocol to transmit data between the malware and its controller, via DNS queries and response packets.
The DNS client software (the malware) sends data, generally encoded in some ways, prepended as the hostname of the DNS query.
Email as communication channel An APT attacker might want to use this method mostly for two reasons: email services, especially external online services, might be less monitored than other services in the compromised network, and it might provide an additional level of anonymity depending on the email service provider that is used.
Zero-day exploits More often than not, attackers use known exploits and only use zero-day exploits when really necessary. It doesn’t take much effort to compromise most networks, gain access and exfiltrate information with standard malware and tools.
The Stuxnet case is a solid and interesting example of zero-day exploits, using four different types. No other known attack has been seen exploiting so many unpatched and unknown vulnerabilities — it has shown an extraordinary level of sophistication.
Two years before Stuxnet, another malware from the Equation group27 was using two of the four zero-day exploits that Stuxnet used. The Equation group targeted many different sectors, including oil and gas, energy, and nuclear research. It showed advanced technical capabilities, including infecting the hard drive firmware of several major hard drive manufacturers, which had seemed impossible without the firmware source code.
Mobile phone malware There has been an increase in the use of mobile phone malware in recent years. It is typically used for cybercrime, but can also be utilized for espionage.
The Reaper threat actor has developed Android malware, which we detect as AndroidOS_KevDroid. This malware has several functionalities, including starting a video or audio recording, downloading the address book from the compromised phone, fetching specific files, and reading SMS messages and other information from the phone.
The MuddyWater APT group29 has used several variants of Android malware (AndroidOS_Mudwater.HRX, AndroidOS_HiddenApp.SAB, AndroidOS_Androrat.AXM, and .AXMA) posing as legitimate applications. These malware variants can completely take control of an Android phone, spread infecting links via SMS, and steal contacts, SMS messages, screenshots, and call logs.
Bluetooth Bluetooth can also be exploited by threat actors. And one of the most interesting recent discoveries in this regard is the USB Bluetooth Harvester.30 It is very uncommon, but it highlights the need for organizations to stay up to date on threat actor developments.
Cloud services Attackers can use legitimate cloud services to render the traffic between malware and the C&C server undetectable. For example, the Slub malware has been used for APT attacks. While it hasn’t affected the industry just yet, it bears mentioning as it use Git Hub (a software development platform), and Slack (a messaging service), for C&C communication can easily be copied by other threat actors.
In the final installation of our series, we’ll look at APT33—a group generally considered responsible for many spear-phishing campaigns targeting the oil industry and its supply chain. We’ll also discuss recommendations that oil and gas companies can utilize to further improve their cybersecurity.
The oil and gas industry is no stranger to major cybersecurity attacks, attempting to disrupt operations and services. Most of the best understood attacks against the oil industry are initial attempts to break into the corporate networks of oil companies.
Geopolitical tensions can cause major changes not only in physical space, but also in cyberspace. In March 2022, our researchers observed several alleged cyberattacks perpetrated by different groups. It has now become important more than ever to identify potential threats that may disrupt oil and gas companies, especially in these times when tensions are high.
Our survey also found that oil and gas companies have experienced disruptions with their supply due to cyberattacks. On average, the disruption lasted six days. The the financial damage amounts to approximately $3.3 million. Due to long disruption, the oil and gas industry has a much larger damage, too.
It is important to have an in-depth at cyberattacks than can disrupt oil and gas companies because they affect operations and profit in a major way. By looking closer at the infrastructure of an oil and gas company and identifying threats that can disrupt operation, a company can seal off loopholes and improve their cybersecurity framework.
The Infrastructure of a Typical Oil and Gas Company
An oil and gas company’s product chain usually has three parts—upstream, midstream, and downstream. Processes related to oil exploration and production is called an upstream, while the midstream refers to the transportation and storage of crude oil through pipelines, trains, ships, or trucks. Lastly, the downstream the production of end products. Cyber risks are present in all three categories, but for midstream and upstream, there are few publicly documented incidents.
Generally, an oil company has production sites where crude oil is extracted from wells, tank farms, where oil is stored temporarily, and a transportation system to bring the crude oil to a refinery. Transportation may include pipelines, trains, and ships. After processing in the refinery, different end products like diesel fuel, gasoline, and jet fuel are transported to tank farms and the products are later shipped to customers.
A gas company also typically has production sites and a transportation system such as railroads, ships, and pipelines. However, it needs compressor stations where the natural gas is compressed before transport. The natural gas is then transported to another plant that separates different hydrocarbon components, from natural gas, like LPG and cooking gas.
The intricate process of oil and gas companies mean they require constant monitoring to ensure the optimal performance measurement, performance improvement, quality control and safety.
Monitoring metrics include temperature, pressure, chemical composition, and detection of leaks. Some oil and gas production sites are in very remote locations where the weather can be extreme. For these sites, communication of the monitored metrics over the air, fixed (optic or copper) lines, or satellite is important. The systems of an oil and gas company is typically controlled by software and can be compromised by an attacker.
Threats
There are several threats that oil and gas companies should be aware of. The biggest threat to the industry is those that have a direct negative impact on the production of their end products. In addition, espionage is something that such companies need to defend themselves against, too.
In our in-depth research, the expert team at Trend Micro identified the following threats that can compromise oil and gas companies:
Sabotage In the context of the oil and gas industry, sabotage can be done by changing the behavior of software, deleting or wiping specific content to disrupt company activity or deleting or wiping as much content as possible on every accessible machine.
Some examples of these kinds of sabotage operations have been reported broadly, the most famous being the Stuxnet case. Stuxnet was a piece of self-replicating malware that contained a very targeted and specific payload. Most infections of the worm were in Iran and analysis revealed that it was designed to exclusively target the centrifuge in the uranium enrichment facility of the Natanz Nuclear Plant in the country.
Insider threat In most cases, an insider is a disgruntled employee seeking revenge or wanting to make easy money by selling valuable data to competitors. This person can sabotage operations. They can alter data to create problems, delete or destroy data from corporate servers or shared project folders, steal intellectual property, and leak sensitive documents to third parties.
Defense against insider threats is very complex since insiders generally have access to a lot of data. An insider also does not need months to know the internal network of the company — the insider probably already knows the inner workings of the organization.
Espionage and data theft Data theft and espionage can be the starting point of a larger destructive attack. Attackers often need specific information before attempting further action. Obtaining sensitive data like well drilling techniques, data on suspected oil and gas reserves, and special recipes for premium products can also translate to monetary gain for attackers.
DNS hijacking DNS hijacking is a form of data theft used by advanced attackers. The objective is to gain access to the corporate VPN network or corporate emails of governments and companies. We have seen several oil companies being targeted by advanced attackers who probably have certain geopolitical goals in mind.
In DNS hijacking, the DNS settings of a domain name are modified by an unauthorized third party. The third-party can, for instance, add an entry to the zone file of a domain or alter the resolution of one or more of the existing hostnames. The simplest things the attacker can do are committing vandalism(defacement), leaving a message on the hijacked website, and making the website unavailable. This will usually be noticed quickly and the result may just be reputational damage.
Attacks on Webmail and Corporate VPN Servers While webmail and file-sharing services have become a vital tool for accessing emails and important documents on the go, these services can increase the possibility of a cyberattack on the surface.
For instance, a webmail hostname might get DNS-hijacked or hacked because of the vulnerability in the webmail software. Webmail and file-sharing and collaboration platforms can be compromised in credential-phishing attacks.
A well-prepared credential-phishing attack can be quite convincing, as when an actor registers a domain name can be quite convincing, as when an actor registers a domain name that resembles the legitimate webmail hostname, or when an actor creates a valid SSL certificate and chooses the targets within an organization carefully. The risk of webmail and third-party file-sharing services can be greatly reduced by requiring two factor authentication (preferably with a physical key) and corporate VPN access to these services.
Data leaks Data leaks have always been problematic. But the oil and gas industry is more susceptible to these threats because leaked information can be quite beneficial to a competitor. Data leaks can also cause substantial damage to a company’s reputation.
During our research, we easily found dozens of sensitive documents related to the oil industry online. One way of finding these documents is by using specially crafted Google queries, called Google Dorks.
Another way to find such content is to hunt for data on public services like Pastebin, an online service that allows anyone to copy and paste any text-based content and store it there, privately, or publicly. Another source of data is public sandboxes meant for analysis of suspicious files. Users can mistakenly send legitimate documents to these sandboxes for analysis. Once uploaded, these documents can be parsed or downloaded by third parties.
External emails In general, emails are well-protected inside companies. However, external emails cannot be controlled the same way. Employees regularly send emails to external addresses, hence some sensitive internal content ends up outside the company’s purview. Even worse, sensitive information can be copied to unsecured backup systems or stored locally on personal computers without standard corporate security protocols, which makes it easier for attackers to get hold of the information. Once a computer is compromised, an attacker can get the emails and use them in different ways to harm a company. For example, an actor could leak them on public servers or services like Pastebin.
In part two of our series, we look at additional threats that can compromise oil and gas companies, such as ransomware, malware, DNS tunneling, and zero-day exploits.
TA558 is a likely financially motivated small crime threat actor targeting hospitality, hotel, and travel organizations.
Since 2018, this group has used consistent tactics, techniques, and procedures to attempt to install a variety of malware including Loda RAT, Vjw0rm, and Revenge RAT.
TA558’s targeting focus is mainly on Portuguese and Spanish speakers, typically located in the Latin America region, with additional targeting observed in Western Europe and North America.
TA558 increased operational tempo in 2022 to a higher average than previously observed.
Like other threat actors in 2022, TA558 pivoted away from using macro-enabled documents in campaigns and adopted new tactics, techniques, and procedures.
Overview
Since 2018, Proofpoint has tracked a financially-motivated cybercrime actor, TA558, targeting hospitality, travel, and related industries located in Latin America and sometimes North America, and western Europe. The actor sends malicious emails written in Portuguese, Spanish, and sometimes English. The emails use reservation-themed lures with business-relevant themes such as hotel room bookings. The emails may contain malicious attachments or URLs aiming to distribute one of at least 15 different malware payloads, typically remote access trojans (RATs), that can enable reconnaissance, data theft, and distribution of follow-on payloads.
Proofpoint tracked this actor based on a variety of email artifacts, delivery and installation techniques, command and control (C2) infrastructure, payload domains, and other infrastructure.
In 2022, Proofpoint observed an increase in activity compared to previous years. Additionally, TA558 shifted tactics and began using URLs and container files to distribute malware, likely in response to Microsoft announcing it would begin blocking VBA macros downloaded from the internet by default.
TA558 has some overlap with activity reported by Palo Alto Networks in 2018, Cisco Talos in 2020 and 2021, Uptycs in 2020, and HP in 2022. This report is the first comprehensive, public report on TA558, detailing activity conducted over four years that is still ongoing. The information used in the creation of this report is based on email campaigns, which are manually contextualized, and analyst enriched descriptions of automatically condemned threats.
Campaign Details and Activity Timeline
2018
Proofpoint first observed TA558 in April 2018. These early campaigns typically used malicious Word attachments that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) or remote template URLs to download and install malware. Two of the most common malware payloads included Loda and Revenge RAT. Campaigns were conducted exclusively in Spanish and Portuguese and targeted the hospitality and related industries, with “reserva” (Portuguese word for “reservation”) themes. Example campaign:
The documents leveraged remote template URLs to download an additional RTF document, which then downloaded and installed Revenge RAT. Interestingly, the term “CDT” is in the document metadata and in the URL. This term, which may refer to a travel organization, appears throughout TA558 campaigns from 2018 to present.
In 2019, this actor continued to leverage emails with Word documents that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) to download and install malware. TA558 also began using macro-laden PowerPoint attachments and template injection with Office documents. This group expanded their malware arsenal to include Loda, vjw0rm, Revenge RAT, and others. In 2019, the group began occasionally expanding targeting outside of the hospitality and tourism verticals to include business services and manufacturing. Example campaign:
Figure 3: Example TA558 Microsoft Word attachment from 2019
The documents leveraged a remote template relationship URL to download an additional RTF document. The RTF document (Author: obidah qudah, Operator: Richard) exploited the CVE-2017-11882 vulnerability to retrieve and execute an MSI file. Upon execution, the MSI file extracted and ran Loda malware.
In December 2019, Proofpoint analysts observed TA558 begin to send English-language lures relating to room bookings in addition to Portuguese and Spanish.
2020
In 2020, TA558 stopped using Equation Editor exploits and began distributing malicious Office documents with macros, typically VBA macros, to download and install malware. This group continued to use a variety of malware payloads including the addition of njRAT and Ozone RAT.
Hotel, hospitality, and travel organization targeting continued. Although the actor slightly increased its English-language operational tempo throughout 2020, most of the lures featured Portuguese and Spanish reservation requests. An example of a common attack chain in 2020:
The message contained a PowerPoint attachment that used template injection techniques and VBA macros which, if enabled, executed a PowerShell script to download a VBS payload from an actor-controlled domain. The VBS script in turn downloaded and executed Revenge RAT.
Figure 5: 2020 attack path example
TA558 was more active in 2020 than previous years and 2021, with 74 campaigns identified. 2018, 2019, and 2021 had 9, 70, and 18 total campaigns, respectively. So far in 2022, Proofpoint analysts have observed 51 TA558 campaigns.
Figure 6: Total number of TA558 campaigns over time
2021
In 2021, this actor continued to leverage emails with Office documents containing macros or Office exploits (e.g. CVE-2017-8570) to download and install malware. Its most consistently used malware payloads included vjw0rm, njRAT, Revenge RAT, Loda, and AsyncRAT.
Additionally, this group started to include more elaborate attack chains in 2021. For example, introducing more helper scripts and delivery mechanisms such as embedded Office documents within MSG files.
In this example 2021 campaign, emails purported to be, e.g.:
Emails masqueraded as Unimed, a Brazilian medical work cooperative and health insurance operator. These messages contained Microsoft Word attachments with macros which, if enabled, invoked a series of scripts to ultimately download and execute AsyncRAT.
Figure 7: Example TA558 email from 2021
Of note is the repeat use of the string “CDT” contained the replyto email address and C2 domain names.
AsyncRAT C2 domains:
warzonecdt[.]duckdns[.]org
cdt2021.zapto[.]org
Example PowerShell execution to download and execute AsyncRAT:
This was the actor’s least active year. Proofpoint observed just 18 campaigns conducted by TA558 in 2021.
2022
In 2022, campaign tempo increased significantly. Campaigns delivered a mixture of malware such as, Loda, Revenge RAT, and AsyncRAT. This actor used a variety of delivery mechanisms including URLs, RAR attachments, ISO attachments, and Office documents.
TA558 followed the trend of many threat actors in 2022 and began using container files such as RAR and ISO attachments instead of macro-enabled Office documents. This is likely due to Microsoft’s announcements in late 2021 and early 2022 about disabling macros by default in Office products, which caused a shift across the threat landscape of actors adopting new filetypes to deliver payloads.
Additionally, TA558 began using URLs more frequently in 2022. TA558 conducted 27 campaigns with URLs in 2022, compared to just five campaigns total from 2018 through 2021. Typically, URLs led to container files such as ISOs or zip files containing executables.
Figure 8: Campaigns using specific threat types over time
For example, this 2022 Spanish language campaign featured URLs leading to container files. Messages purported to be, e.g.:
The URL purported to be a legitimate 155 Hotel reservation link that led to an ISO file and an embedded batch file. The execution of the BAT file led to a PowerShell helper script that downloaded a follow-on payload, AsyncRAT.
Similar to earlier campaigns, persistence was achieved via a scheduled task:
In April 2022 Proofpoint researchers spotted a divergence from the typical email lure. One of the campaigns included a QuickBooks invoice email lure. Additionally, this campaign included the distribution of RevengeRAT which had not been observed in use by TA558 since December 2020. Messages purported to be:
From: Intuit QuickBooks Team <quickbooks@unimed-corporated.com>
The emails contained Excel attachments with macros that downloaded helper scripts via PowerShell and MSHTA. The execution of helper scripts ultimately led to the installation of RevengeRAT. Proofpoint has not seen this theme since April, and it is unclear why TA558 temporarily pivoted away from reservations themes.
Malware Use
Since 2018, TA558 has used at least 15 different malware families, sometimes with overlapping command and control (C2) domains. The most frequently observed payloads include Loda, Vjw0rm, AsyncRAT, and Revenge RAT.
Figure 10: Number of TA558 campaigns by malware type over time
Typically, TA558 uses attacker owned and operated infrastructure. However, Proofpoint has observed TA558 leverage compromised hotel websites to host malware payloads, thus adding legitimacy to its malware delivery and C2 traffic.
Language Use
Since Proofpoint began tracking TA558 through 2022, over 90% of campaigns were conducted in Portuguese or Spanish, with four percent featuring multiple language lure samples in English, Spanish, or Portuguese.
Figure 11: Campaign totals by language since 2018
Interestingly, the threat actor often switches languages in the same week. Proofpoint researchers have observed this actor send, for example, a campaign in English and the following day another campaign in Portuguese. Individual targeting typically differs based on campaign language.
Notable Campaign Artifacts
In addition to the consistent lure themes, targeting, message content, and malware payloads, Proofpoint researchers observed TA558 using multiple notable patterns in campaign data including the use of certain strings, naming conventions and keywords, domains, etc. For example, the actor appears to repeat the term CDT in email and malware attributes. This may relate to the CDT Travel organization and related travel reservation lure themes. Proofpoint researchers observed TA558 use the CDT term in dozens of campaigns since 2018, in C2 domains, replyto email addresses, payload URLs, scheduled task name, and Microsoft Office document metadata (i.e., Author, Last Saved By), and Microsoft Office macro language.
Throughout many of the 2019 and 2020 campaigns the threat actor used various URLs from the domain sslblindado[.]com to download either helper scripts or malware payloads. Some examples include:
microsofft[.]sslblindado[.]com
passagensv[.]sslblindado[.]com
system11[.]sslblindado[.]com
Like other threat actors, this group sometimes mimics technology service names to appear legitimate. For example, using terms in payload URLs or C2 domain names. Some examples include:
microsofft[.]sslblindado[.]com
firefoxsystem[.]sytes[.]net
googledrives[.]ddns[.]net
Another interesting pattern observed were common strings like “success” and “pitbull”. In several campaigns Proofpoint researchers spotted these strings in C2 domains. Some examples include:
successfully[.]hopto[.]org
success20[.]hopto[.]org
4success[.]zapto[.]org
From 2019 through 2020, TA558 conducted 10 campaigns used the keyword “Maringa” or “Maaringa” in payload URLs or email senders. Maringa is a city in Brazil. Examples include:
maringareservas[.]com[.]br/seila[.]rtf
maringa[.]turismo@system11[.]com[.]br
Possible Objectives
Proofpoint has not observed post-compromise activity from TA558. Based on the observed payloads, victimology, and campaign and message volume, Proofpoint assesses with medium to high confidence that this is a financially motivated cybercriminal actor.
The malware used by TA558 can steal data including hotel customer user and credit card data, allow lateral movement, and deliver follow-on payloads.
Open-source reporting provides insight into one possible threat actor objective. In July, CNN Portugal reported a Portuguese hotel’s website was compromised, and the actor was able to modify the website and direct customers to a fake reservation page. The actor stole funds from potential customers by posing as the compromised hotel. Although Proofpoint does not associate the identified activity with TA558, it provides an example of possible follow-on activity and the impacts to both target organizations and their customers if an actor is able to compromise hotel or transportation entities.
Conclusion
TA558 is an active threat actor targeting hospitality, travel, and related industries since 2018. Activity conducted by this actor could lead to data theft of both corporate and customer data, as well as potential financial losses.
Organizations, especially those operating in targeted sectors in Latin America, North America, and Western Europe should be aware of this actor’s tactics, techniques, and procedures.
Indicators of Compromise (IOCs)
The following IOCs represent a sample of indicators observed by Proofpoint researchers associated with TA558.
