Google Workspace (formerly G Suite) now has stronger protections for risky account actions, automatically blocking hijacking attempts with identity verification prompts and logging them for further investigation.
This added layer of security will block threat actors who gain access to a user’s account to protect personal data and sensitive information belonging to their organization.
The enhanced account protection capabilities are available to all Google Workspace customers, including legacy G Suite Basic and Business customers.
“Google will evaluate the session attempting the action, and if it’s deemed risky, it will be challenged with a ‘Verify it’s You’ prompt,” Google said.
“Through a second and trusted factor, such as a 2-step verification code, users can confirm the validity of the action.”
For instance, this new feature would block sensitive actions such as attempts to change the account’s name until “the true account owner can verify that this was intentional.”
Admins can disable it for users stuck behind login prompts
Google added that admins could also temporarily disable login challenges triggered on sensitive account actions for users who can’t get past the verification prompts.
“In the Admin console under Users > ‘UserName’> Security, admins can toggle login challenges OFF for ten minutes if a user gets stuck behind a ‘verify it’s you prompt’,” the company explained.
“We strongly recommend only using this option if contact with the user is credibly established, such as via a video call.”
It’s also important to mention that this feature only supports users using Google as their identity provider, blocking actions taken within Google products, with SAML users not being supported now.
This update builds on a previous Google Workspace security improvement announced in June, with new alerts added to inform of critical and sensitive changes to admin accounts.
Google has further secured Workspace users from attacks by rolling out new Google Drive warning banners in January to warn them of potentially suspicious files used for malware delivery and phishing attacks.
A new large-scale phishing campaign targeting Coinbase, MetaMask, Kraken, and Gemini users is abusing Google Sites and Microsoft Azure Web App to create fraudulent sites.
These phishing pages are promoted through comments posted to legitimate sites by a network of bots controlled by the threat actors. Posting links to phishing pages on various legitimate sites aims to increase traffic and boost the malicious site’s search engine rankings.
Furthermore, because the phishing sites are hosted in Microsoft and Google services, they aren’t flagged by automated moderator systems, allowing promotional messages to stay in the comment section for longer.
Comment containing multiple links to phishing pages(Netskope)
The new campaign was spotted by analysts at Netskope, who noted that this tactic has allowed some of the fraudulent sites to appear as the first result in Google Search.
Even worse, as shown below, Google has also included the phishing pages as featured snippets, giving them the highest exposure possible in the search results.
The first result for the given search term(Netskope)
Abusing legitimate services
Google Sites is a free web page creation tool, part of Google’s online service suite, allowing users to create websites and host them on Google Cloud or other providers.
Similarly, Microsoft’s Azure Web Apps is a platform helping users create, deploy, and manage web applications and websites.
Both services are trusted by internet security tools, offer competitive pricing and high availability, so they are a good option for creating phishing pages.
The crooks in the campaign seen by Netskope created sites that mimicked Metamask, Coinbase, Gemini, and Kraken, targeting people’s wallets and their assets.
The sites are just landing pages, and their visitors are redirected to the actual phishing sites when they click on the “login” buttons.
Landing page for Kraken phishing(Netskope)
Targeting wallets and services
The phishing campaign is currently attempting to steal MetaMask wallets and credentials for crypto exchanges, such as CoinBase, Kraken, and Gemini.
The MetaMask phishing site attempts to steal the user’s password and wallet’s secret recovery phrase (seed phrase). This information allows the threat actor to import the wallet on their own devices and drain the contents.
MetaMask phishing site asking the seed phrase(Netskope)
For the crypto exchange phishing pages, the threat actors attempt to steal their login credentials.
In all four cases, users who enter their credentials are redirected to a fake 2FA (two-factor authentication) page that requests the victim to provide their phone number.
After entering the code, the websites generate a fake error alleging unauthorized activity and authentication problems, prompting the victim to click on an “Ask Expert” button.
Bogus error message served to victims(Netskope)
This takes the victims to an online chat page where a scammer pretending to be a customer support agent promises to solve the problem by directing the victim to install the TeamViewer remote access tool.
The remote access is likely to allow the threat actors to retrieve the multi-factor authentication codes required to log in to the exchanges with the stolen credentials.
Don’t get phished
When attempting to log in to a crypto exchange, always make sure you are on the platform’s official website and not on a clone.
Users of locally installed cryptocurrency wallets, such as MetaMask, Phantom, and TrustWallet, should never share their recovery phrase on any website, regardless of the reason.
It is also important to remember that Google Ads can be abused, and Google Search SEO can be manipulated, so the ranking of the results shouldn’t be seen as a guarantee of safety.
Finally, protect your cryptocurrency exchange accounts with MFA and keep most of your crypto investments on cold wallets that are much more challenging to hack.
There’s a well-worn industry phrase about the probability of a cyberattack: “It’s not a matter of if, but when.” Some of the incidents Sophos recently investigated may force the industry to consider changing this rule-of-thumb: The question is not if, or when – but how many times?
In an issue we highlighted in our Active Adversary Playbook 2022, we’re seeing organizations being hit by multiple attackers. Some attacks take place simultaneously; others are separated by a few days, weeks, or months. Some involve different kinds of malware, or double – even triple – infections of the same type.
Today, Sophos X-Ops is releasing our latest Active Adversary white paper: Multiple Attackers: A Clear and Present Danger. In the paper, we take a deep dive into the problem of multiple attackers, exploring how and why organizations are attacked several times. Recent case studies from our Managed Detection and Response (MDR) and Rapid Response (RR) teams provide insight into the how, and exploring cooperation and competition among threat actors helps explain the why.
Our key findings are:
The key drivers of multiple exploitations are vulnerabilities and misconfigurations going unaddressed after a first attack
Multiple attacks often involve a specific sequence of exploitation, especially after big, widespread vulnerabilities like ProxyLogon/ProxyShell are disclosed – with cryptominers arriving first, followed by wormable botnet builders, RATs, initial access brokers (IABs), and ransomware
While some threat actors are interdependent (e.g., IABs later enabling ransomware), others, such as cryptominers, try to terminate rival malware, and may even ‘close the door’ by patching vulnerabilities or disabling vulnerable services after gaining access
Historically, threat actors have been protective of their infections, to the extent of kicking rivals off compromised systems
Ransomware actors, despite occasionally tangling with each other, seem less concerned about competition, and sometimes adopt strategies which directly or indirectly benefit other groups
Certain features of the underground economy may enable multiple attacks – for instance, IABs reselling accesses, and ransomware leak sites providing data that other threat actors can later weaponize
Some of the case studies we analyze include a ransomware actor installing a backdoor which was later abused by a second ransomware group; and an incident where one organization was attacked by three ransomware groups in the space of a few weeks, all using the same misconfigured RDP server to gain access. After the dust had settled, Sophos discovered some files which had been encrypted by all three groups
At this stage there’s only anecdotal evidence to suggest that multiple attacks are on the rise, but, as Sophos’ Director of Incident Response, Peter Mackenzie, notes: “This is something we’re seeing affecting more and more organizations, and it’s likely due to an increasingly crowded market for threat actors, as well as ransomware-as-a-service (RaaS) becoming more professionalized and lowering the bar to entry.”
Key takeaways for organizations
Multiple attacks not only complicate incident response, but also place additional pressure on victims – whether that’s through more than one ransom demand, or just the sheer technical difficulty of trying to recover from two or more attacks in a short space of time.
In the white paper we provide best practice security guidance, as well as the following eight actionable takeaways to help organizations lower the risk of falling victim to multiple attackers:
Takeaway 1: Update absolutely everything It sounds simple, but: Update everything. One of our key findings is that cryptominers, and webshells and backdoors deployed by IABs, often come first when a vulnerability has been disclosed, and the latter typically try to operate stealthily – so you might think you’ve avoided an attack, when in fact there’s already malware on your system. That might be compounded (in a subsequent attack) by ransomware. Patching early is the best way to avoid being compromised in the future – but it doesn’t mean you haven’t already been attacked. It’s always worth checking that your organization wasn’t breached prior to patching.
Takeaway 2: Prioritize the worst bugs first But how can you patch early, and how do you know what to patch? Prioritizing can be a big ask, given how many vulnerabilities are disclosed (18,429 in 2021, more than 50 a day on average, and the greatest number of reported vulnerabilities ever disclosed during a calendar year). So focus on two key elements: 1) critical bugs affecting your specific software stack; and 2) high-profile vulnerabilities that could affect your technology. There are paid services which offer vulnerability intelligence, but there are also free tools which let you set up custom alerts for particular products. Bug Alert is a non-profit service that aims to give early warning of high impact bugs. Monitoring ‘infosec Twitter’ is also recommended, as that’s where many prominent vulnerabilities are discussed when first released. Or you could use CVE Trends, which collates data from several sites to show the most-talked-about vulnerabilities.
Takeaway 3: Mind your configurations Misconfigurations – and a failure to remediate them after an attack – are a leading cause of multiple exploitations. Cryptominer operators, IABs, and ransomware affiliates always look for exposed RDP and VPN ports, and they’re among the most popular listings on most criminal marketplaces. If you do need remote access and/or management over the internet, put it behind a VPN and/or a zero-trust network access solution that uses MFA as part of its login procedure.
Takeaway 4: Assume other attackers have found your vulnerabilities Threat actors don’t operate in isolation. IABs might resell or relist their products, and ransomware affiliates may use multiple strains – so one vulnerability or misconfiguration can lead to multiple threat actors seeking to exploit your network.
Takeaway 5: Don’t slow-walk addressing an attack in progress Being listed on a leak site may attract other, opportunistic threat actors. If you’re unfortunate enough to be hit with a ransomware attack, take immediate action, in conjunction with your security teams and incident response provider(s), to close the initial entry point and assess what data has been leaked, as part of your wider remediation plan.
Takeaway 6: Ransomware plays nicely with ransomware Many threat actors have traditionally been competitive, to the point of kicking each other off infected systems, and that’s still true today when it comes to cryptominers and some RATs. But ransomware doesn’t seem to follow this trend, and may proceed to encrypt files even if other ransomware groups are on the same network – or operate in a mutually beneficial way, so that one group exfiltrates and the other encrypts.
Takeaway 7: Attackers open new backdoors Some attackers may introduce further vulnerabilities after gaining access, or create deliberate or unintentional backdoors (including the installation of legitimate software), which a subsequent threat actor can exploit. So while it’s crucial to close off the initial infection vector, it’s also worth considering a) other weaknesses and misconfigurations that could be used to gain access, and b) any new ingress points that may have appeared.
Takeaway 8: Some attackers are worse than others Not all ransomware strains are equal. Some have capabilities and features that may complicate attempts to respond to and investigate others – another reason to try to avoid becoming a victim of multiple attacks.
Conclusion
In an increasingly crowded and competitive threat environment, the problem of multiple attackers is likely to grow, with more threat actors coming into the mix and exploiting the same targets – either deliberately or unintentionally.
For organizations, this means that rapidly responding to attacks, applying patches, fixing misconfigurations – and checking for backdoors which attackers might have installed prior to any entry points being closed – will become more and more important.
Multiple attackers are bad news for analysts and responders too, complicating incident response, threat intelligence, and security monitoring. In one of the case studies we explore in the report, for example, one ransomware group wiped Windows Event Logs – which not only deleted traces of that group’s activities, but also those of the two ransomware groups which had attacked the network previously. In another case study, one threat actor was likely an affiliate of two separate ransomware groups.
The threat actors themselves –particularly ransomware actors – will at some point have to decide how they feel about cooperation: whether to fully embrace it or become more competitive. Going forward, some groups might deliberately team up, so that one group’s tactics complement another’s. Or we might see ransomware become more like cryptominers – actively searching for, and terminating, rivals on infected hosts. At the moment, however, it’s an uncertain area – one which we hope our report will shed some light on.
After gaining access via RDP, all three threat actors encrypted files, in an investigation complicated by event log clearing and backups. 3 attackers, 2 weeks – 1 entry point.
In May 2022, an automotive supplier was hit with three separate ransomware attacks. All three threat actors abused the same misconfiguration – a firewall rule exposing Remote Desktop Protocol (RDP) on a management server – but used different ransomware strains and tactics.
The first ransomware group, identified as Lockbit, exfiltrated data to the Mega cloud storage service, used Mimikatz to extract passwords, and distributed their ransomware binary using PsExec.
The second group, identified as Hive, used RDP to move laterally, before dropping their ransomware just two hours after the Lockbit threat actor.
As the victim restored data from backups, an ALPHV/BlackCat affiliate accessed the network, installed Atera Agent (a legitimate remote access tool) to establish persistence, and exfiltrated data. Two weeks after the Lockbit and Hive attacks, the threat actor distributed their ransomware, and cleared Windows Event Logs. Sophos’ Rapid Response (RR) team investigated, and found several files which had been encrypted multiple times – as many as five in some instances.
Figure 1: Files which had been encrypted five times – twice each by Lockbit and Hive, and once by ALPHV/BlackCat
Figure 2: The multi-attacker timeline discovered by Sophos X-Ops
Figure 3: A brief overview of the three ransomware groups that consecutively attacked one organization
While the attacks took place in May, we discovered that a threat actor established an RDP session on the organization’s domain controller, way back in December 2021. This might have been an initial access broker (IAB) – an attacker who finds vulnerable systems and sells access to them on criminal marketplaces – or an early scouting mission by one of the three threat actors.
Either way, in mid-April 2022, a Lockbit affiliate gained RDP access to the organization’s corporate environment through an exposed management server.
Next, the threat actor moved laterally to a domain controller and other hosts, and began exfiltrating data to the Mega cloud storage service, as well as executing two PowerShell scripts: sharefinder.ps1 (to gather information about connected domain network shares) and invoke-mimikatz.ps1 (to extract passwords from LSASS, the Local Security Authority Subsystem Service).
On May 1st, the Lockbit affiliate created two batch scripts (1.bat and 2.bat) to distribute the ransomware binaries LockBit_AF51C0A7004B80EA.exe and Locker.exe across the network, via PsExec.
Figure 4: 1.bat script
Figure 5: 2.bat script
Upon execution, the ransomware encrypted files on nineteen hosts and dropped ransom notes entitled Restore-My-Files.txt.
Figure 6: The Lockbit ransom note
Two hours later, while the Lockbit threat actor was still encrypting files, a Hive ransomware affiliate gained access to the network via the same exposed RDP server and used RDP to move laterally to other hosts.
Hive used legitimate software (PDQ Deploy) already installed on the network to distribute its ransomware binary windows_x32_encrypt.exe. This tactic, known as ‘living off the land’, is popular among threat actors – particularly ransomware actors – as it has a small footprint and is less likely to be detected than downloading malicious tools.
Hive’s ransomware binary encrypted files on sixteen hosts and dropped a further ransom note, HOW_TO_DECRYPT.txt, on impacted devices.
Figure 7: The Hive ransom note
At this point, the organization’s IT team restored most of the infected systems to April 30, the day before the Lockbit threat actor began to encrypt files. From an investigative perspective, this meant some crucial evidence was lost. But the attacks were not over yet.
Only a day after that system restore, an ALPHV/BlackCat affiliate arrived, making RDP connections to domain controllers, file servers, application servers, and other hosts – all from the same management server exploited by Lockbit and Hive.
The ALPHV/BlackCat threat actor exfiltrated data to Mega over the course of a week, and established persistence by installing a backdoor: a legitimate remote access tool named Atera Agent. On May 15th – two weeks after the Lockbit and Hive attacks – the ALPHV/BlackCat affiliate used the credentials of a compromised user to drop ransomware binaries fXXX.exe and fXXXX.exe on six hosts, leaving a ransom note titled RECOVER-eprzzxl-FILES.txt in every folder.
Figure 8: The ALPHV/BlackCat ransom note
Based on analysis from SophosLabs researchers, these binaries not only encrypted files but also deleted volume shadow copies and Windows Event logs. This further complicated our subsequent investigation, as the ALPHV/BlackCat actor erased not only logs relating to their attack, but also those relating to the attacks by Lockbit and Hive.
It’s not clear why Lockbit and ALPHV/BlackCat deployed two ransomware binaries, but one possible reason is fault tolerance: If one executable is detected or blocked, or fails to encrypt, the second might act as a back-up.
Key features of the BlackCat ransomware binaries
The two BlackCat ransomware binaries, fXXX.exe and fXXXX.exe, have the following functionality:
Encrypt files and add the extension .eprzzxl
Collect Universally Unique IDs (UUIDs) from the impacted devices:
wmic csproduct get UUID
Enable Remote to Local and Remote to Remote symbolic link evaluations that allow easy access to files and folders in remote locations:
fsutil behavior set SymlinkEvaluation R2L:1
fsutil behavior set SymlinkEvaluation R2R:1
Modify a registry key to allow the maximum number of network requests by remote processes:
Disable Windows automatic repair on the impacted device
bcdedit /set {default} recoveryenabled No
Clear Windows Event logs
cmd.exe /c for /F \"tokens=*\" %1 in ('wevtutil.exe el') DO wevtutil.exe cl \"%1\"
The aftermath
After the dust had settled, Sophos’ RR team found files that had been encrypted by all three ransomware groups. In fact, as shown in the screenshot below, some files had even been encrypted five times! Because the Hive attack started 2 hours after Lockbit, the Lockbit ransomware was still running – so both groups kept finding files without the extension signifying that they were encrypted.
Figure 9: An example of quintuple-encrypted files
However, despite all three ransomware groups being known for ‘double extortion’ techniques (where, in addition to encrypting files, threat actors threaten to publish the victim’s data if the ransom is not paid), no information was published on any of the groups’ leak sites.
Several things complicated this investigation. The system restoration, BlackCat’s log-wiping, and a lack of DHCP logging all contrived to make piecing together the attacks extremely difficult. Despite these challenges, Sophos’ Rapid Response team was able to gather and analyze the evidence left behind.
When it comes to defense, there are two elements: proactive (following security best practices to minimize the risk of being attacked), and reactive (how to recover quickly and safely if an attack does happen).
Patch and investigate. Keep Windows and other software up to date (and consider setting up some vulnerability alerts, and monitoring in-the-know sources, to get a head start on breaking news about new bugs). This also means double-checking that patches have been installed correctly and are in place for critical systems like internet-facing machines or domain controllers. Patching early is the best way to avoid being compromised in the future – but it doesn’t mean that you haven’t already been attacked. It’s always worth investigating to ensure that your organization wasn’t breached prior to patching. Threat actors may leave backdoors (which may include the installation of legitimate software) or introduce new vulnerabilities, either deliberately or inadvertently, so this is a key thing for responders to look for to reduce the likelihood of a second attack.
Lock down accessible services. Perform scans of your organization’s network from the outside and identify and lock down the ports commonly used by VNC, RDP, or other remote-access tools. If a machine needs to be reachable using a remote management tool, put that tool behind a VPN or zero-trust network access solution that uses MFA as part of its login. It’s also worth remembering that attacks can happen more than once; if an access point remains open, other threat actors are likely to find and exploit it.
Practice segmentation and zero-trust. Separate critical servers from each other and from workstations by putting them into separate VLANs as you work towards a zero-trust network model.
Set and enforce strong passwords and multifactor authentication (MFA). Strong passwords serve as one of the first lines of defense. Passwords should be unique or complex and never re-used. This is easier to do if you provide staff with a password manager that can store their credentials. But even strong passwords can be compromised. Any form of multifactor authentication is better than none for securing access to critical resources such as e-mail, remote management tools, and network assets.
Inventory your assets and accounts. Unprotected and unpatched devices in the network increase risk and create a situation where malicious activities could pass unnoticed. It is vital to have a current inventory of all connected computers and IoT devices. Use network scans and physical checks to locate and catalog them.
Install layered protection to block attackers at as many points as possible. Extend that security to all endpoints that you allow onto your network.
But once threat actors are inside a network, there’s not much that can be done to ‘stop the bleeding’ without having comprehensive Incident Response and remediation plans, and taking immediate action. We’ve written a series of articles called ‘Hindsight security: Actions breach victims wish they had taken sooner’, which includes advice on securing RDP, enforcing MFA, setting up an incident response plan, and more. You can also request a copy of the Sophos Incident Response Guide here.
IOCs
Sophos X-Ops has posted IOCs relating to the Lockbit, Hive, and BlackCat attacks covered in this report on our Github repository.
Adding clarifying details on activity involving active directory.
Aug. 10th 2022
Update made to the Cisco Response and Recommendations section related to MFA.
EXECUTIVE SUMMARY
On May 24, 2022, Cisco became aware of a potential compromise. Since that point, Cisco Security Incident Response (CSIRT) and Cisco Talos have been working to remediate.
During the investigation, it was determined that a Cisco employee’s credentials were compromised after an attacker gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized.
The attacker conducted a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications initiated by the attacker. The attacker ultimately succeeded in achieving an MFA push acceptance, granting them access to VPN in the context of the targeted user.
CSIRT and Talos are responding to the event and we have not identified any evidence suggesting that the attacker gained access to critical internal systems, such as those related to product development, code signing, etc.
After obtaining initial access, the threat actor conducted a variety of activities to maintain access, minimize forensic artifacts, and increase their level of access to systems within the environment.
The threat actor was successfully removed from the environment and displayed persistence, repeatedly attempting to regain access in the weeks following the attack; however, these attempts were unsuccessful.
We assess with moderate to high confidence that this attack was conducted by an adversary that has been previously identified as an initial access broker (IAB) with ties to the UNC2447 cybercrime gang, Lapsus$ threat actor group, and Yanluowang ransomware operators.
For further information see the Cisco Response page here.
INITIAL VECTOR
Initial access to the Cisco VPN was achieved via the successful compromise of a Cisco employee’s personal Google account. The user had enabled password syncing via Google Chrome and had stored their Cisco credentials in their browser, enabling that information to synchronize to their Google account. After obtaining the user’s credentials, the attacker attempted to bypass multifactor authentication (MFA) using a variety of techniques, including voice phishing (aka “vishing”) and MFA fatigue, the process of sending a high volume of push requests to the target’s mobile device until the user accepts, either accidentally or simply to attempt to silence the repeated push notifications they are receiving. Vishing is an increasingly common social engineering technique whereby attackers try to trick employees into divulging sensitive information over the phone. In this instance, an employee reported that they received multiple calls over several days in which the callers – who spoke in English with various international accents and dialects – purported to be associated with support organizations trusted by the user.
Once the attacker had obtained initial access, they enrolled a series of new devices for MFA and authenticated successfully to the Cisco VPN. The attacker then escalated to administrative privileges, allowing them to login to multiple systems, which alerted our Cisco Security Incident Response Team (CSIRT), who subsequently responded to the incident. The actor in question dropped a variety of tools, including remote access tools like LogMeIn and TeamViewer, offensive security tools such as Cobalt Strike, PowerSploit, Mimikatz, and Impacket, and added their own backdoor accounts and persistence mechanisms.
POST-COMPROMISE TTPS
Following initial access to the environment, the threat actor conducted a variety of activities for the purposes of maintaining access, minimizing forensic artifacts, and increasing their level of access to systems within the environment.
Once on a system, the threat actor began to enumerate the environment, using common built-in Windows utilities to identify the user and group membership configuration of the system, hostname, and identify the context of the user account under which they were operating. We periodically observed the attacker issuing commands containing typographical errors, indicating manual operator interaction was occurring within the environment.
After establishing access to the VPN, the attacker then began to use the compromised user account to logon to a large number of systems before beginning to pivot further into the environment. They moved into the Citrix environment, compromising a series of Citrix servers and eventually obtained privileged access to domain controllers.
After obtaining access to the domain controllers, the attacker began attempting to dump NTDS from them using “ntdsutil.exe” consistent with the following syntax:
powershell ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\users\public' q q
They then worked to exfiltrate the dumped NTDS over SMB (TCP/445) from the domain controller to the VPN system under their control.
After obtaining access to credential databases, the attacker was observed leveraging machine accounts for privileged authentication and lateral movement across the environment.
Consistent with activity we previously observed in other separate but similar attacks, the adversary created an administrative user called “z” on the system using the built-in Windows “net.exe” commands. This account was then added to the local Administrators group. We also observed instances where the threat actor changed the password of existing local user accounts to the same value shown below. Notably, we have observed the creation of the “z” account by this actor in previous engagements prior to the Russian invasion of Ukraine.
C:\Windows\system32\net user z Lh199211* /add
C:\Windows\system32\net localgroup administrators z /add
This account was then used in some cases to execute additional utilities, such as adfind or secretsdump, to attempt to enumerate the directory services environment and obtain additional credentials. Additionally, the threat actor was observed attempting to extract registry information, including the SAM database on compromised windows hosts.
reg save hklm\system system
reg save hklm\sam sam
reg save HKLM\security sec
On some systems, the attacker was observed employing MiniDump from Mimikatz to dump LSASS.
tasklist | findstr lsass
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump [LSASS_PID] C:\windows\temp\lsass.dmp full
The attacker also took steps to remove evidence of activities performed on compromised systems by deleting the previously created local Administrator account. They also used the “wevtutil.exe” utility to identify and clear event logs generated on the system.
wevtutil.exe el
wevtutil.exe cl [LOGNAME]
In many cases, we observed the attacker removing the previously created local administrator account.
net user z /delete
To move files between systems within the environment, the threat actor often leveraged Remote Desktop Protocol (RDP) and Citrix. We observed them modifying the host-based firewall configurations to enable RDP access to systems.
netsh advfirewall firewall set rule group=remote desktop new enable=Yes
We also observed the installation of additional remote access tools, such as TeamViewer and LogMeIn.
The attacker frequently leveraged Windows logon bypass techniques to maintain the ability to access systems in the environment with elevated privileges. They frequently relied upon PSEXESVC.exe to remotely add the following Registry key values:
This enabled the attacker to leverage the accessibility features present on the Windows logon screen to spawn a SYSTEM level command prompt, granting them complete control of the systems. In several cases, we observed the attacker adding these keys but not further interacting with the system, possibly as a persistence mechanism to be used later as their primary privileged access is revoked.
Throughout the attack, we observed attempts to exfiltrate information from the environment. We confirmed that the only successful data exfiltration that occurred during the attack included the contents of a Box folder that was associated with a compromised employee’s account and employee authentication data from active directory. The Box data obtained by the adversary in this case was not sensitive.
In the weeks following the eviction of the attacker from the environment, we observed continuous attempts to re-establish access. In most cases, the attacker was observed targeting weak password rotation hygiene following mandated employee password resets. They primarily targeted users who they believed would have made single character changes to their previous passwords, attempting to leverage these credentials to authenticate and regain access to the Cisco VPN. The attacker was initially leveraging traffic anonymization services like Tor; however, after experiencing limited success, they switched to attempting to establish new VPN sessions from residential IP space using accounts previously compromised during the initial stages of the attack. We also observed the registration of several additional domains referencing the organization while responding to the attack and took action on them before they could be used for malicious purposes.
After being successfully removed from the environment, the adversary also repeatedly attempted to establish email communications with executive members of the organization but did not make any specific threats or extortion demands. In one email, they included a screenshot showing the directory listing of the Box data that was previously exfiltrated as described earlier. Below is a screenshot of one of the received emails. The adversary redacted the directory listing screenshot prior to sending the email.
BACKDOOR ANALYSIS
The actor dropped a series of payloads onto systems, which we continue to analyze. The first payload is a simple backdoor that takes commands from a command and control (C2) server and executes them on the end system via the Windows Command Processor. The commands are sent in JSON blobs and are standard for a backdoor. There is a “DELETE_SELF” command that removes the backdoor from the system completely. Another, more interesting, command, “WIPE”, instructs the backdoor to remove the last executed command from memory, likely with the intent of negatively impacting forensic analysis on any impacted hosts.
Commands are retrieved by making HTTP GET requests to the C2 server using the following structure:
/bot/cmd.php?botid=%.8x
The malware also communicates with the C2 server via HTTP GET requests that feature the following structure:
/bot/gate.php?botid=%.8x
Following the initial request from the infected system, the C2 server responds with a SHA256 hash. We observed additional requests made every 10 seconds.
The aforementioned HTTP requests are sent using the following user-agent string:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36 Edg/99.0.1150.36 Trailer/95.3.1132.33
The malware also creates a file called “bdata.ini” in the malware’s current working directory that contains a value derived from the volume serial number present on the infected system. In instances where this backdoor was executed, the malware was observed running from the following directory location:
C:\users\public\win\cmd.exe
The attacker was frequently observed staging tooling in directory locations under the Public user profile on systems from which they were operating.
Based upon analysis of C2 infrastructure associated with this backdoor, we assess that the C2 server was set up specifically for this attack.
ATTACK ATTRIBUTION
Based upon artifacts obtained, tactics, techniques, and procedures (TTPs) identified, infrastructure used, and a thorough analysis of the backdoor utilized in this attack, we assess with moderate to high confidence that this attack was conducted by an adversary that has been previously identified as an initial access broker (IAB) with ties to both UNC2447 and Lapsus$. IABs typically attempt to obtain privileged access to corporate network environments and then monetize that access by selling it to other threat actors who can then leverage it for a variety of purposes. We have also observed previous activity linking this threat actor to the Yanluowang ransomware gang, including the use of the Yanluowang data leak site for posting data stolen from compromised organizations.
UNC2447 is a financially-motivated threat actor with a nexus to Russia that has been previously observed conducting ransomware attacks and leveraging a technique known as “double extortion,” in which data is exfiltrated prior to ransomware deployment in an attempt to coerce victims into paying ransom demands. Prior reporting indicates that UNC2447 has been observed operating a variety of ransomware, including FIVEHANDS, HELLOKITTY, and more.
Apart from UNC2447, some of the TTPs discovered during the course of our investigation match those of the Lapsus$. Lapsus$ is a threat actor group that is reported to have been responsible for several previous notable breaches of corporate environments. Several arrests of Lapsus$ members were reported earlier this year. Lapsus$ has been observed compromising corporate environments and attempting to exfiltrate sensitive information.
While we did not observe ransomware deployment in this attack, the TTPs used were consistent with “pre-ransomware activity,” activity commonly observed leading up to the deployment of ransomware in victim environments. Many of the TTPs observed are consistent with activity observed by CTIR during previous engagements. Our analysis also suggests reuse of server-side infrastructure associated with these previous engagements as well. In previous engagements, we also did not observe deployment of ransomware in the victim environments.
CISCO RESPONSE AND RECOMMENDATIONS
Cisco implemented a company-wide password reset immediately upon learning of the incident. CTIR previously observed similar TTPs in numerous investigations since 2021. Our findings and subsequent security protections resulting from those customer engagements helped us slow and contain the attacker’s progression. We created two ClamAV signatures, which are listed below.
Win.Exploit.Kolobko-9950675-0
Win.Backdoor.Kolobko-9950676-0
Threat actors commonly use social engineering techniques to compromise targets, and despite the frequency of such attacks, organizations continue to face challenges mitigating those threats. User education is paramount in thwarting such attacks, including making sure employees know the legitimate ways that support personnel will contact users so that employees can identify fraudulent attempts to obtain sensitive information.
Given the actor’s demonstrated proficiency in using a wide array of techniques to obtain initial access, user education is also a key part of countering MFA bypass techniques. Equally important to implementing MFA is ensuring that employees are educated on what to do and how to respond if they get errant push requests on their respective phones. It is also essential to educate employees about who to contact if such incidents do arise to help determine if the event was a technical issue or malicious.
For Duo it is beneficial to implement strong device verification by enforcing stricter controls around device status to limit or block enrollment and access from unmanaged or unknown devices. Additionally, leveraging risk detection to highlight events like a brand-new device being used from unrealistic location or attack patterns like logins brute force can help detect unauthorized access.
Prior to allowing VPN connections from remote endpoints, ensure that posture checking is configured to enforce a baseline set of security controls. This ensures that the connecting devices match the security requirements present in the environment. This can also prevent rogue devices that have not been previously approved from connecting to the corporate network environment.
Network segmentation is another important security control that organizations should employ, as it provides enhanced protection for high-value assets and also enables more effective detection and response capabilities in situations where an adversary is able to gain initial access into the environment.
Centralized log collection can help minimize the lack of visibility that results when an attacker take active steps to remove logs from systems. Ensuring that the log data generated by endpoints is centrally collected and analyzed for anomalous or overtly malicious behavior can provide early indication when an attack is underway.
In many cases, threat actors have been observed targeting the backup infrastructure in an attempt to further remove an organization’s ability to recover following an attack. Ensuring that backups are offline and periodically tested can help mitigate this risk and ensure an organization’s ability to effectively recover following an attack.
Auditing of command line execution on endpoints can also provide increased visibility into actions being performed on systems in the environment and can be used to detect suspicious execution of built-in Windows utilities, which is commonly observed during intrusions where threat actors rely on benign applications or utilities already present in the environment for enumeration, privilege escalation, and lateral movement activities.
MITRE ATT&CK MAPPING
All of the previously described TTPs that were observed in this attack are listed below based on the phase of the attack in which they occurred.
Insufficiently protected open ports can put your IT environment at serious risk. Threat actors often seek to exploit open ports and their applications through spoofing, credential sniffing and other techniques. For example, in 2017, cybercriminals spread WannaCry ransomware by exploiting an SMB vulnerability on port 445. Other examples include the ongoing campaigns targeting Microsoft’s Remote Desktop Protocol (RDP) service running on port 3389.
Read on to learn more about the security risks linked to ports, vulnerable ports that need your attention and ways to enhance the security of open ports.
A Refresher on Ports
Ports are logical constructs that identify a specific type of network service. Each port is linked to a specific protocol, program or service, and has a port number for identification purposes. For instance, secured Hypertext Transfer Protocol (HTTPS) messages always go to port 443 on the server side, while port 1194 is exclusively for OpenVPN.
The most common transport protocols that have port numbers are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is a connection-oriented protocol with built-in re-transmission and error recovery. UDP is a connectionless protocol that doesn’t recover or correct errors in messages; it’s faster and has less network overhead traffic than TCP. Both TCP and UDP sit at the transport layer of the TCP/IP stack and use the IP protocol to address and route data on the internet. Software and services are designed to use TCP or UDP, depending on their requirements.
TCP and UDP ports are in one of these three states:
Open — The port responds to connection requests.
Closed — The port is unreachable, indicating that there is no corresponding service running.
Filtered — The firewall is monitoring traffic and blocking certain connection requests to the port.
Security Risks Linked to Ports
Numerous incidents have demonstrated that open ports are most vulnerable to attack when the services listening to them are unpatched or insufficiently protected or misconfigured, which can lead to compromised systems and networks. In these cases, threat actors can use open ports to perform various cyberattacks that exploit the lack of authentication mechanisms in the TCP and UDP protocols. One common example is spoofing, where a malicious actor impersonates a system or a service and sends malicious packets, often in combination with IP spoofing and man-in-the-middle-attacks. The campaign against RDP Pipe Plumbing is one of the latest to employ such a tactic. In addition, ports that have been opened on purpose (for instance, on a web server) can be attacked via that port using application-layer attacks such as SQL injection, cross-site request forgery and directory traversal.
Another common technique is the denial of service (DoS) attack, most frequently used in the form of distributed denial of service (DDoS), where attackers send massive numbers of connection requests from various machine to the service on the target in order to deplete its resources.
Vulnerable Ports that Need Your Attention
Any port can be targeted by threat actors, but some are more likely to fall prey to cyberattacks because they commonly have serious shortcomings, such as application vulnerabilities, lack of two-factor authentication and weak credentials.
Here are the most vulnerable ports regularly used in attacks:
Ports 20 and 21 (FTP)
Port 20 and (mainly) port 21 are File Transfer Protocol (FTP) ports that let users send and receive files from servers.
FTP is known for being outdated and insecure. As such, attackers frequently exploit it through:
Brute-forcing passwords
Anonymous authentication (it’s possible to log into the FTP port with “anonymous” as the username and password)
Cross-site scripting
Directory traversal attacks
Port 22 (SSH)
Port 22 is for Secure Shell (SSH). It’s a TCP port for ensuring secure access to servers. Hackers can exploit port 22 by using leaked SSH keys or brute-forcing credentials.
Port 23 (Telnet)
Port 23 is a TCP protocol that connects users to remote computers. For the most part, Telnet has been superseded by SSH, but it’s still used by some websites. Since it’s outdated and insecure, it’s vulnerable to many attacks, including credential brute-forcing, spoofing and credential sniffing.
Port 25 (SMTP)
Port 25 is a Simple Mail Transfer Protocol (SMTP) port for receiving and sending emails. Without proper configuration and protection, this TCP port is vulnerable to spoofing and spamming.
Port 53 (DNS)
Port 53 is for Domain Name System (DNS). It’s a UDP and TCP port for queries and transfers, respectively. This port is particularly vulnerable to DDoS attacks.
Ports 137 and 139 (NetBIOS over TCP) and 445 (SMB)
Server Message Block (SMB) uses port 445 directly and ports 137 and 139 indirectly. Cybercriminals can exploit these ports through:
Using the EternalBlue exploit, which takes advantage of SMBv1 vulnerabilities in older versions of Microsoft computers (hackers used EternalBlue on the SMB port to spread WannaCry ransomware in 2017)
Capturing NTLM hashes
Brute-forcing SMB login credentials
Ports 80, 443, 8080 and 8443 (HTTP and HTTPS)
HTTP and HTTPS are the hottest protocols on the internet, so they’re often targeted by attackers. They’re especially vulnerable to cross-site scripting, SQL injections, cross-site request forgeries and DDoS attacks.
Ports 1433,1434 and 3306 (Used by Databases)
These are the default ports for SQL Server and MySQL. They are used to distribute malware or are directly attacked in DDoS scenarios. Quite often, attackers probe these ports to find unprotected database with exploitable default configurations.
Port 3389 (Remote Desktop)
This port is used in conjunction with various vulnerabilities in remote desktop protocols and to probe for leaked or weak user authentication. Remote desktop vulnerabilities are currently the most-used attack type; one example is the BlueKeep vulnerability.
Tips for Strengthening the Security of Open Ports
Luckily, there are ways to enhance the security of open ports. We highly recommend the following six strategies:
1. Patch firewalls regularly.
Your firewall is the gatekeeper to all the other systems and services in your network. Patching keeps your firewalls up to date and repairs vulnerabilities and flaws in your firewall system that cybercriminals could use to gain full access to your systems and data.
2. Check ports regularly.
You should also regularly scan and check your ports. There are three main ways to do this:
Command-line tools — If you have the time to scan and check ports manually, use command-line tools to spot and scan open ports. Examples include Netstat and Network Mapper, both of which can be installed on a wide range of operating systems, including Windows and Linux.
Port scanners — If you want faster results, consider using a port scanner. It’s a computer program that checks if ports are open, closed or filtered. The process is simple: The scanner transmits a network request to connect to a specific port and captures the response.
Vulnerability scanning tools — Solutions of this type can also be used to discover ports that are open or configured with default passwords.
Track service configuration changes.
Many services on your network connect to various ports, so it is important to monitor the running states of installed services and continuously track changes to service configuration settings. Services can be vulnerable when they are unpatched or misconfigured.
Using Netwrix Change Tracker, you can harden your systems by tracking unauthorized changes and other suspicious activities. In particular, it provides the following functionality:
Actionable alerting about configuration changes
Automatic recording, analyzing, validating and verifying of every change
Real-time change monitoring
Constant application vulnerability monitoring
4. Use IDP and IPS tools.
Intrusion detection systems (IDS) and intrusion prevention systems (IPS) can help you prevent attackers from exploiting your ports. They monitor your network, spot possible cybersecurity incidents, log information about them and report the incidents to security administrators. IPS complements your firewalls by identifying suspicious incoming traffic and logging and blocking the attack.
5. Use SSH Keys.
Another option is to use SSH keys. These access credentials are more secure than passwords because decrypting SSH is very difficult, if not impossible. There are two types of SSH keys:
Private or identity keys, which identify users and give them access
Public or authorized keys, which determine who can access your system
You can use public-key cryptographic algorithms and key generation tools to create SSH keys.
6. Conduct penetration tests and vulnerability assessments.
Consider conducting penetration tests and vulnerability assessments to protect your ports. Although both of these techniques are used to spot vulnerabilities in IT infrastructure, they are quite different. Vulnerability scans only identify and report vulnerabilities, while penetration tests exploit security gaps to determine how attackers can gain unauthorized access to your system.
FAQs
What is an open port vulnerability?
An open port vulnerability is a security gap caused by an open port. Without proper configuration and protection, attackers can use open ports to access your systems and data.
Which ports are most vulnerable?
Certain ports and their applications are more likely to be targeted because they often have weaker credentials and defenses. Common vulnerable ports include:
FTP (20, 21)
SSH (22)
Telnet (23)
SMTP (25)
DNS (53)
NetBIOS over TCP (137, 139)
SMB (445)
HTTP and HTTPS (80, 443, 8080, 8443)
Ports 1433, 1434 and 3306
Remote desktop (3389)
Is port 80 a security risk?
Port 80 isn’t inherently a security risk. However, if you leave it open and don’t have the proper configurations in place, attackers can easily use it to access your systems and data. Unlike port 443 (HTTPS), port 80 is unencrypted, making it easy for cybercriminals to access, leak and tamper with sensitive data.
Upselling and cross-selling are tactics that you can use to sell more, with less—less time, less money, less resources. Simple as that. And both tactics can be applied to virtually every industry: software, retail, finance, telecom, manufacturing, real estate—you name it.
I run Tee Tweets, a clothing brand that lets you wear any tweet in the world, and cross-selling and upselling are two of the most important tactics in my business strategy. Both techniques are designed to get customers to buy more, and since there are hundreds of thousands of tweets generated every minute, I certainly have plenty of products for buyers to add to their cart.
Upselling and cross-selling are often confused because, in some ways, they accomplish the same goal of increasing the amount that a customer will buy. But there are distinct differences between the two, and if you can master them, they can both be uniquely instrumental to your business’s success.
What’s the difference?
Both cross-selling and upselling involve convincing an existing customer to increase the amount they’re buying. But here’s the difference:
When you’re cross-selling, you’re working specifically to get the customer to make additional purchases that would go well with what they originally intended to buy.
When you’re upselling, you’re not necessarily suggesting more items, but convincing the customer to buy the bigger, better, and more expensive version of their original purchase.
For example, when I send out marketing or confirmation emails to recent buyers, I make sure to include products that are similar to whatever that recipient bought. Often this results in a new sale, but even when it doesn’t, it still exposes the customer to other products they may not have known existed. That’s cross-selling.
There’s not as much upselling involved in TeeTweets, but I’ve come across plenty of upselling opportunities in my freelance consulting career at Swyftlight. I had one particular client who wanted me to build a simple marketing website, so they gave me their specs and budget and asked me to put together a proposal. I pitched the idea of adding eCommerce capabilities to their site, quoting them a rate that was still within their budget but was more than I would have quoted them for the simple site alone. They took me up on it—I effectively upsold them on a better version of their original product.
Those are two basic examples, but if you really want to make sure you’re capitalizing on every upselling and cross-selling opportunity you encounter, it’s important to understand both tactics in depth.
What is upselling?
Upselling is about upgrading the customer to a bigger or better version of the product or service they’re already buying. Virtually every modern business does some form of upselling, but one of the most common examples can be seen in an industry we all know and love: food.
Think specifically of the fast food industry, where customers are always encouraged to “supersize” the size of an item. Ordering small fries? Make it a large for only an extra 25 cents.
Upselling works in all industries, not just consumer-focused ones. If your business pays for software, for example, you’ve almost definitely seen upselling in action. Let’s take a look at Airtable.
Airtable’s pricing structure is laid out in such a way that you can see every plan’s capabilities all in one place. When you’re making your purchase, this page encourages you to stop and wonder: will 5,000 automation runs be enough? Will 5GB hold what I need?
As you’re contemplating how much you need, you’ll also notice that the prices don’t increase proportionately with the increase in services. The Pro plan costs twice as much as the Plus plan, but offers four times more attachment space and ten times more automation runs. When the higher overall price means a lower price-per-item, people are much more susceptible to being upsold.
Those are just two examples. Once you know what upselling looks like, you’ll start to notice it everywhere. More examples include:
Promoting a warranty when someone buys an appliance
Suggesting upgrading to a spa package when someone goes to book a massage
Offering more analytical accounting services in addition to your standard transitional bookkeeping services
When someone hires you to design their logo, proposing an entire branding package instead
Suggesting the fleece-lined version when someone’s about to buy leggings
What is cross-selling?
Cross-selling is about getting customers to buy different, related items in addition to what they’re already buying. The most effective cross-sellers pitch items that will enhance whatever the person is buying, or will make using that item much easier.
The most clear-cut example is Amazon. Whenever you’re looking at a product, if you scroll down, you’ll always see a “Customers also bought” section. Amazon also uses automated purchase history analysis to look at what you’ve bought in the past, find customers with similar buying habits, and suggest items that are popular among people who are looking for the same things you are.
Have a look at this small business in the candle game:
In this case, when you buy a relaxing candle, the site is going to recognize more types of relaxing candles. But cross-selling isn’t just about getting customers to buy more similar items right this moment—it’s also about exposing your customers to new products they might not be familiar with.
The most important thing to keep in mind is that while products you suggest don’t need to be extremely similar, they do need to be complementary. Cross-selling isn’t just about getting customers to buy more items right this moment—it’s about exposing your customers to new products and offerings they may not have seen before. When coupled with a purchase your customer is already set on buying, your brand exposure can have more significant weight than you might expect. You may not make the extra sale today, but you increase the likelihood that the customer comes back at some point down the line.
Upselling vs. cross-selling in action
One of the easiest ways to learn the difference between upselling and cross-selling is to look for examples of both within the same industry or even at the same company.
Let’s say you buy a new desk chair for your home office. The upsell would be a better, fancier chair with ergonomic features and fancy wheels. The cross-sell would be an under-desk mat, which you’ll need to keep those fancy wheels from tearing up the hardwood.
Applying upselling and cross-selling to your business
Upselling and cross-selling are both an art and a science. You need to think creatively about your offerings (and potential offerings) and how they might complement existing purchases. But you also need to dive into your analytics and make some data-driven decisions about what your customers are buying, when they’re buying them, and why. After all, upselling and cross-selling won’t do anything for you if no one actually buys what you’re promoting.
I’ve found that the most effective strategy when it comes to using upselling and cross-selling well is to reverse engineer what makes the most sense for your customers. What adds the most value for them? What questions do they have when buying from you? What products or services do they ask you about that you don’t yet offer? Talking directly to existing customers or clients about what they might want is a great place to start.
And remember: there’s always room to experiment. If people who buy product X often also buy product Y, you should absolutely be trying to sell product Y to everyone who buys product X. But don’t stop there. Try promoting product Z to those same people, or try upselling them to a higher quality version. Think outside the box, and you’ll find some creative ways to sell more—and better.
This article was originally published in March 2021 and was most recently updated in August 2022 with contributions from Amanda Pell.
Cloud communications company Twilio says some of its customers’ data was accessed by attackers who breached internal systems after stealing employee credentials in an SMS phishing attack.
“On August 4, 2022, Twilio became aware of unauthorized access to information related to a limited number of Twilio customer accounts through a sophisticated social engineering attack designed to steal employee credentials,” Twilio said over the weekend.
“The attackers then used the stolen credentials to gain access to some of our internal systems, where they were able to access certain customer data.”
The company also revealed the attackers gained access to its systems after tricking and stealing credentials from multiple employees targeted in the phishing incident.
To do that, they impersonated Twilio’s IT department, asking them to click URLs containing “Twilio,” “Okta,” and “SSO” keywords that would redirect them to a Twilio sign-in page clone.
The SMS phishing messages baited Twilio’s employees into clicking the embedded links by warning them that their passwords had expired or were scheduled to be changed.
Twilio’s EMEA Communications Director Katherine James declined to provide more information when asked how many employees had their accounts compromised in the phishing attack and how many customers were affected by the breach, saying the company has “no additional comment to provide at this time beyond what is posted in the blog.”
Twilio SMS phishing message (Twilio)
“The text messages originated from U.S. carrier networks. We worked with the U.S. carriers to shut down the actors and worked with the hosting providers serving the malicious URLs to shut those accounts down,” Twilio added.
“We have heard from other companies that they, too, were subject to similar attacks, and have coordinated our response to the threat actors – including collaborating with carriers to stop the malicious messages, as well as their registrars and hosting providers to shut down the malicious URLs. Despite this response, the threat actors have continued to rotate through carriers and hosting providers to resume their attacks.”
Credentials revoked, attackers yet to be identified
The company has not yet identified the attackers, but it’s working with law enforcement as part of an ongoing investigation.
Twilio revoked the employee accounts compromised during the attack to block the attackers’ access to its systems and has started notifying customers affected by this incident.
“As the threat actors were able to access a limited number of accounts’ data, we have been notifying the affected customers on an individual basis with the details,” Twilio also revealed.
The company also disclosed in May 2021 that it was impacted by last year’s Codecov supply-chain attack where threat actors modified the legitimate Codecov Bash Uploader tool to steal credentials, secret keys, and user tokens from Codecov customers.
With more than 5,000 employees in 26 offices in 17 countries, Twillio provides programmable voice, text, chat, video, and email APIs used by over 10 million developers and 150,000 businesses to build customer engagement platforms.
Twilio also acquired Authy in February 2015, a popular two-factor authentication (2FA) provider for end users, developers, and enterprises with millions of users worldwide.
As many as 29 different router models from DrayTek have been identified as affected by a new critical, unauthenticated remote code execution vulnerability that, if successfully exploited, could lead to full compromise of the devices and unauthorized access to the broader network.
“The attack can be performed without user interaction if the management interface of the device has been configured to be internet facing,” Trellix researcher Philippe Laulheret said. “A one-click attack can also be performed from within the LAN in the default device configuration.”
Filed under CVE-2022-32548, the vulnerability has received the maximum severity rating of 10.0 on the CVSS scoring system, owing to its ability to completely allow an adversary to seize control of the routers.
At its core, the shortcoming is the result of a buffer overflow flaw in the web management interface (“/cgi-bin/wlogin.cgi”), which can be weaponized by a malicious actor by supplying specially crafted input.
“The consequence of this attack is a takeover of the so-called ‘DrayOS’ that implements the router functionalities,” Laulheret said. “On devices that have an underlying Linux operating system (such as the Vigor 3910) it is then possible to pivot to the underlying operating system and establish a reliable foothold on the device and local network.”
Over 200,000 devices from the Taiwanese manufacturer are said to have the vulnerable service currently exposed on the internet and would require no user interaction to be exploited. Many of the remaining 500,000 devices, even when not exposed externally, are susceptible to one-click attacks.
The breach of a network appliance such as Vigor 3910 could not only leave a network open to malicious actions such as credential and intellectual property theft, botnet activity, or a ransomware attack, but also cause a denial-of-service (DoS) condition.
The disclosure comes a little over a month after it emerged that routers from ASUS, Cisco, DrayTek, and NETGEAR are under assault from a new malware called ZuoRAT targeting North American and European networks.
While there are no signs of exploitation of the vulnerability in the wild so far, it’s recommended to apply the firmware patches as soon as possible to secure against potential threats.
“Edge devices, such as the Vigor 3910 router, live on the boundary between internal and external networks,” Laulheret noted. “As such they are a prime target for cybercriminals and threat actors alike. Remotely breaching edge devices can lead to a full compromise of the businesses’ internal network.”
Twitter on Friday revealed that a now-patched zero-day bug was used to link phone numbers and emails to user accounts on the social media platform.
“As a result of the vulnerability, if someone submitted an email address or phone number to Twitter’s systems, Twitter’s systems would tell the person what Twitter account the submitted email addresses or phone number was associated with, if any,” the company said in an advisory.
Twitter said the bug, which it was made aware of in January 2022, stemmed from a code change introduced in June 2021. No passwords were exposed as a result of the incident.
The six-month delay in making this public stems from new evidence last month that an unidentified actor had potentially taken advantage of the flaw before the fix to scrape user information and sell it for profit on Breach Forums.
Although Twitter didn’t reveal the exact number of impacted users, the forum post made by the threat actor shows that the flaw was presumably exploited to compile a list containing allegedly over 5.48 million user account profiles.
Restore Privacy, which disclosed the breach late last month, said the database was being sold for $30,000.
Twitter stated it’s in the process of directly notifying account owners affected by the issue, while also urging users to turn on two-factor authentication to secure against unauthorized logins.
The development comes as Twitter, in May, agreed to pay a $150 million fine to settle a complaint from the U.S. Justice Department that alleged the company between 2014 and 2019 used information account holders provided for security verification for advertising purposes without their consent.
.png)
