BFGuard – Day 2


In this post we actually start BFGuard and try to connect to the host from other workstations.


Target OS

Here are the Windows OS that we will use for this exercise:

  1. Server
    • Windows Server 2012 R2
  2. Client
    • Windows Server 2012 R2
    • Windows 7

What we saw

BF Guard

BF Guard – Application

Scenario – After 1 failed Login

BF Guard – Application – Statistics

  1. ip
    • Count :- 1
    • Date :- 2016-06-15 15:34:13
      • Time in GMT, not local time


Scenario – After Numerous failed Logins

BF Guard – Application – Statistics

  1. ip
    • Count :- 7
    • Date :- 2016-06-15 16:47:18
      • Time in GMT, not local time


BF Guard – Application – Log entrys

  1. @ 2017-06-15 09:47:39
    • – Auto blocking IP: for: 54864000 minutes


BF Guard – Application – Blocked IP

  1. IP Address
    • IP Address :-
    • From :- 2017-06-15 09:47:39
    • To      :- 2017-06-15 10:47:39
    • City    :- Blocked


OS – Windows

Windows Logs

Windows Logs – Security

Windows Logs – Security – Filter

Here we filter for “Audit Failure“.

Windows Logs – Security – Logs

And, here are the events captured.


Windows Logs – Security – Log – Detailed

Windows Logs – Security – Log – Detailed- Event ID = 4625


  1. Subject
    • Security SID :- NULL SID
      • Since account that we entered to login in under is not known to the targeted computer or Active Directory, we get “NULL SID
    • Logon ID :-  0x0
      • Again, unknown Logon ID
  2. Logon Type
    • Our Logon Type is 3
      • Logon Type = 3
        • Network
  3. Account for which Logon Failed
    • Security SID :- NULL SID
    • Account Name :- bobsmith
    • Account Domain :- LAB
  4. Failure Information
    • Failure Reason :- unknown username or password
    • Status :- 0xC00006D
    • Sub Status :- 0xC0000064
  5. Process Information
    • Caller Process ID :- 0x0
      • Remote Caller Process is not known
    • Caller Process Name :-
      • Remote Caller Process is not known
  6. Network Information
    • Workstation Name :- ASTSQL01
    • Source Network Address :-
      • Network Address not passed in
    • Source Port :-
      • Network Port not passed in
  7. Detailed Authentication Information
    • Logon Process :- NtlmSsp
    • Authentication Package :- NTLM
  8.  Summary
    • Log Name :- Security
    • Source :- Microsoft Windows security
    • Event ID:- 4625
    • Task Category :- Logon
    • Keywords :- Audit Failure
    • Computer :- Host attempted for logon


OS – Windows Firewall

Reviewed server’s Windows Firewall to see how it is configured for “Remote Desktop“.



  1. Remote Desktop configured as:
    • Domain :- Yes
    • Home/Work :- Yes
    • Public :- No
    • Group Policy – Yes



Unfortunately, Windows was not able to capture the incoming IP Address.

BF Guard was thus unable to read the IP Address from the Windows Logs.

Because of this inability, it is not able to re-configure the local Windows Firewall and have it start blocking the Source IP Address.


MS Windows Telnet Client Not able to connect to Telnet Server


On a MS Windows 2012 box, added Microsoft’s Telnet Service.

But unable to connect using Microsoft’s own Telnet Client.


Error Message

The error message is displayed below.




Access Denied: Specified user is not a member of TelnetClients group.
Server administrator must add this user to the above group.

Telnet Server has closed the connection

Connection to host lost.

Corrective Action

Add accounts to Local TelnetClients Group

Command Line


net localgroup TelnetClients [ADAccount] /add


net localgroup TelnetClients LABDOMAIN\dadeniji /add


Review Local Group

Computer Management



Command Line


Telnet Client – Error

Again when trying to connect using MS Telnet as in…

telnet localhost

not prompted for username/password, as application relies on the current user’s context.



Already have Putty from

And, so launched it and used that instead.



Putty Session

Working Putty Session…


Microsoft – Telnet – Turn Off NTLM

By default the Microsoft Telnet Client Utility uses NTLM.  Somehow it is not working for us.

BTW, again, NTLM again passes the current user’s security context.

To discourage that auto-authentication, we can disable NTLM and force the server to request explicit user credentials ( username & password).

Here are the steps:

  1. Start Telnet Session
  2. Disable NTLM
  3. Review NTLM
  4. Connect to Telnet Server

Start Telnet Session



Unset NTLM

Disable NTLM for the current session.

unset NTLM


Review NTLM




connect telnet-server


Authenticate by entering username & password



Thankfully, we connected.



Again once we added our AD Account to the Local TelnetClients group and opted for a Telnet client that allows us to specify user credentials we are good.

On our first successful connection, we used Putty.

On our second success, we went back and used MS Telnet, but disabled NTLM and opted to enter explicit user credentials.


Later Work

It is possible that we are having problems with NTLM because Microsoft has been playing down NTLM for a while now.

It is being replaced with Kerberos, because NTLM is susceptible to replay attempts.



  1. Grant Access to a Telnet Server
  2. Error Message: Access Denied – Specified user is not a member of the TelnetClients group
  3. Telnet Client Command Reference