In this paper, we study the experiences of practitioners in sectoral Computer Security Incident Response Teams (CSIRTs)—specialized teams that mediate between national cybersecurity authorities and the sector constituency. Through interviews with 18 professionals connected to the Informatiebeveiligingsdienst (IBD-CSIRT) for Dutch local governments, we uncover tensions in how key services are valued. For vulnerability notifications, while the CSIRT staff consider them a core service, many constituents hardly mention them, and systemic gaps in information forwarding mean that crucial alerts often never arrive. We extend these insights with 5 interviews across other sector CSIRTs and a validation workshop with 7 participants, all security officers from sector CSIRTs, revealing shared challenges in balancing technical expertise with sector knowledge, building trust-based relationships, and navigating institutional bottlenecks. Our findings contribute the first systematic account of how sector CSIRT professionals understand and perform their role, highlighting the tensions in providing sector-wide support to professionals with differing security needs.

Child sexual abuse material (CSAM) presents a critical challenge for online safety, yet the verification procedures that determine which items are classified as CSAM remain poorly understood. Triple verification (requiring three reviewers to agree) is promoted as a safeguard, but little is known about how it is implemented, how it is perceived by experts, and how voting conditions affect reliability. We address this gap through a mixed-methods study. We interviewed 14 experts from seven organizations (e.g., law enforcement, hotlines, etc.) to map current verification practices, then ran an inter-reliability experiment with Dutch National Police experts who reviewed 2,031 images and videos under different voting conditions (blind vs. non-blind, varied order). Finally, we held a focus group to explore the reasons behind disagreements. We find that practices vary widely, perceptions of triple verification reflect both safeguards and burdens, and expert agreement depends on voting conditions and content type.

Visual Studio Code (VS Code) is one of the most widely used code editors, and its extension ecosystem has increasingly become a target for software supply chain attacks. Developing and validating effective detection techniques in this area requires ground-truth data with both benign and malicious samples. While benign samples are easy to obtain, no publicly available or continuously updated dataset exists for malicious VS Code extensions. To address this gap, we built VSMEx, a continuously updated dataset of malicious VS Code extensions derived from Microsoft's official malicious and removed lists. Over a deployment period of more than three months, VSMEx successfully captured 214 extensions, demonstrating the viability of our approach. In this work, we present an initial analysis of the resulting dataset and share the associated metadata and the list of flagged or removed extensions collected during this period. In addition, we provide controlled access to the dataset itself, facilitating further research and contributing to the security of the VS Code ecosystem. Note that VSMEx continues to operate, making the resulting dataset well suited for training and validation in continuous machine learning settings.

Exposing intrusion campaigns has become a geopolitical tool, with governments and commercial firms publishing threat intelligence reports about hacking attempts and modus operandi. U.S. government officials have explained this as not just a defensive practice but also as a way to 'impose cost' on attackers by forcing them to develop new infrastructure, tools, and techniques. We empirically examine this claim by analyzing attacker behavior before and after publication of indicators of compromise (IOCs). Using IOC feeds from two leading commercial providers, we matched IOCs against a large dataset of real-world network traffic metadata. This enabled us to generate sightings retroactively, capturing malicious activity up to 150 days before and after publication. Unlike prior work focused on post-publication malicious activity, our method provides a more complete view over time. Our results show that most IOCs point to resources that attackers had already abandoned by publication, limiting their utility for detecting ongoing attacks and undermining the idea of 'imposing costs'. Statistical modeling further reveals that publication status has low explanatory power for sightings, suggesting that confounding variables exist. We also observed a 30-day delay between the peak of threat actor activity and IOC publication for one provider. This study is the first empirical assessment linking threat intelligence publication to attacker behavior, bridging computer science and international relations.

In this study, we present a 532-day longitudinal analysis of LockBit 3.0’s leak site. We track 1,856 victims across multiple states-countdown, data publication, deletion, and relisting-and reconstruct a structured, three-stage extortion lifecycle: (1) pre-listing negotiation, (2) countdown negotiation, and (3) post-leak monetization. We find that $8.5 \%$ of countdownstate victims are deleted before their data is published, suggesting private settlements. In the post-leak phase, victims with price tags exhibit significantly more variable deletion timing compared to those without, despite sharing the same median exposure. This indicates that LockBit actively manages some listings after data publication, potentially extending monetization or negotiation efforts.We also measure the operational impact of law enforcement actions-including Operation Cronos and affiliate arrests-on LockBit’s infrastructure and victim activity. While the group rapidly restored services after takedowns, we observe a sustained decline in new victim onboarding, reduced infrastructure redundancy, and delayed payment behavior, suggesting long-term weakening.To our knowledge, this is the first empirical study to model a ransomware extortion lifecycle based on continuous monitoring of leak site behavior. Our findings provide actionable insights into ransomware monetization tactics, negotiation patterns, and post-takedown adaptation.

Many enterprises struggle to apply security patches in time to remove the risk of security breaches. Delays can be attributed to technical dependencies, outdated asset inventories, and issues of scale. Governments have started pursuing a strategy of mandating through regulation the patching of a highly selective set of severe vulnerabilities under very strict deadlines. We worked with a large organization to examine the patching timelines under these regulatory deadlines. We analyze patching ticket-system entries for 81 security advisories over seven years, covering 944 CVEs. We complement this with nine interviews with professionals involved in managing patches. We find that 40.2% of advisories required patching action, with a median completion time of 13.2 days; advisories that do not end in requiring a patch have a median of 1.4 days. Completing the patching process in 48 hours - a recommended industry best practice - is achieved in just 16.2% of the cases. For the deadline of one week, under the Dutch BIO regulation, patching is achieved in 32.4% of the cases, while the performance against the typical CISA KEV deadlines is a bit more hopeful: 56.8% is patched in two weeks and 62.2% in three weeks. We find that some variance in delays can be explained by coordination effort, as measured by the number of involved teams and people. Overall, the strategy of regulatory deadlines for a highly selective set of priority vulnerabilities is associated with much faster enterprise patching. The deadlines are routinely missed, yet they need to trade off realism versus exposure. The three-week KEV deadline is more feasible than the 48-hour one, yet it also leaves open a longer exposure window for exploitation.

The menace of malicious websites, such as online scams or phishing, has exhibited a noteworthy surge. While URL-based blocklists are still used as the primary security solution, previous studies show that the range of protection provided by these lists has little overlap, and the demand to have a second opinion is growing. In this paper, we design a system that aggregates information from multiple security engines in VirusTotal and warns users with malicious URLs that a single antivirus product would dismiss. We introduce VT-SOS, a system utilizing VirusTotal to provide a Second Opinion. Using 47 days of web access logs of real users, we implemented VT-SOS and evaluated effectiveness, affordability, and usability. By simulation, we show that VT-SOS could warn more than 100 users/day and provide a second opinion for more than 30 URLs/day even under a tight budget. We compared VT-SOS with three popular security services and confirmed that it could cover a wider range of malicious websites than those services. By investigating the worst-case user with the most access and warning, we demonstrate that VT-SOS will not deeply affect user experience in practice.

The enduring problems with IoT security has shifted the attention of researchers and governments to the role of vendors. The security community is no stranger to the repeated claim that vendors are dropping the ball on security and privacy, with numerous papers highlighting the many vulnerabilities in IoT products. Are IoT-centric vendors performing worse than other vendors in the industry? To answer this question, we need to do more than simply count the number of vulnerabilities disclosed by each vendor. In our study we analyze the factors influencing the number of vulnerabilities per vendor, like its size, its location and the presence of a vulnerability disclosure policy. We then statistically estimate if IoT-centric vendors produce more vulnerabilities, while controlling for those other factors. The answer is that they do. We can more directly observe the security performance of a vendor by looking at its patching behavior. We collect a unique dataset on the availability and timeliness of patches for 2,741 IoT and non-IoT vulnerabilities from 104 leading vendors. We also collect data on a set of potential causal factors for vendor patching performance. This allows us to estimate a statistical model of factors to explain why some vendors do better than others. We find that IoT-centric vendors are no worse in terms of releasing patches for their vulnerabilities, in fact, they tend to release more patches on-time than non-IoT-centric vendors. Our study increases our understanding of the factors shaping IoT security and provides an empirical basis for regulatory interventions that aim to improve the security performance of IoT vendors.

Many studies have discovered internet-facing systems exposing services that are vulnerable to attack. These are often assumed to be misconfigured systems that are not meant to expose these services to the network, especially not in an enterprise network. In this study, we clarify the causes of the presence of IoT devices exposing Telnet and FTP in a university enterprise network. This also helps us to understand who is responsible. We scanned the network and found 185 IoT devices consisting of 30 device models exposing Telnet and 49 models exposing FTP. We sent out a security notification and a survey to device owners. The survey demonstrated that 2 out of 21 and 8 out of 41 owners intentionally enabled Telnet and FTP, respectively, on all their devices. After receiving the notification, 38 out of 47 owners said they were willing to take measures on at least one of their IoT devices. All except one of the devices of these willing owners were successfully remediated. When we investigated the manuals of the devices, we were able to confirm that there was no disclosure whatsoever of the exposed service in 15 out of 30 manuals for models with Telnet and 10 out of 49 manuals for models with FTP. We also confirmed, by combining a survey of the manufacturers with the device manuals, that 22 out of 30 and 29 out of 49 devices enabled Telnet and FTP by default, respectively. From the above results, we conclude that the presence of misconfigured devices was less driven by human errors of the owners and more by the choices of the manufacturers. The majority of owners were motivated to remediate the security risks once made aware of them.

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.

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.

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 (R2=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.

The number of published software vulnerabilities is increasing every year. How do organizations stay in control of their attack surface despite their limited staff resources? Prior work has analyzed the overall software vulnerability ecosystem as well as patching processes within organizations, but not how these two are connected.We investigate this missing link through semi-structured interviews with 22 organizations in critical infrastructure and government services. We analyze where in these organizations the responsibility is allocated to collect and triage information about software vulnerabilities, and find that none of our respondents is acquiring such information comprehensively, not even in a reduced and aggregated form like the National Vulnerability Database (NVD). This means that information on known vulnerabilities will be missed, even in critical infrastructure organizations. We observe that organizations apply implicit and explicit coping mechanisms to reduce their intake of vulnerability information, and identify three trade-offs in these strategies: independence, pro-activeness and formalization.Although our respondents’ behavior is in conflict with the widely accepted security advice to collect comprehensive vulnerability information about active systems, no respondents recall having experienced a security incident that was associated with missing information on a known software vulnerability. This suggests that, given scarce resources, reducing the intake of vulnerability information by up to 95% can be considered a rational strategy. Our findings raise questions about the allocation of responsibility and accountability for finding vulnerable systems, as well as suggest changing expectations around collecting vulnerability information.

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.

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.

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.

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.

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.

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 ($R^{2}=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.

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.

Large botnets made up of Internet-of-Things (IoT) devices have been a steady presence in the threat landscape since 2016. Earlier research has found preliminary evidence that the IoT binaries and C&C infrastructure were only seen for very brief periods. It has not explained how attackers maintain control over their botnets. We present a more comprehensive analysis of the infrastructure of IoT botnets based on 23 months of data gathered via honeypots and the monitoring of botnet infrastructure. We collected 59,884 IoT malware samples, 35,494 download servers, and 2,747 C&C servers. We focuse on three dominant families: Bashlite, Mirai, and Tsunami. The picture that emerges is that of highly disposable botnets. IoT botnet are not so much maintained as reconstituted from scratch all the time. Not only are most binaries distributed for less than three days, 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. The C&C servers themselves also have a short lifespan. Long-term dynamic analysis finds no mechanism for the attackers to migrate the bots to a new C&C server. In other words, bots are used only immediately after capture and then abandoned---perhaps to be recaptured again via the aggressive scanning practices that these botnets are known for. While IoT botnets appear less advanced than Windows-based botnets, the advantage of being disposable means that they are very resistant to blacklisting and C&C takedown. Most IP addresses are used only once and never seen again. The question that arises is how attackers source these addresses. We speculate that they might be abusing the IP address allocation practices of cloud providers.

Many cybercriminal entrepreneurs lack the skills and techniques to provision certain parts of their business model, leading them to outsource these parts to specialized criminal vendors. Online anonymous markets, from Silk Road to AlphaBay, have been used to search for these products and contract with their criminal vendors. While one listing of a product generates high sales numbers, another identical listing fails to sell. In this paper, we investigate which factors determine the performance of cybercrime products.

Mechanisms for large-scale vulnerability notifications have been confronted with disappointing remediation rates. It has proven difficult to reach the relevant party and, once reached, to incentivize them to act. We present the first empirical study of a potentially more effective mechanism: quarantining the vulnerable resource until it is remediated. We have measured the remediation rates achieved by a medium-sized ISP for 1, 688 retail customers running open DNS resolvers or Multicast DNS services. These servers can be abused in UDP-based amplification attacks. We assess the effectiveness of quarantining by comparing remediation with two other groups: one group which was notified but not quarantined and another group where no action was taken. We find very high remediation rates for the quarantined users, 87%, even though they can self-release from the quarantine environment. Of those who received the email-only notification, 76% remediated. Surprisingly, over half of the customers who were not notified at all also remediated, though this is tied to the fact that many observations of vulnerable servers are transient. All in all, quarantining appears more effective than other notification and remediation mechanisms, but it is also clear that it can not be deployed as a general solution for Internet-wide notifications.

Internet security and technology policy research regularly uses technical indicators of abuse to identify culprits and to tailor mitigation strategies. As a major obstacle, current inferences from abuse data that aim to characterize providers with poor security practices often use a naive normalization of abuse (abuse counts divided by network size) and do not take into account other inherent or structural properties of providers. Even the size estimates are subject to measurement errors relating to attribution, aggregation, and various sources of heterogeneity. More precise indicators are costly to measure at Internet scale. We address these issues for the case of hosting providers with a statistical model of the abuse data generation process, using phishing sites in hosting networks as a case study. We decompose error sources and then estimate key parameters of the model, controlling for heterogeneity in size and business model. We find that 84% of the variation in abuse counts across 45,358 hosting providers can be explained with structural factors alone. Informed by the fitted model, we systematically select and enrich a subset of 105 homogeneous “statistical twins” with additional explanatory variables, unreasonable to collect for all hosting providers. We find that abuse is positively associated with the popularity of websites hosted and with the prevalence of popular content management systems. Moreover, hosting providers who charge higher prices (after controlling for level differences between countries) witness less abuse. These structural factors together explain a further 77% of the remaining variation. This calls into question premature inferences from raw abuse indicators about the security efforts of actors, and suggests the adoption of similar analysis frameworks in all domains where network measurement aims at informing technology policy.

A variety of botnets are used in attacks on financial services. Banks and security firms invest a lot of effort in detecting and combating malware-assisted takeover of customer accounts. A critical resource of these botnets is their command-and-control (C&C) infrastructure. Attackers rent or compromise servers to operate their C&C infrastructure. Hosting providers routinely take down C&C servers, but the effectiveness of this mitigation strategy depends on understanding how attackers select the hosting providers to host their servers. Do they prefer, for example, providers who are slow or unwilling in taking down C&Cs? In this paper, we analyze 7 years of data on the C&C servers of botnets that have engaged in attacks on financial services. Our aim is to understand whether attackers prefer certain types of providers or whether their C&Cs are randomly distributed across the whole attack surface of the hosting industry. We extract a set of structural properties of providers to capture the attack surface. We model the distribution of C&Cs across providers and show that the mere size of the provider can explain around 71% of the variance in the number of C&Cs per provider, whereas the rule of law in the country only explains around 1%. We further observe that price, time in business, popularity and ratio of vulnerable websites of providers relate significantly with C&C counts. Finally, we find that the speed with which providers take down C&C domains has only a weak relation with C&C occurrence rates, adding only 1% explained variance. This suggests attackers have little to no preference for providers who allow long-lived C&C domains.

Hosting providers play a key role in fighting web compromise, but their ability to prevent abuse is constrained by the security practices of their own customers. Shared hosting, offers a unique perspective since customers operate under restricted privileges and providers retain more control over configurations. We present the first empirical analysis of the distribution of web security features and software patching practices in shared hosting providers, the influence of providers on these security practices, and their impact on web compromise rates. We construct provider-level features on the global market for shared hosting -- containing 1,259 providers -- by gathering indicators from 442,684 domains. Exploratory factor analysis of 15 indicators identifies four main latent factors that capture security efforts: content security, webmaster security, web infrastructure security and web application security. We confirm, via a fixed-effect regression model, that providers exert significant influence over the latter two factors, which are both related to the software stack in their hosting environment. Finally, by means of GLM regression analysis of these factors on phishing and malware abuse, we show that the four security and software patching factors explain between 10% and 19% of the variance in abuse at providers, after controlling for size. For web-application security for instance, we found that when a provider moves from the bottom 10% to the best-performing 10%, it would experience 4 times fewer phishing incidents. We show that providers have influence over patch levels--even higher in the stack, where CMSes can run as client-side software--and that this influence is tied to a substantial reduction in abuse levels.

Over the years cybercriminals have misused the Domain Name System (DNS) - a critical component of the Internet - to gain profit. Despite this persisting trend, little empirical information about the security of Top-Level Domains (TLDs) and of the overall 'health' of the DNS ecosystem exists. In this paper, we present security metrics for this ecosystem and measure the operational values of such metrics using three representative phishing and malware datasets. We benchmark entire TLDs against the rest of the market. We explicitly distinguish these metrics from the idea of measuring security performance, because the measured values are driven by multiple factors, not just by the performance of the particular market player. We consider two types of security metrics: occurrence of abuse and persistence of abuse. In conjunction, they provide a good understanding of the overall health of a TLD. We demonstrate that attackers abuse a variety of free services with good reputation, affecting not only the reputation of those services, but of entire TLDs. We find that, when normalized by size, old TLDs like .com host more bad content than new generic TLDs. We propose a statistical regression model to analyze how the different properties of TLD intermediaries relate to abuse counts. We find that next to TLD size, abuse is positively associated with domain pricing (i.e. registries who provide free domain registrations witness more abuse). Last but not least, we observe a negative relation between the DNSSEC deployment rate and the count of phishing domains.

Over the past decade, considerable research effort has been devoted to articulating and measuring the various ways through which cyber crime impacts overall society. The large volume of literature on the topic contains few attempts to produce estimates of the financial impact of specific cyber incidents and little agreement on how to derive such estimates. An important substrata of this literature focuses on placing a monetary value on the costs of cyber crime but little is known about the long-term economic impact to society. In this article, we first assess the shortcomings of existing cost estimates and focus on the relevant issues pertinent to the feasibility of deriving valid and useful estimates beyond cost-benefit analyses. Following a mixed top-down/bottom-up methodology, we propose a theoretical framework to systematically identify the short and long-term impacts of cyber crime both at the agent and societal level. This framework serves as the foundation to assess the economic consequences of cyber crime beyond monetary costs by focusing on the impact on economic growth.

Hosting services are associated with various security threats, yet the market has barely been studied empirically. Most security research has relied on routing data and equates providers with Autonomous Systems, ignoring the complexity and heterogeneity of the market. To overcome these limitations, we combined passive DNS data with WHOIS data to identify providers and some of their properties. We found 45,434 hosting providers, spread around a median address space size of 1,517 IP addresses. There is surprisingly little consolidation in the market, even though its services seem amenable to economies of scale. We applied cluster analysis on several measurable characteristics of providers. This uncovered a diverse set of business profiles and an indication of what fraction of the market fits each profile. The profiles are associated with significant differences in security performance, as measured by the uptime of phishing sites. This suggests the approach provides an effective way for security researchers to take the heterogeneity of the market into account.

Many cybersecurity problems occur on a worldwide scale, but we lack rigorous methods for determining how best to intervene and mitigate damage globally, both short- and long-term. Analysis of longitudinal security data can provide insight into the effectiveness and differential impacts of security interventions on a global level. In this paper we consider the example of spam, studying a large high-resolution data set of messages sent from 260 ISPs in 60 countries over the course of a decade. The statistical analysis is designed to avoid common pitfalls that could lead to erroneous conclusions. We show how factors such as geography, national economics, Internet connectivity and traffic flow impact can affect local spam concentrations. Additionally, we present a statistical model to study temporal transitions in the dataset, and we use a simple extension of the model to investigate the effect of historical botnet takedowns on spam levels. We find that in aggregate most historical takedowns are beneficial in the short-term, but few have long-term impact. Further, even when takedowns are effective globally, they can be detrimental in specific geographic regions or countries. The analysis and modeling described here are based on a single data set. However, the techniques are general and could be adapted to other data sets to help improve decision making about when and how to deploy security interventions.

Botnets continue to pose a significant threat to network-based applications and communications over the Internet. A key mitigation strategy has been to take down command and control infrastructure of the botnets. The efficiency of those mitigation methods has not been extensively studied. In this paper we investigate several observable characteristics of botnet command and controls (C&C) and estimate the variability in the survival rate of these C&Cs and the factors that are related to such variability. Furthermore, we show that different type of mitigation efforts have different impact. Kaplan-Meier analysis is performed to evaluate C&C survival ratios in the particular case of the ZeuS botnet. Using a lasso penalized Cox regression model, we identify the factors that influence the lifetime of a C&C. Location, malware family type, registrar, hosting type and popularity are the fundamental factors that explain this variability. Our results show that location and type of hosting are the two factors that affect more significantly the C&C lifetime. Thus, ZeuS C&Cs in certain regions of Asia are prone to stay online longer that those located in Europe.

IP address counts are typically used as a surrogate metric for the number of hosts in a network, as in the case of ISP rankings based on botnet infected addresses. However, due to effects of dynamic IP address allocation, such counts tend to overestimate the number of hosts, sometimes by an order of magnitude. In the literature, the rate at which hosts change IP addresses is referred to as DHCP churn. Churn rates vary significantly within and among ISP networks, and such variation poses a challenge to any research that relies upon IP addresses as a metric. We present the first attempt towards estimating ISP and Internet-wide DHCP churn rates, in order to better understand the relation between IP addresses and hosts, as well as allow us to correct data relying on IP addresses as a surrogate metric. We propose an scalable active measurement methodology and then validate it using ground truth data from a medium-sized ISP. Next, we build a statistical model to estimate DHCP churn rates and validate against the ground truth data of the same ISP, estimating correctly 72.3% of DHCP churn rates. Finally, we apply our measurement methodology to four major ISPs, triangulate the results to another Internet census, and discuss the next steps to more precisely estimate DHCP churn rates.