서문

7월에 Google은 애플리케이션 바인딩 암호화라는 새로운 보호 메커니즘을 발표했습니다. 이러한 보안 구현이 맬웨어 생태계에 직접적인 영향을 미치고 기준을 높인 것은 의심할 여지가 없습니다. 이 새로운 기능이 출시된 지 몇 달이 지난 후, 많은 인포스틸러는 시장에서 경쟁력을 유지하고 Chrome 브라우저에서 쿠키 데이터를 안정적으로 검색하는 기능을 제공하기 위해 이 보호 기능을 우회하는 새로운 코드를 작성했습니다(Chrome 보안팀에서 예측한 대로).

Elastic Security Labs는 이러한 활동의 하위 집합을 추적하여 여러 멀웨어 제품군이 앱 바운드 암호화를 우회하기 위해 사용하는 여러 기술을 확인했습니다. 이러한 압박에 따라 생태계는 여전히 진화하고 있지만, 저희의 목표는 조직이 이러한 기법을 이해하고 방어하는 데 도움이 되는 기술적 세부 사항을 공유하는 것입니다. 이 글에서는 다음 인포스틸러 제품군에서 사용하는 다양한 방법을 다룹니다:

• STEALC/VIDAR
• METASTEALER
• 페메드론
• 제노스틸러
• LUMMA

핵심 사항

• 최신 버전의 인포스틸러는 애플리케이션 바운드 암호화를 사용하여 Google의 최신 쿠키 보호 기능을 우회하는 우회 방법을 구현합니다.
• 기술에는 공격적 보안 도구 ChromeKatz 통합, COM을 활용하여 Chrome 서비스와 상호 작용하고 앱에 바인딩된 암호화 키를 해독하는 방법, Chrome 내 원격 디버깅 기능 사용 등이 있습니다.
• 방어자는 단기 및 중기적으로 등장할 수 있는 향후 완화 및 우회 기법을 예상하여 Windows 기반 Chrome에 대한 다양한 쿠키 우회 기법을 적극적으로 모니터링해야 합니다.
• Elastic Security는 메모리 시그니처, 행동 규칙, 헌팅 기회를 통해 완화 기능을 제공하여 인포스틸러 활동을 더 빠르게 식별하고 대응할 수 있도록 지원합니다.

배경

일반적으로 쿠키는 웹 애플리케이션에서 방문자가 해당 웹 앱에 액세스하는 데 사용하는 브라우저에 방문자 정보를 저장하는 데 사용됩니다. 이 정보는 웹 앱이 해당 사용자, 선호도 및 기타 정보를 여러 기기에서 위치 간에 추적하는 데 도움이 됩니다.

인증 토큰은 최신 웹 상호 작용의 대부분을 가능하게 하는 클라이언트 측 데이터 저장 구조의 한 가지 용도입니다. 이러한 토큰은 사용자가 웹 애플리케이션으로 성공적으로 인증한 후 브라우저에 저장됩니다. 사용자 이름과 비밀번호, 일회용 비밀번호 또는 생체 인식을 통한 다단계 인증(MFA) 후 웹 애플리케이션은 이후 웹 요청 시마다 이 토큰을 교환하여 브라우저를 사용자임을 '기억'합니다.

유효한 인증 토큰에 액세스한 악의적인 공격자는 이를 재사용하여 해당 웹 서비스의 사용자를 사칭하여 계정을 탈취하거나 개인 또는 금융 정보를 훔치거나 금융 자산 이체와 같은 다른 작업을 수행하는 데 해당 사용자로 위장할 수 있습니다.

사이버 범죄자들은 이러한 유형의 정보를 훔쳐서 상품화하여 금전적 이득을 취하기 위해 인포스틸러를 이용합니다.

Google 크롬 쿠키 보안

기존 버전의 Windows용 Google 크롬은 Windows 기본 데이터 보호 API (DPAPI)를 사용하여 쿠키를 암호화하고 다른 사용자 컨텍스트로부터 쿠키를 보호했습니다. 이는 여러 공격 시나리오에 대해 적절한 보호 기능을 제공했지만, 표적 사용자의 컨텍스트에서 실행되는 악성 소프트웨어는 DPAPI 메서드를 사용하여 이러한 쿠키를 직접 해독할 수 있습니다. 안타깝게도 이러한 상황은 인포스틸러들이 초기 접근을 위해 소셜 엔지니어링을 시도하는 틈새 시장과 정확히 일치합니다. API를 사용한 로컬 복호화부터 마스터키를 훔쳐 원격으로 복호화하는 방법, 기업 환경에서 도메인 전체 백업 DPAPI 키를 악용하는 방법 등 여러 공격 벡터를 통해 공격자들에게 DPAPI 체계는 이제 잘 알려져 있습니다.

2024년 7월 Chrome 127 출시와 함께 Google은 브라우저 데이터의 애플리케이션 바인딩 암호화를 구현했습니다. 이 메커니즘은 쿠키를 포함하여 Windows Chrome 브라우저 데이터에 대한 많은 일반적인 DPAPI 공격에 직접 대응합니다. 이를 위해 데이터를 암호화된 데이터 파일에 저장하고 시스템으로 실행되는 서비스를 사용하여 모든 복호화 시도가 Chrome 프로세스에서 발생하는지 확인한 후 저장된 데이터의 복호화를 위해 해당 프로세스에 키를 반환합니다.

이 암호화 체계가 모든 브라우저 데이터를 보호하는 만병통치약은 아니지만(Chrome 보안팀도 발표문에서 인정했듯이) 멀웨어 제작자를 보다 명백하게 악의적이고 방어자가 식별하고 대응하기 쉬운 TTP로 유도하는 데는 성공적이라고 생각합니다.

도용자 우회 기술 요약

다음 섹션에서는 Elastic에서 관찰한 Google의 앱 바운드 암호화 기능을 우회하는 데 사용되는 특정 인포스틸러 기술에 대해 설명합니다. 이 목록이 우회 방법을 모두 정리한 것은 아니며 이러한 제품군의 개발은 현재 진행 중이지만, 인포스틸러 영역에서 멀웨어 개발자들이 최근 업데이트된 Google의 보안 제어에 어떻게 대응했는지를 보여주는 흥미로운 역학 관계를 나타냅니다. 저희 팀이 관찰한 기술은 다음과 같습니다:

• Chrome의 개발자 도구 프로토콜을 통한 원격 디버깅
• Chrome 네트워크 서비스 프로세스의 프로세스 메모리 읽기(ChromeKatz 및 ReadProcessMemory (RPM))
• SYSTEM 으로 상승한 다음 COM을 통해 GoogleChromeElevationService 의 DecryptData 방법으로 app_bound_encryption_key 을 해독합니다.

STEALC/VIDAR

저희 팀은 9월 20일경 쿠키 우회 기법과 관련된 새로운 코드가 STEALC/VIDAR에 도입된 것을 확인했습니다. 이는 이전 버전에서 눈에 띄는 비정형 샘플로, 조건부 검사와 함께 임베디드 64비트 PE 파일로 구현되었습니다. 이제 Chrome이 데이터를 저장하는 SQLite 데이터베이스의 암호화된 값 앞에 v20이 붙는데, 이는 해당 값이 애플리케이션 바인딩 암호화를 사용하여 암호화되었음을 나타냅니다.

2023 에서 소개된 STEALC는 RACOON과 VIDAR와 같은 기존의 다른 스틸러에서 "많은 영감을 받아" 개발되었습니다. STEALC와 VIDAR는 동시 개발을 계속해 왔으며, 앱 바운드 암호화 우회의 경우 동일한 구현에 정착했습니다.

데이터베이스에서 암호화된 데이터를 추출하는 동안 멀웨어는 이 접두사가 있는지 확인합니다. v20으로 시작하면 바이너리의 .data 섹션에 포함된 PE 파일을 사용하여 자식 프로세스가 스폰됩니다. 이 프로그램은 Chrome의 하위 프로세스 중 하나에 있는 암호화되지 않은 쿠키 값을 추출하는 역할을 합니다.

이 임베디드 바이너리는 OpenDesktopA / CreateDesktopA 을 통해 숨겨진 데스크톱을 만든 다음 CreateToolhelp32Snapshot 을 사용하여 모든 chrome.exe 프로세스를 검사하고 종료합니다. 그러면 새 데스크톱 개체를 사용하여 새 chrome.exe 프로세스가 시작됩니다. 설치된 Chrome 버전에 따라 멀웨어는 쿠키를 관리하는 데 사용되는 내부 구성 요소인 Chromium 기능 CookieMonster의 서명 패턴을 선택합니다.

저희는 시그니처 패턴을 사용하여 ChromeKatz라는 공격용 보안 툴을 위해 개발된 기존 코드를 피벗했습니다. 현재 해당 패턴은 ChromeKatz 저장소에서 제거되었으며 새로운 기술로 대체되었습니다. 분석 결과, 멀웨어 작성자는 앱에 바인딩된 암호화 보호 기능을 우회하기 위해 STEALC 내에 ChromeKatz를 다시 구현한 것으로 보입니다.

악성코드가 일치하는 서명을 식별하면 Chrome의 하위 프로세스를 열거하여 --utility-sub-type=network.mojom.NetworkService 명령줄 플래그가 있는지 확인합니다. 이 플래그는 프로세스가 모든 인터넷 통신을 처리하는 네트워크 서비스임을 나타냅니다. MDSec의 게시물에 설명된 대로 공격자가 원하는 민감한 데이터를 보유하고 있기 때문에 주요 표적이 됩니다. 그런 다음 특정 하위 프로세스에 대한 핸들을 반환합니다.

그런 다음 네트워크 서비스 하위 프로세스의 각 모듈을 열거하여 메모리에 로드된 chrome.dll 의 기본 주소와 크기를 찾아서 검색합니다. STEALC는 CredentialKatz::FindDllPattern와 CookieKatz::FindPattern를 사용하여 쿠키몬스터 인스턴스를 찾습니다. CredentialKatz::FindDllPattern에 2 개의 호출이 있습니다.

CredentialKatz::FindDllPattern에 대한 첫 번째 호출에서는 chrome.dll에서 서명 패턴 중 하나(피해자의 Chrome 버전에 따라 다름)를 찾으려고 시도합니다. 바이트 시퀀스가 시작되는 메모리 위치에 대한 참조 포인터(CookieMonster 클래스의 소멸자 net::CookieMonster::~CookieMonster 함수)가 발견되면 STEALC는 이제 해당 메모리 위치에 대한 참조 포인터를 갖게 됩니다.

CredentialKatz::FindDllPattern 에 대한 두 번째 호출은 바이트 시퀀스 검색을 위한 인수로 net::CookieMonster::~CookieMonster(void) 의 함수 주소를 전달하여 STEALC가 CookieMonster의 가상 함수 포인터 구조체에 대한 포인터를 갖게 됩니다.

STEALC가 사용하는 다음 방법도 ChromeKatz와 동일하며, chrome.dll 모듈에서 CookieMonster vtable을 참조하는 포인터에 대한 메모리 청크를 스캔하여 CookieMonster 인스턴스를 찾습니다. vtable은 주어진 클래스의 모든 객체에 걸쳐 상수이므로 모든 CookieMonster 객체는 동일한 vtable 포인터를 갖습니다. 일치하는 항목이 식별되면 STEALC는 메모리 위치를 CookieMonster 인스턴스로 처리하고 해당 주소를 배열에 저장합니다.

식별된 CookieMonster 인스턴스 각각에 대해 STEALC는 +0x30의 오프셋에 위치한 내부 CookieMap 구조에 액세스하며, 이 구조는 이진 트리입니다. 이 트리 내의 각 노드에는 CanonicalCookieChrome 구조에 대한 포인터가 포함되어 있습니다. CanonicalCookieChrome 구조에는 암호화되지 않은 쿠키 데이터가 저장되어 있어 추출에 액세스할 수 있습니다. 그런 다음 STEALC는 첫 번째 노드를 전용 트래버스 함수에 전달하여 트리 트래버스를 시작합니다.

각 노드에 대해 ReadProcessMemory 을 호출하여 대상 프로세스의 메모리에서 CanonicalCookieChrome 구조에 액세스한 다음 jy::GenerateExfilString에서 추가 처리합니다.

STEALC는 만료일을 UNIX 형식으로 변환하고 HttpOnly 및 Secure 플래그가 있는지 확인하여 추출된 쿠키 데이터의 형식을 지정합니다. 그런 다음 쿠키의 이름, 값, 도메인, 경로, HttpOnly 및 Secure 과 같은 세부 정보를 최종 문자열에 추가하여 유출합니다. 문자열 대신 OptimizedString 구조체가 사용되므로 문자열 값은 문자열 자체가 되거나 문자열 길이가 23보다 큰 경우 문자열을 저장하는 주소를 가리킬 수 있습니다.

METASTEALER

2022년에 처음 발견된 메타스틸러는 최근 Chrome 데이터를 훔치는 기능을 업그레이드하여 Google의 최신 방어 노력을 우회했습니다. 9월 30일, 악성코드 작성자는 텔레그램 채널을 통해 이 업데이트를 발표하며, 크롬 버전 129+의 보안 변경에도 불구하고 쿠키를 포함한 민감한 정보를 추출하는 기능이 강화되었다고 강조했습니다.

저희 팀이 야생에서 관찰한 첫 번째 샘플은 저자들이 업데이트를 홍보한 날인 9월 30일에 발견되었습니다. 이 멀웨어는 Administrator 권한이 없어도 작동한다고 주장하지만, 테스트 결과 실행 중에 SYSTEM 토큰을 가장하려고 시도하기 때문에 상승된 액세스 권한이 필요한 것으로 나타났습니다.

위의 스크린샷에서 볼 수 있듯이 get_decryption 메서드에는 이제 새로운 부울 매개 변수가 포함됩니다. 이 값은 암호화된 데이터(쿠키)가 v20 접두사로 시작하는 경우 TRUE 로 설정되며, 이는 쿠키가 Chrome의 최신 암호화 방법을 사용하여 암호화되었음을 나타냅니다. 업데이트된 기능은 이전 버전과의 호환성을 유지하며 감염된 컴퓨터에 있는 경우 이전 Chrome 버전의 쿠키 암호 해독을 계속 지원합니다.

그런 다음 멀웨어는 Chrome 프로필 디렉터리에 있는 Local State 또는 LocalPrefs.json 파일에 액세스를 시도합니다. 두 파일 모두 JSON 형식이며 이전 Chrome 버전의 경우 암호화 키(encrypted_key)를, 최신 버전의 경우 app_bound_encrypted_key 을 저장합니다. 플래그가 TRUE로 설정되어 있으면 악성 코드는 업데이트된 Chrome 암호화 방법에 따라 app_bound_encrypted_key 를 사용하여 쿠키를 해독합니다.

이 경우 악성 코드는 먼저 ContextSwitcher이라는 새로 도입된 클래스를 사용하여 SYSTEM 토큰을 가장합니다.

그런 다음 GoogleChromeElevationService이라는 암호 해독을 담당하는 Chrome 서비스의 COM을 통해 CLSID 708860E0-F641-4611-8895-7D867DD3675B을 사용하여 인스턴스를 생성하여 키를 해독합니다. 초기화되면 DecryptData 메서드를 호출하여 암호화된 쿠키의 암호를 해독하는 데 사용되는 app_bound_encrypted_key 키를 해독합니다.

메타스틸러는 9월 27일 X에서 공유된 요지에서 시연된 것과 유사한 기법을 사용하며, 이는 멀웨어 작성자에게 영감을 준 것으로 보입니다. 두 가지 접근 방식 모두 유사한 방법을 활용하여 Chrome의 암호화 메커니즘을 우회하고 민감한 데이터를 추출합니다.

페메드론

이 오픈 소스 도둑은 올해 초에 Windows 스마트스크린 취약점(CVE-2023-36025)을 사용하여 전 세계의 주목을 받았습니다. 아직 텔레그램에서 개발이 진행 중이지만, 저희 팀은 9월말에 새로운 크롬용 쿠키 그래버 기능이 포함된 최근 릴리즈 (2.3.2)를 발견하였습니다.

이 악성 코드는 먼저 Chrome 내의 여러 프로필을 열거한 다음 함수(BrowserHelpers.NewEncryption)를 사용하여 브라우저 검사를 수행하여 버전이 127보다 크거나 같은 Chrome 브라우저를 확인합니다.

조건이 일치하면 PHEMEDRONE은 도우미 기능의 조합을 사용하여 쿠키를 추출합니다.

ChromeDevToolsWrapper 클래스와 그 다양한 기능을 보면 PHEMEDRONE이 쿠키에 액세스하기 위해 Chrome 내에서 원격 디버깅 세션을 설정한다는 것을 알 수 있습니다. 기본 포트(9222)는 -2400,-2400 으로 설정된 창 위치와 함께 사용되며, 화면 밖에서 설정되어 눈에 보이는 창이 피해자에게 경고하지 못하도록 합니다.

다음으로, 악성 코드는 더 이상 사용되지 않는 Chrome DevTools 프로토콜 메서드(Network.getAllCookies)를 사용하여 요청을 하는 Chrome의 디버깅 인터페이스에 대한 WebSocket 연결을 설정합니다.

그런 다음 이전 요청에서 쿠키가 일반 텍스트로 반환되며, 아래는 이 동작을 보여주는 네트워크 캡처입니다:

제노스틸러

제노스틸러는 GitHub에서 호스팅되는 오픈 소스 인포스틸러입니다. 7월 2024 에 출시되었으며 이 글을 게시하는 시점에 활발히 개발 중입니다. 특히 Chrome 우회 기능은 9월 26, 2024일에 커밋되었습니다.

제노스틸러의 접근 방식은 메타스틸러의 접근 방식과 유사합니다. 먼저 지정된 Chrome 프로필 아래의 JSON 파일을 구문 분석하여 app_bound_encrypted_key을 추출합니다. 그러나 암호 해독 프로세스는 Chrome 프로세스 내에서 이루어집니다. 이를 위해 XENOSTEALER는 Chrome.exe 인스턴스를 시작한 다음 SharpInjector이라는 헬퍼 클래스를 사용하여 코드를 삽입하고 암호화된 키를 매개변수로 전달합니다.

삽입된 코드는 GoogleChromeElevationService 에서 DecryptData 메서드를 호출하여 해독된 키를 얻습니다.

LUMMA

10월 중순,@g0njxa의 보고에 따라 최신 버전의 LUMMA는 Chrome 쿠키 보호를 우회하는 새로운 방법을 구현했습니다.

LUMMA의 최신 버전을 분석한 결과, 최신 버전의 Google Chrome(130.0.6723.70)에서 쿠키 데이터를 성공적으로 복구한 것을 확인했습니다. LUMMA는 먼저 Kernel32!CreateProcessW을 통해 눈에 보이는 Chrome 프로세스를 생성합니다.

이 활동은 디버거에서 NtReadVirtualMemory 에 대한 여러 호출을 통해 chrome.dll에 대한 Chrome 프로세스 내에서 LUMMA를 검색하는 것을 확인했습니다.

발견되면 악성 코드는 NtReadVirtualMemory을 사용하여 chrome.dll 이미지를 자체 프로세스 메모리에 복사합니다. 크롬캣츠 기법과 유사한 방식으로 루마는 패턴 스캐닝을 활용하여 크롬의 CookieMonster 컴포넌트를 타겟팅합니다.

Lumma는 난독화된 서명 패턴을 사용하여 CookieMonster 기능을 정확히 찾아냅니다:

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

아래는 난독화 해제 후의 YARA 규칙입니다:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

chrome.dll에서 패턴을 디코딩하고 검색한 후 CookieMonster 소멸자(net::CookieMonster::~CookieMonster)로 이어집니다.

그런 다음 쿠키가 메모리에서 식별되고 Chrome 프로세스에서 일반 텍스트로 덤프됩니다.

완료되면 LUMMA는 요청된 다른 데이터와 함께 쿠키를 여러 개의 zip 파일(또는 암호화 및 base64 인코딩)로 C2 서버로 전송합니다.

탐지

다음은 정보 도용자가 사용하는 기술을 식별하는 데 사용할 수 있는 행동 탐지 기능입니다:

• 비정상적인 프로세스를 통한 웹 브라우저 자격 증명 액세스
• 서명되지 않은 프로세스를 통한 웹 브라우저 자격 증명 액세스
• 의심스러운 메모리에서 브라우저 자격 증명 액세스
• 웹 브라우저 파일에 대한 액세스 시도 실패
• 비정상적인 부모로부터의 브라우저 디버깅
• 잠재적 브라우저 정보 검색

또한 다음 쿼리를 사용하여 다양한 관련 비정상 행위를 추적할 수 있습니다:

비정상적인 프로세스를 통한 쿠키 액세스

이 쿼리는 파일 열기 이벤트를 사용하여 프로세스별로 액세스를 집계한 다음 고유 호스트에서 관찰되고 총 액세스 횟수가 적은 액세스를 찾습니다:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

아래는 새로운 Chrome 쿠키 탈취 기능이 업데이트된 것을 포함하여 다양한 정보 탈취 프로그램의 일치 예시입니다:

메타스틸러 동작은 먼저 실행 중인 모든 크롬 인스턴스를 종료한 다음 CoCreateInstance을 호출하여 Google Chrome 고도 향상 서비스를 인스턴스화하는 경향이 있으며, 이러한 일련의 이벤트는 다음 EQL 쿼리로 표현할 수 있습니다:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

이전 추적은 의심스러운 에이전트는 표시하지만 소스 프로세스는 식별하지 못합니다. 이벤트 4663을 통해 레지스트리 개체 액세스 감사를 활성화하면 Chrome Elevation 서비스 CLSID 레지스트리 키 {708860E0-F641-4611-8895-7D867DD3675B}에서 해당 키에 액세스를 시도하는 비정상적인 프로세스를 감지할 수 있습니다:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

다음은 CoCreateInstance (CLSID_Elevator)을 호출하는 동안 메타스틸러 멀웨어에서 일치하는 예시입니다:

페메드론 스틸러는 알려진 브라우저 디버깅 방법을 사용하여 Chromium API를 통해 쿠키를 수집하는데, 다음 스크린샷에서 포트 9222를 통해 디버깅이 활성화된 브라우저 인스턴스와 통신하는 NodeJs 인스턴스를 볼 수 있습니다:

다음 EQL 쿼리를 사용하여 유사한 동작을 수행하는 비정상적인 프로세스를 찾을 수 있습니다:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

특이한 부모에서 생성된 크롬 브라우저

ChromeKatz 구현을 사용하는 STEALC 샘플은 구글 크롬 인스턴스를 생성하여 사용자 기본 프로필을 로드하고, 정상적인 부모 실행 파일을 찾지만 크롬 서명 부모와 Explorer.exe로 제한되어 있는 것으로 나타났습니다, 다음 ES|QL 쿼리를 사용하여 비정상적인 부모를 찾을 수 있습니다:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Chrome 애플리케이션 폴더의 신뢰할 수 없는 바이너리

Chrome 승격 서비스는 Chrome program files 폴더에서 실행되는 바이너리를 신뢰하므로 다음 쿼리를 사용하여 해당 폴더에서 실행되거나 로드된 서명되지 않거나 신뢰할 수 없는 바이너리를 검색할 수 있습니다:

구글 크롬 애플리케이션 폴더에서 로드된 서명되지 않은 DLL

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

구글 크롬 애플리케이션 폴더에서 서명되지 않은 실행 파일 실행

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

결론

Google은 Chrome 내에서 쿠키 데이터를 보호하기 위해 새로운 보안 제어 기능을 구현하는 기준을 높였습니다. 예상대로 멀웨어 개발자들은 자체적인 우회 방법을 개발하거나 통합했습니다. 앞으로도 Google은 사용자 데이터를 더욱 강력하게 보호하기 위해 혁신을 거듭할 것입니다.

조직과 방어자는 비정상적인 엔드포인트 활동을 지속적으로 모니터링해야 합니다. 이러한 새로운 기술은 성공적일 수 있지만, 적절한 보안 도구, 프로세스 및 인력을 갖추지 않으면 잡음이 발생하고 탐지될 수 있습니다.

스틸러 바이패스 및 MITRE ATT&CK

Elastic은 위협이 엔터프라이즈 네트워크에 대해 사용하는 일반적인 전술, 기술 및 절차를 문서화하기 위해 MITRE ATT& CK 프레임워크를 사용합니다.

전술

전술은 기술 또는 하위 기술의 이유를 나타냅니다. 이는 적의 전술적 목표, 즉 행동을 수행하는 이유입니다.

• 자격 증명 액세스
• 방어 회피
• 탐색
• 실행

기술

기술은 공격자가 행동을 수행하여 전술적 목표를 달성하는 방법을 나타냅니다.

• 웹 세션 쿠키 도용
• 프로세스 인젝션
• 비밀번호 저장소의 자격 증명
• 시스템 정보 검색
• 프로세스 검색
• 프로세스 간 통신: 컴포넌트 객체 모델

YARA

Elastic Security는 이 활동을 식별하기 위해 YARA 규칙을 만들었습니다.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

관찰

모든 관측값은 ECS 및 STIX 형식으로도 다운로드할 수 있습니다.

이 연구에서는 다음과 같은 관찰 가능성에 대해 논의했습니다.

참고 자료

위의 조사에서 참조한 내용은 다음과 같습니다:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html