top of page

Search Results

124 items found for ""

  • Botnet 7777: Are You Betting on a Compromised Router?

    Firstly, we extend our thanks to Chris Fearnley and Gi7w0rm , two threat researchers who assisted us behind the scenes with our investigation into the 7777 (“Quad7”) botnet. Their insights were instrumental in confirming the findings mentioned in this blog post. A “7777 botnet” was first referenced in public reporting in October 2023 by Gi7w0rm. At the time, it was described as a botnet with approximately 10,000 nodes, observed primarily in brute-force attacks against Microsoft Azure instances. These attacks were characterized by their low-volume nature, making them inherently difficult to detect, with only 2-3 login attempts made per week in some cases. While initial reports suggested VIP users were targeted by these attacks, more recent research by Sekoia indicated there was no clear targeting pattern in the attacks they observed. The botnet takes its name from the fact it uniquely opens TCP port 7777 on compromised “zombie” routers. When scanned, the service on this port returns an xlogin: banner. To date, various low-confidence attributions have linked Quad7 to both cybercrime and state-sponsored activities. However, little conclusive evidence in this area has been made public, leaving the true operators of the botnet shrouded in mystery. In this blog post, we will examine the Quad7 botnet and the infrastructure used to control it in greater detail. Key Findings Identification of a potential expansion of the Quad7 threat operator’s modus operandi to include a second tranche of bots, characterized by an open port 63256 . The port 63256 botnet appears to be comprised mainly of infected Asus routers. Identification of 12,783 active bots (comprising both 7777 and 63256 ) over the 30-day period ending 05 August 2024, likely to represent a proportion rather than the full extent of the botnet. Identification of seven management IPs either currently active or last observed in the past 30 days. Four of the IPs align with recent research by Sekoia, with the remaining three previously unattributed. Bot Hunting & Characterization As disclosed by other researchers and alluded to above, Quad7 bots can be identified by querying for IP addresses with an open port 7777 displaying the xlogin: banner. In Figure 1 below, we can see that over the past 30 days (at the time of writing), 7,038 devices were identifiable in this way. Figure 1 - Quad7 Bots Note, we have redacted some victim-related information from Figure 1 (and Figure 2 below). This number (7,038) is lower than the approximately 10,000 nodes quoted in Gi7w0rm’s research from last October. There are two likely reasons for this discrepancy: The initial findings may have been derived from a period longer than 30 days or from scan data collected at closer intervals, capturing routers that were only “online” for relatively short periods. Since the public reporting of Quad7 emerged, users may have taken steps to clean infections or update vulnerable firmware to prevent their routers from being targeted. Point 1 raises a more general issue about approximating the scale of botnets with scan data. It is important to remember that statistics derived in this way only represent a proportion of all available bots. This is due to various factors, the most significant being an "offline" device won't be picked up via this discovery method, even though it will likely continue to be a viable bot when it returns "online". Whatever the case, nearly ten months later it is apparent that Quad7 remains active and retains a “healthy” number of bots, particularly if one of its primary use cases is low-volume brute force attacks. Digging further into our result set, and based on the comprehensive tagging of IPs that we undertake to contextualize the data observed on our platforms, it was apparent that a significant proportion were likely Hikvision or TP-Link devices. This finding correlated with previous research on Quad7, such as this blog by VulnCheck, which examined the targeted hardware in more detail. In Figure 2 below, we can see an example of this, with the highlighted host identified specifically as a TP-LINK WR841N router. Figure 2 - Router Tag Example Insights such as these, particularly specific router types, allow us to both understand and track how the botnet proliferates. Additionally, they enable Team Cymru and our customers to hunt for potentially vulnerable infrastructure in the hopes of pre-emptively disrupting future compromises. We will expand on the subject of hardware identification in the next section.. Eagle-eyed readers will also notice in Figures 1 and 2 that, in some cases, port 11288 was also observed open on hosts enrolled in the Quad7 botnet. This is not a novel finding; previous research into Quad7 identified that a SOCKS5 proxy service was configured to operate on this port in some cases. The research by Sekoia narrowed this activity down to an open-source SOCKS5 proxy server developed by GitHub user bhhbazinga . Of possible note, this user lists their location as Hangzhou, China. Sekoia found that TCP/11288 was used by the threat operators to proxy communications to third-party servers for the purpose of brute-forcing attacks. Specifically, they observed connections to login.microsoftonline[.]com , indicating that these attacks were targeted at Microsoft 365 accounts. This process is simplified in Figure 3 below. Figure 3 - SOCKS5 Proxy Use Case By repeating the technique illustrated in Figure 1, we can sanity-check our findings by hunting for hosts with an open port 11288. Based on data from numerous hosts identified through hunting for an open port 7777, we found that a common banner ( \x05\xff ) was also displayed in cases where port 11288 was open. Figure 4, below, shows an example of this. Figure 4 - Open Ports Information The 63256 Botnet Our next finding raises identity issues for the “7777 botnet.” We have observed a potential expansion of the threat operator’s activities, adding over 5,000 “zombie” devices in the process. First, let’s play a game of “spot the difference”, comparing Figure 5 below to Figure 4 above. Figure 5 - The Same Open Ports Information, But Different The banner information is almost identical, but the observed open ports have switched. When we combined a hunt for these banners on port 7777 ( xlogin: ) and port 63256 ( alogin: ), a total of 12,783 hosts were identified. So, in a way , we take back what we said about there being fewer “zombie” devices now compared to October 2023. When looking at tagging data for the 63256 botnet, we found that a significant proportion of the hosts were likely operating ASUS routers. This marks another change in technique. As previously referenced, Quad7 activity had focused on the compromise of TP-LINK routers. The delineation appears to be as follows: 7777 botnet ( xlogin ): TP-LINK routers and various IP-camera types 63256 botnet ( alogin ): ASUS routers NetFlow Analysis Having established a substantial pool of recent analytical leads in the form of hosts likely enrolled in the Quad7 botnet (or botnets), we can now start to examine supporting NetFlow data. In this case, we are seeking to establish common peer IPs and further indications of management activity. In total, seven such IPs were identified with high confidence following our analysis of associated NetFlow data. Figure 6 below presents the observed relationships in the form of a chart. Figure 6 - Infrastructure Diagram The seven IPs were assigned to three distinct providers: HOSTWINDS, HVC-AS, and M247. Four of these IPs were referenced in Sekoia’s research, which this analysis now builds upon. IP 151.236.20.185 continues to be the only IP to communicate with the bots on remote port 7777, which we now know is a service used to provide the threat operators with a remote shell on the compromised device. This IP, therefore, remains of heightened interest due to its apparent elevated role. The remaining six IPs communicated with the bots on remote port 11288. These connections are likely indicative of attack activity being proxied towards intended targets, as in the Microsoft 365 case referenced above. IP 151.236.20.211 also provides a clear link to the 63256 botnet infrastructure, communicating with remote IPs over ports 63256 and 63260. This finding increases our confidence that the two bot infrastructures are linked, while also remaining siloed. To date, we have not observed any activity indicative of the 63256 botnet being utilized in offensive activities. Conclusion The Quad7 botnet continues to pose a significant threat, demonstrating both resilience and adaptability, even if its potential is currently unknown or unreached. Despite public reporting and efforts to mitigate its impact, the botnet remains active with a substantial number of compromised devices. Our investigation has not only confirmed the continued presence of the original 7777 botnet but also identified an expansion in the threat actor's operations, with the addition of the 63256 botnet predominantly affecting ASUS routers. The identification of seven management IPs and their communication patterns provides valuable insights into the botnet's infrastructure and operational methods. The linkage between the 7777 and 63256 botnets, while maintaining what appears to be a distinct operational silo, further underscores the evolving tactics of the threat operators behind Quad7. Our investigations of this infrastructure continue, and we remain focused on further understanding the targeting choices of the threat operators and any leads which may point towards an attribution. We will return at an appropriate time to provide further updates on our findings. Recommendations Maintain Up-to-Date Firmware: Users should ensure their devices have the latest firmware updates to prevent their routers from being compromised and enlisted in malicious activities. Implement Robust Security Practices: Adopting strong security measures is crucial. This includes using strong, unique passwords, disabling unused services, and regularly monitoring network activity to detect any suspicious behavior. Continued Vigilance and Proactive Measures: Security teams must stay vigilant and proactive. By understanding the specific hardware targeted and the communication channels utilized by botnets like Quad7, they can better defend against potential compromises. Collaboration and Information Sharing: It is vital for researchers and security professionals to collaborate and share information. This collective effort is essential in the ongoing battle against botnets. Utilize Advanced Tracking Tools: Users of Pure Signal Recon and Scout can track Quad7 activity by querying the IPs shared in the IOC section below or by performing advanced queries that combine the open ports characteristics discussed in this blog post. Indicators of Compromise The below IPs were all observed in communications with compromised hosts, inbound traffic from these IPs is indicative of enrolment in either the 7777 or the 63256 botnet. Observed in traffic to remote ports 7777 and 11288: 151.236.20.185 Observed in traffic to remote ports 11288, 63256, and 63260: 151.236.20.211 Observed in traffic to remote port 11288: 104.168.152.139 142.11.205.164 23.227.196.73 23.254.201.175 23.254.209.118

  • Navigating the Evolving Landscape of Cybersecurity

    A Focus on Vulnerability Management In recent years, the cybersecurity landscape has undergone significant transformations, particularly in the realm of vulnerability management. This shift is driven by the increasing sophistication of cyber threats, the proliferation of digital transformation initiatives, and the growing complexity of IT environments. In this blog, we will explore how vulnerabilities are changing and how organizations are adapting their ability to ingest feeds, services, and platforms to manage the entire vulnerability management lifecycle effectively. A special focus will be on incorporating the Exploitability Prioritization Scoring System (EPSS) and Known Exploitable Vulnerabilities (KEV) into vulnerability management practices. The Changing Nature of Cyber Vulnerabilities Cyber vulnerabilities have evolved from simple exploits to more sophisticated and multi-faceted threats. Modern vulnerabilities are often more complex, targeting various layers of an organization's infrastructure, including software, hardware, and human elements. Key trends in the changing nature of vulnerabilities include: Increased attack surface: With the rise of cloud computing, IoT devices, and remote work environments, the attack surface has expanded, providing more entry points for cyber attackers. Increased number of technologies and vulnerabilities: The introduction of new technologies has expanded potential security flaws, creating complex environments that obscure vulnerabilities. The volume overwhelms security teams, and the use of open-source components adds risks. Zero-Day vulnerabilities: These are vulnerabilities that are unknown to the vendor and for which no patch is available, making them particularly dangerous as they can be exploited before any mitigation measures are in place. Limitations of Traditional Vulnerability Assessment Traditionally, organizations have relied heavily on the Common Vulnerability Scoring System (CVSS) to assess the severity of vulnerabilities. While CVSS provides a valuable baseline for evaluating vulnerabilities, it has inherent limitations: Inability to prioritize: Because it lacks context-specific factors such as exploitability, CVSS often falls short in enabling Security Teams to prioritize based on the severity of vulnerabilities alone. This limitation underscores the need for more nuanced and dynamic approaches that enable analysts to address mission-critical threats first as they appear. Insufficient exploitability assessment:  CVSS does not adequately assess the exploitability of vulnerabilities. A high CVSS score does not necessarily mean that a vulnerability is easily exploitable in real-world scenarios. Conversely, a vulnerability with a low CVSS score may still be actively exploited if known techniques exist. Organizations must embrace new vulnerability scoring mechanisms into their tools and workflows to better recognize critical vulnerabilities that pose immediate risks to their systems and data. Two new methods that transform Vulnerability Management To address the limitations of traditional vulnerability assessment methods, organizations need more advanced scoring methods such as the Exploitability Prioritization Scoring System (EPSS) and Known Exploitable Vulnerabilities (KEV). Exploitability Prioritization Scoring System (EPSS): What is EPSS?:  EPSS evaluates the likelihood and ease of exploitation of vulnerabilities based on factors such as the presence of known exploits, attack vectors, and weaponization. Benefits of EPSS: By incorporating EPSS into the risk scoring framework, organizations can provide more accurate assessments of vulnerability exploitability. This ensures that mitigation efforts are prioritized based on the actual likelihood of successful exploitation rather than solely relying on CVSS scores. Consideration of Known Exploitable Vulnerabilities (KEV): What is KEV?:  KEV are vulnerabilities for which exploit techniques are publicly available and actively used by threat actors. Benefits of Considering KEV: By including KEV in the risk scoring framework, organizations ensure that they are alerted to vulnerabilities actively exploited in the wild, regardless of their CVSS scores. This proactive approach helps mitigate immediate threats and reduce the risk of successful cyberattacks. Implementation Considerations for EPSS and KEV Integrating EPSS and KEV into a vulnerability management framework involves several key steps: Data Integration: Organizations must integrate additional sources of vulnerability intelligence such as exploit databases and threat intelligence feeds to gather information on known exploit techniques and KEV. Scoring Algorithm Development: Engineering teams must develop algorithms to calculate EPSS scores based on exploitability factors and incorporate KEV data into the risk-scoring model. User Interface Enhancement: The platform's user interface will require updates to display EPSS scores and highlight KEV vulnerabilities effectively. Conclusion Incorporating EPSS and KEV into a vulnerability management framework enhances the accuracy and effectiveness of vulnerability management practices. By providing more nuanced assessments of vulnerability exploitability and considering actively exploited vulnerabilities, organizations can prioritize mitigation efforts more effectively and reduce their exposure to cyber threats. While implementing these enhancements may require an initial investment in development and integration, the long-term benefits in terms of improved security posture and reduced risk far outweigh the associated costs. This proactive approach is crucial in an era where cyber threats are constantly evolving and becoming more sophisticated. By leveraging advanced scoring systems and keeping abreast of known exploit techniques, organizations can stay one step ahead in the cybersecurity game, safeguarding their critical assets and ensuring operational resilience.

  • A Blog with NoName

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

  • Mythic Case Study: Assessing Common Offensive Security Tools

    Having covered the Sliver C2 framework in a previous post, 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.):

  • Seychelles, Seychelles, on the C(2) Shore

    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.

  • Risk Modeling and Real-Time Intelligence - Part 1

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

  • Network Perimeters in the Age of Social Distancing

    The COVID-19 pandemic has turned our world upside down, leaving many of us to question whether we will ever see “normal” again. One concept, we’ve all become familiar with recently is “Social Distancing”. The CDC describes this as “physical distancing”, meaning to keep space between yourself and other people outside of your home. For me, this idea of maintaining separation parallels our computer technical term for the concept of a DMZ, or De-Militarized Zone. Let me explain: DMZ It doesn’t matter when you have started your interest in networks, or even your formal career in information security, we all start with the concept and theory of a DMZ. My first encounter with the computerized version of the DMZ name was from the book “Computer Networks” by the brilliant authors Andrew S. Tanenbaum and David J. Wetherall. Even though the first edition of this book dates back to the early eighties, even then the authors described the security topology and the benefits of having a separation between networks and devices. Incidentally, if you have a passion for military history and this topic of the DMZ you need to have on your to-do list a visit to the ‘other’ DMZ in South Korea – it’s totally worth it! Here is your author on a recent trip there himself: R0 Another new term that was also new for many of us this year was the epidemiological term of R0, pronounced R nought or just R zero. We can understand this as the expected number of infections directly generated by one infected person in a population, where all people are susceptible to the spread of infection. This can be easily translated into a network security analogy, as we see this daily in our work with infected machines scanning for other vulnerable machines and spreading malicious code as infections. If you turned to your interactive device of choice in recent months, you also may have stumbled onto the numbers of infected persons, such as the COVID-19 Dashboard by the Center for Systems Science and Engineering (CSSE) at Johns Hopkins University (JHU). This illustrates that by the end of May 2020 we had 6,152,160 confirmed cases of COVID-19 (the name of the disease you get from the SARS-CoV-2 virus), and that includes the number of active cases as well the number of recovered cases [2]. https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6 But what about computers? Is there value in measuring computer infections in a similar way? Not only do we measure this, but we also classify them according to different categories and classes of “maliciousness”, based on what they do, what type of code they use, and how they operate. Team Cymru World Hackbook Looking into Team Cymru data we reported during the full month of May 2020, 44,441,438 IP “occurrences”. This includes multiple reports about the same IP. We share these reports — at no cost — with National Computer Security Incident Response Teams (NCSIRTs), which are members of our CSIRT Assistance Program (CAP). If you compare those numbers with populational numbers, just for clarity, we can consider 3.7 billion usable IPv4 IPs – 3,706,452,992 and 7.8 billion humans you can see how these numbers are numerically significant. If you are a National CSIRT and not yet a member of our CSIRT Assistance Program, please contact the Jacomo via outreach at cymru.com to join the 124 existing CAP members. Social Distancing When WHO.int started to advise and promote social distancing, I took a look at our data, trying to see if I could find infected IPs talking to the websites of WHO[.]int (22-Feb-2020 to 31-May-2020 total of 4642 IPs) From the time period 22-Feb-2020 to 31-May-2020 we saw 4,642 “infected” IPs that met this criteria. As a security practitioner I would not be comfortable with knowing an infected IP in my network is also probing who[.]int for unauthorized access. The definitions of network perimeter, DMZ, internal network and external network, have evolved a great deal over recent years, especially with the advent of modern cloud-based solutions, and it is time for us to also consider enhancements to the traditional ‘next-hop protection’. We need to take the blinders off and take expand our visibility to include the signal on the network hops reaching out to our “new perimeters”, whereverthey are now located. In today’s world, if you only see the next-hop-network, then you are underestimating your adversaries in the complex cat and mouse game played every minute on the Internet. Incidentally, we help our partners and clients go beyond the next hop, in order to gain the visibility they need. One old and misleading assumption that must be debunked is the notion that you will have adequate defense by simply using a deny list to prevent malicious IPs from accessing your infrastructure. I will share one example of how this is easily bypassed: This is a cropped print-screen of a criminal hacking service that offers compromised systems and one of the many features and guarantees provided by those criminals is that the systems will not show on blacklists. From a criminal perspective, if I need a clean IP to position myself one-hop before a target infrastructure this is easily done for USD $7.50 – this will circumvent your deny lists and geographical access restrictions. Conclusion Paraphrasing the US Marines: “Improvise, Adapt, and Overcome”…more than ever, we need to constantly assess our connected footprint and review our network and security strategy to protect our digital assets. If you don’t already have in place today worst-case scenario detection, protection and reaction methods that include visibility beyond the next hop, you are tempting fate.

  • Navigating Cybersecurity Frontiers in Rwanda: Unveiling the RISE Conference's Agenda

    Why you need to attend the RISE 2024 Conference In the rapidly evolving digital era, cybersecurity remains a paramount concern, especially in regions like Rwanda and across Africa. This May, Team Cymru’s series of RISE Conferences arrives in Rwanda and will serve as a crucial convergence point for cyber law enforcement professionals, cyber threat analysts, and senior network engineers. Here, we will delve into the heart of contemporary cyber challenges, offering insights and solutions tailored to our unique landscape. “After many years of successful events across the African continent, we’re looking forward to welcoming new delegates to advance their cyber threat knowledge and increase their network among their peers.” Steve Santorelli, Chief of Staff, Team Cymru 1. Tackling the Surge in Cybercrimes Amidst Digital Growth: As Rwanda and Africa take large strides forward in digital innovation, a surge in cybercrimes has become an inevitable challenge. The RISE Conference will allow you to discuss this trend, providing a platform to share innovative cybersecurity measures and preventive strategies. We will explore how technological advancement has altered the cybercrime landscape, necessitating updated approaches and tools to safeguard digital assets and information. 2. Cybersecurity in National Policies: A Cornerstone for Digital Economies: The integration of cybersecurity into national policy frameworks is no longer optional but a necessity. The conference will touch on Rwanda's strides in enacting data protection laws and developing comprehensive cybersecurity strategies. Attendees will gain insights into how cybersecurity policy can be effectively woven into the fabric of national governance and business strategies, ensuring a secure digital future for citizens and enterprises alike. 3. Embracing Collaborative Cybersecurity Approaches: In our interconnected world, cybersecurity challenges cross borders and sectors. The RISE Conference emphasizes the need for a collaborative approach to cyber risks. Sessions will focus on fostering international cooperation, with particular attention to protecting vulnerable online populations, such as children, and combating emerging cyber threats. This collaborative ethos is critical for developing a unified front against cyber adversaries. "Following the steps of previous successful RISE events hosted in Morocco in 2017, Kenya in 2018, and South Africa in 2022, we are excited to be working with RICTA.  Together, we will co-host and bring RISE to Rwanda in 2024.” Jacomo Piccolini, Outreach Team, Team Cymru Conclusion: The RISE Conference is more than just an event; it's a beacon for cybersecurity knowledge and collaboration in Rwanda and Africa. By addressing current and pressing cybersecurity challenges through expert-led discussions, workshops, and networking opportunities, we are paving the way for a safer digital future. Join us in shaping the conversation and solutions in the realm of cybersecurity. Event Details: For additional information on the event schedule, expert speakers, and how to register, please visit Team Cymru's Event Page.

  • MoqHao Part 2: Continued European Expansion

    Monitoring Roaming Mantis Operations with Pure Signal™ Recon This blog is a product of ongoing collaboration with @ninoseki, a Tokyo-based researcher who has tracked MoqHao for several years. His public GitHub contains numerous useful OSINT threat hunting tools. Introduction MoqHao (also referred to as Wroba and XLoader) is a malware family commonly associated with the Roaming Mantis threat actor group. MoqHao is generally used to target Android users, often via an initial attack vector of phishing SMS messages (smishing). Roaming Mantis are characterized as Chinese-speaking and financially motivated. The group has historically targeted countries in the Far East – in particular Japan, South Korea and Taiwan. We have previously blogged on a MoqHao campaign targeting Japan during the Golden Week holiday period in April/May 2021. In the recent past, several vendors (e.g., Kaspersky) have noted an expansion in Roaming Mantis’ operations to include several European countries. In this blog we will examine open-source hints attributable to the threat actors, coupled with Team Cymru’s insights, to provide an assessment of Roaming Mantis’ current target base. Landing Pages When following a malicious link distributed in a Roaming Mantis smishing campaign, users are directed to a landing page. These pages are tailored specifically to a target country / language; users from other regions are presented with an error page (404 – resource not found). Based on the user-agent information for the connecting device, one of two outcomes will occur: For Android devices, a malicious APK (MoqHao) is downloaded. . For Apple (iOS) devices, the user is presented with a phishing page where they are asked to enter credentials for a spoofed entity. LANDING PAGE CHARACTERISTICS To determine common characteristics of the infrastructure utilized for the hosting of Roaming Mantis landing pages, 43 IP addresses, which were observed hosting these pages since the beginning 2022, were analyzed. The following findings were true across all the IPs: . The re-use of the same X.509 certificate (SHA1: 834024f91f67445a7fd1a98689cb3f49b4c3ade7), hosted on TCP/443. This certificate has a common name value of localhost and an alt name value which contains (at the time of reporting) 335 legitimate domains, summarized as follows: Global brands, such as Google, PayPal, Tumblr, and YouTube. South Korean entities, such as Naver and Daum. ccTLDs for .kr (South Korea) and .tw (Taiwan). A consistently observed JARM fingerprint (29d21b20d29d29d21c41d21b21b41d494e0df9532e75299f15ba73156cee38). Open ports; TCP/5985, TCP/10081, TCP/47001. Passive scanning of TCP/10081 on the landing page hosting IPs indicated an additional HTTP service listening on this port. The HTML title value for this service provides useful insight into victim targeting, as summarized below. HTML Title = 美国下载 (US Download) 142.0.136.49 142.0.136.50 142.0.136.52 142.4.97.105 142.4.97.106 142.4.97.107 142.4.97.108 142.4.97.109 HTML Title = 英国下载 (UK Download) 134.119.193.106 134.119.193.108 134.119.193.109 134.119.193.110 192.51.188.142 192.51.188.145 192.51.188.146 HTML Title = 韩国下载 (South Korea Download) 27.124.36.25 27.124.36.27 27.124.36.32 27.124.36.52 27.124.39.241 27.124.39.242 27.124.39.243 HTML Title = 日本下载 (Japan Download) 192.51.188.101 192.51.188.103 192.51.188.111 192.51.188.14 91.204.227.111 91.204.227.15 91.204.227.18 91.204.227.20 91.204.227.30 91.204.227.32 91.204.227.40 HTML Title = 德国下载 (Germany Download) 146.0.74.157 146.0.74.197 146.0.74.199 146.0.74.202 146.0.74.203 146.0.74.205 146.0.74.206 146.0.74.228 HTML Title = 法国下载 (France Download) 134.119.205.21 134.119.205.22 As can be seen, in addition to campaigns targeting France, Germany, Japan, South Korea, and the United States, infrastructure was set up for the specific targeting of UK-based users. This finding would indicate a further expansion of Roaming Mantis’ operations within Europe. MoqHao Command & Control In this section we will examine network telemetry relating to the connections made once the malicious APK (MoqHao) is installed on a victim Android device. By examining this stage of the attack, it is possible to identify potential victims with a higher degree of certainty. This confidence is based on the chain of events leading to this point, i.e., a user has interacted with a link contained within an SMS message, visited a landing page, and the malicious APK has successfully been deployed on the user’s device to the point where it has begun to beacon to the C2 server. The starting point for this part of the analysis was a MoqHao sample (SHA1: 74558f86e4b4513f7f52d6b99b7e06d978aec97b) uploaded to VirusTotal by a user in the United Kingdom on March 16, 2022. Analysis of this sample identified a C2 server hosted on 103.249.28.207 (EHOSTICT, KR). Network telemetry for this IP revealed a small number of connections inbound on TCP/28866, sourced from IP addresses assigned to UK mobile providers. In addition, 103.249.28.207 was observed as a C2 server in what appeared to be four further campaigns: TCP/28866 – Spain, Turkey TCP/29869 – South Africa TCP/28844 – Afghanistan, Bangladesh, India, Iran, and Pakistan (South Asia) Passive scanning of 103.249.28.207 identified open TCP/3389 (commonly associated with the Remote Desktop Protocol (RDP)), with a machine name of WIN-MM79JTRSTL7. As an aside, screen captures of RDP activity on 103.249.28.207, sourced from Shodan, provided another ‘Chinese’ flag for this activity. As recently as January 05, 2022, a remote login page was captured (associated with machine name WIN-MM79JTRSTL7), which indicated Chinese language settings – the characters 密码, meaning ‘password’ in Mandarin, were displayed. Figure 3: Remote login portal for 103.249.28.207 (January 2022) This login page was visible dating back to the end of 2020, all the time associated with the same machine name (WIN-MM79JTRSTL7). A screen capture from January 22, 2020, indicated Korean language settings – the characters 암호, meaning ‘password’ in Korean, were displayed. Figure 4: Remote login portal for 103.249.28.207 (January 2020) Given that 103.249.28.207 is assigned to a South Korean provider (Ehost IDC), the information from Shodan may be indicative of a Chinese-speaking user accessing / utilizing the machine since late 2020. A pivot on the value WIN-MM79JTRSTL7 identified a further eight IP addresses, all assigned to EHOSTICT, KR, which were accessed by the same machine. Network telemetry data was obtained for these IPs for the beginning of 2022 onwards, where MoqHao campaigns were identified, they are referenced in Table 2 below In the case of 103.249.28.210, samples uploaded to VirusTotal in early 2021 provide an indication as to when it was an active MoqHao C2. For the remaining IPs it is not clear if they were previously MoqHao C2s. One possibility may be that they are being configured for future use. Although not an exhaustive study of MoqHao C2 infrastructure, it is clear from the findings of this analysis and other findings from the community, that Roaming Mantis continue to expand their operations. What was previously considered to be a regional threat now has a global footprint. Indicators of Compromise MOQHAO C2 SERVERS 103.249.28.206 103.249.28.207 103.249.28.208 103.249.28.209 61.97.248.5 MOQHAO SAMPLE 74558f86e4b4513f7f52d6b99b7e06d978aec97b

  • How the Iranian Cyber Security Agency Detects Emissary Panda Malware

    March 25, 2020 S2 Research Team Other threat intelligence groups have previously publicised that the Chinese-attributed threat group, Emissary Panda (aka APT27, TG-3390, BRONZE UNION, Iron Tiger and LuckyMouse), have been targeting various sectors in the Middle East, including government organisations. On 15 December 2019, Iran’s Minister of Communications and Information Technology, Mohammad Javad Azari-Jahromi, announced that Iranian authorities had detected foreign spying malware on their government servers which they attributed to the “well-known APT27” (Figure 1). Figure 1: Announcement about APT27 by Iran’s Minister of Communications and Information Technology We decided to take a look at our data in an attempt to identify any malware indicators of this compromise. Although Emissary Panda are known to utilise a wide-array of tools, they are most often associated with HyperBro, an in-memory RAT. Therefore, we decided to start by searching for any previously unobserved samples of this malware we have within our datasets. HyperBro malware is installed on a system via three components: A legitimate executable used to side-load A malicious DLL used to decrypt and load A third file as a DLL (the malicious payload) We also know from previous analysis that HyperBro creates various unique artefacts on a victim system, including: A registry key that contains configuration information that the malware relies on to function. A service created by the malware which is used to install itself on a victim system. A process mutex created by HyperBro to ensure that only one instance of the malware is running at any time. 1 – REGISTRY HyperBro stores configuration data in a registry key. The path of this registry key is dynamically generated based on information collected on the victim system. HyperBro queries the registry key HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 for the value of Identifier(Figure 2). The example in Figure 3 has the value Intel64 Family 6 Model 62 Stepping 4. That value is subsequently used by HyperBro to create a registry key in the HKEY_CLASSES_ROOT. In this example, the created key would be HKEY_CLASSES_ROOT\Intel64 Family 6 Model 62 Stepping 4-ll37389743nxshkhjhgee. The appended value –ll37389743nxshkhjhgee is a part of the malware’s embedded configuration and may change over time. 2 – SERVICE HyperBro installs itself to run as a service by injecting itself into a spawned svchost.exe process. The HyperBro process will be an orphaned (no parent process) svchost.exe process. 3 – MUTEX HyperBro creates a process mutex in order to ensure that only one instance of the malware is running at any given time. The name of the process mutex is created by collecting the name of the user currently logged onto the compromised system and appending a hard-coded string. Samples analysed to-date have used the string Defender. For example, if the current system profile has a username “Joe”, HyperBro will create a mutex with the name JoeDefender. IRANIAN GOVERNMENT DETECTION AND REMOVAL TOOLS When searching for HyperBro samples via the Malware Add-on for Augury, our data analyst’s portal, one particular sample stood out to us (SHA1: f7979ded11e695448c24a7a8efc1ea2649f9196c) (Figure 3): Figure 3: Sample of interest that created a process mutex associated with HyperBro We conducted some further analysis on this sample, and while it created a process mutex associated with HyperBro (PhilDefender), the functionality was vastly different from what we expected. In fact, the version information of the sample suggested that this was not HyperBro at all (Figure 4): Figure 4: Version information from sample of interest AFTA are the Iranian Cyber Security Agency. A screenshot from our malware sandbox showed the following image (Figure 5): Figure 5: Screenshot from malware sandbox The logo on the right is for AFTA. Further searches within open source associated the other logo with BitBaan, an Iranian malware analysis laboratory. BitBaan even tweeted about their APT27 remediation tools on 30 December 2019. BitBaan may be a contractor for the Iranian government and this software was developed to share with government agencies and contractors. Unpacking the sample provided us with strings – specifically contact details for AFTA – which we used to identify an archive that was submitted to VirusTotal from an Iranian IP address, with the filename AFTA-APT27-Detector.rar (SHA1: e38ab5339aef4fe8b2587e178fc38879dbc34209). The archive contains tools and documentation for detecting and removing HyperBro malware on both single workstations and a Windows domain, including the aforementioned sample that we previously identified. Each set of tools has its own directory. The tools and documentation for the “stand-alone” deployment (i.e. tools to be used on a single workstation) are in a folder named Stand-alone_APT27_afta; the contents of this folder are shown below: The tools and documentation for deployment to hosts connected to a Windows domain are in a folder named Domain_APT27_afta; the contents of this folder are shown below: The documentation describes creating a network share for storing the tools that all workstations can access. Users are then directed to use the batch script (detector3.bat) as a scheduled task on all workstations connected to the domain. Logs generated by the batch script are stored on the previously-created network share. The tool summarize-x86.exe will create a summary of the log files created by workstations that can be reviewed by network incident responders. The AFTA detection software (AFTA-APT27-Detector.exe) checks for the existence of the three indicators of compromise previously detailed in this blog (registry, service, mutex). When checking for the HyperBro service, the detection utility scans running processes and attempts to identify an orphaned svchost.exeprocess, and if successful will store the name of the DLL file linked to run using that process. The stored name of the DLL file is then used in the removal process (see below). The removal utility (AFTA-APT27-Removal.exe) will attempt to remove HyperBro (and its artefacts) from an infected host in the following order: The registry key containing the configuration data. The service installed by HyperBro, in order to prevent the malware from running again. The svchost.exe process is then terminated. The executable, DLL and payload are deleted from disk. While the discovery of these tools does not confirm the full extent of the compromise of Iranian Government systems by Emissary Panda, their existence alone indicates that the compromise was significant enough that the Iranian Cyber Security Agency (in co-operation with BitBaan) needed to develop tools and documentation to distribute across multiple networks/Windows domains.

  • Attack Surface Management: Why Maturity Models Matter – Part II

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

  • How the New Splunk App for Scout Can Enrich and Accelerate Your Investigations

    Pure Signal, the world’s largest threat intelligence data ocean is now available as a Splunk Dashboard Our mission at Team Cymru has always been to ‘save and improve human lives’. We empower defenders with the actionable intelligence they need to detect, analyze, and respond to threats quickly and effectively. With so many tools available, overwhelming volumes of alerts, and multiple dashboards, there is a strong desire to consolidate and simplify workstreams for SOC analysts. Last year, we launched Pure Signal Scout, a web-based threat-hunting and intelligence tool for security analysts of all experience levels. It features a simple GUI, graphical displays, tagged results, and easy-to-use searches to determine if suspicious IPs are malicious or compromised. Today, we proudly announce the Team Cymru Scout App for Splunk. This app is Splunk certified, and compatible with Splunk Enterprise, and Splunk Cloud (versions 9.2, 9.1, 9.0).  This free app enriches Splunk with real-time and historical threat data. How this can help you: By presenting threat data in an accessible format and providing contextual information, SOC analysts can gain an immediate understanding of cyber threats without training.  They can also create summary reports directly from within the tool for internal sharing and escalation. Key features and benefits: The Scout App for Splunk provides these datasets to help you better understand domain and IP addresses: Tags and Insights, Open Ports, PDNS, X509 Certificate details, Fingerprints, WhoIs Information, and Communication timelines. The app currently contains three Dashboards for Splunk Enterprise: Dashboard 1: Indicators Overview Dashboard This dashboard shows you any of the IOCs (IPs or domains) within Splunk with enriched data from Scout. In this view, you will see any IPs or Domains uploaded from Scout. You can search to identify any IP address or domains uploaded and get immediate data such as tags, ASN information, a summary of IPs communicated with, open ports, PDNS, fingerprints, and x509’s. These provide additional context needed to help identify malicious indicators within Splunk. This information is also available in Scout natively. Common use cases: IP and domain enrichment, alert resolution and triage, conducting more effective investigations Dashboard 2: Correlation Overview Dashboard Match any IPs or domains within your existing logs. Configure and specify the log source and field to match against and enrich. Alerting and reporting can also be created and used to generate enrichments in real-time. Common use cases: Real-time enrichments of IPs and Domains in existing log sources Dashboard 3: Live Investigation Dashboard During investigations, this dashboard will help you quickly obtain domain intelligence in context with Splunk log data. You can add and query either a domain or an IP. If you enter a Domain, this dashboard will show the related IP addresses. If you enter an IP address, you can obtain the rating information. In the example below, this IP is a known malicious IP, that is a known command and control server, it is tagged both as a RAT and a nanocore controller, as well as a Digital Ocean asset. This dashboard also provides timelines showing when ports were open and when specific tags were relevant to the IP address. This information is helpful for any investigation or incident response. Aside from this dashboard, you can also set up alerts or a notification when a specific condition occurs. There are other options to query your account history and usage for your Scout license. I invite you to try Scout Insight and the Scout App for Splunk. Getting started with the Team Cymru App for Splunk is straightforward: Visit the Scout Insight Trial page: sign up for a free, 30-day Scout trial. Navigate to the Team Cymru App for Splunk page to download the app directly from the Splunkbase and follow the installation instructions to integrate it seamlessly into your Splunk environment. Explore and Customize: Explore the features and functionalities of the app, customize dashboards to suit your specific needs, and start leveraging actionable threat intelligence to enhance your cybersecurity posture. Upload indicators via CSV file or - better option - through the API Conclusion The Team Cymru Scout App for Splunk provides immediate access to Pure Signal, the world’s largest threat intelligence data ocean. Installing the App enables you to leverage several graphical dashboards with deep IP and domain intelligence to enrich logs and datasets within Splunk. Having this data in a single place will help centralize critical data inside Splunk, so you can pivot on a domain or IP address and get the information you need to respond, further your investigation, or trigger additional actions. Next steps: Signup for Scout Insight here Download the free app from Splunkbase store

bottom of page