# 재미와 징역형을 부르는 IIS 서버 정찰 > Clean Markdown view of GeekNews topic #30615. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30615](https://news.hada.io/topic?id=30615) - GeekNews Markdown: [https://news.hada.io/topic/30615.md](https://news.hada.io/topic/30615.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-19T05:34:58+09:00 - Updated: 2026-06-19T05:34:58+09:00 - Original source: [mll.sh](https://mll.sh/humiliating-iis-servers-for-fun-and-jail-time/) - Points: 1 - Comments: 1 ## Topic Body - IIS 기본 화면은 막다른 길이 아니라 **버그 바운티 정찰의 출발점**이며, Shodan·Google dork·응답 헤더로 노출 서버와 숨은 vhost를 좁혀갈 수 있음 - HTTP/1.0 요청, `HTTPAPI 2.0 404`, SSL 인증서, `Host` 헤더 브루트포싱은 **내부 IP·Exchange 호스트명·가상 호스트**를 찾는 초기 단서가 됨 - IIS의 DOS 8.3 기반 **tilde shortname enumeration**은 디렉터리 리스팅이 꺼져 있어도 짧은 파일·디렉터리 이름을 드러낼 수 있고, GitHub 검색·BigQuery·LLM·crunch로 전체 이름 후보를 추정함 - IIS/.NET 특화 퍼징은 `web.config`, `trace.axd`, `elmah.axd`, `appsettings.*.json`, `.aspx/.ashx/.asmx/.config` 같은 **고가치 경로와 확장자**를 먼저 겨냥함 - `web.config` 노출, cookieless session 경로 정규화, reverse proxy path confusion, NTFS alternate data stream, 업로드 확장자 우회, HPP는 **설정 오류와 레거시 동작**이 공격면으로 이어질 수 있음을 보여줌 --- ### IIS 서버를 찾아내는 정찰 방법 - IIS 대상은 검색 엔진과 인터넷 자산 검색 서비스에서 먼저 찾을 수 있음 - **Shodan** 쿼리는 대상 도메인의 SSL 인증서, 조직명, `http.title:"IIS"` 조합으로 IIS 서버를 좁히는 방식임 - 예시 대상에는 staging 서버, 잊힌 관리자 패널, 인터넷에 노출된 내부 도구가 포함됨 - Shodan 외에 fofa, censys, netlas, odin도 서로 다른 인터넷 인덱스를 제공함 - **Google dorking**은 IIS 흔적이 인덱싱된 페이지를 찾는 데 쓰임 - `aspnet_client` 폴더와 `_vti_bin`은 IIS 신호로 다뤄짐 - `ext:aspx`는 ASP.NET 페이지를 찾고, 그 아래에 IIS가 있음을 암시함 - `site:*.target.com`, `site:*.*.target.com` 형태의 와일드카드 검색은 기본 서브도메인 열거가 놓친 중첩 서브도메인을 찾는 데 쓰임 - **응답 헤더**는 IIS 식별의 가장 쉬운 단서임 - `Server: Microsoft-IIS/10.0` - `X-Powered-By: ASP.NET` - 대규모 확인에는 `httpx`나 `nuclei`로 IIS 대상 목록을 만들 수 있음 ### IIS 확인 뒤 얻는 초기 단서 - 일부 IIS 구성, 특히 **Exchange 또는 OWA 프런트**는 HTTP/1.0 요청에 내부 정보를 노출할 수 있음 - `Location` 헤더에 `https://192.168.5.237/owa/` 같은 **내부 IP**가 담길 수 있음 - `X-FEServer` 헤더는 Exchange 서버의 내부 호스트명을 드러낼 수 있음 - 이런 정보는 이후 단계에서 활용 가능한 **정보 노출**로 이어짐 ### 자동화와 숨은 가상 호스트 찾기 - IIS 대상 목록을 확보한 뒤 `nuclei`를 `microsoft`, `windows`, `asp`, `aspx`, `iis`, `azure`, `config`, `exposure` 같은 태그로 실행해 반복 작업을 줄일 수 있음 - `HTTPAPI 2.0 404`는 실제로 아무것도 없다는 뜻이 아닐 수 있음 - IIS 인스턴스가 특정 **가상 호스트**에 바인딩돼 있고, 요청의 `Host` 헤더가 맞지 않아 404가 나올 수 있음 - 숨은 vhost를 찾는 방식은 두 가지임 - SSL 인증서의 subject 또는 SAN 필드에서 필요한 호스트명을 찾음 - 인증서가 도움이 되지 않으면 `ffuf`와 `Host` 헤더 wordlist로 vhost를 브루트포싱함 - 맞는 호스트명을 찾으면 일반 404 대신 실제 애플리케이션이 응답할 수 있음 ### IIS tilde shortname enumeration - IIS는 오래된 DOS **8.3 파일명 규칙**에서 이어진 동작 때문에 특수 요청으로 파일과 디렉터리의 짧은 이름을 열거할 수 있음 - 디렉터리 리스팅이 비활성화돼 있어도 `WEB~1.CON`, `GLOBAL~1.ASA`, `SITEBA~1.ZIP`, `ADMIN~1` 같은 조각이 드러날 수 있음 - [shortscan](https://github.com/bitquark/shortscan)은 IIS shortname 열거 도구로 사용됨 - [burp’s IIS Tilde Enumeration Scanner](https://portswigger.net/bappstore/523ae48da61745aaa520ef689e75033b)도 대안으로 활용할 수 있음 - 짧은 이름을 전체 파일명으로 바꾸는 방법은 여러 가지임 - **LLM**: shortname 조각을 포함하는 가능한 파일명 후보를 생성함 - **GitHub code search**: `~1` 앞의 첫 6글자와 확장자를 기준으로 실제 파일명을 검색함 - [GSNW](https://github.com/retkoussa/gsnw): shortname 조각을 받아 GitHub code search에서 매칭 파일명을 수집함 - [GitHub-IIS-Shortname-Generator](https://github.com/m0rd3caii/GitHub-IIS-Shortname-Generator): 유사한 방식으로 단어 목록을 생성함 - [shortnameguesser](https://github.com/projectmonke/shortnameguesser): scanner 출력에서 여러 소스를 질의해 타깃 wordlist를 만듦 - **BigQuery** 방식은 Google BigQuery의 공개 GitHub 데이터셋에서 shortname 패턴과 맞는 파일 경로를 찾음 - `SITEBA~1.ZIP`라면 `sitebackup.zip`, `sitebase.zip` 같은 실제 프로젝트의 파일명 후보를 얻을 수 있음 - 이 방식은 [Assetnote의 IIS hidden files BigQuery 연구](https://www.assetnote.io/resources/research/finding-hidden-files-and-folders-on-iis-using-bigquery)에서 영감을 받은 기법임 - LLM, GitHub, BigQuery가 실패하면 **crunch**로 남은 문자열 조합 wordlist를 만들고 `ffuf`로 시도함 - 하이픈, 언더스코어, URL 인코딩된 공백, 구분자 없음 같은 파일명 변형을 함께 확인함 - Windows는 파일명 공백을 허용하고 IIS도 이를 제공할 수 있음 ### IIS/.NET 특화 퍼징 - 일반 wordlist만으로는 IIS/.NET 생태계의 고유 파일과 엔드포인트를 놓칠 수 있음 - 우선 확인할 **고가치 대상**에는 다음이 포함됨 - `/web.config`, `/web.config.bak`, `/web.config.old`, `/web.config.txt` - `/global.asax` - `/trace.axd` - `/elmah.axd` - `/connectionstrings.config` - `/appsettings.json`, `/appsettings.Development.json`, `/appsettings.Staging.json`, `/appsettings.Production.json`, `/appsettings.Local.json` - `/secrets.json` - `/WS_FTP.LOG` - `/_vti_pvt/service.cnf` - `trace.axd`는 ASP.NET trace viewer이며, 활성화돼 있으면 헤더·쿠키·때로는 자격 증명을 포함한 요청/응답 로그가 노출될 수 있음 - `elmah.axd`는 개발자가 끄지 않은 **디버그 엔드포인트**로 남아 오류 로그를 보여줄 수 있음 - IIS 특화 확장자 퍼징 대상에는 `.asp`, `.aspx`, `.ashx`, `.asmx`, `.wsdl`, `.wadl`, `.config`, `.xml`, `.zip`, `.txt`, `.dll`, `.json`이 포함됨 - 활용할 만한 wordlist는 다음과 같음 - [secLists IIS.txt](https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/IIS.txt): 기본 IIS 경로, 일반 핸들러, 레거시 파일을 포함함 - [orwa’s iis.txt](https://github.com/orwagodfather/WordList/blob/main/iis.txt): 실제 버그 바운티 프로그램에서 사용된 IIS 목록으로 소개됨 - [orwa’s aspx.txt](https://github.com/orwagodfather/WordList/blob/main/aspx.txt): `.aspx` 엔드포인트 중심 목록임 - [wfuzz iis.txt](https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt): 알려진 취약 IIS 경로에 초점을 둔 작은 목록임 - [dirbuster-ng iis.txt](https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt): IIS 특화 약점을 겨냥한 compact 목록임 - [Assetnote wordlists](https://wordlists.assetnote.io/): 실제 크롤링 데이터에서 자동 생성되고 매월 갱신되며, ASP와 ASPX 목록을 권장함 - [OneListForAll](https://github.com/six2dez/OneListForAll): `onelistforallshort.txt`는 타깃 실행에, 전체 목록은 장시간 실행에 쓰임 - IIS는 **대소문자를 구분하지 않으므로** mixed-case wordlist는 중복 요청을 만들 수 있음 - lower-case 목록을 쓰거나 `tr '[:upper:]' '[:lower:]' | sort -u`로 정규화하는 방식이 쓰임 ### web.config와 코드 노출 - `web.config`를 path traversal, 잘못 노출된 백업 파일, shortname 기반 발견으로 읽을 수 있으면 IIS 대상에서 영향이 커질 수 있음 - IIS `web.config`에는 ViewState 서명과 암호화에 쓰이는 **machine keys**가 들어 있을 수 있음 - machine keys가 있으면 악성 직렬화 ViewState payload를 위조해 deserialization 기반 **원격 코드 실행**으로 이어질 수 있음 - [ysoserial.net](https://github.com/pwntester/ysoserial.net)은 key가 있을 때 payload 생성을 돕는 도구임 - 파일 다운로드나 파일 읽기 파라미터가 있으면 `../../web.config` 및 URL 인코딩 변형을 시도하는 흐름으로 이어짐 - ASP.NET의 레거시 **cookieless session** 기능은 `(S(X))` 형태의 세션 토큰을 URL 경로에 넣을 수 있음 - IIS가 해당 세그먼트를 경로 정규화 중 제거하면서 `/bin` 디렉터리 접근 차단을 우회할 수 있음 - `Newtonsoft.Json.dll` 자체는 기본 라이브러리라 애플리케이션 비밀을 담지 않을 수 있음 - 실제 애플리케이션 DLL을 받으면 dotPeek이나 dnSpy로 디컴파일해 하드코딩된 자격 증명, API 키, 내부 엔드포인트 로직, 커스텀 인증 구현을 볼 수 있음 ### 경로 정규화, NTFS, 업로드, WAF 우회 - IIS가 reverse proxy 뒤에 있거나 reverse proxy 역할을 할 때 **경로 정규화 차이**가 접근 제어 우회로 이어질 수 있음 - proxy는 인코딩된 경로를 다른 리소스로 보고 전달하지만, IIS는 `%2f`를 `/`로 디코딩하고 traversal을 해석해 보호 경로를 제공할 수 있음 - IIS 7.5와 유사 버전은 NTFS **alternate data streams**와 index allocation 동작으로 basic authentication 우회가 가능할 수 있음 - 인증 모듈은 보호 경로로 인식하지 못하지만 파일 시스템은 실제 디렉터리로 해석할 수 있음 - 파일 업로드 기능에서는 `.aspx`, `.asp`가 차단돼도 IIS가 기본적으로 HTML로 제공하는 확장자를 통해 stored XSS가 가능할 수 있음 - HTML 렌더링 확장자 예: `.cer`, `.hxt`, `.htm` - XML 기반 XSS 벡터 확장자 예: `.dtd`, `.mno`, `.vml`, `.xsl`, `.xht`, `.svg`, `.xml`, `.xsd`, `.xsf`, `.svgz`, `.xslt`, `.wsdl`, `.xhtml` - IIS는 파일명 끝의 점을 제거하는 동작이 있어 `shell.aspx.`, `shell.aspx..`, `shell.aspx...` 같은 업로드 필터 우회가 가능할 수 있음 - server-side includes 대상으로 `.stm`, `.shtm`, `.shtml` 확장자가 제시됨 - WAF가 payload를 막을 때 **HTTP Parameter Pollution**으로 중복 파라미터에 payload를 나눠 담을 수 있음 - IIS와 ASP.NET은 기본적으로 중복 파라미터 값을 쉼표로 연결하며, WAF 뒤에서 payload가 재조립될 수 있음 ### IIS 버그 바운티에서 남는 교훈과 자료 - IIS의 버그 바운티 공격면은 넓지만 충분히 테스트되지 않는 경우가 많음 - 노출된 Windows/IIS 서버는 내부 IP, 설정 파일, shortname enumeration 같은 형태로 정보를 흘릴 수 있음 - IIS 기본 화면에서 멈추지 않고 더 깊게 정찰하는 것이 실무적으로 중요함 - 참고 자료 - [NahamCon2021 - Hacking IIS](https://youtu.be/cqM-MdPkaWo) - [THE POWER OF RECON by Orwa Atyat](https://youtu.be/yyD8Z5Qar5I) - [Hacking IIS](https://docs.google.com/presentation/d/1AA0gX2-SI_9ErTkBhtW0b-5BH70-1B1X) - [IIS Internet Information Services](https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/iis-internet-information-services) - [Extensions Overview](https://mike-n1.github.io/ExtensionsOverview) - [IIS Shortname Discovery](https://x.com/infosec_au/status/1340785029899698181) - [Assetnote’s BigQuery research for resolving IIS shortnames](https://www.assetnote.io/resources/research/finding-hidden-files-and-folders-on-iis-using-bigquery) ## Comments ### Comment 59900 - Author: neo - Created: 2026-06-19T05:34:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48563394) - 모든 **허니팟** 앞에 IIS 랜딩 페이지를 세워두는 이유가 바로 블랙햇들을 끌어들이기 때문임 그들이 자기 꼬리를 쫓느라 몇 시간을 낭비했다고 생각하면 그렇게 기쁠 수가 없음 - 거기서 멈출 게 아니라 진짜 **IIS 서버**를 앞단에 두고, 허니팟을 마트료시카처럼 겹겹이 만들어서 어디까지 들어오는지 보면 재미있겠음 - 기존 조직의 IP 대역에서 허니팟을 돌리는 게 아니라면 결국 받는 건 **봇 트래픽**뿐임 상위권 블랙햇은 큰 표적을 노리고, 하위권은 Shodan에서 찾은 쉬운 먹잇감이나 자신들이 찾은 애플리케이션 제로데이에 집중함 - **노이즈**는 정말 과소평가된 보안 계층임 - Plex와 Nintendo Switch 포트를 열었더니 스캔이 미친 듯이 들어왔음 포트 스캐너들을 엿먹일 방법이 있으면 더 알고 싶음 - `aspnet_client/admin.php` 같은 URL을 만들고 **WebObjects 헤더**를 반환하게 해두는 것도 좋은 취미가 될 듯함 - “IIS가 오래된 DOS 8.3 파일명 규칙에서 물려받은 레거시 동작을 갖고 있다”는 말은, IIS 문서 루트가 기본적으로 `C:\Inetpub`인 점과 결합해 **기저 운영체제 동작**이 노출된다는 뜻인지 궁금함 Windows 10/11에서는 8.3 파일명이 C 드라이브에서는 기본 활성화지만 다른 드라이브에서는 기본 비활성화임 `PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion` → `24H2` `fsutil 8dot3name query C:`는 `8dot3 name creation is ENABLED`, `fsutil 8dot3name query U:`는 `DISABLED`로 나옴 - 곁가지지만, Windows 업데이트가 “보호 강화”라는 불명확한 이유로 서버가 아닌 모든 PC에 **`c:\inetpub`** 를 만들었던 일이 떠오름 [https://www.pcworld.com/article/2684062/why-is-windows-11-la...]() - 이 내용의 원래 연구는 여기 있음: [https://soroush.me/downloadable/microsoft_iis_tilde_characte...]() - Windows 10 장비에서는 `DisplayVersion` 명령에 응답이 없었고, 구버전 예컨대 **LTSC**에서는 아래처럼 `ReleaseId`를 써야 하는 듯함 `(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId` → `1809` - 글의 **문체**가 꽤 특이함 - 몇 번이나 Claude가 쓴 건가 싶었음 - 와, 이건 옛날 생각이 확 남 한때는 IIS 스캐너가 너무 많아서 서버 로그가 사실상 못 쓸 수준이었음 `../`를 URL 인코딩하기만 하면 되는 **디렉터리 순회 취약점**이 있었고, 몇 달 동안 인터넷 전체를 불태웠음 - 그런 순회 시도는 지금도 PHP/WordPress 스크립트 키디 공격과 나란히 정말 흔하게 보임 - 아직도 **IIS**를 쓰는 곳이 있나? - 씀. Windows Server와 IIS를 쓰면 도메인에 가입된 머신이고, 보통 `HOST/MACHINE.DOMAIN` 형태의 SPN이 있음 Windows 서비스와 IIS App Pool Identity는 (g)MSA나 가상 계정(`NT Service*`)으로 로그인하므로, 30/60/90일 비밀번호 교체를 직접 다루지 않고도 관리되는 **Kerberos** 환경이 제대로 돌아감 MS SQL Server에 Kerberos로 로그인하고, 다른 웹앱의 OAuth2 흐름에도 Kerberos로 로그인하는 식으로 전부 자연스럽게 작동함 기본 Windows 셸에서 WinRM도 별다른 설정 없이 쓸 수 있고, 기술적으로는 2FA도 우회할 수 있는데 실제로 그런 식으로 동작하기 때문임 Linux에서도 가능하냐면 가능하지만, 제대로 설정될 가능성은 근무 환경에 따라 다르고 지금까지의 경험상 높지 않았음 - 기업 IT 부서에서는 아직 **너무 많이** 씀 - Windows Server에서 IIS를 계속 돌리는 사람들과 자주 이야기함 오래된 앱이 정말 많고, 그중에는 매우 중요한 것도 꽤 있음 - 일부 은행은 아직 IIS를 씀 인트라넷을 운영할 만큼 큰 대기업이라면 어딘가에는, 어쩌면 전부에 **IIS**가 돌아가고 있음 AD와 잘 통합돼서 아주 복잡한 작업도 말도 안 되게 단순해짐 세상이 AWS로 옮겨가며 사용량은 줄고 있지만, 그것도 다시 한 벤더의 독점 제품(Amazon)에 묶이는 일이라 똑같이 어리석음. 이번에는 하드웨어도 소유하지 않는다는 차이만 있음 공공 부문 IT는 IIS를 좋아함. 지방자치단체 세금이나 부동산 웹사이트를 보면 `.aspx` 스크립트가 잔뜩 있을 가능성이 큼 유럽 공공 부문 웹앱에서도 봤고, SQL Server 백엔드를 둔 맞춤형 .NET 애플리케이션이 지방정부 전체를 굴리는 경우가 많음 아시아, 특히 중국과 대만은 IIS를 좋아해서 온갖 것을 호스팅하는 데 쓰는 것처럼 보였음 세상이 대체로 넘어간 건 맞지만, 도시와 중요한 조직을 굴리는 **레거시 코드**가 IIS 위에 엄청나게 남아 있고 바뀌지 않을 것임 그게 나쁘다고 생각한다면, 아직도 웹에서 AS/400, Lotus Notes, Novell GroupWise를 돌리는 곳도 있음 - 맞음. 그리고 잘 모르는 입장에서 묻자면, 요즘은 뭘 써야 하는 건가? 작은 회사가 기업용 .NET Framework 코드를 만들고, Windows가 전부이며, 고객이 클라우드를 받아들이지 않고, SOAP가 여전히 주류이고, 유일한 IT 담당자는 2010년 이후 무슨 일이 있었는지 신경 쓸 겨를도 없는 상황을 생각해보면 됨 전체 재작성은 현실적으로 불가능하고, 보안상 이득은 얻고 싶지만 설정을 깊게 파볼 여력도 없고 Kubernetes 같은 복잡한 것에 베팅할 수도 없음 - nginx에 대해서도 이런 **분석 글**을 보고 싶음 - 전체 데스크톱 브라우저 기준으로는 **디자인**이 정말 잘 되어 있고, 내용도 훌륭함 - 비꼬는 건지 모르겠지만, 내 데스크톱 브라우저에서는 사이드바가 본문 패널과 겹쳐서 텍스트 위에 텍스트가 올라감 그래도 그 외의 프레젠테이션은 마음에 듦 - “훌륭하다”는 말은 2000년대 초반 **스크립트 키디** 수준의 내용에는 좀 후한 평가임 작성자는 문명이 별 이유 없이 서로에게 못되게 굴지 않는 사람들에 얼마나 의존하는지 아직 배워야 할 듯함 - 왼쪽 **사이드바**가 본문 텍스트와 겹치는 건 무슨 일인지 모르겠음