1. 악성 MS 워드 트리아지
1. file 을 통한 분석
2. yara64 를 통한 분석
yara 옵션
-w : 경고문구 비활성화
-m : 작성된 yara 룰에 대한 설명, 메타데이터 출력
-s : yara룰과 일치된 문자열 출력
-g : yara룰의 태그값을 출력
3. oleid 를 통한 분석
기대효과 : 문서 파일내에 의심스러운 객체가 포함되어 있는지 식별
4. olevba 를 통한 분석
| Document_open | 문서가 실행될때 매크로 실행 |
| Create, showwindow, CreateObject | 파일 및 응용 프로그램 시스템 명령 실행 의심, 은닉화 의심 |
| Chr, Hex Strings, Base64 Strings | 난독화 의심 |
| VBA Stomping[2] | VBA 매크로 파싱결과 P-code가 생성된다. 그러나 공격자는 악성 P-code와 정상적인 VBA 매크로를 함께 .vbaProject.bin 파일에 저장한다. |
5. pcodedmp 를 통한 P-code 분석
문자열을 복사해서 확인해보면, 2342772...26fq 문자열이 반복되는것을 확인할수 있다.
이부분을 지워보면,
6. oledump를 통한 소스코드 분석
M : VBA 매크로 존재하는 섹션
m : VBA 매크로는 존재하지 않지만, 매크로 관련 모듈에 관한 정의가 존재하는 섹션
- oledump -v -s 13 를 이용해서 13번째 섹션을 조사
13번째 섹션은 함수 호출외에 별다른 악성행위가 없다.
- oledump -v -s 15 를 이용해서 13번째 섹션을 조사
P-code에서 확인한 난독화를 위한 문자열이 존재한다.
- 변수 haothkoebtheil 디버깅
gooykadheoj가 무슨 변수인지 추적해보면,
- roubhaol 추적
이게 뭔말일까?
좀 찾아보니 oledump 동작 방식은 OLE 포맷과 VBA 매크로 저장방식에 대해 깊이 파봐야 이해할수 있을듯 싶어서 나름대로 정리해본다.
OLE 문서는 일종의 가상 파일 시스템 구조를 갖는데, 스토리지(폴더개념)와 스트림(파일개념)이 그것이다. oledump.py는 내부 FAT 구조에 따라 모든 스트림들의 경로와 이름, 크기, 문서 내 상대적 위치를 인덱싱하여 나열한다.
그렇다면, 모듈은 무엇이고 VBA 매크로는 어떻게 저장될까?
모듈은 VBA코드 덩어리이며, 하나의 스트림(파일)이다. 모듈의 종류에 따라 확장자가 달라질수 있으나 모듈은 반드시 하나의 스트림(파일)에 속해 Macros/VBA/ModuleName 형태로 확인된다.
빨간 박스는 뭘까? 이것은 사용자가 정의한 폴더구조로 roubhaol 이라는 문자열을 사용하고 있다. 아직까진 무슨 기능을 하는지 모른다. 다만 Macros/VBA/roubhaol 와 연관되어있음을 짐작할 수 있다.
2. 매크로 스크립트 분석
1. 문서 열람을 통한 분석
- 보기 - 매크로 - 매크로 보기 - 편집
문서2 - 폼 - 사용자 양식을 확인
이전에 "6. oledump를 통한 소스코드 분석" 과정에서 찾았던 Zoom 값을 확인할수 있다.
100에 15를 더했을때 무엇이 될까?
때문에 gooykadheoj 는 s 가 된다.
때문에 조립된 문자열은 "winmgmts:win32_process"이다.
win32_process 메서드는 프로세스를 생성할수 있다. 이 문자열이 어디에 쓰이는지 추적해본다.
deul 변수는 CreateObject 함수의 인자로 전달되는데 이때 CreateObject 함수는 ActiveX 개체에 대한 참조를 만들고 반환한다.
xve 변수에 전달되는것이 무엇일까?
tiaj변수는 개체의 주소, 그렇다면 Create( ) 함수로 인해 생성되는것을 확인해야한다.
함수의 전달인자 geul 변수부터 추적하면,
다시 VBA 편집기에서 ControlTipText를 확인해보면,
그런데 gaod 변수를 살펴보면 Pages 선택 기능이 안보인다. 영상에서도 안보여준다.(왜째서..)
그래서 이것저것 눌러보다가 오른쪽의 수상한 녀석을 발견했다.
복사해서 Notepad++ 로 확인해보면, 이전의 p2342772... 문자열이 또 확인된다. 이 반복되는 문자열을 모두 지워보면 다음과 같은 파워쉘 스크립트가 확인된다.
파워쉘 명령어 -e 옵션은 base64 encodedCommand의 약자이다. 때문에 powershell -e <문자열> 은 인코딩된 명령을 디코딩해서 실행하라는 의미이다.
CyberChef에서 디코딩을 수행해보면 다음과 같이
세미콜론을 기준으로 줄바꿈을 시도해보자
PowerShell-Beautifier 을 이용해서 다음과 같이 파일로 저장한후 powershell ISE 에서 읽어본다.
1 line - 네트워크 보안 프로토콜 TLS 사용
3 line - toeh변수 = userprofile\337.exe
4 line - 웹클라이언트 생성
5 line - 뭔가 알수없는 수개의 도메인이 연결되어있다.
5 line 의 도메인들을 확인해보면, 6 line 에 bp 를 걸고 실행시켜본다.
이를 해결하기 위해 도메인 문자열이 저장된 변수를 직접 확인해본다.
5 line 에서 공백이 발생하기 전까지 드래그하여 선택영역만 실행을 수행한뒤, 변수값을 확인한다.
이를 해결하기 위해서 공백만을 제거하고 다시 5 line 만 실행해서 변수를 확인해본다.
그 밑의 코드를 확인하면, 반복문에 5개의 도메인이 하나씩 들어가서 다운로드를 수행한다.
그후 if문에서 24751 바이트 이상일경우 WMI 클래스를 통해 조건에 맞는 파일을 실행하는것을 확인할수 있다.
REFERENCE & trivia
[1]CDF :
[2]VBA Stomping : VBA 스톰핑은 MS Office의 정상적인 기능을 악용한 사례다. VBA 매크로는 OOXML, OLE 문서에서 삽입가능한 기능이며, VBA를 포함한 파일 작성후 저장시 자동으로 vbaProject.bin 이 생성된다. 파일을 저장할때 VBA매크로는 컴파일되어 P-code 형태로 vbaProject.bin 에 저장되는데 이때 VBA매크로도 함께 저장된다. 공격자는 악성 VBA매크로를 삽입한 문서를 저장한다. 그럼 vbaProject.bin 에는 악성 VBA매크로와 악성 P-code가 함께 저장되는데, 이때 vbaProject.bin 파일에 직접 접근하여(unzip을 이용) 악성 VBA매크로에 정상적인 VBA매크로를 덮어씌운다. 결론적으로 VBA Stomping 기법을 활용한 문서는 정상 VBA매크로와 악성 P-code를 품은채 완성된다. 피해자는 이파일을 열람할시 MS정책에 따라 VBA매크로는 건너뛰고 P-code를 실행한다. 그러나 이 기법은 파일을 저장할시, 새롭게 VBA매크로를 컴파일한다는 MS정책에 따라 악성 P-code를 덮어씌우게 되므로 영속성을 획득하기엔 어려움이 있다.
...
추후 보충