![Man1-new]( "Man1-new")
With season two of Mr. Robot approaching, the storyline follows a hacker group that takes down an evil global corporation and collapses the financial market. Led by the mysterious Mr. Robot, the hackers use a variety of tricks to evade detection, and seem to cover their tracks at every turn. There are similarities shared by the show's hackers and real-life attackers.
Hackers are human. Like the rest of us, they are creatures of habit, turning to familiar tools and techniques time and time again. As they hone their craft, attackers develop their skills and accumulate knowledge. And while they go to great lengths to hide from view and keep their actions under the radar, they leave tracks if you know where to look. By examining subtle clues attackers leave behind, it’s possible for threat researchers to track malware back to a specific actor.
Malware artifacts provide these valuable clues, serving as tools, techniques and procedures (TTPs) in tracking the ongoing operations of a specific threat actor. In this case, we focus on MAN1, a sophisticated crypter dating back to 2014 that's still used today.
We hope that presenting this research publicly will help researchers pursue similar avenues when following threat actors.
The Actor
Associating an actor to a string of campaigns is never an easy task. Crimeware operates like an underground business -- multiple players may be involved in one project, pieces of an operation may be outsourced to various entities, and elements can be handled by multiple groups over time. In these instances, it becomes harder to prove that the same criminal group is behind a string of malware campaigns.
However, subtle tricks and routines found in packers and crypters provide valuable clues for threat researchers. A crypter, in its basic form, is designed to obfuscate code. In some cases, it's possible to associate actors with their payloads, which allows threat researchers to track the movement of specific actors over time. Given the utility of these obfuscation techniques, actors often keep their tricks of the trade private and do not sell them to the masses on the underground.
One actor, or group, using such tricks is MAN1. We've associated MAN1 with Dyre, a trojan first used in large-scale campaigns targeting customers of major financial institutions and later used to target organizations in additional sectors that include technology, petrochemical and others. The MAN1 moniker comes from the binaries the Dyre malware downloads from compromised websites. These downloaded files usually included a man1.exe file, which was typically an older version of Dyre.
Tracking MAN1
To link MAN1 to Dyre, we had to take a look at earlier campaigns. Before Dyre, these actors used Chanitor to download Vawtrak, a banking trojan. The server delivering Chanitor used “bulletproof hosting,” which are hosting services permitting extreme leniency in their terms of service. Later, this actor gradually began delivering both Vawtrak and Dyre. Eventually, the actor began delivering Dyre exclusively. The servers used at the beginning of this transition hold an important clue to uncover the identity of the actor: These same few servers were also used to deliver Vawtrak using Chanitor.
As with most long-established actors, MAN1 exhibits distinct TTPs in performing their ongoing malicious activities. The crypter discussed here is one such tool used by this actor since its involvement in Vawtrak in 2014, and possibly earlier. While crypters are relatively common, really good crypters -- designed to prevent detection through various methods -- can sell for a lot of money on the underground, where they typically remain private and used for a very long time.
The uniqueness and complexity of the crypter, coupled with the other TTPs used by this group, provides another valuable clue and paints a clearer picture of the actor. Over time, the research community picked up on this actor's subtleties, such as its consistent use of ‘feedweb_data’ or ‘cached_data’ folders on compromised websites. These characteristics made it possible for researchers to track this actor's involvement across multiple malware families over time.
A Timeline of Exploits
Let's take a look at MAN1's activities beginning in March 2015.
![Timeline]( "Timeline")
March 2015: Chanitor, Vawtrak: By tracing the IP range by naming schemes and crypter usage, we find the actor's first involvement with Vawtrak, when it spammed out Chanitor as a flight confirmation (1) to deliver Vawtrak from 91.194.254.213/us/file.jpg.
April 2015: Chanitor → Vawtrak, Dyre: In April 2015, we spotted a glaring association with this actor's involvement in both Dyre and the old Vawtrak in a spam campaign (2) that used a macro to download a text file that contained the url to the payload. This technique provides the actor flexibility, in that they can use the same spam campaign to deliver multiple payloads. This technique has one drawback: It needs to burn through extra compromised websites. This campaign had two payloads – one from 91.194.254.235/uss/file.exe using Chanitor (delivering Vawtrak) and one from 91.194.254.222/us2/file.exe delivering Dyre. The Dyre sample used in this campaign was named ‘man1’. This IP range used can be traced back further -- to Chanitor delivering old Vawtrak -- and was also used for testing the newer Vawtrak seen today.
May 2015: Rovnix, Pony → ReactorBot: This actor has shown interest in using the newest malware within the crimeware domain. In May 2015, a new banker emerged and was distributed using Rovnix as a dropper. The downloaded and loaded dll was named ReactorDemo.dll, eventually known as ReactorBot (3). This actor was involved in a spam run delivering CVE-2014-1761 that exploited RTFs delivering Pony, which would then download ReactorBot from locations such as:
Encentivhealth[.]m/wp-content/plugins/cached_data/n1.exe
Also in May, we see this actor using a similar naming structure on compromised websites to deliver Dyre, which was identified as a MAN1 campaign within the research community, from macro docs downloading Pony. In this instance, we see one of the compromised website folder structures exhibit characteristics used by this actor:
Cyctechnology[.]com/wp-content/plugins/cached_data/m1.exe
The /cached_data/ structure is probably familiar to some from frequent Dyre spamming. Why use the same naming structure on compromised websites? Our guess is that it’s an automated process as demonstrated when you examine the contents of that folder across multiple servers.
![Image1]( "Image1")
November 2015: Dyre, Vawtrak: In early November 2015, we witnessed one of the Dyre actors transition from Dyre to the updated version of Vawtrak. This actor continued to deliver both Dyre and Vawtrak during multiple spam campaigns on November 2, 2015 (4, 5). The timing of this transition raises suspicions, as it corresponded with a Dyre takedown event later that same month (6). For the Dyre run, we see the /sliva/ structure for the Pony runs (cd445e52eb7d2ca7359a8513157dd0a9), which is still used today for campaigns delivering Vawtrak.
May 2016: H1N1 → Pony, Vawtrak, Nymaim → Gozi: Earlier, on May 25, 2016, researchers observed a spam campaign delivering Vawtrak and using similar techniques. But instead of Chanitor, the loader was H1N1 downloading Pony as pm.dll and Vawtrak as inst.exe.
Also of note is this actor’s recent use of Nymaim from spammed out macro documents dropping Pony (7). These documents would download Nymaim from places such as:
elfielatorestaurante[.]com/wp-content/plugins/cached_data/print[.]exe
It would then deliver a Gozi/ISFB module targeting US entities*. This delivery was later coined GozNym due to the custom work linking the Gozi/ISFB module to Nymaim (8).
* A portion of these targets can be found toward the end of this post.
June 2016: H1N1, Chanitor/Hancitor → Vawtrak: Recently, this actor pushed Vawtrak heavily using a variety of delivery methods. Two methods seen recently are H1N1 and a Chanitor variant (also called Hancitor). These campaigns are noteworthy for the MAN1 crypter and the tactics it uses. One such tactic involves delivering Pony separately from Vawtrak, even though Vawtrak comes with a stealer module component. This actor has also been observed using the same Pony gate structure of ‘/sl/gate.php’ or ‘/zapoy/gate.php’. A recent campaign on June 7, 2016 utilized a Word document dropper using names that followed a pattern of ‘report_\d{7}.doc’ to deliver a Chanitor variant that would check-in to a gate with the uri ‘/sl/gate.php’ and then download both Pony and Vawtrak.
Also of note on these recent campaigns is the man1.exe file that may show up on compromised websites. This can be seen on a campaign from June 20, 2016, in which H1N1 delivered the usual Pony and Vawtrak malware. However, if we look a little closer at the website, it downloads Pony from ('crr-medvezonok[.]ru/about/pm.dll') and we find a number of other executables residing on that server in that same subfolder ('inst1.exe', 'inst2.exe', 'inst3.exe', 'man1.exe'). The executable man1.exe is actually an old unpacked Dyre malware sample -- further pointing to this actor's previous involvement in Dyre.
Latest: To date, the actor continues using the MAN1 crypter. The actor sticks to the same naming scheme for up to months at a time. These consistent TTPs could be due to a number of reasons: The actor may be using a toolkit or buying mass quantities of shelled servers from the same entity and going through them systematically. Either way, by identifying these key characteristics, we narrowed in on an actor’s use of this custom crypter, which then made it possible for us to trace this actor’s movement across multiple malware families over years. We’ve found other notable malware associated with this actor by following the crypter’s evolution over time. This malware includes a P2P Gozi variant, CTB Locker and Andromeda.
Peeling Back the Layers of the Crypter
Researchers commonly have to break through layers of crypters or packers in order to get to the underlying malware code, and it becomes instinctive to experienced researchers. Some crypters used for malware add functions, such as anti-virtualization or anti-sandboxing. The problem with most crypters is that they are a fire-and-forget tool used to bypass antivirus and sandbox detections. Some crypters employ a more drastic technique in which they use multiple layers that involve dynamically generated code. MAN1 is one such advanced crypter.
While it is often tempting to break through all the layers to get to the heart of the malware, our research supports the idea that sometimes these discarded layers can be used to bridge the gap and turn research into intelligence to help profile actors. This proved to be the case with the MAN1 crypter.
In the MAN1 crypter, the first layer is mostly just a bunch of deadcode with limited functionality, but it allows quite a bit of throwaway code to be added. This deadcode can be added for numerous reasons -- from throwing off sandbox reports, to messing with AV heuristics and generally making it a pain to signature off of. Eventually the code will decode the next layer, which is where most of the real work can begin. Usually, this first layer will be XOR decoded, but will be surrounded by a large amount of useless code operating on Windows or fonts that don't exist.
![Image2]( "Image2")
The second and third layers function roughly the same as the first, with the exception of decoding. The second layer decodes the output of the first layer and the third layer decodes the output of the second.
Each layer shares the following common characteristics:
- Is numbered
- Contains variable length, numbered chunks
- Each chunk may be compressed
To accommodate this setup, each chunk has an attached header as shown in this mock up:
struct DataBlob {
unsigned short CheckVal1;
unsigned short CheckVal2;
unsigned short CheckOffset;
struct ChunkHeader {
unsigned int SetNum;
unsigned int length;
unsigned int SetIndex;
unsigned int check;
unsigned int key;
unsigned int compressedflag;
unsigned int uncompressedSize;
}chunk;
char data[chunk.length];
}
As the layer performs its decoding routine, it utilizes shellcode that is decoded and reassembled for every chunk in the next layer. This shellcode is then used to decode the data in the found chunk. The same shellcode is used on all layers, but differs from sample to sample. This characteristic leads us to believe it is dynamically generated to perform various types of decoding operations and keys on the layers. By comparing this layer between two different samples delivered on the same day, we can see slight differences. This means the layer is generated when the crypt happens on the payload because it is required to encode the payload.
![Image3]( "Image3")
Here we can see the main loop from one sample employing this technique:
![Image4]( "Image4")
Getting through the crypter is trivial. Breaking on kernel32!VirtualAlloc results in returning to the main loop of the layer as each calls VirtualAlloc every time it goes to reconstruct the shellcode layer. Adding a breakpoint to the end of that loop (the instruction just after kernel32!VirtualAlloc) presents the next layer. From there, execute ‘till return’ twice and then the next call will copy over the reconstructed code segment and a JMP.
Conclusion
Intimate knowledge of the crypter and other techniques have allowed us to tie numerous campaigns over the years to a single actor. We're aware that other researchers have identified some of these threads and our intention behind publishing this body of knowledge is to encourage others to recognize MAN1 and help build a fuller profile. The criminal landscape is vast, but there are often significant volumes of activity spanning campaigns and malware families that tie back to individual actors.
IOCs are available on our Github at https://git.io/vKlZb
-- Fidelis Threat Research Team researcher Jason Reaves
References
1: https://techhelplist.com/spam-list/742-order-confirmation-for-flight-malware
2: https://techhelplist.com/spam-list/785-payment-confirmation-for-tax-refund-request-malware
3: http://www.kernelmode.info/forum/viewtopic.php?f=16&t=981&start=70#p25915
4: https://techhelplist.com/spam-list/957-e-ticket-confirmation-aa-malware
5: https://myonlinesecurity.co.uk/american-airlines-e-ticket-confirmation-word-doc-malware/
6: http://www.scmagazine.com/dyre-trojan-almost-dead-after-takedown-by-the-russians/article/472074/
7: https://techhelplist.com/spam-list/995-re-recipient-domain-name-sucks-malware
8: https://securityintelligence.com/meet-goznym-the-banking-malware-offspring-of-gozi-isfb-and-nymaim/
Nymaim Gozi Module Targets:
https[:]//*pib*[.]secure-banking[.]com/*
https[:]//www[.]svbconnect[.]com/auth*
https[:]//connect-ch*[.]ubs[.]com/workbench/*
https[:]//clientlogin[.]ibb[.]ubs[.]com/login*
https[:]//achieveaccess[.]citizenscommercialbanking[.]com/CitizensWebApplication/achieve/loginScreen*
https[:]//onlinebusinessplus[.]vancity[.]com/business/default[.]jsp*
https[:]//www[.]vancity[.]com/BusinessBanking*
https[:]//cashmanageronline[.]bbt[.]com/auth/*
https[:]//onepass[.]regions[.]com/*
https[:]//commerceconnections[.]commercebank[.]com/*
https[:]//pfo[.]us[.]hsbc[.]com/*
https[:]//*/fi*/bb/logon*
https[:]//www8[.]comerica[.]com*
https[:]//connect[.]bnymellon[.]com/ConnectLogin/login/LoginPage[.]jsp*
https[:]//wellsoffice[.]wellsfargo[.]com/portal/signon/index[.]jsp*
https[:]//*[.]ibanking-services[.]com/*
https[:]//*LoginAdv[.]aspx*
https[:]//*ebanking-services[.]com/EamWeb*
https[:]//*/wcmfd/wcmpw/*
https[:]//*phcp/servlet*
https[:]//*[.]blilk[.]com/Core/Authentication/*
https[:]//*1961/*1961[.]ashx*
https[:]//*AOP/Password[.]aspx*
https[:]//*ally[.]com*
https[:]//*cm[.]netteller[.]com/login2008/Authentication*
https[:]//securentrycorp*/Authentication/zbf/k/*
https[:]//*/onlineserv/CM/*
https[:]//*tob/live/usp-core/app/initialLogin*
https[:]//*/CLKCCM/*/login[.]asp*
https[:]//*/Authentication/Login[.]aspx*
https[:]//*engine/login/logins*[.]asp*
https[:]//*myebanking[.]net*
https[:]//*hbloginv50*
https[:]//*User/AccessSignin/*
https[:]//drob[.]santanderbank[.]com/*
https[:]//*bnymellonwealthmanagement[.]com*
*businessonline[.]tdbank[.]com/corporatebankingweb/core*
https[:]//express[.]53[.]com/portal/auth/login/Login*
https[:]//express[.]53[.]com/portal/auth/login/Login*
*/ibanking3/login[.]aspx*
https[:]//trz[.]tranzact[.]org/LogonOTP[.]aspx
https[:]//login[.]tranzact[.]org/account/login*
https[:]//access[.]jpmorgan[.]com/jpmalogon*
https[:]//jpmcsso[.]jpmorgan[.]com/sso/action/federateLogin*markets[.]jpmorgan[.]com*
https[:]//jpmcsso[.]jpmorgan[.]com/sso/action/login*mdcommercial[.]jpmorgan[.]com*
https[:]//cashproonline[.]bankofamerica[.]com/AuthenticationFrameworkWeb/cpo/login/public/loginMain[.]faces*
https[:]//businessaccess[.]citibank[.]citigroup[.]com/cbusol/signon[.]do*
https[:]//www[.]treasury[.]pncbank[.]com/idp/esec/login[.]ht*
https[:]//singlepoint[.]usbank[.]com/cs70_banking/logon/sbuser*
https[:]//*/cmserver/welcome/*
https[:]//*engine/login/businesslogin[.]asp*
https[:]//*/engine/login/businesslogins[.]asp*
https[:]//*/pub/html/login[.]html*
https[:]//ktt[.]key[.]com/ktt/cmd/logon*
https[:]//*secure[.]fundsxpress[.]com/*
https[:]//banamexusa[.]btbanking[.]com/onlineserv/CM/