사이버 범죄 최전선 관찰: UNC6040 선제적 보안 강화 권장 사항

해당 블로그의 원문은 2025년 10월 1일 Google Cloud 블로그(영문)에 게재되었습니다. 

작성자: Omar ElAhdan, Matthew McWhirt, Michael Rudden, Aswad Robinson, Bhavesh Dhake, Laith Al

배경

서비스형 소프트웨어(SaaS) 플랫폼 및 애플리케이션을 보호하려면 포괄적인 보안 전략이 필요합니다. 이 가이드는 UNC6040의 특정 공격 방법론 분석을 바탕으로, 선제적 보안 강화 조치, 포괄적인 로깅 프로토콜, 그리고 고급 탐지 기능을 포함하는 구조화된 방어 프레임워크를 제시합니다. Salesforce에 특화된 보안 권장 사항에 중점을 두지만, 이러한 전략은 조직이 현재의 위협으로부터 SaaS 생태계를 보호하기 위한 실행 가능한 접근 방식을 제공합니다.

Google Threat Intelligence Group (GTIG)은 재정적 동기를 가진 위협 클러스터인 UNC6040을 추적하고 있습니다. 이들은 음성 피싱(vishing) 캠페인을 전문으로 하며, 특히 조직의 Salesforce 인스턴스를 침해하여 대규모 데이터 절취와 후속 공갈을 목적으로 합니다. 지난 몇 달 동안 UNC6040은 운영자가 IT 지원 인력을 사칭하는 설득력 있는 전화 기반 사회 공학 활동을 통해 네트워크를 반복적으로 성공적으로 침해했습니다. 이 접근 방식은 특히 다국적 기업의 영어 사용 지사 직원을 속여 공격자에게 접근 권한을 부여하거나 민감한 자격 증명을 공유하도록 유도하는 데 효과적임이 입증되었으며, 궁극적으로 조직의 Salesforce 데이터 절취를 용이하게 합니다. 관찰된 모든 사례에서 공격자들은 Salesforce 자체에 내재된 취약점을 익스플로잇하는 것이 아니라 최종 사용자를 조작하는 데 의존했습니다.

UNC6040 운영의 일반적인 전술은 피해자를 속여 조직의 Salesforce 포털에 악성 연결 앱(malicious connected app)을 승인하도록 하는 것입니다. 이 애플리케이션은 종종 Salesforce의 Data Loader를 수정(modified)한 버전이며, Salesforce의 승인을 받지 않은 버전입니다. 음성 피싱 통화 중에 공격자는 피해자를 안내하여 Salesforce의 연결 앱 설정 페이지를 방문하고, 정식 버전과 이름이나 브랜딩이 다른 Data Loader 앱 버전을 승인하도록 유도합니다. 이 단계는 UNC6040에게 침해된 Salesforce 고객 환경에서 민감한 정보에 직접 접근, 쿼리 및 유출할 수 있는 상당한 기능을 의도치 않게 부여합니다. 악성 연결 앱을 통한 Data Loader 기능 오용 방법론은 Salesforce가 이러한 위협으로부터 Salesforce 환경을 보호하기 위한 지침에서 상세히 설명한 최근 관찰 내용과 일치합니다.

일부 사례에서는 UNC6040 침입 활동 초기 이후 몇 달이 지나서야 공갈 활동이 관찰되기도 했는데, 이는 UNC6040이 훔친 데이터 접근 권한으로 수익을 창출하는 두 번째 위협 행위자와 제휴했을 수 있음을 시사합니다. 이러한 공갈 시도 중에 공격자는 피해자에게 가하는 압력을 높이기 위한 방법으로, 잘 알려진 해킹 그룹 ShinyHunters와의 연관성을 주장했습니다.

UNC6040 침해 피해 사례에서 다음과 같은 주요 패턴이 관찰되었습니다.

• 동기: UNC6040은 재정적 동기를 가진 위협 클러스터이며, 음성 피싱(vishing) 사회 공학을 통해 피해자 네트워크에 접근합니다.

• Focus: 접근 권한을 획득하면 UNC6040은 Salesforce의 Data Loader 애플리케이션을 사용하여 피해자의 Salesforce 환경에서 데이터를 즉시 유출하는 것이 관찰되었습니다. 이 초기 데이터 절취 이후, UNC6040은 자격 증명 수집(credential harvesting) 또는 음성 피싱을 통해 획득한 최종 사용자 자격 증명을 활용하여 피해자 네트워크 내에서 측면 이동을 수행했습니다. 이들은 Okta 및 Microsoft 365와 같은 다른 클라우드 플랫폼에 있는 피해자의 계정에 접근하고 데이터를 유출하는 것이 관찰되었습니다.

• 공격 인프라: UNC6040은 주로 Mullvad VPN IP 주소를 사용하여 피해자의 Salesforce 환경 및 네트워크의 다른 서비스에 접근하고 데이터 유출을 수행했습니다.

선제적 보안 강화 권장 사항

다음 섹션은 UNC6040이 사용하는 전술로부터 보호하기 위해 우선순위를 정한 권장 사항을 제공합니다. 이 섹션은 다음 범주로 나뉩니다.

1. ID
   • 헬프 데스크 및 최종 사용자 확인 
   • ID 유효성 검사 및 보호
2. SaaS 애플리케이션
   • SaaS 애플리케이션 (예: Salesforce) 강화 조치
3. 로깅 및 탐지

참고: 다음 권장 사항에는 SaaS 애플리케이션을 보호하기 위한 전략이 포함되어 있지만, ID 공급자(IdP) 계층에서 적용 가능한 ID 보안 통제 및 탐지, 그리고 헬프 데스크와 같은 기존 프로세스에 대한 보안 강화도 다룹니다.

1. ID

긍정적인 신원 확인

점점 더 정교해지는 사회 공학 및 자격 증명 침해 공격으로부터 보호하기 위해, 조직은 신원 확인을 위한 강력하고 다계층적인 프로세스를 채택해야 합니다. 이 프로세스는 오래되고 쉽게 침해되는 방법을 넘어, 모든 지원 요청, 특히 계정 수정 (예: 암호 재설정 또는 다중 인증 수정)과 관련된 요청에 대해 더 높은 수준의 신뢰를 확립합니다.

지침 원칙

• 아무것도 가정하지 마십시오: 발신자가 주장하는 신원을 본질적으로 신뢰하지 마십시오. 모든 보안 관련 요청에 대해 확인은 필수입니다.
• 심층 방어 (Defense-in-depth): 여러 확인 방법을 조합하여 사용하십시오. 단일 요소만으로는 위험도가 높은 작업을 수행하기에 충분해서는 안 됩니다.
• 안전하지 않은 식별자 거부: 공개적으로 이용 가능하거나 쉽게 발견할 수 있는 데이터에 의존하는 것을 피하십시오. 다음과 같은 정보는 피해야 합니다.

  • 생년월일

  • 사회 보장 번호(SSN) 끝 네 자리

  • 고등학교 이름

  • 상사 이름

이러한 데이터는 데이터 유출을 통해 자주 침해되거나 OSINT(공개 출처 정보)를 통해 얻을 수 있으므로 주요 확인 요소로 사용되어서는 안 됩니다.

표준 확인 절차

실시간 화상 신원 증명 (주요 방법)

이는 발신자를 식별하는 가장 신뢰할 수 있는 방법입니다. 헬프 데스크 상담원은 다음을 수행해야 합니다.

1. 사용자와 화상 통화를 시작합니다.

2. 사용자에게 유효한 회사 배지 또는 정부 발행 사진이 부착된 ID (예: 운전면허증)를 얼굴 옆 카메라에 제시하도록 요청합니다.

3. 화상 통화상의 인물이 ID의 사진과 일치하는지 육안으로 확인합니다.

4. 사용자의 얼굴을 내부 회사 ID 시스템의 사진과 교차 참조합니다.

5. ID상의 이름이 직원의 회사 기록에 있는 이름과 일치하는지 확인합니다.
   
   화상 통화 불가 시 비상 대책: 실시간 화상 통화가 불가능한 경우, 사용자는 자신의 얼굴, 사진 ID, 그리고 현재 날짜와 시간이 적힌 종이를 함께 보여주는 셀카를 제공해야 합니다.
   
   또한, 헬프 데스크 직원은 요청을 진행하기 전에 사용자의 캘린더에서 부재 중(OOO) 또는 휴가 상태를 확인해야 합니다. OOO로 표시된 사용자로부터의 모든 요청은 공식적으로 복귀할 때까지 잠정적으로 거부되어야 합니다.

대역 외(Out-of-Band, OOB) 확인 (고위험 요청의 경우)

다중 인증(MFA) 재설정 또는 특권 계정의 암호 변경과 같은 고위험 변경의 경우, 초기 ID 증명 후 추가적인 OOB 확인 단계가 필요합니다. 여기에는 다음이 포함될 수 있습니다.

• 콜백: 등록된 전화 번호로 사용자에게 전화를 겁니다.

• 관리자 승인: 확인된 회사 통신 채널을 통해 사용자의 직속 관리자에게 확인 요청을 보냅니다.

제3자 공급업체 요청에 대한 특별 처리 

Mandiant는 공격자가 제3자 공급업체의 지원 인력을 사칭하여 접근 권한을 얻는 사건을 관찰했습니다. 이러한 상황에서는 표준 확인 원칙이 적용되지 않을 수 있습니다.

어떠한 상황에서도 헬프 데스크는 접근을 허용해서는 안 됩니다. 상담원은 요청을 중단하고 다음 절차를 따라야 합니다.

1. 어떤 접근 권한이나 정보도 제공하지 않고 인바운드 통화를 종료합니다.

2. 신뢰할 수 있고 파일에 등록된 연락처 정보를 사용하여 해당 공급업체의 지정된 계정 관리자에게 독립적으로 연락합니다.

3. 요청을 진행하기 전에 계정 관리자로부터 명시적인 확인을 받아야 합니다.

최종 사용자 대상 홍보

Mandiant는 위협 행위자 UNC6040이 SaaS 애플리케이션에 대한 권한 있는 접근 권한을 가진 최종 사용자를 표적으로 삼는 것을 관찰했습니다. 공급업체 또는 지원 인력을 사칭하여 UNC6040은 이 사용자들에게 악성 링크를 제공합니다. 사용자가 링크를 클릭하고 인증하면, 공격자는 애플리케이션에 접근하여 데이터를 유출합니다.

이러한 위협을 완화하기 위해 조직은 모든 최종 사용자에게 모든 제3자 요청을 확인하는 것의 중요성을 철저하게 전달해야 합니다. 확인 절차에는 다음이 포함되어야 합니다.

• 전화를 끊고 파일에 등록된 전화번호를 사용하여 공식 계정 관리자에게 전화하는 것

• 요청자에게 공식 회사 지원 포털을 통해 티켓을 제출하도록 요구하는 것

• 지원 콘솔에서 확인할 수 있는 유효한 티켓 번호를 요구하는 것

조직은 또한 최종 사용자가 의심스러운 통신을 보고할 수 있는 명확하고 접근 가능한 프로세스를 제공하고, 이 보고 메커니즘이 모든 보안 인식 홍보에 포함되도록 보장해야 합니다.

Salesforce는 참조할 수 있는 추가 지침을 제공합니다.

ID 보호

SaaS 애플리케이션에 대한 접근은 일반적으로 중앙 ID 공급자(예: Entra ID, Okta)에 의해 관리되므로, Mandiant는 조직이 이러한 플랫폼 내에서 통합된 ID 보안 통제를 직접 시행할 것을 권장합니다.

지침 원칙

Mandiant의 접근 방식은 다음 핵심 원칙에 중점을 둡니다.

• 인증 경계 (Authentication boundary): 이 원칙은 네트워크 컨텍스트를 기반으로 하는 신뢰의 기본 계층을 설정합니다. 민감한 리소스에 대한 접근은 정의된 경계 내에서 제한되어야 하며, 신뢰할 수 있는 위치와 신뢰할 수 없는 위치를 명확하게 구분하기 위해 주로 신뢰할 수 있는 회사 네트워크 및 VPN에서의 연결을 허용해야 합니다.

• 심층 방어 (Defense-in-depth): 이 원칙은 보안이 단일 통제에 의존할 수 없음을 지시합니다. 조직은 강력한 인증, 장치 규정 준수 검사 및 세션 통제와 같은 다중 보안 조치를 계층화해야 합니다.

• ID 탐지 및 대응 (Identity detection and response): 조직은 접근 결정에 실시간 위협 인텔리전스를 지속적으로 통합해야 합니다. 이는 ID가 침해되거나 위험한 행동을 보이는 경우, 위협이 해결될 때까지 접근이 자동으로 격리되거나 차단되도록 보장합니다.

ID 보안 통제

다음 통제는 중앙 ID 공급자를 통해 SaaS 애플리케이션에 대한 접근을 보호하는 데 필수적입니다.

단일 로그인(SSO) 활용

SaaS 애플리케이션에 접근하는 모든 사용자가 플랫폼 자체 계정이 아닌 회사에서 관리하는 SSO 공급자 (예: Microsoft Entra ID 또는 Okta)를 통해 접근하도록 보장하십시오. 플랫폼 자체의 긴급 상황용 비상 계정(break glass account)은 생성하여 금고에 보관하고 긴급 상황에서만 사용해야 합니다.

회사에서 관리하는 공급자를 통한 SSO가 불가능한 경우, Microsoft Entra ID 또는 Okta가 아닌 해당 SaaS 애플리케이션(예: Salesforce)에 특화된 내용을 참조하십시오.

피싱 저항성 MFA 의무화

SaaS 애플리케이션에 접근하는 모든 사용자에게 피싱 저항성 MFA를 의무화해야 합니다. 이는 자격 증명 절취 및 계정 탈취에 대비하기 위한 기본 요건입니다. 특권 접근 권한을 가진 계정에 대해서는 물리적 FIDO2 키 사용을 고려하십시오. 비즈니스 중요 애플리케이션과 연결된 인증 정책에 MFA 우회 경로가 존재하지 않도록 보장하십시오.

Microsoft Entra ID의 경우:

• 일반 MFA 정책: 조건부 액세스를 통해 모든 사용자에게 MFA를 의무화합니다.

• 패스키 (FIDO2) 설정: 패스키 및 FIDO2 보안 키를 활성화합니다.

Okta의 경우:

• FIDO2 (WebAuthn) 구성: FIDO2 (WebAuthn) 인증 장치를 설정합니다.

• 정책을 통한 의무화: 강력한 인증 장치를 요구하는 인증 정책을 생성합니다.

Google Cloud Identity / Workspace의 경우:

• 일반 MFA 정책: 2단계 인증을 배포합니다.

• 보안 키 의무화: 2단계 인증에 보안 키를 사용합니다.

Salesforce의 경우:

• 로컬 Salesforce 계정에는 MFA가 기본적으로 필요합니다: Salesforce Multi-Factor Authentication FAQ

• FIDO2 (WebAuthn) 구성: Salesforce 조직의 ID 확인 방법으로 보안 키를 등록합니다.

장치 신뢰 및 규정 준수 의무화

회사 애플리케이션에 대한 접근은 도메인에 가입되었거나 조직의 보안 표준을 준수하는 것으로 확인된 장치로 제한되어야 합니다. 이 정책은 장치가 민감한 데이터에 접근하기 전에 최소한의 보안 기준을 충족하도록 보장합니다.

주요 장치 상태 확인에는 다음이 포함되어야 합니다.

• 유효한 호스트 인증서: 장치가 유효한 회사에서 발급한 인증서를 제시해야 합니다.

• 승인된 운영 체제: 엔드포인트가 현재 버전 및 패치 요구 사항을 충족하는 승인된 OS를 실행해야 합니다.

• 활성 EDR 에이전트: 회사 EDR(Endpoint Detection and Response) 솔루션이 설치, 활성화되어 있으며 정상 상태를 보고해야 합니다.

Microsoft Entra ID의 경우:

• 장치 준수 정책: 조건부 액세스를 통해 모든 사용자에게 규정을 준수하는 장치를 요구합니다.

Okta의 경우:

• 장치 신뢰 개요: 관리되는 장치에 대해 Okta 장치 신뢰를 구성합니다.

Google Cloud Identity / Workspace의 경우:

• 상황 인식 액세스: 상황 인식 액세스 개요
• 엔드포인트 확인: 엔드포인트 확인을 통해 장치에 대한 세부 정보를 모니터링하고 수집합니다.

ID 위협에 대한 대응 자동화

Mandiant는 조직이 위협에 실시간으로 대응하는 동적 인증 정책을 구현할 것을 권장합니다. 네이티브 플랫폼 서비스와 제3자 솔루션 모두에서 제공되는 ID 위협 인텔리전스 피드를 인증 프로세스에 통합함으로써, ID가 침해되거나 위험한 행동을 보일 때 자동으로 접근을 차단하거나 재확인하도록 할 수 있습니다.

이 접근 방식은 주로 두 가지 범주의 위험을 평가합니다.

• 위험한 로그인 (Risky sign-ins): 비정상적인 이동, 악성코드와 연결된 IP 주소 또는 암호 살포(password spray) 활동과 같은 요인으로 인해 인증 요청이 비합법적일 확률

• 위험한 사용자 (Risky users): 사용자의 자격 증명이 침해되었거나 온라인에 유출되었을 확률

감지된 위험 수준을 기반으로, Mandiant는 조직이 계층적 접근 방식을 대응에 적용할 것을 권장합니다.

권장되는 위험 기반 조치

• 고위험 이벤트의 경우: 조직은 가장 엄격한 보안 통제를 적용해야 합니다. 여기에는 접근을 완전히 차단하는 것이 포함됩니다.

• 중위험 이벤트의 경우: 상당한 수준의 확인 강화 후에만 접근을 허용해야 합니다. 이는 일반적으로 사용자 신원(강력한 MFA를 통해)과 장치 무결성(규정 준수 및 보안 상태 확인을 통해) 모두에 대한 증명을 요구하는 것을 의미합니다.

• 저위험 이벤트의 경우: 세션의 적법성을 보장하고 낮은 신뢰도의 위협을 완화하기 위해 표준 MFA와 같은 인증 강화 문제를 여전히 요구해야 합니다.

Microsoft Entra ID의 경우:

• 개요
• 구성

Okta의 경우:

• 행동 감지
• 위험 기반 정책

Google Cloud Identity / Workspace의 경우:

• 액세스 컨텍스트 관리자 개요: 상황 인식 액세스를 사용하여 세부적인 위험 기반 접근 정책을 생성합니다.

Salesforce Shield의 경우: 

• 개요

• 이벤트 모니터링: 데이터 접근, 기록 수정, 로그인 출처와 같은 사용자 작업에 대한 상세 로그를 제공하며, 이러한 로그를 외부 분석을 위해 내보낼 수 있도록 허용합니다.

• 트랜잭션 보안 정책: 대규모 데이터 다운로드와 같은 특정 사용자 활동을 모니터링하고, 발생 시 자동으로 경고를 트리거하거나 작업을 차단하도록 구성할 수 있습니다.

2. SaaS 애플리케이션 

Salesforce 표적 보안 강화 통제

이 섹션에서는 Salesforce 인스턴스에 적용할 수 있는 특정 보안 통제를 자세히 설명합니다. 이러한 통제는 Salesforce 내에서 광범위한 접근, 데이터 유출 및 민감한 데이터에 대한 무단 접근을 방지하도록 설계되었습니다.

네트워크 및 로그인 제어

로그인은 신뢰할 수 있는 네트워크 위치에서만 시작되도록 제한합니다.

네트워크 액세스 및 프로필 기반 IP 제한에 대한 Salesforce 지침을 참조하십시오.

IP 주소를 통한 로그인 제한

이 제어는 승인되지 않은 네트워크에서의 자격 증명 오용을 방지하여, 공격자가 유효한 사용자 자격 증명을 훔쳤더라도 액세스를 효과적으로 차단합니다.

• 프로필 수준에서 로그인 IP 범위를 정의하여 회사 및 신뢰할 수 있는 네트워크 주소에서만 액세스를 허용합니다.

• 세션 설정에서 "모든 요청에 로그인 IP 범위 적용(Enforce login IP ranges on every request)"을 활성화하여 기존 세션에 의해 확인이 우회되지 않도록 보장합니다.

신뢰할 수 있는 IP 범위 설정에 대한 Salesforce 지침을 참조하십시오.

애플리케이션 및 API 액세스 거버넌스

연결된 앱 및 API 액세스 관리

위협 행위자는 종종 일반 API 클라이언트와 도난당한 OAuth 토큰을 활용하여 대화형 로그인 제어를 우회합니다. 이 정책은 모델을 "기본적으로 허용(allow by default)"에서 "기본적으로 거부(deny by default)"로 전환하여, 검증된 애플리케이션만 연결할 수 있도록 보장합니다.

• "기본적으로 거부" API 정책 활성화: API 액세스 제어로 이동하여 "관리자가 승인한 사용자의 경우, API 액세스를 허용된 연결된 앱으로만 제한(For admin-approved users, limit API access to only allowed connected apps)"을 활성화합니다. 이는 승인되지 않은 모든 클라이언트를 차단합니다.

• 최소한의 애플리케이션 허용 목록 유지: 필수적인 연결된 앱만 명시적으로 승인합니다. 이 허용 목록을 정기적으로 검토하여 사용되지 않거나 승인되지 않은 애플리케이션을 제거합니다.

• 앱별 엄격한 OAuth 정책 적용: 승인된 각 앱에 대해 신뢰할 수 있는 IP 범위로 액세스 제한, MFA(다단계 인증) 적용, 적절한 세션 및 새로 고침 토큰 시간 제한 설정을 포함한 세부적인 보안 정책을 구성합니다.

• 앱 제거 시 세션 해지: 앱 액세스를 해지할 때, 관련된 모든 활성 OAuth 토큰과 세션도 해지하여 잔존 액세스를 방지하도록 보장합니다.

• 조직 프로세스 및 정책: 타사와 애플리케이션 통합을 관리하는 정책을 수립합니다. 비즈니스 핵심 애플리케이션(예: Salesforce, Google Workspace, Workday)과의 모든 통합에 대해 타사 위험 관리(Third-Party Risk Management) 검토를 수행합니다.

API 액세스 관리에 대한 Salesforce 지침을 참조하십시오.

사용자 권한 및 액세스 관리

최소 권한 원칙 구현

사용자는 자신의 업무 기능을 수행하는 데 필요한 절대적인 최소한의 권한만 부여받아야 합니다.

• "최소 액세스" 프로필을 기본값으로 사용: 최소 권한으로 기본 프로필을 구성하고 모든 신규 사용자에게 기본으로 할당합니다. "모두 보기(View All)" 및 "모두 수정(Modify All)" 권한 할당을 제한합니다.

• 권한 집합(Permission Sets)을 통해 권한 부여: 다수의 사용자 정의 프로필을 생성하는 대신, 직무 역할을 기반으로 잘 정의된 권한 집합을 통해 모든 추가 액세스를 부여합니다.

• 필수적이지 않은 사용자에 대한 API 액세스 비활성화: "API 활성화(API Enabled)" 권한은 Data Loader와 같은 도구에 필요합니다. 모든 사용자 프로필에서 이 권한을 제거하고, 통제된 권한 집합을 통해 소수의 정당한 사용자에게만 부여합니다.

• 비관리자 사용자로부터 '설정(Setup)' 메뉴 숨기기: 모든 비관리자 프로필에 대해 관리 "설정" 메뉴에 대한 액세스를 제거하여 무단 구성 변경을 방지합니다.

• 민감한 작업에 대한 고신뢰 세션 적용: 보고서 내보내기와 같은 민감한 작업에 고신뢰 세션을 요구하도록 세션 설정을 구성합니다.

세션 보안 설정 수정에 대한 Salesforce 지침을 참조하십시오.

고신뢰 세션 보안 요구 사항에 대한 Salesforce 지침을 참조하십시오.

"모두 보기(View All)" 및 "모두 수정(Modify All)" 권한에 대한 Salesforce 지침을 참조하십시오.

세부 데이터 액세스 정책

"비공개(Private)" 조직 전체 공유 기본값(OWD) 적용

• 모든 민감한 개체에 대해 내부 및 외부 조직 전체 기본값(OWD)을 "비공개(Private)"로 설정합니다.

• 역할 계층을 통한 광범위한 액세스에 의존하는 대신, 전략적인 공유 규칙(Sharing Rules) 또는 기타 공유 메커니즘을 사용하여 더 넓은 데이터 액세스를 부여합니다.

행 수준 보안을 위한 제한 규칙(Restriction Rules) 활용

제한 규칙은 다른 모든 공유 설정 위에 적용되는 필터 역할을 하여, 사용자가 볼 수 있는 레코드에 대한 세부적인 제어를 가능하게 합니다.

제한 규칙에 대한 Salesforce 지침을 참조하십시오.

Salesforce 지원 로그인 액세스 해지

민감한 데이터에 액세스하거나 기본 Salesforce 인스턴스에 대한 특권 액세스 권한이 있는 모든 사용자가 Salesforce 지원 액세스 권한 부여에 대해 엄격한 시간 제한을 설정하고 있는지 확인합니다.

모든 상시 요청을 해지하고, 특정 사용 사례에 대해서만 엄격한 시간 제한을 두고 다시 활성화합니다. 관리자 계정에서 이러한 권한 부여를 활성화하는 것에 주의하십시오.

Salesforce 지원 로그인 액세스 부여에 대한 Salesforce 지침을 참조하십시오.

Mandiant는 Salesforce 보안 상태 검사(Security Health Check) 도구를 실행하여 잘못된 구성을 식별하고 해결할 것을 권장합니다. 추가적인 강화 권장 사항은 Salesforce 보안 가이드를 참조하십시오

3. 로깅 및 탐지

Salesforce 표적 로깅 및 탐지 제어

이 섹션에서는 Salesforce 인스턴스에 대한 주요 로깅 및 탐지 전략을 설명합니다. 이러한 제어는 SaaS 환경 내에서 고도화된 위협을 식별하고 대응하는 데 필수적입니다.

SaaS 애플리케이션 로깅

위협 행위자가 SaaS 애플리케이션에 사용하는 전술, 기술 및 절차(TTP)에 대한 가시성을 확보하기 위해, Mandiant는 조직의 Salesforce 환경에서 중요한 로그 유형을 활성화하고 해당 로그를 보안 정보 및 이벤트 관리(SIEM) 시스템으로 수집할 것을 권장합니다.

로깅 전에 필요한 준비 사항

수집을 시작하거나 탐지 규칙을 작성하기 전에, 사용하려는 로그에 대한 조직의 권한이 실제로 있는지 그리고 올바른 기능이 활성화되어 있는지 확인하십시오 

1. 권한 확인 (필수)

1. 대부분의 보안 로그/기능은 Salesforce Shield 또는 이벤트 모니터링 추가 기능(Event Monitoring Add-On)을 통한 이벤트 모니터링 뒤에 숨겨져 있습니다. 이는 실시간 이벤트 모니터링(RTEM) 스트리밍 및 보기에 적용됩니다.

2. 사용 사례별 데이터 모델 선택

1. RTEM - 스트림 (거의 실시간 경고): Enterprise/Unlimited/Developer 구독에서 사용 가능하며, 스트리밍 이벤트는 약 3일간 보존됩니다.

2. RTEM - 스토리지: 다수는 Big Object(네이티브 스토리지)이며, 일부는 표준 개체입니다(예: 위협 탐지 스토어)

3. 이벤트 로그 파일 (ELF) - CSV 모델 (일괄 내보내기): Enterprise/Performance/Unlimited Edition에서 사용 가능합니다.

4. 이벤트 로그 개체 (ELO) - SOQL 모델 (쿼리 가능한 기록): Shield/추가 기능이 필요합니다.

3. 필요한 항목 활성화 (및 액세스 범위 지정)

1. 이벤트 관리자(Event Manager)를 사용하여 이벤트별 스트리밍 및 저장을 활성화/비활성화하고 RTEM 이벤트를 봅니다

2. 프로필/권한 집합을 통해 RTEM 및 위협 탐지 UI에 대한 액세스 권한을 부여합니다.

4. 위협 탐지 및 ETS

1. 위협 탐지 이벤트는 Shield/추가 기능으로 UI에서 볼 수 있으며, 해당 EventStore 개체에 저장됩니다.

2. 향상된 트랜잭션 보안(Enhanced Transaction Security, ETS)은 실시간 이벤트에 대한 차단/MFA/알림 작업을 위해 RTEM에 포함되어 있습니다.

모니터링 권장 로그 소스

• 로그인 기록 (LoginHistory): 사용자 이름, 시간, IP 주소, 상태(성공/실패) 및 클라이언트 유형을 포함하여 모든 로그인 시도를 추적합니다. 비정상적인 로그인 시간, 알 수 없는 위치, 또는 반복된 실패를 식별할 수 있어, 자격 증명 스터핑이나 계정 침해를 나타낼 수 있습니다.

• 로그인 이벤트 (LoginEventStream): Salesforce에 로그인하는 사용자의 로그인 활동을 추적합니다.

• 설정 감사 내역 (SetupAuditTrail): Salesforce 환경 내의 관리 및 구성 변경 사항을 기록합니다. 권한, 보안 설정 및 기타 중요 구성에 대한 변경 사항을 추적하는 데 도움이 되어 감사 및 규정 준수 노력을 용이하게 합니다.

• API 호출 (ApiEventStream): 사용자 또는 연결된 앱에 의해 이루어진 호출을 추적하여 API 사용 및 잠재적인 오용을 모니터링합니다.

• 보고서 내보내기 (ReportEventStream): 보고서 다운로드에 대한 통찰력을 제공하여 잠재적인 데이터 유출 시도를 탐지하는 데 도움을 줍니다.

• 목록 보기 이벤트 (ListViewEventStream): 목록 보기에 대한 사용자 상호 작용, 해당 보기 내 데이터 액세스 및 조작을 추적합니다. 

• 대량 API 이벤트 (BulkApiResultEvent): 사용자가 대량 API 요청의 결과를 다운로드할 때 추적합니다.

• 권한 변경 (PermissionSetEvent): 권한 집합 및 권한 집합 그룹에 대한 변경 사항을 추적합니다. 이 이벤트는 권한이 권한 집합에 추가되거나 제거될 때 시작됩니다.

• API 이상 (ApiAnomalyEvent): 사용자가 API 호출을 하는 방식의 이상을 추적합니다.

• 고유 쿼리 이벤트 유형: 처리된 특정 검색 쿼리(SOQL), 필터 ID, 보고서 ID와 기본 데이터베이스 쿼리(SQL)를 캡처합니다.

• 외부 ID 공급자 이벤트 로그: SSO를 사용한 로그인 시도 정보를 추적합니다. (IdP 이벤트 로그 모니터링 및 수집을 위해서는 귀사의 ID 공급자가 제공하는 지침을 따르십시오.)

이러한 로그 소스는 조직에 위협 행위자가 사용하는 일반적인 TTP를 적절하게 수집하고 모니터링할 수 있는 로깅 기능을 제공할 것입니다. 각 TTP에 대해 모니터링해야 할 핵심 로그 소스 및 관찰 가능한 Salesforce 활동은 다음과 같습니다.

SaaS 애플리케이션 탐지 

네이티브 SIEM 위협 탐지는 어느 정도 보호 기능을 제공하지만, 복잡한 환경 전반에 걸쳐 분산된 이벤트를 연결하는 데 필요한 중앙 집중식 가시성이 부족한 경우가 많습니다. 조직은 사용자 지정 표적 탐지 규칙을 개발하여 악의적인 활동을 사전에 탐지할 수 있습니다.

데이터 유출 및 크로스-SaaS 측면 이동 (인증 후)

MITRE 매핑: TA0010 - 유출 (Exfiltration) & TA0008 - 측면 이동 (Lateral Movement)

시나리오 및 목표

사용자가 (악성 또는 스푸핑된) 연결된 앱을 승인한 후, UNC6040과 같은 위협 행위자는 일반적으로 다음과 같은 행동을 수행합니다.

1. 데이터 유출을 신속하게 수행합니다 (REST 페이지네이션 버스트, 대량 API 다운로드, 대량/민감 보고서 내보내기).

2. 동일한 위험성이 있는 이그레스 IP에서 Okta/Microsoft 365로 피벗하여 액세스를 확장하고 더 많은 데이터를 훔칩니다.

여기서의 목표는 다음과 같은 활동을 탐지하는 것입니다.

• Salesforce OAuth → 유출 (Exfil) : $\le$10분 이내에 발생하는 활동 (동일한 위험 IP에서).

• Salesforce OAuth → Okta/M365 로그인 : $\le$60분 이내에 발생하는 활동 (동일한 위험 IP에서).

• 단일 신호, 낮은 노이즈의 유출 패턴을 탐지하는 것입니다.

기준선 및 허용 목록

피싱 단계에서 이미 유지 관리하고 있는 목록을 재사용하고, 콘텐츠 집중을 위한 두 가지 정규식(regex) 도우미를 추가합니다.

• STRING

• ALLOWLIST_CONNECTED_APP_NAMES 

• KNOWN_INTEGRATION_USERS (user ids/emails that legitimately use OAuth)

• VPN_TOR_ASNS (ASNs as strings)

• CIDR

• ENTERPRISE_EGRESS_CIDRS (your corporate/VPN public egress)

• REGEX

• SENSITIVE_REPORT_REGEX

(?i)\b(all|export|dump)\b.*\b(contact|lead|account|customer|pii|email|phone|ssn)\b

• • M365_SENSITIVE_GRAPH_REGEX

(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/(users|me)/messages
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/drives/.*/items/.*/content
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/reports/
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/users(\?|$)

고신뢰 탐지 카탈로그 (의사 코드) 

Salesforce OAuth → 데이터 유출 (Exfil) 10분 이내 (다중 이벤트)

동일 사용자에 대해 의심스러운 OAuth 성공이 발생한 후 10분 이내에 대량 데이터 유출 활동이 이어지는 경우를 탐지합니다.

이 규칙은 UNC6040와 같은 위협 행위자의 "승인 → 유출" 공격 패턴을 포착하기 위한 가장 정확도가 높은 규칙 중 하나입니다.

핵심 신호:

• OAuth 성공 (알 수 없는 앱에 대한 승인 또는 허용 목록에 있지만 위험성이 있는 외부 발신(egress) IP를 통한 승인), 사용자에게 바인딩.

• 그 후 다음 중 하나:

• BulkApiResultEvent (대규모 RowsProcessed/RecordCount 포함)

• ApiEventStream (다수의 query/queryMore 호출)

• ReportEventStream (대용량/민감 보고서 내보내기)

• 목록 및 제어 변수: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS, SENSITIVE_REPORT_REGEX.

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$bulk.metadata.product_name = "SALESFORCE"
$bulk.metadata.log_type = "SALESFORCE"
$bulk.metadata.product_event_type = "BulkApiResultEvent"
$uid = coalesce($bulk.principal.user.userid, $bulk.extracted.fields["UserId"])

match:
$uid over 10m

또는

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

match:
$uid over 10m

또는

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$report.metadata.product_name = "SALESFORCE"
$report.metadata.log_type = "SALESFORCE"
$report.metadata.product_event_type = "ReportEventStream"
strings.to_lower(coalesce($report.extracted.fields["ReportName"], "")) in regex SENSITIVE_REPORT_REGEX
$uid = coalesce($report.principal.user.userid, $report.extracted.fields["UserId"])

match:
$uid over 10m

참고: 이 경우 다중 이벤트 규칙 대신 단일 이벤트 규칙을 사용할 수도 있으며, 이때 ApiEventStream, BulkApiResultEvent, ReportEventStream과 같은 제품 이벤트 유형만을 모니터링할 단일 이벤트 규칙으로 활용할 수 있습니다. 하지만, 단일 이벤트 규칙을 설정할 경우 노이즈가 매우 클 수 있으므로 주의해야 하며, 따라서 참조 목록을 적극적으로 모니터링해야 합니다.

대량 API 대용량 결과 다운로드 (비통합 사용자)

사람 사용자(Human User)가 임계값을 초과하는 Bulk API/Bulk v2 결과 다운로드를 수행하는 행위.

고신뢰 이유: 명확한 데이터 유출(Exfil) 아티팩트(Artifact)이기 때문.

핵심 신호: BulkApiResultEvent, 사용자가 KNOWN_INTEGRATION_USERS에 포함되지 않음.

목록 및 제어 변수: KNOWN_INTEGRATION_USERS, 크기 임계값.

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "BulkApiResultEvent"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)

REST 쿼리 페이지네이션 버스트 (query/queryMore)

짧은 시간 창 내에 높은 속도로 query*/queryMore 호출이 발생하는 행위.

고신뢰 이유: 스크립트화된 데이터 유출(drains) 행위와 유사하며, 일반적인 사람 사용자는 버스트 임계값에 도달하지 않기 때문.

핵심 신호 (Key Signals): ApiEventStream 발생, Operation이 query, queryMore, query_all, queryall 중 하나에 해당, 10분 이내에 count가 임계값을 초과, 사용자가 KNOWN_INTEGRATION_USERS에 포함되지 않음.

목록 및 제어 변수: 버스트 임계값 (burst threshold), KNOWN_INTEGRATION_USERS

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
not (coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($api.extracted.fields["Operation"], "")) in regex `(?i)^(query|querymore|query_all|queryall)$`
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

비통합 사용자의 민감 보고서 대용량 내보내기

사람 사용자(Human User)가 대용량이거나 민감한 이름을 가진 보고서를 내보내는 행위.

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "ReportEventStream"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($e.extracted.fields["ReportName"], "")) in regex %SENSITIVE_REPORT_REGEX

Salesforce OAuth → Okta/M365 Login 동일 위험 IP 로그인 ≤60 이내 (다중 이벤트)

의심스러운 Salesforce OAuth 이벤트가 발생한 후, 60분 이내에 동일한 공용 IP를 통해 Okta 또는 Entra ID로 로그인이 발생하는 행위입니다. 이때 해당 IP는 기업 네트워크 외부이거나 VPN/Tor ASN과 연결되어 있어야 합니다.

고신뢰 이유: 공격자의 외부 발신(egress) IP를 엄격한 시간 창 내에서 복수의 SaaS 환경에 걸쳐 연결.

핵심 신호:

• Salesforce OAuth 상태: 알 수 없는 앱에 대한 승인 또는 허용 목록에 있지만 위험성이 있는 외부 발신(egress) IP를 통한 승인.

• 동일 IP에서 발생한 OKTA* 또는 OFFICE_365 USER_LOGIN 이벤트.

목록 및 제어 변수: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS (선택 사항: ID가 정규화된 경우).

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$ip = coalesce($oauth.principal.asset.ip, $oauth.principal.ip)

$okta.metadata.log_type in "OKTA"
$okta.metadata.event_type = "USER_LOGIN"
$ip = coalesce($okta.principal.asset.ip, $okta.principal.ip) = $ip

$o365.metadata.log_type = "OFFICE_365"
$o365.metadata.event_type = "USER_LOGIN"
$ip = coalesce($o365.principal.asset.ip, $o365.principal.ip)

match:
$ip over 10m

위험한 로그인 후 M365 Graph 데이터 풀

위험성이 있는 외부 발신(egress) IP를 통한 Entra ID(구 Azure AD) 로그인이 발생한 후, 해당 계정이 메일/파일/보고서를 풀(pull)하는 Microsoft Graph 엔드포인트에 액세스하는 행위.

고신뢰 이유: 계정 탈취(Account Takeover) 후 발생하는 일반적인 로그인 후 데이터 액세스 행위를 포착.

핵심 신호: OFFICE_365 USER_LOGIN 이벤트가 기업 네트워크 외부(off-corp) IP 또는 VPN/Tor ASN에서 발생. 그 후 동일한 계정에 의해 수 시간 이내에 M365_SENSITIVE_GRAPH_REGEX와 일치하는 URL로의 HTTP 통신 발생.

목록 및 제어 변수: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS, M365_SENSITIVE_GRAPH_REGEX

$login.metadata.log_type = "OFFICE_365"
$login.metadata.event_type = "USER_LOGIN"
$ip  = coalesce($login.principal.asset.ip, $login.principal.ip)
( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
 or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$acct = coalesce($login.principal.user.userid, $login.principal.user.email_addresses)

$http.metadata.product_name in ("Entra ID","Microsoft")
($http.metadata.event_type = "NETWORK_HTTP" or $http.target.url != "")
$acct = coalesce($http.principal.user.userid, $http.principal.user.email_addresses)
strings.to_lower(coalesce($http.target.url, "")) in regex %M365_SENSITIVE_GRAPH_REGEX

match:
$acct over 30m

조정 및 예외 처리

• 식별자 연결 - 측면 이동 규칙(lateral rule)은 견고성을 위해 IP 주소별로 그룹화합니다. If you have strong identity normalization (Salesforce <-> Okta <-> M365), clone it and match on user email instead of IP.

• 시간 창 변경 - 승인된 데이터 마이그레이션이나 연결된 앱 온보딩 기간 동안에는 시간에 구애받는 규칙을 일시적으로 중지(Suppress)하십시오. 이 기간 동안에는 공급업체 앱을 일시적으로 ALLOWLIST_CONNECTED_APP_NAMES에 추가할 수 있습니다. 

• 통합 계정 (Integration Accounts) 관리 - KNOWN_INTEGRATION_USERS를 최신 상태로 유지하십시오. 유출(exfil) 규칙에서 발생하는 대부분의 노이즈는 예약된 ETL(추출, 변환, 로드) 작업에서 비롯됩니다.

• 외부 발신(Egress) 위생 관리 - ENTERPRISE_EGRESS_CIDRS를 최신 상태로 유지하십시오. 오래된 NAT/VPN 범위는 VPN/Tor 탐지 결과를 부풀릴 수 있습니다.

   

• 스트리밍 대 저장된 이벤트 (Streaming vs Stored) - 앞서 언급된 규칙들은 실시간 이벤트 모니터링 스트림 객체 (예: ApiEventStream, ReportEventStream, ListViewEventStream, BulkApiResultEvent)를 사용한다고 가정합니다. 과거 추적(historical hunts)을 위해서는, 동일한 로직을 사용하여 저장된 해당 객체 (예: ApiEvent, ReportEvent, ListViewEvent)를 쿼리하십시오

IOC 기반 탐지

시나리오 및 목표

악의적인 위협 행위자가 조직의 네트워크에 성공적으로 액세스했거나 액세스를 시도했습니다.

목표는 사용 가능한 모든 로그를 기반으로 환경 내에서 알려진 UNC6040의 침해 지표(IOC) 존재 여부를 탐지하는 것입니다.

참조 목록

조직이 유지 관리해야 하는 참조 목록은 다음과 같습니다.

• STRING

• UNC6040_IOC_LIST (위협 인텔리전스 소스(예: VirusTotal)에서 가져온 IP 주소 목록 등 침해 지표(IOC) 목록입니다.)

침해지표(IOCs) 목록.

고신뢰 탐지 카탈로그 (의사 코드)

UNC6040 IP 침해 지표(IoC) 탐지

조직 환경에서 소스 또는 대상 연결로부터 UNC6040과 관련된 알려진 침해 지표(IOC)가 탐지되었습니다.

• 고신뢰 이유: 소스 또는 대상 IP 주소가 알려진 UNC6040 IOC와 일치할 때 고신뢰 탐지로 간주됩니다.

($e.principal.ip in %unc6040_IoC_list) or ($e.target.ip in %unc6040_IoC_list)

감사의 말

이 가이드를 구축하는 데 협력하고 도움을 주신 Salesforce에게 감사드립니다.