The background
This is a team work analysis, we have at least 5 (five) members involved with this investigation.The case that is about to be explained here is an APT case. Until now, we were (actually) avoiding APT cases for publicity in Malware Must Die! posts. But due to recent progress in "public privacy violation or power-abuse/bullying" malware cases, we improved our policy, so for several cases fit to "a certain condition", i.e. malware developed by "powerful actors with budget" aiming weak victims including the APT method, or, intimidation for public privacy cases using a crafted-malware, are going to be disclosed and reported here "ala MMD", along w/public criminal threat too. So don't use malware if you don't want to look BAD :-)
This case is NOT a new threat, for the background this threat was written in the Infosec Island blog, written by By Eva Galperin and Morgan Marquis-Boire in the good report of article: "Vietnamese Malware Gets Very Personal" which is posted several months ago, access is in here-->[
You can consider this post is made as additional for the previous writings, to disclose deeper of what public and the victims actually SHOULD know in-depth about the malicious activity detail, that is performed by this malware. To be more preventive in the future for the similar attack that is possibly occurred.
We suspect a group with good budget is in behind of this malware, aiming and bullying privacy of specific individuals who against one country's political method. In a glimpse, the malware, which is trying hard to look like a common-threat, looks like a simple backdoor & connecting/sending some stuffs to CNC. But if you see it closely to the way it works, you will be amazed of the technique used to fulfill its purpose, and SPYING is the right word for that purpose.
The sample we analyzed in this post was received from the victims side, we picked the one file called "Thu moi.7z" which contains the "Thu moi.hta" snipped below:
At the starting part of this script. you can see three points was used to camouflage, which are : (1) The usage of the long white space to cover the evil script start tag from the eye-sight, (2) the effort to minimize the "window" for the shell used to run this evil VB Script, and (3) the effort to NOT showing the window taskbar during the script running.
I will try to peel the evil script used, with the explanation I commented within the lines, as per below:
The line 48 & 49 of the script is to declare the file object & shell mentioned above in the variable "os" and "ws". And following by defining the windows temporary folder as file's path added by the function's generated randomized name as filename+extension. To make sure of what these variables generated values, I am using break points formed by Wscript.Echo trick to burp its value in a pop-up.
The VB Script is creating the EXE file as per previously described above, declared it as an object "p1". Then you can see blob of binary codes to be written as HEX to form a file, by using the combination of commands in VB script. This method is commonly used as technique to write a malware binary in VB Script. But this one is a well-thought one.
And it creates those two files (before execution). I run it many times for fun..NO!" ..for "analysis" (Uhm!), so I can extract randomized injected files to check is it polymorphic or not (and..of course..it is not, NOT with this plain Hex writing crap).
We also check bit-by-bit to make sure which samples belong to which installers, since this malware looks hit some victims / more than one time.
So what does this ".exe" malware do?
Polymorphic self-copy & new process spawner
I picked the .exe file dropped by this .hta installer with the MD5 hash f38d0fb4f1ac3571f07006fb85130a0d, this malware was uploaded to VT about 7 months ago.
The malware is the one was dropped by the installer, you can see the same last bits before blobs of "00" hex were written in the malware binary as per snipped and red-marked color in the VB script mentioned in the previous section:
The self-copied files are polymorphic, below some PoC, one AV evasion detection designed:
Size Exec Date Filename MD5It'll then create the process (with the command line API), which will be executed at the function reversed below, I put default IDA commented information since it is important for all of us (not only reverser) to understand flow used below, pls bear the length, just please scroll down to skip these assembly explanation (unless you interest to know how it works):
-------------------------------------------------------------
438272 Aug 23 01:28 10.tmp* 577237bfd9c40e7419d27b7b884f95d3
438272 Aug 23 07:22 17.tmp* 9451a18db0c70960ace7d714ac0bc2d2
438272 Aug 23 07:36 18.tmp* 53d57a45d1b05dce56dd139fc985c55e
438272 Aug 23 07:39 19.tmp* 387321416ed21f31ab497a774663b400
438272 Aug 23 07:43 1A.tmp* 0a65ecc21f16797594c53b1423749909
438272 Aug 23 07:44 1B.tmp* 91a49ed76f52d5b6921f783748edab01
438272 Aug 23 07:44 1C.tmp* f89571efe231f9a05f9288db84dcb006
438272 Aug 23 07:45 1D.tmp* 7ca95b52ed43d71e2d6a3bc2543b4ee1
438272 Aug 23 07:46 1E.tmp* faec9c62f091dc2163a38867c28c224d
438272 Aug 23 07:47 1F.tmp* 4b02063c848181e3e846b59cbb6b3a46
438272 Aug 23 08:14 20.tmp* 5c8f2f581f75beff1316eee0b5eb5f6d
438272 Aug 23 01:19 F.tmp* b466cb01558101d934673f56067f63aa
: :
0x40BF20 sub_40BF20 proc nearif the .hta dropped malware named "sample.exe", new process will be started by launching command line contains parameters described below:
0x40BF20
0x40BF20 StartupInfo= _STARTUPINFOW ptr -8508h
0x40BF20 ProcessInformation= _PROCESS_INFORMATION ptr -84C4h
0x40BF20 var_84B4= dword ptr -84B4h
0x40BF20 CommandLine= word ptr -84B0h
0x40BF20 FileName= word ptr -4B0h
0x40BF20 ApplicationName= dword ptr -2A8h
0x40BF20 var_A0= dword ptr -0A0h
0x40BF20 var_1C= dword ptr -1Ch
0x40BF20 var_18= dword ptr -18h
0x40BF20 var_10= dword ptr -10h
0x40BF20 var_8= dword ptr -8
0x40BF20 var_4= dword ptr -4
0x40BF20 arg_8= dword ptr 10h
0x40BF20
0x40BF20 push ebp
0x40BF21 mov ebp, esp
0x40BF23 push 0FFFFFFFEh
0x40BF25 push offset unk_4284D0
0x40BF2A push offset sub_416480
0x40BF2F mov eax, large fs:0
0x40BF35 push eax
0x40BF36 sub esp, 8 ; Integer Subtraction
0x40BF39 mov eax, 84F0h
0x40BF3E call sub_4207F0 ; Call Procedure
0x40BF43 mov eax, dword_42A520
0x40BF48 xor [ebp+var_8], eax ; Logical Exclusive OR
0x40BF4B xor eax, ebp ; Logical Exclusive OR
0x40BF4D mov [ebp+var_1C], eax
0x40BF50 push ebx
0x40BF51 push esi
0x40BF52 push edi
0x40BF53 push eax
0x40BF54 lea eax, [ebp+var_10] ; Load Effective Address
0x40BF57 mov large fs:0, eax
0x40BF5D mov [ebp+var_18], esp
0x40BF60 mov esi, [ebp+arg_8]
0x40BF63 xor ebx, ebx ; Logical Exclusive OR
0x40BF65 push ebx ; reserved register (pvReserved) PS: MUST BE NULL!
0x40BF66 call ds:CoInitialize ; [email protected] (Import, LPVOID, pvReserved)
0x40BF6C mov [ebp+var_4], ebx ; Initializes the COM lib is executed here
0x40BF6F push 6 ; push 0x06h
0x40BF71 push offset aHelp ; is a UTF-16 "--help" for params
0x40BF76 push esi
0x40BF77 call sub_41196F ; bottom line: function in sub_41A360, comp & add chars
0x40BF7C add esp, 0Ch ; Add
0x40BF7F test eax, eax ; Logical Compare
0x40BF81 jz loc_40C13E ; Jump if Zero (ZF=1) TO Sleep & Exit
:
0x40BF87 call sub_409740 ; point is control svc manager, grab db (info)
0x40BF8C xor eax, eax ; Logical Exclusive OR
0x40BF8E mov [ebp+FileName], ax
0x40BF95 push 206h
0x40BF9A push ebx
0x40BF9B lea ecx, [ebp-4AEh] ; Load Effective Address ECX w/Filename
0x40BFA1 push ecx
0x40BFA2 call sub_412510 ; check+strings operation (XOR, shift right)
0x40BFA7 add esp, 0Ch ; 12 (0x0c) has to be added to the stack
0x40BFAA push 104h ; nSize
0x40BFAF lea edx, [ebp+FileName] ; Load Effective Address
0x40BFB5 push edx ; lpFilename
0x40BFB6 push ebx ; hModule
0x40BFB7 call ds:GetModuleFileNameW ; grab this process filename
0x40BFBD test eax, eax ; cleanup EAX for jmp
0x40BFBF jz loc_40C15D ; Jump if Zero (ZF=1)
:
0x40BFC5 xor eax, eax ; Logical Exclusive OR
0x40BFC7 mov word ptr [ebp+ApplicationName], ax
0x40BFCE push 206h
0x40BFD3 push ebx
0x40BFD4 lea ecx, [ebp+ApplicationName+2] ; Load Effective Address, this appname
0x40BFDA push ecx ; pushing appname to the stack
0x40BFDB call sub_412510 ; check+strings operation (XOR, shift right)
0x40BFE0 add esp, 0Ch ; 12 (0x0c) has to be added to the stack
0x40BFE3 lea edx, [ebp+ApplicationName] ; Load Effective Address
0x40BFE9 push edx ; push lpBuffer
0x40BFEA push 104h ; and its length (nBufferLength)
0x40BFEF call ds:GetTempPathW ; grab %Temp%
0x40BFF5 test eax, eax ; cleanup EAX for jmp
0x40BFF7 jz loc_40C15D ; Jump if Zero (ZF=1)
:
0x40BFFD lea eax, [ebp+ApplicationName] ; Load Effective Address
0x40C003 push eax ; lpTempFileName
0x40C004 push ebx ; uUnique
0x40C005 push ebx ; lpPrefixString
0x40C006 mov ecx, eax
0x40C008 push ecx ; lpPathName / push Path..
0x40C009 call ds:GetTempFileNameW ; grab %Temp%+%Filename%
0x40C00F test eax, eax ; cleanup EAX for jmp
0x40C011 jz loc_40C15D ; Jump if Zero (ZF=1)
:
0x40C017 call sub_4079C0 ; To CryptAcquireContextW..CryptRelease OP.
0x40C01C test eax, eax ; cleanup EAX for jmp
0x40C01E jz loc_40C15D ; Jump if Zero (ZF=1)
:
0x40C024 mov byte ptr [ebp+var_A0], bl ; reserved pointer
0x40C02A push 80h ; push WritePrivateProfileString to stack
0x40C02F push ebx ; push lpPrefixString to stack
0x40C030 lea edx, [ebp+var_A0+1] ; load rsv pointer address
0x40C036 push edx ; push rsv pointer to stack
0x40C037 call sub_412510 ; check+strings operation (XOR, shift right)
0x40C03C add esp, 0Ch ; 12 (0x0c) has to be added to the stack
0x40C03F mov [ebp+var_84B4], 81h ; EBP to WritePrivateProfileString
0x40C049 lea edx, [ebp+var_84B4] ; load EBP
0x40C04F lea eax, [ebp+var_A0] ; load EAX
0x40C055 call sub_40A300 ; to fnc OP Shift right+4 etc..
0x40C05A test eax, eax ; cleanup EAX for jmp
0x40C05C jz loc_40C15D ; Jump if Zero (ZF=1)
:
0x40C07B xor eax, eax ; cleanup EAX
0x40C07D mov [ebp+CommandLine], ax ; prep exec/command line
0x40C084 push 7FFEh
0x40C089 push ebx ; push lpPrefixString
0x40C08A lea ecx, [ebp-84AEh] ; Load eff addr of ECX
0x40C090 push ecx ; push into stack
0x40C091 call sub_412510 ; check+strings operation (XOR, shift right)
0x40C096 lea edx, [ebp+var_A0] ; load eff addr lpFileName
0x40C09C push edx ; psh lpFileName to stack
0x40C09D lea eax, [ebp+FileName] ; load eff addr fur filename
0x40C0A3 push eax ; push into stack
0x40C0A4 lea ecx, [ebp+ApplicationName] ; load eff addr appname
0x40C0AA push ecx ; push appname to stack
0x40C0AB push offset aSHelpSS ; get "\"%s\" --help%s\t%S" command executed template into stack
; sttarted from the above written path/filename, this file's path+name
; and %S strings from encryption result
0x40C0B0 push 4000h
0x40C0B5 lea edx, [ebp+CommandLine] ; load eff addr exec/cmd line
0x40C0BB push edx ; push cmd/exec to stack
0x40C0BC call sub_411448 ; goto 0x0410A42, obfuscation
0x40C0C1 mov [ebp+StartupInfo.cb], ebx ; transfer the startup info
0x40C0C7 push 40h ; AccessResource
0x40C0C9 push ebx ; push to stack
0x40C0CA lea eax, [ebp+StartupInfo.lpReserved] ; load eff addr for StartupInfo+IpReserved
0x40C0D0 push eax ; push that into stack
0x40C0D1 call sub_412510 ; deobfuscation shif -1 is here
0x40C0D6 add esp, 30h ; Add ESP w/30h
0x40C0D9 mov [ebp+StartupInfo.cb], 44h ; transfer startups to EBP
0x40C0E3 xor ecx, ecx ; cleanup ECX
0x40C0E5 mov [ebp+StartupInfo.wShowWindow], cx ; forming startups info here..
0x40C0EC mov [ebp+StartupInfo.dwFlags], 1
0x40C0F6 mov [ebp+ProcessInformation.hProcess], ebx
0x40C0FC xor eax, eax ; cleanup prep EAX
0x40C0FE mov [ebp+ProcessInformation.hThread], eax ; forming process-info here..
0x40C104 mov [ebp+ProcessInformation.dwProcessId], eax
0x40C10A mov [ebp+ProcessInformation.dwThreadId], eax
0x40C110 lea edx, [ebp+ProcessInformation] ; Load Effective Address
0x40C116 push edx ; Push all info to stack as lpProcessInformation
0x40C117 lea eax, [ebp+StartupInfo] ; assemble startinfo into EAX
0x40C11D push eax ; lpStartupInfo
0x40C11E push ebx ; lpCurrentDirectory
0x40C11F push ebx ; lpEnvironment
0x40C120 push 8000000h ; dwCreationFlags
0x40C125 push ebx ; bInheritHandles
0x40C126 push ebx ; lpThreadAttributes
0x40C127 push ebx ; lpProcessAttributes
0x40C128 lea ecx, [ebp+CommandLine] ; startupinfo+cmd
0x40C12E push ecx ; lpCommandLine
0x40C12F lea edx, [ebp+ApplicationName] ; process info loaded
0x40C135 push edx ; lpApplicationName pushed to stack
0x40C136 call ds:CreateProcessW ; stdcall to start process w/flags
0x40C13C jmp short loc_40C15D
"CreateProcessW","C:\DOCUME~1\...\LOCALS~1\Temp\RANDOM[0-9A-F]{1,2}.tmp","SUCCESS|FAIL","PID: xxx,
Command line: ""C:\DOCUME~1\...\LOCALS~1\Temp\RANDOM[0-9A-F]{1,2}.tmp"" \n
--helpC:\DOCUME~1\...\LOCALS~1\Temp\sample.exe \n
BCE6D32D8CD4F1E6A1064F66D561FDA47E0CD5F8F330C4856A250BB104BC18320FF75E6E56A1741C6770AD238DCFD23DD8A82DDF332FDC8110972549B4FE6D37"The decryption function used is as per below:As you can see the wiring method is in redundancy per 4096 bytes.
This first drop called defrag.exe looks pretty much like Windows harddisk defragmentation tool, down to its property, a perfectly crafted evil file:
: Marc Oschenmeier), we can spot and focus investigation to the badness indicators right away:
Thx for using PEStudio for your investigation. In that case, PEStudio indicating that the image is a fake Microsoft EXE! :-)
This file is actually a DLL file, here's some peframe:
File Name: disk1.imgAnd Virus Total showing the good infection info:
PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
File Size: 249344 byte
Compile Time: 2010-08-14 17:16:08
"DLL: True"
Entry Point: 0x0001BBD1
Sections: 4
MD5 hash: 62646ea0a4ce1e6d955cbaef8c4a510d
SHA-1 hash: 10116a65e19a7ebc6702250cc1caabf755ce8e7f
Anti Debug: Yes
Anti VM: None
First submission 2013-03-11 10:38:19 UTC ( 1 year, 5 months ago )
Last submission 2014-01-21 12:49:00 UTC ( 7 months ago )
File names disk1.dl, disk1.img
This file is then performing registry query and writing operations, I will skip some assembly for this, so shortly, these are the 8 keys added, below data I snip from forensics result:
What this payload does
First thing that caught interest and attention is these obfuscation constant variables saved in .rdata section:
0x40F3AC ; const WCHAR aTztxpx75XtdsjqWe have good decoder team in MMD. Soon these data were translated as per below:
0x40F3AC aTztxpx75Xtdsjq:
0x40F3AC unicode 0, ,0
0x40F3D6 align 4
0x40F3D8 ; const WCHAR aTztufn43Xtdsjq
0x40F3D8 aTztufn43Xtdsjq:
0x40F3D8 unicode 0, ,0
0x40F402 align 4
0x40F404 ; const WCHAR a2e6g3ddEmm
0x40F404 a2e6g3ddEmm:
0x40F404 unicode 0, ,0
0x40F430 ; const WCHAR aQsphsbnGjmftY9
0x40F430 aQsphsbnGjmftY9:
0x40F430 unicode 0, ,0
0x40F498 ; const WCHAR aQsphsbnGjmftNf
0x40F498 aQsphsbnGjmftNf:
0x40F498 unicode 0, ,0
0x40F4DE align 10h
0x40F4E0 ; const WCHAR aQsphsbnGjmft_0
0x40F4E0 aQsphsbnGjmft_0:
0x40F4E0 unicode 0, ,0
0x40F546 align 4
0x40F548 ; const WCHAR aQsphsbnGjmftJo
0x40F548 aQsphsbnGjmftJo:
0x40F548 unicode 0, ,0
0x40F5A2 align 4
And (2) the conclusion of what "defrag.exe" is actually doing, is a loader which patches the executed wsscript.exe's ExitProcess to load the DLL "disk1.img"....Well, it's all starts to make more sense now.
Checking the reported data. I confirmed to find the "process was read" from here:
;; begins parameter to read process in memory here..As for the "Exit Process patching" itself, it is a quite sophisticate technique was used. It used a tiny shellcode that was observed within Mem Loc 1 : 009C0000 to 009D0000 (by Raashid). The shellcode then was saved in binary which I received and take a look deeper to confirm it as per following snips:
0x4014BB mov edx, [ebp+nSize]
0x4014C1 lea ecx, [ebp+NumberOfBytesRead]
0x4014C7 push ecx ; lpNumberOfBytesRead
0x4014C8 mov ecx, [ebp+lpAddress]
0x4014CE push edx ; nSize
0x4014CF lea eax, [ebp+Buffer] ;
0x4014D2 push eax ; lpBuffer
0x4014D3 push ecx ; lpBaseAddress
0x4014D4 push esi ; hProcess
0x4014D5 mov [ebp+NumberOfBytesRead], ebx
0x4014DB call ds:ReadProcessMemory ; ;↑Reads data from an area of memory in a specified process.
0x4014E1 test eax, eax ; execute
So now we know that defrag.exe is actually hacked wscript.exe, hooks ExitProcess Function of kernel32.dll and patches it with a [email protected] and loads a DLL string in local (for further execution), does some error-trapping and gives time for the DLL to be processed (loaded and executed).
OK. So now we have the idea on how this binary sniffs for account, checks for processes and load and use the DLL (disk1.img). There are many more details for more operation in defrag.exe, like searching the process of Auslogic and that skype/messenger buff (also many registry values sniffed too) , but those will be added later after this main course..
The DLL Payload
This DLL is the goal of this infection. It has operations for networking functionalitiy, contains the CNC information and the data to be sent to the CNC. If you do forensics, you may never see disk1.img or the deobfuscated DLL filename in the process, but you will see its operation by the patched wscript.exe (for it was hacked to load this DLL, the wscript.exe process should appear).
Below is the DLL part that in charge for the socket connections...
;; In function 10010544..this will be resulted in some internal socket binding operation we spotted in the debug mode as:
10010593 lea edx, [ebp+var_8]
10010596 push edx
10010597 lea edx, [ebp+var_2C]
1001059A push edx
1001059B push ecx
1001059C push eax
1001059D call ds:getaddrinfo ; networking info
:
100105C7 push dword ptr [esi+0Ch] ; protocol
100105CA push dword ptr [esi+8] ; type
100105CD push dword ptr [esi+4] ; af
100105D0 call ds:socket ; open the socket
100105D6 mov edi, eax
:
100105DD push dword ptr [esi+10h] ; namelen
100105E0 push dword ptr [esi+18h] ; name
100105E3 push edi ; s
100105E4 call ds:connect ; connected to socket
:
10010600 push [ebp+var_8]
10010603 call ds:freeaddrinfo
10010609 mov esi, ds:setsockopt
1001060F push ebx ; optlen (length)
10010610 lea eax, [ebp-1]
10010613 push eax ; optval (value)
10010614 push ebx ; optname
10010615 push 6 ; level
10010617 push edi ; s
10010618 mov [ebp+var_1], bl
1001061B call esi ; setsockopt ; pass socket connection parameters
1001061D push 4 ; optlen
1001061F lea eax, [ebp+optval]
10010622 push eax ; optval
10010623 push 1006h ; optname
10010628 push 0FFFFh ; level
1001062D push edi ; s
1001062E call esi ; setsoc
Bind IP Port Status (n) HookAddr API CallsWhich one of them is successfully established connection to CNC:
--------------------------------------------------------
0.0.0.0 51902 success 1 100105A3 getaddrinfo
0.0.0.0 52652 success 1 100105A3 getaddrinfo
0.0.0.0 57334 success 1 100105A3 getaddrinfo
0.0.0.0 1209 success 1 100105EA connect
0.0.0.0 54643 success 1 100105A3 getaddrinfo
0.0.0.0 53539 success 1 100105A3 getaddrinfo
0.0.0.0 54536 success 1 100105A3 getaddrinfo
0.0.0.0 1210 success 1 100105EA connect
0.0.0.0 51696 success 1 100105A3 getaddrinfo
Bind IP Port Status (n) HookAddr API Calls
--------------------------------------------------------
"91.229.77.179 8008 success" or wait 2 100105EA connect
From the reversing section for this DLL (by Raashid), the domains are encoded using single byte move. and can be seen in the below IDA snapshot:
When I received the result, since I had the report that the CNC was down at the time reversed, I used the local dummy DNS to seek whether the requests was made to those CNC hosts, and is proven:
Does it means the CNC still alive?
I am not so sure. It was connected. The CNC "allowed" the bot to send the data to them, yet it was not responding back afterward and let the communication becoming in "pending" stage. So, there is many possibility can be happened, like: CNC is gone, or CNC specs has changed, etc. After all this APT sample is about 6-7months old.
So please allow me to take a rain check for analysis the blob binary used (still on it..among tons of tasks..). Let's investigate this CNC related network.
The CNC investigation
Based on the reverse engineering, forensics & behavior analysis we did, we found the CNC is actually 3 (three) hostnames matched to the 6 (six) IP addresses as per listed below:
static.jg7.orgWhich historically are using the below IP addresses:
imaps.qki6.com
menmin.strezf.com
8.5.1.38The first three domains is having a very bad reputation in phishing & malware infection globally. PoC-->[
64.74.223.38
208.73.211.66
91.229.77.179
124.217.252.186
212.7.198.211
And the period time for each CNC's used subdomains VS IP addresses above can be viewed clearly below:
first seen 2013-11-01 21:17:45 -0000And below is the DNS queries for these hostname (not IP) recorded in the recent terms, thank's to OpenDNS:
last seen 2013-11-04 05:22:20 -0000
static.jg7.org. A 8.5.1.41
first seen 2013-10-07 13:10:00 -0000
last seen 2013-11-18 14:38:32 -0000
static.jg7.org. A 64.74.223.41
first seen 2013-08-26 10:01:39 -0000
last seen 2013-10-07 12:34:21 -0000
static.jg7.org. A 91.229.77.179
first seen 2012-12-17 04:20:19 -0000
last seen 2013-06-20 05:53:03 -0000
static.jg7.org. A 124.217.252.186
first seen 2013-06-20 08:00:28 -0000
last seen 2013-08-26 09:00:42 -0000
static.jg7.org. A 212.7.198.211
first seen 2013-11-01 21:22:55 -0000
last seen 2013-11-04 05:24:20 -0000
imaps.qki6.com. A 8.5.1.38
first seen 2013-10-07 13:10:18 -0000
last seen 2013-11-18 14:38:38 -0000
imaps.qki6.com. A 64.74.223.38
first seen 2013-08-26 10:02:05 -0000
last seen 2013-10-07 12:33:13 -0000
imaps.qki6.com. A 91.229.77.179
first seen 2012-12-17 04:19:46 -0000
last seen 2013-06-20 05:52:30 -0000
imaps.qki6.com. A 124.217.252.186
first seen 2014-01-06 01:21:07 -0000
last seen 2014-01-11 14:30:44 -0000
imaps.qki6.com. A 208.73.211.66
first seen 2013-06-20 07:07:43 -0000
last seen 2013-08-26 09:01:08 -0000
imaps.qki6.com. A 212.7.198.211
first seen 2013-08-26 10:02:31 -0000
last seen 2014-08-22 04:06:36 -0000
menmin.strezf.com. A 91.229.77.179
first seen 2013-10-05 11:54:26 -0000
last seen 2013-10-07 13:45:55 -0000
menmin.strezf.com. A 208.91.197.101
first seen 2013-06-20 06:26:33 -0000
last seen 2013-08-26 09:01:34 -0000
menmin.strezf.com. A 212.7.198.211
]
With thankfully to KM team (rocks!) I am reserving a topic there for the continuation disclosure for same nature of sample and threat.
The epilogue
This series of APT attack looks come and go, it was reported back then from 2009. This one campaign looks over, but for some reason that we snipped in above writing, there is no way one can be sure whether these networks used are dead. The threat is worth to investigate and monitor deeper. Some posts are suspecting political background supporting a government mission of a certain group is behind this activities, by surveillance to the targeting victims. Avoiding speculation, what we saw is a spyware effort, with a good quality...a hand-made level, suggesting a custom made malware, and I bet is not a cheap work too. We talked and compare results within involved members and having same thought about this.
If you received the sample, or, maybe got infected by these series, I suggest to please take a look at the way it was spread, dropped techniques used binaries, and the many camouflage tricks used. Further, for the researchers involved, we should add that the way to hide the CNC within crook's network is the PoC for a very well-thought & clever tricks. We have enough idea for whom is capable to do this, and now is under investigation.
We are informing to all MMD friends, this investigation is OPEN, please help in gathering information that is related to this threat for the future time frame too, as much as possible. We are opposing whoever group that is backing up this evil operation, and believe me, the dots are started to connect each other..
We are going to handle the similar threat from now on, so IF you have the abuse case by malware and need the deep investigation of what that malware does, do not hesitate to send us sample, archive the samples and text contains the explanations of how you got the sample and how can we contact you, with the password "infected", and please upload it in this link-->[DropBin].
Don't use malware, we never believe that any usage of malware can achieve any goodness. We will battle the malware initiators and its coders for the sake to support a better humanity and better internet usage.
SOCIAL SHARE CARD GENERATOR