[악성코드 분석리포트] Trojan.Android.KRBanker (APKPROTECT)

Trojan.Android.KRBanker (APKPROTECT) - ALYac Division Malware Research

초기 스미싱 악성앱들은 번뜩이는(?) 아이디어에 단순한 코드 작업을 통하여 배포되었습니다. 초기에는 스미싱 악성앱을 발견한 뒤, 백신에 반영되기까지 꽤 오랜 시간이 걸렸는데요. 보안 업체들이 모바일 악성앱에 대해 다소 부족하게 대비했기 때문입니다. (스미싱 관련 포스팅 ▶참고)

 

이 후, 보안 업체들은 스미싱에 대한 대비를 철저히 하여, 스미싱 악성앱들을 빠르게 수집하여 처리할 수 있는 대응체계를 갖추었습니다. 그러자 스미싱 악성앱들도 진화하기 시작했습니다. 초기 스미싱 악성앱에 비해 기능이 확장되었고, 은닉 및 생존율을 높이기 위한 작업이 추가되었습니다. 그리고 분석 시스템들을 회피하기 위해 난독화, 프로텍터, 패커 등이 적용되기 시작했습니다.

이번 분석 보고서에서는 스미싱 악성앱 중 apkprotect로 보호되는 악성앱을 분석하도록 하겠습니다. 우선 안드로이드용 앱들이 사용하는 보호기법들을 살펴보겠습니다. 각 보호기법에 따라 다음과 같이 분류되며, 각각의 특징은 다음과 같습니다.

분석 대상 샘플은 APKPROTECT를 사용하여 DEX 암호화와 코드 내 스트링 암호화를 적용한 버전을 분석했습니다. 해당 버전은 정적 분석을 방해하기 위해 Entry Point 부분의 코드가 암호화 되어 실행되지 않도록 수정되어 있으며, 실행 시 Entry Point 코드가 libapkprotect.so 모듈에 의해 복구됩니다. 그리고 자바 코드 내에서 사용되는 스트링들을 암호화하여 분석을 더욱 어렵게 하고 있습니다.

 

악성코드 분석

※ APKPROTECT 분석

이번 악성코드 분석 보고서는 악성앱의 ‘행위’보다는 악성앱에 적용된 프로텍트의 ‘해제 원리’ 분석을 목표로 작성되었습니다. 패커나 프로텍트가 적용된 악성앱을 분석하기 위해서는, 적용된 패커나 프로텍트를 해제하여 코드나 데이터를 복구하지 않으면 코드 분석이 불가능 하기에 분석을 위해 반드시 복구 과정을 거쳐야 합니다. 

분석 샘플의 정보는 다음과 같습니다.

패키지명 : com.google.xps.gfcfc

MD5 : 4af4bf***29f61847c4a7294bad82***

안드로이드 앱의 분석 절차는 apk파일의 압축 해제를 시작으로 하여, 패키지 내부에 존재하는 각 파일들을 살펴 본 후 매니페스트와 DEX를 디컴파일 하여 코드분석을 진행하도록 하겠습니다.

- APK 분석

 패키지 파일구조 분석

apk는 zip 포맷으로 압축되어 있으며, 압축 유틸리티를 통하여 패키지 내부 구조를 살펴보면 다음과 같은 특징적인 NDK 라이브러리 파일을 찾을 수 있습니다. 라이브러리 파일 이름에서 알 수 있듯,  apk는 apkprotect로 보호되고 있습니다.

libAPKProtect.so는 리눅스용 실행 파일 포맷인 ELF(Excutable Linking Format) 포맷이며 arm용으로 컴파일되어 있습니다. 이는 IDA와 같은 정적 디컴파일러 툴을 이용하여 코드 분석을 수행하거나, 에뮬레이터 또는 실제 디바이스에 앱을 설치하고 동적 디버거를 연결하여 디버깅을 수행할 수 있습니다.

 매니페스트 분석

매니페스트는 앱에서 사용하는 권한과 컴포넌트(액티비티, 서비스, 리시버)를 기술하고 있으며, 앱의 엔트리 포인트 또한 기술하고 있습니다. 매니페스트 분석의 가장 중요한 포인트는 엔트리 포인트를 확인하는 것입니다. 다음 그림은 샘플의 매니페스트 내용 중 일부인데, “application” 태그와 “activity” 태그의 속성 중 android:name이라는 속성을 확인할 수 있습니다. Application에 기술된 속성은 앱의 엔트리 포인트가 실행되기 이전에 호출되는 코드로 주로 앱의 실행에 필요한 데이터의 초기화 등을 담당합니다. 그 다음 activity에 기술된 속성은 앱의 엔트리 포인트이며, 앱 실행 시 최초로 실행되는 코드입니다.

따라서 위의 매니페스트 내용에 따르면 APKPMainAPP1345F 클래스가 com.google.xps.gfcfc.MainActivity 보다 먼저 실행됩니다. 그러므로 코드의 분석 흐름은 APKPMainAPP1345F 클래스를 분석한 후, MainActivity 클래스를 분석하여 이후 호출되는 클래스들 순서로 분석이 이루어 질 것입니다.

 Dex 분석

매니페스트 분석 이후 코드 분석을 위해 dex 파일을 디컴파일하여 코드분석을 진행했습니다. 다음 그림은 디컴파일한 dex의 내용입니다. 

우선 분석 순서에 따라 APKPMainAPP1345F 클래스의 코드를 먼저 살펴보았습니다.

위 그림을 보면 APKPMainAPP1345F 클래스는 APKProtect라는 라이브러리를 로드하는 것 이외에 어떤 작업도 수행하지 않는 것을 알 수 있습니다. 그리고 매니페스트에 기술된 엔트리 포인트인 MainActivity 클래스 분석을 시도하기 위해 클래스를 찾았지만 존재하지 않는 것을 확인할 수 있으며, MainActivity의 inner 클래스인 MyClick이라는 클래스만 존재하는 것을 알 수 있습니다.

엔트리 포인트는 앱이 실행되기 위해서 반드시 존재해야 하는 코드입니다. 위 디컴파일 내용에서는 엔트리 포인트 코드가 감추어져 있다는 것을 알 수 있습니다. (표1에서 볼 수 있듯이 APKProtect는 일부 코드를 암호화하여 실행 시점에 실행 가능 코드로 변경하는 기능이 있다는 것을 알 수 있습니다.) 그리고 실제 코드의 복호화를 담당하는 것이 패키지 분석 시 보았던 libAPKProtect.so 임을 자료 조사를 통하여 알 수 있었습니다. 그러면, 실제 코드 복구를 위해 라이브러리를 분석하도록 하겠습니다.

아래 그림 5는 앱 설치 후 apkprotect에 의해 보호되는 코드의 복구에 대한 개념도입니다. 그림과 같이 DEX의 일부 암호화 코드를 실행 시 복호화 하는 것이 핵심 코드라 할 수 있습니다.

- Libapkprotect.so 분석

앱에서 최초 실행되는 코드인 APKPMainAPP1345F.class 파일의 코드를 살펴보면 libAPKProtect.so 라이브러리를 로드하는 코드만을 확인할 수 있습니다. ELF 포맷의 라이브러리인 libAPKProtect.so는 C++ 코드로 작성되어 arm용으로 컴파일되었습니다. 라이브러리가 로드되면 JNI_OnLoad 함수가 최초로 실행됩니다.

그림 6은 JNI_OnLoad 함수 코드를 보여주고 있습니다. JNI_OnLoad 함수에서 처음 호출되는 ptrace함수는 자신이 디버깅되고 있는지를 확인하는 코드로, 디버깅 되고 있다면 에러가 발생하여 프로세스가 종료되는 anti-debugging 기법이 적용되었습니다. (GDB같은 디버거의 명령어를 이용하여 메모리에 접근하지 못하도록 합니다.)

이제 JNI_OnLoad내에서 호출되는 함수별로 분석해보도록 하겠습니다. 각 함수의 이름은 분석의 편의를 위해 기능에 따라 임의의 이름을 사용했습니다. 그림 7은 코드를 복구하는 코드의 흐름을 간략하게 표현한 개념도입니다.

 Check_dex

Check_dex함수에서는 /proc/self/maps에 접근하여 메모리에 로드된 자신의 덱스 위치를 찾습니다. /proc/self/maps는 현재 시스템에서 실행중인 프로세스들의 정보가 있으며, 메모리에 로드된 실행 이미지의 정보도 포함하고 있습니다. 메모리에서 dex의 위치를 찾는 방법은 mapping된 메모리 주소 공간에서 dex 시그니처 스트링을 검색하여 매핑된 주소를 얻은 후, 매핑된 주소에서 optimized Dex 의 시그니처인 ‘dey’와 Dex의 시그니처인 ‘dex’를 확인합니다. 이렇게 메모리에서 찾은 odex가 자신의 것인지 확인하기 위해서 dex 헤더내에 존재하는 sha-1 시그니처를 비교하여 자신의 odex 파일임을 확인하는 과정을 거칩니다. (odex : omptimize dex)

Odex 찾는 순서를 정리하면 다음과 같습니다.

1. /proc/self/maps에서 메모리 내용 오픈

2. 시그니처인 ‘dey’ 와 ‘dex’를 이용하여 odex파일의 시작위치 탐색

3. 가지고 있던 dex 검증용 sha-1 값을 복호화

4. 탐색된 dex 헤더내의 sha-1값과 비교

복호화하여 나온 값이 자신의 DEX내에 존재하는 sha-1 시그니처 20byte 값과 동일함을 확인할 수 있습니다.

 Check_qemud

Check_qemud 함수에서는 porc/[PID]/cmdline에 접근하여 프로세스 실행을 위해 전달된 명령어 인자를 가져옵니다. 명령어 인자는 실행 대상이 되는 프로세스의 풀 경로를 가지고 있습니다. 이런 점을 이용하여 현재 시스템 상에서 동작하고 있는 프로세스 명을 가져온 후, MD5, CRC 변환으로 특정 프로세스 명을 확인합니다. 확인 결과 /system/bin/qemud이라는 스트링을 탐지하는 것을 알 수 있었습니다. 이런 스트링을 찾는 이유는 현재 앱이 실행되는 환경이 에뮬레이터 인지를 판단하기 위함입니다. Qemud 같은 스트링 발견 시 앱은 그대로 종료됩니다.

 patch_odex

patch_odex 함수에서는 메모리에 올라가있는 odex 파일의 주소를 읽어와서 odex 내용을 패치하는 코드입니다. 패치되는 코드는 실제 파일에 영향을 미치지 않으며, 메모리에서만 적용됩니다. Check_dex에서 찾은 odex의 메모리 위치를 이용하여 암호화되어 있던 엔트리 포인트 코드를 복원합니다. 이 함수는 실제 코드 복원 작업을 하는 것으로 가장 중요한 함수라 할 수 있습니다.

libapkprotect.so의 특정 부분에 코드 패치에 필요한 데이터가 존재하며 패치 시작 주소, 사이즈, XOR 값이 저장되어 있습니다. 아래 그림의 붉은 상자가 패치 시작 주소, 파란색이 사이즈, 녹색이 XOR 값입니다.

코드 복구 전의 MainActivity 코드는 다음과 같습니다. 엔트리 포인트인 onCreate() 메소드가 보이지 않는 것을 확인할 수 있습니다. 

위에서 libAPKProtect.so를 분석한 내용에 따라 코드를 복구했습니다. MainActivity 코드를 살펴 보면 그림 14와 같습니다. 코드의 길이부터 확연하게 차이나며, 결정적으로 엔트릐 포인트 코드인 onCreate 메소드를 확인할 수 있습니다.

※ 스트링 복호화

코드 복구 후 분석을 위해 코드를 살펴보면 특이한 문자열들이 존재합니다. 이런 특이한 문자열을 인자로 받는 메소드를 살펴보면, 스트링 값들을 반환하여 다른 메소드의 인자로 사용되는 것을 알 수 있습니다. 이로 미루어 특이한 문자열들을 정상적인 스트링으로 변환하여 사용하는 것으로 유추할 수 있습니다.

특이 문자열을 인자로 받는 메소드 코드를 살펴보면, 특이 문자열들을 정상적인 문자열로 복호화하여 사용한다는 것을 알 수 있습니다. 그림 14에서는 activeManager라는 메소드를 이용하여 스트링을 복호화하고 있습니다. activeManger 메소드 코드는 그림 15와 같습니다. 

activeManager 메소드와 같이 스트링을 복호화하는 로직은 스트링을 사용하는 클래스마다 메소드 이름만 달리하여 사용하고 있습니다. 

즉 패키지내의 모든 스트링은 암호화되어 있으며, 복호화 로직은 각 클래스별 메소드로 존재합니다. 아래 그림 16은 스트링을 복호화하는 로직의 개념도입니다.

스트링 복호화 후 엔트리 포인트 코드는 그림 17과 같습니다.

※ 악성코드

분석 샘플에 적용된 Apkprotect를 제거한 후, 코드 분석을 수행하여 악성코드의 행위를 분석했습니다. 행위 자체는 기존 KRBanker와 동일합니다.

- 행위 분석

다음 그림은 엔트리 포인트를 시작으로 한 실행 시 코드 흐름입니다. 

 주요 행위는 다음과 같습니다.

1. 설치 뱅킹앱 확인

2. 설치 된 뱅킹앱을 대체할 악성 뱅킹앱 다운로드

3. 정상 뱅킹앱을 악성 뱅킹앱으로 대체

4. 사용자 정보 탈취

5. 문자 탈취

6. 수신전화 차단

악성코드 분석 결론

모바일 악성코드 제작자들은 악성코드의 생존성 및 은닉성을 최대화하기 위해 악성앱에 obfuscator를 넘어 프로텍터와 패커 등을 적용하고 있는 추세입니다. PC 악성코드에서나 적용되던 프로텍터와 패커가 모바일 악성코드에도 본격적으로 도입되고 있는 것입니다.

이번 분석 샘플은 프로텍터 적용 버전 이전엔 분석이 용이하였으나 apkprotect 적용 후 분석이 어려워졌습니다. 이러한 경향은 갈수록 심화될 것으로 판단됩니다. 따라서 obfuscator, 프로텍터, 패커 등에 대하여 지속적인 연구가 이루어져야 하겠습니다.

악성코드 대응방안

Troan.Android.KRBanker과 같은 악성앱의 설치를 막으려면 다음과 같은 조치를 취해야 합니다.

1. 스미싱을 진단할 수 있는 앱 사용

2. 백신을 사용하여 주기적으로 검사

3. 다운받은 파일의 설치 전 백신 검사

4. “알 수 없는 소스” 옵션은 비 활성화 (정상 마켓을 통한 앱 설치 권장)

5. 스마트폰의 구조를 임의로 변경하지 않기