Gardeners know that worms are good. Cybersecurity professionals know that worms are bad. Very bad. In fact, worms are literally the most destructive force for evil known to the computer world. The MyDoom worm holds the dubious position of the most expensive computer malware ever – responsible for some $52 billion in case of damage. On the second place… So biganother worm.
However, it turns out that there are exceptions to every rule. Some biological worms are actually not welcome in most gardens. And it seems that some cyberworms could use their powers for good…
Meet Hopper, the good worm
Detection tools are not good at catching non-exploit-based spread, that’s what worms do best. Most cybersecurity solutions are less resistant to worm attack methods such as token impersonation and others that take advantage of flawed internal configurations – PAM, segmentation, insecure credential storage, and more.
So, what better way to defeat an insidious worm than with… another insidious worm?
And so Hopper was born! Hopper is a real worm, with command and control, built-in privilege escalation and many more of Wormkind’s most devious capabilities. But unlike most worms, Hopper is built to do good. Instead of doing damage, Hopper tells his White Hat operators where and how it managed to infiltrate a network. It reports how far it has gotten in, what it found along the way, and how to improve its defenses.
Up close and personal with Hopper
The Cymulate development team based Hopper on a widely used malware stager – a small executable file that serves as an initial payload, with the primary purpose of preparing a larger payload. Our stager also acts as a PE packer, a program that loads and executes programs indirectly, usually from within a package.
Hopper’s stager is written in such a way that the initial payload does not need to be changed when we make an update to Hopper. This means that excluding hashes has become history with every update, and Hopper users only need to exclude the stager’s hash once. Writing the stager this way also opened the path for running other tools that Hopper needs.
To maximize Hopper’s flexibility, our team added several initial execution methods, additional communication methods, several ways to retrieve the first stage payload, several injection methods, and more. And to make a very unobtrusive worm we need to allow maximum customization of unobtrusive functions, so we have configurations almost entirely operator controlled:
Initial payload configuration – fully configurable execution methods including executables, libraries, python scripts, shell codes, PowerShell scripts and more Payload configuration in the first stage – customizable packet retrieval methods and packet injection methods (e.g. reflective injection) Beacon configuration in the second phase – custom communication channels, live timing and timeout, and jitter API – over-the-air addition of new capabilities to enable future expansion of capabilities, including communication methods, propagation methods, and exploits
Execution, Credential Management and Spreading
Hopper’s first performance is in-mem and in stages. The first stage is a small stump with limited capabilities. This stub knows how to run a more important piece of code rather than contain the code itself – making it more difficult to mark this as a malicious file. For privilege escalation, we chose different UAC bypass methods, exploiting vulnerable services like Spooler and using misconfigured services or autoruns to gain privilege elevation or persistence. The idea here is that Hopper uses the minimum privileges necessary to achieve his goals. For example, if a machine grants user access to our target machine, Hopper may not need to increase privileges to propagate to that target machine.
Hopper features centralized management of credentials, which necessarily allows it to distribute credentials between Hopper instances – meaning all Hoppers can access collected credentials, eliminating the need to duplicate the database of sensitive credentials across other machines.
To propagate, Hopper prefers misconfigurations over exploits. The reason? Exploits can potentially crash systems, they are more noticeable and are easily identified by IPS/network monitoring products and EDR products. On the other hand, misconfigurations are not easily detected as malicious activity. For example, misconfigurations of Active Directory could allow a user to access a resource that he or she should not have had access to, leading to dissemination. Likewise, incorrect software configurations can allow a user to run code remotely and thereby lead to dissemination.
Stealth and C&C communication
The Cymulate team chose Hopper for in-memory execution because encrypting in-memory malware code once it is no longer in use can disrupt the ability of EDR products to fingerprint in-memory content. In addition, in-memory execution uses direct system calls rather than API calls, which can be monitored by EDR products. If Hopper does need to use API functions, it will detect and remove EDR hooks before doing so.
To maintain stealth, Hopper communicates with Command and Control during working hours by masking the activity with normal working hours activity in random timing patterns. It also communicates only with servers on the allowed list or servers that are not considered malicious, such as Slack channels, Google Sheets or other public services.
It comes down to
To prevent worm attacks, a White Hat Worm-like Hopper is an ideal solution. By seeing the network from a worm’s perspective, Hopper turns the worm’s greatest advantage into the defender’s greatest advantage.
Note: This article was written and contributed by Yoni Oren, team leader, senior security researcher, and developer at Cymulate†