PDF Deflate JavaScript 분석

의심스러운 메일 안에 PDF가 첨부되었을 경우 PDF 내부에 데이터 압축 형태가 있는지 확인이 필요하다.

 

Deflate라는 압축형태를 보통 사용하며, Zlib+LZ77+허프만 결합한 알고리즘을 사용한다.
이런 압축형태를 통해 텍스트 스트림, 이미지데이터 등을 압축하는데 사용 된다.

 

PDF파일 내부를 볼 경우 아래와 같은 형태로 되어있다.

<< /Filter /FlateDecode /Length 1234 >>
stream
<압축된 바이너리 데이터>
endstream

 

실제로도 확인해보자. stream ~ endstream까지 Deflate 압축형태인것이다.

압축 바이너리 시작 위치

 

일단 malcat을 통해 쉽게 추출해 보자.

ZLIB 압축 형태

 

나는 FileInsight 툴을 사용할 것이다. 메소드를 변경하고, Decode를 해주자. 
(한번 눌렀을땐 안됐는데 두번 누르니 정상적으로 Inflate가 된다.)

압축 해제 전

압축 해제 후

 

물론 pdftk 라는 툴을 사용해서 풀어줘도 된다.

https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/

PDFtk - The PDF Toolkit

 

무료 버전 설치하면 설치 폴더 안에 GUI버전 말고 commandline으로 하는 pdftk.exe 파일로 풀어주면 된다.
사용방법은 간단하다. (pdftk.exe 원본.pdf output 출력.txt uncompress)

 

그렇게 inflate로 풀어 주니 아래와 같은 텍스트 형태가 나온다.
텍스트를 압축할때는 이런 Deflate로 압축되서 저장되므로 정상적인 형태이다.

 

악성PDF파일의 경우 쉘코드나 JavaScript 코드가 Deflate로 압축되어있으므로 텍스트를 유심히 봐보자.
압축을 해제하니 15kb 뿐이 안하던 PDF파일이 88MB로 늘어났다.

 

내부에 다수의 자바 스크립트와 암호화 된 텍스트들이 보이는데 당황하지 않고 하나하나 봐보면 된다.

암호화 된 데이터 확인

 

해당 바이트코드를 일단 IDA로 올려보았다. 근데 제대로 해석을 못하는거로 보아 뭔가 변형이 있는 듯 하다.

 

HxD를 통해 바이트코드를 올려보니 아스크코드 상으로 URL로 보이는 것이 나오는데 순서가 뒤죽박죽이다. htt:p// 와 .exe만 봐도 2바이트씩 뭔가 작업이 있는 듯 하는거로 추정할 수 있다.

의심 URL 확인

 

내부 함수에서 해당 바이트코드를 읽는 함수들을 찾아보자.
해당 바이트코드를 읽는 첫번째 함수가 의심된다. 확인해보자.

function kQNt1(hM){
    var ZIjcC = "";  // 최종적으로 반환할 문자열을 저장할 변수
    var i;

    // 1. 배열 `hM`을 순회
    for (i = 0; i < hM.length; i++)
        for (var z = 0; z < hM[i].length - 3; z += 4) {
            // 2. `hM[i]`의 문자열을 4글자씩 끊어서 "%uXXXX" 형식으로 변환
            ZIjcC += ("%u" + hM[i][z] + hM[i][z+1] + hM[i][z+2] + hM[i][z+3]);
        }

    // 3. 마지막 요소(`hM[i]`) 처리
    i = hM.length - 1;
    if (hM[i].length % 4 > 0)  
        // 만약 마지막 요소의 길이가 4의 배수가 아닐 경우, 남은 2글자를 "%XX" 형식으로 추가
        ZIjcC += ("%" + hM[i][hM[i].length - 2] + hM[i][hM[i].length - 1]);

    return ZIjcC;  // 최종 변환된 문자열 반환
}

 

예를 들면, "abcd1234" → "%uabcd" + "%u1234" 이런식으로 변환해주는 함수이다.
%u... 이러한 형태는 보통 Unicode escape encoding을 이용한 특정 데이터의 인코딩 또는 난독화에 사용된다. 

 

%uXXXX 형태는 유니코드 16비트(2바이트) 단위로 저장되는 특성이 있다.
%u06eb -> 0xEB 0x06 (리틀엔디안)으로 메모리에 배치된다.

 

%uXXXX 형태는 보통 JavaScript 기반의 쉘코드 인젝션(예: Heap Spray 기법)에서 사용된다.
0xEB (JMP) 같은 값이 있는 경우, 코드 흐름을 제어하는 Exploit 코드일 가능성이 높다.

 

이걸 이용한다고 파악을 했으니 2바이트씩 끊어서 스왑을 해주는 코드를 짜주자.

def swap_bytes(hex_str):
    # 2바이트씩 나누어 리스트로 변환
    byte_pairs = [hex_str[i:i+2] for i in range(0, len(hex_str), 2)]
    
    # 2바이트(16비트) 단위로 순서 변경
    swapped = [byte_pairs[i+1] + byte_pairs[i] for i in range(0, len(byte_pairs)-1, 2)]
    
    # 변환된 문자열 반환
    return ''.join(swapped)

# 테스트 데이터
bhf = "06eb0000000005ebf9e8ffff5a...6e6e65693172412f646e2e727865ff65"

# 변환 실행
swapped_bhf = swap_bytes(bhf)
print("변환된 bhf:", swapped_bhf)

 

이렇게 변환된 쉘코드를 IDA로 올려보자. 일단 제대로 해석을 못하는 듯 하다.

코드 해석 불가

 

'C' 를 눌러 사용자가 직접 코드 확인을 해보자. 그렇게 하니 해석은 해준다. 아무래도 아까 URL이 보였기 때문에 다운로더 정도로 해석하고 그 이후 악성파일을 분석하면 될 것 같다.

C 단축키로 코드 해석 가능

 

그래도 궁금하다면, 디버기에 쉘코드를 올려서 디버깅해도 좋은 방법이 될 것 같다.