中国骇客云教大家如何免杀

免杀,一个在黑客界永不过时的话题。从木马和杀毒软件的第一次交锋开始就始终没有中断过,黑客程序开发者和杀毒软件的技术人员的始终在较量着。面对强大的杀毒软件,病毒的免杀就显的尤为重要。免杀的方式基本分为三种:修改特征码、添加花指令和壳,最后一次,危险漫步就来和大家谈谈加壳这种最常见的免杀方式。

有些动植物长着坚硬的外壳,因为它们都着脆弱的身体,需要用坚硬的外壳来保护自己。根据这一理论,一种叫壳的程序出现了。壳诞生的初衷是为了保护自己的程序不被破解和修改,病毒作为一种特殊的程序,壳同样也可以用于病毒的保护。通过这一现象,壳的用途出现了一个翻天覆地的转变。现在提到壳,大家都会想到病毒的免杀。

一般来说,壳分为两种:加密壳和压缩壳。加密壳主要的作用是对程序进行加密,但加密后程序体积会变大。压缩壳主要用于对程序的压缩,能够减小程序的体积。另外,还有一些特殊的壳既可以加密,同时也可以压缩。

加壳不失为一种不错的免杀方式,但随着杀毒软件的普及和病毒库的日益扩大,越来越多的加壳程序被列入病毒的行列。那么我们还能使用这些壳为病毒免杀吗?YES!但我们要稍微动动手脚了。

如果说单一的添加壳,用不了多久就会被杀,人品不行的一下就被主动防御和云查杀给秒了…

我们可以把一些壳混合起来为程序加壳,也就是题目提到的复合加壳,这样也可以起到免杀的效测试才行。

W(%EL[ZASU3CU`%{N[J23QV.png

我以给灰鸽子加壳为例,给大家一个复合加壳的思路。需要注意的是:要加壳的文件不能是RAR格式的,我这里使用的是没有UPX压缩的灰鸽子。先用加密壳加载灰鸽子服务端,我用到的是国外的一款名为“KeyCrypter”。这个壳的免杀效果非常不错,而且功能强大。但要注意的是:尽量选择一些不常见的加壳程序,加壳要保证一定的数量,不能只加一两个壳。

而且加壳后不等于100%免杀,还要靠我们不断分析测试才行。中国骇客云官方网站hackerschina.org

我以给灰鸽子加壳为例,给大家一个复合加壳的思路。需要注意的是:要加壳的文件不能是

RAR格式的,我这里使用的是没有UPX压缩的灰鸽子。先用加密壳加载灰鸽子服务端,我用到的是国外的一款名为“KeyCrypter”。这个壳的免杀效果非常不错,而且功能强大。

简单介绍一下使用方法,左边是选择要加壳的文件,右边是设置输出文件位置。把下面所有的选项全部选上,这些选项的意思是:反编译、反沙盘等等,我们选上就可以了。然后点击“Crypt File”就为灰鸽子加上了加密壳。

现在还不能添加压缩壳,因为每个壳的兼容性都不一样,我们必须进行资源释放处理。下面我们要使用到“FreeRes”。释放资源后选择“功能”中的“建立可编辑资源”对文件进行资源重建。

接下来我们就用到压缩壳,我选用的是“蚂蚁加壳工具和Mini_pack”,因为他们都是压缩壳,经过我测试,这两个壳在压缩时不需要进行资源释放处理。勾好配置后,找到服务端后进行

二次加壳。压缩完毕,用加壳后的灰鸽子过一下瑞星、卡巴和360,都没有报毒。

中国骇客云教你使用U盘制作进入系统的中钥匙

如今U盘容量越来越大而且价钱越来越低,因而普及率十分之高,置信大家们也动手一个。想不想用U盘作爲开启XP大门的钥匙来维护你的爱机呢?这样他人就会由于没有对应的U盘钥匙而无法开机,平安性自是大爲进步。制造办法十分复杂,也不需第三方软件,只是应用XP本身的工具一组战略,只需3步走。

第一步:先把U盘插上,然后双击翻开“我的电脑”,检查一下本人U盘在Windows XP中

所分配的盘符,我的盘符爲K,将恣意一团体文件复制到U盘的根目录中,我把一个照片放到了外面名字爲“U.JPG”。

第二步:翻开Windows XP的记事本顺序,输出一条命令:if not exist K:\u.jpg shutdown -s -f -t

3 -c”Sorry,你不是本机主人,回绝开机!”

W~$VUM7PH}NBEX_Z@OWH1_N.jpg

其中的“shutdown”既爲关机命令,“-s”爲关机的参数,“-r”爲重启,“-f”爲强迫关机,“-t”后门跟的是倒计时3秒,“-c”提示的关机阐明。本命令的意思是:假如在K盘上我不到“U.jpg”这个文件的话,就显示”Sorry,你不是本机主人,回绝开机!”,之后过3秒就自动关机。当然,假如你在第一步中复制的是“HackerXfiles.mp3”MP3文件也行,只需在相应的命令行中修正一下就可以了。然后将文本另存爲“Check.bat”。将寄存途径定位于Windows XP’的零碎盘C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Startup中(由于GroupPolicy文件夹默许爲隐藏,请先在“文件夹选项”中将其显示,文件的扩展名改爲bat

型,文件名可恣意改,如hackXfiles.bat。

第三步:翻开命令符,间接按Win+R,在外面输出“gpedit.msc”。找到“本地计算机”战略——“计算机配置”——“Windows设置”——“脚本(启动/关机)”,然后双击右侧中的“启动”项;在弹出的“启动属性”窗口中单击“添加”按钮,然后在弹出的“添加脚本”窗口中单击“旅游”按钮,Windows XP会自动定位于零碎盘C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Startup文件夹,单击迭中刚生成的Check.bat批处置文件后在单击“翻开”按钮;之后单击一次“启动”窗口中的“确定”按钮,最初封闭组战略窗口。

OK,一把完满的U盘钥匙曾经打造出来了,只需再启动XP之前将U盘插到主机上。等运转脚本时分会判别能否存在文件“U.JPG”,假如没有发现文件就会3秒后强迫关机,拿起手中的U盘赶快试一下吧!

中国骇客云之图片后门捆绑利用工具FakeImageExploiter?Embedded Backdoor with Image using FakeImageExploiter

backdoor.jpg
在这里,要向大家推荐一款名为“Fake Image Exploiter”的安全工具,该工具可以在图片文件中捆绑隐藏的恶意.bat或.exe程序,方便钓鱼或社工攻击测试过程中的入侵控制。如果受害者点击该恶意图片文件后,将会向控制主机反弹一个管理控制会话。以下是其使用视频:

https://www.youtube.com/watch?v=4dEYIO-xBHU

In this article we are introducing a newly launched hacking tool “Fake Image Exploiter”. It is design so that it becomes easier for attackers to perform phishing or social engineering attacks by generating a fake image with hidden malicious .bat/.exe file inside it.

Let’s start!

Open the terminal inside your kali Linux and type following command to download it from github.

Git clone https://github.com/r00t-3xp10it/FakeImageExploiter.git

Once it gets downloaded then opens the folder and selects the file “settings” for configuration before running the program as shown the given screenshot.

Now made some changes inside setting file as shown the screenshot:

Here you have to declare the type of payload extension you will use to hide it inside the image. You can set any exetension among these four : ps1, bat, txt, exe.  I had set PAYLOAD_EXETNSION=bat similarly set BYPASS_RH=NO and scroll down for next configration.

In same way set these two values also as shown in screenshot then save the changes.

AUTO_PAYLOAD_BUILD=YES

AGENT_HANLER_PORT=4444

After making certain changes in setting file then open the terminal and run the program file:

Cd FakeImageExploiter

./ FakeImageExploiter.sh

Click on YES to execute framework.

Select payload to build as I had choose window/meterpreter/reverse_tcp for attack.

After then a pop up box will open which will allow choosing any jpg image so that it could hide .bat file payload inside that image.

Now select icon for your malicious image.

Give a name to your payload which will be display to victim as file name, from screenshot you can see I had given sales.

Now it generates a link as you can observe it from highlighted part of screenshot and then send this link to victim. Now victim will download the zip file and click on the sales.jpg.

When victim will click on sales.jpg, we will get meterpreter session at the background on metasploit framework.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

配置使用

首先,打开Kali终端,执行下载安装和配置:

git clone https://github.com/r00t-3xp10it/FakeImageExploiter.git

1 (1).png

下载完成之后,进入FakeImageExploiter文件夹,选择setting文件进行配置:

2.png

在此,你可以选择隐藏在图片中的Payload格式,有ps1、bat、txt和exe四种格式可选,我们选择PAYLOAD_EXETNSION=bat;在生成捆绑图片文件的替换图标icon选项中,我们选择BYPASS_RH=NO,非自动,需要手动更改和添加最终生成的图片图标icon。

3.png

同样,在setting文件中找到以下两列进行按需修改:

AUTO_PAYLOAD_BUILD=YES (自动生成Payload选项)

AGENT_HANLER_PORT=4444(植入恶意程序后的客户端监听端口)

4.png

配置选项完成后,可以启动Fake Image Exploiter主程序。

生成Payload

Cd FakeImageExploiter

./ FakeImageExploiter.sh

5.png

选择YES启动Payload生成配置框架:

6.png

选择在捆绑在图片文件中的恶意程序需要加载利用的Payload,这里我们选择window/meterpreter/reverse_tcp:

7.png

之后,会跳出提示框,需要手动选择你需要捆绑.bat Payload进行伪装利用的jpg图片文件:

8.png

以及最终图片文件的替换图标icon主题:

9.png

接下来,为最终捆绑好的恶意图片文件进行命名:

10.png

FakeImageExploiter最后会生成在两个位置生成恶意图片文件,一个为本机Apache2 web服务的根目录下的.zip文件,另外为FakeImageExploiter输出文件夹(output)下的隐藏后缀恶意图片文件,点击执行后,该文件在显示jpg图像的同时,还会隐秘生成一个连向控制主机的反弹管理会话:

11.png

以下是控制端成功连接后显示的反弹管理会话:

12.png

好了,工具介绍完了,但请别用于非法目的哦。

 

Carbon Paper: Peering into Turla’s second stage backdoor窥视Turla的第二阶段的后门

The Turla espionage group has been targeting various institutions for many years. Recently, we found several new versions of Carbon, a second stage backdoor in the Turla group arsenal. Last year, a technical analysis of this component was made by Swiss GovCERT.ch as part of their report detailing the attack that a defense firm owned by the Swiss government, RUAG, suffered in the past.

This blog post highlights the technical innovations that we found in the latest versions of Carbon we have discovered.

Looking at the different versions numbers of Carbon we have, it is clear that it is still under active development. Through the internal versions embedded in the code, we see the new versions are pushed out regularly. The group is also known to change its tools once they are exposed. As such, we have seen that between two major versions, mutexes and file names are being changed.

Infection vectors

The Turla group is known to be painstaking and work in stages, first doing reconnaissance on their victims’ systems before deploying their most sophisticated tools such as Carbon.

A classic Carbon compromise chain starts with a user receiving a spearphishing email or visiting a previously compromised website, typically one that the user visits regularly — a technique known as a watering hole attack.

After a successful attack, a first stage backdoor — such as Tavdig[1]or Skipper[2]— is installed on the user machine. Once the reconnaissance phase is over, a second stage backdoor, like Carbon, is installed on key systems.

Technical analysis

Carbon is a sophisticated backdoor used to steal sensitive information from targets of interest by the Turla group.

This malware shares some similarities with “Uroburos”[3], a rootkit used by the same group. The most relevant resemblance is the communication framework. Indeed, both of them provide communication channels between different malware components. The communication objects are implemented in the same way, the structures and vtables look identical except that there are fewer communication channels provided in Carbon. Indeed, Carbon might be a “lite” version of Uroburos (without kernel components and without exploits).

For Turla group to decide to install Carbon on a system, a (stage 1) recognition tool is usually delivered first to the target: this tool collects several pieces of information about the victim’s machine and its network (through Tavdig or Skipper for example). If the target is considered interesting enough, it will receive more sophisticated malware (such as Carbon or Uroburos).

Global architecture

The Carbon framework consists of:

  • a dropper that installs the carbon components and its configuration file
  • a component that communicates with the C&C
  • an orchestrator that handles the tasks, dispatches them to other computers on the network and injects into a legitimate process the DLL that communicates with the C&C
  • a loader that executes the orchestrator

Carbon Dating

The orchestrator and the injected library have their own development branch.

Thanks to the compilation dates and the internal versions numbers hardcoded in the PE files, we might have the following timeline:

Table 1 – Carbon development timeline

Carbon files

The files from the Carbon framework can have different names depending on the version but they all keep the same internal name (from the metadata) regardless of the version:

  • the dropper: “SERVICE.EXE”
  • the loader: “SERVICE.DLL” or “KmSvc.DLL”
  • the orchestrator: “MSIMGHLP.DLL”
  • the injected library: “MSXIML.DLL”

Each of these files exist in 32bit and in 64bit versions.

Working directory

Several files are created by Carbon to keep logs, tasks to execute and configuration that will modify the malware’s behavior. The contents of the majority of these files are encrypted with the CAST-128 algorithm[4].

A base working directory will contain the files/folders related to Carbon. This directory is chosen randomly among the folders in %ProgramFiles% but excluding “WindowsApps”.

The filenames are hardcoded in the orchestrator. The same names are used in the 3.7x+ branch. Because the injected library accesses the same files as the orchestrator, it is another easy way to link a library version and an orchestrator.

Carbon 3.7x files tree view:
\%carbon_working_folder\%   // base folder├── 0208 // tasks results and logs files│   ├── C_56743.NLS // contains list of files to send to the C&C server, this file is neither compressed nor encrypted├── asmcerts.rs├── getcerts.rs├── miniport.dat  // configuration file├── msximl.dll    // injected library (x32)├── Nls // contains tasks (commands to be executed or PE file) and their configuration files│   ├── a67ncodc.ax  // tasks to be executed by the orchestrator│   ├── b9s3coff.ax  // tasks to be executed by the injected library├── System   // plugins folder│   ├── bootmisc.sdi // not used├── qavscr.dat    // error log├── vndkrmn.dic   // log└── ximarsh.dll   // injected library (x64)

Since version 3.80, all filenames have changed.

Carbon 3.8x files tree view:
\carbon_working_folder\%   // base folder├── 0409  // contains tasks (commands to be executed or PE file) and their configuration files│   ├── cifrado.xml    // tasks to be executed by the injected library│   ├── encodebase.inf // tasks to be executed by the orchestrator├── 1033 // tasks results and logs files│   ├── dsntype.gif // contains list of files to send to the C&C server, this file is neither compressed nor encrypted├── en-US  // plugins folder│   ├── asmlang.jpg // not used├── fsbootfail.dat  // error log├── mkfieldsec.dll  // injected library (x32)├── preinsta.jpg    // log├── wkstrend.xml    // configuration file├── xmlrts.png└── zcerterror.png

File access

In the case of the majority of the files from the Carbon working folder, when one is accessed by the malware, the following steps are taken:

  • a specific mutex is used to ensure its exclusive access.
  • the file is decrypted (CAST-128)
  • when the operations on the file are done, the file is reencrypted (CAST-128)
  • the mutex is released

Mutexes

The following mutexes are created by the orchestrator in Carbon 3.7x:

  • “Global\\MSCTF.Shared.MUTEX.ZRX” (used to ensure exclusive access to “vndkrmn.dic”)
  • “Global\\DBWindowsBase” (used to ensure exclusive access to “C_56743.NLS”)
  • “Global\\IEFrame.LockDefaultBrowser” (used to ensure exclusive access to “b9s3coss.ax”)
  • “Global\\WinSta0_DesktopSessionMut” (used to ensure exclusive access to “a67ncodc.ax”)
  • “Global\{5FA3BC02-920F-D42A-68BC-04F2A75BE158}” (used to ensure exclusive access to new files created in “Nls” folder)
  • “Global\\SENS.LockStarterCacheResource” (used to ensure exclusive access to “miniport.dat”)
  • “Global\\ShimSharedMemoryLock” (used to ensure exclusive access to “asmcerts.rs”)

In carbon 3.8x, the filenames and the mutex names have changed:

  • “Global\\Stack.Trace.Multi.TOS” (used to ensure exclusive access to “preinsta.jpg”)
  • “Global\\TrackFirleSystemIntegrity” (used to ensure exclusive access to “dsntype.gif”)
  • “Global\\BitswapNormalOps” (used to ensure exclusive access to “cifrado.xml”)
  • “Global\\VB_crypto_library_backend” (used to ensure exclusive access to “encodebase.inf”)
  • “Global\{E41B9AF4-B4E1-063B-7352-4AB6E8F355C7}” (used to ensure exclusive access to new files created in “0409” folder)
  • “Global\\Exchange.Properties.B” (used to ensure exclusive access to “wkstrend.xml”)
  • “Global\\DatabaseTransSecurityLock” (used to ensure exclusive access to “xmlrts.png”)

These mutexes are also used in the injected dll to ensure that the orchestrator has been executed.

Configuration File

The configuration file affects the malware’s behavior. The file format is similar to “inf” files used by Windows. It contains among others:

  • an “object_id” that is a unique uuid used to identify the victim, when the value is not set in the file, it is generated randomly by the malware
  • a list of processes into which code is injected (iproc)
  • the frequency and time for task execution / backup logs / connection to the C&C ([TIME])
  • the IP addresses of other computers on the network ([CW_LOCAL])
  • the C&C server addresses ([CW_INET])
  • the named pipes used to communicate with the injected library and with the other computers ([TRANSPORT])

This file might be updated later. Indeed, in the communication library, some cryptographic keys are used to encrypt/decrypt data and these keys are retrieved from a section [CRYPTO] in the configuration file that does not exist when the file is dropped from the loader resources.

Carbon 3.77 configuration file:
[NAME]object_id=iproc = iexplore.exe,outlook.exe,msimn.exe,firefox.exe,opera.exe,chrome.exeex = #,netscape.exe,mozilla.exe,adobeupdater.exe,chrome.exe[TIME]user_winmin = 1800000user_winmax = 3600000sys_winmin = 3600000sys_winmax = 3700000task_min = 20000task_max = 30000checkmin = 60000checkmax = 70000logmin =  60000logmax = 120000lastconnect=111timestop=active_con = 900000time2task=3600000[CW_LOCAL]quantity = 0[CW_INET]quantity = 3address1 = doctorshand.org:80:/wp-content/about/address2 = www.lasac.eu:80:/credit_payment/url/address3 = www.shoppingexpert.it:80:/wp-content/gallery/[TRANSPORT]system_pipe = comnapspstatus = yesadaptable = no[DHCP]server = 135[LOG]logperiod = 7200[WORKDATA]run_task=run_task_system=

Logfile

The Carbon framework includes a logfile that is used to log actions performed by the malware and information on the system that can be useful to the malware operator (for example if an analysis tool such as WireShark is running on the machine).

The log’s format has not changed since Carbon 3.71:

  • Date|Time|Object-Id|Source|Message
example
[LOG]start=120/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|OPER|New object ID generated '8hTdJtUBB57ieReZAOSgUYacts'|20/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|ST|3/81|0|20/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|START OK

This file is periodically backed up and sent to the C&C.

Dropper

The dropper is the only executable that is not a DLL. It is the first PE file to be executed: it is used to extract the other components from its resources.

The PE files that are used to load the main components are extracted into the Windows system directory while the orchestrator, the library used to communicate with the C&C and the configuration file are extracted into the Carbon working directory.

A new section is appended into a random “.inf” file from %SystemRoot%\INF. The section’s name is the volume serial disk number of the compromised machine and a value “root” is created with the chosen Carbon working directory.

Example:
[5049654F]root="C:\Program Files\Windows Portable Devices"

Loader

This part of the component is used to load the orchestrator.

A service that ensures Carbon’s persistency is created. Its name can either be “srservice”, “ipvpn” or “hkmsvc” depending of the operating system version running on the compromised machine.

The Carbon working directory is retrieved by walking through the “%windir%\inf” folder and looking for the file that contains the Carbon base path.

Last but not least, the function “ModuleStart” (in Carbon 3.71) or “ModStart” (since Carbon 3.77) from the orchestrator (located in the Carbon base folder) is called.

Orchestrator

The orchestrator is the main component of the Carbon framework. It is mainly used to inject code into a process that communicates legitimately over the Internet and to dispatch the tasks received from the injected library to other computers on the same network either through named pipes or TCP.

Seven threads are created by the malware. It is easy to identify Carbon’s characteristics because each thread has a specific role:

Configuration fetching

Because the configuration file can be updated by the malware, some attributes like the C&C server addresses are monitored every 10 minutes.

Check Carbon storage folder periodically

There is a storage folder located in the Carbon working directory. This folder contains some files downloaded from the C&C server (tasks that are either commands to be executed or PE files, and their configuration files).

This thread will run continuously and check every two hours[5]whether there is still enough space available in this folder; if not, a notification is written into the logfile.

Task execution

The execution of the tasks in the context of the orchestrator process is very similar to the way in which it is performed in the communication library (cf Communication library / Tasks execution).

Unlike the communication library, it is the file “encodebase.inf” (for Carbon v3.8x) or “a67ncode.ax” that contains the list of the tasks to execute.

Each line of this file is composed in the following way:

  • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath | [execution_mode | username | password]

The five first fields are required, while the last three are optional. If the field “execution_mode” exists, its value will affect the way the task is executed:

  • 0 or 1: normal execution
  • 2: the task is executed in the security context of a specific user (credentials are provided through the username/password fields)
  • 3 or 4: the task is executed in the security context of the user represented by the “explorer.exe” token

P2P

Like Uroburos/Snake, Carbon can dispatch tasks to other computers from the same network via named pipe or TCP. It is useful to be able to dispatch and execute tasks on computers that do not have Internet access.

Communication channels

Uroburos used several types of communication transports than can be categorized as follows:

  • type 1: TCP
  • type 2: enc, np, reliable, frag, m2b, m2d
  • type 3: t2m
  • type 4: UDP, doms, domc

Carbon uses a reduced number of communication channels:

  • type 1: TCP, b2m
  • type 2: np, frag, m2b

The data sent to peers are usually fragmented and transported either by TCP or via a named pipe. If, for example, fragmented data are sent from a computer to another one by a named pipe, an object “frag.np” is set up. In this case the mother class “frag” constructor will be called followed by a call to the constructor subclass “np”.

There is a structure composed of several handlers for each objects: initialize communication, connection (to a pipe / IP address), read data, send data etc.

How a task is forwarded to another computer

Several steps are performed to send data from one computer to another:

  • a communication channel is created (frag.np or frag.tcp object) with a specific named pipe / ip address
  • options are given to the object communication (for example : the fragment’s size, information about the peer etc.)
  • connection to the peer
  • an authentication step is performed between the host and the peer:
    • there is a handshake process where the host is sending the “magic” value “A110EAD1EAF5FA11” and expects to receive “C001DA42DEAD2DA4” from the peer
    • a command “WHO” is sent to the peer where the host sends the victim uuid and expects to receive the same uuid
  • if the authentication was successful, the data are sent to the peer

All the communication between the host and the peer are encrypted with CAST-128

Note that this P2P feature is also implemented in the communication DLL.

Plugins

This malware supports additional plugins to extend its functionalities.

In the configuration file, there is a section named “PLUGINS”. It might not exist when the configuration file is dropped from the loader resources but this file can be updated by the malware. The section “PLUGINS” contains a line formed this way:

  • %plugin_name%=%enabled%|%mode%[:%username%:%password%]|%file_path%

%file_path% can be either the path to a PE file or to a file containing a command line to be executed. %enabled% is a string that is used to know if the plugin has to be executed. If it is the case, that string value is “enabled”.

The attribute %mode% is used to control the context in which to execute the PE file/command line. It can be either:

  • 1 = execution with current user privilege in the current process context through CreateProcess().
  • 2 = execution as the user specified in the configuration (:%username%:%password% attributes), the token of this specific user is retrieved through the LogonUserAs() function.
  • 3 = execution in the security context of the user represented by the “explorer.exe” token (the token of the process “explorer.exe” is duplicated and passed through the CreateProcessAsUser() function.
  • 4 = similar than 3 but the environment variables for the user represented by the “explorer.exe” token are retrieved and passed to the function CreateProcessAsUser()

If it is a PE file:

  • the file is loaded into the malware process memory
  • the module is parsed to check if it is a DLL
  • if the module is a DLL and exports a function “ModStart” (since Carbon 3.77) or “ModuleStart” (for older versions of Carbon), a new thread is created to execute this function.
  • if the module is not a DLL but a valid PE, it is executed from the entry point.

Injection of the communication library into remote processes

The library that is used to communicate with the C&C server is injected into remote processes. In order to know where to inject this DLL, the configuration file is parsed. The section “[NAME]” contains a field “iproc” containing a list of processes that can legitimately communicate to Internet.

Example:
[NAME]iproc = iexplore.exe,outlook.exe,msimn.exe,firefox.exe,opera.exe,chrome.exe

For each process on the list that is running on the system, if its parent process name is either “explorer.exe” or “ieuser.exe”, the DLL will be injected into this process.

The process injection is very classical:

  • the functions “CreateToolHelp32Snapshot / Module32FirstW / Module32NextW” are used to retrieve the base address of the module “kernel32.dll”
  • the module EAT is parsed to get the address of the function “LoadLibraryW”
  • the privilege “SeDebugPrivilege” is enabled for the current process
  • memory is allocated into the remote process and the library path is written into it
  • NtCreateThreadEx or CreateRemoteThread (if the address of the first function cannot be retrieved) is called to execute LoadLibraryW to load the DLL into the memory of the remote process *

Communication library

The following analysis is based on the version 4.x of msximl. This component may have changed in the latest versions.

Configuration fetching

Besides the code in the “Configuration fetching” thread from the orchestrator (which is similar), a field “sethttp1” is retrieved from the [TRANSPORT] section.

If this value is set, HTTP 1.1 will be used for future connections.

Tasks execution

The tasks are retrieved from the C&C server.

The tasks to be executed by the communication library are listed in the file “b9s3coff.ax” (for Carbon v3.7x) or “cifrado.xml” (for Carbon v3.8x).

Each line of this file is composed in the following way:

  • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath

The task file and its config are decrypted (CAST-128) and the task executed. There are some options that are retrieved from the Carbon configuration file: “time2task” is used to set a timeout for the task execution (1 hour by default) while “task_min” and “task_max” are used as to wait a random time between the execution of the tasks on the task list (the random time will be set between “task_min” and “task_max”). These parameters come from the section [TIME].

If the task is a valid DLL file, it is loaded in the current process memory and a new thread is created to execute its “start” export. Otherwise, this is probably a command to execute. In this case, the configuration file is parsed. Like the Carbon configuration file, the task configuration file is formed as a windows “inf” file and should contain a section [CONFIG] with the following parameters:

  • [CONFIG]
    • NAME (“cmd.exe” by default)
    • ARG
    • RESULT (“stdout” by default)
    • COMPRESSION (“yes” by default)
    • DELETE (“no” by default)

The command with its arguments is executed through CreateProcess() function and the results are stored in the %task_result_filepath% file if the RESULT option is not set to “stdout”, while error or additional info are added to the task logfile.

If the option RESULT is set to stdout:

  • the result task file is deleted and the task execution output is written to the log task file
  • the line “task_id | “1” | task_log_filepath | object_id” is added at the end of the file “C_56743.NLS” (Carbon 3.7x) or “dsntype.gif” (Carbon 3.8x)

Otherwise:

  • the task execution is outputted to the task result file and the errors / additional info to the task logfile
  • the line “task_id | “2” | task_log_filepath | task_result_filepath | object_id” is added at the end of the file “C_56743.NLS” (Carbon 3.7x) or “dsntype.gif” (Carbon 3.8x)

In both cases, the same line as written into “C_56743.NLS” is also written into the field “run_task” from the Carbon configuration file. It might be intended as a way for the malware authors to know which is the last task executed when the configuration file is sent to the C&C server (check “Configuration file backup”).

Log rotation

The logfile is backed up and sent to the C&C server periodically (by default this is done every two hours).

Like the backup of the configuration file, this action is performed only during specific times of the day.
Indeed, the log rotation will be performed only when the current local time is in the range of what is defined in the configuration file.

The fields “wh_min” and “wh_max” are retrieved from the [TIME] section of the configuration file (by default: 8 and 20). The thread will execute the code only if the current hour of the day is between %wh_min% and %wh_max%.

If there is a value for the attribute “timestop” from the [TIME] section (which looks like “wDay:wMonth:wYear:wHour:wMinute”), the thread will execute the code only after this specific datetime.

The attributes “lastsend” and “logperiod” from the [LOG] section are used to specify a delay time when to backup and send the log to the C&C server. (by default: every two hours).

A temporary file with a random name prefixed by “~D” is created in the folder “208” (for Carbon v3.7x) or “1033” (for Carbon v3.8x). The logfile content is copied into this new file. It is then compressed with Bzip2 and encrypted (CAST-128).

A new line is added at the end of the file “C_56743.NLS” (for Carbon v3.7x) or “dsntype.gif” (for Carbon v3.8x):

  • “10|1|%s|%s”
    • 1st field: an ID to identify the file as a logfile
    • 2nd field: 1 (file to be sent to the C&C server)
    • 3rd field: the temp file path
    • 4rd field: the victim uuid

Last but not least, the attribute “lastsend” is updated with the current time and the original logfile is deleted.

Communication with the C&C server

The code of this thread is used to retrieve new tasks from the C&C server, to send new files to the server (the files listed in the file “C_56743.NLS” / “dsntype.gif”) and to send the new tasks to the orchestrator.

First request

A random C&C server address is chosen from the ones in the section “CW_INET”. If the port and HTTP resource path are not specified, the default is to use port 80 and “/javascript/view.php”.

A user agent is set up in the following way:

  • the version of Internet Explorer is retrieved through the registry key: “HKLM\Software\Microsoft\Internet Explorer\Version” and is concatenated to the string “Mozilla/4.0 (compatible; MSIE %d.0; ”
    • example: “Mozilla/4.0 (compatible; MSIE 8.0.6001.18702.0;”
  • concatenate the previous string with the OS major/minor version values (through GetVersionExA())
    • “Mozilla/4.0 (compatible; MSIE 8.0.6001.18702.0; Windows NT 5.1; Trident/4.0”
  • enumerate the values key in “HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform” and concatenate each value to the previous string and then append a closing paren.
    • example: “Mozilla/4.0 (compatible; MSIE 8.0.6001.18702.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; Media Center PC 6.0; SLCC2)

The field “trans_timemax” from the section [TIME] is retrieved. It is used to set the timeout for internet requests (through InternetSetOption()). It has a value of 10 minutes by default.

A first GET request is performed on the root page of the C&C web server to check that the host is alive. If no packet capture is running on the system, a new request is done on the C&C server to check if new tasks are available. A “PHPSESSID” cookie is added to the request with the victim uuid as its value. A header “Referer” is added as well and set to the C&C server URL.

The malware is expecting to get an answer to the GET request similar to:

  • <input name=”%name%” value=”%data_in_b64%”>

If the field “value” contains something, a new task is available.

Send data to the server

If the file “C_56743.NLS” / “dsntype.gif” is not empty, it means there are data to be sent the C&C server. The file is parsed and the last line is retrieved. It contains details about the data to be sent. A data blob is built and each of the following fields is encrypted with CAST-128:

  • id | val | tmp_filesize | tmp_content | [OPTIONAL (if val == 2) tmp2_filesize | tmp2_content] | len_object_id | object_id
    • id = the type of data to send to the C&C server, it can be:
      • 10: log backup
      • 11: configuration file
      • 20: a cryptographic key
      • otherwise: an id associated to a task, it can be the result of a task or an error log in the case of task execution failure
    • val = 1 if there is only one file to send, 2 if there are two files
    • object_id = the victim uuid

If the field “dtc” from the section [CRYPTO] of the configuration file is set to 0, this whole blob is base64 encoded and sent to the C&C server through a POST request.

Otherwise, another layer of encryption is used. In this case, the data blob is signed and a random 3DES key is used to encrypt it. Because the 3DES key is randomly generated and the server needs it to decrypt the data, the key is encrypted with the server public key. The server key is retrieved from the field “publicc” of the section [CRYPTO] from the configuration file.

This new blob (encrypted_key | signature_data | encrypted data) is encoded in base64 and sent to the C&C server through a POST request.

In order to avoid detection based on the data size sent in a request, the blob can be fragmented into several packets. An option in the configuration file (“post_frag” in the section [TRANSPORT]) defines whether the blob will be fragmented or sent in only one POST request.

If this option is set to “yes”, the blob is divided into several fragments of a specific size. This size comes from another field in the configuration file: “post_frag_size”.

An additional header will be added to the request:

  • “Content-Range: bytes %u-%u/%u; id=%u\r\n”, i, i+(fragment_size-1), data_size, task_id”

If the option http11 is set, a specific header is added as well:

  • “Expect: 100-continue\r\n”

For each fragments sent, the fields “post_frag_size” and “pfslastset” from the config file (section [CW_INET_RESULTS]) are updated with the fragment size and the timestamp.

Get new tasks

New tasks are retrieved from the C&C server by parsing the html page. The malware expects to find the html tag <input> in the page with a base64 encoded blob in its “value” attribute. Once decoded, this blob contains:

  • an encrypted block of 128 bytes that contains a structure “PUBLICKEYSTRUC” followed by a cryptographic key (probably a 3DES key)
  • signature data (128 bytes) to verify the integrity of the next block
  • a block of encrypted data that contains the task

The malware uses an RSA private key (retrieved from the field “keypair” from the section [CRYPTO] of the configuration file) to decrypt the first block and then uses the freshly decrypted key to decrypt the third block. This block of data can be either:

  • a task to be executed[6]
    • the data are decrypted and stored in few temporary files, the task (a command or a PE file) and its configuration file in the “Nls” folder and the output files (file that will contains the task results and the logfile) are stored in the folder “0208” (or respectively “0409” and “1033” for Carbon v3.8x)
    • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath
    • this line is appended to beginning of the file “b9s3coff.ax” (cifrado.xml on v3.8x)
  • a task to be executed by the orchestrator[7]
    • the data are decrypted and stored in few temporary files (the task, its configuration etc) in the “Nls” and “0208” folder (or “0409” and “1033” for Carbon v3.8x)
    • depending of the content of the data, one of these lines will be added to the beginning of the file “a67ncode.ax” (encodebase.info on v3.8x)
      • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath
      • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath | execution_mode | username | password
      • task_id | task_filepath | task_config_filepath | task_result_filepath | task_log_filepath | execution_mode
  • a new RSA server public key
    • in this case, the configuration file is updated with the new key encoded in base64 (field publicc)
  • data to be sent to an instance of Carbon running in another computer in the same network
    • the data can contains a specific IP address and port, a named pipe or a named pipe with a username and password.

Check Internet availability

Each hour, the internet connection is checked. A first check is done by calling the function InternetAttemptConnect(). If it works, another test is done by sending HTTP GET requests to the following websites:

  • www.google.com
  • www.yahoo.com
  • www.bing.com
  • update.microsoft.com
  • windowsupdate.microsoft.com
  • microsoft.com

An event is used to notify the other threads in case of the loss of Internet access.

Configuration file backup

Similar to the logfile, the configuration file is also periodically backed up and sent to the C&C server. The thread executes the code in a specific range of time (between 8h and 20h by default)[8].

The value “configlastsend” is retrieved from the section [TIME] of the configuration file. If the config file has been sent over a month ago, the config file is copied into a temporary file with a random name prefixed by “~D” in the folder “208” (for Carbon v3.7x) or “1033” (for Carbon v3.8x). This file is then encrypted with CAST-128 algorithm.

To notify the thread that communicates with the C&C server that a new file is ready to be sent to the server, the following line is appending to the file “C_56743.NLS” (for Carbon v3.7x) or “dsntype.gif” (for Carbon v3.8x):

  • “11|1|%s|%s”
    • 1st field: an ID to identify the file as a config file
    • 2nd field: 1 (file to be sent to the C&C server)
    • 3rd field: the temp filepath
    • 4rd field: the victim uuid

Last but not least, the attribute “configlastsend” is updated with the current time.

Additional Notes

Calling API functions

The base address of the modules of interest are retrieved by either parsing the PEB or (if the modules are not loaded into the process memory) by loading the needed files from disk into memory and parsing their headers to get their base addresses.

Once the base addresses are retrieved, the PEB is walked again and the field “LoadCount” from the structure LDR_DATA_TABLE_ENTRY is checked. This value is used as a reference counter, to track the loading and unloading of a module.

If “LoadCount” is positive, the module EAT is parsed to get the needed function address.

Encryption

The module and function names are encrypted (at least since v3.77; it was not the case in v3.71) in a simple way, a logical shift of 1 bit being applied to each characters.

The processes’ names are encrypted as well by just XOR’ing each character with the key 0x55 (for Carbon v3.7x at least since v3.77) and with the key 0x77 for Carbon v3.8x.

With only a few the exceptions, each file from the Carbon working directory is encrypted with the CAST-128 algorithm in OFB mode. The same key and IV are used from the version 3.71 until the version 3.81:

  • key = “\x12\x34\x56\x78\x9A\xBC\xDE\xF0\xFE\xFC\xBA\x98\x76\x54\x32\x10”
  • IV = “\x12\x34\x56\x78\x9A\xBC\xDE\xF0”

Check if packet capture is running

Before communicating with the C&C server or with other computers, the malware ensures that none of the most common packet capture software is running on the system:

  • TCPdump.exe
  • windump.exe
  • ethereal.exe
  • wireshark.exe
  • ettercap.exe
  • snoop.exe
  • dsniff.exe

If any of these processes are running, no communication will be done.

Carbon IoCs are also available on ESET’s GitHub repositoryhttps://github.com/eset/malware-ioc/tree/master/turla

Appendices

Yara rules

import “pe”

rule generic_carbon
{
strings:
$s1 = “ModStart”
$s2 = “ModuleStart”
$t1 = “STOP|OK”
$t2 = “STOP|KILL”
condition:
(uint16(0) == 0x5a4d) and (1 of ($s*)) and (1 of ($t*))
}

rule carbon_metadata
{
condition:
(pe.version_info[“InternalName”] contains “SERVICE.EXE” or
pe.version_info[“InternalName”] contains “MSIMGHLP.DLL” or
pe.version_info[“InternalName”] contains “MSXIML.DLL”)
and pe.version_info[“CompanyName”] contains “Microsoft Corporation”
}

Carbon files decryptor/encryptor

carbon_tool.py

#!/usr/bin/env python2

from Crypto.Cipher import CAST
import sys
import argparse

def main():

parser = argparse.ArgumentParser(formatter_class=argparse.RawTextHelpFormatter)
parser.add_argument(“-e”, “–encrypt”, help=”encrypt carbon file”, required=False)
parser.add_argument(“-d”, “–decrypt”, help=”decrypt carbon file”, required=False)

try:
args = parser.parse_args()
except IOError as e:
parser.error(e)
return 0

if len(sys.argv) != 3:
parser.print_help()
return 0

key = “\x12\x34\x56\x78\x9A\xBC\xDE\xF0\xFE\xFC\xBA\x98\x76\x54\x32\x10”
iv = “\x12\x34\x56\x78\x9A\xBC\xDE\xF0”

cipher = CAST.new(key, CAST.MODE_OFB, iv)

if args.encrypt:
plaintext = open(args.encrypt, “rb”).read()
while len(plaintext) % 8 != 0:
plaintext += “\x00”
data = cipher.encrypt(plaintext)
open(args.encrypt + “_encrypted”, “wb”).write(data)
else:
ciphertext = open(args.decrypt, “rb”).read()
while len(ciphertext) % 8 != 0:
ciphertext += “\x00”
data = cipher.decrypt(ciphertext)
open(args.decrypt + “_decrypted”, “wb”).write(data)

if __name__ == “__main__”:
main()

Open Source documentation

Carbon footprint

Table 2 – Carbon sample hashes
SHA1 hash
7f3a60613a3bdb5f1f8616e6ca469d3b78b1b45b
a08b8371ead1919500a4759c2f46553620d5a9d9
4636dccac5acf1d95a474747bb7bcd9b1a506cc3
cbde204e7641830017bb84b89223131b2126bc46
1ad46547e3dc264f940bf62df455b26e65b0101f
a28164de29e51f154be12d163ce5818fceb69233
7c43f5df784bf50423620d8f1c96e43d8d9a9b28
7ce746bb988cb3b7e64f08174bdb02938555ea53
20393222d4eb1ba72a6536f7e67e139aadfa47fe
1dbfcb9005abb2c83ffa6a3127257a009612798c
2f7e335e092e04f3f4734b60c5345003d10aa15d
311f399c299741e80db8bec65bbf4b56109eedaf
fbc43636e3c9378162f3b9712cb6d87bd48ddbd3
554f59c1578f4ee77dbba6a23507401359a59f23
2227fd6fc9d669a9b66c59593533750477669557
87d718f2d6e46c53490c6a22de399c13f05336f0
1b233af41106d7915f6fa6fd1448b7f070b47eb3
851e538357598ed96f0123b47694e25c2d52552b
744b43d8c0fe8b217acf0494ad992df6d5191ed9
bcf52240cc7940185ce424224d39564257610340
777e2695ae408e1578a16991373144333732c3f6
56b5627debb93790fdbcc9ecbffc3260adeafbab
678d486e21b001deb58353ca0255e3e5678f9614
Table 3 – C&C server addresses (hacked websites used as 1st level of proxies
C&C server address
soheylistore.ir:80:/modules/mod_feed/feed.php
tazohor.com:80:/wp-includes/feed-rss-comments.php
jucheafrica.com:80:/wp-includes/class-wp-edit.php
61paris.fr:80:/wp-includes/ms-set.php
doctorshand.org:80:/wp-content/about/
www.lasac.eu:80:/credit_payment/url/
Notes
5. two hours by default, but the waiting time depends of the field value “logperiod” from the “LOG” section of the configuration file
6. check “Tasks execution” part for more details
7. check “Orchestrator / Tasks execution” part for more details
8. depending of the config file, check “Log rotation” for the details