Assessing the True Business Impact of a Malicious Connected App

The Salesforce ecosystem has responded swiftly to the threat posed by the UNC6040 group, with many excellent resources detailing the phishing methodology. Salesforce Ben’s “A Salesforce Admin’s Guide to Auditing Connected Apps” for example, provides a critical first line of defense that NetSPI also highly recommends to our readers.

The blogs published so far that cover this topic focus on the specific actions taken by and methodology used by UNC6040. This is a case where being too specific can lead to problems. At this point, many respected bloggers in the Salesforce space have covered what happened and how you can keep your organization safe.
But what happens if an attacker gets through? While current discussions focus on preventing the breach, this post explores the critical next question: What is the true business impact?

We’ll move beyond data exfiltration to analyze the deep, cascading risks to your organization’s intellectual property and adjacent cloud infrastructure.

Social Engineering a Connected App

It’s very important to understand that an attacker has full control over the name and logo of the Connected App shown to your employees. For instance, an attacker can configure a malicious Connected App to pull your company’s logo from your homepage every time it’s displayed to users. This ability to control where the Connected App’s logo is sourced from can lead to complacency by your employees when considering authorizing a malicious Connected App.

We recommend being on the lookout for suspiciously named Connected Apps such as “DataLoader2″, “Salesforce CL1” (note the 1 rather than the capital I in this example), or variations on these names that may be dead giveaways for your more astute employees. What if the Connected App had the same name as a program created in-house by your developers? What if the Connected App’s logo matches the company’s logo that an attacker pulled from your company’s LinkedIn page? Each of these what-ifs contribute to a lower drawbridge that’s keeping attackers out of your Salesforce Org.

Impact Analysis – A Defense-in-Depth Failure

We’ve seen a lot of references online regarding what UNC6040 has been doing with the data that they’ve been able to exfiltrate – ransomware, reputational harm, the potential for litigation, and so on.

Should you be concerned about these? Absolutely!

But there are other additional, high priority issues at stake, including leveraging this access to escalate to other corporate-owned infrastructure. An analysis of the fictional scenario below will help illustrate why a defense-in-depth approach to managing the security of your Salesforce Org can protect your customers and your company. In this example, we will assume your company has been breached by UNC6040.

Scenario: A Single Click Cascades to a Full Infrastructure Breach

One of your employees had a lapse in judgement and installed a malicious Connected App that looked legitimate because it had the company logo attached. In truth, an attacker found your company logo by visiting Slack at https://yourCompany.enterprise.slack.com and configured the malicious Connected App to display your company logo along with a legitimate sounding name such as “IT App.”

Imagine a fictional employee, we’ll call him Jameson, has been with the company for five years. Your company has run through three Salesforce administrators in those five years and each one of them installed Managed Packages and mass assigned the “API Enabled” permission to every user on the Salesforce Org. There’s a high chance that Jameson’s account has been assigned various Permission Sets over the years that were configured without expiration dates. Because of this, Jameson has access to over 100 Apex classes and Visualforce Pages associated with Managed Package namespaces on top of the custom Apex classes the admin created since he’s also the company’s only Salesforce developer.

Jameson has no idea what any of this means and goes about his day working on assigned Cases associated with his Account. The consultancy that set up the company’s Salesforce Org 20 years ago talked them into an “open model” when it comes to record permissions, so unfortunately Jameson also unknowingly has access to the Salesforce Org’s setup section and most records stored in the Salesforce Org’s database. Now, let’s see what happens when Jameson authorizes the attacker’s malicious Connected App.

1. Once the unwitting employee clicks “Allow,” the attacker immediately retrieves a valid access token after the OAuth flow completes.

2. The access token is used as a bearer token in a GET request sent to https://yourCompany.my.salesforce.com/services/data/v64.0/ and provides access to your Salesforce Org’s REST API.

3. The attacker then requests a list of the objects in use by your Salesforce Org by visiting https://yourCompany.my.salesforce.com/services/data/v64.0/sobjects. This list returns the names of default and custom objects as well as those associated with Managed Packages.

4. For each object, the attacker issues a SOQL query by sending a GET request to https://yourCompany.my.salesforce.com/services/data/v64.0/query?q=SELECT+FIELDS(ALL)+FROM+EmailMessage+LIMIT+200.
   • This returns all field data for every EmailMessage record that Jameson has access to. FIELDS(ALL) limits queries to 200 records, but even if there are thousands of records, programmatically retrieving this data is both easy and quick to accomplish.

5. Given the “open model” approach to data, the attackers have successfully exfiltrated your Users, Contacts, Opportunities, Accounts, EmailMessages, Attachments, ContentDocuments, custom object records, Custom Metadata Types, Custom Settings, Custom Labels, and so on.
   • In addition to the data itself, the attacker also exfiltrated ApexClass and ApexPage source code which contain intellectual property in the form of your custom Apex and Visualforce Page implementations.

6. The attacker searches for “HttpRequest” in the exfiltrated Apex code and sees a reference to an Apex class named S3BucketController and reviews its source code. It quickly becomes obvious that the company’s Salesforce admin is storing AWS credentials in a Custom Metadata Type instead of using a Named Credential.
   • Jameson, by means of the Salesforce Org’s open permissions model, has access to just about everything, so the attacker issues the following GET request to retrieve the plaintext credentials, https://yourCompany.my.salesforce.com/services/data/v64.0/query?q=SELECT+access_key__c,secret_access_key__c+FROM+Integration_Credentials__mdt

7. The attacker pivots from your compromised Salesforce Org to your company’s AWS infrastructure. The attacker has gone from being limited by the permissions assigned to Jameson to a whole new world of possibilities where they may locate additional opportunities to pivot, gather sensitive data, or disrupt other integrated platforms.

Visualizing the Attack Path

This flowchart illustrates how a simple action by an employee can lead to a critical infrastructure takeover made possible by multiple security misconfigurations.

Impact Summary

A user with legacy “permission creep” authorized what they thought was a legitimate internal app. This not only exposed Salesforce data such as emails and contacts, it also allowed an attacker to use that access to read the source code of your custom automations, find hardcoded AWS credentials, and pivot from your Salesforce Org into your company’s core cloud infrastructure.

What if the User’s Permissions Were Limited?

What if Jameson’s permissions were limited and they didn’t have access to much data? Is the impact of this sort of attack lessened? The honest answer is that it depends. In the hypothetical but common scenario described above, it is very likely that an attacker can leverage Jameson’s access to both custom and namespace-associated Apex classes to explore opportunities for privilege escalation.

A previous NetSPI blog explores some aspects of Apex Actions. These are Apex class methods commonly used in Flows that are exposed to users via the @InvocableMethod decorator. As mentioned in the Salesforce Ben blog post, a Salesforce Org user must have the “API Enabled” permission in order to authorize the installation of an attacker’s malicious Connected App. Unfortunately, this is the only permission required to explicitly call Apex Actions from the REST API.

NetSPI’s blog post linked above describes how Apex Actions can be called explicitly via https://yourCompany.my.salesforce.com/services/data/v64.0/actions/custom/apex/ActionName
or
https://yourCompany.my.salesforce.com/services/data/v64.0/actions/custom/apex/Namespace/ActionName
if the method is associated with a Managed Package’s Apex class.

The worry with Apex Actions, and any other exposed Apex functionality, is that they can sometimes be exploited to go from no access to a complete takeover of your Salesforce Org. This can happen via SOQL Injection, SOSL Injection, Insecure Deserialization, Unsafe DML operations, and more.

Conclusion

As we’ve seen, a compromised Connected App isn’t just a data privacy issue; it’s a potential gateway to your entire technology stack and integrated infrastructure. The risk extends beyond customer data to your company’s intellectual property and other cloud platforms.
The first line of defense is a thorough audit of your existing Connected Apps. For a comprehensive, step-by-step walkthrough of that process, we highly recommend the guide published by Salesforce Ben.
Once you’ve completed that initial audit, the work isn’t over. To protect against the deeper, systemic risks we’ve outlined, we highly recommend following these critical steps:

1. Eradicate Hardcoded Credentials
   • Your number one priority must be to eliminate secrets from your metadata and code. Conduct a code search for terms like ‘key,’ ‘secret,’ and ‘password,’ and replace all instances with Named Credentials and External Credentials. This single step severs the primary attack chain we demonstrated.
2. Enforce the Principle of Least Privilege
   • Go beyond a simple Connected App audit and tackle Permission Set and Profile hygiene. Create a “Minimum Viable Permissions” baseline for your standard users. A user like Jameson should never have access to view all data or read all Apex classes. This is the foundation to a true defense-in-depth strategy.
3. Scrutinize “API Enabled” Permissions
   • Does every user with this permission truly need it? This permission is the key that unlocks the door for malicious apps. Treat it as a seldom assigned privilege, not a default privilege. If your Managed Package vendor requires “API Enabled,” don’t be afraid to question why.
4. Implement Proactive Monitoring
   • Utilize Salesforce Shield or other event monitoring tools to create alerts for unusual data export activity, high-volume Apex executions, or authorizations of new Connected Apps.
     

We’ve covered the critical manual steps to begin securing your organization, from auditing Permission Sets to hunting for hardcoded credentials. This process is vital, but it can also be time-consuming and requires a deep understanding of your Org’s history and metadata.
Learn more about how NetSPI’s Salesforce Configuration Review offering can give you a complete picture of your security posture and book a call with NetSPI to review your primary security concerns.