Nemesis

내일 업데이트를 푸시하고, 라이선스를 변경하며, 데이터 스틸러에 대항하는 몇 가지 새로운 몬스터도 추가할 예정입니다.

악성 샘플에서 jlaive 포크들을 계속 보다가, 실제로 런타임에 분해할 만한 공개 도구가 없어서 짜증나서 만든 윈도우 도구입니다.

간단히 말해, 네이티브 레이어에서 CLR을 후킹하고, 리플렉티브 어셈블리 로드를 추적하며, PE를 메모리에서 직접 자동 덤프하는 .NET 프로세스 모니터입니다. 또한 원본 온디스크 바이너리와 비교하여 AMSI 및 ETW 무결성을 확인하고, clr.dll 문자열 패치 및 직접 LoadFromBuffer 사용과 같은 우회 기술을 탐지합니다.

샘플은 어디서 구하나요? https://tria.ge 를 추천합니다 (광고 아님). 원하는 샘플을 다운로드하고 패밀리별로 필터링할 수 있습니다.

이름의 의미?

왜 이름이 nemesis일까 궁금할 수 있습니다.

이 도구의 정확한 목적을 나타내기 때문입니다. nemesis는 상대방에게 끊임없는 도전이나 몰락을 의미하는 존재이며, 이것이 이 프로젝트의 아이디어입니다.

그리스 신화에서 nemesis는 신성한 응보의 정령으로, 너무 오만하거나 자신이 무적이라고 생각하는 자에게 응징을 내리는 존재였습니다. "FUD"라고 자랑하는 멀웨어에게는 딱 맞는 이름이라고 생각합니다.

왜 만들어졌나

저는 멀웨어 분석가입니다. 이 일을 오래 하다 보면(취미로 하는 저에게는) 특히 jlaive(일명 crybat)이 유행하고 모든 스크립트 키디가 포크를 만들면서, 동일한 로더 체인을 계속 보게 됩니다.

패턴은 어리석을 정도로 간단하지만 다루기는 정말 성가십니다:

something.bat  →  난독화된 powershell  →  csharp 스텁  →  실제 페이로드

단어 샐러드처럼 보이는 .bat을 더블클릭하면 cmd가 쓰레기 코드 벽으로 powershell을 실행합니다. powershell이 .NET 스텁(aes, gzip, base64)을 복호화/압축해제합니다. 그 스텁은 amsi + etw를 패치하고, 실제 exe/dll을 메모리에 리플렉티브 로드합니다. 끝입니다. 유용한 형태로 디스크에 기록되는 것은 없습니다.

그게 마음에 걸렸습니다. 이 특정 체인, 즉 .NET 페이로드가 실제로 나타나는 곳을 후킹하고, 프로세스가 자체적으로 소멸되기 전에 덤프를 뜨고, 이런 스텁들이 항상 하는 amsi/etw 패치를 잡아내는 공개 도구가 제대로 없었습니다. 그래서 nemesis를 만들었습니다.

만능 해결책은 아닙니다. 샌드박스를 대체하지도 않습니다. 하지만 의심스러운 .bat을 테스트 박스에서 실행하고 실제 아티팩트를 꺼낼 수 있는 실용적인 도구를 제공합니다.

실제 기능

론처 (Launcher.exe)

• 대상(exe, bat, cmd 등)을 일시 중단 상태로 생성
• 메인 스레드가 실행되기 전에 Nemesis.dll을 인젝션
• nemesis가 준비되었다고 알릴 때까지 대기
• 재개합니다. 대상이 powershell 자식 프로세스를 생성하면 론처가 그것들에도 인젝션 가능

nemesis dll (Nemesis.dll)

• jlaive 스타일 스텁이 실제로 사용하는 CLR 로드 경로를 후킹:
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer (nLoadImage에서 해석된 패턴)
• 리플렉티브 PE가 메모리에 나타나면 -> %TEMP%\Nemesis_dumps에 덤프 대기열 추가
• 현재 메모리의 amsi.dll / ntdll.dll 익스포트를 온디스크 복사본과 비교 (고전적인 ret 패치를 AmsiScanBuffer / EtwEventWrite에 잡아냄)
• CLR이 로드될 때 AMSI 검사는 CLR의 .rdata 문자열도 확인 (일부 우회는 그것들을 패치함; vxug에 훌륭한 논문이 있습니다: 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf)
• 콘솔(컬러) + %TEMP%\Nemesis.log에 로깅. 또한 ENABLE_VIRTUAL_TERMINAL_PROCESSING을 활성화하여 콘솔이 이상하게 동작하는 문제를 방지합니다 :D

기본적으로: bat 체인을 실행하고, 크립터가 실제로 페이로드를 로드하는 지점에서 잡아내고, 우회 트릭을 로깅합니다.

증명:

빌드

Visual Studio 2022+와 C++ 데스크톱 + MASM (x64) 필요.

Nemesis.slnx를 열고 Release | x64를 선택한 후 솔루션을 빌드합니다.

실제 대상에서 실행

이것이 실제 사용 사례입니다. 의심스러운 bat을 지정하고 어떤 결과가 나오는지 확인합니다:

cd x64\Release
.\Launcher.exe "C:\path\to\suspicious.bat"

-- 뒤의 추가 인자는 대상에 전달됩니다:

.\Launcher.exe myapp.exe -- --some-flag

사용자 정의 dll 경로:

.\Launcher.exe --dll C:\path\Nemesis.dll myapp.exe

아티팩트:

• 로그 → %TEMP%\Nemesis.log
• 덤프된 PE → %TEMP%\Nemesis_dumps

nemesis는 무엇이고 무엇이 아닌가

무엇인가:

• jlaive 스타일 크립터(bat → ps1 → csharp 체인)를 위한 런타임 분석 도우미
• 샘플이 있을 때 메모리 내 덤프 + amsi/etw 텔레메트리를 얻기 위한 랩 VM에서 유용
• 다른 분석가들이 사용하고, 확장하고, 불평할 수 있도록 공개

무엇이 아닌가:

• EDR 대체재가 아님
• 모든 포크 변종을 잡는다고 보장하지 않음 (난독화 변경, 새로운 우회, 예: 패치리스 amsi/etw는 현재 대상이 아니며 추후 변경 예정) 아마도 이 프로젝트는 관리형 언어 툴킷으로 발전할 수도 있음

참고 사항

• 현재 CLR ASM 디토어는 x64 전용
• cmd.exe 호스트는 종종 CLR이 없으므로 nemesis가 준비 신호를 보내지 않으며 론처가 멈추지 않음; 실제 작업은 powershell/dotnet이 나타날 때 발생
• LNK1104로 빌드 실패? 아직 nemesis.dll이 로드되어 있음; 대상을 종료하고 재빌드
• pwsh.exe vcpkg 빌드 중 잡음은 무시해도 됨

추가 자료 (jlaive 생태계)

싸우는 상대를 이해하고 싶다면:

• Trend Micro on BatCloak / Jlaive — bat → ps1 → csharp 레이어 케이크
• Fortinet on ScrubCrypt — jlaive의 성가신 후속작; ScrubCrypt의 차이점은 .bat에서 파이프 기호로 명령을 파이프한다는 점인데, 꽤 잘 작동함...
• Unprotect.it — ScrubCrypt — 기법 분석
• https://github.com/backdoorskid/ClrAmsiScanPatcher - 앞서 언급한 .NET 문자열을 찾음; 해당 .pdf 파일을 읽어보길 권장합니다 :)

면책 조항

nemesis를 사용함으로써 이를 수락하는 것입니다. 아무런 보증 없이 있는 그대로 제공되며 — 모든 위험을 감수합니다.

귀하는 합법적이고 승인된 사용(랩 VM, 소유 시스템, 명시적 허가)에 대한 전적인 책임이 있습니다. 법률이 허용하는 최대 범위 내에서 저자와 zypherion.tech는 사용 또는 오용으로 인해 발생하는 모든 손해, 손실 또는 법적 청구에 대해 모든 책임을 부인합니다. 전체 약관은 LICENSE를 참조하십시오.

라이선스

비상업적 / 개인 / 연구 / 취미 용도 → PolyForm Noncommercial 1.0.0

상업적 사용(판매, 유료 제품, SaaS, 클라이언트 작업 등) → 별도 라이선스 필요. PolyForm Noncommercial은 해당 용도를 포함하지 않습니다.

상업 라이선스가 필요하면 연락주세요:

[[email protected] / @wd6g(discord) / telegram: @ZypherionTechnologies]

todo

참고: compilemethod를 확인하고 수정해야 함; 현재로서는 크립터가 보통 asm.load(...)를 사용하기 때문에 꼭 필요한 것은 아님... 또한 rdata 문자열을 제대로 테스트하지 못했음; 유감스럽게도... 바보 같은 코드로 PR하지 말아주세요. n(Native) 백엔드(예: nLoadImage)를 후킹하는 것은 일반적으로 레지스터를 보존해야 하며 까다롭기 때문에 asm을 사용합니다.