Module 1: Leaked Credential Check - Credential Stuffing¶

In this module, we will Demo Leaked Credentials Check (LCC) to detect ATO attacks and provide a compliance check for NIST guidance with a single login attempt with leaked credentials.

Leaked Credentials Check Overview

Leaked Credential Check (LCC) provides access to a database of compromised credentials, which can be used to detect ATO attacks and provide a compliance check for NIST guidance. LCC is an add-on feature to BIG-IP Advanced WAF which been consumed as a subscription service.

Advantages of F5 Leaked Credential Check (LCC)

• Integrated with F5 Advanced WAF; Can be enabled within minutes.

• LCC policy can be managed and enforced by the application owner.

• Flexible deployment options based on number of users; Not based on number of AWF instances.

• Policy configuration and enforcement can be automated via tmsh CLI and BIG-IP REST API.

Flow trough the Demo

LCC is configured on BIG-IP named BIG-IP 16.1 - All Demos. Login to that BIG-IP instance to check the LCC configuration. The Password of the BIG-IP instance is listed within the Details / Documentation Tab.

1. Within Security › Application Security > Security Policies > Policies List you´ll notice a Security Policy named LCC.

2. The Policy is attached to Virtual Server arcadia.emea.f5se.com_vs and Hackazon_protected_vs.

   

3. Check the LCC configuration under Security › Cloud Services > Cloud Security Services Applications > f5-credential-stuffing-cloud-app.

4. You will notice a predefined API Key ID and API Key Secret configuration. Additional the Endpoint which will be used is called f5-credential-stuffing-blackfish.

   

1. The LCC feature is configured within the Brute-Force Protection profile. Normally a login page is specified for the login credentials to be captured by Advanced WAF. The information required to manually identify the login URL can be found by reviewing the HTML source code and snooping the HTML traffic generated as a user logs into the site (e.g. keyboard F12).

   

1. Leaked Credential Detection is enabled within the Brute Force Protection configuration.

   

2. The following mitigation actions can be configured as an Action:

   

1. Within that demo Learning and Blocking Settings for Leaked Credential Detection have been set to Alarm and Block.

   

2. The Honeypot Page and the Leaked Credentials Page can be configured in the Response and Blocking Pages screen (see screenshot below).

   

3. RDP to windows machine called win-client. The Password of the instance is listed within the Details / Documentation Tab.

   1. Launch Chrome. Spot the Folder called Leaked Credentials Check demo.

   2. Choose the bookmark called Hackazon — Login.

   3. Login with username demo33@fidnet.com and password mountainman01

   4. Your login is blocked by LCC as those credentials are known as leaked credentials.

   5. Alternatively you can also select the Arcadia bookmark in the Leaked Credentials Chrome Folder and you can also try other username/password combinations like usernam admin with password 12345678.

   

4. Go back to to the BIG-IP instance to check in the request log for the blocked request with the Leaked credentials detection violation.

   

Demo Leaked Credentials Check with a Script

1. Remove ASM policy named LCC from Virtual Server Hackazon_protected_virtual on BIG-IP Instance BIG-IP 16.1 - All Demos.

   1. Launch the attack:

   2. SSH or use Web Shell of UDF Instance called kali.

   3. Run sudo su.

   4. Check you are in directory /home/ec2-user, else move to this directory.

   5. Launch the Brute Force stuffing attack (be careful, copy paste does not work every time because of the “”).

   6. hydra -C cred_list.txt -V -I 10.1.10.78 http-form-post "/user/login?return_url=:username=^USER^&password=^PASS^:S=My Account". This is the VS on the BIG-IP named Leaked Credential Check Demo.

   7. Within your Putty or Web Shell Session You should see one line with [80][http-post-form] host: 10.1.10.78   login: demo33@fidnet.com   password: mountainman01. This means attack passed with this credential.

   

   1. Login to Hackazon (demo1/demo1 or with the previous stolen cred), to show it works and that there is no Captcha.

2. Try with a distributed attack. Here we simulate a Bot network sending a Credential Stuffing attack with thousand leaked credentials.

   1. Enable ASM policy LCC on VS Hackazon_protected_virtual.

   2. SSH or use Web Shell of UDF Instance called kali.

   3. Check you are in directory /home/ec2-user, else move to this directory.

   4. Launch the Brute Force stuffing attack (be careful, copy paste does not work every time because of the “”).

   5. hydra -C cred_list.txt -V -I 10.1.10.78 http-form-post "/user/login?return_url=:username=^USER^&password=^PASS^:S=My Account". This is the VS on the BIG-IP named Leaked Credential Check Demo.

   6. Keep attack on going and RDP to windows machine called win-client.

   7. Launch Chrome and click Hackazon login bookmark.

   8. Login as demo1 / demo1, you should see a Captcha. You are a legitimate user, but the website is protecting itself. Proof you are a legitimate user by answering the CAPTCHA.

   9. Go to BIGIP and check Brute Force and cred stuffing logs Security > Event Logs > Application > Brute Force Attack.

   

Additional information

The following cloud related commands could help to identify whether the cloud connection is working.

1. tmsh show security cloud-services application-stats

   

2. tmctl app_cloud_security_service_stat