Some Worms Use Their Powers for Good

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^[1]
worm holds the dubious position of most costly computer malware
ever – responsible for some $52 billion^[2]
in damage. In second place… Sobig^[3], another worm.

It turns out, however, that there are exceptions to every rule.
Some biological worms are actually not welcome^[4]
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^[5], 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^[6] 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^[7].