Search Results
124 items found for ""
- Your Opportunity to Combat Cybercrime Worldwide
How to Sponsor the 2024 RISE and Underground Economy Conferences Sometimes in cybersecurity we lose sight of the bigger picture. Each day we're certainly aware that we're taking action to keep our organizations safe and to keep malicious actors out of networks and systems they could impact in major ways. But it's also about individuals. In an episode of Team Cymru's Future of Cyber Risk podcast, Selena Larson, Senior Threat Intelligence Analyst at Proofpoint, articulated it perfectly when she said: "There's a human being on the end of every attack. ... It's really important for us as practitioners — that includes intelligence analysts, that includes people who are writing these reports about threat activity — to remember that there's always someone on the other end that's experiencing something that really, really sucks. And … think about how we as a community and as security practitioners ourselves can make the space better so that there are fewer victims of cybercrime." This is why Team Cymru’s mission is to save and improve lives. Every day we save and improve lives through our nearly 20 years of experience and expertise at providing unparalleled threat intelligence and insight for security vendors, network defenders, incident response teams, and analysts. We also save and improve lives through our Community Services division that provides no-cost threat detection and intelligence to network operators, hosting providers, and more than 140 CSIRT teams across nearly 90 countries. And we save and improve lives by hosting four conferences every year, where industry professionals can learn how to better protect their organizations and improve the lives of people in the process. What are the Underground Economy and RISE Conferences? Launched in 2008, the Team Cymru Underground Economy Conference is our annual flagship conference with 500 attendees that takes place every year in September. In 2016, we launched three annual, smaller RISE Conferences (200 attendees), to offer four conferences annually. These events are a global gathering of cybersecurity professionals where they can learn more about cyber threats and critical investigations, and take advantage of networking opportunities. These events are academic in nature, consisting of confidential case studies and workshops on external threat hunting, threat intelligence, and cybercrime, delivered by industry professionals. Past sessions at the Underground Economy Conference and RISE have included case studies presented from the analysts and investigators responsible for thwarting recent high-profile cyber attacks, as well as those who orchestrated massive, transcontinental botnet and dark web takedowns. Past conferences have also covered topics such as: Sim swapping Fast flux botnets Ransomware OPSEC investigative leads State sponsored hackers Crypto mining malware Cyber-security AI in vehicles Ransomware toolsets Supply chain risk management Open source tool reviews The Underground Economy Conference and RISE consists of one or two days of plenary sessions followed by one to two days of training. Attendance is restricted to verified industry peers and detectives, and those wanting to attend will need to apply. The hand-picked group of up to 200 attendees for RISE and 500 attendees for the annual Underground Economy Conference includes individuals from industry and financial services, law enforcement, information security, and academia. Our upcoming conference schedule includes: RISE: January 24–25, 2024 in Latvia RISE: April, 2024 (location TBD) Underground Economy Conference: September 2024 in Strasbourg, France RISE: November 2024 in Singapore RISE and Underground Economy Conferences rely on generous sponsors in order to make our unique and high-quality conference happen — and you can learn more about sponsorship opportunities below. Who Benefits from RISE and Underground Economy Conferences? Ultimately, we all benefit from these events, both those in security and end users who are protected by that security. Because we host events around the globe, RISE and Underground Economy Conferences allow for a more geographically-targeted environment that provides security practitioners with the latest in insights and techniques to aid in the global fight against cybercrime. Miranda Bruce, a Postdoctoral Fellow in the Department of Sociology at Oxford University and a recipient of an Underground Economy Conference scholarship in September 2023, had this to say about her experience: "Underground Economy was just really great for me and it's great for anybody. Even if you don't have an academic interest in cybercrime, it teaches you new things, it gets you in touch with new people, and it gives you a new way of thinking about this area and thinking about how cybercrime is becoming more complex and also how it's becoming more simple in some ways." By bringing these unique learnings back to their organizations, attendees can not only advance their security strategy, but can ensure their teams are up on the latest trends and technology. They'll also walk away with new connections, partnerships, and friendships that will help us all combat cybercrime together. Why You Should Become a RISE and Underground Economy Conference Sponsor By becoming a sponsor of these events, you'll not only support the advancement of cybersecurity knowledge and innovation around the globe. You'll save and improve the lives of millions of people who will be less impacted by cybercrime because of it. Sponsorship also has its benefits as well. Your logo placement across various conference assets lets attendees know that you're a supporter of combating cybercrime worldwide. You'll join past sponsors like Cisco, Google, and Walmart in helping further cybersecurity innovation. You'll also receive guaranteed delegate invitations to these invitation-only conferences so that you can boost your own internal cybersecurity efforts. If you want to make a tangible impact on combating cybercrime around the globe, learn more about sponsorship opportunities for RISE and Underground Economy Conferences today. Join us in our mission to save and improve lives, and we'll see you in a few short months at RISE Latvia in January 2024!
- Risk Modeling and Real-Time Intelligence - Part 2
Learn about NIST 2.0 now to avoid becoming a statistic in the future By 2025, 45% of all organizations will have experienced a cyber-attack through a supply chain partner. This explains why we are now seeing more inquiries and discussions about the NIST 2.0 Cybersecurity Framework from our customer base, this blog seeks to discuss the topic for senior cybersecurity stakeholders. This revised framework is not just a compliance checklist; it's a strategic tool to enhance overall security resilience and align with industry-leading practices. As a security leader responsible for threat intelligence and hunting, this blog is an excellent primer to help you navigate the new NIST 2.0 framework and align your team and organization to it. Keep reading and learn about: The new Govern section and how to align risk management to business functions and company strategies. How to use DPRM solutions for the cybersecurity risk inputs needed to fortify overall risk planning and incident response. What provisions you need to make for privacy, supply chain security, and the incorporation of new technologies. Why automating asset discovery and continual prioritization leads lower risks from supply chain partners. How to drive up the cost for a threat actor to attack your organization using collaborative efforts. Actionable insights for implementing NIST 2.0, tailored to cater to different cybersecurity maturity levels within organizations. With the significant changes that 2.0 brings, it's clear that NIST wants to make its framework more accessible. It's a smart move when you consider that the majority of news-worthy cyber-attacks happen through supply chain partners. Not only that, but the number of cyber-attacks has risen considerably. Some Other sources indicate more than a 200% YoY increase in supply chain cyber-attacks, representing a significant step forward in guiding organizations to strengthen their cybersecurity measures. NIST 2.0 Focuses on Reducing Risk For Companies of All Sizes Regardless of the industry analyst or news source, it would be hard to disagree that supply chain and third-party cyber-attacks are increasing exponentially. The challenge is that large organizations must find ways to protect what isn't theirs, as they are still held liable for cybersecurity oversights at the supply chain and third-party levels. It is too costly for a company not to strategize to find a way to ensure security using risk and threat platforms. NIST is very timely to introduce this guidance for all company sizes as supply chain and third-party cybersecurity is a problem everyone owns. It requires a unique approach that combines real-time threat intelligence, continuous asset discovery, and increased collaboration for parent companies, subsidiaries, and partners. NIST now provides guidance and examples for its 2.0 framework for companies of any size. If you have enterprise customers, you may feel the effects of the 2.0 Cybersecurity Framework as recommendations are being translated by larger organizations into new security and audit requirements for their suppliers and third-party services. There is no getting away from the fact NIST 2.0 is a sizable body of work. Instead of rattling off all the changes, let's discuss where security leaders should take note DPRM Platforms Play Center Stage in the NIST 2.0 Cyber Security Framework Are large enterprise organizations amongst your customers or your does your company play a role in the supply chain delivery of a customer or critical service? The new "Govern" function and its implementation examples show how DPRM solutions are the cornerstone to providing the cybersecurity risk inputs needed to fortify overall risk planning and incident response. Nowhere is that emphasis more apparent than in the new "Govern" function, providing cross-functional recommendations and examples aimed at better executive collaboration. The Govern functions lend more clarity to categorizing assets so that security leaders can take a more proactive approach and prioritize response. You may be one step ahead if you already use the inputs from a DPRM platform. If your team engaged in these activities, you may have a short path to show alignment with NIST 2.0 recommendations. Ensure the tools you use can keep pace and enable the benefits of proactive defense. Here are some salient points to think about when considering a threat and risk management platform to realize the advantages contained in the 2.0 cybersecurity framework recommendations. Do you have a DPRM solution that provides: Multi-score impact methodology that considers the severity of the vulnerability via CVSS scoring critical aspects of the infrastructure and includes other factors, such as manual inputs, to generate a score. Automates the impact score on an asset using CVSS scoring, combined with human and AI/ML generated input. Continual asset discovery – Shadow IT requires SecOps to diligently discover and inventory new IT systems as they are added to the external attack surface you monitor. Integration opportunities with GRC systems and other business management systems via API Supply Chain Security Measures Go Mainstream with NIST 2.0 Recommendations Many security leaders likely didn’t need reminders about supply chain risk. But, you know it's time to get even more serious about supply chain security when Homeland Security builds a new supply chain risk management office. Then, NIST released its first update to its Cybersecurity Framework. Regardless of whether you need to act now or wait until a later point, you need to know about the new NIST 2.0 recommendations and prepare. If you are with a parent company with a long list of supply chain partners, you must bring them into your cybersecurity programs. The infrastructure you need to secure is your partner's rather than yours. But at the same time, you are still responsible for any breach resulting from their cybersecurity shortcomings. If you are in an industry where a customer and/or critical system relies on third-party services, you are responsible for the breach regardless of the source. So, as a security leader, how do you put another company's assets under your purview and collaborate to reduce risk? Ultimately, you are responsible for your and your supply chain partners' security shortcomings. The NIST release of 2.0 recommendations and implementation examples highlight the minimum capabilities needed for increased supply chain security; the timing could not be better. Due diligence will always depend on human interactions and assessments, as it should be. At the same time, a lot of tedious and manual work goes into assessing risk. So, the more you can increase the efficacy, automation, and coverage of your cybersecurity programs to include key partner relationships, the better off you will be in the long term. Supporting supply chain partners by collaborating on cybersecurity is a win-win situation for everyone involved. Here are some key ways that a DPRM solution can augment your supply chain security program: Multiple risk scores – DPRM platforms enable multiple scores by business unit, subsidiary, supply chain partners, and third-party services. Create specific groups – Monitor risk by groups you create, such as function, geography, partner, or type of service, to measure individual and overall group risk scores. Benchmark – Compare business risk scores to highlight weak links. Evaluate similar groups, partners, or applications against each other to benchmark risk reduction across groups and identify security gaps. Automate scanning and discovery – Supply chain and third-party service partners should have their infrastructure scanned and assessed regularly. Partners should be able to show improvement from past scans, such as reducing the number or severity of vulnerabilities within their infrastructure. Map vulnerabilities of a group of partners to track the overall and individual risk scores and provide guidance for remediation where possible. Automate Asset Discovery and Continual Prioritization for In-Depth Situational Awareness Corporate IT environments are constantly in flux, with new applications being spun up and business units sometimes going rogue and standing up new infrastructure. It's hard to keep up with, even with visibility into your infrastructure. Nowhere is automated asset discovery needed more than for your externally exposed infrastructure. Once you have performed your initial in-depth discovery, it must be followed up with frequent scans as new software, configuration changes, and admin updates will affect the risk score of that asset. Discovery is just the beginning; it is just one facet of managing vulnerabilities. It is vital that initial discovery and continual scanning take place, but it only answers the question of where? Vulnerability management needs more; it needs business logic that enables automating the priority of assets to help answer the what? And why? Solutions that can automate prioritizing assets by bringing together CVSS severity scores along with business impact scoring will give vulnerability management teams the automation they need to weed through the noise of low-level alerts and concentrate on what matters most. So, what is the best way to prioritize assets? Because what matters most is not always a straightforward answer. Consider these attributes when looking to prioritize response. Severity – The first step is ascertaining the vulnerability severity. If exploited, how much damage would it cause? To a certain extent, business context is needed, but you can make a reasonable estimate based on your knowledge of your software and hardware environment. Likelihood – This can be defined by the exposure of a system to your external attack surface, the frequency of threats or exploits, and how much publicity the vulnerability has received. But probably the indicator of likelihood is the capabilities and motivations of attackers. This may be a more important attribute if you suffer from repeated attacks and relentless threat actors. Risk – It is always a central theme in prioritizing security response. Its calculation takes into account the loss a company might suffer in the case of a successful attack. Risk helps you examine and rank vulnerabilities by the assets they affect and how those assets may interact with other business systems. Context – Not all high-value assets are externally facing and well-known. But they carry the same weight when it comes to risk. This could include a work stoppage or business downtime as the main risk. You may place more value on that asset even if it is not externally facing or otherwise well-known. NIST 2.0 Emphasizes Real-Time Intelligence. Why should you also? We get it. Operationalizing threat intelligence is not easy. Even worse is operationalizing something that doesn’t matter anymore.You can use threat reports to block IP addresses, and that can help but only until attackers change tactics again. Things like the MITRE ATT&CK framework can tell you about possible TTPs (Techniques, Tactics, and Procedures). But they are not investigative tools that will tell you what adversary is targeting you and how to defend yourself in anticipation of an attack. The 2.0 recommendations include many examples of the need for real-time threat intelligence to complement the capabilities of a DPRM solution. The new 2.0 standard recognizes that security analysts need to be able to observe attacker behavior and conduct a more thorough investigation. The ability to do a deeper dive into an incident requires having a view beyond your perimeter that enables analysts to make queries and quickly know the nature of an incident, including: Quickly know if a suspect IP should be further investigated Understand what happened during an event. Observe attacker behavior to anticipate an attack. Attribute attackers to an incident Determine the root cause of an incident. Stop exfiltration by blocking c2 communications These actions provide security analysts with the means to create playbooks using real-time intelligence. The data generated can also be used to identify other third parties and help compromised victims with remediation advice. The NIST 2.0 framework is a welcomed update. Implementation examples represent a better way for companies of all sizes to consume this information and build better processes while taking advantage of new collaboration opportunities. The NIST 2.0 Cybersecurity framework recognizes the need for more collaboration in cybersecurity. When we all work together, the collective efforts pay off by driving up the cost for a threat actor to attack while enriching our threat intelligence sources for a proactive cyber defense. Further Reading: Learn more about the threat vectors you should be considered about here Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Learn more about the value of monitoring external risks and how that empowers organizational success, read our customer case study here Mature threat intelligence teams add tangible financial business value and reduction of business risk., Learn more about how our Fortune 10 customer integrated real-time threat intelligence to enact a proactive defense that goes beyond the MITRE ATT&CK framework to offer pre-compromise defense. Up the Ante on Supply Chain Security Stop the Budget Drain of Dated Threat Intelligence Don’t Inherit a Security Problem with M&A Activity Automate Real-Time Intelligence and Increase Productivity. and Morale! External Threat Hunting Prevents Data Breaches
- Threat Modeling and Real-Time Intelligence - Part 2
Leverage Internet Telemetry & Threat Intelligence for Benefits Beyond the MITRE ATT&CK Framework The MITRE ATT&CK framework is like a blueprint of the battlefield, showcasing potential threat actors and their tactics to infiltrate an organization. It guides a security practitioner to identify gaps in an organization's capabilities by following the tactics a bad actor may use to gain access. It also covers the techniques employed by threat actors to move laterally inside a network and compromise additional systems and infrastructure. It sheds light on how vulnerabilities are exploited, leading threat actors to move laterally within networks. However, the framework remains static, providing a snapshot of known adversarial behavior. It offers security leaders and practitioners guidelines and essential attributes for threat detection, but they are not designed to guide security leaders on how to gain the visibility needed to better detect threats. Real-time threat intelligence fills this void, providing the crucial context to attribute attacks, track adversary behavior, and map their infrastructure. It is a vital source of intelligence and visibility that extends beyond boundaries to address evolving threats. It steps in and supports rapid threat analysis by offering a dynamic view of bad actors that may be targeting you and acts as a single source of truth. Real-time threat intelligence and the MITRE security framework are complementary forms of intelligence that enable analysts to defend against threat actors proactively. A security framework such as MITRE is adversarial-focused. It can help you find gaps in your capabilities and give you an idea of who may be attacking you and how they move laterally within your environment to gain further access to your business systems. Real-time intelligence gives you a way to observe the beginning stages of an attack when threat actors are performing reconnaissance on you as their target, or your third-party networks. There are few useful recommendations on how to use tools to defend an organization at this stage. But solutions do exist! This blog seeks to discuss where, why and how these blindspots can be addressed using threat intelligence derived from external threat intelligence sources, and the strategic gains there for innovative security leaders to seize. Real-Time External Threat Intelligence Complements the MITRE ATT&CK Framework The MITRE ATT&CK framework is renowned for its adversarial approach to defense. It provides a structured process for understanding threat actors' tactics, techniques, and procedures (TTPs). It reveals their modus operandi, so analysts have a starting place to understand what tools, experience and knowledge they need to track down bad actors - both inside and beyond the perimeter. It enables security teams to fortify their defenses in the right areas and bridge capability gaps in others. Frameworks offer guidelines and essential attributes for threat detection, but they are not designed to guide security leaders on how to gain the visibility you need to better detect threats. Real-time threat intelligence fills this void, providing the crucial context to attribute attacks, track adversary behavior, and map their infrastructure. It is a vital source of intelligence and visibility that extends beyond boundaries to address evolving threats. It steps in and supports rapid threat analysis by offering a dynamic view of bad actors that may be targeting you and acts as a single source of truth. The threat landscape demands innovative approaches that move beyond static data and reactive methodologies. Among the tools at a security leader's disposal are real-time threat intelligence and the MITRE ATT&CK framework. These two pillars of defense, though distinct in nature, can pave the way for a proactive cyber-defense strategy that enables a shift towards anticipating and defeating threats from adversaries. While the framework equips defenders with essential insights with a range of TTPs, you must independently learn how to create your own unique threat data and the playbooks that pivot off of it. When analysts can see infrastructure changes and trace communications with threat actor groups, they can find other victims of an attack and notify them of possible compromise. This type of threat reconnaissance is the primary way enterprise security teams can raise the cost of attack and make it less profitable for threat actors to target their organization. Actionable Insight: Embrace both external threat intelligence and the MITRE ATT&CK framework to equip cyber defenders with the visibility they need. It is the cornerstone of a proactive cyber defense that does not relegate defenders to reacting to events and chasing false positives and other resource-draining efforts. Close the Capability gap for Proactive Defense with the MITRE ATT&CK Framework and Real-Time Threat Intelligence The MITRE ATT&CK framework lays the foundation for creating robust detection mechanisms and preparing for what can be expected to detect and mitigate a threat. It doesn’t take long to notice that much of the model is focused on what occurs when an attacker is already in your network - what about when they are scanning your assets? Or when they have already compromised your network and are setting up staging servers to steal your data - your internal network analysis and security tools are blind to this activity at this point in the attack so far - gaining external visibility of attacker activity is the difference of that data remaining in your possession, or being stolen. Up-to-date external threat intelligence has the potential to greatly enhance security across the board. By automating detection policies with data that analysts derive by tracking threat actor infrastructure, this can be applied across the entire MITRE model. i.e., before, during and after an attack. To achieve this, analysts need a real-time view of threat actor activities. These insights and resulting additions to defense policies mean that analysts are not providing out-of-date information to block lists, ensuring defenses are optimized and effective. They are acting on what is happening now, ensuring that any updating of defense policies uses real-time data as it develops. Access to real-time information and visibility into threat actor movements enable analysts to build constructive views and learn about IOCs from an external threat perspective. Actionable Insight: Use the MITRE ATT&CK framework initially as a gap analysis tool. Not only does it call out adversary tactics, but helps to inform where you may, or may not, have visibility, tools, data, knowledge or resources that add value to your cyber defense. Allocate resources to invest in technologies that enable analysts to create actionable threat intelligence playbooks, promoting effective attribution and preventative tactics. How Visibility and Reconnaissance Pays off to Countering Attacks A quick snapshot of the MITRE ATT&CK reconnaissance frameworks shows ten different reconnaissance techniques and more than 30 sub-techniques that a bad actor might employ in their reconnaissance effort to gather intelligence for a targeted attack. As a defender, the framework suggestions for pre-compromise mitigations offered are minimal. Detection recommendations are relegated to anomaly-based analysis, known for high false-positive rates. It leaves little path for security leaders working towards enacting a proactive defense strategy and wanting to get ahead of attacks. When using threat intelligence based on internet telemetry, new possibilities open up to monitor malicious activity as it is happening. Analysts have a ground-zero current source of truth to observe attacker behavior and quickly make decisions if a suspicious IP should be further investigated. Visibility beyond the perimeter pays off in the latter stages of attack by enabling analysts to anticipate what a threat actor is going to do next, and be able to specify proactive defenses to counter an attacks. Creating visibility into the external threat landscape supports proactive defenses and a high detection efficacy in the pre-compromise stage. This visibility is crucial to building a proactive defense strategy and addressing all stages of compromise using the framework. Aggressive efforts made in the pre-compromise stage of an attack can pay out benefits towards prevention during exfiltration. Suppose you use internet telemetry enriched with threat intelligence for visibility and reconnaissance in the pre-compromise stage. In that case, you already have the answers to block exfiltration proactively instead of relying on signature or anomaly-based detection methods. It is a better way to address threats than using reactionary methods that lead to high false positive rates. Actionable Insight: Identify your visibility gaps that lie within the ‘Reconnaissance’ column of the MITRE ATT&CK framework. This will lead to data sources that will help you to better understand the threat actors that are reaching out to your own and third-party networks, including victims of ongoing attacks. It reveals their evolving tactics, and the changes they make to their infrastructure before another attack. External threat intelligence or internet telemetry are the only sources of knowledge and data that will fill the visibility gap for threat actors at the Reconnaissance stage of the model. Enhance Detection Capabilities with Actionable Insights Real-time up-to-date external threat intelligence derived from internet telemetry has the potential to greatly enhance security across the board. By automating detection policies with data that analysts derive by tracking threat actor infrastructure, it can be applied across the entire MITRE model. i.e., before, during and after an attack. To achieve this, analysts need to be able to observe attackers in real time view of threat actor activities. These insights and resulting additions to defense policies mean that analysts are not providing out-of-date information to block lists, ensuring defenses are optimized and effective with current information. They are acting on what is happening now, ensuring that any updating of defense policies uses real-time data as it develops. Access to real-time information and visibility into threat actor movements enable analysts to build constructive views and learn about IOCs from an external threat perspective. It's important to remember that the MITRE ATT&CK framework does not provide a complete answer to defense against attackers' tactics, techniques, and procedures and only offers suggestions for mitigation and detection. Bad actors constantly innovate, and a security leader's response must do the same. Let your analysts do more by tracing down attackers, making associations, and preempting an attack with reconnaissance-led intelligence that can actively block an attack. Once you enable visibility to internet telemetry and historical context, analysts are not just reacting to what is happening inside the network. This is foundational to enacting a proactive defense that turns the dynamics of the MITRE ATT&CK framework on its head and creates new areas for learning and preemptive defense. Actionable Insight: Allocate resources to invest in technologies that enable analysts to create actionable threat intelligence playbooks, promoting effective attribution and preventative tactics. Learn more about the threat vectors you should be considering for your Threat Model here Read our customer case study about the discoveries made when external Threat Intelligence is applied over a Threat Model. Mature threat intelligence teams add tangible financial business value and reduction of business risk. Learn more about how our customer gained success integrating real-time threat intelligence to enact a proactive defense that goes beyond the MITRE ATT&CK framework to offer pre-compromise defense. Up the Ante on Supply Chain Security Stop the Budget Drain of Dated Threat Intelligence Don’t Inherit a Security Problem with M&A Activity Automate Real-Time Intelligence and Increase Productivity. and Morale! External Threat Hunting Prevents Data Breaches
- Threat Modeling and Real-Time Intelligence - Part 1
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
- Inside the IcedID BackConnect Protocol (Part 2)
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
- Visualizing Qakbot Infrastructure Part II: Uncharted Territory
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
- A Visualizza into Recent IcedID Campaigns:
Reconstructing Threat Actor Metrics with Pure Signal™ Recon Introduction IcedID (also known as BokBot) started life in early 2017 as a banking trojan that later evolved to include dropper malware capabilities. These capabilities enable IcedID to download and deploy additional malware like Cobalt Strike, with recent infections leading to Quantum ransomware. Cybersecurity professionals should continue to pay attention to IcedID as it remains one of the top dropper malware in the threat landscape and has no signs of slowing down. It is typically delivered via email spamming campaigns, with new campaigns being delivered on a near-daily basis that leverage an assortment of different lure types and execution processes. This got us curious - how do different campaigns compare to each other? We’ve extensively tracked IcedID C2 infrastructure using our Recon and BARS (Botnet Analysis and Reporting Service) feed tooling, and using this data we were able to peek behind the scenes at metrics that are possibly similar to what the threat actors are tracking themselves. C2 Tracking We’ve previously written about IcedID Stage 2 Tier 1 (T1) and Tier 2 (T2) C2 infrastructure and threat telemetry, which pertains to bot activity that occurs after IcedID has successfully infected a machine. In this post, our focus is on the Stage 1 T1 C2s that initially load the malware onto a victim’s machine after they perform the action being asked of them in the lure, such as ‘enable macros’ or ‘click a disguised shortcut’. Registration Until 21 September 2022 and dating back to at least two months, domains used as Stage 1 downloader C2s were registered with 1337 Services LLC Hosting (connected to the Njalla hosting service) and parked there for an average of 31 days before use as a C2. This process was possibly developed for the circumvention of firewall blocks against newly registered domains. As of 22 September 2022, however, domains used as C2s have been registered only a few days prior, breaking this long-term pattern. C2 Assignment Either the day before or the day of a campaign, a C2 domain is assigned to a new IP that is used for inbound victim traffic on port 80 and for T1 -> T2 communications. Communication with the T2 C2 generally begins the same day the campaign is released. According to our C2 tracking data for the August-September 2022 timeframe, domains and IPs are typically only used for one campaign and not recycled. In mid-September there were a few instances where downloader IPs and domains were reused, but as of the end of September, C2s have returned to being unique / single-use. C2 Lifespan C2 communication with T2 infrastructure occurs for an overall average of six days before ending, and four or five C2 IPs are normally active at a time. Although, around the third week of September active C2s dwindled down to two from the usual amount due to IPs and domains being reused between campaigns, which prevented aged-out C2s from being replaced. In most cases, no changes are made regarding the IP or domain once it’s inactive. All but one of the C2 domains from the campaigns we analyzed were still assigned to the same IPs at the time of writing. Campaign Metrics Using the C2s we’ve gathered from tracking IcedID infrastructure, we analyzed data from campaigns that were spammed during the period 13 - 21 September 2022 to see if there was a correlation between TTPs and the volume of victim interaction. In order to identify potential traffic, we had to remove general noise, as well as security research traffic from our data. This process includes enrichment with supplementary open source data such as WHOIS information. The numbers provided throughout this blog are based on an approximation derived from sampled threat telemetry. Delivery Methods Of the campaigns analyzed, the following methods were used for malware delivery: Password Protected ZIP -> ISO -> LNK -> JS -> [CMD or BAT] -> DLL Delivery was via a password protected zip file that contained an ISO which itself contained a LNK file and archive holding the files used for IcedID installation. When the LNK file is clicked by the user, it functions as a shortcut to run a script within the archive that ultimately installs IcedID from a DLL. It is typically launched through either a CMD or BAT script, depending on which was included in the archive. Password Protected ZIP -> ISO -> CHM -> DLL Delivery was via a password protected zip file containing an ISO that led to a CHM (Compiled HTML) file. The victim must open the file to launch the DLL and complete the infection process. Maldoc Users received either a malicious Word or Excel file that asked them to enable macros, which then allowed the embedded script to execute and install IcedID. PrivateLoader Delivery was through PrivateLoader, a pay-per-install service that distributes malware by hiding it in free software downloaded by unsuspecting users. ________________________________________ 13 September There were two campaigns launched; one targeting Italian speakers (project ID 3281798692) and the other targeting English speakers (project ID 726442267). The Italian lure was in the form of a malicious ‘.docm’ file with kolinandod[.]com as the C2, which was set to resolve to 159.203.5[.]238 on 12 September. There were around 18 potential victims and most of the victim communication occurred the same day of the campaign. The C2 stopped interacting with the T2 on 19 September. The lure targeting English speakers arrived using the following delivery method: Password Protected ZIP -> ISO -> LNK -> JS -> BAT -> DLL The C2 was qvantumbrakesz[.]com, which resolves to 134.209.97[.]90. There were around 115 potential victims that communicated with the C2 before it was disconnected from the T2 on 20 September. Most of this traffic occurred on the day of the campaign and tapered off until the last victim hit it on 19 September. ________________________________________ 14 September For the campaign on 14 September (project ID 809191839), threat actors returned to leveraging CHM files for the delivery method: Password Protected ZIP -> ISO -> CHM -> DLL Note: The use of CHMs was first spotted in a IcedID campaign on 8 August 2022, but the use of this file-type maliciously is a technique that has been around for several years. The C2 was allozelkot[.]com and was set to resolve to 188.166.169[.]40 on the day of the campaign. There were around 18 unique victims with the last connections occurring on the 19th. The C2 stopped communicating with the T2 on 22 September. ________________________________________ 15-16 September Both the 15 September and 16 September campaign used pildofraften[.]com as their C2. This domain has resolved to the same IP address (142.93.44[.]94) since 15 September. Seeing domains and IPs reused for Stage 2 bot C2s is not uncommon, but this is the first case of a Stage 1 downloader C2 reusing either since at least mid-August 2022. The campaign on September 15 (project ID 612758225) used the delivery method: Password Protected ZIP -> ISO -> LNK -> JS -> BAT -> DLL The second campaign (project ID 3747825559), seen on 16 September, was delivered as an EXE dropped by PrivateLoader. There were around 79 potential victims and most of them first communicated with the C2 on 16 September. The last victim requests to the C2 occurred 19 September and traffic with the T2 ended 22 September. ________________________________________ 19 Sep The campaign that occurred on 19 September (project ID 775636601) was a bit of an outlier compared to the others we’ve looked at so far. Delivery consisted of a password protected zip file containing an ISO: Password Protected Zip -> ISO -> LNK -> DLL The C2 was aviadronazhed[.]com, which was updated to resolve to 67.205.169[.]96 on the day of the campaign. Inbound port 80 traffic began at around 15:00 UTC and continued for about three hours for a total of five potential victims. T2 traffic began about two and half hours after the victim traffic (17:30 UTC) and lasted around two and half hours after the last port 80 request (20:30 UTC). Oddly, the C2 was then disconnected from the T2 instead of continuing to communicate for the usual period of approximately six days. Another oddity was that unlike other C2s where domains remained on the same IPs at the conclusion of a campaign, this domain was updated and removed from 67.205.169[.]96 on 22 September. ________________________________________ 20-21 September Three campaigns occurred during the period 20 - 21 September and each had a unique domain that resolved to the same IP (161.35.110[.]54). The IP was reused between domains similarly to the 15 - 16 September campaigns, except in this case the domains were unique. There was one campaign seen on 20 September (project ID 512092511) with alkaliodplus[.]com as its C2. For delivery it used a password protected zip file and ISO: Password Protected ZIP -> ISO -> LNK -> BAT -> DLL Two campaigns were seen on 21 September, each with a unique project ID and domain: nikolandfantazy[.]com (project ID 1367965656) and zalikomanperis[.]com (project ID 2432960414). The delivery was via a password protected zip containing an ISO: Password Protected ZIP -> ISO -> LNK -> JS -> CMD -> DLL There were 29 potential victims from when the C2 was active between 20 - 27 September, with the last communication from a unique IP on port 80 happening on the 26 September. Only two victims hit the C2 on 20 September and most of the traffic began on 21 September before gradually tapering off. ________________________________________ Bonus Bloopers! These campaigns fell outside of the timeframe we were focusing on but due to their peculiarities we thought it would be interesting to add for comparison. 9 September The lure for this campaign (project ID 3207262051) was meant to be an XLSM file for English-speakers, but the threat actors used the Italian word for “View” on the button they wanted to convince users to click. Figure 1 – Screenshot from Hatching Triage The C2 for this campaign was audifastinggip[.]com and it began resolving to 143.198.178[.]0 on 9 September. Until 13 September around 12 potential victims were curious enough to click the “Visualizza” button, and communication with the T2 ended on 15 September. 22-23 September It appears a key component of the process may have been skipped when setting up the C2 on 22 September (project ID 1023645195). The C2 was trallfasterinf[.]com, and it resolves to 137.184.114[.]20. Unlike the other C2s we’ve tracked which were registered an average of 31 days prior to being used in a campaign, this domain was the first to be registered only one day before it was a C2. It was assigned to this IP the day of the campaign, which is normal, but T2 communications appear to have never been set up. Potential victim traffic is hitting the C2, but it goes nowhere. The C2 for 23 September (project ID 2349072319) was sebdgoldingor[.]com, and it also resolves to 137.184.114[.]20. Reusing IPs for these C2s is a new behavior which occurred twice in the same week. It was also registered with Njalla on 21 September, two days prior. Interestingly, T2 communications were still not set up when this second campaign launched. Two campaigns seen the following Monday on 26 September contained the expected T2 traffic, so it appears the threat actors may have had a bit of a mishap with 137.184.114[.]20. Analysis/Key Findings GEO Targeting The 13 September campaign targeting Italian speakers resulted in 18 potential victims. It was also the only campaign from our timeframe using a malicious Word document as the delivery method, which makes a true comparison difficult. The campaign that leveraged a CHM file along with an English-lure also had 18 potential victims. It’s probable that the target base for this campaign was larger than that aimed at Italian speakers (based on the prevalence of both languages), so 18 potential Italian victims may be considered a successful number to the threat actors. Delivery Methods The campaign with the highest potential victim count was the campaign targeting English speakers that was released the same day as the Italian campaign (13 September). It was delivered via the most common method; a password protected zip file containing an ISO, which contained a LNK file. The second most successful campaign was that which leveraged PrivateLoader on 16 September 16. From our observations, it appears that campaigns leveraging CHM files are less successful, which could explain why we have only seen this technique being used twice. However, we do not have a complete picture - the number of victims may have been proportionately similar (or different) based on the number of users targeted. For example, it is possible the CHM file campaigns were tests against a smaller target base, in which case one might argue that they were successful. Lastly, it appears end users are far less likely to fall for a lure if there are any errors within the aesthetics, as seen with the campaign on 9 September – security awareness training appears to pay off! Unfortunately, in the majority of cases, lures look quite realistic and don’t always contain obvious errors and misspellings. Traffic Timeline Excluding the 19 September campaign as an outlier, the majority of victim traffic hits the C2 the day after a campaign is first reported in the wild. This could be a coincidence due to the small dataset being examined, and therefore will be a topic we revisit after further tracking. Communication with the T2 infrastructure ends at least one day after the last victim traffic, which lasted anywhere from three to seven days. Due to the small sample size, this is also something we will continue to keep an eye on for any emerging patterns. The timeframe we examined was coincidently when many odd behaviors were being observed, including the changes with C2s being reused, the time between domain registration and C2 assignment shrinking, and the campaign on 19 September that was quickly cut short (among other observations not mentioned). We believe that the threat actors behind IcedID were either making changes to various infrastructure processes behind the scenes or were having technical issues during this time. Conclusion In this post we pulled back the curtain on IcedID campaign metrics and Stage 1 C2 infrastructure, to shed light on behaviors and details not often available. These metrics are numbers the threat actors are watching as well, and just like any other business may influence their future actions. When it comes to delivery methods, daily campaigns often leverage emails containing password protected zip files and ISOs and perform comparatively well. The relative success of the campaign leveraging PrivateLoader infections, with the malware concealed within ‘cracked’ software downloads, makes this method something also worth watching. The threat actors spamming IcedID are likely aware that lures with glaring mistakes and typos perform poorly compared to those that are more realistic, as we saw with the campaign on 9 September. Targets may not be as easily tricked by phishing emails nowadays, but in response the threat actors have adapted their methods to use lures that appear legitimate and don’t typically include errors. Make sure your company’s security awareness training has adapted too! We hope that these findings provide benefit to the reader in a number of areas: Context on the cadence, volume, and impact of IcedID campaigns. Data points for the assessment of the effectiveness of IcedID delivery TTPs. Context for the aging out of IcedID C2 IP IOCs; whilst IcedID domains continue to resolve to these IPs, their communications with the T2 cease after approximately 6 days. Topics for security awareness trainings that reflect the current environment IOCs
- Team Cymru’s Threat Hunting Maturity Model Explained - Part 1
Introduction to the Series In this four part series we’ll be looking at Team Cymru’s Threat Hunting Maturity Model. Its purpose is to define each step of the journey that organizations take to hire, empower and gain value from an elite threat hunting team. This series is aimed at those who may not be deeply familiar with threat intelligence lifecycles and how and where threat hunting specifically fits. For some, many years of dedication has created some highly talented skills to map, trace, and track threat actors beyond the network perimeter, but for many, the path is unknown or unclear as to where threat hunting adds value within a cyber security strategy. To go from reactive threat hunting, to proactive threat hunting and ultimately external threat hunting is a journey. First Steps Cyber threat intelligence, being described by Forrester in their report here as ‘immature’, does at first seem at odds with the perception of those practitioners who have experience using, integrating, and relying on this vital feed of information. However, when the organizational challenges and product limitations are laid out, it becomes clear there is much for cyber threat intelligence providers still to achieve in order to bring more value to practitioners, and enable senior stakeholders to understand what those values are. The inability to mature stems from poor tooling and a high volume of alerts restricting a potentially elite team from playing a more strategic role in the organization. This impacts their ability to create optimal workflows, increases operational costs, and makes it difficult for senior stakeholders to see value. Let’s look at the threat intelligence lifecycle, widely recognized as five distinct stages, each has obstacles and challenges. If we look through the lens of a budget owner and senior stakeholder, it’s not straightforward. Each of these need working through in the first phase of the Threat Hunting Maturity Model. Cyber Threat Intelligence Lifecycle PLANNING & DIRECTION For a market defined as immature, it is ironic that choice is a challenge when deciding on a commercial provider for threat intelligence. Our own Financial Study revealed our customer was using 15 simultaneously. One of the most common frustrations our customers have with threat intelligence providers is the decay in relevance and usefulness of the data itself. The other key consideration is how well (or not) the data has been curated, and to what extent. If you need industry-specific knowledge for threats unique to your sector, there’s likely to be a source, but you may need several to gain a more complete picture. COLLECTION Gaps will occur across multiple feeds, which is not surprising when cyber threat intelligence is a collection of human intelligence, imagery, electronic sources, intercepted signals, or publicly available sources (OSINT). What sets each apart will be levels of visibility for its specific use case, and how well it empowers the team and ultimately integrates into various processing platforms and data tools. PROCESSING At this stage data is processed into a comprehensible form. The data forms can require translating spoken languages into something native, processing various data types and formats, and decrypting where and when necessary. Again, the phrase ‘immature’ seems at odds with whole industries powering this stage alone. Security Information And Event Management (SIEM) solutions are effective at processing data, but only for specific formats that they support, and the ROI has eroded. This has led to disillusionment among senior stakeholders as highlighted in this article The industry is now evaluating machine learning and natural language Processing as a way to scale threat intelligence processing. ANALYSIS AND PRODUCTION Threat analysts at this stage in the cyber intelligence lifecycle now start their human intensive processes. This is a highly skilled art, and at this point, machines typically perform badly at these tasks. Outcomes include reports that must be easily consumed by senior management, stakeholders and executives. This is also where the various methods of threat hunting take place. Data has been collected from its various sources, and now it needs investigating, validating, and assessing for levels of threat and risk to the organization. We’ll cover the different methods in Part 2 across Reactive, Proactive, and External Threat Hunting. DISSEMINATION The finished product of this process must get to the right hands to be effective, so the intelligence cycle must loop back upon itself. These reports and assessments are delivered to clients as curated reports if that is the business model, or directly to leadership who commissioned the cycle in the first place. AND THEN? Is this where it stops? What happens next? POST DISSEMINATION: ACTION, OR NO ACTION? Knowledge obtained from internal threat intelligence reports enable senior decision makers to take appropriate and proportionate levels of action, based on the information they now have. This is where analysts and threat hunters add value as they are able to contrast and compare external threat intelligence, balanced with their own findings, and produce insights that are specific and unique to their organization. FEEDBACK: RESPONSE TO THREAT INTELLIGENCE Leadership who receive threat intelligence reports will then provide feedback that creates a closed loop. Based on responses back to analysts and threat hunters, it will be clear what information and knowledge became useful and actionable. That will provide clarity as to how reliable, accurate and trusted the original data was at point of collection. READY TO LEVEL UP? If you are ready to leverage threat intelligence in new ways, head to our webinar “Modernizing Security with Threat Reconnaissance” hosted by Team Cymru Fellow, Dave Monnier. You’ll gain a deeper understanding of how threat intelligence gathered externally can be exploited using your existing team. NEXT: In Part 2, we’ll start to dig into the different methods of threat hunting, reveal how the definitions have changed over time, and where they feature on the Team Cymru Threat Hunting Maturity Model.
- Tracking BokBot (IcedID) Infrastructure
Mapping a Vast and Currently Active IcedID Network BokBot (also known as IcedID) started life as a banking trojan using man-in-the-browser attacks to steal credentials from online banking sessions and initiate fraudulent transactions. Over time, the operator(s) of BokBot have also developed its use as a delivery mechanism for other malware, in particular ransomware. In the past BokBot was itself primarily distributed via the Emotet botnet. Since the takedown of Emotet earlier this year we have been tracking BokBot to see how the actors might react to and seek to exploit the situation for personal gain. Over recent months we have been posting BokBot IOCs to our Twitter account (@teamcymru_S2) as we identify them. However, in this blog we want to share some of our broader techniques, as well as a brief insight into our recent view of the upward management of BokBot infrastructure. All ‘Tier 1’ BokBot domains and hosting IP addresses, which we have identified over the past six months, are available through our public GitHub. PASSIVE DNS Our research started with a list of BokBot controller domains, identified in a blog post by FireEye in February: colombosuede[.]club colosssueded[.]top golddisco[.]top june85[.]cyou Pivoting on these domain names within our Passive DNS (PDNS) data holdings, we were able to identify several dozen linked domains, as well as a handful of ‘Tier 1’ hosting IP addresses. A summary of these findings is illustrated in Figure 1 below. Figure 1: Initial PDNS Pivots All of the domains we identified in this process used relatively uncommon top-level domains (TLDs) (Figure 2) and were registered through domain name registrars NameSilo and Porkbun. The majority of the Tier 1 IP addresses we identified were assigned to either Digital Ocean or M247. These three elements (TLD, domain registrar and hosting provider) provide us with a repeating pattern, which gives us a degree of confidence that the identified domains are related. Figure 2: Most Frequently Occurring TLDs CERTIFICATE AND BANNER INFORMATION Looking more closely at the Tier 1 IP addresses hosting these domains, more patterns begin to emerge. Firstly, these IP addresses host a self-signed X.509 certificate with the subject: CN=localhost, C=AU, ST=Some State, O=Internet Widgits Pty Ltd Whilst not unique to BokBot hosts, the repeated appearance of this certificate provides another indication that identified infrastructure is linked. Secondly, we often observed banner information on these IP addresses indicating the use of OpenResty (a web platform based on Nginx). OpenResty has previously been identified as a tool favoured by the BokBot operator(s) for management activities – dating back to 2017. NETWORK TRAFFIC ANALYSIS Next, we utilized our network traffic data holdings to look for common peers amongst the Tier 1 IP addresses. Using this methodology, we identified several Tier 2 IP addresses which were used to relay traffic from the Tier 1 IP addresses over TCP/443. The Tier 2 IP addresses hosted banner information indicating the use of OpenResty, similar to the Tier 1 IP addresses. We subsequently discovered these Tier 2 IP addresses were exchanging network traffic with dozens of previously unknown Tier 1 IP addresses, which we then enriched with PDNS data to identify further BokBot domains. This process becomes repeatable – pivoting between network traffic and PDNS data until all ‘new’ infrastructure identifications are exhausted. A common attribute amongst the Tier 2 IP addresses was the hosting of an X.509 certificate with a CN value of ‘main.info’. This certificate was first observed on IP 185.103.110.172, assigned to Creanova Hosting Solutions Ltd in Finland, and subsequently observed on a further sixteen Tier 2 IP addresses (Table 1). Table 1: BokBot Tier 2 IP Addresses Figure 3: BokBot Infrastructure Discovery Process We observed the Tier 2 IP addresses in Table 1 being used in the management of BokBot infrastructure over a number of months. However, on 29 April 2021 we noticed a significant drop-off in activity, which has remained consistent to the time of publishing (Figure 3). Figure 4: Tier 2 IP Address Activity Timeline CONCLUSION In conclusion, while BokBot operations may have been temporarily impacted by the Emotet takedown, our analysis shows they are currently running a vast and active network which encompasses upwards of 1,500 domains hosted on over 250 Tier 1 IP addresses. We hope that the releasing of these indicators proves helpful in identifying and mitigating existing BokBot activities and also in disrupting the future operations of the BokBot actor(s). Our findings are summarized in Figure 5 below: Figure 5: BokBot Infrastructure Overview
- Announcing: A Free Attack Surface Assessment Report
Get Valuable Insights about Your Attack Surface, Detect Vulnerabilities … And get a free t-shirt! Your Attack Surface could provide attackers with an “open door” to your entire organization. Are you aware of the risks? The risks your organization faces from your attack surface are significant, and very hard to understand. Forgotten assets, 3rd party dependencies, shadow IT, and devices vulnerable to threats are all part of your attack surface. What you don’t know about your attack surface could lead to your next breach! Using Team Cymru’s Pure Signal, our unmatched internet visibility gives you the ability to immediately discover and quantify your risks - you’ll even get a t-shirt to say you’ve been there and done it. Why is discovering external assets so challenging? Discovery is hard: attempting to discover external assets is time consuming, expensive, and often inaccurate, if not continually out of date. Tracking and managing assets: Many security teams try to manage their assets in a spreadsheet, this is time-consuming, error-prone, and will never keep up with the pace of rapid changes to IT infrastructure. Accuracy and currency: Most organizations External Attack Surface is dynamic, evolving, expanding, and in many cases, sprawling. Many organizations will admit they know what they don’t know: what their external assets are and who owns them internally. We can now fill this critical information gap. Here is your chance to get some free insight into what you are missing. Vulnerability scanning: An Effective Means to Managing Your Attack Surface? Not designed for ASM: Using vulnerability scanning tools is not practical or cost effective on a daily basis. The shifting asset landscape results in security gaps that outpace asset scanning. Alert fatigue continues to plague security teams, impacting the entire SOC. Knowing which vulnerabilities to prioritize over others, regardless of the CVE rating, is a challenge. Prioritization: How can you tell not just who owns what, but just how important is it really? Getting a clear picture of combined business impact and vulnerability severity is significant to prioritization. Take The first step toward clarity, visibility, and reducing external asset related risks With our free Attack Surface Assessment Report, submit a domain you own - and we’ll do the rest. Outcome: You’ll become aware of how many IP addresses and other assets are discoverable If there are potential vulnerabilities associated with them Get a clear number of third-party dependencies Discover any malicious threats impacting assets you own Expert Advice: Armed with your report, you’ll have the option to discuss the results with our highly-experienced security practitioners, who can answer any questions and discuss how you can address and reduce risks.
- Team Cymru Myth vs Fact
Team Cymru has a clear mission: To Save and Improve Human Lives. We strive to meet this mission by equipping network defenders with insights sourced from Internet traffic, that we process and refine into actionable threat intelligence. There have been misunderstandings about the use of Internet traffic to protect networks from attack and abuse. This post clarifies how we collect, refine and distribute threat intelligence derived from Internet-sourced data. We do this for our customers and the wider community of Internet security defenders who believe in making the Internet safer for everyone. We hope this post helps explain the mission that we have been passionately pursuing for over 20 years. Team Cymru is a ‘data broker [1]’ Fact: We are not a data broker. Our focus is on compromised and malevolent Internet devices, not on persons. We hold no subscriber data that would allow any users of our product to connect a person to a piece of Internet infrastructure. The data that underpins our product is lawfully handled and compliant with all applicable data privacy regulations, including GDPR, CCPA and other relevant state and national privacy legislation. Our platform doesn’t show the type, usage or users of Internet services. Myth: The Augury platform makes a wide array of different types of internet data available to its users, including packet capture data (PCAP) related to email, remote desktop, and file sharing protocols. Fact: Our platform does not collect email, remote desktop or file sharing (FTP, torrents, et al.) on the Internet. Numerous studies have shown that the collection of email is not possible because the vast majority of email is encrypted end-to-end. In a September 2022 Google report [2], it was shown that 75% of outbound email and 86% of inbound email is encrypted in transit. Email to and from many providers, such as Google, Microsoft, Cloudflare, Amazon, Comcast, Apple iCloud, Facebook, LinkedIn, Twitter, Instagram, and Protonmail, is encrypted in transit by default via TLS, without any user configuration required. According to Microsoft [3], Remote Desktop Protocol (RDP) has been encrypted by default since 2009. We extract malicious email addresses (not content), remote desktop attempts, and FTP attempts through our malware sandboxing, and we report spam and phishing from our spam traps and honeypots. All of our PCAPs are generated in our internal infrastructure. Myth: “Augury’s data can also include web browser activity, like URLs visited and cookie usage.” Fact: Our platform isn’t capable of global web traffic collection and presentation. Our platform only provides URLs and cookies mapped to malicious servers. Studies have proven such collection activity simply isn’t possible. The web is an encrypted sphere, keeping web traffic safe from prying eyes. Google’s transparency study [4] shows that over 90% of page loads via their Chrome browser are encrypted over HTTPS. In Google’s review of the top 100 web sites, which account for 25% of all global web traffic, 100 out of 100 of those sites provide encryption, and 97 of them default to encryption. Scott Helme [5] has performed checks of the Alexa top one million web sites, and showed that 72% of the top one million web sites defaulted to encryption. The CA Security Council [6] predicted that over 90% of web traffic would be encrypted by May 2019, presciently matching Google’s current findings. The Firefox Telemetry project [7] concluded that 87% of all page loads by Firefox browsers were encrypted. Yet there are compromised websites, with the Webtribunal study [8] of April 2022 noting that 1 in 10 URLs are malicious. IBM noted [9] in 2020 that 30,000 web sites are hacked each day. Through our malware analysis engines, scanners, honeypots, spam traps, phishing detection, IDS platform, and feeds of IOCs (indicators of compromise) we identify compromised websites. These sites spread malware, command armies of bots and launch attacks, in addition to stealing credentials. Network defenders want to spot, block, or clean these devices and related infected devices as quickly as possible. Our platform makes it possible to see these hacked sites. This data is tied solely to malicious activity and malicious infrastructure, and the network defenders who use our tools rely on it to better defend their infrastructure. Myth: Team Cymru obtains PCAP data from the ISPs it has relationships with. Fact: We do not obtain PCAP data from any 3rd party. We invest significant resources towards running our own global platform of honeypots, IDS sensors, scanners, and numerous malware processing engines. Our infrastructure is the source of our data. This data forms the basis of our products and services, including services such as our free to use CSIRT (Computer Security Incident Response Team) Assistance Program and the Malware Hash Registry (MHR). CSIRT teams in over 140 countries download our threat intelligence daily. Millions of queries hit our publicly available insight portals, and our customers use our feeds and platforms to defend their networks. Our stellar reputation results from two decades of partnership with the communities and network defenders. Myth: “Augury also contains so-called netflow data … Netflow records can reveal which servers users connect to, often thereby revealing specific websites they visit. The logs may also reveal the volume of data sent or received, and how long a user accessed a site.” Fact: Augury does not provide anyone access to raw or bulk netflow data. Netflow records contain no content or user information. It is statistically inaccurate to assert that netflow can be used to identify an individual or provide a pattern of life that can be mapped to a person and preferences. Limited, specific queries producing anonymized and aggregated results can be derived from sampled netflow. Netflow does not identify users. Netflow data includes only headers such as protocol and device IP addresses. It is sampled and thus sees only approximately 1 in every 10,000 netflow. These sessions include scanning, hacking, DDoS, and other forms of malicious activity. Further, legitimate sessions are driven through content delivery networks (CDN) behind which sit millions of websites. Of the top 1M websites [10], 43.96% sit behind CDNs, 59.04% of the top 100K websites and 61.95% of the Top 10K websites. It is impossible to use netflow to differentiate between these websites. Additionally, shared infrastructure among cloud providers further precludes identifying specific cloud hosted infrastructures. It is thus statistically inaccurate to assert that netflow can be used to identify an individual or provide a pattern of life that can be mapped to a person and preferences. There are no logs or any content included in netflow. Malicious controllers, large scale scans, and DDoS have a persistence and periodicity that reveals a statistical pattern, permitting the mapping of malicious infrastructures and identifying hacked devices of importance to network defenders. Augury enables the mapping of malicious devices, not people. Please see our Nimbus Threat Monitor and other Community Services for additional details. https://www.team-cymru.com/community-services [11] Myth: “Augury provides different levels of access for private (commercial) and government clients. Fact: False. There is one identical platform with usage-based tiers. Please direct requests for further information to 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 Download a PDF of this post here.
- Sliver Case Study: Assessing Common Offensive Security Tools
The Use of the Sliver C2 Framework for Malicious Purposes The proliferation of Cobalt Strike during the early 2020s has been undeniable, and its impact unquestionable. In response to this challenge, the detection strategies of defenders have steadily matured. Consequently, threat actor decision making with regards to tooling is likely evolving too. We therefore decided to identify and track Cobalt Strike “alternatives”, specifically off-the-shelf Offensive Security Tools (OST). In this post we will discuss the Sliver C2 framework and its usage for potentially malicious purposes since the start of 2022. Sliver is a Golang based implant and thus is compatible with the major operating systems. Our focus centered on the detection of new Sliver samples associated with Linux, MacOS, and Windows operating systems, and the extracted network infrastructure contained within those samples. To understand threat actor TTPs, we subsequently tracked network telemetry for the wider C2 infrastructure in cases where Sliver was deployed. Key Findings Sliver utilized as a beachhead for the initial infection tool-chain Sliver utilized in the ransomware delivery framework for attacks observed in the wild Sliver deployed via active opportunistic scanning and possible exploitation of Log4j / VMware Horizon vulnerabilities Sliver utilized in the targeting of organizations within Government, Research, Telecom, and University sectors, in addition to sporadic victims of opportunity Identification of Sliver Samples Sliver’s current advantage lies in its obscurity alongside other less commonly utilized OSTs, with most organizations still focused on Cobalt Strike detection. This opens a possible gap in coverage – no one can be expected to detect all the things. This gap exposes organizations to the risk of these lesser known, yet still highly capable, OST C2 frameworks. During Q1 of 2022, we observed 143 Sliver samples, detected with the potential for usage as a first stage tool in malicious activity. For comparison, 4,455 samples of Cobalt Strike were observed within the same time-period. Based on the continued prevalence of Cobalt Strike, organizations focusing on detection of that toolset are certainly justified. However, if organizations have the resources to do so, we strongly recommend some study of Sliver to identify possible detection opportunities. This should be considered an anecdotal analysis of samples, as no detection rule is infallible, and no malware corpus complete. It is also not feasible to distinguish between legitimate versus malicious use for the totality of samples identified. What follows is our analysis of two distinct malicious campaigns which leveraged Sliver for C2 purposes. Sliver Campaign 1 – “Scan & Exploit” 193.27.228.127 (SELECTEL, RU) C2 PORTS: 8888, 13338, 23338, 33338 Between 03 February – 04 March 2022 Sliver samples were discovered, utilizing Russian-hosted infrastructure, in the targeting of organizations in various sectors distributed globally. These samples and associated C2 IP (193.27.228.127) were deemed malicious, based on observations of 193.27.228.127 sweeping ranges in an indiscriminate manner, likely seeking exploitation opportunities. Data from GreyNoise further highlighted the use of 193.27.228.127 for malicious purposes, targeting Log4j and Exchange (ProxyShell) vulnerabilities. Based on the identification of Virlock samples (as discussed later in this blog) it is assessed that in some cases the actors sought to monetize the accesses they had gained. In one instance, a victim was observed connecting to TCP/80 on 193.27.228.127, potentially indicative of an exploitation of Log4j, with subsequent connections to 193.27.228.127:8888. This victim was identified running VMware Horizon and was therefore likely vulnerable to CVE-2021-44228 and CVE-2021-45046. The use of TCP/8888 aligns with several identified Sliver samples configured to communicate with 193.27.228.127. After a period of approximately 14 days, we observed the C2 communications ‘migrate’ to TCP/13338, TCP/23338, and TCP/33338. NOTE: TCP/8888 is associated with Sliver’s default mTLS configuration, the use of the additional TCP ports ending in *3338 appeared more unique to this threat actor and were utilized in circumstances where victim communications persisted over extended time-periods. The following samples (Table 1) were observed communicating with C2 IP 193.27.228.127. When generating payloads, the Sliver configurator outputs a binary based on a naming convention of RANDOMWORD1_RANDOMWORD2.exe by default. In this case, Sliver was utilized for C2 communications in the first stage of the breach activity. A subsequent sample, identified as Atera Remote Management software, also communicated with 193.27.228.127. This sample was first uploaded to VirusTotal on February 11, 2022. It appeared the actor used these two tools in concert, potentially switching to the use of Atera after initial compromise was achieved. Atera Sample SHA-256: 0ef7eebec233eb5e4156a8a4715c8d21d8930ea97c19780fc274a62260499412 176.113.115.107 (Red Bytes LLC, RU) C2 PORTS: 8888, 13338, 23338, 33338 Approximately 30 days after first observing victim communications with 193.27.228.127, the actor was observed switching victims to a new C2 IP (176.113.115.107), again assigned to a provider in Russia. As previously, victim communications continued over TCP/13338, TCP/23338, and TCP/33338. ‘In-the-wild’ file names for samples communicating with 176.113.115.107 continued to point towards exploitation of Log4j and VMware Horizon vulnerabilities (Table 2). In addition to the above referenced samples, a sample with possible Virlock ransomware capabilities was also observed communicating with 176.113.115.107. This sample was first uploaded to VirusTotal on March 11, 2022. This finding is indicative of the actor attempting to monetize the access gained by deploying ransomware on a compromised host. It is unclear whether ransomware deployment was the intended final goal in every case. Virlock Sample SHA-256: 2d6785797cd3f2bfb377b985efe55db0220e12e3c7b1e12ee83888b61a5ad8da 45.9.148.243 (NICEIT, DM) C2 PORT: 8888 Finally, in recent days an additional Sliver sample was detected, communicating with a ‘new’ C2 IP (45.9.148.243) assigned to a provider in Dominica. Network telemetry data does not indicate any current victim communications and it is unclear how this sample / C2 IP is connected to this activity. Updates on this activity will be posted on Twitter via @teamcymru_S2. Sliver Sample SHA-256: b9e95117e23e6a69e71441aef07f9683cf0682f34f8f84f876822d8143a05776 One of the challenges faced when tracking this activity was the volume of noise generated by the ongoing exploitation of hosts via vulnerabilities in utilities such as Log4j and Exchange. In several cases, we observed the same victim likely compromised by multiple threat actors. However, what can be concluded is the apparent utilization of Sliver in malicious activity, coupled with the continuous scanning, exploitation, and triage of victim infrastructure. The activity associated with this cluster was previously commented on in other public reporting: Sophos: Horde of miner bots and backdoors leveraged Log4J to attack VMware Horizon servers TrueSec: FIN12/Conti Syndicate Use TeamTNT Tools in Ransomware Attacks Sliver Campaign #2 – Pakistan & Turkey The second campaign identified leveraging Sliver was deemed malicious based on the domain name utilized by the actors, which appeared to target government entities in Pakistan and Turkey. The detected Sliver samples communicated with ping.turkey.g0v.cq.cn, which resolved to IP 16.162.223.161 (AMAZON-02, US). Sliver Samples SHA-256: f301e581bb62b251abc7009a709fb163ceeb63de42625d6bfc2ac9a07d9d3adb SHA-256: a862e2d3aa3a74e23665010ded23510210927d3c056d645f32479be0974e057a Network telemetry data for 16.162.223.161 did not identify current victim communications, however this does not rule out ongoing or future malicious activity. Passive DNS data for 16.162.223.161 identified three further domains resolving to this IP address: nationalhelpdesk.pk pkgov.org sngpl.org.pk Given the similarity in the apparent spoofing of government entities, it was inferred that these domains related to the domain (ping.turkey.g0v.cq.cn) identified in the Sliver samples. A further pivot on pkgov.org identified an email address (abdulrehm8282@gmail.com) used in the domain registration. This email address was used in the registration of two further domains, which resolved to IP 15.152.186.38 (AMAZON-02, US): ntcgov.org uno-desk.org In this case, network telemetry for 15.152.186.38:80 provided evidence of inbound connections from potential victims located in Pakistan. NTC is likely a reference to one of two Pakistani organizations; the National Telecom Corporation, or the National Technology Council. Data from our Botnet Analysis and Reporting Service (BARS) indicated that a Cobalt Strike Beacon server was listening on TCP/80 of 15.152.186.38, associated with the following shellcode sample: SHA-256: bc94d6ed7abfea4239e941817cdad65a0a243e2e4a718ef401db4cbbef0bf478 Passive DNS data for ntcgov.org identified several subdomains, providing an insight into the intended targets of this campaign: dxb.ntcgov.org geo-raabta.ntcgov.org geo-tv.ntcgov.org The string dxb possibly relates to DXB, the airport code for Dubai International, and the string raabta possibly relates to a project undertaken by the Centre for Pakistan and Gulf Studies. It could be inferred that this campaign was undertaken to gain insight into collaborative projects conducted between Pakistan and the Gulf States (which includes Dubai, UAE). CONCLUSION We have observed a steady increase in detected Sliver samples over Q1 of 2022, providing insight into actor deployment methods and objectives. Of note we identified two separate campaigns which leveraged Sliver for likely malicious purposes. The latter campaign highlighted the potential use of both Sliver and Cobalt Strike in conjunction with each other. As previously stated, the threat posed by malicious utilization of Cobalt Strike has not diminished, however we would recommend that organizations also remain mindful of other OSTs, by applying resources to develop detection mechanisms for frameworks like Sliver. RECOMMENDATIONS Improve visibility Consider an attack surface management solution to track remediation of vulnerable assets. Be proactive Monitor (and hunt externally, beyond your network perimeter) for Sliver with community Snort / YARA rules, for example: UK NCSC (link) Travis Green (link) Monitor and hunt internally within your infrastructures, look specifically for Sliver as an initial payload, or in concert with other OSTs (like Cobalt Strike). Research Review threat actor TTPs where Sliver was leveraged in previous malicious campaigns, for example: SANS (link) @pathtofile (link) Alexis Rodriguez (link) FURTHER READING If you are concerned about the risks and vulnerabilities of external assets, you can access our eBook on Attack Surface Management here: https://team-cymru.com/ebook-the-future-of-attack-surface-management-brad-laporte/ INDICATORS OF COMPROMISE IP Addresses 193.27.228.127 176.113.115.107 45.9.148.243 16.162.223.161 15.152.186.38 Domains ping.turkey.g0v.cq.cn nationalhelpdesk.pk pkgov.org sngpl.org.pk uno-desk.org dxb.ntcgov.org geo-raabta.ntcgov.org geo-tv.ntcgov.org SHA-256 Hashes 1f95397c4634f3348f3001a02eab269148f4c08271c2e2461905a4359f7c4761 d8241e046cb9efcfa7ce733249d580eacff996d8669adbe71019eedafb696a55 08137096b85a3a2611249bb57ba9ace4e8efc9ba28cfddd8557edc3e11e9690c 2190a7d8d7eafd4af56b01d9a828ab2dc553a804ccda4c291dce51ce01da81f8 0ef7eebec233eb5e4156a8a4715c8d21d8930ea97c19780fc274a62260499412 fc2b02476805361fc5042adfb40b529431151a9c7da2b21fa3fa73e98fba9f64 d2958f7b646c092fe645cbdc4c7805490ff9d134c12fa8d945132e71880dd6fd 7f0deab21a3773295319e7a0afca1bea792943de0041e22523eb0d61a1c155e2 c139a777b9b1bca0d7e43335d23c123171dbaceccf45a9eeaf359051e0d0be8e 2d6785797cd3f2bfb377b985efe55db0220e12e3c7b1e12ee83888b61a5ad8da b9e95117e23e6a69e71441aef07f9683cf0682f34f8f84f876822d8143a05776 f301e581bb62b251abc7009a709fb163ceeb63de42625d6bfc2ac9a07d9d3adb a862e2d3aa3a74e23665010ded23510210927d3c056d645f32479be0974e057a bc94d6ed7abfea4239e941817cdad65a0a243e2e4a718ef401db4cbbef0bf478