Gardeners know that worms are good. Cybersecurity professionals know that worms are bad. Very bad. In fact, worms are literally the most devasting force for evil known to the computing world. The MyDoom worm holds the dubious position of most costly computer malware ever – responsible for some $52 billion in damage. In second place… Sobig, another worm.
It turns out, however, that there are exceptions to every rule. Some biological worms are actually not welcome in most gardens. And some cyber worms, it seems, can use their powers for good …
Meet Hopper, The Good Worm
Detection tools are not good at catching non-exploit-based propagation, which is what worms do best. Most cybersecurity solutions are less resilient to worm attack methods like token impersonation and others that take advantage of deficient internal configurations - PAM, segmentation, insecure credential storage, and more.
So, what better way to beat a stealthy worm than with … another stealthy worm?
And thus was born Hopper! Hopper is a real worm, with command and control, built-in privilege escalation, and many more of wormkind's most devious capabilities. But contrary to most worms, Hopper was built to do good. Instead of causing harm, Hopper tells its White Hat operators where and how it succeeded in infiltrating a network. It reports how far it got in, what it found along the way, and how to improve defenses.
Up Close and Personal with Hopper
The development team at Cymulate based Hopper on a common malware stager – a small executable that serves as an initial payload, with its primary objective being to prepare a larger payload. Our stager also serves as a PE packer, a program that loads and executes programs indirectly, usually from a package.
Hopper's stager was written in such a way that the initial payload doesn't have to be changed if we make an update to Hopper. This means that excluding hashes on every update turned into history, and Hopper users only need to exclude the stager's hash once. Writing the stager in this way also opened up the path for executing other tools that Hopper needs.
To maximize Hopper's flexibility, our team added different initial execution methods, additional communication methods, various ways to fetch the first stage payload, different injection methods, and more. And, to create a very stealthy worm, we need to allow for maximum customization of stealthy features, so we made configurations almost entirely operator-controlled:
- Initial payload configuration – fully configurable execution methods including executables, libraries, python scripts, shellcodes, PowerShell scripts, and more
- First stage payload configuration – customizable package fetching methods and package injection methods (for example, reflective injection)
- Second stage beacon configuration - tailored communication channels, keep alive timing and timeout, and jitter
- API – over the air addition of new capabilities to allow easier future expansion of capabilities, including communication methods, spread methods, and exploits
Execution, Credential Management, and Spreading
Hopper's initial execution is in-mem and in stages. The first stage is a small stub with limited capability. This stub knows how to run a more significant piece of code instead of containing the code within itself - making it harder to flag this as a malicious file. For privilege escalation, we chose different UAC bypass methods, exploiting vulnerable services such as Spooler and using misconfigured services or autoruns to gain privilege elevation or persistency. The idea here is for Hopper to use the minimum privileges needed to achieve its goals. For example, if a machine provides user access to our target machine, Hopper might not need to elevate privileges to spread to that target machine.
Hopper features centralized credentials management, which enables it to distribute credentials between Hopper instances by necessity - meaning that all Hoppers have access to credentials collected, eliminating the need to duplicate the sensitive credentials database across other machines.
To spread, Hopper prefers misconfigurations over exploits. The reason? Exploits can potentially crash systems, they stand out more and are easily identified by IPS/network monitoring products and EDR products. Misconfigurations, on the other hand, are not easily detected as malicious activity. For example, Active Directory misconfigurations may lead a user to gain access to a resource that he or she should not have had access to, and therefore lead to spreading. Similarly, software misconfigurations may allow a user to execute code remotely and therefore lead to spreading.
Stealth and C&C Communications
The Cymulate team chose in-memory execution for Hopper, since encrypting malware code in-memory once no longer in use can disrupt EDR products' ability to fingerprint in-memory content. Moreover, in-memory execution uses direct system calls instead of API calls, which may be monitored by EDR products. If Hopper does need to use API functions, it detects and unloads EDR hooks before doing so.
To maintain stealth, Hopper communicates with Command and Control during working hours by masking the activity with normal working hour activity in random timing patterns. It also communicates only with allow-listed servers or servers that aren't considered malicious, like Slack channels, Google Sheets, or other public services.
The Bottom Line
To preempt worm attacks, a White Hat worm-like Hopper is an ideal solution. By seeing the network from a worm's perspective, so to speak, Hopper turns the worm's greatest advantage to the defender's greatest advantage.
Note: This article is written and contributed by Yoni Oren, Team Leader, Senior Security Researcher and Developer at Cymulate.
