Worms are helpful, as gardeners are aware. Worms are undesirable, as cyber security experts are aware. very poor Worms are arguably the most destructive form of evil that has ever existed in computing. The MyDoom worm, which caused $52 billion in damage, holds the dubious distinction of being the most expensive piece of computer malware ever. Another worm, Sobig, comes in second.
However, it turns out that every rule has an exception. In fact, some biological worms are undesirable in most gardens. And it appears that certain cyber worms can use their abilities for good.
Introducing Hopper, The Good Worm.
Worms excel in non-exploit-based propagation, which detection technologies struggle to stop. The majority of cybersecurity solutions are less resistant to worm attack techniques like token impersonation and others that rely on inadequate internal setups, including PAM, segmentation, unsafe credential storage, and others.
So how about using even another stealthy worm to defeat the first one?
Hopper was born as a result! Hopper is a true worm with all of the most cunning features of the wormkind, including command and control, built-in privilege escalation, and many others. Hopper was created to do good, in contrast to the majority of worms. Hopper informs its White Hat operators of where and how it was able to breach a network, as opposed to doing damage. It details how far it penetrated, what it discovered along the way, and suggestions for bolstering defenses.
Hopper Up Close and Personal
The Cymulate development team modeled Hopper on a typical malware stager, which is a small program that acts as the initial payload and has as its main goal preparing a larger payload. Our stager also performs the function of a PE packer, which loads and runs programs indirectly, often from a package.
The stager for Hopper was created in a way that prevents the initial payload from needing to be altered whenever Hopper is updated. Hopper users only need to exclude the stager’s hash once, as excluding hashes on each update turned into history. This method of writing the stager made it easier to use other tools that Hopper requires.
Our team expanded Hopper’s adaptability by including various initial execution techniques, extra communication techniques, several ways to obtain the first stage payload, varied injection techniques, and more. Additionally, we needed to allow for maximum customization of stealthy characteristics in order to build an extremely stealthy worm, therefore we built setups that were virtually fully operator-controlled:
Configuring the initial payload includes fully customizable execution techniques such as executables, libraries, Python scripts, shellcodes, PowerShell scripts, and more.
Customizable package fetching and package injection methods for the first stage payload (for example, reflective injection)
In order to facilitate future capability development, including communication methods, spread techniques, and exploits, second stage beacon configuration includes customizable communication channels, keep alive timing and timeout, and jitter API.
Execution, Management of Credentials, and Spreading
The early steps of Hopper’s execution take place in memory. The initial stage is a stub with very little power. As opposed to containing the code within itself, this stub knows how to run a more substantial piece of code, making it more difficult to identify this file as malicious. We used a variety of UAC bypass techniques for privilege escalation, taking advantage of weak services like Spooler and misconfigured services or autoruns to elevate or persist privileges. The aim behind this is for Hopper to only use the rights necessary to accomplish its objectives. For instance, Hopper might not need to elevate privileges to spread to our target system if another machine grants user access to it.
Since all Hoppers have access to the credentials gathered, there is no need to replicate the sensitive credentials database across many machines thanks to Hopper’s centralized credentials management, which enables it to share credentials between Hoppers instances as needed.
Hopper prefers configuration errors to exploits for spreading. The cause? Exploits have the potential to bring down systems, they stand out more, and they are simple for IPS/network monitoring and EDR devices to spot. On the other side, mistakes are harder to spot as malevolent conduct. For instance, Active Directory setup errors may give a user access to a resource they shouldn’t have, which would allow them to spread. Similar to this, software bugs can enable remote code execution by users, which promotes proliferation.
C&C Communications and stealth
Because encrypting malware code in memory after it has finished running can prevent EDR devices from being able to fingerprint in-memory material, the Cymulate team decided to use in-memory execution for Hopper. Additionally, in-memory execution employs direct system calls rather than API calls, which EDR tools may be able to monitor. Hopper identifies and unloads EDR hooks in advance of using API methods if that becomes necessary.
Hopper communicates with Command & Control while working by disguising the activity with regular workday activities at random intervals. Additionally, it only exchanges data with servers that are on the allow-list or that aren’t regarded as dangerous, such as Google Sheets, Slack channels, or other open-source applications.
the conclusion
A White Hat worm-like Hopper is the ideal defense against worm attacks. Hopper converts the worm’s greatest advantage to the defender’s greatest advantage by virtually viewing the network from the worm’s point of view.
Note: Yoni Oren, team leader, senior security researcher, and developer at Cymulate, wrote and contributed to this paper.
