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.

@en

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.

@en

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.@en

Signature-based network intrusion detection systems (NIDSs) and network intrusion prevention systems (NIPSs) remain at the heart of network defense, along with the rules that enable them to detect threats. These rules allow Security Operation Centers (SOCs) to properly defend a network, yet we know almost nothing about how rules are created, evaluated and managed from an organizational standpoint. In this work, we analyze the processes surrounding the creation, management, and acquisition of rules for network intrusion detection. To understand these processes, we conducted interviews with 17 professionals who work at Managed Security Service Providers (MSSPs) or other organizations that provide network monitoring as a service or conduct their own network monitoring internally. We discovered numerous critical factors, such as rule specificity and total number of alerts and false positives, that guide SOCs in their rule management processes. These lower-level aspects of network monitoring processes have generally been regarded as immutable by prior work, which has mainly focused on designing systems that handle the resulting alert flows by dynamically reducing the number of noisy alerts SOC analysts need to sift through. Instead, we present several recommendations that address these lower-level aspects to help improve alert quality and allow SOCs to better optimize workflows and use of available resources. These recommendations include increasing the specificity of rules, explicitly defining feedback loops from detection to rule development, and setting up organizational processes to improve the transfer of tacit knowledge.@en

DNS is one of the core building blocks of the Internet. In this paper, we investigate DNS resolution in a strict IPv6-only scenario and find that a substantial fraction of zones cannot be resolved. We point out, that the presence of an AAAA resource record for a zone’s nameserver does not necessarily imply that it is resolvable in an IPv6-only environment since the full DNS delegation chain must resolve via IPv6 as well. Hence, in an IPv6-only setting zones may experience an effect similar to what is commonly referred to as lame delegation. Our longitudinal study shows that the continuing centralization of the Internet has a large impact on IPv6 readiness, i.e., a small number of large DNS providers has, and still can, influence IPv6 readiness for a large number of zones. A single operator that enabled IPv6 DNS resolution–by adding IPv6 glue records–was responsible for around 20.3% of all zones in our dataset not resolving over IPv6 until January 2017. Even today, 10% of DNS operators are responsible for more than 97.5% of all zones that do not resolve using IPv6.@en

The smishing-based malware Flubot was taken down in mid-2022, yet there is little understanding of how it directly impacted smartphone users. We engage with customers of a partner Internet Service Provider (ISP), who have suffered a Flubot infection on their smartphones. We surveyed 87 ISP customers who had been notified of a Flubot infection, in the months around and preceding the take-down of Flubot. We found that slightly over half of respondents were unaware of the malware infection before being notified, though many others had suspicions. We also observe that just over half of respondents experienced non-technical harms from the malware, with many experiencing harms before notification and several experiencing unwanted or aggressive activity from users of other infected devices. Many respondents reported not having removed the malware, while some discarded the infected device or stopped using online services in their efforts to be more secure afterwards. We offer recommendations, including that clearer guidance be sought to help users identify a malware infection (and not a focus only on prevention), and support provided for recovery from personal harms caused by mobile malware, as the impacts are not only technical.@en

For years, attackers have exploited vulnerabilities in Internet of Things (IoT) devices. Previous research has examined target selection in cybercrime, but there has been little investigation into the factors that influence target selection in attacks on IoT. This study aims to better understand how attackers choose their targets by analyzing the frequency of specific exploits in 11,893 IoT malware binaries that were distributed between 2018-2021. Our findings indicate that 78% of these binary files did not specifically target IoT vulnerabilities but rather scanned the Internet for devices with weak authentication. To understand the usage of exploits in the remaining 2,629 binaries, we develop a theoretical model from relevant literature to examine the impact of four latent variables, i.e. exposure, vulnerability, exploitability, and patchability. We collect indicators to measure these variables and find that they can explain to a significant extent (?2=0.38) why some vulnerabilities are more frequently exploited than others. The severity of vulnerabilities does not significantly increase the frequency with which they are targeted, while the presence of Proof-of-Concept exploit code does increase it. We also observe that the availability of a patch reduces the frequency of being targeted, yet that more complex patches are associated with higher frequency. In terms of exposure, more widespread device models are more likely to be targeted by exploits. We end with recommendations to disincentivize attackers from targeting vulnerabilities.@en

Researchers and practitioners often face the issue of having to attribute an IP address to an organization. For current data this is comparably easy, using services like whois or other databases. Similarly, for historic data, several entities like the RIPE NCC provide websites that provide access to historic records. For large-scale network measurement work, though, researchers often have to attribute millions of addresses. For current data, Team Cymru provides a bulk whois service which allows bulk address attribution. However, at the time of writing, there is no service available that allows historic bulk attribution of IP addresses. Hence, in this paper, we introduce and evaluate our ‘Back-to-the-Future whois’ service, allowing historic bulk attribution of IP addresses on a daily granularity based on CAIDA Routeviews aggregates. We provide this service to the community for free, and also share our implementation so researchers can run instances themselves.@en

With the emergence of remote education and work in universi- ties due to COVID-19, the ‘zoomification’ of higher education, i.e., the migration of universities to the clouds, reached the public dis- course. Ongoing discussions reason about how this shift will take control over students’ data away from universities, and may ulti- mately harm the privacy of researchers and students alike. How- ever, there has been no comprehensive measurement of universi- ties’ use of public clouds and reliance on Software-as-a-Service of- ferings to assess how far this migration has already progressed. We perform a longitudinal study of the migration to public clouds among universities in the U.S. and Europe, as well as institutions listed in the Times Higher Education (THE) Top100 between Jan- uary 2015 and October 2022. We find that cloud adoption differs between countries, with one cluster (Germany, France, Austria, Switzerland) showing a limited move to clouds, while the other (U.S., U.K., the Netherlands, THE Top100) frequently outsources universities’ core functions and services—starting long before the COVID-19 pandemic. We attribute this clustering to several socio- economic factors in the respective countries, including the general culture of higher education and the administrative paradigm taken towards running universities. We then analyze and interpret our results, finding that the implications reach beyond individuals’ pri- vacy towards questions of academic independence and integrity.@en

IP spoofing, sending IP packets with a false source IP address, continues to be a primary attack vector for large-scale Denial of Service attacks. To combat spoofing, various interventions have been tried to increase the adoption of source address validation (SAV) among network operators. How can SAV deployment be increased? In this work, we conduct the first randomized control trial to measure the effectiveness of various notification mechanisms on SAV deployment. We include new treatments using nudges and channels, previously untested in notification experiments. Our design reveals a painful reality that contrasts with earlier observational studies: none of the notification treatments significantly improved SAV deployment compared to the control group. We explore the reasons for these findings and report on a survey among operators to identify ways forward. A portion of the operators indicate that they do plan to deploy SAV and ask for better notification mechanisms, training, and support materials for SAV implementation.@en

We tracked the largest volunteer security information sharing community known to date: the COVID-19 Cyber Threat Coalition, with over 4,000 members. This enabled us to address long-standing questions on threat information sharing. First, does collaboration at scale lead to better coverage? And second, does making threat data freely available improve the ability of defenders to act? We found that the CTC mostly aggregated existing industry sources of threat information. User-submitted domains often did not make it to the CTC's blocklist as a result of the high threshold posed by its automated quality assurance using VirusTotal. Although this ensured a low false positive rate, it also caused the focus of the blocklist to drift away from domains related to COVID-19 (1.4%-3.6%) to more generic abuse, such as phishing, for which established mitigation mechanisms already exist. However, in the slice of data that was related to COVID-19, we found promising evidence of the added value of a community like the CTC: just 25.1% of these domains were known to existing abuse detection infrastructures at time of listing, as compared to 58.4% of domains on the overall blocklist. From the unique experiment that the CTC represented, we draw three lessons for future threat data sharing initiatives.@en

Consumer IoT devices may suffer malware attacks, and be recruited into botnets or worse. There is evidence that generic advice to device owners to address IoT malware can be successful, but this does not account for emerging forms of persistent IoT malware. Less is known about persistent malware, which resides on persistent storage, requiring targeted manual effort to remove it. This paper presents a field study on the removal of persistent IoT malware by consumers. We partnered with an ISP to contrast remediation times of 760 customers across three malware categories: Windows malware, non-persistent IoT malware, and persistent IoT malware. We also contacted ISP customers identified as having persistent IoT malware on their network-attached storage devices, specifically QSnatch. We found that persistent IoT malware exhibits a mean infection duration many times higher than Windows or Mirai malware; QSnatch has a survival probability of 30% after 180 days, whereby most if not all other observed malware types have been removed. For interviewed device users, QSnatch infections lasted longer, so are apparently more difficult to get rid of, yet participants did not report experiencing difficulty in following notification instructions. We see two factors driving this paradoxical finding: First, most users reported having high technical competency. Also, we found evidence of planning behavior for these tasks and the need for multiple notifications. Our findings demonstrate the critical nature of interventions from outside for persistent malware, since automatic scan of an AV tool or a power cycle, like we are used to for Windows malware and Mirai infections, will not solve persistent IoT malware infections.@en

Notwithstanding the predicted demise of signature-based network monitoring, it is still part of the bedrock of security operations. Rulesets are fundamental to the efficacy of Network Intrusion Detection Systems (NIDS). Yet, they have rarely been studied in production environments. We partner with a Managed Security Service Provider (MSSP) to gain more insight into the evolution of rulesets, the alerts that they trigger and the incidents that get investigated. We analyze a combined ruleset - including both commercial and proprietary rules - that consists of 130 thousand rules and was used to monitor hundreds of networks. We find that these rulesets keep growing over time but there is almost no overlap among them in terms of detection options or what indicators of compromise they contain. The combined ruleset triggered more than 62 million alerts and led to 150 thousand incident investigations by SOC analysts, though the vast majority of rules never triggered a single alert. We find that just 0.5% of all rules are responsible for more than 80% of the alerts and incidents and only 1.2% of all alerts were deemed to merit closer investigation. Of all incidents, 16% were labeled as false positives and 9% carried significant risk to the client organization. Independently of the type of rule, updating rules is a minor activity. Most rules are never modified and only a fraction is deleted, except for periodic purges in some sets. Seven in-depth interviews with rule developers corroborate the patterns we found in our analysis. Finally, we identify several rule management practices that influence rule and ruleset efficacy, such as supplementing commercial rules with your own and making rules as specific as possible.@en

The Internet of things (IoT) is composed by a wide variety of software and hardware components that inherently contain vulnerabilities. Previous research has shown that it takes only a few minutes from the moment an IoT device is connected to the Internet to the first infection attempts. Still, we know little about the evolution of exploit vectors: Which vulnerabilities are being targeted in the wild, how has the functionality changed over time, and for how long are vulnerabilities being targeted? Understanding these questions can help in the secure development, and deployment of IoT networks. We present the first longitudinal study of IoT malware exploits by analyzing 17,720 samples collected from three different sources from 2015 to 2020. Leveraging static and dynamic analysis, we extract exploits from these binaries to then analyze them along the following four dimensions: (1) evolution of infection vectors over the years, (2) exploit lifespan, vulnerability age, and the time-to-exploit of vulnerabilities, (3) functionality of exploits, and (4) targeted IoT devices and manufacturers. Our descriptive analysis uncovers several patterns: IoT malware keeps evolving, shifting from simply leveraging brute force attacks to including dozens of device-specific exploits. Once exploits are developed, they are rarely abandoned. The most recent binaries still target (very) old vulnerabilities. In some cases, new exploits are developed for a vulnerability that has been known for years. We find that the mean time-to-exploit after vulnerability disclosure is around 29 months, much longer than for malware targeting other environments.@en

Geographically distributed infrastructures, such as buildings, dams, and solar power plants, are commonly maintained via Internet-connected remote management devices. Previous studies on detecting and securing industrial control systems (ICS) have overlooked these remote management devices, as they do not expose ICS-specific services like Modbus and BACnet and thus do not show up in Internet-wide scans for such services. In this paper, we implement and validate a discovery method for these devices via their Web User Interface (WebUI) and detect 890 devices in Japan alone. We also show that many of these devices are highly insecure. Many allow access to the status or even the control over industrial systems without proper authentication. Taking a closer look at three prevalent remote management devices, we discovered 13 0-day vulnerabilities, several of which were rated as medium or high severity. They have been responsibly disclosed to the manufacturers. By using honeypots that imitate these systems, we show that over time, only a small number of attackers enter these systems, but some do change critical parameters. Attackers appear to interact more with the system when more facility information is displayed on the WebUI. Finally, we notified operators of 317 vulnerable remote management devices by email and telephone. We reached 212 persons in charge of the devices and received confirmation that our method had correctly identified the device. 50% of the persons in charge of the devices stated that they mitigated or will mitigate the problem. We confirmed their actions via a followup scan for vulnerable devices and found that measures were taken for 58% of the devices when we could reach the persons in charge of the device.@en

Large botnets made up of Internet-of-Things (IoT) devices have a steady presence in the threat landscape since 2016. However, it has not explained how attackers maintain control over their botnets. In this paper, we present a long-term analysis of the infrastructure of IoT botnets based on 36 months of data gathered via honeypots and the monitoring of botnet infrastructure. We collected 64,260 IoT malware samples, 35,494 download servers, and 4,736 C&C servers during 2016 to 2021. Not only are most binaries distributed for less than three days, but the connection of bots to the rest of the botnet is also short-lived. To reach the C&C server, the binaries typically contain only a single hard-coded IP address or domain. Long-term dynamic analysis finds no mechanism for the attackers to migrate the bots to a new C&C server. Although malware binaries that use domain names to connect to their C&C servers increased in 2020, the C&C servers themselves have a short lifespan and this tendency has not changed. The picture that emerges is that of highly disposable botnets. IoT botnets are reconstituted from scratch all the time rather than maintained.@en

Many consumer Internet-of-Things (IoT) devices are, and will remain, subject to compromise, often without the owner's knowledge. Internet Service Providers (ISPs) are among the actors best-placed to coordinate the remediation of these problems. They receive infection data and can notify customers of recommended remediation actions. There is insufficient understanding of what happens in peoples' homes and businesses during attempts to remediate infected IoT devices. We coordinate with an ISP and conduct remote think-aloud observations with 17 customers who have an infected device, capturing their initial efforts to follow best-practice remediation steps. We identify real, personal consequences from wide-scale interventions which lack situated guidance for applying advice. Combining observations and thematic analysis, we synthesize the personal stories of the successes and struggles of these customers. Most participants think they were able to pinpoint the infected device; however, there were common issues such as not knowing how to comply with the recommended actions, remediations regarded as requiring excessive effort, a lack of feedback on success, and a perceived lack of support from device manufacturers. Only 4 of 17 participants were able to successfully complete all remediation steps. We provide recommendations relevant to various stakeholders, to focus where emergent interventions can be improved.@en

Asset discovery is fundamental to any organization's cybersecurity efforts. Indeed, one must accurately know which assets belong to an IT infrastructure before the infrastructure can be secured. While practitioners typically rely on a relatively small set of well-known techniques, the academic literature on the subject is voluminous. In particular, the Internet measurement research community has devised a number of asset discovery techniques to support many measurement studies over the past five years. In this paper, we systematize asset discovery techniques by constructing a framework that comprehensively captures how network identifiers and services are found. We extract asset discovery techniques from recent academic literature in security and networking and place them into the systematized framework. We then demonstrate how to apply the framework to several case studies of asset discovery workflows, which could aid research reproducibility. These case studies further suggest opportunities for researchers and practitioners to uncover and identify more assets than might be possible with traditional techniques. @en

For the mitigation of compromised Internet of Things (IoT) devices we rely on Internet Service Providers (ISPs) and their users. Given that devices are in the hands of their subscribers, what can ISPs realistically do? This study examines the effects of ISP countermeasures on infections caused by variants of the notorious Mirai family of IoT malware, still among the dominant families. We collect and analyze more than 4 years of longitudinal darknet data tracking Mirai-like infections in conjunction with threat intelligence data on various other IoT and non-IoT botnets across the globe from January 2016 to May 2020. We measure the effect of two ISP countermeasures on Mirai variant infection numbers: (i) reducing the attack surface (i.e., closing ports that are used by the malware for propagation) and (ii) ISPs increasing their general network hygiene and malware removal efforts (as observed by proxy of the remediation of infections of other families of IoT and non-IoT malware and reductions in the number of DDoS amplifiers in their networks). We map our infection data to 342 broadband providers that have the bulk of the broadband market share in their respective 83 countries. We find that the number of infections correlates strongly with the number of ISP subscribers (R2=0.55$). Yet, infection numbers can still vary by three orders of magnitude even for ISPs with comparable subscriber numbers. We observe that many ISPs, together with their subscribers, have reduced their attack surface for IoT compromise by blocking traffic to commonly-exploited infection vectors such as Telnet and FTP. We statistically estimate the impact of these reductions on infection levels and, counter-intuitively, find no significant impact. In contrast, we do find a significant impact for improving general network hygiene and best malware mitigation practices. ISPs that were more successful in reducing DDoS amplifiers and non-Mirai malware infections in their networks also end up with significantly lower Mirai infection rates. In other words, rather than investing in IoT-specific countermeasures like reducing the attack surface, our findings suggest that ISPs might be better off investing in general security efforts to improve network hygiene and clean up abuse. @en

IoT devices keep entering our homes with the promise of delivering more services and enhancing user experience; however, these new devices also carry along an alarming number of vulnerabilities and security issues. In most cases, the users of these devices are completely unaware of the security risks that connecting these devices entail. Current tools do not provide users with essential security information such as whether a device is infected with malware. Traditional techniques to detect malware infections were not meant to be used by the end-user and current malware removal tools and security software cannot handle the heterogeneity of IoT devices. In this paper, we design, develop, and evaluate a tool, called NURSE, to fill this information gap, i.e., enabling end-users to detect IoT-malware infections in their home networks. NURSE follows a modular approach to analyze IoT traffic as captured by means of an ARP spoofing technique which does not require any network modification or specific hardware. Thus, NURSE provides zero-configuration IoT traffic analysis within everybody's reach. After testing NURSE in 83 different IoT network scenarios with a wide variety of IoT device types, results show that NURSE identifies malware-infected IoT devices with high-accuracy (86.7%) using device network behaviour and contacted destinations.@en