Search Results

Exposing links to Kharkiv (Ukraine) and the CC2BTC Marketplace Introduction Team Cymru’s S2 Research Team has blogged previously on the initial Raccoon stealer command and control methodology (Raccoon Stealer - An Insight into Victim “Gates”), which utilized “gate” IP addresses to proxy victim traffic / data to static threat actor-controlled infrastructure. Since the publication of our previous blog, the following timeline of events has occurred: 1. Raccoon Stealer version one (V1) ceased operations in late March 2022, citing the loss of a developer during the Russian invasion of Ukraine. Figure 1 - Suspension of Raccoon Stealer V1 2. Raccoon Stealer re-emerged with version two (V2) in early June 2022. 3. The US Department of Justice unseals the indictment of Mark Sokolovsky, for crimes related to the operation of Raccoon Stealer (V1), on 25 October 2022. Following the unsealed indictment, we wanted to share additional insights from our long-term tracking of Raccoon Stealer V1 operations, which were previously shared with law enforcement and industry partners. While our previous blog post focused on victim-facing infrastructure, this post will highlight aspects of upstream infrastructure and management of Raccoon Server V1 and its associated services. Note, from this point onwards we will refer to Raccoon Stealer V1 simply as Raccoon. Key Findings Key elements of the Raccoon infrastructure identified, including the likely location of victim data storage, a Tor .onion control panel, and a Telegram update server. Providing a snapshot into threat actor TTPs with regards to ‘internal’ architecture. Pivoting from these key elements identified threat actor infrastructure located in Kharkiv, Ukraine, likely used to operate the service (MaaS). Attribution of the CC2BTC marketplace to the Raccoon operators, a business model which allowed the threat actors to profit twice from the theft of victim data. Starting at the “Gate” To paraphrase our previous blog: At the time of execution, Raccoon samples retrieve the URL of the active “gate” from a Telegram channel unique to the “customer”. The URL is stored in an encrypted string located in the public description of the Telegram channel. The full decryption process has been covered verbosely by other vendors, and therefore it is unnecessary to repeat it here. Though each “customer” had their own Telegram channel, our research found that the “gate” URL, once decrypted, was common across all samples at any particular time, indicating this detail was updated centrally. The initial infection traffic, where Raccoon checked-in for the first time with the C2 server, therefore appeared as follows: Figure 2: Initial Infection Traffic By examining common upstream peers of the Raccoon “gate” IPs over time, we were able to identify two key hosts involved in these C2 communications (Step 3 in Figure 2). Both IP addresses were assigned to an Italian VPS provider and, with a small number of exceptions, remained static up to the point the Raccoon infrastructure was dismantled. Note, all threat actor-controlled IP addresses have been redacted from this blog post and are instead replaced with descriptive names. Researchers requiring sight of these IPs should contact outreach@cymru.com for further information. Figure 3: Raccoon C2 Infrastructure The Italian IPs both communicated with an IP address assigned to a Dutch provider (C2 Proxy), which appeared to manage the proxying of data between the two, specifically from C2 Server B to C2 Server A. It was noted throughout the threat actors’ infrastructure that communications would alternate between hosts assigned to either the Dutch or Italian VPS provider (the same two providers were used in all cases). We assess this was likely a mechanism intended to cover / disguise activities, whereby one VPS provider would not have the complete picture without the other. We also observed communications originating from a second IP address assigned to the Dutch provider (Raccoon Core Server), connecting to C2 Server A on TCP/443. It is our assessment that this IP hosted the core Raccoon server, where much of the victim data was likely stored. Passive DNS data for Raccoon Core Server showed it hosting a domain containing the string “enot”. “Enot” is the romanized version of the Russian / Ukrainian word for Raccoon (“енот / єнот”). Tor Control Panel One of the “selling points” of Raccoon was the provision of a control panel for its customers, accessible over the Tor network as a .onion site. The control panel was most recently hosted at: dq7shlx5o67t64ljuzisyp34s3n7vepnhc5ijt5hjh433qzaatyj5bid[.]onion Figure 4: Login Page for the Raccoon Control Panel When assessing inbound connections to the Raccoon Core Server, we observed a high volume of communications originating from Possible Tor Host (assigned to the Italian VPS provider), an IP which in turn exchanged a large number of communications with known Tor relays; based on available Consensus data at the time of analysis. Figure 5: Communications with Raccoon Core Server Our hypothesis is that Possible Tor Host hosted the back-end infrastructure for the Tor .onion site, which Raccoon “customers” used to access / manage stolen data stored on the Raccoon Core Server, and to provide further updates to victim machines back through the infrastructure described in Figure 3. Telegram Updates Another element of Raccoon’s core functionality, as already described above, was the use of Telegram channels - which we believe were updated centrally. Whilst building out infrastructure communicating with key elements of the threat actors’ operation, and also hosted on IPs assigned to the Dutch and Italian VPS providers, we identified a candidate for the Telegram update server. Telegram Update Server was observed in regular communications with IPs overtly assigned to Telegram, generally coinciding with when “gate” IPs were updated in the Raccoon campaigns we were tracking. In addition, Telegram Update Server received regular inbound connections from a number of Cloudflare IPs, potentially indicating a clearweb service hosted on this IP behind Cloudflare’s infrastructure. Passive DNS data for Telegram Update Server showed it hosting a domain containing the string “raccoon-core” as of late 2019. Figure 6: Infrastructure Overview Telegram Update Server also communicated with Possible Tor Host, believed to host the Tor .onion site referenced above, via an intermediary (XMPP Proxy). Open ports information, particularly relating to the use of TCP/4443 in these communications, indicated the use of a XMPP file transfer protocol. It is possible these communications were indicative of a “closing of the loop” between the Telegram channel updates and the information presented to the Raccoon “customers” in the .onion control panel. Management Leads to Kharkiv, Ukraine With several key elements of infrastructure identified, we began to look for IPs outside of the network which might be used for management purposes, i.e., connecting into the Dutch and Italian hosts. Fortunately, like many aspects of the Raccoon infrastructure, the external management IPs remained consistently static. From 2021 onwards, we observed the same two IP addresses connecting to several key hosts, including the Tor .onion site and Telegram update servers, on TCP/22 (SSH). WHOIS information for both IPs pointed to a Ukrainian ISP called TRIOLAN (AS13188), and in particular to the company’s Kharkiv infrastructure. Figure 7: Management IP WHOIS Information Based on the available information, TRIOLAN appears to be a provider of home / small office broadband services - indicating to us that these may in fact be the ultimate source of the threat actors’ Internet access. Where Else Does the Management Lead Us? Having identified the threat actors’ management IPs, we decided to look in more detail at the other IP addresses they were accessing via SSH (TCP/22). One such IP quickly became very intriguing to us. Figure 8: Is this a Marketplace? Possible Marketplace, assigned to the same Italian VPS as referenced previously, received inbound management connections from both Ukrainian IPs. Additionally, it made outbound connections to two cryptocurrency platforms and a number of Tor relays. Our initial thoughts were that this IP address was connected to the operation of a marketplace or payment service. In October 2021 we hit gold. We began to observe outbound connections from Possible Marketplace to an IP assigned to a Lithuanian VPS provider (NFS Server) on TCP/2049. Port 2049 is commonly associated with Network File System (NFS), a file system protocol from the prehistoric age of the Internet. NFS is generally deployed within networks and is used to mount exported shares on remote servers - enabling users to access data as if it were stored locally, but without the hard disk constraints. Using NFS across the Internet is NOT advisable in 2022 (or in this case also 2021). But in this case, this is exactly what the threat actors were doing. Internet scan data for NFS Server listed its exported shares, and from which IP addresses in particular they were accessible from. Note, we did not seek to access any of the data stored on NFS Server and therefore cannot comment on its contents. Figure 9: Shares Mounted on NFS Server A few things in Figure 9 stood out to us: The first share, entitled “rst” mapped to Raccoon Core Server - the IP identified above (Figure 3) as the likely Raccoon core server. The likelihood that “rst” = Raccoon stealer. The second share, entitled “cbtc” mapped to Possible Marketplace (Figure 8). Based on our initial assessments of Possible Marketplace, we began to look at candidate underground economy marketplaces for potential matches with the string “cbtc”. CC2BTC Marketplace Our search led us to CC2BTC, a marketplace intended specifically for trade of stolen credit card information; handily one of the key targets of Raccoon. Figure 10: Advertisement for CC2BTC Reviewing the advertisements for CC2BTC, it appeared that the business model was to charge “customers” to access the marketplace, limiting the number of credit card details they could purchase per day based on their membership tier; Aluminum, Bronze, Silver, Gold, or Platinum. A post from May 2020 identified the cost of each tier - although it is not clear if this was a one-off payment or a subscription. Figure 11: CC2BTC Membership Tiers We were also able to identify a Telegram channel utilized by the operators of CC2BTC to update “customers” on a daily basis, and often several times per day, on the latest “merchandise” available for purchase. Figure 12: Example of the CC2BTC Telegram Updates In Figure 12, credit cards from Canada, the United States, Singapore, the United Kingdom, and Brazil (in order of appearance) were offered for sale on 2 February 2022. At this stage, the idea that “cbtc” = CC2BTC seemed plausible, however the following series of events in March 2022 helped us to solidify this assessment. Firstly, on 20 March 2022, the “last” update was made to the CC2BTC Telegram channel. Figure 13: Final Update in the CC2BTC Telegram Channel Secondly, around 25 March 2022, users of CC2BTC begin to realize something had “gone wrong”, discussing this fact in other underground forums. Figure 14: Concern is Raised About the Fate of CC2BTC It was around this time that CC2BTC disappeared completely, with no response to any of their concerned customers. By the end of March 2022, the user “cc2btc” was banned from one carding forum, and the CC2BTC logo removed as a ‘sponsor’ from another. Figure 15: User ‘cc2btc’ Banned from Carding Forum Without wanting to state the obvious, the disappearance of CC2BTC coincided completely with the cessation of Raccoon operations. Conclusion Based on our assessment that the operators of Raccoon and CC2BTC are one and the same, it appears that they had established a savvy business model prior to the disappearance of both services. By firstly charging “customers” of Raccoon for access to their malware, which was subsequently used by those customers to steal victim data, and secondly charging “customers” of CC2BTC access to their marketplace to, in theory, purchase credit card information stolen via Raccoon deployments, they were in effect able to profit twice from the same data theft. Figure 16: Hypothetical Business Model We hope that in sharing these findings that we have provided another snapshot into the ‘business world’ of cyber-crime, providing additional considerations to investigators when assessing the extent and impacts of data theft over the Internet. The news of an arrest in the case of Raccoon demonstrates that offenders can and will face justice.

How Team Cymru products help you discover and manage the impact and risk On November 1st, 2022, version 3.0.7 of OpenSSL was released to patch a high vulnerability, at the time of writing it was as yet undisclosed. Vulnerability Description Published as X.509 Email Address 4-byte Buffer Overflow with accompanying CVE-2022-3602 and CVE-2022-3786, this vulnerability allows an attacker to craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. Vulnerability Impact The specific CVE-2022-3602 vulnerability, if exploited, could result in a crash (causing a denial of service) and/or remote code execution. What is being advised? Upgrading to OpenSSL 3.0.7 as soon as possible is being advised for users of OpenSSL 3.0.0 - 3.0.6. How to assess risk using Team Cymru products Team Cymru has two products that enable organisations to assess and quantify this vulnerability, and measure risk to both their own, and third parties. Starting with Pure Signal Orbit, our Attack Surface Management platform. With a combination of Asset Management, Vulnerability Management, Business Risks and Threat Intelligence, it is the most fully featured product on the market that finds assets, reveals vulnerabilities and alerts to threats at unmatched speed and scale. This puts you at a distinct advantage when facing celebrity vulnerabilities and reacting to alerts of high or critical patches. Assessing the Attack Surface & External Digital Assets for OpenSSL 3.x Vulnerabilities How to use Pure Signal Orbit to find impact assets and quantify impact of the Open SSL 3.0.7. After logging in, go to Vulnerability Management, then follow these two alternative steps: From the Pure Signal Orbit Dashboard Move your cursor to the bottom right of the dashboard as shown below, and click on the box that highlights OpenSSL Less Than 3.0.7 Critical Vulnerability. Figure 1 - where to find the Vulnerability alerts in the Orbit dashboard You will see this box in the lower right corner of the Pure Signal Orbit Dashboard. Figure 2 - the OpenSSL v3.0 Vulnerability alert in the Orbit dashboard You will then see a list of impacted assets, where you can click through as see specifics such as Environment, Business Risk score, any other Vulnerabilities that may be present, in addition to our helpful response guides. From the Vulnerability Management view Log in to your Pure Signal Orbit dashboard and select ‘Vulnerabilities’, and then select ‘Vulnerability Types’ shown below. In the search box shown below, type the following: “OpenSSL” or “CVE-2022-3786” or “CVE-2022-3602” (not currently live in this view yet) Figure 3 - where to find the the search tool within the Orbit dashboard You will now be presented with the list of assets impacted by Open SSL Critical Vulnerability, and can take action in order of priority using our integrated Total Asset Risk score that combines CVE weightings in addition to Business Risk scores. Threat Reconnaissance technique for assessing potential OpenSSL risk from vulnerable third parties Pure Signal Recon is our analysts portal into the world’s largest data ocean designed specifically for Threat Intelligence. By ingesting over 200bn daily internet connections, Pure Signal data is unmatched in size and scale to gain visibility into third party risks, and very effective at making discoveries when vulnerabilities are announced.. How to use Pure Signal Recon to find impact assets and quantify impact of the Open SSL 3.0.7. After logging in, run a Query, include the following: Specify your timeframe - i.e. previous 7 days Specify the IP addresses or ranges of IP’s of interest There are 2 primary data sets that will contain this information - “Open Ports” and “NMAP Open Ports” Use the post query filters and search for “OpenSSL/3” to identify any vulnerable versions of OpenSSL You can apply the following variations: Post Filter: Data = “OpenSSL/3” Post Filter: Version = “OpenSSL/3” Results will be returned within the confines of the argument and any further filters you have applied. Figure 4 - Sample results from running an OpenSSL v3.0 query from within the Recon dashboard We hope both these examples for discovering OpenSSL v3.0 vulnerabilities across Pure Signal Orbit and Recon are useful. If you have any questions or queries we have a range of options to get you in front of our experts quickly. For Orbit, please visit our product page or request your free evaluation here For Recon, please visit our product page or contact our Sales Team directly here

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

An overview of a bulletproof hosting provider named ELITETEAM. Introduction: What is “Bulletproof Hosting” (BPH)? Bulletproof hosting (BPH) is a type of service offered by hosting providers that allows operators unrestricted and unregulated use of their paid infrastructure. Usually, these providers ignore abuse complaints, giving threat actors an ideal platform to conduct various malicious activities. BPH providers prefer to operate in jurisdictions that have lenient laws against such conduct. Due to the different laws in different countries, this creates a significant gray area that allows BPH providers to claim immunity to what their customers (threat actors) host. In addition to malicious activities, some of the other services enabled / hosted by BPH providers include online gambling, the sharing of copyrighted materials, misinformation, etc. A number of online monikers are associated with individuals involved in the provision of BPH services, and include; Yalishanda, BraZZZerS, MoreneHost, and Vicetemple. Executive Summary ELITETEAM, a bulletproof hosting provider registered in the Republic of Seychelles, is associated with multiple malicious campaigns. Multiple distinct clusters of threat activity were noted, operating from IP addresses within a netblock associated with ELITETEAM. Each threat cluster had seemingly different “goals”, from directly stealing banking information to deploying ransomware and crypto miners. With a diverse range of targets, and notable differences in attacker TTPs. Evidence was identified, based on AS announcements, linking ELITETEAM to another known Russian bulletproof hosting provider. ELITETEAM Netblock Summary ELITETEAM owns four different ASNs as “1337TEAM LIMITED”: AS39770, AS60424, AS56873, and AS51381, but mainly operates from AS51381, which is associated with netblock 185.215.113.0/24. Looking at the WHOIS data related to this netblock, an address in Seychelles is provided: Figure 1: ELITETEAM WHOIS Data The address “Global Gateway 8, Rue de la Perle office “1337TEAM LIMITED”, Seychelles” was previously disclosed in documents commonly referred to as the Panama Papers and Offshore Leaks, indicating that ELITETEAM may use Seychelles as a front for their operations, whilst controlling them from another location. Infrastructure Summary The identified malicious infrastructure, hosted via ELITETEAM and discussed in this blog post, is divided into three different clusters, as follows: Cluster 1: Malvertising and info-stealing Cluster 2: Phishing Cluster 3: Skimming Cluster 1 The first cluster, and currently the most active one, was previously observed (since December 2020), targeting victims through exploitation of the Log4Shell (CVE-2021-44228) vulnerability. However, since around February 2022, we have observed a switch to the use of malvertising campaigns, using ‘fake’ software as a lure, leading to the installation of the Amadey malware on victim machines. Figure 2: Malvertising Campaign Following the initial installation of Amadey, depending on the version number of the malware, (3.08 through to 3.21 was observed in this cluster) one of two payloads are then dropped; Redline stealer, or Smokeloader. It appears the initial goal of the threat actors is the theft of victim information / credentials, however further payloads were also observed being dropped, including Djvu ransomware and crypto miners. During this investigation, we focused our research on five Amadey C2 servers: Figure 3: Amadey C2 Servers Note: For reasons unknown, this cluster hosts multiple different versions of Amadey, all of which are currently in use in attacks. Pivoting on URL strings associated with the Amadey C2 servers (Figure 2), we were able to identify a list of tasks hosted on 185.215.113.92 (Amadey version 3.21). Figure 4: Tasks Hosted on 185.215.113.92 The payloads associated with these tasks appeared to be hosted on a Bitbucket account named ‘USASoftwareDevelopment’. Figure 5: USASoftwareDevelopment Bitbucket Account Analysis of these payloads identify them as Redline stealer executables (botnet: IMHOTEP), which are likely loaded onto victim systems to facilitate data theft and systems reconnaissance. Data from victim systems is then exfiltrated to 185.215.113.217. Note: The number of downloads recorded against each payload provides a further indication to the scale of this activity. Figure 6: Data Exfiltration to 185.215.113.217 Similar findings were also observed for 185.215.113.205, which was not initially identified as an Amadey C2 server. Figure 7: Tasks Hosted on 185.215.113.205 In this case, the payloads were hosted on a different Bitbucket account (‘Alex’), but again all of the samples analyzed were identified as Redline stealer. Of note, data exfiltration for these payloads was to 65.21.133.231 (assigned to AS24940 - Hetzner Online GmbH). Figure 8: Data Exfiltration to 65.21.133.231 Examining threat telemetry for 65.21.133.231:47430, it is apparent that this particular campaign became active on 20 August 2022, and to date has seen at least 500 victims. The observed victims were dispersed globally, with the highest concentrations in Brazil, India, and South Africa, based on IP geo-location data. Finally, a third Bitbucket account (named ‘mrssoprano666’) was identified, again associated with 185.215.113.92. Figure 9: ‘mrssoprano666’ Bitbucket Account In this case, we pay witness to a potential “career” change. We identified a user called ‘mrssoprano666’ on an underground Russian-language forum, offering ‘physical’ services associated with fraudulent activity. These services included answering telephone calls, making calls to victims (posing as a bank or shop), and the rerouting of parcels. Figure 10: Forum Post by ‘mrssoprano666’ Based on the timeline of activity on this forum, it appears that the user ‘mrssoprano666’ disappeared in 2020 (having advertised their services since 2018) before subsequently re-appearing as a cybercrime affiliate this year. Cluster 2 The second cluster is mainly used to conduct phishing campaigns, with a particular focus on the spoofing of investment and cryptocurrency platforms. This cluster is highly active, particularly considering AS51381 only accounts for 256 IP addresses, ranking 8th place in Interisle’s Phishing Landscape 2021 behind much larger ASs. Figure 11: Phishing Landscape 2021 Rankings Three IPs are used to host phishing sites: 185.215.113.100 Observed most recently in a campaign targeting Polish Credit-Agricole users. 185.215.113.201 Used as a Redline Stealer C2 until April 2022 Switched to phishing purposes in June 2022 185.215.113.206 As noted previously, there is a financial flavor to this cluster, in one campaign we observed the targeting of Fidelity customers, in an attempt to steal credentials. Figure 12: Phishing Page Targeting Fidelity Interestingly, there was also a second stage to this attack; usually attackers are simply seeking credentials, but in this case it appears the attackers wanted to double up on the opportunity. Once a user had entered their credentials, they were directed to download a file called ‘Fidelity Protect Services’. This is a completely fictitious product offering from Fidelity, but continues to be a highly convincing part of the scam. Figure 13: Fidelity Protect Services The file (hosted at cv19alert[.]com/fidelityprotect.exe) was not available for download at the time of our investigation. However, a copy was uploaded to Virustotal on 28 June 2022 by a user in the United States (MD5: 4532b0d0ca6330bf73e0d6f76f8cf35b). Analysis of the sample identifies it as a Raccoon Stealer V2 payload, with the timeline aligning with the malware first being spotted in the wild (and initially referred to as RecordBreaker based on User Agent strings). In the first stage, the malware pushes the ‘machineId’ and username to the C2 server, along with the ‘configId’ (RC4 key). Figure 14: Initial POST Request The RC4 key is used to decrypt the location of the C2 server, in this case 104.193.255.48 (AS14576 - HOSTING SOLUTIONS). Figure 15: Decrypted C2 Server Unfortunately the C2 was offline at the time of our investigation, so we were not able to retrieve the full configuration of the malware. Cluster 3 The third cluster is connected to credit and debit card skimming activity, with the earliest observations occurring in November 2021. A campaign associated with this cluster was previously reported on by the Sucuri research team, which noted: Compromise of the victim website, with an attempt to load a malicious JavaScript file. Website visitors met with an unwarranted prompt for credit card information. Spoofing of the legitimate domain ‘api.jquery.com’; the attackers used a similar domain ‘apiujquery[.]com’. C2 server used to serve the secondary payload, allowing for JavaScript injections into pages when certain keywords were triggered, e.g., ‘checkout’, ‘my-account’, ‘order’. C2 server located at 51.178.8.230 (AS16276 - OVH). At some stage after the publication of this blog, the C2 server was moved to 185.215.113.5. Figure 16: Current Campaign C2 Details Based on our threat telemetry for 185.215.113.5, we have observed at least 50 unique victims connecting to the C2 server over the past three months. Reviewing the current campaign, it appears very similar to the one reported on nearly a year ago. The first JavaScript injection payload sends a unique hash to the C2 to register and identify the victim on the admin side. However, some updates to the second stage payload have been noted. Firstly, the ‘triggered words’ list has been updated to include several more keywords. Figure 17: Triggered Words List Secondly, an additional C2 server was identified, hosted on 185.215.113.20. Both the initial and the ‘new’ C2 server share the same SSH Server Host Key value. Figure 18: SSH Server Host Key Match The current IOCs for this campaign are therefore as follows: apiujquery[.]com | 185.215.113.5 C2: http://apiujquery[.]com/ajax/libs/jquery/3.5.1/jquery-3.12.0.min.js?i apigstatic[.]com | 185.215.113.20 C2: https://apigstatic[.]com/ajax/libs/jquery/5.1.7/jquery-7.41.3.min.js?i Big Picture Big Picture - Summary of Infrastructure Zooming out from the clusters already discussed, a significant number of IPs within the 185.215.113.0/24 netblock have been linked to malicious activity in the recent past. With 110~ IPs categorized as malicious within VirusTotal over the past 90 days, and 80~ IPs associated with entries made to ThreatFox within the past year. Figure 19: Malicious Activity Cluster within AS51381 Big Picture - AS Details ELITETEAM have been highlighted in the past by other researchers, identifying them as malicious / BPH providers. To quote Spamhaus in their botnet report from 2021 “[ELITETEAM] is a bulletproof hosting company purporting to be located in Seychelles. In reality, they more than likely operate out of Russia.” In late 2020, when the ASs were first allocated to ELITETEAM, they were initially declared as Russian before being updated to reflect their status as Seychellois, as is the case today. Figure 20: ASN Description Information for AS51381 and AS60424 Digging deeper into the details surrounding the ASs assigned to ELITETEAM, looking at information such as netblock announcements and peering, we were able to establish further ties to Russia. Figure 21: ELITETEAM Peers Indeed, all ASs connected to the ELITETEAM infrastructure are owned by Russian entities: AS3555 | Crex Fex Pex Internet System Solutions LLC | Announcing AS51381 until January 2021 AS203804 | AS Infolika | Peer until February 2021 Details of the above activity have been disclosed previously by Valery Reiss-Marchive when discussing the Egregor ransomware. AS213254 | OOO RAIT TELECOM | Peer until August 2022 AS49612 | DDOS-GUARD LTD | Current peer as of September 2022 AS3175 | Filanco LLC | Owned by Datahouse.ru, another Russian BPH provider for which ELITETEAM is an upstream peer AS213254 (OOO RAIT TELECOM) was seized by US law enforcement (ICE - Homeland Security Investigations) in early September 2022 and is currently no longer visible on the routing table. Figure 22: US Law Enforcement Takedown of AS213254 It is possible that at some stage in the chain the operators were aware of the law enforcement action, as there was a migration observed in August 2022, where for a period both AS213254 and AS49612 were observed as peers for AS51381. Conclusion As outlined throughout this blog, ELITETEAM enables malicious activity on a significant scale, allowing threat actors to operate with impunity against global targets, who in some cases appear to be individuals with surplus funds with which to invest or experiment with digital currencies, and in others just your average Joe Public. We have observed varying campaigns and TTPs, indicating diverse usage of ELITETEAM’s services by threat actors of varying skill sets. It is not often sound advice to say, ”block all connections to a /24”, but in respect of the infrastructure assigned to ELITETEAM, overwhelming evidence compels us to suggest this to be the case. All the data and information we have researched points to ELITETEAM being Russian / Russian-speaking, operating behind a shell organization in Seychelles. We have reason to believe that Datahouse, RU is connected to ELITETEAM and worthy of further investigation. Figure 23: Obi Wan Kenobi Encountering ELITETEAM IOCs Netblock: Amadey C2s on 2022/09/21: Phishing IPs: Phishing domains: Skimmer IPs: Skimmer domains: File sharing websites used to drop payloads: RedLine Stealer payloads: Amadey payloads: Detection mechanisms IDS Rules: MALWARE-CNC Win.Trojan.Redline variant outbound request detected ET DROP Spamhaus DROP Listed Traffic Inbound group 22 ET DROP Spamhaus DROP Listed Traffic Inbound group 21 ET MALWARE Amadey CnC Check-In ET INFO Executable Retrieved With Minimal HTTP Headers - Potential Second Stage Download MALWARE-CNC Win.Trojan.Amadey botnet outbound connection Other Considerations: Monitor external assets and endpoints for connections to the netblock assigned to ELITETEAM, in addition to the phishing and C2 IPs provided above.

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.

Having covered the Sliver C2 framework in a previous post (May 2022), this blog will continue our examination of Cobalt Strike “alternatives”, focusing on the Mythic C2 framework. The rationale for this write-up is based on conversations with red-team operators and our observations of internet-facing Mythic C2 servers over the past three months. Like Sliver, Mythic is a free-to-use, open-source tool. Written predominantly in Python, Mythic provides cross-platform payload creation options (Linux, MacOS, and Windows). With an active development community, and ‘plug-n-play’ functionality for its various (also open-source) agents, the technical entry barrier for users is comparatively low. Mythic is therefore attractive to threat actors of varying skill sets; for the lower-skilled actor the ‘plug-n-play’ capabilities mean they can use the framework and additional agents ‘off-the-shelf’. In the case of higher-skilled actors, the framework’s flexibility for customization might be used to evade detection mechanisms based on ‘known’ fingerprints. Key Findings ● Although dwarfed by Cobalt Strike, the number of online internet-facing Mythic servers outnumbers a number of other ‘common’ C2 frameworks, including Sliver. ● Mythic was observed being deployed alongside reNgine, a powerful reconnaissance tool. ● Connections to an operator identified previously utilizing Sliver, potentially in Pakistan-focused activities. ● Low confidence ties to e-crime operators have been identified within open source reporting. Identification of Mythic Servers Since the first quarter of 2021, the number of online Mythic servers has generally remained static; with 76 servers online at the time of writing - for ease of access we have used data from Shodan for this illustration. Figure 1: Online Mythic Servers Comparing this to other C2 frameworks (including Cobalt Strike), Mythic accounts for about 2% of the current ‘market share’ – interestingly, about 8x more prevalent than Sliver at present. Figure 2: C2 Framework Market Share Whilst 76 servers may seem like a low number, this only accounts for internet-facing infrastructure and likely doesn’t include many of the Mythic instances being used for red team operations within closed / controlled environments. With that being said, Cobalt Strike remains the most prevalent framework in use today. Therefore, the purpose of this blog series is not to suggest defenders divert resources away from the detection of Cobalt Strike as a threat vector, but merely to heighten awareness of emerging and plausible alternatives. Mythic in the Wild? Reviewing the currently online Mythic servers, most of them (90%) fit a ‘default’ profile, with details for the web portal port, SSL certificate, etc. having not been altered from the ‘out-of-the-box’ settings. Default settings: ● Port - 7443 ● SSL certificate - Issuer: O=Mythic In cases where these settings were modified, we have observed cases of re-use, where modified configurations were seemingly copied from box to box over time. In doing this, actors leave behind an attributable trail which makes tracking from C2 server to C2 server possible. For example, by following E-Tag information (present in HTTP headers), we were able to tie multiple Mythic servers together. From this starting point we start to ‘zoom in’ on activities utilizing the Mythic framework, shedding light on some of the use cases. Mythic + reNgine We were able to follow this particular operator for a number of months, based on a recurring E-Tag value. In addition to Mythic, this operator was also observed using a reconnaissance framework called ‘reNgine’. Figure 3: Identified Operator Infrastructure Based on observed certificate information (CN = redteamtools.msfven0m[.]xyz), this infrastructure was likely used by a red team operator to target multiple customer organizations - although the potential for a false flag cannot be ruled out. Figure 4: Certificate for 47.243.104.222 In this case the scenario was quite simple, reNgine was first used to scan port 443 on the victim server, seeking vulnerabilities which would allow initial compromise / exploitation. A Mythic beacon was then dropped on a victim machine for management of the exfiltration stage. As a side note, reNgine is another powerful tool which blue team operators should become familiar with. At the time of writing, approximately 920 online reNgine servers were identifiable. Mythic + Pakistani Focus In our blog on Sliver, we identified a campaign which appeared to target both Pakistan and Turkey, based on the domain names observed. Whilst hunting for Mythic servers, we identified a similar domain ‘rd.mofa-pk[.]org’ - which appears to target the Pakistani Ministry of Foreign Affairs. The domain mofa-pk[.]org was most recently hosted on 3.239.29.103 (assigned to AMAZON-AES), amongst the other domains hosted on this IP are: ● nationalhelpdesk[.]pk ● sngpl.org[.]pk Both of these domains were highlighted in our Sliver blog as being connected to the same activity, as outlined below: Figure 5: Excerpt from the Sliver Blog It would appear that the operator behind this linked infrastructure makes use of a diverse range of C2 frameworks in their activities. Our investigations into this cluster continue. Mythic + Bazarloader / Bazarbackdoor? In June 2022, a researcher shared a new Mythic C2 framework on Twitter with a slightly different web login panel. The default login panel for a Mythic C2 contains the Mythic logo, but in this case, the page contained this “Botleggers Club” image: Figure 5: Source - https://twitter.com/benkow_/status/1542047469860683777 The “Botleggers Club” was mentioned in the Conti Leaks as a panel to manage / administrate and interact with clients (the bots), and also to deliver malware (BazarLoader / BazarBackdoor). By pivoting on E-Tag values once again, a number of IP addresses were identified, sharing the same details as the Mythic C2 mentioned above (cryptolvl-rsa-check[.]com): ● 139.59.72.48 ● 147.189.169.143 ● 159.223.193.246 ● 203.28.246.137 ● 34.240.115.152 ● 43.142.60.207 However, after this information (the Tweet) was publicly exposed, the server configurations were modified and now only one of these IPs is displaying the same E-Tag. It is likely that the other servers were either shut down, or moved elsewhere with updated configurations. Conclusion From a technical point of view, Mythic has all of the advantages of Cobalt Strike (or any of the most popular C2 frameworks). Based on the number of commits, issues, and pull requests on GitHub, the community is highly active in contributing to the development of the framework. In other forums, such as Twitter, we also observe researchers sharing their tips and tools for the improvement of Mythic functionality. As noted already, Cobalt Strike remains the most popular C2 framework, but we wouldn’t be surprised to see growth in the use of Mythic in the near future. Indeed for some red team operators, this trend is already occurring - we would expect that malicious actors have taken note and are either considering or have already adopted the use of Mythic into their TTPs. Indicators of Compromise Note - only the most recently active Mythic C2 servers are shared. Domains cisco-update.com corpse.sh idinfosystems.com linux-sec.top live-office365.com mofa-pk.org onerule.digital v56119.php-friends.de IP Addresses 101.35.90.253 103.134.19.126 139.162.8.112 139.59.144.58 139.59.249.255 142.93.166.252 142.93.246.237 159.223.234.22 3.212.113.251 3.96.54.147 46.243.186.22 47.96.177.12 5.2.79.164 54.173.67.191 MITRE ATT&CK Matrix: This MITRE ATT&CK Matrix is a summary of the combined capabilities of every Mythic agent (Apollo, Athena, Tetanus, etc.):

8 Reasons to reassess your ASM strategy In our The State of Attack Surface Management published in May, we surveyed 440 security practitioners in the US and Europe who work on their company’s security team. Each organization surveyed had to use attack surface management, or ASM platform, and these professionals were able to provide first-hand knowledge about the benefits and drawbacks of ASM tools today. This survey is vital reading if you are new to ASM or looking to compare your current experience to see how you measure against other organizations. It’s critical for organizations to have effective solutions that enable security teams to protect their organization from cyber-attack. But are the tools and methods being used appropriate for modern security teams, or are technology gaps leaving organizations vulnerable? We’ve condensed the contents of our survey to eight key takeaways. These high-level insights provide a flavor of what you can find in the complete report and will enable you to assess and potentially evolve your current approach to ASM. Insight No. 1. Shadow IT While freedom and control over their own IT environments may help users across the organization do their jobs more efficiently, it opens unchecked entry points for cybercriminals and is a potential disaster for the company. A growing organization continuously adds elements to its infrastructure without following policies or best practices, and often the security team is the last to know about it. This is why 20% of respondents say their organization implemented ASM to increase their visibility of shadow IT in the enterprise; other surveys have discovered this to be sometimes over 50%. According to 23.4%, identifying rogue or unclassified events is the most valuable capability that ASM has provided their organization. PRO TIP: YOUR ASM TOOL MUST HAVE BOTH CONTINUOUS AND AUTONOMOUS DISCOVERY OF UNKNOWN OR NEW ASSETS AND BE ABLE TO AUTOMATICALLY SCAN FOR VULNERABILITIES TO EXPOSE SHADOW IT RISKS. Insight No. 2. Cloud Migration 16.3% of our respondents say that errors associated with moving more data and assets to the cloud are the primary reason their attack surface is expanding. Illustrating the effect of expanding attack surfaces in the cloud, Verizon’s 2022 Data Breach Investigations Report (DBIR) states that misconfigured cloud storage accounts for 13% of breaches. PRO TIP: YOUR ASM TOOL MUST HAVE INSIGHTS INTO THE APPLICATION LAYER AND TECHNOLOGY STACK ACROSS ANY CLOUD ENVIRONMENT, IN ADDITION TO MAPPING THE UNDERLYING INFRASTRUCTURE TO FULLY REVEAL THE EXTENT OF DEPENDENCIES AND RISKS OF APPROVED AND UNAPPROVED CLOUDAPPS. Insight No. 3. Lack of Integration 14.5% cite the main limitation of existing ASM platforms as their lack of integration with automation platforms. For security teams to gain even more advantages over static reports, they need more integrations. However, legacy ASM tools can be challenging and expensive to update and maintain. As ASM 2.0 tools mature, the industry will undoubtedly benefit from the more time-saving integrations it can provide. PRO TIP: THE MORE CAPABILITIES YOUR ASM TOOL HAS, THE LESS COMPLEX INTEGRATION BECOMES, SAVING TIME, MONEY, AND EFFORT ON STITCHING TOGETHER MULTIPLE TECHNOLOGIES, WORKFLOWS, AND PROCESSES. LOOK FOR ASM PLATFORMS THAT, AS A MINIMUM, INTEGRATE ASSET MANAGEMENT, VULNERABILITIES MANAGEMENT, AND CLOUD INFRASTRUCTURE MANAGEMENT IN ADDITION TO THREAT INTELLIGENCE – IT IS MORE EFFICIENT TO INTEGRATE A SINGLE PLATFORM THAN SEVERAL. Insight No. 4. Required Training When security solutions need an inordinate amount of time dedicated to training before users can effectively do their jobs, they burden already struggling security teams. This is why a plurality of 21.5% indicates that the training needed for analysts to use the platform is their primary challenge with their current ASM platform. PRO TIP: YOUR ASM TOOL NEEDS TO BE MORE THAN FULLY FEATURED; IT MUST HAVE MANY OF THE LABOR-INTENSIVE AND REPETITIVE TASKS AUTOMATED AND RUNNING CONTINUOUSLY – THIS MEANS MORE EMPHASIS ON USING THE PLATFORM, NOT LEARNING THE METHODS. ANOTHER KEY POINT IS THE USER EXPERIENCE. EVALUATE HOW SEAMLESSLY ASM INTEGRATES MULTIPLE COMPETENCIES AND ASSESS HOW EASY TASKS CAN BE DONE. IF ANYTHING LOOKS COMPLEX OR TIME-CONSUMING, MOVE ON. Insight No. 5. Time to Deploy Of our respondents involved in deploying their current ASM solution, 23.2% said it took 6 to 9 months to get them up and running. For 18.5%, it took over a year — a long time to leave their organization vulnerable to unmanaged risks. The time it takes to deploy and implement a new security solution is consequential because it expresses the amount of time the organization continues to go without the protection provided by the improved processes. The frustration created by a new implementation is also a challenge for security teams looking to get up and running quickly and smoothly. PRO TIP; YOUR ASM NEEDS TO HIT THE GROUND RUNNING. ASSESS HOW MANY OF THE FEATURES ARE AUTOMATED AND DON’T REQUIRE TIME OR TRAINING TO ACHIEVE VALUE, IN ADDITION TO FUNCTIONS THAT CAN EASILY BE CONTROLLED, SUCH AS ASSET DISCOVERY AND VULNERABILITIES SCANNING. IF YOU AREN’T GAINING A FRICTIONLESS EXPERIENCE DURING EVALUATION OR PROOF OF CONCEPT, CHANCES ARE YOUR ASM WILL TAKE MONTHS TO INTEGRATE INTO YOUR ENVIRONMENT. Insight No. 6. Security Concerns Integrating a new platform or giving an untested solution broad access across the enterprise will keep a CISO up at night. This is especially worrisome considering that 29.7% of our respondents said their top concerns were about the security aspects of data integration and how much access their current ASM platform had across the enterprise. PRO TIP: ASM IS CURRENTLY A BUOYANT MARKET FOR INVESTORS, BUT THAT ALSO BRINGS RISKS FOR PROCUREMENT. YOUR ASM PROVIDER SHOULD PASS YOUR STANDARD THIRD-PARTY ASSESSMENTS AND ESPECIALLY BE COMPLIANT WITH ISO27001 TO GIVE ASSURANCES THEY TAKE YOUR DATA, SECURITY, AND INTEGRITY SERIOUSLY. AS PART OF THAT ASSESSMENT, CASE STUDIES, PROVENANCE, AND FINANCIAL ASSESSMENTS PROVIDE INSIGHTS TO SEPARATE THE TARGET ACQUISITION START-UPS FROM LESS RISKY, MORE STABLE AND BETTER-ESTABLISHED ORGANIZATIONS. Insight No. 7. Cost Legacy ASM solutions fail to deliver an adequate ROI for modern cloud-based enterprises. Many ASM users did not fully realize the initial benefits promised when they acquired their solution as well. 21.1% of the respondents felt they overpaid for their current ASM solution. Of those who plan to stop working with their ASM vendor in the next 12 months, 21% cite the cost of operation and maintenance. PRO TIP; AS AN ASM BUYER, AUTOMATION IS THE KEY TO LOWERING OPERATIONAL COSTS. PREMIUM SERVICES WILL HAVE A HIGHER INITIAL PURCHASE PRICE, BUT THE RETURNS WILL START ALMOST IMMEDIATELY BECAUSE THEY OFFER WIDER FUNCTIONALITY, HIGH LEVELS OF AUTOMATION, AND ACCURACY. MAKE A POINT TO ENSURE THAT HUMANS ARE ALSO INVOLVED ON THE VENDOR SIDE. THIS IS HUGELY BENEFICIAL AS THE DATA WILL BE MORE ACCURATE, THEREFORE LESS TIME WASTED ON BUDGET AND RESOURCE-DRAINING FALSE POSITIVES. Insight No. 8. Future Plans Most businesses see enough value in their legacy ASM solution to justify using it, but many enterprises recognize they need a better solution. While 51% have no plans to stop working with their ASM vendor in the next 12 months, 27.9% say they plan to terminate their current ASM vendor with no intentions of replacing them. PRO TIP: IT’S CLEAR THAT LEGACY ASM HAS FAILED TO MEET THE MINIMUM EXPECTATIONS OF BUYERS AND USERS. AS A BUYER, YOU NEED TO BE AWARE THAT THE NEXT GENERATION OF ASM PLATFORMS HAVE ALREADY EMERGED, REFERRED TO AS ASM 2.0. THESE NEW GEN PLATFORMS RESOLVE MANY OF THE CHALLENGES CUSTOMERS FACE, SO IT IS VITAL TO ASSESS A NEW OR EXISTING ASM PLATFORM ON THE BASIS Conclusion Our survey results show a widespread and immediate need for change. ASM must help, not hinder, organizations in managing digital asset risks across the entire attack surface. Still, many organizations are so frustrated with their current ASM that they’re considering abandoning it altogether. Our survey reveals legacy ASM tools are challenging to use, expensive to operationalize, and need further integrations to gain fractional advantages over a static report. But abandoning an ASM altogether will send organizations backward, not forwards. The positive news is the future of ASM is already available in the form of ASM 2.0 ASM 2.0 seamlessly blends asset discovery, vulnerability management, cloud application management, threat intelligence, and business risk management – gone are single-function low-value platforms. SOCs gain real-time verified and validated alerts to risks and threats affecting their assets. With ASM 2.0, patching external assets in order of priority can be in lockstep with organizational goals. Additionally, shadow IT challenges are quickly discovered, assessed for impact, and risks addressed with a complete inventory of cloud-based web applications, including the IP addresses they reside on, providing laser focus for any cloud security team. To avoid falling into legacy ASM traps triggered by your peers and to gain deeper insights into how an ASM 2.0 solution can address the deficiencies of your current ASM, download the full report here.

The Wall Street Journal reports that national regulators in EU member states could be given the authority to force financial institutions to drop existing tech suppliers, if they fail to address cybersecurity problems. The WSJ reports that these proposals have not yet been agreed upon by European governments, but – to invoke the immortal internet caveat, I am not a lawyer (nor a diplomat) – how the law will look at the end of that negotiation process is anyone’s guess. While the ultimate shape of this legislation (assuming it ever emerges at all) is unknown, there will probably be yet more variation in its practical implementation from nation to nation. It will be interesting to see, a few years down the road, if these efforts result in marked improvements in the fight against financial crime. As lawmakers around the globe are grappling with the thorny problem of legislating for the digital era, they may be watching what their foreign counterparts are doing, and learning what works (or doesn’t). However, merely proposing these measures could have knock-on effects within the tech industry. As anyone who has ever attempted it will know, switching key technology providers is a headache. One that no business (much less one as large and complex as a bank) will wish to undergo without a compelling reason. The WSJ observes that EU banks may begin reviewing contracts with existing suppliers now. As an extension of that, one might assume that new suppliers could face even tougher scrutiny. So what could this mean for the tech industry? Forward thinking businesses that have (or hope to find) customers among the European financial industry will probably look to get ahead of the curve. Such businesses might seek accreditations for their services, if they do not already hold them. Although it remains to be seen how the details of this regulation will shake out, a respected cyber-security benchmark seems like a reasonable place to start. Looking beyond the finance and tech industries, businesses (of all kinds) have traditionally relied on external suppliers for all sorts of technical goods and services. In recent years, this interdependency has expanded as organizations make the shift to SaaS, IaaS and other flavors of as-a-service. Against this backdrop, supply chain security is a growing concern (regulations or no) and banks are far from being the only ones with an interest in this area. Consequently, we may see an expanding market for supply chain risk assessments. Such assessments can be conducted by internal teams, external consultants, or via a hybrid approach. There are also tools that assist with this. But, whatever the approach, on-demand, accurate information is vital. Many of our clients gain this on-demand ability to check up on the state of their third-party vendors’ security via our Pure Signal cyber reconnaissance solution. It allows them to continuously monitor their supply chains for anomalous traffic and the presence of outdated operating systems and software. It can also help to verify vendors’ claims about their security posture. For example, our clients can see traffic indicators firsthand that give them a better sense of whether an organization’s network is truly a zero-trust environment. Giving their analysts access to this ground truth allows our clients to close serious gaps in their third-party risk assessment processes and their security programs as a whole.

Summary As this research reveals, mapping out adversary infrastructure has distinct advantages that enable a proactive response to future threats. A well resourced team with access to the right tools can monitor changes to adversary infrastructure in real time, discoveries can become strategic advantages when fully exploited. This blog is geared towards the practitioner threat hunters and threat researchers, anyone reading this with the bottomline in mind should take a look at our economic study here first. Introduction We began tracking the threat actor Hagga in late 2021 following the release of an analysis by Z-Lab (Yoroi Security’s malware research team). Z-Lab were tracking a worldwide campaign to distribute the Agent Tesla information stealer through an elusive multi-stage infection process. In their analysis, they shared the IOCs for this campaign, including a single hardcoded IP address (69.174.99.181) and a common URL directory pattern for the identified C2 panels. This blog will describe how we were able to pivot in threat telemetry, using these IOCs as seeds, to identify several other C2s used by this threat actor, ultimately leading us to a backend MySQL server. FIGURE 1: C2 PANEL IOCS Key Observations Hagga infrastructure is hosted on dedicated leased infrastructure, largely on QuadraNet and Vietnam Posts and Telecommunications (VNPT). An HTTPS certificate serves as a key indicator of Hagga C2 panels. 69.174.99.181 (QuadraNet, US) Passive DNS data for 69.174.99.181 identified it hosting the domain (update.)newbotv4[.]monster from 01 November 2021 onwards. During the period 17 September – 17 December 2021, no further domains were hosted on this IP, indicating it was likely dedicated infrastructure (and not a compromised / shared host). Reviewing certificate data for this IP address identified an expired self-signed SSL certificate with a CN value of localhost. SHA1: B0:23:8C:54:7A:90:5B:FA:11:9C:4E:8B:AC:CA:EA:CF:36:49:1F:F6 Whilst examining threat telemetry for 69.174.99.181, it was noted that 97% of the observed data related to communications with a single Hostinger IP address on TCP/3306 (the default port for MySQL servers). This activity occurred between 14 October – 17 December; occurring during the same time window as the Agent Tesla campaign identified by Z-Lab. Hostinger IP Address Note: The Hostinger IP address is redacted throughout this report. As backend infrastructure, its identification would not provide any value to network defenders, and as explained below is likely also utilized for unconnected shared hosting purposes. Passive DNS data identified this IP as a web hosting control panel server. This is supported by open ports data identifying 16 TCP ports that are associated with Hostinger cPanel services. Namely, ports 21, 25, 80, 110, 143, 443, 465, 587, 993, 995, 2080, 2083, 2086, 2087, and 3306. Threat telemetry data for the Hostinger IP address identified inbound connections to TCP/3306 from numerous other IP addresses dating back to at least 17 September 2021. It was assessed that the IP was shared amongst other Hostinger clients, who were likely unconnected to malicious activities. FIGURE 2: HOSTINGER MYSQL CLIENTS Hostinger MySQL Clients Considering the likelihood that the Hostinger IP was used in shared hosting, we needed to include additional constraints to limit our scope to data of relevance to the initial (and potentially other) C2s. We identified several HTTP requests to the original C2 IP address, with several ‘webpanel’ paths using a common naming convention. These paths aligned with the Z-LAB C2 indicators. TABLE 1: 69.174.99.181 URL REQUESTS In addition, we also identified requests to one of the other Hostinger MySQL clients that matched one of the ‘webpanel-‘ patterns: TABLE 2: 155.94.209.50 URL REQUESTS Interestingly, one of the 155.94.209.50 URL requests was for a ‘login.php’ page. When navigating to that URL we were taken to a login page containing a “Mana Tools” logo. FIGURE 3: MANA TOOLS C2 PANEL Whilst we did not have evidence of a URL request to 69.174.99.181 for a ‘login.php’ page, when navigating to the URL http[:]//69.174.99.181/webpanel-reza/login[.]php we were taken to an identical page. First reported in 2019 by Yoroi researchers, Mana Tools is a malware distribution and C2 panel that was created by the threat actor Hagga. It has been associated with several well-known malware variants, including RevengeRAT, AzoRult, Lokibot, Formbook, and Agent Tesla. In addition to 155.94.209.50, we identified a further three MySQL clients hosting the same expired self-signed SSL certificate as 69.174.99.181. According to reverse DNS and WHOIS information, all the identified IPs (based on URL and certificate data) are hosted on QuadraNet infrastructure. FIGURE 4: HOSTINGER MYSQL CLIENT RELATION Examining open ports data for each of the above IPs, it appears that they are run on MS-Windows based operating systems. In addition to having standard Windows ports open, TCP/445, TCP/3389, and TCP/445, they also returned WIN-NetBIOS Computer Names in the RDP response. We also found commonalities amongst several of the Hostinger MySQL client IPs in Passive DNS data. Domain bot.statusupdate[.]one (resolving to 161.129.64.49) was also observed in URL request data in connection with the Mana Tools C2 panel. 64.188.20.198 replaced the original C2 (69.174.99.181) as the hosting IP for domain update.newbotv2[.]monster. Based on threat telemetry for communications with the Hostinger IP and timestamps for the Passive DNS resolutions, it appears that the threat actor “rebranded” the C2 domain from bot.statusupdate[.]one to newbotv4[.]monster around 13 October 2021. The X.509 Certificate It was identified that the certificate (Figure 3) with the serial B5C752C98781B503 was a default certificate included with OpenSSL as part of an XAMPP installation. XAMPP is a free, open-source distribution that packages OpenSSL, MariaDB, PHP, and Perl with an Apache web server. Its primary use is for developers, allowing them to deploy a web server on a local server to test web applications without the need for an internet connection. Given that this certificate was installed on several systems hosting Mana Tools, it appeared that this threat actor was using XAMPP as the web server to host the Mana Tools C2 panel on Windows virtual servers. Back to the Hostinger IP Having identified the Hostinger IP as a common destination for MySQL traffic from several Hagga C2s, we needed to find more evidence to connect Hagga to the cPanel server. As stated earlier, given the possibility that the cPanel IP is shared amongst multiple Hostinger customers, this was difficult to achieve based on threat telemetry alone. To aid this process, we used insight derived from MalBeacon, in addition to further Passive DNS data. Note: MalBeacon is a revolutionary system that can attribute malware campaigns to the threat actor themselves through proprietary pixel tracking technology. If you haven’t heard of it before, I urge you to check it out. MalBeacon data identified several actor IPs in the vicinity of Lahore, Pakistan, associated with the C2s 69.174.99.181 and 64.188.20.198. TABLE 3: MALBEACON DATA Whilst examining threat telemetry data for the Hostinger IP, we found cPanel management traffic to TCP/2083 from the actor IP 42.201.155.21 on 26 November 2021 and from 42.201.155.40 between 02 December 2021 and 03 December 2021. This activity aligned with the dates the IPs were associated with the Hagga C2s. We also identified resolutions in passive DNS data that connect the newbotv4.monster and statusupdate.one domains to Hostinger. TABLE 4: HOSTINGER PDNS RESULTS Whilst the response IP differed from the Hostinger IP address seen in the outbound TCP/3306 connections, it aligned with the processes of leasing a cPanel VPS with Hostinger. When a user purchases their cPanel account through Hostinger, they are asked to add the domain that they are seeking to host on the account to start the service. Once that domain is added, Hostinger assigns several default hostnames to the domain that resolve to a second IP address, which differs from the cPanel management IP first provided. These default hostnames are what are detailed in Table 4. The cPanel management IP can continue to be used for access to the web server control panel, or as an endpoint for a MySQL database. Continued Observation of Hostinger IP By continuously monitoring threat telemetry for the Hostinger IP and examining X.509 certificates and URL requests for new MySQL clients, we were able to identify additional related C2 infrastructure within hours or days of them being stood up. 103.151.122.110 (VNPT-AS-VN, VN) 72.11.157.208 (QuadraNet, US) 192.154.226.47 (Reprise Hosting, US) 64.188.21.227 (QuadraNet, US) 72.11.143.125 (QuadraNet, US) 72.11.143.47 (QuadraNet, US) 207.32.217.137 (1G Servers, US) 194.31.98.108 (PREFIXBROKER, NL) 103.133.105.61 (VNPT-AS-VN, VN) 78.138.105.142 VELIANET-FR-PINETLLC, FR) 103.153.77.98 (VNPT-AS-VN, VN) Additionally, we were able to identify an upgrade to the Mana Tools C2 panel. FIGURE 5: NEW MANA TOOLS C2 PANEL We revisited MalBeacon to examine beacon data for the newly discovered C2 domains and IP addresses to enumerate associated activity. We subsequently identified several ‘new’ adversary IPs in the vicinity of Lahore, Pakistan. These IPs were observed in communications with the Hostinger IP during the same timeframe they were associated with the Hagga C2 panels. FIGURE 6: HAGGA ACTIVITY Conclusion From the starting point of an IP address (69.174.99.181) associated with an Agent Tesla command and control server, it was possible to pivot and identify a backend server hosting a MySQL database operated by the threat actor Hagga. From this point a further pivot led us to the identification of additional C2s hosting the Mana Tools C2 panel along with a common certificate that can be used to increase confidence in attributing future infrastructure to this threat actor. Indicators of Compromise IP Addresses 103.151.122.110 72.11.157.208 192.154.226.47 64.188.21.227 72.11.143.125 72.11.143.47 207.32.217.137 194.31.98.108 103.133.105.61 78.138.105.142 103.153.77.98 69.174.99.181 161.129.64.49 155.94.209.50 64.188.27.104 64.188.20.198 Domains mobibagugu.duckdns.org mobibanewdan.duckdns.org mohbeebnew.duckdns.org mubbibun.duckdns.org cdec22.duckdns.org vncgoga.duckdns.org bakuzamokala.duckdns.org warnonmobina.duckdns.org abotherrdpajq.duckdns.org mobinomomuam.duckdns.org workflowstatus.live heavy-dutyindustry.shop microsoftiswear.duckdns.org update.newbotv4.monster newbotv4.monster bot.statusupdate.one

Threat Telemetry Analysis for the Disclosure of CVE-2022-26134 SUMMARY Team Cymru’s S2 Research Team has highlighted why it is important for cyber defenders to address the critical window between 0-day discovery and the subsequent release of security patches. While malicious activity surges after the release of a POC, the most advanced and skilled threat actors are likely able to develop their own exploits and begin exploitation attempts soon after learning of a new vulnerability. The need to improve awareness of external digital assets and vulnerability management is driven by just how agile and fast sophisticated threat actor groups can be when news of unpatched exploits reaches them. This research not only provides insights on a recent 0-day example, but shows that if organizations do not have control over their attackable surface, they are more susceptible to breach than those organizations taking proactive measures. BACKGROUND On 2 June 2022, Volexity published research following an incident response investigation conducted over the Memorial Day weekend (28 – 30 May 2022). During their investigation, the Volexity team uncovered a Confluence 0-day, now tracked as CVE-2022-26134, being exploited by what they believed to be Chinese state-linked threat actors. Having identified the initial infection vector was a remote code execution (RCE) exploit, Volexity analysts were able to recreate and identify the 0-day vulnerability, which at the time of their reporting, affected all versions of Atlassian Confluence Server. After successful exploitation, further malicious activity included the use of the open source Behinder web server implant, the China Chopper webshell, and a custom file-upload shell. Volexity provided 15 IP addresses which were used by the threat actors to interact with webshells on victim hosts; the initial purpose of this blog post is to provide further insight into these IPs. RESEARCH Pre-Disclosure Of the 15 IP IOCs, 11 were identified as VPN nodes, primarily associated with the Private Internet Access (PIA) and Surfshark services. Caveat: Due to the occurrence of unrelated / benign activities, data derived from VPN nodes must be treated with a degree of caution when it comes to attribution. In an effort to increase confidence in our findings, we focused on scenarios where multiple IP IOCs were observed in communication with a potential victim host. Throughout this analysis, we chose to concentrate on communications involving port 8090, the default for Confluence Server instances, which was observed in the public ‘proof of concept’ exploit code. Examining threat telemetry for the 15 IP IOCs, we were able to identify with high confidence, nine organizations which were targeted on or around 26 May 2022. This activity was specifically associated with three of the IPs (154.16.105.147, 156.146.34.46, and 156.146.34.52), all of which were PIA VPN nodes. The identified target organizations were spread across multiple sectors and regions, indicative of the threat actors moving to an opportunistic phase, potentially associated with more than one group. Given previous timelines for the exploitation of 0-day vulnerabilities, it is likely that the initial targeting and compromises occurred weeks or months prior to the elevated levels of activity observed at the end of May 2022. The targeted organizations included several government departments, as well as private companies in the digital, higher education, information technology, and logistics and supply chain sectors. Victims were observed in Asia, Europe, and both North and South America. In addition to the high confidence targets, seven medium/low confidence targets were identified where a specific organization could not be linked to the IP addresses observed. This was due to a lack of contextual information for these IPs, for example Passive DNS data. Post-Disclosure With a set of potential victim organizations established, pivoting on a sample of the targeted IP addresses provides us with the opportunity to uncover additional malicious activities, knowing that these IPs host vulnerable Confluence servers. When examining threat telemetry from the beginning of June 2022 onwards, it was noted that approximately half of the IP addresses ‘targeted’ by the threat actors described by Volexity were not observed in any additional communications over port 8090. Visualizing the resulting data based on daily counts shows there is a clear spike in activity on 3 June 2022, which then mostly tapers off and stabilizes by 11 June 2022. While not all of this traffic is due to malicious activity, the first three days of June saw above average data volumes which coincides with the public disclosure of CVE-2022-26134. From this data there were 11 IP addresses (listed in the IOC section below) which stood out due to their numerous and broad range of potential targets. Pivoting on these IPs, we found that most of them had a history of exploiting/scanning for numerous vulnerabilities on a massive scale. We also found that six of these IPs were managed by the same threat actor and often used together in various campaigns related to vulnerability exploitation. Within the last 30 days some of the vulnerabilities that we observed targeted included CVE-2021-3129, CVE-2022-22947, CVE-2021-34535, and CVE-2021-41773. We also saw exploits for CVEs from as far back as 2013, another reminder that there is no cut-off point for the exploitation of vulnerable machines. As shown in the chart below, this group of malicious IPs were most active on 2 June 2022. The results are slightly different from the previous dataset but share a common theme of an initial flood of activity around the time of disclosure, lasting approximately three days before levelling out. Up to this point, our research has been limited to a small and specific sample of targeted IPs, and from the previous line graphs it would be easy to assume that interest was limited to the first three days of June 2022. In order to obtain a larger dataset (to improve the accuracy of threat telemetry sampling), we used Shodan to identify IP addresses that were shown as potentially vulnerable to the 0-day. As previously, we focused on telemetry for port 8090 from the beginning of June 2022 onwards. With a broader sampling of data, we observed that the peak in activity post-disclosure happened on 6 June 2022, later than the previous datasets (and more in line with general information security community observations). Additionally, it appeared that data volumes did not tail-off in the same way, with elevated levels of activity continuing from the initial peak. One hypothesis could be that the threat actors responsible for the activities observed in our initial limited sample were more skilled and therefore possessed a quicker reaction time to the announcement of a ‘new’ vulnerability. Conversely, in our larger sample, we potentially observed lesser skilled threat actors (feeding frenzy) utilizing the publicly disseminated proof-of-concept (POC) exploit code which emerged in the days after the initial disclosure. RECOMMENDATIONS Temporary mitigations should be explored to limit successful early exploitation by higher skilled threat actors, while awaiting the publication of a POC and for patch cycles to catch up. While traditional incident response would place this issue in the remediation phase based on their own detections and context of the threat, note that malicious behavior experienced by one organization is not indicative of the threat landscape and risk of exploitation. Consider reviewing your existing, or deploying a new, Attack Surface Management Platform. The goal is to gain full visibility of security weaknesses across your external digital assets. Use Cases are highlighted here. Assess how your team currently becomes aware of new and emerging exploits and vulnerabilities. Explore methods that could bring critical information to their attention sooner and give you and your team an advantage. IOCS 109.237.96.124 185.40.4.66 193.106.191.48 203.245.3.170 23.99.229.118 45.156.27.27 51.159.15.27 62.233.50.179 95.182.120.164 95.182.120.180 95.182.123.66

Free-to-use browser automation framework creates thriving criminal community Summary Evidence suggests an increasing number of threat actor groups are making use of a free-to-use browser automation framework. The framework contains numerous features which we assess may be utilized in the enablement of malicious activities. The technical entry bar for the framework is purposefully kept low, which has served to create an active community of content developers and contributors, with actors in the underground economy advertising their time for the creation of bespoke tooling. The framework warranted further research due to the high number of distinct threat groups who include it in their toolkits. Introduction During three recent (and separate) investigations into command and control (C2) infrastructure for Bumblebee loader, and BlackGuard and RedLine stealers, our analysts observed connections from the C2s to a tool repository / marketplace called Bablosoft. Looking into open-source reporting, we found that other vendors had previously come across Bablosoft in their investigations: General research by F5 Labs into credential stuffing attacks Research by NTT into the toolkit utilized by GRIM SPIDER In this blog post, we will examine Bablosoft in further detail, providing our hypotheses on the threat actor use cases for the tools on offer, and highlighting links to other threat activity. Bablosoft Insight from Open Source References to Bablosoft first appeared within public forums during late 2016, when the ‘main’ developer – who goes by the moniker Twaego – posted about the release of a tool entitled BrowserAutomationStudio (BAS). As can be discerned from the advert, the purpose of BAS is to provide users with an easy-to-use framework for the creation of bots, including “spammers” and a “credentials checker”. Reviewing this and other public threads on BAS / Bablosoft, it is clear the tool was well received by the community, for several reasons: The tool is free – although a premium version with additional features is available The developer (Twaego) actively works on community feedback/requests to improve the tool Users can share applications/scripts through the Bablosoft community page The postings also provided further insight into some of the tool’s capabilities; browser emulation, mimicking of human behavior (keyboard and mouse), proxy support, a mailbox search feature, and the ability to load data from file/URL/string. Features which have caught the eye of several distinct threat actor operations. In underground forums we have identified users ‘offering their services’ for the creation of bespoke scripts for BAS, for example to interact with the Telegram API, or the development of “bruters” and “recruiters”. In the post above, the user BasCoder provides an overview of a business-like service, inclusive of a ‘free consultation’, with projects priced from $20 depending on scale. We identified a ‘thank you’ post from another user who appeared to have used BasCoder’s services for a BAS-related project. The customer in this case, a user called n1ppyyy, is a now-banned but formerly active member of the XSS forum who engaged in numerous topics indicative of an interest or involvement in malicious activity. Insight from Threat Telemetry In the cases of the Bumblebee, BlackGuard and RedLine C2s, we observed connections to downloads.bablosoft[.]com (resolving to 46.101.13.144). Threat telemetry for this IP address provides an insight into the general user base for Bablosoft, with the majority of activity coming from locations in Russia and Ukraine (based on WHOIS information). As for Twaego (the ‘owner’ of Bablosoft), their profile summary indicates they are from Kiev, Ukraine. We were able to corroborate this information based on management activity to several elements of the Bablosoft infrastructure, sourced from a single Ukrainian-assigned IP address. In addition, the IP was also involved with management connections to a number of hosts on TCP/27017 – commonly associated with MongoDB. Malicious Use Cases As previously highlighted, we observed the Bumblebee, BlackGuard and RedLine C2 IPs connecting to the ‘downloads’ subdomain of bablosoft[.]com, with the assumption that the operators were downloading tools for use in threat activities. For the BlackGuard and RedLine C2s there are several use cases for BAS which may be applicable. For example, we identified a ‘gmail accounts checker’ which the threat actors might utilize for assessing the validity of stolen credentials. Whilst examining threat telemetry for other elements of the Bablosoft infrastructure, we identified several hosts associated with cryptojacking malware making connections to fingerprints.bablosoft[.]com. The Fingerprint element of the BAS service allows users to alter their browser fingerprint, a function likely used by these particular actors as a means of anonymizing or normalizing their activity. Conclusion Based on the number of actors already utilizing tools offered on the Bablosoft website, we can only expect to see BAS becoming a more common element of the threat actor’s toolkit. As referenced by F5 Labs in their report on credential stuffing – “One of the reasons we expect to see more of BAS is because of the Bablosoft community and how easy the software makes it to redistribute and sell work.”. An “unofficial” Telegram group, entitled Bablosoft – BAS chat (BABLOSOFT – ЧАТ ПО БАСУ), retains a membership of over 1,000 users, further highlighting the level of community activity around the tool. This group appears to be used predominantly by Russian speakers, to share updates on new features, scripts and tips. IOCs Bumblebee C2: 45.147.229.177 BlackGuard Panel C2: 185.173.157.26 RedLine Controller C2: 91.243.59.61

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