Malware is recognized as one of the most severe cybersecurity threats today. Although malware attacks are as old as the Internet, our understanding of which part of the Internet infrastructure is used to distribute malware software is still rather limited.
In this work, we analyze more than 3 million sessions established with honeypots deployed in 55 countries that are associated with the download and execution of malware binaries. We identify two main tactics to load malware to infected machines: injection of malware by hosts initiating the connection (clients) and downloading malware from third parties (loaders). The latter tactic contributes to more than 80% of this class of sessions but involves a smaller number of cloud and content delivery servers with very different profiles than that of the clients. Our analysis also shows that it is not uncommon for different malware families to rely on the same hosting infrastructures for downloading malware. Further investigation into the code executed to download and activate malware shows that criminals tend to hide their traces by deleting their history and modifying logs and files on the compromised machines.@en

Honeypots have been used for decades to detect, monitor, and understand attempts of unauthorized use of information systems. Previous studies focused on characterizing the spread of malware, e.g., Mirai and other attacks, or proposed stealthy and interactive architectures to improve honeypot efficiency.

In this paper, we present insights and benefits gained from collaborating with an operational honeyfarm, i.e., a set of honeypots distributed around the globe with centralized data collection. We analyze data of about 400 million sessions over a 15-month period, gathered from a globally distributed honeyfarm consisting of 221 honeypots deployed in 55 countries. Our analysis unveils stark differences among the activity seen by the honeypots-some are contacted millions of times while others only observe a few thousand sessions. We also analyze the behavior of scouters and intruders of these honeypots. Again, some honeypots report orders of magnitude more interactions with command execution than others. Still, diversity is needed since even if we focus on the honeypots with the highest visibility, they see only a small fraction of the intrusions, including only 5% of the files. Thus, although around 2% of intrusions are visible by most of the honeypots in our honeyfarm, the rest are only visible to a few. We conclude with a discussion of the findings of work.@en

Today, there is an increasing number of peering agreements between Hypergiants and networks that benefit millions of end-user. However, the majority of Autonomous Systems do not currently enjoy the benefit of interconnecting directly with Hypergiants to optimally select the path for delivering Hypergiant traffic to their users. In this paper, we develop and evaluate an architecture that can help this long tail of networks. With our proposed architecture, a network establishes an out-of-band communication channel with Hypergiants that can be two or more AS hops away and, optionally, with the transit provider. This channel enables the exchange of network information to better assign requests of end-users to appropriate Hypergiant servers. Our analysis using operational data shows that our architecture can optimize, on average, 15% of Hypergiants’ traffic and 11% of the overall traffic of networks that do not interconnect with Hypergiants. The gains are even higher during peak hours when available capacity can be scarce, up to 46% for some Hypergiants.

@en