Hfinger - HTTP 요청 핑거프린팅

Hfinger 지문인식 HTTP request-1.png



맬웨어의 HTTP 요청 지문을 채취하는 도구입니다. Tshark를 기반으로 하며 Python3으로 작성되었습니다. 작업 프로토타입 단계 :-)

주요 목적은 맬웨어 요청을 식별하는 데 도움이 되는 고유한 표현(지문)을 제공하는 것입니다. 고유함이란 각 지문이 하나의 특정 맬웨어 계열에서만 표시되지만 하나의 계열이 여러 개의 지문을 가질 수 있음을 의미합니다. Hfinger는 전체 요청을 인쇄하는 것보다 짧은 형식으로 요청을 나타내지만 여전히 사람이 이해할 수 있습니다.

Hfinger는 샌드박스 시스템이나 SIEM뿐만 아니라 수동 맬웨어 분석에도 사용할 수 있습니다. 생성된 지문은 요청을 그룹화하고, 특정 악성 코드 계열에 대한 요청을 찾아내고, 동일한 계열의 다양한 작업 을 식별하거나 , 다른 보안 시스템이 무시하지만 지문을 공유하는 알려지지 않은 악성 요청을 발견하는 데 사용될 수 있습니다.

학술 논문은 도구 연구와 함께 제공되며, 예를 들어 p0f , FATT 및 Mercury와 비교하여 설계 선택의 동기와 도구 평가를 설명합니다 .


이 프로젝트의 기본 가정은 다양한 맬웨어 계열의 HTTP 요청이 어느 정도 고유하므로 일종의 식별을 제공하기 위해 지문을 채취할 수 있다는 것입니다. Hfinger는 추가 분석 수단을 제공하기 위해 특정 헤더의 구조와 값에 대한 정보를 보유합니다. 예를 들어 유사한 요청을 그룹화하는 작업은 현재 진행 중인 작업입니다.

악성코드의 HTTP 요청과 헤더를 분석한 후, 우리는 요청 중 가장 특징적인 몇 가지 부분을 발견했습니다. 여기에는 다음이 포함됩니다. * 요청 방법 * 프로토콜 버전 * 헤더 순서 * 공통 헤더 값 * 페이로드 길이, 엔트로피 및 비ASCII 문자 존재 여부

또한 요청 URL의 일부 표준 특성이 고려됩니다. 이러한 모든 부분은 아래에 자세히 설명된 일련의 기능으로 변환됩니다 .

위의 특징은 실제 지문인 가변 길이 표현으로 변환됩니다. 보고 모드에 따라 요청을 지문 인식하는 데 다양한 특성이 사용됩니다. 이러한 모드에 대한 자세한 내용은 아래에 설명되어 있습니다. 특징 선택 과정은 곧 나올 학술 논문에서 설명될 것입니다.

설치 전에 필요한 최소 요구 사항: * Python >= 3.3, * Tshark >= 2.2.0.

PyPI에서 설치 가능:

pip install hfinger

Hfinger는 tshark 버전의 패키지를 사용하여 Xubuntu 22.04 LTS에서 테스트되었지만 Xubuntu 18.04 또는 Xubuntu 20.043.6.2와 같은 이전 버전에서도 작동해야 합니다. 2.6.103.2.3

모든 PoC와 마찬가지로 최소한 Python 가상 환경 내에서 독립형 환경에서 Hfinger를 실행해야 합니다. 설정은 여기서 다루지 않지만 이 튜토리얼을 시도해 볼 수 있습니다 .

설치되면 명령줄에서 직접 hfinger 도구를 호출하거나 python -m hfinger를 호출하여 Python 모듈로 호출할 수 있습니다.

예:

foo@bar:~$ hfinger -f /tmp/test.pcap<br>[{"epoch_time": "1614098832.205385000", "ip_src": "127.0.0.1", "ip_dst": "127.0.0.1" , "port_src": "53664", "port_dst": "8080", "지문": "2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9 /ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4"}]<br>
-h 짧거나 긴 스위치를 사용하여 도움말을 표시할 수 있습니다. --help:

사용법: hfinger [-h] (-f FILE | -d DIR) [-o 출력_경로] [-m {0,1,2,3,4} ] [-v]<br> [-l 로그파일]<br><br>Hfinger - pcap 파일에 저장된 악성 코드 HTTP 요청 지문 채취<br><br>선택 인수:<br> -h, --help 이 도움말 메시지 표시 그리고 종료<br> -f FILE, --file FILE 단일 pcap 파일 읽기<br> -d DIR, --directory DIR<br> DIR 디렉터리에서 pcap 파일 읽기<br> -o output_path, --output-path output_path<br> 출력 디렉터리 경로<br> -m {0,1,2,3,4}, --mode {0,1,2,3,4}<br> 지문 보고서 모드 <br> 0 - 유사한 숫자 충돌 및 지문은 모드 2로, 그러나 더 적은 수의 기능을 사용합니다. <br> 1 - 모든 설계된 기능을 표현하지만 모드 0, 2, 4보다 충돌이 조금 더 많습니다. <br> 2 - 최적(기본 모드), <br> 3 - 생성된 지문 수가 가장 적지만 충돌 횟수가 가장 높습니다. <br> 4 - 지문 엔트로피가 가장 높지만 지문이 모드 0-2보다 약간 많습니다.<br> -v, --verbose 다음에 대한 정보 보고 요청의 비표준 값 <br>(예: 비ASCII 문자, CRLF 태그 없음, 구성 목록에 없는 값) <br> --logfile(-l)이 없으면 다음으로 인쇄됩니다. 표준 오류.< br> -l LOGFILE, --logfile LOGFILE<br> 상세 모드에서 로그 파일을 출력합니다. -v 또는 --verbose 스위치를 의미합니다.<br><br>
pcap 파일에 대한 경로를 제공해야 합니다(- f) 또는 pcap을 포함합니다. 파일 디렉터리(-d). 출력은 JSON 형식입니다. 소스 파일 이름을 사용하여 표준 출력이나 제공된 디렉터리(-o)로 인쇄합니다. 예를 들어

hfinger -f example.pcap -o /tmp/pcap 명령의 출력은

/tmp/pcap/example.pcap.json

보고서

모드 -m/ --mode를 사용하여 기본값을 변경할 수 있습니다. 보고 모드 0-4. 이러한 모드는 요청 특성이나 나타내는 반올림 모드가 다릅니다. 2 요청 분석 중에 일반적으로 사용되는 모든 기능을 나타내기 위해 기본 모드( )를 선택했지만 충돌 횟수와 생성된 지문도 더 적습니다. 다른 모드를 사용하면 다른 목표를 달성할 수 있습니다. 예를 들어 모드 3에서는 생성된 지문 수가 적지만 맬웨어 계열 간의 충돌 가능성은 더 높습니다. 확실하지 않은 경우 아무것도 변경할 필요가 없습니다. 보고 모드에 대한 자세한 내용은 을 참조하십시오 .

Hfinger 버전 0.2.1부터 장황한 표현 수준이 감소되었습니다. 발견된 비표준 헤더 값, 요청의 비페이로드 부분에 있는 비ASCII 문자, 누락된 CRLF 태그( ) 및 분석된 요청의 기타 비애플리케이션 오류 문제에 대한 정보를 받으려면 -v를 사용해야 합니다. /. 상세 모드에서 이러한 문제가 발생하면 표준 오류로 인쇄됩니다. / 스위치( / 의미)를 사용하여 정의된 위치에 로그를 저장할 수도 있습니다. 로그 데이터는 로그 파일에 추가됩니다. --verbose\r\n\r\nl--log-v--verbose

버전 0.2.0부터 Hfinger는 다른 Python 애플리케이션으로 가져오기를 지원합니다. 애플리케이션에서 사용하려면 hfinger.analytic에서 hfinger_analyze 함수를 가져오고 pcap 파일 경로와 보고서 모드를 사용하여 호출하면 됩니다. 반환된 결과는 지문 인식 결과가 포함된 사전 목록입니다.

예:

from hfinger.analytic import hfinger_analyze<br><br>pcap_path = "SPECIFY_PCAP_PATH_HERE"<br>reporting_mode = 4<br>print(hfinger_analyze(pcap_path, reporter_mode))<br>
버전 0.2.1부터 Hfinger는 다음을 사용합니다. 로깅 모듈 로깅 중 요청의 비페이로드 부분에서 비표준 헤더 값, 비ASCII가 발견되었습니다. 문자, 누락된 CRLF 태그(\r\n\r\n) 및 애플리케이션 오류가 아닌 분석된 요청의 기타 문제입니다. Hfinger는 hfinger라는 이름을 사용하여 자체 로거를 생성하지만 사전에 구성 하지 않으면 실제로 로그 정보가 삭제됩니다. 이 로그 정보를 받으려면 hfinger_analyze를 호출하기 전에 hfinger 로거를 구성하고 로그 수준을 login.INFO로 설정하고 필요에 따라 로그 핸들러를 구성한 후 로거에 추가해야 합니다. 더 많은 정보는 hfinger_analyze 함수 docstring에서 확인할 수 있습니다.

지문은 요청에서 추출된 기능을 기반으로 합니다. 전체 목록 의 특정 기능 사용은 사전 정의된 목록에서 선택한 보고 모드에 따라 달라집니다(보고 모드에 대한 자세한 내용은 여기에서 확인할 수 있습니다 ). 아래 이미지는 기본 보고 모드에서 샘플 지문 생성을 나타냅니다.

Hfinger 지문인식 HTTP request-1.png



정보를 추출하기 위해 요청의 세 부분, 즉 URI, 헤더 구조(메서드 및 프로토콜 버전 포함), 페이로드를 분석합니다. 지문의 구체적인 특징은 (파이프)를 사용하여 구분됩니다. 예제에서 요청|의 최종 지문은 다음과 같습니다. POST

2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us -ag: f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4

기능 생성은 아래에 나타나는 순서대로 설명되어 있습니다. 지문.

먼저 URI 특징을 추출합니다. * 기본 길이의 로그로 표현된 URI 길이(정수로 반올림됨), (예제에서 URI의 길이는 43자이므로 log10(43)≒2), * 디렉터리 수, ( 예) 디렉터리의 경우 3개), * 평균 디렉터리 길이는 디렉터리의 실제 평균 길이를 10진수로 표현하고 정수로 반올림합니다. (예제에는 세 개의 디렉터리가 있으며 총 길이는 20자입니다(6 + 6+ 8), 따라서 log10(20/3)≒1), * 요청한 파일의 확장자, 그러나 알려진 확장자 목록에 있는 경우에만 hfinger/configs/extensions.txt, * 평균 길이, 실제 평균 길이는 소수점 한 자리까지 반올림된 10진법으로 표현됩니다. (예제에서 두 값의 길이는 모두 4자이며 이는 명백히 4자와 동일하며 log10(4)≒0.6입니다.)

둘째, 헤더 구조적 특성을 분석합니다. * 요청 메서드는 메서드(PO)의 처음 두 글자로 인코딩됩니다. * 프로토콜 버전은 정수로 인코딩됩니다( 1은 버전 1.1 , 0은 버전 1.0 , 9는 버전을 나타냄 ). 0.9 ), * 헤더의 순서, * 및 인기 있는 헤더와 그 값.

요청에서 헤더의 순서를 나타내기 위해 각 헤더의 이름은 hfinger/configs/headerslow.json의 패턴에 따라 인코딩됩니다. 예를 들어 User-Agent 헤더는 us-ag로 인코딩됩니다. 인코딩된 이름은 ,로 구분됩니다. 헤더 이름이 대문자(또는 Accept-Encoding과 같은 복합 헤더를 구문 분석할 때 대문자의 일부)로 시작하지 않는 경우 인코딩 표현 앞에 !가 붙습니다. 헤더 이름이 알려진 헤더 목록에 없으면 FNV1a 해시를 사용하여 해시 되고 해당 해시가 인코딩으로 사용됩니다.

공통 헤더를 구문 분석할 때 요청에 이러한 헤더가 있는지 확인됩니다. 이러한 헤더에는 다음이 포함됩니다. * 연결 * Accept-Encoding * Content-Encoding * Cache-Control * TE * Accept-Charset * Content-Type * Accept * Accept-Language * User-Agent

요청에서 헤더가 발견되면 일반적인 값 테이블은 해당 값을 확인하여 header_name_representation:value_representation 쌍을 생성합니다. 헤더의 이름은 (앞서 언급한 대로) hfinger/configs/headerslow.json의 스키마에 따라 인코딩되고, 값은 hfinger/configs 디렉터리 또는 파일 configs.py에 저장된 스키마에 따라 인코딩됩니다. 헤더 . 위의 예에서 Accept는 ac로 인코딩되고 그 값은 ()로 얻어집니다. 쌍은 요청에 나타나는 순서대로 구분 기호를 사용하여 지문에 삽입됩니다. 인코딩 테이블에서 헤더 값을 찾을 수 없는 경우 FNV1a 해시를 사용하여 해시됩니다. 헤더 값이 여러 값으로 구성된 경우, 예를 들어 별도의 값 목록을 제공하도록 표시하면 결과가 발생합니다. 그러나 개발 중에 헤더 값에 "품질 값" 태그( )가 포함되어 있으면 전체 값이 해당 FNV1a 해시를 사용하여 인코딩됩니다. 마지막으로 User-AgentAccept-Language 헤더의 값은 FNV1a 해시를 사용하여 직접 인코딩됩니다. */*as-asasterisk-asteriskac:as-as/
,Accept: / , text/*ac:as-as,te-asq=

마지막으로 페이로드 특성에는 다음과 같습니다. * 문자 N으로 표시되는 ASCII가 아닌 문자가 있습니다. , 그렇지 않으면 A로 표시*, 정수로 반올림된 페이로드의 섀넌 엔트로피* 및 10으로 표시되는 페이로드 길이 실제 페이로드 길이의 기본 로그(소수점 첫째 자리로 반올림됨)입니다.

Hfinger는 요청에서 정보를 추출하기 위해 지문으로 표시되는 특성이 다른 5가지 보고 모드로 작동합니다. 다음은 다음과 같습니다(도구 구성의 숫자 사용). * 모드 0 - 모드 2와 비슷한 수의 충돌 및 지문을 생성하지만 더 적은 수의 기능을 사용합니다. 약간 더 많은 충돌, * 모드 - 최적(기본 모드), 일반적으로 모든 기능을 나타냅니다. 요청 분석 중에 사용되지만 적은 수의 충돌 및 생성된 지문도 제공합니다. * 모드 - 모든 모드에서 가장 적은 수의 생성된 지문을 생성하지만 가장 많은 충돌을 달성하기 위해 * 모드 - 가장 높은 지문 엔트로피를 제공하지만 패턴보다 약간 더 많은 지문을 생성합니다. 02423402

이러한 패턴은 악성 코드군과 생성된 지문 수를 고유하게 식별하는 Hfinger의 능력을 최적화하기 위해 선택되었습니다. 모드 0, 2, 4는 맬웨어군 간에 비슷한 수의 충돌을 제공하지만 모드 4는 다른 두 모드보다 약간 더 많은 지문을 생성합니다. 모드 2는 생성된 지문 및 충돌 수가 비슷할 때 모드 2보다 더 많은 요청 기능을 나타냅니다. 패턴은 모든 디자인 특징을 대표하는 유일한 패턴이지만, 패턴, 및 에 비해 충돌 횟수가 거의 두 배 증가합니다. 모드는 다른 모드보다 최소 2배 적은 지문을 생성했지만 충돌 발생 횟수는 약 9배 더 많았습니다. 모든 디자인 기능은 여기에 설명되어 있습니다 . 010143

패턴은 다음 기능으로 구성됩니다(지문에 나타나는 순서대로). * 패턴 0: * 디렉터리 수, * 정수로 표시되는 평균 디렉터리 길이, * 요청된 파일의 확장자, * 부동 소수점으로 표시되는 평균 길이, * 헤더의 순서, * 인기 있는 헤더 및 해당 값, * 부동소수점으로서의 페이로드 길이. * 패턴 1: * 정수의 URI 길이, * 디렉토리 수, * 정수의 평균 디렉토리 길이, * 요청된 파일의 확장자, * 정수의 가변 길이, * 변수의 수, * 정수 평균 길이, * 요청 방법, * 프로토콜 버전, * 헤더 순서, * 널리 사용되는 헤더 및 해당 값, * 비ASCII 문자의 존재 여부, * 정수형 페이로드 엔트로피, * 페이로드 길이는 정수입니다. * 모드 2: * 정수로 표현된 URI 길이, * 디렉토리 수, * 정수로 표현된 평균 디렉토리 길이, * 요청된 파일의 확장자, * 부동 소수점 숫자로 표현된 평균 길이, * 요청 방법, * 프로토콜 버전, * 헤더 순서, * 인기 있는 헤더 및 해당 값, * 비ASCII 문자의 존재 여부, * 정수형 페이로드 엔트로피, * 부동 소수점형 페이로드 길이. * 모드 3: * 정수로 표현된 URI 길이, * 정수로 표현된 평균 디렉터리 길이, * 요청된 파일의 확장자, * 정수로 표현된 평균 길이, * 헤더 순서. * 모드 4: * 부동 소수점 수의 URI 길이, * 디렉터리 수, * 부동 소수점 수의 평균 디렉터리 길이, * 요청된 파일 확장자, * 부동 소수점 수의 가변 길이, * 부동 소수점 수의 변수 길이 평균 길이, * 요청 방법, * 프로토콜 버전, * 헤더 순서, * 널리 사용되는 헤더 및 해당 값, * 비ASCII 문자의 존재 여부, * 부동 소수점 형태의 페이로드 엔트로피, * 부동 소수점 형태의 페이로드 길이.




Hfinger 다운로드
 
뒤로
상단