Differences between analyzing with AXIOM and manual analysis

개요

침해사고 발생률이 증가할수록 다양한 도구를 이용한 분석 방법이 제시되고 있다. Magnet 에서는 IR과 관련해 여러 도구를 제시하고 있으며, 흔히 알고 있는 AXIOM에서도 침해사고 관련 아티팩트 분석을 지원하고 있다.

• Magnet RESPONSE : IR 수집 도구
  • 참고 링크 1 : https://www.magnetforensics.com/blog/magnet-response-new-free-tool-for-ir-investigations/
• Magnet Nexus : 원격 진단 도​구
  • 참고 링크 1 : https://www.magnetforensics.com/products/magnet-nexus/

본 글에서는 케이스를 이용해 AXIOM의 침해사고 관련 아티팩트 분석 지원 정도를 확인할 것이다. 확인한 내용을 기반으로 기존의 분석 방법(이하 매뉴얼 분석)과 비교해 각 방법의 장단점을 파악할 것이다.

케이스 정보

AXIOM과 매뉴얼 분석 비교를 위해 사용된 케이스 정보는 아래 표와 같다. 케이스는 총 4개로 윈도우 케이스 3개, 리눅스 케이스 1개로 구성되어 있다. DOREMI 케이스는 플레인비트에서 자체적으로 제작한 교육용 케이스이며, 나머지 케이스들은 Cyber Defenders에 올라와 있는 CTF 연습용 케이스들이다.

Windows 사고 분석 시 차이점

1) 랜섬웨어로 인한 웹서버 감염

케이스의 전반적인 내용은 다음과 같다.

위 그림에 따라 분석한 후, 파악한 매뉴얼 분석과 AXIOM 분석의 전반적인 차이는 아래와 같다.

분석 데이터 추출 및 대상 정보 확인과 같은 분석 준비 단계에서는 직접 추출하지 않고 바로 확인이 가능하다는 점에서 AXIOM 분석을 추천한다. 하지만 AXIOM에서는 웹로그 분석을 지원하지 않기 때문에 매뉴얼 분석을 추천한다. 각 행위에 대해 자세히 살펴보면 다음과 같다.

분석 대상 시스템 정보를 확인할 때 매뉴얼 분석의 경우 해당 정보가 있는 아티팩트를 수집 후 별도의 도구를 통해 확인해야 한다. 반면 AXIOM의 경우 별도의 파일 추출 없이 Examine을 통해 모든 아티팩트에 대해 바로 확인 가능하므로(ex. Operating system → Operating System Information), 분석 절차 간의 시간이 단축된다. 이런 점에서 AXIOM을 이용한 분석이 매뉴얼 분석보다 낫다고 생각한다.

하지만 AXIOM의 침해사고 관련 아티팩트 분석 지원 정도를 보면, 침해사고 분석에 있어서 마냥 AXIOM 분석이 매뉴얼 분석보다 낫다고 생각할 수 없다.

랜섬웨어 감염 사고를 분석하기 위해서는 보통 웹로그와 시스템로그를 사용해 최초 침투 경로 및 공격 행위를 확인한다. 그중 웹서버를 대상으로 한 랜섬웨어 감염 사고의 경우 웹로그를 이용해 최초 침투를 확인한다. 따라서, 해당 케이스에 대해 매뉴얼 분석 시에도 access.log를 추출해 최초 침투 및 DB 계정 탈취와 같은 공격 행위에 대해 분석했다.

동일하게 분석을 진행하기 위해 AXIOM에서도 웹로그 분석 내용을 확인해 봤다. 하지만 AXIOM에서는 웹로그 분석을 아예 지원하고 있지 않기 때문에 Artifact Explorer 내 어느 항목에서도 확인할 수 없었다. 시스템 로그의 경우 Operating system 내 Windows Event Logs-System Events에서 보여주고 있지만, 다른 아티팩트처럼 상세 분석이 이루어지는 것이 아닌 단순 뷰어 수준으로 보여주고 있다.

결론적으로 AXIOM에서 분석할 수 있는 로그 종류가 제한적이기 때문에 정찰, 침투 등 행위를 분석하는 것은 매뉴얼 분석이 효과적이라고 생각한다.

2) 악성 이메일로 인한 PC 감염

해당 케이스는 이메일 분석을 하는 케이스로, 실제 악성 이메일을 다운로드한 케이스는 아니다. 하지만 이메일과 연관된 특정 시나리오에 대한 분석 방법 비교하기에는 적합한 케이스라고 판단해, 이를 가지고 이메일 관련 분석에 있어서의 분석 방법을 비교했다.

케이스 분석 시 파악된 전반적인 차이점은 아래 표와 같다.

이 케이스에서 초점을 맞추고 봐야 할 부분은 이메일 파일(.ost) 분석이다. 매뉴얼 분석 시 이메일 파일 분석할 때 특정 뷰어(ex. Kernel OST Viewer)를 이용한다. 이런 뷰어들은 특정 파일에 대해 세부적으로 잘 보여주지만, 분석 결과 추출이 불가능하다는 단점이 있다. 하지만 AXIOM으로 분석하면 세부적인 내용을 확인할 수 있을 뿐만 아니라, 분석 결과 추출도 가능하다.

결론적으로 AXIOM에서는 이메일 파일에 대해 상세 분석을 지원하면서 동시에 분석 결과 추출까지 가능하기 때문에 이메일 관련 사고를 분석할 때는 AXIOM 분석으로 하는 것이 더 좋을 것 같다고 판단된다.

3) 악성파일 다운로드로 인한 PC 감염

케이스의 전반적인 내용은 다음과 같다.

위 그림에 따라 분석한 후, 파악한 매뉴얼 분석과 AXIOM 분석의 전반적인 차이는 아래와 같다.

이전 케이스들과 동일하게 분석 준비 단계에서는 추출 없이 바로 확인 가능하다는 점을 고려해 AXIOM 분석을 추천한다. 하지만 악성파일 분석과 같은 정적 분석은 AXIOM에서 지원하지 않기 때문에 매뉴얼 분석을 추천한다. 각 행위에 대해 자세히 살펴보면 다음과 같다.

사용자 정보 확인과 같이 특정 정보를 확인하는 것은 분석 준비 단계와 동일하게 AXIOM을 이용해 추출 없이 바로 확인하면 된다. 하지만, 사용자 정보 확인은 예외이다. AXIOM에서는 사용자가 이용하고 있는 계정 뿐만 아니라 시스템이 이용하고 있는 계정(기본 제공 계정) 등 windows 내 모든 계정 정보를 확인 할 수 있다. 따라서 사용자 정보 확인하는 것은 AXIOM을 이용한다면 정확한 정보 확인이 어려우므로, 매뉴얼 분석 방법(직접 추출 후 특정 값 확인)으로 확인하는 것을 추천한다.

특정 정보들을 모두 확인한 후 해당 케이스는 악성파일 다운로드로 인해 PC가 감염된 케이스인 것을 고려해. 악성코드 실행 이력 및 유입 경로를 파악했다.

악성코드 실행 이력을 파악하기 위해 매뉴얼 적으로는 $MFT 파일을 추출한 후 ConsoleHost_history.txt를 이용해 PowerShell 실행 및 명령어 이력을 확인했다. 위 그림처럼 AXIOM에서도 Operating system 항목 내 PowerShell History 항목으로 Powershell 명령어 이력을 확인할 수 있다. PowerShell History 항목을 보면 ConsolHost_history.txt처럼 시간순대로 정렬되어 있다. 이는 사용자가 별도의 설정을 하지 않아도 자동으로 정렬​된다.

케이스 전반적인 내용 소개 때 말한 것처럼 사용자가 PowerShell을 이용해 다운로드 받은 악성코드는 실행 시 추가 악성파일을 생성하는 코드이다. 생성된 악성파일은 서비스에 등록되어 자동 실행된다.

추가 생성되어 자동 실행되는 악성파일을 IDA로 분석해 자동 실행 서비스 등록 및 vmtoolsIO.exe 라는 파일 추가 생성하는 것을 확인했다. 하지만 AXIOM에서는 악성파일에 대한 정적 분석은 지원을 하지 않고 있기 때문에, 관련 분석은 아예 불가능하다.

결론적으로 AXIOM에서는 PC 아티팩트에 대해 상세 분석(ex. PowerShell History)을 많이 지원하고 있다. 이런 점에서 보면 PC에서 일어난 침해사고의 경우 AXIOM을 사용해도 좋을 것 같지만, 악성파일에 대한 추가 행위 및 파일 자체에 대한 분석이 필요하다면 매뉴얼 분석을 하는 것이 더 좋을 것 같다고 판단된다.

Linux 사고 분석 시 차이점

1) 웹서버 대상 공격

케이스의 전반적인 내용은 다음과 같다. 공격자는 서버 침투를 위해 피해 서버의 root 계정에 BruteForce 공격을 수행한다. 이후 피해 서버의 취약점(CVE-2018-7600)을 이용해 Reverse Connection을 연결하는 PHP 코드를 삽입한다. 침투한 피해 서버 내에서 악성파일(리눅스 권한 상승 취약점에 대한 exploit 코드)을 생성해 계정 권한을 탈취하고, update.php 파일이라는 웹 셸을 생성해 거점을 확보한다. 해당 케이스 분석 시 파악된 전반적인 차이점은 아래 표와 같다.

AXIOM에서는 리눅스 분석도 지원하고 있기 때문에, 리눅스 분석 대상의 정보 확인과 같은 분석 준비 단계에서 특정 정보 확인이나 가벼운 분석 정도는 가능하다. 하지만 AXIOM을 이용한 리눅스 사고에 대한 상세 분석은 어렵다. 어려운 이유는 다음과 같다.

첫 번째 PHP파일 및 웹로그 분석을 지원하지 않기 때문에 공격자의 유입 경로 및 공격자와의 연결 방법 등의 내용 파악이 어렵다. 앞서 분석한 케이스 중 '랜섬웨어로 인한 웹서버 감염' 케이스에서 이야기했다시피 AXIOM에서는 웹로그 분석 지원하지 않고 있다. 또한 AXIOM에서는 PHP파일에 대한 분석을 지원하지 않고 있기 때문에, 매뉴얼 분석에서 PHP파일로 확인했던 피해 서버의 취약점을 확인할 수 없다.

두 번째 리눅스 시스템 파일에 대해 상세 분석을 지원하지 않고, .bash_history에서 파악된 삭제 파일에 대해 복구를 지원하지 않기 때문에 악성파일 관련 행위 파악이 어렵다. 보통 삭제된 악성파일의 추가 행위를 확인하기 위해 삭제된 악성파일을 복구한 후 악성파일과 passwd/group, .viminfo 등의 시스템 파일을 함께 분석한다.

매뉴얼 분석 시 .bash_history에서 'rm 37292.c' 명령어를 확인한 후 R-studio를 이용해 삭제된 악성파일을 복구했다. AXIOM에서도 .bash_history로 악성파일 삭제 이력을 확인할 수 있다. 하지만 .bash_history에서 확인되는 각 명령어를 각각의 아티팩트로 인식하기 때문에, 삭제된 악성파일로 인식하고 이에 대한 복구를 지원하지 않는다.

또한, AXIOM에서 앞서 언급한 passwd/group, .viminfo 등의 시스템 파일에 대한 분석을 지원하지 않기 때문에 매뉴얼 분석시 시스템 파일 분석으로 확인한 계정 권한 변경 및 이후 공격 행위에 대해 파악이 불가능하다. 시스템 로그(autho.log)의 경우 AXIOM에서 Operating system 내 Bash/ZSH Sessions 및 System Logs - Linux 항목으로 확인 가능하지만, 윈도우 시스템 로그와 동일하게 상세 분석이 아닌 단순 뷰어 수준으로 보여주고 있다.

결론적으로 AXIOM에서는 리눅스 사고 분석에 필요한 대부분의 아티팩트(ex. PHP파일, 로그, 시스템 파일 등)에 대해 상세 분석을 지원하지 않고 있기 때문에 리눅스 환경 사고를 분석할 때는 매뉴얼 분석으로 하는 것이 더 좋을 것 같다고 판단된다.

결론

본 글에서는 총 4개의 케이스를 분석해 보면서 분석 행위 단위로 매뉴얼 분석과 AXIOM 분석을 비교했다. 비교 결과를 정리해 보면 아래 표와 같다.

침해사고 발생률 증가로 AXIOM도 그에 따라 많은 부분을 지원한다고 하지만, 매뉴얼 분석에 비하면 아직 부족한 부분이 많은 것 같다고 느낀다. 본 글에 나온 추천 방식은 단지 추천일 뿐이지 모든 분석가가 지켜야 하는 지표를 제시하는 것은 아니다. 모든 분석이 동일하겠지만 침해사고를 분석할 때는 좀 더 다양한 방법을 사용해 여러 근거를 토대로 사고 분석을 하는 것이 좋을 것 같다.