Worms are Good and Evil

10657996054?profile=RESIZE_400xFisherman are fans of worms for bait as most fish like them, yet cybersecurity professionals know that worms are bad.  Worms have proven to be the most devastating force known to the computing world.  The MyDoom worm holds the dubious position of most costly computer malware, responsible for some $52 billion in damage.  And winning second place is Sobig, another worm.

Some investigators call MyDoom a virus, others call it a worm.  It is known as My Doom and the Doom Virus.   MyDoom is a serious threat, this small bit of code spreads from one computer to another via email attachments.  If a user receives these messages and opens their files, the program sits on your computer.  And soon, everyone in your address book gets a message from your computer.  Researchers became aware of MyDoom in 2004, and the attacks launched then have long since passed. But plenty of infected computers remain.  So, it is important to know how this worm works and how you can rid your computer of the code.

The SoBig worm operates the same way.  It uses email and shared network folders to infect machines running Microsoft’s Windows.  The worm arrives in e-mail messages from a single sender, big@boss.com, and is stored in attached executable files with names such as Sample.pif, Untitled1.pif and Movie_0074.mpeg.pif.

When opened, the worm places a copy of itself into the Windows folder on the infected machine, creates a process to run the worm program and modifies the Windows registry so that the worm program will be launched whenever Windows is started.   Once it has infected a machine, the worm searches for e-mail addresses in a variety of text files on the computer's hard drive.  Those addresses are used to send out more copies of itself.  Sobig also searches for any shared folders on networks that the infected machine may have access to and places a copy of itself in any network folder it can access.[1]

It turns out that there are exceptions to every rule.  Some biological worms are actually not welcome in most gardens.  And (believe it or not) some cyber worms, can use their software code for positive ends, such as Hopper.

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, and insecure credential storage.

Hopper is a real worm, with command and control, built-in privilege escalation, and many more of worm's most devious capabilities.  But contrary to most worms, Hopper was built to do good things, 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.

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 does not have to be changed if there is 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, the team added different initial execution methods, additional communication methods, various ways to fetch the first stage payload, different injection methods, and more.  To create a very stealthy worm, it needed to allow for maximum customization of stealthy features, so configurations were developed to make it 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

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, the developers 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 was for Hopper to use the minimum privileges needed to achieve its goals.  For example, if a machine provides user access to a 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.  Exploits can potentially crash systems, they stand out more and are easily identified by IPS/network monitoring products and EDR products. Misconfigurations are not easily detected as malicious activity.  For example, Active Directory misconfigurations may lead a user to gain access to a resource that a user 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.

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.

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.

Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization.    For questions, comments or assistance, please contact the office directly at 1-844-492-7225, or feedback@wapacklabs. com    

Weekly Cyber Intelligence Briefings:

Weekly Cyber Intelligence Briefings:

REDSHORTS - Weekly Cyber Intelligence Briefings

https://attendee.gotowebinar.com/register/5504229295967742989

 

[1] https://thehackernews.com/2022/07/some-worms-use-their-powers-for-good.html

E-mail me when people leave their comments –

You need to be a member of Red Sky Alliance to add comments!