악성코드

1주차_capa 규칙

werty2 2026. 3. 16. 22:36

capa 규칙을 활용한 안드로이드 악성코드 탐지

참고 링크: https://cloud.google.com/blog/ko/topics/threat-intelligence/capa-rules-android-malware-detection?hl=ko

 

capa 규칙을 활용한 안드로이드 악성코드 탐지 | Google Cloud 블로그

Android와 Mandiant는 안드로이드 악성코드에서 관찰되는 기능들을 탐지하기 위해 기존 capa 규칙을 개선하고 새로운 규칙을 개발했습니다.

cloud.google.com

 

 

최근 공격자들은 악성코드 탐지를 어렵게 하기 위해 네이티브 코드를 사용하고나 심볼을 제거해 파일을 난독화 하는 등의 다양한 방법을 시도하고 있다. 이러한 문제에 대처하기 위해 Android 보안팀은 오픈 소스 바이너리 분석 도구인 capa를 확장해 안드로이드 대상 파일을 분석하고 있다. 

 

이 때 capa는 입력 파일을 역어셈블한 후 실행 파일이 실제로 어떤 능력을 가지고 있는지를 자동으로 분석해주는 도구이다. 파일을 분석하면 다음과 같은 능력(Capability)을 리스트로 보여준다. 

  • Host Interaction: 파일 복사, 레지스트리 수정, 프로세스 생성 등
  • Communication: HTTP 통신, 소켓 연결 등 (악성코드 여부 판단에 중요)
  • Anti-Analysis: 디버깅을 방해하거나 가상 머신인지 확인하는 기술 등

capa를 설치하기 위해서는 https://mandiant.github.io/capa/  다음 링크에서 설치하면 된다.

 

capa - extract capabilities from executable files

capa recognizes behaviors by matching rules crafted by expert reverse engineers. Rules describe logical combinations of features familiar to human analysts. Things like: API calls, like CreateRemoteThread, integer constants, like 0x100000001b3 = FNV prime,

mandiant.github.io

 

 

공격자들은 불법 도박 앱을 개발해 이를 음악이나 캐주얼 게임과 같은 무해한 외관을 위장시킨다. 이는 특정 지역 시장에서만 도박 포털을 공개하는데, Android 보안 팀이 이와 같은 앱을 탐지하고 차단하는 방법에 대해 알아보겠다.

 

대부분의 심볼이 제거되고 탐지를 피하기 위해 런타임에 로드되는 네이티브 ELF 파일에 주요 동작을 숨기는 음악앱으로 가장한 도박 웹사이트가 있다. 앱을 JEB Decompiler를 이용해 Java 소스 코드로 디컴파일했을 때, MainActivity에는 playSong 함수가 보인다. 이를 통해 앱은 무해한 노래 재생 기능을 하는 것처럼 보인다. 하지만 앱이 초기화되며 onCreate 함수를 호출할 때 ELF 파일을 로드하는 작은 초기화 코드 영역이 보이고 이 파일도 리버스 엔지니어링을 해야한다. 

Ghidra를 이용해 ELF 파일을 C 소스 코드로 디컴파일하면, 시간대 정보를 사용해 사용자의 지리적 위치를 추정하는 코드가 있다는 것을 알 수 있다. 사용자의 위치가 목록에 있는 위치값과 일치하면 악성코드는 원격 서버에서 암호화된 DEX 파일을 다운로드 -> 다운로드한 DEX 파일을 해독 -> 해독된 DEX 파일을 메모리에 로드한다. 로드된 DEX 파일은 서버 측 클로킹 기술을 사용해 사용자에게 도박 웹사이트를 로드한다. 클로킹이란 프로그램이 실행되는 환경이 분석 환경이면 평범한 페이지를 보여주고, 일반 사용자가 특정 헤더를 들고 접속하면 악성 코드가 실행되는 방식이다.

 

아래 그림은 위의 과정을 나타낸 것이다. 

 

안드로이드 보안팀에서는 다양한 안드로이드 악성코드 샘플에서 사용되는 ELF 파일에서 관찰되는 기능 탐지에 중점을 둔 독점 capa 규칙을 만들었다. 독점 규칙은 capa의 오픈 소스 규칙과 함께 악성 코드 기능을 탐지하는 데 사용된다.

독점 규칙:

  • ptrace API 호출 수행
  • Android에서 JNI를 통해 장치 구성 정보 추출
  • Android에서 JNI를 통해 시간대 추출
  • Android에서 JNI를 통해 Base64를 사용하여 데이터 인코딩 또는 디코딩
  • Android에서 JNI를 통해 Cipher API를 사용하여 데이터 암호화 또는 해독

오픈 소스 규칙:

  • 파일 생성 또는 열기
  • Linux에 파일 쓰기
  • Linux에서 파일 읽기
  • Linux에서 파일 권한 확인
  • 스레드 생성
  • Base64 문자열 참조

 

안드로이드 악성코드 분석 ELF 파일들을 디컴파일하면 수천, 수백만 줄의 코드가 포함되어 있다. 이를 빠르게 분석하기 위해 Gemini를 이용하면, 의심스러운 코드 집합에 집중할 수 있다.

위의 도박 앱에서 capa 규칙과 일치하는 함수들을 요약하도록 Gemini에게 다음과 같은 프롬프트를 사용했다고 한다.


당신은 안드로이드 악성코드 분석 전문가인 세계적인 수준의 안드로이드 리버스 엔지니어입니다. 안드로이드 앱의 일부인 ARM/AArch64 ELF 파일에서 몇 가지 함수가 주어졌으며, 디컴파일된 의사 C 코드가 함께 제공됩니다. 당신은 다음을 위해 이 함수들을 분석해야 합니다.
        1. 이 함수들이 무엇을 하려고 하는지 요약합니다.
        2. 이 함수들 중 안드로이드 악성코드에 발견될 수 있는 코드/행동 패턴을 가진 것이 있는지 판단합니다.
{추가 지침...}

이 함수들은 Ghidra에 의해 다음과 같이 의사 C 형식으로 디컴파일됩니다. 
[function_1 내용]
[function_2 내용]

답변에서, 시작 부분에 HIGH / MEDIUM / LOW를 사용하여 위험 수준을 평가하는 전체 평결을 내리고 각 잠재적 악성 행동에 대한 근거를 설명하십시오.

 

Gemini의 이에 대한 응답은 아래와 같다.


평결: 매우 높은 위험(HIGH RISK)
제공된 안드로이드 애플리케이션 코드는 악성 의도를 강력하게 나타내는 여러 가지 우려스러운 행동을 보입니다. 정교한 안드로이드 악성코드 기술과 일치하는 여러 위험 신호의 존재로 인해 위험 수준은 매우 높음(HIGH)으로 평가됩니다. 아래 분석은 관찰된 특정 악성 행동 패턴을 자세히 설명합니다.

1. 동적 코드 로딩 (HIGH): comeOn 함수는 코드를 동적으로 로딩하고 실행하는 패턴을 보여줍니다. 앱은 getCacheFilePathdownloadFile을 사용하여 파일(잠재적으로 DEX 또는 ELF)을 가져온 다음 getDexClassLoader를 사용하여 실행을 시도합니다. 이는 초기 설치 후 악성 페이로드를 전달하는 고전적인 기술로, 악성코드가 기능을 쉽게 업데이트하고 정적 분석을 회피할 수 있도록 합니다. 사용자 정의 복호화(decryptFile, decryptAES)의 사용은 난독화 및 안티 분석 기능을 더욱 강화하며, 로드된 코드의 진정한 성격을 숨기려는 의도적인 시도를 나타냅니다.

2. 사용자 정의 복호화 및 실행 (HIGH): decryptFile 함수는 악성 페이로드를 난독화하기 위해 파일의 사용자 정의 복호화를 수행합니다. 복호화는 AES 알고리즘을 사용하며, 이는 리버싱 프로세스에 복잡성을 더합니다. 동적 로딩과 결합하면 이는 정교한 악성코드 전략을 강력하게 나타냅니다. 복호화된 파일은 디스크에 기록(fopen, fwrite)되고 사용자 정의 클래스 로더를 사용하여 실행됩니다.

3. 시간 기반 은폐 (MEDIUM): thread_function은 시간 기반 은폐를 통합합니다. 사용자 시간대(getTimeZoneInfo)를 확인하고 시간대가 "America/Sao Paulo"가 아닌 경우 행동을 변경할 수 있습니다. 더 중요한 것은, 추가 파일을 다운로드하는 데 사용되는 문자열에 타임스탬프("?time=" + 현재 시간)를 추가한다는 것입니다. 이는 장치의 시간에 따라 행동을 변경하고 잠재적으로 다양한 네트워크 요청을 동적으로 생성하여 분석을 더욱 어렵게 만들어서 탐지를 회피하려는 시도를 암시합니다.

4. 네트워크 은폐 (MEDIUM): thread_function은 추가적인 은폐 행동을 보이지만, 세부 사항은 제한적입니다. 이 함수는 네트워크 리소스와 상호 작용하여 추가 리소스를 다운로드하며, 네트워크 활성 특성을 보여줍니다. 네트워크 작업에 사용되는 데이터는 문자열 조작 및 URL 난독화를 통해 난독화되어 식별 및 분석을 어렵게 만듭니다. 사용된 정확한 은폐 메커니즘은 디컴파일된 코드에서 완전히 명확하지 않지만, 이러한 행동의 존재는 심각한 우려 사항입니다.

5. 난독화 기술 (HIGH): 전체 코드베이스는 광범위한 난독화 기술을 사용합니다. 코드는 복잡한 데이터 구조(데크, 해시 테이블, 트리)와 복잡한 제어 흐름에 크게 의존합니다. 함수 및 변수 이름은 무의미하여 분석을 방해합니다. 여러 겹의 간접 참조와 공격적인 힙 메모리 관리(operator_new, operator_delete)의 사용은 코드를 이해하고 분석하기 어렵게 만듭니다. 이러한 난독화 방법은 리버스 엔지니어링을 회피하려는 악성코드의 전형적인 특징입니다.

6. 디버깅 방지/분석 방지 기술 (HIGH): JNI_OnLoad 함수에는 ptrace(PTRACE_TRACEME, 0, 0, 0) 호출이 포함되어 있습니다. 이는 디버깅 또는 분석 도구를 탐지하려는 시도의 명확한 지표입니다. 디버거가 연결되어 있으면 이 함수의 행동은 달라질 가능성이 높습니다. 충돌하거나 실행을 중단하거나 악성 코드를 숨길 수도 있습니다.

결론:
동적 코드 로딩, 사용자 정의 복호화, 정교한 난독화 및 디버깅 방지 기술의 조합은 악성 활동의 가능성이 높음을 나타냅니다. 여러 사용자 정의 함수의 역할에 대한 불완전한 이해는 위험을 더욱 가중시킵니다. 앱의 행동은 수신된 데이터와 시간에 민감한 요인에 크게 의존하므로 광범위한 악성 행위의 가능성에 대한 심각한 우려를 제기합니다. 이 애플리케이션을 격리하고 추가 조사를 위한 즉각적인 조치를 취해야 합니다. 네트워크 통신, 파일 시스템 조작 또는 기타 악성 활동을 식별하려면 상세한 샌드박스 분석이 중요합니다.

 

Gemini의 이러한 답변은 분석가가 핵심 함수 호출인 getCacheFilePath getDexClassLoader를 쉽게 검사할 수 있도록 하고, 분석가가 악성 페이로드를 신속하게 조사할 수 있도록 하며, 추가 규칙 작성 아이디어를 위해 더 의심스러운 동작 (예: getDexClassLoader JNI 호출, URL 난독화) 을 설명한다.

cf) 참고로 JNI는 자바와 네이티브 언어인 C, C++를 연결해주는 통로 역할을 한다. 대부분의 안드로이드앱은 자바나 코틀린으로 만들어지기 때문에 안드로이드 운영체제는 자바 코드를 감시하는 데 최적화되어 있고, 네이티브 코드는 하드웨어와 더 가깝기 때문에 시스템의 깊은 곳을 건드릴 때 사용된다. 공격자들은 감시를 피하며 더 정밀한 작업을 하기 위해 JNI을 사용해 자바에서 C/C++로 만든 함수를 부른다. 

 

 

분석 대상 악성코드

https://www.exploit-db.com/docs/english/33093-introduction-to-android-malware-analysis.pdf

위의 보고서에 나와있는 방식대로 악성코드(syssecApp.apk) 분석

 

분석 전 준비과정

1. 안드로이드 스튜디오 공식 홈페이지에서 안드로이드 스튜디오 설치 (VirtualBox가 PC를 가상으로 만들어주듯, 안드로이드 스튜디오는 스마트폰을 가상으로 만들어줌)

2. 프로그램 실행 후 Device Manager 클릭 -> Create Device를 누르고 원하는 기기 모델 선택

3. 설치할 안드로이드 버전을 선택 (Google Play 로고가 없는 이미지가 루트 권한을 얻기 더 쉬워서 분석에 용이)

4. 재생 버튼(▶)을 누르면 컴퓨터 화면에 가짜 스마트폰이 뜸

 

분석과정

0. 정적 분석:

  • apktool을 이용해 apk 파일을 리소스 형태로 풀어줌
  • 권한 확인: AndroidManifest.xml 파일(안드로이드 애플리케이션의 상세한 정보 포함, main함수를 찾는 데에도 도움을 줌)을 열어 앱이 요구하는 권한 확인 
  • 코드 변환: Dex2Jar를 사용해 앱의 classes.dex 파일을 .jar 포맷으로 변환 JD-GUIAPKInspector를 통해 자바 소스 코드로 복원한 다음, 저장
  • 저장한 파일 안의 .src 파일의 압축을 풀게 되면 .java 파일들을 볼 수 있다. 그 이후 Eclipse나 intellij로 src 폴더를 보며 정적 분석 시작
  • 주요 클래스 분석:
    • SmsReceiver: "bank"라는 단어가 포함된 문자를 가로채고 알림을 숨기는 로직을 확인할 수 있음
    • Runner: 15초마다 실행되며 데이터를 훔치는 steal() 메서드가 포함된 핵심 악성 클래스

cf) .dex 파일을 풀면 나오는 실제 경로는 아래와 같다.

 

 

1. 악성코드 파일(apk) 설치, 가상환경(에뮬레이터) 화면 위로 드래그해서 설치함

2. 안드로이드 스튜디오 하단 탭의 [Logcat] 클릭 -> 수많은 로그들 중 필요한 부분만 필터링하기 위해 필터링 창에 System.out 등을 입력

3. 설치한 앱 아이콘을 클릭해 실행 -> 화면에는 평범한 미로 게임이 떠야 함

4. 게임을 하는 동안 Logcat 창을 확인해 아래와 같은 문구가 뜨는지 확인

  • 네트워크 연결 시 "Network ok, stealing!" 문구가 출력
  • "dumping sms", "dumping contacts" 등의 메시지와 함께 실제 데이터 수집이 시작됨

5. 마지막에 "Sending data..." 라는 문구와 함께 훔친 정보가 담긴 XML 코드가 로그에 찍히는지 확인, 내 기기의 여러 정보들이 포함되어 있음

6. 이 앱은 127.0.0.1:53471로 데이터를 보내려고 시도함 -> 127.0.0.1은 로컬 호스트 이므로 외부 서버로 데이터가 가지는 않지만, 로그에는 "Sent data to 127.0.0.1:53471" 이라는 성공 메시지가 출력됨

'악성코드' 카테고리의 다른 글

6주차_Jadx(1)  (0) 2026.05.18
5주차_Frida(1)  (0) 2026.05.11
4주차_학습용 악성코드 동적분석  (0) 2026.04.02
3주차_학습용 악성코드 정적분석  (0) 2026.03.29
2주차_악성코드 분석 툴  (0) 2026.03.23