Salesforce Integration Risks: Detecting Evil Twin Backdoor Threats in Your Environments

Post-image

Detecting, mitigating and preventing backdoors in Salesforce environments.

Backdoors in the SaaS Era

In the cybersecurity world, old threats often reemerge in new forms, adapted to modern technologies. Traditionally, attackers installed backdoors on servers and laptops to maintain access even after defenders cleaned or reinstalled parts of the infrastructure. In the SaaS era, attackers are adapting these techniques to modern environments, increasingly using common SaaS services for their backdoors and command & control infrastructure. This approach allows them to leverage the benefits of SaaS, bypass many security controls, and operate with greater stealth.

A prime example is the Scattered Spider gang, known for using legitimate cloud syncing tools like Airbyte and Fivetran to exfiltrate victim data. Salesforce is one of their targets, with data being stolen using these techniques.

The Challenge of Evil Twin Integrations

Attackers can make their backdoors and activities harder to detect by using SaaS accounts that are already in use within the environment. This complicates log analysis and anomaly detection. Luke Jennings of Push Security has highlighted how Evil Twin attacks can make attackers' connections nearly invisible in today’s SaaS-based enterprises.

Are Evil Twin integrations a potential risk to the Salesforce landscape? How invisible are these integrations that use known services but connect to the attacker’s account instead of an account owned by the victim or one of its business partners?

Creating a Doppelgänger Integration in Salesforce

To demonstrate how an Evil Twin can be discovered on Salesforce, I connected a Coefficient account to a test org in Salesforce. Coefficient is a great service to use when connecting Google Sheets with Salesforce data. I then repeated the process with a different Coefficient account, downloading some account data each time.

Each OAuth app has a “Client ID” and “Client Secret” as defined in the OAuth 2.0 standard. Salesforce refers to OAuth apps as “Connected Apps” and the Client ID and Secret as “Consumer Key” and “Consumer Secret”. Typically, OAuth Apps can be identified by the unique Client ID they have. However, Salesforce considers the Consumer Key a secret, visible only to the app creator.

Image


In Salesforce, it’s possible to set up a Connected App in any Org you have admin access to and name it whatever you like. You can also give it whatever icon you want. The Consumer Key and Secret are stored and can be viewed in the setup. The application name is visible in the login history. This means a connected app can appear almost identical in logs, providing a level of invisibility. I created a connected app that was just named “Coefficient” in an unrelated Salesforce Org and used it to connect to the same Org as before. The Login History snipped below shows the three login types. As you can see, the two tests with two different Coefficient accounts produced identical log lines and the one with a connected app with an identical name only differs by the login IP address.

Image

Detecting and Mitigating Evil Twin Attacks

Here are some ways to detect Evil Twin attacks and anomalies in Salesforce logs:

  • Check IP Address Anomalies: Look for unusual IP addresses in login history and API logs.

  • Duplicate Apps: Identify duplicate apps in Connected Apps OAuth usage. Salesforce shows them as different apps even if they have the same name since Salesforce itself does see the Oauth ClientID.

  • App IDs: Watch for well-known apps with multiple App IDs starting with “888” in API logs. Connected apps starting with “888” are defined in some other Salesforce Org.

  • Access Patterns: Monitor for unexpected access patterns, such as unusual schedules or types of queried objects.

  • Compromised Accounts: Pay special attention to compromised user accounts that start using new apps during the suspected period of compromise.

Preventive Measures

To prevent Evil Twin attacks and make investigations easier, consider these practices:

  • Use Integration Users: Set up integrations with dedicated integration users to make anomalies more apparent applying the principle of least privilege.

  • Minimize Connected Apps: Reduce the number of Connected Apps to make it harder for attackers to find their favorite tool in your environment. Periodically review and remove unused Connected Apps.

  • Enforce IP Allowlisting: Restrict integration users to specific IP addresses where feasible.

  • Limit Self-Authorization: Minimize the number of apps that allow all users to self-authorize.

  • Enable Event Logs: Ensure event logs for login history and API access are enabled.

  • App Allowlisting: Consider enabling App allowlisting to control which apps users can authorize to access Salesforce.

Valo Detects Backdoors In Salesforce Using AI

Backdoor threats are a risk impacting all SaaS offerings, including Salesforce environments. Manual countermeasures can be very laborious, and general SaaS Posture Management solutions can be too generic. This is why at Valo, we created a purpose-built solution specifically for Salesforce to help its administrators automate the detection of risks, like backdoors targeting Salesforce environments.

If you are interested in seeing Valo in action in your Salesforce environment, visit us here to request early access. Experience for yourself what Valo can do to thwart risks impacting your Salesforce environments.

Conclusion

Backdoor threats are an evolving challenge in the SaaS era, especially for Salesforce environments. By employing vigilant detection methods and preventive measures, and leveraging tools like Valo, you can significantly enhance the security of your Salesforce integrations.

Stay vigilant, stay secure. For more information on keeping your integrations safe, visit Valo today.

  • Mika Stahlberg

    Mika Stahlberg