모바일 포렌식을 수행한 적이 있다면 Facebook의 Messenger 앱을 접했을 가능성이 있습니다.익숙하지 않은 분들을 위해 Facebook은 브라우저가 아닌 모든 다이렉트 메시지를 위한 독립형 "메신저" 애플리케이션을 만들어 트래픽[및 비즈니스 모델]을 더 잘 처리하기로 결정했습니다.이 앱은 2017년에 10억 명의 사용자를 달성했으며 그 이후로 꾸준히 증가하고 있습니다(forbes).
일반적인 스마트폰 장치에는 메신저 프로젝트의 코드명인 'com.facebook.katana' 데이터베이스가 포함되어 있습니다.이 로컬 데이터베이스(2018년 7월 기준)에는 수많은 사용자 데이터가 포함된 수많은 테이블이 있습니다.연락처, 메시지 대화, 타임스탬프 등은 모두 조사관이 선택하기에 무르익었습니다.불행히도 Facebook Messenger는 Windows 10 OS에서 그다지 친숙하지 않습니다.
Windows 10 App Store에서 Facebook Messenger에 저장되는 데이터는 무엇입니까?
놀랍게도 이 응용 프로그램은 로컬 및 클라우드 스토리지의 아름다운 조화를 사용합니다.모바일 장치에 있는 데이터베이스와 다소 유사한 데이터베이스를 찾을 수 있을 것이라고 생각하여 이 Windows 앱 개요를 살펴보았습니다.일부 sqlite 데이터베이스 파일 은Windows에 존재하지만 모바일 버전의 파일과 크게 다릅니다.신중한 검색을 통해 간접적으로 가능한 사례 증거로 사용할 수 있는 데이터베이스 파일을 4개만 찾았습니다.fbomnistore.db , orca2.db, p2p_transfer.db 및searchstore.db입니다.
fbomnistore.db:
이 데이터베이스에서 검색할 데이터의 대부분은 사용자 계정 로그 및 앱 세부 정보에 중점을 둡니다.다음 경로에서 찾을 수 있습니다.
이 데이터베이스에 있는 29개의 테이블 중 3개만 우리와 관련이 있습니다.첫 번째는"client_activity_log"입니다.이 테이블은 애플리케이션이 다른 데이터를 '새로고침'한 마지막 시간과 같은 사용자 계정에 대한 애플리케이션 데이터를 표시합니다.가능한 로그 항목에는 연락처/메시지 수집 또는 대기열에 대한 스냅샷을 요청하는 사용자의 클라이언트가 포함될 수 있습니다.조사자는 메시지를 애플리케이션으로 가져온 시간과 애플리케이션이 메시지, 연락처 및 스레드에 대한 업데이트 요청을 마지막으로 실행한 시간과 같은 특정 작업을 추론할 수 있습니다.
"collection_index#"는 연락처, 통화 등을 다루는 테이블 모음의 서문입니다. 조사관은 시스템에서 발생한 전화 통화와 모든 메신저 연락처에 대한 자세한 정보를 볼 수 있습니다.연락처 이름, 친구인 경우, 심지어 Facebook에 연결된 전화번호와 같은 반값 필드를 제공합니다.
"library_metadata"는 이 데이터베이스에서 마지막으로 유용한 테이블입니다.여기에서 특정 작업이 마지막으로 발생한 시간에 대한 항목을 찾을 수 있습니다.여기에는 메시지, 연락처, 통화 및 업데이트에 대한 마지막 확인이 포함됩니다.
p2p_transfer.db:
많은 사람들은 Facebook에 자체 내장형 포인트 투 포인트 결제 시스템이 있다는 사실을 잊습니다.이 테이블 내에서 과거 지불 요청 및 성공적인 거래에 대한 정보를 검색할 수 있습니다.이 데이터베이스의 경로는 다음과 같습니다.
사용자 계정에 대한 모든 지불 요청은 "p2p_requests"테이블에 기록됩니다.여기에서 돈을 요청하는 사람의 Facebook ID, 이 요청과 관련된 ID, 지불을 요청하는 사람 및 완료된 이체에 대해 이체 ID가 표시됩니다.또한 거부/승인된 요청 상태, 예상 통화, 요청 생성 시간 및 업데이트 시간, 요청에 첨부된 메모 및 요청의 url/Facebook 스레드 ID와 함께 표시됩니다.
"p2p_transfers" 는 클라이언트의 사용자 계정이 다른 Facebook ID로 송금한 경우에 대해 동일한 정보를 많이 보유합니다.
orca2.db:
마지막으로 사용자 메시지 처리를 담당하는 데이터베이스에 도착합니다.이 데이터베이스의 경로는 다음과 같습니다.
유감스럽게도 이 데이터베이스 내에서 실제 메시지 내용을 찾을 수 없습니다.Facebook은 사용자의 모든 메시지를 서버에 저장한 다음 "messages" 테이블 내에서 "msg_id"를 할당하여 특정 메시지를 연결하는 것으로 보입니다.고맙게도 테이블은 메시지의 스레드 ID와 타임스탬프를 제공합니다."thread_summaries" 테이블은 한 단계 더 나아가 모든 Facebook 메시지 스레드의 이름, 스레드의 마지막 메시지 타임스탬프 및 그룹의 사용자 지정 이름을 제공합니다.모든 "fbid_from_thread_key" 항목은 URL " www.facebook.com/messages/t/" 끝에 개별적으로 배치하여 메시지 스레드를 직접 열 수 있습니다.*참고로 이 스레드와 해당 콘텐츠를 제대로 보려면 사용자가 Facebook에 로그인해야 합니다.
"folder_type"은 메시지 스레드의 현재 상태를 알려주는 "thread_summaries" 테이블 내의 필드 항목 입니다.지금까지 다음 플래그의 의미를 알아냈습니다.
플래그: 1 = 스레드에 메시지가 있음
플래그: 2 = 메시지가 보류 상태이며 수락 또는 거부되지 않았습니다.
플래그: 5 = 이 스레드에서 보내거나 받은 메시지가 없습니다.
searchstore.db:
내 발견에 따르면 이 데이터베이스는 사용자 계정이 Facebook 사용자를 검색하거나 프로필을 본 경우 모든 인스턴스를 보유합니다.이 데이터베이스의 경로는 다음과 같습니다.
"blob_storage" 및 "search_tokens" 테이블은 이 데이터베이스의 중요한 데이터를 보유합니다."search_tokens"로 이동하면 이 호스트의 계정이 프로필을 검색하거나 방문한 Facebook 사용자의 이름과 관련 fbid를 찾을 수 있습니다.그런 다음 "blob_storage" 테이블로 이동하여 동일한 fbid를 찾아 마지막 검색/프로필 보기의 타임스탬프를 찾을 수 있습니다.
요약:
모바일 장치의 응용 프로그램과 달리 Facebook Messenger의 사용자 콘텐츠와 데이터의 대부분은 클라우드에 저장됩니다.이 메타데이터의 주요 용도는 Facebook에 대한 소환장이 조사에 유용한지 여부에 대한 초기 정당화로 간주됩니다.예를 들어, 소환장을 제출하려는 노력은 메시지가 전송되지 않았다면 소용이 없을 것입니다.또한 이러한 데이터베이스는 포렌식 이미지를 통해서만 또는 시스템의 폴더 구조를 탐색해야만 찾을 수 있다는 점에 유의해야 합니다.Windows는 지속적으로 호출하기 때문에 FTK Imager의 물리적 드라이브 마운트 기능과 같은 특정 상황에서는 채워지지 않습니다.
Apktool은 대표적인안드로이드 애플리케이션(Android Application)대상의리버스 엔지니어링도구입니다. APK 파일을 분석하여 리소스를 뽑아낼 수 있고(디코딩), 코드를 수정하여 다시재빌드(Rebuild)할 수도 있습니다.실제로 XML, 이미지 파일, .dex 파일을 포함하여 안드로이드 앱의 주요 소스를 뽑기 위해 가장 많이 사용되고 있습니다.
이후에 명령 프롬프트를 실행하여apktool이라고 입력하시면, 정상적으로 툴이 실행됩니다.
※ 참고사항 ※
참고로 Apktool은 버전에 따라서 APK 파일을 처리하는 방법이 다를 수 있기 때문에, 가능하면 최신 버전과 가장 많이 사용되는 버전 두 가지를 모두 이용하는 것이 좋습니다. 필자의 경우 최신 버전인Apktool v2.4.1과 더불어Apktool v.2.3.4를 같이 사용합니다. 저는 그래서 다음과 같이 apktool_2.3.4.jar 또한 다운로드 받아서 윈도우 폴더에 위치시킵니다.
이 경우 직접 java를 이용하여 Apktool을 실행하실 수 있습니다.
java -jar C:\Windows\apktool_2.3.4.jar
※ 디컴파일 하는 방법 ※
디컴파일(Decompile)을 위해 하나의 APK 파일을 준비한 뒤에 다음과 같이 명령어를 입력합니다. 여기에서d는 특정한 파일을 디코딩(Decoding)하라는 의미입니다. 공식 문서에서는 Decoding이라는 표현을 쓰고 있네요.참고로-o 옵션을 넣어서 만들어질 소스 폴더의 경로를 설정할 수 있습니다. -o 옵션을 넣지 않으면 자동으로 앱 이름과 동일한 이름의 폴더가 만들어집니다.
apktool d {앱 파일} -o {소스 폴더 경로}
※ 재빌드 하는 방법 ※
소스코드를 수정한 뒤에 다시재빌드(Rebuild)할 때는 다음과 같은 명령어를 입력합니다. 여기에서b는 특정한 폴더를 기준으로 다시 빌드(Build)를 진행한다는 의미입니다. 참고로-o 옵션을 넣어서 빌드 결과로 만들어질 APK 파일의 경로를 설정할 수 있습니다.
apktool b {소스 폴더 경로} -o {앱 파일}
재빌드가 성공적으로 이루어진다면 다음과 같이 APK 파일이 만들어지는 것을 확인할 수 있습니다.
스미싱과 보이스피싱 등을 결합한 형태로 악성 앱들이 유포되고 있습니다. 해당 앱들은 주로 1 금융 관련 앱을 사칭하였으나 최근에는 국가기관, 2 금융 사칭 등으로 다양한 형태로 나타나고 있습니다. 기기 및 개인정보를 탈취하고 금융 정보 탈취를 목적으로 기기의 통화 상태를 감시합니다.
특히, 해당 앱은 분석을 어렵게 하기 위해서 중국 Qihoo 360사의 패킹 기술을 적용하였습니다.
본 분석 보고서에서는 “Trojan.Android.KRBanker”를 상세 분석하고자 합니다.
악성코드 상세 분석
1. 패킹 특징
중국 Qihoo 360사의 패킹 된 앱은 일반 앱과는 다른 부분이 존재합니다. 앱의 권한과 컴포넌트 관련 정보를 볼 수 있는 매니페스트를 보면 일반 안드로이드 앱에서는 볼 수 없는 항목인 “android:qihoo”부분이 추가되어 있는데 이는 디컴파일을 방해합니다. “assets” 폴더에는 파일의 무결성과 동적 패킹에 관여하는 “.appkey”, “libjiagu.so” 파일이 포함되어 있습니다. 또한, 아래 [그림 2]를 보면 패키지명이 “com.android.hellod3”이지만, 패킹 된 덱스 코드에서는 해당 부분을 찾을 수 없어 정적 분석으로는 실제 악성 행위와 관련된 코드를 볼 수 없습니다.
[그림 1] 패킹 된 앱의 구조
[그림 2] 패킹 전 후 덱스코드 비교
2. 안티 디컴파일러
앱 디컴파일에 흔히 쓰이는 “apktool” 최신 버전을 통해서 컴파일을 시도하면 매니페스트의 “qihoo”와 관련된 요소를 찾을 수 없다고 하여 에러를 일으킨다. 앱의 동적 분석을 위해서는 매니페스트에 android:debuggable="true" 항목이 필요한데 이를 방지한다.
[그림 3] 컴파일 실패
3. 안티 디버깅
패킹 앱의 초기에는 안티 디버깅이 포함되어 있지 않아서 메모리에 로드된 덱스 파일을 실시간 덤프를 함으로써 간단히 패킹앱의 분석이 가능했습니다. 그러나 최근 패킹 앱에는 다양한 안티 디버깅 기법이 추가되었기 때문에 동적 분석을 통해서 안티 디버깅을 우회한 다음에서야 메모리에 로드된 덱스 파일 덤프가 가능합니다.
3.1 dlactivity 확인
“/system/linker” 모듈 내부에 존재하는 “dl_rtld_db_dlactivity”의 값은 디버깅 되고 있는지 없는지를 나타냅니다.
[그림 4] dlactivity 활용 안티 디버깅
3.2 TracerPid 확인
“/proc/self/status” 파일을 확인해보면 앱과 관련된 정보들이 나타나있습니다. 그 중에서 “TracerPid”의 값을 통해서 디버깅 여부를 확인할 수 있습니다.
[그림 5] TracerPid 활용 안티 디버깅
3.3 주소 활성화 여부 확인
주소와 포트를 확인하여 디버깅 여부를 확인합니다. IDA를 통해서 안드로이드 원격 디버깅이 가능한데, IDA의 기본 디버깅 주소와 포트의 활성화 여부를 확인하여 디버깅 여부를 확인합니다.
[그림 6] 주소 확인을 통한 안티 디버깅
3.4 특정 문자 확인
“gdb”, “android_server” 등의 동적 디버깅에 사용되는 도구들의 명령어 및 메모리상의 관련 문자열 확인을 통해서 디버깅 여부를 확인합니다.
[그림 7] 명령어 및 메모리 확인을 통한 안티 디버깅
3.5 시간 확인
코드 실행 중간중간에 시간 관련 함수를 추가하여 해당 코드의 실행 시간을 계산하여 디버깅 여부를 확인합니다.
[그림 8] 시간 확인을 통한 안티 디버깅
3.6 덱스 파일 덤프
안티 디버깅을 모두 우회하면 복호화된 덱스 파일은 “libart.so” 모듈에 의해서 메모리로 로드되는데, 이때 덱스 파일이 로드된 메모리 주소와 덱스 파일 구조에 기록되어 있는 덱스 파일의 크기를 계산하여 해당 부분을 덤프합니다. 다음 실제 코드가 담긴 덱스코드를 분석합니다.
[그림 9] 덱스 파일 덤프
4. 덱스 파일 분석
“assets” 폴더에는 “image.zip” 파일이 있는데 내부에는 악성 행위에 사용되는 가짜 통화 관련 사진과 악성 앱을 구성하는 여러 개의 사진 등이 있습니다.
[그림 10] 악성 앱에 사용되는 파일
기기의 아이디와 전화번호를 탈취하여 식별 정보로 사용합니다.
[그림 11] 기기 정보 탈취
기기 부팅 시 서비스를 실행시켜 지속적인 악성 행위를 가능토록 합니다.
[그림 12] 기기 부팅 시 재실행
안드로이드 정책에서는 일정 시간 동안 와이파이를 사용하지 않으면 꺼지게 되는데 이를 방지하여 C&C와의 지속적인 통신을 가능토록 합니다.
[그림 13] 지속적인 와이파이 연결
메시지를 주기적으로 감시하고 탈취하여 C&C 서버로 전송합니다.
[그림 14] 메시지 탈취
주소록을 주기적으로 감시하고 탈취하여 C&C 서버로 전송합니다.
[그림 15] 주소록 탈취
통화 상태를 확인하고 특정 번호를 감시하여 해커에게 연결되도록 하고 사용자를 속이기 위해서 가짜 통화 사진을 팝업합니다.
[그림 16] 통화 탈취
C&C 서버는 “lib” 폴더의 “libmasker.so” 파일 내부의 함수 호출을 통해서 불러옵니다.
[그림 17] C&C 서버
결론
해당 악성 앱은 금융권 앱의 아이콘과 이름을 사칭합니다. 사용자의 기기 및 개인정보를 탈취하고 전화 상태를 확인하여 특정번호를 감시합니다. 통화를 종료하고 해커에게 전화를 자동으로 걸도록 하여 금융 정보를 탈취합니다. 특히, 앱의 분석을 어렵게 하기 위해서 중국의 Qihoo 360의 패킹을 적용했습니다.
따라서, 악성 앱으로부터 피해를 최소화하기 위해서는 백신 앱을 통한 주기적인 검사가 중요합니다. 출처가 불명확한 URL과 파일은 실행하지 않는 것이 기본이고 공식 마켓인 구글 플레이스토어를 통해서 확보한 앱이라도 백신 앱을 추가 설치하여 주기적으로 업데이트하고 검사해야 합니다.
현재 알약 M에서는 해당 앱을‘Trojan.Android.KRBanker’탐지 명으로 진단하고 있습니다.
