Category: Vmware

Reflecting on the GDPR to celebrate Privacy Day 2024

26/01/2024
Emily Hancock

10 min read

This post is also available in Deutsch, Français, 日本語 and Nederlands.

Reflecting on the GDPR to celebrate Privacy Day 2024

Just in time for Data Privacy Day 2024 on January 28, the EU Commission is calling for evidence to understand how the EU’s General Data Protection Regulation (GDPR) has been functioning now that we’re nearing the 6th anniversary of the regulation coming into force.

We’re so glad they asked, because we have some thoughts. And what better way to celebrate privacy day than by discussing whether the application of the GDPR has actually done anything to improve people’s privacy?

The answer is, mostly yes, but in a couple of significant ways – no.

Overall, the GDPR is rightly seen as the global gold standard for privacy protection. It has served as a model for what data protection practices should look like globally, it enshrines data subject rights that have been copied across jurisdictions, and when it took effect, it created a standard for the kinds of privacy protections people worldwide should be able to expect and demand from the entities that handle their personal data. On balance, the GDPR has definitely moved the needle in the right direction for giving people more control over their personal data and in protecting their privacy.

In a couple of key areas, however, we believe the way the GDPR has been applied to data flowing across the Internet has done nothing for privacy and in fact may even jeopardize the protection of personal data. The first area where we see this is with respect to cross-border data transfers. Location has become a proxy for privacy in the minds of many EU data protection regulators, and we think that is the wrong result. The second area is an overly broad interpretation of what constitutes “personal data” by some regulators with respect to Internet Protocol or “IP” addresses. We contend that IP addresses should not always count as personal data, especially when the entities handling IP addresses have no ability on their own to tie those IP addresses to individuals. This is important because the ability to implement a number of industry-leading cybersecurity measures relies on the ability to do threat intelligence on Internet traffic metadata, including IP addresses.  

Location should not be a proxy for privacy

Fundamentally, good data security and privacy practices should be able to protect personal data regardless of where that processing or storage occurs. Nevertheless, the GDPR is based on the idea that legal protections should attach to personal data based on the location of the data – where it is generated, processed, or stored. Articles 44 to 49 establish the conditions that must be in place in order for data to be transferred to a jurisdiction outside the EU, with the idea that even if the data is in a different location, the privacy protections established by the GDPR should follow the data. No doubt this approach was influenced by political developments around government surveillance practices, such as the revelations in 2013 of secret documents describing the relationship between the US NSA (and its Five Eyes partners) and large Internet companies, and that intelligence agencies were scooping up data from choke points on the Internet. And once the GDPR took effect, many data regulators in the EU were of the view that as a result of the GDPR’s restrictions on cross-border data transfers, European personal data simply could not be processed in the United States in a way that would be consistent with the GDPR.

This issue came to a head in July 2020, when the European Court of Justice (CJEU), in its “Schrems II” decision1, invalidated the EU-US Privacy Shield adequacy standard and questioned the suitability of the EU standard contractual clauses (a mechanism entities can use to ensure that GDPR protections are applied to EU personal data even if it is processed outside the EU). The ruling in some respects left data protection regulators with little room to maneuver on questions of transatlantic data flows. But while some regulators were able to view the Schrems II ruling in a way that would still allow for EU personal data to be processed in the United States, other data protection regulators saw the decision as an opportunity to double down on their view that EU personal data cannot be processed in the US consistent with the GDPR, therefore promoting the misconception that data localization should be a proxy for data protection.

In fact, we would argue that the opposite is the case. From our own experience and according to recent research2, we know that data localization threatens an organization’s ability to achieve integrated management of cybersecurity risk and limits an entity’s ability to employ state-of-the-art cybersecurity measures that rely on cross-border data transfers to make them as effective as possible. For example, Cloudflare’s Bot Management product only increases in accuracy with continued use on the global network: it detects and blocks traffic coming from likely bots before feeding back learnings to the models backing the product. A diversity of signal and scale of data on a global platform is critical to help us continue to evolve our bot detection tools. If the Internet were fragmented – preventing data from one jurisdiction being used in another – more and more signals would be missed. We wouldn’t be able to apply learnings from bot trends in Asia to bot mitigation efforts in Europe, for example. And if the ability to identify bot traffic is hampered, so is the ability to block those harmful bots from services that process personal data.

The need for industry-leading cybersecurity measures is self-evident, and it is not as if data protection authorities don’t realize this. If you look at any enforcement action brought against an entity that suffered a data breach, you see data protection regulators insisting that the impacted entities implement ever more robust cybersecurity measures in line with the obligation GDPR Article 32 places on data controllers and processors to “develop appropriate technical and organizational measures to ensure a level of security appropriate to the risk”, “taking into account the state of the art”. In addition, data localization undermines information sharing within industry and with government agencies for cybersecurity purposes, which is generally recognized as vital to effective cybersecurity.

In this way, while the GDPR itself lays out a solid framework for securing personal data to ensure its privacy, the application of the GDPR’s cross-border data transfer provisions has twisted and contorted the purpose of the GDPR. It’s a classic example of not being able to see the forest for the trees. If the GDPR is applied in such a way as to elevate the priority of data localization over the priority of keeping data private and secure, then the protection of ordinary people’s data suffers.

Applying data transfer rules to IP addresses could lead to balkanization of the Internet

The other key way in which the application of the GDPR has been detrimental to the actual privacy of personal data is related to the way the term “personal data” has been defined in the Internet context – specifically with respect to Internet Protocol or “IP” addresses. A world where IP addresses are always treated as personal data and therefore subject to the GDPR’s data transfer rules is a world that could come perilously close to requiring a walled-off European Internet. And as noted above, this could have serious consequences for data privacy, not to mention that it likely would cut the EU off from any number of global marketplaces, information exchanges, and social media platforms.

This is a bit of a complicated argument, so let’s break it down. As most of us know, IP addresses are the addressing system for the Internet. When you send a request to a website, send an email, or communicate online in any way, IP addresses connect your request to the destination you’re trying to access. These IP addresses are the key to making sure Internet traffic gets delivered to where it needs to go. As the Internet is a global network, this means it’s entirely possible that Internet traffic – which necessarily contains IP addresses – will cross national borders. Indeed, the destination you are trying to access may well be located in a different jurisdiction altogether. That’s just the way the global Internet works. So far, so good.

But if IP addresses are considered personal data, then they are subject to data transfer restrictions under the GDPR. And with the way those provisions have been applied in recent years, some data regulators were getting perilously close to saying that IP addresses cannot transit jurisdictional boundaries if it meant the data might go to the US. The EU’s recent approval of the EU-US Data Privacy Framework established adequacy for US entities that certify to the framework, so these cross-border data transfers are not currently an issue. But if the Data Privacy Framework were to be invalidated as the EU-US Privacy Shield was in the Schrems II decision, then we could find ourselves in a place where the GDPR is applied to mean that IP addresses ostensibly linked to EU residents can’t be processed in the US, or potentially not even leave the EU.

If this were the case, then providers would have to start developing Europe-only networks to ensure IP addresses never cross jurisdictional boundaries. But how would people in the EU and US communicate if EU IP addresses can’t go to the US? Would EU citizens be restricted from accessing content stored in the US? It’s an application of the GDPR that would lead to the absurd result – one surely not intended by its drafters. And yet, in light of the Schrems II case and the way the GDPR has been applied, here we are.

A possible solution would be to consider that IP addresses are not always “personal data” subject to the GDPR. In 2016 – even before the GDPR took effect – the Court of Justice of the European Union (CJEU) established the view in Breyer v. Bundesrepublik Deutschland that even dynamic IP addresses, which change with every new connection to the Internet, constituted personal data if an entity processing the IP address could link the IP addresses to an individual. While the court’s decision did not say that dynamic IP addresses are always personal data under European data protection law, that’s exactly what EU data regulators took from the decision, without considering whether an entity actually has a way to tie the IP address to a real person3.

The question of when an identifier qualifies as “personal data” is again before the CJEU: In April 2023, the lower EU General Court ruled in SRB v EDPS4 that transmitted data can be considered anonymised and therefore not personal data if the data recipient does not have any additional information reasonably likely to allow it to re-identify the data subjects and has no legal means available to access such information. The appellant – the European Data Protection Supervisor (EDPS) – disagrees. The EDPS, who mainly oversees the privacy compliance of EU institutions and bodies, is appealing the decision and arguing that a unique identifier should qualify as personal data if that identifier could ever be linked to an individual, regardless of whether the entity holding the identifier actually had the means to make such a link.

If the lower court’s common-sense ruling holds, one could argue that IP addresses are not personal data when those IP addresses are processed by entities like Cloudflare, which have no means of connecting an IP address to an individual. If IP addresses are then not always personal data, then IP addresses will not always be subject to the GDPR’s rules on cross-border data transfers.

Although it may seem counterintuitive, having a standard whereby an IP address is not necessarily “personal data” would actually be a positive development for privacy. If IP addresses can flow freely across the Internet, then entities in the EU can use non-EU cybersecurity providers to help them secure their personal data. Advanced Machine Learning/predictive AI techniques that look at IP addresses to protect against DDoS attacks, prevent bots, or otherwise guard against personal data breaches will be able to draw on attack patterns and threat intelligence from around the world to the benefit of EU entities and residents. But none of these benefits can be realized in a world where IP addresses are always personal data under the GDPR and where the GDPR’s data transfer rules are interpreted to mean IP addresses linked to EU residents can never flow to the United States.

Keeping privacy in focus

On this Data Privacy Day, we urge EU policy makers to look closely at how the GDPR is working in practice, and to take note of the instances where the GDPR is applied in ways that place privacy protections above all other considerations – even appropriate security measures mandated by the GDPR’s Article 32 that take into account the state of the art of technology. When this happens, it can actually be detrimental to privacy. If taken to the extreme, this formulaic approach would not only negatively impact cybersecurity and data protection, but even put into question the functioning of the global Internet infrastructure as a whole, which depends on cross-border data flows. So what can be done to avert this?

First, we believe EU policymakers could adopt guidelines (if not legal clarification) for regulators that IP addresses should not be considered personal data when they cannot be linked by an entity to a real person. Second, policymakers should clarify that the GDPR’s application should be considered with the cybersecurity benefits of data processing in mind. Building on the GDPR’s existing recital 49, which rightly recognizes cybersecurity as a legitimate interest for processing, personal data that needs to be processed outside the EU for cybersecurity purposes should be exempted from GDPR restrictions to international data transfers. This would avoid some of the worst effects of the mindset that currently views data localization as a proxy for data privacy. Such a shift would be a truly pro-privacy application of the GDPR.

1 Case C-311/18, Data Protection Commissioner v Facebook Ireland and Maximillian Schrems.
2 Swire, Peter and Kennedy-Mayo, DeBrae and Bagley, Andrew and Modak, Avani and Krasser, Sven and Bausewein, Christoph, Risks to Cybersecurity from Data Localization, Organized by Techniques, Tactics, and Procedures (2023).
3 Different decisions by the European data protection authorities, namely the Austrian DSB (December 2021), the French CNIL (February 2022) and the Italian Garante (June 2022), while analyzing the use of Google Analytics, have rejected the relative approach used by the Breyer case and considered that an IP address should always be considered as personal data. Only the decision issued by the Spanish AEPD (December 2022) followed the same interpretation of the Breyer case. In addition, see paragraphs 109 and 136 in Guidelines by Supervisory Authorities for Tele-Media Providers, DSK (2021).
4 Single Resolution Board v EDPS, Court of Justice of the European Union, April 2023.

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

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

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

Source :
https://blog.cloudflare.com/reflecting-on-the-gdpr-to-celebrate-privacy-day-2024/

Thanksgiving 2023 security incident

01/02/2024
Matthew Prince John Graham-Cumming Grant Bourzikas

11 min read

On Thanksgiving Day, November 23, 2023, Cloudflare detected a threat actor on our self-hosted Atlassian server. Our security team immediately began an investigation, cut off the threat actor’s access, and on Sunday, November 26, we brought in CrowdStrike’s Forensic team to perform their own independent analysis.

Yesterday, CrowdStrike completed its investigation, and we are publishing this blog post to talk about the details of this security incident.

We want to emphasize to our customers that no Cloudflare customer data or systems were impacted by this event. Because of our access controls, firewall rules, and use of hard security keys enforced using our own Zero Trust tools, the threat actor’s ability to move laterally was limited. No services were implicated, and no changes were made to our global network systems or configuration. This is the promise of a Zero Trust architecture: it’s like bulkheads in a ship where a compromise in one system is limited from compromising the whole organization.

From November 14 to 17, a threat actor did reconnaissance and then accessed our internal wiki (which uses Atlassian Confluence) and our bug database (Atlassian Jira). On November 20 and 21, we saw additional access indicating they may have come back to test access to ensure they had connectivity.

They then returned on November 22 and established persistent access to our Atlassian server using ScriptRunner for Jira, gained access to our source code management system (which uses Atlassian Bitbucket), and tried, unsuccessfully, to access a console server that had access to the data center that Cloudflare had not yet put into production in São Paulo, Brazil.

They did this by using one access token and three service account credentials that had been taken, and that we failed to rotate, after the Okta compromise of October 2023. All threat actor access and connections were terminated on November 24 and CrowdStrike has confirmed that the last evidence of threat activity was on November 24 at 10:44.

(Throughout this blog post all dates and times are UTC.)

Even though we understand the operational impact of the incident to be extremely limited, we took this incident very seriously because a threat actor had used stolen credentials to get access to our Atlassian server and accessed some documentation and a limited amount of source code. Based on our collaboration with colleagues in the industry and government, we believe that this attack was performed by a nation state attacker with the goal of obtaining persistent and widespread access to Cloudflare’s global network.

“Code Red” Remediation and Hardening Effort

On November 24, after the threat actor was removed from our environment, our security team pulled in all the people they needed across the company to investigate the intrusion and ensure that the threat actor had been completely denied access to our systems, and to ensure we understood the full extent of what they accessed or tried to access.

Then, from November 27, we redirected the efforts of a large part of the Cloudflare technical staff (inside and outside the security team) to work on a single project dubbed “Code Red”. The focus was strengthening, validating, and remediating any control in our environment to ensure we are secure against future intrusion and to validate that the threat actor could not gain access to our environment. Additionally, we continued to investigate every system, account and log to make sure the threat actor did not have persistent access and that we fully understood what systems they had touched and which they had attempted to access.

CrowdStrike performed an independent assessment of the scope and extent of the threat actor’s activity, including a search for any evidence that they still persisted in our systems. CrowdStrike’s investigation provided helpful corroboration and support for our investigation, but did not bring to light any activities that we had missed. This blog post outlines in detail everything we and CrowdStrike uncovered about the activity of the threat actor.

The only production systems the threat actor could access using the stolen credentials was our Atlassian environment. Analyzing the wiki pages they accessed, bug database issues, and source code repositories, it appears they were looking for information about the architecture, security, and management of our global network; no doubt with an eye on gaining a deeper foothold. Because of that, we decided a huge effort was needed to further harden our security protocols to prevent the threat actor from being able to get that foothold had we overlooked something from our log files.

Our aim was to prevent the attacker from using the technical information about the operations of our network as a way to get back in. Even though we believed, and later confirmed, the attacker had limited access, we undertook a comprehensive effort to rotate every production credential (more than 5,000 individual credentials), physically segment test and staging systems, performed forensic triages on 4,893 systems, reimaged and rebooted every machine in our global network including all the systems the threat actor accessed and all Atlassian products (Jira, Confluence, and Bitbucket).

The threat actor also attempted to access a console server in our new, and not yet in production, data center in São Paulo. All attempts to gain access were unsuccessful. To ensure these systems are 100% secure, equipment in the Brazil data center was returned to the manufacturers. The manufacturers’ forensic teams examined all of our systems to ensure that no access or persistence was gained. Nothing was found, but we replaced the hardware anyway.

We also looked for software packages that hadn’t been updated, user accounts that might have been created, and unused active employee accounts; we went searching for secrets that might have been left in Jira tickets or source code, examined and deleted all HAR files uploaded to the wiki in case they contained tokens of any sort. Whenever in doubt, we assumed the worst and made changes to ensure anything the threat actor was able to access would no longer be in use and therefore no longer be valuable to them.

Every member of the team was encouraged to point out areas the threat actor might have touched, so we could examine log files and determine the extent of the threat actor’s access. By including such a large number of people across the company, we aimed to leave no stone unturned looking for evidence of access or changes that needed to be made to improve security.

The immediate “Code Red” effort ended on January 5, but work continues across the company around credential management, software hardening, vulnerability management, additional alerting, and more.

Attack timeline

The attack started in October with the compromise of Okta, but the threat actor only began targeting our systems using those credentials from the Okta compromise in mid-November.

The following timeline shows the major events:

October 18 – Okta compromise

We’ve written about this before but, in summary, we were (for the second time) the victim of a compromise of Okta’s systems which resulted in a threat actor gaining access to a set of credentials. These credentials were meant to all be rotated.

Unfortunately, we failed to rotate one service token and three service accounts (out of thousands) of credentials that were leaked during the Okta compromise.

One was a Moveworks service token that granted remote access into our Atlassian system. The second credential was a service account used by the SaaS-based Smartsheet application that had administrative access to our Atlassian Jira instance, the third account was a Bitbucket service account which was used to access our source code management system, and the fourth was an AWS environment that had no access to the global network and no customer or sensitive data.

The one service token and three accounts were not rotated because mistakenly it was believed they were unused. This was incorrect and was how the threat actor first got into our systems and gained persistence to our Atlassian products. Note that this was in no way an error on the part of Atlassian, AWS, Moveworks or Smartsheet. These were merely credentials which we failed to rotate.

November 14 09:22:49 – threat actor starts probing

Our logs show that the threat actor started probing and performing reconnaissance of our systems beginning on November 14, looking for a way to use the credentials and what systems were accessible. They attempted to log into our Okta instance and were denied access. They attempted access to the Cloudflare Dashboard and were denied access.

Additionally, the threat actor accessed an AWS environment that is used to power the Cloudflare Apps marketplace. This environment was segmented with no access to global network or customer data. The service account to access this environment was revoked, and we validated the integrity of the environment.

November 15 16:28:38 – threat actor gains access to Atlassian services

The threat actor successfully accessed Atlassian Jira and Confluence on November 15 using the Moveworks service token to authenticate through our gateway, and then they used the Smartsheet service account to gain access to the Atlassian suite. The next day they began looking for information about the configuration and management of our global network, and accessed various Jira tickets.

The threat actor searched the wiki for things like remote access, secret, client-secret, openconnect, cloudflared, and token. They accessed 36 Jira tickets (out of a total of 2,059,357 tickets) and 202 wiki pages (out of a total of 194,100 pages).

The threat actor accessed Jira tickets about vulnerability management, secret rotation, MFA bypass, network access, and even our response to the Okta incident itself.

The wiki searches and pages accessed suggest the threat actor was very interested in all aspects of access to our systems: password resets, remote access, configuration, our use of Salt, but they did not target customer data or customer configurations.

November 16 14:36:37 – threat actor creates an Atlassian user account

The threat actor used the Smartsheet credential to create an Atlassian account that looked like a normal Cloudflare user. They added this user to a number of groups within Atlassian so that they’d have persistent access to the Atlassian environment should the Smartsheet service account be removed.

November 17 14:33:52 to November 20 09:26:53 – threat actor takes a break from accessing Cloudflare systems

During this period, the attacker took a break from accessing our systems (apart from apparently briefly testing that they still had access) and returned just before Thanksgiving.

November 22 14:18:22 – threat actor gains persistence

Since the Smartsheet service account had administrative access to Atlassian Jira, the threat actor was able to install the Sliver Adversary Emulation Framework, which is a widely used tool and framework that red teams and attackers use to enable “C2” (command and control), connectivity gaining persistent and stealthy access to a computer on which it is installed. Sliver was installed using the ScriptRunner for Jira plugin.

This allowed them continuous access to the Atlassian server, and they used this to attempt lateral movement. With this access the Threat Actor attempted to gain access to a non-production console server in our São Paulo, Brazil data center due to a non-enforced ACL. The access was denied, and they were not able to access any of the global network.

Over the next day, the threat actor viewed 120 code repositories (out of a total of 11,904 repositories). Of the 120, the threat actor used the Atlassian Bitbucket git archive feature on 76 repositories to download them to the Atlassian server, and even though we were not able to confirm whether or not they had been exfiltrated, we decided to treat them as having been exfiltrated.

The 76 source code repositories were almost all related to how backups work, how the global network is configured and managed, how identity works at Cloudflare, remote access, and our use of Terraform and Kubernetes. A small number of the repositories contained encrypted secrets which were rotated immediately even though they were strongly encrypted themselves.

We focused particularly on these 76 source code repositories to look for embedded secrets, (secrets stored in the code were rotated), vulnerabilities and ways in which an attacker could use them to mount a subsequent attack. This work was done as a priority by engineering teams across the company as part of “Code Red”.

As a SaaS company, we’ve long believed that our source code itself is not as precious as the source code of software companies that distribute software to end users. In fact, we’ve open sourced a large amount of our source code and speak openly through our blog about algorithms and techniques we use. So our focus was not on someone having access to the source code, but whether that source code contained embedded secrets (such as a key or token) and vulnerabilities.

November 23 – Discovery and threat actor access termination begins

Our security team was alerted to the threat actor’s presence at 16:00 and deactivated the Smartsheet service account 35 minutes later. 48 minutes later the user account created by the threat actor was found and deactivated. Here’s the detailed timeline for the major actions taken to block the threat actor once the first alert was raised.

15:58 – The threat actor adds the Smartsheet service account to an administrator group.
16:00 – Automated alert about the change at 15:58 to our security team.
16:12 – Cloudflare SOC starts investigating the alert.
16:35 – Smartsheet service account deactivated by Cloudflare SOC.
17:23 – The threat actor-created Atlassian user account is found and deactivated.
17:43 – Internal Cloudflare incident declared.
21:31 – Firewall rules put in place to block the threat actor’s known IP addresses.

November 24 – Sliver removed; all threat actor access terminated

10:44 – Last known threat actor activity.
11:59 – Sliver removed.

Throughout this timeline, the threat actor tried to access a myriad of other systems at Cloudflare but failed because of our access controls, firewall rules, and use of hard security keys enforced using our own Zero Trust tools.

To be clear, we saw no evidence whatsoever that the threat actor got access to our global network, data centers, SSL keys, customer databases or configuration information, Cloudflare Workers deployed by us or customers, AI models, network infrastructure, or any of our datastores like Workers KV, R2 or Quicksilver. Their access was limited to the Atlassian suite and the server on which our Atlassian runs.

A large part of our “Code Red” effort was understanding what the threat actor got access to and what they tried to access. By looking at logging across systems we were able to track attempted access to our internal metrics, network configuration, build system, alerting systems, and release management system. Based on our review, none of their attempts to access these systems were successful. Independently, CrowdStrike performed an assessment of the scope and extent of the threat actor’s activity, which did not bring to light activities that we had missed and concluded that the last evidence of threat activity was on November 24 at 10:44.

We are confident that between our investigation and CrowdStrike’s, we fully understand the threat actor’s actions and that they were limited to the systems on which we saw their activity.

Conclusion

This was a security incident involving a sophisticated actor, likely a nation-state, who operated in a thoughtful and methodical manner. The efforts we have taken ensure that the ongoing impact of the incident was limited and that we are well-prepared to fend off any sophisticated attacks in the future. This required the efforts of a significant number of Cloudflare’s engineering staff, and, for over a month, this was the highest priority at Cloudflare. The entire Cloudflare team worked to ensure that our systems were secure, the threat actor’s access was understood, to remediate immediate priorities (such as mass credential rotation), and to build a plan of long-running work to improve our overall security based on areas for improvement discovered during this process.

We are incredibly grateful to everyone at Cloudflare who responded quickly over the Thanksgiving holiday to conduct an initial analysis and lock out the threat actor, and all those who contributed to this effort. It would be impossible to name everyone involved, but their long hours and dedicated work made it possible to undertake an essential review and change of Cloudflare’s security while keeping our global network running and our customers’ service running.

We are grateful to CrowdStrike for having been available immediately to conduct an independent assessment. Now that their final report is complete, we are confident in our internal analysis and remediation of the intrusion and are making this blog post available.

IOCs
Below are the Indications of Compromise (IOCs) that we saw from this threat actor. We are publishing them so that other organizations, and especially those that may have been impacted by the Okta breach, can search their logs to confirm the same threat actor did not access their systems.

IndicatorIndicator TypeSHA256Description
193.142.58[.]126IPv4N/APrimary threat actor
Infrastructure, owned by
M247 Europe SRL (Bucharest,
Romania)
198.244.174[.]214IPv4N/ASliver C2 server, owned by
OVH SAS (London, England)
idowall[.]comDomainN/AInfrastructure serving Sliver
payload
jvm-agentFilenamebdd1a085d651082ad567b03e5186d1d4
6d822bb7794157ab8cce95d850a3caaf		Sliver payload

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

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

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

Source :
https://blog.cloudflare.com/thanksgiving-2023-security-incident

AnyDesk says hackers breached its production servers, reset passwords

By Lawrence Abrams
February 2, 2024

AnyDesk confirmed today that it suffered a recent cyberattack that allowed hackers to gain access to the company’s production systems. BleepingComputer has learned that source code and private code signing keys were stolen during the attack.

AnyDesk is a remote access solution that allows users to remotely access computers over a network or the internet. The program is very popular with the enterprise, which use it for remote support or to access colocated servers.

The software is also popular among threat actors who use it for persistent access to breached devices and networks.

The company reports having 170,000 customers, including 7-Eleven, Comcast, Samsung, MIT, NVIDIA, SIEMENS, and the United Nations.

AnyDesk hacked

In a statement shared with BleepingComputer late Friday afternoon, AnyDesk says they first learned of the attack after detecting indications of an incident on their production servers. 

After conducting a security audit, they determined their systems were compromised and activated a response plan with the help of cybersecurity firm CrowdStrike.

AnyDesk did not share details on whether data was stolen during the attack. However, BleepingComputer has learned that the threat actors stole source code and code signing certificates.

The company also confirmed ransomware was not involved but didn’t share too much information about the attack other than saying their servers were breached, with the advisory mainly focusing on how they responded to the incident.

As part of their response, AnyDesk says they have revoked security-related certificates and remediated or replaced systems as necessary. They also reassured customers that AnyDesk was safe to use and that there was no evidence of end-user devices being affected by the incident.

“We can confirm that the situation is under control and it is safe to use AnyDesk. Please ensure that you are using the latest version, with the new code signing certificate,” AnyDesk said in a public statement.

While the company says that no authentication tokens were stolen, out of caution, AnyDesk is revoking all passwords to their web portal and suggests changing the password if it’s used on other sites.

“AnyDesk is designed in a way which session authentication tokens cannot be stolen. They only exist on the end user’s device and are associated with the device fingerprint. These tokens never touch our systems, “AnyDesk told BleepingComputer in response to our questions about the attack.

“We have no indication of session hijacking as to our knowledge this is not possible.”

The company has already begun replacing stolen code signing certificates, with Günter Born of BornCity first reporting that they are using a new certificate in AnyDesk version 8.0.8, released on January 29th. The only listed change in the new version is that the company switched to a new code signing certificate and will revoke the old one soon.

BleepingComputer looked at previous versions of the software, and the older executables were signed under the name ‘philandro Software GmbH’ with serial number 0dbf152deaf0b981a8a938d53f769db8. The new version is now signed under ‘AnyDesk Software GmbH,’ with a serial number of 0a8177fcd8936a91b5e0eddf995b0ba5, as shown below.

Signed AnyDesk 8.0.6 (left) vs AnyDesk 8.0.8 (right)
Signed AnyDesk 8.0.6 (left) vs AnyDesk 8.0.8 (right)
Source: BleepingComputer

Certificates are usually not invalidated unless they have been compromised, such as being stolen in attacks or publicly exposed.

While AnyDesk had not shared when the breach occurred, Born reported that AnyDesk suffered a four-day outage starting on January 29th, during which the company disabled the ability to log in to the AnyDesk client.

“my.anydesk II is currently undergoing maintenance, which is expected to last for the next 48 hours or less,” reads the AnyDesk status message page.

“You can still access and use your account normally. Logging in to the AnyDesk client will be restored once the maintenance is complete.”

Yesterday, access was restored, allowing users to log in to their accounts, but AnyDesk did not provide any reason for the maintenance in the status updates.

However, AnyDesk has confirmed to BleepingComputer that this maintenance is related to the cybersecurity incident.

It is strongly recommended that all users switch to the new version of the software, as the old code signing certificate will soon be revoked.

Furthermore, while AnyDesk says that passwords were not stolen in the attack, the threat actors did gain access to production systems, so it is strongly advised that all AnyDesk users change their passwords. Furthermore, if they use their AnyDesk password at other sites, they should be changed there as well.

Every week, it feels like we learn of a new breach against well-known companies.

Last night, Cloudflare disclosed that they were hacked on Thanksgiving using authentication keys stolen during last years Okta cyberattack.

Last week, Microsoft also revealed that they were hacked by Russian state-sponsored hackers named Midnight Blizzard, who also attacked HPE in May.

Related Articles:

GTA 5 source code reportedly leaked online a year after Rockstar hack

Lurie Children’s Hospital took systems offline after cyberattack

Johnson Controls says ransomware attack cost $27 million, data stolen

A mishandled GitHub token exposed Mercedes-Benz source code

How SMBs can lower their risk of cyberattacks and data breaches

Source :
https://www.bleepingcomputer.com/news/security/anydesk-says-hackers-breached-its-production-servers-reset-passwords/

DDoS threat report for 2023 Q4

09/01/2024
Omer Yoachimik – Jorge Pacheco

Welcome to the sixteenth edition of Cloudflare’s DDoS Threat Report. This edition covers DDoS trends and key findings for the fourth and final quarter of the year 2023, complete with a review of major trends throughout the year.

What are DDoS attacks?

DDoS attacks, or distributed denial-of-service attacks, are a type of cyber attack that aims to disrupt websites and online services for users, making them unavailable by overwhelming them with more traffic than they can handle. They are similar to car gridlocks that jam roads, preventing drivers from getting to their destination.

There are three main types of DDoS attacks that we will cover in this report. The first is an HTTP request intensive DDoS attack that aims to overwhelm HTTP servers with more requests than they can handle to cause a denial of service event. The second is an IP packet intensive DDoS attack that aims to overwhelm in-line appliances such as routers, firewalls, and servers with more packets than they can handle. The third is a bit-intensive attack that aims to saturate and clog the Internet link causing that ‘gridlock’ that we discussed. In this report, we will highlight various techniques and insights on all three types of attacks.

Previous editions of the report can be found here, and are also available on our interactive hub, Cloudflare Radar. Cloudflare Radar showcases global Internet traffic, attacks, and technology trends and insights, with drill-down and filtering capabilities for zooming in on insights of specific countries, industries, and service providers. Cloudflare Radar also offers a free API allowing academics, data sleuths, and other web enthusiasts to investigate Internet usage across the globe.

To learn how we prepare this report, refer to our Methodologies.

Key findings

  1. In Q4, we observed a 117% year-over-year increase in network-layer DDoS attacks, and overall increased DDoS activity targeting retail, shipment and public relations websites during and around Black Friday and the holiday season.
  2. In Q4, DDoS attack traffic targeting Taiwan registered a 3,370% growth, compared to the previous year, amidst the upcoming general election and reported tensions with China. The percentage of DDoS attack traffic targeting Israeli websites grew by 27% quarter-over-quarter, and the percentage of DDoS attack traffic targeting Palestinian websites grew by 1,126% quarter-over-quarter — as the military conflict between Israel and Hamas continues.
  3. In Q4, there was a staggering 61,839% surge in DDoS attack traffic targeting Environmental Services websites compared to the previous year, coinciding with the 28th United Nations Climate Change Conference (COP 28).

For an in-depth analysis of these key findings and additional insights that could redefine your understanding of current cybersecurity challenges, read on!

Illustration of a DDoS attack

Hyper-volumetric HTTP DDoS attacks

2023 was the year of uncharted territories. DDoS attacks reached new heights — in size and sophistication. The wider Internet community, including Cloudflare, faced a persistent and deliberately engineered campaign of thousands of hyper-volumetric DDoS attacks at never before seen rates.

These attacks were highly complex and exploited an HTTP/2 vulnerability. Cloudflare developed purpose-built technology to mitigate the vulnerability’s effect and worked with others in the industry to responsibly disclose it.

As part of this DDoS campaign, in Q3 our systems mitigated the largest attack we’ve ever seen — 201 million requests per second (rps). That’s almost 8 times larger than our previous 2022 record of 26 million rps.

Largest HTTP DDoS attacks as seen by Cloudflare, by year

Growth in network-layer DDoS attacks

After the hyper-volumetric campaign subsided, we saw an unexpected drop in HTTP DDoS attacks. Overall in 2023, our automated defenses mitigated over 5.2 million HTTP DDoS attacks consisting of over 26 trillion requests. That averages at 594 HTTP DDoS attacks and 3 billion mitigated requests every hour.

Despite these astronomical figures, the amount of HTTP DDoS attack requests actually declined by 20% compared to 2022. This decline was not just annual but was also observed in 2023 Q4 where the number of HTTP DDoS attack requests decreased by 7% YoY and 18% QoQ.

On the network-layer, we saw a completely different trend. Our automated defenses mitigated 8.7 million network-layer DDoS attacks in 2023. This represents an 85% increase compared to 2022.

In 2023 Q4, Cloudflare’s automated defenses mitigated over 80 petabytes of network-layer attacks. On average, our systems auto-mitigated 996 network-layer DDoS attacks and 27 terabytes every hour. The number of network-layer DDoS attacks in 2023 Q4 increased by 175% YoY and 25% QoQ.

HTTP and Network-layer DDoS attacks by quarter

DDoS attacks increase during and around COP 28

In the final quarter of 2023, the landscape of cyber threats witnessed a significant shift. While the Cryptocurrency sector was initially leading in terms of the volume of HTTP DDoS attack requests, a new target emerged as a primary victim. The Environmental Services industry experienced an unprecedented surge in HTTP DDoS attacks, with these attacks constituting half of all its HTTP traffic. This marked a staggering 618-fold increase compared to the previous year, highlighting a disturbing trend in the cyber threat landscape.

This surge in cyber attacks coincided with COP 28, which ran from November 30th to December 12th, 2023. The conference was a pivotal event, signaling what many considered the ‘beginning of the end’ for the fossil fuel era. It was observed that in the period leading up to COP 28, there was a noticeable spike in HTTP attacks targeting Environmental Services websites. This pattern wasn’t isolated to this event alone.

Looking back at historical data, particularly during COP 26 and COP 27, as well as other UN environment-related resolutions or announcements, a similar pattern emerges. Each of these events was accompanied by a corresponding increase in cyber attacks aimed at Environmental Services websites.

In February and March 2023, significant environmental events like the UN’s resolution on climate justice and the launch of United Nations Environment Programme’s Freshwater Challenge potentially heightened the profile of environmental websites, possibly correlating with an increase in attacks on these sites​​​​.

This recurring pattern underscores the growing intersection between environmental issues and cyber security, a nexus that is increasingly becoming a focal point for attackers in the digital age.

DDoS attacks and Iron Swords

It’s not just UN resolutions that trigger DDoS attacks. Cyber attacks, and particularly DDoS attacks, have long been a tool of war and disruption. We witnessed an increase in DDoS attack activity in the Ukraine-Russia war, and now we’re also witnessing it in the Israel-Hamas war. We first reported the cyber activity in our report Cyber attacks in the Israel-Hamas war, and we continued to monitor the activity throughout Q4.

Operation “Iron Swords” is the military offensive launched by Israel against Hamas following the Hamas-led 7 October attack. During this ongoing armed conflict, we continue to see DDoS attacks targeting both sides.

DDoS attacks targeting Israeli and Palestinian websites, by industry

Relative to each region’s traffic, the Palestinian territories was the second most attacked region by HTTP DDoS attacks in Q4. Over 10% of all HTTP requests towards Palestinian websites were DDoS attacks, a total of 1.3 billion DDoS requests — representing a 1,126% increase in QoQ. 90% of these DDoS attacks targeted Palestinian Banking websites. Another 8% targeted Information Technology and Internet platforms.

Top attacked Palestinian industries

Similarly, our systems automatically mitigated over 2.2 billion HTTP DDoS requests targeting Israeli websites. While 2.2 billion represents a decrease compared to the previous quarter and year, it did amount to a larger percentage out of the total Israel-bound traffic. This normalized figure represents a 27% increase QoQ but a 92% decrease YoY. Notwithstanding the larger amount of attack traffic, Israel was the 77th most attacked region relative to its own traffic. It was also the 33rd most attacked by total volume of attacks, whereas the Palestinian territories was 42nd.

Of those Israeli websites attacked, Newspaper & Media were the main target — receiving almost 40% of all Israel-bound HTTP DDoS attacks. The second most attacked industry was the Computer Software industry. The Banking, Financial Institutions, and Insurance (BFSI) industry came in third.

Top attacked Israeli industries

On the network layer, we see the same trend. Palestinian networks were targeted by 470 terabytes of attack traffic — accounting for over 68% of all traffic towards Palestinian networks. Surpassed only by China, this figure placed the Palestinian territories as the second most attacked region in the world, by network-layer DDoS attack, relative to all Palestinian territories-bound traffic. By absolute volume of traffic, it came in third. Those 470 terabytes accounted for approximately 1% of all DDoS traffic that Cloudflare mitigated.

Israeli networks, though, were targeted by only 2.4 terabytes of attack traffic, placing it as the 8th most attacked country by network-layer DDoS attacks (normalized). Those 2.4 terabytes accounted for almost 10% of all traffic towards Israeli networks.

Top attacked countries

When we turned the picture around, we saw that 3% of all bytes that were ingested in our Israeli-based data centers were network-layer DDoS attacks. In our Palestinian-based data centers, that figure was significantly higher — approximately 17% of all bytes.

On the application layer, we saw that 4% of HTTP requests originating from Palestinian IP addresses were DDoS attacks, and almost 2% of HTTP requests originating from Israeli IP addresses were DDoS attacks as well.

Main sources of DDoS attacks

In the third quarter of 2022, China was the largest source of HTTP DDoS attack traffic. However, since the fourth quarter of 2022, the US took the first place as the largest source of HTTP DDoS attacks and has maintained that undesirable position for five consecutive quarters. Similarly, our data centers in the US are the ones ingesting the most network-layer DDoS attack traffic — over 38% of all attack bytes.

HTTP DDoS attacks originating from China and the US by quarter

Together, China and the US account for a little over a quarter of all HTTP DDoS attack traffic in the world. Brazil, Germany, Indonesia, and Argentina account for the next twenty-five percent.

Top source of HTTP DDoS attacks

These large figures usually correspond to large markets. For this reason, we also normalize the attack traffic originating from each country by comparing their outbound traffic. When we do this, we often get small island nations or smaller market countries that a disproportionate amount of attack traffic originates from. In Q4, 40% of Saint Helena’s outbound traffic were HTTP DDoS attacks — placing it at the top. Following the ‘remote volcanic tropical island’, Libya came in second, Swaziland (also known as Eswatini) in third. Argentina and Egypt follow in fourth and fifth place.

Top source of HTTP DDoS attacks with respect to each country’s traffic

On the network layer, Zimbabwe came in first place. Almost 80% of all traffic we ingested in our Zimbabwe-based data center was malicious. In second place, Paraguay, and Madagascar in third.

Top source of Network-layer DDoS attacks with respect to each country’s traffic

Most attacked industries

By volume of attack traffic, Cryptocurrency was the most attacked industry in Q4. Over 330 billion HTTP requests targeted it. This figure accounts for over 4% of all HTTP DDoS traffic for the quarter. The second most attacked industry was Gaming & Gambling. These industries are known for being coveted targets and attract a lot of traffic and attacks.

Top industries targeted by HTTP DDoS attacks

On the network layer, the Information Technology and Internet industry was the most attacked — over 45% of all network-layer DDoS attack traffic was aimed at it. Following far behind were the Banking, Financial Services and Insurance (BFSI), Gaming & Gambling, and Telecommunications industries.

Top industries targeted by Network-layer DDoS attacks

To change perspectives, here too, we normalized the attack traffic by the total traffic for a specific industry. When we do that, we get a different picture.

Top attacked industries by HTTP DDoS attacks, by region

We already mentioned in the beginning of this report that the Environmental Services industry was the most attacked relative to its own traffic. In second place was the Packaging and Freight Delivery industry, which is interesting because of its timely correlation with online shopping during Black Friday and the winter holiday season. Purchased gifts and goods need to get to their destination somehow, and it seems as though attackers tried to interfere with that. On a similar note, DDoS attacks on retail companies increased by 16% compared to the previous year.

Top industries targeted by HTTP DDoS attacks with respect to each industry’s traffic

On the network layer, Public Relations and Communications was the most targeted industry — 36% of its traffic was malicious. This too is very interesting given its timing. Public Relations and Communications companies are usually linked to managing public perception and communication. Disrupting their operations can have immediate and widespread reputational impacts which becomes even more critical during the Q4 holiday season. This quarter often sees increased PR and communication activities due to holidays, end-of-year summaries, and preparation for the new year, making it a critical operational period — one that some may want to disrupt.

Top industries targeted by Network-layer DDoS attacks with respect to each industry’s traffic

Most attacked countries and regions

Singapore was the main target of HTTP DDoS attacks in Q4. Over 317 billion HTTP requests, 4% of all global DDoS traffic, were aimed at Singaporean websites. The US followed closely in second and Canada in third. Taiwan came in as the fourth most attacked region — amidst the upcoming general elections and the tensions with China. Taiwan-bound attacks in Q4 traffic increased by 847% compared to the previous year, and 2,858% compared to the previous quarter. This increase is not limited to the absolute values. When normalized, the percentage of HTTP DDoS attack traffic targeting Taiwan relative to all Taiwan-bound traffic also significantly increased. It increased by 624% quarter-over-quarter and 3,370% year-over-year.

Top targeted countries by HTTP DDoS attacks

While China came in as the ninth most attacked country by HTTP DDoS attacks, it’s the number one most attacked country by network-layer attacks. 45% of all network-layer DDoS traffic that Cloudflare mitigated globally was China-bound. The rest of the countries were so far behind that it is almost negligible.

Top targeted countries by Network-layer DDoS attacks
Top targeted countries by Network-layer DDoS attacks

When normalizing the data, Iraq, Palestinian territories, and Morocco take the lead as the most attacked regions with respect to their total inbound traffic. What’s interesting is that Singapore comes up as fourth. So not only did Singapore face the largest amount of HTTP DDoS attack traffic, but that traffic also made up a significant amount of the total Singapore-bound traffic. By contrast, the US was second most attacked by volume (per the application-layer graph above), but came in the fiftieth place with respect to the total US-bound traffic.

Top targeted countries by HTTP DDoS attacks with respect to each country’s traffic
Top targeted countries by HTTP DDoS attacks with respect to each country’s traffic

Similar to Singapore, but arguably more dramatic, China is both the number one most attacked country by network-layer DDoS attack traffic, and also with respect to all China-bound traffic. Almost 86% of all China-bound traffic was mitigated by Cloudflare as network-layer DDoS attacks. The Palestinian territories, Brazil, Norway, and again Singapore followed with large percentages of attack traffic.

Top targeted countries by Network-layer DDoS attacks with respect to each country’s traffic
Top targeted countries by Network-layer DDoS attacks with respect to each country’s traffic

Attack vectors and attributes

The majority of DDoS attacks are short and small relative to Cloudflare’s scale. However, unprotected websites and networks can still suffer disruption from short and small attacks without proper inline automated protection — underscoring the need for organizations to be proactive in adopting a robust security posture.

In 2023 Q4, 91% of attacks ended within 10 minutes, 97% peaked below 500 megabits per second (mbps), and 88% never exceeded 50 thousand packets per second (pps).

Two out of every 100 network-layer DDoS attacks lasted more than an hour, and exceeded 1 gigabit per second (gbps). One out of every 100 attacks exceeded 1 million packets per second. Furthermore, the amount of network-layer DDoS attacks exceeding 100 million packets per second increased by 15% quarter-over-quarter.

DDoS attack stats you should know

One of those large attacks was a Mirai-botnet attack that peaked at 160 million packets per second. The packet per second rate was not the largest we’ve ever seen. The largest we’ve ever seen was 754 million packets per second. That attack occurred in 2020, and we have yet to see anything larger.

This more recent attack, though, was unique in its bits per second rate. This was the largest network-layer DDoS attack we’ve seen in Q4. It peaked at 1.9 terabits per second and originated from a Mirai botnet. It was a multi-vector attack, meaning it combined multiple attack methods. Some of those methods included UDP fragments flood, UDP/Echo flood, SYN Flood, ACK Flood, and TCP malformed flags.

This attack targeted a known European Cloud Provider and originated from over 18 thousand unique IP addresses that are assumed to be spoofed. It was automatically detected and mitigated by Cloudflare’s defenses.

This goes to show that even the largest attacks end very quickly. Previous large attacks we’ve seen ended within seconds — underlining the need for an in-line automated defense system. Though still rare, attacks in the terabit range are becoming more and more prominent.

1.9 Terabit per second Mirai DDoS attacks
1.9 Terabit per second Mirai DDoS attacks

The use of Mirai-variant botnets is still very common. In Q4, almost 3% of all attacks originate from Mirai. Though, of all attack methods, DNS-based attacks remain the attackers’ favorite. Together, DNS Floods and DNS Amplification attacks account for almost 53% of all attacks in Q4. SYN Flood follows in second and UDP floods in third. We’ll cover the two DNS attack types here, and you can visit the hyperlinks to learn more about UDP and SYN floods in our Learning Center.

DNS floods and amplification attacks

DNS floods and DNS amplification attacks both exploit the Domain Name System (DNS), but they operate differently. DNS is like a phone book for the Internet, translating human-friendly domain names like “www.cloudfare.com” into numerical IP addresses that computers use to identify each other on the network.

Simply put, DNS-based DDoS attacks comprise the method computers and servers used to identify one another to cause an outage or disruption, without actually ‘taking down’ a server. For example, a server may be up and running, but the DNS server is down. So clients won’t be able to connect to it and will experience it as an outage.

A DNS flood attack bombards a DNS server with an overwhelming number of DNS queries. This is usually done using a DDoS botnet. The sheer volume of queries can overwhelm the DNS server, making it difficult or impossible for it to respond to legitimate queries. This can result in the aforementioned service disruptions, delays or even an outage for those trying to access the websites or services that rely on the targeted DNS server.

On the other hand, a DNS amplification attack involves sending a small query with a spoofed IP address (the address of the victim) to a DNS server. The trick here is that the DNS response is significantly larger than the request. The server then sends this large response to the victim’s IP address. By exploiting open DNS resolvers, the attacker can amplify the volume of traffic sent to the victim, leading to a much more significant impact. This type of attack not only disrupts the victim but also can congest entire networks.

In both cases, the attacks exploit the critical role of DNS in network operations. Mitigation strategies typically include securing DNS servers against misuse, implementing rate limiting to manage traffic, and filtering DNS traffic to identify and block malicious requests.

Top attack vectors
Top attack vectors

Amongst the emerging threats we track, we recorded a 1,161% increase in ACK-RST Floods as well as a 515% increase in CLDAP floods, and a 243% increase in SPSS floods, in each case as compared to last quarter. Let’s walk through some of these attacks and how they’re meant to cause disruption.

Top emerging attack vectors
Top emerging attack vectors

ACK-RST floods

An ACK-RST Flood exploits the Transmission Control Protocol (TCP) by sending numerous ACK and RST packets to the victim. This overwhelms the victim’s ability to process and respond to these packets, leading to service disruption. The attack is effective because each ACK or RST packet prompts a response from the victim’s system, consuming its resources. ACK-RST Floods are often difficult to filter since they mimic legitimate traffic, making detection and mitigation challenging.

CLDAP floods

CLDAP (Connectionless Lightweight Directory Access Protocol) is a variant of LDAP (Lightweight Directory Access Protocol). It’s used for querying and modifying directory services running over IP networks. CLDAP is connectionless, using UDP instead of TCP, making it faster but less reliable. Because it uses UDP, there’s no handshake requirement which allows attackers to spoof the IP address thus allowing attackers to exploit it as a reflection vector. In these attacks, small queries are sent with a spoofed source IP address (the victim’s IP), causing servers to send large responses to the victim, overwhelming it. Mitigation involves filtering and monitoring unusual CLDAP traffic.

SPSS floods

Floods abusing the SPSS (Source Port Service Sweep) protocol is a network attack method that involves sending packets from numerous random or spoofed source ports to various destination ports on a targeted system or network. The aim of this attack is two-fold: first, to overwhelm the victim’s processing capabilities, causing service disruptions or network outages, and second, it can be used to scan for open ports and identify vulnerable services. The flood is achieved by sending a large volume of packets, which can saturate the victim’s network resources and exhaust the capacities of its firewalls and intrusion detection systems. To mitigate such attacks, it’s essential to leverage in-line automated detection capabilities.

Cloudflare is here to help – no matter the attack type, size, or duration

Cloudflare’s mission is to help build a better Internet, and we believe that a better Internet is one that is secure, performant, and available to all. No matter the attack type, the attack size, the attack duration or the motivation behind the attack, Cloudflare’s defenses stand strong. Since we pioneered unmetered DDoS Protection in 2017, we’ve made and kept our commitment to make enterprise-grade DDoS protection free for all organizations alike — and of course, without compromising performance. This is made possible by our unique technology and robust network architecture.

It’s important to remember that security is a process, not a single product or flip of a switch. Atop of our automated DDoS protection systems, we offer comprehensive bundled features such as firewall, bot detection, API protection, and caching to bolster your defenses. Our multi-layered approach optimizes your security posture and minimizes potential impact. We’ve also put together a list of recommendations to help you optimize your defenses against DDoS attacks, and you can follow our step-by-step wizards to secure your applications and prevent DDoS attacks. And, if you’d like to benefit from our easy to use, best-in-class protection against DDoS and other attacks on the Internet, you can sign up — for free! — at cloudflare.com. If you’re under attack, register or call the cyber emergency hotline number shown here for a rapid response.

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

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

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

Source :
https://blog.cloudflare.com/ddos-threat-report-2023-q4/

Prevent spam user registration in WordPress: 2024 guide

JANUARY 20, 2024 BY PAUL G.

Spam registrations are common on WordPress websites. WordPress is the most popular content management system in the world, with over 60 percent market share. This makes it a prime target for scammers. It’s also, unfortunately, easy to create fake user accounts on the platform, requiring only an account name, email address, and password – all things spammers can simply invent. 

Fake registrations can cause extensive issues, such as hogging resources, spreading malware, and creating an unmanageable user base. 

WordPress doesn’t have a default functionality to combat spam user registrations, butthe good news is that plugins like Shield Security PRO can fill in the gap. Let’s take a look at some strategies for preventing spam user registrations. 

Introduction to spam registrations in WordPress 

WordPress spam registrations are when spammers create accounts on sites without any intention of using them for authentic purposes. Typically, spammers use automated programs or bots to create these accounts. Spammers may also use bots and spam accounts for phishing purposes, trying to acquire sensitive information from users and webmasters to compromise their security. 

Website owners often underestimate the harm spam registrations can cause. These range from immediate annoyances to long-term security problems and data distortion. 

For example, spam registrations can clog your inbox, causing surges of email notifications informing you of fake sign-ups for your website. Processing and deleting these emails and accounts without getting rid of legitimate users is time-consuming and challenging. 

Spam registrations can also overload server resources, affecting performance. Spam bots can make frequent login attempts, using up your bandwidth and making your website run slower for legitimate users. 

There can also be some considerable long-term consequences. Users may tire of spam comments and stop interacting with your content. You may also struggle to analyse user data, distorting your view of how your site is functioning. This can lead to security vulnerabilities and damage your site’s SEO. 

Strategies to prevent WordPress user registration spam 

This section covers various strategies and techniques that you can implement to prevent new user registration spam and improve the overall security of your WordPress site.

Install a WordPress security plugin

The first strategy is to install a WordPress security plugin. Choosing the right security plugin not only helps prevent spam registrations on your WordPress site, but it also gives you access to a wide range of security features.

Shield Security PRO is the best plugin for improving the overall security of your WordPress site. The plugin’s key features include bad bot detection and blocking, invisible CAPTCHA codes, human and bot spam prevention, traffic rate limiting, and malware scanning. 

A screenshot of Shield Security PRO’s feature comparison. 

Here’s a rundown of Shield Security PRO’s features and how they can help protect your site:

Disable WordPress registration

Using a plugin like ShieldPRO is the best choice to ensure the ongoing security of your WordPress site. However, there are also manual methods you can employ to help prevent user registration spam.

Disabling user registration in WordPress is one strategy. This approach eliminates the problem of spam signups entirely. You could try this option if you don’t need to collect user information, run a website with limited resources, or simply want to provide audiences with information for free.

The steps to disable registration on your WordPress site are as follows: 

  1. From the WordPress dashboard, go to Settings > General.
  2. Next, go to “Membership” and uncheck the “Anyone can register” box.

It’s worth considering that this technique prevents you from collecting visitor details, which stops you from building email lists or marketing directly to your audience. It also reduces personalisation opportunities and limits community building. 

Add CAPTCHA to your user registration form

You can also try adding CAPTCHA to your user registration form. This prevents automated spam registrations by identifying bots before they can create accounts. 

Various forms of CAPTCHA plugins for your site exist, including: 

  • reCAPTCHA: Google reCAPTCHA is a free service that combines text and images in a user-friendly interface, designed to weed out bots
  • hCAPTCHA: hCAPTCHA is a free service that uses images and action-based tests to identify bots. This service is customisable and prioritises user privacy. 

ShieldPRO’s AntiBot Detection Engine (ADE) avoids the need to use CAPTCHA at all. Since the plugin automatically detects and blocks bots, there’s no reason to test your visitors for signs of nuts and bolts. 

Implement geoblocking

You can also try geoblocking, a security method that limits website access to specific regions. It works by filtering IP addresses by location, only letting specific IPs enter the site. 

Geoblocking prevents spam from regions known for high levels of malicious activity. However, it also comes with various drawbacks. For example, it causes false positives, blocking legitimate site users just because they are in the wrong country. Spammers can also bypass it with proxy sites and VPNs.

Fortunately, ShieldPRO’s automated IP blocking technology more accurately and effectively stops spam users by blocking them after a specified number of offences. It detects malicious activity regardless of the traffic’s origin. 

Require manual approval for user registration

Manual user approvals can also mitigate spam registrations, offering significant benefits. The approach drastically reduces the chances of bot sign-up while also permitting you to collect legitimate user details. 

Drawbacks include the time-intensive nature of this method and the lack of scalability for larger WordPress sites. You may need to hire multiple full-time operatives to manage website administration, which can get pricey, fast.

Turn on email activation for user registration

Email activation for user registration is another popular technique to guard against spam registrations. It works by getting users to click a link in their email account to verify their details. 

Screenshot of Shield Security PRO’s email verification settings.

Shield Security PRO features a built-in email-checking feature. This tests to see if the email has a valid structure and is registered to a legitimate domain. It also checks if there are any mail exchange records for the domain, and determines if the email address goes to a disposable domain. These checks help to flag fake and temporary email addresses in user registrations. 

Block spam IP addresses

One of the primary ways Shield Security PRO works is by blocking malicious IP addresses once they’ve behaved badly enough to qualify as a bot. There is no one clear action an IP address can do on your site that proves it’s a bot. However, certain patterns of behaviour give bots away clear as day. 

“When you look at the activity as a whole” says Paul Goodchild, creator of Shield Security PRO, “a bot’s activity on a site is clearly distinguishable from human users.” 

The plugin then uses this clear indication as a signal to block the IP address entirely, stopping malicious activity in its tracks. The plugin also uses CrowdSec technology to minimise the risk of false positives and enable as many legitimate sign-ups as possible. 

Secure your WordPress site with ShieldPRO today 

The damaging impact of spam user registrations can be substantial. It can cause clogged inboxes, distorted user analytics, and server overload. The long-term consequences are diminished website SEO, reputational damage, and security vulnerabilities due to phishing and malware. 

Fortunately, there are various methods to prevent spam user registrations on WordPress websites. The most effective option is to use a plugin like Shield SecurityPRO. This plugin keeps malicious bots off your website. Since most spam user registrations come from bots, this means you can rest a lot easier. 

Try ShieldPRO on their WordPress sites today with a 14-day money-back guarantee. Install it to maximise your WordPress security and get some well-earned peace of mind.

Hey gorgeous!

If you’re curious about ShieldPRO and would like to explore the powerful features for protecting your WordPress sites, click here to get started today. (14-day satisfaction guarantee!)

You’ll get all PRO features, including AI Malware Scanning, WP Config File Protection, Plugin and Theme File Guard, import/export, exclusive customer support, and so much more.

TRY SHIELDPRO TODAY →

Source :
https://getshieldsecurity.com/blog/stop-spam-registrations-wordpress/

Sonicwall Sonicos 7.1.1 FAQ

01/11/2024

Description

This article helps answer frequently asked questions regarding SonicOS 7.1.1.

Q. What is SonicOS 7.1.1?
A. SonicOS 7.1.1 is the feature release available on all Gen 7 firewalls which brings in new capabilities around security, content filtering, integrations and virtual platforms.


Q. Will we be able to manage SonicOS 7.1 from NSM 2.3.5?
A. NSM 2.3.5 will not support SonicOS 7.1. The support for SonicOS 7.1 will be available from NSM 2.4.0, which will be released early next year (2024). Please read the following article on NSM Compatibility with SonicOS 7.1.


Q. What are the new features available on SonicOS 7.1.1?
A. The major features implemented in SonicOS 7.1.1 are DNS Filtering, reputation-based content filtering, Wi-Fi 6 access-point management, Network Access Control (NAC) integration with Aruba ClearPass, NSv bootstrapping, auto-update firmware and some other enhancements with storage and user interface (UI) for ease of use.


Q. How can existing firewall customers running SonicOS 7 upgrade/migrate to SonicOS 7.1.1?
A. You can upgrade the firewall to SonicOS 7.1 on box without using a migration tool.


Q. How can existing firewall customers running SonicOS6.5 and previous versions upgrade to SonicOS 7.1.1?
A. Users will be required to make use of our Secure Upgrade Program to upgrade their existing hardware models to Gen 7. They will then need to migrate their settings to the new firewall running 7.1.1 OS
Learn more about the Secure Upgrade Program


Q. Are there any new features in 7.1.1 that will require new licenses?
A. The DNS Filtering feature is a licensed feature that will be available as an a la carte license for Gen 7 firewalls without the APSS bundle.


Q. Do I need any additional licensing if I already have the APSS license available on my current Gen 7 firewall?
A. No.


Q. Can I perform a firmware/OS upgrade on my existing NSv NGFW running SonicOS 7.1.1?
A. The downgrade of firmware from SonicOS 7.1 to SonicOS 7.0 is not supported. Please refer to this article when upgrading your firewall: How can I upgrade SonicOS Firmware?


Q. Is there any change in behavior with regard to Policy Mode with 7.1.1?
A. There is no change in behavior with regard to Policy Mode in SonicOS 7.1.1. The NSv 270, 470 and 870 will continue to support both Global and Policy Mode. The NSsp15700 will continue to support only Policy Mode.


Q. What is CFS 5.0? How does it differ from CFS 4.0?
A. Content Filtering Service 5.0 brings category extension with CFS 4.0. SonicOS 7.0.1 supported 64 categories and that has been increased to 89. Content Filtering 5.0 brings in performance improvements along with reputation-based blocking.


Q. What is upgrade behavior when a user upgrades from SonicOS 7.0.1 to SonicOS 7.1.1 with regard to CFS policies?
A. There will be no impact on the existing CFS policies, however as CFS 5.0 brings in reputation-based blocking, users will be required to configure the CFS policies with the new reputation parameter in CFS 5.0. Please refer to this upgrade article.


Q. Can we downgrade the firewall from SonicOS 7.1 to SonicOS 7.0?
A. The downgrade of firmware from SonicOS 7.1 to SonicOS 7.0 is not supported. Please refer to this article when upgrading your firewall.


Q. What is DNS Filtering? How is it different from the current DNS capabilities in SonicOS 7.0.1?
A. DNS Filtering inspects the DNS traffic in real time and provides the ability to block threats and access to malicious websites. DNS Filtering blocks threats before they can reach your network. The DNS security capabilities on 7.0.1 include DNS Tunnel Detection and DNS Sinkholes. Please read DNS Security to understand them in detail.


Q. What is the upgrade behavior when users upgrade from SonicOS 7.0.1 to SonicOS 7.1.1 with regard to DNS proxy and sink-holing?
A. The upgrade from SonicOS 7.0.1 to SonicOS 7.1.1 would have no impact on the behavior that was there previous to the SonicOS 7.1 upgrade.


Q. What does the NAC integration feature do?
A. SonicWall Next-Generation Firewalls (NGFWs) provide Restful threat API which integrates with Aruba ClearPass as network access control (NAC). ClearPass can pass the security context vectors using the restful API which is included with SonicWall NGFWs. ClearPass can pass security context vectors including Source IP, Source MAC, User ID, User Role, Domain, Device Category, Device Family, Device Name, OS Type, Hostname and Health Posture to SonicWall NGFWs to enforce real-time rules based on Device Type, OS and Device Health Posture at every point of control. When an alert is generated on a client machine, it can be shared by ClearPass to SonicWall NGFWs which would trigger a range of predetermined, policy-based actions from quarantine to blocking.


Q. Does this NAC integration feature work with any NAC providers?
A. No, this NAC integration only works with Aruba ClearPass.


Q. Which access point models can I integrate with firewalls running SonicOS 7.1.1?
A. With the launch of SonicOS 7.1.1, users will now also be able to integrate and manage Wi-Fi 6 APs like 621, 641 and 681.


Q. How can I automate NSv deployment using the bootstrapping feature? Which platforms support this feature?
Bootstrapping helps with NSv automated deployments. Token-based registration will help ease the bootstrapping process. KVM already supported bootstrapping in SonicOS 7.0.1. With the launch of 7.1.1, other platforms like VMWare, Hyper-V, AWS and Azure will also support bootstrapping features.


Q. How is the bootstrapping process different between private cloud and public cloud?
A. The bootstrapping process is not different between private cloud and public cloud. SonicOS supports bootstrapping on AWS, Azure, VMware, KVM and Hyper-V.


Q. What are the new parameters that will be stored in secondary storage modules with the launch of 7.1.1?
A. TSR , exp, PCAP, threat logs and appflow logs will be stored in the secondary storage module as part of SonicOS 7.1.1


Q. Will the new features available in SonicOS 7.1.1 be available in the Capture Threat Assessment (CTA) report?
A. During the launch, the new features in SonicOS 7.1.1 will not be included in the CTA report.


Q. Are the new features available on NSM?
A. Yes. The upcoming NSM version 2.4 is planned to support the new features on SonicOS 7.1.1.


Q. Can I manage SonicOS 7.1.1 on the previous versions of NSM (prior to 2.4)?
A. You can upgrade the SonicOS version to 7.1.1, but the new features which are part of 7.1.1 will not be available on NSM versions prior to 2.4


Q. What are the best practices to be followed on SonicOS 7.1.1?
A. Please follow the best practices when upgrading the firewall from SonicOS 7.0.1 to SonicOS 7.1 documented here.

The migration tool is not required for the configuration migration from SonicOS 7.0 to SonicOS 7.1. Any customer migrating from Gen 6 to SonicOS 7.1 would need to upgrade to SonicOS 7.0.1 using the migration tool and then migrate to SonicOS 7.1.

 DNS Filtering is the first line of defense and works independent of Content Filtering Services (CFS). Please follow the admin guides for seamless configuration with best practices.
 
Q. What is the new website for URL rating and reputation lookup with CFS 5.0?
A. https://cfssupportapi.global.sonicwall.com/


Q. How can I check the URL rating on the firewall UI?
A. Device –> Diagnostics –> URL Rating Request Tool 


Q. What is the performance impact of enabling the new SonicOS 7.1 features on an existing firewall?
A. We do not expect there to be any impact on the performance of an existing firewall because of new features.


Q. Can DNS proxy 4to4 and 4to6 features work alongside DNS filtering? Can this be accomplished by adding an additional DNS proxy-only rule alongside a DNS filtering rule for X0 Interface? If so, what will take precedence/priority?
A. DNS rules give the choice of either proxy or filtering on a single rule. When proxy is enabled, Client 4to4 or 4to6 DNS queries can be proxied. When DNS filtering is enabled, only Client 4to4 Requests DNS queries will be proxied and filtered.
—While DNS proxies will process both DNS TCP and DNS UDP, DNS filtering is only for DNS UDP.
—Both proxy or filtering DNS rules can be stacked, the most specific match will be applied, and the lookup precedence/priority is top-down.
—To have DNS proxy 4to6 alongside DNS filtering, the proxy rule must explicitly have source zone and address of the 4to6 Clients for the traffic to hit the rule and the policy to be applied


Q. Can DNS Filtering be applied on custom zones or is it restricted to default zones, LAN, DMZ and WLAN?
A. DNS Filtering can be applied to LAN, DMZ and WLAN zones as well as custom zones with Trusted, Public and Wireless Security Types.


Q. How long does a cache entry last before we request a category for a specific domain again?
A. The cache entry of a domain would depend on the TTL of the domain. 


Q. Are there plans to support DNS over TLS and DNS over HTTPS?
A. Yes. DNS over TLS and DNS over HTTPS will be available in a future release.


Q. Will the DNS Filtering license be included with any existing bundle or does the customer need to buy it separately?
A. DNS Filtering will be available with APSS and there will be a la carte SKUs for EPSS, TPSS and HW only.

Q. What happens to the WNM managed access-point when the firewall is upgraded to SonicOS 7.1?

A. Please note that if you have 600 series access points on the network connected to a WLAN zone of a firewall with 7.0.x managed by WNM, after the update to 7.1 the access points will be acquired by the firewall. All WNM settings will not be available. Please “Disable SonicPoint/SonicWave management” on the WLAN zone for seamless management.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/sonicos-7-1-1-faq/231212121859137/

What is the minimum recommended length of twisted pair copper cable that I should use with my Sonic

Description

What is the minimum recommended length of twisted pair copper cable that I should use with my SonicWall firewalls’ HA ports for high availability?

Resolution

Question:

What is the minimum recommended length of twisted pair copper cable that I should use with my SonicWall firewalls’ HA ports for high availability?

Answer:

At present, there is no officially published minimum length for a twisted pair cable from IEEE or ANSI, though there is information about maximum lengths for twisted pair cable.

However, sometimes customers want to use a cable that is only several inches in length for this. The reason why is because it looks neat and tidy, and it’s one less cable that has to be strung through a rackmount cable channel. However, using such a small cable often causes problems. Customers have reported issues where the firewalls appear to lock up, and they can neither be managed, nor can they pass traffic.

The reason why this occurs, is because the extremely short HA cable causes problems with the transmissions of the HA heartbeats. In an HA pair, when the idle unit does not receive heartbeats for the configured interval and time threshold, it will go active. However, if the other unit in the HA pair is still active, both units’ interfaces will be competing for the addressing, which means there is an IP conflict between all of each firewall’s interfaces. This will prevent the devices from being managed, and it will also prevent them from passing traffic.

With regards to cable length, the following needs to be considered:
—
1.) Crosstalk

Crosstalk is when a signal sent on one circuit interferes with another signal sent on a separate but adjacent circuit. This is usually caused by circuits being close together. With ethernet cabling, this effect is reduced by twisting the circuit pairs. This reduces the circuits’ ability to interfere with one another while traveling the length of the copper media. With an extremely short cable, there is usually not enough twisted pair to prevent crosstalk interference.

2.) Return Loss

Return loss is essentially the loss of a signal’s power which is returned or reflected by a discontinuity in the cabling (ie: a point in the transmission line where the signal cannot conduct fully to the next leg of the pathway). It is desirable to have a high level of return loss (ie: the loss of reflectivity). Low return loss can be caused by problems at the termination point of the cable, or by a device which is in line with the transmission pathway. A shorter cable presents a potential for lower return loss, because there is less wire to degrade the reflection of signals.

3.) Cable Quality

The quality of cabling will vary from vendor to vendor, depending upon how accurate the equipment is which is used in the manufacturing process. Some vendors do not twist their cabling as effeciently as others do, and some have lower-quality crimps than others. Cables which are crimped by individuals often suffer greatly by comparison to manufactured cables, as one can only be so precise with a hand-crimping tool. The most common problem with custom cables is a loss of twisting near the termination point of the cable. Most vendors who make cables less than half of 1 meter in length do not have those cables certified by any standards body.


For high availability, SonicWall support recommends using a patch or crossover (NSA units have MDIx autosensing capabilities on their interfaces) cable which is no shorter than 1 meter in length (about three feet). There are many posted discussions on this topic available to read online, however, this post from a Fluke Networks employee at forucms.bicsi.org sums up these discussions very well.

http://forums.bicsi.org/Topic2210-4-1.aspx#bm2215
—-
“If you are talking specifically about patch cords, then 0.5 m is the implied minimum length in ANSI/TIA/EIA-568-B.2-1 for a certified patch cord. That’s because the math for the limit lines really does not work below this. Infact, getting a certified patch cord of 0.5 is going to be tricky. Many vendors only offer a certified patch cord of 1.0 m or longer.”

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/what-is-the-minimum-recommended-length-of-twisted-pair-copper-cable-that-i-should-use-with-my-sonic/170505905452401/#:~:text=For%20high%20availability%2C%20SonicWall%20support,length%20%28about%20three%20feet%29

Black Basta-Affiliated Water Curupira’s Pikabot Spam Campaign

By: Shinji Robert Arasawa, Joshua Aquino, Charles Steven Derion, Juhn Emmanuel Atanque, Francisrey Joshua Castillo, John Carlo Marquez, Henry Salcedo, John Rainier Navato, Arianne Dela Cruz, Raymart Yambot, Ian Kenefick
January 09, 2024
Read time: 8 min (2105 words)

A threat actor we track under the Intrusion set Water Curupira (known to employ the Black Basta ransomware) has been actively using Pikabot. a loader malware with similarities to Qakbot, in spam campaigns throughout 2023.

Pikabot is a type of loader malware that was actively used in spam campaigns by a threat actor we track under the Intrusion set Water Curupira in the first quarter of 2023, followed by a break at the end of June that lasted until the start of September 2023. Other researchers have previously noted its strong similarities to Qakbot, the latter of which was taken down by law enforcement in August 2023. An increase in the number of phishing campaigns related to Pikabot was recorded in the last quarter of 2023, coinciding with the takedown of Qakbot — hinting at the possibility that Pikabot might be a replacement for the latter (with DarkGate being another temporary replacement in the wake of the takedown).

Pikabot’s operators ran phishing campaigns, targeting victims via its two components — a loader and a core module — which enabled unauthorized remote access and allowed the execution of arbitrary commands through an established connection with their command-and-control (C&C) server. Pikabot is a sophisticated piece of multi-stage malware with a loader and core module within the same file, as well as a decrypted shellcode that decrypts another DLL file from its resources (the actual payload).

In general, Water Curupira conducts campaigns for the purpose of dropping backdoors such as Cobalt Strike, leading to Black Basta ransomware attacks (coincidentally, Black Basta also returned to operations in September 2023). The threat actor conducted several DarkGate spam campaigns and a small number of IcedID campaigns in the early weeks of the third quarter of 2023, but has since pivoted exclusively to Pikabot.

Pikabot, which gains initial access to its victim’s machine through spam emails containing an archive or a PDF attachment, exhibits the same behavior and campaign identifiers as Qakbot. 

Figure 1. Our observations from the infection chain based on Trend’s investigation
Figure 1. Our observations from the infection chain based on Trend’s investigation

Initial access via email

The malicious actors who send these emails employ thread-hijacking, a technique where malicious actors use existing email threads (possibly stolen from previous victims) and create emails that look like they were meant to be part of the thread to trick recipients into believing that they are legitimate. Using this technique increases the chances that potential victims would select malicious links or attachments. Malicious actors send these emails using addresses (created either through new domains or free email services) with names that can be found in original email threads hijacked by the malicious actor. The email contains most of the content of the original thread, including the email subject, but adds a short message on top directing the recipient to open the email attachment.

This attachment is either a password-protected archive ZIP file containing an IMG file or a PDF file. The malicious actor includes the password in the email message. Note that the name of the file attachment and its password vary for each email.

Figure 2. Sample email with a malicious ZIP attachment
Figure 2. Sample email with a malicious ZIP attachment
Figure 3. Sample email with a malicious PDF attachment
Figure 3. Sample email with a malicious PDF attachment

The emails containing PDF files have a shorter message telling the recipient to check or view the email attachment.

The first stage of the attack

The attached archive contains a heavily obfuscated JavaScript (JS) with a file size amounting to more than 100 KB. Once executed by the victim, the script will attempt to execute a series of commands using conditional execution.

Figure 4. Files extracted to the attached archive (.zip or .img)
Figure 4. Files extracted to the attached archive (.zip or .img)
Figure 5. Deobfuscated JS command
Figure 5. Deobfuscated JS command

The script attempts command execution using cmd.exe. If this initial attempt is unsuccessful, the script proceeds with the following steps: It echoes a designated string to the console and tries to ping a specified target using the same string. In case the ping operation fails, the script employs Curl.exe to download the Pikabot payload from an external server, saving the file in the system’s temporary directory.

Subsequently, the script will retry the ping operation. If the retry is also unsuccessful, it uses rundll32.exe to execute the downloaded Pikabot payload (now identified as a .dll file) with “Crash” as the export parameter. The sequence of commands concludes by exiting the script with the specified exit code, ciCf51U2FbrvK.

We were able to observe another attack chain where the malicious actors implemented a more straightforward attempt to deliver the payload. As before, similar phishing techniques were performed to trick victims into downloading and executing malicious attachments. In this case, password-protected archive attachments were deployed, with the password contained in the body of the email.

However, instead of a malicious script, an IMG file was extracted from the attachment. This file contained two additional files — an LNK file posing as a Word document and a DLL file, which turned out to be the Pikabot payload extracted straight from the email attachment:

Figure 6. The content of the IMG file
Figure 6. The content of the IMG file

Contrary to the JS file observed earlier, this chain maintained its straightforward approach even during the execution of the payload.

Once the victim is lured into executing the LNK file, rundll32.exe will be used to run the Pikabot DLL payload using an export parameter, “Limit”.

The content of the PDF file is disguised to look like a file hosted on Microsoft OneDrive to convince the recipient that the attachment is legitimate. Its primary purpose is to trick victims into accessing the PDF file content, which is a link to download malware.

Figure 7. Malicious PDF file disguised to look like a OneDrive attachment; note the misspelling of the word “Download”
Figure 7. Malicious PDF file disguised to look like a OneDrive attachment; note the misspelling of the word “Download”
Figure 7. Malicious PDF file disguised to look like a OneDrive attachment; note the misspelling of the word “Download”

When the user selects the download button, it will attempt to access a malicious URL, then proceed to download a malicious JS file (possibly similar to the previously mentioned JS file).

The delivery of the Pikabot payload via PDF attachment is a more recent development, emerging only in the fourth quarter of 2023.

We discovered an additional variant of the malicious downloader that employed obfuscation methods involving array usage and manipulation:

Figure 8. Elements of array “_0x40ee” containing download URLs and JS methods used for further execution
Figure 8. Elements of array “_0x40ee” containing download URLs and JS methods used for further execution

Nested functions employed array manipulation methods using “push” and “shift,” introducing complexity to the code’s structure and concealing its flow to hinder analysis. The presence of multiple download URLs, the dynamic creation of random directories using the mkdir command, and the use of Curl.exe, as observed in the preceding script, are encapsulated within yet another array. 

The JavaScript will run multiple commands in an attempt to retrieve the malicious payload from different external websites using Curl.exe, subsequently storing it in a random directory created using mkdir.

Figure 9. Payload retrieval commands using curl.exe
Figure 9. Payload retrieval commands using curl.exe

The rundll32.exe file will continue to serve as the execution mechanism for the payload, incorporating its export parameter.

Figure 10. Payload execution using rundll32.exe
Figure 10. Payload execution using rundll32.exe

The Pikabot payload

We analyzed the DLL file extracted from the archive shown in Figure 6 and found it to be a sample of a 32-bit DLL file with 1515 exports. Calling its export function “Limit”, the file will decrypt and execute a shellcode that identifies if the process is being debugged by calling the Windows API NtQueryInformationProcess twice with the flag 0x7 (ProcessDebugPort) on the first call and 0x1F ProcessDebugFlags on the second call. This shellcode also decrypts another DLL file that it loads into memory and then eventually executes.

Figure 11. The shellcode calling the entry point of the decrypted DLL file
Figure 11. The shellcode calling the entry point of the decrypted DLL file

The decrypted DLL file will execute another anti-analysis routine by loading incorrect libraries and other junk to detect sandboxes. This routine seems to be copied from a certain GitHub article.

Security/Virtual Machine/Sandbox DLL filesReal DLL filesFake DLL files
cmdvrt.32.dllkernel32.dllNetProjW.dll
cmdvrt.64.dllnetworkexplorer.dllGhofr.dll
cuckoomon.dllNlsData0000.dllfg122.dll
pstorec.dll  
avghookx.dll  
avghooka.dll  
snxhk.dll  
api_log.dll  
dir_watch.dll  
wpespy.dll  

Table 1. The DLL files loaded to detect sandboxes

After performing the anti-analysis routine, the malware loads a set of PNG images from its resources section which contains an encrypted chunk of the core module and then decrypts them. Once the core payload has been decrypted, the Pikabot injector creates a suspended process (%System%\SearchProtocolHost) and injects the core module into it. The injector uses indirect system calls to hide its injection.

Figure 12. Loading the PNG images to build the core module
Figure 12. Loading the PNG images to build the core module

Resolving the necessary APIs is among the malware’s initial actions. Using a hash of each API (0xF4ACDD8, 0x03A5AF65E, and 0xB1D50DE4), Pikabot uses two functions to obtain the addresses of the three necessary APIs, GetProcAddress, LoadLibraryA, and HeapFree. This process is done by looking through kernel32.dll exports. The rest of the used APIs are resolved using GetProcAddress with decrypted strings. Other pertinent strings are also decrypted during runtime before they are used.

Figure 13. Harvesting the GetProcAddress and LoadLibrary API
Figure 13. Harvesting the GetProcAddress and LoadLibrary API
Figure 13. Harvesting the GetProcAddress and LoadLibrary API

The Pikabot core module checks the system’s languages and stops its execution if the language is any of the following:

  • Russian (Russia)
  • Ukrainian (Ukraine)
  •   

It will then ensure that only one instance of itself is running by creating a hard-coded mutex, {A77FC435-31B6-4687-902D-24153579C738}.

The next stage of the core module involves obtaining details about the victim’s system and forwarding them to a C&C server. The collected data uses a JSON format, with every data item  using the wsprintfW function to fill its position. The stolen data will look like the image in Figure 13 but with the collected information before encryption:

Figure 14. Stolen information in JSON format before encryption
Figure 14. Stolen information in JSON format before encryption

Pikabot seems to have a binary version and a campaign ID. The keys 0fwlm4g and v2HLF5WIO are present in the JSON data, with the latter seemingly being a campaign ID.

The malware creates a named pipe and uses it to temporarily store the additional information gathered by creating the following processes: 

  • whoami.exe /all
  • ipconfig.exe /all
  • netstat.exe -aon

Each piece of information returned will be encrypted before the execution of the process.

A list of running processes on the system will also be gathered and encrypted by calling CreateToolHelp32Snapshot and listing processes through Process32First and Process32Next.

Once all the information is gathered, it will be sent to one of the following IP addresses appended with the specific URL, cervicobrachial/oIP7xH86DZ6hb?vermixUnintermixed=beatersVerdigrisy&backoff=9zFPSr: 

  • 70[.]34[.]209[.]101:13720
  • 137[.]220[.]55[.]190:2223
  • 139[.]180[.]216[.]25:2967
  • 154[.]61[.]75[.]156:2078
  • 154[.]92[.]19[.]139:2222
  • 158[.]247[.]253[.]155:2225
  • 172[.]233[.]156[.]100:13721

However, as of writing, these sites are inaccessible.

C&C servers and impact

As previously mentioned, Water Curupira conducts campaigns to drop backdoors such as Cobalt Strike, which leads to Black Basta ransomware attacks.It is this potential association with a sophisticated type of ransomware such as Black Basta that makes Pikabot campaigns particularly dangerous.

The threat actor also conducted several DarkGate spam campaigns and a small number of IcedID campaigns during the early weeks of the third quarter of 2023, but has since pivoted exclusively to Pikabot.

Lastly, we have observed distinct clusters of Cobalt Strike beacons with over 70 C&C domains leading to Black Basta, and which have been dropped via campaigns conducted by this threat actor.

Security recommendations

To avoid falling victim to various online threats such as phishing, malware, and scams, users should stay vigilant when it comes to emails they receive. The following are some best practices in user email security:

  • Always hover over embedded links with the pointer to learn where the link leads.
  • Check the sender’s identity. Unfamiliar email addresses, mismatched email and sender names, and spoofed company emails are signs that the sender has malicious intent.
  • If the email claims to come from a legitimate company, verify both the sender and the email content before downloading attachments or selecting embedded links.
  • Keep operating systems and all pieces of software updated with the latest patches.
  • Regularly back up important data to an external and secure location. This ensures that even if you fall victim to a phishing attack, you can restore your information.

A multilayered approach can help organizations guard possible entry points into their system (endpoint, email, web, and network). Security solutions can detect malicious components and suspicious behavior, which can help protect enterprises.  

  • Trend Vision One™ provides multilayered protection and behavior detection, which helps block questionable behavior and tools before ransomware can do any damage. 
  • Trend Cloud One™ – Workload Security protects systems against both known and unknown threats that exploit vulnerabilities. This protection is made possible through techniques such as virtual patching and machine learning.  
  • Trend Micro™ Deep Discovery™ Email Inspector employs custom sandboxing and advanced analysis techniques to effectively block malicious emails, including phishing emails that can serve as entry points for ransomware.  
  • Trend Micro Apex One™ offers next-level automated threat detection and response against advanced concerns such as fileless threats and ransomware, ensuring the protection of endpoints.
     

Indicators of Compromise (IOCs)

The indicators of compromise for this blog entry can be found here.

Source :
https://www.trendmicro.com/it_it/research/24/a/a-look-into-pikabot-spam-wave-campaign.html

Trend Micro Defends FIFA World Cup from Cyber Threats

By: Jon Clay
January 11, 2024
Read time: 4 min (970 words)

Trend Micro collaborates with INTERPOL to defend FIFA World Cup by preventing attacks & mitigating risks to fight against the rising threat of cybercrime.

The prominent sporting event, FIFA World Cup, concluded in December 2022, and it generated a lot of online engagements from millions of fans around the world. The remarkable penalty-shootout in the finals was hailed the champion of the event and it was a trending topic in social media and headline news. Before and during this event, the online users were rejoicing and betting their favorite teams at the same time cybercriminals were taking advantage of the event to deploy spam and scams. With this, law enforcement, and in particular, INTERPOL, had to step up and tapped its gateway partners to be on the lookout and report to them the cyberthreats surrounding the 2022 FIFA World Cup. Trend Micro helped by proactively monitoring our global threat intelligence that revealed many malicious websites and scams before and during the event. For example, we saw websites disguised as ticketing systems of the 2022 FIFA World Cup and many survey scams. We shared this information to INTERPOL, helping in their goal of preventing attacks and mitigating the risk posed by the fraudsters of this event. Furthermore, through our global threat intelligence, we monitored the detections of malicious websites and files from the country of Qatar as INTERPOL worked closely with them to prevent cybercriminals and malicious actors in disrupting the sporting event.

Let’s look a bit deeper into the different cyber threats we discovered and shared with INTERPOL, besides blocking them for our customers.

Malicious Websites found throughout 2022

figure-1
Figure 1: Trend Micro detections of malicious sites bearing keywords of “FIFA” and “World Cup”
figure-2
Figure 2: Top affected countries of malicious sites related to FIFA World Cup
figure-3
Figure 3: Timeline of FIFA World Cup Cyberthreats

Fake Ticketing System

It is no wonder due to the millions of potential victims that cybercriminals created dubious sites for selling tickets to the 2022 FIFA World Cup and trick users into inputting their personal information and credit card details in phishing attempts. We observed a few sites such as fifa-ticketssales[.]com and prime-ticketssales[.]com, both imitating the FIFA World Cup ticketing page and one showing an unbelievable number of sold tickets and remaining number of seats. We also identified contact details of scammers such as phone numbers and email addresses, some of these phone numbers were linked to other scam sites which is typical for scammers to reuse phone numbers.

figure-4
Figure 4: Fake selling tickets of FIFA World Cup
figure-5
Figure 5: Questionable number of tickets sold and used as lure to users

Fake Live Streaming

Cybercriminals created several fake streaming sites to lure victims to click on it. We identified around 40 unique domains that hosted fake streaming of FIFA World Cup. Example sites are watchvsportstv[.]com/2022-FIFA-WORLD-CUP-FINAL, sportshdlivetv[.]com/FIFA-WORLD-CUP-FINAL and istream2watch[.]stream/video/fifa-world-cup. From our analysis of these fake live streaming pages, the user will be redirected to websites with subscription forms or premium access requests and lure these users to subscribe and pay. Among the top countries detected were Brazil, Philippines, and Malaysia.

Survey Scams

Survey scams are relentless and scammers have been using them for a long time now. One we reported for example was https://www.theregister.com/2012/03/23/pinterest_attracts_scammers/. While the FIFA World Cup 2022 was ongoing, especially as we approached the semi-finals and final game, we observed malicious sites hosting survey scams that offered free 50GB mobile data. We identified more than 40 IP addresses or servers hosting the scam sites. Mostly were registered by Chinese names and hosted under Google LLC. Survey scams aim to trick users into obtaining free mobile data 50GB for a faster streaming of video or a free mobile network. It tricks users into inputting phone number and personal information thus in the end it will incur charges to the victims not knowing that it is a scam and may use their personal information for future spam or scams. Additionally, mostly it will redirect to fake dating sites and would require and harvest email address which can allow spammers to include them in their next wave of spam.

figure-6
Figure 6: FIFA World Cup Survey scam that offers free mobile data
figure-7
Figure 7: It requests for phone number which may lead to unwanted charges.
figure-8
Figure 8: Displays the offer is successful, however, it requires the user to share it in WhatsApp, thus propagating this survey scam
figure-9
Figure 9: Survey scam common web page title

Crypto scamming and malicious app

Based on external reports there were crypto scammers that leveraged the sporting event. We observed some scam sites such as cristiano-binance[.]xyz, binance[.]supply, football-blnance[.]com, football-binance[.]com, birance[.]online and birance[.]site that lure users to click on the button “Connect wallet” and will compromise the account. We also observed malicious app or Android RAT which was reported from https://twitter.com/ESETresearch/status/1596222440996311040 https://blog.cyble.com/2022/12/09/threat-actors-targeting-fans-amid-fifa-world-cup-fever/ and it was called “ Kora 442” with malicious site kora442[.]com. It lured users to download the app “kora442.apk” and promised live and exclusive broadcasts of the 2022 FIFA World Cup. Example of hashes are 2299d4e4ba3e9c2643ee876bb45d6a976362ce3c, c66564b7f66f22ac9dd2e7a874c6874a5bb43a26, 9c904c821edaff095e833ee342aedfcaac337e04 and 60b1da6905857073c4c46e7e964699d9c7a74ec7. The package name is com.app.projectappkora and we detect it as AndroidOS_DummyColl.HRX. It steals information from the infected device and sends it to the Command &Control (C&C) server.

figure-10
Figure 10: Fraudulent site potential hijacking of Crypto account
figure-11
Figure 11: Malicious mobile app site with download request

Trend Micro’s mission has always been making the world safe for exchanging digital information and our support of INTERPOL and the 2022 FIFA World Cup gave us an opportunity to do exactly this. We’re proud of our continued support of INTERPOL, whether it is helping them with investigations of cybercriminals, or helping with a major worldwide sporting event. Our 34 years of experience in proactively identifying new threats and attacks and protecting users against them will continue in the future and we look forward to more engagements with law enforcement and organizations managing these events.

Source :
https://www.trendmicro.com/it_it/research/24/a/trend-micro-defends-fifa-world-cup-from-cyber-threats.html

Forward Momentum: Key Learnings From Trend Micro’s Security Predictions for 2024

By: Trend Micro
December 06, 2023
Read time: 4 min (971 words)

In this blog entry, we discuss predictions from Trend Micro’s team of security experts about the drivers of change that will figure prominently in 2024.

Digital transformations in the year ahead will be led by organizations pursuing a pioneering edge from the integration of emergent technologies. Advances in cloud technology, artificial intelligence and machine learning (AI/ML), and Web3 are poised to reshape the threat landscape, giving it new frontiers outside the purview of traditional defenses. However, these technological developments are only as efficient as the IT structures that support them. In 2024, business leaders will have to take measures to ensure that their organization’s systems and processes are equipped to stay in step with these modern solutions — not to mention the newfound security challenges that come with implementing and securing them.

As the new year draws closer, decision-makers will need to stay on top of key trends and priority areas in enterprise cybersecurity if they are to make room for growth and fend off any upcoming threats along their innovation journey. In this blog entry, we discuss predictions from Trend Micro’s team of security experts about the drivers of change that will figure prominently next year.

Misconfigurations will allow cybercriminals to scale up their attacks using cloud-native worms

Enterprises should come into 2024 prepared to ensure that their cloud resources can’t be turned against them in “living-off-the-cloud” attacks. Security teams need to closely monitor cloud environments in anticipation of cyberattacks that, tailored with worming capabilities, can also abuse cloud misconfigurations to gain a foothold in their targets and use rootkits for persistence. Cloud technologies like containerized applications are especially at risk as once infected, these can serve as a launchpad from which attackers can spread malicious payloads to other accounts and services. Given their ability to infect multiple containers at once, leverage vulnerabilities at scale, and automate various tasks like reconnaissance, exploitation, and achieving persistence, worms will endure as a prominent tactic among cybercriminals next year.

AI-generated media will give rise to more sophisticated social engineering scams

The gamut of use cases for generative AI will be a boon not only for enterprises but also for fraudsters seeking new ways of profiteering in 2024. Though they’re often behind the curve when it comes to new technologies, expect cybercriminals — swayed by the potential of lucrative pay — to incorporate AI-generated lures as part of their upgraded social engineering attacks. Notably, despite the shutdown of malicious large language model (LLM) tool WormGPT, similar tools could still emerge from the dark web. In the interim, cybercriminals will also continue to find other ways to circumvent the limitations of legitimate AI tools available online. In addition to their use of digital impostors that combine various AI-powered tools in emerging threats like virtual kidnapping, we predict that malicious actors will resort specifically to voice cloning in more targeted attacks.

The rising tide of data poisoning will be a scourge on ML models under training

Integrating machine-learning (ML) models into their operations promises to be a real game changer for businesses that are banking on the potential of these models to supercharge innovation and productivity. As we step into 2024, attempts to corrupt the training data of these models will start gaining ground. Threat actors will likely carry out these attacks by taking advantage of a model’s data-collection phase or by compromising its data storage or data pipeline infrastructure. Specialized models using focused datasets will also be more vulnerable to data poisoning than LLMs and generative AI models trained on extensive datasets, which will prompt security practitioners to pay closer attention to the risks associated with tapping into external resources for ML training data.

Attackers will take aim at software supply chains through their CI/CD pipelines

Software supply chains will have a target on their back in 2024, as cybercriminals will aim to infiltrate them through their continuous integration and delivery (CI/CD) systems. For example, despite their use in expediting software development, components and code sourced from third-party libraries and containers are not without security risks, such as lacking thorough security audits, containing malicious or outdated components, or harboring overlooked vulnerabilities that could open the door to code-injection attacks. The call for developers to be wary of anything sourced from third parties will therefore remain relevant next year. Similarly, to safeguard the resilience of critical software development pipelines and weed out bugs in the coming year, DevOps practitioners should exercise caution and conduct routine scans of any external code they plan to use.

New extortion schemes and criminal gangs will be built around the blockchain

Whereas public blockchains are hardened by continuous cyberattacks, the same can’t be said of their permissioned counterparts because of the latter’s centralized nature. This lack of hard-won resilience will drive malicious actors to develop new extortion business models specific to private blockchains next year. In such extortion operations, criminals could use stolen keys to insert malicious data or modify existing records on the blockchain and then demand a payoff to stay mum on the attack. Threat actors can also strong-arm their victims into paying the ransom by wresting control of enough nodes to encrypt an entire private blockchain. As for criminal groups, we predict that 2024 will see the debut of the first criminal organizations running entirely on blockchains with smart contract or decentralized autonomous organizations (DAOs).

Countering future cyberthreats

Truly transformative technologies inevitably cross the threshold into standard business operations. But as they make that transition from novel to industry norm, newly adopted tools and solutions require additional layers of protection if they are to contribute to an enterprise’s expansion. So long as their security stance is anchored on preparedness and due diligence, organizations stand to reap the benefits from a growing IT stack without exposing themselves to unnecessary risks. To learn more about the key security considerations and challenges that lie ahead for organizations and end users, read our report, “Critical Scalability: Trend Micro Security Predictions for 2024.”

Source :
https://www.trendmicro.com/it_it/research/23/l/forward-momentum–key-learnings-from-trend-micro-s-security-pred.html