Red Team 인프라 하드닝 리소스를 수집하는 Wiki
이 위키는 탄력적인 Red Team 인프라를 구축하기 위한 리소스를 제공하기 위해 작성되었습니다. Steve Borosh(@424f424f)와 Jeff Dimmock(@bluscreenofjeff)의 BSides NoVa 2017 발표 "Doomsday Preppers: Fortifying Your Red Team Infrastructure"(슬라이드)를 보완하기 위해 만들어졌습니다.
추가하고 싶은 내용이 있다면 저장소에 Pull Request를 제출하거나 이슈를 등록해 주세요.
이 위키에 참조된 콘텐츠의 모든 작성자와 기여해 주신 모든 분들께 감사드립니다!
활성 대응에 맞서야 하거나 장기간(수 주, 수 개월, 수 년) 지속되는 레드 팀 인프라를 설계할 때는 각 자산을 기능에 따라 분리하는 것이 중요합니다. 이는 캠페인 자산이 탐지되기 시작할 때 블루 팀에 대한 복원력과 민첩성을 제공합니다. 예를 들어, 평가용 피싱 이메일이 식별된 경우 레드 팀은 전체 팀 서버를 새로 구성하는 대신 새 SMTP 서버와 페이로드 호스팅 서버만 만들면 됩니다.
다음 기능을 서로 다른 자산에 분리하는 것을 고려하세요:
이러한 각 기능은 각 소셜 엔지니어링 캠페인에 필요할 가능성이 높습니다. 레드 팀 평가에서는 활성 사고 대응이 일반적이므로 각 캠페인마다 새로운 인프라 세트를 구현해야 합니다.
복원력과 은닉성을 더욱 강화하기 위해 모든 백엔드 자산(예: 팀 서버) 앞에는 리다이렉터를 배치해야 합니다. 목표는 항상 대상과 백엔드 서버 사이에 호스트를 두는 것입니다. 이러한 방식으로 인프라를 구성하면 새 인프라를 훨씬 빠르고 쉽게 구축할 수 있습니다. 새 팀 서버를 구성하고, 세션을 마이그레이션하고, 백엔드에서 소각되지 않은 자산을 다시 연결할 필요가 없습니다.
일반적인 리다이렉터 유형:
각 리다이렉터 유형에는 다양한 시나리오에 가장 적합한 여러 구현 옵션이 있습니다. 이러한 옵션은 위키의 리다이렉터 섹션에서 자세히 설명합니다. 리다이렉터는 VPS 호스트, 전용 서버 또는 PaaS(Platform-as-a-Service) 인스턴스에서 실행되는 앱일 수도 있습니다.
기능 분리와 리다이렉터 사용을 고려한 샘플 설계는 다음과 같습니다:
Digital Ocean으로 C2 인프라 구축 방법 – 1부 - Lee Kagan (@invokethreatguy)
Terraform을 사용한 자동화된 레드 팀 인프라 배포 - 1부 - Rasta Mouse (@_RastaMouse)
인지된 도메인 평판은 대상이 사용하는 제품과 해당 구성에 따라 크게 달라집니다. 따라서 대상에서 작동할 도메인을 선택하는 것은 정확한 과학이 아닙니다. OSINT(오픈소스 정보 수집)는 통제 상태를 최선으로 추정하고 도메인을 확인할 리소스를 결정하는 데 중요합니다. 다행히도 온라인 광고주들도 동일한 문제에 직면하여 우리가 활용할 수 있는 몇 가지 솔루션을 만들었습니다.
expireddomains.net은 최근 만료되거나 삭제된 도메인을 위한 검색 엔진입니다. 만료 기간, 백링크 수, Archive.org 스냅샷 수, SimilarWeb 점수와 같은 검색 및 고급 필터링을 제공합니다. 이 사이트를 사용하면 도메인 수명이 있는 기존 사용 도메인을 등록할 수 있으며, 이는 대상과 유사해 보이거나, 사칭 대상과 유사해 보이거나, 단순히 대상 네트워크에 자연스럽게 섞일 가능성이 높은 도메인입니다.
C2 또는 데이터 유출용 도메인을 선택할 때는 금융 또는 의료로 분류된 도메인을 선택하는 것을 고려하세요. 많은 조직에서 법적 또는 데이터 민감성 문제의 가능성으로 인해 해당 범주에 대해 SSL 중간자 공격을 수행하지 않습니다. 또한 선택한 도메인이 이전의 악성코드 또는 피싱 캠페인과 연관되지 않도록 하는 것도 중요합니다.
Charles Hamilton(@MrUn1k0d3r)의 도구 CatMyFish는 expireddomains.net과 BlueCoat를 사용하여 검색 및 웹 분류 확인을 자동화합니다. 검색에 더 많은 필터를 적용하거나 등록한 자산의 장기 모니터링을 수행하도록 수정할 수 있습니다.
Joe Vest (@joevest)와 Andrew Chiles (@andrewchiles)의 또 다른 도구인 DomainHunter는 BlueCoat/WebPulse, IBM X-Force, Cisco Talos 분류, 도메인 수명, 대체 가능한 TLD, Archive.org 링크 및 HTML 보고서를 반환합니다. 또한 Malwaredomains.com과 MXToolBox를 사용하여 알려진 악성코드 및 피싱 캠페인에서의 사용 여부를 확인합니다. 이 도구에는 BlueCoat/WebPulse 캡차를 우회하기 위한 OCR 지원도 포함되어 있습니다. 도구 초기 릴리스에 대한 자세한 내용은 블로그 게시물을 확인하세요.
또 다른 도구인 Max Harley (@Max_68)의 AIRMASTER는 expireddomains.net과 Bluecoat를 사용하여 분류된 도메인을 찾습니다. 이 도구는 OCR을 사용하여 BlueCoat 캡차를 우회하여 검색 속도를 높입니다.
기존 등록 도메인을 사용할 수 없거나 직접 등록한 도메인을 선호하는 경우 도메인을 직접 분류할 수 있습니다. 아래의 직접 링크를 사용하거나 Dominic Chell (@domchell)의 Chameleon과 같은 도구를 사용하세요. 대부분의 분류 제품은 도메인 분류를 결정할 때 리디렉션이나 복제된 콘텐츠를 간과합니다. Chameleon 사용에 대한 자세한 내용은 Dominic의 게시물 분류는 보안 경계가 아닙니다를 확인하세요.
마지막으로 DNS 설정이 올바르게 전파되었는지 확인하세요.
간편함과 피싱이라는 단어는 실제로 잘 어울리지 않는 것 같습니다. 적절한 피싱 인프라를 구축하는 것은 정말 골치 아픈 일이 될 수 있습니다. 다음 튜토리얼은 현재까지 "대부분의" 스팸 필터를 통과하고 대상과의 양방향 통신을 포함한 간편한 피싱 경험을 위한 RoundCube 인터페이스를 제공하는 피싱 서버를 신속하게 구축하는 데 필요한 지식과 도구를 제공합니다. 피싱에 관한 많은 설정과 게시물이 있습니다. 이것은 그 중 하나의 방법일 뿐입니다.
이전 섹션에 나열된 적절한 확인을 통과한 도메인이 있고 피싱 서버를 가동했다면 아래 그림과 같이 도메인에 대한 "A" 레코드를 몇 개 생성해야 합니다.
다음으로 피싱 서버에 ssh로 접속하고 /etc/hosts에 올바른 FQDN 호스트 이름이 있는지 확인하세요. 예: "127.0.0.1 email.yourphishingserver.com email localhost"
이제 몇 가지 간단한 단계로 피싱에 사용할 웹 프런트엔드를 설치합니다. 먼저 최신 "BETA" 버전의 iRedMail을 피싱 서버에 다운로드하세요. 쉬운 방법은 다운로드 버튼을 마우스 오른쪽 버튼으로 클릭하고 링크 주소를 복사한 다음 wget을 사용하여 피싱 서버에 직접 다운로드하는 것입니다. 그런 다음 "tar -xvf iRedMail-0.9.8-beta2.tar.bz2"로 압축을 풉니다. 압축이 풀린 폴더로 이동하여 iRedMail.sh 스크립트를 실행 가능하게 만듭니다(chmod +x iRedMail.sh). 루트로 스크립트를 실행하고 프롬프트를 따르면 모든 것을 완료하기 위해 재부팅해야 합니다.
메일 서버를 가리키는 모든 올바른 DNS 레코드가 있는지 확인해야 합니다. (https://docs.iredmail.org/setup.dns.html). DKIM의 경우 DKIM 키를 나열하려면 새 명령은 "amavisd-new showkeys"여야 합니다.
DMARC의 경우 (https://www.unlocktheinbox.com/dmarcwizard/)를 사용하여 dmarc 항목을 생성할 수 있습니다.
이제 피싱에 사용할 사용자를 생성합니다.
새 사용자로 RoundCube 인터페이스에 로그인하고 책임감 있게 피싱하세요!
Cobalt Strike는 펜테스트 또는 레드 팀 이메일 피싱을 지원하는 사용자 정의 가능한 스피어피싱 기능을 제공합니다. HTML 및/또는 일반 텍스트 형식의 템플릿, 첨부 파일, 반송 주소, URL 임베딩, 원격 SMTP 서버 사용 및 메시지별 전송 지연을 지원합니다. 또 다른 흥미로운 기능은 클릭 추적을 위해 각 사용자의 임베디드 URL에 고유 토큰을 추가할 수 있다는 것입니다.
자세한 내용은 다음 리소스를 확인하세요:
클라이언트 신뢰와 OPSEC이 중요한 레드 팀 및 피싱 연습의 경우, 캡처된 클라이언트 데이터와 기본 인프라를 고객 자체 서버(온프레미스)에 유지하는 것은 클라우드 전용 솔루션보다 상당한 이점을 제공합니다. 이 접근 방식은 민감한 운영을 내부에 유지하면서 클라우드 자산을 얇은 리다이렉터와 프런트로만 사용합니다.
견고한 온프레미스 Evilginx 설정은 일반적으로 다음으로 구성됩니다:
쿠키 게이팅은 특정 쿠키를 요구하여 피싱 포털에 대한 봇 공격과 자동화된 스캐닝을 줄입니다:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
이 규칙은 필수 쿠키를 포함하지 않은 포털 도메인으로의 요청을 리디렉션하며, 리디렉션 루프를 방지하기 위해 파비콘 요청은 예외 처리합니다.
### 샘플 Caddy 구성```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
내부 노드에서 적절한 플래그와 함께 Evilginx를 실행합니다:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**중요:** Evilginx는 사설 네트워크 내부에서만 접근 가능해야 하며, 해당 IP를 공개 DNS에 게시해서는 안 됩니다.
### OPSEC 및 강화 체크리스트
1. **Evilginx IP를 공개 DNS에 절대 노출하지 마세요** - 사설 네트워킹만 사용하세요
2. **민감한 데이터는 클라이언트 서버에만 보관하세요** - 리다이렉터는 캡처된 자격 증명을 저장해서는 안 됩니다
3. **리다이렉터를 강화하세요** - 도메인을 순환하고, 짧은 TTL을 사용하며, 여러 개의 임시 리다이렉터를 배포하세요
4. **WAF/방화벽 규칙을 구현하세요** - 쿠키 검사, IP 허용 목록 또는 UA 검증을 사용하세요
5. **로깅과 보존을 분리하세요** - Caddy에 액세스 로그를, Evilginx 호스트에 캡처 로그를 유지하세요
6. **지문을 피하세요** - 예측 가능한 패턴이나 동일한 TLS 지문을 사용하지 마세요
이 하이브리드 접근 방식(공개 리다이렉터/사설 캡처)은 클라우드 프론팅의 복원력을 제공하면서도 민감한 작업을 온프레미스에 유지하는 보안 및 법적 이점을 유지합니다.
## 피싱 프레임워크
자체 피싱 설정을 직접 구축하거나 Cobalt Strike와 같은 침투 테스트 또는 레드 팀 프레임워크를 사용하는 것 외에도, 이메일 피싱에 특화된 수많은 도구와 프레임워크가 있습니다. 이 위키는 각 프레임워크에 대해 자세히 다루지는 않지만, 각각에 대한 몇 가지 리소스는 아래에 정리되어 있습니다:
### Gophish
* [Gophish 공식 사이트](https://getgophish.com/)
* [Gophish GitHub 저장소](https://github.com/gophish/gophish)
* [Gophish 사용자 가이드](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Phishing Frenzy 공식 사이트](https://www.phishingfrenzy.com/)
* [Phishing Frenzy GitHub 저장소](https://github.com/pentestgeek/phishing-frenzy)
* [Phishing Frenzy 소개 - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### Social-Engineer Toolkit
* [Social-Engineer Toolkit GitHub 저장소](https://github.com/trustedsec/social-engineer-toolkit)
* [Social-Engineer Toolkit 사용자 매뉴얼](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (구 FirePhish)
* [FiercePhish GitHub 저장소](https://github.com/Raikia/FiercePhish)
* [FiercePhish 위키](https://github.com/Raikia/FiercePhish/wiki)
# 리다이렉터
## SMTP
"리다이렉터"가 우리가 달성하려는 것을 설명하기에 가장 적절한 단어는 아닐 수 있지만, 목표는 다른 리다이렉션과 동일합니다. 최종 이메일 헤더에서 피싱 발신지의 모든 흔적을 제거하고 피해자와 백엔드 서버 사이에 버퍼를 제공하려는 것입니다. 이상적으로 SMTP 리다이렉터는 설정이 빠르고 폐기가 쉬워야 합니다.
SMTP 리다이렉터가 수행하도록 구성하려는 두 가지 핵심 작업이 있습니다:
### Sendmail
#### 이전 서버 헤더 제거
`/etc/mail/sendmail.mc` 끝에 다음 줄을 추가하세요:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
/etc/mail/access의 끝에 다음을 추가합니다:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### catch-all 주소 구성하기
이 설정은 *@phishdomain.com으로 수신된 모든 이메일을 선택한 이메일 주소로 전달합니다. 피싱 이메일에 대한 응답이나 반송 메시지를 수신하는 데 매우 유용합니다.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
//Mailer Definitions// 바로 앞(/etc/mail/sendmail.mc의 끝 부분)에 다음 줄을 추가합니다:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
`/etc/mail/virtusertable` 파일 끝에 다음 줄을 추가합니다:```bash
@phishdomain.com external-relay-address
참고: 두 필드는 탭으로 구분되어야 합니다
Postfix는 sendmail보다 더 쉬운 대안을 제공하며 호환성이 더 넓습니다. Postfix는 또한 Dovecot과 함께 완전한 IMAP 지원을 제공합니다. 이를 통해 테스터는 catch-all 주소에 의존하고 피싱 도구를 사용해 새 메시지를 만들어야 하는 대신, 원래 메시지에 응답하는 피싱 대상과 실시간으로 소통할 수 있습니다.
피싱용 Postfix 메일 서버 설정에 대한 전체 가이드는 Julian Catrambone(@n0pe_sled)의 게시물 Mail Servers Made Easy에서 확인할 수 있습니다.
참고: C2 리다이렉터를 사용할 때, 스테이징 트래픽이 리다이렉터 도메인을 통해 전송되도록 사후 침투 프레임워크에 외부 리스너를 구성해야 합니다. 이렇게 하면 손상된 호스트가 C2 트래픽과 마찬가지로 리다이렉터를 통해 스테이징하게 됩니다.
socat을 사용하여 포트 53의 수신 DNS 패킷을 팀 서버로 리다이렉트할 수 있습니다. 이 방법은 작동하지만, 일부 사용자는 이 방법을 사용할 때 Cobalt Strike의 스테이징 문제나 지연 시간 문제를 보고했습니다. 2017년 4월 21일 수정: 다음 socat 명령은 @xorrior의 테스트 덕분에 잘 작동하는 것으로 보입니다:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### DNS용 iptables
iptables DNS 포워딩 규칙은 Cobalt Strike와 잘 작동하는 것으로 확인되었습니다. socat이 이러한 유형의 트래픽을 처리할 때 겪는 문제는 없는 것으로 보입니다.
아래는 DNS 리다이렉터 규칙 세트의 예시입니다.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
또한 "FORWARD" 체인 정책을 "ACCEPT"로 변경합니다
일부 사용자는 내부 네트워크에 C2 서버를 호스팅해야 하는 요구 사항이나 필요성이 있을 수 있습니다. IPTABLES, SOCAT, 그리고 역방향 SSH 터널을 조합하여 다음과 같은 방식으로 확실히 이를 달성할 수 있습니다.
이 시나리오에서는 이 섹션 앞부분에서 설명한 규칙 예시를 사용하여 IPTables로 모든 DNS 트래픽을 전달하는 휘발성 리다이렉터를 사용합니다. 다음으로, 내부 C2 서버에서 메인 리다이렉터로 역방향 SSH 포트 포워딩 터널을 생성합니다. 이렇게 하면 메인 리다이렉터가 포트 6667에서 수신하는 모든 트래픽이 내부 C2 서버의 포트 6667로 전달됩니다. 이제 팀 서버에서 socat을 시작하여 포트 6667로 들어오는 모든 TCP 트래픽을 UDP 포트 53으로 포크(fork)합니다. 이는 DNS C2가 수신 대기해야 하는 포트입니다. 마지막으로, 메인 리다이렉터에서도 유사하게 socat 인스턴스를 설정하여 포트 53으로 들어오는 모든 UDP 트래픽을 포트 6667의 SSH 터널로 리다이렉트합니다.
참고: C2 리다이렉터를 사용할 때는 포스트 익스플로잇 프레임워크에서 외부 리스너(foreign listener)를 구성하여 스테이징 트래픽이 리다이렉터 도메인을 통해 전송되도록 해야 합니다. 이렇게 하면 손상된 호스트가 C2 트래픽 자체와 마찬가지로 리다이렉터를 통해 스테이징을 수행하게 됩니다.
socat은 '멍청한 파이프(dumb pipe)' 리다이렉션을 제공합니다. socat이 지정된 소스 인터페이스/포트에서 수신하는 모든 요청은 대상 IP/포트로 리다이렉트됩니다. 필터링이나 조건부 리다이렉션은 없습니다. 반면 Apache mod_rewrite는 피싱을 강화하고 테스트 인프라의 복원력을 높이는 여러 방법을 제공합니다. mod_rewrite는 URI, 사용자 에이전트, 쿼리 문자열, 운영 체제, IP와 같은 요청 속성을 기반으로 조건부 리다이렉션을 수행할 수 있습니다. Apache mod_rewrite는 htaccess 파일을 사용하여 Apache가 각 수신 요청을 처리하는 방식을 결정하는 규칙 세트를 구성합니다. 이러한 규칙을 사용하면, 예를 들어 기본 wget 사용자 에이전트로 서버에 요청을 보내는 트래픽을 대상 웹사이트의 합법적인 페이지로 리다이렉트할 수 있습니다.
요약하자면, 리다이렉터가 조건부 리다이렉션이나 고급 필터링을 수행해야 한다면 Apache mod_rewrite를 사용하십시오. 그렇지 않으면 선택적 iptables 필터링과 함께 socat 리다이렉션으로 충분합니다.
socat은 지정된 포트로 들어오는 모든 TCP 패킷을 팀 서버로 리다이렉트하는 데 사용할 수 있습니다.
로컬호스트의 TCP 포트 80을 다른 호스트의 포트 80으로 리다이렉트하는 기본 구문은 다음과 같습니다:``` socat TCP4-LISTEN:80,fork TCP4::80
리디렉터가 둘 이상의 네트워크 인터페이스로 구성된 경우, socat은 다음 구문을 사용하여 IP 주소로 특정 인터페이스에 바인딩할 수 있습니다:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
이 예시에서 10.0.0.2는 리다이렉터의 로컬 IP 주소 중 하나이고, 1.2.3.4는 원격 팀 서버의 IP 주소입니다.
socat 외에도 iptables는 NAT를 통해 '더미 파이프' 리다이렉션을 수행할 수 있습니다. 리다이렉터의 로컬 포트 80을 원격 호스트로 전달하려면 다음 구문을 사용하세요:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### HTTP용 SSH
이전에 DNS 터널에 SSH를 사용하는 방법을 다룬 적이 있습니다. SSH는 NAT를 뚫고 임플란트가 리다이렉터와 서버 환경에 연결할 수 있는 경로를 확보하는 견고하고 안정적인 수단으로 작동합니다. SSH 리다이렉터를 설정하기 전에 `/etc/ssh/sshd_config`에 다음 줄을 추가해야 합니다:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
내부 서버에서 리다이렉터의 로컬 포트 80을 내부 팀 서버로 전달하려면, 내부 서버에서 다음 구문을 사용하세요:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
여러 포트를 동시에 포워딩할 수도 있습니다. 예를 들어 443과 80을 동시에 열고 싶다면 다음과 같이 하면 됩니다:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
페이로드와 웹 리소스를 제공할 때, 사고 대응자가 파일을 검토할 수 있는 가능성을 최소화하고 C2 구축 또는 정보 수집 여부와 관계없이 페이로드 실행 성공 가능성을 높이고자 합니다.
Jeff Dimmock의 Apache Mod_Rewrite 사용법 및 예제:
기타 Apache mod_rewrite 사용법 및 예제:
리다이렉터 서버에 Apache Mod_Rewrite를 자동으로 설정하려면 Julain Catrambone(@n0pe_sled)의 블로그 게시물 Mod_Rewrite 자동 설정과 관련 도구를 확인하세요.
C2 트래픽을 리다이렉션하는 의도는 두 가지입니다: 백엔드 팀 서버를 숨기고, 사고 대응자가 접속했을 때 합법적인 웹사이트처럼 보이게 하는 것입니다. Apache mod_rewrite와 맞춤형 C2 프로필 또는 기타 프록시(예: Flask)를 통해 실제 C2 트래픽을 조사용 트래픽과 안정적으로 필터링할 수 있습니다.
위의 "C2 리다이렉션"을 확장하여, 또 다른 방법은 리다이렉팅 서버가 Apache의 SSL Proxy Engine을 사용하여 인바운드 SSL 요청을 수락하고, 해당 요청을 역방향 HTTPS 리스너로 프록시하는 것입니다. 모든 단계에서 암호화가 사용되며, 필요에 따라 리다이렉터의 SSL 인증서를 교체할 수 있습니다.
이를 mod_rewrite 규칙과 함께 작동시키려면 LetsEncrypt(일명 CertBot)로 인증서를 설치했다고 가정할 때 규칙을 **"/etc/apache2/sites-available/000-default-le-ssl.conf"**에 배치해야 합니다. 또한 SSL ProxyPass 엔진을 활성화하려면 동일한 구성 파일에 다음 줄이 필요합니다:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### 기타 Apache mod_rewrite 리소스
* [Automating Apache mod_rewrite and Cobalt Strike Profiles](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [공식 Apache 2.4 mod_rewrite 문서](http://httpd.apache.org/docs/current/rewrite/)
* [Apache mod_rewrite 소개](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Apache용 mod_rewrite 심층 가이드](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod_rewrite-for-apache--net-6708)
* [Mod_Rewrite/.htaccess 구문 검사기](http://www.htaccesscheck.com/)
# C2 트래픽 수정
## Cobalt Strike
Cobalt Strike는 Malleable C2 프로필로 트래픽을 수정합니다. 프로필은 서버의 C2 트래픽이 네트워크 상에서 어떻게 보일지 수정할 수 있는 고도로 사용자 정의 가능한 옵션을 제공합니다. Malleable C2 프로필은 침해 대응 회피를 강화하고, 알려진 적을 사칭하거나, 대상이 사용하는 합법적인 내부 애플리케이션으로 위장하는 데 사용할 수 있습니다.
* [공식 Malleable C2 프로필 - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Malleable Command and Control 문서 - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - 권한 상승을 위한 경로 - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [A Brave New World: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [Cobalt Strike용 Malleable C2 프로필 작성 방법 - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [인메모리 회피 (비디오 시리즈) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Malleable C2 프로필을 만들거나 수정하기 시작할 때, Beacon 정보 배치에 대한 데이터 크기 제한을 염두에 두는 것이 중요합니다. 예를 들어, URL 매개변수에 대량의 데이터를 보내도록 프로필을 구성하면 많은 요청이 필요하게 됩니다. 이에 대한 자세한 내용은 Raphael Mudge의 블로그 게시물 [Beware of Slow Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/)를 확인하세요.
Malleable C2 프로필에 문제가 발생하고 teamserver 콘솔에서 오류가 출력되는 경우, 문제 해결 팁은 Raphael Mudge의 블로그 게시물 [Broken Promises and Malleable C2 Profiles](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/)를 참조하세요.
## Empire
Empire는 Communication Profiles를 사용하며, 이는 GET 요청 URI, 사용자 에이전트 및 헤더에 대한 사용자 정의 옵션을 제공합니다. 프로필은 각 요소가 파이프 문자로 구분되고 `listeners` 컨텍스트 메뉴의 `set DefaultProfile` 옵션으로 설정됩니다.
다음은 기본 프로필의 예시입니다:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
대안으로, DefaultProfile 값은 Empire의 초기 설정 전에 /setup/setup_database.py 파일을 수정하여 설정할 수 있습니다. 이렇게 하면 Empire가 사용할 기본 통신 프로필이 변경됩니다.
통신 프로필 외에도 Joe Vest(@joevest)의 게시물 Empire - Modifying Server C2 Indicators에 제시된 단계에 따라 Empire 서버의 스테이징 URI, 서버 헤더 및 기본 웹페이지 콘텐츠를 사용자 지정하는 것을 고려하세요.
신뢰할 수 있는 합법적인 웹 서비스를 C2에 활용하면 직접 구성한 도메인과 인프라를 사용하는 것보다 상당한 이점을 얻을 수 있습니다. 구성 시간과 복잡성은 사용되는 기술과 서비스에 따라 다릅니다. 타사 서비스를 C2 리디렉션에 활용하는 대표적인 예로 도메인 프론팅(Domain Fronting)이 있습니다.
도메인 프론팅은 검열 회피 서비스와 앱에서 합법적이고 신뢰도가 높은 도메인을 통해 트래픽을 라우팅하는 데 사용하는 기술입니다. 도메인 프론팅을 지원하는 인기 있는 서비스로는 Google App Engine, Amazon CloudFront, Microsoft Azure 등이 있습니다. Google 및 Amazon과 같은 많은 제공업체가 도메인 프론팅에 대한 완화 조치를 구현했다는 점에 유의해야 하므로, 이 위키에서 제공되는 일부 링크된 리소스나 정보는 사용 시점에 이미 오래되었을 수 있습니다.
간단히 말해, 트래픽은 신뢰할 수 있는 서비스 제공업체의 DNS 및 SNI 이름을 사용합니다. 아래 예시에서는 Google이 사용됩니다. 트래픽이 엣지 서버(예: gmail.com에 위치)에 수신되면 패킷의 Host 헤더에 지정된 오리진 서버(예: phish.appspot.com)로 패킷이 전달됩니다. 서비스 제공업체에 따라 오리진 서버는 지정된 도메인(우리가 팀 서버로 지정할)으로 트래픽을 직접 전달하거나, 최종 홉 전달을 수행하기 위해 프록시 앱이 필요할 수 있습니다.
도메인 프론팅 작동 방식에 대한 자세한 내용은 백서 Blocking-resistant communication through domain fronting 및 TOR 프로젝트의 meek 문서를 참조하세요.
모든 google.com 도메인과 같은 표준 프론팅 가능 도메인 외에도 다른 합법적인 도메인을 프론팅에 활용할 수 있습니다.
프론팅 가능한 도메인을 찾는 방법에 대한 자세한 내용은 다음을 확인하세요:
많은 PaaS 및 SaaS 제공업체는 프로비저닝된 인스턴스와 함께 사용할 정적 하위 도메인 또는 URL을 제공합니다. 연결된 도메인이 일반적으로 신뢰도가 높다면, 해당 인스턴스는 구매한 도메인과 VPS보다 C2 인프라에 추가적인 신뢰를 제공할 수 있습니다.
리디렉션을 설정하려면 인스턴스의 일부로 정적 하위 도메인 또는 URL을 발급하는 서비스를 식별해야 합니다. 그런 다음 인스턴스에 네트워크 또는 애플리케이션 기반 리디렉션을 구성해야 합니다. 인스턴스는 이 위키에서 논의된 다른 리디렉터와 유사하게 프록시 역할을 합니다.
추가 연구가 필요한 또 다른 흥미로운 기술은 과도하게 허용적인 Amazon S3 버킷을 C2에 사용하는 것입니다. S3 버킷을 C2에 사용할 수 있는 방법에 대한 자세한 내용은 Andrew Luke (@Sw4mp_f0x)의 게시물 S3 Buckets for Good and Evil을 확인하세요. 이 기술은 Empire의 타사 C2 기능과 결합하여 대상의 합법적인 S3 버킷을 역으로 사용할 수 있습니다.
PaaS를 C2에 사용하는 또 다른 예는 Scott Sutherland(@_nullbind)의 Databases and Clouds: SQL Server as a C2를 확인하세요.
과거에는 다른 타사 서비스도 C2에 사용된 사례가 있었습니다. 사용자 생성 콘텐츠의 빠른 게시 또는 수정을 허용하는 타사 웹사이트를 활용하면 평판 기반 통제를 회피하는 데 도움이 될 수 있습니다. 특히 해당 타사 사이트가 일반적으로 신뢰받는 경우 더욱 그렇습니다.
다른 타사 C2 옵션에 대한 다음 리소스를 확인하세요:
공격 인프라는 합법적인 서버의 껍데기처럼 보여 쉽게 식별되는 경우가 많습니다. 대상 조직이나 대상이 사용할 법한 서비스 사이에서 실제 서버와 더 잘 섞이도록 인프라에 추가적인 조치를 취해야 합니다.
리디렉터는 잘못된 URI 리디렉션, 피싱 페이로드 링크 만료, 또는 일반적인 사고 대응자 기술 차단을 통해 위장에 도움이 될 수 있습니다. 그러나 기본 호스트와 그 지표에도 주의를 기울여야 합니다.
예를 들어, John Menerick(@Lord_SQL)의 게시물 Fall of an Empire에서는 인터넷에서 Empire 서버를 탐지하는 방법을 다룹니다.
이러한 지표 및 유사한 지표에 대응하려면 C2 트래픽 패턴 수정, 서버 랜딩 페이지 수정, 열린 포트 제한, 기본 응답 헤더 수정을 수행하는 것이 좋습니다.
여러 공격 프레임워크에 대해 이러한 방법 및 기타 전술을 수행하는 방법에 대한 자세한 내용은 다음 게시물을 확인하세요:
공격 인프라는 다른 인터넷 연결 호스트와 마찬가지로 공격을 받을 수 있으며, 사용 중인 데이터와 대상 환경으로의 연결로 인해 매우 민감한 것으로 간주되어야 합니다.
2016년에는 가장 일반적인 공격 도구에서 원격 코드 실행 취약점이 공개되었습니다:
iptables를 사용하여 원치 않는 트래픽을 필터링하고 필수 인프라 요소 간의 트래픽을 제한해야 합니다. 예를 들어, Cobalt Strike 팀 서버가 Apache 리디렉터에만 자산을 제공하는 경우 iptables 규칙은 리디렉터의 소스 IP에서 포트 80만 허용해야 합니다. 이는 SSH 또는 Cobalt Strike의 기본 포트 50050과 같은 관리 인터페이스에 특히 중요합니다. 또한 비대상 국가 IP를 차단하는 것도 고려하세요. 대안으로 VPS 제공업체가 제공하는 하이퍼바이저 방화벽 사용을 고려하세요. 예를 들어, Digital Ocean은 하나 이상의 드롭릿을 보호할 수 있는 Cloud Firewalls를 제공합니다.
chattr는 팀 서버에서 cron 디렉터리가 수정되는 것을 방지하는 데 사용할 수 있습니다. chattr을 사용하면 chattr 속성이 제거될 때까지 root를 포함한 모든 사용자가 파일을 수정하지 못하도록 제한할 수 있습니다.
SSH는 공개 키 인증 전용으로 제한하고 초기 로그인에는 제한된 권한의 사용자를 사용하도록 구성해야 합니다. 추가 보안을 위해 SSH에 다중 인증(MFA)을 추가하는 것을 고려하세요.
업데이트! 정기적으로 시스템을 업데이트하고 취약점을 해결하기 위해 필요에 따라 핫픽스를 적용하는 것을 잊지 않는 보안 목록이 완성됩니다.
물론 이 목록이 팀 서버를 보호하기 위해 할 수 있는 모든 것을 포함하는 것은 아닙니다. 모든 인프라에 일반적인 강화(hardening) 관행을 따르세요:
인프라의 안전한 설정과 설계에 대해 논의하는 온라인 리소스가 많이 있습니다. 모든 설계 고려 사항이 모든 공격 인프라에 적합한 것은 아니지만, 어떤 옵션을 사용할 수 있고 다른 테스터들이 무엇을 하고 있는지 아는 것은 유용합니다.
다음은 그러한 리소스 중 일부입니다:
이 위키에서 다루는 주제는 공격 인프라를 강화하지만 일반적으로 설계하고 구현하는 데 상당한 시간이 필요합니다. 자동화를 사용하면 배포 시간을 크게 줄여 더 복잡한 구성을 더 짧은 시간에 배포할 수 있습니다.
공격 인프라 자동화에 대한 다음 리소스를 확인하세요:
모든 것을 문서화하세요 - 복잡한 레드 팀 인프라를 운영한다는 것은 많은 움직이는 부품이 있다는 것을 의미합니다. 각 자산의 기능과 트래픽이 전송되는 위치를 반드시 문서화하세요.
자산을 여러 서비스 제공업체와 지역에 분산하세요 - 인프라 자산은 여러 서비스 제공업체와 지리적 지역에 분산되어야 합니다. 블루 팀 구성원은 공격을 적극적으로 수행하는 것으로 식별된 제공업체에 대한 모니터링 임계값을 높이거나 특정 서비스 제공업체를 완전히 차단할 수도 있습니다. 참고: 암호화되거나 민감한 데이터를 국경을 넘어 전송할 때는 국제 개인정보 보호법을 염두에 두세요.
과용하지 마세요 - 고급 기술에 흥분하여 대상에게 모든 것을 쏟아붓고 싶어지기 쉽습니다. 특정 적대적 위협을 모방하는 경우, 실제 위협 행위자가 사용한 기술 또는 위협 행위자의 기술 범위 내에 있는 기술만 활용하세요. 레드 팀 테스트가 장기간 동일한 대상을 공격할 경우, "쉬운" 것부터 시작하여 평가가 진행됨에 따라 더 고급 트레이드크래프트를 사용하는 것을 고려하세요. 블루 팀과 함께 레드 팀의 기술을 발전시키면 조직이 지속적으로 발전하지만, 한 번에 모든 것을 블루 팀에게 쏟아붓는 것은 블루 팀을 압도하고 학습 과정을 늦출 수 있습니다.
로그를 모니터링하세요 - 모든 로그는 작전 기간 내내 모니터링되어야 합니다: SMTP 로그, Apache 로그, socat 리디렉터의 tcpdump, iptables 로그(트래픽 전달 또는 대상 필터링 관련), 웹로그, Cobalt Strike/Empire/MSF 로그. rsyslog와 같은 도구를 사용하여 로그를 중앙 위치로 전달하면 모니터링이 더 쉬워집니다. 운영 중 과거 명령 사용을 검토할 때 운영자 터미널 데이터 보존이 유용할 수 있습니다. @Killswitch_GUI는 모든 bash 터미널 명령을 중앙 위치에 기록하는 사용하기 쉬운 프로그램인 lTerm을 만들었습니다. lTerm으로 모든 터미널 출력 기록. 고급 인프라 모니터링 및 분석을 위해 Cobalt Strike 로그를 Splunk로 보내는 방법의 예는 Vincent Yiu의 게시물 CobaltSplunk을 확인하세요.* 고가치 이벤트 알림 구현 - 공격 인프라를 구성하여 새 C2 세션이나 자격 증명 캡처 성공과 같은 고가치 이벤트에 대한 알림을 생성합니다. 알림을 구현하는 인기 있는 방법 중 하나는 Slack과 같은 채팅 플랫폼의 API를 이용하는 것입니다. Slack 알림에 대한 다음 게시물을 확인하세요: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
사고 대응 핑거프린팅 - 가능하다면 평가가 시작되기 전에 IR 활동을 수동적 또는 능동적으로 핑거프린팅해 보세요. 예를 들어, 관련 없는 인프라를 사용하여 대상에게 평범한 수준의 피싱 이메일을 보내고 해당 인프라가 수신하는 트래픽을 모니터링합니다. IR 팀의 조사는 팀이 어떻게 운영되고 어떤 인프라를 사용하는지에 대한 많은 정보를 노출할 수 있습니다. 이를 평가 전에 파악할 수 있다면 필터링하거나 완전히 우회할 수 있습니다.
위키에 포함할 도구, 팁 또는 링크를 기여해 주신 다음 모든 분들(알파벳순)께 큰 감사를 드리며, 이 위키에서 참조된 도구나 게시물을 작성해 주신 모든 분께도 다시 한번 감사드립니다!