In H1 2022, malicious objects were blocked at least once on 31.8% of ICS computers globally.Percentage of ICS computers on which malicious objects were blocked
For the first time in five years of observations, the lowest percentage in the first half of the year was observed in March. During the period from January to March, the percentage of attacked ICS computers decreased by 1.7 p.p.Percentage of ICS computers on which malicious objects were blocked, January – June 2020, 2021, and 2022
Among regions, the highest percentage of ICS computers on which malicious objects were blocked was observed in Africa (41.5%). The lowest percentage (12.8%) was recorded in Northern Europe.Percentage of ICS computers on which malicious objects were blocked, in global regions
Among countries, the highest percentage of ICS computers on which malicious objects were blocked was recorded in Ethiopia (54.8%) and the lowest (6.8%) in Luxembourg.15 countries and territories with the highest percentage of ICS computers on which malicious objects were blocked, H1 202210 countries and territories with the lowest percentage of ICS computers on which malicious objects were blocked, H1 2022
Threat sources
The main sources of threats to computers in the operational technology infrastructure of organizations are internet (16.5%), removable media (3.5%), and email (7.0%).Percentage of ICS computers on which malicious objects from different sources were blocked
Regions
Among global regions, Africa ranked highest based on the percentage of ICS computers on which malware was blocked when removable media was connected.Regions ranked by percentage of ICS computers on which malware was blocked when removable media was connected, H1 2022
Southern Europe leads the ranking of regions by percentage of ICS computers on which malicious email attachments and phishing links were blocked.Regions ranked by percentage of ICS computers on which malicious email attachments and phishing links were blocked, H1 2022
Industry specifics
In the Building Automation industry, the percentage of ICS computers on which malicious email attachments and phishing links were blocked (14.4%) was twice the average value for the entire world (7%).Percentage of ICS computers on which malicious email attachments and phishing links were blocked, in selected industries
In the Oil and Gas industry, the percentage of ICS computers on which threats were blocked when removable media was connected (10.4%) was 3 times the average percentage for the entire world (3.5%).Percentage of ICS computers on which threats were blocked when removable media was connected
In the Oil and Gas industry, the percentage of ICS computers on which malware was blocked in network folders (1.2%) was twice the world average (0.6%).Percentage of ICS computers on which threats were blocked in network folders
Diversity of malware
Malware of different types from 7,219 families was blocked on ICS computers in H1 2022.Percentage of ICS computers on which the activity of malicious objects from different categories was prevented
Ransomware
In H1 2022, ransomware was blocked on 0.65% of ICS computers. This is the highest percentage for any six-month reporting period since 2020.Percentage of ICS computers on which ransomware was blocked
The highest percentage of ICS computers on which ransomware was blocked was recorded in February (0.27%) and the lowest in March (0.11%). The percentage observed in February was the highest in 2.5 years of observations.Percentage of ICS computers on which ransomware was blocked, January – June 2022
East Asia (0.95%) and the Middle East (0.89%) lead the ransomware-based ranking of regions. In the Middle East, the percentage of ICS computers on which ransomware was blocked per six-month reporting period has increased by a factor of 2.5 since 2020.Regions ranked by percentage of ICS computers on which ransomware was blocked, H1 2022
Building Automation leads the ranking of industries based on the percentage of ICS computers attacked by ransomware (1%).Percentage of ICS computers on which ransomware was blocked, in selected regions, H1 2022
Malicious documents
Malicious documents (MSOffice+PDF) were blocked on 5.5% of ICS computers. This is 2.2 times the percentage recorded in H2 2021. Threat actors distribute malicious documents via phishing emails and actively use such emails as the vector of initial computer infections.Percentage of ICS computers on which malicious documents (MSOffice+PDF) were blocked
In the Building Automation industry, the percentage of ICS computers on which malicious office documents were blocked (10.5%) is almost twice the global average.Percentage of ICS computers on which malicious office documents (MSOffice+PDF) were blocked, in selected industries
Spyware
Spyware was blocked on 6% of ICS computers. This percentage has been growing since 2020.Percentage of ICS computers on which spyware was blocked
Building Automation leads the ranking of industries based on the percentage of ICS computers on which spyware was blocked (12.9%).Percentage of ICS computers on which spyware was blocked, in selected industries
Malware for covert cryptocurrency mining
The percentage of ICS computers on which malicious cryptocurrency miners were blocked continued to rise gradually.Percentage of ICS computers on which malicious cryptocurrency miners were blocked
Building Automation also leads the ranking of selected industries by percentage of ICS computers on which malicious cryptocurrency miners were blocked.Percentage of ICS computers on which malicious cryptocurrency miners were blocked, in selected industries
by Or Katz and Jim Black Data analysis by Gal Kochner and Moshe Cohen
Executive summary
Akamai researchers have analyzed malicious DNS traffic from millions of devices to determine how corporate and personal devices are interacting with malicious domains, including phishing attacks, malware, ransomware, and command and control (C2).
Akamai researchers saw that 12.3% of devices used by home and corporate users communicated at least once to domains associated with malware or ransomware.
63% of those users’ devices communicated with malware or ransomware domains, 32% communicated with phishing domains, and 5% communicated with C2 domains.
Digging further into phishing attacks, researchers found that users of financial services and high tech are the most frequent targets of phishing campaigns, with 47% and 36% of the victims, respectively.
Consumer accounts are the most affected by phishing, with 80.7% of the attack campaigns.
Tracking 290 different phishing toolkits being reused in the wild, and counting the number of distinct days each kit was reused over Q2 2022, shows that 1.9% of the tracked kits were reactivated on at least 72 days. In addition, 49.6% of the kits were reused for at least five days, demonstrating how many users are being revictimized multiple times. This shows how realistic-looking and dangerous these kits can be, even to knowledgeable users.
The most used phishing toolkit in Q2 2022 (Kr3pto, a phishing campaign that targeted banking customers in the United Kingdom, which evades multi-factor authentication [MFA]) was hosted on more than 500 distinct domains.
Introduction
“It’s always DNS.” Although that is a bit of a tongue-in-cheek phrase in our industry, DNS can give us a lot of information about the threat landscape that exists today. By analyzing information from Akamai’s massive infrastructure, we are able to gain some significant insights on how the internet behaves. In this blog, we will explore these insights into traffic patterns, and how they affect people on the other end of the internet connection.
Akamai traffic insights
Attacks by category
Based on Akamai’s range of visibility across different industries and geographies, we can see that 12.3% of protected devices attempted to reach out to domains that were associated with malware at least once during Q2 2022. This indicates that these devices might have been compromised. On the phishing and C2 front, we can see that 6.2% of devices accessed phishing domains and 0.8% of the devices accessed C2-associated domains. Although these numbers may seem insignificant, the scale here is in the millions of devices. When this is considered, along with the knowledge that C2 is the most malignant of threats, these numbers are not only significant, they’re cardinal.
Comparing 2022 Q2 results with 2022 Q1 results (Figure 1), we can see a minor increase in all categories in Q2. We attribute those increases to seasonal changes that are not associated with a significant change in the threat landscape.
Fig. 1: Devices exposed to threats — Q1 vs. Q2
In Figure 2, we can see that of the 12.3% potentially compromised devices, 63% were exposed to threats associated with malware activity, 32% with phishing, and 5% with C2. Access to malware-associated domains does not guarantee that these devices were actually compromised, but provides a strong indication of increased potential risk if the threat wasn’t properly mitigated. However, access to C2-associated domains indicates that the device is most likely compromised and is communicating with the C2 server. This can often explain why the incidence of C2 is lower when compared with malware numbers.
Fig. 2: Potentially compromised devices by category
Phishing attack campaigns
By looking into the brands that are being abused and mimicked by phishing scams in Q2 2022, categorized by brand industry and number of victims, we can see that high tech and financial brands led with 36% and 47%, respectively (Figure 3). These leading phishing industry categories are consistent with Q1 2022 results, in which high tech and financial brands were the leading categories, with 32% and 31%, respectively.
Fig. 3: Phishing victims and phishing campaigns by abused brands
When taking a different view on the phishing landscape–targeted industries by counting the number of attack campaigns being launched over Q2 2022, we can see that high tech and financial brands are still leading, with 36% and 41%, respectively (Figure 3). The correlation between leading targeted brands when it comes to number of attacks and number of victims is evidence that threat actors’ efforts and resources are, unfortunately, effectively working to achieve their desired outcome.
Akamai’s research does not have any visibility into the distribution channels used to deliver the monitored phishing attacks that led to victims clicking on a malicious link and ending up on the phishing landing page. Yet the strong correlation between different brand segments by number of attack campaigns and the number of victims seems to indicate that the volume of attacks is effective and leads to a similar trend in the number of victims. The correlation might also indicate that the distribution channels used have minimal effect on attack outcome, and it is all about the volume of attacks that lead to the desired success rates.
Taking a closer look at phishing attacks by categorization of attack campaigns — consumers vs. business targeted accounts— we can see that consumer attacks are the most dominant, with 80.7% of the attack campaigns (Figure 4). This domination is driven by the massive demand for consumers’ compromised accounts in dark markets that are then used to launch fraud-related second-phase attacks. However, even with only 19.3% of the attack campaigns, attacks against business accounts should not be considered marginal, as these kinds of attacks are usually more targeted and have greater potential for significant damage. Attacks that target business accounts may lead to a company’s network being compromised with malware or ransomware, or to confidential information being leaked. An attack that begins with an employee clicking a link in a phishing email can end up with the business suffering significant financial and reputational damages.
Fig. 4: Phishing targeted accounts — consumers vs. business
Phishing toolkits
Phishing attacks are an extremely common vector that have been used for many years. The potential impacts and risks involved are well-known to most internet users. However, phishing is still a highly relevant and dangerous attack vector that affects thousands of people and businesses daily. Research conducted by Akamai explains some of the reasons for this phenomenon, and focuses on the phishing toolkits and their role in making phishing attacks effective and relevant.
Phishing toolkits enable rapid and easy creation of fake websites that mimic known brands. Phishing toolkits enable even non–technically gifted scammers to run phishing scams, and in many cases are being used to create distributed and large-scale attack campaigns. The low cost and availability of these toolkits explains the increasing numbers of phishing attacks that have been seen in the past few years.
According to Akamai’s research that tracked 290 different phishing toolkits being used in the wild, 1.9% of the tracked kits were reused on at least 72 distinct days over Q2 2022 (Figure 5). Further, 49.6% of the kits were reused for at least five days, and when looking into all the tracked kits, we can see that all of them were reused no fewer than three distinct days over Q2 2022.
Fig. 5: Phishing toolkits by number of reused days Q2 2022
The numbers showing the heavy reuse phenomenon of the observed phishing kits shed some light on the phishing threat landscape and the scale involved, creating an overwhelming challenge to defenders. Behind the reuse of phishing kits are factories and economic forces that drive the phishing landscape. Those forces include developers who create phishing kits that mimic known brands, later to be sold or shared among threat actors to be reused over and over again with very minimal effort.
Further analysis on the most reused kits in Q2 2022, counting the number of different domains used to deliver each kit, shows that the Kr3pto toolkit was the one most frequently used and was associated with more than 500 domains (Figure 6). The tracked kits are labeled by the name of the brand being abused or by a generic name representing the kit developer signature or kit functionality.
In the case of Kr3pto, the actor behind the phishing kit is a developer who builds and sells unique kits that target financial institutions and other brands. In some cases, these kits target financial firms in the United Kingdom, and they bypass MFA. This evidence also shows that this phishing kit that was initially created more than three years ago is still highly active and effective and being used intensively in the wild.
Fig. 6: Top 10 reused phishing toolkits
The phishing economy is growing, kits are becoming easier to develop and deploy, and the web is full of abandoned, ready-to-be-abused websites and vulnerable servers and services. Criminals capitalize on these weaknesses to establish a foothold that enables them to victimize thousands of people and businesses daily.
The growing industrial nature of phishing kit development and sales (in which new kits are developed and released within hours) and the clear split between creators and users means this threat isn’t going anywhere anytime soon. The threat posed by phishing factories isn’t just focused on the victims who risk having valuable accounts compromised and their personal information sold to criminals — phishing is also a threat to brands and their stakeholders.
The life span of a typical phishing domain is measured in hours, not days. Yet new techniques and developments by the phishing kit creators are expanding these life spans little by little, and it’s enough to keep the victims coming and the phishing economy moving.
Summary
This type of research is necessary in the fight to keep our customers safer online. We will continue to monitor these threats and report on them to keep the industry informed.
The best way to stay up to date on this and other research pieces from the Akamai team is to follow Akamai Security Research on Twitter.
A critical remote code-execution vulnerability (CVE-2021-44228) has been publicly disclosed in Log4j, an open-source logging utility that’s used widely in applications, including many utilized by large enterprise organizations.
The vulnerability allows threat actors to exfiltrate information from, and execute malicious code on, systems running applications that utilize the library by manipulating log messages. There already are reports of servers performing internet-wide scans in attempts to locate vulnerable servers, and our threat intelligence teams are seeing attempts to exploit this vulnerability at alarming volumes. Log4j is incorporated into many popular frameworks and many Java applications, making the impact widespread.
Akamai Guardicore Segmentation is well positioned to address this vulnerability in different ways. It’s highly recommended that organizations update Log4j to its latest version- 2.16.0. Due to the rapidly escalating nature of this vulnerability, Akamai teams will continue to develop and deploy mitigation measures in order to support our customers.
As a follow up to Akamai’s recent post we wanted to provide more detail on how organizations can leverage Akamai Guardicore Segmentation features to help address log4j exposure.
Log4j vulnerability: scope and impact
Log4j is a Java-based open-source logging library. On December 9, 2021, a critical vulnerability involving unauthenticated remote code execution (CVE-2021-44228) in Log4j was reported, causing concern due to how commonly Log4j is used. In addition to being used directly in a large multitude of applications, Log4j is also incorporated into a host of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink.
Although Akamai first observed exploit attempts on the Log4j vulnerability on December 9th, following the widespread publication of the incident, we are now seeing evidence suggesting it could have been around for months. Since widespread publication of the vulnerability, we have seen multiple variants seeking to exploit this vulnerability, at a sustained volume of attack traffic at around 2M exploit requests per hour. The speed at which the variants are evolving is unprecedented.
A compromised machine would allow a threat actor to remotely provide a set of commands which Log4j executes. An attacker would have the ability to run arbitrary commands inside a server. This can allow an attacker to compromise a vulnerable system – including those that might be secured deep inside of a network with no direct access to the internet.
Akamai’s security teams have been monitoring attackers attempting to use Log4j in recent days. Other than the increase in attempted exploitation, Akamai researchers are also seeing attackers using a multitude of tools and attack techniques to get vulnerable components to log malicious content, in order to get remote code execution. This is indicative of threat actors’ ability to exploit a new vulnerability, and the worse the vulnerability is, the quicker they will act.
Mitigating Log4j abuse using Akamai Guardicore Segmentation
Customers using Akamai Guardicore Segmentation can leverage its deep, process level visibility to identify vulnerable applications and potential security risks in the environment. They can then use it to enact precise control over network traffic in order to stop attempted attacks on vulnerable systems, without disruptions to normal business operations.
Guardicore Hunt customers have their environments monitored and investigated continuously by a dedicated team of security researchers. Alerts on security risks and suggested mitigation steps are immediately sent.
If you’d like to hear more about Akamai Guardicore Segmentation, read more or contact us.
What’s under threat: identify vulnerable Java processes and Log4j abuse
In order to protect against potential Log4j abuse, it is necessary to first identify potentially exploitable processes. This requires deep visibility into network traffic at the process level, which is provided by the Reveal and Insight features of Akamai Guardicore Segmentation. Precise visibility into internet connections and traffic at the process level allows us to see clearly what mitigation steps need to be taken, and visibility tools with historical data are pivotal in helping to prevent disruption to business operations.
Identify internet connected Java applications: using Reveal Explore Map, create a map for the previous week, and filter by java applications- such as tomcat, elastic, logstash- and by applications that have connections to/from the internet. Using this map, you can now see which assets are under potential threat. While this won’t yet identify Log4j applications, this can give you an idea of which machines to prioritize in your mitigation process.
Create a historical map to analyze normal communication patterns: using Reveal Explore Map, create a historical map of previous weeks (excluding the time since Log4j was reported) to view and learn normal communication patterns. Use this information to identify legitimate communications, and respond without disrupting the business. For example, a historical map might indicate what network connections exist under normal circumstances, those could be allowed, while other connections blocked or alerted on. Additionally, compare and contrast with a more recent map to identify anomalies.
Identify applications vulnerable to Log4j abuse: in the query section below, use Query 1 with Insight queries to identify assets that are running Java applications which have Log4j jar files in their directories. This query should return all Log4j packages in your environment, allowing you to assess and address any mitigation steps needed. To better prioritize exposed machines, cross reference the information with the Reveal Explore Map described previously.
Note that this query identifies Log4j packages that exist in the Java process current working directory or sub-directories.
Detect potential exploitation attempts in Linux logs: run an Insight query using YARA signature rule (Query 2, provided below in the query section) to search for known Log4j IoCs in the logs of linux machines. This can help you identify whether you’ve been attacked.
Note, a negative result does not necessarily mean that no attack exists, as this is only one of many indicators.
Stopping the attack: using Guardicore Segmentation to block malicious IoCs and attack vectors
It is imperative to be able to take action, once vulnerable applications have been identified. While patching is underway, Akamai Guardicore Segmentation offers a multitude of options for alerting on, stopping and preventing potential attacks. Critically, a solution with detailed and precise control over network communication and traffic is required to be able to surgically block or isolate attack vectors, with minimal to no disruption to normal business functions.
Automatically block IoC’s with Threat Intelligence Firewall (TIFW) and DNS Security: Akamai security teams are working around the clock to identify IPs and Domains used for Log4j exploitation. Customers who have these features turned on can expect a constantly updated list of IoCs to be blocked, preventing Log4j being used to download malicious payloads. Note that TIFW can be set to alert or block, please ensure it’s configured correctly. DNS Security is available from V41 onwards. The IoCs are also available on the Guardicore Threat Intel Repository and Guardicore Reputation Service.
Fully quarantine compromised servers: if compromised machines are identified during your investigation, use Akamai Guardicore Segmentation to isolate attacked/vulnerable servers from the rest of your network. Leverage built-in templates to easily enable deployment of segmentation policy to mitigate attacks.
Block inbound and outbound traffic to vulnerable assets: as a precautionary measure, you may also choose to block traffic to all machines identified with an unpatched version of Log4j, until patching is completed. Using a historical map of network traffic can help you limit the impact on business operations.
Create block rules for outgoing traffic from Java applications to the internet: if necessary, all internet-connected Java applications revealed in previous steps can be blocked from accessing the internet, as an additional precaution, until patching is complete.
Search queries
Query 1: To Identify assets that are running Java applications, which also have a Log4j jar file under their directories, run the following Insight query:
Query 2: To detect potential exploitation attempts, run an Insight query using YARA signature rules (our thanks to Florian Roth who published the original rule):
SELECT path, count FROM yara WHERE path LIKE '/var/log/%%' AND sigrule = "rule EXPL_Log4j_CallBackDomain_IOCs_Dec21_1 {
$sa1 = {22 2E 6C 6F 67 34 6A 2E 63 6F 72 65 2E 6E 65 74 2E 4A 6E 64 69 4D 61 6E 61 67 65 72 2E 6C 6F 6F 6B 75 70 28 4A 6E 64 69 4D 61 6E 61 67 65 72 22}
Or, more accurately, the cybercriminals responsible for July’s record-setting European DDoS attack may have never left. In the weeks following our coverage of the previous incident, the victim (a customer based in Eastern Europe) has been bombarded relentlessly with sophisticated distributed denial-of-service (DDoS) attacks, ultimately paving the way for a new European packets per second (pps) DDoS record.
On Monday, September 12, 2022, Akamai successfully detected and mitigated the now-largest DDoS attack ever launched against a European customer on the Prolexic platform, with attack traffic abruptly spiking to 704.8 Mpps in an aggressive attempt to cripple the organization’s business operations.
Attack breakdown
Adversaries are constantly evolving their techniques, tactics, and procedures to evade detection and maximize disruption, as demonstrated by this ongoing attack campaign. Let’s break down and compare the two record-setting events.
July Attack
September Attack
Peak pps
659.6 Mpps
704.8 Mpps
Cumulative Attacks
75
201
IPs Targeted
512
1813
Vector
UDP
UDP
Distribution
1 location
6 locations
Date of Attack
July 21, 2022
September 12, 2022
Top Scrubbing Locations
HKG, LON, TYO
HKG, TYO, LON
Prior to June 2022, this customer only saw attack traffic against its primary data center; however, they recognized the importance of a comprehensive defensive strategy early on, and onboarded their 12 remaining global data centers to the Prolexic platform for peace of mind. This proved highly fortuitous, as the attack campaign expanded unexpectedly, hitting six different global locations, from Europe to North America. These events reflect a growing trend in which adversaries are increasingly hitting deep-reconnaissance targets.
Attack mitigation
To thwart an attack of this magnitude and complexity, Akamai leveraged a balanced combination of automated and human mitigation: 99.8% of the assault was pre-mitigated thanks to the customer’s proactive defensive posture, a preemptive security measure implemented by the Akamai Security Operations Command Center (SOCC). Remaining attack traffic and follow-up attacks leveraging different vectors were swiftly mitigated by our frontline security responders. In the wake of increasingly sophisticated DDoS attacks worldwide, many businesses struggle with the staffing of internal security resources, and instead look to Akamai’s SOCC to augment and act as an extension of their incident response team.
The attackers’ command and control system had no delay in activating the multidestination attack, which escalated in 60 seconds from 100 to 1,813 IPs active per minute. Those IPs were spread across eight distinct subnets in six distinct locations. An attack this heavily distributed could drown an underprepared security team in alerts, making it difficult to assess the severity and scope of the intrusion, let alone fight the attack. Sean Lyons, Senior Vice President and General Manager of Infrastructure Security says, “Akamai Prolexic’s DDoS specialization culture, focus on customer infrastructure designs and history are rooted in defending the most complex, multifaceted attacks, and our platform is equipped with purpose-built tooling for rapid threat mitigation, even in the ‘fog of war.’ “
Akamai Prolexic’s DDoS specialization culture, focus on customer infrastructure designs and history are rooted in defending the most complex, multifaceted attacks, and our platform is equipped with purpose-built tooling for rapid threat mitigation, even in the ‘fog of war.
Sean Lyons, Senior Vice President and General Manager of Infrastructure Security
Conclusion
Having a proven DDoS mitigation strategy and platform in place is imperative for shielding your business from downtime and disruption. Learn more about Akamai’s industry-leading DDoS solutions and how our advanced attack-fighting capabilities keeps organizations safe from increasingly sophisticated threats.
Immediately review and implement Cybersecurity and Infrastructure Security Agency (CISA) recommendations.
Review critical subnets and IP spaces, and ensure that they have mitigation controls in place.
Deploy DDoS security controls in an always-on mitigation posture as a first layer of defense, to avoid an emergency integration scenario and to reduce the burden on incident responders. If you don’t have a trusted and proven cloud-based provider, get one now.
Proactively pull together a crisis response team and ensure runbooks and incident response plans are up-to-date. For example, do you have a runbook to deal with catastrophic events? Are the contacts within the playbooks updated? A playbook that references outdated tech assets or people who have long left the company isn’t going to help.
For additional information on the steps you can take to protect your organization, please visit the following CISA resources:
The Internet of Things (IoT) is here, and we’re using it for everything from getting instant answers to random trivia questions to screening visitors at the door. According to Gartner, we were expected to use more than 25 billion internet-connected devices by the end of 2021. But as our digital lives have become more convenient, we might not yet have considered the risks involved with using IoT devices.
How can you keep yourself secure in today’s IoT world, where hackers aim to outsmart your smart home? First we’ll look at how hackers infiltrate the IoT, and then we’ll look at what you can do right now to make sure the IoT is working for you – not against you.
How hackers are infiltrating the Internet of Things
While we’ve become comfortable asking voice assistants to give us the weather forecast while we prep our dinners, hackers have been figuring out how to commandeer our IoT devices for cyber attacks. Here are just a few examples of how cyber criminals are already infiltrating the IoT.
Gaining access to and control of your camera
Have you ever seen someone with a sticker covering the camera on their laptop or smartphone? There’s a reason for that. Hackers have been known to gain access to these cameras and spy on people. This has become an even more serious problem in recent years, as people have been relying on videoconferencing to safely connect with friends and family, participate in virtual learning, and attend telehealth appointments during the pandemic. Cameras now often come with an indicator light that lets you know whether they’re being used. It’s a helpful protective measure, but not a failsafe one.
Using voice assistants to obtain sensitive information
According to Statista, 132 million Americans used a digital voice assistant once a month in 2021. Like any IoT gadget, however, they can be vulnerable to attack. According to Ars Technica, academic researchers have discovered that the Amazon Echo can be forced to take commands from itself, which opens the door to major mischief in a smart home. Once an attacker has compromised an Echo, they can use it to unlock doors, make phone calls and unauthorized purchases, and control any smart home appliances that the Echo manages.
Many bad actors prefer the quiet approach, however, slipping in undetected and stealing information. They can piggyback on a voice assistant’s privileged access to a victim’s online accounts or other IoT gadgets and make off with any sensitive information they desire. With the victim being none the wiser, the attackers can use that information to commit identity fraud or stage even more ambitious cyber crimes.
Hacking your network and launching a ransomware attack
Any device that is connected to the internet, whether it’s a smart security system or even a smart fridge, can be used in a cyber attack. Bad actors know that most people aren’t keeping their IoT gadgets’ software up to date in the same way they do their computers and smartphones, so they take advantage of that false sense of security. Once cyber criminals have gained access to an IoT device, they can go after other devices on the same network. (This is because most home networks are designed to trust devices that are already connected to them.) When these malicious actors are ready, they can launch a ransomware attack that brings your entire digital life to a halt – unless you agree to fork over a hefty sum in bitcoin, that is.
Using bots to launch a DDOS attack
Although most people never notice it, hackers can and do infect IoT devices with malware en masse, gaining control over them in the process. Having turned these zombie IoT devices into bots, the hackers then collectively use them to stage what’s called a botnet attack on their target of choice. This form of assault is especially popular for launching distributed denial of service (DDOS) attacks, in which all the bots in a botnet collectively flood a target with network requests until it buckles and goes offline.
How you can keep your Internet of Things gadgets safe from hackers
So how can you protect your IoT devices from these determined hackers? Fortunately, you can take back control by becoming just a little more cyber smart. Here are a few ways to keep your IoT gadgets safe from hackers:
Never use the default settings on your IoT devices. Although IoT devices are designed to be plug-and-play so you can start enjoying them right away, their default settings are often not nearly as secure as they should be. With that in mind, set up a unique username and strong password combination before you start using any new IoT technology. While you’re at it, see if there’s an option to encrypt the traffic to and from your IoT device. If there is, turn it on.
Keep your IoT software up to date. Chances are, you regularly install the latest software updates on your computer and phone. Hackers are counting on you to leave your IoT gadgets unpatched, running outdated software with vulnerabilities they can exploit, so be sure to keep the software on your IoT devices up to date as well.
Practice good password hygiene. We all slip into bad password habits from time to time – it’s only human – but they put our IoT security at risk. With this in mind, avoid re-using passwords and be sure to set unique, strong passwords on each of your IoT devices. Update those passwords from time to time, too. Don’t store your passwords in a browser, and don’t share them via email. A password manager can help you securely store and share your passwords, so hackers never have a chance to snatch them.
Use secure, password-protected WiFi. Cyber criminals are notorious for sneaking onto open, insecure WiFi networks. Once they’re connected, they can spy on any internet activity that happens over those networks, steal login credentials, and launch cyber attacks if they feel like it. For this reason, make sure that you and your IoT devices only use secure, password-protected WiFi.
Use multi-factor authentication as an extra layer of protection. Multi-factor authentication (MFA), gives you extra security on top of all the other measures we mentioned above. It asks you to provide one more credential, or factor, in addition to a password to confirm you are who you say you are. If you have MFA enabled and a hacker tries to log in as you, you’ll get a notification that a login attempt is in progress. Whenever you have the option to enable MFA on any account or technology, take advantage of it.
Protect your Internet of Things devices with smart password security
The IoT is making our lives incredibly convenient, but that convenience can be a little too seductive at times. It’s easy to forget that smart home devices, harmless-looking and helpful as they are, can be targeted in cyber attacks just like our computers and phones. Hackers are counting on you to leave your IoT gadgets unprotected so they can use them to launch damaging attacks. By following these smart IoT security tips, you can have the best of both worlds, enjoying your smart life and better peace of mind at the same time.
Learn how LastPass Premium helps you strengthen your password security.
New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.
As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.
Here are the 5 key things we learned from 200 responses:
1 — Remote Work Has Accelerated the Use of EDR Technologies
In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.
2 — 90% of CISOs Use an MDR Solution
There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.
3 — Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams
The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.
4 — Small Security Teams Are Ignoring More Alerts
Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.
5 — 96% of CISOs Are Planning to Consolidate Security Platforms
Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.
The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.
Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.
The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:
The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:
Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
LLVM has the -mretpoline option
MSVC has the /Qspectre option
Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.↩
Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am
At Wordfence our business is to secure over 4 million WordPress websites and keep them secure. My background is in network operations, and then I transitioned into software development because my ops role was at a scale where I found myself writing a lot of code. This led me to founding startups, and ultimately into starting the cybersecurity business that is Wordfence. But I’ve maintained that ops perspective, and when I think about securing a network, I tend to think of ports.
You can find a rather exhaustive list of TCP and UDP ports on Wikipedia, but for the sake of this discussion let’s focus on a few of the most popular ports:
20 and 21 – FTP
22 – SSH
23 – (Just kidding. You better not be running Telnet)
25 – Email via SMTP
53 – DNS
80 – Unencrypted Web
110 – POP3 (for older email clients)
443 – Web encrypted via TLS
445 – Active Directory or SMB sharing
993 – IMAP (for email clients)
3306 – MySQL
6378 – Redis
11211 – Memcached
If you run your eye down this list, you’ll notice something interesting. The options available to you for services to run on most of these ports are quite limited. Some of them are specific to a single application, like Redis. Others, like SMTP, provide a limited number of applications, either proprietary or open-source. In both cases, you can change the configuration of the application, but it’s rare to write a custom application on one of those ports. Except port 443.
In the case of port 443 and port 80, you have a limited range of web servers listening on those ports, but users are writing a huge range of bespoke applications on port 443, and have a massive selection of applications that they can host on that port. Everything from WordPress to Drupal to Joomla, and more. There are huge lists of Content Management Systems.
Not only do you have a wide range of off-the-shelf web applications that you can run on port 443 or (if you’re silly) port 80, but you also have a range of languages they might be coded in, or in which you can code your own web application. Keep in mind that the web server, in this case, is much like an SSH or IMAP server in that it is listening on the port and handling connections, but the difference is that it is handing off execution to these languages, their various development frameworks, and ultimately the application that a developer has written to handle the incoming request.
With SSH, SMTP, FTP, IMAP, MySQL, Redis and most other services, the process listening on the port is the process that handles the request. With web ports, the process listening on the port delegates the incoming connection to another application, usually written in another language, running at the application layer, that is part of the extremely large and diverse ecosystem of web applications.
This concept in itself – that the applications listening on the web ports are extremely diverse and either home-made or selected from a large and diverse ecosystem – presents unique security challenges. In the case of, say, Redis, you might worry about running a secure version of Redis and making sure it is not misconfigured. In the case of a web server, you may have 50 application instances written in two languages from five different vendors all on the same port, which all need to be correctly configured, have their patch levels maintained, and be written using secure coding practices.
As if that doesn’t make the web ports challenging enough, they are also, for the most part, public. Putting aside internal websites for the moment, perhaps the majority of websites derive their value from making services available to users on the Internet by being public-facing. If you consider the list of ports I have above, or in the Wikipedia article I linked to, many of those ports are only open on internal networks or have access to them controlled if they are external. Web ports for public websites, by their very nature, must be publicly accessible for them to be useful. There are certain public services like SMTP or DNS, but as I mentioned above, the server that is listening on the port is the server handling the request in these cases.
A further challenge when securing websites is that often the monetary and data assets available to an attacker when compromising a website are greater than the assets they may gain compromising a corporate network. You see this with high volume e-commerce websites where a small business is processing a large number of web-based e-commerce transactions below $100. If the attacker compromises their corporate network via leaked AWS credentials, they may gain access to the company bank account and company intellectual property, encrypt the company’s data using ransomware, or perhaps even obtain customer PII. But by compromising the e-commerce website, they can gain access to credit card numbers in-flight, which are far more tradeable, and where the sum of available credit among all cards is greater than all the assets of the small business, including the amount of ransom that business might be able to pay.
Let’s not discount breaches like the 2017 Equifax breach that compromised 163 million American, British and Canadian citizen’s records. That was extremely valuable to the attackers. But targets like this are rare, and the Web presents a target-rich environment. Which is the third point I’d like to make in this post. While an organization may run a handful of services on other ports, many companies – with hosting providers in particular – run a large number of web applications. And an individual or company is far more likely to have a service running on a web port than any other port. Many of us have websites, but how many of us run our own DNS, SMTP, Redis, or another service listening on a port other than 80 or 443? Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.
That port 443 security is different has become clear to us at Wordfence over the years as we have tracked and cataloged a huge number of malware variants, web vulnerabilities, and a wide range of tactics, techniques, and procedures (TTP) that attackers targeting web applications use. Most of these have no relationship with the web server listening on port 443, and nearly all of them have a close relationship with the web application that the web server hands off control to once communication is established.
My hope with this post has been to catalyze a different way of thinking about port 443 and that other insecure port (80) we all hopefully don’t use. Port 443 is not just another service. It is, in fact, the gateway to a whole new universe of programming languages, dev frameworks, and web applications.
In the majority of cases, the gateway to that new universe is publicly accessible.
Once an attacker passes through that gateway, a useful way to think about the web applications hosted on the server is that each application is its own service that needs to have its patch level maintained, needs to be configured correctly, and should be removed if it is not in use to reduce the available attack surface.
If you are a web developer you may already think this way, and if anything, you may be guilty of neglecting services on ports other than port 80 or 443. If you are an operations engineer, or an analyst working in a SOC protecting an enterprise network, you may be guilty of thinking about port 443 as just another port you need to secure.
Think of port 443 as a gateway to a new universe that has no access control, with HTTPS providing easy standardized access, and with a wide range of diverse services running on the other side, that provide an attacker with a target and asset-rich environment.
—
Footnote: We will be exhibiting at Black Hat in Las Vegas this year at booth 2514 between the main entrance and Innovation City. Our entire team of over 30 people will be there. We’ll have awesome swag, as always. Come and say hi! Our team will also be attending DEF CON immediately after Black Hat.
Written by Mark Maunder – Founder and CEO of Wordfence.
Amplification attacks are one of the most common distributed denial of service (DDoS) attack vectors. These attacks are typically categorized as flooding or volumetric attacks, where the attacker succeeds in generating more traffic than the target can process, resulting in exhausting its resources due to the amount of traffic it receives.
In this blog, we start by surveying the anatomy and landscape of amplification attacks, while providing statistics from Azure on most common attack vectors, volumes, and distribution. We then describe some of the countermeasures taken in Azure to mitigate amplification attacks.
DDoS amplification attacks, what are they?
Reflection attacks involve three parties: an attacker, a reflector, and a target. The attacker spoofs the IP address of the target to send a request to a reflector (e.g., open server, middlebox) that responds to the target, a virtual machine (VM) in this case. For the attack to be amplified the response should be larger than the request, resulting in a reflected amplification attack. The attacker’s motivation is to create the largest reflection out of the smallest requests. Attackers achieve this goal by finding many reflectors and crafting the requests that result in the highest amplification.
Figure 1. Reflected amplification attack
The root cause for reflected amplification attacks is that an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible, this attack vector would be mitigated. Lots of effort has thus been made on disabling IP source address spoofing, and many organizations prevent spoofing nowadays so that attackers cannot leverage their networks for amplification attacks. Unfortunately, a significant number of organizations still allow source spoofing. The Spoofer project shows that a third of the IPv4 autonomous systems allow or partially allow spoofing.
UDP and TCP amplification attacks
Most attackers utilize UDP to launch amplification attacks since reflection of traffic with spoofed IP source address is possible due to the lack of proper handshake.
While UDP makes it easy to launch reflected amplification attacks, TCP has a 3-way handshake that complicates spoofing attacks. As a result, IP source address spoofing is restricted to the start of the handshake. Although the TCP handshake allows for reflection, it does not allow for easy amplification since TCP SYN+ACK response is not larger than TCP SYN. Moreover, since the TCP SYN+ACK response is sent to the target, the attacker never receives it and can’t learn critical information contained in the TCP SYN+ACK needed to complete the 3-way handshake successfully to continue making requests on behalf of the target.
Figure 2. Reflection attack in TCP
In recent years, however, reflection and amplification attacks based on TCP have started emerging.
Independent research found newer TCP reflected amplification vectors that utilize middleboxes, such as nation-state censorship firewalls and other deep packet inspection devices, to launch volumetric floods. Middleboxes devices may be deployed in asymmetric routing environments, where they only see one side of the TCP connection (e.g., packets from clients to servers). To overcome this asymmetry, such middleboxes often implement non-compliant TCP stack. Attackers take advantage of this misbehavior – they do not need to complete the 3-way handshake. They can generate a sequence of requests that elicit amplified responses from middleboxes and can reach infinite amplification in some cases. The industry has started witnessing these kinds of attacks from censorship and enterprise middle boxes, such as firewalls and IDPS devices, and we expect to see this trend growing as attackers look for more ways to create havoc utilizing DDoS as a primary weapon.
Carpet bombing is another example of a reflected amplification attack. It often utilizes UDP reflection, and in recent years TCP reflection as well. With carpet bombing, instead of focusing the attack on a single or few destinations, the attacker attacks many destinations within a specific subnet or classless inter-domain routing (CIDR) block (for example /22). This will make it more difficult to detect the attack and to mitigate it, since such attacks can fly below prevalent baseline-based detection mechanisms.
Figure 3. Carpet bombing attack
One example of TCP carpet bombing is TCP SYN+ACK reflection, where attacker sends spoofed SYN to a wide range of random or pre-selected reflectors. In this attack, amplification is a result of reflectors that retransmit the TCP SYN+ACK when they do not get a response. The amplification of the TCP SYN+ACK response itself may not be large, and it depends on the number of retransmissions sent by the reflector. In Figure 3, the reflected attack traffic towards each of the target virtual machines (VMs) may not be enough to bring them down, however, collectively, the traffic may well overwhelm the targets’ network.
UDP and TCP amplification attacks in Azure
In Azure, we continuously work to mitigate inbound (from internet to Azure) and outbound (from Azure to internet) amplification attacks. In the last 12 months, we mitigated approximately 175,000 UDP reflected amplification attacks. We monitored more than 10 attack vectors, where the most common ones are NTP with 49,700 attacks, DNS with 42,600 attacks, SSDP with 27,100 attacks, and Memcached with 18,200 attacks. These protocols can demonstrate amplification factors of up to x4,670, x98, x76 and x9,000 respectively.
Figure 4. UDP reflected amplification attacks observed from April 1, 2021, to March 31, 2022
We measured the maximum attack throughput in packets per second for a single attack across all attack vectors. The highest throughput was a 58 million packets per second (pps) SSDP flood in August last year, in a short attack campaign that lasted 20 minutes on a single resource in Azure.
Figure 5. Maximum pps recorded for a single attack observed from April 1, 2021, to March 31, 2022
TCP reflected amplification attacks are becoming more prevalent, with new attack vectors discovered. We encounter these attacks on Azure resources utilizing diverse types of reflectors and attack vectors.
One such example is a TCP reflected amplification attack of TCP SYN+ACK on an Azure resource in Asia. Attack reached 30 million pps and lasted 15 minutes. Attack throughput was not high, however there were approximately 900 reflectors involved, each with retransmissions, resulting in a high pps rate that can bring down the host and other network infrastructure elements.
Figure 6. TCP SYN+ACK amplification attack volume on an Azure resource in Asia
We see many TCP SYN+ACK retransmissions associated with the reflector that doesn’t get the ACK response from the spoofed source. Here is an example of such a retransmission:
The retransmitted packet was sent 60 seconds after the first.
Mitigating amplification attacks in Azure
Reflected amplification attacks are here to stay and pose a serious challenge for the internet community. They continue to evolve and exploit new vulnerabilities in protocols and software implementations to bypass conventional countermeasures. Amplification attacks require collaboration across the industry to minimize their effect. It is not enough to mitigate such attacks at a certain location, with a pinpoint mitigation strategy. It requires intertwining of network and DDoS mitigation capabilities.
Azure’s network is one of the largest on the globe. We combine multiple DDoS strategies across our network and DDoS mitigation pipeline to combat reflected amplification DDOS attacks.
On the network side, we continuously optimize and implement various traffic monitoring, traffic engineering and quality of service (QoS) techniques to block reflected amplification attacks right at the routing infrastructure. We implement these mechanisms at the edge and core of our wide area networks (WAN) network, as well as within the data centers. For inbound traffic (from the Internet), it allows us to mitigate attacks right at the edge of our network. Similarly, outbound attacks (those that originate from within our network) will be blocked right at the data center, without exhausting our WAN and leaving our network.
On top of that, our dedicated DDoS mitigation pipeline continuously evolves to offer advanced mitigation techniques against such attacks. This mitigation pipeline offers another layer of protection, on top of our DDoS networking strategies. Together, these two protection layers provide comprehensive coverage against the largest and most sophisticated reflected amplification attacks.
Since reflected amplification attacks are typically volumetric, it is not only enough to implement advanced mitigation strategies, but also to maintain a highly scalable mitigation pipeline to be able to cope with the largest attacks. Our mitigation pipeline can mitigate more than 60Tbps globally, and we continue to evolve it by adding mitigation capacity across all network layers.
Different attack vectors require different treatment
UDP-based reflected amplification attacks are tracked, monitored, detected, and mitigated for all attack vectors. There are various mitigation techniques to combat these attacks, including anomaly detection across attacked IP addresses, L4 protocols, and tracking of spoofed source IPs. Since UDP reflected amplification attacks often create fragmented packets, we monitor IP fragments to mitigate them successfully.
TCP-based reflected amplification attacks take advantage of poor TCP stack implementations, and large set of reflectors and targets, to launch such attacks. We adopt our mitigation strategies to be able to detect and block attacks from attackers and reflectors. We employ a set of mitigations to address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based attacks. Mitigation combines TCP authentication mechanisms that identify spoofed packets, as well as anomaly detection to block attack traffic when data is appended to TCP packets to trigger amplification with reflectors.
Figure 7. Amplification attack detection
Get started with Azure DDoS Protection to protect against amplification attacks
Azure’s DDoS mitigation platform mitigated the largest ever DDoS attacks in history by employing a globally distributed DDoS protection platform that scales beyond 60Tbps. We ensure our platform and customers’ workloads are always protected against DDoS attacks. To enhance our DDoS posture, we continuously collaborate with other industry players to fight reflected amplification attacks.
Azure customers are protected against Layer 3 and Layer 4 DDoS attacks as part of protecting our infrastructure and cloud platform. However, Azure DDoS Protection Standard provides comprehensive protection for customers by auto-tuning the detection policy to the specific traffic patterns of the protected application. This ensures that whenever there are changes in traffic patterns, such as in the case of flash crowd event, the DDoS policy is automatically updated to reflect those changes for optimal protection. When a reflected amplification attack is launched against a protected application, our detection pipeline detects it automatically based on the auto-tuned policy. The mitigation policy, that is automatically set for customers, without their need to manually configure or change it, includes the needed countermeasures to block reflected amplification attacks.
Protection is simple to enable on any new or existing virtual network and does not require any application or resource changes. Our recently released Azure built-in policies allow for better management of network security compliance by providing great ease of onboarding across all your virtual network resources and configuration of logs.
To strengthen the security posture of applications, Azure’s network security services can work in tandem to secure your workloads, where DDoS protection is one of the tools we provide. Organizations that pursue zero trust architecture can benefit from our services to achieve better protection.
This month, the Cisco Umbrella team – in conjunction with Talos – has witnessed the rise of complex cyberattacks. In today’s edition of the Cybersecurity Threat Spotlight, we unpack the tactics, techniques, and procedures used in these attacks.
Want to see how Cisco Umbrella can protect your network? Sign up for a free trial today!
BlackCat Ransomware
Threat Type: Ransomware
Attack Chain:
Description: BlackCat – also known as “ALPHV”- is a ransomware which uses ransomware-as-a-service model and double ransom schema (encrypted files and stolen file disclosure). It first appeared in November 2021 and, since then, targeted companies have been hit across the globe.
BlackCat Spotlight: BlackCat ransomware has quickly gained notoriety for being used in double ransom (encrypted files and stolen file disclosure) attacks against companies. While it targets companies across the globe, more than 30% of the compromises happened to companies based in the U.S.
There is a connection between the BlackCat, BlackMatter and DarkSide ransomware groups, recently confirmed by the BlackCat representative. Attack kill chain follows the blueprint of other human-operated ransomware attacks: initial compromise, followed by an exploration and data exfiltration phase, then attack preparation and finally, the ransomware execution. The key aspect of such attacks is that adversaries take time exploring the environment and preparing it for a successful and broad attack before launching the ransomware. Some of the attacks took up to two weeks from the initial to final stage, so it is key to have capabilities to detect such activities to counter them.
Target Geolocations: U.S., Canada, EU, China, India, Philippines, Australia Target Data: Sensitive Information, Browser Information Target Businesses: Any Exploits: N/A
Mitre ATT&CK for BlackCat
Initial Access: Valid Accounts: Local Accounts
Discovery: Account Discovery System Information Discovery Network Service Discovery File and Directory Discovery Security Software Discovery ADrecon Sofperfect Network Scanner
Which Cisco Products Can Block: Cisco Secure Endpoint Cisco Secure Firewall/Secure IPS Cisco Secure Malware Analytics Cisco Umbrella
ZingoStealer
Threat Type: Information Stealer
Attack Chain:
Description: ZingoStealer is an information stealer released by a threat actor known as “Haskers Gang.” The malware leverages Telegram chat features to facilitate malware executable build delivery and data exfiltration. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. ZingoStealer has the ability to download additional malware such as RedLine Stealer and the XMRig cryptocurrency mining malware.
ZingoStealer Spotlight: Cisco Talos recently observed a new information stealer, called “ZingoStealer” that has been released for free by a threat actor known as “Haskers Gang.” This information stealer, first introduced to the wild in March 2022, is currently undergoing active development and multiple releases of new versions have been observed recently. In many cases, ZingoStealer is being distributed under the guise of game cheats, cracks and code generators.
The stealer is an obfuscated .NET executable which downloads files providing core functionality an attacker-controlled server. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. The malware is also used as a loader for other malware payloads, such as RedLine Stealer and the XMRig cryptocurrency mining malware.
Target Geolocations: CIS Target Data: User Credentials, Browser Data, Financial and Personal Information, Cryptocurrency Wallets, Data From Browser Extensions Target Businesses: Any Exploits: N/A
Mitre ATT&CK for ZingoStealer
Initial Access: Trojanized Applications
Credential Access: Credentials from Password Stores Steal Web Session Cookie Unsecured Credentials Credentials from Password Stores: Credentials from Web Browsers
Discovery: Account Discovery Software Discovery Process Discovery System Time Discovery System Service Discovery System Location Discovery
Persistence: Registry Run Keys/Startup Folder Scheduled Task/Job: Scheduled Task
Privilege Escalation: N/A
Execution: User Execution Command and Scripting Interpreter: PowerShell
Evasion: Obfuscated Files or Information
Collection: Archive Collected Data: Archive via Utility Data Staged: Local Data Staging
Command and Control: Application Layer Protocol: Web Protocols
Which Cisco Products Can Block: Cisco Secure Endpoint Cisco Secure Email Cisco Secure Firewall/Secure IPS Cisco Secure Malware Analytics Cisco Umbrella Cisco Secure Web Appliance
BumbleBee Loader
Threat Type: Loader
Attack Chain:
Description: BumbleBee is a loader that has anti-virtualization checks and loader capabilities. The goal of the malware is to take a foothold in the compromised system to download and execute additional payloads. BumbleBee was observed to load Cobalt Strike, shellcode, Sliver and Meterpreter malware.
BumbleBee Spotlight: Security researchers noticed the appearance of the new malware being used by Initial Access Brokers, which previously relied on BazaLoader and IcedID malware. Dubbed BumbleBee due to presence of unique User-Agent “bumblebee” in early campaigns, this malware appears to be in active development.
It already employs complex anti-virtualization techniques, as well as uses asynchronous procedure call (APC) injection to launch the shellcode and LOLBins to avoid detections. Delivery chain relies on user interaction to follow the links and open malicious ISO or IMG file. Loader achieves persistence via scheduled task which launches Visual Basic Script to load BumbleBee DLL. Afterwards, the execution malware communicates with the Command-and-Control server and downloads additional payloads such as Cobalt Strike, shellcode, Sliver and Meterpreter. Threat actors using such payloads have been linked to ransomware campaigns.
Target Geolocations: Canada, U.S., Japan Target Data: N/A Target Businesses: Any Exploits: N/A
Mitre ATT&CK for BumbleBee
Initial Access: Malspam
Persistence: Scheduled Task/Job
Execution: Scheduled Task/Job: Scheduled Task Command and Scripting Interpreter: Virtual Basic User Execution: Malicious File
Evasion: System Binary Proxy Execution: Rundll32 Virtualization/Sandbox Evasion: System Checks Process Injection: Asynchronous Procedure Call
Discovery: System Information Discovery System Network Configuration Discovery System Network Connections Discovery
Fig. 1: Devices exposed to threats — Q1 vs. Q2
Fig. 2: Potentially compromised devices by category
Fig. 3: Phishing victims and phishing campaigns by abused brands
Fig. 4: Phishing targeted accounts — consumers vs. business
Fig. 5: Phishing toolkits by number of reused days Q2 2022
Fig. 6: Top 10 reused phishing toolkits
