블랙에너지를 해체하다, 2부 – “표식”

BlackEnergy 프레임워크가 무엇인지에 대해 연설하지 않겠습니다. 이미 저 없이도 이 주제에 대해 많이 언급되었기 때문입니다. 그러나 이 특정 리뷰의 정보를 참조하고 싶습니다.:

여러분, Flashplayer를 만나보세요!

우리 인프라에 대한 공격 조사의 일환으로 우리는 여러 악성코드 샘플을 감지했으며 그 중에는 Flashplayerapp.exe도 있었습니다 (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)간단히 말해서, flashplayerapp은 main_light.dll을 자신의 메모리 공간에 추출한 후 이를 제어합니다. 이 라이브러리는 BlackEnergy의 경량 버전으로, 공격자가 추구하는 목표에 따라 기능을 갖춘 메인 페이로드를 다운로드하기 위한 C&C 통신에 사용됩니다. 파일을 생성합니다: C:UsersuserAppdataAdobecache.dat암호화된 상태에서 이 파일은 여러 정보를 포함하며, 빌드 버전(예: 2015lstb)과 다양한 페이로드를 검색할 수 있는 명령 및 제어 센터의 주소(예: hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) 등을 포함합니다. 이 샘플을 분석하면서 코드의 한 부분에서 특별히 주목할 만한 점을 발견했는데, 이는 코드 난독화라는 기술을 사용하는 명백한 신호였습니다. 이 소스의 인용문을 번역해보겠습니다 http://hacks.clan.su/publ/11-1-0-481:

여기 우리 코드 조각이 어떻게 보였는지를 설명합니다 (퍼뮤테이션 엔진에 의해 추가된 명령은 빨간색으로 강조되어 있으며 기능에는 영향을 주지 않으며, 코드 이해를 더 어렵게 만들 뿐입니다):불필요한 문자열을 제거함으로써, 우리는 kernel32.dll에서 모든 함수 이름을 처리하는 메커니즘을 얻게 됩니다.그들의 (이름을) 어떤 값과 비교하는 형태의 해시로 변환함으로써:이 C를 예로 들어 이 메커니즘을 재구성해 보겠습니다. 그 결과, 우리는 kernel32.dll 라이브러리의 모든 함수 이름과 이 이름의 해시 값을 포함하는 “사전”을 생산할 수 있는 유틸리티를 받게 됩니다. 우리는 코드 리버스 분석 중에 얻은 해시 값을 우리의 새로운 “사전”에서 검색해 보겠습니다. 먼저 EAX 레지스터에서 값을 검색하고 (0x5147F60F), 그 후 그 값을 참조 값과 비교합니다:우리의 이론이 작동합니다: 우리 샘플은 첫 번째 함수의 이름을 처리하고 해시를 생성한 후, 현재 버퍼에 포함된 참조 값과 비교하고 있습니다 (0xC8AC8026). 이 값을 검색하고 보십시오… 우리는 LoadLibraryA 함수를 얻습니다!다른 예제의 긴 텍스트를 피하기 위해, 우리 “샘플”이 GetProcAdress라는 다른 함수를 검색하는 데 동일한 접근 방식을 사용한다는 사실만 언급하겠습니다.이 두 함수를 사용하여 우리 “샘플”은 다른 라이브러리를 로드하고 필요한 함수의 주소를 추출할 수 있습니다.

엔진이 남긴 흔적

이름이 아닌 일부 해시 값에 기반하여 함수 호출을 사용하여 정적 코드 분석을 어렵게 만드는 기술은 새로운 것이 아닙니다. 그러나 이는 다음과 같은 생각을 하게 했습니다: 비록 악성 코드가 처리되는 방법이 어떻게 되었든, 함수 이름 해시 알고리즘을 알고 있기 때문에 우리는 이 두 함수(LoadLibraryA 및 GetProcAdress)를 코드에서 확실하게 검색할 수 있습니다. 그래서 나는 인터넷에서 이 해시 (0xC8AC8026)에 대한 언급을 찾기 시작했습니다. 이 예제에서 누군가가 이전에 사용한 적이 있는지를 찾기 위해 놀랍게도 그 무언가를 발견했습니다:이 해시는 2006년 첫 언급되었으며 (이 기사는 archive.org에는만 찾을 수 있습니다): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

그 후, 2008년 이 알고리즘의 잠재적인 저자가 포럼에 등장합니다:https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

그 후 2009년 blogs.technet.com에 shellcode MS08-067에 관한 분석 기사가 게시됩니다:http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

그리고 2013년, “XAKEP” 잡지 (러시아의 최대 IT 및 정보 보안 미디어 중 하나)가 기사를 게시합니다 https://xakep.ru/2011/06/23/55780/ 여기에서 정확히 동일한 알고리즘이 동일한 해시를 생성하는 것으로 언급됩니다 (!):잠시만 기다려 보세요, 우리는 여기서 같은 해시 값을 생성하는 동일한 알고리즘이 10년 이상 사용되고 있음에도 불구하고 아무도 이것을 눈치채지 못했다는 상황에 직면하고 있습니다? 그렇지 않다면, 현재처럼 보이는 flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)가 지금까지 주목을 받지 않았다는 것은 불가능했을 것입니다. 우리는 이미 2016년에 살고 있기 때문에 바이러스 백신 솔루션이 여전히 주목하지 않았을 것입니다:이 분석된 샘플에서 사용된 구체적인 퍼뮤테이션 엔진에 의해 남긴 명확한 “표식”이 있으며, 이는 유효한 서명처럼 보입니다. 게다가, 이는 매우 간단하게 명확한 텍스트에서 직접 추적할 수 있습니다:자, 우리는 가정과 이론을 정리했으니 실전에 들어가 이 결론을 Yara 서명/규칙으로 변환하려고 해 봅시다:

rule API_Hash

{meta: description = “Hash of LoadLibrary that is {26 80 ac c8} 및 GetProcAddres {ee ea c0 1f}”

문자열:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

조건: $a 및 $b

}

이제 해야 할 일은 이 엔진으로 실제로 얼마나 많은 악성 코드가 패킹되었는지 알아내기 위해 다양한 샘플 (예: 바이러스 백신 연구소)에서 테스트하는 것입니다. 현재로서는, 나는 몇몇의 안티 바이러스 회사에서 매우 적은 수의 샘플로 실험을 수행할 수 있었으며, 결과는 충분히 가치가 있었습니다! 잡힌 샘플 중, 우리는: Win32/Spy.Bebloh (은행 트로잔) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit (비밀번호 도용용 트로잔) — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock (백도어) — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp (은행 트로잔 Carberp를 설치하는 드로퍼) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos (스팸 발신자) — http://www.virusradar.com/en/Win32_Kelihos/detail이 목록에는 잘 알려진 계열만 포함됩니다. 이 두 해시 값은 랜섬웨어 / 파일 암호화기 (Win32/Filecoder.HydraCrypt), 비트코인 채굴기 (CoinMiner.LC), WinLocker (LockScreen.AQT) 및 기타 악성코드 가족에도 나타납니다.

현재로서는, 이 비교적 간단해 보이는 Yara 규칙이 현재까지 단일 오탐지도 발생시키지 않았지만, 테스트는 단지 몇십 대의 컴퓨터에 대해 수행되었습니다. 따라서 나는 이 연구가 출판된 후, 당신 (!) 과 이 글을 이렇게 멀리까지 읽은 사람들이 이 규칙의 정확성을 증명하거나 반증할 충분히 큰 피드백을 공유할 것을 진심으로 기대합니다! 물론, 시그니처로 단지 여덟 바이트를 사용하면 예외적으로 작은 것이며, 이 규칙은 일부 “합법” 파일을 잡을 가능성이 큽니다. 그럼에도 불구하고 이 경량 Yara 규칙은 더 복잡한 분석 논리의 일부로서 샌드박스에서 살아남을 수 있습니다.

결론

이 기사의 목표는 BlackEnergy 악성코드를 역공학하는 것이 아니라, 하나의 또는 다른 악성코드 코드의 조립 과정에서 사용된 도구가 그들의 흔적을 남기고, 방어를 위해 활용될 수 있는 유용한 지표의 출현으로 이어질 수 있다는 사실을 강조하고자 합니다. 그리고 이 지표들은 상당히 오랜 시간 동안 눈에 띄지 않을 수 있습니다…

Andrii Bezverkhyi 번역 | SOC Prime CEO