보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

비인가 원격 접근/제어 트래픽 로그 분석

2017.06.07

21,532

기술지원센터 분석기술팀 이세호, 문형훈

 

 

SPiDER TM V5.0은 이글루시큐리티 보안관제 경험과 빅테이터 활용역량이 집약된 통합보안관리솔루션으로 최초탐지부터 로그/네트워크 패킷 분석까지 일원화 된 관제환경구성을 통해 관제업무의 기민성과 효율성을 높이는 동시에 인프라 전반에 대한 가시성을 확보합니다.   

 

 

1. 개 요

 

최근 글로벌 보안기업들이 발표한 ‘2017년 1분기의 공격 특징을 살펴 보면 흔적 지우는 와이퍼 그리고 파일리스 악성코드 등 정교한 표적형(APT) 공격이 급격히 증가했다. 또한 유명 인터넷 검색 엔진인 쇼단(shodan)의 멀웨어 헌터를 통해 서버, 라우터, 웹캠등 인터넷과 연결된 수많은 기기들이 RAT에 의해 통제 당하는 걸 확인할 수 있다.  또한 한국인터넷진흥원에서 수집/분석한 1분기 악성코드를 살펴보면 가장 많이 확인된 악성코드 유형은 랜섬웨어>원격제어>정보탈취 순 이였다. 특히 국내 PC 환경에 맞춤 제작되는 지능형 악성코드들로 인해 1차 감염 후 원격제어를 통해 내부침투와 정보유출과 같은 2차 침입 피해가 증가하고 있다. 즉, 최초 침입이 성공하면 공격자는 감염된 PC를 통해 공격 지속성을 유지하기 위해 원격 통로를 생성한다. 

이번 SIEM Guide에서는 대표적인 원격제어 프로토콜인 SSH, FTP, RDP, XRDP, TeamViewer, RDB 관리 접속과 Proxy Tool을 통해 비인가 원격 접근 시 발생하는 트래픽 로그를 분석하는 방법에 대해 기술하고자 한다. 

 

 

2. 비인가 원격 접근/제어 시 FW&IPS 트래픽 및 OS 로그 분석

 

지난호에서 비인가 접근시도 탐지 방법에 대해 알아 보았다면 이번호에서는 비인가 원격 접근/제어 시 발생하는 FW의 트래픽 로그와 IPS의 탐지 로그, 그리고, EndPoint단인 서버의 시스템(OS) 로그에서 발생하는 로그들을 분석해 보겠다. 

 

먼저 분석할 방화벽 로그는 국산과 외산 2가지 종류로 방화벽 제조사마다 로그 생성의 특징이 있다.  P사 방화벽은 세션의 시작과 끝을 event_type 필드 처럼 start와 end로 구분을 해준다. 즉 syn 패킷을 처리하면 “start” type를 발생시키고, 세션이 종료가 되면 “end” type의 로그를 남긴다. 즉, SSH, 원격테스크톱 등 비인가 접근 시 즉시 탐지를 할 수가 있다. 또한 “end” type의 로그에는 세션의 연결(ESTABLISHED) 시간인 duration과 송수신한 bytes와 패킷 수 등 해당 세션에 대한 상세 정보를 같이 남긴다. 이러한 정보를 통해 비인가 접근한 시간과 송수신한 데이터의 양을 가능해 볼 수가 있다.

 

A사 방화벽은 프로토콜에 따라 세션 연결 시 syn 패킷 생성 여부가 달라진다. 즉, SSH 프로트콜 처럼 모든 세션 연결이 종료되어야만 로그를 생성을 하는 경우도 있다. 물론 기본 정책 로그에서 연결 시작과 연결 종료에 해당하는 모든 로그를 생성하도록 설정 한다면 가능하나 연결 지속 시간인 duration 필드의 시간 생성되지 않은 문제점이 있다. 그러나, tcp_flag 필드의 상태 값을 통해 해당 세션의 상태를 좀 더 정확히 알 수가 있다.

 

 


 [그림 1] 원격접속/제어 프로그램 & VPN Proxy 툴

 


▶ 비인가 원격 접근 로그 분석 시나리오

 

아래 [그림 2]는 3월호에서 다루었던 내용으로 내부 사용자가 악성코드에 감염된 이후, 권한이 있는 서버 관리자 PC에서 서버 팜으로 비인가 원격 접근을 하고 이어서 외부 C&C 서버 통신과 내부 데이터 유출 시 발생하는 로그를 분석하는 시나리오다.

 

위 시나리오에 따르면 해커는 SSH와 원격 터미널 프로그램을 이용하여 내부 서버 팜으로 지속 접근에 성공한다.

그리고, DB서버에서 내부정보를 export를 받은 후 VPN Proxy 를 이용하여 C&C 서버로 암호화 파일 전송을 한다. 그럼 이러한 과정에서 발생하는 트래픽 로그 분석을 시뮬레이션 해보겠다.

 

 

 

[그림 2] 비인가 접근/제어 트래픽 로그 분석 시나리오

 

 

3. 내부 →내부(사용자 → 서버팜) : FW/IPS 트래픽과 OS 트래픽 로그 분석

 

▶ SSH(SSH File Transfer Protocol -SSH 파일 전송 프로토콜) 트래픽 로그 분석

 

 

최근 탐지장비 우회를 위해 암호화 통신이 증가 하고 있다. 이러한 암호화 트래픽은 방화벽 정책 로그와 시스템(OS) 감사 로그를 통해 접근 이력을 확인할 수 있다.

 

암호 통신의 대표적인 툴인 시큐어 쉘 프로토콜(SSH)은 신뢰할 수 있는 데이터 스트림을 통해 파일 접근, 파일전송, 파일 관리 기능을 제공하는 네트워크 틀로 원격 제어 시 많이 이용하고 있다. 그럼 접근제어 시 발생하는 로그 특징에 대해 알아 보겠다.

 

우선 NAT환경 등 여러 보안장비에서 동일 세션 이력을 조회할 때, 출발지 Port를 활용하면 외부 방화벽 > 내부 방화벽 > 서버까지 접속한 이력을 한번에 검색 가능하다. 

아래 그림의 PA방화벽 로그 event_type 필드를 보면 하나의 세션에 대해 start와 end type이 명확히 구분된다. End type의 로그에서 출발 포트 3039번 세션이 SSH 어플리케이션으로 duration 2592초 동안 세션 연결되었음을 알 수가 있다. 그리고, A사 방화벽은 서두에 설명처럼 세션 연결이 종료된 후 tcp_flag “S sa A”와 "S sa A / FA fa A"로 정책 로그가 생성이 된다. 연결 시간은 2540초와 2572초 동안 연결됨을 알 수 있다. 마지막으로 서버의 Secure 로그에서는 접속IP, 계정, 성공여부의 정보가 포함되어 있으며 root 계정으로 Accepted 됨을 알 수가 있다. 암호화 통신이다 보니 개별 보안장비를 통해서는 접속한 계정이나 로그인 성공여부를 알 수 없는 부분을 OS로그를 수집함으로 쉽게 확인할 수 있다. 이렇듯 장비 별 부족한 정보를 상호 보완하기 위해서는 네트워크의 전체 경로에 존재하는 모든 장비의 로그 수집이 필요하다. 

 

장비별 관련 검색어는 아래와 같다.

 

검색어(PA) : log:fw AND event_type:end AND application:ssh AND duration:[600 TO *]

   (설명 : FW로그 중 SSH 프로토콜을 이용하여 600초 이상 장시간 연결되었던 로그 검색)

검색어(TG) : log:fw AND tcp_flag:"S sa A / FA fa A" AND d_port:22 AND duration:[600 TO *]

   (설명 : 22번 포트로 정상 종료된(tcpflag ‘S sa A / FA fa A’) 장기간 연결 세션 검색)

검색어(OS) : sublog:secure AND user:root AND action:"Accepted"

   ( OS에 ROOT 계정으로 SSH 정상 접속이 사용자 검색)

 

 

 

[그림 3] SSH 파일 전송 프로토콜 접근제어 로그

 

 

▶ SFTP 파일 전송 트래픽 로그 분석

 

SSH 프로트콜을 이용하여 접속 시 시스템 제어만 했는지 파일 송수신까지 했는지는 알 수가 없다. 대신 송수신 Packets 필드의 다량 패킷 과 송수신 bytes 필드의 데이터 전송 용량을 통해 구분은 가능하다. [그림 4]의 ①번 로그는 SSH 접속이며, 접속 시간이 긴 편에 비해 송수신 데이터 량은 적다. 그러나 ②③번 로그처럼 SFTP 사용시 접속 시간은 짧은데 반해 패킷 과 송수신 데이터 량이 큰걸 볼 수가 있다. 데이터 송신과 수신의 구분은 ②번 로그처럼 Sent Bytes가 크면 파일 업로드를 한 것이고, ③번 로그처럼 Rcvd Bytes가 크면 파일 다운로드 트래픽 이다.

 

검색어 : sent_bytes:[10000000 TO *] (설명:10MB 이상 로그 전송)

 

 

 

[그림 4] SFTP 파일 전송 로그

 

 

 

[그림 5] ②번 sftp로 업로드한 파일 : 80MB

 

 

 

[그림 6] ③번 sftp로 다운로드한 파일 : 74MB

 

 

▶ RDP(Remote Desktop Protocol) > mstsc : 원격 데스크톱 연결) 트래픽 로그 분석

 

 

1) 방화벽 트래픽 로그 분석 : 3389 포트

 

그래픽 사용자 인터페이스를 제공하는 대표적은 원격 접근/제어 프로토콜인 원격 데스크톱 프로토콜(RDP)은 마이크로소프트사가 윈도우 NT 4.0 서버, 터미널 서버 에디션의 일부로 개발한 소유(사유) 프로토콜(proprietary protocol)이다. 기본 포트는 TCP 포트 3389를 사용한다. 이 프로토콜은 ITU-T T.128 애플리케이션 공유 프로토콜의 확장이다. 그래서 차세대 FW에서 보면 처음 인증 요청 시 사용 애플리케이션 ID명이 t.120으로 남는 것을 확인 할 수 있다. 

 

아래 [그림 7]는 NAT 환경에서 RDP 접속 시 NAT 방화벽 정책 적용 이후 서버팜 방화벽을 통해 해당 서버까지 접속되는 로그이다. 원격테스톱 연결 시 P사 방화벽은 연결 요청부터 최종 세션 종료까지 t.120과 ms-r에 애플리케이션 트래픽이 5줄의 정책 로그가 생성된다.

반면 A사 방화벽은 연결 요청과 인증, 그리고 연결 종료로그까지 보통 3줄을 생성 시킨다. 윈도우 이벤트 뷰어[그림3-7]의 로그를 보면 RDP-Tcp 연결 요청 > 사용자 인증 > 연결 성공 > 연결 종료 순으로 서비스가 진행된다.

마지막에 생성된 로그의 Duration 필드를 통해 얼마 동안 세션 연결이 되었는지 알 수 있다. 그리고, sent_bytes와 rcvd_bytes 필드의 크기를 통해 송수신 파일 전송 량을 가늠할 수도 있다.

 

검색어 :  application:"ms-rdp" AND duration:[600 TO *] AND pkt_bytes:[* TO 200000]

  (설명 : ms-rdp 애플리케이션 사용과 세션 연결시간이 600초 이상이며, 200000byte 이하인 트래픽 로그)

검색어 : tcp_flag:"S sa A / RA" AND duration:[600 TO *] AND sent_bytes[1000000 TO *]

   ( 설명 : 원격 터미널 사용 중 외부로 데이터 전송이 큰 경우)

 

 

 

[그림 7] 원격 데스크톱 접근/제어 트래픽 로그

 

 

2) 윈도우 OS 이벤트 뷰어에 원격 테스크톱 관련 이벤트

 

① 이벤트 ID : 261 > 수신기 RDP-Tcp이(가) 연결을 받았습니다. (같은 로그 두번 생성됨)

② 이벤트 ID : 1149 > 원격 데스크톱 서비스: 사용자 인증 성공

③ 이벤트 ID : 25 > 원격 데스크톱 서비스 : 세션 다시 연결 성공

④ 이벤트 ID : 24 > 원격 데스크톱 서비스 : 세션 연결 끊김

 

 

 

[그림 8] 윈도우 이벤트 뷰어 : 원격 데스크톱 서비스 로그

 

 

3) IPS 탐지 로그 

 

IPS 로그에서는 “ms_terminal_derver_request(TCP)” 명으로 실시간 탐지 된다.

앞서 A사의 방화벽의 늦게 탐지되는 문제에 대해서는 IPS 모듈에서 탐지는 이벤트 로그를 활용하여 실시간 탐지하면 된다. 

 

검색어 : attack:ms_terminal_server_request(TCP)

 

 

 

[그림 9] 원격 데스크톱 접근/제어 트래픽 탐지

 

 

▶ 리눅스 원격 터미널 제어 트래픽 로그 분석 : XRDP 

 

리눅스 서버도 그래픽 사용자 인터페이스를 제공하는 xrdp를 사용하여 원격제어가 가능하다. 사용하는 포트 또한 TCP 3389이다. 리눅스 서버에서는 GUI 화면 접속을 위해 vnc를 많이 사용하였으나 최근 xvnc를 이용하여 원격 테스크톱 프로그램으로 접속 가능한 xrdp를 더 많이 사용하는 듯 하다.

로그 생성은 RDP와 동일하게 RDP-Tcp 연결 요청(S sa A / RA) > 연결 지속(S sa A) > 연결 종료(S sa A / RA a)순으로 로그 3줄이 생성 된다.  ID/PW등 접속 실패 시 요청(S sa A / RA) > 종료(S sa A / fa A RA)의 트래픽을 생성 시킨다.

 

 


 [그림 10] 리눅스 XRDP 접속/제어 트래픽 탐지

 

 

 

 

[그림 11] 원격 데스크톱 XRDP(리눅스) 설정 및 접속 화면

 

  

▶ RDP 브루트포스(Brute force) 공격 트래픽 로그 분석 : FW+IPS

 

방화벽 로그를 보면 세션 연결 시간이 0.01초 동안 과다 접속 시도가 이루어 진걸 확인할 수 있다. 또한 duration(세션) 필드 값이 10초로 동일한 세션 시간과 송수신 패킷/용량이 동일함을 알 수가 있다. 그리고, “Application: insufficient-data”와 “tcp_fla:S sa A / ra” 필드의 로그가 생성되며, 비정상 트래픽으로 인증이 실패 되었음을 쉽게 알 수가 있다.

IPS 로그에서는 “ms_terminal_derver_request(TCP)” 명으로 실시간 탐지 된다.

 

검색어 : tcp_flag:"S sa A / ra“  AND sent_bytes:175 AND rcvd_bytes:92

 

 

 

[그림 12] RDP 브루트포스(Brute force) 공격 트래픽

 

 

▶ 윈도우 이벤트 뷰어 : RDP 브루트포스(Brute force) 공격 트래픽 로그

 

윈도우의 이벤트 뷰어에서 발생한 이벤트를 보면 이벤트ID 261 “수신기 RDP-Tcp이(가) 연결을 받았습니다.” 라는 이벤트가 많이 발생함을 볼 수가 있다.

 

 

 

[그림 13] 윈도우 이벤트 뷰어 화면

 

 

▶ SSH 브루트포스(Brute force) 공격

 

RDP 프로토콜과 달리 SSH 로그인 실패 시 타임아웃 대기 시간이 길다 보니 RDP 보다 2개의 시간과 트래픽이 발생한다. Application:ssh 정상으로 로그 생성되며, tcp_flag는 “S sa A / fa A FA a”로 정상 세션 종료까지 이루어 진다. 

 

검색어 : d_port:22 AND duration:23 AND tcp_flag:"S sa A / fa A FA a" AND rcvd_byte:3715

 

 

 

[그림 14] SSH 브루트포스 공격 트래픽

 

 

▶ TeamViewer(원격제어) TCP 5938 포트 트래픽 로그 분석

 

 

컴퓨터 원격 제어 프로그램으로 널리 알려져 있는 teamviewer는 SSH, 원격 테스톱 처럼 클라언트가 특정 서비스 포트를 LISTENING하고 있는 서버로 직접 접속하는 방식이 아니다.

즉, 사용자PC와 서버에 클라이언트 프로그램을 통해 팀뷰어 중계 서버로 접속이 되면, 팀뷰어 중계기 서버에서 서로간에 세션을 연결시켜 준다.  그러기 때문에 서버로 접근한 트래픽 로그를 찾으면 로그를 검색할 수 없다. 악성코드가 감염이 되면 외부의 C&C서버로 접근하듯이 인터넷 상에 있는 팀뷰어 중계 서버로 접속을 한다.

[그림 15]에서 보듯이 원격 데스크톱은 3389 Local Port로 접속이 되었지만, 팀뷰어는 5938 Remote Port(내부->외부)로 접속이 된 세션을 확인할 수 있다.

 

 

 

[그림 15] 팀뷰어 연결 세션

 

 

[그림 16]에서 원격 제어를 하고자 하는 서버IP가 출발지IP가 되어 외부의 인증/중계서버로 접속하는 트래픽 로그를 확인할 수 있다. 팀뷰어도 동일하게 최종 세션 연결이 종료(tcp_flag:"S sa A / FA fa a A")되면 얼마 동안 연결이 지속되었는지 확인할 수 있는 로그가 생성된다. 인증과 중계서버 연결 등으로 원격 데스크톱 접속 보다 많은 트패픽을 생성 시키며, 목적지 국가는 모두 외국이다. 팀뷰어 또한 파일전송 기능을 지원 한다. 송수신 바이트와 세션 연결시간 등으로 고려하여 판단하면 된다.

 

검색어 :  application:”teamviewer-base” AND (!d_country:KR OR !d_country:”-“)

   (설명 : 팀뷰어 애플리케이션을 이용하여, 해외로 접속한 로그 검색)

검색어 :  d_port:5938 AND duration:[60 TO *] AND tcp_flag:"S sa A / FA fa a A" AND sent_bytes:[10000000 TO 99000000]

 

 

 

[그림 16] 팀뷰어 원격제어 트래픽 로그

 

 

▶ Application-Control 모듈 탐지 로그

 

 

차세대 방화벽들의 주요 기능인 애플리케이션 액세스를 제어하는 기능들이 포함되었다. A사 방화벽 역시 Application-control 모듈을 통해 팀뷰어 인증서버에 로그인시 53 Port 도메인 질의 시 “teamview_login_traffic(UDP)” 탐지 명으로 경보 이벤트를 확인할 수 있다.

 

검색어 :  app_name:teamview AND attack:"teamview_login_traffic(UDP)"

 

 

 

[그림 17] TG UTM 의 Application-Control 모듈 탐지 로그

 

 

▶ BIND DNS 서버의 도메인 질의 로그 

 

DNS의 질의 로그 분석을 통해 내부 사용자가 팀뷰어 사용을 위해 접속 시도한 흔적을 쉽게 찾을 수 있다. 로그인 인증을 하기 위해 A 레코드로 teamviewer.com의 masterXX, serverXXXXX, client 서브 도메인으로 질의를 한다. 원격 제어를 시도하거나 허용 하더라도 동일한 질의가 발생한다.

 

검색어 : log:dns AND origin:192.168.1.98 AND domain:*teamviewer*

 

 

 

[그림 18] BIND DNS 서버 질의 로그

 

 

4. 서버팜→ 사용자 : RDBMS 접속 트래픽 로그 분석

 

▶ RDBMS 오라클 1521 포트 트래픽 로그 분석

  

오라클 접속 포트인 1521 포트로 접속 시 패스워드가 틀릴 경우 접속 갱신 시간인 10~30초 정도의 인터벌이 생긴다. A사 방화벽 같은 경우 로그인 성공 시 tcp_flag 상태는 “S sa A / RA”이며, 로그인 실패 시 "S sa A / FA fa a fa"와 "S sa A / FA fa a A"이다. 프로토콜 마다 통신하는 방식이 다르다 보니 TCP Flag 상태도 다르다는 걸 볼 수가 있다. 

DB 접속 로그 중 눈여겨 볼 부분은 1번 트래픽 처럼 DB 정보를 Export 하는 경우일 것이다.

sftp나 ftp와 보다 데이터 추출 시간이 느리기 때문에 장시간 세션과 다운로드 받는 형태이라 rcvd bytes 용량이 큰 트래픽을 주의하여 보면 내부정보 유출 분석 시 용이하다. 

참고로, Sent_bytes 필드와 rcvd_bytes 필드의 단일 용량과 10분 혹은 하루 등 지정 시간 동안의 전체 용량의 합계가 일정 용량 이상일 경우 경보를 발생 시킬 수도 있다.

 

검색어: tcp_flag:"S sa A / RA" AND duration:[60 TO 452] AND rcvd_bytes:[10000000 TO 113913296]

 

 

 

[그림 19] 오라클 1521 Port 접속 로그

 

 

5. 내부 → 외부 : WEB Proxy 트래픽 로그 분석

 

▶ UltraSurf : WEB Proxy 툴 

 

UltraSurf 툴은 보안 필터 기능을 하는 무설치, 저 용량 프로그램으로 웹 접속 시 크롬의 브라우저 경우 시크릿 모드로 실행되어 사용기록과 방문한 사이트나 쿠키 등과 같은 민감한 정보들은 저장을 막아준다. 그리고, Proxy 툴의 핵심 기능인 세가지 서로 다른 서버를 사용하여 자신의 IP를 위장 시켜주며, HTTPS 암호화 통신을 기본 통신으로 한다.

내부 웹서버에 TOR 브라우저나 web Proxy 툴을 이용하여 접근하는 IP들을 검출하거나, 내부 사용자들이 web Proxy 툴 사용을 검출할 때 활용 가능하다. 또한 DB서버에서 Export 받은 데이터를 외부 C&C 서버로 유출할 경우 추적을 피하기 Proxy 툴을 많이 이용 하기도 한다.

 

[그림 20]에서처럼 web Proxy 툴을 이용하여 내부 홈페이지로 접속 시 가장 큰 차이점은 Proxy서버를 경유하여 접속하다 보니 정상 접속에 비해 세션 연결시간(duration 필드)이 길며, 그로 인해 한 세션당 송/수신 패킷 또한 정상 접속에 비해 두 세배 크다.

 

 

 

[그림 20] UltraSurf 툴로 내부 웹서버 접속한 트래픽(외부->내부)

 

 

[그림 21]는 Proxy 툴을 이용하여 내부에서 외부로 나가는 트래픽 로그이다. [그림 22]에서 보듯이 whois를 해보면 자신의 IP가 64.71.171.90로 나오지만, 해당 방화벽에서 나가는 트래픽으로 검색해 보면 찾을 수 없을 것이다. 즉, 내부 사용자가 Proxy서버로 접속하는 IP와 Proxy서버에서 홈페이지로 접속할 때 IP가 다르다는 것이다. Proxy 툴 실행이 하나의 세션을 통신하며 Proxy 툴을 종료할 경우 방화벽에선 장시간 세션으로 로그 한 줄이 생성된다. 

내부 사용자의 사용여부를 검출하고자 한다면 평소 방문하지 않은 해외 IP로 접속 시 평판탐지 기능 등으로 모니터링 하면 된다.

 

검색어 : d_ip:443 AND duration:[600 TO *] AND (!d_country:KR OR !d_country:”-“)

 

 

  

[그림 21] UltraSurf 사용하여 외부 접속(내부->외부)

 

[그림 22]처럼 세션 연결 후 같은 세션으로 많은 패킷이 송수신되고 있다.

 

 

  

[그림 22] UltraSurf 세션 트래픽 WireShark 패킷 캡처

 

 

6. 마치며…

 

위와 같이 외부에서 비인가 원격 접근 또는 제어 시 활용될 수 있는 프로토클 및 TOOL을 살펴보면 접속 시간이 길며, 송수신 패킷과 전송량이 크다는 공통점을 확인 할 수 있었다. 외부 비인가 원격 접근 및 제어에 대한 분석을 하는 경우 외부->내부, 내부->내부, 내부->외부로 향하는 장시간 세션을 우선적으로 검색 및 분석해 보는 것을 추천합니다.