Saturday, August 23, 2014

Another country-sponsored #malware: Vietnam APT Campaign

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-->[LINK], the post was very well written as heads up for this threat. Also, there are similar article supported to this threat and worth reading beforehand like:


    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:

    ..which was reported as the latest of this series.

    From the surface, if "Thu moi.hta" file is being executed (double clicked), it will extract (drop) and opening a Microsoft Word DOC file, to camouflage the victim to make them believe that they are opening an archived document file, while what had actually happened is, in the background a series of infection activities happened in the victim's PC.

    Malware installer scheme

    How the file was extracted from "Thu moi.hta" is by utilizing a simple embedded VB Script, you can see it started in the line 307 (of that .hta sample file) as per shown below in any text editor you pick:

    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:

    So, the script was design to keep on running in any run time error. You will meet the function forming the randomized strings for an "exe" filename. You can see how this script generate the "random seed" to be used for randomizing the strings used for filename, and how it merged filename with the ".exe" extension afterwards. Then the script is obfuscating the WScript's (the Windows OS interpreter engine for running a VB Script) commands to form an object of file system, and the shell for execution a windows command/executable file(s).

    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.

    The next lines is explaining the same method used for HEX file-writing. Yes, it wrote another file, and declaring it as object "p", but this one is using the static variable name "Doc Loi.doc" which is using the %Temp% path too (noted: GetSpecialFolder(x) where x=2 means %Temp%).

    Here's the punchline, the last part of codes (lines 116 and 117) you will see the script is performing execution of object "p" (the .doc file) and without waiting it just run the "p1" (the .exe malware).

    We recheck the run result of any decoding method we did. In this case I just commented the line 116 and 117 per expected, this script runs and minimizing the window w/o taskbar title:

    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 is not, NOT with this plain Hex writing crap).

    Further, we also formed the binary file-injecting itself from hex-strings directly from the script as per snipped below, to study the possibility of a miss-writing that can happened during forming the PE extraction, the test was done with the same result. A snip of scratch used (thanks to MMD DE team):

    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:

    This binary is having an interesting functionality. There's so much to write from it..but I will go to important highlights, or this post is going to be a book. Among all usual malicious tricks for evasion & "reverse/debug checking" tricks used, it was designed to detect the way it was called. When it was initially executed as the form of the dropped .exe from the .hta installer it will delete the original file and rewrite itself to the %Temp% folder using the random Hex-filename with ".tmp" extension, below is the partial writing codes snipped for it:

    The self-copied files are polymorphic, below some PoC, one AV evasion detection designed:

    Size   Exec Date    Filename MD5
    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 
          :              :
    It'll then create the process (with the command line API), which will be executed at the function reversed below, I commented important flow used below, pls bear the length, just please scroll down to skip these assembly explanation (unless you interest to know how it works):
    0x40BF20 sub_40BF20 proc near
    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 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 ; CoInitialize@OLE32.DLL (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 
    if the .hta dropped malware named "sample.exe", new process will be started by launching command line contains parameters described below:
    "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
    The decryption function used is as per below:
    And this malware will end its process here, raising new process that has just been executed..

    More drops & payload installation

    The process RANDOM[0-9A-F]{1,2}.tmp started by allocated memory, loading rpcss.dll, uxtheme.dll, MSCTF.dll before it self deleting the dropper .exe. The snip code for the deletion is as per below, this isn't also an easy operation, it checks whether the file is really there, if not it makes sure it is there..

    0x40A648 push    edi             ; push pszPath into stack
    0x40A649 call    ds:PathFileExistsW ; get the path
    0x40A657 push    0Ah             ; lpType
    0x40A659 push    65h             ; lpName
    0x40A65B push    ebx             ; hModule (for the FindResourceW)
    0x40A65C call    ds:FindResourceW ; Indirect Call to get resouce
    0x40A662 mov     esi, eax        ; feed esi w/eax
    0x40A664 cmp     esi, ebx        ; condition to check if ESI contains file data
    0x40A666 jz      loc_0x40A7CB      ; then goto file deletion below:
    0x40A7CB loc_0x40A7CB:             ; lpFileName
    0x40A7CB push    edi             ; push path+filename to stack
    0x40A7CC call    ds:DeleteFileW  ; call API DeleteFileW@KERNEL32.DLL (Import, 1 Params)
    0x40A7D2 mov     [ebp+var_18], 1 ; Execution, note: mov dword ptr [ebp-18h], 0x01h
    ;; ..OR fill the ESI and make sure it was executed..
    0x40A779 mov     ecx, [ebp+lpFile]
    0x40A77C mov     edx, [ebp+lpExistingFileName]
    0x40A77F push    ecx             ; lpNewFileName
    0x40A780 push    edx             ; lpExistingFileName
    0x40A78B mov     eax, [ebp+lpFile] ; eax < file opeation info
    0x40A78E push    1               ; nShowCmd
    0x40A790 push    ebx             ; lpDirectory
    0x40A791 push    ebx             ; lpParameters
    0x40A792 push    eax             ; lpFile
    0x40A793 push    ebx             ; lpOperation
    0x40A794 push    ebx             ; hwnd
    0x40A795 call    ds:ShellExecuteW ; prep shell to exec/open file
    0x40A79B mov     [ebp+var_18], 1
    ..up to this point I know that we're dealing with a tailored-made malware.

    Back to the highlights, RANDOM[0-9A-F]{1,2}.tmp executed with the right condition will drop payloads of this threat, the first drop is the real deal payload, following by the second drop as the its driver. The file creation of first payload is handled in function 0x41FC90, with the related snip below:

    0x41FEAF mov     eax, [ebp+arg_0]
    0x41FEB2 mov     edi, ds:CreateFileW ; prep API CreateFileW@KERNEL32.DLL (import, 7 attribs at 0x41FED0)
    0x41FEB8 push    0               ; prepare hTemplateFile to stack
    0x41FEBA push    [ebp+dwFlagsAndAttributes] ; to stack: dwFlagsAndAttributes
    0x41FEBD mov     dword ptr [eax], 1
    0x41FEC3 push    [ebp+dwCreationDisposition] ; dwCreationDisposition
    0x41FEC6 lea     eax, [ebp+SecurityAttributes] ; load w/add sec-attrib
    0x41FEC9 push    eax             ; lpSecurityAttributes to stack
    0x41FECA push    [ebp+dwShareMode] ; dwShareMode
    0x41FECD push    [ebp+dwDesiredAccess] ; dwDesiredAccess
    0x41FED0 push    [ebp+lpFileName] ; push EBP with lpFileName & its data assembled:
    0x41FED0                         ; C:\Documents and Settings\...\Application Data\Common Files\defrag.exe
    0x41FED0                         ; "SUCCESS|FAIL",
    0x41FED0                         ; "Desired Access: Read Attributes,
    0x41FED0                         ; Disposition: Open,
    0x41FED0                         ; Options: Open Reparse Point,
    0x41FED0                         ; Attributes: n/a,
    0x41FED0                         ; ShareMode: Read, Write, Delete,
    0x41FED0                         ; AllocationSize: n/a,
    0x41FED0                         ; OpenResult: Open|Fail"
    0x41FED3 call    edi ; CreateFileW ; Call API 
    0x41FED5 mov     [ebp+hHandle], eax ; Boom! File create execution..
    And the writing this file is written in function 0x418EC2 after deobfuscating data part, as per snipped here:
    0x418FB9 mov     eax, [eax+6Ch]
    0x418FBC xor     ecx, ecx        ; cleanup ECX
    0x418FBE cmp     [eax+14h], ecx  ; Compare Two Operands
    0x418FC1 lea     eax, [ebp+CodePage] ; Load Effective Address
    0x418FC7 setz    cl              ; Set Byte if Zero (ZF=1)
    0x418FCA push    eax             ; lpMode
    0x418FCB mov     eax, [ebx]
    0x418FCD push    dword ptr [edi+eax] ; hConsoleHandle, val=0x01(write)
    0x418FD0 mov     esi, ecx
    0x418FD2 call    ds:GetConsoleMode ; in this case is output mode console screen buffer.
      : (etc etc)
    0x4194F0 push    ecx             ; lpOverlapped
    0x4194F1 lea     ecx, [ebp+var_1AD8] ; load eff addr lpNumberOfBytesWritten
    0x4194F7 push    ecx             ; push lpNumberOfBytesWritten to stack
    0x4194F8 push    [ebp+nNumberOfBytesToWrite] ; length, value (dec) 4,096 why??
    0x4194FB push    [ebp+lpBuffer]  ; lpBuffer
    0x419501 push    dword ptr [eax+edi] ; hFile (the defrag.exe)
    0x419504 call    ds:WriteFile    ; Indirect Call Near Procedure
    0x41950A test    eax, eax        ; Execution to write...
    0x41950C jz      short loc_0x419523 ; Jump if Zero (ZF=1)
    0x419523 call    ds:GetLastError
    0x419529 mov     dword ptr [ebp+WideCharStr], 
    we recorded this drop operation in the forensics way too, as per below as evidence:

    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:

    Only by using good analysis binary static analysis tool like PEStudio (maker: Marc Oschenmeier), we can spot and focus investigation to the badness indicators right away:

    The next drop is the next task of this binary, noted that none of these drops were fetched from internet instead the data is already included in .hta or .[random].exe or [random.tmp].
    Using the exactly the same functions described above, 0x41FC90 for creation and 0x418EC2 for writing, the second drop operation were also performed. The file name is formed as per below strings:

    "C:\Documents and Settings\MMD\Application Data\Identities\{116380ff-9f6a-4a90-9319-89ee4f513542}\disk1.img"
    the forensics PoC is:

    This file is actually a DLL file, here's some peframe:
    File Name:      disk1.img
    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
    And Virus Total showing the good infection info:
    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:

    We can see the autostart, and the way it camouflage malicious data in registry using legit scattered softwares and Windows components. Like: Auslogic (RecoveryDataStore), Photo Viewer, Disk Defragment Module, Microsoft Remote Assitance. This all means to hide and prevent the quick notice of this malware in the infected PC, it is a well thought plan.
    To be noted that one of the key is used to run the defrag.exe execution via ShellExecuteW by the [Random].tmp file, and also you can see the "key" used for this malware saved, one last thing to be noticed is the the bot ID used.

    PS: There are also more drops made which are the Windows task installer for this malware

    It is the Windows scheduler (kinda crond) to execute the EXE payload (defrag.exe). Pic:

    What this payload does

    First thing that caught interest and attention is these obfuscation constant variables saved in .rdata section:

    0x40F3AC ; const WCHAR aTztxpx75Xtdsjq
    0x40F3AC aTztxpx75Xtdsjq:
    0x40F3AC    unicode 0, <"tztxpx75]xtdsjqu/fyf">,0
    0x40F3D6    align 4
    0x40F3D8 ; const WCHAR aTztufn43Xtdsjq
    0x40F3D8 aTztufn43Xtdsjq:
    0x40F3D8    unicode 0, <"tztufn43]xtdsjqu/fyf">,0
    0x40F402    align 4
    0x40F404 ; const WCHAR a2e6g3ddEmm
    0x40F404 a2e6g3ddEmm: 
    0x40F404    unicode 0, <"2e6g3dd/emm">,0
    0x40F430 ; const WCHAR aQsphsbnGjmftY9
    0x40F430 aQsphsbnGjmftY9: 
    0x40F430    unicode 0, <"Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfmpxvujm/fyf">,0
    0x40F498 ; const WCHAR aQsphsbnGjmftNf
    0x40F498 aQsphsbnGjmftNf: 
    0x40F498    unicode 0, <"Qsphsbn!Gjmft]Nfttfohfs]ntntht/fyf">,0
    0x40F4DE    align 10h
    0x40F4E0 ; const WCHAR aQsphsbnGjmft_0
    0x40F4E0 aQsphsbnGjmft_0:
    0x40F4E0    unicode 0, <"Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf">,0
    0x40F546    align 4
    0x40F548 ; const WCHAR aQsphsbnGjmftJo
    0x40F548 aQsphsbnGjmftJo: 
    0x40F548    unicode 0, <"Qsphsbn!Gjmft]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf">,0
    0x40F5A2    align 4
    We have good decoder team in MMD. Soon these data were translated as per below:

    When these data formed in the functions where they were called, we will have better idea of WHY these strings were obfuscated. This time we will take a look at the dump analysis in disassembly, to seek the executed code parts only:
    ;;Loads a malicious DLL "1d5f2cc.dll" (later on known as disk1.img))
    0x0C22D37  call 0x0C28720h  target: 0x0C28720
    0x0C22D3C  add esp, 0Ch  
    0x0C22D3F  push 0x0C2F404h <== UTF-16 "2e6g3dd/emm" ; DECODED "1d5f2cc.dll"
    0x0C22D44  lea edx, dword ptr [ebp-00000084h]  
    0x0C22D4A  push edx  
    0x0C22D4B  call dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL 
    ;; Strings for "\Software\Auslogics" entry in registry
    0xC2207C  lea ecx, dword ptr [ebp-00000802h]  
    0xC22082  push ecx  
    0xC22083  mov word ptr [ebp-00000804h], ax  
    0xC2208A  call 00C28720h  target: 00C28720
    0xC2208F  add esp, 0Ch  
    0xC22092  push 00C2F278h <== UTF-16 "Tpguxbsf]Bvtmphjdt]|11111111.1111.1111.1111.111111111111~]SfdpwfszEbubTupsf"
             ; DECODED: "Software\Auslogics\{00000000-0000-0000-0000-000000000000}\RecoveryDataStore"
    ;; Checks path/process iexplorer.exe ..depends on system...
    0x0C22A4E  call ebx  PathFileExistsW@SHLWAPI.DLL (Import, 1 Params)
    0x0C22A50  test eax, eax  
    0x0C22A52  jne 0x0C22AB8h  target: 0x0C22AB8
    0x0C22A54  push 0x0C2F4E0h <== UTF-16 "Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf"
               ; DECODED: "Program Files (x86)\Internet Explorer\iexplore.exe"
    ;; This look bad, why "Skype" is here??
    0x0C22625  xor eax, eax  
    0x0C22627  push 0000007Eh  
    0x0C22629  push eax  
    0x0C2262A  lea ecx, dword ptr [ebp-0x000086h]  
    0x0C22630  push ecx  
    0x0C22631  mov word ptr [ebp-0x000088h], ax  
    0x0C22638  call 0x0C28720h  target: 0x0C28720
    0x0C2263D  mov esi, dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL
    0x0C22643  add esp, 0Ch  
    0x0C22646  push 0x0C2F360h <== UTF-16 "//]tlzqf/fyf"
               ; DECODED "..\skype.exe"
    0x0C2264B  lea edx, dword ptr [ebp-0x000088h]  
    0x0C22651  push edx  
    0x0C22652  call esi  lstrcpyW@KERNEL32.DLL
    ;; And checks for Messenger too.??
    0x0C229DB  push edx  
    0x0C229DC  call ebx  PathFileExistsW@SHLWAPI.DLL 
    0x0C229DE  test eax, eax  
    0x0C229E0  jne 0x0C22A46h  target: 0x0C22A46
    0x0C229E2  push 0x0C2F498h <== UTF-16 "Qsphsbn!Gjmft]Nfttfohfs]ntntht/fyf" ; 
               ; DECODED: "Program Files\Messenger\msmsgs.exe"
    0x0C229E7  lea eax, dword ptr [esp+74h]  
    0x0C229EB  push eax  
    0x0C229EC  call esi  lstrcpyW@KERNEL32.DLL
    ;; wscript.exe path..this must be used for something bad..
    0x0C22876  call dword ptr [0x0C2D090h]  GetVersion@KERNEL32.DLL (Import, 0 Params)
    0x0C2287C  mov esi, dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL (Import, 2 Params)
    0x0C22882  push 0x0C2F3ACh <== UTF-16 "tztxpx75]xtdsjqu/fyf"; DECODED: "syswow64\wscript.exe"
    0x0C22887  lea eax, dword ptr [esp+74h]  
    0x0C2288B  push eax  
    0x0C2288C  call esi  lstrcpyW@KERNEL32.DLL (Import, 2 Params)
    Found this function is interesting, I found the check for username "Administrator" and SUID "system" are checked:
     ;; Getting the current user name....
    0x0C21FAB  xor bl, bl  
    0x0C21FAD  call dword ptr [0xC2D00Ch]  GetUserNameW@ADVAPI32.DLL (Import, 2 Params)
    0x0C21FB3  test eax, eax  
    0x0C21FB5  je 0x0C21FCEh  target: 0xC21FCE
    0x0C21FB7  push 0x0C2F22Ch  <== UTF-16 "system"
    0x0C21FBC  lea ecx, dword ptr [ebp-0x000204h]  
    0x0C21FC2  push ecx
     ;; Seek for Administrator account...
    0x0C21AC9  call dword ptr [0x0C2D014h]  LookupAccountSidW@ADVAPI32.DLL
    0x0C21ACF  test eax, eax  
    0x0C21AD1  je 0x0C21AFDh  target: 0x0C21AFD
    0x0C21AD3  lea ecx, dword ptr [ebp-0x000204h]  
    0x0C21AD9  push ecx  
    0x0C21ADA  push 0x0C2F1FCh <== UTF-16 "administrators"
    0x0C21ADF  call dword ptr [0x0C2D030h]  lstrcmpiW@KERNEL32.DLL
    0x0C21AE5  test eax, eax  
    Suspicious isn't it?

    I go back to the binary for understanding the related functions, which is in 0x4027F0. I was wondering of what is the part of wscript.exe (not again!??) mentioned by this binary. So I trailed the path of the wscript.exe starting here, assumed that the Windows architecture is x64:

    0x40286E call    sub_408720      ; Check to fill ECX w/Quad deobfs
    0x402873 add     esp, 0Ch        ; reserve ESP w/version info
    0x402876 call    ds:GetVersion   ; Get current version number of Windows
    0x402876                         ; and information about the operating system platform
    0x40287C mov     esi, ds:lstrcpyW
    0x402882 push    offset aTztxpx75Xtdsjq <== Push: "tztxpx75]xtdsjqu/fyf" to stack
    0x402882                         ; Decoded: "syswow64\wscript.exe"
    0x402887 lea     eax, [esp+694h+pMore] ; load EAX
    0x40288B push    eax             ; lpString1 (push this to the stack)
    0x40288C call    esi ; lstrcpyW  ; Indirect Call Near Procedure
    0x40288E mov     dx, [esp+690h+pMore]
    0x402893 xor     edi, edi        ; Cleanup EDI
    0x402895 xor     ecx, ecx        ; Clenup ECX
    0x402897 movzx   eax, dx         ; trail of [esp+69Ch+CommandLine]
    0x40289A cmp     di, dx          ; A check to goto Appname/path
    then found the binary wscript.exe is executed in this part:
    0x402B54 xor     eax, eax
    0x402B56 push    40h
    0x402B58 push    eax
    0x402B59 mov     [esp+698h+ProcessInformation.hThread], eax
    0x402B5D mov     [esp+698h+ProcessInformation.dwProcessId], eax
    0x402B61 mov     [esp+698h+ProcessInformation.dwThreadId], eax
    0x402B65 lea     eax, [esp+698h+StartupInfo.lpReserved] ; Load Effective Address
    0x402B69 push    eax
    0x402B6A mov     [esp+69Ch+ProcessInformation.hProcess], 0
    0x402B72 call    sub_408720      ; deobfs procedure..
    0x402B77 add     esp, 0Ch        ; prep ESP
    0x402B7A xor     ecx, ecx        ; initiate ECX
    0x402B7C lea     edx, [esp+690h+ProcessInformation] ; pump EDX w/process info
    0x402B80 push    edx             ; lpProcessInformation
    0x402B80                         ; goes to stack
    0x402B81 lea     eax, [esp+694h+StartupInfo] ; load eff addr EAX filled w/
    0x402B81                         ; startup info
    0x402B85 push    eax             ; lpStartupInfo goes to stack
    0x402B86 push    offset Buffer   ; lpCurrentDirectory
    0x402B8B push    ecx             ; lpEnvironment
    0x402B8B                         ; (fill ECX w/ cmd execution flags)
    0x402B8C push    ecx             ; dwCreationFlags
    0x402B8D push    ecx             ; bInheritHandles
    0x402B8E push    ecx             ; lpThreadAttributes
    0x402B8F push    ecx             ; lpProcessAttributes
    0x402B90 mov     [esp+6B0h+StartupInfo.wShowWindow], cx
    0x402B95 lea     ecx, [esp+6B0h+CommandLine] ; load ProcInfo,Thread/ProcID+CmdLine
    0x402B9C push    ecx             ; lpCommandLine goes to stack
    0x402B9D lea     edx, [esp+6B4h+ApplicationName] ; load appname &..
    0x402BA4 push    edx             ; lpApplicationName goes ot stack
    0x402BA5 mov     [esp+6B8h+StartupInfo.cb], 44h
    0x402BAD mov     [esp+6B8h+StartupInfo.dwFlags], 1
    0x402BB5 call    ds:CreateProcessW ; process called
    0x402BBB test    eax, eax        ; execution
    So we have the wscript.exe process up and running.

    Up to this part our teammate poke me in DM, and he asked me what can he helped, so I asked our friend (Mr. Raashid Bhat) to take over the further analysis of this defrag.exe and disk1.img, while I went to other parts, and after a while he came up straight forward with (1) decoder logic, which is match to our crack team did:

    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..
    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
    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:

    This shellcode I tweaked a bit, is in a plain assembly, contains three addresses of Windows static API call to (I wrote these API in order of calls from top to bottom) LoadLibraryW@kernel32.dll, RtlGetLastWin32Error@ntdll.dll, Sleep@kernel32.dll which can be shown in assembly code of the code as per snips below:

    So now we know that defrag.exe is actually hacked wscript.exe, hooks ExitProcess Function of kernel32.dll and patches it with a LoadLibraryW@kernel32.dll 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
    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
    ..this will be resulted in some internal socket binding operation we spotted in the debug mode as:
    Bind IP  Port   Status          (n) HookAddr  API Calls
    --------------------------------------------------------  51902  success  1  100105A3  getaddrinfo  52652  success  1  100105A3  getaddrinfo  57334  success  1  100105A3  getaddrinfo  1209   success  1  100105EA  connect  54643  success  1  100105A3  getaddrinfo  53539  success  1  100105A3  getaddrinfo  54536  success  1  100105A3  getaddrinfo  1210   success  1  100105EA  connect  51696  success  1  100105A3  getaddrinfo
    Which one of them is successfully established connection to CNC:
    Bind IP  Port   Status          (n) HookAddr  API Calls
    "  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:

    Which sending the below blobs of binary:

    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:

    Furthermore, using the different method of networking (I won't explain this for the security purpose), I could find the alive connection to the CNC's IP and PoC'ing the blob binary sent to initiate the connection. Noted, again the data matched, the reversing blob binary is actually the CNC sent data used to initiate the CNC communication, as per captured in the PCAP below, same bits:

    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:
    Which historically are using the below IP addresses:
    The first three domains is having a very bad reputation in phishing & malware infection globally. PoC-->[here]

    For the location of these IP are shown in the below details:

    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 -0000
    last seen 2013-11-04 05:22:20 -0000 A
    first seen 2013-10-07 13:10:00 -0000
    last seen 2013-11-18 14:38:32 -0000 A
    first seen 2013-08-26 10:01:39 -0000
    last seen 2013-10-07 12:34:21 -0000 A
    first seen 2012-12-17 04:20:19 -0000
    last seen 2013-06-20 05:53:03 -0000 A
    first seen 2013-06-20 08:00:28 -0000
    last seen 2013-08-26 09:00:42 -0000 A
    first seen 2013-11-01 21:22:55 -0000
    last seen 2013-11-04 05:24:20 -0000 A
    first seen 2013-10-07 13:10:18 -0000
    last seen 2013-11-18 14:38:38 -0000 A
    first seen 2013-08-26 10:02:05 -0000
    last seen 2013-10-07 12:33:13 -0000 A
    first seen 2012-12-17 04:19:46 -0000
    last seen 2013-06-20 05:52:30 -0000 A
    first seen 2014-01-06 01:21:07 -0000
    last seen 2014-01-11 14:30:44 -0000 A
    first seen 2013-06-20 07:07:43 -0000
    last seen 2013-08-26 09:01:08 -0000 A
    first seen 2013-08-26 10:02:31 -0000
    last seen 2014-08-22 04:06:36 -0000 A
    first seen 2013-10-05 11:54:26 -0000
    last seen 2013-10-07 13:45:55 -0000 A
    first seen 2013-06-20 06:26:33 -0000
    last seen 2013-08-26 09:01:34 -0000 A
    And below is the DNS queries for these hostname (not IP) recorded in the recent terms, thank's to OpenDNS:

    Cross checking various similar samples with the all recorded domains & IPs for the related CNC we found more possibility related hostnames to the similar series of the threat, suggesting the same actor(s), noted the usage of DDNS domains:
    (there are some more but we are not 100% sure of them a TBA now..)
    The bully actor(s) who spread this APT loves to hide their domain behind various of services like:
    With noted that these THREE CNC domains used by this sample, are made on this purpose only, and leaving many traceable evidence in the internet that we collected all of those successfully. Trailing every info leaves by this domains:, will help you to know who is actually behind this attack. Noted: see the time frame data we disclosed above. If there any malware initiators and coders think they can bully others and hide their ass in internet is a BIG FAIL.

    The data is too many to write it all here, by the same method of previous check we can find the relation between results. It is an interesting investigation.


    What we analyzed is shared only in KernelMode, link-->[here]
    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.

  • Sunday, August 10, 2014

    A protest! What's BAD stays BAD. Legalized any badness then you ruined the FAITH!

    I think all American friends know exactly what will InfoSec people react to this "search warrant" (see twitter embedded below). Like it or not, I am a part of InfoSec non-"AmericaIn" faction and feeling VERY upset about this privacy-violation-anarchism.

    Don't preach us anymore about the story of "freedom of speech", liberalism, human rights and privacy BULLSHIT, as non-"AmericaIn" we see that your government doesn't even care about thousands multinational people's privacy just to nail some crooks, people's rights are getting ripped from them as "disposable casualties / items" by this warrant and AND THAT IS WRONG! and this is the malicious verdict-->[HERE] with payload here-->[HERE]

    This strategy (linked-->HERE) is not only against privacy, which was recognized to be violated significantly since the disclosure of "the Snowden issues", but the worst part of the problem has ESCALATED now..
    This search warrant was LEGALIZED and will motivate bad people to use malware methods more! (hidden frame, drive-by-download, installing payloads, callbacks to CNC.. these MO ring any bell??) This is VERY principled matter to us.

    How we as MMD suppose to suppress malware growth now IF a court order (linked-->HERE) from a country that created internet is PUBLICLY (I said publicly since that warrant is searchable and viewable w/o secrecy) has legalized the usage of malware??

    There are still more options to dig up & use, there are also tons of good folks who are willing to help the FBI to nail crooks connected via Tor connection, yet WHY has the nastiest counteroffensive been chosen?? The Feds can come to us for examples and we can show them interesting ways to track the bad Tor users WITHOUT USING MALWARE!

    This is going to be written in the history of malware, like, "In 2014 2012 US Court publicly issued search warrant to allow the FBI to use "malware method" on ..etc etc etc.." < How does it sound? (Thank's for the "friend" initialed AP who contacted and correction the date! )

    I am off the field then, pick up some other player to play in this nasty game, this is just a WAY OUT OF LINE for me now. Ah, yes, BTW, you can expect me to STOP sharing malcodes and samples to US's entities .GOV, .MIL or .EDU as I am AFRAID those evil technology will be misused for the similar purpose ....or worse!

    I still can't believe my eyes after reading and checking the facts, I KEEP MY FAITH for you guys, that FAITH was all that supported our research and sharing, our heartbeats...and you RUINED that faith now, what is BAD is just matter what excuse is given to use it, WTF!

    Unless something will be done accordingly from the US's side to put the perception back in the right place, this will be my last post on our belovd internet as malwaremustdie.

    Oh yes, I am damn serious about everything I wrote!

    Supported article:
    Twitter thread


    So that's your excuse to legitimate the wrong perception that your country's court legalized? Russian or China government NEVER issue warrant to legalize any malware. And you are saying something like: "if a scum can do a scum acts.. meaning good folks can do as scum does too? No way, friend. I was called as "vigilante" for the things that I didn't even done, what would THIS mass-infection of malware & public privacy exploitation be called then??

    Ahahaha! Everyone knows I am NO QUITTER. You don't know me THAT well! This is a matter of what's RIGHT and what's WRONG. The worst part is, maybe samples and malcodes we snagged and shared to US governments were being used too to make that "legitimated" malware. America is the country built from good conscious, at least that was I truly believe, I guess I was very wrong.. My faith on what US can do to conduct RIGHT thing and WRONG thing in IT security and internet security had broken badly now.

    Yep. Damn right I will.

    And that isn't doing any greater good for us. BTW.. Want us to keep on VOLUNTEERING work hard?? Well.. we have some conditions like:
    KEEP THE F** FAITH THEN!! We can still make a good fight without infecting innocent people and act like a crook! So STOP USING MALWARE!! REVOKE THAT IDIOTIC SEARCH WARRANT!!
    What's the matter with you guys!! Wake up America!! Geez!

    Nope! It is a PROTEST, not drama.
    They're using driven-by-download "malware" to mass infecting visitor's PC of a site now, Sir. I drew a clear red line for that matter, and they just crossed it.
    We're doing MMD for raising the world's awareness for people to be protected of malware, to fight it together, and in our back a government was opening warrant to "an indecent malware OP" executed, so now we have to oppose a government's mass malware too, it is just way out of line now.. Now I know WHY some people JUST DON'T WANT malware to be ended.
    Ask anyone else to do the "charity analysis work" for the threat that MOSTLY attacking THAT country, and ask anyone else to feed THAT COUNTRY with malware codes then! I am out! per US "can" revoke that warrant and doing as what good guys supposed do without using malicious driven-by-download that was "framed" in public accessed suspicious sites (I consider TOR and THAT .onion SITE as public visitable sites) and blindly mass infecting the innocent users. They can have their decision, I can decide mine too.

    If ONE country start to play "anarchy" in internet and thinks that they own internet and can do whatever they want, like infecting people with malware, so let THAT COUNTRY clean up all of malware shits themself then, WITHOUT US! It's their internet after all, isn't it?

    I had no plan on quitting, in fact there are at least 3 events I planned to attends & being as speaker. Why should I make THIS or "Snowden buff" as excuses for quitting? FYI, if I want, my sickness would be a perfect reason to quit if I wanted to yet I never use it at all, and I bet you haven't heard that too isn't it?

    I don't care about Snowden and mass espionage he disclosed. But I care about THIS CASE since it is about legitimizing a malware that actually mass-infected a public network..just to aim some crooks.
    Ask to yourself now: What would people say if ..say...MMD hacks GMail server just to aim several malware moronz that is currently using GMail?

    Look, we are good guys, and good guys are supposed to work in good ways. Look at us (MalwareMustDie/MMD), MMD works under the law, and that LAW which was supposed to be built from conscious of RIGHT and WRONG. The technique used in "THAT malware" is definitely against moral and privacy aspects we all have, there is no way you can control the visitor of a public accessible site and there's no doubt that innocent victims were harmed (read: infected) and their privacy were violated too. Want to argue more about this? Should I disclosed some codes then??

    There are SO MANY ways without using malware to trace the bad tor users, and I believe Tor Project folks will always cooperate to law enforcement. Why the LAW enforcer should use technique that is commonly used to break the LAW itself? Since when we started to allow Government uses malware?? Who says THAT IS OK?? Does US Congress know about this matter and approve this??? Because I am telling you all this method won't give ANY good merit to USA.

    KEEP THE FAITH!! There are good people who is sacrificing after work hours by doing something good and having these FAITH, why government can't have the some faith??

    I can answer this question practically, principally and morally speaking:

    PRACTICALLY: How can we know that? It was mentioned THAT COUNTRY's LE was nailing ID of some crooks by the information gatherted during the infection by this method, meaning, the infection was applied, the information was gathered, the malware codes was implelented as hidden frame in public site which having possibility to be visited by innocent INTERNATIONAL users too (via redirection etc), so, it is logically all infected innocent people's privacy info are also in the hand of FBI. Do we have some kind of NDA about this with FBI somehow? Hell NO! This is a strictly privacy violation made by a one-sided country's law against INTERNATIONAL people!

    PRINCIPALLY: (1)Infected a site with malcodes, (2) driven-by-download, (3) mass-infecting visitor of some sites, (4)gathering sensitive information, and (5)send those back to the CNC , are the definition of malicious infection method that we all fight EVERYDAY. If the law legalized this EVIL method for whatever reason they presented with that "Search Warrant", this means bad methods are becoming legit to be used for LE to nail a crook. FYI, I consulted with my lawyer and it was confirmed that warrant CAN BE USED for "using the same method" in many cases too. So now, we will have bad people using malware, and good people using malware, the things that we would love to end.

    MORALLY: Do good people in order to nail a JERK have to be a JERK too by adapting the JERK's way to conduct stuff? Malware method is NEVER designed to support ANY goodness, all of malware basic concept are made and meant to: steal, spy, overpower, and destroy concepts.. I don't buy that "Using malware we can make a better world!!" buff! As good guys we should conduct our act WITH FAITH. NOTED: Using MALWARE is not the only option left for tracing Tor users. Many good researchers know and doing that in daily basis in proper ethical hacking way, why LE should use MALWARE?? This is just about a matter of Power Play for me. A lousy Show Off! USA can start loosing MORE friends for this, starting from ME.

    We against the usage of malware by anyone, to whatever target, for whatever purpose! Every malware is naturally designed to infect, steal, spy, manipulate, attack or destructive purpose, that is why it was called MAL-WARE = MALICIOS SOFTWARE. There is nothing good that can come up by using malware, it may harm innocent people by: compromising the privacy information, destruction to your data, or worse than that.. There is no excuse to legitimate the usage of malware by blah blah reasons, and IT IS WRONG to evade the multinational people's privacy by infecting malware to thousands of PC to innocent users just to get 12 ID of crooks!! I still wonder why US Congress was allowing this miserable incompetent method to fight the crime!! We don't have to be a JERK to catch a JERK!!
    Read our blog, is there any of our MMD post is containing illegal method?? NO! We can nail many BAD stuff by Ethical Hacking method, why can't you??

    You damn right! We'll start to peel this crap first, then MAYBE we can call it even. Enough talking, let's start walking. I promise that MMD will aways be every malware-users' worst nightmare!

    Sir. We do VALUE every effort we do, that's why we are protesting this. How we can SUPPRESS the usage of malware IF the country's that developed internet is allowing the usage of it, by a mere "regular search warrants from a district court"? They don't think of multinational right exists or what?? We are in purpose using Tor for PRIVACY and the FBI thinks they can ruined it ANYTIME by getting a regular search warrant..

    We don't do our research for mere CHARITY. Let's simplify, what's WRONG just stay WRONG, there is no justification for it. No one can predict exactly what malware will run, malware is MAL-icious by its nature and name, using it in multinational sites for ANY purpose is just irresponsible OR disrespectful act to others. Who the FUCK was allowing the FBI in getting NON-AMERICAN IP's INFO in Tor? I didn't recall signing any NDA to let them do that too, not even in Tor Project SLA!

    A bad misinterpretation of our protest:

    Putting things right!

    As you can see in the analysis above, the malicious hidden IFRAME redirector driven by javascript, which are implemented in some pages under the Freedom Hosting site, is redirecting users matching to criteria Wndows OS and Firefox browser to the specific .onion domain to exploit 0day CVE-2013-1690 and executing shellcode as the payload. The shellcode is sending ARP to the remote host followed by HTTP/1.1 GET to a host in USA that has no specific registered organization listed (ghost block IP), with the below trace:
    ASN: 701 / UUNET
    Vienna, Virginia, United States, North America         
    38.9012,-77.2653 Verizon Business
    It's beyond any doubt now that sensitive information (READ: PRIVACY): (1) Infected PC hostname, (2) MacAddress (attached in ARP packet) and (3) IP address is sent to this remote host. Not to mention (4) the cookie which was installed in infected PC can be use for tracking purpose.
    Below is the evidence of the traffic capture snapshot.
    PCAP picture in big image-->[HERE]

    A check mate!

    Malware MUST Die! /* Including the legalized one! */

    Sunday, June 15, 2014

    MMD-0025-2014 - ITW Infection of ELF .IptabLex & .IptabLes China #DDoS bots malware

    The background

    I think some of Linux sysadmins and malware researchers already know this issue well by reading references in sysadmin/linux forums or reported incident in works, or maybe facing this problem them self. Since the wave of attacks are still spotted and hitting several services with the known webapp vulnerabilities, yet there are no complete verdict details of the threat (yet), we feel it's important to raise an alert on this subject in MMD post as advisory to help fellow admins who may google info of this threat with hoping this may help giving thorough explanation. The recent vulnerability that was exploited to spread this malware infection is a per tweeted here:

    Maybe some of us think that DDoS tools are just only infiltrating victim sites with some kids attemting to hack on unattended sites & installing their bots written in IRC Perl/PHP DDoS'er scripts. This post is a good reading for you who think that way, since it explained a more serious threat using ELF DoS binaries specifically built to conduct DDoS action in hacked Linux servers via serious root exploitation method in each infection. This threat is known as the infection of .IptabLex and .IptabLes ELF #DDoS backdoor trojan (malware). The infection was coming from China, and is world-wide now, hitting various Linux based services with new flaws in vulnerability and giving problems to some of us.
    Here goes the details..

    The worldwide incidents reported

    First, how is the coverage of this infection? Below is the list of reported incidents of the current threat world wide, I followed & collected in chronological basis, all are referring to the same binary sets and similar infection modus operandi. Infected server's distributions are varied like Debian, Ubuntu, Slackware, CentOS to Redhat, via vulnerability in server application like Tomcat, Elasticsearch, Apache struts etc. But all of them are informing same vector of hack in code injection vulnerability.
    FYI. No, we have not seen any FreeBSD or Mac OS X based server as victim (yet).

    Jan 13 2014 at 15:26 (CHINA) [link]
    Jan 18 2014 at 19:11 (EUROPE) [link]
    Apr 10, 2014 (N/A) [link]
    Apr 25, 2014 (N/A) [link]
    May 4 2014 (HUNGARY) [link]
    May 8 2014 (USA) [link]
    May 12 2014 (US) [link]
    May 25, 2014 (N/A) [link]
    May 27, 2014 (VIETNAM) [link]
    May 27, 2014 (N/A) [link]
    Jun 3, 2014 (EUROPE) [link]
    Jun 4, 2014 (N/A) [link]
    Jun 8 2014 (EUROPE) [link]

    Source of threat

    The origin of the threat is coming from China, which can be technically described in the next analysis sections, but there are so many report posted about the threat in China sites with this reference -->>[here]

    The symptoms of infection

    An infected linux host will suffer the root privilege escalation and installed with the malware sets as per below details.

    Malware main files will be located in either /boot or /usr as per below. It firstly tried to write in /boot , if fail the malware will be saved in /usr.


    The malware will be accompanied by the autostart script:

    $ ll -a /boot/Ip*
    IptabLes -> /etc/rc.d/init.d/IptabLes
    IptabLex -> /etc/rc.d/init.d/IptabLex
    $ sudo cat /etc/rc.d/init.d/IptabLex
    exit 0
    $ sudo cat /etc/rc.d/init.d/IptabLes
    exit 0
    The PID locked files will be detected:
    $ ll -a /[InfectedPath]/
    ↑In most cases we found these files spotted in root (/) directory.

    In the case that I was handled, the binaries and autostart scripts is having these size:

    -r----x--x   1 xxx xxx 1103207 Apr 25 16:38 .IptabLes*
    -r----x--x   1 xxx xxx  722392 Apr 25 16:38 .IptabLex*
    -r----x--x   1 xxx xxx      33 Apr 25 16:IptabLes*
    -r----x--x   1 xxx xxx      33 Apr 25 16:IptabLex*
    While the first two are the malware binaries them self, following by the autostart scripts. Usually the infected host is having both binaries. The bigger size one is the newer and "advanced version", and the smaller one is limited version.

    In some cases the "advanced" versions is having runtime problem and created segmentation fault (crash) as per lsof below:

    $ sudo lsof -p 27322
    .IptabLes 27322 root  cwd    DIR  253,0     4096       2 /
    .IptabLes 27322 root  rtd    DIR  253,0     4096       2 /
    .IptabLes 27322 root  txt    REG  104,1  1103243    5905 /boot/.IptabLes
    .IptabLes 27322 root    0u   REG  253,0        5   98310 /
    .IptabLes 27322 root    1u   REG  253,0        5   98313 /
    .IptabLes 27322 root    2u  sock    0,5      0t0 3442424 can't identify protocol
    .IptabLes 27322 root    3u   raw             0t0 3445564 00000000:00FF->00000000:0000 st=07
    .IptabLes 27322 root    4u   raw             0t0 3445565 00000000:00FF->00000000:0000 st=07
    .IptabLes 27322 root    5u   raw             0t0 3445566 00000000:00FF->00000000:0000 st=07
    Where the smaller size mostly runs well, as per reported lsof:
    $ sudo lsof -p 2013
    .IptabLex 2013 root  cwd    DIR   253,0     4096     2 /
    .IptabLex 2013 root  rtd    DIR   253,0     4096     2 /
    .IptabLex 2013 root  txt    REG   104,1   722580  5906 /boot/.IptabLex
    .IptabLex 2013 root    0u   REG   253,0        5 98309 /
    .IptabLex 2013 root    1uW  REG   253,0        5 98311 /
    .IptabLex 2013 root    2u  IPv4 3479690      0t0   TCP x.x.x.x:10038-> (ESTABLISHED)
    The netstat connection upon started upon malware success running and connected to the backdoor can be seen like this:
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
    tcp        0    157 x.x.x.x:53534      ESTABLISHED 20543/.IptabLex     
    There will be also some UDP ports opened as per below:
    udp  0   0*  20595/.IptabLes
    udp  0   0*  20595/.IptabLes
    udp  0   0*  20832/.IptabLes
    udp  0   0*  20832/.IptabLes
    udp  0   0*  20832/.IptabLes
    udp  0   0*  20832/.IptabLes
    And the SYN packet generated from the infected host will look like this:
    tcp  0   1 x.x.x.x:52831       SYN_SENT    20539/.IptabLes
    tcp  0   1 x.x.x.x:36089      SYN_SENT    20389/.IptabLes
    tcp  0   1 x.x.x.x:36089      SYN_SENT    20389/.IptabLes
    tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:58164       SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:36720      SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:36720      SYN_SENT    20595/.IptabLes
    tcp  0   1 x.x.x.x:55258      SYN_SENT    20613/.IptabLex
    tcp  0   1 x.x.x.x:55258      SYN_SENT    20613/.IptabLex
    tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
    tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes
    tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
    tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes
    tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
    tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes

    Definition of the Malware

    This malware is the DDoS bot ELF malware variant, with a bot backdoor function connected to the CNC which sending them instruction to attack targeted hosts by SYN Flood or DNS Flood DoS techniques. It was autostarted as daemon everytime the host's services started.

    So far we see no RAT (Remote Access Trojan) functionality spotted unless for the specific DoS bot functions, and also no sign of rootkits/system environment deletion detected except the additional of autostart scripts.
    The deletion process of this malware can be performed safely by execution of the below commands:

    $ sudo rm -f /.mylisthb*  
    $ sudo  rm -f /boot/.IptabLex
    $ sudo  rm -f /boot/.IptabLes
    $ sudo  rm -f /usr/.IptabLex
    $ sudo  rm -f /usr/.IptabLes 
    $ sudo  rm -f /etc/rc.d/init.d/IptabLex
    $ sudo  rm -f /etc/rc.d/init.d/IptabLes
    The further observation of the binaries we know that it was originated in China Linux environment.

    According to the reported cases it has backdoors connected to China IP addresses as per recorded data below:||4134 | | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK  ||23724 |   | CHINANET-IDC-BJ | CN | - | FOREST ETERNAL COMMUNICATION TECH. CO.LTD

    Binary Analysis

    ELF file type:

    IptabLes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
    IptabLex: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
    With noted:
    - There is no dynamic section in this file.
    - There are no section groups in this file.
    - There are no relocations in this file.
    - There are no unwind sections in this file.
    The header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF32
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           Intel 80386
      Version:                           0x1
      Entry point address:               0x8048110
      Start of program headers:          52 (bytes into file)
      Start of section headers:          648072 (bytes into file)
      Flags:                             0x0
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         5
      Size of section headers:           40 (bytes)
      Number of section headers:         39
      Section header string table index: 36
    ..and Section Headers:
    Section Headers:
      [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
      [ 0]                   NULL            00000000 000000 000000 00      0   0  0
      [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
      [ 2] .init             PROGBITS        080480f4 0000f4 000017 00  AX  0   0  4
      [ 3] .text             PROGBITS        08048110 000110 0695a8 00  AX  0   0 16
      [ 4] __libc_freeres_fn PROGBITS        080b16c0 0696c0 00100f 00  AX  0   0 16
      [ 5] __libc_thread_fre PROGBITS        080b26d0 06a6d0 0001db 00  AX  0   0 16
      [ 6] .fini             PROGBITS        080b28ac 06a8ac 00001c 00  AX  0   0  4
      [ 7] .rodata           PROGBITS        080b28e0 06a8e0 01554c 00   A  0   0 32
      [ 8] __libc_atexit     PROGBITS        080c7e2c 07fe2c 000004 00   A  0   0  4
      [ 9] __libc_subfreeres PROGBITS        080c7e30 07fe30 000030 00   A  0   0  4
      [10] __libc_thread_sub PROGBITS        080c7e60 07fe60 000008 00   A  0   0  4
      [11] .stapsdt.base     PROGBITS        080c7e68 07fe68 000001 00   A  0   0  1
      [12] .eh_frame         PROGBITS        080c7e6c 07fe6c 00b4fc 00   A  0   0  4
      [13] .gcc_except_table PROGBITS        080d3368 08b368 00010c 00   A  0   0  1
      [14] .tdata            PROGBITS        080d4474 08b474 000014 00 WAT  0   0  4
      [15] .tbss             NOBITS          080d4488 08b488 000018 00 WAT  0   0  4
      [16] .ctors            PROGBITS        080d4488 08b488 000008 00  WA  0   0  4
      [17] .dtors            PROGBITS        080d4490 08b490 00000c 00  WA  0   0  4
      [18] .jcr              PROGBITS        080d449c 08b49c 000004 00  WA  0   0  4
      [19]      PROGBITS        080d44a0 08b4a0 00002c 00  WA  0   0  4
      [20] .got              PROGBITS        080d44cc 08b4cc 000008 04  WA  0   0  4
      [21] .got.plt          PROGBITS        080d44d4 08b4d4 00000c 04  WA  0   0  4
      [22] .data             PROGBITS        080d44e0 08b4e0 000900 00  WA  0   0 32
      [23] .bss              NOBITS          080d4de0 08bde0 0041f8 00  WA  0   0 32
      [24] __libc_freeres_pt NOBITS          080d8fd8 08bde0 000014 00  WA  0   0  4
      [25] .comment          PROGBITS        00000000 08bde0 000398 00      0   0  1
      [26] .debug_aranges    PROGBITS        00000000 08c178 000120 00      0   0  1
      [27] .debug_pubnames   PROGBITS        00000000 08c298 000850 00      0   0  1
      [28] .debug_info       PROGBITS        00000000 08cae8 0079a5 00      0   0  1
      [29] .debug_abbrev     PROGBITS        00000000 09448d 0014a8 00      0   0  1
      [30] .debug_line       PROGBITS        00000000 095935 0018a2 00      0   0  1
      [31] .debug_frame      PROGBITS        00000000 0971d8 000cfc 00      0   0  4
      [32] .debug_str        PROGBITS        00000000 097ed4 0016f2 01  MS  0   0  1
      [33] .debug_loc        PROGBITS        00000000 0995c6 0046d9 00      0   0  1
      [34] .debug_ranges     PROGBITS        00000000 09dc9f 000300 00      0   0  1
      [35] .note.stapsdt     NOTE            00000000 09dfa0 000230 00      0   0  4
      [36] .shstrtab         STRTAB          00000000 09e1d0 0001b8 00      0   0  1
      [37] .symtab           SYMTAB          00000000 09e9a0 009700 10     38 948  4
      [38] .strtab           STRTAB          00000000 0a80a0 0085f4 00      0   0  1
    The smaller size and big size is different in Symbol table '.symtab' entries, if you diff the table functions, the newer version (the bigger in size) is suggesting the "advanced mode" version with the "pro" features:
      2030: 08049750   130 FUNC    GLOBAL DEFAULT    3 CheckPro
      1946: 08049820    40 FUNC    GLOBAL DEFAULT    3 AddProList
      1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
      1671: 08049850   106 FUNC    GLOBAL DEFAULT    3 CreateProlist
    ..and also having more additional "features":
       424: 0806816e    13 FUNC    LOCAL  DEFAULT    3 _L_lock_30
       425: 0806817b    10 FUNC    LOCAL  DEFAULT    3 _L_unlock_120
      1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
      1081: 08068190   159 FUNC    GLOBAL DEFAULT    3 __getdents
      1162: 08049950   191 FUNC    GLOBAL DEFAULT    3 FindPtr
      1242: 080676f0   107 FUNC    GLOBAL DEFAULT    3 __strncasecmp
      1258: 0804ca20   442 FUNC    GLOBAL DEFAULT    3 killpeofnames
      1379: 080680c0   174 FUNC    WEAK   DEFAULT    3 readdir
      1381: 080d40c0 0x5aadd OBJECT  GLOBAL DEFAULT   22 filebyte
      1438: 080676f0   107 FUNC    WEAK   DEFAULT    3 strncasecmp
      1632: 08049a10    57 FUNC    GLOBAL DEFAULT    3 FindCptr
      1670: 080680c0   174 FUNC    GLOBAL DEFAULT    3 __readdir
      1760: 08049be0   208 FUNC    GLOBAL DEFAULT    3 WriteToFiles
      1785: 08050060   325 FUNC    GLOBAL DEFAULT    3 __deallocate_stack
      2041: 080d40a0     4 OBJECT  GLOBAL DEFAULT   22 constfilesize
      2052: 0804c720   106 FUNC    GLOBAL DEFAULT    3 tttaaa
      2209: 0804c6c0    82 FUNC    GLOBAL DEFAULT    3 mystristr
      2212: 0812ebc0   576 OBJECT  GLOBAL DEFAULT   22 tttxsa

    Reverse Engineering Highlights

    These are the source codes file list of this malware in C language:

    Reversing this malware is interesting, and overall reverse effort was taking longer time than I thought. In this highlight I will guide you to the best way to go to the malicious code PoC the verdict the DoS activities. After choosing your best disassembler, I suggest you start trailing the function in address .text:0804DA40 called startmain() to find the good trail that can lead you to the DDoS functions (the verdict) soon:
    public startmain
    startmain   proc near 
    var_18      = dword ptr -18h
    var_14      = dword ptr -14h
    var_10      = dword ptr -10h
    arg_0       = dword ptr  8
    push    ebp
    mov     ebp, esp
    push    edi
    mov     edi, offset aBoot_iptables ; contains "/boot/.IptabLes or Iptablex"
    push    esi
    push    ebx
    You should find the PID and its locking can be followed afterwards from .text:0804DAF5 (for the checking are you trailing the right path..):
    mov     [esp+18h+var_18], offset LOCKFILEX ; "/.mylisthbS"
    call    promutex
    sub     eax, 1
    call    getpid
    call    fork
    Followed by the fork function at .text:080533B0 below:
    fork    proc near           
            push    ebp         
            mov     ebp, esp
            pop     ebp
            jmp     __libc_fork
    fork    endp
    Seek the calls lead to this function's start addeess (0x80533B0) and you will see the main DDoS function directly referring to it:
    The above functions are DoS function which can be reversed as per here-->>[Pastebin] and here-->>[Pastebin], which can be breakdown deeper in how the SYN or UDP packets were formed, randomization of size and the build then followed by the sending thread. The details of those sub functions I will not cover here since it is going to be very long (but please feel free to comment for requests), and the pastebins showed enough evidence of the attack act performed by this flooder.

    Let's moving on. In the .rodata:080B3360 you'll find the URL that the malware use for "test purpose", which can help PoC'ing the origin of this malware w/o much heavy reversing:

    As you can see, three of the listed sites are Chinese web sites. The other things that can help to ID is the multilanguage Linux trace detected and the way it compiled the binaries (based on previous reference of similar threat from same origin, it is typical)

    More malicious activities on the update server's data (link) which clearly show the fetch for updates then save it and deleting those upon done, infected host's sensitive information taken (link), getting networking information of the infected host (link), and hard coding installation of autostart scripts and installation steps (link) which PoC'ed all of the symptoms written above. For the own data handle itself this malware uses a compression logic with the decompression logic that's so "spaghetti coded" like the image below:

    ..with the code can be viewed here (link) ; Note: All reversed snips can be viewed in each shown disassembler links.

    Analysis Samples & Virus Total

    Samples are all in Virus Total already with the below hashes, under detection ratio between 3/54 to 8/54:

    (thank's to "Angel Hun" for the last two samples!)
    For fellow researchers, sysadmins or IR friends, I am sharing samples below:
    2014/04/25  16:38         1,103,207 boot-.IptabLes
    2014/04/25  16:38           722,392 boot-.IptabLex
    2014/04/25  16:39                33 etc-rc.d-init.d-IptabLes
    2014/04/25  16:39                33 etc-rc.d-init.d-IptabLex
    2014/01/19  16:09         1,103,245 src-IptabLes
    2014/01/19  16:09           722,582 src-IptabLex
    That can be downloaded here-->>[MMD Mediafire] with the usual password.


    For the questions and comments are welcome. I need more samples of the recent incidents, if you happen to know ones please help to send us the sample via the DropBox link in the right panel in our (this) blog menu. The comment with the sensitive information or privacy will not posted. With thank you in advance.