Carpet bombing-type DDoS attacks targeting a wide-range network rather than a single IP address have threatened the Internet. Some researchers have investigated the characteristics of single-target DDoS attacks. Still, much less is known about the characteristics of carpet bombing, even the differences between them. In this paper, we profile characteristics of carpet bombing via data from amplification DDoS honeypots and the differences between single-target DRDoS attacks and carpet bombing. We analyze attacks highly concentrated on a specific network on victims, duration, number of packets, ports, and TTLs, and describe the differences between single-target DRDoS attacks and carpet bombing. Our analysis at the level of Autonomous Systems demonstrates that carpet bombing attacks target more hosting networks, including some critical targets, than single-target attacks. We found carpet bombing attacks targeting more “Corporate” networks. We also found that each IP address targeted by carpet bombing receives fewer packets than single-target DRDoS attacks. According to the result of the comparison of attack duration and TTL, carpet bombing lasted longer and referred to having diverse values of TTL in the packets. On the contrary, most single-target DRDoS attacks have a single value of TTL in the packets. This implies carpet bombing has a higher probability of originating from multiple sources. Finally, comparing ports shows that using various ports for Carpet Bombing is highly proportional to single-target DRDoS attacks.

@en

We investigate the potential for abuse of recent AI advances by developing seven malware programs and two attack tools using ChatGPT, OpenAI Playground's "text-davinci-003"model, and Auto-GPT - an open-source AI agent capable of generating automated prompts to accomplish user-defined goals. We confirm that: 1) Under the safety and moderation control of recent AI systems, it is possible to generate the functional malware and attack tools (up to about 400 lines of code) within 90 minutes, including the debugging time. 2) Auto-GPT does not ease the hurdle of generating the right prompts for malware generation, but it evades the safety controls of OpenAI with its automatically generated prompts. When given goals with sufficient details, it writes the code in nine of nine malware and attack tools we tested. 3) There is still room to improve the moderation and safety controls of ChatGPT and text-davinci-003 model, especially for the growing jailbreak prompts. Overall, we find that recent AI advances, including ChatGPT, Auto-GPT, and text-davinci-003, demonstrate the potential for generating malware and attack tools under safety and moderation control, highlighting the need for improved safety measures and enhanced safety controls in AI systems. @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

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

Distributed Denial of Service attacks against the application layer (L7 DDoS) are among the most difficult attacks to defend against because they mimic normal user behavior. Some mitigation techniques against L7 DDoS, e.g., IP blacklisting and load balancing using a content delivery network, have been proposed; unfortunately, these are symptomatic treatments rather than fundamental solutions. In this paper, we propose a novel technique to disincentivize attackers from launching a DDoS attack by increasing attack costs. Assuming financially motivated attackers seeking to gain profit via DDoS attacks, their primary goal is to maximize revenue. On the basis of this assumption, we also propose a mitigation solution that requires mining cryptocurrencies to access servers. To perform a DDoS attack, attackers must mine cryptocurrency as a proof-of-work (PoW), and the victims then obtain a solution to the PoW. Thus, relative to attackers, the attack cost increases, and, in terms of victims, the economic damage is compensated by the value of the mined coins. On the basis of this model, we evaluate attacker strategies in a game theory manner and demonstrate that the proposed solution provides only negative economic benefits to attackers. Moreover, we implement a prototype to evaluate performance, and we show that this prototype demonstrates practical performance.

@en

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

Open-source honeypots are a vital component in the protection of networks and the observation of trends in the threat landscape. Their open nature also enables adversaries to identify the characteristics of these honeypots in order to detect and avoid them. In this study, we investigate the prevalence of 14 open-source honeypots running more or less default configurations, making them easily detectable by attackers. We deploy 20 simple signatures and test them for false positives against servers for domains in the Alexa top 10,000, official FTP mirrors, mail servers in real operation, and real IoT devices running telnet. We find no matches, suggesting good accuracy. We then measure the Internet-wide prevalence of default open-source honeypots by matching the signatures with Censys scan data and our own scans. We discovered 19,208 honeypots across 637 Autonomous Systems that are trivially easy to identify. Concentrations are found in research networks, but also in enterprise, cloud and hosting networks.
While some of these honeypots probably have no operational relevance, e.g., they are student projects, this explanation does not fit the wider population. One cluster of honeypots was confirmed to belong to a well-known security center and was in use for ongoing attack monitoring. Concentrations in an another cluster appear to be the result of government incentives. We contacted 11 honeypot operators and received response from 4 operators, suggesting the problem of lack of network hygiene. Finally, we find that some honeypots are actively abused by attackers for hosting malicious binaries. We notified the owners of the detected honeypots via their network operators and provided recommendations for customization to avoid simple signature-based detection. We also shared our results with the honeypot developers.@en