cert-polska/hfingerTshark를 사용하여 pcap 파일에서 악성코드 HTTP 요청의 고유한 지문을 생성하며, 요청 구조, 헤더 및 페이로드 특성 분석을 통해 악성코드 패밀리를 식별 및 그룹화할 수 있습니다.
악성코드 HTTP 요청을 핑거프린팅하는 도구입니다. Tshark 기반이며 Python3로 작성되었습니다. 작업 중인 프로토타입 단계입니다 :-)
주요 목표는 악성 요청의 고유한 표현(핑거프린트)을 제공하여 식별에 도움을 주는 것입니다. 여기서 _고유_란 각 핑거프린트가 하나의 특정 악성코드 계열에서만 나타나야 하지만, 하나의 계열이 여러 핑거프린트를 가질 수 있음을 의미합니다. Hfinger는 전체 요청을 출력하는 것보다 짧지만 사람이 해석할 수 있는 형태로 요청을 표현합니다.
Hfinger는 수동 악성코드 분석뿐만 아니라 샌드박스 시스템이나 SIEM에서도 사용할 수 있습니다. 생성된 핑거프린트는 요청 그룹화, 특정 악성코드 계열에 속한 요청 식별, 한 계열의 다양한 작업 식별, 또는 다른 보안 시스템에서 누락되었지만 핑거프린트가 일치하는 알려지지 않은 악성 요청을 발견하는 데 유용합니다.
학술 논문이 이 도구 작업과 함께 제공되며, 예를 들어 설계 선택의 동기와 p0f, FATT, Mercury와의 비교 평가를 설명합니다.
이 프로젝트의 기본 가정은 서로 다른 악성코드 계열의 HTTP 요청이 어느 정도 고유하므로, 식별을 제공하기 위해 핑거프린팅할 수 있다는 것입니다. Hfinger는 일부 헤더의 구조와 값에 대한 정보를 유지하여 추가 분석 수단을 제공합니다. 예를 들어, 유사한 요청의 그룹화 - 현재로서는 아직 진행 중인 작업입니다.
악성코드의 HTTP 요청과 헤더를 분석한 후, 요청 중 가장 구별되는 부분을 식별했습니다. 여기에는 다음이 포함됩니다:
또한 요청 URL의 일부 표준 기능도 고려되었습니다. 이러한 모든 부분은 기능 집합으로 변환되었으며, 자세한 내용은 여기에서 설명합니다.
위의 기능은 가변 길이 표현(실제 핑거프린트)으로 변환됩니다. 보고 모드에 따라 요청을 핑거프린팅하는 데 다른 기능이 사용됩니다. 이러한 모드에 대한 자세한 내용은 아래에 제시됩니다. 기능 선택 프로세스는 곧 발표될 학술 논문에서 설명될 예정입니다.
설치 전 필요한 최소 요구 사항:
Python >= 3.3,Tshark >= 2.2.0.PyPI에서 설치 가능:
pip install hfinger
Hfinger는 Xubuntu 22.04 LTS에서 tshark 패키지 버전 3.6.2로 테스트되었지만, Xubuntu 18.04의 2.6.10 또는 Xubuntu 20.04의 3.2.3과 같은 이전 버전에서도 작동해야 합니다.
모든 PoC와 마찬가지로 Hfinger는 최소한 Python 가상 환경과 같은 분리된 환경에서 실행해야 합니다. 여기서 설정 방법을 다루지 않지만, 이 튜토리얼을 참조할 수 있습니다.
설치 후 명령줄에서 hfinger를 호출하거나 Python 모듈로 python -m hfinger를 호출하여 도구를 사용할 수 있습니다.
예를 들어:
foo@bar:~$ hfinger -f /tmp/test.pcap
[{"epoch_time": "1614098832.205385000", "ip_src": "127.0.0.1", "ip_dst": "127.0.0.1", "port_src": "53664", "port_dst": "8080", "fingerprint": "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"}]
도움말은 짧은 -h 또는 긴 --help 스위치로 표시할 수 있습니다:
usage: hfinger [-h] (-f FILE | -d DIR) [-o output_path] [-m {0,1,2,3,4}] [-v]
[-l LOGFILE]
Hfinger - fingerprinting malware HTTP requests stored in pcap files
optional arguments:
-h, --help show this help message and exit
-f FILE, --file FILE Read a single pcap file
-d DIR, --directory DIR
Read pcap files from the directory DIR
-o output_path, --output-path output_path
Path to the output directory
-m {0,1,2,3,4}, --mode {0,1,2,3,4}
Fingerprint report mode.
0 - similar number of collisions and fingerprints as mode 2, but using fewer features,
1 - representation of all designed features, but a little more collisions than modes 0, 2, and 4,
2 - optimal (the default mode),
3 - the lowest number of generated fingerprints, but the highest number of collisions,
4 - the highest fingerprint entropy, but slightly more fingerprints than modes 0-2
-v, --verbose Report information about non-standard values in the request
(e.g., non-ASCII characters, no CRLF tags, values not present in the configuration list).
Without --logfile (-l) will print to the standard error.
-l LOGFILE, --logfile LOGFILE
Output logfile in the verbose mode. Implies -v or --verbose switch.
pcap 파일(-f) 또는 pcap 파일이 포함된 디렉터리(-d)의 경로를 제공해야 합니다. 출력은 JSON 형식입니다. 표준 출력으로 출력되거나 제공된 디렉터리(-o)에 소스 파일 이름을 사용하여 저장됩니다. 예를 들어, 다음 명령의 출력:
hfinger -f example.pcap -o /tmp/pcap
은 다음 위치에 저장됩니다:
/tmp/pcap/example.pcap.json
보고 모드 -m/--mode는 0-4 범위의 정수를 제공하여 기본 보고 모드를 변경하는 데 사용할 수 있습니다.
모드는 표현되는 요청 기능 또는 반올림 방식에 따라 다릅니다.
기본 모드(2)는 요청 분석 중 일반적으로 사용되는 모든 기능을 표현하면서도 낮은 충돌 수와 적은 수의 핑거프린트를 제공하도록 선택되었습니다.
다른 모드로 다른 목표를 달성할 수 있습니다.
예를 들어, 모드 3에서는 생성되는 핑거프린트 수는 적지만 악성코드 계열 간 충돌 가능성이 더 높아집니다. 확실하지 않다면 아무것도 변경할 필요가 없습니다.
보고 모드에 대한 자세한 정보는 여기에 있습니다.
버전 0.2.1부터 Hfinger는 덜 상세하게 작동합니다. 헤더의 비표준 값, 요청의 비페이로드 부분에 있는 비ASCII 문자, CRLF 태그(\r\n\r\n) 부재, 그리고 분석된 요청의 기타 문제(애플리케이션 오류가 아닌)에 대한 정보를 받으려면 -v/--verbose를 사용해야 합니다. 상세 모드에서 이러한 문제가 발생하면 표준 오류 출력으로 출력됩니다. 또한 -l/--log 스위치를 사용하여 로그를 지정된 위치에 저장할 수 있습니다(-v/--verbose를 암시함). 로그 데이터는 로그 파일에 추가됩니다.
버전 0.2.0부터 Hfinger는 다른 Python 애플리케이션으로의 가져오기를 지원합니다. 앱에서 사용하려면 hfinger.analysis에서 hfinger_analyze 함수를 가져와 pcap 파일 경로와 보고 모드를 인자로 호출하면 됩니다. 반환되는 결과는 핑거프린팅 결과를 포함한 딕셔너리 목록입니다.
예:
from hfinger.analysis import hfinger_analyze
pcap_path = "SPECIFY_PCAP_PATH_HERE"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
버전 0.2.1부터 Hfinger는 logging 모듈을 사용하여 헤더의 비표준 값, 요청의 비페이로드 부분에 있는 비ASCII 문자, CRLF 태그(\r\n\r\n) 부재, 그리고 분석된 요청의 기타 문제(애플리케이션 오류가 아닌)에 대한 정보를 로깅합니다. Hfinger는 hfinger라는 이름으로 자체 로거를 생성하지만, 사전 구성이 없으면 로그 정보는 실제로 버려집니다. 이 로그 정보를 받으려면 hfinger_analyze를 호출하기 전에 hfinger 로거를 구성하고, 로그 레벨을 logging.INFO로 설정하고, 필요에 따라 로그 핸들러를 구성하여 로거에 추가해야 합니다. 자세한 정보는 hfinger_analyze 함수 독스트링에서 확인할 수 있습니다.
핑거프린트는 요청에서 추출된 기능을 기반으로 합니다. 전체 목록에서 특정 기능의 사용은 미리 정의된 목록에서 선택한 보고 모드에 따라 다릅니다(보고 모드에 대한 자세한 정보는 여기에 있습니다). 아래 그림은 기본 보고 모드에서 예시 핑거프린트 생성을 보여줍니다.
정보를 추출하기 위해 요청의 세 부분이 분석됩니다: 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 기능이 추출됩니다:
log10(43)≈2),log10(20/3)≈1),hfinger/configs/extensions.txt에 있는 알려진 확장자 목록에 있는 경우에만),log10(4)≈0.6).둘째, 헤더 구조 기능이 분석됩니다:
PO),요청의 헤더 순서를 나타내기 위해 각 헤더 이름은 hfinger/configs/headerslow.json의 스키마에 따라 인코딩됩니다. 예를 들어 User-Agent 헤더는 us-ag로 인코딩됩니다. 인코딩된 이름은 ,로 구분됩니다. 헤더 이름이 대문자로 시작하지 않거나(또는 Accept-Encoding과 같은 복합 헤더를 분석할 때 해당 부분 중 하나라도 대문자가 아닌 경우) 인코딩된 표현 앞에 !가 붙습니다. 헤더 이름이 알려진 헤더 목록에 없으면 FNV1a 해시를 사용하여 해시되고, 이 해시가 인코딩으로 사용됩니다.
인기 헤더를 분석할 때 요청에 해당 헤더가 나타나는지 확인합니다. 이러한 헤더는 다음과 같습니다:
요청에서 헤더가 발견되면 해당 값이 일반적인 값 테이블과 비교되어 header_name_representation:value_representation 쌍을 생성합니다. 헤더 이름은 앞서 설명한 대로 hfinger/configs/headerslow.json의 스키마에 따라 인코딩되고, 값은 헤더에 따라 hfinger/configs 디렉터리 또는 configs.py 파일에 저장된 스키마에 따라 인코딩됩니다. 위 예제에서 Accept는 ac으로 인코딩되고, 해당 값 */*는 as-as (asterisk-asterisk)로 인코딩되어 ac:as-as가 됩니다. 쌍은 요청에 나타나는 순서대로 핑거프린트에 삽입되며 /로 구분됩니다. 헤더 값을 인코딩 테이블에서 찾을 수 없으면 FNV1a 해시를 사용하여 해시됩니다. 헤더 값이 여러 값으로 구성된 경우 토큰화되어 ,로 구분된 값 목록이 제공됩니다. 예를 들어, Accept: */*, text/*는 ac:as-as,te-as를 생성합니다. 단, 현재 개발 단계에서는 헤더 값에 "품질 값" 태그()가 포함된 경우 전체 값이 FNV1a 해시로 인코딩됩니다. 마지막으로 및 헤더의 값은 직접 FNV1a 해시를 사용하여 인코딩됩니다.
마지막으로 페이로드 기능은 다음과 같습니다:
N으로 표시되며, 그렇지 않으면 A로 표시됩니다.Hfinger는 다섯 가지 보고 모드로 작동하며, 핑거프린트에 표현되는 기능, 즉 요청에서 추출되는 정보가 다릅니다. (도구 구성에 사용된 번호와 함께) 다음과 같습니다:
0 - 모드 2와 비슷한 수의 충돌 및 핑거프린트를 생성하지만 더 적은 기능을 사용합니다.1 - 설계된 모든 기능을 표현하지만 모드 0, 2, 4보다 약간 더 많은 충돌을 생성합니다.2 - 최적(기본 모드)으로, 일반적으로 요청 분석 중 사용되는 모든 기능을 표현하면서도 낮은 충돌 수와 적은 수의 핑거프린트를 제공합니다.3 - 모든 모드 중에서 가장 적은 수의 핑거프린트를 생성하지만 가장 높은 충돌 수를 나타냅니다.4 - 가장 높은 핑거프린트 엔트로피를 제공하지만 모드 0-2보다 약간 더 많은 핑거프린트를 생성합니다.모드는 생성된 핑거프린트 수 대비 악성코드 계열을 고유하게 식별하는 Hfinger의 능력을 최적화하기 위해 선택되었습니다. 모드 0, 2, 4는 악성코드 계열 간 비슷한 수의 충돌을 제공하지만, 모드 4는 다른 두 모드보다 약간 더 많은 핑거프린트를 생성합니다. 모드 2는 모드 0보다 더 많은 요청 기능을 표현하면서도 생성된 핑거프린트 수와 충돌 수는 비슷합니다. 모드 1은 설계된 모든 기능을 표현하는 유일한 모드이지만, 모드 0, 2, 4와 비교하여 충돌 수가 거의 두 배 증가합니다. 모드 3은 다른 모드보다 최소 두 배 적은 핑거프린트를 생성하지만 충돌 수는 약 9배 증가합니다. 설계된 모든 기능에 대한 설명은 여기에 있습니다.
모드는 핑거프린트에 나타나는 순서대로 다음 기능으로 구성됩니다:
0:
1:
2:
3:
4:
q=