Slack은 이제 많은 조직에서 핵심적인 협업 플랫폼으로 자리 잡았습니다. 조직 내외의 커뮤니케이션부터 프로젝트 워크플로까지, 다양한 업무가 Slack을 중심으로 운영되고 있습니다. 하지만 사용이 늘어날수록 위험도 함께 증가합니다. Slack에는 지적 재산, 인증 정보, 그리고 탐색에 활용할 수 있는 다양한 정보가 포함되어 있어, 공격자들에게 매우 매력적인 표적이 되고 있습니다.
Sumo Logic Cloud SIEM은 이제 Slack의 감사 로그(audit log)를 모니터링하여 의심스러운 활동을 탐지하고, 내부자 및 외부 위협으로부터 Slack 사용 환경을 보호합니다. 이를 통해 기업의 데이터와 시스템을 안전하게 유지할 수 있습니다.
10달러짜리 도난당한 Slack 쿠키로 시작된 대규모 침해 사고
EA(Electronic Arts)의 보안 침해 사례가 그 대표적인 예입니다. 이 사건에서 공격자는 10달러에 판매된 도난된 Slack 쿠키를 구매했습니다. 그 구매 한 건으로 공격자는 EA 내부 Slack 채널에 접근할 수 있었고, 이를 이용해 IT 팀을 사회공학적으로 속여 EA의 내부 네트워크 접근 토큰을 확보했습니다. 그 결과, 공격자는 FIFA 21 게임의 소스 코드와 독점 소프트웨어 개발 키트를 포함해 총 780GB에 달하는 데이터를 탈취했습니다.
EA만의 문제가 아니었습니다. 디즈니(Disney), 록스타(Rockstar), 우버(Uber), 트위터(Twitter) 등 여러 유명 기업들도 Slack이 공격 성공의 핵심적인 역할을 했던 침해 사고를 겪었습니다.
Slack이 공격자에게 표적으로 선택되는 이유는 분명합니다. Slack은 초기 접근, 내부 탐색, 자격 증명 탈취, 데이터 유출 등 다양한 공격 전술이 실행되기에 적합한 환경을 제공합니다. 따라서 Slack은 공격자가 이용하는 핵심 거점이자, 때로는 최종 목표로 작용하기도 합니다.
Slack 감사 로그: 보안 강화를 위한 핵심 요소
Slack이 이처럼 공격자에게 매력적인 표적이기 때문에, Slack 환경은 악의적 행위를 지속적으로 모니터링해야 합니다.
이 모니터링을 시작하는 방법 중 하나는 바로 로그(log)를 활용하는 것입니다. Slack은 감사 로그(audit log), 접근 로그(access log) 등 여러 형태의 로그를 제공합니다. 이 블로그에서는 그중에서도 감사 로그에 초점을 맞추어 살펴보겠습니다. Slack에서 생성되는 감사 로그는 “지속적인 규정 준수를 보장하고, 부적절한 시스템 접근으로부터 보호하며, 기업 내에서 발생하는 의심스러운 활동을 감사하기 위한 것”입니다.
이러한 감사 로그와 이를 API를 통해 접근할 수 있는 기능은, Sumo Logic과 같은 SIEM 솔루션이 보안 모니터링 및 통합 분석을 수행하는 데 필수적인 기반이 됩니다.
Slack의 감사 로그를 활용한 위협 탐지
Slack 감사 로그에는 이상 이벤트(Anomaly Event)라는 매우 유용한 기능이 포함되어 있습니다. 이는 Slack이 비정상적인 행위나 행동 패턴을 감지할 때 자동으로 생성되는 이벤트입니다. 모든 이상 이벤트가 즉각적인 대응을 요구하는 것은 아닙니다. 이상 이벤트마다 신뢰 수준(confidence level)이 다르기 때문입니다. 하지만 이상 이벤트가 트리거되면, 그 활동을 분석하여 조치가 필요한지를 판단할 필요가 있습니다.
Slack은 이상 이벤트마다 신뢰 수준을 명시적으로 제공하지는 않지만, 일부 이벤트의 경우 침해 가능성이 높은(high-confidence) 지표로 간주한다고 밝힙니다.
Slack의 이상 이벤트 대응 기능은 어떤 이벤트가 고신뢰(high-confidence) 이벤트로 분류되는지를 보여줍니다. 이 기능은 특정 이상 이벤트가 발생할 경우 해당 사용자의 세션을 자동으로 종료하도록 설정되어 있습니다. Slack 엔지니어링 팀은 기본적으로 ‘Tor 출구 노드(Tor exit node)에서 Slack에 접근’하는 이벤트와 ‘데이터 스크레이핑(data scraping)’을 고신뢰 침해 이벤트로 간주하고 있습니다.
Slack의 이상 이벤트는 SIEM 환경에서 수집 및 분석이 가능하다는 점에서 보안 운영팀(SOC)에 특히 유용합니다. Sumo Logic Cloud SIEM은 Slack의 이상 이벤트를 완벽하게 지원하며, 이벤트를 위협 경고(Threat Alert)로 정규화하여 ‘Normalized Security Signal’(MATCH-S00402) 규칙을 자동으로 트리거합니다. 이를 통해 이상 이벤트가 각 엔터티의 활동 점수(Activity Score)에 반영되며, 보안 분석팀은 위험도가 높은 사용자나 시스템을 신속하게 식별할 수 있습니다.
Sumo Logic Cloud SIEM 신호로 전달되는 Slack의 이상 이벤트
Slack 이상 이벤트 대응 기본 설정
Sumo Logic으로 Slack 감사 로그를 수집 및 인제스트하는 방법
Sumo Logic을 사용하면 Slack 감사 로그 수집이 비교적 간단합니다. 이 블로그에서는 Slack에서 로그를 수집하는 전체 과정을 안내하겠지만, 그 단계의 개요를 간략히 요약하면 다음과 같습니다.
- Slack Enterprise Grid 계정을 보유해야 합니다. Enterprise Grid 계정이 없으면 Slack 감사 로그를 수집할 수 없습니다.
auditlogs:read권한을 가진 Slack 앱을 생성합니다.- 해당 앱을 Enterprise Grid에 설치합니다.
- Sumo Logic의 Slack Cloud-to-Cloud Connector를 설치 및 구성합니다.
- 중요 안내: Slack 로그 소스 설정에서 “Forward to SIEM” 체크박스를 선택하여 로그가 SIEM으로 포워딩되도록 구성했는지 반드시 확인합니다.
보안 분석팀이 Slack 로그를 활용해 위협을 탐지·조사·대응하는 방법
Slack은 자사 플랫폼에서 비정상적인 행동을 감지하고 이상 이벤트를 생성함으로써 고객에게 매우 유용한 보안 기능을 제공합니다. Slack은 자사 플랫폼의 동작을 누구보다 잘 이해하고 있기 때문에, 어떤 행동을 ‘이상 행동’으로 간주해야 하는지를 가장 정확히 판단할 수 있는 위치에 있습니다.
그러나 Slack 엔지니어링 팀은 이상 이벤트를 생성하기 위해 사용하는 탐지 기준을 외부에 공개하지 않습니다. 그 이유는 명확합니다. 이 기준이 공개될 경우, 공격자들이 그 정보를 악용해 탐지를 회피하는 방법을 훨씬 쉽게 설계할 수 있기 때문입니다.
하지만 보안 분석가 입장에서는 이 점이 도전 과제가 됩니다. 경고가 왜 트리거되었는지를 정확히 알 수 없으면, 해당 이상 이벤트를 유발한 감사 로그를 찾아내기 위해 쿼리를 작성하고 검증하는 데 더 많은 시간이 소요됩니다. 또한, 분석 로직을 튜닝하거나 오탐과 미탐을 평가하는 과정도 그만큼 까다로워지고, 일부 단계에서는 추측에 의존해야 할 수도 있습니다.
이상 이벤트의 종류에 따라 트리거 원인을 파악하기 쉬운 경우도 있지만, 그렇지 않은 경우도 있습니다. 예를 들어, excessive_downloads(과도한 다운로드) 와 같은 이벤트는 발생 원인이 명확하지 않아, 이벤트 발생 전후의 다운로드 활동을 직접 검색하거나, 다운로드된 파일의 종류를 검토하거나, 해당 사용자의 이전 기간과 비교했을 때 다운로드 양이 ‘정상적인지’를 평가해야 할 수도 있습니다.
이제 이러한 이상 이벤트를 실제로 어떻게 조사할 수 있는지 살펴보겠습니다.
Slack에서 발생할 수 있는 쿠키 탈취 의심 사례 조사하기
EA 침해 사례로 다시 돌아가 봅시다. 이 사건에서 공격자는 도난된 쿠키를 이용해 내부 시스템에 접근했습니다. 그렇다면, 도난된 쿠키가 재사용될 때 Slack에서는 어떤 이상 이벤트가 발생할 수 있을까요? 그리고 이러한 이상 이벤트가 로그에 남는다면, 어떻게 조사할 수 있을까요?
Slack 세션 ID 이해하기
사용자가 Slack에 로그인할 때마다 세션 ID가 생성됩니다. 이 세션은 사용자의 기기 안에 쿠키로 저장되어 유지됩니다. 일반적으로 각 세션 ID는 단일 기기에만 매핑되어야 합니다. 만약 쿠키가 탈취되어 다른 기기에서 사용된다면, 다음과 같은 로그 아티팩트에서 차이를 확인할 수 있습니다.
- 사용자 에이전트 문자열
- IP 주소 및 위치
- TLS 핸드셰이크(ja3 지문)
이러한 신호들은 도난된 쿠키의 재사용 여부를 식별하는 데 유용한 단서가 될 수 있습니다. 다만 주의할 점은, Slack 감사 로그는 상호작용(interactive action)이 발생했을 때만 생성된다는 것입니다. 즉, 클릭이나 다운로드 없이 단순히 메시지를 읽는 수동적 접근은 로그에 기록되지 않을 수 있습니다. 따라서 쿠키 재사용 여부 탐지는 사용자의 실제 활동 형태에 따라 달라집니다.
이러한 차이점들은 동일한 세션 ID와 관련된 로그에서 확인할 수 있습니다.
Sumo Logic Cloud SIEM 레코드에 표시된 Slack 세션 ID 예시
쿠키 탈취를 시사할 수 있는 이상 이벤트
쿠키 탈취로 인해 트리거될 수 있는 Slack 이상 이벤트 목록을 살펴보면 다음과 같은 후보들이 있습니다.
ASNip_address(IP 주소)session_fingerprint(세션 지문)torunexpected_client(예상치 못한 클라이언트)unexpected_user_agent(예상치 못한 사용자 에이전트)user_agent(사용자 에이전트)
Sumo Logic을 이용한 쿠키 탈취 탐지
이제 위의 정보를 바탕으로, 지난 2주간 우리 환경에서 발생한 Slack 이상 이벤트 전체를 조회해 보겠습니다. 다음 검색 쿼리는 모든 Slack 이상 이벤트를 가져와 발생 원인별로 그룹화한 것입니다.
_index=sec_record_notification metadata_vendor="Slack" metadata_deviceEventId="anomaly" | count by threat_signalName
그림 4: 원인별로 그룹화한 Slack 이상 이벤트
검색 결과, 총 323건의 이벤트가 검색되었습니다. 여기서 주목할 점은 두 가지입니다.
- 한 이벤트에 복수의 발생 원인이 생길 수 있습니다. 예를 들어,
asn|ip_address또는unexpected_user_agent|user_agent와 같은 형태로 표시됩니다. - 가장 빈도가 높은 이상 이벤트 원인은 asn|ip_address 입니다. 이러한 이벤트는 API를 통해 허용된 자율 시스템 번호(ASN) 및 IP 주소 범위를 제외 목록에 추가하여 필터링할 수 있습니다.
이번에는 unexpected_user_agent와 user_agent 이벤트에 초점을 맞추어 도난된 쿠키와 관련된 활동을 추적하겠습니다. 이를 위해 다음 쿼리를 사용하여 해당 이벤트와 그 세션 ID를 조회합니다.
_index=sec_record_notification metadata_vendor="Slack" metadata_deviceEventId="anomaly" | where threat_signalName = "Anomaly Event : unexpected_user_agent|user_agent" | count by sessionId
unexpected_user_agent 이상 이벤트의 세션 ID
이제 조사할 대상이 되는 이상 이벤트를 확보했습니다.
따라서 이벤트의 세부 정보를 검토하며 이벤트가 왜 트리거되었는지에 대한 맥락(context)을 파악해 보겠습니다.
unexpected_user_agent|user_agent 이상 이벤트에 대한 세부 정보
이상 이벤트 분석하기
이상 이벤트의 세부 메타데이터는 이벤트가 트리거된 이유를 보여줍니다. 이번 사례에서는 IP 주소와 사용자 에이전트가 변경된 것이 원인이었습니다.
IP 주소 변경
- 현재 IP 주소:
172.59.222.55 - 이전 IP 주소:
204.16.138.54
이 IP 주소 변경은 기기가 바뀌었다는 뜻일까요? 즉, 사용자의 기기에서 공격자의 기기로 전환되었을 가능성이 있을까요? 그럴 가능성도 있지만, 이 경우에는 해당 기기가 모바일 기기이며, GeoIP 정보상 두 주소 모두 노스캐롤라이나주 샬럿(Charlotte, North Carolina) 지역에 속하므로 기기가 바뀌었을 가능성은 낮다고 판단됩니다.
사용자 에이전트 변경
- 현재 사용자 에이전트: “
AppleCoreMedia/1.0.0.21F90(iPhone; U; CPU OS 17_5_1 같은 Mac OS X; en_us)“ - 이전 사용자 에이전트: “
com.tinyspeck.chatlyio/25.04.10 (iPhone; iOS 17.5.1; Scale/3.00)“
이 사용자 에이전트의 변경은 기기의 변경을 의미할까요?
- 사용자 에이전트 문자열이 스푸핑되지 않았다고 가정하면, 두 값 모두 iOS 17.5.1 버전을 사용하는 iPhone에서 발생한 것으로 보입니다.
- 참고로, Tiny Speck은 Slack을 처음 개발한 회사의 이름입니다. 따라서
com.tinyspeck.chatlyio/25.04.10문자열은 Slack iOS 클라이언트를 의미할 가능성이 높습니다.한편AppleCoreMedia는 iOS에서 스트리밍 및 미디어 재생을 처리하는 프레임워크입니다. - 이 점을 감안하면, Slack 내에서 동영상 등 미디어 파일을 스트리밍할 때는 AppleCoreMedia 사용자 에이전트가 나타나고, 일반적인 Slack 사용 시에는 Tiny Speck 에이전트가 기록되는 것으로 보입니다. 공식 문서에 이러한 동작이 명시되어 있지는 않지만, 로그 분석 결과는 이러한 해석을 뒷받침합니다.
- AppleCoreMedia는 iOS의 스트리밍 미디어입니다.
즉, AppleCoreMedia는 iOS의 스트리밍 미디어 처리용, Tiny Speck은 일반적인 Slack 사용 활동을 반영하는 에이전트일 가능성이 큽니다.
이 가설을 검증하기 위해, 이상 이벤트에 포함된 개별 로그를 검토해 보겠습니다. 세션 ID를 검색하고 각 활동과 연관된 사용자 에이전트를 확인합니다.
(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=8475310491012 | fields action, http_userAgent
세션은 장기간 유지될 수 있으므로, 검색 시 시간 범위를 넉넉히 설정하는 것이 좋습니다. 이번 사례의 세션은 90일 이상 유지되었습니다.
감사된 Slack 활동 및 관련 사용자 에이전트 문자열
2025년 4월 9일에 발생한 이상 이벤트 이전 며칠간의 로그를 집중적으로 살펴보겠습니다. 이상 이벤트가 발생하기 약 한 시간 전, 사용자 에이전트가 Tiny Speck(Slack) 에이전트에서 AppleCoreMedia로 변경되었습니다. 그 이유는 무엇일까요? 아마도 file_downloaded에서 다운로드된 파일의 유형이 스트리밍을 필요로 했기 때문일 것입니다. 이를 확인하기 위해, 검색 결과 표시 항목에 file_mimetype 필드를 추가합니다. 필드 목록에서 숨김 필드 섹션을 열고 해당 필드명을 선택합니다.
필드 8: 검색 결과 표시에 file_mimeType 필드 추가
file_mimeType을 표시한 결과, MP4 파일을 다운로드할 때는 AppleCoreMedia, JPG 파일을 다운로드할 때는 Tiny Speck 사용자 에이전트가 사용된다는 사실을 명확히 확인할 수 있습니다.
그림 9: 다운로드한 파일 유형과 연관된 사용자 에이전트 문자열 분석
이 경우, Slack 이상 이벤트에서 악의적인 행위를 발견하지 못했습니다. 사용자 에이전트가 변경된 세션이 있었지만, 이는 동일한 세션 쿠키를 여러 기기에서 사용했기 때문이 아니라, 파일 유형의 차이로 인해 Slack 내에서 서로 다른 프로세스가 호출된 결과였습니다.
Slack 이상 이벤트 유형을 활용한 맞춤형 분석 콘텐츠 제작
Slack은 이상 이벤트를 탐지하기 위한 정확한 로직을 공개하지 않습니다. 이는 보안상 타당한 접근입니다. 하지만 이상 이벤트 유형(anomaly event types) 자체는 대시보드, 헌팅, 맞춤형 분석 규칙을 설계할 때 좋은 참고 자료가 됩니다.
이를 활용하면 다음과 같은 활동을 모니터링할 수 있습니다.
- 일반적이지 않은 관리자 행위: 최초 감지 규칙(First Seen rule) 적용
- 다운로드, 파일 공유, 메시지 삭제 등의 급격한 증가: 아웃라이어 규칙(Outlier Rules) 적용
다시 쿠키 탈취 탐지로 돌아가서, 하나의 Slack 세션에서 복수의 사용자 에이전트 문자열이 사용된 경우를 헌팅하려면 어떻게 해야 할까요? 다음과 같이 count_distinct 연산자를 사용할 수 있습니다.
(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" metadata_product="Slack" | count_distinct(http_userAgent) by sessionId | sort by _count_distinct
세션 ID당 고유 사용자 에이전트 문자열 개수
이렇게 관심 있는 세션을 찾아낸 후, 아래와 같은 쿼리를 사용해 해당 세션의 모든 로그를 다시 조회할 수 있습니다.
(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=[insert session ID here] | count by http_userAgent
Slack 기반 위협에 한발 앞선 대응
Slack은 기업 내부의 다양한 정보가 오가는 플랫폼으로, 해커들에게는 매력적인 공격 대상입니다. 이상 이벤트를 포함한 Slack 감사 로그를 모니터링하는 것은 침해를 조기에 감지하는 데 매우 중요합니다.
Sumo Logic은 이러한 로그를 손쉽게 수집, 분석, 대응할 수 있도록 지원합니다. 이를 통해 보안 팀은 위협에 한발 앞서 대응할 수 있습니다.
Sumo Logic Cloud SIEM에 대해 더 자세히 알아보려면, 대화형 Cloud SIEM 데모를 확인해 보세요.
