EvilProxy phishing campaign leverages convincing impersonations of enterprise applications

Executive Summary

Okta Threat Intelligence has identified a high-volume attack campaign that subsequent research shows has been active since at least March 2025, leveraging the EvilProxy phishing-as-a-service (PhaaS) toolkit to execute real-time phishing attacks designed to steal user credentials and active session cookies. We track this campaign as O-UNC-035.

This operation targets organizations across numerous sectors, including Finance, Government, Healthcare, and Technology, primarily using highly convincing lures impersonating popular business tools such as SAP Concur and document signing services such as Adobe or DocuSign.

Threat Analysis

EvilProxy Phishing-as-a-Service

EvilProxy (O-TA-041) is a PhaaS toolkit that uses a reverse-proxy/adversary-in-the-middle (AitM) architecture to intercept victims' logins and session cookies in real time, allowing attackers to bypass multi-factor authentication (MFA) and hijack accounts.

Originally observed in 2022 and rapidly productized on dark-web marketplaces, EvilProxy has been widely used in targeted account takeover and Business Email Compromise campaigns because it proxies legitimate sites. This means that users see real MFA prompts, and that the attacker is able to capture tokens and cookies for the attacker to replay. Because EvilProxy is sold and maintained as a service, it scales attacks and lowers the skill barrier for criminals: operators can launch large volumes of tailored phishing campaigns.

Lure mechanisms

We have observed trusted enterprise software and services impersonated to trick users into clicking links and entering credentials:

• Document signing services (such as Docusign, Adobe Acrobat, Adobe Sign, EchoSign): A consistent theme observed in this campaign was the impersonation of document management and electronic signature providers. Attackers use the promise of a shared document or a signature request to entice victims.
• Expenses and procurement platforms (such as SAP Concur, Coupa): This was the most frequent lure observed in this campaign. It targets employees by impersonating popular expense and travel management systems, often with prompts to approve a report or review an expense. A more generic lure uses terms like expense, expensereport, or expensesolutions.
• Microsoft SharePoint: The campaign also targets users of the Microsoft 365 ecosystem by faking a link to a shared document or a collaborative site.
• Online Meetings: The attackers registered generic domains that include words like meeting to impersonate invitations to meeting platforms.
• KnowBe4: The attackers impersonated a security awareness training company, in an attempt to trick targeted users into assuming the phishing lure was part of an official phishing test.

Code analysis

The lure redirection chain starts with a short link in which the victim's email address is obfuscated within the URL path. The user is then bounced through a redirector branded with the target's company name in the subdomain, and finally lands them on a convincing Microsoft-branded phishing page that steals credentials. The JavaScript on the redirector extracts the email from the path, re-encodes it, and builds a personalized redirect URL that carries that identity across every hop.

HTTP chain example 1

Initial Link:

hxxps[://]expensereport[.]ch/[coded_string]

Redirector:

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

Final URL (showing the sign-In website for credential harvesting):

hxxps[://][32_characters_string][.]laurimarierefling[.]com/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

HTTP chain example 2

Initial Link:

hxxps[://]sapconcursolutions[.]pl/[coded_string]

Redirector:

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

Final URL (showing the sign-In website for credential harvesting):

hxxps[://][32_characters_string][.]concurmgt[.]pl//?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

How the redirector decodes and personalises the victim

The phishing pages accept the last path segment and attempt the use of several decoders in sequence-custom token mapping, hex, Base32, and Base64-until the result contains "@". That value becomes the victim's email for downstream use, as seen in this initial lure page code example:

let encodedValue = window.location.pathname.split('/').pop();
...
email = decodeEmail(encodedValue); // custom tri-gram map
...
if (!decodingSuccessful && isHexadecimal(encodedValue)) email = hexToString(encodedValue);
if (!decodingSuccessful && isBase32(encodedValue)) email = base32ToString(encodedValue);
if (!decodingSuccessful && isBase64(encodedValue)) email = base64ToString(encodedValue);

The custom decoder replaces three-character tokens back into characters, using a map like:

const encodingMap = {
    "@":"MN3",".":"OP4","a":"QR5","e":"ST6","i":"UV7",
    "o":"WX8","u":"YZ9","s":"ABO","n":"CD1","r":"EF2",
    "d":"GH3","I":"JK4"
};

Anti-analysis gates

Before redirecting, the script attempts to avoid crawlers and sandboxes:

function isBot() {
    const botPatterns = ['bot','spider','crawl','slurp','baidu','yandex',
        'wget','curl','lighthouse','pagespeed','prerender','screaming frog',
        'semrush','ahrefs','duckduckgo'];
if (navigator.webdriver || navigator.plugins.length === 0 ||
    navigator.languages === "" || navigator.languages === undefined)
return true;
...
}

If a bot/headless signal is found-or if the operator's "blocked" org appears -the page hard-redirects to the legitimate Microsoft login, giving triage teams a clean page while real users continue down the phish. The api.ipify.org service is used to return the victim's public IP address, to compare to an IP/range block list.

Block-listed domains

The code also contains two blocked domains, which if found in the victim email address will cause the phishing flow to exit instead to the authentic Microsoft login page:

const blockedDomains = ['belfius', 'baringa'];
const emailDomain = email.split('@')[1].toLowerCase();

for (const blocked of blockedDomains) {
    if (emailDomain.startsWith(blocked)) {
        window.location.href = "https://login.microsoftonline.com/common/login";
return;
    }
}

The provenance of the blocking of these two domains is unknown. The "belfius" domain appears to refer to a Belgian bank, while "baringa" appears to be associated with a UK management consultancy.

Query parameters

Across the observed samples, the redirector builds the same parameterised URL and only the domain family varies. Two parameters are the victim's email in different wrappers; the rest are nonces plus a timestamp:

• uid → Base64(email)
  • Can be decoded using a CyberChef recipe
• hid → hex(Base64(email))
  • Can be decoded using a CyberChef recipe
• document, token → random IDs (nonce-like)
• t → Unix timestamp (ms)
  • Can be converted to a human-readable date using a CyberChef’s recipe

Authentication flow

Within the authentication flow, the impersonated company's name appears in certain fields of both the redirector and the final URL. Additionally, the phishing framework automatically populates the victim's email address in the username field of the phishing page.

Initial link:

hxxps[://]expensereport[.]ch/616c6578616e6465722e652e6261754073662e6672622e6f7267

Redirector:

hxxps[://]sf[.]sapconcur[.]sa[.]com/expense/?uid=...&hid=...&document=...&token=...&t=...

Final URL

hxxps[://]299afcb76fac4238a0facad80c326230[.]concursolutions[.]asia/?uid=...&hid=...
&document=...&token=...&t=...&u9pPUdqL=...

Threat Response

What we're doing:

We're actively engaged in the following activities to mitigate this threat:

• Continuously monitoring for newly registered phishing domains and infrastructure associated with this campaign.
• Proactively filing abuse reports with relevant registrars and hosting providers to initiate takedown requests for identified malicious sites.
• Providing guidance and assistance to organizations to enhance the security of their Okta environments and assisting them to investigate any suspicious activity related to potentially compromised accounts.

Protective Controls

Recommendations for customers

• Enroll users in strong authenticators such as Okta FastPass, FIDO2 WebAuthn and smart cards and enforce phishing resistance in policy.
• Okta app sign-on policies (formerly "authentication policies") can also be used to restrict access to user accounts based on a range of customer-configurable prerequisites. We recommend administrators restrict access to sensitive applications to devices that are managed by Endpoint Management tools and protected by endpoint security tools. For access to less sensitive applications, require registered devices (using Okta FastPass) that exhibit indicators of basic hygiene.
• Deny or require higher assurance for requests from rarely-used networks. With Okta Network Zones, access can be controlled by location, ASN (Autonomous System Number), IP, and IP-Type (which can identify known anonymizing proxies).
• Okta Behavior and Risk evaluations can be used to identify requests for access to applications that deviate from previously established patterns of user activity. Policies can be configured to step-up or deny requests using this context.
• Train users to identify indicators of suspicious emails, phishing sites and common social engineering techniques used by attackers. Make it easy for users to report potential issues by configuring End User Notifications and Suspicious Activity Reporting.
• Document, evangelize and adhere to a standardized process for validating the identity of remote users that contact IT support personnel, and vice versa.
• Take a "Zero Standing Privileges" approach to administrative access. Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles.
• Apply IP Session Binding to all administrative apps to prevent the replay of stolen administrative sessions.
• Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions.

Observing and responding to phishing infrastructure:

• Review application logs (Okta logs, web proxies, email systems, DNS servers, firewalls) for any evidence of communication with any such suspicious domains.
• Monitor the domains regularly to see if the contents change.

If content hosted on the domain violates copyright or legal marks, consider providing evidence and issuing a takedown request with the domain registrar and/or web hosting provider.