HTTP 악용의 단계, 분석 방법 고르기, URL 평판 확인¶

이 페이지에서 다루는 것

공격자가 HTTP를 공격의 거의 모든 단계(전달·공격·설치·C2·유출)에 쓰는 방식과 각 단계가 로그에 어떻게 보이는지, 자동 분석과 수동 분석 중 무엇을 먼저 고를지, 가장 쉬운 첫 단계인 URL 평판 확인과 그 함정(평판 좋은 도메인의 나쁜 URL, 결과 없음 ≠ 안전), 그리고 조사할 때 정보를 흘리지 않는 법(OPSEC, 디팽). 마지막에 확인 문제와 해설이 있습니다.

표기

[보충] = 꼭 알아야 할 실무 보충, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. HTTP 자체의 기초는 HTTP 섹션에 있습니다.

한눈에 보는 핵심 8가지¶

HTTP는 공격의 거의 모든 단계에 쓰인다. 단계마다 로그에 남는 모양이 다르다.
분석은 빠른 답부터: 자동(평판 조회, 스크린샷, 샌드박스) → 안 되면 수동(헤더·내용 분석, 파일 추출, 이상 징후 찾기).
방법마다 잘 맞는 단계가 다르다. 스크린샷은 피싱엔 좋지만 C2 주소엔 쓸모없다.
URL 평판 조회는 "악성이다"를 가장 빨리 확인하는 방법이다.
결과 없음 ≠ 깨끗함. 새로 만든 주소는 어디에도 기록이 없다.
좋은 도메인 ≠ 안전한 URL. 해킹된 블로그, 클라우드 공유 파일, 워터링 홀.
조회와 제출은 다르다. 공개 스캐너에 제출하면 남이 볼 수 있고 공격자에게 신호가 갈 수 있다(OPSEC).
보고서·티켓에 URL을 적을 때는 클릭되지 않게 디팽(hxxps://evil[.]example)한다.

HTTP는 공격의 거의 모든 단계에 쓰인다¶

왜 중요한가. HTTP는 거의 모든 조직이 허용하는 프로토콜이라, 공격자 트래픽이 정상 트래픽 속에 섞이기 좋습니다. 악성 파일을 전달하고, 피싱 사이트로 비밀번호를 훔치고, C2와 데이터 유출에도 쓰입니다. 그래서 분석가는 공격의 각 단계에서 HTTP가 어떻게 보이는지 알아야 합니다.

공격 단계를 설명할 때 자주 쓰는 틀이 록히드 마틴의 사이버 킬 체인(Cyber Kill Chain)입니다. 공격을 일곱 단계로 나눈 것으로, 이 사이트의 다른 학습 페이지에서도 다시 나옵니다.

단계	뜻	HTTP가 쓰이는 방식
1 정찰(Recon)	표적 조사	공격자가 회사 웹사이트·채용 공고를 훑어봄(우리 웹 서버 로그에 남음)
2 무기화(Weaponize)	공격 도구 준비	공격자 쪽에서 일어나 보통 우리 로그엔 안 보임
3 전달(Deliver)	공격을 표적에게 보냄	피싱 링크, 악성 광고, 해킹된 사이트의 리디렉션, 가짜 업데이트
4 공격(Exploit)	취약점을 이용해 실행	익스플로잇 킷, 브라우저·플러그인 공격, 사용자가 직접 실행하게 속이기
5 설치(Install)	악성코드 자리 잡기	실행 파일·스크립트 다운로드
6 C2(Command & Control)	원격 조종	주기적인 GET·POST
7 목표 달성(Actions)	데이터 탈취 등	인코딩·암호화된 업로드

각 단계가 프록시 로그에서 어떻게 보이는지 예를 들어 보겠습니다(도메인은 모두 예시).

09:01:14  GET  https://parcel-redelivery.example/track?id=8812           200  text/html
09:01:20  GET  https://parcel-redelivery.example/dl/label.zip            200  application/zip
09:02:03  GET  http://203.0.113.71/u/update.ps1                          200  text/plain
09:05:00  POST https://api-telemetry-sync.example/gate                   200  text/html  (312 B)
09:10:00  POST https://api-telemetry-sync.example/gate                   200  text/html  (312 B)
13:47:31  POST https://api-telemetry-sync.example/upload                 200  text/html  (148 MB sent)

1줄 전달: 택배 재배송을 흉내 낸 피싱 링크를 누름
2줄 전달·공격: 그 사이트에서 ZIP을 받음(안에 실행 파일이나 스크립트가 들어 있을 수 있음)
3줄 설치: 도메인이 아닌 IP 주소로 직접 PowerShell 스크립트를 받음
4~5줄 C2: 정확히 5분 간격으로 같은 주소에 작은 POST(같은 크기 312바이트) — 비콘
6줄 목표 달성: 같은 C2로 148MB를 올림 — 데이터 유출

한 줄씩 보면 평범해 보여도, 시간 순서로 이어 보면 공격 전체가 HTTP 위에서 일어났다는 게 드러납니다.

[보충] 요즘 SOC에서는 킬 체인보다 더 잘게 나눈 MITRE ATT&CK을 더 많이 씁니다. 위 예를 ATT&CK으로 쓰면 피싱 링크는 T1566.002(Spearphishing Link), 웹 프로토콜 C2는 T1071.001(Web Protocols), C2 채널로 유출은 T1041(Exfiltration Over C2 Channel)입니다. 킬 체인은 "큰 흐름", ATT&CK은 "구체적인 기법"을 말할 때 씁니다.

분석 방법 고르기: 빠른 답부터¶

왜 필요한가. 분석가에게 시간은 한정돼 있습니다. 경보 하나에 몇 시간을 쓰면 다른 경보가 쌓입니다. 그래서 가장 빨리 정확한 답에 닿는 방법을 고르는 것이 기술입니다. 다만 빠름을 위해 정확함을 희생하면 안 됩니다.

구분	방법	장점	한계
자동	URL·사이트 평판 조회	몇 초 만에 답	새 주소는 기록 없음
자동	스크린샷 서비스	피싱 페이지를 눈으로 바로 확인	C2 주소는 빈 화면이라 쓸모없음
자동	샌드박스(HTML 분석, 가상 머신에서 통째 실행)	실제 동작을 봄	시간이 걸리고, 샌드박스를 알아채는 악성코드가 있음
수동	헤더 분석(요청·응답)	무엇을 주고받았는지 정확히	사람 시간이 듦
수동	내용 분석, 파일 추출, 이상 징후 찾기	자동 도구가 놓친 걸 찾음	가장 느림, 기술 필요

순서는 보통 자동으로 빠르게 확인 → 답이 안 나오거나 애매하면 수동으로 깊게입니다. 그리고 단계에 맞는 방법을 골라야 합니다.

피싱 페이지(전달) → 스크린샷이 가장 빠름. 마이크로소프트 로그인 화면을 흉내 냈는지 한눈에 보임
악성 파일 다운로드(설치) → 파일 해시 평판 조회, 샌드박스
C2 주소 → 스크린샷은 빈 페이지나 가짜 404만 보여 줌. 헤더 분석, 통신 주기·크기 같은 수동 분석이 필요

가장 쉬운 첫 단계: URL 평판 조회¶

무엇인가. 전 세계 보안 업체와 커뮤니티가 모은 "이 URL은 악성으로 확인됨" 기록을 찾아보는 것입니다. 이미 누군가 악성으로 확인한 주소라면 몇 초 만에 확정할 수 있어서 가장 빠른 첫 단계입니다.

대표적인 서비스(목적과 보여 주는 정보가 서로 다름):

서비스	특징
VirusTotal	URL·도메인·파일 해시를 여러 보안 엔진으로 동시에 판정
urlscan.io	페이지를 실제로 열어 스크린샷, 불러온 리소스, 리디렉션을 보여 줌
URLhaus(abuse.ch)	악성코드 배포 URL 목록
Google Safe Browsing 투명성 보고서	크롬이 경고하는 사이트인지
Cisco Talos Intelligence	IP·도메인 평판

함정 1: 결과 없음 ≠ 깨끗함¶

평판 조회는 이미 누군가 발견해서 기록한 것만 알려 줍니다. 공격자는 피싱 도메인을 새로 만들고 몇 시간만 쓰고 버리는 경우가 많습니다. 그런 주소는 어디에도 기록이 없어서 "0개 엔진 탐지"로 나옵니다. "나쁘다는 기록이 없다"와 "안전하다"는 다릅니다. 결과가 깨끗하면 다음 단계(도메인 나이, 내용 분석)로 넘어갑니다.

함정 2: 좋은 도메인 ≠ 안전한 URL¶

URL 하나의 평판과 도메인 전체의 평판은 다릅니다. 평판 좋은 도메인 위에도 악성 URL이 있을 수 있습니다.

https://www.small-bakery.example/wp-content/uploads/2026/11/inv.php
https://www.dropbox.com/scl/fi/a8k2.../Remittance_Advice.zip?dl=1
https://www.industry-association.example/news/2026-conference

1줄 해킹된 워드프레스 블로그: 빵집 도메인은 오래되고 깨끗하지만, 업로드 폴더에 공격자가 심은 PHP 파일이 있음
2줄 클라우드 공유 파일: Dropbox는 세계적으로 평판이 좋지만, 그 안의 파일은 누구나 올릴 수 있음
3줄 워터링 홀(Watering Hole): 표적들이 자주 가는 업계 협회 사이트를 해킹해 그 페이지에 공격 코드를 심는 수법. 사자가 동물들이 모이는 물웅덩이에서 기다리는 것에 빗댄 이름

그래서 조회할 때 전체 URL과 도메인을 따로 봅니다. 도메인 전체가 나쁜지 알고 싶으면 도메인을 검색하고, 이 주소가 나쁜지 알고 싶으면 URL을 검색합니다. 좋은 도메인 평판이 그 도메인의 모든 것을 보증하지는 않습니다.

결과 읽기 예¶

URL:        https://login-m365-secure.example/auth?client=office
Detections: 7 / 94 engines flagged as phishing
First seen: 2026-11-04 08:12 UTC (5 hours ago)
Domain age: 2 days
Final URL:  https://login-m365-secure.example/auth/index.php
Page title: "Sign in to your account"

7/94 — 94개 엔진 중 7개가 피싱으로 판정. 숫자가 작아 보여도 새 주소는 엔진들이 따라잡는 데 시간이 걸리므로 소수의 탐지도 중요한 신호
First seen 5시간 전, 도메인 나이 2일 — 갓 만든 주소
Page title "Sign in to your account" — 마이크로소프트 로그인 화면 제목을 흉내
종합하면 사실상 확정. 다음은 누가 접속했고 무엇을 입력했나를 조사

[보충] 조사하면서 정보를 흘리지 않기(OPSEC)¶

평판 서비스 사용이 보안 운영 기준(OPSEC, Operational Security)에 맞는지도 따져야 합니다. 조회 방법에는 단계가 있습니다.

단계	하는 일	위험
수동적 조회	이미 있는 결과만 검색	거의 없음
공개 제출	서비스가 그 주소를 새로 방문·분석, 결과가 공개	남이 볼 수 있음, 공격자가 알아챌 수 있음
비공개 제출	결과를 나만 봄(유료·설정 필요)	서비스가 방문하는 것 자체는 공격자 서버 로그에 남음
우리 쪽 격리 환경에서 직접 확인	사내 샌드박스·분석 VM	조직 IP가 드러나지 않게 설정해야 함

조심해야 할 이유:

공개 스캔 결과는 누구나 봅니다. 피싱 URL에는 종종 피해자 이메일이 들어 있습니다(?u= 뒤의 Base64 등). 공개 제출하면 우리 직원 이메일과 "이 사람이 표적"이라는 정보가 공개됩니다. 비밀번호 재설정 링크, 문서 공유 링크처럼 토큰이 든 정상 URL을 잘못 제출하면 그 문서나 계정이 노출될 수 있습니다.
공격자도 이 서비스들을 봅니다. 자기 URL이 제출되면 "들켰다"는 걸 알고 주소를 바꾸거나 흔적을 지웁니다.
회사 PC나 회사 IP로 의심 URL을 직접 열지 않습니다. 공격자 서버 로그에 우리 조직이 조사 중이라는 게 남고, PC가 감염될 수 있습니다.

[보충] 디팽(Defang). 보고서, 티켓, 채팅에 의심 URL을 적을 때는 실수로 클릭되거나 자동으로 링크가 되지 않게 모양을 바꿉니다.

https://login-m365-secure.example/auth   →   hxxps://login-m365-secure[.]example/auth
203.0.113.71                             →   203.0.113[.]71

http → hxxp, https → hxxps
점 . → [.]
받는 사람이 분석할 때는 다시 원래대로 되돌려(리팽, Refang) 도구에 넣음

2026년 관점¶

[2026 현재] 그대로 유효한 것

"HTTP는 거의 모든 단계에 쓰인다", "빠른 자동 확인 → 필요하면 수동", "결과 없음 ≠ 안전", "좋은 도메인 ≠ 안전한 URL"은 모두 그대로입니다. 특히 마지막 원칙은 클라우드 서비스 악용이 늘면서 더 중요해졌습니다.

[변경됨] 바뀐 것

평판 조회를 피하는 기술이 늘었습니다. 피싱 도메인은 몇 시간만 쓰고 버리고, 방문자가 보안 스캐너인지 확인해서 스캐너에는 깨끗한 페이지를 보여 주며(클로킹), CAPTCHA나 Cloudflare Turnstile 같은 확인 화면 뒤에 피싱 페이지를 숨겨 자동 스캐너가 내용을 못 보게 합니다. 그래서 "스캐너가 본 결과"와 "피해자가 본 화면"이 다를 수 있습니다.
QR 코드 피싱(Quishing)이 흔해졌습니다. 메일 본문에 URL 대신 QR 코드 이미지를 넣어, 메일 필터의 URL 검사를 피하고 회사 보안이 없는 개인 휴대폰으로 열게 만듭니다. QR 코드를 디코딩해서 URL을 꺼낸 다음 평판을 확인해야 합니다.
평판 확인은 자동화가 기본입니다. SIEM·SOAR가 경보에 들어온 URL·도메인·해시를 자동으로 여러 서비스에 조회해 붙여 주는 보강(Enrichment)이 일반화됐습니다. 분석가는 조회 자체보다 결과 해석과 그 너머의 분석에 시간을 씁니다.
AI로 만든 피싱 페이지가 늘어 문장 어색함 같은 예전 단서가 약해졌습니다. 반면 도메인 나이, 인증서 발급 시점, 호스팅 위치 같은 기술적 신호는 여전히 통합니다.

[주의] 지금 그대로 하면 틀리거나 위험한 것

"평판 깨끗함 = 종결"로 처리하지 않습니다. 새 도메인, 클라우드 호스팅, 확인 화면으로 가려진 페이지는 평판 서비스가 모를 수 있습니다.
공개 스캐너에 아무 URL이나 제출하지 않습니다. 피해자 정보나 토큰이 든 URL은 파라미터를 지우거나, 비공개 옵션이나 사내 격리 환경을 씁니다.
회사 PC로 의심 URL을 직접 열어 보지 않습니다.

확인 문제¶

문제 1¶

다음 네 프록시 로그 줄은 각각 킬 체인의 어느 단계에 해당할 가능성이 높습니까?

A: POST https://cdn-metrics-api.example/beacon   (every 60 s, 256 B)
B: GET  https://hr-portal-update.example/review.html   (link from email)
C: GET  http://198.51.100.9/s/a.exe
D: POST https://cdn-metrics-api.example/up   (2.3 GB sent, 02:10)

정답과 해설

A — C2(6단계). 같은 주소에 정확히 60초마다 같은 크기의 작은 POST = 비콘.
B — 전달(3단계). 메일 속 링크로 연 수상한 페이지 = 피싱 전달.
C — 설치(5단계). 도메인 없이 IP 주소로 직접 실행 파일을 받음. 정상 소프트웨어는 보통 도메인과 https를 씀.
D — 목표 달성(7단계), 데이터 유출. C2와 같은 도메인으로 새벽에 2.3GB 업로드.

A와 D가 같은 도메인이라는 점이 중요합니다. C2 채널로 그대로 유출한 것으로 보입니다(ATT&CK T1041). 이렇게 단계별 흔적을 시간 순서로 이으면 사건 전체 그림이 나옵니다.

문제 2¶

직원이 메일로 받은 링크를 눌렀습니다. 그 URL을 VirusTotal에서 찾아보니 0/94, urlscan.io에도 기록이 없습니다. "안전하네요, 종결하겠습니다"라는 판단은 맞습니까? 무엇을 더 확인해야 합니까?

정답과 해설

맞지 않습니다. 결과 없음은 "아직 아무도 기록하지 않았다"는 뜻일 뿐입니다. 피싱 도메인은 새로 만들어 몇 시간만 쓰는 경우가 많고, 클로킹이나 확인 화면으로 스캐너를 피하기도 합니다.

더 확인할 것:

도메인 나이와 등록 정보 — 며칠 전에 만들었다면 강한 의심 신호
인증서 발급 시점 — 인증서 투명성(CT) 로그에서 그 도메인 인증서가 언제 처음 발급됐는지
안전한 방식의 내용 확인 — 격리된 분석 환경이나 비공개 스캔으로 페이지를 열어 로그인 화면을 흉내 내는지
우리 로그 — 그 직원이 그 사이트에 POST(로그인 정보 입력)를 했는지, 이후 무엇을 받았는지
같은 메일을 받은 다른 직원 — 메일 게이트웨이에서 같은 발신자·제목·URL 검색

문제 3¶

피싱 메일 속 URL이 이렇습니다.

https://login-verify.example/start?u=ai5zbWl0aEBjb3JwLmV4YW1wbGU=

이 URL을 그대로 공개 스캐너에 제출해도 될까요? 무엇이 위험하고, 어떻게 해야 할까요?

정답과 해설

그대로 제출하면 안 됩니다. u= 뒤의 값은 Base64이고, 풀면 j.smith@corp.example — 우리 직원의 이메일 주소입니다.

위험:

공개 결과에 직원 이메일이 노출됩니다. "이 조직의 이 사람이 피싱 표적"이라는 정보가 공개됩니다.
피싱 페이지는 이 값으로 화면에 이메일을 미리 채워 진짜처럼 보이게 하거나, 누가 클릭했는지 추적합니다. 스캐너가 이 URL을 방문하면 공격자에게는 "j.smith가 링크를 열었다"처럼 보이거나, "조사 중"이라는 신호가 될 수 있습니다.

대응:

먼저 수동적 조회(이미 있는 결과 검색)를 도메인 기준으로 함
내용 확인이 필요하면 파라미터를 지우거나 가짜 값으로 바꾼 URL을 비공개 옵션이나 사내 격리 환경에서 분석
보고서에는 디팽해서 기록: hxxps://login-verify[.]example/start?u=<redacted>
그리고 실제로 j.smith가 링크를 눌렀는지, 로그인 정보를 입력했는지 우리 로그에서 확인