Volatility, Python ile yazılmış açık kaynak kodlu bir memory forensics (framework) çatısıdır. Volatility, 32 ve 64 bit Windows, Linux, OSX, Android platformların memory dump (bellek dökümü) dosyalarını analiz edebiliyor ve aynı zamanda Windows, Linux, OSX platformlarında analiz yapmamıza da olanak sağlıyor. [1]

Öncelikle elimizde analizini yapacağımız sistemin bir bellek dökümü dosyasının olması gerekiyor. Analiz etmek istediğiniz sistem Windows ise, bellek dökümünü MoolSols firmasının Windows Memory Toolkit ürününün free versiyonu yardımı ile alabilirsiniz. [2] *nix sistemler üzerinde bellek dökümü almak için ise fmem aracını kullanabilirsiniz. [3] [3.1]

Bu yazıda örnek olarak ZeuS zararlı yazılımının bulaşmış olduğu bir makinanın bellek dökümünü Volatility ile inceleyeceğiz. Örnek dosyayı bu bağlantıdan indirebilirsiniz.

-- http://publish.boateknoloji.com/wp-content/uploads/2014/01/zeus.vmem.zip

 

Volatility’nin düzgün çalışabilmesi için sisteminizde bazı araçların kurulu olması gerekiyor. Bunlar Distorm3, Yara, PyCrypto, PIL ve OpenPyxl [4]. Volatility’i sisteminize indirmek için aşağıdaki komutu kullanabilirsiniz. Herhangi bir kuruluma gerek kalmadan ~/Volatility dizini içinde çalışır hale gelecektir.

$ svn checkout http://volatility.googlecode.com/svn/trunk Volatility

 

Volatility’nin çalışma yapısını ve şablonunu inceleyelim.

$ python vol.py [PLUGIN] -f [IMAGE] --profile=[PROFILE]

 

İlk olarak ‘python vol.py’ komutu ile Volatility’nin çalışmasını sağlıyoruz. Devamında ise Volatility’nin işlem yapabilmesi için bizden beklediği parametreleri giriyoruz. Bunlar;

[PLUGIN]: Volatility’nin hangi eklentisini kullanmak istediğimizi,

-f [IMAGE]: Hangi bellek dökümü dosyası üzerinde işlem yapmak istediğimizi,

--profile=[PROFILE]: Hangi profilde analiz yapmak istediğimizi belirtir. (Volatility genel olarak profili belirtmeden de işlem yapabiliyor. Ancak daha iyi sonuçlar alabilmek için profili belirtmemiz gerekir.)

 

Eklentiler, profiller gibi diğer bütün objeler hakkında bilgi almak için aşağıdaki komutu çalıştırabilirsiniz.

$ python vol.py --info

 

Tüm komutlar ve seçenekleri görmek için ise aşağıdaki komutu çalıştırmanız yeterli olacaktır.

$ python vol.py -h

 

Bir plugin hakkında detaylı bilgi almak için de aşağıdaki komutu kullanabilirsiniz.

$ python vol.py [PLUGIN] -h

 

Eğer her seferinde profil tanımlaması ve bellek dökümü dosyasının yolu gibi parametreleri belirtmek istemiyorsanız Volatility için ortam değişkenleri (environment variable) tanımlayabilirsiniz.

Profil değişkeni atamak için:

$ export VOLATILITY_PROFILE=[PROFILE]

 

Dosya yolu değişkeni atamak için:

$ export VOLATILITY_LOCATION=file:///[PATH]

 

komutlarını kullanabilirsiniz. Bu değişkenleri atadıktan sonra aşağıdaki gibi basit ve sade bir şekilde Volatility’i çalıştırabilirsiniz.

$ python vol.py [PLUGIN]

 

Eğer daha spesifik bir konfigürasyon yapmak istiyorsanız bunu .volatilityrc dosyası ile yapabilirsiniz. .volatilityrc dosyası standart olarak kullanıcının ana dizininde algılanır. Eğer farklı bir dizindeki .volatilityrc dosyası ile işlem yapmak istiyorsanız bunun için aşağıdaki komutu kullanmalısınız.

$ python vol.py --conf-file:[PATH]

 

.volatilityrc dosyasının içeriği şuna benzemektedir:

[DEFAULT]
PROFILE=[PROFILE]
LOCATION=file:///[PATH]

 

Not: Eğer ortam değişkeni tanımladıysanız .volatilityrc dosyası ile çakışma yaşanabiliyor, .volatilityrc dosyasını kullanmak istiyorsanız önce ortam değişkenlerini unset komutu ile kaldırmanız gerekiyor.

$ unset VOLATILITY_PROFILE$ unset VOLATILITY_LOCATION

 

Volatility’den temel olarak bahsettik, şimdi bellek dökümü dosyamız üzerinde Volatility’nin bir kaç plugininden bahsedelim. Öncelikle imageinfo pluginini kullanarak başlayacağız. imageinfo, bellek dökümü dosyamız hakkında bize aşağıdaki gibi detaylı bir bilgi sunacaktır.

$ python vol.py -f ~/sample/zeus.vmem imageinfo

 

imageinfo

Burada Suggested Profile(s) kısmında gördüğümüz gibi Volatility bize iki profil önerdi. Bu profilleri belirterek, Volatility’nin belirtmiş olduğumuz profile göre işlem yapmasını sağlayabiliriz.

Diğer bir pluginimiz pslist bellek dökümünü almış olduğumuz sistemde o anda çalışan tüm işlemlerin (process) listesini detayları ile birlikte getiriyor.

$ python vol.py -f ~/sample/zeus.vmem pslist

 

pslist

pstree plugini ise o anki çalışan işlemlerin listesini bir işlem ağacı şeklinde getiriyor.

$ python vol.py -f ~/sample/zeus.vmem pstree

 

pstree

 

psxview plugini PsActiveProcessHead içeriği ile çeşitli diğer kaynakların raporladıkları işlem listelerinin neler olduğunu karşılaştırarak gizli işlemleri tespit etmemize yardımcı oluyor.

psxview

devicetree plugini ile sistemde bulunan aygıtların listesini ağaç şeklinde görebiliyoruz.

$ python vol.py -f ~/sample/zeus.vmem devicetree

 

devicetree

 connscan plugini ile sistemden dışarıya herhangi bir bağlantı olup olmadığını tarayabiliyoruz.

$ python vol.py -f ~/sample/zeus.vmem connscan

 

connscan

 

apihooks plugini, işlemlerde ve çekirdek belleğinde (kernel memory) herhangi bir hooking [5] olup olmadığını kontrol eder ve var ise bunları gösterir.

$ python vol.py -f ~/sample/zeus.vmem apihooks

 

Belirli bir işleme ait hooking olup olmadığını kontrol etmek için ise apihooks pluginine -p [PID] parametresini ekliyoruz.

$ python vol.py -f ~/sample/zeus.vmem apihooks -p 856

 

apihooks

threads plugini, bize eğer mevcutsa her iş parçacığının (threads) kayıtlarının içeriği de dahil olmak üzere, iş parçacığının başlangıç adresinde bulunan kodun disassemblysi ve analizle ilgili olabilecek çeşitli diğer alanlarda geniş bir bilgi verir.

$ python vol.py -f ~/sample/zeus.vmem threads

 

threads

threads plugini için bazı filtreler uygulayabilirsiniz, bunların listesini görmek için threads pluginini -L parametresi ile birlikte çalıştırın.

$ python vol.py threads -L

 

threads-L

Çıktıda bulunan filtreleri -F [FILTERNAME] parametresi ile kullanabilirsiniz.

threads-F_System

thrdscan pluginini, fiziksel bellekteki ETHREAD nesneleri ve (ETHREAD bir ana işlem esaslı olduğundan) gizli işlemleri taramak için kullanabilirsiniz.

$ python vol.py -f ~/sample/zeus.vmem thrdscan

thrdscan

malfind plugini gizli veya kod enjekte edilmiş DLL dosyalarını bulmamıza yardımcı olur ve -D [PATH] parametresini de beraberinde vermemizle birlikte bulguları bir dump dosyasına kaydeder. malfind pluginini tek bir işlem (process) için kullanmak istiyorsak -p [PID] parametresini de vermemiz gerekiyor.

$ python vol.py -f ~/sample/zeus.vmem malfind -D ~/dumps -p 856

 

malfind

clipboard plugini kullanıcıların panolarındaki veriyi geri getirmek için kullanılır.

$ python vol.py -f ~/sample/zeus.vmem clipboard

 

clipboard

screenshot plugini, sistemin ekran görüntüsünü wire-frame diagram şeklinde bize verir. screenshot pluginine -D [PATH] parametresi ile ekran görüntülerinin nereye kaydedileceğini belirtiyoruz.

$ python vol.py -f ~/sample/zeus.vmem screenshot -D ~/screenshots

 

screenshot

Kaydedilen ekran görüntüleri aşağıdakine benzer şekilde olacaktır.

screenshot-preview

 

cmdscan plugini, saldırganların konsol kabuğunu (cmd.exe) kullanarak girdikleri komutlar için bellekte arama yapar.

$ python vol.py -f ~/sample/zeus.vmem cmdscan

 

cmdscan

Bazı komutlara böylece değinmiş olduk, şimdi adım adım elimizdeki bellek dökümü dosyasının analizini yapalım.

Öncelikle elimizdeki bellek dökümü dosyası hakkında bilgi edinerek başlıyoruz.

$ python vol.py -f ~/sample/zeus.vmem imageinfo

imageinfo

Komutu çalıştırdıktan sonraki çıktıyı incelediğimizde Volatility bize sistemin WinXPSP2x86 veya WinXPSP3x86 profilinde olabileceği önerisinde bulunuyor. Bellek dökümünün alındığı tarih ve yerel zaman da çıktıda belirtilmiş.

Biz herhangi bir profil ataması yapmadan analizimize devam edeceğiz. Sistemde herhangi şüpheli bir işlemin çalışıp çalışmadığını kontrol etmek üzere pslist pluginini kullanarak çalışan tüm işlemlerin listesini alıyoruz.

$ python vol.py -f ~/sample/zeus.vmem pslist

 

pslist

İlk bakışta göze çarpan, şüpheli gibi görünen bir işlem görünmüyor. İncelemeye devam edelim. connscan plugini ile herhangi aktif bir bağlantı olup olmadığını kontrol edelim.

$ python vol.py -f ~/sample/zeus.vmem connscan

 

connscan

Çıktıyı incelediğimizde 856 işlem numarasına (PID) sahip işlemin, 172.16.176.143 IP numarasına sahip yerel adresin 1054/TCP, 0.0.0.0 IP numarasına sahip yerel adresin de 1056/TCP portu üzerinden; 193.104.41.75 IP numarasına sahip uzak sunucunu ile 80/TCP portu üzerinden iletişimde olduğunu görüyoruz.

193.104.41.75 IP adresi hakkında bilgi edinelim. (http://www.whois.sc/193.104.41.75)

Daha önceki pslist pluginine ait çıktımızdan 856 işlem numarasına sahip işlemin svchost.exe olduğunu biliyoruz. pstree pluginini kullanarak svchost.exe’nin işlem ağacındaki yerine gözatalım.

$ python vol.py -f ~/sample/zeus.vmem pstree

 

pstree

 

Çıktıyı incelediğimizde svchost.exe’nin services.exe altında çalışan bir işlem olduğunu görüyoruz. svchost.exe için malfind pluginini kullanarak enfekte olmuş mu kontrol edelim. malfind pluginine -D [PATH] parametresi ile dump dosyasının nereye çıkarılacağını ve -p [PID] parametresi ile de hangi işlem üzerinde çalışacağımızı belirtiyoruz.

$ python vol.py -f ~/sample/zeus.vmem malfind -D ~/dumps -p 856

 

malfind-p856

Dump dosyalarımızın kaydedildiği dizine bir gözatalım.

$ ls ~/dumps

ls-dumps

Gördüğümüz gibi malfind plugini process.0x80ff88d8.0xb70000, process.0x80ff88d8.0xcb0000 isimli iki .dmp dosyası oluşturmuş. Bu oluşturulan .dmp dosyalarını VirusTotal aracılığıyla tarayalım.

 

virustotal-1

 

virustotal-2

 

VirusTotal process.0x80ff88d8.0xb70000.dmp dosyasının enfekte olduğunu tespit etti. Diğer detaylar için bu bağlantıyı https://www.virustotal.com/en/file/8e3be5dc65aa35d68fd2aba1d3d9bf0f40d5118fe22eb2e6c97c8463bd1f1ba1/analysis/ kullanabilirsiniz.

Hazırlayan

Mustafa KISA <mustafa.kisa@boateknoloji.com>

Bağlantılar

[1] -- Volatility -- An Advanced Memory Forensics Framework: https://code.google.com/p/volatility

[2] -- MoonSols Windows Memory Toolkit: http://www.moonsols.com/windows-memory-toolkit

[3] -- fmem Tool: http://hysteria.sk/~niekt0/fmem

[3.1] -- Doc (6.2 fmem module): http://hysteria.sk/~niekt0/fmem/doc/foriana.pdf

[4] -- Volatility Recommented Packages: https://code.google.com/p/volatility/wiki/VolatilityInstallation#Recommended_packages

[5] -- Hooking: http://en.wikipedia.org/wiki/Hooking

 

 

We looked in to the HIKIT malware in our previous article. Mandiant stated that this malware stole data from the contractor companies that worked with the Department of Defense (DoD). The major evidence that led to this conclusion was that these contractor companies were among the clients of Mandiant and that they were infected and the data Mandiant obtained by examining these infections.

It is not possible to find a detailed explanation or analyse about HIKIT online. As we previously stated, despite the technical analysis, those behind this malware are still unknown. According to Mandiant, it is possible that an APT group of Chinese origin is behind it.

Our current study, in contrast to the previous, is less about the technical analysis and more about the investigation of the case. As previously stated, we have decided to dig deeper into the source of this malware.

The previous analysis did not cover a detailed explanation as to how this malware spreads. As a result of our studies, we have discovered that this malware exploited the Java Script codes run on “Microsoft Explorer” to infect systems.

 

Problem Product Producer
Exploit:HTML/IframeRef.Z Internet Explorer Microsoft

 

So, where did the infection come from? It was not possible for us to list all outcomes as carrying out separate investigations for each and every one of them would take a great deal of time. However, it will be possible to carry out these studies when a system is directly targeted. Our focus was the malware that we analysed as HIKIT is a malware with many variations.

As stated above, we started our study by identifying which websites hosted this “exploit” code. We obtained a list of sites that used the "exploit" code. These sites are as follows:

The Domain List

tkit.tk
tweak.tk
ahraz.tk
html-channel.com
freedomains4all.tk
html-site.nl
goodman-shirt.de
html-rulez.ru
html-studio.ru
tkmailias.tk
webnews.it

 

Many of our investigations on each domain did not result in solid evidence. The reason was that we were unable to find any registered domains. Only one of them had information on the domain name. We continued our researches on this domain name and the name it was registered to and identified the other domain addresses registered to the e-mail address we came across, nevertheless, it should be noted that these website might have been hacked to be used as a medium to spread various malwares.

Other Registired Domain Names

cristianos.ws
clfooter.ws
gaypornreviews.ws
duuf2gnia9bt18h7qy1tg621k.ws
888games.ws
fel0ny.ws
ukrainegirls.ws
spydirectory.ws
pandorabox.ws

We have found out that many of the site names above were registered to the e-mail address below. By looking into the site names and the domain WHOIS records of that date, it can be understood that these records were made on purpose.

3-1

 

At the beginning, we said that the dropped used to infect HIKIT was possible via the Java Script code that runs on MS Internet Explorer. Actually, our studies consisted of not only these but also other security weaknesses present in different applications. The Adobe Flash Player applications is just one of these.

So far, we had information on how HIKIT infected; however, there was not any information on the C&C servers. When we looked into the servers the above domains were connected to, the results were as follows;

IP Country
94.76.200.157 İngiltere
46.4.34.4 Almanya
87.106.29.14 Almanya
77.222.40.38 Rusya
208.82.114.84 Amerika
206.246.140.14 Amerika
24.223.234.70 Amerika
173.9.9.178 Amerika
91.199.120.6 İspanya
94.228.86.11 Slovakya
88.191.150.8 Fransa

 

The IP addresses that directly communicate with the above addresses, in other words, where initial attacks for HIKIT were carried out, communicate with the headquarters via many points. The major communications was via the server in Spain. The most transmittance of malware to this server is from China.

3-2

 

The IP address of the server overseeing the malware distribution in China points to the location below. When we made an enquiry on the same point for the resident instead of location, we came up with "People's Republic of China – Guiyang People’s Government.” This increased our suspicion that the distribution headquarters of this malware was a Chinese government facility. However, we are still uncertain as we do not have any solid evidence at hand.

3-3

 

With the below communications are still active, it can be said that this malware is about very different vectors. When we looked into the Exploit Kit software used, we mostly came across the software named “Blackhole Exploit Kit.”

3-4

“Maltego ile oluşturduğumuz organik graph”

 

It is still not possible to make certain statements about the source of HIKIT malware, it has a very fragmented structure and it is hard to present the obtained data with undeniable evidence. The graph structure above covers many vectors that have an organic connection with HIKIT. While many of the domain names are of German and Russian origin, servers that host the domains and that are the origin of spread are scattered among many facilities. While the major origin of spread is China, malwares are distributed from many different countries such Indonesia, Hungary, Romania and Korea.

As a result, while it is impossible to reach a final decision about the source, our research mostly circling around China, considering the current threats as well, gives a significant amount of ideas as to the source of the malware.

 

Trend Micro – Deep Discovery Inspector

We used the product Trend Micro – Deep Discovery Inspector in our research to finding the HIKIT malware over the web. Deep Discovery Inspector is capable of scanning malwares over the web and, with its “Virtual Analyzer” module, analysing them in detail.

3-5

 

Firstly, we positioned the Trend Micro Deep Discovery Inspector onto the work environment we created and relayed our web traffic to Deep Discovery Inspector over the spine switch. Having started to monitor our web traffic, Deep Discovery managed to catch the HIKIT malware we received as seen above.

The log included various data such as the source of the malware, the infected IP address and protocol information. If you like, you can get the results of the analyse carried out over the cloud by connecting to Trend Micro’s Threat Connect platform in order to better examine the malware.

 

3-6

 

We preferred to connect to the Threat Connect platform to see these details. To that end, it is sufficient to just open the details of the malwares caught by Deep Discovery and click on the name of the threat.

3-7

 

When you request detailed information about the threat, Deep Discovery will automatically direct you to the Threat Connect Platform. Then, it is possible to see the results of the analysis carried out by Trend Micro laboratories. The page covers the summary of the malware and a visualized organic connection graph.

3-8

 

It is possible to see the details by clicking on the graphs. Then, we can reach sample reports and obtain more detailed information about HIKIT. The map on the same screen shows which countries the malware named HIKIT is most active.

3-9

 

The sample report above shows the systems affected by, file format of and the processes created or affected by the malware. If that much detail about the malware is not enough, Trend Micro Threat Connect can dig even deeper and show the effects made in each stage of operation.

3-10

 

The “execution flow” tab on the same screen may show which resources the malware uses on the system and the modifications it makes by the second. The API used and the Mutex objects created by the malware in order not to infect an already-infected system are listed above.

It is possible to display details by clicking on the related objects and records, for instance, the figure below covers the Registry values created or modified via the system.

3-11

 

 

Trend Micro Deep Discovery and Threat Connect can present reports about the malwares it detects that are comprehensible to normal users. It also provides explanations as to how the malware can be deleted manually.

3-12

 

The above figure explains how to delete HIKIT malware step by step. Additionally, it provides various methods on how to perform that depending on the malware.

ATTACHMENTpdfThe HIKIT Rootkit Analysis (Part 2)

 image002

 

Yasin SÜRER
Threat Researcher
yasin.surer@boateknoloji.com

Introduction: The HIKIT Rookit Analysis 

Malwares (virus, worm, rootkit, etc.) are among the most important elements, included in complicated attacks. “Malwares" are among the most irrevocable tools, used by the attacker, during attacks, especially called APT (Advanced Persistent Threat), in which many different vectors are used.

Mostly, organized crime rings get the people, having advanced knowledge on this issue, write Malwares. Malwares, written as target-driven, must overcome several security mechanisms to reach a specific purpose.

This case means techniques and structures, used in Malwares, are complicated. Accordingly; malicious code analysis, besides being a difficult and onerous work, it requires advanced technical knowledge.

APT and Target

Discovered by Mandiant, HIKIT is a sort of Malware that enables seizing the control of remote system. HIKIT is an intelligence gathering purposed software, an advanced Malware, that carries out its functionality on kernel level completely.

The interesting point is that “intelligence” purpose of this Malware completely gathers data, belonging to the contracted / contractor companies of United States of America -- Department of Defense. It carries out activities aimed at gathering several data about organizations, in which some companies that are also available in SBIR/STTR list.

Technical Analysis

We only have an object named “oci.dll” to perform technical analysis on HIKIT. We confirmed that the file named “oci.dll” was not subjected to any compression process. We observe that there are files with different names in the current executable file when we proceed via this object. Initially; an interesting "string" data, available in the Malware, draws our attention.

h:\\JmVodServer\\hikit\\bin32\\RServer.pdb

The abovementioned data is the file that contains “debug” symbols, belonging to the Malware, that are available in the computer of the individual that developed the Malware. We can observe that name given to the Malware by the developer is “RServer” and its location in the developer’s computer. After getting this information, phases related with development process of the Malware are as follows:

  • As the first phase, the Malware installs the file named “oci.dll” via a “dropper”.
  • DLL installs the signed (driver) module into the system at kernel level.
  • The module, installed at kernel level, waits for a command from the attacker.

image003

How the aforementioned phases realized are displayed in the figure. The Malware, transmitted to users through various ways, waits for communicating with the attacker that connects behind "proxy".

After all these processes, we can start carrying out analysis process with the data we obtain. First of all; we need the most basic information on the executable file. We can start analyzing the Malware, beginning from the most basic steps, to carry out all these issues.

image004

As seen in the picture above, "oci.dll" file contains a file named "w2fw.sys". Thus; we can observe more clearly that the Malware contains a rootkit. Rootkit softwares operate at the kernel level and analysis process is harder when compared to the other (use-mode) Malwares.

image005

Code Signing Mechanism

Before mentioning about the following activities, the issue that must be known is code signing logic. Microsoft uses a technique called code signing to determine if modules to be executed at kernel level are safe. This means is to state that the module, installed in the kernel, is a safe module and it's approved.

image006

The interesting case that we encountered during analysis process is that *.inf extended files are signed due to GlobalSign certificates. GlobalSign became a current issue with a claim of "hacking" in 2011. It stopped its services for a while due to a doubt of certificates being stolen from its servers. The claims that suggested “GlobalSign was hacked” appeared in early September 2011 and when an analysis is carried out on "timestamp" information of the current file, October is pointed as the last date of edition.

image007 image008

We already stated that this Malware, analyzed in rootkit class, is executed in kernel level. As known, inf extended files contain the information on how to setup driver softwares. Now that we have the information that GlobalSign certificates are implemented on the malicious, we can observe that the Malware added itself to the system as signed to execute operations at kernel level.

image009

The Malware contains a function, as seen above, to perform various registrations and modifications in Register book. As soon as this function is completed, other routines that belong to the infection processes start to be operated.

image010

Malware & Attacker Communication

Other than this information, we obtain more interesting data when we open the malicious to analyze. For example; the Malware can make contact with the attacker for commands when the infection processes are completed.

image011

“Disassembly” output, that can be seen above, belongs to the routine that is operated for the attacker to connect to the target system. We can see that several processes are operated for connection to be completed If there is a key word within packets when the connection is established, connection process of the attacker is completed.

More technically, the Malware installs itself to NDIS-Level to monitor the incoming packets and adds to the system as "cyber network adaptor". Thus; by listening the packets, received by the whole network, it searches for a specific pattern between the among packets.

During this connection process, the attacker connects with the target via ports numbered 80 and 443. Within the rules of Firewall, 80 (HTTP) and 443 (HTTPS) ports are among the permitted ports. This case means that the malicious has an access to the target by means of by-passing firewall software or devices.

The interesting point in this phase is that the Malware does not contact with any (command and control) server or the attacker's computer. Instead, HIKIT contacts with the attacker by monitoring the whole net on the machine that it infected, in case of any incoming key word.

We can acquire a visual result on which values the aforementioned routines gain and where they go. It's clearly seen in the following figure that which function goes to what result. Accordingly; the information about which routines are effective in making contact is available in this diagram.

image012

The Malware permits several commands to be operated for remote access, when the contact is made. This definition is solely for the commands, operated by the malicious, and the commands to be operated by the attacker on the target are the commands that operating system defines. "Shell" command that we encountered among the commands to be operated after the contact is made, while proceeding within the machine code, enables creating a command line via remote machine.

image013

This means that all the commands, which can be operated by a common or authorized user on operating system, can give command to the backdoor, installed by the attacker to be operated. In short; it can operate a command for his purpose on the system by opening a "command prompt"  for the attacker.

image014

As soon as the “file” command, that can be seen below, is executed, it is in contact with the driver. Thus, the attacker can carry out the operations of file reading, changing file permissions, creating index and index listing. As a result; the attacker can succeed an access to system with full-authority, when the malicious completes infection processes.

The aforementioned “disassembly” is related with the implementation of the operations that were mentioned previously. Another feature of the malicious is the attacker’s ability of making contact via SOXKS5, a proxy.

image015

This feature, that attracted our attention while analyzing the malicious, is function which is embedded into the malicious by the attacker to make contact via proxy. As a result; it becomes harder to track the attacker as the contact is more uncertain.

"Strings” that belong to the below program are available. Some data, acquired in the beginning of the article, are available here. You can reach all "string" values, contained in the program, through analysis report.

Result

That this software, published and determined by Mandiant, is a part of APT attack is almost definite. It was stated that its aim was to gather intelligence and information about companies, contracted with U.S.A. Department of Defense. HIKIT was programmed to remain permanent in the system in which it is infected and turn systems into the attacker's slaves during this period. Similar examples of APT attacks are increasing today. As mentioned before, it is quite difficult to determine a malicious on NDIS Driver level and APT attack that it serves.

The aforementioned technique that enables the attacker to make contact with the system via a specific pattern is quite old and hard to determine. Determining this sort of an attack is only possible with "network traffic analysis” in some cases. As observed during the analysis; softwares and devices such as Firewall and Anti-virus are inefficient against these kinds of attacks.

The organizations that suffer from such attacks and companies that develop security products are completely aware of the situation. Besides classic security products such as; Firewall, anti-virus, the establishments must pay attention for different solutions to determine APT attacks.

1-1

1-2

1-3 1-4 1-5 1-6

Attachment :pdf The HIKIT Rootkit Analysis (Part1)

 image002

 

Yasin SÜRER
Threat Researcher
yasin.surer@boateknoloji.com