使用登錄類型 8 (NetworkCleartext) 的數千個 4625 登錄失敗錯誤的根源是什麼？

我有一個 Windows Server 2008 R2 系統，它每天在 Windows 日誌的安全部分顯示數千個 4625 登錄失敗錯誤，登錄類型為 8 (NetworkCleartext)。源網路地址中沒有列出試圖獲得訪問權限的系統的 IP 地址，因此我建構的用於阻止經常失敗的 IP 的腳本無法找到它們。

這些登錄嘗試可能來自哪些服務？

以下是其中一個範例：

An account failed to log on.

Subject:
   Security ID:        SYSTEM
   Account Name:       server-name$
   Account Domain:     example
   Logon ID:       0x3e7

Logon Type:         8

Account For Which Logon Failed:
   Security ID:        NULL SID
   Account Name:       Administrator
   Account Domain:     

Failure Information:
   Failure Reason:     Unknown user name or bad password.
   Status:         0xc000006d
   Sub Status:     0xc0000064

Process Information:
   Caller Process ID:  0x4d0
   Caller Process Name:    C:\Windows\System32\svchost.exe

Network Information:
   Workstation Name:   system-name
   Source Network Address: -
   Source Port:        -

Detailed Authentication Information:
   Logon Process:      Advapi  
   Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
   Transited Services: -
   Package Name (NTLM only):   -
   Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
   - Transited services indicate which intermediate services have participated in this logon request.
   - Package name indicates which sub-protocol was used among the NTLM protocols.
   - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

有多個登錄源可能會產生這些錯誤：

1. FTP 登錄 - 檢查您的 FTP 日誌以查看是否同時出現登錄失敗。這是我的案例的來源，我花了很長時間才弄清楚，這就是我發布這個的原因。
2. 通過 http 或 https 的基本身份驗證登錄（簡單但可能很危險的密碼保護網站的方法）
3. ASP 腳本
4. 可能還有其他我不知道的

WindowsSecurity.com 上提到了數字 2 和 3：

此登錄類型表示類似於登錄類型 3 的網路登錄，但密碼是通過網路以明文形式發送的。Windows 伺服器不允許使用明文身份驗證連接到共享文件或列印機。我知道的唯一情況是使用 ADVAPI 從 ASP 腳本內登錄，或者當使用者使用 IIS 的基本身份驗證模式登錄到 IIS 時。在這兩種情況下，事件描述中的登錄過程都會列出 advapi。基本身份驗證只有在沒有包含在 SSL 會話（即 https）中時才具有危險性。至於由 ASP 生成的登錄，腳本請記住，在原始碼中嵌入密碼對於維護目的是一種不好的做法，並且存在惡意人員查看原始碼並因此獲得密碼的風險。

引用自：https://serverfault.com/questions/570842