How to Protect Your Customers and Your Brand from Stolen Credential Misuse

During 2020 a number of Online Retailers have made headline news due to the media erroneously reporting that their customer Portals had been breached. These include Tesco Clubcard Members (https://www.techradar.com/uk/news/tesco-clubcard-holders-warned-of-major-security-issue) and most recently, Wiggle (https://cyclingindustry.news/security-breach-reported-on-wiggles-customer-accounts).

In both these instances there was no exploitation of a cyber vulnerability. Threat Actors in all likelihood gained access to these Portals Accounts using a database of credentials stolen from other platforms or possibly via a Spear Phishing campaign. 

 

The obvious questions here are:

  • How was this possible? and
  • How can this be prevented in the future?

I prefer a shared responsibility model so let’s answer the above questions with this in mind:

 

How was this possible?

Many subscribers have the same username (email address) and password for all online portals and web applications. Therefore, if one Portal account is compromised, e.g. Marriot-Sheraton or Carphone Warehouse, there’s a good possibility that these credentials will work on other sites. It is good practice to use a different password for each online Portal account, which can be challenging without the use of a password manager, the use and choice of which is the subject of many existing Blog articles which can be found with a quick search.

 

How can this be prevented in the future?

Online Retailers also have responsibility in this regard so let’s now look at “How can this can be prevented in the future”. There are a number of actions that retailers can take depending on what they are wanting to do with customer details. For example, Online Retailers require no details from a customer to transact. All the information required for transacting including delivery address can be provide by PayPal, or similar services.  Making use of payment gateways, like PayPal, also negates Man-in-the-Middle attacks whereby a threat actor intercepts and makes use of card details entered at the time of the transactions as per the British Airways 3rd party data breach. The above isn’t going to be suitable for loyalty card Portals as customer details are required.

 

However, Online Retailers that provide the option of simple Two Factor Authentication (2FA) are few and far between, Amazon being one of them.  PayPal also has the option of turning on 2FA and without it, PayPal remains nearly as susceptible to the use of Breached or Phished Credentials as any other Online Portal. While 2FA is fallible it is far superior than not making use of it at all as demonstrated by this Google 2FA survey https://thenextweb.com/google/2019/05/23/google-data-shows-2-factor-authentication-blocks-100-of-automated-bot-hacks/. A full account of 2FA is available here: https://authy.com/what-is-2fa/.

 

Simple 2FA can be provided with a Smart Phone App such as Authy or Google Authenticator. I prefer Authy, as you are able to restore all of your 2FA codes if you lose your Phone whereas Google Authenticator requires you to make use of Backup Codes. For Online Retailers or Organisations that have loyalty programmes and want your personal details, they should as a minimum when getting you to sign up offer up a QR code to enable 2FA. Adding this type of 2FA to their Portal is a very simple exercise: https://www.twilio.com/authy/api

In addition to the above, organisations with online portals who wish to stop threat actors making use of fraudulent domains to send Phishing emails to customers/suppliers in order to obtain credentials to gain access to their Portal should take the following steps:

 

1 Add the following to you DNS:

  • SPF: A Sender Policy Framework (SPF) record is a type of Domain Name Service (DNS) TXT record that identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to detect and prevent spammers from sending messages with forged From: addresses on your domain.
  • DKIM: A DKIM Record Check. DKIM (DomainKeys Identified Mail) is an email authentication technique that allows the receiver to check that an email was indeed sent and authorized by the owner of that domain.
  • DMARC: A DMARC record is the core of a DMARC implementation in which the DMARC record rulesets are defined. This DMARC record informs email receivers if a domain is set up for DMARC. If so, the DMARC record contains the policy which the domain owner wants to use. In essence, a DMARC record is a DNS (Domain Name Service) entry.
  • DNSSEC: DNSSEC increases security by adding cryptographic signatures to DNS records; these signatures can be checked to verify that a record came from the correct DNS server.

 

 

2 Add 2FA/MFA

 

As mentioned earlier in this Blog, requiring Customers / Suppliers to make use of 2FA when logging into the Portal using an App like Authy which can either provide a 6-digit 2FA code or can be used to accept a Login Notification Request which will then deter Threat Actors from registering Fraudulent Domains to act as though they are from a facsimile of an organisation’s domain as standard username and password credentials don’t work on the Portal. Threat Actors first check that there is a use for harvested credentials before creating Fraudulent Domains to go Spear Phishing.

 

 

3 Monitor Fraudulent Domains and Implement Take Downs

 

Fraudulent domains are created for mainly two reasons:

  1. To Phish credentials from your clients as they believe that they have value, e.g. logging into a loyalty program portal;
  2. Setup a fake online retail portal that sells counterfeit goods.

To be truly effective and to properly verify that this is a Fraudulent Domain, phishing credentials, you need some human intervention, who will perform the following steps:

  • Verify the domain is Fraudulent as soon as it is registered and is brought to his attention via an algorithm;
  • Verify that a domain has a Web Portal which is a facsimile of the original;
  • Verify that the domain has registered mx records and is attempting to send email;
  • Alert customer;
  • Take down the fraudulent domain.

More information on the Different Kinds of Impersonating: Phishing and Domain Squatting can be found in the following SOCRadar Blog Article: https://socradar.io/different-kinds-of-impersonating-phishing-and-domain-squatting/

 

SOCRadar also provide a full Fraudulent Domain Monitoring and Take Down Service: https://socradar.io/solutions/phishing-domain-detection/