With the growing reliance on cloud services for storage and deployment, securing cloud environments has become critically important. Cloud storage solutions like AWS S3, Google Cloud Storage, and Azure Blob Storage are widely used to store vast amounts of data, including sensitive configuration files used in software development. These files often contain secrets such as API keys and credentials. Misconfigured cloud buckets can inadvertently expose these secrets, leading to unauthorized access to services and security breaches. In this work, we explore the issue of secret leaks in files exposed through misconfigured cloud storage. Our analysis covers a variety of file formats frequently used in development and focuses on different secrets that have diverse types of impact as well as the possibility for a non-intrusive validation. By systematically scanning a large collection of publicly acces-sible cloud buckets, we identified 215 instances where sensitive credentials were exposed. These secrets provide unauthorized access to services like databases, cloud infrastructure, and third-party APIs, posing significant security risks. Upon discovering these leaks, we responsibly reported them to the respective organizations and cloud service providers and measured the outcomes of the disclosure process. Our respon-sible disclosure efforts led to the remediation of 95 issues. Twenty organizations directly communicated their actions back to us, promptly addressing the issues, while the remaining fixes were implemented without direct feedback to the disclosers. Our study highlights the global prevalence of secret leaks in cloud storage and emphasizes the varied responses from organizations in mitigating these critical security risks.

More than three decades after its introduction, Role-Based Access Control (RBAC) continues to be one of the most widely used access control models in organizations. This popularity stems from its simplicity, the reduced risk of errors, and its clear alignment with business processes. However, the primarily manual nature of data management in RBAC systems, coupled with a lack of oversight, can lead to various inefficiencies over time. These may include roles that are not assigned to any users or roles that have identical sets of permissions. Such issues can slow down systems that rely on these data and, more critically, complicate auditing processes, increasing the risk of security gaps and compliance violations.In this paper, we present a taxonomy of inefficiencies that can arise in RBAC data over time and propose a framework for detecting these inefficiencies. We specifically focus on the most resource-intensive inefficiencies, namely roles that share the same or similar users or permissions. To address these issues, we propose three detection methods, including a custom algorithm we developed. We evaluate these methods using synthetic datasets, demonstrating that our algorithm significantly outperforms baseline approaches. Its efficiency allows us to identify these inefficiencies even on a standard laptop used by large organizations. Furthermore, we applied our framework to real RBAC data from a large organization with over 60,000 employees and uncovered a substantial number of inefficiencies, highlighting its practical value in real-world scenarios.

Endpoint Detection and Response (EDR) systems provide continuous monitoring, threat detection, and response capabilities. This has driven their widespread adoption in enterprises, making them a key part of an enterprise's security architecture. However, EDR systems are a double-edged sword, and in this study, we demonstrate how this class of systems can be employed for offensive use. Unlike prior studies that focused on evasion and tampering, we introduce the new concept of EDR repurposing, which we call EvilEDR. Our analysis shows that EvilEDR can be used to execute arbitrary commands via the response console, transfer tools, exfiltrate data, and passively collect system information to facilitate further exploitation and lateral movement. EvilEDR operates covertly, masquerading as a legitimate process and communicating seamlessly with trusted domains. Additionally, we show that EvilEDR can impair defenses by registering its own EPP as the default. It can also isolate the host from the network, severing telemetry and response channels essential for enterprise defense mechanisms. Fortunately, EvilEDR can be effectively detected and mitigated, and in this paper, we propose concrete and actionable defense strategies to achieve this.

As ransomware attacks grow in frequency and complexity, accurate attribution is crucial. Victim organizations often feel compelled to pay ransom, but must first attribute the attack and conduct sanction screening to ensure the threat actor receiving the payment is not a sanctioned entity, avoiding severe legal and financial risks. This cyber threat actor attribution process typically relies on Indicators of Compromise (IoCs) matching known threat profiles. However, the emergence of the Ransomware-as-a-Service (RaaS) ecosystem and rebranding behavior complicate attribution for sanction screening. Our mixed-methods study, combining interviews with 20 experts with an analysis of ransomware incident reports, reveals significant challenges and limitations in the current attribution process. High-level IoCs, widely regarded as more reliable, lack the necessary specificity for accurate attribution, leading to potential risks of misattribution. Practitioners rely on lower-level IoCs, which provide clearer links to threat actors but are highly volatile, further complicating sanction enforcement. These challenges highlight the need for urgent improvements in the attribution and sanction processes. To mitigate these risks, we offer recommendations aimed at enhancing data-sharing practices, improving attributions frameworks, and refining the sanction violation policy to better support sanction screening efforts. While we do not recommend paying ransomware actors, we acknowledge that some organizations may face pressures to do so in certain situations. In such cases, it is vital to ensure legal compliance, particularly regarding sanctioned entities. This work aims to help victims of ransomware shield themselves from transgressing against sanctions.

Internet-wide scanning services are widely used for attack surface discovery across organizations and the Internet. Enterprises, government agencies, and researchers rely on these tools to assess risks to Internet-facing infrastructure. However, their reliability and trustworthiness remain largely unexamined. This paper addresses this gap by comparing results from three commercial scanners – Shodan, ONYPHE, and LeakIX – with findings from our independent experiments using verified Nuclei templates, designed to identify specific vulnerabilities through crafted benign requests. We found that the payload based detections of Shodan are mostly confirmed. Yet, Nuclei finds many more vulnerable endpoints, so defenders might face massive underreporting. For Shodan’s banner-based detections, the opposite issue arises: a significant overreporting of false positives. This indicates that banner-based detections are unreliable. Moreover, three commercial services and Nuclei scans exhibit significant discrepancies. Our work has implications for industry users, policymakers, and the many academic researchers who rely on the results provided by these attack surface management services. By highlighting their shortcomings in vulnerability monitoring, this work serves as a call for action to advance and standardize such services to enhance their trustworthiness.

Distributed Denial-of-Service (DDoS) attacks continue to threaten the availability of Internet-based services. While countermeasures exist to decrease the impact of these attacks, not all operators have the resources or knowledge to deploy them. Alternatively, anti-DDoS services such as DDoS clearing houses and blackholing have emerged. Unwanted Traffic Removal Service (UTRS), being one of the oldest community-based anti-DDoS services, has become a global free collaborative service that aims at mitigating major DDoS attacks through the Border Gateway Protocol (BGP). Once the BGP session with UTRS is established, UTRS members can advertise part of the prefixes belonging to their AS to UTRS. UTRS will forward them to all other participants, who, in turn, should start blocking traffic to the advertised IP addresses. In this paper, we develop and evaluate a methodology to automatically detect UTRS participation in the wild. To this end, we deploy a measurement infrastructure and devise a methodology to detect UTRS-based traffic blocking. Using this methodology, we conducted a longitudinal analysis of UTRS participants over ten weeks. Our results show that at any point in time, there were 562 participants, including multihomed, stub, transit, and IXP ASes. Moreover, we surveyed 245 network operators to understand why they would (not) join UTRS. Results show that threat and coping appraisal significantly influence the intention to participate in UTRS.

Remotely Triggered Black Hole (RTBH) is a common DDoS mitigation approach that has been in use for the last two decades. Usually, it is implemented close to the attack victim in networks sharing some type of physical connectivity. The Unwanted Traffic Removal Service (UTRS) project offers a free, global, and relatively low-effort-to-join and operate RTBH alternative by removing the requirement of physical connectivity. Given these unique value propositions of UTRS, this paper aims to understand to what extent UTRS is adopted and used to mitigate DDoS attacks. To reach this goal, we collected two DDoS datasets describing amplification and Internet-of-Things-botnet-driven attacks and correlated them with the information from the third dataset containing blackholing requests propagated to the members of UTRS. Our findings suggest that, currently, just a small portion of UTRS members (approximately 10 % ) trigger mitigation attempts: out of 1200+ UTRS members, only 124 triggered blackholing events during our study. Among those, with high probability, 25 Autonomous Systems (ASes) reacted on AmpPot attacks mitigating 0.025 % of them globally or 1.03 % targeting UTRS members; 2 countered IoT-botnet-driven attacks alleviating 0.001 % of them globally or 0.06 % targeting UTRS members. This suggests that UTRS can be a useful tool in mitigating DDoS attacks, but it is not widely used.

A reduction in phishing threats is of increasing importance to organizations. One part of this effort is to provide training to employees, so that they are able to identify and avoid phishing emails. Yet further, simulated phishing emails are used to test whether employees will both identify and report a suspicious email. We worked with a partner bank to examine a repository of many thousands of reported emails from a behavioural perspective. We divide reported emails into categories and examine reporting trends over time relative to training and phishing simulation campaigns. Among our findings, the level of reporting of benign emails is comparable to the number of malicious emails reported, and we see indications that training and simulations amplify the reporting of benign emails. Our analysis uncovers reporting patterns for unique reporters per email campaign as a promising indicator for the security-related culture around phishing prevention. Evidence from our analysis informs recommendations, such as providing reporting infrastructure for reporting not only malicious emails, but also benign but suspicious work-related emails, in a manner that minimises the disruption for users erring on the side of caution when assessing emails.

Many organizations continue to expose vulnerable systems for which patches exist, opening themselves up for cyberattacks. Local governments are found to be especially affected by this problem. Why are these systems not patched? Prior work relied on vulnerability scanning to observe unpatched systems, notification studies on remediating them, and on user studies of sysadmins to describe self-reported patching behavior, but they are rarely used together as we do in this study. We analyze scan data following standard industry practices and detect unpatched hosts across the set of 322 Dutch municipalities. Our first question is: Are these detections false positives? We engage with 29 security professionals working for 54 municipalities to collect ground truth.

All detections were accurate. Our approach also uncovers a major misalignment between systems that the responsible CERT attributes to the municipalities and the systems the practitioners at municipalities believe they are responsible for. We then interviewed the professionals as to why these vulnerable systems were still exposed. We identify four explanations for non-patching: unaware, unable, retired and shut down. The institutional framework to mitigate cyber threats assumes that vulnerable systems are first correctly identified, then correctly attributed and notified, and finally correctly mitigated. Our findings illustrate that the first assumption is correct, the second one is not and the third one is more complicated in practice. We end with reflections on how to better remediate vulnerable hosts.

Organizations are increasingly reliant on third-party software products to expedite their own development cycles, often incorporating numerous components into their end systems, resulting in a lack of transparency in software dependencies. Malicious actors exploit this, leading to Software Supply Chain (SSC) attacks with substantial economic and security damages. To mitigate this threat, the Software Bill of Materials (SBOM) concept was introduced. It details software components and their supply chain relationships, thus enhancing SSC transparency. Unfortunately, SBOM adoption still remains limited. While previous studies identified some reasons behind this, they overlooked the perspectives of different business stakeholder groups involved in SBOM's lifecycle.

In this work, we address this gap by studying business stakeholder groups directly involved in SBOM production and consumption. The main goal of this work is to identify which groups can drive or inhibit SBOM adoption and the rationale behind this behavior. By conducting interviews with the group representatives, we identified stakeholder-specific risks, benefits, concerns and incentives regarding SBOM adoption. Our analysis suggests that SBOM adoption potential is higher among System Integrators and Software Vendors. At the same time, B2B customers and Individual Developers have the least motivation, inhibiting the process of SBOM adoption. Given that these are the main SBOM consuming and supplying stakeholders correspondingly, we conclude that the overall adoption potential of this technology is currently limited and requires considerable external impulse.

Large- and medium-sized organizations employ various security systems to protect their assets. These systems, often developed by different vendors, focus on different threats and usually work independently. They generate separate and voluminous alerts that have to be monitored and analyzed by often overburdened security analysts. Prior work has tried to support analysts by better correlating and prioritizing alerts. In this work, we propose to combine the wisdom of individual security systems using an Integration Layer (IL). We validated our idea by deploying the IL in a large global organization (50,000+ employees) running four very different security detection systems. We did so by using end-to-end red-team exercises to generate real attack data. For training, we labeled our dataset with evaluations directly from the incident response team instead of using the escalated decisions of the first/second tier Security Operation Center (SOC) analysts as in prior works. We showed that our approach considerably reduces the number of alerts requiring investigation while maintaining very high performance on multi-step attack detection - Matthews correlation coefficient (MCC) reaches 0.998. The substantial dependence of the model on features derived from the different security systems supports the viability of our integration methodology. The explainability layer added to our system gives analysts insights into why a particular case is marked as an attack or non-attack. Based on the test results, our approach has been added to the production setup.

The AI Act represents a significant legislative effort by the European Union to govern the use of AI systems according to different risk-related classes, imposing different degrees of compliance obligations to users and providers of AI systems. However, it is often critiqued due to the lack of general public comprehension and effectiveness regarding the classification of AI systems to the corresponding risk classes. To mitigate these shortcomings, we propose a Decision-Tree-based framework aimed at increasing legal compliance and classification clarity. By performing a quantitative evaluation, we show that our framework is especially beneficial to individuals without a legal background, allowing them to enhance the accuracy and speed of AI system classification according to the AI Act. The qualitative study results show that the framework is helpful to all participants, allowing them to justify intuitively made decisions and making the classification process clearer.

The AI Act represents a significant legislative effort by the European Union to govern the use of AI systems according to different risk-related classes, linking varying degrees of compliance obligations to the system's classification. However, it is often critiqued due to the lack of general public comprehension and effectiveness regarding the classification of AI systems to the corresponding risk classes. To mitigate those shortcomings, we propose a Decision-Tree-based framework aimed at increasing robustness, legal compliance and classification clarity with the Regulation. Quantitative evaluation shows that our framework is especially useful to individuals without a legal background, allowing them to improve considerably the accuracy and significantly reduce the time of case classification.

DNS is a protocol responsible for translating human-readable domain names into IP addresses. Despite being essential for many Internet services to work properly, it is inherently vulnerable to manipulation. In November 2021, users from Mexico received bogus DNS responses when resolving whatsapp.net. It appeared that a BGP route leak diverged DNS queries to the local instance of the k-root located in China. Those queries, in turn, encountered middleboxes that injected fake DNS responses. In this paper, we analyze that event from the RIPE Atlas point of view and observe that its impact was more significant than initially thought—the Chinese root server instance was reachable from at least 15 countries several months before being reported. We then launch a nine-month longitudinal measurement campaign using RIPE Atlas probes and locate 11 probes outside China reaching the same instance, although this time over IPv6. More broadly, motivated by the November 2021 event, we study the extent of DNS response injection when contacting root servers. While only less than 1% of queries are impacted, they originate from 7% of RIPE Atlas probes in 66 countries. We conclude by discussing several countermeasures that limit the probability of DNS manipulation.