1. 연구 배경 및 문제 제기 (Problem)

• 배경: 안드로이드는 전 세계 모바일 OS 시장에서 가장 널리 사용되며, 이에 따라 악성코드 (Malware) 의 표적이 되고 있습니다. 기존 악성코드 분석 기술은 정적 분석 (Static Analysis) 과 동적 분석 (Dynamic Analysis) 에 의존하지만, 공격자들은 이를 우회하기 위해 다양한 기법을 발전시켜 왔습니다.
• 기존 기법의 한계:
  • 오브퓨세이션 (Obfuscation): 변수명 변경, 문자열 암호화, 리플렉션 (Reflection) 사용 등.
  • 기타 기법: 스테가노그래피 (Steganography), 안티-리패킹 (Anti-repacking), AI 기반 탐지 회피 등.
  • 문제점: 이러한 기존 기법들은 이미 잘 알려져 있어 탐지 도구들이 이를 식별하거나 우회하는 데 익숙해졌습니다.
• 새로운 위협 (WebAssembly):
  • WebAssembly (Wasm) 은 브라우저 환경에서 네이티브에 가까운 속도로 실행되는 이진 포맷으로, C/C++, Rust 등 다양한 언어로 컴파일된 코드를 실행할 수 있습니다.
  • 연구의 핵심: Wasm 은 아직 산업계 표준 악성코드 탐지 도구 (VirusTotal, MobSF 등) 에 의해 충분히 분석되지 않은 "블라인드 스폿 (Blind Spot)"입니다. 공격자가 Wasm 모듈을 악성 로직을 숨기는 오비퓨세이션 수단으로 활용할 경우, 기존 정적 분석 도구들은 이를 탐지하지 못할 가능성이 높습니다.

2. 연구 방법론 (Methodology)

저자들은 안드로이드 환경에서 Wasm 을 실행할 수 있는 세 가지 주요 방식을 규명하고, 이를 악성코드에 적용하는 프로토타입 (Proof-of-Concept, PoC) 을 개발했습니다.

A. 안드로이드에서 Wasm 실행 방식 분석

안드로이드 APK 는 Java/Kotlin 기반이며, Wasm 실행을 위해 다음 세 가지 경로를 사용할 수 있음을 확인했습니다.

1. WebView 기반 실행:
   • 안드로이드 WebView(크로미움 엔진 내장) 를 통해 HTML 페이지에서 Wasm 모듈을 로드하고 실행합니다.
   • JavaScript 와의 브리징을 통해 네이티브 앱과 통신합니다.
   • 특징: 구현이 쉽지만, 브라우저 이벤트 루프와 JS-브릿지 오버헤드가 존재합니다.
2. 자바스크립트 엔진 (Standalone JS Engine) 기반 실행:
   • WebView 없이 APK 내부에 V8 이나 androidx.JavaScriptEngine 과 같은 JS 엔진을 직접 내장합니다.
   • JS 엔진을 통해 Wasm 바이너리를 컴파일하고 실행합니다.
   • 특징: UI 컴포넌트가 필요 없어 더 통제된 환경이지만, 엔진 번들링으로 APK 크기가 커집니다.
3. 네이티브 런타임 (Native Runtime) 기반 실행 (WasmEdge):
   • WasmEdge 와 같은 경량화된 네이티브 Wasm 런타임을 JNI(Java Native Interface) 를 통해 APK 에 직접 내장합니다.
   • Java/Kotlin 코드가 직접 Wasm 함수를 호출합니다.
   • 특징: 가장 효율적이며 오버헤드가 적고, 호스트 (안드로이드) 와 게스트 (Wasm) 간의 인터페이스를 세밀하게 제어할 수 있습니다.

B. 위협 모델 및 PoC 개발

저자들은 두 가지 악성코드 시나리오를 Wasm 을 활용하여 재구현했습니다.

1. 랜섬웨어 (Ransomware):
   • 구현: AES 암호화 로직 전체를 Wasm 모듈 내부에 구현했습니다.
   • 방식: WASI (WebAssembly System Interface) 의 preopen 기능을 사용하여 안드로이드 파일 시스템의 특정 디렉토리를 Wasm 내부 경로로 매핑하고, Wasm 에서 직접 암호화를 수행합니다.
   • 목표: 악성 로직이 DEX 바이트코드에 존재하지 않게 하여 정적 분석을 회피합니다.
2. 스파이웨어 (Spyware):
   • 구현: 파일 읽기 및 네트워크 전송 로직은 안드로이드 네이티브 API 를 사용하되, 악성 URL(Exfiltration 주소) 은 Wasm 모듈 내부에 숨깁니다.
   • 방식: Wasm 모듈이 호스트 (안드로이드) 에 등록된 onHttpPost 함수를 호출하여 데이터를 전송하되, URL 은 Wasm 메모리에서 동적으로 생성됩니다.
   • 목표: 악성 IoC(지표) 인 URL 을 숨겨 정적 분석 도구들이 악성 행위를 식별하지 못하게 합니다.

3. 주요 기여 및 결과 (Key Contributions & Results)

A. 실험 결과 (VirusTotal 및 MobSF 분석)

저자들은 원본 악성코드와 Wasm 을 적용한 변형 코드를 VirusTotal(VT) 과 MobSF 에 제출하여 탐지율을 비교했습니다.

• 랜섬웨어 사례:
  • 원본: 66 개 AV 엔진 중 27 개가 악성코드로 탐지.
  • Wasm 적용 버전: 7 개만 탐지 (탐지율 약 74% 감소).
  • 이유: 대부분의 정적 분석 엔진은 DEX 파일을 분석하지만, Wasm 바이너리 내부의 악성 로직은 분석하지 않거나 악성으로 분류하지 못함.
  • 비교: 기존 오브퓨세이션 도구 (Obfuscapk) 를 사용한 경우 평균 14 개 엔진이 탐지한 것과 대조적으로, Wasm 은 훨씬 더 은밀한 은폐 수단이었습니다.
• 스파이웨어 사례:
  • 원본: 악성 URL 이 포함된 IoC 가 탐지됨.
  • Wasm 적용 버전: URL 이 Wasm 내부에 숨겨져 있어 IoC 가 탐지되지 않음.
  • MobSF 분석: MobSF 는 API 호출 패턴 (파일 읽기, 네트워크 연결) 은 감지했으나, 구체적인 악성 URL 은 Wasm 내부에 숨겨져 있어 식별하지 못했습니다.

B. 주요 결론

• Wasm 은 안드로이드 악성코드의 은폐 (Obfuscation) 에 매우 효과적인 새로운 수단입니다.
• 산업계 표준 도구 (VT, MobSF 등) 는 Wasm 바이너리를 분석하는 데 미숙하여, Wasm 내부에 숨겨진 악성 로직이나 IoC 를 놓치고 있습니다.
• 기존 오브퓨세이션 기법보다 Wasm 을 활용한 기법이 탐지 회피에 훨씬 더 효과적입니다.

4. 방어적 분석 가이드라인 (Defensive Guidelines)

논문은 Wasm 기반 악성코드를 탐지하기 위한 정적 및 동적 분석 가이드라인을 제시합니다.

1. 정적 분석 (Static Analysis):
   • APK 내 .wasm 파일 존재 여부 확인.
   • 네이티브 라이브러리 (예: libwasmedge.so) 검색.
   • Java/Kotlin 코드 내 바이트 배열 (ByteArray) 분석: Wasm 시그니처 (00 61 73 6D) 가 포함된 배열 찾기.
   • Wasm 바이너리를 wabt (wasm2wat, wasm-objdump 등) 도구로 디컴파일하여 내부 구조 및 악성 패턴 분석.
2. 동적 분석 (Dynamic Analysis):
   • Frida 등을 사용하여 Wasm 런타임 API 훅킹 (Hooking).
   • 실행 중 메모리 (Root 환경) 를 inspect 하여 디컴파일된 Wasm 코드 및 명령어 분석.

5. 연구의 의의 (Significance)

• 새로운 위협 인식: Wasm 이 단순한 성능 향상을 위한 기술이 아니라, 안드로이드 생태계에서 악성코드의 은폐를 위한 강력한 도구로 악용될 수 있음을 최초로 실증적으로 입증했습니다.
• 보안 도구 개선 필요성 강조: 기존 모바일 보안 솔루션이 Wasm 바이너리를 "제 1 순위 보안 객체"로 취급하고 심층 분석해야 할 필요성을 제기했습니다.
• 미래 연구 방향: 대규모 자동화 파이프라인을 통한 Wasm 기반 악성코드 탐지 연구, Wasm 런타임 자체의 취약점 분석, 그리고 Wasm 과 안드로이드 간의 인터페이스 보안 강화가 필요함을 강조합니다.

요약: 이 논문은 안드로이드 악성코드가 WebAssembly를 활용하여 기존 탐지 도구 (VirusTotal, MobSF) 를 우회하는 새로운 위협 모델을 제시합니다. Wasm 모듈 내부에 악성 로직을 숨기거나 IoC 를 은닉함으로써 정적 분석을 무력화할 수 있음을 실험을 통해 증명했으며, 이에 대응하기 위한 새로운 분석 기법과 보안 정책의 필요성을 강조하고 있습니다.