Search Results

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

Introduction This blog post is part of an ongoing series of analysis on MoqHao (also referred to as Wroba and XLoader), a malware family commonly associated with Roaming Mantis. MoqHao is generally used to target Android users, often via an initial attack vector of phishing SMS messages (smishing). The threat group behind Roaming Mantis are characterized as Chinese-speaking and financially motivated, first public acknowledgement goes back to around 2018. The group has historically targeted countries in the Far East – Japan, South Korea and Taiwan, but they are expanding their campaign. In our most recent post (MoqHao Part 2: Continued European Expansion), we demonstrated how Roaming Mantis had widened their sights to Western countries, including France, Germany, the United Kingdom, and the United States. Further Reading MoqHao Part 1.5: High-Level Trends of Recent Campaigns Targeting Japan MoqHao Part 1: Identifying Phishing Infrastructure In this post we will explore whether Roaming Mantis have continued to expand their operations over the past year, focusing on their activities in recent months. In doing so we will seek to highlight some techniques which we have utilized to pivot to connected infrastructure. Key Findings Identification of 14 MoqHao C2 servers, based on malware analysis and pivots within contextual data sets. Evidence of Roaming Mantis campaigns targeting every continent, with Africa, Asia, and Europe the most impacted. Close to 1.5 million victim communications to the MoqHao C2 servers observed since the end of 2022. The scope of Roaming Mantis continues to grow; all mobile users should be conscious of smishing threats, particularly from operators who have evolved their campaigns over several years. MoqHao Command & Control As in previous posts, our analysis begins with the identification of infrastructure utilized for the purpose of post-infection communications, once a malicious APK (MoqHao) has been installed on a victim device. The rationale for this approach is two-fold: The delivery and installation methodology for MoqHao includes the use of ‘disposable’ staging infrastructure which generally utilizes Dynamic DNS services, in addition to legitimate platforms, such as Baidu, Imgur, Pinterest, and VKontakte. Analysis of network telemetry data associated with these phases of an infection is complicated by the presence of security research, scanning, and (large volume) benign user activity. Furthermore, until beacons to a Moqhao C2 server are observed, it is not wholly accurate to identify any communications as ‘victim’ related. Whilst MoqHao’s delivery infrastructure has a short shelf life, its C2 infrastructure is used for extended periods of time and in some cases even reused after periods of inactivity. By analyzing stable infrastructure, we can draw higher level conclusions on targeting, i.e., where large groupings of victim connections originate from. In addition, as this infrastructure is more static, by disclosing it we can have the greatest impact on Roaming Mantis operations. Figure 1: Simplified Delivery Chain for MoqHao Our initial method of identifying MoqHao C2 infrastructure is based on analysis of malware samples. In this case we have started with three malware samples identified within our internal malware holdings, which are also available in VirusTotal. MoqHao is detected by several antivirus vendors as ‘Wroba’, querying for this string within malware repositories will generally lead to connected samples. 37134b50f0c747fb238db633e7a782d9832ae84b This file was first uploaded on 24 October 2022 by a user in Canada, it is configured to receive C2 information (91.204.227.31:28877) from a user profile on VKontakte. Examining network telemetry for 91.204.227.31 (HDTIDC - South Korea) we observe a campaign targeting users in Australia, with the most recent victim connections occurring around 29 January 2023. Open Ports information for 91.204.227.31 identifies that TCP/5985 was open during the period when victim connections occurred. The banner data obtained from scanning that port contains reference to a Computer / Domain Name - WIN-VLVN3FLKKGL. Figure 2: Open Ports Information for 91.204.227.31 Pivoting on the WIN-VLVN3FLKKGL value we identified four additional IP addresses, all within 91.204.227.0/26. We found victim communications to three of these IP addresses, two of which were identified in previous reporting (by Kaspersky) as MoqHao C2 servers: 91.204.227.32 << Kaspersky C2 91.204.227.33 << Kaspersky C2 91.204.227.51 The first two C2s are used in campaigns primarily targeting users located in Asia, but also Australia (as was the case with 91.204.227.31). A significant proportion of victims were in Japan, Nepal, and Thailand. 91.204.227.51 was used as the C2 server for a campaign targeting users in France, with the last victim connections observed around 26 February 2023. 198b55d4e7c7c0ee4fc4cbe13859533e651b91f6 This file was first uploaded on 20 February 2023 by a user in Canada, it is configured to receive C2 information (198.144.149.142:28866) from a user profile on VKontakte. Examining network telemetry for 198.144.149.142 (NETMINDERS - Canada) we observe a campaign targeting users globally - in Africa, Asia, Europe, North America, and Oceania, with victim connections still occuring at the time of writing. Open Ports information for 198.144.149.142 identifies an RDP certificate hosted on TCP/3389 with a Common Name value of sid380. Figure 3: Certificate Data for 198.144.149.142 Pivoting on the sid380 value we identified 12 additional IP addresses, all within 198.144.149.128/28. We found victim communications to one of these IP addresses, which was identified in the Kaspersky reporting as a MoqHao C2 server: 198.144.149.131 << Kaspersky C2 As in the case of 198.144.149.142, this C2 is used in campaigns targeting users globally, further including South America (Brazil and Suriname). 5ceb8950759a8d9d31389d1370d381d158c79fbe This file was first uploaded on 25 February 2023 by a user in Japan, it is configured to receive C2 information (91.204.227.43:29872) from a user profile on VKontakte. Examining network telemetry for 91.204.227.43 (HDTIDC - South Korea) we observe a campaign targeting users in India, with the most recent victim connections occurring around 03 March 2023. Open Ports information for 91.204.227.43 identifies that TCP/5985 was open during the period when victim connections occurred. The banner data obtained from scanning that port contains reference to a Computer / Domain Name - M172-17-64-184. Figure 4: Open Ports Information for 91.204.227.43 Pivoting on the M172-17-64-184 value we identified 13 additional IP addresses, all within 91.204.227.0/26. We found victim communications to seven of these IP addresses, one of which was identified in the Kaspersky reporting as a MoqHao C2 server: 91.204.227.37 Campaigns targeting users in Turkey and the United States. 91.204.227.39 << Kaspersky C2 Campaigns primarily targeting users in India and Nepal, with additional targeting in the Middle East and North America. 91.204.227.41 A campaign targeting users in South Africa. 91.204.227.42 Campaigns primarily targeting users in Europe (Austria and Czech Republic), with additional targeting in Asia and the Middle East. 91.204.227.47 Campaigns targeting users in Malaysia and Nepal. 91.204.227.48 A campaign targeting users in the Czech Republic, with additional targeting in Belgium, the Dominican Republic, and Turkey. 91.204.227.49 Campaigns targeting users in India, Portugal, South Africa, and the United Kingdom, with smaller clusters of victims globally (Africa, Asia, Europe, the Middle East, North America, and Oceania). Conclusion Whilst this analysis is caveated by the fact it is based on sampled data, and that some researcher / scanning activity likely slipped through our net, we were able to identify connections, indicative of victims, from 67 distinct countries. Approximately 80% of connections were from the East Asian region (primarily Japan), which could be referred to as the ‘traditional’ operating base of Roaming Mantis. However, when you remove those connections from the data, you’re left with a picture of the operators’ efforts to expand globally. Figure 5: Spread of Victim Communications Users from Africa, other regions in Asia, and Europe in particular are increasingly appearing in victim communications to MoqHao infrastructure. Smishing often doesn’t receive the same level of attention as phishing when it comes to the malware delivery stakes. But, with over 1 million observed victim connections since the end of 2022 related to Roaming Mantis alone, it is clearly a viable initial access vector. If Roaming Mantis can develop their delivery methods globally, to match the depth and ‘real feel’ spoofing of their East Asian campaigns, we would anticipate that the threat to users will continue to grow over coming months and years. Recommendations We encourage continued education on mobile device security in general and smishing more specifically, to arm users with the knowledge required to identify and avoid threats. Where feasible, connections to the static MoqHao C2 servers listed in the IOC section below should be pre-emptively blocked. Users of Pure Signal Recon can track MoqHao campaigns based on the methods described in this blog post. IOCs MoqHao Samples 198b55d4e7c7c0ee4fc4cbe13859533e651b91f6 37134b50f0c747fb238db633e7a782d9832ae84b 5ceb8950759a8d9d31389d1370d381d158c79fbe MoqHao C2 Servers (With Port Pairings 🍷) ACTIVE (14 March 2023) HDTIDC LIMITED - South Korea: 91.204.227.32:28877 91.204.227.33:28899 91.204.227.37:28836 91.204.227.37:28856 91.204.227.39:28844 91.204.227.41:29869 91.204.227.42:29871 91.204.227.47:28999 91.204.227.48:28843 91.204.227.49:29870 NETMINDERS - Canada: 198.144.149.131:28866 198.144.149.142:28866 INACTIVE (Date) HDTIDC LIMITED - South Korea: 91.204.227.31:28877 (29 January 2023) 91.204.227.43:29872 (03 March 2023) 91.204.227.51:36599 (26 February 2023) NETMINDERS - Canada: 198.144.149.131:28867 (05 January 2023) 198.144.149.131:28868 (22 February 2023) 198.144.149.131:28869 (03 January 2023)

Automate Threat Intelligence to Stay Ahead of the Pack Introduction In our last several entries we talked about how threat hunting capabilities pays for itself in terms of reducing the cost of data breaches, sunsetting overlapping threat intelligence sources and preventing supply chain and third party compromises before attackers pivot to reach your core systems. We also discussed the importance of having visibility into the external attack surface of M&A targets and subsidiaries and how that can pay off in identifying difficult to detect APTs. Financial and Productivity gains from Cyber Threat Intelligence Automation No ROI or cybersecurity budget discussion would be complete without discussing the productivity gains that analysts and other experts receive from automation. Being able to save a single, or two, or five FTE analysts time from performing the tedious work of updating block lists is payback enough. But imagine the huge win of being able to show how the organization saved more than $600K over three years by automating phishing block lists with real-time data. Keep reading and find out how they realized new areas of cost saving and productivity in just under six months, including: Reallocation of 5 FTE security analysts from the soul-crushing work of manually updating a wide range of block lists for core services, networks, VPNs, and proxies Vanquishing almost all email cleanup tasks required after a compromise, saving months in people hours and reducing disruption to business operations Gaining efficiency and improving perimeter security by automating the updating of block lists in response to changes in attacker infrastructure Equipping the IR team with the most relevant data to look at the right firewall log to determine if a malicious communication was attempted The Payback of Proactive Security This Fortune 10 organization has a sophisticated security team, with tools that most security teams would envy, but, their value far exceeds the funding they require. Year on year, the security team increases in strategic importance, making a sound financial business case to continue applying the appropriate level of budget to achieve the strategic outcomes. Integrating Pure Signal™ Recon into an effective Cyber Threat Program is non-trivial. What it does enable though, is a seismic shift from reactive to proactive defense. This means Pure Signal Recon is just one part of a strategic transformation to bring about a proactive security program, and move away from a reactionary security response of the past. The senior security leaders at our client knew they could start to get ahead of the attackers, but only if they could transition the team from performing reactive security processes to taking on more proactive security measures. Everyone in the security team knows that the threat actors they deal with are determined to achieve their objectives, and are unlikely to go away soon. The team needed to make a shift and automate most of their reactionary security practices like the manual updating of block lists. At the same time, they needed to equip their team of elite threat hunters with the ability to scope out the wider, external threat landscape. This would allow them to undertake the more strategic work of understanding the origin of outside threats, and monitoring threat actor infrastructure to record how it evolves. Pure Signal™ Recon offered the team the ability to understand changes in infrastructure, and automate the changes in their block-lists in real time. Automating Real Time Security Intelligence pays off, fast First, they needed to onboard Pure Signal™ Recon into their environment. Unlike many solutions they have implemented, it did not involve the customary heavy lifting. Within days they were ingesting Pure Signal™ Recon data into their insight engine with a simple modification of existing scripts. In a month or less, the team was able to use Recon’s APIs to complete significant data extractions. Let’s look at one example of how they got quickly off the ground. A lead analyst took a good hard look at the external network telemetry data and was able to say with confidence, “‘Okay, this pattern right here looks like an exfiltration” and send it over to their IR team. With the nugget of data, they looked at the inside firewall logs to see which machine was involved with those communications. The endpoint was identified and remediation work could start immediately, not when it was already too late. Prior to using Recon, the team was able to avoid most email cleanup processes due to effective rules and customized block lists. Soon after implementation, the arduous process of email cleanup pretty much disappeared from the list of things no one wants to do. When it comes to automating block lists, what makes the threat intelligence from Pure Signal™ Recon unique is that it continually improves the fidelity of block lists with frequent movements of attacker infrastructure and their typical dynamic changes as they take place, not updating you a week later. If you haven’t already, check out how often malicious actors move their infrastructure in our blog here. This supports automating custom block-lists on real-time processes for the core network, VPNs, proxies, and outbound proxies with real-time information. In addition, this unique visibility that Recon provided helped them to trim down the number of intelligence feeds needed from 15 to five without missing anything as we’ve previously detailed. When speaking to Forrester analysts, security leaders said they were able to reallocate five FTE analysts due to a combination of Recon’s continued assistance to improving security rules and block lists. The financial gains For the purposes of determining labor cost savings, 50% of financial benefit was due to their usage of Recon reducing wasted labor time associated with tackling and cleaning up phishing attacks. The result? $600K cost savings to the budget over three years. CISO Tools: Learn more about how you can get started on the path towards reducing data breaches and utilizing real-time threat intelligence, request a free copy of the full financial analysis of Threat Reconnaissance here. Engage your analysts directly with our Security Architects and expert practitioners via our Sales Team, starting here.