RoKRAT 셸코드 및 스테가노그래피 기반 위협 분석과 EDR 대응 방안

◈ 주요 결과 (Key Findings)

APT37 그룹의 RoKRAT 악성파일의 새로운 형태 등장
암호화된 Shellcode 방식을 2단계로 삽입해 분석 방해 시도
사진파일 속에 악성코드를 숨기는 스테가노그래피 기법 발견
보안 제품의 탐지를 회피하기 위한 Fileless 공격 지속적 수행
단말 이상행위 탐지에 최적화된 효율적 EDR 관제 시스템 구축 필요

1. 개요 (Overview)

지니언스 시큐리티 센터(Genians Security Center / GSC)는 APT37 그룹이 사용하는 악성파일을 분석 중에 새로운 형태를 발견했습니다. 보통 이들이 주로 사용하는 것은 일명 'RoKRAT' 이름으로 불립니다. 해당 위협 행위자(Threat Actor)는 LNK 확장자를 가진 바로가기(Shortcut) 파일 내부에 'Cmd' 또는 'PowerShell' 명령어를 넣어 공격에 활용하고 있습니다.

현재 이 공격은 한국에서 계속 관찰될 정도로 위협 활성도가 높음을 유지하고 있습니다. 그 만큼 효과적인 공격수단으로 볼 수 있습니다. 따라서 다수의 업무용 단말을 보유한 기업이나 기관의 보안 관리자들은 해당 위협에 대한 다양한 공격유형과 기술에 대해 꾸준히 파악할 필요가 있습니다.

바로가기 파일의 기본 아이콘에는 작은 화살표가 포함돼 있어, 어느정도 육안 구별이 가능합니다. 물론, 사용자가 직접 만든 바로가기 폴더나 파일은 대부분 정상이므로 절대 오해해서는 안됩니다. 만약, 이메일 첨부파일이나 SNS 등의 메신저로 받은 압축파일 내부에 바로가기 파일이 있다면, 그것은 십중팔구 악성코드일 가능성이 높습니다. 이처럼 보안 책임자는 최신 위협의 유입과정과 파일 확장자 개념, 아이콘의 고유 특징 등을 이해할 필요가 있습니다.

이를 통해 정기적인 사내 보안 교육 및 사례 공유를 통해 임직원의 보안 인식수준을 높인다면, 내부 보안 강화에 많은 도움을 줄 수 있습니다. 그리고 EDR 또는 MDR 서비스 도입을 통해 보다 체계적이고 효율적인 위협 관리 체계를 운영할 수 있습니다. 본 보고서는 최신 사례를 기반으로 위협을 효과적으로 방어하기 위한 인사이트 확보와 방어전략 수립에 필요한 기술분석 자료로 활용할 수 있습니다.

2. 배경 (Background)

지니언스는 APT37 그룹의 다양한 위협 활동을 분석해, 사이버 위협 대응을 위한 위협 인텔리전스 보고서를 제공하고 있습니다.

유형별 실제 사례 분석을 통해 지능형지속위협(APT)의 변화와 흐름을 파악할 수 있습니다. 북한 연계뿐만 아니라 중국, 러시아 등 국가배후 해킹조직의 위협은 나날이 높아지고 있습니다. 기존에 알려진 공격 도구 역시 계속 발전하고 있어, 이에 대한 다양한 분석과 연구가 중요해 지는 추세입니다.

[그림 2-1] 공격 시나리오

3. 기술적 분석 (Technical Analysis)

3-1. 바로가기(Shortcut) LNK 분석

악성 파일은 '국가정보와 방첩 원고.zip' 압축 파일을 통해 유포가 됐습니다. 압축 파일 내부에 '국가정보와 방첩 원고.lnk' 이름의 바로가기 파일이 포함돼 있습니다.

해당 바로가기 파일의 사이즈는 약 54MB(54,160,170 Bytes)로 비정상적으로 큰 것을 알 수 있습니다. 왜냐하면, 코드 내부에 미끼용 정상 문서와 함께 RoKRAT Shellcode 등을 은닉해 두고 있기 때문입니다.

정상적인 보통의 바로가기 파일은 단순한 텍스트 정보(파일의 경로, 아이콘 정보 등)를 저장하므로 최대 몇 십 킬로바이트(KB) 정도 입니다.

[그림 3-1] 유포된 악성파일 화면

'국가정보와 방첩 원고.lnk' 파일 내부에 은닉된 속성정보를 추출하면 다음과 같습니다.

[그림 3-2] LNK 파일 구조 및 코드 상관 분석

바로가기 파일 내부에는 4가지 데이터가 포함돼 있습니다.

미끼(Decoy)용 정상 HWP 문서파일
Shellcode (ttf01.dat)
Powershell 명령어 (ttf02.dat)
배치파일 명령어 (ttf03.bat)

미끼 파일을 제외한 데이터의 실행 흐름은 하기와 같습니다.

ttf03.bat -> ttf02.dat -> ttf01.dat

[그림 3-3] 코드 실행 흐름

'ttf03.bat' 배치파일을 통해 분리된 PowerShell 명령이 순차적으로 실행됩니다. 그리고 'ttf02.dat' 파일을 통해 shellcode 블록인 'ttf01.dat' 파일을 불러오고, XOR 연산을 수행합니다.

$exeFile = Get-Content -path $exePath -encoding byte
$len = $exeFile.count
$newExeFile = New-Object Byte[] $len
$xK = '3'

for ($i = 0; $i -lt $len; $i++) {
$newExeFile[$i] = $exeFile[$i] -bxor $xK[0]
}

[표 3-1] XOR 연산 로직

PowerShell에서 $xK='3'로 선언된 문자열의 첫 번째 문자는 ASCII 코드값으로 0x33(10진수 51)에 해당하며, 이는 XOR 연산 시 사용되는 키 값으로 작동합니다.

각 바이트는 $exeFile[$i] -bxor $xK[0]을 통해 XOR 로직으로 디코딩 됩니다.

수동으로 디코딩 작업을 수행하기 위해 하기 PowerShell 명령을 사용할 수 있습니다. 이를 통해 'ttf01.dat_decode' 파일을 획득할 수 있습니다.

$key = '3'
$keyByte = [byte][char]$key

$inputFile = "D:\ttf01.dat"
$outputFile = "D:\ttf01.dat_decode"

$encodedBytes = Get-Content -Path $inputFile -Encoding Byte
$decodedBytes = New-Object Byte[] $encodedBytes.Length

for ($i = 0; $i -lt $encodedBytes.Length; $i++) {
$decodedBytes[$i] = $encodedBytes[$i] -bxor $keyByte
}

[IO.File]::WriteAllBytes($outputFile, $decodedBytes)
Write-Host "XOR decoding complete. Output saved to: $outputFile"

[표 3-2] PowerShell XOR 파일 변환 명령어

순차적 코드 분석을 위해 수동 변환을 편리하게 진행할 수 있습니다.

[그림 3-4] PowerShell 수동 디코딩 변환 예제

변환된 코드를 비교해 보면, 전형적인 shellcode 블록을 가지고 있습니다. 상세한 shellcode 분석을 위해 코드 디버깅을 수행하고, 페이로드(Payload) 확인 과정이 필요하게 됩니다.

[그림 3-5] shellcode 비교 화면

3-2. shellcode 분석

shellcode 디버깅 과정을 통해 XOR 변환 로직을 확인할 수 있습니다.

[그림 3-6] XOR 변환 과정

실제 원본 shellcode 데이터를 기준으로, 오프셋 00000590 번지부터 0xAE 1바이트로 XOR 변환이 진행됩니다.

변환된 데이터는 32비트 EXE 실행파일이며, Time Date Stamp 값은 '2025-04-21 00:39:59 (UTC)' 입니다. 위협 행위자는 한국시간(UTC+9) 기준 오전 9시 39분에 악성코드를 제작했다 추정할 수 있습니다.

해당 파일에서 'Program Database(PDB)' 정보가 확인이 됩니다. PDB 파일은 Windows에서 Visual Studio 등으로 프로그램을 빌드할 때 생성되는 디버깅 정보 파일입니다. 이 파일은 실행 파일(EXE)이나 동적 라이브러리(DLL)에 대한 심볼 정보(symbol information), 소스 코드 매핑, 변수명, 함수명 등의 디버깅에 필요한 정보를 포함합니다.

악성코드에 존재하는 PDB 정보는 개발자의 다양한 정보를 파악하는데 활용되고, 유사 변종에 대한 단서로도 사용됩니다.

프로그램 로컬 경로
프로젝트 명
개발자 정보
악성코드 종류
악성코드 버전 등

[그림 3-7] DebugData PDB 경로 정보

해당 정보에는 'InjectShellcode' 문자열 데이터가 포함돼 있어, 개발자의 의도를 예측해 볼 수 있습니다.

D:\Work\Util\InjectShellcode\Release\InjectShellcode.pdb

[표 3-3] PDB 문자열 정보

다수의 RoKRAT 변종 중에 'InjectShellcode' 문자열이 발견된 것은 이번이 처음입니다. 이는 Anti-Virus 제품의 탐지나 악성코드 분석을 어렵게하기 위한 목적으로 보입니다.

[그림 3-8] mspaint.exe 프로세스 메모리 인젝션 루틴

'InjectShellcode' 모듈은 CreateProcessW API 함수를 통해 하드코딩된 'C:\Windows\SysWOW64' 경로에 존재하는 'mspaint.exe' 프로세스를 생성합니다. 여기서 'mspaint.exe' 파일은 Windows 그림판 프로그램입니다.

참고로 64비트는 호환성 고려를 위해 Windows-32-on-Windows-64(WOW64) 하위 시스템을 사용하여 수정 없이 32비트 프로그램을 실행합니다. 하지만, Windows 11의 최신 버전에서는 'mspaint.exe'가 더 이상 'SysWOW64' 또는 'System32' 경로에 존재하지 않습니다. UWP(Universal Windows Platform) 앱으로 전환됐기 때문입니다. 전환된 시점이 정확하게 알려져 있진 않지만, 2024년 10월 전후 수차례 누적 업데이트를 통해 클래식 그림판이 제거됐다는 사용자 경험이 보고된 바 있습니다.

따라서, 일부 환경에서는 'SysWOW64' 경로로 하드코딩된 'mspaint.exe' 프로세스 인젝션 기법이 실패하고, 악성코드가 제대로 작동하지 못합니다.

만약 'SysWOW64' 경로에 'mspaint.exe' 파일이 존재한다면, 가상 메모리 공간을 할당하고 데이터를 쓰게 됩니다. 이때 'xmmword_403018' 배열의 데이터 '325869FF25798BC277BF22DEB1DEB967h'부터 '0xDA000'(892,928) 바이트만큼 쓰게 됩니다.

그리고 'xmmword_402170' 배열의 데이터와 XOR 연산을 수행합니다. 이때 사용되는 데이터는 '32323232323232323232323232323232h' 입니다. XOR 연산이 수행된 데이터는 두번째 shellcode 구조를 가지게 됩니다.

[그림 3-9] shellcode 디코딩 루틴

해당 shellcode는 eax가 가리키는 오프셋 000590 번지부터 bl 값인 '0xD6' 키와 XOR 연산을 반복 수행합니다.

XOR 연산이 완료되면, 32비트 EXE 실행파일로 변환이 됩니다. 이 파일이 바로 RoKRAT 변종입니다.

[그림 3-10] XOR 연산 전후 결과 비교

참고로, 2025년 07월 20일에는 '북한이탈주민의 성공적인 남한정착을 위한 아카데미 운영.lnk' 파일명을 가진 변종이 발견됐습니다.

해당 유형은 'C:\Windows\SysWOW64' 경로에 존재하는 'mspaint.exe' 프로세스 대신에 'notepad.exe' 파일명으로 변경했습니다. 그리고 'Weapon' 폴더 경로에서 악성파일을 개발했습니다.

D:\Work\Weapon\InjectShellcode\Release\InjectShellcode.pdb

[표 3-4] PDB 문자열 정보

'Weapon' 폴더는 2025년 02월 03일 "K 메신저로 유포된 'APT37' 그룹의 악성 HWP 사례 분석" 보고서의 [그림 12]에서도 동일하게 발견된 바 있습니다.

3-3. RoKRAT 분석

XOR 연산 후 변환된 최종 모듈은 APT37 그룹이 사용하는 RoKRAT 변종으로 확인이 됩니다. RoKRAT에 대해서는 'Operation. ToyBox Story' 보고서 등을 통해 여러차례 소개한 바 있으니, 상세한 점은 이전 내용을 참고하시면 되겠습니다.

이번 변종의 경우도 기존과 큰 차이가 없는, 전형적인 RoKRAT 기능을 수행합니다. 이번 모듈에서도 고유 식별자 문자열(--wwjaughalvncjwiajs--)이 그대로 발견됐습니다. 이 문자열은 RoKRAT 유형이 C2로 쓰는 클라우드 API를 요청할 때 Content-Type에 포함하는 고정값으로 알려져 있습니다.

RoKRAT 모듈은 감염된 단말의 기본적인 컴퓨터 정보와 문서파일, 스크린샷 등을 수집하여 합법적인 클라우드 서비스로 유출을 시도합니다.

api.pcloud.com
cloud-api.yandex.net
api.dropboxapi.com

위협 행위자는 shellcode 및 Fileless 기반으로 이 모듈을 로드하고 있는데, 그 이유 때문인지 내부 기능은 크게 변경하지 않고 사용하고 있습니다.

[그림 3-11] RoKRAT 내부 문자열

더불어 무료 클라우드 저장소를 C2 서버로 지속 악용 중입니다.

따라서 기업이나 기관의 보안 담당자는 외부 클라우드 접속 기록도 세심히 살펴볼 필요가 있습니다.

[그림 3-12] Dropbox API 및 Access Token 값

이번 경우는 2개의 Dropbox Access Token Key가 사용됐습니다. 해당 Key 값은 하기와 같고, 현재는 취소(revoke)된 상태입니다.

hFkFeKn8jJIAAAAAAAAAAZr14zutJmQzoOx-g5k9SV9vy7phb9QiNCIEO7SAp1Ch
gYQs1sJ0etEAAAAAAAAAAUsEYLCFpEUR38u0SxDzsfL2F8ZCLokJPGpPsq4OTNUX

2025년 07월 20일 발견된 변종의 토큰 값은 아래와 같습니다.

Q54LEwmIgyAAAAAAAAAIIMytoGW3__MIEynCsFRSwohgvHI_fjViYK5ZfrG28teC
1yLixfRbcDAAAAAAAAAACJoZNYUJ5tQzE6jjb-mhXhqWZBRYWi8NJQ349sxGdkt_

3-4. C2 Dropbox 가입자 정보

Dropbox API 서비스와 Access Token 통해 확인해 보면, 가입자의 이력 정보를 일부 조회할 수 있습니다. 이를 통해 위협 행위자(Threat Actor)의 이메일 정보 등을 식별할 수 있습니다.

"email": "nusli.vakil@yandex.com",
"email_verified": true,
"disabled": false,
"country": "US",
"locale": "en",

"email": "reddy.kappeta@yandex.com",
"email_verified": true,
"disabled": false,
"country": "US",
"locale": "en",

"email": "leon24609@gmail.com",
"email_verified": true,
"disabled": false,
"country": "GB",
"locale": "ko",

"email": "leon91729@zoho.com",
"email_verified": true,
"disabled": false,
"country": "JP",
"locale": "ko",

[표 3-5] Dropbox 가입자 이력 정보

[그림 3-13] 링크드인 가입자 화면 (프로필 모자이크 처리)

두개의 가입자 정보 모두 러시아의 Yandex 이메일 계정이 사용됐습니다. 이메일에 사용된 아이디를 검색해 보면, 링크드인(Linkedin)이 나오지만, 동일인이라고 단정할 수는 없습니다.

다만, APT37 배후의 위협 행위자가 클라우드 저장소에 가입할 때 등록하는 이메일 주소가 링크드인에서 지속 관찰되는 것은 매우 흥미로운 점입니다. 이와 관련된 내용은 'Operation. ToyBox Story' 보고서에서 기술한 바 있습니다.

4. 사진 속 은닉 기법 (Hiding Techniques in Images)

4-1. 스테가노그래피 기법의 RoKRAT 발견

2025년 07월 초에 Multiple Provider Router DLL처럼 위장한 RoKRAT Loader 형태가 다수 식별됐습니다. 원본 파일명은 'mpr.dll'이고, 32Bit DLL 변종 모두 유사한 기능을 가지고 있습니다.

일부는 HWP 문서에 악성 OLE를 삽입해 공격에 쓰인 것으로 확인됩니다.

[그림 4-1] 악성 HWP 내부 구조 분석 화면

문서 내부에 'BIN001.OLE', 'BIN002.OLE' 오브젝트가 존재하는데, 하나는 Sysinternals에서 배포하는 'ShellRunas.exe' 파일입니다. 그리고 다른 하나는 'credui.dll' 입니다.

실제 악성 HWP 문서가 실행되고 내부에 삽입된 하이퍼링크를 클릭하면 임시폴더(%Temp%) 경로에 생성된 'ShellRunas.exe' 실행 여부 창이 나타납니다. 만약 실행을 허용하면, 함께 생성된 'credui.dll' 악성 모듈이 로드됩니다. 이것은 전형적인 DLL Side-Loading 기법입니다.

유사 사례에서 확인된 DLL Side-Loading 방식은 다음과 같습니다. 여기서 dll 파일들이 악성 모듈입니다.

ShellRunas.exe
- credui.dll
AccessEnum.exe
- mpr.dll
Hhc.exe
- hha.dll

'credui.dll' 모듈은 DropBox 드라이브에 존재하는 'Father.jpg' 이미지를 다운로드하고 메모리 상에서 로드합니다. 흥미로운 점은 JPEG 이미지 포맷 내부에 RoKRAT 모듈을 은닉해 둔 점이며, 보통 '스테가노그래피(Steganography)' 기법이라고 말합니다.

두가지 형태의 사진으로 위장한 방법이 발견됐는데, 내부적인 악성코드 패턴은 동일합니다. 이에 'mpr.dll' 모듈로 위장된 악성 코드를 기준으로 분석하겠습니다.

[그림 4-2] 이미지 위장 악성파일 사례

'mpr.dll' 파일 내부에 'MYIMAGEFILE' 이름의 리소스(Resources)가 포함된 것을 알 수 있습니다. 얼핏 리소스 이름만 봤을 때는 이미지 파일이 삽입된 것처럼 해석될 수 있습니다.

[그림 4-3] 'mpr.dll' 리소스 영역 화면

이 파일은 리소스를 찾아 해당 데이터를 로드하고, SHGetKnownFolderPath 함수를 통해 %LOCALAPPDATA% 경로에 'version1.0.tmp' 파일로 저장합니다.

[그림 4-4] 리소스 데이터 생성 함수

그리고 LoadLibraryW 함수를 통해 'version1.0.tmp' 파일을 로드합니다.

[그림 4-5] 라이브러리 로드 함수

파일 로드가 진행되면, 해당 DLL 내부의 함수들 주소를 획득합니다

OpenURL
GetMyFirstResult
Set_InstallKey
Check_Installed
ProtectMe

'version1.0.tmp' 파일 내부에도 'MYIMAGEFILE' 이름의 리소스가 포함돼 있습니다. 그리고 실제로 JPEG 이미지 포맷의 헤더를 가지고 있습니다.

[그림 4-6] 'version1.0.tmp' 리소스 영역 화면

리소스를 추출해 확인해서 보면, 실제로 유효한 JPEG Exif(Exchangeable image file format) 헤더를 가지고 있습니다. 그리고 JPEG 이미지 파일은 실제 특정 인물의 얼굴 모습을 포함하고 있습니다.

그런데 분석결과 'version1.0.tmp' 파일은 사진 리소스내 데이터를 0xAA Key 값으로 XOR 연산하는 로직이 발견됐습니다. 연산 후 변환된 오프셋 0x4201 위치에서는 shellcode 데이터가 관찰됐습니다.

[그림 4-7] 사진 화면 및 shellcode 모습

이렇게 나온 shellcode 데이터는 내부 루틴을 통해 0x29 Key 값으로 XOR 연산이 한번 더 수행됩니다. 이 연산을 통해 내부에 숨겨져 있는 RoKRAT 모듈이 나타나는 과정을 거칩니다.

이처럼 사진 파일 헤더를 가지고 있지만, 디코딩 과정을 거쳐 내부에 악성코드가 로드됩니다. 전형적인 스테가노그래피 기법의 형태를 가지고 있습니다.

[그림 4-8] XOR 연산 수행 루틴

여기서 사용된 RoKRAT 기능을 분석한 결과, 두개의 클라우드 Access Token 값이 식별됐습니다.

pCloud
- U1XD7ZzVoRYfYDIfLZhPK7ykZ43rMhs5ej88WQ78GctvXupdkFGXy
Yandex
- y0_AgAAAAB6OAV_AAzOMAAAAAEZECSQAAAy5BcMOOVPsYKi_OfJu8GQ3fWpZA

이 토큰 값은 2023년부터 2024년에 이미 사용된 내역이 확인됩니다.

5. 결론 및 대응 (Conclusion)

Genian EDR 관리자는 위협 흐름을 가시성 높게 파악할 수 있습니다. 스테가노그래피 기법을 이용한 사례의 경우, 리소스 영역 내부에 존재했던 'version1.0.tmp' 파일이 생성되는 과정을 쉽게 파악할 수 있습니다.

확장자가 tmp 파일이지만, 'rundll32.exe' 부모프로세스에서 실행된 것을 확인할 수 있습니다.

[그림 5-1] 리소스에 포함된 DLL 생성 후 실행 화면

mspaint.exe 프로세스에 shellcode를 삽입(Injection)하여 파일리스(Fileless) 형태로 공격을 수행하는 경우, 시그니처나 패턴 기반의 보안 제품에서 탐지가 어려울 수 있습니다.

[그림 5-2] mspaint.exe 프로세스에 인젝션하여 통신하는 모습

EDR(Endpoint Detection and Response) 제품을 사용할 경우, shellcode와 Dropbox API를 이용한 외부 통신행위를 빠르게 식별할 수 있습니다.

단말에서 채증된 악성코드를 상세히 리버싱(Reversing)하고 분석하려면 많은 시간이 필요합니다. 하지만, EDR을 통해 악성코드별 동작 흐름을 신속히 파악한다면, SOC(Security Operations Center) 내의 위협 분석가에게 큰 도움이 됩니다.

악성코드의 흐름을 시각적으로 제공하는 것은 위협 분석가에게 매우 중요한 도구입니다. 여기에는 몇 가지 주요 이점이 있습니다.

공격의 전체 흐름 이해
- EDR을 통해 수집된 데이터를 시각화하면 악성코드가 시스템 내에서 어떻게 전파되고, 감염되는지를 명확히 이해할 수 있습니다. 이는 공격의 전체적인 흐름을 이해하는 데 큰 도움이 됩니다.

감염 경로 분석
- 시각적 데이터 분석을 통해 악성코드가 시스템 내에서 어떤 경로를 통해 전파되었는지를 파악할 수 있습니다. 이는 공격자가 취한 특정 공격 벡터를 이해하는 데 도움을 줍니다.

위협 탐지와 대응 강화
- EDR 시각화는 위협을 빠르게 탐지하고 대응하는 데 필수적입니다. 특히, 악성 활동의 패턴을 식별하고, 신속하게 반응하여 피해를 최소화하는 데 도움이 됩니다.

악성코드 분류 및 특성 분석
- 악성코드의 종류와 특성을 시각적으로 분석함으로써, 해당 악성코드의 작동 원리와 기능을 이해하는 데 도움이 됩니다. 이는 방어 전략을 개발하고, 유사한 공격을 예방하는 데 중요한 기반이 됩니다.

보고서 작성 및 기록
- EDR 시각화는 위협 분석 결과를 보다 명확하게 문서화하고 보고서로 작성하는 데 도움을 줍니다. 이는 보안 팀 간의 효과적인 커뮤니케이션을 촉진하고, 향후 사건 대응을 위한 기록으로 활용될 수 있습니다.

요약하면, EDR을 통한 악성코드의 시각적 분석은 위협분석가가 공격의 세부적인 면을 깊이 이해하고, 효과적으로 대응하는 데 큰 도움을 줍니다.

[그림 5-3] 클라우드 기반 C2 통신 이벤트 조사 화면

Genian EDR은 합법적인 클라우드 서비스를 악용한 C2 통신 기록도 MITRE ATT&CK Technique 태그를 붙여주고 있기 때문에 보안 관리자가 위협 가능성 판단에 도움을 받을 수 있습니다.

RoKRAT은 Dropbox, Google Drive, Yandex Disk 같은 클라우드 서비스로 위장한 C2(Command & Control) 통신을 사용합니다. 그렇기 때문에 보안 장비에서 탐지가 어려워 장기간 은폐된 활동이 가능합니다.

특히, 파일리스 형태로 메모리 상에서 실행되며 디스크에 흔적을 거의 남기지 않아 전통적인 백신이나 로그 기반 탐지로는 포착이 어렵습니다. 이처럼 은밀하고 지속적인 공격에는 EDR을 활용한 대응 체계가 필수적입니다. 시스템에 침투 후 수행하는 스크립트 실행, 프로세스 생성, 네트워크 연결 시도 등의 행위를 실시간 감시하고 탐지할 수 있기 때문입니다.

RoKRAT 위협은 진화를 거듭하고 있으며, 최신 변종은 일반적인 백신(Anti-Virus)이나 SIEM 시스템만으로는 탐지와 대응이 어려운 고도화된 APT용 악성코드입니다. 따라서 다음과 같은 이유로 EDR 기반의 대응이 꼭 필요합니다.

실시간 이상행위 탐지(XBA) 및 분석
공격 전 과정에 대한 시각적 이해
신속한 네트워크 격리 및 대응 방안 선택
향후 유사 공격 방지를 위한 데이터 축적

6. 침해 지표 (Indicator of Compromise)

a2ee8d2aa9f79551eb5dd8f9610ad557

ae7e18a62abb7f93b657276dcae985b9

d5fe744b9623a0cc7f0ef6464c5530da

f6d72abf9ca654a20bbaf23ea1c10a55

fd9099005f133f95a5b699ab30a2f79b

5ed95cde6c29432a4f7dc48602f82734

16a8aaaf2e3125668e6bfb1705a065f9

64d729d0290e2c8ceaa6e38fa68e80e9

443a00feeb3beaea02b2fbcd4302a3c9

e13c3a38ca58fb0fa9da753e857dd3d5

e4813c34fe2327de1a94c51e630213d1