[논문 리뷰] Latrodectus 이해하기

악성코드에서 C2 주소를 복원하면 어디로 통신하도록 설정됐는지 알 수 있습니다.
그 주소로 실제 요청을 보냈고 응답까지 받았는지는 실행 기록에서 확인해야 합니다.
Latrodectus를 다룬 분석 자료를 읽을 때도 코드가 보여주는 기능과 특정 환경에서 관찰된 행위를 구분할 필요가 있습니다.

이 글은 VB2025의 Latrodectus 기술 보고서를 중심으로 Elastic, Bitsight, Proofpoint·Team Cymru의 분석을 비교합니다.
문자열 복원, API 식별, 환경 검사가 어떻게 동작하는지 살펴보고 각 근거로 어디까지 설명할 수 있는지 검토합니다.
분석 방법의 적용 조건은 SOUPS 2024의 실무 분석가 연구와 연결합니다.

1. Latrodectus의 역할과 분석 문제

후속 코드를 실행하는 로더

Latrodectus는 공격자의 명령을 전달하는 C2 서버와 통신하며 후속 코드를 내려받아 실행하는 Windows 기반 악성코드입니다.
이처럼 감염된 시스템에서 다음 단계의 코드가 실행되도록 연결하는 프로그램을 로더라고 부릅니다.
VB2025 보고서는 후속 실행 파일·DLL·셸코드의 다운로드와 실행 외에도 본체의 시스템 정보 수집, 업데이트와 재시작 기능을 설명합니다.

로더의 명령 처리 코드를 읽으면 후속 코드를 받아 실행하는 기능을 확인할 수 있습니다.
내려받은 코드가 정보를 훔치는지, 다른 프로그램을 실행하는지 등 구체적인 동작은 그 파일을 따로 분석해야 합니다.

• VB2025 — 로더의 역할과 C2 명령, 2·9–10쪽

전달 과정과 DLL의 주요 로직 진입

VB2025 보고서는 JavaScript에서 MSI 설치 패키지를 거쳐 Latrodectus DLL 본체로 이어지는 전달 과정을 설명합니다.
Proofpoint 연구진이 2024년 2월 20일 관찰한 TA578 캠페인에서는 저작권 침해 항의로 위장한 메시지의 링크를 통해 JavaScript 파일을 내려받도록 유도했습니다.
이 스크립트가 MSIEXEC을 호출해 WebDAV 공유의 MSI를 실행하고 MSI가 포함된 DLL의 fin export를 호출하는 흐름입니다.

Export는 DLL이 외부에서 호출할 수 있도록 공개한 함수입니다.
VB2025에 제시된 본체에는 이름이 서로 다른 네 개의 export가 있으며 모두 같은 코드 주소를 가리킵니다.
저자는 각 export를 호출했을 때 동일한 주요 로직으로 진입하는 것을 확인했다고 보고합니다.

그림 1. VB2025 Fig. 1, 2쪽. 화면은 네 export의 주소가 같다는 것을 보여줍니다. 각각 호출했을 때 같은 로직이 실행됐다는 설명은 저자의 본문 관찰에 근거합니다.

DLL을 메모리에 로드하는 과정과 export 함수를 호출하는 과정은 구분해야 합니다.
또한 이 전달 사례와 VB의 DLL 화면을 같은 샘플의 연속 실행 기록으로 합칠 수는 없습니다.

• VB2025 — 전달 과정과 DLL export, 2쪽·Fig. 1
• Proofpoint·Team Cymru — TA578 캠페인의 JavaScript·MSI 전달 사례

분석을 어렵게 만드는 조건

Latrodectus는 C2 주소 등의 내부 문자열을 암호화해 저장하고 필요한 Windows API를 실행 중에 찾아 사용합니다.
문자열을 그대로 읽거나 파일의 정적 import 목록만 살펴보는 것으로는 설정과 호출 대상을 충분히 파악하기 어렵습니다.

프로세스 수, MAC 주소 길이, 디버깅 여부, WOW64 실행 여부를 확인하는 검사도 포함됩니다.
조건에 따라 앞선 단계에서 종료할 수 있으므로 DLL이 실행됐다는 사실만으로 이후 통신이나 후속 코드 실행까지 이어졌다고 볼 수는 없습니다.

• VB2025 — 환경 검사·문자열 암호화·실행 중 API 조회, 3–5쪽

2. 비교 자료의 성격과 범위

중심 자료는 VMRay의 Albert Zsigovits가 Virus Bulletin 2025에서 발표한 「Arachnid alert: Latrodectus loader crawls through defences」입니다.
Latrodectus의 버전별 변화와 내부 동작을 추적한 기술 사례 보고서로 구조표·코드·함수 호출 기록·설정 추출 화면을 함께 제시합니다.

자료마다 분석 대상과 관찰 조건이 다릅니다.
VB의 문자열 구조표는 여러 버전을 다루지만 Elastic은 자신들이 분석한 특정 샘플의 구현을 설명합니다.
Elastic은 이 파일이 패킹되어 있어 본체 분석 전에 언패킹이 필요했다고 명시합니다.

Elastic의 행위 평가에는 C2 명령을 모사하는 Flask 서버도 사용됐습니다.
이 환경에서 지시한 명령과 관찰 결과는 실제 캠페인의 C2가 같은 명령을 보냈다는 증거와 구분해야 합니다.

출처 사이의 관계도 고려해야 합니다.
VB 보고서는 Elastic과 Proofpoint 자료를 인용하고 Proofpoint와 Team Cymru 자료는 하나의 공동 보고서입니다.
여러 문서에 같은 설명이 나온다는 이유만으로 서로 독립적인 관찰이 반복됐다고 셀 수는 없습니다.

• VB2025 — 버전별 구조와 참고문헌, 5·11쪽
• Elastic — LATRODECTUS analysis·Sandboxing LATRODECTUS
• Bitsight — Windows API resolution
• Proofpoint·Team Cymru — 공동 연구와 캠페인 관찰
• SOUPS 2024 — 인터뷰 연구의 대상과 분석 방법, 61쪽·§7.2

3. 문자열·설정 복원

버전에 따라 달라지는 저장 구조

문자열 복원은 암호화된 바이트열을 원래 문자열로 되돌리는 과정입니다.
C2 주소 등 숨겨진 데이터를 읽는 데 사용되며 VB 보고서는 이를 구성정보 추출의 기초로 설명합니다.
구성정보 추출은 이렇게 얻은 값과 다른 분석 결과에서 악성코드의 동작에 필요한 설정 항목을 식별하는 작업입니다.

VB2025의 문자열 암호화 표는 다음과 같이 구분합니다.

• v1.1a: PRNG를 사용하는 XOR 방식.
• v1.1b·v1.2·v1.3: 초기값을 증가시키는 Rolling XOR 방식.
• v1.4·v1.5·v1.7·v1.8: AES-256 CTR 방식.

그림 2. VB2025의 문자열 암호화 구조표, 5쪽. 표에 실린 버전의 알고리즘과 필드 위치를 비교합니다. 길이 관련 필드의 실제 계산 과정은 Elastic 코드와 함께 확인할 수 있습니다.

초기 XOR 계열의 데이터는 DLL의 .data 섹션에 저장됩니다.
앞 4바이트는 복원에 사용하는 초기값, 다음 2바이트는 길이 관련 정보이며 오프셋 6부터 암호문이 이어집니다.

AES 계열에서는 공통 키가 .text 섹션에 있고 .data의 문자열별 데이터가 길이 2바이트·IV 16바이트·암호문 순서로 구성됩니다.
여기서 공통 키란 해당 샘플 안의 문자열 복원에 공통으로 쓰는 키를 뜻합니다.

• VB2025 — 버전별 알고리즘과 문자열 저장 구조, 3·5쪽

Elastic 코드가 보여주는 길이 계산과 XOR

Elastic의 Python 코드는 앞 4바이트를 32비트 정수 x, 다음 2바이트를 16비트 정수 y로 읽습니다.
실제 복원 길이 L은 (x XOR y) & 0xffff입니다.
즉, 저장된 y를 그대로 문자열 길이로 사용하지 않고 두 값의 XOR 결과에서 하위 16비트를 취합니다.

암호문은 6바이트 헤더 다음에서 L바이트를 읽습니다.
바이트 위치 i를 0부터 세면 각 암호문 바이트와 XOR할 값은 (x + i + 1) & 0xff입니다.
첫 바이트에는 x + 1의 하위 8비트를 사용하고 이후 위치가 증가할 때마다 계산값도 바뀝니다.

그림 3. Elastic의 String obfuscation에 실린 HTML 코드를 렌더링한 발췌입니다. 원문 웹페이지의 스크린샷이나 실행 결과가 아니며, 초기값·길이 계산과 반복문 안의 바이트 연산을 보여줍니다. 중간 코드는 생략돼 있습니다.

VB 구조표와 Elastic 코드는 초기값·길이 정보·암호문의 배치를 공통으로 설명합니다.
VB가 데이터의 위치와 버전별 차이를 정리한다면, Elastic은 저장된 값으로 길이와 평문 바이트를 구하는 연산을 구체화합니다.
따라서 두 자료의 설명 차이는 구조와 처리 규칙을 연결해 주는 보완 관계로 읽을 수 있습니다.

다만 구조와 알고리즘 유형이 비슷하다고 같은 세부 버전이나 샘플로 확정할 수는 없습니다.
Elastic의 통신 예시에는 ver=1.1&up=4가 나오지만 파라미터 표는 up의 의미를 Unknown으로 둡니다.
이 값을 VB의 특정 세부 버전에 직접 대응시키기는 어렵습니다.

• Elastic — String obfuscation의 Python 코드와 Communication 파라미터
• VB2025 — 초기 XOR 계열 저장 구조, 5쪽

AES 전환과 구성정보 추출 결과

AES-CTR에서는 키를 사용해 카운터 블록을 암호화하고 그 결과인 키스트림을 암호문과 XOR해 평문을 얻습니다.
VB가 설명한 Latrodectus 샘플에서는 .text의 공통 키와 .data의 문자열별 IV·암호문을 읽어 해당 처리 과정을 재현할 수 있습니다.
복원에는 키와 IV뿐 아니라 길이와 카운터 처리 방식도 맞아야 합니다.

따라서 AES로 바뀌었다는 사실만으로 복원이 불가능해졌다고 판단할 수는 없습니다.
해당 샘플에 필요한 입력과 복원 코드가 있다면 이를 분석해 문자열을 되돌릴 수 있으며 기존 XOR 복원기를 그대로 적용하는 것은 맞지 않습니다.

그림 4. VB2025 Fig. 14, 10쪽의 v1.8 구성정보 추출 사례. 주소와 키는 원문이 보고한 샘플의 설정값입니다. 이 화면은 해당 주소와의 통신 성공을 보여주는 기록이 아닙니다.

VMRay Platform의 결과에는 C2 URL, 버전, mission ID, RC4·AES 키가 포함됩니다.
AES 키는 내부 문자열 복원에, RC4 키는 C2 통신 본문의 복원에 쓰이므로 용도가 다릅니다.
이 구성정보 화면을 Elastic의 XOR 코드로 같은 샘플을 복원한 결과로 해석해서는 안 되며 모든 키가 문자열 복원만으로 얻어졌다는 뜻도 아닙니다.

• VB2025 — AES 키·IV 저장 위치와 v1.8 설정 추출, 5·8–10쪽·Fig. 14
• NIST SP 800-38A — CTR 모드의 복호화 원리, §6.5

4. API 식별

DLL 이름에서 함수 주소까지

Latrodectus는 Windows 함수의 이름을 그대로 사용해 조회하는 대신, 이름에 CRC32를 계산한 값과 미리 준비된 목표값을 비교합니다.
CRC32 값은 대상을 찾기 위한 비교값이며 그 숫자가 실행할 함수의 주소가 되는 것은 아닙니다.

VB2025와 Bitsight가 설명하는 조회 과정은 다음과 같습니다.

1. 프로세스 정보를 담는 PEB를 통해 이미 로드된 kernel32.dll과 ntdll.dll의 시작 주소를 찾습니다. Bitsight의 조회 함수는 DLL 이름의 CRC32 목표값을 입력받습니다.
2. 추가 DLL은 Windows\System32에서 파일 이름을 같은 규칙으로 계산·비교해 찾고 LoadLibraryW로 로드합니다. VB는 user32.dll, wininet.dll, iphlpapi.dll을 예로 듭니다.
3. DLL의 export 함수 이름을 CRC32로 계산해 목표값과 비교한 뒤, 일치한 항목의 함수 주소를 얻어 저장합니다.

DLL의 시작 주소는 함수 목록을 살펴볼 출발점입니다.
그 주소만으로 원하는 API의 호출 주소를 알아낸 것은 아니므로 export 조회 과정까지 따라가야 합니다.

그림 5. Bitsight Fig. 8. GetAdaptersInfo 항목에는 DLL을 찾을 정보, 목표 해시와 함수 주소를 저장할 위치가 연결돼 있습니다. 아래 반복문은 각 항목을 조회해 결과를 저장하는 코드를 보여줍니다.

그림의 76–78행을 보면 목표 해시는 0x32A4B9E0, 대상 DLL은 iphlpapi.dll, 대응 함수는 GetAdaptersInfo입니다.
VB가 본문으로 설명한 조회 절차를 Bitsight의 구체적인 데이터 항목과 연결할 수 있습니다.
실행 중 이렇게 찾는 API는 정적 import 목록에 드러나지 않을 수 있으므로 목록 외에 조회 코드도 분석 대상이 됩니다.

• VB2025 — Runtime API resolving and API hashing, 5쪽·Fig. 6
• Bitsight — DLL 탐색과 API 조회, Windows API resolution·Fig. 6–8

함수 식별과 실제 호출의 차이

이 코드로 어떤 API를 조회하도록 구성했는지 식별할 수 있습니다.
특정 실행에서 그 API를 실제로 호출했는지, 무엇을 넘겼고 어떤 값을 받았는지는 실행 기록에서 확인해야 합니다.

VB 보고서는 GetAdaptersInfo로 얻은 네트워크 어댑터 정보의 하드웨어 주소 길이를 검사하는 코드도 제시합니다.
함수 이름과 주소를 찾는 데서 그치지 않고 반환된 정보가 어떤 비교와 분기에 쓰이는지 연결하면, 이 API가 해당 로직에서 수행하는 역할을 설명할 수 있습니다.

• Bitsight — API 조회 항목, Fig. 8
• VB2025 — GetAdaptersInfo와 주소 길이 검사, 3–4쪽·Fig. 3

5. 환경 검사와 관찰 범위

프로세스 수에 따른 종료 조건

VB2025가 분석한 Latrodectus는 Windows 10·11에서 실행 중인 프로세스가 75개 미만이면 종료합니다.
Windows 8.1 이하에서는 50개 미만을 기준으로 삼습니다.
Elastic 코드에서도 프로세스 수와 자체 운영체제 구분값을 함께 비교합니다.

그림 6. Elastic의 Anti-analysis에 실린 프로세스 수 검사 코드. os_version은 자체 구분값이므로 6을 Windows의 실제 주 버전 번호로 읽지 않습니다. 기준을 충족해도 다른 검사나 이후 통신의 성공까지 보장하지는 않습니다.

VB 저자는 가상환경에 일반 사용자 PC보다 실행 중인 프로그램이 적을 수 있다는 점을 들어 샌드박스 회피를 겨냥했을 가능성이 높다고 해석합니다.
코드가 직접 보여주는 사실은 운영체제와 프로세스 수에 따른 종료 조건입니다.
그 기준에 미달하는 시스템을 모두 샌드박스라고 분류할 수는 없습니다.

• VB2025 — Process count check, 3쪽
• Elastic — Anti-analysis의 프로세스 수·OS 검사

MAC 주소 검사에서 남는 확인 범위

VB 본문은 MAC 주소 길이가 6바이트가 아니면 종료한다고 설명합니다.
그러나 Fig. 3에는 길이와 6을 비교한 뒤 부호 없는 비교에서 ‘작거나 같음’에 해당하는 jbe 분기가 보입니다.
본문의 설명과 그림의 조건을 함께 검토할 필요가 있는 대목입니다.

그림 7. VB2025 Fig. 3, 4쪽. 아래쪽 블록에 cmp ... , 6과 jbe가 있습니다. 분기 이후의 전체 코드가 보이지 않아 이 그림만으로 최종 종료 조건을 확정하기는 어렵습니다.

이 차이를 근거로 새로운 종료 조건을 추정해 원문의 설명을 대체해서는 안 됩니다.
보이는 비교·분기와 보이지 않는 이후 실행 경로를 구분해야 합니다.

• VB2025 — MAC address validity, 3–4쪽·Fig. 3

다른 검사와 행위 미관찰의 해석

디버깅 검사는 현재 프로세스의 PEB에서 BeingDebugged 플래그를 직접 읽습니다.
WOW64 검사는 현재 프로세스가 64비트 Windows에서 32비트 프로세스로 실행되는지 확인하고 해당하면 종료하는 것으로 설명됩니다.

VB 저자는 당시 관찰한 DLL이 모두 64비트였으므로 일반적인 실행에서는 WOW64 종료 조건에 해당하지 않아 의도가 명확하지 않다고 밝힙니다.
일부 에뮬레이션 상황을 탐지하려는 시도일 가능성은 저자가 제시한 해석입니다.

이처럼 앞선 검사에서 종료할 수 있으므로 파일 생성이나 통신이 보이지 않았다고 해서 해당 기능이 없거나 파일이 정상이라고 판단할 수는 없습니다.
DLL 로드, 주요 함수 진입, 검사 단계의 종료는 서로 다른 실행 지점입니다.
SOUPS 연구의 §7.2도 목표 복호화 함수에 도달하기 위해 앞선 회피 검사를 처리하는 분석 절차를 설명합니다.

• VB2025 — BeingDebugged·WOW64 검사, 3–4쪽
• SOUPS 2024 — 목표 난독화 해제 코드에 도달하는 디버깅 절차, §7.2

예약 작업 설정과 실제 재실행

Elastic은 COM을 이용해 Updater라는 예약 작업을 만들고 로그인 시 실행하도록 설정한 사례를 설명합니다.
공개 화면에는 로그인 조건인 At log on과 활성화 상태인 Enabled가 표시됩니다.
같은 화면의 상태는 The task has not yet run (0x41303)입니다.

그림 8. Elastic의 Scheduled task properties 화면. 로그인 실행 설정과 캡처 시점의 작업 상태가 함께 보입니다. 이후 로그인에서 실제로 재실행됐는지를 보여주는 기록은 아닙니다.

Microsoft 문서에서 0x41303은 작업이 아직 실행되지 않았다는 상태입니다.
이 값을 재실행 실패로 해석하거나 악성코드 본체가 전혀 실행되지 않았다고 확대할 수는 없습니다.
작업에 실행 경로를 설정한 사실과 그 경로로 실제 재실행한 사실은 서로 다른 근거를 필요로 합니다.

• Elastic — Setup / persistence와 예약 작업 화면
• Microsoft — SCHED_S_TASK_HAS_NOT_RUN 상태값

6. 분석 방법의 강점과 한계

복원 규칙을 직접 구현하는 방법

Elastic의 공개 함수는 암호화된 바이트열에서 길이와 바이트별 연산을 계산해 복원된 데이터를 반환합니다.
입력과 처리 규칙이 코드로 명시되므로 분석가는 어떤 연산으로 결과를 얻는지 검토할 수 있습니다.
필요한 데이터를 확보했다면 DLL의 전체 실행 경로를 거치지 않고도 문자열을 복원할 수 있다는 장점이 있습니다.

그러나 입력 확보가 선행돼야 합니다.
Elastic의 샘플처럼 본체 분석 전에 언패킹이 필요할 수 있고 VB의 XOR 계열과 AES-CTR처럼 저장 구조와 알고리즘이 바뀌면 복원기도 그에 맞아야 합니다.
한 버전의 복원 코드를 다른 변형에 적용하려면 입력 형식과 계산 규칙이 유지되는지 확인해야 합니다.

• Elastic — LATRODECTUS analysis·String obfuscation
• VB2025 — 버전별 저장 구조와 알고리즘, 3·5쪽

샘플이 복원한 데이터를 메모리에서 읽는 방법

SOUPS 2024 연구는 복호화·난독화 해제 코드를 찾고 해당 처리가 끝난 지점에 중단점을 설정한 뒤 디버거에서 실행해 메모리의 복원 데이터를 추출하는 절차를 설명합니다.
샘플 자체의 코드를 이용하므로 같은 알고리즘을 별도로 재구현하는 부담을 줄일 수 있습니다.

그림 9. SOUPS 2024 Fig. 4, 인쇄 70쪽. 분석가 인터뷰에서 정리한 일반적인 난독화 해제 절차입니다. Latrodectus에 직접 적용해 검증한 실험 결과로 제시된 그림은 아닙니다.

이 방법은 복원 결과가 메모리에 존재하는 지점까지 도달할 수 있어야 합니다.
앞선 환경 검사로 실행이 중단된다면 해당 검사를 처리하거나 목표 함수에 필요한 입력을 준비하는 추가 작업이 필요합니다.
연구 자체에도 인터뷰 참여자의 회상 누락과 자기보고 편향이라는 한계가 있습니다.

• SOUPS 2024 — 난독화 해제 절차와 연구 한계, §7.2·Fig. 4·§10

적용 조건과 추가로 필요한 증거

두 방법의 차이는 어디에서 복원 결과를 얻는가에 있습니다.

문자열이나 설정을 얻은 뒤에도 실제 행위와 연결하려면 추가 근거가 필요합니다.
VB의 설정 추출 화면, Bitsight의 API 조회 코드, Elastic의 예약 작업 화면은 각각 설정값·조회 대상·실행 설정을 보여줍니다.
서로 다른 샘플과 환경의 자료를 한 번의 실행 기록으로 연결할 수는 없습니다.

선택한 자료의 관찰 범위를 보완하는 방향으로 다음을 제안할 수 있습니다.

• 통신과 API 호출: 요청 전송·응답 수신 기록, API에 넘긴 인자와 반환값을 해당 실행 경로에 연결합니다.
• 예약 작업: 등록된 실행 대상과 로그인 이후의 프로세스 생성·명령행 기록을 대조합니다.
• 환경 검사: 비교에 쓰인 값과 실제 선택된 분기를 함께 기록해 종료 또는 후속 코드 도달을 확인합니다.

이는 추가 검증 방향이며 이 글에서 수행한 실험 결과는 아닙니다.

• VB2025 — 환경 검사·구성정보 추출, 3–6·10쪽
• Elastic — String obfuscation·Setup / persistence·Sandboxing LATRODECTUS
• Bitsight — Windows API resolution·Fig. 6–8
• SOUPS 2024 — 복원 지점 도달과 메모리 추출, §7.2

7. 종합 판단

VB2025의 버전별 구조표는 Latrodectus의 문자열이 어디에 어떤 형태로 저장되는지 비교하는 데 유용합니다.
Elastic의 계산 코드를 함께 읽으면 그 필드에서 실제 길이와 평문 바이트를 구하는 규칙까지 연결할 수 있습니다.
API 조회도 VB의 절차 설명과 Bitsight의 DLL·해시·함수 포인터 항목을 대조하면 구체적인 조회 대상을 파악할 수 있습니다.

이 자료들의 강점은 구조와 구현, 관찰 결과를 서로 보완한다는 데 있습니다.
그 과정에서 설정값의 추출, 함수의 식별, 실행 조건의 존재가 각각 무엇을 입증하는지 구분해야 합니다.
기능을 설명하는 코드와 특정 환경에서 실제로 발생한 행위를 연결할 때 분석의 범위도 분명해집니다.

이 글의 판단은 2024–2025년 공개 자료가 다룬 버전·샘플·관찰 조건에 한정됩니다.
다른 변형을 분석할 때는 문자열 구조와 복원 규칙, API 조회 방식, 환경 검사 조건이 같은지 해당 파일에서 다시 확인해야 합니다.

• VB2025 — 버전별 구조와 분석 결과, 3–6·10쪽
• Elastic — 문자열 복원과 샌드박스 분석
• Bitsight — DLL·API 조회 코드
• SOUPS 2024 — 분석 절차와 적용 조건, §7.2

AI 활용 범위

자료 조사와 원고 정리에는 Codex를 활용했으며 바탕이 된 비평문의 문장 다듬기에는 Astra와 Gemini를 사용했습니다.
기술 설명은 공개 원문과 코드·표·캡처에 대조했습니다.
본문 이미지는 원문에서 가져온 자료이며 독립적인 악성코드 실행 결과를 제시한 글은 아닙니다.

참고문헌

1. Zsigovits, A. (2025). Arachnid alert: Latrodectus loader crawls through defences. Virus Bulletin Conference 2025. VMRay. 기술 보고서.
2. Proofpoint Threat Research & Team Cymru S2. (2024, April 4). Latrodectus: This Spider Bytes Like Ice. 캠페인·기술 공동 분석.
3. Stepanic, D., & Bousseaden, S. (2024, May 16). Spring Cleaning with LATRODECTUS: A Potential Replacement for ICEDID. Elastic Security Labs. 문자열 복원·동적 분석.
4. Batista, J. (2024, June 17). Latrodectus, are you coming back? Bitsight. API 조회·통신 분석.
5. Yong Wong, M., Landen, M., Li, F., Monrose, F., & Ahamad, M. (2024). Comparing Malware Evasion Theory with Practice: Results from Interviews with Expert Analysts. Twentieth Symposium on Usable Privacy and Security (SOUPS 2024), 61–80. USENIX Association. 학술 논문.
6. Dworkin, M. (2001). Recommendation for Block Cipher Modes of Operation: Methods and Techniques. NIST Special Publication 800-38A, §6.5. CTR 모드 공식 정의.
7. Microsoft. Task Scheduler Error and Success Constants. SCHED_S_TASK_HAS_NOT_RUN 항목. 예약 작업 상태값 공식 문서.