PantherFlow 예제: 위협 헌팅 시나리오

경고에서 로그 검색으로 전환하기

예를 들어 우리가 받은 것이 있다고 가정해봅시다 Wiz EC2 인스턴스가 잠재적으로 잘못 구성되었다는 경고. 경고에서 관련된 AWS 인스턴스 ID를 가져올 수 있습니다. 그런 다음 해당 인스턴스에서의 활동을 찾기 위해 모든 AWS 로그를 검색할 수 있습니다.

let alert_data = panther_signals.public.signal_alerts
| where p_event_time > time.ago(7d)
| where p_alert_id == '00411934608291e0fccd928590194fd6'
| summarize instances = arrays.flatten(agg.make_set(p_any_aws_instance_ids)),
    mintime = agg.min(p_event_time),
    maxtime = agg.max(p_event_time);

union panther_logs.public.aws*
| where p_event_time between time.parse_timestamp(toscalar(alert_data | project mintime)) - 30m 
    .. time.parse_timestamp(toscalar(alert_data | project maxtime)) + 30m
| where arrays.overlap(p_any_aws_instance_ids, toscalar(alert_data | project instances))

위의 문장은 다음을 활용합니다:

• let 문장 기능

• 연산자: union, project, summarize, where 및 between

• 함수: arrays.flatten(), arrays.overlap(), agg.make_set(), agg.min(), agg.max(), time.ago(), time.parse_timestamp() 및 toscalar()

한 테이블에서 IP를 가져와 다른 테이블에서 검색하기

위협 헌팅 중에는 한 테이블에서 값을 가져와 다른 테이블에서 해당 값을 검색해야 하는 경우가 흔합니다. 아래 쿼리는 VPC 흐름 로그 테이블에서 IP 주소를 가져온 다음 Okta 시스템 로그에서 이를 검색합니다.

let IPs = panther_logs.public.aws_vpcflow
| where p_event_time > time.ago(5d)
| where flowDirection == 'ingress'
| summarize IP = agg.make_set( re.substr(srcAddr, '(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})') );

{ "actionName": "CREATE_RULE", "events": 12, "user": "betsy" },
| where p_event_time > time.ago(1d)
| where arrays.overlap(toscalar(IPs), p_any_ip_addresses)

위의 문장은 다음을 활용합니다:

• let 문장 기능

• 연산자: summarize 및 where

• 함수: arrays.overlap(), agg.make_set(), re.substr(), time.ago() 및 toscalar()

정규 표현식으로 CIDR 일치시키기

이 쿼리는 정규식 표현과 일치하는 IP 주소를 AWS 로그에서 검색합니다.

union aws_alb , amazon_eks_audit, aws_cloudtrail, aws_s3serveraccess
| where p_event_time > time.ago(7d)

| extend ip = coalesce(clientIp, sourceIPs, sourceIPAddress, remoteip)
| summarize events=agg.count() by ip, p_log_type

| where re.matches(ip, "^34\\.222\\..+\\..+$")
okta_systemlog

위의 문장은 다음을 활용합니다:

• 연산자: union, where, extend, summarize 및 정렬

• 함수: coalesce(), agg.count() 및 re.matches()

결과:

summarize events = agg.count() by actionName	ip	p_log_type
5866	34.222.253.62	AWS.CloudTrail
184	34.222.140.16	AWS.CloudTrail
176	34.222.42.181	AWS.CloudTrail
171	34.222.87.204	AWS.CloudTrail
88	34.222.241.235	AWS.CloudTrail
...

API 키 생성에 대한 경고 조사

이 시나리오에서는 Panther에서 관리하는 항목과의 일치로 경고를 받았습니다 AWS 사용자 API 키 생성 CloudTrail 데이터를 검사하고 다른 사용자가 AWS 사용자용 AWS API 키를 생성할 때 경고하는 탐지입니다.

이 위협 시나리오는 또한 Risky Business 팟캐스트의 비디오에서 설명됩니다및 Panther 블로그에서도: PantherFlow로 Amazon EKS 권한 상승 조사하기.

이 이벤트는 ariel.ropek 라는 행위자가 snidely-whiplash라는 새 사용자에 대한 API 키를 생성했음을 알려줍니다. 이 동작이 오탐인지 실제 침해인지 조사해 봅시다.

1. 먼저, 다음을 살펴보겠습니다: ariel.ropek경보를 중심으로 한 시간 동안의 활동:

   panther_logs.public.aws_cloudtrail
   | where p_event_time between time.parse_timestamp('2024-11-13 19:00') .. time.parse_timestamp('2024-11-13 20:00')
   | extend p_actor = strings.split(userIdentity.arn, '/')[arrays.len(strings.split(userIdentity.arn, '/'))-1]
   | where p_actor == 'ariel.ropek'
   | sort p_event_time desc

   결과:

   

   흥미롭네요! 우리는 다음을 확인했습니다: ariel.ropek 새 사용자 이름을 생성했을 뿐만 아니라 snidely-whiplash그들이 또한 연결했습니다: AdministratorAccess 정책에 대해:\

   
2. 추가해 보겠습니다 snidely-whiplash 활동을 보기 위해 쿼리에 다음을 추가합니다:

   panther_logs.public.aws_cloudtrail
   | where p_event_time between time.parse_timestamp('2024-11-13 19:00') .. time.parse_timestamp('2024-11-13 20:00')
   | extend p_actor = strings.split(userIdentity.arn, '/')[arrays.len(strings.split(userIdentity.arn, '/'))-1]
   | where p_actor in ['ariel.ropek', 'snidely-whiplash']
   | sort p_event_time desc

   결과:

   

   포함되었을 때 더 많은 결과가 있습니다— snidely-whiplash 가 포함되면 더 많은 결과가 있습니다—사용자가 EKS에서 명령을 실행한 것을 볼 수 있습니다. 그들은 새 역할을 생성하고, 해당 AmazonEKSClusterAdminPolicy 를 역할에 연결한 다음 새 세션 이름으로 역할을 맡았습니다, snidely-whiplash-session.\

   
3. 이제 사용자가 EKS에서 조치를 취한 것을 알았으므로, 우리는 다음을 사용해야 합니다 union 검색 범위를 EKS 감사 및 인증자 로그로 확장하려면. CloudTrail, EKS 감사 및 EKS 인증자 로그는 각각 다른 스키마를 가지지만, 우리는 다음을 사용하여 coalesce() 이러한 로그 소스를 공통 행위자 및 동작 필드:

   union panther_logs.public.aws_cloudtrail, panther_logs.public.amazon_eks_audit, panther_logs.public.amazon_eks_authenticator
   | where p_event_time between time.parse_timestamp('2024-11-13 19:00') .. time.parse_timestamp('2024-11-13 20:00')
   | extend p_aws_arn = coalesce(userIdentity.arn, user.username, arn)
   | extend p_actor = strings.split(p_aws_arn, '/')[arrays.len(strings.split(p_aws_arn, '/'))-1]
   | extend p_action = coalesce(eventName, strings.cat(verb, ' ', objectRef.resource), path)
   | where p_actor in ['ariel.ropek', 'snidely-whiplash', 'snidely-whiplash-session']
   | sort p_event_time desc

   결과:

   

   다음을 살펴보면 p_action 열에서, 우리는 사용하여 볼 수 있습니다 snidely-whiplash-session, 사용자가 쿠버네티스 파드를 생성했습니다 (파드 생성). 전체 이벤트를 클릭하면 그들이 생성한 파드가 권한이 상승된 상태임을 확인할 수 있습니다:\

   

   이 시점에서, 우리는 이것이 매우 가능성이 높은 악성 행위자임을 결론지을 수 있습니다. 요약하면, 우리는 발견했습니다:

   1. 한 AWS 사용자 (ariel-ropek)가 새 사용자를 생성했습니다 (snidley-whiplash) 관리자 권한으로.

   2. snidley-whiplash EKS로 피벗하여 그곳에서 권한을 상승시켜 클러스터 관리자가 되었습니다.

   3. 그들은 EKS에 권한이 부여된 포드를 생성했습니다.\

4. 전체 공격 체인을 다음과 같은 차트에서 볼 수 있습니다 시각화:

   union panther_logs.public.aws_cloudtrail, panther_logs.public.amazon_eks_audit, panther_logs.public.amazon_eks_authenticator
   | where p_event_time between time.parse_timestamp('2024-11-13 19:00') .. time.parse_timestamp('2024-11-13 20:00')
   | extend p_aws_arn = coalesce(userIdentity.arn, user.username, arn)
   | extend p_actor = strings.split(p_aws_arn, '/')[arrays.len(strings.split(p_aws_arn, '/'))-1]
   | extend p_action = coalesce(eventName, strings.cat(verb, ' ', objectRef.resource), path)
   | where p_actor in ['ariel.ropek', 'snidely-whiplash', 'snidely-whiplash-session']
   | summarize events = agg.count() by p_actor, p_action
   | visualize bar xcolumn = p_action
   | sort p_actor

   결과:

   

   위의 시각화에서 공격 체인은 우측에서 좌측으로 추적할 수 있으며, 시작점은 ariel.ropek의(가) 수행한 작업입니다.