재미와 징역형을 부르는 IIS 서버 정찰

3 hours ago 2

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은 IIS shortname 열거 도구로 사용됨
burp’s IIS Tilde Enumeration Scanner도 대안으로 활용할 수 있음
짧은 이름을 전체 파일명으로 바꾸는 방법은 여러 가지임
- LLM: shortname 조각을 포함하는 가능한 파일명 후보를 생성함
- GitHub code search: ~1 앞의 첫 6글자와 확장자를 기준으로 실제 파일명을 검색함
- GSNW: shortname 조각을 받아 GitHub code search에서 매칭 파일명을 수집함
- GitHub-IIS-Shortname-Generator: 유사한 방식으로 단어 목록을 생성함
- shortnameguesser: scanner 출력에서 여러 소스를 질의해 타깃 wordlist를 만듦
BigQuery 방식은 Google BigQuery의 공개 GitHub 데이터셋에서 shortname 패턴과 맞는 파일 경로를 찾음
- SITEBA~1.ZIP라면 sitebackup.zip, sitebase.zip 같은 실제 프로젝트의 파일명 후보를 얻을 수 있음
- 이 방식은 Assetnote의 IIS hidden files 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: 기본 IIS 경로, 일반 핸들러, 레거시 파일을 포함함
- orwa’s iis.txt: 실제 버그 바운티 프로그램에서 사용된 IIS 목록으로 소개됨
- orwa’s aspx.txt: .aspx 엔드포인트 중심 목록임
- wfuzz iis.txt: 알려진 취약 IIS 경로에 초점을 둔 작은 목록임
- dirbuster-ng iis.txt: IIS 특화 약점을 겨냥한 compact 목록임
- Assetnote wordlists: 실제 크롤링 데이터에서 자동 생성되고 매월 갱신되며, ASP와 ASPX 목록을 권장함
- 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은 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가 재조립될 수 있음