난 언제나 어떻게 하면 인생을 날로 먹을 수 있을지.. 아니 업무의 생산성을 높일 수 있을 지 고민하며 산다. 최근 눈부시게 발전하는 AI 를 볼수록 이런 생각이 점차 굳어졌다. 하지만 그럼에도 불구하고 그동안 멀웨어 진단에 AI 를 활용하는 것에 대해 회의적이었다. 멀웨어 진단에 있어서 절대 해선 안되는 일 중 하나가 오진을 하는 것인데, AI 는 오진이 너무 많이 일으킨다는 점이 이유다.

하지만 최근에는 멀웨어 분석의 전체 과정을 AI 에게 맡기지 말고, AI 에게 맡길만한 업무와 그렇지 않은 업무를 구분해서 처리하면 괜찮을 것 같다고 생각했다. 이후 Gemini 로 멀웨어 분석을 이리저리 시도해본 결과 어느 정도 유의미한 수준의 결과가 나와 글을 쓰게 되었다.

1. Gemini 를 이용한 멀웨어 분석

1.1 실행 파일 데이터 추출

우선 Gemini 를 통해 멀웨어를 분석하는 데에는 다음과 같은 제한 조건이 있다는 점을 알아야 한다.

• Input 데이터 크기 한계.
• 제한된 업로드 파일 확장자. 실행 파일(exe,elf, 등)은 업로드할 수 없다.

위와 같은 한계점을 해결하기 위해 우선 분석하고자 하는 실행 파일에서 어셈블리 코드, 주요 바이너리 데이터, 등 분석에 필요한 정보를 추출하여 텍스트 형태로 변환해야 한다. 이 작업을 매번 손으로 직접할 순 없으니 Ghidra Script(extract_code.py) 를 작성했다.

Ghidra 에서 스크립트를 등록, 실행하는 방법은 아래와 같다.

우선 Ghidra 로 실행 파일 분석을 완료한 후, 상단의 Display Script Manager 아이콘을 클릭하여 스크립트 관리창을 팝업시킨다.

Script Manager 창의 우측 상단 아이콘 중 Manage Script Directories 를 클릭하면 스크립트를 저장할 디렉토리를 설정할 수 있는 Bundler Manager 창이 팝업된다.

Bundle Manager 창에서 우측 상단의 Display file chooser to add bundles to list 버튼을 클릭하면 디렉토리 경로를 선택할 수 있다. 선택된 디렉토리 경로는 Bundle Manager 에 추가되며, 이제부터 해당 경로의 파일을 스크립트로 인식할 수 있다.

다시 앞서 보았던 Script Manager 창으로 돌아와 Filter 에서 우리가 사용할 extract_code.py 를 검색해보자. 검색이 안되면 Bundle Manager 에 디렉토리가 제대로 추가되었으며, extract_code.py 파일이 해당 경로에 존재하는지 확인 후, 우측 상단의 Refresh Script List 버튼을 클릭한다. 검색에 성공하면 스크립트를 더블 클릭하여 실행할 수 있다.

실행된 스크립트는 실행 결과를 생성할 경로를 선택할 수 있는 선택 창이 출력된다. 적절한 경로를 선택하자. 스크립트가 실행되는 과정은 Ghidra Console 창에서 확인할 수 있다. 현재 실행 파일에서 확인된 함수 수와 현재까지 진행된 수를 출력해준다.

Ghidra Script 는 다음과 같은 동작을 수행한다.

1. 실행 파일로부터 Ghidra 가 분석한 모든 함수 목록을 얻는다.
2. 모든 함수의 decompile 된 코드와, 어셈블리 코드를 텍스트 파일로 생성한다.
3. 실행 파일의 defined 된 데이터를 텍스트 파일로 생성한다.

최종적으로 실행 결과 앞서 선택한 디렉토리 경로에 다음과 같은 텍스트 파일 3개이 생성된다.

• {파일명}_all_assembly.txt : 모든 함수 어셈블리 코드.
• {파일명}_all_decompiled.txt : 모든 함수 디컴파일된 코드.
• {파일명}_defined_data.txt : define 된 데이터.

1.2 Gemini 에 분석 요청

이제 앞서 생성된 텍스트 파일 3개를 이용해 Gemini 에 분석을 요청하면 된다. 나는 아래와 같은 프롬프트로 요청을 하나, 다른 프롬프트를 사용해도 상관 없다.

넌 악성 코드 분석가야. 내가 ghidra 로 exe 실행 파일의 어셈블리 코드와 decompile 된 코드를 추출했어. 이 정보를 근거로 이 실행 파일의 동작을 분석하고 요약해서 악성 파일인지 정상 파일인지 판단해줘. 만약 악성 파일이면 알려진 malware family 중 어떤 것인지 알려줘.

아래 이미지는 이전에 분석했던 BPFDoor 샘플에 대한 코드를 기반으로 분석 요청을 한 결과다. 핵심적인 동작을 잘 요약했으며, 내가 특정한 함수의 동작에 대해 물어보면 상세한 동작도 제대로 설명해주었다.

2. 사용 후기

우선 정적 분석이 가능한 부분에 대해서는 아주 훌륭한 성능을 보여주었다. 내가 쉽게 분석할 수 있는 코드를 빠르게 처리하는 것은 물론이요, 내가 분석하기 어려운 코드도 거의 정확하게 분석해냈다. 예를 들어 아래 코드는 어떤 멀웨어에서 Base64 문자열을 디코딩하는 기능을 수행하는 함수다. 난 Base64 의 디코딩 과정을 정확히 이해하지 못하기 때문에 이 코드만 보고는 어떤 동작을 수행하는지 알기 어려워, 동적 분석을 병행하여 Base64 문자열이 디코딩되어 반환되는 것을 확인해야 한다.

하지만 Gemini 는 내가 던져준 decompile 된 코드만 보고도 해당 코드가 Base64 디코딩 함수인 것을 분석해냈다는 점에서 나보다 전반적인 지식이 넓고 분석 능력도 엇비슷하다고 판단했다.

이 밖에도 놀라운 성과를 보여준 건 멀웨어 분석이 아닌 CTF 에서 pwnable 분야 문제를 풀 때였다. 간단한 문제는 거의 내가 건드릴 것도 없이 실행 파일 정보만 추출해서 던져주니 알아서 답을 도출해냈다. 사실 pwnable 뿐만 아니라 그 밖의 분야에서도 막히거나 내가 놓친 부분을 잘 캐치해서 정답으로 이끌어 나가는 모습을 보여줬다. 이제는 거의 나와 함께 일하는 파트너 수준, 아니 어떨 때는 나보다 더 논리적인 모습도 보여주었다.

하지만 사용하면 할 수록 한계점도 명확하게 보였다.

분석 대상 파일이 난독화, 암호화가 심한 경우 상세한 분석을 진행하지 못하고, 난독화와 암호화 여부만 언급했다. 상세한 분석을 하기 위해서는 분석가가 직접 복호화된 데이터를 덤프 뜬 후 분석을 요청해야 했다.

또한 Input 데이터가 너무 크거나 복잡하면 Gemini 가 분석을 거부해버렸다. 때때로 대화창을 새로 열고 똑같이 다시 시도하면 분석해주기도 한다.

이 밖에도 각 함수 분석해서 rename 해달라고 했더니 요청했더니 존재하지도 않는 주소의 함수를 분석하는 등, 일부 요청은 환각이 심했다. 단, 개별 함수에 대한 분석을 요청했을 때는 정상적으로 잘 분석했다.

아직 부족한 부분이 많았지만 개선의 여지가 많기에 앞으로도 LLM 을 이용한 멀웨어 분석은 계속 테스트할 예정이다. 추후 좋은 방법을 발견하면 포스팅하겠다.