Green Blood 랜섬웨어 그룹은 2026년 1월부터 활동이 확인된 신규 랜섬웨어 그룹으로, Golang 기반의 랜섬웨어 페이로드를 운영하는 것이 특징이다. 이들은 남아시아와 아프리카, 남미 일부 국가를 중심으로 공격을 전개하고 있으며, 다른 랜섬웨어 그룹과 마찬가지로 감염된 시스템의 파일을 암호화하고 피해 기업의 민감 정보를 탈취하는 이중 갈취 방식을 사용한다. 또한 몸값이 지불되지 않을 경우 복호화 키를 영구적으로 파기하겠다는 협박성 메시지를 통해 피해자에게 금전 지불을 압박하는 방식을 사용한다.

 

(사진)

 

 

분석 내용

Green Blood 랜섬웨어는 우선 현재 시스템의 논리 코어 수를 확인하고, 이를 기준으로 동시에 실행 가능한 OS 스레드 수를 조정한다.

 

또한 중복 실행을 방지하기 위해 Mutex를 생성한다. 이 과정에서 LazyDLL과 LazyProc 객체를 활용하여 kernel32.dll에 포함된 CreateMutexW API를 동적으로 호출한다. 사용되는 Mutex 이름은 아래와 같다.

 

Mutex 이름

Global\\GREENBLOOD_ENCRYPTOR_MUTEX_2A3B4C5D

[표 1] 중복 실행 방지를 위해 사용하는 Mutex 이름

 

이후 AES-256 암호화에 사용할 32 바이트 크기의 난수를 생성한다. 이를 위해 운영체제의 CSPRNG를 사용하는 crypto/rand.Read 함수를 호출하여 암호학적으로 안전한 난수를 생성한다. 생성된 값은 이후 AES-256 암호화 알고리즘의 Key로 사용된다.

 

 

[그림 3] crypto/rand.Read 함수를 호출해 생성한 32 바이트 크기의 난수

 

다음으로 현재 환경을 식별하기 위한 고유 값인 Machine ID를 생성한다. 이를 위해 다음 정보를 수집한 뒤 해당 정보를 기반으로 16 바이트 크기의 Machine ID를 생성하며, 만약 해당 정보 수집 과정에서 실패할 경우에는 현재 시간 정보를 기반으로 16 바이트 크기의 Machine ID를 생성한다.

 

Index	수집 대상 정보
1	Host 이름
2	Logical Drive 정보 및 Volume Serial Number
3	Windows Version
4	BIOS UUID
5	Network Interface MAC 주소

[표 2] Machine ID 생성에 사용되는 정보 (5개)

 

 

 

[그림 4] Machine ID 생성을 위해 현재 환경의 정보를 수집하는 루틴

 

그 후 공격자가 복호화 과정에서 사용할 Recovery Token을 생성한다. 해당 값은 앞서 생성한 32 바이트 크기의 AES-256 암호화 Key와 16 바이트 크기의 Machine ID를 XOR 연산하여 생성된다.

 

 

[그림 5] AES-256 암호화 Key와 Machine ID를 XOR 연산하여 Recovery Token을 생성하는 루틴

 

 

암호화 준비

Green Blood 랜섬웨어는 실제 파일 암호화를 수행하는 Worker와 암호화 대상을 탐색하여 암호화 대상 파일 큐에 등록하는 Worker, 두 종류의 Worker를 생성한다.

 

암호화 대상을 탐색하는 Worker는 GetLogicalDrives API를 호출하여 사용자 환경에 존재하는 드라이브의 비트 마스크 값을 획득하고, 해당 값을 기반으로 하드 디스크 드라이브와 같은 고정 드라이브를 암호화 대상 드라이브로 선정한다.

 

이후 선정된 고정 드라이브의 디렉토리를 재귀적으로 순회하며 대상이 디렉토리인 경우에는 랜섬 노트를 생성하고, 대상이 파일인 경우에는 암호화 대상 파일 여부를 확인한다.

 

 

[그림 6] GetLogicalDrives API 호출 결과를 기반으로 암호화 대상 고정 드라이브를 식별하는 루틴

 

 

 

우선 파일 확장자가 “.tgbg”인지 확인하여 이미 암호화가 완료된 파일인지 확인한다. 이미 암호화가 완료된 파일에 대해서는 추가적인 암호화를 수행하지 않는다. 반면, 암호화되지 않은 파일인 경우애는 해당 파일의 확장자를 소문자로 변환한 뒤, 암호화 제외 대상 확장자 목록과 비교해 암호화 제외 대상 여부를 판단한다.

 

암호화 제외 대상 파일 확장자

exe, dll, sys, drv, ocx, cpl, scr, msi, msu, cab, mui, mun, edb, jrs, log, tmp, temp, lnk, url, pif

[표 3] 암호화 제외 대상 확장자 (20개)

 

이후 암호화 대상 확장자 목록과 다시 비교해 최종적으로 암호화 대상 파일 여부를 결정하며, 암호화 대상 파일로 확인될 경우 해당 파일을 암호화 대상 파일 큐에 등록한다.

 

암호화 대상 파일 확장자

doc, xls, ppt, pdf, txt, rtf, odt, ods, odp, csv, xml, yml, sql, mdf, ldf, mdb, dbf, myd, myi, frm, ibd, bak, old, arc, bck, bkf, log, err, inf, ini, cfg, cpp, hpp, css, php, ps1, vbs, jpg, png, gif, bmp, psd, mp3, wav, mp4, avi, mov, wmv, mkv, flv, m4a, aac, zip, rar, tar, bz2, tgz, vmx, vhd, iso, img, pst, ost, eml, msg, mae, trn, dmp, wal, key, pem, crt, pfx, p12, cer, pub, gpg, pgp, asc, ora, rsp, msi, lnk, htm, sln, lck, exe, dll, sys, drv, ocx, cpl, scr, msu, cab, mui, mun, edb, jrs, tmp, url, pif, docx, xlsx, pptx, json, yaml, back, log1, log2, info, conf, java, html, jpeg, tiff, indd, flac, vmdk, vhdx, dump, priv, temp, accdb, error, audit, prefs, mssql, db, py, js, ts, go, rs, cs, vb, pl, sh, ai, 7z, gz, xz, sqlite, backup, config, csproj, vbproj, sqlite3, archive, journal, vcxproj, pbxproj, propertiesshell, settings, c, h, xcodeproj

[표 4] 암호화 대상 확장자 (140개)

 

또한 파일 확장자가 존재하지 않더라도 파일 크기가 100 바이트 이상인 경우에는 암호화를 수행한다. 단, MS Office 임시 파일과 같이 파일명이 “~”로 시작하는 파일은 암호화 대상에서 제외한다.

 

이와 같은 절차를 통해 최종 암호화 대상 파일을 식별한 후, 이를 암호화 대상 파일 목록 큐로 전송한다.

 

 

 

 

[그림 7] 암호화 대상 파일을 식별하는 루틴

 

실제 파일 암호화를 수행하는 Worker는 총 50개가 생성되어 병렬로 실행된다. 각 Worker는 암호화 대상 파일 큐로부터 파일 하나를 수신한 뒤, 해당 파일에 대해 암호화 함수를 호출하는 방식으로 동작한다.

 

각 Worker는 파일 암호화를 수행하기에 앞서 파일 이름을 소문자로 변환한다. 이후 파일명 마지막 5 바이트를 암호화 확장자인 “.tgbg”와 비교하여 이미 암호화된 파일인지 여부를 다시 한 번 검증한다. 그리고 각 파일에 대해 최대 5번까지 암호화를 시도한다.

 

 

[그림 8] 파일 암호화를 수행하는 Worker 생성 및 실행 루틴

 

파일 암호화

 

암호화를 수행할 파일에 대해 먼저 os.stat 함수를 호출하여 해당 파일의 존재 여부를 확인한다. 이후 파일 크기를 확인해, 파일 크기가 50GB 이상인 경우에는 암호화를 수행하지 않는다.

 

 

[그림 9] 암호화 대상 파일의 크기를 확인하는 루틴

 

그 다음 해당 파일의 전체 경로 뒤에 “.tmp”를 붙여 Write-Only 모드로 임시 파일을 생성한다. 이후 각 파일마다 crypto/rand.Read 함수를 호출하여 16바이트 크기의 난수를 생성하고 이를 파일의 최상단에 저장한다. 이 난수는 해당 파일을 암호화하는 데 사용되는 AES-256 암호화 알고리즘의 IV 값으로 활용되며, 파일마다 서로 다른 IV 값이 적용된다.

 

이후 랜섬웨어 실행 초기에 생성한 32바이트 크기의 Key를 기반으로 CTR 모드의 AES-256 암호화 알고리즘을 사용해 파일을 암호화한다. 파일 암호화는 1MB 단위로 수행되며, 파일의 EOF에 도달할 때까지 동일한 과정을 반복한다.

 

 

[그림 10] AES-256 암호화 알고리즘(CTR 모드)을 사용하여 파일을 암호화하는 루틴

 

 

암호화가 완료되면 생성한 tmp 파일의 확장자를 “.tgbg”로 변경하여 최종 암호화 파일을 생성하고, 기존 원본 파일은 삭제한다.

 

암호화가 완료된 파일의 구조는 다음과 같다. 파일의 최상단에는 해당 파일의 AES-256 암호화에 사용된 IV 값이 저장되며, 그 뒤에는 암호화된 파일 데이터가 순차적으로 위치한다.

 

 

[그림 11] 암호화 후의 파일 구조

 

추가로, 사용자의 Home 디렉토리에 대해서는 별도의 Worker를 생성하여 처리하며, 이는 드라이브 대상 파일 암호화 Worker와 병렬로 암호화를 수행한다.
 

안티 포렌식 및 자가 삭제 기능

 

Green Blood 랜섬웨어는 사용자의 복구를 방해하기 위해 총 7개의 안티 포렌식 기능과 자가 삭제 기능을 사용한다.

 

먼저 현재 프로세스가 관리자 권한으로 실행 중인지 여부를 확인한다. 관리자 권한이 존재하는 경우에는 사전에 정의된 7개의 명령어를 순차적으로 실행하며, 관리자 권한이 없는 경우에는 해당 명령어를 실행하지 않고 해당 절차를 생략한다.

 

Index	안티 포렌식 명령어 및 의미
1	vssadmin delete shadows /all /quiet
	모든 볼륨 섀도우 복사본 삭제
2	wbadmin delete catalog -quiet
	Windows 백업 카탈로그 삭제
3	bcdedit /set {default} recoveryenabled no
	Windows 복구 환경 비활성화
4	bcdedit /set {default} bootstatuspolicy ignoreallfailures
	부팅 실패 상태 무시 설정
5	wmic shadowcopy delete
	WMI 기반 볼륨 섀도우 복사본 삭제
6	reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection” /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
	Windows Defender 실시간 감시 비활성화
7	netsh advfirewall set allprofiles state off
	Windows 방화벽 모든 프로필 비활성화

[표 5] 복구를 방해하기 위해 사용하는 안티 포렌식 명령어 (7개)

 

 

[그림 12] 복구를 방해하기 위해 안티 포렌식 명령어를 사용하는 루틴

 

이후 Temp 경로에 “cleanup_greenblood.bat” 이름의 배치 파일을 생성하고, 이를 실행하여 자가 삭제 기능을 수행한다. 해당 배치 파일은 5초 동안 대기한 뒤 랜섬웨어 실행 파일을 삭제하며, 삭제에 실패할 경우에도 반복적으로 재시도하도록 구성되어 있다. 마지막 단계에서는 자신을 실행한 배치 파일 또한 삭제한다.

 

 

[그림 13] 자가 삭제 기능 배치 파일 (cleanup_greenblood.bat)

 

 

복호화 가능성

 

GreenBlood 랜섬웨어는 각 파일마다 서로 다른 IV 값을 사용하지만, 대칭키 기반의 AES-256 암호화 알고리즘을 사용한다. 그리고 해당 Key는 랜섬웨어 실행 초기에 한 번 생성된 이후 모든 파일 암호화 과정에서 동일하게 사용된다.

 

또한 해당 Key 값은 현재 시스템 정보를 기반으로 생성된 16바이트 크기의 Machine ID와 XOR 연산을 수행하여 Recovery Token을 생성하는 데 사용되고, 생성된 Recovery Token은 랜섬 노트에 명시되기 때문에, 이를 역연산할 경우 높은 확률로 파일 복호화에 필요한 Key를 복원할 수 있다.

 

 

[그림 14] 랜섬 노트에 명시된 Recovery ID 및 Machine ID

 

복호화 방법은 다음과 같다. 먼저 랜섬 노트에 포함된 Recovery ID 값에서 “GREEN-BLOOD-” 문자열을 제외한 뒤의 32 바이트 크기의 데이터를 XOR 연산에 사용할 값으로 사용한다. 이후 랜섬 노트에 함께 명시된 16바이트 크기의 Machine ID와 XOR 연산을 수행하면, 현재 환경에서 파일 암호화에 사용된 AES-256 암호화 Key를 복원할 수 있다.

 

그리고 복원한 AES-256 Key와 각 암호화 파일의 최상단에 저장된 16 바이트 IV 값을 사용해 AES-256 CTR 모드의 복호화 알고리즘을 적용하면, 높은 확률로 파일 데이터를 정상적으로 복구할 수 있다.

 

 

 

 

[그림 15] Recovery ID 기반 XOR 연산을 이용한 AES-256 암호화 Key 복원 및 파일 복호화 결과

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

안랩 대응 현황

 

안랩 제품군의 진단명과 엔진 날짜 정보는 다음과 같다.

[V3 진단]

• Ransomware/Win.GreenBlood.C584923 (2026.01.31.01)
• Ransomware/Win.GreenBlood.C584449 (2026.02.05.02)
• Ransom/MDP.Event.M1785 (2017.11.23.00)   
• Ransom/MDP.Decoy.M1171 (2016.07.14.02)
• Ransom/MDP.Event.M1875 (2018.03.09.00)
• Ransom/MDP.Event.M4353 (2022.07.05.00)
• Ransom/MDP.Behavior.M2813 (2020.03.24.03)
• Ransom/MDP.Delete.M1105 (2016.05.18.02)
• Ransom/MDP.Event.M1946 (2018.06.06.00)
• Ransom/MDP.Event.M4807 (2024.02.08.02)

[EDR 진단]

• Execution/EDR.Malware.M10459 (2022.08.12.03)
• Connection/EDR.Event.M11768 (2024.06.11.00)

 

 

※ 이하 자세한 내용은 첨부파일을 참조하시기 바랍니다.

MD5

e760729dcee518659d9510ae1705db51