イベントID4624（ログオン成功）には「ログオンタイプ（LogonType）」というフィールドがあります。同じ4624でも、コンソールから直接ログインしたのか、ネットワーク経由でファイル共有にアクセスしただけなのかで、意味がまったく変わります。
4624だけでは意味がない、本体はログオンタイプ
イベントID4624のプロパティにはLogonTypeという数値フィールドがあり、この数値が「どうやってログオンしたか」を表します。
LogonType（ログオンタイプ）
イベントID4624・4625に含まれるフィールドで、ログオンの方法を数値で示す。コンソールへの直接ログオンか、ネットワーク経由か、RDP経由かなど、認証の経路によって値が変わる。
この数値と、実際に自分が実行した操作（runas・net use・RDP接続など）を結びつけて覚えておくと、ログを見たときに「これは普段の業務か、それとも見慣れない操作か」を素早く判断できるようになります。
ログオンタイプ一覧——何をすると記録されるか
| タイプ | 名称 | 何をすると記録されるか |
|---|---|---|
| 2 | 対話型（Interactive） | コンソールへの直接ログオン、runas（/netonlyなし） |
| 3 | ネットワーク（Network） | net use、psexec（接続先）、共有フォルダ・プリンタへのアクセス |
| 4 | バッチ（Batch） | スケジュールタスクの実行 |
| 5 | サービス（Service） | Windowsサービスの起動 |
| 7 | ロック解除（Unlock） | 画面ロックの解除 |
| 8 | 平文ネットワーク（NetworkCleartext） | IISの基本認証など、パスワードが平文でネットワークを流れるログオン |
| 9 | 新しい資格情報（NewCredentials） | runas /netonly、別資格情報を使うツール |
| 10 | リモート対話型（RemoteInteractive） | RDP接続 |
| 11 | キャッシュされた対話型（CachedInteractive） | DCに到達できない状態でのキャッシュ資格情報ログオン（オフラインのノートPC等） |
認証パッケージ（NTLM/Kerberos）は別のフィールド
ログオンタイプと合わせてよく見る項目に「認証パッケージ（AuthenticationPackageName）」があります。
この項目には、NTLMとKerberosという2つの実際の認証プロトコルに加えて、「Negotiate」という値が記録されることもあります。
NTLMとKerberosが同列に並ぶ「プロトコル」であるのに対し、Negotiateはその2つのどちらを使うかを選ぶ「仕組み」であり、階層が異なります。
この3つを同列の選択肢として比較しないよう注意してください。
Negotiate（ネゴシエイト）
認証パッケージの一種。NTLM・Kerberosという2つのプロトコルのうち、どちらを使うかを選ぶ仕組み。Kerberosを優先的に使おうとし、使えない条件（SPNが解決できない、KDCに到達できない等）がある場合のみNTLMにフォールバックする。イベントログ上は、最終的に選ばれたプロトコル名（NTLMまたはKerberos）が記録されることもあれば、「Negotiate」自体がそのまま記録されることもある。
ログオンタイプと認証パッケージも、フィールドとしては独立しています。同じログオンタイプでも、状況次第でNTLMになったりKerberosになったりします。
例えばタイプ3（ネットワーク）のログオンは、接続先をIPアドレスで指定した場合はNTLM、ホスト名（FQDN）で指定できた場合はKerberosになりやすい、という傾向があります。IPアドレス指定ではSPN（サービスプリンシパル名）の解決ができずKerberosが成立しないためです。
各ログオンタイプで実務上よく見られる傾向は以下の通りです。あくまで傾向であり、絶対的なルールではない点に注意してください。
| タイプ | 認証パッケージの傾向 |
|---|---|
| 2（対話型） | ドメインに到達できればKerberos、できなければNTLM |
| 3（ネットワーク） | 接続先をIPで指定→NTLMになりやすい／ホスト名で指定→Kerberosになりやすい |
| 5（サービス） | ドメインサービスアカウントであればKerberosになりやすい |
| 9（新しい資格情報） | 送信先次第でNTLM/Kerberosが切り替わる |
| 10（RDP） | 到達できればKerberos、できなければNTLM |
| 11（キャッシュ） | ライブのKerberos/NTLM通信自体が発生しない（ローカルキャッシュとの照合のみ） |
NTLM/Kerberosそれぞれの認証の仕組み自体については「Microsoftの認証プロトコル比較｜Kerberos・NTLM・OAuth・OIDC・SAMLを整理する」で解説しています。
見分ける際に注意したい落とし穴
runasとrunas /netonlyは別のログオンタイプになる
runasだけを実行した場合はタイプ2（対話型）として記録されますが、runas /netonlyを使うとタイプ9（新しい資格情報）として記録されます。
/netonlyは「ローカルでは元のアカウントのまま、ネットワークアクセス時だけ別の資格情報を使う」というオプションで、動作が変わる分ログオンタイプも変わります。攻撃者ツールがこのオプションを好んで使う傾向があるため、タイプ9の発生は一つの手がかりになります。
タイプ8はパスワードが平文で流れたことを意味する
タイプ8（NetworkCleartext）は、認証パッケージの種類にかかわらず、資格情報がネットワーク上を平文に近い形で流れたことを示します。通常のドメイン環境ではあまり発生しないため、発生していたら通信経路・アプリケーションの認証方式を確認する価値があります。
タイプ11は「異常」ではなく「オフライン」のサイン
タイプ11（キャッシュされた対話型）は、攻撃の兆候ではなく、単にそのときDCに到達できなかったことを示します。社外で使うノートPCでは日常的に発生します。ただし、社内ネットワークに接続しているはずの端末でタイプ11が頻発している場合は、名前解決やネットワーク経路に問題がある可能性があります。
大量のログオンイベントから異常を見分ける全体的な考え方については「イベントID4624が大量に記録される原因とは？」も参照してください。
現場で確認しておくべきこと
自分の環境で、サービスアカウントがタイプ2やタイプ10（対話型・RDP）でログオンしていないか確認してください。
サービスアカウントは通常タイプ5（サービス）でログオンするはずです。それ以外のタイプで記録されている場合、誰かがそのアカウントの資格情報を使って手動操作をしている可能性があります。
ADの監査ポリシー全体の設計については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」もあわせてご覧ください。
コメント