https://vulnerablelife.wordpress.com/2017/06/18/new-fileless-ransomware-with-code-injection-ability-detected-in-the-wild/

psexec를 이용해서 원격으로 svchost.exe에 인젝션하고 파일 인크립트한다는 내용

https://sentinelone.com/blogs/zusy-powerpoint-malware-spreads-without-needing-macros/

매크로 없이 동작하는 오피스 악성코드

대신 사용하는 기능 - "external programs" 

마우스 클릭하지 않아도 동작

external programs를 활성화 할것인지 메세지는 띄워짐

활성화 할경우 powershell 사용한 playload 동작함

C&C는 user-agent를 보내지 않아야 함

최근에 분석한 악성코드.

VMWARE, VirtualBox, VM HDD Size 확인

1. VMWARE magic number ('VMXh') 체크 (이미지 생략)

2. VirtualBox 체크 

- \\\.\\VBoxMiniRdrDn

- VboxHook.dll

3. HDD 용량 체크

GetLogicalDrives로 드라이브를 찾고

GetDiskFreeSpaceExW로 용량 정보를 얻어온다.

특이하게 2부터 7까지 5번 돌면서 G_bytes(위그림의..) 변수에 각 드라이브 용량 합을 20Gbyte와 비교한다.

20G 미만 VM으로 판단

이부분은 처음 봐서 정리함. 

tag - e77d2f10a34

이번 악성코드를 살펴보니 자식 프로세스에 메모리를 재할당하고 Thread Context 구조체를 활용, OEP를 원하는 지점으로 수정하는 방법을 사용하고 있었다.

찾아보니 이미 HOWTO가 많이 검색되었다.

아래는 320변종이라는 악성코드가 사용하는 코드

악성코드가 Thread Context 구조체를 접근하는 이유는 Eax, Ebx가 각각 특정 포인터 역할을 하기 때문이다.

Context.Eax =>Original Entiry Point(OEP)

Context.Ebx =>Process Environment Block(PEB)

(PEB + 8 offset은 Image Base Address이므로 PEB 주소를 알면 이를 수정할 수 있다.)

Eax를 보면 OEP가 수정되었다는 것을 알 수 있다.

최근 악성코드가 사용한 캡쳐 코드

{

  i = 0;

  do

  {

    v5 = 1;

    v6 = 0;

    v7 = 0;

    v8 = 0;

    GdiplusStartup(&v4, &v5, &v13);

    v1 = CreateDCA("DISPLAY", 0, 0, 0);

    H_value = GetDeviceCaps(v1, 8);             // H(가로)

    V_value = GetDeviceCaps(v1, 10);            // V(세로)

    v10 = 0;

    v9 = 0;

    Sleep(0xBB8u);

    GetTempPathW(0xC8u, &Buffer);

    wsprintfW(&Buffer, L"%s%d.jpg", &Buffer, i);

    v2 = CREATE_BITMAP(&v9);

    Save_img(v2, &Buffer);

    DeleteDC(v1);

    GdiplusShutdown(v4);

    ++i;

  }

  while ( i < 5 );

  Sleep(0x2710u);

  return sub_10001C90(&unk_10004140);

}

CREATE_BITMAP(&v9){

  v1 = a1;

  if ( IsRectEmpty(a1) )

  {

    result = 0;

  }

  else

  {

    v8 = CreateDCA("DISPLAY", 0, 0, 0);

    hDCA = v8;

    v9 = CreateCompatibleDC(v8);

    v10 = v1->top;

    v5 = v1->right;

    v6 = v9;

    v11 = v1->left;

    v4 = v1->bottom;

    v19 = v11;

    v18 = v10;

    H_value = GetDeviceCaps(hDCA, 8);

    V_value = GetDeviceCaps(hDCA, 10);

    if ( v19 < 0 )

      v19 = 0;

    if ( v18 < 0 )

      v18 = 0;

    if ( v5 > H_value )

      v5 = H_value;

    if ( v4 > V_value )

      v4 = V_value;

    v12 = v4 - v18;

    v13 = v5 - v19;

    v14 = CreateCompatibleBitmap(hDCA, v13, v12);

    v15 = SelectObject(v6, v14);

    BitBlt(v6, 0, 0, v13, v12, hDCA, v19, v18, 0xCC0020u);

    v16 = SelectObject(v6, v15);

    (DeleteDC)(v17, hDCA);

    DeleteDC(v6);

    result = v16;

  }

  return result;

}

Save_img(v2, &Buffer){

  v4 = 0;

  GdipCreateBitmapFromHBITMAP(this, 0, &v4);

  v3 = v4;

  jpeg_encode(&v6);

  v8 = dword_1000317C;

  v9 = dword_10003180;

  v7 = 1;

  v10 = dword_10003184;

  v12 = 1;

  v11 = dword_10003188;

  v14 = &v5;

  v13 = 4;

  v5 = 30;

  GdipSaveImageToFile(v3, a2, &v6, &v7);

  return GdipDisposeImage(v3);

}

자가보호를 해제하기 위해 API 후킹을 해제하는 악성코드 

"MOV EDI EDI"

악성코드 입장에서는 후킹만 해제하면 되니 참 속편한 듯

후킹해제는 보안 프로그램에서 사용 할 수도 있으니 악성코드라고 보기도 힘든거 같다.

끝없는 창과 방패의 싸움

#PlugX Malware

보통의 경우 최초 드럽퍼가 실행되면 exe, dll, data 파일(확장자는 제작자 마음) 이렇게 3종류의 파일이 특정 폴더에 설치가 된다. 최초 드럽퍼가 어떻게 실행되는 지 확인하지 못 했지만, 방법이야 다양하니 생략,,

예) 

C:\Program Files\Common Files\Nv.exe

C:\Program Files\Common Files\NvSmartMax.dll

C:\Program Files\Common Files\NvSmart.mp3

같은 폴더에 나란히 3가지 파일이 설치되면 먼저 exe파일이 실행되고 DLL이 로드되며 해당 DLL이 다시 남은 data 파일(위의 NvSmart.mp3)을 로드하는 방식이다. 설치를 위해 각각의 파일이 반드시 존재해야하는 것이다.

그런데 3가지 파일이 반드시 필요한 이유가 더 있다. 자세히 살펴보면...

일단 DLL 파일의 Main코드를 살펴보면 다음과 같은 코드들을 볼 수 있다.

처음부터 '20120101'을 현재 실행되고 있는 PC의 System시간과 비교한다. 이 부분은 상기 언급한 반드시 필요한 부분에 포함되지 않지만, 구지 비교하는 이유가 궁금해서.. 이유가 뭘까. 

위 그림을 보면 Module EP를 찾아서 EP의 Page를 R/W하게 변경한다. 그리고 다음과 같이 하드 코딩된 주소(_DataLoad_Routine_)와 EP의 거리를 계산해서 Module EP부분에 덮어쓴다. 해당 어셈코드는 "E8 A6 18 00 00"에서 "E8 8A F8 8F 0F"로 변경되면서 점프되는 곳이 _DataLoad_Routine_ 주소로 바뀌는 것이다.

[Dll Main 코드에 삽입된 EP 수정 코드]

(귀찮게...)

어쨌건 정리하면, exe는 쓰고자하는 DLL을 import하고..

[exe의 import table중 일부]

DLL이 로드되면 DLL Main코드가 실행되면서 exe의 EP가 수정되며(exe 시작전) 다시 DLL의 특정 주소로 점프가 된다(exe 시작 직후). exe는 dll 실행히켜주고 dll은 exe 수정해주고 다시 exe는 dll을 통해 data 파일을 호출하는...완벽한 호흡을 자랑한다..;;

[exe의 원래 EP 코드]

그리고 첨부해서.. exe 원래 EP 코드를 보면 CRTStartup 보다 먼저 어떤 Call이 실행 되는 것을 볼 수 있다. 그래서 exe를 그냥 메인코드 먼저 디버깅하거나 IDA같은 Disassembler로만 보면 놓치는게 있을 수도..

Private Const PROCESSOR_ARCHITECTURE_INTEL = 0
Private Const PROCESSOR_ARCHITECTURE_IA64 = 6
Private Const PROCESSOR_ARCHITECTURE_AMD64 = 9
Private Const PROCESSOR_ARCHITECTURE_UNKNOWN = &HFFFF

GetCurrentProcess -> IsWow64Process

return cmp 0 

0 이면 64bit아님

or

GetNativeSystemInfo

위의 그램을 보면 파라메터로 들어가는 push eax값이 lpSystemInfo로 해당 주소값에 ProcessorArchitecture 결과값이 저장된다. 따라서 cmp ax, 9와 같이 해당 주소의 값을 찾아와서 비교를 하면 64bit 여부를 알아낼 수 있다.

return cmp 9, 6 이면 64bit

0 이면 32bit

MoveFileExA

lpExistingFileName "C:\WINDOWS\system32\drivers\etc\5Uiue"

lpNewFileName (null)

dwFlags "MOVEFILE_DELAY_UNTIL_REBOOT"

최근 주말에 유포되는 악성코드에서 사용하는 행위.

별거 아닌거 같지만 여러 이유가 있는 거 같군. ㅎ

*NGRBOT에서 사용하는 방법

다음은 패치하는 코드.(Native 함수 LdrEnumerateLoadedModules를 통해 모든 모듈에 CallBack함수를 실행, CallBack 함수 및 _Inline_Patch_Routine에서 Inline Patch 행위를 한다.)

주소 찾는 방식.(메모리상 Header, Export Table 정보를 이용한다.)