Search Results

Leverage DPRM Solutions in Cyber Risk Models for Better Business Outcome Risk models and frameworks span a wide range of essential topics for the business. So, it is not uncommon to see risk modeling used throughout an organization. When it comes to cyber risk models, there are many use cases for building a model to assess the risk of a business opportunity. Cyber risk models are commonly used to determine the risk vs. business opportunity for M&A initiatives, introducing new customer services and online applications, and measuring risk with their supply chain partners. There are several frameworks that GRC professionals use to gauge risk and reward for IT initiatives to help companies make good decisions about risk. NIST is one of the most well-known producers of IT frameworks for cybersecurity risk management. The newly released 2.0 version of the cybersecurity framework heavily emphasizes a new Govern function incorporating cybersecurity into a broader enterprise risk management strategy. Factor Analysis of Information Risk (FAIR) is another methodology and framework for quantifying cyber risk designed to measure, manage, and report on information risk from the business perspective. Service Organization Control (SOC) Type 2 is a trust-based cybersecurity framework and auditing standard and one of the most challenging frameworks to implement. Prioritizing Vulnerabilities and Business Risk Digital risk protection management (DRPM) solutions offer security leaders a way to aggregate thousands of data points to identify internet-facing systems and data that need to be protected. This data identifies IT security gaps, offering a view into an organization's risk profile. This information is vital for vulnerability management professionals who must prioritize CVEs by the business that pose if exploited. A zero-day attack is a high risk, but that same exploit can be higher if the CVE presents on a critical system that provides access to customer information or acts as the core system that keeps supply chain or manufacturing systems online and productive. A modern DRPM solution will consider these scenarios and prioritize mitigation to reduce business risk. Today's business environment requires versatile tools beyond numerical calculations and best estimates. DPRM platforms continually ingest and aggregate multiple sources of information to continually discover externally facing infrastructure and prioritize business risk. DPRM data fed into a risk model or GRC system is critical in evaluating the balance between risk and business opportunity. This assessment is crucial for mergers and acquisitions, new online customer services, and supply chain partnerships. Actionable Insight: Use data from DPRM systems to feed risk models to evaluate risks and opportunities across various business domains, especially in M&A, customer service innovation, and supply chain partnerships. Create a Blueprint of Cyber Risk for Better Decision-Making Cyber risk frameworks and DPRM platforms complement each other as navigational guides, offering a structured approach to assessing digital vulnerabilities to the right level of business risk. They are central to evaluating many business scenarios requiring cybersecurity and business leaders to collaborate to assess risk vs. opportunity. Business situations where this is evident include M&A evaluations, introducing online services, and gauging new supply chain vendors. They provide the business with a panoramic view of potential risks and prioritization in a way that is easy for business counterparts to understand and help them make informed choices. M&A Evaluations - M&A opportunities and subsidiaries are ripe for sophisticated attackers to find new ways to infiltrate parent organizations. Proactively searching for ongoing threats relating to M&A activities and within subsidiaries pays off in the early identification of compromise. New Online Services – Fighting fraud is essential to defending any new service and must be evaluated early and often in any new application launch. Supply Chain Partnerships – Vital to business, no company can ignore strategic partnerships supporting the launch of new products or aiding new corporate capabilities. At the same time, they represent a significant risk as every new partnership represents another way for a threat actor to access core systems. In each scenario, essential risk and threat models support a proactive defense. It is vital to any enterprise organization as most partners are smaller and more vulnerable to an attack. Actionable Insight: Develop cyber risk models using a framework to comprehensively understand digital vulnerabilities and potential impact, including qualification of the business risk. DPRM solutions, in context with the framework or model you choose, will enable well-informed decisions in areas like M&A due diligence, online service deployment, and supply chain management. Real-Time Threat Intelligence Informs Predictive Cyber Risk Models Your initial asset discovery and prioritization efforts are the tip of the spear as you get started with your DPRM solution and using risk frameworks to aid in decisions about prioritizing vulnerabilities and collaborating with the business on cyber risk. Your DPRM solution should aggregate data for discovering assets within your environment and partner infrastructure supporting external applications. Discovery must be continual to aid security leaders in identifying and safeguarding critical internet-facing systems and data. These solutions highlight vulnerabilities by analyzing multiple data points, offering insights crucial for effective vulnerability management and risk prioritization. Real-time threat intelligence complements these processes by providing up-to-date information about active threat actors and their tactics. The knowledge you get from a DPRM platform aids in risk scoring and quantifying potential financial impacts that empower organizations to focus on reducing attack risks. External Attack Surface Management (EASM) platforms, such as Pure Signal™ Orbit, is an example of a DPRM solution focusing on external digital risks that offer the benefit of informing risk with real-time threat intelligence. Actionable Insight: Leverage real-time threat intelligence to prioritize risks effectively and quantify potential financial impacts, enabling the allocation of resources to high-priority areas. Start Early and Collaborate Often Even if you don't have a DPRM solution in place or have someone on your team that is a wiz at creating bespoke models for risk analysis (most teams don't), you can start now. Involve business unit leaders to support the discovery of applications and understanding of their usage of cloud services. If you subscribe to threat intelligence, ensure that it is real-time data, not curated information that may not be timely or support proactive defenses. Find solutions like Pure Signal to support your digital risk program and assessment. Create criteria that you would use to prioritize vulnerabilities by cyber risk and evaluate your environment for weaknesses. Start asking questions to understand the company's appetite for cyber risk. Use tools like the MITRE ATT&CK framework to understand adversarial behavior and gaps in your ability to detect and mitigate attacks. Further Reading: Call to action: Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Learn more about the value of monitoring external risks and how that empowers organizational success. Read our customer case study here Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Learn more about the value of monitoring external risks and how that empowers organizational success. Read our customer case study here Mature threat intelligence teams add tangible financial business value and reduce business risk. Learn more about how our customer gained success integrating real-time threat intelligence to enact a proactive defense that goes beyond the MITRE ATT&CK framework to offer pre-compromise defense. Up the Ante on Supply Chain Security Stop the Budget Drain of Dated Threat Intelligence Don’t Inherit a Security Problem with M&A Activity Automate Real-Time Intelligence and Increase Productivity. and Morale! External Threat Hunting Prevents Data Breaches

Leverage Internet Telemetry & Threat Intelligence for Benefits Beyond the MITRE ATT&CK Framework The MITRE ATT&CK framework is like a blueprint of the battlefield, showcasing potential threat actors and their tactics to infiltrate an organization. It guides a security practitioner to identify gaps in an organization's capabilities by following the tactics a bad actor may use to gain access. It also covers the techniques employed by threat actors to move laterally inside a network and compromise additional systems and infrastructure. It sheds light on how vulnerabilities are exploited, leading threat actors to move laterally within networks. However, the framework remains static, providing a snapshot of known adversarial behavior. It offers security leaders and practitioners guidelines and essential attributes for threat detection, but they are not designed to guide security leaders on how to gain the visibility needed to better detect threats. Real-time threat intelligence fills this void, providing the crucial context to attribute attacks, track adversary behavior, and map their infrastructure. It is a vital source of intelligence and visibility that extends beyond boundaries to address evolving threats. It steps in and supports rapid threat analysis by offering a dynamic view of bad actors that may be targeting you and acts as a single source of truth. Real-time threat intelligence and the MITRE security framework are complementary forms of intelligence that enable analysts to defend against threat actors proactively. A security framework such as MITRE is adversarial-focused. It can help you find gaps in your capabilities and give you an idea of who may be attacking you and how they move laterally within your environment to gain further access to your business systems. Real-time intelligence gives you a way to observe the beginning stages of an attack when threat actors are performing reconnaissance on you as their target, or your third-party networks. There are few useful recommendations on how to use tools to defend an organization at this stage. But solutions do exist! This blog seeks to discuss where, why and how these blindspots can be addressed using threat intelligence derived from external threat intelligence sources, and the strategic gains there for innovative security leaders to seize. Real-Time External Threat Intelligence Complements the MITRE ATT&CK Framework The MITRE ATT&CK framework is renowned for its adversarial approach to defense. It provides a structured process for understanding threat actors' tactics, techniques, and procedures (TTPs). It reveals their modus operandi, so analysts have a starting place to understand what tools, experience and knowledge they need to track down bad actors - both inside and beyond the perimeter. It enables security teams to fortify their defenses in the right areas and bridge capability gaps in others. Frameworks offer guidelines and essential attributes for threat detection, but they are not designed to guide security leaders on how to gain the visibility you need to better detect threats. Real-time threat intelligence fills this void, providing the crucial context to attribute attacks, track adversary behavior, and map their infrastructure. It is a vital source of intelligence and visibility that extends beyond boundaries to address evolving threats. It steps in and supports rapid threat analysis by offering a dynamic view of bad actors that may be targeting you and acts as a single source of truth. The threat landscape demands innovative approaches that move beyond static data and reactive methodologies. Among the tools at a security leader's disposal are real-time threat intelligence and the MITRE ATT&CK framework. These two pillars of defense, though distinct in nature, can pave the way for a proactive cyber-defense strategy that enables a shift towards anticipating and defeating threats from adversaries. While the framework equips defenders with essential insights with a range of TTPs, you must independently learn how to create your own unique threat data and the playbooks that pivot off of it. When analysts can see infrastructure changes and trace communications with threat actor groups, they can find other victims of an attack and notify them of possible compromise. This type of threat reconnaissance is the primary way enterprise security teams can raise the cost of attack and make it less profitable for threat actors to target their organization. Actionable Insight: Embrace both external threat intelligence and the MITRE ATT&CK framework to equip cyber defenders with the visibility they need. It is the cornerstone of a proactive cyber defense that does not relegate defenders to reacting to events and chasing false positives and other resource-draining efforts. Close the Capability gap for Proactive Defense with the MITRE ATT&CK Framework and Real-Time Threat Intelligence The MITRE ATT&CK framework lays the foundation for creating robust detection mechanisms and preparing for what can be expected to detect and mitigate a threat. It doesn’t take long to notice that much of the model is focused on what occurs when an attacker is already in your network - what about when they are scanning your assets? Or when they have already compromised your network and are setting up staging servers to steal your data - your internal network analysis and security tools are blind to this activity at this point in the attack so far - gaining external visibility of attacker activity is the difference of that data remaining in your possession, or being stolen. Up-to-date external threat intelligence has the potential to greatly enhance security across the board. By automating detection policies with data that analysts derive by tracking threat actor infrastructure, this can be applied across the entire MITRE model. i.e., before, during and after an attack. To achieve this, analysts need a real-time view of threat actor activities. These insights and resulting additions to defense policies mean that analysts are not providing out-of-date information to block lists, ensuring defenses are optimized and effective. They are acting on what is happening now, ensuring that any updating of defense policies uses real-time data as it develops. Access to real-time information and visibility into threat actor movements enable analysts to build constructive views and learn about IOCs from an external threat perspective. Actionable Insight: Use the MITRE ATT&CK framework initially as a gap analysis tool. Not only does it call out adversary tactics, but helps to inform where you may, or may not, have visibility, tools, data, knowledge or resources that add value to your cyber defense. Allocate resources to invest in technologies that enable analysts to create actionable threat intelligence playbooks, promoting effective attribution and preventative tactics. How Visibility and Reconnaissance Pays off to Countering Attacks A quick snapshot of the MITRE ATT&CK reconnaissance frameworks shows ten different reconnaissance techniques and more than 30 sub-techniques that a bad actor might employ in their reconnaissance effort to gather intelligence for a targeted attack. As a defender, the framework suggestions for pre-compromise mitigations offered are minimal. Detection recommendations are relegated to anomaly-based analysis, known for high false-positive rates. It leaves little path for security leaders working towards enacting a proactive defense strategy and wanting to get ahead of attacks. When using threat intelligence based on internet telemetry, new possibilities open up to monitor malicious activity as it is happening. Analysts have a ground-zero current source of truth to observe attacker behavior and quickly make decisions if a suspicious IP should be further investigated. Visibility beyond the perimeter pays off in the latter stages of attack by enabling analysts to anticipate what a threat actor is going to do next, and be able to specify proactive defenses to counter an attacks. Creating visibility into the external threat landscape supports proactive defenses and a high detection efficacy in the pre-compromise stage. This visibility is crucial to building a proactive defense strategy and addressing all stages of compromise using the framework. Aggressive efforts made in the pre-compromise stage of an attack can pay out benefits towards prevention during exfiltration. Suppose you use internet telemetry enriched with threat intelligence for visibility and reconnaissance in the pre-compromise stage. In that case, you already have the answers to block exfiltration proactively instead of relying on signature or anomaly-based detection methods. It is a better way to address threats than using reactionary methods that lead to high false positive rates. Actionable Insight: Identify your visibility gaps that lie within the ‘Reconnaissance’ column of the MITRE ATT&CK framework. This will lead to data sources that will help you to better understand the threat actors that are reaching out to your own and third-party networks, including victims of ongoing attacks. It reveals their evolving tactics, and the changes they make to their infrastructure before another attack. External threat intelligence or internet telemetry are the only sources of knowledge and data that will fill the visibility gap for threat actors at the Reconnaissance stage of the model. Enhance Detection Capabilities with Actionable Insights Real-time up-to-date external threat intelligence derived from internet telemetry has the potential to greatly enhance security across the board. By automating detection policies with data that analysts derive by tracking threat actor infrastructure, it can be applied across the entire MITRE model. i.e., before, during and after an attack. To achieve this, analysts need to be able to observe attackers in real time view of threat actor activities. These insights and resulting additions to defense policies mean that analysts are not providing out-of-date information to block lists, ensuring defenses are optimized and effective with current information. They are acting on what is happening now, ensuring that any updating of defense policies uses real-time data as it develops. Access to real-time information and visibility into threat actor movements enable analysts to build constructive views and learn about IOCs from an external threat perspective. It's important to remember that the MITRE ATT&CK framework does not provide a complete answer to defense against attackers' tactics, techniques, and procedures and only offers suggestions for mitigation and detection. Bad actors constantly innovate, and a security leader's response must do the same. Let your analysts do more by tracing down attackers, making associations, and preempting an attack with reconnaissance-led intelligence that can actively block an attack. Once you enable visibility to internet telemetry and historical context, analysts are not just reacting to what is happening inside the network. This is foundational to enacting a proactive defense that turns the dynamics of the MITRE ATT&CK framework on its head and creates new areas for learning and preemptive defense. Actionable Insight: Allocate resources to invest in technologies that enable analysts to create actionable threat intelligence playbooks, promoting effective attribution and preventative tactics. Learn more about the threat vectors you should be considering for your Threat Model here Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Mature threat intelligence teams add tangible financial business value and reduction of business risk. Learn more about how our customer gained success integrating real-time threat intelligence to enact a proactive defense that goes beyond the MITRE ATT&CK framework to offer pre-compromise defense. Up the Ante on Supply Chain Security Stop the Budget Drain of Dated Threat Intelligence Don’t Inherit a Security Problem with M&A Activity Automate Real-Time Intelligence and Increase Productivity. and Morale! External Threat Hunting Prevents Data Breaches

Keeping Security Teams at the Forefront of Proactive Defense Threat modeling is an integral part of security-by-design programs for applications, products, and services used by your organization that could be exploited by threat actors or suffer a software vulnerability. There are many different tools, methodologies (PASTA and STRIDE), and frameworks (OWASP and MITRE ATT&CK) to help security practitioners with threat modeling initiatives. Like the MITRE ATT&CK framework, threat models are adversarial-focused, requiring analysts to have a hacker mindset. Think like your enemy. In a way, creating a threat model is comparable to authoring a "worst-case scenario" handbook specifically for defending against cybersecurity threats. And like any disaster scenario needs a corresponding recovery plan, the time to prepare is now, not later, when it is too late. This blog series explores the relationship between threat Intelligence and threat modeling to demonstrate how they strengthen an organization's security. We will discuss how Threat intelligence informs adaptive threat models, merging strategic foresight with tactical preparedness to face evolving cyber threats. Threat Modeling informed by Intelligence is Vital for Security-by-Design Initiatives Threat modeling plays a vital role in security-by-design programs. Companies that need this level of security will analyze potential threats and vulnerabilities in applications, products, or services before they are brought to market. Security experts can identify weaknesses and create strong defenses against emerging risks by considering worst-case scenarios. However, the true power of threat modeling lies in applying threat intelligence to enable preemptive defenses. Real-time threat Intelligence involves monitoring and analyzing threat actors, their motives, tactics, and the external threat landscape. It can be thought of as strategic reconnaissance in cybersecurity. It allows organizations to predict, adapt, and defend by identifying changes in adversary behavior. When companies take a proactive approach to defending critical business applications, they recognize the need for tools to build visibility into threat actors operating in their geography and industry. This is where real-time threat intelligence and threat modeling step in to offer a preemptive defense strategy. Threat Modeling and Intelligence-Led Use Cases Threat modeling defends against potential cyber threats to applications, products, or online services. It's vital in identifying and addressing vulnerabilities and protecting digital assets from malicious actors. Integrating threat modeling into corporate initiatives early in development lays a secure foundation for product enhancements. Cyber threat modeling complements many different business initiatives and scenarios. Its versatility makes it applicable to a wide range of business initiatives, including: Application Development and Design: Early-stage software and app development to pinpoint design, architecture, and code vulnerabilities. Critical Network Infrastructure: Assessing routers, firewalls, and switches to identify attack vectors and improve network security. Cloud and Virtualization: Understand the security implications of cloud and virtualization technologies and manage risks. IoT Devices: A vital component of secure IoT device design and communication protocols, especially in medical settings. Critical Infrastructure: Digital transformation projects create risks that need threat modeling to build defenses for anticipating cyber threats. E-commerce and Finance: Online platforms handling online transactions and customer incentives need to build defenses against attacks that take into account seasonal impacts and changes to incentives and fulfillment partners. Healthcare and Medical Devices: Connected patient healthcare and communications must be protected with built-in defenses. Automotive and Transportation: Development of embedded defenses for secure connected vehicles. Supply Chain Security: Assess security risks with threat models that include software supply chain partners used to deliver services and operate critical production systems and communications. Incident Response: Simulate cyberattacks with threat modeling to develop response plans. Government and Defense: Capture nation-state actors TTPs to build predictive defenses and proactive response. Social Engineering: Improve awareness against social engineering cyber-attacks with threat models that visualizes a credential based compromise. All of these will likely have internet facing systems, or communications that traverse it, making external threat intelligence a key ingredient for their success and security. Create Preemptive Defenses using Frameworks and Threat Models Security practitioners within enterprise organizations use tools, methodologies, and frameworks for comprehensive threat modeling. PASTA and STRIDE methodologies and OWASP and MITRE ATT&CK frameworks offer different approaches to modeling threat actor behavior and their techniques, tactics, and procedures. On the defensive side, many tactical workflows and processes use frameworks to anticipate attacks and devise built-in resiliency in case of compromise. Frameworks like OWASP (Open Web Application Security Project) and MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) provide resources for analysts to build a threat modeling practice. MITRE ATT&CK adopts an adversarial perspective, encouraging analysts to think like a hacker. Security experts can identify weaknesses and create strong defenses against emerging risks by considering worst-case scenarios. Start Early to Model Threats for New Applications and Changing Business Realities A good example of using these combined initiatives and maximizing its benefits is during the early stages of the Software Development LifeCycle (SDLC), before an application or new online service reaches production. It enables security analysts and developers to scrutinize every aspect of the application's architecture. This scrutiny proactively identifies inherent weaknesses and potential vulnerabilities that might go unnoticed. During this early phase, collaboration with the threat intelligence team becomes invaluable. These teams understand the evolving threat landscape, offering insights into threat actor behavior, tactics, techniques, and procedures (TTPs). By integrating threat intelligence into the threat modeling process, organizations can fortify their defenses and better align their security efforts with company business initiatives. Threat modeling is most effective when it adapts to changing environments. Security leaders help align threat models with evolving dynamics by establishing feedback loops for ongoing assessment with business counterparts. Dynamic factors, such as seasonal business variations and introducing new incentives, significantly change an application's risk profile and the type of attacks likely to occur. Our own research demonstrates that even your cyber adversaries have seasonal changes that impact when they are most likely to launch an attack against your organization. Business unit leaders play a pivotal role in these scenarios, as their insights can help align threat models with evolving commercial dynamics. Establishing a feedback loop between threat modeling, intelligence, hunting teams, and business units is instrumental in assessing ongoing application changes and the internal and external threat landscape. For instance, integrating third-party access via APIs or introducing new monetization strategies can dramatically alter an application's threat model by introducing new threat vectors. This adaptability ensures that threat models remain relevant and effective in the face of emerging challenges. Build Threat Models that include Partners and Cloud Services Business transformation initiatives are a driving force in migrating to cloud services to speed up the launch of new applications and customer services. Third-party services available through APIs are another factor that spurs the adoption of cloud services and drives the availability of online customer services. Proactive defense of core applications critical to the business requires continuous monitoring and prioritization of CVEs, especially within vulnerable application development frameworks. Organizations must enact proactive security measures that allow analysts to quickly discover new applications, points of entry, and how new business partnerships will change their attack surface and influence business risk. This is critical in light of the software supply chain that makes up online customer services or other core functions you cannot do without. When analysts can operate with an outside-in view of your external attack surface that includes third parties and cloud services, they can better defend it.This level of visibility enables the creation of realistic threat models that consider third parties that support your applications. As cybersecurity threats evolve, threat modeling emerges as an indispensable tool for organizations making strides toward a proactive security defense. Early examination of potential attack vectors and vulnerabilities using threat models empowers security practitioners to craft aggressive defenses in designing new services and products. By integrating threat intelligence and fostering collaboration across various teams, organizations can ensure their threat models remain relevant, agile, and capable of anticipating and mitigating emerging threats. The synergy between threat modeling, intelligence, and stakeholder involvement paves the way for a more secure and resilient digital future. Further Reading: Learn more about the threat vectors you should be considering in your Threat Model here Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Up the Ante on Supply Chain Security Stop the Budget Drain of Dated Threat Intelligence Don’t Inherit a Security Problem with M&A Activity Automate Real-Time Intelligence and Increase Productivity. and Morale! External Threat Hunting Prevents Data Breaches

A Data-Driven Approach Based on Analysis of Network Telemetry In this blog post, we will provide an update on our high-level analysis of QakBot infrastructure, following on from our previous blog post. We will pick up the timeline from where we left it, basing our findings on data collected between 1 May and 20 July 2023. We have continued to focus on elements and trends for which we do not observe in regular commentary; specifically the relationship between victim-facing command and control (C2) infrastructure and upstream servers, we previously referenced these as being geolocated in Russia. As with our previous blog, this represents an ongoing piece of research, our analysis of QakBot is fluid with various hypotheses being identified and tested. As and when we uncover new insights into QakBot campaigns we will seek to provide further written updates. We welcome feedback and comment via our Twitter page on the hypotheses mentioned in this post; broadly our findings represent the benefits and challenges of working with NetFlow data - whilst we can form broad conclusions, these are sometimes open to interpretation. Confirmation and contradiction are both of value to us as we continue to understand this threat operation. Key Findings C2 activity around both victim and upstream T2 communication slowed down before spamming ended around 22 June. After spamming ceased, C2 activity continued albeit at a lower volume. 15 new C2s set up after spamming ended have been identified so far. Additionally, the number of existing C2s communicating with the T2 layer significantly decreased with only 8 remaining past 22 June. We’ve observed interesting outbound activity from the T2 layer, targeting both publicly reported and suspected Qakbot C2s, as well as other undefined destinations. The T2 C2s connect to the same list of ports used in the process for deploying the Qakbot proxy module, with usually only one or two ports observed in a day. Although the volume of connections, variety of destinations, and port usage appear random, over time the destination ports are used with relatively equal frequency. During the first half of 2023, port 443 was assigned to approximately 48% of the C2s extracted from Qakbot campaigns. Among those C2s, only a subset engaged in communication with the T2 layer. Within this subset, 80% were assigned port 443, making it the predominant port for communication between victims and C2s. C2s are usually compromised hosts in residential IPs space, as are the other destination IPs identified from outbound T2 connections. Additional criteria like geolocation and AS organization may influence the selection of these hosts, guiding the purchase from third parties and determining which Qakbot victims become bot C2s or used for other operator activity. Summer Glow Up Qakbot has a history of taking an extended break each summer before returning sometime in September, with this year's spamming activities ceasing around 22 June 2023. But are the QakBot operators actually on vacation when they aren’t spamming, or is this "break" a time for them to refine and update their infrastructure and tools? It's worth considering that the summer months might offer a unique opportunity for operational work, especially when their main targets in the Northern Hemisphere are often on some form of holiday, leading to a potential decline in the success rate of their attacks during this time. The line graph below shows the volume of connections from C2s over TCP/443 to the three Tier 2 (T2) IPs geolocated in Russia. In our previous blog post, we referred to the three T2s as RU1, RU2, and RU3. Since then, the IPs have been made public so we have included them in some of the legends accompanying the charts below. However, for the sake of simplicity and continuity, we will continue to refer to them collectively as RU* within this post. Figure 1: Volume of bot C2s connections with the T2 layer (RU1, RU2, RU3) over TCP/443 After a very busy May, things began to slowly wind down at the end of the month before a sudden drop in connections to the T2 in early June, even though spamming continued for three more weeks until around 22 June. We were unable to identify any new T2s after this decline in activity, though traffic from some C2s persisted, suggesting that the T2 infrastructure remained unchanged. However, it wouldn’t be surprising if fresh IPs for the T2 layer are introduced before their anticipated return in late summer. After this drop-off, a slight spike was observed on 21 and 22 June, the last day of pre-summer mass spamming (affiliate ID obama271). Interestingly, a few more spikes occurred after this period, which we will explore further. The graph below represents the volume of bot C2 to T2 traffic according to C2 geolocation: Figure 2: Volume of bot C2 to T2 traffic per geolocation (of C2s) for 1 May through 20 July From this perspective, we observe that on 2 June, US C2s all but disappeared, and traffic from Indian C2s significantly decreased. We suspect the lack of US activity is at least partially attributable to Lumen’s Black Lotus Labs null-routing the T2 layer in their networks, as noted in their recent blog post. For curiosity’s sake, let's quickly examine data for traffic volume and timing from the perspective of likely QakBot victim to C2 communications during the same time frame: Figure 3: Volume of inbound connections to C2s from hosts that are likely infected with Qakbot As was the case with C2 to T2 communications, we can see a winding down of activity at the end of May, however this does not drop off as suddenly at the beginning of June. Instead, victim to C2 communications appear to gradually reduce in volume up to and beyond the date QakBot ceased spamming operations (22 June). Turning back to C2 to T2 activity, the following graph is a zoomed-in view of June onward, highlighting the start of a considerable drop in activity that persists through July. Figure 4: Volume of bot C2 to T2 traffic per geolocation (of C2s) for 1 June through 20 July According to our data, a lull lasted from 2 June to 12 June, during which only Indian C2s communicated upstream, albeit at a drastically reduced volume compared to May. We also noted some spikes in traffic from South African C2s. We examined the IPs from the geolocations present during this timeframe to determine whether these were legacy C2s with sporadic bursts of activity, or new C2s being incorporated into their infrastructure. Our analysis revealed: Fifteen new C2s were set up since Qakbot ceased spamming, indicated by a green box in the timeline below. Six additional C2s, active since before June (some dating back to October and December 2022), that continued to exhibit upstream activity after spamming concluded, indicated by a blue box in the timeline below. Two C2s, new in June, that also maintained activity after spamming concluded, indicated by an orange box in the timeline below. Figure 5: Timeline of most recent reported and suspected Qakbot C2s We suspect that the IPs in the above timeline represent new and existing C2s intended for use upon Qakbot’s return post-summer glow up break. Most of the C2s established after spamming ceased have only a few connections to the T2 and for brief durations, possibly indicative of C2s that are not currently active but were prepared or primed for future spamming. We will continue monitoring Qakbot during their summer break for any signs of changes in their infrastructure or how they operate. The Mystery of the Outbound Tier 2 Connections Whilst examining NetFlow data for the C2 to T2 communications from which we derived the findings described above, we kept making the same unexpected observation. A clear pattern of communications sourced from the T2s, where QakBot C2s were the destination, i.e., the reverse of the traffic we were examining. These communications occurred over the same 32 ports: 20, 21, 22, 53, 80, 443, 465, 990, 993, 995, 1194, 2078, 2083, 2087, 2222, 3389, 6881, 6882, 6883, 8443, 32100, 32101, 32102, 32103, 50000, 50001, 50002, 50003, 50010, 61200, 61201, and 61202. Malware such as Qakbot, IcedID, and Emotet leverage tiered infrastructure. This consists of victim hosts communicating with bot C2s, which comprise the Tier 1 layer of the bot infrastructure, which then communicate upstream with the T2 layer. The traffic typically continues to be proxied through additional tiers of infrastructure before it reaches the pane, which is accessed by the threat actors. Aside from subtle differences, for example the ports used, this process is essentially the same for the many malware families we track. The traffic we have observed sourced from QakBot T2s to the C2 / Tier 1 layer is atypical. When we expand our dataset to look at all outbound traffic from the T2s, we establish a larger pool of ‘T2 destination IPs’. As mentioned, some of these T2 destination IPs are publicly reported QakBot C2s. However, in the majority of cases the T2 destination IPs have not previously been identified as malicious, although many share common host characteristics associated with QakBot C2s. Let’s begin by examining what we already know. Qakbot C2s utilize various ports as defined in their malware configurations. These are the ports that an infected host would use to communicate with the bot C2. Bot C2s are generally compromised machines, often including previous Qakbot victims that have been elevated to C2 status. Our findings for 2023 reveal that 52 different ports were employed for C2s within the Qakbot configurations, including many of the ports listed above. Based on this, it is possible that the T2s are conducting a form of check-in with the C2s, utilizing the ports designated for victim traffic. We developed a second theory based on information provided in a fantastic writeup published a few years ago by Check Point Research, where they explored how a Qakbot-infected victim ultimately receives the proxy module. After the malware ensures incoming connections are allowed in the host firewall and port forwarding is enabled, it verifies incoming connections by sending a message to a bot, with confirmation based upon the response. The payload in this message contains a list of ports that match the same destination ports the T2s are using for the mysterious outbound connections, as shown in the excerpt below. Figure 6: “An Old Bot’s Nasty New Tricks: Exploring Qbot’s Latest Attack Methods“, Check Point Research, 2020 Mystery solved? Unfortunately no, it wasn’t so simple. The activity that Check Point describes would appear differently in NetFlow data from what we are currently observing with respect to outbound T2 communications. Our investigation encompasses repeated connections over an extended time frame, interspersed with periods of inactivity. Usually, one to three of the T2s will sporadically reach out to the same destination IPs for months, and not in a manner that implies verification of a fixed list of available ports. However, this information offers another possible explanation for the activity; the mysterious outbound connections from the T2s might be related in some way to the proxy module, given the identical port list. Spoiler alert, we believe this the most likely theory based on our analysis of the NetFlow data and information currently available to us, into which we will now delve deeper. “You know my method. It is founded upon the observation of trifles.” Sherlock Holmes NetFlow Observations I: Reported vs Unidentified C2s Examining the T2 destination IPs identified over a seven-month period, we discovered that only 29% of all destination IPs were reported Qakbot C2s. Of these, 79% also demonstrated typical upstream C2 to T2 bot communication over TCP/443. The remaining 71% of destination IPs were not known as malicious, although 17% of them did exhibit standard upstream C2 communication with the T2 over TCP/443. To provide additional context for these and other data points discussed in this blog post, we compared the findings against both reported and unreported C2s. The unreported C2s were identified by monitoring communications to the T2s over TCP/443 during the same time period. Figure 7: Percentages of T2 destination IPs that are Qakbot C2s, and of IPs with upstream T2 bot communication Repeating the same process for analyzing bot C2 to T2 NetFlow data, we found that 76% of all source IPs were recognized as Qakbot C2s. Of all the C2s, only 17% had inbound connections from the T2, and within this subset, 65% were publicly reported as Qakbot C2s. Figure 8: Percentages of reported and unreported C2s with typical upstream bot traffic, and of those that are also T2 destination IPs In summary, only 29% of the T2 destination IPs were verified as Qakbot C2s, as opposed to 76% of the C2s exhibiting upstream T2 traffic. Consequently, over 70% of the T2 destination IPs have not been observed in the wild as malicious. Furthermore, only 12% of the T2 destination IPs displayed upstream T2 bot traffic typical of a normal C2 but were not identified in the wild as Qakbot C2s. Based on these discrepancies, it seems improbable that the T2s are conducting any sort of management-related check-in for the bot C2s. NetFlow Observations II: Traffic Volume Figure 9: Line chart of traffic volume for outbound communication per T2 C2, spike outliers are cut off for legibility Similar to the upstream bot C2 traffic we analyzed in our previous blog post, there are notable resemblances between RU2 and RU3 in terms of traffic volume and timing, and are also adjacent IP addresses associated with Horizon LLC (ASN 59425). In contrast, RU1 belongs to IP space assigned to SmartApe (ASN 56694), and exhibits a lower overall traffic volume compared to the other two IPs. The timing of RU1 activity generally occurs independently of RU2 and RU3, although there are occasions when all three simultaneously experience spikes in volume. Next, we will present a comparison of all T2 outbound communication juxtaposed with typical C2 to T2 bot communication, irrespective of the T2 host. Figure 10: Volume of outbound connections from the T2 layer Figure 11: Volume of inbound connections to the T2 layer, from Qakbot bot C2s, over TCP/443 There are a few notable observations: The traffic volume for outbound T2 connections (blue) is markedly smaller than that of standard inbound bot C2 connections (orange). If they appeared on the same chart, the outbound T2 traffic would be virtually indiscernible when compared to the bot C2 traffic. Outbound T2 activity functions independently of inbound communication from C2s, meaning they do not happen concurrently. Instances of increased outbound T2 connections often occur following spikes in activity for inbound bot C2 connections Spikes in outbound T2 connections frequently correspond with a decline in bot C2 activity. Based on these findings, we hypothesize a connection between the volume and timing of bot C2 upstream activity and the outbound T2 activity we are investigating. Although there is minimal overlap between the groups of bot C2s and T2 destination IPs, it seems that both forms of T2 activity occur in a sequential manner, contingent on traffic volume. NetFlow Observations III: Port Usage Frequency In Qakbot C2 configurations, many C2s (often exceeding 100) are present, but only a small subset have been observed communicating with the T2 layer in our data. Taking into account all C2s, regardless of T2 communication, we found that approximately 48% were assigned port 443, 29% port 2222, and 16% port 995. All other ports were allocated to fewer than 3% of C2s. It’s worth noting that for C2s we’ve identified communicating upstream over TCP/443, these percentages change; around 80% of C2s are assigned port 443, 9% port 995, 5% port 2078, and 4% port 2222. The remaining ports were associated with less than 1% of C2s. In comparison, the chart below illustrates the frequency of destination ports utilized for outbound connections from the T2: Figure 12: Frequency of ports used as destination ports in outbound T2 connections, since November 2022 Upon examination, it’s immediately evident that there is no correlation between the two datasets regarding port usage frequency. Although port 443 was technically the most frequently utilized destination port for outbound T2 connections, its usage is far from the 48% seen with all reported bot C2s (regardless of T2 communication), and port 3389 was observed just as often. In fact, all of the 32 ports we identified with this type of communication were seen at roughly equivalent rates, with port 21 being the least common. On its own, this data point might suggest some form of automation governing which ports are accessed. However, this inference alone is not sufficient. Incorporating the timing of when the ports are used in these connections could provide further insights into whether the process appears automated. Our analysis focused on the period from May through 16 June, when activity gradually diminished to become almost nonexistent. RU1 Figure 13: Destination ports identified in outbound connections per day from T2 188.127.231.177 RU2 Figure 14: Destination ports identified in outbound connections per day from T2 62.204.41.187 RU3 Figure 15: Destination ports identified in outbound connections per day from T2 62.204.41.188 This data may not be pretty, but fortunately, a detailed examination of the individual colored bars representing each port isn't essential to grasp the overarching trends of what's occurring. By viewing the visuals collectively, it's apparent that typically only a small number of ports are accessed in a single day, with usually just one or two destination IPs accessed via each port (y-axis). Interestingly, all of the T2 IPs have visually different patterns from this perspective, a finding that contradicts the general similarities observed between RU2 and RU3. However, RU2 and RU3 do share a similar volume of ports seen per day compared to RU1. Despite these variations, there are common patterns that all three hosts exhibit. For example, they all display consistent periods of inactivity, such as those occurring from May 1-2, June 4-6, and June 9-13. They also share some spikes related to the variety of different ports used for outbound connections within specific time frames, as seen on 8 June and the period around 14/15 June. So far, we’ve determined that the T2 makes outbound connections over different ports at relatively the same frequency, with no one or two ports used far more or less than others. However, usually, only a few of the ports are seen in connections per day, and they seem to be chosen sporadically, with the exception of certain days when almost all of the ports are utilized. Regardless, over time, the T2s communicate across each of the 32 ports with a generally equal frequency. What remains unclear is the rhythm or cadence of how often a T2 connects to each destination IP using these ports, and whether this process is automated. If blatant automation is involved, we would anticipate a pattern of repeated connections with consistent timing and volume. Behavior attributed to human intervention wouldn't be so orderly; instead, it would appear more random and unpredictable. While automation can be configured to mimic this, we can at least rule out the more evident instances. To delve deeper, we chose a small sample of IPs that showed inbound T2 connections over an extended period and mapped out a timeline. In this illustration, each line color symbolizes a different T2 destination IP from the sample. A spike in a line indicates that at least one of the T2 C2s connected to that IP on that day, with the Y axis representing how many of the 32 destination ports were observed in those communications. Figure 16: Volume and timing of inbound connections from the T2 for a sample of nine destination IPs Examining the timing and volume of connections for each destination IP, there appears to be no evident pattern suggesting the use of automation. The T2 C2s communicate with these IPs erratically and in inconsistent volumes. While it's conceivable that the activity is directly linked to operator actions, considering the observations previously discussed, it may actually be a hybrid of both systematic automation and random activity. We hypothesize that the selection of ports used in connections may be determined by an automated process, yet the connections themselves seem to be responsive to the unpredictable nature of C2 bot communications that outbound T2 connections appear to follow. NetFlow Observations IV: Characteristics of Destination IPs To enrich our analysis, we examined and compared characteristics such as AS and geolocation to those of hosts identified from typical upstream bot communication. Some T2 destination IPs were confirmed as proxies and subsequently removed from the data to prevent skewing observations based on specific host details. We first compared geolocations between T2 destination IPs and bot C2s identified from November to July 2023. We identified geolocations that were unique to bot C2s and not present among T2 destination IPs. Geolocations that were shared between the two datasets appeared in differing quantities. For instance, while only 31% of bot C2s were situated in the US, this figure increased to 60% of T2 destination IPs. Figure 17: Side-by-side comparison of the geolocations that are associated bot C2s and T2 destination IPs Next, we made a similar comparison of AS designations, filtered by geolocations with more than one IP. As pointed out by Black Lotus Labs, Qakbot seems to favor compromised hosts located in residential IP space, and our findings align with this observation. We found that Comcast is the predominant AS organization for both bot C2s and T2 destination IPs. According to our NetFlow data, the vast majority of US-based T2 destination IPs and (high confidence) bot C2s with upstream T2 connections are located within Comcast’s IP space. Figure 18: Side-by-side comparison of AS organizations associated with bot C2s and T2 destination IPs. Click the image to view it in full screen for better legibility. These characteristics lead us to develop a theory that additional criteria, such as geolocation and AS organization, may influence the selection of compromised hosts. These factors could determine which hosts are purchased from third parties, or decide which Qakbot victims are escalated to the status of bot C2s or become T2 destination IPs, at least in some cases. Conclusion In this post, we have sought to continue our understanding of the relationship between the various tiers of infrastructure associated with the QakBot operation. Our data illustrates the winding down of operations leading up to QakBot’s seasonal ‘lull’ in operations, which appears in part to have been accelerated by good work from Lumen’s Black Lotus Labs. However, we also demonstrate that there is not a total cessation in operations, new infrastructure continues to be stood up albeit at a reduced cadence - likely for future use once spamming recommences. We have also sought to illuminate interesting communications sourced from QakBot’s upstream infrastructure, with outbound traffic occurring to both reported and unreported QakBot C2s, as well as currently undefined servers. We have demonstrated possible relationships between this activity and inbound communications to the same upstream infrastructure, noting that activity does not overlap, but one may precede the other. We have established an interest in 32 specific ports, which the upstream infrastructure seeks to communicate with, potentially associated with QakBot’s proxy module. We have also shown that this activity is, at least in part, possibly human-generated, with some reliance on automation for certain elements of the activity (specifying ports). Finally, we hypothesized that certain factors may be considered when elevating a victim / compromised host to C2 status; including geolocation and who the host is assigned to from a hosting perspective. Drawing this all together, we hope to have provided some interesting leads into further investigation of the QakBot operation, as well as providing opportunities for identification and mitigation of its threat. In elevating victims to be used as C2 infrastructure with T2 communication, QakBot effectively punishes users twice, first in the initial compromise, and second in the potential risk to reputation of a host being identified publicly as malicious. We believe cutting off communications to the upstream servers is an effective remedy to the second part of this process; meaning that victim machines are cut off from further C2 instructions and in doing so protecting current and future users from compromise. Recommendations Users of Pure Signal Recon and Scout are able to follow this activity by querying for the three Russian T2 IPs. Cyber defenders should monitor for inbound connections from the three Russian T2 IPs over the ports listed below. In addition, to identify any compromised hosts that were elevated to Qakbot C2 status, monitor for outbound connections from the host to any of the T2 IPs over TCP/443. Indicators of Compromise Ports 20 21 22 53 80 443 465 990 993 995 1194 2078 2083 2087 2222 3389 6881 6882 6883 8443 32100 32101 32102 32103 50000 50001 50002 50003 50010 61200 61201 61202 RU T2 188.127.231.177 62.204.41.187 62.204.41.188 New Bot C2s (Figure 5) 73.32.187.91 81.20.248.72 103.107.36.56 113.193.95.44 113.193.166.238 180.151.16.132 197.86.195.132 197.87.63.16 197.87.135.186 197.87.135.218 197.87.143.152 197.87.143.229 197.89.10.173 197.92.136.237 201.130.167.212 Other C2s Observed Active January - July 2023 High Confidence 23.30.22.225 23.30.22.230 23.30.173.133 24.9.220.167 27.0.48.205 27.0.48.233 27.109.19.90 43.243.215.206 43.243.215.210 49.248.11.251 50.248.58.241 59.153.96.4 64.237.207.9 64.237.212.162 64.237.221.254 64.237.245.195 64.237.251.199 67.177.41.245 67.177.42.38 67.187.130.101 68.59.64.105 68.62.199.70 69.242.31.249 73.0.34.177 73.1.85.92 73.22.121.210 73.29.92.128 73.36.196.11 73.41.215.237 73.60.227.230 73.78.215.104 73.88.173.113 73.127.53.140 73.155.10.79 73.161.176.218 73.161.178.173 73.165.119.20 73.197.85.237 73.207.160.219 73.215.22.78 73.223.248.31 73.226.175.11 73.228.158.175 73.230.28.7 74.92.243.113 74.92.243.115 74.93.148.97 75.149.21.157 76.16.49.134 76.27.40.189 79.168.224.165 89.203.252.238 96.87.28.170 98.37.25.99 98.222.212.149 99.251.67.229 99.252.190.205 99.254.167.145 102.130.200.134 103.11.80.148 103.12.133.134 103.42.86.42 103.42.86.110 103.42.86.238 103.42.86.246 103.71.20.249 103.71.21.107 103.87.128.228 103.111.70.66 103.111.70.115 103.113.68.33 103.123.221.16 103.123.223.76 103.123.223.121 103.123.223.124 103.123.223.125 103.123.223.130 103.123.223.131 103.123.223.132 103.123.223.133 103.123.223.141 103.123.223.144 103.123.223.153 103.123.223.168 103.123.223.171 103.134.117.111 103.176.239.98 103.195.16.175 103.211.63.108 103.212.19.254 103.221.68.250 103.231.216.238 103.252.7.228 103.252.7.231 103.252.7.238 109.49.47.10 113.11.92.30 114.143.176.234 114.143.176.235 114.143.176.236 114.143.176.237 117.248.109.38 119.82.120.15 119.82.120.175 119.82.121.87 119.82.121.251 119.82.122.226 119.82.123.160 125.63.121.38 157.119.85.203 174.58.146.57 174.171.10.179 174.171.129.247 174.171.130.96 180.151.13.23 180.151.19.13 180.151.104.240 180.151.108.14 183.82.107.190 183.82.112.209 183.87.163.165 183.87.192.196 189.151.95.176 195.146.105.72 197.83.246.187 197.83.246.199 197.90.177.242 197.92.136.122 197.92.141.173 197.94.78.32 197.94.95.20 197.148.17.17 200.8.245.72 201.130.116.138 201.130.119.176 201.142.207.183 202.142.98.62 203.109.44.236 Medium Confidence ​49.205.181.242 64.237.188.252 64.237.213.86 69.255.128.224 73.14.226.243 73.45.247.179 76.149.184.246 96.85.69.170 96.85.69.171 96.92.67.169 98.244.148.34 103.204.192.220 138.68.166.127 138.197.95.196 175.100.177.171 180.151.18.235 180.151.107.118 180.151.118.243 183.82.122.136 187.199.135.157 187.211.104.152 187.211.105.137 189.248.64.238 197.92.131.106 201.142.195.172 201.142.197.29 201.142.213.13

Introduction In this blog post, we will provide an update on our continued analysis and tracking of infrastructure associated with IcedID’s BackConnect (BC) protocol; a continuation of the analysis we shared in late-December 2022, which you can read here, in addition to our campaign metrics and infrastructure tracking blog posts. Note: whilst the same BC protocol is utilized by several other threat operations, including Bazar and QakBot, this blog post focuses specifically on IcedID infrastructure. Given that it is deployed post-compromise following initial assessments of the value of a victim host, the use of the BC protocol is of particular interest to us, and remains a priority for our overall tracking of IcedID. Analyzing activity related to BC infrastructure provides a strategic view into threat actor activity and interests, as it is a window into what occurs after a successful infection and the victim was deemed valuable for their use. Since our last post, updates were made to the version of the BC protocol used by the IcedID threat actors during mid-April 2023. The last time we observed updates to the protocol was 7 months ago in September 2022. One of the more noticeable changes, shared by Palo Alto Networks’ Unit 42, was in the port utilized by victim hosts when connecting to the BC command and control (C2) server, which was updated from TCP/8080 to TCP/443. In our previous blog post, we referenced 11 IcedID BC C2 servers, active from the beginning of July 2022 through the end of 2022. Our analysis highlighted that generally two C2 servers were active at any given time, and the average life cycle for a C2 server was around four weeks. We will revisit this C2 timeline in order to assess how IcedID’s use of the BC protocol has evolved over the past six months, and in doing so also review the associated management infrastructure used to access / administer it. Key Findings The overall quantity of BC C2s has increased. A total of 34 medium and high confidence IcedID BC C2 servers were identified since 23 January 2023, up from 11 we observed from July 2022 until the end of the year. The average life cycle for a BC C2 has decreased. The average uptime of a BC C2 decreased from 28 days to eight days, and concurrently active servers increased from two to a maximum of four. Additional management infrastructure has been identified. Management activity continues to be sourced from two static VPN nodes, with other common management peers observed. Management-related activity has evolved from our last blog post. Management activity now varies from C2 to C2, we do not always observe connections from the same management IPs. Observed management activity is likely a mix of IcedID operator and affiliate access. Victims can communicate with multiple BC C2 servers over time. A possible connection between BC-infected victims and spamming activity was identified. C2 Server Timeline As explained in our previous blog post, a methodology was established for tracking BC C2 servers based on the observance of management traffic from a number of static IP addresses. By regularly monitoring outbound traffic from these IPs, we continue to identify new C2 servers as communications commence. Figure 2: IcedID BC Protocol Management - c. November 2022 In this instance, management traffic is defined as IP addresses observed in communications with multiple C2 servers, connecting to specific ports of interest, in repeated established sessions. The established sessions element is inferred based upon observed ephemeral ports and TCP flags, in simple terms; scenarios involving a consistent ephemeral port with evidence of a successful TCP three-way handshake and subsequent activity / data transfer. Figure 3: A Simple Visualization of the Previous Waffle 🙂 Getting back to the C2 servers, the following timeline illustrates the periods when we observed management traffic, and by extension an indication of when the C2 servers were in active use. Whilst this section is based on the enumeration of BC C2 servers since the aforementioned updates in April 2023, for completeness we include all identified C2 servers (since the beginning of 2023) in the Indicators of Compromise section at the end of this post. Figure 4: Timeline of BC C2 Servers from mid-April 2023 Onwards Since 11 April 2023, a total of 20 high confidence BC C2 servers were identified, based on pivots from management infrastructure. The first observation is that the number of concurrent C2 servers in operation has increased since our previous blog post, with as many as four C2 servers receiving management communications on a particular day. We also note that the life cycle of the C2 servers has decreased significantly, from around 28 days to just over eight. Figure 5: Previous Timeline - July to December 2022 There are a number of hypothesized reasons for these changes and each one is not independent of the others (nor is the following list exhaustive): Greater awareness of BC infrastructure has resulted in faster response times; both in reporting to hosting providers and mitigation activities; leading to a shorter C2 shelf-life. An increase in the use of the BC protocol by IcedID threat actors and their affiliates has required additional infrastructure to be stood up. Disruption / changes to activities has increased the need for additional back-up / fall-over C2 servers. General evolution of threat actor modus operandi - e.g. “statistics show that an individual C2 server reaches its peak potential on day N (<28 days), so why not rotate them more often?”. We know from analyzing other IcedID infrastructure that the admins run a metrics-influenced operation. Since IcedID returned from its winter hiatus on 23 January 2023 through the end of June 2023, we have identified 34 medium (50-75%) and high (75-99%) confidence BC C2 servers. In the case of the four medium confidence C2 servers, we (Team Cymru) were not able to confirm their usage with the same veracity, but on the balance of probabilities are likely connected to IcedID BC activity; indeed some were reported by other researchers. Management Infrastructure In this section we will provide background context on the IP addresses we have observed accessing the BC C2s on particular ports of interest; namely TCP/8082, TCP/8083, and TCP/8101. We assess that TCP/8082 relates to the BC SOCKS proxy, TCP/8083 to VNC (screen sharing), however at this stage it is unclear what the use of TCP/8101 relates to. We began to observe this port (TCP/8081) open on BC C2 servers over the past few months. The two IP addresses we detailed in our previous blog post (see Figure 2) continue to be used to access BC C2 servers, however they are no longer observed in every single case. The VNC Management IP continues to be accessed from IP addresses assigned to MOLDTELECOM-AS and was last observed communicating with BC C2 servers in early July 2023. The SOCKS Management IP continues to be accessed from an IP address assigned to a Ukrainian ISP, interspersed with irregular connections from Starlink infrastructure. Communications with BC C2 servers was last observed in early June 2023. Over the past six months, we have observed other IPs accessing the BC C2 servers. By following the activities of a number of these IPs we are able to fill in the blanks where we don’t see communications from those two originally identified management nodes. It is unclear why the IPs accessing the C2s vary depending on C2, ; although it is plausible to assess that the activity originates from both IcedID operators and their affiliates. The recently identified management IPs fall into three distinct categories: Private VPN Nodes These IPs appear to be utilized in the same way as the initial two management IPs, with a limited number of inbound peers. Outbound traffic is broadly limited to IcedID BC-related infrastructure, with connections occurring on all three ports of interest. German Node 🇩🇪 This IP connects to BC C2 servers on TCP/8101 and is currently active at the time of writing. Aside from connections to BC C2 servers, we also observe inbound connections from Tor relays - hinting at how this node is accessed. Latvian Node 🇱🇻 This IP connects to BC C2 servers on TCP/8082 and TCP/8083 and is also currently active at the time of writing. This IP is observed in traffic indicative of blockchain/cryptocurrency trading and the use of Tor and Tox messenger. TCP/1194, commonly associated with OpenVPN, is open on this IP - again hinting at how this node is accessed. Russian Node 🇷🇺 This IP connects to BC C2 servers on TCP/8082 and TCP/8101 and is also currently active at the time of writing. Aside from connections to BC C2 servers, we also observe outbound connections utilizing common mail ports (25, 143, 468, 993, etc). Figure 6: Private VPN Nodes - Hypothesized Management Access Jump Boxes In February we published a blog post stemming from an investigation into an IP address which was observed connecting to various elements/levels of the IcedID infrastructure, including BC C2 servers. This IP was geolocated to Chile, but there was clear evidence that it was utilized by a Russian-speaking operator. Since our last post, we have observed the Chilean jump box was accessed via an OpenVPN connection from an IP geolocated to Switzerland - assigned to Private Layer Inc, a Panamanian-registered VPS provider. We have continued to monitor this Swiss IP, which has led to the identification of further jump boxes, utilized in much the same way as we described in the blog. Figure 7: Jump Box Management and Identification Since June, an IP geolocated to the United States has been used as the current jump box and again this has included access to BC C2 servers. We continue to assess that this infrastructure is associated with IcedID administration. Russian Telecommunications (Rostelecom) These appear to be consumer IPs which, based on data from Spur Intelligence, are utilized as small gateways for a limited number of concurrent users. We have observed numerous IPs (with no cross-over in usage) assigned to Rostelecom, Russia’s largest ISP, in communication with BC C2 servers using port TCP/8083. Whois information for these IPs is consistent in identifying them as previous VolgaTelecom infrastructure for the Mari El region of Russia. VolgaTelecom was absorbed by Rostelecom in 2011; it is unclear if this infrastructure continues to serve Mari El, however this may provide an indication of the end user’s location if so. Outside of the connections to BC C2 servers, we observe general Internet usage, BitTorrent activity, and evidence of the use of crypto-mining software. Victimology In simple terms, victimology refers to the practice of understanding and studying the characteristics of victims versus focusing on the perpetrators. In cyber threat research we can use victim to C2 communications, at a large scale, to understand trends in threat activity. We looked for potential victims by identifying activity that matched typical C2 communication over TCP/443, excluding traffic that was likely researcher or scanner related. Eventually a sample of eight candidate victim IPs from various ASNs and geographical regions was collected, all of which communicated with three or more BC C2s over a relatively long period of time. We found there were many other potential victims connections to the C2 servers, but the majority communicated with only one or two, and for shorter time periods. In the timeline below, connections with the BC C2 servers for each victim is indicated by a line next to the geolocation of the victim. Each box on a line represents the start and end date of communication between the victim and the C2 server listed within the box. Underneath the x-axis of the timeline are flags showing when we first spotted the C2 in the management infrastructure we monitor (a replication of Figure 4). Figure 8: BC Victim Timeline For all of the victims in our sample, first connections to a new BC C2 server began after we identified the C2 via monitoring the management related IPs mentioned in the section above. The two management nodes we originally wrote about in our previous blog only communicated with five of the BC C2 servers, and in some cases this only occurred after victim traffic had commenced. This is a good example of why we continuously update our tracking of upstream threat actor infrastructure, whilst it might remain static for a duration, this infrastructure can change or be superseded by other key hosts. In the case of IcedID BC infrastructure we were able to adapt our insights by continuing to pivot from NetFlow data for known BC C2 servers. We see that victims can communicate with multiple BC C2s over time while they remain infected, but not every victim communicates with every new C2. In fact, there is no discernable pattern around how long a victim communicates with a C2, when victims switch to a new C2, or which C2 servers a victim communicates with. However, when we pivot to analyzing the volume of traffic between victims and C2s, we finally see a pattern emerge. Figure 9: Spikes in BC Victim Traffic Volume Regardless of C2, some days show jumps in traffic volume between the victims and C2 servers. For example, on 13 June 2023 there was a spike for the British, Japanese, and German victims, but they were not communicating with the same C2. The German and Japanese victims were communicating with C2 207.154.203.203, while the British victim was communicating with C2 68.183.198.18. This is potentially indicative of the overall coordination of IcedID victims interacted with using the BC protocol. Whilst victims may be communicating with separate C2 servers, we see peaks in activity within the same time parameters. This points to the same IcedID operator or affiliate accessing multiple victims for a specific purpose, likely via a panel which consolidates all victims together regardless of specific C2 server. TCP/587 and TCP/465 Activity While analyzing victim NetFlow data, we found that all eight victims from our sample group shared outbound connections to some of the same obscure mail servers over TCP/465 and TCP/587, typically in bursts on the same day. We hypothesize these communications may be connected to IcedID delivery / spam operations. Often we observe the victims connecting to the same mail servers concurrently, or scenarios when victims switch between mail servers which are ultimately in the same pool. Essentially, there is a lot of overlap which appears more than just coincidental, where batches of victim machines are used, presumably using the SOCKS element of BC, to access mail servers. When we look back into our data, we observe this pattern of activity occurring as far back as March 2023, and potentially even before. Additionally, the bursts of activity coincide quite clearly with the previous line chart showing the volume of connections between victims and BC C2s, specifically on: 10, 19, and 30 May 2023 13, 23, and 24 June (and an uptick at the end of the research window, 26/27 June) 2023 Figure 10: BC Victim Mail Server Traffic Are they related? Based on the comparison of the two charts, it seems likely. On the days where victims had a spike in BC C2 traffic, there was also a burst of activity from victims sending outbound connections to mail servers over TCP/587 (and sometimes TCP/465). It is unlikely that such a random group of victims would coincidently have the same type of activity on the same days, repeatedly over months. It’s far more unlikely that it would also coincidently align with victim/BC C2 activity. Whilst we have no definitive proof at this point in time, our current hypothesis, based on the findings described above, is that BC is used (at least in part) to enable spamming operations associated with IcedID and their affiliates. Specifically, the SOCKS element of BC is used to proxy connections to mail servers via a subset of IcedID victims. Conclusion In this blog post we have outlined how IcedID BC infrastructure has expanded over the first half of 2023; with an increase in C2 servers observed in total, and in parallel use at any point in time. We have also discussed some of our techniques for tracking emergent C2 infrastructure, often on a timeline whereby identification occurs before victim traffic is observed. Early identification is key to preventing future compromise, threat actor-victim interaction and eventual data / financial loss. In examining management infrastructure associated with IcedID BC, we are also able to discern a pattern of multiple distinct accesses from users we assess to be both associated with the day to day operations of IcedID, and their affiliates who interact with victim hosts post-compromise. Through victimology analysis we are also able to provide a hypothesized purpose for the BC protocol; we would assume one of several purposes. The evidence in our NetFlow data suggests that certain IcedID victims are used as proxies in spamming operations, enabled by BC’s SOCKS capabilities. This is a potential double blow for victims, not only are they compromised and incurring data / financial loss, but they are also further exploited for the purposes of spreading further IcedID campaigns. Recommendations Users of Pure SignalTM Recon and Scout can follow this activity by pivoting from the BC C2 servers provided in the IOCs section at the end of this blog post. In general we would recommend that the IOCs are used for cyber defense measures; both proactive blocking and reactive threat hunting. Threatfox is an excellent open-source resource for up to date IOCs relating to IcedID and many other threat campaigns. Indicators of Compromise BC C2 Servers 5.196.196.252 135.148.217.85 80.66.88.71 45.61.137.220 193.239.85.16 185.99.132.16 167.99.235.95 (Medium) 162.33.179.145 46.21.153.153 193.149.176.100 45.61.139.144 45.61.137.159 (Medium) 45.61.139.235 (Medium) 193.149.176.198 192.153.57.134 193.149.187.7 162.33.179.218 139.59.33.128 138.197.146.18 167.99.248.131 134.122.62.178 104.248.223.35 64.227.48.93 209.38.220.183 161.35.166.97 138.68.244.54 68.183.198.18 207.154.203.203 64.227.146.71 116.203.30.206 (Medium) 139.59.186.140 139.59.72.105 104.248.21.165 159.89.116.11

Uninvited guests lurking in IP space could harm you and your business Introduction: In the ever-evolving Internet landscape, a peculiar term called "Bogons" comes up occasionally. While it may sound whimsical or obscure, bogons have significant implications for senior stakeholders and IT professionals. In this blog post, we will delve into the world of bogons, exploring three compelling reasons why senior stakeholders should be motivated to take action, followed by three reasons why IT Security and IT Operations should be concerned about bogons. Part 1: What are Bogons? Bogons are like people who show up with fake reservations at your favorite restaurant; they will occupy your reserved table while you remain inconvenienced. In the world of computers and networks, these 'bogons' are like mysterious guests who shouldn't be there but somehow slip through the cracks and bring tangible business risks with them. 'Bogons' are IP addresses or network blocks that shouldn't exist on the Internet. They are reserved for private use and are not assigned to anyone, or the Regional Internet Registry (RIR) reclaims them and puts them on hold. Most bogons look and function like regular IP addresses, so your network devices won't necessarily take any action by default when they see traffic related to bogons. But since using bogons on the public Internet is already violating accepted best practices, chances are good that anyone using bogons may have malicious intentions in mind. Just as you wouldn't want nefarious or fake guests in a restaurant causing chaos, networks don't want bogons to cause any trouble. They can lead to various problems, such as unauthorized access attempts, network congestion, or data exfiltration. It's as if these rude guests are trying to disrupt the smooth flow of your evening on purpose. Secure networks use filtering systems to identify and block bogons, just as you would have a booking reference at the restaurant entrance to prevent unauthorized guests from entering. The filtering system checks incoming and outgoing network traffic, ensuring only valid IP addresses can pass through. This way, the network maintains order, security, and efficient operation. By filtering out bogons, networks can focus on legitimate traffic and avoid wasting resources on those mysterious and unnecessary addresses. It's like having a well-managed reservation system that only accommodates genuine guests, making your restaurant experience more secure and efficient. In summary, bogons are like unwanted guests in a restaurant who shouldn't be there. They are IP addresses that don't belong or aren't assigned to anyone on the public Internet. Filtering bogons from network traffic is crucial to maintain security, efficiency, and proper functioning, just as keeping unauthorized guests out of a restaurant ensures a smooth dining experience. Part 2: Reasons for Senior Stakeholders to Take Action Protecting Reputation and Brand: Senior stakeholders know the importance of maintaining a solid reputation and brand image. Accepting or passing network traffic related to bogons shows a general disregard for best practices on the Internet and lax enforcement of security standards. Network service providers, in particular, should take all necessary steps to prevent bogons from entering or leaving their networks, including from their customers. Bogons are often used for DDoS (distributed denial of service) and data exfiltration attacks, so even if bogons aren't impacting you directly, they may be traveling across your network to affect others. By running a clean network and implementing proper filtering mechanisms (bogon and otherwise), organizations can safeguard their brand integrity and maintain the trust of their customers and partners. Ensuring Regulatory Compliance: Compliance with data protection and privacy regulations is critical to business operations in today's digital age. Ignoring bogons can expose organizations to compliance violations and compromise, potentially resulting in legal repercussions and financial penalties. Taking a proactive approach to identifying and filtering bogons demonstrates a commitment to maintaining a secure and compliant infrastructure, which can help senior stakeholders avoid legal troubles and ensure a robust governance framework. Mitigating Operational Risks: Bogons can introduce operational risks by consuming network resources, leading to unnecessary costs, performance degradation, or service disruptions. These unapproved addresses can clutter network traffic and divert valuable resources, affecting the overall efficiency of IT operations. By addressing bogons, senior stakeholders can minimize risks, optimize network performance, and ensure uninterrupted functions, improving productivity and customer satisfaction. Part 3: Why IT Security and IT Operations should be ‘bogon proactive’ Enhancing Network Security: Bogons are often associated with malicious activities, making them a priority for IT Security teams to identify and mitigate. Attackers can exploit unallocated or invalid addresses within bogon prefixes to launch attacks, infiltrate networks, or disguise their malicious activities. Implementing effective bogon filtering mechanisms bolsters network security by: preventing unauthorized access attempts reducing the attack surface improving threat detection capabilities. Avoiding False Positives and Misconfigurations: Bogons can contribute to false positives and misconfigurations in security systems and network devices. Without proper filtering, security solutions may flag bogon addresses as potential threats in error, triggering unnecessary alerts and straining security teams. Moreover, misconfigured systems or devices may inadvertently allow bogon traffic, undermining the effectiveness of security measures. By actively addressing bogons, IT professionals can: minimize false positives streamline incident response efforts optimize security operations. Ensuring Efficient Resource Allocation: Bogons consume valuable network resources, including bandwidth, processing power, and storage. This inefficient resource allocation can impact overall system performance, leading to degraded user experience and reduced operational efficiency. By implementing robust bogon filtering mechanisms, IT Operations teams can: Reclaim these resources, optimize network utilization, and ensure efficient allocation for critical business functions Improve performance, scalability, and cost-effectiveness Conclusion Despite their whimsical name, Bogons pose tangible risks and challenges for organizations across industries. By understanding the motivations of senior stakeholders and recognizing the concerns of IT Security and IT Operations, organizations can take proactive steps to address bogons. Implementing effective filtering mechanisms, investing in network security measures, and optimizing resource allocation will enhance the organization's cybersecurity posture and improve reputation, regulatory compliance, and operational efficiency. Embracing the battle against bogons is essential to navigate the ever-changing cybersecurity landscape and safeguard the digital infrastructure in today's interconnected world. Recommendations Don't panic. However, bogon filtering is non-trivial and requires careful planning and execution to ensure minimal disruption to services, networks, and infrastructure. Bogon filtering complexity is compounded by the fact that specific bogon filtering lists can change daily. One day an IP is a bogon; next week, it may be a valid IP address. However, with some examples of web server traffic volumes being significantly bogon related, the challenges are worth the rewards. Team Cymru provides free access and trusted and constantly updated tools to help organizations filter out bogon IPs. These tools seamlessly integrate into your webservers, firewalls, routers, and monitoring systems. Bogons are likely a potential risk or direct threat to your organization; sign up for our free-to-use bogon filtering service here.

At the beginning of this year, we released a detailed publication on Vidar infrastructure, encompassing both the primary administrative aspects, and the underlying backend. In that publication, we highlighted three key insights: Russian VPN gateways had the potential to confer anonymity to Vidar operators and customers, thereby rendering it more arduous for analysts to attain a comprehensive understanding of the threat. These gateways were observed to be transitioning towards Tor. There were indications of Vidar operators expanding their infrastructure, necessitating continued vigilance from analysts. We anticipated an influx of new customers and consequently a surge in campaigns in forthcoming weeks. The analysis revealed that Vidar operators had segregated their infrastructure into two distinct components: one dedicated to regular customers and the other specifically catering to the management team, as well as potentially serving premium or high-priority users. As a refresher, Vidar is an info-stealer malware, which was first spotted in the wild in late 2018 by the security researcher Fumik0. Upon initial inspection, the identified sample appeared to be Arkei (another info-stealer), however differences in both the sample’s code and C2 communications were observed. The name itself (Vidar) is derived from a string found in the malware’s code, alluding to the Norse god Víðarr. Vidar is considered to be a distinct fork of the Arkei malware family. As of the end of January 2023 (and as described in our previous blog), Vidar’s administration and backend infrastructure was configured as follows: Figure 1: Vidar Infrastructure as of January 2023 Over the past four months, several changes have occurred within this infrastructure configuration. Therefore, the intention of this blog post is to provide a comprehensive update on how Vidar is administered / operated today. Key Findings Vidar threat actors continue to rotate their backend IP infrastructure, favoring providers in Moldova and Russia. Evidence suggests that since our last blog post, the threat actors have taken steps to anonymize their activities using public VPN services. By tracking the hosting of the main Vidar site (presently my-odin[.]com), we are able to monitor other aspects of the threat actors infrastructure, potentially illuminating both affiliates and victims. Vidar’s Spring Makeover(s) Since August 2022, Vidar threat actors have utilized the domain my-odin[.]com as the primary location for managing various elements of their operation, including affiliate authentication, file sharing, and panel administration. Previously, it was possible to download any files hosted on the URL path /private, such as the bash script responsible for installing the necessary components for a new Vidar campaign, making it possible to monitor malware updates. However, more recently, changes were made whereby if an unauthenticated attempt to download a file occurs, the user is redirected to the Vidar affiliate login page. In the period since our previous blog post was published, there were two updates to the IP address used to host my-odin[.]com. In parallel with these changes, updates were also made to the background infrastructure supporting the Vidar operation, which we will detail below. Technically speaking, the IP address for my-odin[.]com was updated three times, however in the case of the update from 186.2.166.15 (ProManaged LLC) to 5.252.179.201 (MivoCloud SRL) very little else changed, with the infrastructure remaining largely as described in our previous blog post (Figure 1). March 2023 At the end of March 2023 the IP address was updated from 5.252.179.201 to 5.252.176.49, with the threat actors continuing their use of MivoCloud SRL-assigned infrastructure. With this transition, other alterations were also made behind the scenes. The primary IP address (the ‘Managing IP’ in Figure 1) used to manage 5.252.176.49 was accessed via ‘new’ peers, utilizing the Remote Desktop Protocol (RDP). As far as we can tell, this server was previously accessed directly. From mid-March 2023 onwards, the RDP management activity was sourced from ProtonVPN relays which appeared to be used more broadly by other users, mainly for benign activities. By using VPN infrastructure, which in at least part was also utilized by numerous other benign users, it is apparent that the Vidar threat actors may be taking steps to anonymize their management activities by hiding in general Internet noise. In addition to the changes in how the management IP is accessed, we also observed ‘new’ outbound connections from the IP (5.252.176.49) hosting my-odin[.]com. Communications with infrastructure associated with ‘blonk[.]co’; Blonk is a recruitment platform which utilizes AI to match candidates with opportunities, in the way that dating applications match potential partners. The precise reason for these communications being observed from Vidar management infrastructure is uncertain, however it is plausible that the threat actors may use this platform in their operations; for identifying targets / victims, or perhaps even for recruitment. Finally, we continued to observe outbound connections to 185.173.93.98:443, a host located in Russia assigned to Adman LLC. In addition to the TCP/443 traffic it was also observed in GRE tunnelling activity with 5.252.176.49. This IP (185.173.93.98) operates as a conduit between Vidar’s my-odin[.]com and proxy_pass infrastructure (we detailed proxy_pass in our previous blog post). Figure 2 below summarizes the Vidar infrastructure as of the end of April 2023, as detailed above. Figure 2: Vidar Infrastructure as of April 2023 May 2023 During May 2023, we observed the initiation of the process to update the hosting IP for my-odin[.]com once more. Again (this finding was also documented in our previous blog post) the Vidar threat actors reused the same SSL certificate when transferring infrastructure, revealing the new IP address; 185.229.64.137 (S.C. INFOTECH-GRUP S.R.L.). Figure 3: SSL Certificate for my-odin[.]com Based on our network telemetry data, we can see that communications with 185.229.64.137 commenced on 03 May 2023; this aligns with other open source passive DNS information for the domain resolution. Figure 4: Summarized Communications Involving 185.229.64.137 The behaviour of the new IP address hosting my-odin[.]com remains broadly consistent with previous (5.252.176.49), however we also observe inbound connections from Tor relays; potentially evidence of Vidar affiliates accessing their accounts / malware repositories. The change in infrastructure detailed above is summarized in Figure 5 below. Figure 5: Vidar Infrastructure as of June 2023 Conclusion This short update provides further insight into the ‘behind-the-scenes’ operation of Vidar, demonstrating the evolution of its management infrastructure as well as evidence of steps taken by the threat actors to potentially cover their tracks. By continuing to track this infrastructure we are able to identify future changes, as well as uncovering evidence which may support victim and/or affiliate identification. Elements of the infrastructure were redacted from this blog post as investigations are currently ongoing; lower confidence aspects will be shared in the future once confirmation of findings have taken place. As ever, we will continue to update the community on any new or emergent findings related to Vidar and other connected threats. Recommendations Users of Pure SignalTM Recon and Scout are able to track Vidar management infrastructure by querying for my-odin[.]com or the associated hosting IP addresses referenced in this blog post.

A Data-Driven Approach based on Analysis of Network Telemetry This blog post seeks to draw out some high-level trends and anomalies based on our ongoing tracking of QakBot command and control (C2) infrastructure. By looking at the data with a broader scope, we hope to supplement other research into this particular threat family, which in general focuses on specific infrastructure elements; e.g., daily alerting on active C2 servers. This blog represents an ongoing piece of research, our analysis of QakBot is fluid with various hypotheses being identified and tested. As and when we uncover new insights into QakBot campaigns we will seek to provide further written updates. We are not going to go over the entire history and functionality of Qakbot, for which there are numerous, well written reports on the subject. However, there are a couple of details relevant for this analysis worth mentioning. Qakbot campaigns are tracked by the threat actors via affiliate IDs that are included in the malware configurations, at present the most active are “Obama” and “BB”. Whilst each malware configuration includes a list of around 100 to 150 potential C2s, only a fraction are actually used for bot communications. Refill your coffee and get comfortable, things are about to get data heavy. Key Findings QakBot C2 servers are not separated by affiliate ID. QakBot C2 servers from older configurations continue to communicate with upstream C2 servers months after being used in campaigns. Identification of three upstream C2 servers located in Russia, two of which behave similarly based on network telemetry patterns and the geolocations of the bot C2s communicating with them. When one upstream C2 server goes down for a period of time, other upstream C2 servers see a spike in C2 traffic volume. The majority of Qakbot bot C2 servers are likely compromised hosts that were purchased from a third-party. Based on our data, most of these compromised hosts are located in India. Active C2 Servers By analyzing outbound connections from known victim-facing C2 servers, we are able to determine upstream management (Tier 2) infrastructure based on communications with common peers. In most cases a particular management port is utilized and generally communications are ‘ongoing’ for extended periods. Once this Tier 2 (T2) management layer is identified, we are able to further determine which victim-facing C2 servers are currently active, based on the observation of connections to this T2 layer. This is a family agnostic process, not limited to QakBot C2 infrastructure. In the case of Qakbot, C2 servers from campaigns associated with the affiliate IDs “Obama” and “BB” have been communicating with the same three upstream Russian T2 servers over TCP/443 for months. Russian IP space is often used in higher tiers of botnet infrastructure due to the protection it offers against (non-Russian) LEA activity and researcher visibility. It is a bit of a catch-22, however, since repeated outbound connections to Russian IP space from source IPs located in various random countries tend to stand out as anomalous, or at least, of interest. Using C2 configuration data from April 2023 QakBot campaigns, we confirmed that the upstream Russian T2 servers remained unchanged. We then sifted through all of the C2 servers to identify those that connected to them over TCP/443. Interestingly, most of the C2 servers with this upstream traffic were listed in configurations from both Obama and BB campaigns. Five IPs were unique to Obama campaigns, and only one was unique to BB within this timeframe (specifically BB23 with campaign ID 1681114726). Bot C2s to Upstream T2s The graphs below display the volume of traffic flows from 1 March to 8 May 2023 for the active C2 servers identified above, categorized by the affiliate configurations they appeared in. Each color represents one of the upstream Russian IPs, referred to as RU1, RU2, and RU3. April C2 servers present in both Obama and BB campaigns April C2 servers only present in Obama campaigns April C2 servers only present in BB campaigns In general, the affiliates do not seem to be separated by the upstream infrastructure with which their C2 servers communicate. However, there are some exceptions. For instance, a single unique BB C2 was live for two days and mostly communicated with RU3, with one connection to RU2 on the first day. C2s from the Obama campaigns primarily communicated with RU2 and RU3, although there were a few interactions with RU1 in early April. In April, there seems to be a gap in activity for RU2 and RU3. To gain a clearer understanding of the overall C2 to T2 traffic volumes, it is necessary to combine all active C2s from April, regardless of affiliation. All April C2 Servers RU2 and RU3 exhibit similar patterns to each other, while RU1 follows a separate pattern. Traffic volumes consistently decrease over weekends for all three, a trend commonly observed in e-crime infrastructure. Interestingly, RU2 and RU3 were nearly inactive from 21 April until 1 May 2023. Upon resuming activity, C2 communication over TCP/443 spiked to levels twice as high as before the period of inactivity. During the inactivity period, there was a significant surge in traffic volume to RU1. However, just before the return of RU2 and RU3 in early May, the traffic volume to RU1 reduced to roughly match their volume patterns. Many C2 servers from this timeframe became active around mid-March and increased their activity beyond April. For comparison, the graph below includes all other confirmed or high confidence C2 servers that communicated with the Russian IPs over TCP/443 since 26 January 2023 (but were not included in April campaigns). C2 Servers First Active Prior to April 2023 These previous C2 servers experienced spikes in activity, presumably when they were included in malware configurations, as observed with the C2 servers identified as active during April 2023. Subsequently, the traffic volume of these previous C2 servers significantly decreased but remained active. In a future blog post, we will revisit this topic and explore the timelines of C2 servers and the relationships between affiliates. From this perspective, there are fewer similarities between RU2 and RU3, although they still share more alignment than with RU1. It also appears there have been previous periods of inactivity when C2 servers ceased communicating with an upstream Russian IP, as observed with RU1 from 25 February to 6 March 2023. These older C2 servers also stopped communicating with RU1 for approximately three weeks from the end of March through April, but they resumed connections on 19 April 2023. C2 servers included in April campaigns continued to communicate with RU1 during this period. Telemetry by IP Geolocation There appears to be a potential relationship between RU2 and RU3 based on the April C2 traffic volume patterns. Hypothesizing from Qakbot's intermittent use of geofencing payloads, perhaps this relationship is influenced by geolocation. The following comparison shows confirmed and high confidence C2s, active between 26 January and 8 May 2023, categorized by geolocation for each of the three Russian T2s. This section is caveated by the potential for observation bias. Team Cymru’s global coverage varies from region to region, and from day to day based on sampling rates and data volumes. RU1 RU2 RU3 The volume and diversity of C2s for all three Russian T2s changed their patterns around the second week of March, with increased activity for India (IN) and United States (US) located IPs, and a decrease in the number of different GEOs with active C2 servers. RU2 and RU3 once again exhibit similar patterns and receive traffic from all US-based C2 servers, as well as C2s from other North American locations not observed with RU1. During this timeframe, RU1 showed less diversity compared to RU2 and RU3, predominantly utilizing hosts located in India. There were only two short periods in February and March when US and Czech Republic (CZ) C2 servers connected to RU1. The CZ hosts were seen communicating with all three T2s around the same time period in February. More recently, hosts geo-tagged as South African (ZA) have started communicating with all three T2s, but most consistently connect to RU1. One last thing to note: Qakbot C2 servers are historically compromised machines, either purchased from third parties or infected and turned into bots (although the latter is less common). Combining the above information into one graph reveals that starting in March, India is by far the most prevalent country for active Qakbot C2s. These compromised machines are most likely purchased from a broker serving the e-crime community. Conclusion This analysis provides a recent snapshot of the Qakbot infrastructure, highlighting observed trends and anomalies. By visualizing this data through line charts, we have uncovered intriguing insights into the inner workings of Qakbot's infrastructure. While the data can be utilized to identify potential threats and implement proactive measures, the primary focus of this post is to highlight the interesting data points that can be uncovered through network telemetry analysis. By leveraging these insights, readers can gain a deeper understanding of the tactics and strategies employed by cybercriminals to carry out their attacks. Recommendations We recommend that the IOCs listed at the end of this blog post are used by cyber defenders to hunt for existing QakBot infections, as well as in blocking future attacks. For users of Pure Signal™ Recon and Scout, the aforementioned Russian T2 servers are identifiable by querying against the IOC list; filtering on outbound connections to remote TCP/443. Pivoting on inbound connections to the Russian T2 servers will illuminate new QakBot C2 infrastructure over time. Indicators of Compromise Below are the confirmed Qakbot bot C2 servers that we have identified communicating with upstream T2 infrastructure over TCP/443 this year. 23.30.22.225 23.30.173.133 24.9.220.167 27.0.48.205 27.0.48.233 27.109.19.90 43.243.215.206 43.243.215.210 59.153.96.4 64.237.207.9 64.237.212.162 64.237.221.254 64.237.245.195 64.237.251.199 67.187.130.101 68.62.199.70 69.242.31.249 73.22.121.210 73.29.92.128 73.36.196.11 73.60.227.230 73.78.215.104 73.88.173.113 73.155.10.79 73.161.176.218 73.161.178.173 73.165.119.20 73.215.22.78 73.223.248.31 73.228.158.175 73.230.28.7 74.92.243.113 74.92.243.115 74.93.148.97 75.149.21.157 76.16.49.134 76.27.40.189 89.203.252.238 96.87.28.170 98.37.25.99 98.159.33.25 98.222.212.149 99.251.67.229 99.252.190.205 99.254.167.145 103.11.80.148 103.12.133.134 103.42.86.42 103.42.86.110 103.42.86.238 103.42.86.246 103.71.20.249 103.71.21.107 103.87.128.228 103.111.70.66 103.111.70.115 103.113.68.33 103.123.221.16 103.123.223.76 103.123.223.121 103.123.223.130 103.123.223.131 103.123.223.132 103.123.223.141 103.123.223.144 103.123.223.168 103.123.223.171 103.212.19.254 103.231.216.238 103.252.7.228 103.252.7.231 103.252.7.238 109.49.47.10 114.143.176.234 114.143.176.235 117.248.109.38 119.82.120.15 119.82.120.175 119.82.121.87 119.82.121.251 119.82.122.226 119.82.123.160 157.119.85.203 174.58.146.57 174.171.10.179 174.171.130.96 180.151.104.240 180.151.108.14 183.82.107.190 183.82.112.209 183.87.163.165 183.87.192.196 189.151.95.176 197.92.136.122 197.94.78.32 197.94.95.20 201.130.119.176 201.142.195.172 201.142.207.183 201.142.213.13 202.142.98.62

Six reasons why going faster with Cyber Threat Reconnaissance is mission critical Introduction Cyber Threat Reconnaissance is a critical aspect of any cybersecurity strategy. With cyber attacks becoming more frequent and sophisticated, it is essential for organizations to gather intelligence and stay ahead of potential threats. Key components of effective Cyber Threat Reconnaissance include: visibility of external threat actor infrastructure data, integrations to power automation, speed of data acquisition, and the enabling of analysts to be highly agile when using threat hunting tools. In this blog post, we’ll discuss the six key advantages of these components in the process of Cyber Threat Reconnaissance. Key Advantage 1: Enhanced Visibility External threat actor infrastructure data provides valuable insights into the traffic patterns and behavior of indicators of compromise (IOCs) on the internet. This data can help analysts identify anomalies, such as unusual traffic patterns interacting with their own infrastructure, or suspicious connections that may indicate a cyber threat. By having access to external threat actor infrastructure data, analysts can proactively detect and respond to potential threats before they escalate into a full-scale attack. Key Advantage 2 Real-time Data Acquisition Speed of data acquisition is crucial in Cyber Threat Reconnaissance. In today's fast-paced environment, cyber threats can emerge and evolve quickly. Real-time data acquisition allows analysts to quickly gather information about potential threats and respond proactively. With fast data acquisition, analysts can detect threats and take action before they cause significant damage. Key Advantage 3: Agile Analyst Tools that easily integrate Agility of analyst tools is another critical factor in Cyber Threat Reconnaissance. Analysts need to have access to powerful and flexible tools that enable them to quickly integrate across multiple platforms, enabling more stakeholders to analyze data and identify potential threats and risks. With agile tools that can rapidly process large volumes of data from multiple sources, analysts are more able to identify patterns and trends, and enable informed decisions about the best proactive course of action. Key Advantage 4: Improved Decision-making With enhanced visibility, real-time data acquisition, and agile analyst tools, Cyber Threat Reconnaissance can improve decision-making. Analysts can quickly identify potential threats and respond proactively, rather than reactively. This approach can help organizations limit financial losses, utilize analyst time more efficiently, and shield resources from being drained, this helps to prevent damage to their systems and data, and reduce the risk of reputational harm. Key Advantage 5: Comprehensive Threat Detection The combination of enhanced visibility, real-time data acquisition, and easily integrated agile analyst tools can lead to more comprehensive threat detection. Analysts can identify external threats at different stages of the cyber attack lifecycle, from reconnaissance to exfiltration. This approach can help organizations prevent attacks before they occur, and minimize the damage if an attack is already in progress. Key Advantage 6: Reduce risks = lower operational costs Quickly identifying threat actors and their infrastructure, and then proactively monitoring them is proven to have tangible cost savings as proven by our own findings. A cyber threat platform that consolidates multiple data sources isn’t just less complex and easier to integrate, it has proven ROI. Use Cases include validating real-world threats as they are unfolding to build better and stronger defenses, among others that enable organizations to shift from reactive to more optimal proactive strategies. With the average cost of a data breach at a painful $4.35M according to IBM, prevention continues to be more cost-effective than cure. Conclusion In conclusion, effective Cyber Threat Reconnaissance is a critical aspect of any cybersecurity strategy. Visibility of external threat actor infrastructure data, speed of data acquisition, and agility of analyst tools are essential factors that can significantly enhance Cyber Threat Reconnaissance. By having access to these key advantages, organizations can detect and respond to potential threats proactively, prevent damage to their systems and data, and reduce the risk of reputational harm and the financial impact of being victim to a criminal group or sophisticated threat actor. Recommendations Read our blogs on Cyber Threat Reconnaissance maturity, Part 1 and Part 2. Get introduced to Pure Signal Scout™, the world's fastest threat analysts tool for global threat infrastructure telemetry free trial here. Use IoCs from our own S2 Team Threat Research Blogs to speed up your discovery of threat actor infrastructure here.

O Team Cymru tem uma missão clara: Salvar e Melhorar Vidas Humanas. Nós nos esforçamos para cumprir essa missão, equipando os defensores de rede com insights provenientes de métricas de Internet, que processamos e refinamos esses dados em uma forma útil de inteligência de ameaças. Ocorrem mal-entendidos sobre o uso de métricas de tráfego de Internet para proteger as redes de ataques e abusos. Este post procura esclarece como coletamos, refinamos e distribuímos inteligência de ameaças derivadas de dados provenientes da Internet. Fazemos isso para nossos clientes e para a comunidade de defensores da segurança na Internet, que acreditam em tornar a Internet mais segura para todos. Esperamos que este post ajude a explicar a missão que temos perseguido apaixonadamente por mais de 20 anos. A Team Cymru é um ‘corretor de dados[1]’ Fato: Nós não somos um corretor de dados. Nosso foco está em dispositivos de Internet comprometidos e malévolos, não em pessoas. Não mantemos dados de assinantes que permitam que qualquer usuário de nosso produto conecte uma pessoa a uma parte da infraestrutura da Internet. Os dados que sustentam o nosso produto são legalmente tratados e estão em conformidade com todos os regulamentos de privacidade de dados aplicáveis, incluindo GDPR, CCPA e outras legislações de privacidade estaduais e nacionais relevantes. Nossa plataforma não mostra o tipo, o uso ou os usuários dos serviços de Internet. Mito: A plataforma Augury disponibiliza uma ampla gama de diferentes tipos de dados da Internet para seus usuários, incluindo dados de captura de pacotes (PCAP) relacionados a e-mail, área de trabalho remota e protocolos de compartilhamento de arquivos. Fato: Nossa plataforma não coleta e-mail, área de trabalho remota ou compartilhamento de arquivos (FTP, torrents, et al.) na Internet. Numerosos estudos mostraram que a coleta de e-mails não é possível porque a grande maioria dos e-mails é criptografada de ponta a ponta. Em um relatório do Google de setembro de 2022 [2], foi mostrado que 75% dos e-mails de saída e 86% dos e-mails de entrada são criptografado em trânsito. O e-mail enviado e recebido para muitos provedores, como Google, Microsoft, Cloudflare, Amazon, Comcast, Apple iCloud, Facebook, LinkedIn, Twitter, Instagram e Protonmail, é criptografado em trânsito por padrão via TLS, sem qualquer configuração de usuário necessária. De acordo com a Microsoft [3], o Protocolo de Ambiente de Trabalho Remoto (RDP) tem sido encriptado por predefinição desde 2009. Extraímos endereços de e-mail maliciosos (não o conteúdo), tentativas de acesso à área de trabalho remota e tentativas de acesso à FTP por meio de nossas sandbox de malware, e relatamos spam e phishing de nossas armadilhas de spam e honeypots. Todos os nossos PCAPs são gerados em nossa própria infraestrutura interna. Mito: "Os dados da Augury também podem incluir atividades do navegador da Web, como URLs visitadas e uso de cookies". Fato: Nossa plataforma não é capaz de coleta e apresentação de tráfego da Web global. Nossa plataforma fornece apenas URLs e cookies mapeados para servidores maliciosos. Estudos provaram que essa atividade de coleta simplesmente não é possível. A web é uma esfera criptografada, mantendo o tráfego da web a salvo de olhares indiscretos. O estudo de transparência do Google [4] mostra que mais de 90% dos carregamentos de páginas através do navegador Chrome são criptografados por HTTPS. Na revisão do Google dos 100 principais sites, que respondem por 25% de todo o tráfego global da web, 100 em cada 100 desses sites fornecem criptografia e 97 deles têm como padrão a criptografia. Scott Helme [5] realizou verificações do Alexa top um milhão de sites, e mostrou que 72% dos principais um milhão de sites padrão para criptografia. O Conselho de Segurança da CA [6] previu que mais de 90% do tráfego da web seria criptografado até maio de 2019, combinando previsivelmente as descobertas atuais do Google. O projeto de Telemetria do Firefox [7] concluiu que 87% de todos os carregamentos de páginas pelos navegadores Firefox foram criptografados. No entanto, existem sites comprometidos, com o estudo Webtribunal [8] de abril de 2022 observando que 1 em cada 10 URLs são maliciosas. A IBM observou [9] em 2020 que 30.000 sites são hackeados todos os dias. Por meio de nossos mecanismos de análise de malware, scanners, honeypots, armadilhas de spam, detecção de phishing, plataforma IDS e feeds de IOCs (indicadores de comprometimento), identificamos sites comprometidos. Esses sites espalham malware, comandam exércitos de bots e lançam ataques, além de roubar credenciais. Os defensores de rede querem detectar, bloquear ou limpar esses dispositivos e dispositivos infectados relacionados o mais rápido possível. Nossa plataforma torna possível ver esses sites que foram hackeados. Esses dados estão vinculados exclusivamente a atividades maliciosas e infraestrutura maliciosa, e os defensores da rede que usam nossas ferramentas dependem deles para defender melhor sua própria infraestrutura. Mito: A equipe Cymru obtém dados PCAP dos ISPs com os quais tem relacionamentos. Fato: Nós não obtemos dados PCAP de qualquer 3ª parte. Investimos recursos significativos para executar nossa própria plataforma global de honeypots, sensores IDS, scanners e vários mecanismos de processamento de malware. Nossa infraestrutura é a fonte de nossos dados. Esses dados formam a base de nossos produtos e serviços, incluindo serviços gratuitos como nosso Programa de Assistência à CSIRTs (Computer Security Incident Response Team) e o Registro de Hash de Malware (MHR). As equipes da CSIRT em mais de 154 países baixam nossa inteligência de ameaças diariamente sem custo. Milhões de consultas chegam aos nossos portais de insights disponíveis publicamente e nossos clientes usam nossos feeds e plataformas para defender suas redes. Nossa reputação estelar resulta de duas décadas de parceria com as comunidades e defensores da rede. Mito: "Augury também contém os chamados dados netflow ... Os registros Netflow podem revelar a quais servidores os usuários se conectam, muitas vezes revelando sites específicos que visitam. Os registros também podem revelar o volume de dados enviados ou recebidos e por quanto tempo um usuário acessou um site. Fato: Augury não fornece a ninguém acesso a dados brutos ou de fluxo de rede em massa. Os registros Netflow não contêm conteúdo ou informações do usuário. É estatisticamente impreciso afirmar que o netflow pode ser usado para identificar um indivíduo ou fornecer um padrão de vida que pode ser mapeado para uma pessoa e preferências. Consultas limitadas e específicas que produzem resultados anônimos e agregados podem ser derivadas do netflow amostrado. O Netflow não identifica usuários. Os dados do Netflow incluem apenas cabeçalhos, como endereços IP de protocolo e dispositivo. É amostrado e, portanto, vê apenas aproximadamente 1 em cada 10.000 fluxo. Essas sessões incluem varredura, hacking, DDoS e outras formas de atividade maliciosa. Além disso, as sessões legítimas são conduzidas através de redes de entrega de conteúdo (CDN) atrás das quais estão milhões de sites. Dos 1 milhões de principais sites [10 ], 43,96% ficam atrás de CDNs, 59,04% dos 100 principais sites e 61,95% dos 10 principais sites. É impossível usar o netflow para diferenciar entre esses sites. Além disso, a infraestrutura compartilhada entre provedores de nuvem impede ainda mais a identificação de infraestruturas hospedadas em nuvem específicas. Portanto, é estatisticamente impreciso afirmar que o netflow pode ser usado para identificar um indivíduo ou fornecer um padrão de vida que possa ser mapeado para uma pessoa e preferências. Não há logs ou qualquer conteúdo incluído no netflow. Controladores maliciosos, varreduras em larga escala e DDoS têm uma persistência e periodicidade que revela um padrão estatístico, permitindo o mapeamento de infraestruturas maliciosas e identificando dispositivos hackeados de importância para os defensores da rede. Augury permite o mapeamento de dispositivos maliciosos, não de pessoas. Consulte nosso Monitor de Ameaças Nimbus e outros Serviços Comunitários para obter detalhes adicionais. https://www.team-cymru.com/community-services [11] Mito: "Augury fornece diferentes níveis de acesso para clientes privados (comerciais) e governamentais. Fato: Falso. Há uma plataforma idêntica com camadas baseadas em uso. Por favor, encaminhe os pedidos de mais informações para media@cymru.com Endnote [1] https://en.wikipedia.org/wiki/Information_broker [2] https://transparencyreport.google.com/safer-email/overview?hl=en [3] https://scotthelme.co.uk/top-1-million-analysis-november-2021 [4] https://techcommunity.microsoft.com/t5/security-compliance-and-identity/top-10-rdp-protocol-misconceptions-8211-part-2/ba-p/246716 [5] https://transparencyreport.google.com/https/overview?hl=en [6] https://scotthelme.co.uk/top-1-million-analysis-november-2021 [7] https://vmblog.com/archive/2019/01/10/ca-security-council-2019-predictions-the-good-the-bad-and-the-ugly.aspx [8] https://telemetry.mozilla.org [8] https://webtribunal.net/blog/ssl-stats/ [9] https://community.ibm.com/community/user/security/blogs/lissa-coffeey1/2020/11/30/global-website-hacking-statistics-in-2020 [10] https://trends.builtwith.com/cdn [11] https://www.team-cymru.com/community-services

Identifying Connected Infrastructure and Management Activities Introduction This blog post seeks to build on recent public reporting on campaigns attributed to SideCopy, a Pakistani-linked threat group. SideCopy has been active since 2019, primarily targeting South Asian countries, with a focus on India and Afghanistan. The group's name comes from its use of an infection chain that mimics that of SideWinder APT, an Indian-linked threat group. The distinction between SideWinder and SideCopy was first made by security researcher @Sebdraven and is documented here. Some reports suggest that SideCopy may be a subdivision of Transparent Tribe (APT36), with similar tactics and techniques observed. The S2 Research Team has blogged previously on the activities of Transparent Tribe: Transparent Tribe APT Infrastructure Mapping - Part One Transparent Tribe APT Infrastructure Mapping - Part Two In this post we share the discoveries of our S2 Threat Research Team after examining analysis by the Chinese cyber security company QiAnXin, published on 20 March 2023, which detailed a SideCopy attack chain used to deploy AllaKore RAT. AllaKore RAT is an open-source remote access tool which has been modified for the purposes of SideCopy operations, and is commonly observed in their intrusions. Key Findings Identification of additional malware samples and C2 infrastructure associated with SideCopy targeting of the Indian Ministry of Defense Evidence of management activity sourced from mobile IPs located in Pakistan, centered around a key IP address (66.219.22.252) connected to SideCopy’s use of Action RAT Further credence provided to the assessment that SideCopy is a Pakistani-linked threat actor group, involved state-level espionage activities India in the Crosshairs As discussed in the analysis by QiAnXin, spear phishing was used as the initial delivery method for this campaign. Examining the lures involved, the targets appear to be users in India, specifically in the Ministry of Defence. Figure 1: Example PDF Lure (https://twitter.com/jaydinbas/status/1629149627848044550) In a bid to further understanding of this campaign, we will not seek to repeat analysis of the infection chain. Instead we will focus on the two tools which were ultimately dropped, examining threat telemetry surrounding their associated command and control (C2) infrastructure. DUser.dll (Action RAT) The first tool, identified as Action RAT in analysis by Cyble, is dropped onto the victim machine alongside a benign executable which is used to sideload it, in order to avoid detection. Action RAT’s capabilities include the ability to receive commands from the C2 server, to retrieve information from the victim machine, to execute further payloads, and to upload information back to the C2. We found two samples of Action RAT (loaded as DUser.dll), including the sample analyzed by Cyble. Cyble Sample Stage 1: feeadc91373732d65883c8351a6454a77a063ff5 (DRDO - K4 Missile Clean room.pptx.lnk) C2: www.cornerstonebeverly[.]org Action RAT: 3c4c8cbab1983c775e6a76166f7b3c84dde8c8c5 (DUser.dll) C2: 144.91.72.17:8080 (Contabo GmbH) Sample Two Stage 1: 0d68a135b1f4be18481cf44ed02bcbf82aeb542e (Cyber Advisory - Profiles (Pic and Mob No) of PIOs.docx.lnk) C2: www.kwalityproducts[.]com Action RAT: cb031561fd76643885671922db7d5b840060334d (DUser.dll) C2: 84.46.250.78:8080 (Contabo GmbH) Examining threat telemetry for the two C2 IPs 144.91.72.17 and 84.46.250.78 we observed initial victim connections on 06 February 2023 and 15 March 2023 respectively. In total we observed 18 distinct victims, all located in India, connecting to the C2 servers - highlighting the targeted nature of the campaign. Further to this activity we also observed 37 distinct IPs (again all located in India) connecting to 144.91.72.17:9468 in activity which commenced on 07 January 2023. Of the 37 IPs, two were observed connecting to the Action RAT port (TCP/8080). We were unable to identify a sample talking to TCP/9468 of 144.91.72.17, however we would hypothesize that this IP was used for C2 communications with another tool associated with SideCopy activities. Management Hints? Examining outbound activity from 144.91.72.17 and 84.46.250.78, we observed connections from 84.46.250.78 to 66.219.22.252:82 (IMMEDION, US). Whilst 66.219.22.252 is assigned to an American provider, WHOIS data places it in Pakistan. Further examining connections to 66.219.22.252:82, we observed communications sourced from 17 distinct IPs assigned to Pakistani mobile providers and four Proton VPN nodes during the period of interest. All of the Proton VPN nodes and all but three of the Pakistani mobile IPs were also observed connecting to 66.219.22.252:3389 within the same time period. Port 3389 (RDP) is often observed open on SideCopy (and Transparent Tribe) C2 servers, and is believed to be utilized for management purposes by the threat actors. These findings are therefore indicative of management of 66.219.22.252 by actors likely located in Pakistan, in addition to actors unknown accessing via Proton VPN infrastructure. Examining the communications sourced from the Pakistani mobile IPs, to 66.219.22.252:82 and 66.219.22.252:3389, we can start to build a general pattern of life, illustrated in Figure 2 below. Figure 2: Pattern of Life for Management of 66.219.22.252 The timings in Figure 2 shown above are based on UTC, which is 5 hours behind Pakistan Standard Time. Therefore, Figure 2 demonstrates that management of 66.219.22.252 occurs between Monday to Saturday, from roughly 10AM to 7PM - with some exceptions on Thursdays. These data points are potentially indicative of the threat actors accessing their infrastructure within a typical working week cadence, suggesting that management is undertaken professionally. Finally, when analyzing threat telemetry data for 66.219.22.252, we also observed inbound connections to TCP/8080 and TCP/9467 sourced from IP addresses assigned to Indian providers. TCP/9467 is noteworthy given its similarity to the activity observed on 144.91.72.17:9468 which we assess to be indicative of SideCopy C2 communications. The findings in this section derived from threat telemetry data are summarized below in Figure 2. Figure 3: Threat Telemetry Data Associated with the Action RAT C2s AllaKore RAT According to QiAnXin’s analysis, DUser.dll is also used to load and execute a version of AllaKore RAT, which is dropped on the victim machine via separate infrastructure. AllaKore RAT’s capabilities include functionality which allows for keylogging, screenshotting, and remote access of the victim machine, with an ability to also upload stolen information to the C2 server. We found two samples of AllaKore RAT, both of which were referenced by QiAnXin. Sample One Dropped via: f369ee5fc8dcf5a9e95d85dadff5a095a0e3a760 (hta.dll) C2: www.kcps[.]edu[.]in AllaKore RAT: ea844939dc428e6fdb6624d717d0286e4dcae9b1 (simsre.exe) C2: 89.117.63.146:9921 Sample Two Dropped via: f369ee5fc8dcf5a9e95d85dadff5a095a0e3a760 (hta.dll) C2: www.kcps[.]edu[.]in AllaKore RAT: 972d85b5736ae8bdf06a9d74f2a3356829ce2095 (sicsmdb.exe) C2: 185.229.119.60:9134 Examining threat telemetry data for the two C2 IPs 89.117.63.146 and 185.229.119.60 we observed initial victim connections on 06 January 2023 and 22 February 2023 respectively. In total we observed 236 distinct victims, all located in India, connecting to the C2 servers. When compared to the victim numbers for the Action RAT C2s, it could be assessed that AllaKore RAT is deployed more widely and via other means outside of the scope of the infection chain described by QiAnXin. Further to this activity we also observed 455 distinct IPs (again all located in India) connecting to 89.117.63.146:7439 and 185.229.119.60:7469 in activity which commenced at the same time as the activity on the ports associated with the AllaKore RAT samples. We were unable to identify samples talking to TCP/7439 of 89.117.63.146 and TCP/7469 of 185.229.119.60, however as previously we would hypothesize that this IP was used for C2 communications with another tool associated with SideCopy activities. Conclusion In this blog post we have sought to illustrate the following points: We have good evidence to demonstrate this particular SideCopy campaign, highlighted first by others in the industry, was successful in targeting Indian users. This finding is based on observations within our threat telemetry data, indicating victim connections to the C2 servers. Victim activity predated the public reporting of this campaign, in some cases by several months. This continues to support the statistics about attacker dwell time, and highlights the importance of retrospective analysis of data logs. There is specific evidence to demonstrate that the Action RAT infrastructure, connected to SideCopy, is managed by users accessing the Internet from Pakistan. Pivots on known threat actor infrastructure can lead to the identification of further, previously unknown infrastructure, in addition to hints at attribution and management. Recommendations We would recommend that cyber defenders, particularly those located in countries / regions which SideCopy operations are known to target, use the IOCs mentioned in this blog to hunt against their own data holdings (including historical logs), and to preemptively block malicious activity. Users of Pure Signal Recon can examine this campaign by querying against the domains and IP addresses referenced in the IOC section below. Further pivots into other currently unknown infrastructure may be possible as this threat actor undertakes future campaigns. Indicators of Compromise Malware Hashes (SHA1) 0d68a135b1f4be18481cf44ed02bcbf82aeb542e 3c4c8cbab1983c775e6a76166f7b3c84dde8c8c5 972d85b5736ae8bdf06a9d74f2a3356829ce2095 cb031561fd76643885671922db7d5b840060334d ea844939dc428e6fdb6624d717d0286e4dcae9b1 f369ee5fc8dcf5a9e95d85dadff5a095a0e3a760 f369ee5fc8dcf5a9e95d85dadff5a095a0e3a760 feeadc91373732d65883c8351a6454a77a063ff5 Domains www.cornerstonebeverly[.]org www.kwalityproducts[.]com www.kcps[.]edu[.]in IP Addresses (with port pairings 🍷) 144.91.72.17:8080 144.91.72.17:9468 185.229.119.60:9134 66.219.22.252:8080 66.219.22.252:9467 84.46.250.78:8080 89.117.63.146:9921