{"id":15050,"date":"2019-04-09T08:10:14","date_gmt":"2019-04-09T16:10:14","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2019\/04\/09\/news-8799\/"},"modified":"2019-04-09T08:10:14","modified_gmt":"2019-04-09T16:10:14","slug":"news-8799","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2019\/04\/09\/news-8799\/","title":{"rendered":"Say hello to Baldr, a new stealer on the market"},"content":{"rendered":"

Credit to Author: Malwarebytes Labs| Date: Tue, 09 Apr 2019 15:00:13 +0000<\/strong><\/p>\n

By\u00a0William Tsing<\/a>, Vasilios Hioureas<\/a>, and J\u00e9r\u00f4me Segura<\/a><\/em><\/p>\n

Over the past few months, we have noticed increased activity and development of new stealers. One such new stealer, called Baldr, first appeared in January 2019, and our analysis of this malware finds that its authors were serious about making a long-lasting product.<\/p>\n

Unlike many banking Trojans that wait for the victim to log into their bank’s website, stealers typically operate in grab-and-go mode. This means that upon infection, the malware will collect all the data it needs and exfiltrate it right away. Because such stealers are often non-resident (meaning they have no persistence mechanism) unless they are detected at the time of the attack, victims will be none-the-wiser that they have been compromised.<\/p>\n

This type of malware is popular among criminals and covers a greater surface than more specialized bankers. On top of capturing browser history, stored passwords, and cookies, stealers will also look for files that may contain valuable data.<\/p>\n

In this blog post, we will review the Baldr stealer by looking at its introduction in cybercrime forums and its distribution in the wild.<\/p>\n

Baldr on the market<\/h3>\n

Baldr is likely the work of three threat actors: Agressor for distribution, Overdot for sales and promotion, and LordOdin for development. Appearing first in January, Baldr quickly generated many positive reviews on most of the popular clearnet Russian hacking forums.<\/p>\n

\"\"<\/p>\n

Previously associated with the Arkei stealer (seen below), Overdot posts a majority of advertisements across multiple message boards, provides customer service via Jabber, and addresses buyer complaints in the reputational system used by several boards.<\/p>\n

\"\"<\/p>\n

Of interest is a forums post referencing Overdot’s previous work with Arkei, where he claims that the developers of both Baldr and Arkei are in contact and collaborate on occasion.<\/p>\n

Unlike most products posted on clearnet boards, Baldr has a reputation for reliability, and it also offers relatively good communication with the team behind it.<\/p>\n

\"\"<\/p>\n

LordOdin, also known as BaldrOdin, has a significantly lower profile in conjunction with Baldr, but will monitor and like posts surrounding it.<\/p>\n

\"\"<\/p>\n

He primarily posts to differentiate Baldr from competitor products like Azorult, and vouches that Baldr is not simply a reskin of Arkei:<\/p>\n

\"\"<\/p>\n

Agressor\/Agri_MAN is the final player appearing in Baldr’s distribution:<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

Agri_MAN has a history of selling traffic on Russian hacking forums dating back roughly to 2011. In contrast to LordOdin and Overdot, he has a more checkered reputation, showing up on a blacklist for chargebacks, as well as getting called out for using sock puppet accounts to generate good reviews.<\/p>\n

Using the alternate account Agressor, he currently maintains an automated shop to generate Baldr builds at\u00a0service-shop[.]ml<\/em>. Interestingly, Overdot makes reference to an automated installation bot that is not connected to them, and is generating complaints from customers:<\/p>\n

\"\"<\/p>\n

This may indicate Agressor is an affiliate and not directly associated with Baldr development. At presstime, Overdot and LordOdin appear to be the primary threat actors managing Baldr.<\/p>\n

Distribution<\/h3>\n

In our analysis of Baldr, we collected a few different versions, indicating that the malware has short development cycles. The latest version analyzed for this post is version 2.2, announced March 20:<\/p>\n

\"\"<\/p>\n

We captured Baldr via different distribution chains. One of the primary vectors is the use of Trojanized applications disguised as cracks or hack tools. For example, we saw a video posted to YouTube offering a program to generate free Bitcoins, but it was in fact the Baldr stealer in disguise.<\/p>\n

\"\"<\/p>\n

We also caught Baldr via a drive-by campaign involving the Fallout exploit kit:<\/p>\n

\"\"<\/p>\n

Technical analysis (Baldr 2.2)<\/h3>\n

Baldr\u2019s high level functionality is relatively straight forward, providing a small set of malicious abilities in the version of this analysis. There is nothing ground breaking as far as what it\u2019s trying to do on the user\u2019s computer, however, where this threat differentiates itself is in its extremely complicated implementation of that logic.<\/p>\n

Typically, it is quite apparent when a malware is thrown together for a quick buck vs. when it is skillfully crafted for a long-running campaign. Baldr sits firmly in the latter category\u2014it is not the work of a script kiddie. Whether we are talking about its packer usage, payload code structure, or even its backend C2 and distribution, it’s clear Baldr’s authors spent a lot of time developing this particular threat.<\/p>\n

Functionality overview<\/h4>\n

Baldr’s main functionality can be broken down into five steps, which are completed in chronological order.<\/p>\n

Step 1: User profiling<\/strong><\/p>\n

Baldr starts off by gathering a list of user profiling data. Everything from the user account name to disk space and OS type is enumerated for exfiltration.<\/p>\n

Step 2: Sensitive data exfiltration<\/b><\/p>\n

Next, Baldr begins cycling through all files and folders within key locations of the victim computer. Specifically, it looks in the user AppData<\/em> and temp<\/em> folders for information related to sensitive data. Below is a list of key locations and application data it searches:<\/p>\n

AppDataLocalGoogleChromeUser DataDefault  AppDataLocalGoogleChromeUser DataDefaultLogin Data  AppDataLocalGoogleChromeUser DataDefaultCookies  AppDataLocalGoogleChromeUser DataDefaultWeb Data  AppDataLocalGoogleChromeUser DataDefaultHistory  AppDataRoamingExodusexodus.wallet  AppDataRoamingEthereumkeystore   AppDataLocalProtonVPN   WalletsJaxx   Liberty   NordVPN   Telegram   Jabber   TotalCommander   Ghisler<\/pre>\n
Many of these data files range from simple sqlite databases to other types of custom formats. The authors have a detailed knowledge of these target formats, as only the key data from these files is extracted and loaded into a series of arrays. After all the targeted data has been parsed and prepared, the malware continues onto its next functionality set.<\/p>\n
Step 3: ShotGun file grabbing<\/strong><\/p>\n
DOC, DOCX, LOG, and TXT files are the targets in this stage. Baldr begins in the Documents and Desktop directories and recursively iterates all subdirectories. When it comes across a file with any of the above extensions, it simply grabs the entire file\u2019s contents.<\/p>\n
Step 4: ScreenCap<\/strong><\/p>\n
In this last data-gathering step, Baldr gives the controller the option of grabbing a screenshot of the user\u2019s computer.<\/p>\n
Step 5: Network exfiltration<\/strong><\/p>\n
After all of this data has been loaded into organized and categorized arrays\/lists, Baldr flattens the arrays and prepares them for sending through the network.<\/p>\n
One interesting note is that there is no attempt to make the data transfer more inconspicuous. In our analysis machine, we purposely provided an extreme number of files for Baldr to grab, wondering if the malware would slowly exfiltrate this large amount of data, or if it would just blast it back to the C2.<\/p>\n
\"\"<\/p>\n
The result was one large and obvious network transfer. The malware does not have built-in functionality to remain resident on the victim\u2019s machine. It has already harvested the data it desires and does not care to re-infect the same machine. In addition, there is no spreading mechanism in the code, so in a corporate environment, each employee would need to be manually targeted with a unique attempt.<\/p>\n
Packer code level analysis<\/h4>\n
We will begin with the payload obfuscation and packer usage. This version of Baldr starts off as an AutoIt script built into an exe. Using a freely available AIT decompiler, we got to the first stage of the packer below.<\/p>\n
\"\"<\/p>\n
As you can see, this code is heavily obfuscated. The first two functions are the main workhorse of that obfuscation. What is going on here is simply reordering of the provided string, according to the indexes passed in as the second parameter. This, however, does not pose much of a problem as we can easily extract the strings generated by simply modifying this script to ConsoleWrite<\/em> out the deobfuscated strings before returning:<\/p>\n
\"\"<\/p>\n
The resulting strings extracted are below:<\/p>\n
Execute  BinaryToString  @TempDir  @SystemDir  @SW_HIDE  @StartupDir  @ScriptDir  @OSVersion  @HomeDrive  @CR  @ComSpec  @AutoItPID  @AutoItExe  @AppDataDir  WinExists  UBound  StringReplace  StringLen  StringInStr  Sleep  ShellExecute  RegWrite  Random  ProcessExists  ProcessClose  IsAdmin  FileWrite  FileSetAttrib  FileRead  FileOpen  FileExists  FileDelete  FileClose  DriveGetDrive  DllStructSetData  DllStructGet  DllStructGetData  DllStructCreate  DllCallAddress  DllCall  DirCreate  BinaryLen  TrayIconHide  :Zone.Identifier  kernel32.dll  handle  CreateMutexW  struct*  FindResourceW  kernel32.dll  dword  SizeofResource  kernel32.dll  LoadResource  kernel32.dll  LockResource  byte[  VirtualAlloc  byte shellcode [  <\/pre>\n
In addition to these obvious function calls, we also have a number of binary blobs which get deobfuscated. We have included only a limited set of these strings as to not overload this analysis with long sets of data.<\/p>\n
We can see that it is pulling and decrypting a resource DLL from within the main executable, which will be loaded into memory. This makes sense after analyzing a previous version of Baldr that did not use AIT as its first stage. The prior versions of Baldr required a secondary file named\u00a0Dulciana.\u00a0<\/em>So, instead of using AIT, the previous versions used this file containing the encrypted bytes of the same DLL we see here:<\/p>\n
\"\"<\/p>\n
Moving forward to stage two, all things essentially remain equal throughout all versions of the Baldr packer. We have the DLL loaded into memory, which creates a child process of the main Baldr executable in a suspended state and proceeds to hollow this process, eventually replacing it with the main .NET payload. This makes manually unpacking with ollyDbg nice because after we break on child Baldr.exe load, we can step through the remaining code of the parent, which writes to process memory and eventually calls ResumeThread()<\/em>.<\/p>\n
\"\"<\/p>\n
As you can see, once the child process is loaded, the functions that it has set up to call contain VirtualAlloc, WriteProcessMemory, <\/em>and ResumeThread,<\/em> which gives us an idea what to look out for.\u00a0If we dump this written memory right before resume thread is called, we can then easily extract the main payload.<\/p>\n
Our colleague @hasherezade<\/a> has made this step-by-step video of unpacking Baldr:<\/p>\n