봇 탐지 머신러닝 모델링

사이버 보안 분야의 머신러닝 모델링은 네트워크 프로토콜, 로그 기록 방식, 공격 기법, 취약점 등에 대해 종합적으로 이해하고 있어야 하기 때문에 처음 시작하는데 많은 어려움이 있습니다.

이번 글에서는 웹 로그를 대상으로 인터넷 봇 트래픽을 분류하는 모델을 만드는 과정을 통해 머신러닝 모델링 방법을 설명하려고 합니다. 인터넷 봇은 인터넷 익스플로러, 크롬과 같은 웹 브라우저가 아니라 자동화된 방식으로 웹사이트에 접속하는 프로그램을 의미합니다.

로그프레소에서는 실제로 따라할 수 있도록 로그프레소 스토어의 웹 로그를 익명화한 데이터를 제공합니다. opendata@logpresso.com 으로 연락주시면 데이터를 재배포하지 않으며 연구 목적으로만 사용하는데 동의하신 경우에 한해 데이터를 전달해드립니다. IP 주소를 익명화하는 대신, 접속 IP의 특성을 확인할 수 있도록 AI 스페라의 크리미널 IP 평판 정보 약 1만 건을 포함합니다.

이 웹 로그는 아래와 같은 필드를 포함하고 있습니다;

  • 접속 시각, 로그 ID, 레이블, 익명화된 IP 식별번호, 크리미널 IP 평판, 국가, ASN, 처리 소요시간, HTTP 응답 상태, 다운로드 바이트, HTTP 메소드, 경로 및 쿼리스트링, 개행으로 구분된 HTTP 헤더 목록

봇 데이터 특성 확인

머신러닝 모델링에서 가장 먼저 해야할 일은 데이터의 특성 확인입니다. 사람이 구분하지 못하는 것은 기계도 구분하기 어렵습니다. 아래는 크롬 브라우저를 통해 접속한 경우 기록되는 HTTP 헤더입니다:

Host: logpresso.store
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
Connection: Keep-Alive
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: https://<masked>
Accept-Encoding: gzip, deflate, br
sec-ch-ua: "Chromium";v="104", " Not A;Brand";v="99", "Google Chrome";v="104"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
sec-fetch-site: cross-site
sec-fetch-mode: navigate
sec-fetch-user: ?1
sec-fetch-dest: document
content-length: 0

아래는 아이폰 사파리 브라우저에서 접속한 경우 기록되는 HTTP 헤더입니다:

Host: logpresso.store
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1
Connection: Keep-Alive
Accept-Language: ko-KR,ko;q=0.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://www.logpresso.com/
Accept-Encoding: gzip, deflate, br
content-length: 0

아래는 masscan 봇이 접속한 경우 기록되는 HTTP 헤더입니다:

User-Agent: masscan/1.0 (https://github.com/robertdavidgraham/masscan)
Accept: */*
content-length: 0

아래는 zgrab 봇이 접속한 경우 기록되는 HTTP 헤더입니다:

Host: 3.39.215.159
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip
content-length: 0

아래는 Censys 봇이 접속한 경우 기록되는 HTTP 헤더입니다:

Host: 3.39.215.159
User-Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)
Accept-Encoding: gzip
Connection: close
content-length: 0

아래는 실제 공격의 HTTP 헤더입니다:

Host: 3.39.215.159
Content-Length: 20
Accept-Encoding: gzip, deflate
Accept: */*
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded

몇 개 밖에 안 되는 샘플이지만 어느 정도 경향성이 눈에 보일 것입니다. 주목할 수 있는 봇 HTTP 트래픽의 특징은 아래와 같습니다:

  • 전반적으로 HTTP 헤더의 수가 적은 경향이 있다.
  • Host 헤더에 IP 주소가 사용되거나 존재하지 않는다.
  • Accept 헤더는 */* 으로 모든 유형의 응답을 수락한다.
  • User-Agent 헤더 값은 마치 크롬 브라우저 같지만 브라우저 버전이 매우 낮다.
  • Accept-Encoding 헤더는 br (Brotli) 같은 최신의 압축 유형을 지원하지 않는다.
  • Accept-Language 헤더가 없거나 quality factor 없이 단순하다.
  • Referer 헤더가 존재하지 않는다.

왜 이러한 특징이 나타날까요? 봇은 자동화된 프로그램이므로 사용자 편의와 관련된 헤더가 없습니다. 인터넷을 광범위하게 스캔하며 활동하는 봇들은 특정 사이트를 목표로 하는 것이 아니기 때문에 도메인 정보가 없고 IP 주소 범위를 순차적으로 접속합니다. 반대로 말하면, 우리가 지금 만들고 있는 모델은 APT (Advanced Persistent Threat) 공격 탐지에는 적합하지 않다는 의미입니다. 단 하나의 모델이 모든 유형의 공격을 효과적으로 탐지하기는 어려우므로, 목적에 따라 모델을 조합할 필요가 있습니다.

한편, 2차적으로 파생되는 특성들도 존재합니다. IP 주소는 구간별로 ASN에 할당되는데, 샘플 데이터를 ASN (Autonomous System Number) 단위로 집계해보면 명확한 특성을 확인할 수 있습니다.

jsonfile masked_labeled_store_access.json
| pivot count rows asn cols label
| search in(asn, "*Korea Telecom*", "*OVH*", "*Free SAS*")

ASN별 정상 및 악성 데이터 분포

ASN에 따라 상당히 치우친 결과를 볼 수 있는데 이는 가입자망에서 직접 봇을 돌리는 것보다 클라우드나 호스팅 서비스에서 봇을 돌리는게 추적을 회피하는데 훨씬 유리하기 때문입니다. 그래서 경험이 많은 보안팀은 IP 대역만 봐도 직감적으로 정탐을 구분할 수 있습니다. 일반적인 고객이 굳이 클라우드나 호스팅 서비스를 통해 웹 서비스에 접속할 이유가 없습니다.

같은 맥락에서, 외부 인텔리전스를 활용하여 특정 IP 주소가 VPN IP 주소인지, 프록시 IP인지, TOR 노드 IP인지 구분할 수 있다면 정오탐을 판단하는데 상당한 도움이 될 것입니다. 아래는 샘플 데이터의 IP에 대해 AI 스페라에서 크리미널 IP 서비스의 평판 정보를 조회하여 생성한 자료입니다.

크리미널 IP 평판 데이터

하지만 현실적으로 모든 접속 IP 주소에 대해 매번 평판을 조회하기는 어려우므로, 이 정보는 라벨링에만 사용할 것입니다.

masked_labeled_store_access.json 파일은 미리 라벨링이 되어있지만, 모델러가 처음 맞닥뜨리는 가장 어려운 문제는 어떻게 대량의 학습용 데이터를 라벨링할 것인가 하는 부분입니다. 데이터에 라벨링이 되어있지 않다면 어떻게 해야할까요?

휴리스틱을 이용한 공격 로그 라벨링

로그프레소는 강력한 쿼리 기능을 제공하므로 휴리스틱 룰을 적용하여 명백한 공격 로그와, 정상 로그를 나눠볼 수 있습니다. 예를 들면, 스캐너 봇은 아래와 같이 대량의 HTTP 404 오류를 유발합니다.

jsonfile masked_labeled_store_access.json
| search pin == "IP_09686" 
| fields _time, log_id, pin, label, reputation, country, asn, method, uri, path, query, params, status, duration

스캐너 봇이 유발한 404 오류 목록

물론 정상적인 검색엔진의 경우에도 존재하지 않는 sitemap.xml 이나 favicon.ico 를 조회하려고 시도할 수 있으므로, 아래와 같이 404가 발생한 경로명들을 추출해보고 허용되는 접속 오류는 일부 수작업으로 걸러내도록 합니다.

jsonfile masked_labeled_store_access.json 
| search status == 404 
| stats count by path 
| eval len = len(path) 
| sort len

웹 애플리케이션 공격 경로 통계

약 2000건 이상의 공격 경로들을 확인할 수 있습니다. 단, 일부 마스킹 관련된 오류가 있기도 하고, 앞서 언급한 것처럼 정상적인 404 접속 시도도 존재하므로 관련 없는 경로들은 제외해야 합니다.

정상 사용자 및 브라우저의 경로 오류

load 77836557-74ac-4304-8efc-a0c28f92e4e9
| search not(in(path, "/timezone", "/ko/oauth", "/ko/login", "/ko/apps*", "/en/apps*", "/apps*", "/en/packages/*", "/ko/packages/*", "", "/", "//", "/en", "/ko", "/ip", "/ko/", "/robots.txt", "/sitemap.txt", "//sitemap.xml", "/sitemap.xml.gz", "/sitemap_index.xml", "/apple-touch-icon.png", "/apple-touch-icon-precomposed.png"))

이 쿼리 결과를 저장해두고 아래와 같이 다시 불러와서 조인시키면 명백한 공격 로그를 식별할 수 있습니다. 불러오기 메뉴에서 저장된 쿼리 결과를 클릭하면 guid를 확인할 수 있습니다.

jsonfile masked_labeled_store_access.json 
| join path [ load ba890e78-af76-4c4f-a658-185c68513681 | fields path ]
| fields _time, log_id, pin, label, reputation, country, asn, method, uri, path, query, params, status, duration

악성 라벨링이 완료된 데이터셋

전체 29만건 중에서 2만건의 봇 접속 로그가 명확하게 식별되었습니다. 가장 흔하게 보이는 /wp-includes/wlwmanifest.xml 경로 접근은 워드프레스 취약점 공격입니다. 이 쿼리 결과는 이후에 정상 데이터와 합쳐서 학습 데이터로 만들 것입니다.

휴리스틱을 이용한 정상 로그 라벨링

봇이 아닌 일반적인 브라우저의 접속 로그만 확실하게 추려낼 수 있는 방법이 어떤게 있을까요? 봇들도 User-Agent 헤더로는 일반 브라우저인 것처럼 위장하기 때문에 에이전트 문자열을 이용하는 것은 적절하지 않습니다. 정상 로그는 상대적으로 훨씬 많으므로 여러가지 방법이 있을 수 있겠지만, 여기에서는 봇이 일반적으로 ETag 기반의 캐시 로직까지 따라하지는 않는다는 점을 이용하려고 합니다.

웹 브라우저가 이전 컨텐츠를 캐시하고 있어야만 if-none-match 헤더로 ETag를 전송할 수 있고, 그 값이 정확해야만 웹 서버가 304 Not Modified 응답하게 되니 일반적인 웹 브라우저일 가능성이 훨씬 높습니다.

jsonfile masked_labeled_store_access.json 
| search status == 304
| fields _time, log_id, pin, label, reputation, country, asn, method, uri, headers

ETag를 이용한 정상 데이터 라벨링

이제 정상으로 확신할 수 있는 약 5만건의 데이터가 확보되었습니다.

학습 데이터 생성

앞서 여러가지 봇 데이터 특성에 대하여 언급하였습니다. 이제 원본 데이터에서 특성(feature)을 추출해야 합니다. 정규표현식을 사용하면 간단히 원하는 헤더 항목을 추출할 수 있습니다. 정규식 앞부분의 (?i) 는 대소문자를 무시하라는 의미입니다.

jsonfile masked_labeled_store_access.json 
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| fields _time, pin, user_agent, accept_lang, accept, connection, host, accept_encoding, chrome_ver, edge_ver, referer, accept_encoding, sec_fetch_site

HTTP 헤더 필드 추출

이 문자열 값들을 그대로 모델에 넣을 수도 있기는 하지만 나중에 학습되지 않은 범주형 (categorical) 값이 들어오면 분류 정확도가 떨어지기 때문에 좋은 결과를 기대하기 어렵습니다. 조금 더 전처리를 수행해봅시다:

jsonfile masked_labeled_store_access.json 
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| fields _time, log_id, pin, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot

머신러닝 모델 특성 추출

이제 수치형으로 깔끔하게 정리되었습니다. 각 특성의 의미는 아래와 같습니다:

  • header_count: 헤더 수
  • has_sec_fetch_site: sec-fetch-site 헤더 존재 여부
  • has_referer: referer 헤더 존재 여부
  • accept_all: */* 여부
  • accept_br: br 압축 가용 여부
  • accept_sdch: sdch 압축 가용 여부
  • chrome_ver: 크롬 버전
  • python_client: Python 클라이언트 여부
  • go_client: Go 클라이언트 여부
  • java_client: 자바 클라이언트 여부
  • fb_asn: 페이스북 ASN에서 접속
  • google_asn: 구글 ASN에서 접속
  • ms_asn: 마이크로소프트 ASN에서 접속
  • huawei_asn: 화웨이 클라우드 ASN에서 접속
  • yandex_asn: 얀덱스 ASN에서 접속
  • fb_client: 페이스북 클라이언트 여부
  • google_bot: User-Agent 헤더의 Google 봇 여부
  • bing_bot: User-Agent 헤더의 Bing 봇 여부
  • petal_bot: User-Agent 헤더의 Petal 봇 여부
  • yandex_bot: User-Agent 헤더의 Yandex 봇 여부
  • known_bot: 허용된 봇 여부. 위의 검색엔진 봇을 포괄하고 이후 IP 주소로 특정된 봇 허용

그러면 이제 이 모든 것을 합쳐서 라벨링된 학습 데이터를 만들 수 있습니다.

# 정상, 악성 라벨링된 데이터 병합
| jsonfile masked_labeled_store_access.json | search status == 304 | eval label = "BENIGN"
| union [ 
  jsonfile masked_labeled_store_access.json 
  | join path [ load ba890e78-af76-4c4f-a658-185c68513681 | fields path ]
  | eval label = "MALICIOUS"
]
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| fields _time, log_id, label, pin, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot

완성된 학습 데이터셋

이제 이 결과 데이터에서 _time, log_id, pin을 제외하고 labeled.csv로 다운로드 합니다. 복사-붙여넣기 편의상 이후 모델링은 로그프레소 쉘에서 수행하도록 하겠습니다.

logpresso> ml.addCsvInput bot labeled.csv
added

아래와 같이 로드된 데이터를 확인할 수 있습니다.

logpresso> ml.input bot
Input [bot]
---------------------
Type: csv
Size: 74444

Fields
---------------------
label (CATEGORICAL, cardinality 2)
header_count (NUMERIC)
has_sec_fetch_site (NUMERIC)
has_referer (NUMERIC)
accept_all (NUMERIC)
accept_br (NUMERIC)
accept_sdch (NUMERIC)
chrome_ver (NUMERIC)
python_client (NUMERIC)
go_client (NUMERIC)
java_client (NUMERIC)
fb_asn (NUMERIC)
google_asn (NUMERIC)
ms_asn (NUMERIC)
huawei_asn (NUMERIC)
yandex_asn (NUMERIC)
fb_client (NUMERIC)
google_bot (NUMERIC)
bing_bot (NUMERIC)
petal_bot (NUMERIC)
yandex_bot (NUMERIC)
known_bot (NUMERIC)

처음이니 모든 특성을 랜덤포레스트 모델에 투입해봅시다. 학습 목표인 label 변수 앞에는 + 기호로 표시합니다.

logpresso> ml.createModel rforest bot bot
Input [bot]
---------------------
Type: csv
Size: 74444

Fields
---------------------
label (CATEGORICAL, cardinality 2)
header_count (NUMERIC)
has_sec_fetch_site (NUMERIC)
has_referer (NUMERIC)
accept_all (NUMERIC)
accept_br (NUMERIC)
accept_sdch (NUMERIC)
chrome_ver (NUMERIC)
python_client (NUMERIC)
go_client (NUMERIC)
java_client (NUMERIC)
fb_asn (NUMERIC)
google_asn (NUMERIC)
ms_asn (NUMERIC)
huawei_asn (NUMERIC)
yandex_asn (NUMERIC)
fb_client (NUMERIC)
google_bot (NUMERIC)
bing_bot (NUMERIC)
petal_bot (NUMERIC)
yandex_bot (NUMERIC)
known_bot (NUMERIC)

Select Model Fields? +label, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
created

학습 명령을 내리고 진행 상태를 확인합니다:

logpresso> ml.fit bot
started

logpresso> ml.tasks
Model Tasks
-------------
[6518b162-3cc8-4b90-9d25-ebee8e80ed67] rforest [bot] progress (load 100.00%, train 40.00%), elapsed 4 secs

이제 모델 정보를 조회하면 변수 중요도와 모델 성능을 확인할 수 있습니다:

logpresso> ml.model bot
Model [bot]
-------------------
Fields
-------------------
[*] label (cardinality: 2)
[ ] header_count
[ ] has_sec_fetch_site
[ ] has_referer
[ ] accept_all
[ ] accept_br
[ ] accept_sdch
[ ] chrome_ver
[ ] python_client
[ ] go_client
[ ] java_client
[ ] fb_asn
[ ] google_asn
[ ] ms_asn
[ ] huawei_asn
[ ] yandex_asn
[ ] fb_client
[ ] google_bot
[ ] bing_bot
[ ] petal_bot
[ ] yandex_bot
[ ] known_bot
-------------------
Hyper Parameters
-------------------
-------------------
Variable Importance
-------------------
accept_all: 39.61612659638045
has_sec_fetch_site: 3.191940042593
header_count: 1.5948264282227802
accept_sdch: 0.43369895792856517
fb_asn: 0.3070484892597034
has_referer: 0.10297082667489638
accept_br: 0.0
chrome_ver: 0.0
python_client: 0.0
go_client: 0.0
java_client: 0.0
google_asn: 0.0
ms_asn: 0.0
huawei_asn: 0.0
yandex_asn: 0.0
fb_client: 0.0
google_bot: 0.0
bing_bot: 0.0
petal_bot: 0.0
yandex_bot: 0.0
known_bot: 0.0
-------------------
Performance
-------------------
Accuracy: 0.9952982267598065
Precision: 0.9952982267598065
Recall: 0.9952982267598065
F1 score: 0.9952982267598065

처음 돌렸는데 정확도가 무려 99.5%라니 이게 정말 통할까요? 전체 데이터에 동일하게 피처 추출한 상태로 rforest 명령어를 추가하여 확인합니다:

jsonfile masked_labeled_store_access.json
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| # 랜덤포레스트 모델 호출
| rforest model=bot header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
| fields _time, log_id, _guess, label, pin, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot

랜덤포레스트 모델 추론

랜덤포레스트 모델이 분류한 결과는 _guess 필드에 출력됩니다. 일단 시작부터 틀린 것이 보이니 뒤에 stats count by _guess, label 을 추가하여 혼동행렬 (Confusion Matrix)을 계산해봅시다.

혼동 행렬

테스트할 때는 99.5%인 줄 알았는데 전체 데이터에 대해서 돌려보니 88% 밖에 안 됩니다. 뭐가 잘못된 것일까요? 모델은 MALICIOUS라고 답했는데 BENIGN이었던 데이터들을 확인해봅시다.

jsonfile masked_labeled_store_access.json
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| # 모델 호출
| rforest model=bot header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
| fields _time, log_id, _guess, label, pin, user_agent, headers, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
| # 오탐 결과만 선별
| search _guess == "MALICIOUS" and label == "BENIGN"

오탐 샘플 분석

보아하니 검색엔진 봇들이 모두 악성으로 분류된 것 같습니다. _guess == "MALICIOUS" and label == "BENIGN” 결과를 대상으로 한 번 통계를 내보겠습니다:

result 4704 | stats count by user_agent | sort -count

오탐 발생한 유저 에이전트 통계

오탐 26327건 중에 PetalBot, bingbot, Slack-ImgProxy, facebookexternalhit 정도만 제대로 처리되더라도 22577건, 즉, 오탐의 85%를 제거할 수 있습니다. 그런데 이 검색엔진 관련된 피처를 빠뜨렸던게 아닙니다. 왜 이런 일이 벌어졌을까요? 이 때 모델 정보의 변수 중요도(Variable Importance)를 다시 확인해봐야 합니다.

-------------------
Variable Importance
-------------------
accept_all: 39.61612659638045
has_sec_fetch_site: 3.191940042593
header_count: 1.5948264282227802
accept_sdch: 0.43369895792856517
fb_asn: 0.3070484892597034
has_referer: 0.10297082667489638
accept_br: 0.0
chrome_ver: 0.0
python_client: 0.0
go_client: 0.0
java_client: 0.0
google_asn: 0.0
ms_asn: 0.0
huawei_asn: 0.0
yandex_asn: 0.0
fb_client: 0.0
google_bot: 0.0
bing_bot: 0.0
petal_bot: 0.0
yandex_bot: 0.0
known_bot: 0.0

accept_all 특성이 지배적이고, fb_asn 외의 검색엔진 관련된 변수는 모델에 전혀 사용되지 않은 것처럼 보입니다. 한 번 이전의 학습 데이터에서 known_bot 분포를 확인해봐야겠습니다.

# 정상, 악성 라벨링된 데이터 병합
| jsonfile masked_labeled_store_access.json | search status == 304 | eval label = "BENIGN"
| union [ 
  jsonfile masked_labeled_store_access.json 
  | join path [ load ba890e78-af76-4c4f-a658-185c68513681 | fields path ]
  | eval label = "MALICIOUS"
]
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| fields _time, log_id, label, pin, path, headers, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
| # known_bot 통계
| pivot count rows known_bot cols label

known_bot이 1인 경우 오히려 73건 모두 악성으로 라벨링되어 있습니다. 아까 404 응답에 대해 확실한 공격으로 분류했었는데 뭔가 잘못된듯 합니다.

접속 허용된 봇에 대한 분류 결과 통계

원본을 확인하니 페이스북에서 포스팅할 때 경로 입력 과정의 오타로 인해 404 응답 처리된 로그들이 있었고 그것들이 모두 악성으로 분류되었다는 점을 확인할 수 있습니다. 그 외에 bing 봇의 atom.xml, sitemaps.xml 요청에 대한 404 응답도 모두 악성으로 잘못 분류되었습니다.

악성으로 잘못 분류된 데이터 예시

그 외에 Slack도 known_bot으로 분류해야 하는데, Slack은 AWS를 사용하므로 IP 주소로 특정할 수 밖에 없습니다. 1444건이 출력되는 아래의 쿼리 결과를 저장합니다.

jsonfile masked_labeled_store_access.json
| search headers == "*Slack-*"
| stats count by pin, asn

이것들을 모두 반영해서 학습 데이터를 다시 정리합니다.

# 정상, 악성 라벨링된 데이터 병합
| jsonfile masked_labeled_store_access.json | search status == 304 | eval label = "BENIGN"
| # 슬랙 known_bot 정상 데이터 추가
| union [ 
  jsonfile masked_labeled_store_access.json 
  | search headers == "*Slack-*" 
  | eval known_bot=1, label = "BENIGN" ]
| # 악성 분류 데이터에서 facebook이나 bingbot은 정상으로 재분류
| union [ 
  jsonfile masked_labeled_store_access.json 
  | join path [ load ba890e78-af76-4c4f-a658-185c68513681 | fields path ]
  | rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
  | eval label = if(user_agent == "*facebookexternalhit*" or user_agent == "*bingbot*", "BENIGN", "MALICIOUS") ]
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, nvl(known_bot, 0))
| fields _time, log_id, label, pin, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot

모델 데이터를 다시 적재하고 학습합니다:

logpresso> ml.addCsvInput bot_fixed labeled_fixed.csv
added

logpresso> ml.createModel rforest bot2 bot_fixed
Input [bot_fixed]
---------------------
Type: csv
Size: 76867

Fields
---------------------
label (CATEGORICAL, cardinality 2)
header_count (NUMERIC)
has_sec_fetch_site (NUMERIC)
has_referer (NUMERIC)
accept_all (NUMERIC)
accept_br (NUMERIC)
accept_sdch (NUMERIC)
chrome_ver (NUMERIC)
python_client (NUMERIC)
go_client (NUMERIC)
java_client (NUMERIC)
fb_asn (NUMERIC)
google_asn (NUMERIC)
ms_asn (NUMERIC)
huawei_asn (NUMERIC)
yandex_asn (NUMERIC)
fb_client (NUMERIC)
google_bot (NUMERIC)
bing_bot (NUMERIC)
petal_bot (NUMERIC)
yandex_bot (NUMERIC)
known_bot (NUMERIC)

Select Model Fields? +label, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_c
lient, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
created

logpresso> ml.fit bot2
started

logpresso> ml.tasks
Model Tasks
-------------
[5fc1a68a-4a3b-4810-ab7a-9608212ed480] rforest [bot2] progress (load 100.00%, train 30.00%), elapsed 4 secs

새로 학습된 모델의 정확도는 어떤지 확인해봅니다:

logpresso> ml.model bot2
Model [bot2]
-------------------
Fields
-------------------
[*] label (cardinality: 2)
[ ] header_count
[ ] has_sec_fetch_site
[ ] has_referer
[ ] accept_all
[ ] accept_br
[ ] accept_sdch
[ ] chrome_ver
[ ] python_client
[ ] go_client
[ ] java_client
[ ] fb_asn
[ ] google_asn
[ ] ms_asn
[ ] huawei_asn
[ ] yandex_asn
[ ] fb_client
[ ] google_bot
[ ] bing_bot
[ ] petal_bot
[ ] yandex_bot
[ ] known_bot
-------------------
Hyper Parameters
-------------------
-------------------
Variable Importance
-------------------
accept_sdch: 56.48699943927758
yandex_bot: 22.787406812885486
accept_all: 21.551910129425835
has_sec_fetch_site: 4.790621163151365
header_count: 1.281179927083544
chrome_ver: 0.20474131367645387
has_referer: 0.20081416801138077
yandex_asn: 0.04364948596639201
google_asn: 0.03269234686475131
accept_br: 0.0
python_client: 0.0
go_client: 0.0
java_client: 0.0
fb_asn: 0.0
ms_asn: 0.0
huawei_asn: 0.0
fb_client: 0.0
google_bot: 0.0
bing_bot: 0.0
petal_bot: 0.0
known_bot: 0.0
-------------------
Performance
-------------------
Accuracy: 0.9879659142652703
Precision: 0.9879659142652703
Recall: 0.988356208937748
F1 score: 0.9881610230627685

F1 점수는 98.8%로 이전보다 오히려 약간 떨어졌는데요. 이제 전체 데이터에 대해 새로 만든 bot2 모델을 돌려서 다시 결과를 확인할 것입니다. 주의할 점은 학습할 때 Slack을 알려진 봇으로 처리했으니 모델 입력 시 동일한 처리를 추가해야 한다는 것입니다. rforest 명령어의 model 이름도 bot2 로 변경해야 합니다.

jsonfile masked_labeled_store_access.json
| # 피처 추출 영역
| rex field=headers "(?i)user-agent: (?<user_agent>[^\n]+)"
| rex field=headers "(?i)accept-language: (?<accept_lang>[^\n]+)"
| rex field=headers "(?i)accept: (?<accept>[^\n]+)"
| rex field=headers "(?i)connection: (?<connection>[^\n]+)"
| rex field=headers "(?i)host: (?<host>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)chrome/(?<chrome_ver>\d+)"
| rex field=headers "(?i)edg/(?<edge_ver>\d+)"
| rex field=headers "(?i)referer: (?<referer>[^\n]+)"
| rex field=headers "(?i)accept-encoding: (?<accept_encoding>[^\n]+)"
| rex field=headers "(?i)sec-fetch-site: (?<sec_fetch_site>[^\n]+)"
| eval accept_br = if(accept_encoding == "*br*", 1, 0)
| eval accept_sdch = if(accept_encoding == "*sdch*", 1, 0)
| eval chrome_ver = int(chrome_ver), edge_ver = int(edge_ver)
| eval python_client = if(lower(user_agent) == "*python*", 1, 0)
| eval go_client = if(lower(user_agent) == "*go-http-client*", 1, 0)
| eval java_client = if(lower(user_agent) == "*java*", 1, 0)
| eval fb_asn = if(asn == "*FACEBOOK*", 1, 0)
| eval google_asn = if(asn == "*GOOGLE*", 1, 0)
| eval ms_asn = if(asn == "*MICROSOFT*", 1, 0)
| eval huawei_asn = if(asn == "*HUAWEI CLOUDS*", 1, 0)
| eval yandex_asn = if(asn == "*YANDEX*", 1, 0)
| eval fb_client = if(in(user_agent, "*FBAN/FBIOS;FBDV*", "*facebookexternalhit*", "*cortex/1.0*", "*adreview*"), 1, 0)
| eval google_bot = if(in(user_agent, "*Googlebot-Image/*", "*Googlebot/*"), 1, 0)
| eval bing_bot = if(in(user_agent, "*bingbot/*"), 1, 0)
| eval petal_bot = if(in(user_agent, "*PetalBot*"), 1, 0)
| eval yandex_bot = if(in(user_agent, "*YandexBot/*"), 1, 0)
| eval accept_all = if(len(accept) == 3, 1, 0), keep_alive = if(lower(connection) == "keep-alive", 1, 0)
| eval has_referer = if(len(referer) > 0, 1, 0)
| eval has_sec_fetch_site = if(len(sec_fetch_site) > 0, 1, 0)
| eval header_count = len(split(headers, "\n")), host_header_ip = if(isnotnull(ip(host)), 1, 0)
| eval known_bot = if((google_bot > 0 and google_asn > 0) or (ms_asn > 0 and bing_bot > 0) or (fb_asn > 0 and fb_client > 0) or (huawei_asn > 0 and petal_bot > 0), 1, 0)
| # 추론 시에도 슬랙의 known_bot 처리를 추가해야 함
| eval known_bot = if(user_agent == "*Slack-*", 1, known_bot)
| # 랜덤포레스트 모델 호출
| rforest model=bot2 header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot
| fields _time, log_id, _guess, label, pin, header_count, has_sec_fetch_site, has_referer, accept_all, accept_br, accept_sdch, chrome_ver, python_client, go_client, java_client, fb_asn, google_asn, ms_asn, huawei_asn, yandex_asn, fb_client, google_bot, bing_bot, petal_bot, yandex_bot, known_bot

이제 정확도가 95%로 개선되었습니다.

최종 모델의 혼동 행렬

정리

전체 데이터의 라벨링은 휴리스틱으로 일괄 처리했기 때문에, 앞서 봤던 것처럼 일부 오류가 있을 수 있습니다. 적용된 방법은 아래와 같습니다:

  • 다수의 세부 페이지 접속에서 단 한 번의 오류도 유발하지 않은 브라우저 접속 로그
  • 크리미널 IP 서비스(https://criminalip.io/)에서 평판 조회 결과가 inbound_score 혹은 outbound_score가 4 이상인 경우 악성 IP로 일괄 분류
  • 정상 서비스 경로라도 악성 데이터를 POST한 경우 해당 IP의 모든 로그를 악성으로 분류
  • 알려진 스캐너, 흔하지 않은 크롤러, 프로그래밍 방식으로 접근한 모든 클라이언트 로그를 악성으로 분류

이 글에서는 HTTP 헤더에서 특성을 추출하여 사용했지만, 일반적인 웹 서버의 로그 세팅에서는 통상 헤더 전체가 기록되지 않습니다. 기본적인 웹 로그 세팅에서 알려지지 않은 웹 공격을 탐지하는게 목적이라면, 로그프레소의 특허 제10-2096785처럼 로그의 시퀀스를 학습하는 것이 좋습니다. 웹 방화벽은 공격 탐지 시 HTTP 헤더 정보를 전달하지만, 탐지 결과의 정오탐 분류가 목적이라면 HTTP 본문을 포함한 페이로드 전체를 대상으로 모델링하는 것이 효과적입니다.

개별 웹 로그에 대해 모델이 추론한 결과로 경보를 발생시키면 경보의 양 때문에 대응하는데 어려움을 겪을 수 있습니다. 수백만 건의 접속 로그에 대하여 단 1%만 오류가 발생하더라도 1000건 이상의 오탐이 발생할 수 있기 때문입니다. 따라서 출발지 IP 주소로 그룹화하여 경보를 발생시키는 것이 탐지 결과에서 전체적인 맥락을 파악하고 방화벽 등을 통해 위협 IP를 차단 조치하기에 유리합니다.

둘러보기

더보기

NTFS 포렌식

NTFS는 윈도우즈 운영체제에서 지금까지 사용하고 있는 파일시스템입니다. 파일시스템은 물리적인 디스크 공간을 논리적인 디렉터리 계층과 파일 단위로 구조화하여 사용할 수 있도록 만들어줍니다. 스마트폰이 대중화된 이후 포렌식의 분석 대상이 개인정보를 집적하고 있는 모바일 기기로 많이 이동하고 있지만 여전히 윈도우즈 운영체제는 업무에서 핵심적인 생산성 도구입니다. 악성코드에 감염되거나 정보가 유출되었을 때 호스트에서 어떤 일이 발생했는지 알아내려면 NTFS 파일시스템에 대한 이해가 필수적입니다. ## MFT: 마스터 파일 테이블 ![](/media/ko/2020-09-12-ntfs-forensic/mft-structure.png) 마스터 파일 테이블은 NTFS 파일시스템에 존재하는 모든 디렉터리와 파일에 대한 메타데이터를 유지합니다. 마스터 파일 테이블은 1024바이트 고정 길이 레코드로 구성되어 있으며, 파일 삭제 여부, 파일 크기, 디스크 할당 크기 등을 48바이트의 MFT 헤더에 담고 있습니다. 파일 이름, 접근 권한, 파일 생성/수정/접근 일시 등의 정보는 MFT 헤더 뒤에 이어지는 여러 가지의 속성 (Attribute) 에 포함됩니다. 분석에 가장 흔히 사용되는 속성은 $STANDARD_INFORMATION 과 $FILE_NAME 속성이며, 아래의 필드를 포함하고 있습니다. * 파일 이름 * 디스크 할당 크기 * 실제 크기 * 파일 생성 일시 * 파일 수정 일시 * MFT 레코드 변경 일시 * 파일 액세스 일시 * 파일 권한 * 파일 속성 (숨김, 압축 등) 파일을 삭제하더라도 마스터 파일 테이블에서 즉시 삭제되지는 않으므로, 악성코드나 중요한 증적 파일이 삭제되더라도 MFT에서 삭제 흔적을 확인할 수 있습니다. 로그프레소 포렌식의 ntfs-mft 커맨드는 아래와 같은 필드 출력을 제공합니다. * no: MFT 인덱스 번호 * file_path: 파일 경로 * file_name: 파일 이름 * file_size: 파일 크기 * alloc_size: 디스크 할당 크기 * in_use: 삭제 여부 * is_dir: 디렉터리 여부 * link_count: 하드링크 수 * created_at: 파일 생성일시 ($FILENAME 속성) * modified_at: 파일 변경일시 ($FILENAME 속성) * access_at: 파일 접근일시 ($FILENAME 속성) * mft_modified_at: MFT 레코드 변경일시 ($FILENAME 속성) * std_created_at: 파일 생성일시 ($STANDARD_INFORMATION 속성) * std_modified_at: 파일 수정일시 ($STANDARD_INFORMATION 속성) * std_mft_modified_at: MFT 레코드 변경일시 ($STANDARD_INFORMATION 속성) * std_access_at: 파일 접근일시 ($STANDARD_INFORMATION 속성) * is_readonly: 읽기전용 여부 * is_hidden: 숨김 여부 * is_system: 시스템 파일 여부 * is_archive: 보관 가능 여부 * is_device: 장치 여부 * is_normal: 일반 여부 * is_temp: 임시 파일 여부 * is_sparse: Sparse 여부 * is_reparse: Reparse 여부 * is_compressed: 압축 여부 * is_offline: 오프라인 여부 * is_indexed: 인덱스 여부 * is_encrypted: 암호화 여부 * lsn: $LogFile 시퀀스 번호 * seq: MFT 레코드 시퀀스 (레코드 재할당 시 증가) * file_ref: 파일 참조 번호 * parent_file_ref: 디렉터리 파일 참조 번호 * parent_no: 디렉터리 MFT 인덱스 번호 ## USNJRNL: 저널링 로그 MFT에서 파일 삭제를 확인할 수는 있지만 사건을 조사할 때 또 하나 중요한 부분은 삭제 시점입니다. NTFS 파일시스템은 저널링을 지원하기 때문에, 파일 변경 이력을 $Extend 폴더의 $UsnJrnl 파일에 기록합니다. ![](/media/ko/2020-09-12-ntfs-forensic/usnjrnl-structure.png) 따라서 USNJRNL 파일을 분석하면 시스템에서 언제, 어떤 파일을 대상으로 어떤 작업을 수행했는지 파악할 수 있습니다. ntfs-usnjrnl 커맨드는 아래와 같은 필드 출력을 제공합니다. * _time: 파일 이벤트 시각 * file_name: 파일 이름 * file_no: MFT 인덱스 번호 * file_ref: 파일 참조 번호 * parent_file_no: 디렉터리 MFT 인덱스 번호 * parent_file_ref: 디렉터리 참조 번호 * reason: 파일 작업 목록 * usn: 레코드 오프셋 (Update Sequence Number) 저널링 로그는 MFT를 번호로 참조하기 때문에, 아래와 같이 조인하여 완전한 파일 경로를 확보할 수 있습니다. ```query ntfs-usnjrnl USNJRNL | join file_no [ ntfs-mft MFT | rename no as file_no ] ``` ![](/media/ko/2020-09-12-ntfs-forensic/ntfs-usnjrnl-join.png) 이러한 파일 변경 이력은 간단히 통계 처리하여 아래와 같이 타임라인을 시각화 할 수도 있습니다. ```query ntfs-usnjrnl USNJRNL | explode reason | timechart span=1h count by reason ``` ![](/media/ko/2020-09-12-ntfs-forensic/ntfs-usnjrnl-timechart.png) ## 코드게이트 포렌식 문제 연습 로그프레소 포렌식 솔루션은 쿼리를 기반으로 다양한 포렌식 아티팩트를 연관 분석하는 강력한 기능을 지원합니다. 아래에서는 이전 코드게이트 2012 컨퍼런스에서 NTFS와 관련하여 출제된 문제를 어떻게 분석하는지 설명합니다. > In Energy corporate X which is located in Seoul, APT(Advanced Persistent Threat) was occurred. For 6 months, Attacker A has stolen critical information with an elaborate attack. > Attacker A exerted great effort to remove his all traces such as malicious file, prefetch, registry and event logs for the period of attacking, so it was hard for Energy Corporate X to find an attacking path. > However IU who is Forensic expert can find the traces of the malicious files Attacker A used by analyzing MFT (Master File Table). > What time malicious file was created? The time is based on Korea Standard Time (UTC +09:00) * Codegate 2012 Forensic 400 문제 파일 400점 문제이지만 풀이 방법을 알면 간단하게 접근할 수 있습니다. 문제 지문에서는 MFT를 분석 대상으로 제시하고 있고, 공격자가 프리페치를 삭제하려고 시도하였다고 언급하여 실행 파일을 암시하고 있습니다. 문제의 목표는 악성코드 생성일시를 찾는 것입니다. ```query ntfs-mft E:\codegate2012\$MFT | search file_name == "*.exe" ``` ![](/media/ko/2020-09-12-ntfs-forensic/codegate-query.png) 간단한 확장자 검색으로 휴지통에 있는 r32.exe 파일이 2012-02-23 02:39:18 KST에 생성되었고 파일 크기가 82944 바이트라는 사실을 확인할 수 있습니다.

2020-09-12

의사결정나무를 이용한 이상탐지

기계학습 분야에는 이상치(outlier)를 탐지하는 다양한 알고리즘이 제안되어 있지만, 알고리즘마다 특성이 있기 때문에 이를 잘 알아두어야 문제 풀이에 적합한 기계학습 알고리즘을 선택할 수 있습니다. 이번 절에서는 데이터 기반 의사결정에 광범위하게 사용되는 의사결정나무(Decision tree)를 이용하여 이상탐지를 수행하는 방법을 설명합니다. 이상치는 정상치에 비해 매우 다른 특징을 가진 데이터를 의미합니다. 일반적으로는 이상치를 찾기 위해 정상치를 학습하고, 정상치와 달라보이는 이상치를 추출합니다. 가장 쉽고 간단하게 생각할 수 있는 방법은 통계적으로 평균과 표준편차를 구해서, 이와 크게 벗어나는 값을 이상치로 취급하는 방법입니다. 여기서 더 나아가 다차원 데이터를 취급할 때는 군집 기반의 방법론을 주로 사용합니다. 아래의 도표는 LOF (Local Outlier Factor) 알고리즘이 군집에서 멀리 떨어진 값을 이상치로 계산한 예시입니다. ![](/media/ko/2017-08-22-anomaly-detection/lof.png) 이러한 기존 방법론의 가장 큰 문제는 1) 정상치를 모두 고려해야 하므로 계산 부하가 크다는 점, 2) 매번 정상치를 프로파일링해서 이상치를 계산하므로 모델을 생성하고 재활용하기 어렵다는 점입니다. Isolation Forest 기계학습 알고리즘은 기존 방법론과 다르게, 이상치 기준을 모델로 생성하는 방법론을 제시합니다. ## 공간분할 기반 이상탐지 아래의 그림은 2차원 데이터를 대상으로 Isolation Forest의 동작을 시각적으로 보여줍니다. ![](/media/ko/2017-08-22-anomaly-detection/isolation-forest.png) Isolation Forest 알고리즘은 랜덤하게 차원을 선택해서 임의의 기준으로 공간을 분할합니다. 군집 내부에 있는 정상치 Xi의 경우 공간 내에 한 점만 남기고 완전히 고립시키려면 많은 횟수의 공간 분할을 수행해야 하지만, 군집에서 멀리 떨어진 이상치 Xo는 적은 횟수의 공간 분할만으로 고립시킬 수 있습니다. 공간분할은 차원과 기준 값으로 표현할 수 있으므로, 여러 번의 공간분할은 의사결정나무 (Decision Tree) 형태로 표현할 수 있습니다. 정상치일수록 완전히 고립시킬 수 있을 때까지 의사결정나무를 깊숙하게 타고 내려가야 합니다. 반대로 이상치의 경우, 의사결정나무의 상단부만 타더라도 고립될 가능성이 높습니다. 이런 특성을 이용하면 의사결정나무를 몇 회 타고 내려가야 고립되는가를 기준으로 정상치와 이상치를 분리할 수 있습니다. ![](/media/ko/2017-08-22-anomaly-detection/isolation-forest-score-map.png) 이런 의사결정나무를 여러 개 모아서 앙상블 모델을 만들면 왼쪽 그래프처럼 안정적인 이상지수(score)를 산출할 수 있습니다. 논문에서는 약 50개에서 100개 정도의 의사결정나무를 이용하면 이상지수가 안정화된다는 점을 언급하고 있습니다. 오른쪽 그래프는 등고선 형태로 군집의 경계에 해당하는 점들은 0.5의 이상지수를 가진다는 사실을 보여주고 있습니다. 이상지수는 0~1 범위로 정규화되므로, 일반적으로 0.5보다 크고 1에 가까울수록 이상치로 정의할 수 있습니다. ## 이상탐지 수행 성능 Isolation Forest는 군집기반 이상탐지 알고리즘에 비해 월등한 실행 성능을 보입니다. 군집기반 이상탐지 알고리즘의 경우, 자기 자신을 제외한 나머지 모든 인스턴스에 대한 유클리디안 거리를 계산해야 하므로 O(N2)의 수행시간이 필요합니다. 반면, Isolation Forest는 일부 데이터를 샘플링하여 의사결정나무 모델을 생성하고 이를 이용하여 이상탐지를 수행하므로 O(logN)의 수행시간이면 충분합니다. 또 하나는 정확성에 대한 부분인데, 이상탐지 분야에서 해결하기 어려운 문제는 Swamping과 Masking이라 불리는 현상입니다. Swamping은 정상치가 이상치에 가까운 경우 이상치로 잘못 분류하게 되는 현상이고, Masking은 이상치가 군집화되어 있으면 정상치로 잘못 분류하게 되는 현상입니다. ![](/media/ko/2017-08-22-anomaly-detection/isolation-forest-sample.png) Isolation Forest는 전수 데이터를 이용하지 않고 일부 데이터만 샘플링해서 모델을 생성하기 때문에, 상대적으로 이런 오류에 강건한 특성을 가지게 됩니다. 위의 도표는 이상치 군집과 정상치 군집이 가까이 있을 때, 샘플링이 어떻게 이러한 문제를 극복하는지 시각적으로 보여주고 있습니다. ## 로그프레소의 활용 로그프레소에서는 기계학습을 쿼리로 수행할 수 있을 뿐 아니라, 스트림 쿼리에 이미 생성된 기계학습 모델을 배포(Deploy)하여 밀리초 이내의 실시간 이상탐지를 수행할 수 있도록 지원합니다. 예를 들어, 이상금융거래시스템(FDS)은 고객정보, 거래정보, 단말정보 등 다차원 데이터를 이용하여 이상탐지 모델을 생성하고 이를 기반으로 0.1초 이내에 실시간 탐지를 수행합니다. 아래는 실제 환경과 유사한 거래 데이터를 가상으로 생성하여 만든 모델링 데모입니다. 이 중에서 거래시각, 고객연령, 연속이체횟수 특성의 분포를 살펴보면 다음과 같습니다. ![](/media/ko/2017-08-22-anomaly-detection/fds-histogram.png) 거래시각은 0-86400초 범위의 값, 연령은 0-100 범위의 값, 연속이체횟수는 0-16 범위의 값을 가지고 있습니다. anomalies 쿼리를 사용하면 서브쿼리 결과를 이용하여 Isolation Forest 모델을 즉시 생성하고 이를 이용하여 스코어링을 실행할 수 있습니다. ```query table transaction | anomalies _time, age, cnt [ table transaction ] | eval category = if(_score >= 0.7, "outlier", "normal") ``` 3차원으로 시각화하면 아래와 같이 색상으로 분리된 정상 거래와 이상 거래를 확인할 수 있습니다. ![](/media/ko/2017-08-22-anomaly-detection/fds-3d-histogram.png) 위의 예시는 설명을 위해 극단적으로 단순화한 모델이며, 실제로는 수집 데이터 원본 뿐 아니라 CEP (Complex Event Processing) 기술을 통해 생성된 다양한 특성 값의 분포와 영향력을 비교하고 가공하는 과정을 거치게 됩니다. 기존의 룰/시나리오 기반 탐지 모델은 각각의 차원에 대해 임계치를 정의하고 조합했지만, 기계학습을 이용한 이상탐지는 다차원으로 데이터를 분석하고 경계면을 자동 생성함으로써 더 정교한 탐지를 수행할 수 있습니다. ## 레퍼런스 * Liu, Fei Tony, Ting, Kai Ming and Zhou, Zhi-Hua. "Isolation forest." Data Mining, 2008. ICDM'08. Eighth IEEE International Conference on Data Mining. * Liu, Fei Tony, Ting, Kai Ming and Zhou, Zhi-Hua. "Isolation-based anomaly detection." ACM Transactions on Knowledge Discovery from Data (TKDD) 6.1 (2012)

2017-08-22

레지스트리 포렌식

레지스트리는 윈도우즈 운영체제와 응용프로그램에 관련된 방대한 설정과 운영 정보가 기록된 데이터베이스입니다. 윈도우즈 운영체제 초창기에는 INI 파일을 사용했으나, 레지스트리가 도입되면서 표준화된 계층적 데이터 구조, 다중 사용자 환경 지원, 접근 권한 제어, 바이너리 포맷 파일 기반의 효율적 I/O, 타입 시스템, 트랜잭션 등을 제공하게 되었습니다. 레지스트리를 분석하면 어떤 프로그램이나 서비스가 부팅 시 자동으로 실행되는지, 어떤 프로그램을 최근에 실행했는지, 어떤 프로그램을 얼마나 오래 사용했는지, 최근 어떤 파일을 검색했는지, 어떤 파일을 열어봤는지, 어느 서버에 접속했는지, 어떤 파일을 압축했는지 등 무수히 많은 정보를 추출할 수 있습니다. 따라서 레지스트리 분석은 사고 조사 초기에 수행해야 할 중요한 단계이며, 여기에서 확인된 정보에 따라 후속 조사의 진행이 결정될 수 있습니다. ## 레지스트리 하이브 파일 레지스트리 편집기(regedit)를 통해 하나로 보이는 레지스트리의 계층적 구조는 물리적으로 여러 개의 레지스트리 하이브 파일에 분산되어 있습니다. ![](/media/ko/2020-11-01-registry-forensic/reg-hive-files.png) `%SystemRoot%\System32\config` 디렉터리에는 아래와 같은 레지스트리 하이브 파일이 존재합니다. * SAM: HKEY_LOCAL_MACHINE\SAM * SECURITY: HKEY_LOCAL_MACHINE\Security * SOFTWARE: HKEY_LOCAL_MACHINE\Software * SYSTEM: HKEY_LOCAL_MACHINE\System 또한 각 사용자 계정의 디렉터리에는 NTUSER.DAT 레지스트리 하이브 파일이 존재합니다. ## HIVE 파일 구조 레지스트리 하이브 파일은 아래와 같이 구성되어 있습니다. ![](/media/ko/2020-11-01-registry-forensic/hive-structure.png) BASE 블록 구조 ![](/media/ko/2020-11-01-registry-forensic/hive-base-block.png) HIVE BIN 헤더 구조 ![](/media/ko/2020-11-01-registry-forensic/hive-bin-header.png) 로그프레소 포렌식의 hive-file 커맨드는 아래와 같은 필드를 출력합니다. ![](/media/ko/2020-11-01-registry-forensic/hive-file-command.png) * key: 키 * type: 타입 (문자열, 이진값, DWORD, QWORD 등) * name: 값 * value: 데이터 * last_written: 마지막 기록 시각 ## 코드게이트 포렌식 문제 연습 로그프레소 포렌식 솔루션은 쿼리를 기반으로 다양한 포렌식 아티팩트를 연관 분석하는 강력한 기능을 지원합니다. 아래에서는 이전 코드게이트 2011 컨퍼런스에서 레지스트리와 관련하여 출제된 문제를 어떻게 분석하는지 설명합니다. > we are investigating the military secret's leaking. we found traffic with leaking secrets while monitoring the network. Security team was sent to investigate, immediately. But, there was no one present. > It was found by forensics team that all the leaked secrets were completely deleted by wiping tool. And the team has found a leaked trace using potable device. Before long, the suspect was detained. But he denies allegations. > Now, the investigation is focused on potable device. The given files are acquired registry files from system. The estimated time of the incident is Mon, 21 February 2011 15:24:28(KST). > Find a trace of portable device used for the incident. > The Key : "Vendor name" + "volume name" + "serial number" (please write in capitals) * Codegate 2011 Forensic 300 문제 파일 제시된 파일의 압축을 풀면 6개의 레지스트리 하이브 파일을 확인할 수 있습니다. 먼저 시스템에 마운트된 장치 정보를 추출하기 위해 SYSTEM 하이브 파일에서 MountedDevices 키를 검색하면 아래와 같이 이진값으로 된 레지스트리 데이터를 확인할 수 있습니다. ```query hive-file codegate2011\system.bak | search key == "*MountedDevices" and name == "\\DosDevices*" ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step1.png) 이 데이터를 UTF-16으로 디코드하면 아래와 같은 문자열을 확인할 수 있습니다. ```query hive-file codegate2011\system.bak | search key == "*MountedDevices" and name == "\\DosDevices*" | eval value = substr(decode(value, "UTF-16LE"), 4) ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step2.png) USB 값만 필터링해서 정규식으로 파싱하면 제조사, 모델명, 버전, 시리얼을 추출할 수 있습니다. ```query hive-file codegate2011\system.bak | search key == "*MountedDevices" and name == "\\DosDevices*" | eval value = substr(decode(value, "UTF-16LE"), 4) | search value == "*USB*" | rex field=value "Ven_(?<vendor>[^&]+)&Prod_(?<product>[^&]+)&Rev_(?<version>[^#]+)#(?<serial>[^&]+)" | eval serial = lower(serial) | fields vendor, product, version, serial, value ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step3.png) 그러나 아직 볼륨 이름과 장치를 연결한 시간을 확인하지 못한 상태입니다. 장치를 연결한 시간은 HKLM\SYSTEM\ControlSet00X\Enum\USB\VID_####&PID_#### 키의 마지막 수정 시간을 확인하면 됩니다. 아래와 같이 쿼리하면 66개의 키를 확인할 수 있습니다. ```query hive-file codegate2011\system.bak | search key == "*USB\\VID_*" | eval serial = lower(valueof(split(key, "\\"), 5)) | stats max(last_written) as last_connect by serial ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step4.png) 볼륨 이름은 HKLM\SOFTWARE\Microsoft\Windows Portable Devices\Devices 키에서 확인할 수 있습니다. 아래와 같이 쿼리하면 40개의 키를 확인할 수 있습니다. ```query hive-file codegate2011\software.bak | search key == "*Windows Portable Devices*" and name == "FriendlyName" | rex field=key "&REV_[^#]+#(?<serial>[^&]+)" | eval serial = lower(serial) | stats first(value) as volume_name by serial ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step5.png) 이 3종의 쿼리 결과를 시리얼 번호로 조인하면 원하는 결과를 한 번에 추출할 수 있습니다. ```query hive-file codegate2011\system.bak | search key == "*MountedDevices*" | eval value = substr(decode(value, "UTF-16LE"), 4) | search value == "*USB*" | rex field=value "Ven_(?<vendor>[^&]+)&Prod_(?<product>[^&]+)&Rev_(?<version>[^#]+)#(?<serial>[^&]+)" | eval serial = lower(serial) | stats count by vendor, product, version, serial, value | join serial [ hive-file codegate2011\system.bak | search key == "*USB\\VID_*" | eval serial = lower(valueof(split(key, "\\"), 5)) | stats max(last_written) as last_connect by serial ] | join serial [ hive-file codegate2011\software.bak | search key == "*Windows Portable Devices*" and name == "FriendlyName" | rex field=key "&REV_[^#]+#(?<serial>[^&]+)" | eval serial = lower(serial) | stats first(value) as volume_name by serial ] | search last_connect >= date("2011-02-21", "yyyy-MM-dd") and last_connect <= date("2011-02-22", "yyyy-MM-dd") | order volume_name, vendor, product, version, serial, last_connect ``` ![](/media/ko/2020-11-01-registry-forensic/codegate-step6.png) 이처럼 로그프레소 쿼리를 이용하여 레지스트리 포렌식 데이터를 손쉽게 분석하고 가공할 수 있으며, 재사용 가능한 라이브러리로 구축할 수 있습니다.

2020-11-01