What is the source of thousands of 4625 Logon Failure errors with Logon Type 8 (NetworkCleartext)?

Question

I search a MongoDB collection using the find(...,limit=10000,...) method and I get the 10k documents I requested.

Is there a cheap way to estimate how many documents would have been found without the limit argument?

One obvious method is count_documents, but I suspect it would be prohibitively expensive.

Solution 1

There are multiple login sources that could possibly be generating these errors:

1. FTP logins - check your FTP log to see if login failures are showing up at the same time. This was the source in my case, which took me entirely too long to figure out, and which is why I'm posting this.
2. Logins via Basic Authentication over http or https (simple, but possibly dangerous, way to password-protect a web site)
3. ASP scripts
4. There are likely others of which I'm not aware

Numbers 2 and 3 are mentioned at WindowsSecurity.com:

This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.

Solution 2

The logon type 8 occurs when the password was sent over the network in the clear text. Basic authentication in IIS is most possible cause for this kind of login failure. As for as I know there are five commonly used Microsoft IIS based services with Basic Authentication by end users via either by their Desktop or Mobile device, such are OWA client, MS Exchange ActiveSync, Outlook Anywhere, FTP client and SharePoint server.

When an end-user connect the Basic authentication enabled OWA client from their desktop-pc/mobile device with wrong passwords, the event 4625 with logon type 8 will be logged in Exchange Server which hosts the OWA.

Check this article: http://www.morgantechspace.com/2014/12/Find-Account-Lockout-Source-for-Logon-Type-8.html

Solution 3

I'd run a netstat -a -n | find "1232" to see what ports process ID (PID) 1232 is listening on. That's the PID that's generating these authentication failures. You could sniff traffic incoming on those ports to track down the source.

(I'm having a hard time coming up with services that run in-process w/ svchost.exe and listen for authentication. It almost feels third-party to me...)

Comments

[JohnnyHK]

How about using estimated_document_count instead? It's the next method in the documentation you linked.

[sds]

@JohnnyHK: Thanks. Alas, that method returns the estimated total number of documents, instantaneously, regardless of the filter argument.

[FooBee]

Login type 3 != Logon type 8.