Search Results

Elite Threat Hunting Teams Track Down Hidden Threats in M&A Situations By now we have discussed several areas of proactive security and how external threat hunting functions powered by Pure Signal Recon pays back huge dividends to the budget and reducing corporate risk. The most obvious area where supporting elite threat hunting capabilities pays off is in avoiding a data breach in the first place. Other areas where new capabilities were realized include trimming unnecessary sources of threat intelligence. Then we talked about third party risk reduction and cost savings are other areas aided by early identification of compromised supply chain partners. Now let’s tackle the subject of threat hunting for and on behalf of the Corporate Risk team. Proactively searching for ongoing threats relating to M&A activities and within subsidiaries pays off in early identification of compromise. This is an important part of daily life in a multinational corporation as new acquisitions represent the key to growth and access to innovation, but they also send chills down the spine of those responsible for the day they join parent IT systems. How do you really know news of the acquisition hasn’t already leaked into the hands of your adversaries? They can more easily implant themselves in a smaller acquisition, wait around until they are integrated with your system and voila! They now have access to you: their original objective. However, there is significant opportunity in being proactive, as this is an area where CISO efforts to be proactive in their cybersecurity program can stand out and make a direct impact on reducing corporate risk. Detecting Active CyberThreats in M&A Activities Gives Back to the Budget When it comes to monitoring the cybersecurity practices of M&A interests and recently acquired companies, there are two schools of thought for assessing their cybersecurity posture. One course of CISO action says that when due diligence kicks in, that is when you can hand out the security questions, audit spreadsheets, and security scorecard forms to the company you are looking to acquire. Another train of thought calls for saving the spreadsheets for later and dive in right now and start monitoring the company’s infrastructure for threats and malicious C2 communications. There are no prizes for guessing which option gives a clear picture of risks and threats in real time. By using Pure Signal Recon analysts have the visibility into the external threat landscape - that means eyes on the acquisition candidates today, now. Not after forming filling, and especially not after networks are joined and breach attacks commence. Forward looking CISOs need to instruct their teams to proactively look for compromises in third party infrastructure and monitor for signs of malicious communications with C2 systems. It is much better to be in a position of being able to tell a subsidiary or a M&A target that they have a problem than to wait for them to tell you they have a problem - this is how the story unfurled at our customer: The security team was able to detect an advanced persistent threat that none of the company’s other defenses picked-up. With information from Recon, the subsidiary’s IR team shut down the attack before any more damage was done. Early identification of this attack paid off in several ways: Shut-down an attack on a subsidiary with real-time notification of malicious C2 communications Prevented attacker from gaining enough access to pivot to core networks and applications of the parent company Avoided post breach costs of remediation, customer communications, fines, and all other external facing costs Averted malware attack on new organizational acquisition, saving $771,450 over 3 years The external attack surface of this enterprise organization represents a large chunk of real estate as it spans their infrastructure as well as supply chain partners, serious M&A targets, and subsidiaries. Corporate risk runs high as these entities represent new ways for attackers to entrench themselves in core systems of the parent company. M&A opportunities and subsidiaries are ripe for sophisticated attackers to spread their wings and find new ways to infiltrate parent organizations. It is a perfect situation for attackers to take advantage of. Everyone is distracted, busy, and there are many new names and faces. Some say it is the perfect opportunity for a ransomware attack, as a company being acquired will most likely pay a ransom instead of disclosing what happened to the parent company. Taking a proactive approach to cybersecurity pays off, a recent Accenture study revealed that 92% of CIOs say their cybersecurity due diligence uncovered key risks or resulted in a material impact in their deals. M&A deals are a high stakes game with a lot of money involved and you can’t put off cybersecurity until the deal is done. CISO Tools: Learn more about how you can get started on the path towards reducing data breaches and utilizing real-time threat intelligence, request a free copy of the full financial analysis of Threat Reconnaissance here. Engage your analysts directly with our Security Architects and expert practitioners via our Sales Team, starting here.

Up the Ante Against Supply Chain Attacks and Still Have Time to Save the World Introduction In our first post we talked about how external threat hunting with Pure Signal Recon can have a direct financial savings in terms of reducing the cost of a data breach and minimizing risk. In our second blog post we talked about how most organizations need fewer cyber threat intelligence sources than they subscribe to, it’s a good place to realize some tactical yet meaningful budget savings. Based on feedback from our Fortune 10 client, we also explored how too many CTI sources can detract from your external threat hunting program if the curated data isn’t relevant or timely. Let’s discuss the impact Pure Signal Recon had on this Fortune 10 security organization to help them better identify security gaps and confirmed threats originating from their supply chain. Additional visibility and leveraging the right CTI data reduced the cost of compromise, with use cases such as: Early identification of compromised third parties Shut down of threat actor Command & Control (C2) communications in real-time Blocking 24 of 30 significant events with third parties.* Notifying an additional 300 compromised organizations and provided enough information to prevent or minimize damage Raising the cost to attack - Continually forced bad actors to retool their infrastructure In addition, their supply chain threat hunting and monitoring efforts earned a projected cost reduction of $1,3M of net present value savings over three years. A Mile Long Supply Chain Requires Significant Expertise to Secure This Fortune 10 multinational national retailer has a supply chain that is expansive as it varied. While there is no doubt their supply chain serves as a strategic advantage; it can also be used as another attack vector to compromise vulnerable core applications and security gaps in infrastructure. This is no surprise considering 98% of organizations have a relationship with at least one third party that has experienced a breach in the last two years.1 Every compromised supply chain partner incident has a significant cost in terms of cybersecurity, legal and potentially PR expertise to respond to an event, depending how far reaching the breach, and how well recognized your brand. Time is crucial to ensuring a third-party breach can’t be used to pivot into core systems. The legal & PR teams get involved to minimize the possibility of negative press and customer notification mandates. The case study organization typically requires at least 15 FTE security analysts or legal professionals working three days each when a partner is compromised. Using Pure Signal Recon, they were able to block 24 of 30 significant events with a third party. Using a simple formula of $75 per hour for each FTE multiplied by 3 days each, it is easy to see how the cost of responding to supply chain compromises adds up. High-risk third-party threat events where threat hunting team prevented compromise 24 Time that security team and lawyers are involved per third-party compromise (hours) 15 employees x 3 days each x 8 hours per day = 360 Average hourly cost of security and legal team members Assumption $75 Cost per event $27,000 x 24 events prevented = $648,000 x 3 years = $1.4M Risk Adjusted Net Present Value Even by downward adjusting the figures by 15% to yield a three-year risk-adjusted total point value, it still equals a cost savings of $1,3M in terms of expert resources and time. Threat Hunting for the Greater Good: Third Party Notification and Community Collaboration Reduces ROI for Attackers A good payoff for proactive supply chain monitoring efforts is avoiding 3rd party compromises from happening in the first place. But when your external threat hunting capabilities can benefit the broader good while making it harder for attackers to succeed; it is a great payoff. If your organization promotes Corporate Social Responsibility (CSR) in the public domain, then the following stats are incredibly valuable to your senior stakeholders in addition to your Marketing and PR Teams, and perhaps as CISO will work wonders for your personal profile in the public domain. This security team fought back against attacker advancements and upped the ante by notifying more than 350 other victims of similar C2 communications. With Pure Signal Recon the security team were able to map infrastructure being used by ransomware gangs, watch it evolve in real-time and notify potential victims and provide advice to stop a compromise from happening. Real-time visibility into attacker infrastructure increases the cost for attackers as C2 communications are quickly identified and blocked with Pure Signal Recon forcing attackers to retool. The other victims of this ransomware group included non-profits, school districts, universities and even some Government agencies. This speaks to Team Cymru’s own mission: To Save and Improve Human Lives, and we’re proud to see how this influences our customers to join us in our mission. This type of recognition of adding value to those who need it goes a long way toward bolstering the role of a CISO and how they, along with an elite group of threat hunters, can benefit the broader community. 1 SANS Ethical Hacker Report 2022 . CISO Tools: Learn more about how you can get started on the path towards reducing data breaches and utilizing real-time threat intelligence, request a free copy of the full financial analysis of Threat Reconnaissance here. Engage your analysts directly with our Security Architects and expert practitioners via our Sales Team, starting here.

Stop the Budget Drain and Strain of Old Threat Data you Don’t Use In our first post, we talked about how cyber threat intelligence can help you save tangible dollars and reduce corporate risk of a data breach by using Threat Reconnaissance to prevent attacks. Even in organizations that have already shored up their defenses and reduced their risk by 75%, Pure Signal Recon helped close gaps. This Fortune 10 organization reduced costs to their budget by $1.78M over three years. This reduction was made by simply trimming down their overlapping threat intelligence feeds and focusing on real-time actionable information. Let’s talk about when having too much of a good thing can weigh down your budget and hold a threat hunting team back. Too many tools are the curse of many cybersecurity organizations. These tools can come from previous administrations, are typically only partially implemented and then rendered unusable, perhaps they come from a simple case of ‘we’ve always done it like this’. Or maybe it is vendor curated intelligence that may or may not be applicable to what you care about at the moment. When threat intelligence isn’t the right fit, it becomes another drain on the budget as well as taking up analyst time as they decide if the information is relevant. Threat Intelligence Tool x Training x Integration x Complexity = Cost This enterprise security team supports a Fortune 10 retail organization, and by identifying where data was duplicated, they were able to save $1.7M over three years, sunsetting 3 out of their 15 threat intelligence sources. By activating their subscription to Pure Signal Recon, for the first time, they were enabled to: Work with real time data outside of their network perimeter Gain actionable insights faster due to fewer tools and complexity Uncover critical threat actor information specific to their organization Pure Signal Recon provided them the visibility, data, and vital knowledge about threat actor infrastructure to preemptively stop attacks and shut down malicious communications. What was the pay off? Created of custom playbooks using a combination of Recon, their internal security data, and Recon-sourced data Reduced the budget by $1.78M by unsubscribing to two cyber-intelligence solutions and reports the first year and an additional solution starting the second year Decreased reliance on lower value vendor-created intelligence reports and data because they could respond based on the real-time raw intelligence from Pure Signal Recon CISO Tools: Learn more about how you can get started on the path towards reducing data breaches and utilizing real-time threat intelligence, request a free copy of the full financial analysis of Threat Reconnaissance here. Engage your analysts directly with our Security Architects and expert practitioners via our Sales Team, starting here.

Threat Reconnaissance that Saves your Butt and the Budget Threat hunting and reconnaissance often seems like another hard to explain cybersecurity budget item, especially when talking to business counterparts. As a CISO, you know that having an elite team of threat hunters focused on your external attack surface saves the company from a compromise or attack. External threat hunters have the visibility to monitor threat actor infrastructure, see how it evolves, and shut down any communication going to hackers. You know how important this capability is to safeguard the organization, but how about the rest of the company? Spoiler alert: over the next five parts of this series, we’re going to explain in simple terms how an elite group of threat hunters using Pure Signal Recon were able to effect a total $9m in savings. This threat hunting team supported cybersecurity needs for key business initiatives and helped their company realize a three year risk reduction savings of $9m. Half of the $9m in savings can be attributed to avoiding a data breach in the first place, so let’s start our discussion with the biggest area of cost savings and risk reduction. We’ll start where the largest savings were found, with $4.5m of the $9m being attributed to data breach avoidance. Data Breaches - Proactive Approach for Payback As a real world example we are going to examine the hard dollars that a large multinational retailer saved with their investment in Pure Signal Recon to empower their analysts with unmatched threat hunting and reconnaissance capabilities. This is a company with a mature cybersecurity team that provides cybersecurity defenses to protect a 1m+ workforce, a global corporate organization with an extensive supply chain and ongoing M&A activity. This write up is based on the original Forrester Total Economic Impact™ (TEI) study, an independently held private collaboration between our client and them. The goals were to determine the cost savings gains that could be achieved by using external threat reconnaissance to support a proactive cybersecurity organization to safeguard company reputation, share value, and careers, from cyber risks. Defining the ROI of Threat Reconnaissance - What Matters Most With access to the proper tools, threat hunting empowers analysts to act on threats to your organization in real time, instead of the usual reactive responses that drain resources and budget. It opens up a new range of preemptive capabilities that can turn your threat analysts into a powerful layer of proactive cyber defense.It has When justifying budgets and helping the business understand the importance of your threat hunting function consider where it has direct impact on business outcomes: Stop a data breach from happening with a predictive response to persistent threat actors Reduce the amount of tools needed and lower the swivel chair security tax on your analysts Detect impending data breaches via your supply chain and other 3rd parties Address the business risk of new company acquisitions via M&A Remove tedious analyst work with automation so they could focus on strategic cybersecurity initiatives Predictive Response Pays Off First we will focus on the most obvious area where improved threat intelligence pays off; preventing data breaches from happening in the first place. In this real world scenario, we are profiling a sophisticated cybersecurity team that could already show that they were able to reduce the standard cost of a data breach by more than 75%. As a retail conglomerate and global brand, they are highly targeted and sought after “prize” with threat actors. They wanted to close the gap by another 40% reduction in projected costs due to a data breach. The team had the skills and experience to further close the gap on corporate risk and cost by transitioning from providing reactive cybersecurity to a more proactive response to threats. They knew about Pure Signal Recon and believed it could give them the understanding of threat actor infrastructure to enable automatic blocking of threats from getting inside. But they were also realists and knew that some threats do get inside no matter what. So they wanted the ability to preemptively stop any information from getting out should a threat enter the network. So what did this all accumulate to? What do these capabilities mean in hard dollars? Pure Signal Recon enabled analysts to act on real-time data from outside their perimeter with the ability to: Trace malicious activity back to the source, map threat actors’ infrastructures, and monitor it for changes Map key threat actors infrastructures and track their infrastructure changes See a threat actor's back-end infrastructure beyond the C2s (command and control servers). View the infrastructure that they proxy through to get to C2s to retool their attacks Block C2s being stood up as they are being stood up in real-time It was further estimated that by investing in Pure Signal Recon they realized a 20% reduction of projected data breach costs within 6 months of deployment. In terms of internal productivity, it also paid back $756K in reduction loss productivity. They estimated a data breach would affect at least 5% of the 100,000 corporate employees within scope of the potential attack, with 3.6 hours of downtime per breach with an average cost of $42 per hour. Having the ability to actively perform reconnaissance on the bad actors that persistently target your company is a critical part of effective cybersecurity strategy. When paired with the right tools, opportunities, and mindset, investing in a threat hunting function pays back dividends towards your budget. To learn more about threat reconnaissance please visit our blog here. CISO Tools: Learn more about how you can get started on the path towards reducing data breaches and utilizing real-time threat intelligence, request a free copy of the full financial analysis of Threat Reconnaissance here. Engage directly with our Security Architects and expert practitioners via our Sales Team, starting here.

Spoiler Alert: They weren't actually from Chile. Introduction This blog post provides a short update on our ongoing tracking of infrastructure associated with IcedID. We have posted publicly on IcedID on several occasions over the past year, and as far back as May 2021; they remain a persistent threat. To recap... 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 such as Cobalt Strike, with infections sometimes leading to ransomware. Late last week we identified a ‘new’ IP address connecting to 5.196.196.252; one of the currently active IcedID BackConnect C2 servers. These connections were made to the same remote port, associated with the SOCKS proxy module, which we wrote about in December 2022. Key Findings Identification of an IP address geolocated to Chile, used to access various elements of the IcedID infrastructure. The Chilean IP resides in a /24 netblock which is also utilized for hosting IcedID Bot C2 infrastructure (on separate IPs). Threat telemetry data shows consistent connections sourced from the Chilean IP, to an IP geolocated to the Netherlands which is used to host two IcedID-connected domains. Web browsing activity originating from the Chilean IP provides a snapshot into suspected threat actor TTPs. With an apparent interest in DNS and visits to services noted for association with Conti and LockBit ransomware. From Chile... Kind Of The ‘new’ IP address is assigned to Zappie Host, a New Zealand-based VPS provider, although geolocation data places it in Chile. Zappie Host, and the specific /24 netblock in which this IP resides (216.73.159.0/24), is regularly used to host IcedID Bot C2 infrastructure. In our initial assessment of this ‘Chilean’ IP, we noted a gap in activity between 12 December 2022 and 26 January 2023; interestingly, this matched timelines we had observed in the case of IcedID Bot, Loader, and BackConnect infrastructure. We have generally attributed these drops in activity to the festive and new year celebration period, infrastructure updates, and on occasion an indication of internal issues impacting the threat operators. Further, we noted the use of WireGuard VPN to access the Chilean IP; up to 12 December 2022. When activity returned in January 2023 this changed to OpenVPN. Both WireGuard VPN and OpenVPN were noted in our aforementioned investigation into BackConnect, hinting at the potential of a common playbook being used across various elements of infrastructure management associated with IcedID. Further Ties to IcedID Examining threat telemetry data for the Chilean IP, we observed connections to the panel port of the IcedID Loader Tier 2 server. This server is used to manage the Tier 1 Loader C2s, which serve the purpose of receiving initial victim communications and delivering the IcedID DLL. We have previously blogged about these first stage Loader C2s. Further connections were also observed to 168.100.8.93:443 (assigned to BLNWX - BitLaunch), commencing 27 January 2023 and continuing daily until the time of writing. During this period of activity, we identified two domains resolving to 168.100.8.93, based on pDNS and certificate data: neonmilkustaers[.]com - registered 9 November 2022 svoykbragudern[.]com - registered 18 November 2022 Both domains are typical of current IcedID domain nomenclature. Looking at domain registration data for the above dates, filtered by registrant organization (Tucows) and name server usage (Njalla), we found other domains registered within close temporal proximity: trbiriumpa[.]com - registered 9 November 2022 whothitheka[.]com - registered 9 November 2022 ebothlips[.]com - registered 9 November 2022 olifamagaznov[.]com - registered 18 November 2022 If these domains look familiar, that’s because they are - and we applaud your attention to detail. All four domains have been utilized for IcedID Loader C2 infrastructure over the past three months, and as recently as last week. However, the standout observation for 168.100.8.93 and therefore the domains hosted on it, are the differences in behavior when compared to other IcedID C2 infrastructure. According to our threat telemetry data, we do not see the expected victim communications we would usually expect for C2 infrastructure, which therefore makes us question the purpose of these domains. Victim communications with the Loader C2s tend to occur over TCP/80, so the connections from the Chilean IP appear to be related to another service. One hypothesis we have is that the Chilean IP and by extension 168.100.8.93 may be used for some form of development or testing purpose. Figure 1: Summary of Chilean IP Threat Telemetry Threat Operator TTPs In addition to the connections to IcedID-linked infrastructure, since 26 January 2023 the Chilean IP has communicated with dozens of other IP addresses over TCP/443 (HTTPS). Based on our internal pDNS data, combined with OSINT investigations, we were able to identify domains (or define the general purpose) associated with the majority of these destination IP addresses - i.e., the targets of the connections. Most consisted of websites related to DNS, privacy, and expected threat actor activity such as Tox and Tor usage. There were also visits to Yandex IP space, the Russian search engine popular in CIS countries. Below we have listed some of the sites visited, which by extension provides an insight into the services and tools the suspected threat actor behind the Chilean IP is interested in: A few of these sites are particularly pertinent: Libsodium, the library which includes features such as encryption, password hashing, etc., is also utilized in the LockBit ransomware. Njalla is currently IcedID’s domain registrar of choice, so it is somewhat unsurprising that it appears here. Qaz.im appears in the Conti Leaks, and Conti ransomware was often dropped by IcedID. Based on our observations, it appears this service continues to be used; likely a result of it being hosted in Russian IP space and therefore deemed (rightly or wrongly) to be outside the reach of LEA action. Sape, the SEO service, is notable given the recent use of malvertising campaigns as an initial delivery mechanism for IcedID. Conclusion Tracking the background infrastructure associated with the day-to-day operation of threats like IcedID allows us to not only identify new victim-facing C2 infrastructure, but also to illuminate other elements of interest. In this blog we identify a Chilean IP, which based on its activities is likely not operated by a Chilean actor, utilized for the purposes of access / management of IcedID-linked infrastructure. The surrounding activities provide us with an insight into the motivations of this actor and highlight some of the services and tools they may be using or investigating. We also allude to some techniques which can be used to identify or confirm IcedID domains, a topic which we are planning further expansion on in the future. In the case of IcedID, whilst we find that the operators can change their spots (making all leopards jealous), this is often a gradual process which provides us with opportunities for pattern-of-life, and as a result infrastructure, identification. Recommendations Although not used exclusively by IcedID operators to host their C2 infrastructure, we would recommend that defenders take interest in any activity within their networks inbound to / outbound from 216.73.159.0/24. BackConnect C2 infrastructure is fairly static, with a life-cycle of approximately 30 days, it is therefore viable to block connections to current C2s. We will continue to post updates to this infrastructure on our Twitter feed - @teamcymru_S2. Users of Pure Signal Recon will be able to track this activity by querying for inbound connections to 168.100.8.93:443 and pivoting from there. IOCs IcedID Bot C2s from 216.73.159.0/24 (Nov 2022 - Feb 2023): 216.73.159.132 216.73.159.134 216.73.159.29 216.73.159.44 216.73.159.60 216.73.159.80 Recently active BackConnect C2s: 135.148.217.85 5.196.196.252 80.66.88.71 IcedID domains (mentioned): neonmilkustaers[.]com svoykbragudern[.]com olifamagaznov[.]com trbiriumpa[.]com whothitheka[.]com ebothlips[.]com

The challenges of prioritization, the threat landscape and contextualizing risk for the business In our last post, we talked about the realities of asset discovery. We also talked about the benefits of continuous real-time discovery of assets. Now let’s talk about discovering and prioritizing vulnerabilities across the external threat landscape. Then we will discuss contextualizing digital risk with your business counterparts and how a maturity model can help you communicate risk and justify the business case. Managing your response to vulnerabilities is a whole other part of attack surface management, but first, you must discover them. Your approach to discovering assets is likely to correlate with your method of identifying vulnerabilities. From manual, occasional and sporadic all the way to automated, continuous, and structured, the knowledge you gain from differing methods can vary widely. How you discover vulnerabilities today is another useful data point to map to the Attack Surface Maturity Model. It will enable you to understand where and how you need to improve, or if what you are doing is already optimal. To improve your responses to emerging and newly discovered vulnerabilities, you must expand your knowledge of external risks and threats, then pair that knowledge with your critical assets. This is how you build the contextual knowledge to prioritize vulnerabilities by digital risk, weed out what is not critical for another time, and quickly identify false positives. Resolving vulnerabilities by deciphering quarterly scanning reports and creating service tickets is a less-than-optimal way to address vulnerabilities, it takes time. Time is an advantage to attackers, as the longer you leave gaps, the more they will be exploited and help adversaries achieve their objectives. CVSS scores help, but only when you know that vulnerability matches something in your environment. You can prioritize high-ranking vulnerabilities, but without continuous scanning, you are still operating several months too late, and in some cases, your assets may not even be exploitable. And if that were not enough, then you must meet with business stakeholders to plan for scheduled downtime of applications. At least if you could communicate vulnerabilities in real-timeHoudini-like, it would cut out at least two or three weeks of time for potential threats to dwell before being identified and managed. The good news is that if you are already prioritizing vulnerabilities, you are on the way towards benefitting sooner from new attack surface management capabilities and improving communication. Realizing the top end of the spectrum of capabilities of ASM maturity will not only support continuously scanning, but it will automatically prioritize response based of the digital risk involved. No manual intervention involved except one-time tasks of rating existing and newly discovered assets by digital risk. Houdini-like Another important area of attack surface management that is difficult to navigate is understanding and applying knowledge of external attacks. To catch up to the top range of capabilities, you must factor in what is being actively exploited and understand what is going on in the external threat environment. You need to be able to have an answer for; Who is attacking us? What is their infrastructure? What is currently being exploited by threat actors? Finally, you need to take this newfound knowledge and apply it to your supply chain partners and M&A targets. We don’t have to tell you that your supply chain offers a key opportunity for exploiting business systems to siphon off data or money to threat actors. They represent another, much wider and deeper attack surface that must become a part of your security strategy. The top end of the ASM maturity model scale requires the capability to discover assets and scan your business partners and M&A infrastructure. These newfound capabilities and insights must be contextualized for the business. Part of that is accomplished by measuring your results against industry standards. Gauge your efforts and benchmark it against your framework of choice, (NIST, FEDRAMP, PCI, CIS Top 18, etc.) This offers you a way to start conversations with business counterparts, so they operate with a clear picture of risk. It will help you justify remediation actions, budget, and your overall security strategy in your conversations. Beyond these capabilities, a mature attack surface management program saves you time. It should enable you to evolve your prioritized response to include automated communications for real-time stakeholder notification. Integration with IT Ops platforms like ServiceNow or Agile platforms like JIRA can pay back further dividends towards reducing manual processes, remediation scheduling, and help your team focus on strategic initiatives. By following a model to mature your attack surface management practice, you will find opportunities to further consolidate tools, optimize communication, respond faster, and reduce digital corporate risk. To start maturing your knowledge of the risks and threats external to your organization, sign up here for a free trial of our Attack Surface Management platform.

The challenges of asset discovery, the unknown, and ad-hoc vulnerability scans Attack surface management gets adopted because security leaders have a mandate to know their attack surface, measure and manage digital risks, and improve defense against persistent threat actors. Like most, you have adapted some of the attack surface management tenets; for example, you must “know thyself “and that means having a good handle on assets that need to be protected. Most start out with the assets they know about: crown jewel assets that represent significant revenue to the company through sales or operational efficiency. That is the very beginning of the road to discovery, as the business is always changing. You must evolve your efforts to uncover a wide range of new asset possibilities. Most vexing is that you must know what it is that you currently do not know. This is no small challenge; you must come to terms with how to keep up with applications that spin up faster than you could ever record in a spreadsheet. It’s a given that business units are going to go rogue and implement their own systems, cloud data repositories, and grant access to outside or untrusted third parties; without ever talking to you. Nevertheless, you must discover and defend these unknowns, identify application owners, and justify the very important cybersecurity actions that must take place to keep things secure by reducing digital risk. To highlight the Shadow IT challenge, our ASM customers typically discover between 30% more assets than what they thought made up their attack surface, this figure has risen as high as 500%. Rogue applications, forgotten web servers, historical portals - for an attacker they all count as legitimate targets Other times, customer POC results are truly startling and enlightening to them in equal measure. Large environments continuously breed new applications and other unknowns that get stood up every day. You already know Step One is discovery, but how do you understand where you are overall? Maturity models pinpoint your place in time and justify elevating your capabilities. You can look at where you are now, and know the capabilities needed to get where you need. Your end game; so to speak But this isn’t easy, especially if you are beginning with a legacy spreadsheet that has been passed down with little context. If you are a mid to large-sized organization with applications being stood up all the time, heavy M&A activity, and or a supply chain a mile long, the unknown becomes a more acute challenge. If discovery is the ‘what’, then the ‘how’ you go about discovering assets is another capability on the maturity model for attack surface management. Often, companies start by contracting with a company to perform quarterly scans. This is a good start. But if you work in an environment that has applications being continuously stood up, a dynamic supply chain, and consistent M&A activity, then you are constantly behind the curve ball and are acting on yesterday’s news. When you factor in the multitude of vulnerabilities being introduced on the regular, threat actor techniques, and targets changing on a whim, you quickly realize how out-of-touch efforts from quarterly scanning can become. To break through, you must get ahead of what is happening to your attack surface (all of it) and react faster. With this thought in mind, our customers quickly realize that only continuous real-time monitoring will help them keep up. It must be passive, must not affect service levels, and above all, it must be continuous and supply you with information on new instances and possible malicious intent in real-time. It’s not an easy transition for any team to meet these objectives and groom their analysts to take on an offensive security posture. Even with the benefit of working with real-time tools. Without a roadmap and the right intelligence, anyone would be off to a rough start. That is why it is important to look at a maturity model to give you outside perspective and a path to get from one end of the capability spectrum to the other. Keep reading to find out how referring to a maturity model will help you evolve your attack surface management practice to where it needs to go. If you want to fast-forward your knowledge of external assets and curious to know how many you really have, click here for our free report.

Further Insight into the Hacktivist Operation Targeting NATO and Affiliated Nations Key Findings NoName057(16) is a pro-Russian hacktivist operator / group, which has claimed responsibility for repeated Distributed Denial of Service (DDoS) attacks against entities in perceived anti-Russian countries since March 2022. NoName057(16) back-end infrastructure is hosted in Russia and likely operated by individual(s) with experience in systems design / maintenance. DDoS attack targeting instructions include timestamps that align with Moscow Standard Time. Recent targets have included entities with infrastructure hosted in Czechia, Denmark, Estonia, Germany, Slovakia, and Slovenia. The majority of DDoS attack infrastructure used in NoName057(16) campaigns is assigned to two interlinked hosting providers; MIRhosting and Stark Industries. A limited number of netblocks are used in the DDoS attacks, providing a potential mitigation / defense opportunity Introduction NoName057(16) attacks have targeted government / military departments in Ukraine and NATO countries, as well as organizations from core sectors such as finance, freight, and media. Recent reporting (Avast, SentinelLabs) has revealed that NoName057(16) relies upon a “volunteer” system (rather than a botnet of infected hosts), in which the “volunteers” are rewarded financially for contributing attack infrastructure. This system is managed via two Telegram channels (@noname05716 and @nn05716chat). In this blog post we will examine two elements of NoName057(16)’s infrastructure; the management infrastructure sitting behind the known C2 servers, and the attack infrastructure which is purportedly donated by their “volunteers”. In doing so we will seek to understand how the operation functions, and provide information for cyber defenders to protect their interests from future attacks. Infrastructure The starting point for this analysis is the current C2 server used to coordinate NoName057(16)’s campaigns; as previously reported by SentinelLabs - 31.13.195.87 (NETERRA, BG). According to our records this server became operational on 19 December 2022. Two Dynamic DNS (DDNS) domains, registered with No-IP, currently resolve to 31.13.195.87: tom56gaz6poh13f28[.]myftp.org zig35m48zur14nel40[.]myftp.org The DDoS tool (DDOSIA) receives targeting information from the /client/get_targets URL path on either of these domains (over HTTP on TCP/80). Examining network telemetry for 31.13.195.87, we observe a high volume of outbound connections to TCP/5001 of 87.121.52.9 (NETERRA, BG). The use of TCP/5001 is notable as this port was used for communications with the previous C2 server (77.91.122.69), which was active until 16 December 2022. When '87.121.52.9:5001/client/get_targets' was accessed, we noted that the same targeting information was returned, as observed on the C2 domains. It is therefore plausible that the published C2 servers are mirrors of 87.121.52.9. Figure 1: Targeting Information Pivoting to examine network telemetry for 87.121.52.9, we observe a number of interesting communications. Telegram Regular connections are made to api.telegram[.]org, potentially indicative of Telegram bot interactions. It is possible that these connections relate to updates made to the Telegram channels associated with NoName057(16)’s DDoS campaigns. CLOUDASSETS, RU A high volume of traffic is observed to two IP addresses assigned to CLOUDASSETS, RU (AS212441). 109.107.184.11 Connections are made to TCP/27017 of 109.107.184.11, this port is commonly associated with MongoDB. It is likely that data transferred from the attack infrastructure is stored in a database hosted on this IP address. 185.173.37.220 Connections are made to TCP/5672 and TCP/6379 of 185.173.37.220, these ports are commonly associated with RabbitMQ and Redis respectively. This host is therefore likely used to store events / commands from the operator(s) of this infrastructure. It is plausible that further operator hosts sit beyond this IP address, to either update or read messages from the RabbitMQ bus, however due to the geolocation of 185.173.37.220 further upstream insights are not available. In addition to the outbound connections, inbound traffic to local ports TCP/5051 and TCP/9100 was observed, sourced from 91.142.79.201 (also CLOUDASSETS, RU). Pivoting on 91.142.79.201, additional traffic was also observed sourced from this IP to TCP/9100 of 31.13.195.87 (the original C2 server). TCP/9100 is commonly associated with Prometheus Node Exporter, a platform used for collecting metrics / alerts from remote servers. Indeed, open ports information for 31.13.195.87:9100 shows an instance of Node Exporter running as of the time of writing. Figure 2: Open Ports Data for 31.13.195.87 - Censys 91.142.79.201 is therefore likely used for monitoring the operator’s infrastructure and collecting metrics on usage; possibly providing updates on campaign effectiveness and the number of active ‘bots’. In a few instances, we also observed 91.142.79.201 making connections to TCP/9100 of IP addresses used in the attack infrastructure of NoName057(16)’s operation. When reviewing the infrastructure in its totality, it is clear that the operator(s) behind NoName057(16) is familiar with systems design / maintenance; potentially pointing towards a threat actor(s) with legitimate work experience in this area. Figure 3: An Overview of NoName057(16) Infrastructure Targeting Previous reporting on NoName057(16) has highlighted DDoS attacks against an array of targets across business sectors and nations, including government / military departments. At the time of writing this report, we took a look at the ‘current’ targets of the operation; one which stood out was the Estonian Ministry of Finance, with a particular subdomain being targeted. Figure 4: Targeting Details for the Estonian Ministry of Finance From this entry on the C2 target list, we can see that a domain hosted on xx.xx.xx.246 is the target of the attack, which was set to commence at 10:00 on 25 January 2023. We initially assumed this meant 10:00 UTC, however, when looking into our threat telemetry for xx.xx.xx.246 the attack appears to have commenced at 07:00 UTC; so the start time in the C2 target list in fact refers to UTC+3, which happens to coincide with Moscow Standard Time. As of 17:00 UTC on 25 January 2023 the target subdomain was displaying a ‘down for maintenance’ message, likely indicating that the attack had achieved a degree of success. Figure 5: Maintenance Message Returning to the aforementioned threat telemetry data for this target, the DDoS attack is evident in the data; which we have mapped below looking at the last seven days of traffic to/from xx.xx.xx.246 (19 - 25 January 2023). Figure 6: DDoS Attack Data - Target One As of 17:00 UTC on 25 January, we can see that the attack began at 07:00 UTC (as mentioned previously), with a peak in activity between 08:00 UTC - 09:00 UTC, and a large volume of traffic has been received since that time; significantly outside the usual expected norms for this IP address. Looking at a previous Estonian target from the same seven-day time period, we see that the attack lasted for 24 hours, commencing and ending at 07:00 UTC. As previously, activity peaked in the first few hours of the attack; this period is likely when the DDoS is most effective, before mitigating actions can be undertaken. Figure 7: DDoS Attack Data - Target Two Overall, since the beginning of 2023, we have been able to confirm attacks against entities with infrastructure hosted in Czechia, Denmark, Estonia, Germany, Slovakia, and Slovenia. Attack Infrastructure When examining the data for the DDoS attacks against the two Estonian targets, we found that 99.8% of the traffic inbound to the second (earlier) target was sourced from IP addresses which had later been used in the attack on the first target. Whilst IPs assigned to 21 distinct ASNs were observed in this ‘common’ dataset, 98.6% of the traffic originated from IPs assigned to STARK-INDUSTRIES, GB. Looking further into the data, IPs residing in two /24 netblocks were responsible for over 65% of this traffic: 5.182.39.0/24 (38 IPs) 94.131.106.0/24 (21 IPs) STARK-INDUSTRIES, GB relates to a hosting company ‘Stark Industries Solutions Ltd’ which was incorporated in the United Kingdom through Companies House on 10 February 2022, by Moldovan national Ivan NECULITI. NECULITI is further associated with several other hosting companies; including MIRhosting and Perfect Quality (PQ) Hosting, which are purported to operate from the Netherlands and Moldova respectively. We frequently observe all three hosting companies being used to host malicious content, or as in this case, used directly for attack infrastructure. The website hucksters[.]net, which amongst other things seeks to expose individuals involved in fraud and spam, has previously profiled NECULITI. Note, we have seen no evidence which associates NECULITI directly with these malicious activities; nor do we intend to insinuate that he is connected in any way with nefarious pursuits in general. This data point is mentioned as it exists on the public record and is the common tie between the hosting companies highlighted. Pivoting back to the C2 server (31.13.195.87), by examining all inbound connections to TCP/80 since 19 December 2022, when it became operational, we are able to extract a more complete picture of the attack infrastructure. This process is caveated by the fact that other ‘non attack infrastructure’ connections are likely to have been made to 31.13.195.87:80, particularly since the publication of this IP as a C2 server for NoName057(16) activities. However, the idea here is to identify likely attack infrastructure based on the regularity and volume of traffic, and any emerging patterns, for example sequential IPs within the same netblock as seen in the two attacks above. In total we observed IPs assigned to 83 distinct ASNs communicating with 31.13.195.87:80. However, once again infrastructure associated with the previously referenced hosting provider(s) dominated, with 84% of all communications originating from IPs assigned to either MIRhosting or Stark Industries. Figure 8: Top-10 Observed ASNs Looking a little further into this data, IPs residing in a limited number of netbooks generated the majority of the traffic; the top 10 netblocks accounting for 68% of the total. Figure 9: Top-10 Observed Netblocks 5.182.39.0/24, as observed in the data for the Estonian attacks, is the clear number one, the other netblock from that data (94.131.106.0/24) was just outside the top-ten at number thirteen. What was notable was the fact that many of the IPs had been in communication with 31.13.195.87 since 19 December 2022, continuing up to the time of writing; indicating a broadly static attack infrastructure. Conclusion In this post we have examined the infrastructure used to manage the DDoS attacks attributed to NoName057(16); demonstrating a well-thought out structure which includes capacity for monitoring, tasking, and remote storage of data. As a pro-Russian hacktivist operation, it is no surprise that there are several pointers to a Russian nexus; the use of Russian hosting providers for the management infrastructure, and the use of Moscow Standard Time for targeting instructions. From our observations, whilst heavily focused on a small number of specific targets, NoName057(16) has had some successes in temporarily disrupting web services, with evidence of their targets being offline or ‘under maintenance’. The broader impacts of these attacks will likely remain limited providing there is no major escalation of activities / or growth in available attack infrastructure. That brings us to the most significant finding in this blog; the static and limited nature of the attack infrastructure which has been utilized by NoName057(16) to date. For an operation which is labeled as “volunteer” driven; the fact that so much of the infrastructure is sourced from one provider raises questions. Is a sizeable chunk donated by one generous “volunteer”? How many “volunteers” actively contribute to the operation? Are NoName057(16) propping up their operation with infrastructure they have procured themselves? We have observed a diverse range of IPs being utilized in attacks, but the volume of traffic related to the majority of these IPs is minimal; if you were to deduct the traffic sourced from IPs assigned to Stark Industries there is a question as to what impact the attacks would have. With all this being said, we will continue to monitor NoName057(16)’s activities, providing updates via our Twitter and Mastodon pages. Recommendations Although not always the best advice with DDoS attacks; we would recommend that inbound connections from the below netblocks are blocked. For users of Pure Signal Recon, you can follow this activity by querying for the IPs detailed in Figure 3; 31.13.195.87 87.121.52.9 109.107.184.11 185.173.37.220 91.142.79.201 If you are an ISP or Network Operator with DDoS challenges, sign up for our no-cost DDoS mitigation service UTRS IOCs Key Attack Infrastructure (as of 26 January 2023) 5.182.39.0/24 94.131.109.0/24 94.131.102.0/24 5.182.37.0/24 185.248.144.0/24 45.159.251.0/24 45.67.34.0/24 94.131.110.0/24 5.182.38.0/24 45.142.214.0/24 94.131.99.0/24 5.182.36.0/24 94.131.106.0/24 80.92.204.0/24 45.8.147.0/24

Summary Three key takeaways from our analysis of Vidar infrastructure: Russian VPN gateways are potentially providing anonymity for Vidar operators / customers, making it more challenging for analysts to have a complete overview of this threat. These gateways now appear to be migrating to Tor. Vidar operators appear to be expanding their infrastructure, so analysts need to keep them in their sights. We expect a new wave of customers and as a result, an increase of campaigns in the upcoming weeks. The analysis indicates that Vidar operators have split their infrastructure into two parts; one dedicated to their regular customers and the other for the management team, and also potentially premium / important users. Introduction Vidar is an info-stealer malware, which was first spotted in the wild in late 2018 by the security researcher Fumik0. Upon initial inspection, the identified sample appeared to be Arkei (another info-stealer), however differences in both the sample’s code and C2 communications were observed. The name itself (Vidar) is derived from a string found in the malware’s code. Vidar is considered to be a distinct fork of the Arkei malware family. Vidar has a simple business model, with “customers'' paying between $130 and $750 depending on the length of their subscription. Some personalization of the tool is possible, for example to tweak the targeted information types, although by default Vidar is designed to steal, amongst other things; browser histories, cookies, credentials, cryptocurrency wallets, and two-factor authentication software data. The delivery methodology for Vidar has varied over time, utilizing email / phishing lures and ‘poisoned’ cracked software targeting vendors such as AnyDesk and Windows, the latter leveraging SEO impersonation and YouTube videos to dupe users into downloading the malware. Four years after Vidar was first discovered it is now the ‘parent’ of further forks, including; Lumma, Mars, and Oski. In this post, we’ll look into the Vidar management infrastructure, starting with the ‘main’ website and pivoting from there. This website is at the same time; the Vidar customer portal where payloads, settings, victims assets, etc. can be managed, the Vidar management portal likely used for interactions with their customers, and a staging post for the deployment of VPS servers. Vidar Website Overview As observed by Fumik0 back in 2018, the ‘main’ Vidar website was hosted at my-vidar[.]com, and remained at this location until 22 August 2022. On this date the site was moved to my-odin[.]com, initially reusing the same SSL certificate. Figure 1: SSL Certificate for my-vidar[.]com Figure 2: Domains Hosting the SSL Certificate The following day the SSL certificate was updated; the threat actors likely realized they had created a trail to their new site. Visually the site remained the same following the switch in domains, with the home page displaying a long text on the origins of Vidar from a mythological perspective. This text identifies Vidar as the son of Odin (“He is the son of the chief of those gods, Odin”), providing an explanation for the use of the ‘my-odin[.]com’ domain. Navigating on URI paths on the my-odin[.]com domain led to the discovery of several paths which are accessible without logging in as a user. Figure 3: URI Paths on the my-odin[.]com Domain /auth/ This path contains the Vidar users (or customers) web portal, where access to a dashboard is provided for the management of payloads related to their campaigns, victim assets, etc. /private/ This path contains at least two files: 1. install.sh A bash script which is run on the user / customer VPS server to download all the web-server requirements for the set up of a new Vidar campaign. Figure 4: install.sh 2. Vida.tar.bz2 This archive contains all of the aforementioned Vidar web-server requirements and also the Vidar payload. We’ll detail findings related to this archive later in this post. /sellers/auth/login This path appears to be of particular significance to the operation, as the connection form not only requires user credentials but also a Google Authenticator token. We assess with medium confidence that this portal is used by the operators for maintenance purposes. Network Telemetry By examining network telemetry for the IP address used to host the my-odin[.]com domain (186.2.166.15), we were able to determine the peer IP responsible for its management. We have chosen to redact this IP due to the ongoing nature of this investigation. This management IP is subsequently used for other activities which we have deemed of relevance to the Vidar operation. Figure 5: Overview of Network Telemetry Telegram We assess that the connections to Telegram infrastructure are indicative of communications between the Vidar operators and their customers, as well as other elements of the underground economy. Mega Connections were observed to Mega user storage infrastructure (*.userstorage.mega.co.nz), these repositories are hosted on shared infrastructure so it was not possible to discern specific user identification associated with Vidar. Bofbot Bofbot appears to be a cryptocurrency / investment platform of questionable legitimacy. It is possible the Vidar operators utilize Bofbot for the processing of payments from their customers, or even a service they are involved in running themselves - the IP hosting the Bofbot domain was previously used to host the original my-vidar[.]com domain. The IP addresses hosting bofbot[.]com and my-odin[.]com are both assigned to ‘ProManaged LLC’, an entity which provides dedicated hosting, DDoS-protection, etc. ProManaged LLC was previously associated with malicious hosting provision. Aside from the activity surrounding the management IP, we have observed some interesting connections to the my-odin[.]com website via six VPN gateways, with activity commencing in November 2022. All six gateways are linked to ‘Hola[.]org’. Figure 6: Hola VPN Connections The static nature of these connections may be indicative of a particular operator / customer accessing the site via Hola VPN, or potentially a more widely shared methodology aimed at providing anonymity to the Vidar users. However, as the true source of the connections cannot be determined, these remain hypotheses at this time. In recent weeks we have also observed some of the VPN connections being replaced by traffic from the Tor network. What’s Inside the Archive? As previously mentioned, the archive utilized by Vidar customers to initiate their campaigns is named ‘Vida.tar.bz2’. This archive contains all the server files needed to run the necessary configuration. proxy.conf An interesting finding is in the “proxy.conf” file, containing the settings corresponding to the campaign’s proxy setup; with a remote server IP provided as the proxy_pass value. Figure 7: proxy.conf As can be observed in Figure 7, the current proxy_pass IP is 94.231.205.192, and this value appears to be updated frequently; at least for every new version release of Vidar. Prior to the latest Vidar release at the beginning of January 2023, the proxy_pass IP was 194.99.22.147; both recent proxy_pass IPs are assigned to ‘MVPS LTD’. It appears that the Vidar operators have a preference for this particular provider, as the previous my-vidar[.]com domain was also hosted on one of their IPs (185.243.215.136). Based on PDNS data, the most recent domain hosted on 185.243.215.136 is old.my-vidar[.]net, which remains resolvable and hosts the same files as my-odin[.]com; although the files point to the new site. It appears this domain (old.my-vidar[.]net) has been retained as part of the migration process. Examining network telemetry data for the current proxy_pass IP (94.231.205.192) we are able to define the behavior of the infrastructure sitting behind it. Figure 8: Proxy Pass Network Telemetry We can see that the proxy_pass IP is used to route traffic to TCP/80 on 185.173.93.98 (ADMAN-AS, RU), an IP which also receives inbound connections from two further IPs assigned to ‘ProManaged LLC’. From 185.173.93.98 we also observe a point-to-point connection with 5.252.179.201 (MivoCloud SRL, RU), using the GRE protocol. In turn, we observe 5.252.179.201 in communication with several Vidar C2s on remote port TCP/80, as well as receiving inbound communications from the initial Vidar management IP (Figure 5), and a number of IPs identified as Tor nodes / relays. Historic PDNS data for 5.252.179.201 shows it hosting new.my-vidar[.]net and new.my-odin[.]com until 24 December 2022. The observed SSL certificate hosted on 5.252.179.201 was also, for a short period of time, hosted on a second IP address. Figure 9: 5.252.179.201 SSL Certificate The second IP (5.252.176.64) currently hosts the domain new.my-odin[.]com. We assess that this server may be used in the future by the Vidar operators, but for now traffic remains minimal. proxy.conf Continued Aside from the proxy_pass IP address, another interesting detail in this file provides intel for the retrieval of malware configuration information, as well as also for potential hunting opportunities. Usually when requesting a Vidar C2 a 403 error is returned; as an unauthorized request for a resource. However, from the proxy.conf file (Figure 7) we can see that access will be granted when using an empty User-Agent; based on the line “if ($http_user_agent != "") { return 403; }”. Figure 10: Vidar Configuration Extraction Example In the example above, we were able to extract the configuration for a recent Vidar C2 (65.109.190.87) by using this methodology. As mentioned previously, Vidar allows for customer interaction with its configuration, so in the past few days when requesting this particular C2, we have obtained various different configurations: 1,1,1,1,1,41c46b16f0a37f117ca48ec104248136,1,0,1,0,0,Default;%DOCUMENTS%\;*.txt;50;true;movies:music:mp3:exe; 1,1,1,1,1,c519931eb60ec791d08d29432098c4a8,1,1,1,1,0,Default;%DOCUMENTS%\;*.txt;900;true;movies:music:mp3:exe;Recent;%RECENT%\;*.txt;800;false;movies:music:mp3:exe;Crypto;%DESKTOP%\;*.txt;1000;false;movies:music:mp3:exe;User;%USERPROFILE%\;*.txt;1000;false;movies:music:mp3:exe;Appdata;%APPDATA%\;*.txt;1000;false;movies:music:mp3:exe 1,1,1,1,1,d0d81123a4d0eece79fc6f8c465db7c8,1,1,1,1,0,decuments;%DOCUMENTS%\;*.txt:*.doc:*.docx:*.rtf:*.xls:*.xlsx;300;false;movies:music:mp3:exe;DESKTOP;%DESKTOP%\;*.txt:*.doc:*.docx:*.rtf:*.xls:*.xlsx;300;false;movies:music:mp3:exe 1,1,1,1,0,9fe632d67af2e40151f7e9fafe7a08fb,1,1,1,0,0,Default;%DOCUMENTS%\;*.txt;50;true;movies:music:mp3:exe; These configurations provide an insight into the evolution of a campaign, in the first example the malware is directed to grab .txt files located in directories containing the string DOCUMENTS with a maximum file size of 50kb. In the second and third example further profiles have been added to grab additional file types in several different directories. Vidar Payload Updates Since the beginning of 2023, three Vidar version updates have been released, mostly recently on 13 January 2023 with the release of version 2.0 (following versions 1.9 and 1.8). Vidar version 1.8 re-introduced the form-grabbing feature for the Opera Crypto browser, as well as the collection of Opera Crypto wallet data. Figure 11: Targeting of Opera Crypto These updates were first observed in the wild in use by the DJVU ransomware operators (within botnet 19). In the campaign observed by Team Cymru’s S2 Research team, two domains were utilized for the staging of DJVU ransomware (spaceris[.]com) and Vidar (uaery[.]top). Figure 12: DJVU Ransomware Campaign Since 16 January 2023, the Vidar crew has published a new payload upgrade, which now leads to the 2.1 version. Once again, this was first observed in use during a DJVU campaign, involving the same C2 domains as previously; spaceris[.]com and uaery[.]top. In addition to DJVU, we have also observed the most recent versions of Vidar being deployed alongside other payloads, such as IcedID and Redline Stealer. Conclusion Since August 2022, we have observed the Vidar operators updating and expanding their infrastructure, seemingly preparing for a future influx of customers. Based on recent updates, including the re-introduction of the form-grabbing functionality for the Opera Crypto browser, and improvements in security with proxies being rotated more frequently, it is apparent that the Vidar operators are listening to their current customers at the same time as seeking new ones. By analyzing the network telemetry data surrounding the Vidar website, we are able to discern how both operators and customers access the Vidar management infrastructure, with some further indications of how other elements of the operation fall into play; for example the traffic to Mega and Telegram infrastructure. By examining the proxy_pass infrastructure we were also able to ascertain how data may be transferred from C2 servers back to the central management infrastructure. Overall, we assess that the Vidar operation is becoming more competent and we would expect to see the rate of update releases and infrastructure adjustments to continue during 2023. We will continue to monitor this threat, to assess any reactions to this publication and to share any subsequent updates or changes in TTPs with the community. For day to day updates on Vidar and other threats, you can follow us on Twitter or Mastodon. IOCs Recommendations For Recon customers, add 94.231.205.192 and 194.99.22.147 to a query, filtering on port TCP/80. In addition, monitoring recent Vidar C2s reported on Threatfox and looking for traffic on port TCP/80 would also be a good thing to do. For BARS customers, watch out for Vidar controller and victim information appearing in your feeds in the near future.

Deriving Threat Actor TTPs from Management Infrastructure Tracking You can find our previous work on Stage 1 and Stage 2 of IcedID’s initial infection chain in our Dragons News Blog. Data on Stage 1 C2 infrastructure is now also shared as part of our Botnet Analysis and Reporting Service (BARS). As part of our ongoing tracking of IcedID / BokBot, we wanted to share some insights derived from infrastructure associated with IcedID’s BackConnect (BC) protocol. When deployed post “initial” compromise, the BC protocol allows the threat actor(s) additional functionality, using the infected host as a proxy. Amongst other things, the BC protocol contains a VNC module, providing the malware operator(s) with a remote-access channel which can be brokered for profit. For a comprehensive description of the BC protocol, we recommend this blog by Netresec. Furthermore, we must credit @malware_traffic having drawn upon his collection of threat actor telemetry data to confirm some of the observations shared in this post. Key Findings Eleven BC C2s identified since 01 July 2022, managed via two VPN nodes. Operators likely located in Moldova and Ukraine managing distinct elements of the BC protocol. Evidence of malicious use of the SpaceX Starlink network identified. Exposure of several tools and processes utilized by the operators, including temporary SMS messaging, file sharing, cryptocurrency wallets, and a favorite local radio station. Starting Point - 51.89.201.236 The starting point for our analysis is derived from the two sources mentioned above; although not a new phenomenon, reporting on the BC protocol is fairly scarce, with the last major point of reference, prior to the most recent coverage, being made in May 2020. In early October 2022, an IOC (51.89.201.236:8080) derived from an IcedID infection was identified by @malware_traffic. The IOC was later attributed as a C2 server for the BC protocol by Netresec, noting a change in the auth value (0x08088b1f) used by the bot and C2 server for verification purposes. Figure 1: https://twitter.com/netresec/status/1577966512459087874 With an active C2 server for the BC protocol identified, our first step was to examine our network telemetry data surrounding this IP address, looking for indications of management access, common peers, and subsequent similar patterns of activity, e.g., evidence of victim communications over TCP/8080. Figure 2: Initial Data Pivots Over time, by repeating this process it was possible to identify two long standing management IP addresses, which were observed in communication with 11 distinct BC C2 servers (including 51.89.201.236) since 01 July 2022. Figure 3: C2 Server Timeline (Based on Management Traffic) Based on the data behind Figure 3, we can state that the average life cycle for a BC C2 server, based on first and last observations of management traffic, is approximately four weeks and that there are generally one or two servers active at any given time. Additionally, in all cases communications between the C2 and management servers commenced and ceased on a Monday to Friday schedule - indicating a degree of “professionalism” to the operation and a point which became a trend during this analysis. Auth Value Changes Returning to the aforementioned auth value (0x08088b1f), based on our investigations, the campaigns involving 51.89.201.236 are the first time the “new” auth value was observed. However, this finding is caveated with the fact that relevant PCAP data was not available for the two preceding C2 IPs - 135.125.242.223 and 198.244.187.242. All prior C2s used the “previous” auth value (0x974f014a), which was associated with IcedID dating back a number of years. The change in auth value therefore likely happened at some point between 30 August and 22 September 2022. Figure 4: Auth Value for 135.181.175.108 (Last Active 30 August 2022) Management Insights The remainder of this blog will focus on the two management IP addresses which have been associated with the operation of the BC protocol for at least half a year. These IPs consistently connect to the BC C2 servers on the same two (separate) static ports, one which hosts a VNC service and the second which we hypothesize is associated with the SOCKS proxy module. Figure 5: BackConnect Management Setting the BC protocol management communications to one side, examining the rest of the data available for these two IP addresses provides an insight into the threat actor(s) operation, with some hints at attribution. VNC Management The first observation with the VNC Management is that it appears to be a VPN node. When examining inbound connections, a large proportion take place on UDP/1194, a port commonly associated with OpenVPN as the service’s default port. The VNC Management IP is therefore most likely used for routing traffic / providing anonymisation to the operator(s) and may not host any digital artifacts. On the other side of the OpenVPN connections are numerous Moldovan IPs, the vast majority of which are assigned to a large residential broadband provider. In the 30-day period prior to the time of writing this report, 31 distinct Moldovan IPs were observed connecting to the VNC Management IP. Interestingly, the communications do not overlap, pointing towards a single user / access point. Our hypothesis in this case is that the operator(s) of VNC Management IP are employing some operational security measures whilst operating from / via a residential access point. The data available points to an end user frequently rebooting their router in order to refresh their public IP address. Turning to outbound connections, a number of observations can be made, indicating potential operator TTPs. Firstly, regular traffic to TeamViewer infrastructure was observed, indicating that the software may be installed on the operator’s machine, with usage routed through TeamViewer’s servers. Like VNC, TeamViewer has been used previously by threat actors for remote access management purposes, for example, it is leveraged to gain access to networks and establish persistence in ransomware operations. Secondly, communications with a single Tor relay were observed over an extended period. This particular finding may be indicative of a single operator accessing the Tor network via the VNC Management IP. By default, the Tor browser utilizes a small pool of Guard relays, which is refreshed approximately every 60 days. Ongoing communications with a single Tor relay is therefore indicative of an end user accessing Tor via the Tor browser. As each instance of the Tor browser has its own set of Guard relays, multiple users accessing the Tor network via the same VPN access point would result in the observation of connections to multiple Tor relays. Figure 6: Communications with Tor Relay By examining the timeline of activity involving communications with this particular Tor relay, we can see that it was likely associated with the operator until 3 December 2022, when the Guard pool likely reset. Since this date we have not observed any further connections to Tor relays; likely as a result of a coverage gap. The majority of the Tor activity fits to a Monday to Friday schedule, although there were some days where access took place over the weekend. Most notably on 5 and 6 November 2022, following a spike in activity on 3 November 2022. This activity coincided with a resurgence of Emotet activity, which included a new version of IcedID being dropped alongside it. The spike is therefore a possible indicator of collusion between the operators of Emotet and IcedID. Aside from Tor, connections were also observed to IPs assigned to Telegram, indicating likely use of Telegram messenger. This finding is not particularly exciting (Telegram is used widely), but serves to highlight the overall TTPs of the VNC Management IP operators. More interestingly, traffic to onlinesim[.]ru caught our attention. This website appears to provide temporary ‘virtual’ numbers to be used for sending / receiving SMS messages. By virtue of the fact that this domain was accessed via the same infrastructure as is used to manage the BC C2s, it can be inferred that these temporary numbers serve a purpose in the overall process; although the exact use-case is currently unknown. Another indicator for operator attribution came in the form of connections to an API for a local radio station based in Chelyabinsk, Central Russia. We have two hypotheses for this activity, a) the API is embedded in another website and is pulling data from the radio station in Chelyabinsk, or b) the operator has some ties to that particular region of Russia; an expat living in Moldova? Finally, we observed RDP connections to a set of IPs that share a distinct machine name, however it is unclear what the purpose of these connections are beyond the obvious use of the RDP protocol. Figure 7: Summary of Activity - VNC Management IP SOCKS Management Intriguingly, although the SOCKS Management IP serves a similar purpose to the VNC Management IP, there are variations in both how this is accomplished and by whom. Like the VNC Management IP, the SOCKS Management IP appears to be a VPN node, masking the true location of the operator(s), used to funnel not only BC protocol-related communications, but also other (mostly) connected activities. Inbound traffic to the SOCKS Management IP is observed over UDP/51820, the default port for the open-source WireGuard VPN service. Noting the similar use of an (albeit different) open-source, and likely private, VPN service. On the other end of these communications are a handful of IPs assigned to providers in Ukraine. Most significantly, several of these IPs are attributable to ‘SpaceX Starlink’ infrastructure provided to Ukraine to help maintain Internet connectivity since the commencement of Russia’s “special operation” / illegal invasion in February 2022. It is possible that this is the first example of the Starlink infrastructure being used by cyber criminals. Beyond the Ukrainian IPs, in this case it is difficult to attribute the management activity more specifically; as the infrastructure is likely utilized by tens, or even hundreds of users at any given time. Figure 8: Inbound and Outbound Activity - SOCKS Management IP Looking at outbound connections from the SOCKS Management IP, there is similar use of Tor and Telegram. Although, in the case of Tor, this may be more indicative of some form of automated or hidden service-related activity as communications with numerous Tor relays were observed. This is in comparison with the VNC Management IP which appeared to only communicate with the one Tor relay; matching more closely the ‘expected’ behavior of an individual using the Tor browser. Additionally, a large volume of connections, both inbound and outbound, over TCP and UDP/33445 were observed, generally associated with Tox messenger. Tox has been utilized by cyber criminals in the past, including for C2 purposes. The default port for Tox is UDP/33445, however mobile connections default to TCP - it is therefore possible that the operator(s) of the SOCKS Management IP are using it to access Tox on both desktop and mobile. In much the same way as the BC C2s have a life cycle of around four weeks, the SOCKS Management IP also communicates with cloud infrastructure (accessed via SSH) with the cloud peer IP changing over time. However, it was noted that all of the cloud IPs displayed the same unique SSH Server Host Key, indicating a likely consistent setup. Finally, looking at outbound web-browsing activity (TCP/80 and TCP/443), the SOCKS Management IP is used to access IP addresses associated with Gofile (file sharing), ProtonMail, Trezor (cryptocurrency wallet), and a not insignificant number of pornographic sites (someone in IcedID senior management needs to crack down on adherence to the Acceptable Use Policy!). Figure 9: Summary of Activity - SOCKS Management IP Conclusion This blog serves two purposes, the first is to highlight our tracking of BC C2 infrastructure, sharing details of C2 servers and the process we undertake behind the scenes in order to identify them. We will continue to share details of new / emerging BC C2 servers via our Twitter account @teamcymru_S2. The second is to provide a snapshot into a ‘day in the life of’ the BC operators, and in doing so, providing wider context on threat actor TTPs. In the case of BC, there appears to be two operators managing the overall process within distinct roles. Much of the activity we observe and have described in this blog occurs during the typical working week (Monday to Friday). Both of these points indicate a degree of ‘professionalism’ in the operation of the BC protocol, and by extension IcedID itself. Evidence of a ‘dispersed’ workforce undertaking specific tasks may also help to explain some of the variations in the TTPs observed. Whilst seemingly using two distinct VPN services, we can see an overall ‘playbook’ in use, i.e., its best practice to use a VPN for purposes of anonymization. The fact that both services are configured with default settings indicate either laziness, attempts to ‘hide within the noise’, or a lack of understanding / appreciation of the tooling in use. We were surprised that beyond the use of a VPN node, very few steps appear to have been taken to cover the operators’ tracks; we think this speaks to a confidence in ‘invincibility’, by operating from regions where law enforcement action is difficult to effect / prioritize. The use of services like ProtonMail, TeamViewer and Telegram is commonly observed within threat actor operator playbooks, and these mainstream tools continue to be used by maliciously motivated individuals. Services like Gofile and onlinesim[.]ru may point to more ‘operator-specific’ TTPs, whilst also highlighting a general use of file sharing and temporary SMS platforms. Finally, by highlighting a number of areas where we still have question marks in our understanding, we hope that we can encourage future collaboration on the BC protocol. We hope that this blog post has been informative and has served to provide confidence in the IOCs which we have previously shared on this subject matter. IOCs BackConnect C2 Servers 135.125.242.223 135.181.175.108 137.74.104.108 176.31.136.226 185.156.172.97 188.40.246.37 198.244.187.242 198.251.84.61 212.114.52.91 51.195.169.87 51.89.201.236

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.

Telemetry Data Suggests 107.173.231.114 Remains an Active IOC Introduction This blog provides a short update on Team Cymru’s ongoing tracking of threat actor groups associated with Iran. PHOSPHORUS is an Iranian threat group known to target organizations in energy, government, and technology sectors based in Europe, the Middle East, the United States, and other countries/regions. In recent reporting, PHOSPHORUS TTPs have included the likely opportunistic targeting of unpatched vulnerable systems, leveraging common exploits such as Log4J and ProxyShell. Reports published in 2022 (for instance by the DFIR Report and Deep Instinct) have highlighted the long-term utilization of a common command and control (C2) server (107.173.231.114 – ColoCrossing, US), believed to be associated with PHOSPHORUS activities. Passive DNS information historically associated 107.173.231.114 with several similarly structured domain names, for example: kcp53.mssync[.]one tcp443.mssync[.]one tcp443.symantecserver[.]co tcp.newdesk[.]top kcp53.newdesk[.]top work.newdesk[.]top tcp443.newdesk[.]top tcp443.aptmirror[.]eu kcp53.aptmirror[.]eu tcp443.msupdate[.]us kcp53.msupdate[.]us Reporting by Secureworks suggested that PHOSPHORUS domains from this attack cluster were, in general, registered with Porkbun, and that some of the domains were also associated with opportunistic ransomware attacks. However, between 30 June 2022 and 06 July 2022, the domains aptmirror[.]eu, msupdate[.]us, and newdesk[.]top (mentioned above) were re-registered with NameSilo. The domains were previously registered with Porkbun. Recent observations relating to 107.173.231.114 On 14 September 2022 a joint Cybersecurity Advisory Alert (AA22-257A) was released highlighting these domains and 107.173.231.114 within the report’s IOC section. Figure 1 – CISA Alert Having noticed the CISA alert, we conducted a review of recent network telemetry data for 107.173.231.114, revealing that exploitation activity involving this IP likely continues. Communications were observed between a South Asian victim and ports TCP/443 and UDP/53 of 107.173.231.114. We assess this was likely an opportunistic compromise, based on the presence of an outdated/unpatched version of Microsoft Exchange running on the victim IP. The activity likely indicates the malware in use relies on a hardcoded IP address vice domain resolution for ongoing C2 communications. The use of binaries with hardcoded IP addresses is a known TTP of the threat actor and was described in the previously mentioned Secureworks report. Secondly, the victim also communicated over the same ports (TCP/443 and UDP/53) with an IP address assigned to Kaspersky. It is possible these connections equate to behavior observed in previous PHOSPHORUS samples, whereby the malware would seek to communicate with legitimate Kaspersky domains. Connections to domains such as kcp53.kaspersky[.]com and tcp443.kaspersky[.]com are potentially a means of masking malicious communications with similarly constructed domains (see the PDNS data for 107.173.231.114 above). Reporting by Deep Instinct, referenced earlier, included these Kaspersky domains and attributed PHOSPHORUS malware with generating many connections to legitimate companies along with connections to attacker-controlled domains to confuse a network defender into categorizing the traffic as authentic traffic. It is worth noting that the Kaspersky IP hosted both kcp53.kaspersky[.]com and tcp443.kaspersky[.]com, as well as other domains, at the time these connections were observed. Thirdly, the victim also communicated with TCP/443 of an IP address assigned to Cloudflare. At the time of these connections, the Cloudflare IP hosted numerous domains including api.myip[.]com. As noted in the previously referenced DFIR Report research, PHOSPHORUS malware was observed resolving the domain api.myip[.]com in the past. It is therefore possible that these connections are indicative of similar behavior – a step likely undertaken by the attackers to enrich their understanding of the victim host. A diagram of the network activity documented above is provided below. Figure 2: Network Telemetry Mapping of Victim Communications In addition to the South Asian victim, potential victims in Africa and the Middle East were also observed communicating with both 107.173.231.114 and the Kaspersky IP over ports TCP/443 and UDP/53. Communications with 107.173.231.114 continued as of 29 November 2022. Recommendations If you are concerned about assets that could be vulnerable to Log4J and ProxyShell, Team Cymru are offering a free external attack surface assessment as part of our Pure Signal Orbit evaluation experience, you can find the sign up page here. For customers of Pure Signal Recon, add 107.173.231.114 to a query, filtering for ports TCP/443 and UDP/53.