침입대응 과정은 보안팀의 분석인력에 의한 메뉴얼한 분석을 통해 위험을 분석하고 서비스 영향도를 판단한다. 하지만 자동화된 공격이 증가되고 특히 인공지능 엔진을 활용한 취약점 공격 시도가 다양하게 발생하면서 대응하고 분석할 경보와 알림도 증가 했다.
기존 인력으로 대응에 한계가 있을뿐만 아니라 증가하는 위협 시도를 인적 자원으로 지속 대응하기에는 현실적인 제약이 많다. 자동화되고 Agentic 기반의 취약점 공격가 증가하는데 사람이 메뉴얼하게 대응한다는 방법론에 실효성이 떨어질 수 밖에 없다.
사후 대응적이고 과도한 오탐 경보에 시달리던 기존 보안운영센터(SOC)가 AI 기술의 발전과 함께 스스로 판단하고 행동하는 ‘Agentic AI SOC’로 빠르게 진화하고 있다. Elastic Security Labs 리포트에 따르면, 2026년은 실험적인 AI 도입 단계를 넘어 실제 비즈니스 환경에서 자율형 AI 보안 솔루션을 대규모로 생산 적용하는 실질적인 변곡점이 될 것이다.
에이전틱 AI는 인간의 세부적인 개입 없이도 스스로 계획을 세우고, 상황에 맞게 적응하며, 위협을 독립적으로 해결한다. 에이전틱 SOC의 핵심 차별점은 단편적인 알림이 아닌 전체 공격 체인의 우선순위를 식별하고, 자체 런북과 워크플로우를 통한 자동 격리(Closed Loop)를 수행하며, 모든 결정에 검증 가능한 투명한 근거(Traceable reasoning)를 제공하는 데 있다.
슬랙과 같은 업무 협업 툴을 이용해 보안 경보에 대한 모니터부터 케이스 생성 대응까지 L1 위협 모니터링 과정을 Agentic 기반으로 수행하는 과정을 데모로 소개 한다.
글쓴이 보관물: bigrootno1@gmail.com
엔드포인트(Endpoint) 보안 분석 항목 (feat. 클로바더빙)
엔드포인트(Endpoint) 보안 분석 항목
보안 위협 또는 침해사고가 발생하는 경우 개별 시스템에 대한 조사 및 분석을 진행 한다. 엔드포인트 시스템에는 보안 위협과 연관된 다양한 정보가 포함되어 있다. 사용자 정보, 시스템 구성 정보, 서버 설정, 컨텐이너 구성 파일, 가상 운영 환경 설정 등 환경에 따라 다양한 정보를 분석 과정에 조사하게 된다. 엔드포인트 시스템의 주요 보안 분석 항목을 살펴 보자.
운영 체제 로그 분석
로그 파일의 분석 정보는 좁은 의미로 해석하면 우리가 자주 사용하는 PC나 노트북 또는 서버 장비에서 기록하는 정보를 의미한다. 각각의 장비에는 운영체제가 동작하고 운영체제에 따라 관련 로그를 기록한다. 침해사고가 발생하면 운영체제에서 기록하는 로그를 수집해 이상 징후 분석에 활용 한다. 운영체제에는 사용자가 필요에 따라 설치한 응용프로그램이 동작한다. 개별 응용프로그램은 동작과 관련된 로그를 기록하게 되고 이 또한 위협 분석 시 수집되는 정보다.
| 구분 | 수집 항목 | 주요 분석 항목 |
| 윈도우 | 시스템 보안 이벤트 레지스트리 정보 | 이벤트 ID중요 레지스트리 수정 항목 |
| 리눅스 | 운영체제 로그 애플리케이션 로그 | 보안 로그사용자 인증 로그 |
| 애플리케이션 | 웹 로그 데이터베이스 로그 | 웹 요청 정보응답코드 |
대표적인 엔드포인트 시스템으로 윈도우와 리눅스가 있다. 윈도우 로그는 크게 운영체제자체의 로그와 애플리케이션에 의해 발생되는 로그로 구분해 볼 수 있다. 윈도우에서 운영체제 로그의 가장 대표적인 로그는 이벤트로그다. 컴퓨터관리의 이벤트 뷰어를 통해 확인이 가능한데 운영체제의 보안 로그와 시스템 로그를 제공한다. 엔드포인트 시스템 로그 형식과 종류에 대해서는 자세히 살펴보자.
운영체제 정보
운영체제 버전 확인은 점검 대상 시스템 기본 정보 수집 항목 중 하나이다. 윈도우의 경우 “ver”명령을 이용해서 운영체제 버전을 간단하게 확인할 수 있다. cmd명령 창에서 ver명령을 입력하면 버전 정보를 확인 할 수 있다. 버전 정보를 확인하는 이유는 시스템에 영향을 미치는 취약점을 확인하기 위해서다. 공개된 취약점 공격 도구의 경우 OS나 응용프로그램 버전에 따라 영향 여부가 틀려진다. 내장 명령외 자주 사용하는 점검 툴인 psinfo.exe 명령을 이용해서 텍스트 기반으로 결과를 확인할 수 있다. Sysinternals에서 제작된 툴 모음에 포함된다.
그림 psinfo 실행 화면(이미지 출처[1])
[1] https://learn.microsoft.com/en-us/sysinternals/downloads/psinfo
리눅스에서는 ‘uname’ 명령을 이용해 시스템 정보를 확인 한다. 커널 버전과 OS정보를 확인할 수 있고, 리눅스의 경우 Exploit마다 취약한 Kernel 버전이 있기 때문에 로컬 또는 원격에서 Exploit공격을 시도할 때 버전 정보가 중요하게 쓰인다.
| $uname –a Linux linuxos 5.15.0-1083-gcp #92~20.04.1-Ubuntu SMP Tue Apr 29 09:12:55 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux |
파일 시스템 정보
파일 시스템 정보는 넓은 의미에 흔히 말하는 C, D, E 등의 파티션 정보나 물리적 디스크 정보를 말한다. 단순 시스템 경로 파악하거나 할당되지 않은 디스크 공간이 있는지 등을 확인한다. 일부 악성코드의 경우 비데이터 영역에 악성코드를 삽입해 구동되는 경우도 있다. 이러한 경우는 일반적인 점검으로 확인이 어렵고, 디스크 이미지를 추출해서 별도의 분석 툴을 이용해 물리 디스크 전체에 대한 점검을 진행해야 한다.
파일 시스템 구조를 알면 직접 디스크상에서 삭제된 파일, 악성코드, 숨김 파일 등을 분석할 수 있다. 좀더 상세한 분석이 필요하거나 법적 증거로 제출하기 위해서는 디스크 이미지를 추출해 분석해야 한다. 이 작업을 위해서는 전용 분석툴이 필요하다.
윈도우는 ‘컴퓨터 관리’ 메뉴에서 논리구조인 파티션과 물리구조인 디스크 정보를 확인할 수 있다. 리눅스 시스템의 경우는 ‘df’ 명령을 이용해 파티션 정보와 물리적 디스크 정보를 확인 할 수 있다.
| $df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 7850996 2820552 4631632 38% / udev 254668 224 254444 1% /dev none 254668 216 254452 1% /dev/shm none 254668 96 254572 1% /var/run none 254668 0 254668 0% /var/lock none 254668 0 254668 0% /lib/init/rw /dev/sr0 201018 201018 0 100% /media/cdrom1 |
IP 정보
IP 정보 수집은 네트워크 관련된 기본 정보를 수집하는 과정이다. IP 정보 수집을 통해 현재 시스템의 네트워크 할당 정보를 확인한다. 간혹 한 개의 시스템에 2개의 다른 IP를 부여해 사용하기도 한다. 이 경우 공격자가 접근한 경로가 2개로 나뉘게 된다. 시스템에 부여된 IP 확인해 침해발생 시 추가로 접근 시도 가능성이 있는 내부 IP대역을 확인 한다. 통상 특정 시스템에 침해사고가 발생할 경우 해당 IP의 동일 서브넷에 포함되는 시스템의 경우 일단 침해가능성에 대해 의심해봐야 한다. 수집된 물리주소(Mac Address)는 ARP 스푸핑 공격 시 공격 시스템을 확인하기 위한 용도로 사용된다. IP정보 확인을 윈도우는 명령 창에서 ‘ipconfig’ 명령을 이용해 확인 가능하다. 리눅스 시스템에서는 ifconfig 명령을 이용해 시스템에 할당된 IP를 확인 할 수 있다.
설치프로그램목록
설치 프로그램 목록은 악성코드 설치 확인이나 정상 소프트웨어 이지만 의도하지 않게 설치된 프로그램이 있는지 점검하고 침해사고와의 연관성을 확인하기 위해 점검 한다. 설치된 프로그램을 점검하는 관점은 설치된 소프트웨어 중 외부와 통신을 위해 사용하거나 시스템을 제어할 수 있는 권한을 가진 소프트웨어에 대해 살펴 보고, 해당 프로그램이 설치된 경우 설치 일자, 설치 계정, 수정일자 등을 이용해 침해사고를 분석하는데 실마리로 이용하게 된다.
윈도우에서 쉽게 확인하는 방법은 제어판의 “프로그램 추가/제거”를 실행 시켜 확인하는 것이다. 이 때 프로그램뿐만 아니라 윈도우 구성요소에 대해서도 확인이 가능하다. 이러한 방법은 GUI기반으로 이뤄지기 때문에 자동화된 스크립트로 결과를 저장하기 어렵다. 분석가가 직접 실행시켜서 눈으로 확인하는 방법이다. 프로그램 목록을 텍스트로 추출해서 일괄 분석에 사용하려면 레지스트리 정보를 이용해 추출 할 수 있다.
패키지정보
리눅스는 rpm명령을 이용해 다음과 같이 설치된 프로그램을 확인 할 수 있다. 관리자나 사용자가 설치한적 없는 프로그램이 깔려 있다면 공격자에 의해 설치된 것인지 의심해볼 수 있다.
| [root@localhost ~]# rpm -qa | more python3-perf-5.14.0-284.11.1.el9_2.x86_64 libgcc-11.3.1-4.3.el9.x86_64 setup-2.13.7-6.el9.noarch filesystem-3.16-2.el9.x86_64 basesystem-11-13.el9.noarch tzdata-2023c-1.el9.noarch kernel-headers-5.14.0-284.11.1.el9_2.x86_64 glibc-common-2.34-60.el9.x86_64 glibc-all-langpacks-2.34-60.el9.x86_64 glibc-2.34-60.el9.x86_64 coreutils-common-8.32-32.el9.x86_64 libselinux-3.5-1.el9.x86_64 –More– |
Debian 계열의 설치 프로그램 목록 확인 시 dpkg 명령을 이용한다.
시스템구동정보
윈도우의 경우 작업 스케줄러 구동 로그를 확인하여 스케줄러 작업을 통해 구동되었던 내역을 수집 할 수 있다. 해당 파일은 %SystemRoot%\tasks\SchedLgU.txt 경로에 존재한다. 작업 스케줄에 등록되어 구동을 시도하는 악성 코드나 비정상 서비스를 확인 할 수 있다.
| C:\Users\Administrator> dir /a C:\Windows\Tasks C:\Windows\Tasks 디렉터리 2026-03-10 오전 10:20 <DIR> . 2026-03-10 오전 10:20 <DIR> .. 2026-04-12 오후 02:15 654 Adobe Flash Player Updater.job 2026-04-01 오전 09:00 1,102 GoogleUpdateTaskMachineCore.job 2026-04-15 오전 08:30 84 SA.DAT 2026-04-14 오후 11:55 3,420 SCHEDLGU.TXT 4개 파일 5,260 바이트 2개 디렉터리 45,120,540,672 바이트 남음 |
SCHEDLGU.TXT: 작업 스케줄러의 서비스 로그 파일 이다. 어떤 작업이 언제 실행되었는지, 오류가 있었는지 확인하는 데 매우 중요하다. 최신 윈도우의 작업 스케줄 정보는 주로 아래의 레지스트리와 경로에 XML 형태로 저장 된다. %SystemRoot%\tasks\에 파일이 없더라도 아래 경로를 반드시 확인해야 합니다.
a. 파일 경로: C:\Windows\System32\Tasks
b. 레지스트리: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks
컨테이너 구성 점검
컨테이너 환경은 일반적인 호스트 시스템과 달리 계층적 구조(Image, Container, Orchestrator)를 가지고 있어, 보안 조사 시 각 레이어별 특화된 접근이 필요하다. 컨테이너 보안 분석 시 반드시 점검해야 할 핵심 항목은 다음과 같다.
| 점검 항목 | 분석 정보 |
| K8s Audit Logs | 누가, 언제, 어떤 API 호출을 했는지에 대한 기록 |
| Container Stdout/Stderr | 애플리케이션 레벨의 에러 및 동작 로그 |
| Cloud Trail / VPC Flow | 인프라 수준에서의 변경 사항 및 네트워크 흐름 |
| Ephemeral Storage | 컨테이너 삭제 전 생성된 임시 파일 및 변조된 바이너리 |
엔드포인트 시스템 사고 조사 과정에서 주요 항목을 메뉴얼하게 조사하기는 쉽지 않다. 초기 사고 대응 과정에서 신속하게 필요한 엔드포인트 정보를 수집하기 위해 스크립트를 이용해 필요한 정보를 수집한다.
샘플 스크립트는 윈도우 운영체제에서 실행 가능한 샘플이다. 파워쉘 실행을 통해 필요한 정보를 수집하고 하나의 파일로 저장하는 샘플 스크립트 이다.
| $ReportFile = “$env:COMPUTERNAME`_Security_Check.txt” $Divider = “#” * 60 $Content = @” $Divider ############## 서버 보안 점검 보고서 (v3.0) ################### 작성자: 송대근 점검일시: $(Get-Date -Format “yyyy-MM-dd HH:mm:ss”) 호스트명: $env:COMPUTERNAME $Divider [1. 시스템 및 OS 정보] $(Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, OSArchitecture | Out-String) 빌드 정보: $((Get-ItemProperty ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’).CurrentBuild) [2. 네트워크 IP 정보] $(ipconfig /all | Out-String) [3. 설치 프로그램 목록 (Programs & Features)] $(Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, InstallDate | Where-Object { $_.DisplayName -ne $null } | Sort-Object DisplayName | Out-String) [4. 자동 실행 항목 (Registry Run Keys)] — HKLM Run — $(Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run | Out-String) — HKCU Run — $(Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run | Out-String) [5. 예약된 작업 (Scheduled Tasks – 상위 10개)] $(Get-ScheduledTask | Where-Object {$_.State -ne “Disabled”} | Select-Object TaskName, TaskPath, State | select -First 10 | Out-String) $Divider “@ $Content | Out-File -FilePath $ReportFile -Encoding utf8 Write-Host “점검이 완료되었습니다. 결과 파일: $ReportFile” -ForegroundColor Green |
Agentic AI를 활용한 보안 위협 대응: 선제적 보안 위협 대응
효율적인 이벤트 분석
효율적으로 이벤트를 분석하기 위해 다음과 같은 단계를 거치게 된다.
가장 먼저 수행하는 작업이 분석 정보를 선별하는 것이다. 네트워크 패킷이나 로그를 보기 좋게 가공하는 과정이다. 보기 좋게 가공한다는 것은 먼저 수집된 정보 중 정상 범주의 데이터를 제외 하는 과정이다. 이 부분이 이번 장에서 첫 번째로 배우게 될 짚더미 치우기다.
정상 범위의 데이터를 제외하고 나며 선별된 정보에서 가장 핵심적인 메시지를 찾아 낸다. 이 핵심 이벤트를 찾는 것이 여러분이 두번째로 배우게 될 공격 구분 이다. 그리고 핵심 메시지를 찾아 냈다면 시스템에 미치는 영향을 통해 이론이나 가설을 증명 하게 된다. 만약 적정한 정보를 찾지 못하거나 잘못된 데이터 가공이 이뤄졌다면 추가 증거 수집을 통해 분석 과정을 반복한다.
- 무조건 많은 정보를 수집하는 것이 증거 수집은 아니다.
- 분석되지 않은 데이터나 사용되지 않는 데이터는 의미가 없다.
- 분석을 통해 즉각적인 행동과 정보 보호 전략을 수립한다.
- 기본적인 데이터는 자동으로 처리하여 효율적으로 분석한다.
- 보안 위협에 대응하는 보안팀의 대응 마인드도 중요하다.
웹로그분석(짚더미치우기)
짚더미를 치운다는 것은 분석되지 않거나 불필요한 정보를 치워서 좀더 효율적으로 이벤트를 분석하기 위한 작업 이다. 가능한 부분은 프로그램이나 오픈 소스를 이용해 자동으로 분류해서 분석 대상을 선별하는 것도 방법 중 하나다.
다음과 같은 가정을 해보자.
“일반적인 네트워크 트래픽엔 공격 패킷이나, 악성코드가 없다.”
하지만 이러한 착한 트래픽은 모래 더미처럼 수 없이 많다. 모래 더미에 숨어 있는 바늘 같은 공격 트래픽을 찾는 일은 결코 쉬운 일이 아니다.
모래더미처럼 쌓아 놓은 정보들 중에 불필요한 정보들을 치워 보자.
웹 로그를 이용해 짚더미를 치우는 방법은 같이 살펴보자. 로그 파서를 설치하고 실행 시키면 로그를 분석하기 위해서는 로그 타입을 “ IISW3CLOG” 형식으로 지정 한다.
<짚더미 1단계 – 메소드 점검>
먼저 분석할 웹 로그에서 응답 코드 현황에 대한 통계를 추출한다.
먼저 샘플 로그를 저장하고 해당 로그 위치를 경로로 지정해 다음과 같은 쿼리 문은 로그 파서 쿼리창에 입력하고 실행 버튼()을 클릭 하면 다음 그림처럼 응답코드 통계를 추출할 수 있다.
| SELECT sc-status AS Status, COUNT(*) AS Total FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ GROUP BY Status ORDER BY Total DESC |
<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치운다>
일반적으로 웹 응답과정에서 자주 발생하는(흔히 정상 범주에 해당하는) 응답코드를 제외하고 나머지 코드를 살펴 보자. 정상 범주에 대한 기준은 다음과 같이 정의 하자.
| 응답코드 | 설명 |
| 200 | 클라이언트 요청이 성공했습니다. |
| 302 | 개체 이동 |
| 304 | 수정되지 않았습니다. |
| 404 | 찾을 수 없습니다. |
4개 응답코드를 제외하고 500(에러), 401(거부), 201(파일생성), 206(일부응답)와 같이 잘 발생하지 않는 응답코드 위주로 분석을 진행 하자. 동일하게 로그 파서 쿼리 창에 다음과 같이 입력하고 실행 한다.
| SELSELECT sc-status AS Status, cs-method, cs-uri-stem, c-ip FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ WHERE (Status = 500) or (Status = 401) or (Status = 201) or (Status = 206) |
총 25개의 결과물이 검색되었다. 25개 정도면 충분히 하나씩 전수 분석이 가능한 범위다. 응답코드를 정렬해서 하나씩 살펴보자.
먼저 201 응답 코드로 응답된 URL을 보면 /test.txt, /da.txt URL에 대해 3가지 메소드(PUT, COPY, MOVE)가 사용되었다.
| Status | cs-method | cs-uri-stem | c-ip |
| 201 | PUT | /test.txt | 192.168.20.20 |
| 201 | COPY | /test.txt | 192.168.20.20 |
| 201 | PUT | /da.txt | 192.168.20.37 |
| 201 | MOVE | /da.txt | 192.168.20.37 |
<짚더미 치우기 3단계 – 공격자 상세 분석>
이제 공격자로 의심되는 IP에 대해 상세하게 분석해 보자.
다음 그림 처럼 쿼리문을 입력하고 결과를 확인해 보자.
| SSELECT TO_TIMESTAMP(date,time) as Datetime, sc-status, cs-method, cs-uri-stem, c-ip FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ WHERE c-ip like ‘192.168.20.37’ ORDER BY Datetime |
웹 로그를 분석해 보면 192.168.20.37 IP에서 PUT메소드를 이용해 da.txt파일을 업로드 하였고, 성공적으로(201 응답코드) 웹 서버에 파일이 업로드 된것을 알 수 있다. 이후 공격자는 MOVE메소드를 이용해서 업로드한 da.txt 파일을 fuck.asp 파일로 변경하였다.
해당 파일은 IIS 환경에서 동작하는 웹 쉘 파일로 공격자는 웹쉘을 이용해 웹 서버를 장악했다.
정상 범주의 데이터를 제거한 것만으로 공격자의 공격 경로를 찾아 낸 것이다.
패킷 분석
앞서 로그를 이용해 침해 분석하는 방법을 살펴 보았다. 이번에는 네트워크 패킷을 분석해 보자. 마찬가지로 분석 범위를 선정하는 작업 만으로도 상당히 침해분석을 효율적으로 수행 할 수 있다.
<짚더미 1단계 – 메소드 점검>
Statistic > HTTP > Packet Counter > 필터 입력 없이 Create stat 클릭
통계 정보를 추출해 보면 사용된 메소드 정보와 웹 서버의 응답 코드 정보를 한눈에 요약해서 살펴 볼 수 있다. 요약된 정보를 통해 분석 대상 범위에서 제외할 정보를 정의한다. 효율적으로 분석 작업을 하기 위해서는 정상 범위의 데이터를 제외할 필요가 있다. 정상 범위를 정의하기 위해 수집한 정보의 현황을 먼저 살펴보는 과정이다.
<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치우기>
로그 분석할 때와 마찬가지로 정상 범주의 패킷을 제거하자. 정상 범위로 웹 요청 패킷 중 GET 요청 패킷을 제외해보자. 와이어샤크에 패킷 필터 구문을 적용하자.
Filter > BPF(Berkeley Packet Filter) 형식 필터 구문 입력
| !(http.request.method == GET) && tcp |
GET요청이 포함된 패킷을 제외한 TCP 패킷을 불러왔다. 이 과정을 통해서 원본 패킷에서 분석해야 하는 범위를 상당수 좁혔다. 분석 대상을 선택하기 따라 추가적인 범위 구분이 가능 하다.
Case #1 GET요청이 아닌 웹 통신 분석
| !(http.request.method == GET) && tcp.dstport == 80 |
Case #2 실제 데이터 통신이 발생한 패킷만 분석
| !(http.request.method == GET) && tcp.dstport == 80 && tcp[13] == 18 |
Case #3 특정 메소드 분석
| http.request.method == NOTIFY |
<짚더미 치우기 3단계 – 상세 분석>
앞서 로그상에 정상 범주를 제외하고 남은 로그에 대해 상세 분석 하듯이 정상 범주를 제외한 패킷 상세 분석을 진행한다. 특정 코드 (“204”)에 의한 패킷분석을 통해서 사고 발생 연관 공격 패킷 또는 피해 관련 증적 정보를 추적한다.
로그와 패킷 분석 작업은 시간과 리소스가 많이 필요한 과정이다. 효율적인 이벤트 분석을 하기 위해 불필요한 데이터를 정제하고 공격의 흔적을 찾이 위해 적정한 범위로 분석 대상을 선별하는 작업이 중요하다.
침해사고 업무절차(워크플로우) 자동화 도구 활용
엔드포인트(Endpoint) 보안에 대한 이해
사이버 보안 침해사고가 발생하면 기업은 내부적으로 침해사고분석을 통해 공격자의 흔적을 찾아내고, 공격 당시 사건을 재구성하여 시스템에 발생한 피해를 파악 한다.
시스템에 침해가 발생하기 까지는 많은 일들이 발생 한다. 공격자가 시스템을 공격하고 장악하기 위해 정보 수집 과정을 거치게 된다. 이 과정에서 공격자는 대상 시스템의 서비스 종류, 시스템 현황, OS종류, IP대역, 포트정보, 취약점 정보 등 많은 정보를 수집하게 된다.
외부의 공격자가 정보 수집을 통해 충분히 공략할 대상 시스템의 약점을 파악했으면 취약점을 이용해 공격에 들어가게 된다. 보통 이 과정에서 많은 수의 공격이 탐지되고 차단이 된다. 공격자는 가능한 모든 방법을 동원해 탐지되지 않기 위해 우회 시도를 하고, 100번의 공격 중 1번의 공격이 성공하게 되면 공격 성공 단계에 이르게 된다. 바로 이 단계가 침해가 발생되는 시점 이다.
시스템 장악에 성공하면 공격자는 자신의 목적에 따라 시스템에 악성코드를 설치하거나 시스템의 정보를 유출하는 행위가 이뤄지고, 많은 경우 침해사고 발생에 대한 인지는 정보 유출 또는 시스템 변조가 발생되고 이뤄지게 된다. 공격자가 공격 대상의 약점을 악용해 개인정보유출과 랜섬웨어로 인한 피해로 이어지게 된다.
보안팀은 공격을 탐지하고 예방하기 위해 다양한 방법을 이용해 침입시도에 대해 모니터 한다. 주로 네트워크에서 발생되는 정보를 활용하게 된다. 가장 많이 사용되는 정보는 침입탐지시스템에서 제공하는 정보를 활용한다. 시스템에 가해지는 공격시도나 공격행위에 대해 네트워크 레벨에서 사전에 분석해 파악하고, 차단하면 시스템 침해를 예방할 수 있다.
시스템에 발생되는 변화를 모두 기록하는 운영체제의 시스템 로그는 보안 사고 대응 관점에서 중요한 정보다. 침해사고가 발생하면 시스템 로그 분석을 통해서 타임테이블을 정의하고 공격 경로와 시스템 피해를 파악할 수 있다. 공격자가 원격에서 시스템에 접근하게 되면 시스템에 접근을 시도한 계정과 원격 IP 또는 접근한 컴퓨터의 정보, 접근 시간 등 사고 조사에 중요한 IOC 정보를 수집할 수 있다.
네트워크에 노출된 윈도수 시스템에 로그인을 시도한 로그 샘플을 살펴보자. 해당 로그는 윈도우 보안 이벤트 로그다.
로그를 살펴보면 해외 49개 IP (대부분 러시아)에서 짧은 시간동안 사전식 대입 공격을 통해 로그인을 시도했다. 공격자는 135개의 ‘Username’을 변경해서 네트워크를 통해 로그인을 시도했다. 실제 시스템이 외부에 노출되면 여러분이 예상하는 것보다 빨리 공격에 노출된다. 한가지 흥미로운 부분은 공격자가 로그인을 시도한 Username 이다. 해외 공격자가 로그인을 시도하지만 실제 한글 이름이나 성의 영문 이니셜을 사전 파일로 사용한 것으로 보인다. 공격 대상 국가에 맞춰 사전 파일을 커스터마이징해서 공격하는 모습이 흥미롭다.
공격자의 로그인 실패 로그는 윈도우 보안 이벤트로 남기 때문에 사고 분석이나 보안 모니터링 로그로 활용할 수 있다. 개별 로그의 상세 분석 정보를 통해 필요한 IOC를 추출하고 여러 시스템을 분석할 때 분석 키워드로 사용한다.
운영체제의 시스템 로그는 사고 조사 뿐만 아니라 사고를 예방하는 관점에서도 중요하다. 공격자에 의해 백도어 프로그램이 설치되거나 시스템 명령이 실행되면 모든 정보를 시스템에 로그로 남길 수 있다. 특히 윈도우 운영체제의 시스템 로그에는 공격 과정에서 발생하는 다양한 정보가 로그에 기록된다.
시스템 로그는 중요성 만큼 기록하는 정보가 많다. 운영체제의 로그 설정에 따라 보관할 수 있는 기간도 다르기 때문에 분석가나 실시간 모니터링 관점에서는 로그를 XDR 플랫폼과 연동해서 사고 분석 과정에서 활용하거나 실시간 위협 탐지를 위해 활용한다.
사고가 발생할 경우 사고조사를 수행하는 분석가 입장에서는 피해 범위를 파악하기 위해 모든 시스템을 일일이 확이할 수 없기 때문에 시스템 로그를 수집해서 식별된 IOC와 연관된 시스템 로그를 분석해서 사고 피해 범위를 유추한다. 이후 파악된 시스템의 디지털 포렌식 작업이나 2차 상세 점검을 수행하는게 효율적으로 사고 분석을 수행할 수 있다.
실시간으로 수집되는 시스템 로그에는 시스템 운영과 관련된 다양한 정보가 수집된다. 보안팀에게는 실시간 보안 위협과 관련된 정보가 실시간으로 전달된다. 원격에서 공격을 시도할 경우 시스템에 접근하려는 시도가 로그를 통해 수집된다. 공격을 시도하는 원격 IP나 시스템에서 외부로 연결되는 백도어 IP를 수집해 모니터링 할 수 있다. 실시간 모니터를 위해서 보안팀은 오픈 소스 기반의 인텔리전스 (OSINT)를 활용 힐 수 있다.
엘라스틱(Elastic) SIEM 대시보드 feat. 클로바더빙
SIEM 플랫폼(Elastic SIEM)을 이용한 Threat Hunting 악성코드 감염 경로 분석 데모
네트워크 정보 수집
방화벽 허용 로그에는 4계층 기반의 통신 정보 활용이 가능 하다. 네트워크 통신을 주고 받은 IP 주소와 서비스 포트, 프로토콜, 통신량(byte) 등 활용이 가능 하다.
앞서 로그와 프로세스 정보 분석을 통해 공격 받은 시스템을 분석하는 방법을 살펴 보았다. 공격이 발생한 시스템이 확인되면 사고가 발생한 시간과 사고 발생 IP 주소를 키워드로 네트워크 통신 내역을 추적한다. 방화벽 허용 로그 검색을 통해서 공격 경로를 분석 한다. 다음은 네트워크 방화벽 허용 로그다.
| Sep 25 19:02:42 192.168.0.1 %ASA-6-302015: Built outbound UDP connection 35484054 for outside:10.0.1.127/137 (10.0.1.127/137) to inside:10.0.1.124/137 (10.0.1.124/137) Sep 25 19:04:45 192.168.0.1 %ASA-6-302016: Teardown UDP connection 35484054 for outside:10.0.1.127/137 to inside:10.0.1.124/137 duration 0:02:02 bytes 150 Sep 25 19:10:20 192.168.0.1 %ASA-6-302015: Built outbound UDP connection 35484817 for outside:10.0.1.127/138 (10.0.1.127/138) to inside:10.0.1.124/138 (10.0.1.124/138) Sep 25 19:12:22 192.168.0.1 %ASA-6-302016: Teardown UDP connection 35484817 for outside:10.0.1.127/138 to inside:10.0.1.124/138 duration 0:02:01 bytes 201 Sep 25 19:13:02 192.168.0.1 %ASA-6-302013: Built inbound TCP connection 35485033 for outside:192.168.0.118/51879 (192.168.0.118/51879) to inside:10.0.1.124/80 (10.0.1.124/80) Sep 25 19:13:02 192.168.0.1 %ASA-6-302014: Teardown TCP connection 35485033 for outside:192.168.0.118/51879 to inside:10.0.1.124/80 duration 0:00:00 bytes 0 TCP Reset-I Sep 25 19:13:02 192.168.0.1 %ASA-6-302013: Built inbound TCP connection 35485035 for outside:192.168.0.118/51879 (192.168.0.118/51879) to inside:10.0.1.124/80 (10.0.1.124/80) Sep 25 19:13:02 192.168.0.1 %ASA-6-302014: Teardown TCP connection 35485035 for outside:192.168.0.118/51879 to inside:10.0.1.124/80 duration 0:00:00 bytes 0 TCP Reset-I Sep 25 19:13:03 192.168.0.1 %ASA-6-302013: Built inbound TCP connection 35485036 for outside:192.168.0.118/51879 (192.168.0.118/51879) to inside:10.0.1.124/80 (10.0.1.124/80) |
수집한 방화벽 허용 로그에서 공격자 IP정보를 검색 후 접근한 시간과 통신 내역을 확인한다. 방화벽 로그에서 통신에 사용된 포트와 통신 시간, 통신량(byte) 정보를 확인한 수 있다. 이 정보는 공격자가 얼마나 많은 데이터 통신을 했는지 추축하는데 사용된다. 만약 FTP 통신을 통해 대용량의 통신을 주고 받았다면 자료 유출이 발생했을 가능성이 있다.
공격자가 현재 활동을 하고 있다면 방화벽 세션 정보를 확인해서 통신을 시도하고 있는 모든 시스템 IP 주소도 확인해 볼 수 있다. 다음은 시스코 방화벽에서 확인한 현재 접속한 세션 정보다.
| TCP out 172.18.0.175:1861 in 10.0.0.34:80 idle 0:00:30 Bytes 815 flags UIOB TCP out 172.19.0.68:33059 in 10.0.0.48:80 idle 0:17:23 Bytes 238 flags UfIB TCP out 172.20.0.151:1049 in 10.0.0.48:80 idle 0:20:34 Bytes 206 flags UfIB TCP out 172.21.0.103:23132 in 10.0.0.48:80 idle 0:02:08 Bytes 238 flags UfIB TCP out 172.16.0.188:3375 in 10.0.0.22:80 idle 0:01:04 Bytes 4564 flags UIOB TCP out 172.16.0.188:3374 in 10.0.0.22:80 idle 0:01:04 Bytes 24638 flags UIOB TCP out 172.16.0.188:3373 in 10.0.0.22:80 idle 0:01:04 Bytes 9557 flags UIOB TCP out 172.17.0.230:25 in 10.0.0.33:4232 idle 0:00:52 Bytes 0 flags saA TCP out 172.22.0.47:1080 in 10.0.0.48:80 idle 0:02:38 Bytes 256 flags UfIB TCP out 172.23.0.36:36474 in 10.0.0.48:80 idle 0:29:44 Bytes 256 flags UfIB |
공격자의 침투 경로를 분석하다 보면 방화벽에 남아 있는 정보로는 정보가 부족하다. 예를 들어 앞서 FTP 통신을 통해서 데이터를 보냈다는 사실은 방화벽 로그를 이용해 확인 할 수 있다. 하지만 어떤 파일이 전송되었는지, 공격자가 접속한 계정 정보가 무엇인지, 몇 개의 파일을 가져갔는지 정보는 알 수 없다.
특히 웹 서버처럼 다양한 변수를 사용하는 경우에는 공격 경로 파악하는데 상세 통신 내역이 반드시 필요하다.
분석에 필요한 정보는 웹 어플리케이션 방화벽이나 침입탐지 시스템에서 일부 확인이 가능하지만 전체 통신 내역을 확인하려면 모든 세션 정보를 수집해야 한다. 이 경우 패킷 수집 솔루션을 활용하지만 전체 패킷을 수집하기 때문에 분석할 정보가 상당히 많다.
전체 패킷을 수집하지 않아도 세션 정보로도 공격자의 경로 추적은 가능하다. Bro-IDS 프로그램은 오픈 소스 기반으로 네트워크 통신 분석 프로그램이다. 오픈 소스 프로그램에 대한 설명과 간단한 설치 가이드는 별첨 문서를 참고 하자.
세션[1] 분석 솔루션은 어플리케이션 통신 내역을 모두 수집할 수 있다. 분석가가 공격 경로를 파악하는데 필요한 정보를 제공한다. 다음은 웹 통신 내역을 수집 분석한 로그 샘플이다. URI를 포함해 웹 링크 횟수 및 참조 정보 등 분석에 유용한 다양한 정보를 제공한다.
다음은 웹 통신 내역을 수집한 후 엑셀을 이용해 URL 접근 내역을 통계로 작성한 결과다.
공격자 IP가 식별이 되었다면 공격자 IP를 검색 키워드로 URL 목록을 추출하고 접근한 통신 내역을 확인할 수 있다. 추출한 정보는 시간 순서대로 정리한 후 공격자 동선을 파악하는데 사용한다.
세션 분석 솔루션에서 제공하는 정보 중 통신 내역에 대한 통계 정보도 유용하게 활용된다. 해킹에 의해 비정상적으로 발생되는 어플리케이션이나 IP 주소를 찾아내는데 활용할 수 있다. 다음 그림을 보자.
공격자 IP가 식별 되었다면 좀더 쉽게 통신 내역을 분석할 수 있지만 공격자 IP를 식별해야 하는 경우에는 이러한 통계 정보를 활용하면 도움이 된다.
주로 많이 사용되는 통신 포트나 IP 주소를 제외하고 의도하지 않게 사용되고 있는 통신 포트에 주목하자. 악성코드 감염에 의한 현상일 수 있다.
주기적으로 해당 정보를 가공 활용한다면 내부에서 트래픽을 많이 사용하는 IP나 서비스에 대해 식별이 가능하고, 어떤 IP로 사용자 요청이 집중되는지 수치를 통해 확인 가능하다.
용도에 따라 다양하게 활용이 가능하다.
- 내부 서비스 포트 사용 현황
- 가장 많이 접근하는 도착지
- 가장 적게 접근하는 도착지
- 서비스 통계 현황
- 프로토콜 비율
- 패킷 flag별 비율
세션 분석 기반의 솔루션에서 수집할 수 있는 정보를 살펴 봤다. 상세한 통신 정보를 수집하고 공격 경로 분석에 활용하는 것이 핵심이다.
네트워크 기반의 상용 보안 제품도 애플리케이션 분석을 기반으로 이상 행위에 대한 탐지 및 차단 기능을 제공한다.
경우에 따라서 네트워크 상에 주고 받은 모든 패킷을 수집해 위협과 관련된 이상 행위를 찾아내야 할 경우가 있다. 풀 패킷(Full Packet) 파일을 분석하려고 하면 먼저 그 양에 한번 놀라고, 어디서 부터 시작해야 할지에 한번 더 막막함을 느끼게 된다. 이는 어마어마한 양의 네트워크 패킷을 처음부터 끝까지 모두 보려 하기 때문이다. 풀 패킷 분석을 한다고 해서 모든 패킷을 하나하나 다 분석할 필요 없다. 앞서 이벤트 분석 방법론에서 언급했던 것과 마찬가지로 필요한 패킷을 선별적으로 분석하면 된다. 필요한 경우 추가 분석을 진행하면 된다. 모든 패킷을 분석하는 부담감을 버리길 바란다.
선별적으로 이벤트를 분석하기 위해서는 먼저 분석 대상과 분석 범위에 대해서 정의해야 한다. 분석 범위의 기준은 여러가지가 있다. 우리는 이번 장에서 분석 범위의 기준을 비 정상 범위의 대상으로 지정하여 분석하는 방법을 살펴 볼 것이다.
[1] 세션(session) [IT용어] ① 망 환경에서 사용자 간 또는 컴퓨터 간의 대화를 위한 논리적 연결. (출처 네이버)