Note: Content from this post first appeared in r/CrowdStrike
We will continue to update on this dynamic situation as more details become available. CrowdStrike’s Intelligence team is in contact with 3CX.
On March 29, 2023, CrowdStrike observed unexpected malicious activity emanating from a legitimate, signed binary, 3CXDesktopApp — a softphone application from 3CX. The malicious activity includes beaconing to actor-controlled infrastructure, deployment of second-stage payloads, and, in a small number of cases, hands-on-keyboard activity.
The CrowdStrike Falcon® platform has behavioral preventions and atomic indicator detections targeting the abuse of 3CXDesktopApp. In addition, CrowdStrike® Falcon OverWatch™ helps customers stay vigilant against hands-on-keyboard activity.
The 3CXDesktopApp is available for Windows, macOS, Linux and mobile. At this time, activity has been observed on both Windows and macOS.
CrowdStrike Intelligence has assessed there is suspected nation-state involvement by the threat actor LABYRINTH CHOLLIMA. CrowdStrike Intelligence customers received an alert this morning on this active intrusion.
The CrowdStrike Falcon platform protects customers from this attack and has coverage utilizing behavior-based indicators of attack (IOAs) and indicators of compromise (IOCs) based detections targeting malicious behaviors associated with 3CX on both macOS and Windows.
Customers should ensure that prevention policies are properly configured with Suspicious Processes enabled.
Figure 1. CrowdStrike’s indicator of attack (IOA) identifies and blocks the malicious behavior in macOS (click to enlarge)
Figure 2. CrowdStrike’s indicator of attack (IOA) identifies and blocks the malicious behavior in Windows (click to enlarge)
Hunting in the CrowdStrike Falcon Platform
Falcon Discover
CrowdStrike Falcon® Discover customers can use the following link: US-1 | US-2 | EU | Gov to look for the presence of 3CXDesktopApp in their environment.
Falcon Insight customers can assess if the 3CXDesktopApp is running in their environment with the following query:
Event Search — Application Search
event_simpleName IN (PeVersionInfo, ProcessRollup2) FileName IN ("3CXDesktopApp.exe", "3CX Desktop App")
| stats dc(aid) as endpointCount by event_platform, FileName, SHA256HashData
Falcon Long Term Repository — Application Search
#event_simpleName=/^(PeVersionInfo|ProcessRollup2)$/ AND (event_platform=Win ImageFileName=/\\3CXDesktopApp\.exe$/i) OR (event_platform=Mac ImageFileName=/\/3CX\sDesktop\sApp/i)
| ImageFileName = /.+(\\|\/)(?.+)$/i
| groupBy([event_platform, FileName, SHA256HashData], function=count(aid, distinct=true, as=endpointCount))
Atomic Indicators
The following domains have been observed beaconing, which should be considered an indication of malicious intent.
CrowdStrike Falcon® Insight customers, regardless of retention period, can search for the presence of these domains in their environment spanning back one year using Indicator Graph: US-1 | US-2 | EU | Gov.
Event Search — Domain Search
event_simpleName=DnsRequest DomainName IN (akamaicontainer.com, akamaitechcloudservices.com, azuredeploystore.com, azureonlinecloud.com, azureonlinestorage.com, dunamistrd.com, glcloudservice.com, journalide.org, msedgepackageinfo.com, msstorageazure.com, msstorageboxes.com, officeaddons.com, officestoragebox.com, pbxcloudeservices.com, pbxphonenetwork.com, pbxsources.com, qwepoi123098.com, sbmsa.wiki, sourceslabs.com, visualstudiofactory.com, zacharryblogs.com)
| stats dc(aid) as endpointCount, earliest(ContextTimeStamp_decimal) as firstSeen, latest(ContextTimeStamp_decimal) as lastSeen by DomainName
| convert ctime(firstSeen) ctime(lastSeen)
Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.
Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from other threat actors and ransomware gangs. Common purchasing plans include buying the entire tool, using the existing infrastructure while paying per infection, or letting other attackers perform the service while sharing revenue with them.
In this attack, the threat actor consists of one of the most prevalent ransomware groups, specializing in access via third parties, while the targeted company is a medium-sized retailer with dozens of sites in the United States.
The threat actors used ransomware as a service to breach the victim’s network. They were able to exploit third-party credentials to gain initial access, progress laterally, and ransom the company, all within mere minutes.
The swiftness of this attack was unusual. In most RaaS cases, attackers usually stay in the networks for weeks and months before demanding ransom. What is particularly interesting about this attack is that the company was ransomed in minutes, with no need for discovery or weeks of lateral movement.
A log investigation revealed that the attackers targeted servers that did not exist in this system. As it turns out, the victim was initially breached and ransomed 13 months before this second ransomware attack. Subsequently, the first attacker group monetized the first attack not only through the ransom they obtained, but also by selling the company’s network information to the second ransomware group.
In the 13 months between the two attacks, the victim changed its network and removed servers, but the new attackers were not aware of these architectural modifications. The scripts they developed were designed for the previous network map. This also explains how they were able to attack so quickly – they had plenty of information about the network. The main lesson here is that ransomware attacks can be repeated by different groups, especially if the victim pays well.
“RaaS attacks such as this one are a good example of how full visibility allows for early alerting. A global, converged, cloud-native SASE platform that supports all edges, like Cato Networks provides complete network visibility into network events that are invisible to other providers or may go under the radar as benign events. And, being able to fully contextualize the events allows for early detection and remediation.
#2: The Critical Infrastructure Attack on Radiation Alert Networks#
Attacks on critical infrastructure are becoming more common and more dangerous. Breaches of water supply plants, sewage systems and other such infrastructures could put millions of residents at risk of a human crisis. These infrastructures are also becoming more vulnerable, and attack surface management tools for OSINT like Shodan and Censys allow security teams to find such vulnerabilities with ease.
In 2021, two hackers were suspected of targeting radiation alert networks. Their attack relied on two insiders that worked for a third party. These insiders disabled the radiation alert systems, significantly debilitating their ability to monitor radiation attacks. The attackers were then able to delete critical software and disable radiation gauges (which is part of the infrastructure itself).
“Unfortunately, scanning for vulnerable systems in critical infrastructure is easier than ever. While many such organizations have multiple layers of security, they are still using point solutions to try and defend their infrastructure rather than one system that can look holistically at the full attack lifecycle. Breaches are never just a phishing problem, or a credentials problem, or a vulnerable system problem – they are always a combination of multiple compromises performed by the threat actor,” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.
#3: The Three-Step Ransomware Attack That Started with Phishing#
The third attack is also a ransomware attack. This time, it consisted of three steps:
1. Infiltration – The attacker was able to gain access to the network through a phishing attack. The victim clicked on a link that generated a connection to an external site, which resulted in the download of the payload.
2. Network activity – In the second phase, the attacker progressed laterally in the network for two weeks. During this time, it collected admin passwords and used in-memory fileless malware. Then on New Year’s Eve, it performed the encryption. This date was chosen since it was (rightfully) assumed the security team would be off on vacation.
3. Exfiltration – Finally, the attackers uploaded the data out of the network.
In addition to these three main steps, additional sub-techniques were employed during the attack and the victim’s point security solutions were not able to block this attack.
“A multiple choke point approach, one that looks horizontally (so to speak) at the attack rather than as a set of vertical, disjointed issues, is the way to enhance detection, mitigation and prevention of such threats. Opposed to popular belief, the attacker needs to be right many times and the defenders only need to be right just once. The underlying technologies to implement a multiple choke point approach are full network visibility via a cloud-native backbone, and a single pass security stack that’s based on ZTNA.” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.
It is common for security professionals to succumb to the “single point of failure fallacy”. However, cyber-attacks are sophisticated events that rarely involve just one tactic or technique which is the cause of the breach. Therefore, an all-encompassing outlook is required to successfully mitigate cyber-attacks. Security point solutions are a solution for single points of failure. These tools can identify risks, but they will not connect the dots, which could and has led to a breach.
According to ongoing security research conducted by Cato Networks Security Team, they have identified two additional vulnerabilities and exploit attempts that they recommend including in your upcoming security plans:
While Log4j made its debut as early as December of 2021, the noise its making hasn’t died down. Log4j is still being used by attackers to exploit systems, as not all organizations have been able to patch their Log4j vulnerabilities or detect Log4j attacks, in what is known as “virtual patching”. They recommend prioritizing Log4j mitigation.
Security solutions like firewalls and VPNs have become access points for attackers. Patching them has become increasingly difficult, especially in the era of architecture cloudification and remote work. It is recommended to pay close attention to these components as they are increasingly vulnerable.
How to Minimize Your Attack Surface and Gain Visibility into the Network#
To reduce the attack surface, security professionals need visibility into their networks. Visibility relies on three pillars:
Actionable information – that can be used to mitigate attacks
Reliable information – that minimizes the number of false positives
Timely information – to ensure mitigation happens before the attack has an impact
Once an organization has complete visibility to the activity on their network they can contextualize the data, decide whether the activity witnessed should be allowed, denied, monitored, restricted (or any other action) and then have the ability to enforce this decision. All these elements must be applied to every entity, be it a user, device, cloud app etc. All the time everywhere. That is what SASE is all about.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
Any organization that handles sensitive data must be diligent in its security efforts, which include regular pen testing. Even a small data breach can result in significant damage to an organization’s reputation and bottom line.
There are two main reasons why regular pen testing is necessary for secure web application development:
Security: Web applications are constantly evolving, and new vulnerabilities are being discovered all the time. Pen testing helps identify vulnerabilities that could be exploited by hackers and allows you to fix them before they can do any damage.
Compliance: Depending on your industry and the type of data you handle, you may be required to comply with certain security standards (e.g., PCI DSS, NIST, HIPAA). Regular pen testing can help you verify that your web applications meet these standards and avoid penalties for non-compliance.
Many organizations, big and small, have once a year pen testing cycle. But what’s the best frequency for pen testing? Is once a year enough, or do you need to be more frequent?
The answer depends on several factors, including the type of development cycle you have, the criticality of your web applications, and the industry you’re in.
Agile development cycles are characterized by short release cycles and rapid iterations. This can make it difficult to keep track of changes made to the codebase and makes it more likely that security vulnerabilities will be introduced.
If you’re only testing once a year, there’s a good chance that vulnerabilities will go undetected for long periods of time. This could leave your organization open to attack.
To mitigate this risk, pen testing cycles should align with the organization’s development cycle. For static web applications, testing every 4-6 months should be sufficient. But for web applications that are updated frequently, you may need to test more often, such as monthly or even weekly.
Any system that is essential to your organization’s operations should be given extra attention when it comes to security. This is because a breach of these systems could have a devastating impact on your business. If your organization relies heavily on its web applications to do business, any downtime could result in significant financial losses.
For example, imagine that your organization’s e-commerce site went down for an hour due to a DDoS attack. Not only would you lose out on potential sales, but you would also have to deal with the cost of the attack and the negative publicity.
To avoid this scenario, it’s important to ensure that your web applications are always available and secure.
Non-critical web applications can usually get away with being tested once a year, but business-critical web applications should be tested more frequently to ensure they are not at risk of a major outage or data loss.
If all your web applications are internal, you may be able to get away with pen testing less frequently. However, if your web applications are accessible to the public, you must be extra diligent in your security efforts.
Web applications accessible to external traffic are more likely to be targeted by attackers. This is because there is a greater pool of attack vectors and more potential entry points for an attacker to exploit.
Customer-facing web applications also tend to have more users, which means that any security vulnerabilities will be exploited more quickly. For example, a cross-site scripting (XSS) vulnerability in an external web application with millions of users could be exploited within hours of being discovered.
To protect against these threats, it’s important to pen test customer-facing web applications more frequently than internal ones. Depending on the size and complexity of the application, you may need to pen test every month or even every week.
Certain industries are more likely to be targeted by hackers due to the sensitive nature of their data. Healthcare organizations, for example, are often targeted because of the protected health information (PHI) they hold.
If your organization is in a high-risk industry, you should consider conducting pen testing more frequently to ensure that your systems are secure and meet regulatory compliance. This will help protect your data and reduce the chances of a costly security incident.
You Don’t Have Internal Security Operations or a Pen testing Team#
This might sound counterintuitive, but if you don’t have an internal security team, you may need to conduct pen testing more frequently.
Organizations that don’t have dedicated security staff are more likely to be vulnerable to attacks.
Without an internal security team, you will need to rely on external pen testers to assess your organization’s security posture.
Depending on the size and complexity of your organization, you may need to pen test every month or even every week.
During a merger or acquisition, there is often a lot of confusion and chaos. This can make it difficult to keep track of all the systems and data that need to be secured. As a result, it’s important to conduct pen testing more frequently during these times to ensure that all systems are secure.
M&A also means that you are adding new web applications to your organization’s infrastructure. These new applications may have unknown security vulnerabilities that could put your entire organization at risk.
In 2016, Marriott acquired Starwood without being aware that hackers had exploited a flaw in Starwood’s reservation system two years earlier. Over 500 million customer records were compromised. This placed Marriott in hot water with the British watchdog ICO, resulting in 18.4 million pounds in fines in the UK. According to Bloomberg, there is more trouble ahead, as the hotel giant could “face up to $1 billion in regulatory fines and litigation costs.”
To protect against these threats, it’s important to conduct pen testing before and after an acquisition. This will help you identify potential security issues so they can be fixed before the transition is complete.
While periodic pen testing is important, it is no longer enough in today’s world. As businesses rely more on their web applications, continuous pen testing becomes increasingly important.
There are two main types of pen testing: time-boxed and continuous.
Traditional pen testing is done on a set schedule, such as once a year. This type of pen testing is no longer enough in today’s world, as businesses rely more on their web applications.
Continuous pen testing is the process of continuously scanning your systems for vulnerabilities. This allows you to identify and fix vulnerabilities before they can be exploited by attackers. Continuous pen testing allows you to find and fix security issues as they happen instead of waiting for a periodic assessment.
Continuous pen testing is especially important for organizations that have an agile development cycle. Since new code is deployed frequently, there is a greater chance for security vulnerabilities to be introduced.
Pen testing as a service models is where continuous pen testing shine. Outpost24’s PTaaS (Penetration-Testing-as-a-Service) platform enables businesses to conduct continuous pen testing with ease. The Outpost24 platform is always up-to-date with an organization’s latest security threats and vulnerabilities, so you can be confident that your web applications are secure.
Manual and automated pen testing: Outpost24’s PTaaS platform combines manual and automated pen testing to give you the best of both worlds. This means you can find and fix vulnerabilities faster while still getting the benefits of expert analysis.
Provides comprehensive coverage: Outpost24’s platform covers all OWASP Top 10 vulnerabilities and more. This means that you can be confident that your web applications are secure against the latest threats.
Is cost-effective: With Outpost24, you only pay for the services you need. This makes it more affordable to conduct continuous pen testing, even for small businesses.
Regular pen testing is essential for secure web application development. Depending on your organization’s size, industry, and development cycle, you may need to revise your pen testing schedule.
Once-a-year pen testing cycle may be enough for some organizations, but for most, it is not. For business-critical, customer-facing, or high-traffic web applications, you should consider continuous pen testing.
Outpost24’s PTaaS platform makes it easy and cost-effective to conduct continuous pen testing. Contact us today to learn more about our platform and how we can help you secure your web applications.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
The Border Gateway Protocol (BGP) is the glue that keeps the entire Internet together. However, despite its vital function, BGP wasn’t originally designed to protect against malicious actors or routing mishaps. It has since been updated to account for this shortcoming with the Resource Public Key Infrastructure (RPKI) framework, but can we declare it to be safe yet?
If the question needs asking, you might suspect we can’t. There is a shortage of reliable data on how much of the Internet is protected from preventable routing problems. Today, we’re releasing a new method to measure exactly that: what percentage of Internet users are protected by their Internet Service Provider from these issues. We find that there is a long way to go before the Internet is protected from routing problems, though it varies dramatically by country.
Why RPKI is necessary to secure Internet routing
The Internet is a network of independently-managed networks, called Autonomous Systems (ASes). To achieve global reachability, ASes interconnect with each other and determine the feasible paths to a given destination IP address by exchanging routing information using BGP. BGP enables routers with only local network visibility to construct end-to-end paths based on the arbitrary preferences of each administrative entity that operates that equipment. Typically, Internet traffic between a user and a destination traverses multiple AS networks using paths constructed by BGP routers.
BGP, however, lacks built-in security mechanisms to protect the integrity of the exchanged routing information and to provide authentication and authorization of the advertised IP address space. Because of this, AS operators must implicitly trust that the routing information exchanged through BGP is accurate. As a result, the Internet is vulnerable to the injection of bogus routing information, which cannot be mitigated by security measures at the client or server level of the network.
An adversary with access to a BGP router can inject fraudulent routes into the routing system, which can be used to execute an array of attacks, including:
Denial-of-Service (DoS) through traffic blackholing or redirection,
Impersonation attacks to eavesdrop on communications,
Machine-in-the-Middle exploits to modify the exchanged data, and subvert reputation-based filtering systems.
Additionally, local misconfigurations and fat-finger errors can be propagated well beyond the source of the error and cause major disruption across the Internet.
Such an incident happened on June 24, 2019. Millions of users were unable to access Cloudflare address space when a regional ISP in Pennsylvania accidentally advertised routes to Cloudflare through their capacity-limited network. This was effectively the Internet equivalent of routing an entire freeway through a neighborhood street.
The most prominent proposals to secure BGP routing, standardized by the IETF focus on validating the origin of the advertised routes using Resource Public Key Infrastructure (RPKI) and verifying the integrity of the paths with BGPsec. Specifically, RPKI (defined in RFC 7115) relies on a Public Key Infrastructure to validate that an AS advertising a route to a destination (an IP address space) is the legitimate owner of those IP addresses.
RPKI has been defined for a long time but lacks adoption. It requires network operators to cryptographically sign their prefixes, and routing networks to perform an RPKI Route Origin Validation (ROV) on their routers. This is a two-step operation that requires coordination and participation from many actors to be effective.
The two phases of RPKI adoption: signing origins and validating origins
RPKI has two phases of deployment: first, an AS that wants to protect its own IP prefixes can cryptographically sign Route Origin Authorization (ROA) records thereby attesting to be the legitimate origin of that signed IP space. Second, an AS can avoid selecting invalid routes by performing Route Origin Validation (ROV, defined in RFC 6483).
With ROV, a BGP route received by a neighbor is validated against the available RPKI records. A route that is valid or missing from RPKI is selected, while a route with RPKI records found to be invalid is typically rejected, thus preventing the use and propagation of hijacked and misconfigured routes.
One issue with RPKI is the fact that implementing ROA is meaningful only if other ASes implement ROV, and vice versa. Therefore, securing BGP routing requires a united effort and a lack of broader adoption disincentivizes ASes from commiting the resources to validate their own routes. Conversely, increasing RPKI adoption can lead to network effects and accelerate RPKI deployment. Projects like MANRS and Cloudflare’s isbgpsafeyet.com are promoting good Internet citizenship among network operators, and make the benefits of RPKI deployment known to the Internet. You can check whether your own ISP is being a good Internet citizen by testing it on isbgpsafeyet.com.
Measuring the extent to which both ROA (signing of addresses by the network that controls them) and ROV (filtering of invalid routes by ISPs) have been implemented is important to evaluating the impact of these initiatives, developing situational awareness, and predicting the impact of future misconfigurations or attacks.
Measuring ROAs is straightforward since ROA data is readily available from RPKI repositories. Querying RPKI repositories for publicly routed IP prefixes (e.g. prefixes visible in the RouteViews and RIPE RIS routing tables) allows us to estimate the percentage of addresses covered by ROA objects. Currently, there are 393,344 IPv4 and 86,306 IPv6 ROAs in the global RPKI system, covering about 40% of the globally routed prefix-AS origin pairs1.
Measuring ROV, however, is significantly more challenging given it is configured inside the BGP routers of each AS, not accessible by anyone other than each router’s administrator.
Measuring ROV deployment
Although we do not have direct access to the configuration of everyone’s BGP routers, it is possible to infer the use of ROV by comparing the reachability of RPKI-valid and RPKI-invalid prefixes from measurement points within an AS2.
Consider the following toy topology as an example, where an RPKI-invalid origin is advertised through AS0 to AS1 and AS2. If AS1 filters and rejects RPKI-invalid routes, a user behind AS1 would not be able to connect to that origin. By contrast, if AS2 does not reject RPKI invalids, a user behind AS2 would be able to connect to that origin.
While occasionally a user may be unable to access an origin due to transient network issues, if multiple users act as vantage points for a measurement system, we would be able to collect a large number of data points to infer which ASes deploy ROV.
If, in the figure above, AS0 filters invalid RPKI routes, then vantage points in both AS1 and AS2 would be unable to connect to the RPKI-invalid origin, making it hard to distinguish if ROV is deployed at the ASes of our vantage points or in an AS along the path. One way to mitigate this limitation is to announce the RPKI-invalid origin from multiple locations from an anycast network taking advantage of its direct interconnections to the measurement vantage points as shown in the figure below. As a result, an AS that does not itself deploy ROV is less likely to observe the benefits of upstream ASes using ROV, and we would be able to accurately infer ROV deployment per AS3.
Note that it’s also important that the IP address of the RPKI-invalid origin should not be covered by a less specific prefix for which there is a valid or unknown RPKI route, otherwise even if an AS filters invalid RPKI routes its users would still be able to find a route to that IP.
The measurement technique described here is the one implemented by Cloudflare’s isbgpsafeyet.com website, allowing end users to assess whether or not their ISPs have deployed BGP ROV.
The isbgpsafeyet.com website itself doesn’t submit any data back to Cloudflare, but recently we started measuring whether end users’ browsers can successfully connect to invalid RPKI origins when ROV is present. We use the same mechanism as is used for global performance data4. In particular, every measurement session (an individual end user at some point in time) attempts a request to both valid.rpki.cloudflare.com, which should always succeed as it’s RPKI-valid, and invalid.rpki.cloudflare.com, which is RPKI-invalid and should fail when the user’s ISP uses ROV.
This allows us to have continuous and up-to-date measurements from hundreds of thousands of browsers on a daily basis, and develop a greater understanding of the state of ROV deployment.
The state of global ROV deployment
The figure below shows the raw number of ROV probe requests per hour during October 2022 to valid.rpki.cloudflare.com and invalid.rpki.cloudflare.com. In total, we observed 69.7 million successful probes from 41,531 ASNs.
Based on APNIC’s estimates on the number of end users per ASN, our weighted5 analysis covers 96.5% of the world’s Internet population. As expected, the number of requests follow a diurnal pattern which reflects established user behavior in daily and weekly Internet activity6.
We can also see that the number of successful requests to valid.rpki.cloudflare.com (gray line) closely follows the number of sessions that issued at least one request (blue line), which works as a smoke test for the correctness of our measurements.
As we don’t store the IP addresses that contribute measurements, we don’t have any way to count individual clients and large spikes in the data may introduce unwanted bias. We account for that by capturing those instants and excluding them.
Overall, we estimate thatout of the four billion Internet users, only 261 million (6.5%) are protected by BGP Route Origin Validation, but the true state of global ROV deployment is more subtle than this.
The following map shows the fraction of dropped RPKI-invalid requests from ASes with over 200 probes over the month of October. It depicts how far along each country is in adopting ROV but doesn’t necessarily represent the fraction of protected users in each country, as we will discover.
Sweden and Bolivia appear to be the countries with the highest level of adoption (over 80%), while only a few other countries have crossed the 50% mark (e.g. Finland, Denmark, Chad, Greece, the United States).
ROV adoption may be driven by a few ASes hosting large user populations, or by many ASes hosting small user populations. To understand such disparities, the map below plots the contrast between overall adoption in a country (as in the previous map) and median adoption over the individual ASes within that country. Countries with stronger reds have relatively few ASes deploying ROV with high impact, while countries with stronger blues have more ASes deploying ROV but with lower impact per AS.
In the Netherlands, Denmark, Switzerland, or the United States, adoption appears mostly driven by their larger ASes, while in Greece or Yemen it’s the smaller ones that are adopting ROV.
The following histogram summarizes the worldwide level of adoption for the 6,765 ASes covered by the previous two maps.
Most ASes either don’t validate at all, or have close to 100% adoption, which is what we’d intuitively expect. However, it’s interesting to observe that there are small numbers of ASes all across the scale. ASes that exhibit partial RPKI-invalid drop rate compared to total requests may either implement ROV partially (on some, but not all, of their BGP routers), or appear as dropping RPKI invalids due to ROV deployment by other ASes in their upstream path.
To estimate the number of users protected by ROV we only considered ASes with an observed adoption above 95%, as an AS with an incomplete deployment still leaves its users vulnerable to route leaks from its BGP peers.
If we take the previous histogram and summarize by the number of users behind each AS, the green bar on the right corresponds to the 261 million users currently protected by ROV according to the above criteria (686 ASes).
Looking back at the country adoption map one would perhaps expect the number of protected users to be larger. But worldwide ROV deployment is still mostly partial, lacking larger ASes, or both. This becomes even more clear when compared with the next map, plotting just the fraction of fully protected users.
To wrap up our analysis, we look at two world economies chosen for their contrasting, almost symmetrical, stages of deployment: the United States and the European Union.
112 million Internet users are protected by 111 ASes from the United States with comprehensive ROV deployments. Conversely, more than twice as many ASes from countries making up the European Union have fully deployed ROV, but end up covering only half as many users. This can be reasonably explained by end user ASes being more likely to operate within a single country rather than span multiple countries.
Conclusion
Probe requests were performed from end user browsers and very few measurements were collected from transit providers (which have few end users, if any). Also, paths between end user ASes and Cloudflare are often very short (a nice outcome of our extensive peering) and don’t traverse upper-tier networks that they would otherwise use to reach the rest of the Internet.
In other words, the methodology used focuses on ROV adoption by end user networks (e.g. ISPs) and isn’t meant to reflect the eventual effect of indirect validation from (perhaps validating) upper-tier transit networks. While indirect validation may limit the “blast radius” of (malicious or accidental) route leaks, it still leaves non-validating ASes vulnerable to leaks coming from their peers.
As with indirect validation, an AS remains vulnerable until its ROV deployment reaches a sufficient level of completion. We chose to only consider AS deployments above 95% as truly comprehensive, and Cloudflare Radar will soon begin using this threshold to track ROV adoption worldwide, as part of our mission to help build a better Internet.
When considering only comprehensive ROV deployments, some countries such as Denmark, Greece, Switzerland, Sweden, or Australia, already show an effective coverage above 50% of their respective Internet populations, with others like the Netherlands or the United States slightly above 40%, mostly driven by few large ASes rather than many smaller ones.
Worldwide we observe a very low effective coverage of just 6.5% over the measured ASes, corresponding to 261 million end users currently safe from (malicious and accidental) route leaks, which means there’s still a long way to go before we can declare BGP to be safe.
…… 1https://rpki.cloudflare.com/ 2Gilad, Yossi, Avichai Cohen, Amir Herzberg, Michael Schapira, and Haya Shulman. “Are we there yet? On RPKI’s deployment and security.” Cryptology ePrint Archive (2016). 3Geoff Huston. “Measuring ROAs and ROV”. https://blog.apnic.net/2021/03/24/measuring-roas-and-rov/ 4Measurements are issued stochastically when users encounter 1xxx error pages from default (non-customer) configurations. 5Probe requests are weighted by AS size as calculated from Cloudflare’s worldwide HTTP traffic. 6Quan, Lin, John Heidemann, and Yuri Pradkin. “When the Internet sleeps: Correlating diurnal networks with external factors.” In Proceedings of the 2014 Conference on Internet Measurement Conference, pp. 87-100. 2014.
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.
Reverse-engineering reveals close similarities to BlackMatter ransomware, with some improvements
A postmortem analysis of multiple incidents in which attackers eventually launched the latest version of LockBit ransomware (known variously as LockBit 3.0 or ‘LockBit Black’), revealed the tooling used by at least one affiliate. Sophos’ Managed Detection and Response (MDR) team has observed both ransomware affiliates and legitimate penetration testers use the same collection of tooling over the past 3 months.
Leaked data about LockBit that showed the backend controls for the ransomware also seems to indicate that the creators have begun experimenting with the use of scripting that would allow the malware to “self-spread” using Windows Group Policy Objects (GPO) or the tool PSExec, potentially making it easier for the malware to laterally move and infect computers without the need for affiliates to know how to take advantage of these features for themselves, potentially speeding up the time it takes them to deploy the ransomware and encrypt targets.
A reverse-engineering analysis of the LockBit functionality shows that the ransomware has carried over most of its functionality from LockBit 2.0 and adopted new behaviors that make it more difficult to analyze by researchers. For instance, in some cases it now requires the affiliate to use a 32-character ‘password’ in the command line of the ransomware binary when launched, or else it won’t run, though not all the samples we looked at required the password.
We also observed that the ransomware runs with LocalServiceNetworkRestricted permissions, so it does not need full Administrator-level access to do its damage (supporting observations of the malware made by other researchers).
Most notably, we’ve observed (along with other researchers) that many LockBit 3.0 features and subroutines appear to have been lifted directly from BlackMatter ransomware.
Is LockBit 3.0 just ‘improved’ BlackMatter?
Other researchers previously noted that LockBit 3.0 appears to have adopted (or heavily borrowed) several concepts and techniques from the BlackMatter ransomware family.
We dug into this ourselves, and found a number of similarities which strongly suggest that LockBit 3.0 reuses code from BlackMatter.
Anti-debugging trick
Blackmatter and Lockbit 3.0 use a specific trick to conceal their internal functions calls from researchers. In both cases, the ransomware loads/resolves a Windows DLL from its hash tables, which are based on ROT13.
It will try to get pointers from the functions it needs by searching the PEB (Process Environment Block) of the module. It will then look for a specific binary data marker in the code (0xABABABAB) at the end of the heap; if it finds this marker, it means someone is debugging the code, and it doesn’t save the pointer, so the ransomware quits.
After these checks, it will create a special stub for each API it requires. There are five different types of stubs that can be created (randomly). Each stub is a small piece of shellcode that performs API hash resolution on the fly and jumps to the API address in memory. This adds some difficulties while reversing using a debugger.
The first stub, as an example (decoded with CyberChef)
Obfuscation of strings
Many strings in both LockBit 3.0 and BlackMatter are obfuscated, resolved during runtime by pushing the obfuscated strings on to the stack and decrypting with an XOR function. In both LockBit and BlackMatter, the code to achieve this is very similar.
Georgia Tech student Chuong Dong analyzed BlackMatter and showed this feature on his blog, with the screenshot above.
LockBit’s string obfuscation, in comparison
By comparison, LockBit 3.0 has adopted a string obfuscation method that looks and works in a very similar fashion to BlackMatter’s function.
API resolution
LockBit uses exactly the same implementation as BlackMatter to resolve API calls, with one exception: LockBit adds an extra step in an attempt to conceal the function from debuggers.
BlackMatter’s dynamic API resolution (image credit: Chuong Dong)
The array of calls performs precisely the same function in LockBit 3.0.
LockBit’s dynamic API resolution
Hiding threads
Both LockBit and BlackMatter hide threads using the NtSetInformationThread function, with the parameter ThreadHideFromDebugger. As you probably can guess, this means that the debugger doesn’t receive events related to this thread.
LockBit employs the same ThreadHideFromDebugger feature as an evasion technique
Printing
LockBit, like BlackMatter, sends ransom notes to available printers.
LockBit can send its ransom notes directly to printers, as BlackMatter can do
Deletion of shadow copies
Both ransomware will sabotage the infected computer’s ability to recover from file encryption by deleting the Volume Shadow Copy files.
LockBit calls the IWbemLocator::ConnectServer method to connect with the local ROOT\CIMV2 namespace and obtain the pointer to an IWbemServices object that eventually calls IWbemServices::ExecQuery to execute the WQL query.
BlackMatter code for deleting shadow copies (image credit: Chuong Dong)
LockBit’s method of doing this is identical to BlackMatter’s implementation, except that it adds a bit of string obfuscation to the subroutine.
LockBit’s deletion of shadow copies
Enumerating DNS hostnames
Both LockBit and BlackMatter enumerate hostnames on the network by calling NetShareEnum.
BlackMatter calls NetShareEnum() to enumerate hostnames… (image credit: Chuong Dong)
In the source code for LockBit, the function looks like it has been copied, verbatim, from BlackMatter.
…as does LockBit
Determining the operating system version
Both ransomware strains use identical code to check the OS version – even using the same return codes (although this is a natural choice, since the return codes are hexadecimal representations of the version number).
BlackMatter’s code for checking the OS version (image credit: Chuong Dong)LockBit’s OS enumeration routine
Configuration
Both ransomware contain embedded configuration data inside their binary executables. We noted that LockBit decodes its config in a similar way to BlackMatter, albeit with some small differences.
For instance, BlackMatter saves its configuration in the .rsrc section, whereas LockBit stores it in .pdata.
And LockBit uses a different linear congruential generator (LCG) algorithm for decoding.
LockBit’s config decryption routine
Some researchers have speculated that the close relationship between the LockBit and BlackMatter code indicates that one or more of BlackMatter’s coders were recruited by LockBit; that LockBit bought the BlackMatter codebase; or a collaboration between developers. As we noted in our white paper on multiple attackers earlier this year, it’s not uncommon for ransomware groups to interact, either inadvertently or deliberately.
Either way, these findings are further evidence that the ransomware ecosystem is complex, and fluid. Groups reuse, borrow, or steal each other’s ideas, code, and tactics as it suits them. And, as the LockBit 3.0 leak site (containing, among other things, a bug bounty and a reward for “brilliant ideas”) suggests, that gang in particular is not averse to paying for innovation.
LockBit tooling mimics what legitimate pentesters would use
Another aspect of the way LockBit 3.0’s affiliates are deploying the ransomware shows that they’re becoming very difficult to distinguish from the work of a legitimate penetration tester – aside from the fact that legitimate penetration testers, of course, have been contracted by the targeted company beforehand, and are legally allowed to perform the pentest.
The tooling we observed the attackers using included a package from GitHub called Backstab. The primary function of Backstab is, as the name implies, to sabotage the tooling that analysts in security operations centers use to monitor for suspicious activity in real time. The utility uses Microsoft’s own Process Explorer driver (signed by Microsoft) to terminate protected anti-malware processes and disable EDR utilities. Both Sophos and other researchers have observed LockBit attackers using Cobalt Strike, which has become a nearly ubiquitous attack tool among ransomware threat actors, and directly manipulating Windows Defender to evade detection.
Further complicating the parentage of LockBit 3.0 is the fact that we also encountered attackers using a password-locked variant of the ransomware, called lbb_pass.exe , which has also been used by attackers that deploy REvil ransomware. This may suggest that there are threat actors affiliated with both groups, or that threat actors not affiliated with LockBit have taken advantage of the leaked LockBit 3.0 builder. At least one group, BlooDy, has reportedly used the builder, and if history is anything to go by, more may follow suit.
LockBit 3.0 attackers also used a number of publicly-available tools and utilities that are now commonplace among ransomware threat actors, including the anti-hooking utility GMER, a tool called AV Remover published by antimalware company ESET, and a number of PowerShell scripts designed to remove Sophos products from computers where Tamper Protection has either never been enabled, or has been disabled by the attackers after they obtained the credentials to the organization’s management console.
We also saw evidence the attackers used a tool called Netscan to probe the target’s network, and of course, the ubiquitous password-sniffer Mimikatz.
Incident response makes no distinction
Because these utilities are in widespread use, MDR and Rapid Response treats them all equally – as though an attack is underway – and immediately alerts the targets when they’re detected.
We found the attackers took advantage of less-than-ideal security measures in place on the targeted networks. As we mentioned in our Active Adversaries Report on multiple ransomware attackers, the lack of multifactor authentication (MFA) on critical internal logins (such as management consoles) permits an intruder to use tooling that can sniff or keystroke-capture administrators’ passwords and then gain access to that management console.
It’s safe to assume that experienced threat actors are at least as familiar with Sophos Central and other console tools as the legitimate users of those consoles, and they know exactly where to go to weaken or disable the endpoint protection software. In fact, in at least one incident involving a LockBit threat actor, we observed them downloading files which, from their names, appeared to be intended to remove Sophos protection: sophoscentralremoval-master.zip and sophos-removal-tool-master.zip. So protecting those admin logins is among the most critically important steps admins can take to defend their networks.
For a list of IOCs associated with LockBit 3.0, please see our GitHub.
Acknowledgments
Sophos X-Ops acknowledges the collaboration of Colin Cowie, Gabor Szappanos, Alex Vermaning, and Steeve Gaudreault in producing this report.
In part one, we discussed what numerical control machines do and their basic concepts. These concepts are important to understand the machines better, offering a wider view of their operations. We also laid out how we evaluated the chosen vendors for our research.
For this blog, we will continue discussing our evaluated vendors and highlighting findings that we discovered during our research.
Haas
Figure 1. The Haas simulator we used for preliminary testing (left) and the Haas CNC machine (Super Mini Mill 2) by Celada we used for verification (right)
Haas was the first vendor we focused on because of the fast availability of its controller. We began our analysis by conducting port scanning on the controller simulator and identifying the protocols exposed by the controller. After that, we evaluated the options with which an attacker could abuse the protocols to perform attacks aimed at the security of the machine and verified these attacks in practice on a real-world machine installation.
Okuma
Figure 2. The Okuma simulator we used for the development of the malicious application and during the initial testing
Okuma stands out in the market of CNC controllers for one interesting feature: the modularity of its controller. While the vendor offers in the device’s simplest form a tiny controller, it also provides a mechanism, called THINC API, to highly customize the functionalities of the controller. With this technology, any developer can implement a program that, once installed, runs in the context of the controller, in the form of an extension. This approach is very similar to how a mobile application, once installed, can extend a smartphone’s functionalities.
Heidenhain
Figure 3. The Hartford 5A-65E machine, running on a Heidenhain TNC 640 controller, that we used in our experiments at Celada
In the spirit of the Industry 4.0 paradigm, Heidenhain offers the Heidenhain DNC interface to integrate machines on modern, digital shop floors. Among the many scenarios, Heidenhain DNC enables the automatic exchange of data with machine and production data acquisition (MDA/PDA) systems, higher level enterprise resource planning (ERP) and manufacturing execution systems (MESs), inventory management systems, computer-aided design and manufacturing (CAD/CAM) systems, production activity control systems, simulation tools, and tool management systems
In our evaluation, we had access to the library provided by Heidenhain to the integrators to develop interfaces for the controller. The manufacturer provides this library, called RemoTools SDK,35 to selected partners only.
Fanuc
Figure 4. The Yasuda YMC 430 + RT10 machine, running on a Fanuc controller, that we used in our experiments at the Polytechnic University of Milan
Like Heidenhain, Fanuc offers an interface, called FOCAS,36 for the integration of CNC machines in smart network environments. Even though this technology offers a restricted set of remote-call possibilities compared with the other vendors’ (that is, a limited number of management features), our experiments showed that a miscreant could potentially conduct attacks like damage, DoS, and hijacking.
What we found
As our evaluation identified 18 different attacks (or variations), we grouped them into five classes: compromise, damage, and denial of service (DoS):
Table 1. A summary of the attacks we identified in our research
Controller manufacturers like Haas, Okuma, and Heidenhain have been found to have a similar number of issues, around 15. Fanuc had 10 confirmed attacks. Unfortunately, our research shows that this domain lacks awareness concerning security and privacy. This creates serious and compelling problems.
The need for automation-facing features like remote configuration of tool geometry or parametric programming with values determined by networked resources is becoming more common in manufacturing.
With these findings, we determined countermeasures that enterprises can do to mitigate such risks, which we’ll discuss in our final installation. In the last part, we’ll also discuss our responsible disclosure process.
Actions to Help Protect Against APT Cyber Activity:
• Enforce multifactor authentication (MFA) on all user accounts. • Implement network segmentation to separate network segments based on role and functionality. • Update software, including operating systems, applications, and firmware, on network assets. • Audit account usage.
From November 2021 through January 2022, the Cybersecurity and Infrastructure Security Agency (CISA) responded to advanced persistent threat (APT) activity on a Defense Industrial Base (DIB) Sector organization’s enterprise network. During incident response activities, CISA uncovered that likely multiple APT groups compromised the organization’s network, and some APT actors had long-term access to the environment. APT actors used an open-source toolkit called Impacket to gain their foothold within the environment and further compromise the network, and also used a custom data exfiltration tool, CovalentStealer, to steal the victim’s sensitive data.
This joint Cybersecurity Advisory (CSA) provides APT actors tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) identified during the incident response activities by CISA and a third-party incident response organization. The CSA includes detection and mitigation actions to help organizations detect and prevent related APT activity. CISA, the Federal Bureau of Investigation (FBI), and the National Security Agency (NSA) recommend DIB sector and other critical infrastructure organizations implement the mitigations in this CSA to ensure they are managing and reducing the impact of cyber threats to their networks.
Download the PDF version of this report: pdf, 692 KB
For a downloadable copy of IOCs, see the following files:
Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 11. See the MITRE ATT&CK Tactics and Techniques section for a table of the APT cyber activity mapped to MITRE ATT&CK for Enterprise framework.
From November 2021 through January 2022, CISA conducted an incident response engagement on a DIB Sector organization’s enterprise network. The victim organization also engaged a third-party incident response organization for assistance. During incident response activities, CISA and the trusted –third-party identified APT activity on the victim’s network.
Some APT actors gained initial access to the organization’s Microsoft Exchange Server as early as mid-January 2021. The initial access vector is unknown. Based on log analysis, the actors gathered information about the exchange environment and performed mailbox searches within a four-hour period after gaining access. In the same period, these actors used a compromised administrator account (“Admin 1”) to access the EWS Application Programming Interface (API). In early February 2021, the actors returned to the network and used Admin 1 to access EWS API again. In both instances, the actors used a virtual private network (VPN).
Four days later, the APT actors used Windows Command Shell over a three-day period to interact with the victim’s network. The actors used Command Shell to learn about the organization’s environment and to collect sensitive data, including sensitive contract-related information from shared drives, for eventual exfiltration. The actors manually collected files using the command-line tool, WinRAR. These files were split into approximately 3MB chunks located on the Microsoft Exchange server within the CU2\he\debug directory. See Appendix: Windows Command Shell Activity for additional information, including specific commands used.
During the same period, APT actors implanted Impacket, a Python toolkit for programmatically constructing and manipulating network protocols, on another system. The actors used Impacket to attempt to move laterally to another system.
In early March 2021, APT actors exploited CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 to install 17 China Chopper webshells on the Exchange Server. Later in March, APT actors installed HyperBro on the Exchange Server and two other systems. For more information on the HyperBro and webshell samples, see CISA MAR-10365227-2 and -3.
In April 2021, APT actors used Impacket for network exploitation activities. See the Use of Impacket section for additional information. From late July through mid-October 2021, APT actors employed a custom exfiltration tool, CovalentStealer, to exfiltrate the remaining sensitive files. See the Use of Custom Exfiltration Tool: CovalentStealer section for additional information.
APT actors maintained access through mid-January 2022, likely by relying on legitimate credentials.
Use of Impacket
CISA discovered activity indicating the use of two Impacket tools: wmiexec.py and smbexec.py. These tools use Windows Management Instrumentation (WMI) and Server Message Block (SMB) protocol, respectively, for creating a semi-interactive shell with the target device. Through the Command Shell, an Impacket user with credentials can run commands on the remote device using the Windows management protocols required to support an enterprise network.
The APT cyber actors used existing, compromised credentials with Impacket to access a higher privileged service account used by the organization’s multifunctional devices. The threat actors first used the service account to remotely access the organization’s Microsoft Exchange server via Outlook Web Access (OWA) from multiple external IP addresses; shortly afterwards, the actors assigned the Application Impersonation role to the service account by running the following PowerShell command for managing Exchange:
This command gave the service account the ability to access other users’ mailboxes.
The APT cyber actors used virtual private network (VPN) and virtual private server (VPS) providers, M247 and SurfShark, as part of their techniques to remotely access the Microsoft Exchange server. Use of these hosting providers, which serves to conceal interaction with victim networks, are common for these threat actors. According to CISA’s analysis of the victim’s Microsoft Exchange server Internet Information Services (IIS) logs, the actors used the account of a former employee to access the EWS. EWS enables access to mailbox items such as email messages, meetings, and contacts. The source IP address for these connections is mostly from the VPS hosting provider, M247.
Use of Custom Exfiltration Tool: CovalentStealer
The threat actors employed a custom exfiltration tool, CovalentStealer, to exfiltrate sensitive files.
CovalentStealer is designed to identify file shares on a system, categorize the files, and upload the files to a remote server. CovalentStealer includes two configurations that specifically target the victim’s documents using predetermined files paths and user credentials. CovalentStealer stores the collected files on a Microsoft OneDrive cloud folder, includes a configuration file to specify the types of files to collect at specified times and uses a 256-bit AES key for encryption. See CISA MAR-10365227-1 for additional technical details, including IOCs and detection signatures.
MITRE ATT&CK Tactics and Techniques
MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. CISA uses the ATT&CK Framework as a foundation for the development of specific threat models and methodologies. Table 1 lists the ATT&CK techniques employed by the APT actors.
Actors obtained and abused credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. In this case, they exploited an organization’s multifunctional device domain account used to access the organization’s Microsoft Exchange server via OWA.
Actors abused PowerShell commands and scripts to map shared drives by specifying a path to one location and retrieving the items from another. See Appendix: Windows Command Shell Activity for additional information.
Command and Scripting Interpreter: Windows Command Shell
Actors abused the Windows Command Shell to learn about the organization’s environment and to collect sensitive data. See Appendix: Windows Command Shell Activity for additional information, including specific commands used.The actors used Impacket tools, which enable a user with credentials to run commands on the remote device through the Command Shell.
Actors executed malicious payloads via loading shared modules. The Windows module loader can be instructed to load DLLs from arbitrary local paths and arbitrary Universal Naming Convention (UNC) network paths.
Actors obtained and abused credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.
Actors obtained and abused credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. In this case, they exploited an organization’s multifunctional device domain account used to access the organization’s Microsoft Exchange server via OWA.
Actors obtained and abused credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. In this case, they exploited an organization’s multifunctional device domain account used to access the organization’s Microsoft Exchange server via OWA.
Actors used Windows command shell commands to detect and avoid virtualization and analysis environments. See Appendix: Windows Command Shell Activity for additional information.
Actors used the taskkill command to probably disable security features. CISA was unable to determine which application was associated with the Process ID.
Actors used the systeminfo command to look for details about the network configurations and settings and determine if the system was a VMware virtual machine.The threat actor used route print to display the entries in the local IP routing table.
System Network Configuration Discovery: Internet Connection Discovery
Actors checked for internet connectivity on compromised systems. This may be performed during automated discovery and can be accomplished in numerous ways.
Actors attempted to identify the primary user, currently logged in user, set of users that commonly use a system, or whether a user is actively using the system.
Actors used the tasklist command to get information about running processes on a system and determine if the system was a VMware virtual machine.The actors used tasklist.exe and find.exe to display a list of applications and services with their PIDs for all tasks running on the computer matching the string “powers.”
Actors used the ipconfig command to get detailed information about the operating system and hardware and determine if the system was a VMware virtual machine.
Actors likely used net share command to display information about shared resources on the local computer and decide which directories to exploit, the powershell dircommand to map shared drives to a specified path and retrieve items from another, and the ntfsinfo command to search network shares on computers they have compromised to find files of interest.The actors used dir.exe to display a list of a directory’s files and subdirectories matching a certain text string.
Actors used a non-application layer protocol for communication between host and Command and Control (C2) server or among infected hosts within a network.
Actors used the certutil command with three switches to test if they could download files from the internet.The actors employed CovalentStealer to exfiltrate the files.
Actors scheduled data exfiltration to be performed only at certain times of day or at certain intervals and blend traffic patterns with normal activity.
Exfiltration Over Web Service: Exfiltration to Cloud Storage
The actor’s CovalentStealer tool stores collected files on a Microsoft OneDrive cloud folder.
DETECTION
Given the actors’ demonstrated capability to maintain persistent, long-term access in compromised enterprise environments, CISA, FBI, and NSA encourage organizations to:
Monitor logs for connections from unusual VPSs and VPNs. Examine connection logs for access from unexpected ranges, particularly from machines hosted by SurfShark and M247.
Monitor for suspicious account use (e.g., inappropriate or unauthorized use of administrator accounts, service accounts, or third-party accounts). To detect use of compromised credentials in combination with a VPS, follow the steps below:
Review logs for “impossible logins,” such as logins with changing username, user agent strings, and IP address combinations or logins where IP addresses do not align to the expected user’s geographic location.
Search for “impossible travel,” which occurs when a user logs in from multiple IP addresses that are a significant geographic distance apart (i.e., a person could not realistically travel between the geographic locations of the two IP addresses in the time between logins). Note: This detection opportunity can result in false positives if legitimate users apply VPN solutions before connecting to networks.
Search for one IP used across multiple accounts, excluding expected logins.
Take note of any M247-associated IP addresses used along with VPN providers (e.g., SurfShark). Look for successful remote logins (e.g., VPN, OWA) for IPs coming from M247- or using SurfShark-registered IP addresses.
Identify suspicious privileged account use after resetting passwords or applying user account mitigations.
Search for unusual activity in typically dormant accounts.
Search for unusual user agent strings, such as strings not typically associated with normal user activity, which may indicate bot activity.
Review the YARA rules provided in MAR-10365227-1 to assist in determining whether malicious activity has been observed.
Monitor for the installation of unauthorized software, including Remote Server Administration Tools (e.g., psexec, RdClient, VNC, and ScreenConnect).
Monitor for anomalous and known malicious command-line use. See Appendix: Windows Command Shell Activity for commands used by the actors to interact with the victim’s environment.
Monitor for unauthorized changes to user accounts (e.g., creation, permission changes, and enabling a previously disabled account).
CONTAINMENT AND REMEDIATION
Organizations affected by active or recently active threat actors in their environment can take the following initial steps to aid in eviction efforts and prevent re-entry:
Report the incident. Report the incident to U.S. Government authorities and follow your organization’s incident response plan.
Report incidents to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870).
For DIB incident reporting, contact the Defense Cyber Crime Center (DC3) via DIBNET at dibnet.dod.mil/portal/intranet or (410) 981 0104.
Reset all login accounts. Reset all accounts used for authentication since it is possible that the threat actors have additional stolen credentials. Password resets should also include accounts outside of Microsoft Active Directory, such as network infrastructure devices and other non-domain joined devices (e.g., IoT devices).
Monitor SIEM logs and build detections. Create signatures based on the threat actor TTPs and use these signatures to monitor security logs for any signs of threat actor re-entry.
Enforce MFA on all user accounts. Enforce phishing-resistant MFA on all accounts without exception to the greatest extent possible.
Audit accounts and permissions. Audit all accounts to ensure all unused accounts are disabled or removed and active accounts do not have excessive privileges. Monitor SIEM logs for any changes to accounts, such as permission changes or enabling a previously disabled account, as this might indicate a threat actor using these accounts.
Mitigation recommendations are usually longer-term efforts that take place before a compromise as part of risk management efforts, or after the threat actors have been evicted from the environment and the immediate response actions are complete. While some may be tailored to the TTPs used by the threat actor, recovery recommendations are largely general best practices and industry standards aimed at bolstering overall cybersecurity posture.
Segment Networks Based on Function
Implement network segmentation to separate network segments based on role and functionality. Proper network segmentation significantly reduces the ability for ransomware and other threat actor lateral movement by controlling traffic flows between—and access to—various subnetworks. (See CISA’s Infographic on Layering Network Security Through Segmentation and NSA’s Segment Networks and Deploy Application-Aware Defenses.)
Isolate similar systems and implement micro-segmentation with granular access and policy restrictions to modernize cybersecurity and adopt Zero Trust (ZT) principles for both network perimeter and internal devices. Logical and physical segmentation are critical to limiting and preventing lateral movement, privilege escalation, and exfiltration.
Manage Vulnerabilities and Configurations
Update software, including operating systems, applications, and firmware, on network assets. Prioritize patching known exploited vulnerabilities and critical and high vulnerabilities that allow for remote code execution or denial-of-service on internet-facing equipment.
Implement a configuration change control process that securely creates device configuration backups to detect unauthorized modifications. When a configuration change is needed, document the change, and include the authorization, purpose, and mission justification. Periodically verify that modifications have not been applied by comparing current device configurations with the most recent backups. If suspicious changes are observed, verify the change was authorized.
Search for Anomalous Behavior
Use cybersecurity visibility and analytics tools to improve detection of anomalous behavior and enable dynamic changes to policy and other response actions. Visibility tools include network monitoring tools and host-based logs and monitoring tools, such as an endpoint detection and response (EDR) tool. EDR tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
Monitor the use of scripting languages (e.g., Python, Powershell) by authorized and unauthorized users. Anomalous use by either group may be indicative of malicious activity, intentional or otherwise.
Restrict and Secure Use of Remote Admin Tools
Limit the number of remote access tools as well as who and what can be accessed using them. Reducing the number of remote admin tools and their allowed access will increase visibility of unauthorized use of these tools.
Use encrypted services to protect network communications and disable all clear text administration services(e.g., Telnet, HTTP, FTP, SNMP 1/2c). This ensures that sensitive information cannot be easily obtained by a threat actor capturing network traffic.
Implement a Mandatory Access Control Model
Implement stringent access controls to sensitive data and resources. Access should be restricted to those users who require access and to the minimal level of access needed.
Audit Account Usage
Monitor VPN logins to look for suspicious access (e.g., logins from unusual geo locations, remote logins from accounts not normally used for remote access, concurrent logins for the same account from different locations, unusual times of the day).
Closely monitor the use of administrative accounts. Admin accounts should be used sparingly and only when necessary, such as installing new software or patches. Any use of admin accounts should be reviewed to determine if the activity is legitimate.
Ensure standard user accounts do not have elevated privileges Any attempt to increase permissions on standard user accounts should be investigated as a potential compromise.
VALIDATE SECURITY CONTROLS
In addition to applying mitigations, CISA, FBI, and NSA recommend exercising, testing, and validating your organization’s security program against threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA, FBI, and NSA recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:
Select an ATT&CK technique described in this advisory (see Table 1).
Align your security technologies against the technique.
Test your technologies against the technique.
Analyze the performance of your detection and prevention technologies.
Repeat the process for all security technologies to obtain a set of comprehensive performance data.
Tune your security program, including people, processes, and technologies, based on the data generated by this process.
CISA, FBI, and NSA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.
RESOURCES
CISA offers several no-cost scanning and testing services to help organizations reduce their exposure to threats by taking a proactive approach to mitigating attack vectors. See cisa.gov/cyber-hygiene-services.
U.S. DIB sector organizations may consider signing up for the NSA Cybersecurity Collaboration Center’s DIB Cybersecurity Service Offerings, including Protective Domain Name System (PDNS) services, vulnerability scanning, and threat intelligence collaboration for eligible organizations. For more information on how to enroll in these services, email dib_defense@cyber.nsa.gov.
ACKNOWLEDGEMENTS
CISA, FBI, and NSA acknowledge Mandiant for its contributions to this CSA.
APPENDIX: WINDOWS COMMAND SHELL ACTIVITY
Over a three-day period in February 2021, APT cyber actors used Windows Command Shell to interact with the victim’s environment. When interacting with the victim’s system and executing commands, the threat actors used /q and /c parameters to turn the echo off, carry out the command specified by a string, and stop its execution once completed.
On the first day, the threat actors consecutively executed many commands within the Windows Command Shell to learn about the organization’s environment and to collect sensitive data for eventual exfiltration (see Table 2).
Command
Description / Use
net share
Used to create, configure, and delete network shares from the command-line.[1] The threat actor likely used this command to display information about shared resources on the local computer and decide which directories to exploit.
powershell dir
An alias (shorthand) for the PowerShell Get-ChildItem cmdlet. This command maps shared drives by specifying a path to one location and retrieving the items from another.[2] The threat actor added additional switches (aka options, parameters, or flags) to form a “one liner,” an expression to describe commonly used commands used in exploitation: powershell dir -recurse -path e:\<redacted>|select fullname,length|export-csv c:\windows\temp\temp.txt. This particular command lists subdirectories of the target environment when.
systeminfo
Displays detailed configuration information [3], tasklist – lists currently running processes [4], and ipconfig – displays all current Transmission Control Protocol (TCP)/IP network configuration values and refreshes Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) settings, respectively [5]. The threat actor used these commands with specific switches to determine if the system was a VMware virtual machine: systeminfo > vmware & date /T, tasklist /v > vmware & date /T, and ipconfig /all >> vmware & date /.
route print
Used to display and modify the entries in the local IP routing table. [6] The threat actor used this command to display the entries in the local IP routing table.
netstat
Used to display active TCP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table, IPv4 statistics, and IPv6 statistics.[7] The threat actor used this command with three switches to display TCP connections, prevent hostname determination of foreign IP addresses, and specify the protocol for TCP: netstat -anp tcp.
certutil
Used to dump and display certification authority (CA) configuration information, configure Certificate Services, backup and restore CA components, and verify certificates, key pairs, and certificate chains.[8] The threat actor used this command with three switches to test if they could download files from the internet: certutil -urlcache -split -f https://microsoft.com temp.html.
ping
Sends Internet Control Message Protocol (ICMP) echoes to verify connectivity to another TCP/IP computer.[9] The threat actor used ping -n 2 apple.com to either test their internet connection or to detect and avoid virtualization and analysis environments or network restrictions.
taskkill
Used to end tasks or processes.[10] The threat actor used taskkill /F /PID 8952 to probably disable security features. CISA was unable to determine what this process was as the process identifier (PID) numbers are dynamic.
PowerShell Compress-Archive cmdlet
Used to create a compressed archive or to zip files from specified files and directories.[11] The threat actor used parameters indicating shared drives as file and folder sources and the destination archive as zipped files. Specifically, they collected sensitive contract-related information from the shared drives.
On the second day, the APT cyber actors executed the commands in Table 3 to perform discovery as well as collect and archive data.
Command
Description / Use
ntfsinfo.exe
Used to obtain volume information from the New Technology File System (NTFS) and to print it along with a directory dump of NTFS meta-data files.[12]
WinRAR.exe
Used to compress files and subsequently masqueraded WinRAR.exe by renaming it VMware.exe.[13]
On the third day, the APT cyber actors returned to the organization’s network and executed the commands in Table 4.
Command
Description / Use
powershell -ep bypass import-module .\vmware.ps1;export-mft -volume e
Threat actors ran a PowerShell command with parameters to change the execution mode and bypass the Execution Policy to run the script from PowerShell and add a module to the current section: powershell -ep bypass import-module .\vmware.ps1;export-mft -volume e. This module appears to acquire and export the Master File Table (MFT) for volume E for further analysis by the cyber actor.[14]
set.exe
Used to display the current environment variable settings.[15] (An environment variable is a dynamic value pointing to system or user environments (folders) of the system. System environment variables are defined by the system and used globally by all users, while user environment variables are only used by the user who declared that variable and they override the system environment variables (even if the variables are named the same).
dir.exe
Used to display a list of a directory’s files and subdirectories matching the eagx* text string, likely to confirm the existence of such file.
tasklist.exe and find.exe
Used to display a list of applications and services with their PIDs for all tasks running on the computer matching the string “powers”.[16][17][18]
ping.exe
Used to send two ICMP echos to amazon.com. This could have been to detect or avoid virtualization and analysis environments, circumvent network restrictions, or test their internet connection.[19]
del.exe with the /f parameter
Used to force the deletion of read-only files with the *.rar and tempg* wildcards.[20]
The global cybersecurity market is flourishing. Experts at Gartner predict that the end-user spending for the information security and risk management market will grow from $172.5 billion in 2022 to $267.3 billion in 2026.
One big area of spending includes the art of putting cybersecurity defenses under pressure, commonly known as security testing. MarketsandMarkets forecasts the global penetration testing (pentesting) market size is expected to grow at a Compound Annual Growth Rate (CAGR) of 13.7% from 2022 to 2027. However, the costs and limitations involved in carrying out a penetration test are already hindering the market growth, and consequently, many cybersecurity professionals are making moves to find an alternative solution.
Pentests aren’t solving cybersecurity pain points
Pentesting can serve specific and important purposes for businesses. For example, prospective customers may ask for the results of one as proof of compliance. However, for certain challenges, this type of security testing methodology isn’t always the best fit.
1 — Continuously changing environments
Securing constantly changing environments within rapidly evolving threat landscapes is particularly difficult. This challenge becomes even more complicated when aligning and managing the business risk of new projects or releases. Since penetration tests focus on one moment in time, the result won’t necessarily be the same the next time you make an update.
2 — Rapid growth
It would be unusual for fast-growing businesses not to experience growing pains. For CISOs, maintaining visibility of their organization’s expanding attack surface can be particularly painful.
According to HelpNetSecurity, 45% of respondents conduct pentests only once or twice per year and 27% do it once per quarter, which is woefully insufficient given how quickly infrastructure and applications change.
3 — Cybersecurity skills shortages
As well as limitations in budgets and resources, finding the available skillsets for internal cybersecurity teams is an ongoing battle. As a result, organizations don’t have the dexterity to spot and promptly remediate specific security vulnerabilities.
While pentests can offer an outsider perspective, often it is just one person performing the test. For some organizations, there is also an issue on trust when relying on the work of just one or two people. Sándor Incze, CISO at CM.com, gives his perspective:
“Not all pentesters are equal. It’s very hard to determine if the pentester you’re hiring is good.”
4 — Cyber threats are evolving
The constant struggle to stay up to date with the latest cyberattack techniques and trends puts media organizations at risk. Hiring specialist skills for every new cyber threat type would be unrealistic and unsustainable.
HelpNetSecurity reported that it takes 71 percent of pentesters one week to one month to conduct a pentest. Then, more than 26 percent of organizations must wait between one to two weeks to get the test results, and 13 percent wait even longer than that. Given the fast pace of threat evolution, this waiting period can leave companies unaware of potential security issues and open to exploitation.
5 — Poor-fitting security testing solutions for agile environments
Continuous development lifecycles don’t align with penetration testing cycles (often performed annually.) Therefore, vulnerabilities mistakenly created during long security testing gaps can remain undiscovered for some time.
Bringing security testing into the 21st-century Impact
A proven solution to these challenges is to utilize ethical hacker communities in addition to a standard penetration test. Businesses can rely on the power of these crowds to assist them in their security testing on a continuous basis. A bug bounty program is one of the most common ways to work with ethical hacker communities.
What is a bug bounty program?
Bug bounty programs allow businesses to proactively work with independent security researchers to report bugs through incentivization. Often companies will launch and manage their program through a bug bounty platform, such as Intigriti.
Organizations with high-security maturity may leave their bug bounty program open for all ethical hackers in the platform’s community to contribute to (known as a public program.) However, most businesses begin by working with a smaller pool of security talent through a private program.
How bug bounty programs support continuous security testing structures
While you’ll receive a certificate to say you’re secure at the end of a penetration test, it won’t necessarily mean that’s still the case the next time you make an update. This is where bug bounty programs work well as a follow-up to pentests and enable a continuous security testing program.
The impact of bug bounty program on cybersecurity
By launching a bug bounty program, organizations experience:
More robust protection: Company data, brand, and reputation have additional protection through continuous security testing.
Enabled business goals: Enhanced security posture, leading to a more secure platform for innovation and growth.
Improved productivity: Increased workflow with fewer disruptions to the availability of services. More strategic IT projects that executives have prioritized, with fewer security “fires” to put out.
Increased skills availability: Internal security team’s time is freed by using a community for security testing and triage.
Clearer budget justification: Ability to provide more significant insights into the organization’s security posture to justify and motivate for an adequate security budget.
Improved relationships: Project delays significantly decrease without the reliance on traditional pentests.
Want to know more about setting up and launching a bug bounty program?
Intigriti is the leading European-based platform for bug bounty and ethical hacking. The platform enables organizations to reduce the risk of a cyberattack by allowing Intigriti’s network of security researchers to test their digital assets for vulnerabilities continuously.
If you’re intrigued by what you’ve read and want to know about bug bounty programs, simply schedule a meeting today with one of our experts.
Cybersecurity company Imperva has disclosed that it mitigated a distributed denial-of-service (DDoS) attack with a total of over 25.3 billion requests on June 27, 2022.
The “strong attack,” which targeted an unnamed Chinese telecommunications company, is said to have lasted for four hours and peaked at 3.9 million requests per second (RPS).
“Attackers used HTTP/2 multiplexing, or combining multiple packets into one, to send multiple requests at once over individual connections,” Imperva said in a report published on September 19.
The attack was launched from a botnet that comprised nearly 170,000 different IP addresses spanning routers, security cameras, and compromised servers located in more than 180 countries, primarily the U.S., Indonesia, and Brazil.
The disclosure also comes as web infrastructure provider Akamai said it fielded a new DDoS assault aimed at a customer based in Eastern Europe on September 12, with attack traffic spiking at 704.8 million packets per second (pps).
The same victim was previously targeted on July 21, 2022, in a similar fashion in which the attack volume ramped up to 853.7 gigabits per second (Gbps) and 659.6 million pps over a period of 14 hours.
Akamai’s Craig Sparling said the company has been “bombarded relentlessly with sophisticated distributed denial-of-service (DDoS) attacks,” indicating that the offensives could be politically motivated in the face of Russia’s ongoing war against Ukraine.
Both the disruptive attempts were UDP flood attacks where the attacker targets and overwhelms arbitrary ports on the target host with User Datagram Protocol (UDP) packets.
UDP, being both connectionless and session-less, makes it an ideal networking protocol for handling VoIP traffic. But these same traits can also render it more susceptible to exploitation.
“Without an initial handshake to ensure a legitimate connection, UDP channels can be used to send a large volume of traffic to any host,” NETSCOUT says.
“There are no internal protections that can limit the rate of a UDP flood. As a result, UDP flood DoS attacks are exceptionally dangerous because they can be executed with a limited amount of resources.”
Number of attacks targeting users of Kaspersky mobile solutions, Q1 2020 — Q2 2022 (download)
As in the previous quarter, fraudulent apps occupied seven out of twenty leading positions in the malware rankings. That said, the total number of attacks by these apps started to decrease.
Interestingly enough, some fraudulent app creators were targeting users from several countries at once. For instance, J-Lightning Application purported to help users to invest into a Polish oil refinery, a Russian energy company, a Chinese cryptocurrency exchange and an American investment fund.
On the contrary, the number of attacks by the RiskTool.AndroidOS.SpyLoan riskware family (loan apps that request access to users’ text messages, contact list and photos) more than quadrupled from the first quarter. The majority of users whose devices were found to be infected with this riskware were based in Mexico: a third of the total number of those attacked. This was followed by India and Colombia. The ten most-affected countries include Kenya, Brazil, Peru, Pakistan, Nigeria, Uganda and the Philippines.
The second quarter was also noteworthy for Europol taking down the infrastructure of the FluBot mobile botnet, also known as Polph and Cabassous. This aggressively spreading banking Trojan attacked mainly users in Europe and Australia.
Mobile threat statistics
In Q2 2022, Kaspersky detected 405,684 malicious installation packages, a reduction of 110,933 from the previous quarter and a year-on-year decline of 480,421.
Distribution of newly detected mobile malware by type, Q1 and Q2 2022 (download)
Adware ranked first among all threats detected in Q2 2022 with 25.28%, exceeding the previous quarter’s figure by 8.36 percentage points. A third of all detected threats of that class were objects of the AdWare.AndroidOS.Ewind family (33.21%). This was followed by the AdWare.AndroidOS.Adlo (22.54%) and AdWare.AndroidOS.HiddenAd (8.88%) families.
The previous leader, the RiskTool riskware, moved to second place with 20.81% of all detected threats, a decline of 27.94 p.p. from the previous quarter. More than half (60.16%) of the discovered apps of that type belonged to the Robtes family.
Various Trojans came close behind with 20.49%, a rise of 5.81 p.p. on the previous quarter. The largest contribution was made by objects belonging to the Mobtes (38.75%), Boogr (21.12%) and Agent (18.98%) families.
Top 20 mobile malware programs
Note that the malware rankings below exclude riskware or PUAs, such as RiskTool or adware.
Verdict
%*
1
DangerousObject.Multi.Generic
21.90
2
Trojan-SMS.AndroidOS.Fakeapp.d
10.71
3
Trojan.AndroidOS.Generic
10.55
4
Trojan.AndroidOS.GriftHorse.ah
6.07
5
Trojan-Spy.AndroidOS.Agent.aas
5.40
6
Trojan.AndroidOS.GriftHorse.l
3.43
7
DangerousObject.AndroidOS.GenericML
3.21
8
Trojan-Dropper.AndroidOS.Agent.sl
2.82
9
Trojan.AndroidOS.Fakemoney.d
2.33
10
Trojan.AndroidOS.Fakeapp.ed
1.82
11
Trojan.AndroidOS.Fakeapp.dw
1.68
12
Trojan.AndroidOS.Fakemoney.i
1.62
13
Trojan.AndroidOS.Soceng.f
1.59
14
Trojan-Ransom.AndroidOS.Pigetrl.a
1.59
15
Trojan.AndroidOS.Boogr.gsh
1.56
16
Trojan-Downloader.AndroidOS.Necro.d
1.56
17
Trojan-SMS.AndroidOS.Agent.ado
1.54
18
Trojan-Dropper.AndroidOS.Hqwar.gen
1.54
19
Trojan.AndroidOS.Fakemoney.n
1.52
20
Trojan-Downloader.AndroidOS.Agent.kx
1.45
* Unique users attacked by this malware as a percentage of all attacked users of Kaspersky mobile solutions.
First and third places went to DangerousObject.Multi.Generic (21.90%) and Trojan.AndroidOS.Generic (10.55%), respectively, which are verdicts we use for malware detected with cloud technology. Cloud technology is triggered whenever the antivirus databases lack data for detecting a piece of malware, but the antivirus company’s cloud already contains information about the object. This is essentially how the latest malware types are detected.
Trojan-SMS.AndroidOS.Fakeapp.d rose from third to second place with 10.71%. This malware is capable of sending text messages and calling predefined numbers, displaying ads and hiding its icon.
Members of the Trojan.AndroidOS.GriftHorse family took fourth and sixth places with 6.07% and 3.43%, respectively. This family includes fraudulent apps that purchase paid subscriptions on the user’s behalf.
Trojan-Spy.AndroidOS.Agent.aas (5.40%), an evil twin of WhatsApp with a spy module built in, retained fifth position.
The verdict of DangerousObject.AndroidOS.GenericML (3.21%) came seventh. These verdicts are assigned to files recognized as malicious by our machine-learning systems.
Trojan-Dropper.AndroidOS.Agent.sl (2.82%), a dropper that unpacks and runs a banking Trojan on devices, remained in eighth place. Most of the attacked users were based in Russia or Germany.
Trojan.AndroidOS.Fakemoney.d slid from second to ninth place with 2.33%. Other members of the family occupied twelfth and nineteenth places in the rankings. These are fraudulent apps that offer users to fill out fake welfare applications.
Trojan.AndroidOS.Fakeapp.ed dropped to tenth place from sixth with 1.82%; this verdict covers fraudulent apps purporting to help with investing in gas utilities and mostly targeting Russian users.
Trojan.AndroidOS.Fakeapp.dw dropped from tenth place to eleventh with 1.68%. This verdict is assigned to various scammer apps, for example, those offering to make extra income.
Trojan.AndroidOS.Soceng.f (1.59%) dropped from twelfth to thirteenth place. This Trojan sends text messages to people in your contacts list, deletes files on the user’s SD card, and overlays the interfaces of popular apps with its own window.
Trojan-Ransom.AndroidOS.Pigetrl.a dropped from eleventh to fourteenth place with 1.59%. This malware locks the screen, asking to enter an unlock code. The Trojan provides no instructions on how to obtain this code, which is embedded in the body of the malware.
The verdict of Trojan.AndroidOS.Boogr.gsh occupied fifteenth place with 1.56%. Like DangerousObject.AndroidOS.GenericML, this verdict is produced by a machine learning system.
Trojan-Downloader.AndroidOS.Necro.d (1.56%), designed for downloading and running other malware on infected devices, climbed to sixteenth place from seventeenth.
Trojan-SMS.AndroidOS.Agent.ado dropped from fifteenth to seventeenth place with 1.54%. This malware sends text messages to short codes.
Trojan-Dropper.AndroidOS.Hqwar.gen, which unpacks and runs various banking Trojans on a device, kept eighteenth place with 1.54%.
Trojan-Downloader.AndroidOS.Agent.kx (1.45%), which loads adware, dropped to the bottom of the rankings.
Map of attempts to infect mobiles with malware, Q2 2022 (download)
TOP 10 countries and territories by share of users attacked by mobile malware
Countries and territories*
%**
1
Iran
26,91
2
Yemen
17,97
3
Saudi Arabia
12,63
4
Oman
12,01
5
Algeria
11,49
6
Egypt
10,48
7
Morocco
7,88
8
Kenya
7,58
9
Ecuador
7,19
10
Indonesia
6,91
* Excluded from the rankings are countries and territories with relatively few (under 10,000) Kaspersky mobile security users. ** Unique users attacked as a percentage of all users of Kaspersky mobile security solutions in the country.
Iran remained the leader in terms of the share of infected devices in Q2 2022 with 26.91%; the most widespread threats there as before were the annoying AdWare.AndroidOS.Notifyer and AdWare.AndroidOS.Fyben families. Yemen rose to second place with 17.97%; the Trojan-Spy.AndroidOS.Agent.aas spyware was the threat most often encountered by users in that country. Saudi Arabia came third with 12.63%, the most common malware apps in the country being the AdWare.AndroidOS.Adlo and AdWare.AndroidOS.Fyben adware families.
Mobile banking Trojans
The number of detected mobile banking Trojan installation packages increased slightly compared to the previous quarter: during the reporting period, we found 55,614 of these, an increase of 1,667 on Q1 2022 and a year-on-year increase of 31,010.
Almost half (49.28%) of the detected installation packages belonged to the Trojan-Banker.AndroidOS.Bray family. The Trojan-Banker.AndroidOS.Wroba was second with 5.54%, and Trojan-Banker.AndroidOS.Fakecalls third with 4.83%.
Geography of mobile banking threats, Q2 2022 (download)
TOP 10 countries and territories by shares of users attacked by mobile banking Trojans
Countries and territories*
%**
1
Spain
1.04
2
Turkey
0.71
3
Australia
0.67
4
Saudi Arabia
0.64
5
Switzerland
0.38
6
UAE
0.23
7
Japan
0.14
8
Colombia
0.14
9
Italy
0.10
10
Portugal
0.09
* Countries and territories with relatively few users of Kaspersky mobile security solutions (under 10,000) have been excluded from the ranking. ** Unique users attacked by mobile banking Trojans as a percentage of all Kaspersky mobile security solution users in the country.
In Q2 2022, Spain still had the largest share of unique users attacked by mobile financial threats: 1.04%. Trojan-Banker.AndroidOS.Bian.h accounted for 89.95% of attacks on Spanish users. Turkey had the second-largest share (0.71%), with attacks on Turkish users dominated by Trojan-Banker.AndroidOS.Ermak.a (41.38%). Australia was third with 0.67%; most attacks in this country were attributed to Trojan-Banker.AndroidOS.Gustuff.d (96,55%).
Mobile ransomware Trojans
The number of mobile ransomware Trojan installation packages we detected in Q2 2022 (3,821) almost doubled from Q1 2022, increasing by 1,879; the figure represented a year-on-year increase of 198.
Geography of mobile ransomware Trojans, Q2 2022 (download)
TOP 10 countries and territories by share of users attacked by mobile ransomware Trojans
Countries and territories*
%**
1
Yemen
0,30
2
Kazakhstan
0,19
3
Azerbaijan
0,06
4
Kyrgyzstan
0,04
5
Switzerland
0,04
6
Egypt
0,03
7
Saudi Arabia
0,03
8
Uzbekistan
0,02
9
Russian Federation
0,02
10
Morocco
0,02
* Excluded from the rankings are countries and territories with relatively few (under 10,000) Kaspersky mobile security users. ** Unique users attacked by ransomware Trojans as a percentage of all Kaspersky mobile security solution users in the country or territory.
Countries leading by number of users attacked by mobile ransomware Trojans were Yemen (0.30%), Kazakhstan (0.19%) and Azerbaijan (0.06%). Users in Yemen most often encountered Trojan-Ransom.AndroidOS.Pigetrl.a, while users in Kazakhstan and Azerbaijan were attacked mainly by members of the Trojan-Ransom.AndroidOS.Rkor family.
