마이크로소프트의 웹 서버 IIS(Internet Information Services)는 전 세계적으로 널리 사용되지만, 그만큼 공격자들의 주요 표적이 되기도 합니다. 많은 사람들이 IIS의 기본 화면을 마주하면 더 이상 정보를 얻을 수 없다고 생각하기 쉽지만, 실제로는 이곳이 버그 바운티(Bug Bounty) 프로그램에서 잠재적 취약점을 찾아내기 위한 정찰(reconnaissance)의 중요한 시작점입니다. 공격자들은 쇼단(Shodan), 구글 도크(Google dork)와 같은 인터넷 자산 검색 서비스와 서버 응답 헤더 분석을 통해 숨겨진 가상 호스트(vhost)나 내부 네트워크 정보를 파악하며 공격 대상을 좁혀나갑니다.
IIS 서버를 정찰하는 초기 단계에서는 쇼단 쿼리, 구글 도킹, 응답 헤더 분석이 주로 활용됩니다. 예를 들어, 쇼단에서는 SSL 인증서 정보나 HTTP 타이틀을 조합해 IIS 서버를 식별하고, 구글 도킹은 `aspnet_client` 폴더나 `.aspx` 확장자를 통해 IIS 흔적이 있는 페이지를 찾아냅니다. 또한, 서버 응답 헤더의 `Server: Microsoft-IIS/10.0` 같은 정보는 가장 쉽고 확실한 IIS 식별 단서가 됩니다. 이렇게 초기 단서를 확보한 후에는 HTTP/1.0 요청을 통해 내부 IP 주소나 익스체인지(Exchange) 서버의 호스트명 같은 민감한 정보가 노출될 수 있습니다. 특히 SSL 인증서의 `subject`나 `SAN` 필드, 또는 호스트 헤더 브루트포싱(brute-forcing)을 통해 숨겨진 가상 호스트를 찾아내는 기법은 실제 애플리케이션의 취약점을 발견하는 데 결정적인 역할을 합니다.
IIS의 오래된 DOS 8.3 파일명 규칙에서 파생된 틸드 숏네임 열거(tilde shortname enumeration)는 디렉터리 리스팅이 비활성화되어 있어도 짧은 파일이나 디렉터리 이름을 노출시킬 수 있습니다. `WEB~1.CON` 같은 형태로 드러난 짧은 이름은 LLM(대규모 언어 모델), 깃허브(GitHub) 코드 검색, 구글 빅쿼리(BigQuery) 등을 활용해 실제 파일명 후보를 추정할 수 있습니다. 또한, `web.config`, `trace.axd`, `elmah.axd`와 같은 IIS/.NET 생태계의 고유한 파일이나 엔드포인트를 대상으로 하는 특화된 퍼징(fuzzing)은 설정 오류나 레거시 동작으로 인한 취약점을 발견하는 데 효과적입니다. 이러한 정보 노출은 `machine keys`를 통한 원격 코드 실행(RCE)이나 경로 정규화(path normalization) 우회, 파일 업로드 취약점 등으로 이어질 수 있어, 공격자에게는 매우 매력적인 공격면이 됩니다. 따라서 IIS 서버 관리자는 이러한 정찰 및 공격 기법을 이해하고 선제적으로 보안을 강화해야 합니다.