2.1. 분석 대상 개요확보한 악성코드는 총 6개이며, 감염 체인 구성에 따라 3개 유형으로 구분할 수 있다. 유형별 단계 구성과 각 단계의 역할은 아래 표와 같다.유형파일명역할TYPE 1smss.exe드로퍼edgsvc.dll로더gsosvc.dat백도어TYPE 2rasgreeng.dll로더bold.dll다운로더TYPE 3ipbootp.dll로더위 표의 단계 구성은 확보한 악성코드로만 재구성한 것으로, 실제 공격에 사용된 전체 감염 체인과는 차이가 있다. 분석 과정에서 확인되지 않은 항목은 다음과 같다.각 유형별 유포 경로 및 초기 침투 악성코드TYPE 1 드로퍼 실행 인자TYPE 2 셸코드TYPE 3 ADS 데이터유형별 특징을 정리한 표는 아래와 같다.항목TYPE 1TYPE 2TYPE 3암호 알고리즘ChaCha20AES-CBC-128AES-CBC-128파일 및 설정 데이터 은닉 위치레지스트리, NTFS ADS(설정 데이터)레지스트리(다운로더, 설정 데이터)NTFS ADS지속성 확보 방식서비스 하이재킹, SSP 등록미확인미확인C&C 통신 방식POST(hash, lang, ei/ie 또는 oq)POST(type, data)미확인전송 데이터 처리 방식ChaCha20 + XOR → Base64AES-CBC-128 → Base64미확인2.2. TYPE 1해당 유형은 드로퍼, 로더, 백도어로 구성되어 있고 최종 백도어는 COPPERHEDGE 변종으로 확인되었다.2.2.1. smss.exe - 드로퍼32비트 Windows MFC 실행 파일로, 내부 프로젝트명은 shayTamir이다. 정상 파일로 보이지만 실행 시 특정 길이의 인자가 전달되면 악성 로직이 실행된다.caption - 파일 정보악성 로직 실행 조건악성코드 실행 시 34자(wide-char)의 인자가 전달되면 악성 로직이 실행된다. 전달된 인자에서 첫 번째와 마지막 글자를 제외한 나머지 글자는 다이얼로그 객체에 저장되며, 이후 오버레이 데이터를 복호화하는 ChaCha20 키로 사용된다.caption - 인자 파싱 루틴34자 인자가 전달되지 않으면 악성 로직은 실행되지 않아 정상 프로그램이 실행된 것처럼 보인다.안티 리버싱 기법악성코드에는 분석을 방해하기 위한 4가지 기법이 적용되어 있다. 적용된 기법은 아래 표와 같다.기법내용효과문자열 암호화모든 민감 문자열을 ChaCha20으로 암호화하였다. 복호화의 경우 하드코딩된 키를 이용한다.문자열 기반 정적 분석 및 시그니처 탐지 회피API 이름 암호화 및 동적 APIAPI 이름은 XOR로 암호화되어 있다. 실행 시점에 복호화되어 API 함수 주소를 동적으로 resolve한다.IAT 은닉으로 Import 목록만으로 기능 추정 불가명령줄 게이트34자 인자가 없으면 악성 로직이 실행되지 않는다.샌드박스 자동 분석 회피(상위 바이너리가 존재하지 않는 경우)드롭 파일명 랜덤 생성 및 바이너리 패딩악성코드가 실행될 때마다 드롭 파일명을 무작위로 생성하고, 60MiB ~ 80MiB의 정크 데이터를 추가한다.파일명, 해시 기반 탐지 회피문자열 복호화에 사용되는 ChaCha20 키, IV, Counter 값은 아래와 같다.ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2ChaCha20 IV: 876543210987ChaCha20 Counter: 255API 이름은 XOR 연산만으로 암호화되어 있으나, 복호화 루틴은 단일 키를 반복하는 형태가 아니다. 복호화에는 아래 세 값을 조합해 한 바이트씩 평문을 구한다.암호화된 이름xor 키 테이블데이터 영역의 바이트 데이터암호화된 이름과 xor 키 테이블은 고정된 값이지만 데이터 영역의 바이트 데이터는 복호화 과정에서 계속 변경된다. 이로 인해 특정 바이트를 복호화하려면 이전 연산이 모두 정확히 수행되어야 한다.caption - api 이름 복호화 로직복호화에 사용되는 xor 키 테이블 데이터는 아래와 같다.0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82(16진수 형태)이 중 06 09 2A 86 48 86 F7 0D 01 01 01은 DER로 인코딩된 rsaEncryption OID의 바이트열과 일치한다. 이는 암호 관련 표준 상수를 본래 용도와 무관하게 사용한 것으로 보인다.드롭 파일명 생성드로퍼는 실행될 때마다 서비스로 실행되는 DLL과 백도어의 파일명을 무작위로 생성한다. 파일명이 고정되어 있지 않으므로 파일명 기반 탐지 규칙으로는 식별이 어렵다. 드롭되는 두 파일의 구성은 아래 표와 같다.확장자설명.dll서비스로 등록되어 실행되는 로더, .dat 파일을 복호화해 메모리에서 실행한다..dat로더에 의해 복호화되어 메모리에서 실행되는 백도어파일명 생성 루틴은 2회 호출되며, 각 자리별로 지정된 알파벳 집합에서 문자를 하나씩 무작위로 선택하되 세 글자가 모두 서로 다르도록 제한한다. 자리별 알파벳 집합은 아래와 같다.첫 번째 자리: [abcdefgmnpsw]두 번째 자리: [abcdefhlmnprs]세 번째 자리: [acefghinoprst]이후 GetTickCount 함수 반환 값의 최하위 비트에 따라 svc 또는 mgr 문자열을 결합하고, 확장자를 붙여 최종 파일명을 완성한다. 이때 동일한 이름의 파일이 이미 존재하는 경우 최대 100회까지 재생성을 시도한다. 분석 과정에서 확인된 파일명은 edgsvc.dll, gsosvc.dat이다. 생성 경로는 C:\Windows\System32이다.caption - 드롭 파일 생성 로직하이재킹 대상 서비스 선정로더 DLL을 svchost.exe가 자동으로 실행하도록 만들기 위해, 새로운 서비스명을 생성하지 않고 netsvcs 그룹에 이름은 등록되어 있으나 실제 서비스 키가 존재하지 않는 빈 슬롯을 찾아 하이재킹 대상으로 삼는다.먼저 암호화된 레지스트리 경로(HKLM\SOFTWARE\Microsoft\Windows NT\currentVersion\Svchost)를 복호화해 해당 경로의 netsvcs 값에서 서비스 목록을 조회한다. 이후 각 항목에 대해 HKLM\SYSTEM\CurrentControlSet\Services\ 키 열기를 시도하고, 열기에 실패한 이름만 수집한다. 마지막으로 수집된 목록에서 rand 함수 반환 값을 이용해 하나를 선택하고 하이재킹한다.caption - 레지스트리 조회 로직로더, 백도어 추출 및 드롭로더와 백도어는 악성코드 오버레이 영역에 암호화 및 압축된 상태로 내장되어 있다.먼저 악성코드에 존재하는 28바이트 마커 34567890ABCDEFGHIJklmnopqrst를 탐색해 오버레이 위치를 식별한다. 이후 인자로 전달된 데이터를 키로 사용해 28바이트 헤더를 ChaCha20으로 복호화하고, 복호화된 첫 4바이트 값이 나머지 6개 DWORD의 합과 일치하는지 확인하는 체크섬 검사를 한다. 이 검사는 전달된 인자가 올바른 경우에만 통과하므로, 인자 값을 모르면 내장된 로더와 백도어를 추출할 수 없다.caption - 검증 로직체크섬 검사를 통과하면 헤더의 오프셋 및 길이 정보를 이용해 데이터 세그먼트 2개를 복호화하고, 각각 C:\Windows\System32 경로에 미리 생성된 파일명으로 저장한다.caption - 파일 생성 로직설정 데이터 구성 및 저장로더는 자신이 복호화해야 할 백도어의 파일명과 복호화 키를 알아야 한다. 이를 위해 두 정보를 레지스트리에 암호화해 기록한다.4,204 바이트의 설정 블롭을 구성해 생성된 파일명 등의 정보를 기록하고, 이를 ChaCha20으로 암호화해 아래 레지스트리 경로에 REG_BINARY 형식으로 저장한다. 이때 %d 형식 지정자에는 파일명 첫 3글자에서 각각 0x60을 뺀 값을 대입하고, 레지스트리 기록에 성공하면 다이얼로그 플래그를 1로 세팅한다. 확인된 레지스트리 경로는 아래와 같다.레지스트리 경로: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\USB_Keyboard_547caption - 레지스트리 경로 생성 로직설정 데이터 구조는 아래 표와 같다.설정 데이터는 다른 감염 사례에서 확인하였다. 레지스트리 값, 로더명, 백도어명이 본 보고서에서 언급되는 것과 다르다.그러나 설정 데이터에 있는 백도어 ChaCha20 키를 이용해 다음 단계 복호화가 가능하였다.오프셋크기타입필드값+0x0004DWORDC&C URL 개수5+0x004260ASCIIC&C URL[0]hxxps://f****.com/include/security.asp+0x108260ASCIIC&C URL[1]hxxp://1*****2/default.php+0x20C260ASCIIC&C URL[2]hxxp://1*****7/default.php+0x310260ASCIIC&C URL[3](=URL[1] 중복)hxxp://1*****2/default.php+0x414260ASCIIC&C URL[4](=URL[2] 중복)hxxp://1*****7/default.php+0x5184DWORD직접 IP 연결 모드 플래그0(비활성)+0x51C4in_addrC&C 직접 IP0+0x5202WORDC&C 포트0+0x5224DWORD연속 접속 실패 허용 횟수5+0x5264DWORD논리 드라이브 변경 감시 스레드 사용 여부0+0x52A4DWORD터미널 세션 변경 감시 스레드 사용 여부0+0x52E4DWORD자가 보호 사용 여부0(미사용)+0x5322WORD재접속 대기 시간(분)60(0x3C)+0x5348double활성화 대기 시각(VARIANT time)45709.45 → 2025-02-21 10:48:01+0x53C32UTF-16로더 DLL명bhamgr.dll+0x55C32UTF-16백도어 페이로드명(.dat)wchmgr.dat+0x57C32UTF-16C&C 보고 식별자uploadmgr+0x59C32-0x2026 명령 응답에 포함되는 필드(용도 미상)0+0x5BC4DWORD동작 모드(설정 로드 직후 현재 모드 값으로 덮어씀)5+0x5C032ASCII백도어 ChaCha20 키GX152-6M2V9Z-16KIPG-KAJRE4-PR376+0x5E04-(0)-+0x5E4520UTF-16명령 실행 셸 경로c:\windows\system32\cmd.exe+0x7EC520UTF-16명령 결과 임시 파일 생성 경로(비어있음, 미설정 시 %TEMP% 사용)+0x9F4520UTF-16PNG 파일 경로 0(비어있음)+0xBFC520UTF-16PNG 파일 경로 1(비어있음)+0xE04 ~ +0x100C--0x00 패딩/예약-+0x100C32bytesPNG 모듈 복호화 키 0(0xBD-XOR 저장)00 00 AC 23 00 00 00 00 70 23 00 00 00 00 78 23 38 DF 3F 7C 06 00 00 00 00 00 10 7C B8 DF 4D 82+0x102C32bytesPNG 모듈 복호화 키 1동일 값+0x104C ~ +0x106C--0x00 패딩(끝)-서비스 등록 및 실행위 과정에서 다이얼로그 플래그가 1이 되면 SCM API를 이용해 서비스를 등록하고 실행한다. 과정은 다음과 같다.CreateServiceW로 서비스를 생성하고, ImagePath는 %SystemRoot%\system32\svchost.exe -k netsvcs로 지정해 공유 프로세스 방식으로 동작하게 한다.ChangeServiceConfig2로 서비스 설명과 복구 옵션을 설정한다. 실패 시 120초 지연 후 자동 재시작하며, 실패 카운터는 24시간 주기로 초기화된다.HKLM\SYSTEM\CurrentControlSet\Services\ \Parameters\ServiceDll 값에 드롭한 DLL 경로를 REG_EXPAND_SZ 형식으로 기록한다.StartService로 서비스를 실행한다.이로 인해 시스템 부팅 시마다 로더가 자동으로 실행되며, 서비스가 비정상 종료되더라도 복구 설정에 의해 재시작된다.2.2.2. edgsvc.dll - 로더edgsvc.dll은 하이재킹된 서비스로 등록되어 실행되는 로더이다. 앞 단계인 드로퍼와 동일하게 API를 실행 시점에 해석해 IAT를 은닉하고, 레지스트리에 저장된 설정 데이터를 복호화해 백도어 파일 경로와 복호화 키를 획득한다. 백도어는 리플렉티브 로딩 방식으로 메모리에서 실행한다.API 이름 암호화 및 동적 APIAPI 이름은 xor 연산만으로 암호화되어 있으나, 복호화 루틴은 단일 키를 반복하는 형태가 아니다. 복호화 함수는 분기와 호출 없이 약 8,960개 명령으로 구성되어 있다. 복호화에는 아래 세 값을 조합해 한 바이트씩 평문을 구한다.암호화된 이름xor 키 테이블데이터 영역의 바이트 데이터암호화된 이름과 xor 키 테이블은 고정된 값이지만 데이터 영역의 바이트 데이터는 복호화 과정에서 계속 변경된다. 이로 인해 특정 바이트를 복호화하려면 이전 연산이 모두 정확히 수행되어야 한다.caption - api 이름 복호화 로직복호화에 사용되는 xor 키 테이블 데이터는 아래와 같다.0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82(16진수 형태)이 중 06 09 2A 86 48 86 F7 0D 01 01 01은 DER로 인코딩된 rsaEncryption OID의 바이트열과 일치한다. 이는 암호 관련 표준 상수를 본래 용도와 무관하게 사용한 것으로 보인다.설정 데이터 조회 및 복호화먼저 악성코드에 하드코딩된 ChaCha20 키와 IV로 레지스트리 서브키 문자열과 값 이름을 각각 복호화한다. ChaCha20 키와 IV는 드로퍼가 사용하는 것과 동일하다.ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2ChaCha20 IV: 876543210987ChaCha20 Counter: 255복호화된 서브키 문자열에는 드로퍼와 동일하게 %d 형식 지정자 3개가 포함되어 있으며, 로더 파일명의 첫 3글자에서 0x60을 뺀 값이 대입되면 최종 경로가 완성된다.최종 레지스트리 경로: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\USB_Keyboard_547레지스트리 경로에서 암호화된 설정 데이터(4,204바이트)를 읽어 ChaCha20으로 복호화한다. 복호화된 설정 데이터에서 추출하는 정보는 아래 2가지이다.백도어 파일명백도어 복호화용 ChaCha20 키caption - 설정 데이터 복호화 및 추출 로직로더는 서로 다른 2개의 ChaCha20 키를 사용하고, 획득 경로가 상이하다. 상세 정보는 아래 표와 같다.용도출처비고레지스트리 경로, 값 이름, 설정 데이터 복호화바이너리에 하드코딩IV는 876543210987(드로퍼가 사용하는 ChaCha20 IV와 동일)백도어 복호화설정 데이터에서 추출바이너리에 존재하지 않는다. 레지스트리에 기록된 설정 데이터 없이는 백도어 복호화 불가백도어 복호화 및 실행위 과정에서 백도어 파일명과 백도어 복호화용 ChaCha20 키를 추출하였으므로 먼저 C:\Windows\System32 문자열과 백도어 파일명을 결합해 전체 경로를 구성한다. 이후 파일 데이터를 읽어 백도어 복호화용 ChaCha20 키를 이용해 복호화한다. 만약 복호화 과정에서 키 인자가 전달되지 않은 경우 하드코딩된 키를 사용하도록 구현되어 있다. 확인된 복호화 키는 아래와 같다.백도어 복호화용 ChaCha20 키: GX152-6M2V9Z-16KIPG-KAJRE4-PR376caption - 복호화 키 설정 로직복호화된 백도어는 파일로 생성되지 않고 자체 구현된 PE로더 로직을 통해 메모리에서 실행된다. 단계는 다음과 같다.MZ 및 PE 시그니처 탐색 및 검증메모리 할당 이후 헤더와 섹션 데이터 복사베이스 재배치 및 임포트 테이블 해석섹션별 메모리 보호 속성 적용TLS 콜백 실행엔트리포인트 호출2.2.3. gsosvc.dat - 백도어로더에 의해 메모리에서 실행되는 백도어로, 해당 백도어는 COPPERHEDGE 변종으로 확인되었다.동작 모드 조건DllMain 함수 실행 시 ChaCha20으로 프로세스명 2개(lsass.exe, svchost.exe)를 복호화한 뒤, 현재 프로세스명 및 로드된 DLL명 길이와 비교해 동작 모드를 결정한다. 복호화에 사용되는 ChaCha20 키, IV는 드로퍼 및 로더와 동일하다.ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2ChaCha20 IV: 876543210987ChaCha20 Counter: 255전체 동작 모드의 동작 조건과 설명은 아래 표와 같다.모드동작 조건설정 저장자가 보호0외부 로더가 설정한 경우저장 없음없음1프로세스가 lsass.exe인 경우HKLM 레지스트리로더, 백도어 데이터를 전역 변수에 저장한 뒤 로더와 백도어, 설정 데이터 삭제2프로세스가 svchost.exe이고 DLL명이 10자 이하인 경우HKLM 레지스트리로더, 백도어 데이터를 전역 변수에 저장한 뒤 로더와 백도어, 설정 데이터 삭제3외부 로더가 설정한 경우NTFS ADS 파일없음4프로세스가 lsass.exe, svchost.exe가 아닌 경우HKLM 레지스트리로더, 백도어 데이터를 전역 변수에 저장한 뒤 로더와 백도어, 설정 데이터 삭제5프로세스가 svchost.exe이고 DLL명이 10자 초과인 경우HKLM 레지스트리로더, 백도어 데이터를 전역 변수에 저장한 뒤 로더와 백도어, 설정 데이터 삭제모드 1은 악성코드가 SSP(Security Support Provider)로 lsass.exe에 로드된 상태이고 모드 3은 설정 데이터를 %LOCALAPPDATA%\Microsoft\Internet Explorer\brndlog.txt:loginfo ADS에 저장한 형태이다.모드 값은 프로세스명 매칭 결과로만 1, 2, 4, 5 중 하나로 결정되고 모드 0, 3은 별도의 외부 로더가 컨텍스트(모드 필드, 설정 포인터)를 직접 구성해 실행한 방식에서만 사용된다. 본 보고서에서는 동작 모드가 2 또는 5인 경우에 대해 설명한다.지속성 확보위 과정이 완료되면 중복 실행 방지를 위해 뮤텍스를 생성하고 지속성을 확보한다. 뮤텍스명은 아래와 같다.뮤텍스명: MsSecurityObjcaption - 뮤텍스 설정 로직지속성은 SSP 등록을 통해 확보한다. HKLM\SYSTEM\CurrentControlSet\Control\Lsa경로의 Security Packages 값에 로더 파일명을 추가하고, 이때 System32 경로의 reg.exe를 이용해 기존 Security Packages 값을 읽어 기존 항목을 64자 단위로 그대로 보존한 채 로더 파일명만 목록에 추가해 REG_MULTI_SZ 값을 재구성한다. 이후 시스템 부팅 시 lsass.exe가 SSP로 등록된 DLL을 자동으로 로드한다.caption - 레지스트리 값 작성 로직자가 보호 루틴모드 1, 2, 4, 5에서는 초기화 과정에서 자가 보호 루틴이 실행된다. 먼저 설정 데이터가 담긴 레지스트리 값을 삭제하고, 로더와 백도어 데이터를 각각 메모리에서 읽은 뒤 로더와 백도어를 삭제한다. 이후 콘솔 컨트롤 핸들러를 등록해, 시스템 종료 이벤트 발생 시 메모리에 저장 중인 로더와 백도어 그리고 설정 데이터가 복원되도록 설정한다.caption - 메모리 저설정 데이터는 이미 메모리에 존재하므로 따로 읽지는 않는다. 또한 복원 시 로더는 파일 데이터에 64MiB ~ 80MiB 정크 데이터가 추가된 상태로 복원된다. 설정 파일은 기존 레지스트리 경로에 복원된 후 SSP를 재등록한다.시스템 정보 수집컴퓨터명, 사용자명, 네트워크 어댑터의 IPv4 주소, OS 제품명, ANSI 코드 페이지를 수집한다. 또한 현재 동작 모드도 수집하며 컴퓨터명과 CPU 모델명을 결합한 데이터의 CRC32 값을 시스템 식별 값으로 생성한다. 이후 자신의 실행 경로를 획득해 해당 디렉토리를 작업 디렉토리로 설정한다.caption - 시스템 정보 수집 로직C&C 서버 통신설정 데이터에 포함된 C&C 서버 URL에 대해 요청을 전송한다. 확인된 C&C 서버 URL은 총 3개로 모두 국내 서버이다.hxxps://f*****.com/include/security.asphxxp://1*****.2/default.phphxxp://1*****.7/default.phpC&C 서버 SSL 적용 여부에 따라 통신 시 사용하는 파라미터 구성이 상이하다.SSL: hash= &lang=T3F56E5UJH0JC3D4&ei= &ie= Non-SSL: hash= &lang=T3F56E5UJH0JC3D4&oq= 통신 데이터는 12바이트 헤더와 가변 길이 페이로드로 구성되며, 헤더 구조는 아래 표와 같다.오프셋크기항목+02랜덤 값+22명령 ID+44완료 플래그+84페이로드 크기통신 데이터와 헤더는 각각 ChaCha20 및 XOR로 암호화된 후 Base64로 인코딩되어 URL 파라미터에 연결된다. 첫 통신 시 C&C 서버의 응답이 전송한 hash 파라미터 값과 일치하는지 검증하며, 불일치할 경우 연결을 종료한다.caption - 응답 데이터 검증 로직명령 수신 루프는 먼저 hash= 값과 명령 ID 0x2047로 폴링 요청을 전송한다. 이후 기존 hash 파라미터 값과 함께 C&C의 명령 데이터를 수신하면 명령 ID에 따라 핸들러를 호출하며, 명령 실행 결과를 기존 hash 파라미터 값과 함께 전송한 후 다시 값으로 폴링한다.확인된 명령 코드는 총 30개로 상세 동작은 “부록 C. 명령 코드” 참고 바란다.추가 모듈 로드 및 인젝션실행 중 반복적으로 설정 데이터에 저장된 2개의 PNG 파일 경로에서 은닉된 추가 모듈 데이터를 읽어와 복호화한 뒤 explorer.exe에 인젝션해 실행한다. 다만 분석된 설정 데이터에는 PNG 파일 경로가 기록되어 있지 않았다.복호화 과정은 다음과 같다.각 32바이트 블록에 대해 i = 31부터 0까지 역순으로 순회하며, key[i] 값을 12로 나눈 나머지가 0이 아닌 경우에만 아래를 수행한다.교환 위치 j = (key[i] % 12 + i) % 32를 산출한 뒤, block[i]와 block[j]를 교환한다.교환 후 block[i](원래 block[j]에 있던 값)를 key[i]와 XOR한다.복호화에 사용되는 키는 설정 데이터(+0x100C)에 각 바이트가 0xBD와 XOR된 형태로 저장되어 있으며, 이를 XOR해 원본 키를 복원한다. 원본 복호화 키는 아래와 같다.원본 복호화 키(16진수 형태): BD BD 11 9E BD BD BD BD CD 9E BD BD BD BD C5 9E 85 62 82 C1 BB BD BD BD BD BD AD C1 05 62 F0 3F2.3. TYPE 2해당 유형은 로더, 다운로더, 셸코드로 구성되어 있으나 셸코드는 확보하지 못하였다.2.3.1. rasgreeng.dll - 로더해당 로더에는 ES-Computing의 유효하지 않은 인증서로 서명이 적용되어 있다.항목값SubjectC=KR, ST=Gyeongsangnam-do, L=Jinju-si, O=ES-Computing, OU=IT Team, CN=ES-ComputingIssuerthawte SHA256 Code Signing CASerial Number13F8F43FFAFEAD5F5EA8C0D259C2D0E6Thumbprint(SHA1)2E1DD779B28F86B5766C08245B86E37E9C5E4937Thumbprint(SHA256)76C71C03440826ADF26F4C35C36B97343ADCFF6A48188393EDD375F9A7289F14유효기간2019-02-14 ~ 2020-05-15(만료)레지스트리 조회 및 복호화특정 레지스트리 경로에 존재하는 다운로더와 설정 데이터를 읽어 복호화한다. 레지스트리 경로는 평문으로 존재하고, 각 레지스트리 경로에 대한 설명은 아래 표와 같다.레지스트리 경로설명HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts\GiddyupStda Bold암호화된 다운로더 데이터HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts\GiddyupStda암호화된 설정 데이터(C&C 서버 URL 포함)암호화된 다운로더 데이터는 AES-CBC-128로 복호화한다. 복호화에 사용되는 키와 IV는 아래와 같다.AES 키: g2Oc6qWRU3n.B0PmAES IV(16진수 형태): 00000000000000000000000000000000caption - 레지스트리 조회 및 복호화 로직암호화된 설정 데이터는 로더에서 복호화하지 않고 다음 단계인 다운로더에서 복호화한다.다운로더 실행 및 인자 전달복호화된 다운로더를 메모리에서 실행하는데, 이때 다운로더의 DllMain 함수를 호출하면서 AES 키와 암호화된 설정 데이터를 인자로 전달한다.caption - 메모리 실행 로직2.3.2. bold.dll - 다운로더네임드 파이프 생성DllMain 함수가 호출되면 네임드 파이프를 생성한다. 이때 파이프 이름은 다음 단계를 통해 생성된다.D9hWnVEqdgzJ673B8euS 문자열에서 무작위 인덱스 문자 2개를 골라 서로 위치를 교환한다.위 과정을 201회 반복한다.\\.\pipe\ 형식으로 최종 이름을 조합한다.caption - 파이프 생성 로직C&C 서버 통신인자로 전달받은 암호화된 설정 데이터를 함께 전달된 AES 키로 복호화해 C&C 서버 URL을 추출한다. 확인된 C&C 서버 URL은 아래와 같다.hxxps://d*****.com/lgdacom_mobile/lgdacom.asphxxps://www.l*****.co.kr/lib/asp/include_view.asp통신을 시도하기 전에 각 C&C 서버 URL별로 실제 통신 가능 여부를 먼저 확인한다. 먼저 봇 ID를 4바이트 rand 함수 반환 값으로 생성한 뒤 type= &data=8Rvi4-UPMQvFgjMJ3cZF 형식으로 파라미터를 구성해 POST 요청을 전송하고, 응답이 로 시작하는지 확인해 활성 여부를 판단한다.caption - 통신 가능 여부 확인 로직활성으로 확인되면 데이터를 수신한다. 이때 type=cisco 형식으로 POST 요청을 전송해 C&C 서버로부터 데이터를 수신한다. 응답 데이터의 앞 15바이트가 로 시작하면 나머지 데이터를 복호화한다. 복호화는 응답 데이터의 공백 문자를 +로 치환하고 Base64로 디코딩한다. 이후 AES-CBC-128로 복호화한다.caption - 응답 데이터 복호화 로직복호화된 데이터는 10바이트 헤더와 실제 데이터로 구성되며, 헤더 구조는 아래 표와 같다.오프셋크기항목+02명령 코드+24데이터 크기+64종료 플래그(수신 완료·루프 종료 신호)+10-실제 데이터이때 수신한 명령 코드가 60(0x3C) 이하이면 오프셋 10부터의 데이터를 셸코드 실행 함수로 전달한다. 셸코드 실행 시에는 파이프 이름, 복호화된 설정 데이터, 다운로더의 상태 정보 등을 함께 전달한다. 셸코드 실행을 마친 뒤, 방금 실행한 명령 코드가 19(0x13)이고 실행 결과가 0이면 통신 루프를 정상 종료한다. 추가로 크기가 큰 셸코드의 경우 헤더의 종료 플래그가 설정되고 누적 수신량이 전체 크기에 도달할 때까지 type=cisco 요청을 반복해 분할 수신한다.수신한 명령 코드가 60(0x3C)을 초과하는 경우에는 셸코드를 실행하지 않고, 명령 코드 24(0x18)와 플래그 1로 확인 응답만 전송한 뒤 다음 명령을 대기한다.caption - 셸코드 실행 로직파이프 데이터 송신네임드 파이프 스레드는 메인 C&C 통신 루틴과 별도의 스레드로 생성되어, 파이프를 통해 전달되는 데이터를 C&C 서버로 전송한다. 데이터 앞 10바이트에 수신 시와 동일한 구조의 헤더를 추가하고, 수신 데이터 복호화에 사용한 것과 동일한 키로 AES-CBC-128 암호화를 한다. 최종적으로 암호화된 데이터를 Base64로 인코딩해 type=article&data= 형식으로 POST 요청을 전송한다.caption - 파이프 데이터 송신 로직C&C 서버에서 다운로드하는 셸코드는 확보하지 못해 이후 과정은 분석할 수 없었다.2.4. TYPE 32.4.1. ipbootp.dll - 로더해당 로더는 자기 자신의 ADS에 저장된 암호화된 DLL을 복호화해 메모리에서 실행한다.API 이름 암호화 및 동적 APIAPI 이름은 AES-CBC-128로 암호화되어 있다. 복호화에 사용되는 키와 IV는 하드코딩되어 존재한다.AES 키(16진수 형태): CE F6 E7 9D D1 F2 C6 1B 5F 26 5D A1 7D 73 A2 15AES IV(16진수 형태): CD 85 ED 5E 75 20 CB 3F 98 3E 6B 7F DA 53 71 1DADS 페이로드 추출 및 실행ADS 관련 문자열도 AES-CBC-128로 복호화된다. ADS 관련 문자열은 아래와 같다.:dat, :kgb자기 자신의 ADS에서 암호화된 페이로드와 복호화 키를 추출한다. 각 ADS 경로는 아래 표와 같다.ADS 경로내용 :dat암호화된 페이로드 :kgbAES 키 16바이트 + IV 16바이트:kgb의 첫 16바이트가 AES 키이고 다음 16바이트가 IV이다. 이후 AES-CBC-128로 암호화된 페이로드를 복호화한다. 복호화된 페이로드는 파일로 생성되지 않고 자체 구현된 PE로더 로직을 통해 메모리에서 실행된다. 단계는 다음과 같다.MZ 및 PE 시그니처 탐색 및 검증메모리 할당 이후 헤더와 섹션 데이터 복사베이스 재배치 및 임포트 테이블 해석섹션별 메모리 보호 속성 적용TLS 콜백 실행엔트리포인트 호출ADS는 확보하지 못해 이후 과정은 분석할 수 없었다.

엔키화이트햇 위협연구팀은 2025년부터 2026년 초까지 국내 기업 그룹웨어 개발사의 내부망에 침투해 측면 이동 및 고객사 침투를 시도한 북한 배후 공격 그룹 Kimsuky의 공격 사례를 추적하였다. 분석 결과, 공격자는 취약점 악용, 스피어피싱 등의 초기 침투 경로를 통해 외부망과 연결된 서버의 제어권을 확보하고, Gomir 및 다양한 변종 악성코드를 설치하였다.공격자는 구글 드라이브를 C&C 서버로 악용하거나, 새로운 커스텀 프로토콜을 구현하는 등 (Gomir) 악성코드의 통신 방식을 대폭 변경하여 탐지 회피를 효과적으로 시도하였다. 또한 침해한 그룹웨어 개발사의 제품을 사용하는 고객사 서버에 직접 침투하였으며, 그룹웨어 로그인 페이지를 변조해 임직원들의 계정 정보를 유출하는 등 적극적인 측면 이동을 시도하였다.본 보고서는 공격에 사용된 Gomir, BirdTroy, DriveTroy를 탐지할 수 있는 탐지 스크립트 및 YARA Rule 을 함께 제공한다.

엔키화이트햇 위협연구팀은 2026년 상반기 북한 배후 공격 그룹 Kimsuky의 대한민국 군·기업 관계자 대상 악성코드 유포 사례를 식별하였다.분석 결과, Webex 사칭 공격 사례에서 최종 페이로드인 HttpSpy 변종의 전체 실행 체인이 확인되었다. 기존 HttpSpy가 단일 바이너리로 동작했던 것과 달리, 본 변종은 설치 과정이 3단계로 분리되었다. 보안프로그램 위장 공격 사례에서는 다운로더 단계까지만 확인되었으나, 동일한 RC4 키·인프라·코드 패턴을 공유하여 같은 위협 행위자의 공격으로 판단하였다.Kimsuky는 가짜 웹페이지에 JSONP 통신 기능을 추가해, 악성코드가 피해 시스템에 구축한 로컬 서버와 통신해 실행 여부를 확인하고, 미실행 시 설치를 유도하였다. (JSONPing, 섹션 4.4. 참조) 또한, Kimsuky가 이미 침해한 것으로 추정되는 피해자의 미팅 일정 정보를 활용해 가짜 미팅 페이지를 제작하고, 다른 미팅 참가자들에게 악성코드를 유포한 정황도 확인되었다.