Inside a Red Bull-themed recruitment phishing campaign

The Red Bull recruitment scam: what is it?

Phishing remains one of, if not the most effective, tools in a threat actor’s toolbox. Not because businesses lack the investment in awareness or security tools, but because attackers are constantly evolving ways to bypass or nullify these checks.

Despite significant investment in training, email filtering, authentication and endpoint protection, phishing attempts still succeed, because automation can be predicted, and it can be evaded.  

This is where the human-led detection provided by a SOC becomes essential. A skilled analyst can proactively threat hunt and use Open-Source Intelligence (OSINT) to continually adapt current detections and build new detections to spot the subtle signs of compromise that our security tools miss.  

By working with a managed SOC or SOCaaS, you don’t just benefit from your specific data. When an attack is identified, the custom detection is rolled out to everyone. This is how Evalian scales protection, transforming a single incident into proactive defences for everyone. 

To demonstrate this, I will use this blog to explore a live phishing campaign that Evalian’s SOC identified. It bypassed standard enterprise security tools and checks, landed cleanly in inboxes, and led victims to a spoofed Facebook login page designed to steal credentials.

I will demonstrate how I was able to deconstruct the attack to identify Indicators of Compromise (IoC), and I will show you how analysing the attack methodology of this threat actor, and the IoCs left behind by the attacker helped us build the right detections to continue to monitor a protect all our customers. 

Red Bull phishing email 

The first step was triage. The email passed all authentication checks and looked legitimate to our security tools. However, it triggered suspicion during a routine analyst review. Here’s how we began to break it down. 

“You might be a great fit for something at Red Bull…” 

That’s how the phishing email begins. Friendly, personal and professional. But behind the polished tone and fake opportunity lies a multi-domain phishing campaign designed to steal credentials, rapidly deployed infrastructure using low-cost Virtual Private Servers (VPS) for churn, a spoofed Facebook login page, and clever abuse of reputable domains and services. 

Let’s unpack the full anatomy of this campaign from email origin to TLS fingerprinting and show how layered deception can bypass the unprepared. 

While appearing to come from a team within Red Bull, the actual sender domain was: 

messaging-service@post.xero[.]com 

Reply-to:  

red.bull.crew@srbs.user0212-stripe[.]com (not affiliated with Red Bull) 

The link embedded in the email was: 

hxxp://redbull-social-media-manager.apply-to-get-hired[.]com 

Analysing the email header 

The email came from what looked like a legitimate service:
messaging-service@post.xero[.]com 

Not only that, but the message also passed SPF, DKIM, and DMARC, making it appear clean to most email filters. 

Looking deeper into the headers, I found: 

• Sender IP: 198.244.57.62 (Mailgun US) 

• Authenticated domain: post.xero.com 

• X-Mailgun headers: Confirmed it originated from a high-risk IP pool 

• SCL (Spam Confidence Level): 1 Microsoft didn’t flag it as spam 

Despite all signs pointing to legitimacy, the Reply-To address revealed the trick: 

red.bull.crew@srbs.user0212-stripe[.]com 

This technique, riding on the reputation of a legitimate sender, is increasingly common in modern phishing campaigns. Abuse of services like Mailgun, SendGrid, or Salesforce to deliver malicious content allows attackers to bypass basic spam detection. 

Following the link 

With a suspicious sender identified, we moved into the controlled analysis.

Our aim: understand the user journey, extract infrastructure indicators, and determine the attack’s objective. 

The link in the email pointed to: 

hxxp://redbull-social-media-manager.apply-to-get-hired[.]com 

I loaded it in a controlled environment and was presented with a surprisingly convincing multi-step flow: 

1. A reCAPTCHA screen, likely to slow down automated scanners. 

2. A Glassdoor-style fake job description 

3. A Facebook login page, complete with the familiar UI, but completely fraudulent. 

From the browser’s DevTools Network tab, I observed the login attempt sending credentials via a POST request to: 

/login_job 

The remote IP 38.114.120[.]167, is hosted by a provider known for high-abuse VPS hosting. 

Network behaviour 

From the spoofed Facebook login page, I monitored the network requests using browser DevTools. When dummy credentials were entered, they triggered a request to: 

POST https://redbull-social-media-manager.apply-to-get-hired[.]com/login_job 

Remote IP: 38.114.120[.]167
Server: nginx/1.24.0 (Ubuntu)
Response Status: 504 Gateway Timeout 

A 504 error indicates that the backend server did not respond in time, but this doesn’t mean the phishing attempt failed. There are several possibilities here: 

Stalling tactic 

The server might intentionally delay or suppress responses to avoid sandbox or scanner detection. Some phishing kits implement “slow kill” techniques for this purpose. The POST request to /login job hangs before returning a 504 Gateway Timeout. This behaviour is consistent with stalling, either intentional or due to overuse. Many phishing kits introduce artificial latency (e.g., sleep functions) to evade detection by sandboxes and automated scanners, which typically terminate analysis after a few seconds. 

What was visible: 

• No immediate server-side rejection or redirect 

• The page remained responsive client-side 

• Delayed POST request without a network layer block (e.g., no connection refused). 

This suggests a stalling technique may be in play, whether intentional or from overloaded infrastructure. 

Offline backend 

The other plausible possibility is that the backend infrastructure was offline. The 504 Gateway Timeout indicates the front-end web server is running (nginx) but failed to reach the backend (likely PHP or database service). This is common in hastily deployed phishing kits where the attacker forgets to maintain the backend. 

The certificate and domain were still valid, so the infrastructure hadn’t been fully abandoned. Only the backend response chain failed. 

Checking the TLS certificate 

The phishing page was served over HTTPS, with a valid Let’s Encrypt certificate. The certificate’s Common Name (CN) caught my attention: 

CN=bot2shimeta.charliechaplin7eont[.]space 

Let’s Encrypt doesn’t validate domain ownership beyond DNS, attackers frequently automate TLS provisioning to appear trustworthy. 

I extracted the JARM fingerprint from the TLS connection: 

27d40d40d00040d00042d43d000000d2e61cae37a985f75ecafb81b33ca523 

Using tools like jarm.tech, this can be used to hunt other phishing infrastructure using the same TLS stack. 

Using Shodan, I searched for the JARM fingerprint associated with the phishing page, combined with the cert issuer (E5 from Let’s Encrypt) and hosting provider (GlobalTeleHost). This narrowed 300,000+ results down to 21 hosts all sharing traits: 

• VPS-style domains (api.*, *.top, *.io) 

• TLS fingerprints identical to the phishing infrastructure 

• Certificates issued within the same few days 

This indicates a cluster not just a single malicious site, likely part of a broader phishing kit or campaign. 

Mapping the infrastructure 

Once we understood the user-facing side of the campaign, we shifted our focus to the infrastructure. Could this domain be part of a larger kit or reused tooling? We used OSINT, passive DNS, and TLS fingerprinting to find out. 

Now I had a domain: charliechaplin7eont.space. 

From there, I pivoted into: 

• Passive DNS (via VirusTotal) 

• Subdomains: 

• bot2shimeta.charliechaplin7eont[.]space 

• mrbeastmeta.charliechaplin7eont[.]space 

• samkymeta.charliechaplin7eont[.]space 

• meta.charliechaplin7eont[.]space 

These names suggest targeting across brands, using influencer names like “MrBeast” and spoofing Meta itself. 

I noticed all subdomains resolved to the same IP:
38.114.120[.]167 

And the IP belonged to:
ASN 63023 (AS-GLOBALTELEHOST) a block associated with transient, low-trust infrastructure. 

Using VirusTotal’s graphing tools, I mapped out related domains in this phishing kit, including: 

• redbull-social-media-manager.jobs-apply-fast[.]com 

• redbull-jobs.jobapply-careers[.]com 

• redbull.career-applynow[.]com 

Indicating this was a campaign. 

Domain and certificate insights 

Looking at the domain charliechaplin7eont.space via WHOIS and DNS tools: 

• Registrar: Porkbun 

• Created: May 30, 2025 

• Expires: May 30, 2026 

• Nameservers: porkbun.com nameservers (distributed globally) 

The domain’s creation date matches closely with the email campaign, suggesting quick setup and deployment, typical of phishing kits sold as services. 

The Let’s Encrypt cert (issued on May 30) had a 90-day lifetime, and no other SANs a single-purpose cert used only for this phishing flow. 

Broader infrastructure 

While the email appeared to come from messaging-service@post.xero.com, the Reply-To header told a more interesting story: 

Reply-To: red.bull.crew@srbs.user0212-stripe[.]com 

This unusual subdomain srbs.user0212-stripe[.]com initially appeared benign when loaded in the browser. The page presented itself as a generic “Technology Solutions” landing page, complete with buzzwords, consulting service claims, and basic navigation elements (Home, Services, About, Contact). On the surface, it seemed like a placeholder or a low-effort business front. 

However, this domain has all the hallmarks of phishing infrastructure obfuscation: 

• Hosted on IP: 172.81.134[.]78 

• Served by an Apache server with chunked encoding 

• TLS-protected (via Let’s Encrypt) 

• No meaningful backend functionality 

• Static HTML landing page, suggesting it was either: 

• A front to make the domain appear legitimate 

• A cloaked page is shown to non-targeted visitors 

Using VirusTotal and passive DNS tools, I observed that this domain shares infrastructure characteristics with a wider network of suspicious domains: 

• Several .mlko.my subdomains (e.g. ejhns.mlko[.]my, omtla.mlko[.]my, etc.) resolved on the same day (2025-07-01) 

• All had 0 detections on VirusTotal, but the pattern, short, random-looking hostnames with the same hosting fingerprint strongly suggests automated phishing kit activity 

The WHOIS history links the IP and infrastructure back to DataWagon LLC, a VPS provider often associated with abuse-resistant or disposable hosting. The infrastructure also reused TLS certificates previously seen on domains like hbsfm.607325[.]com, reinforcing the idea that this wasn’t a one-off phish it’s part of a repeatable, rentable phishing operation. 

Detection/hunting query 

With confidence in the infrastructure indicators and tactics, we moved to detection engineering. The goal wasn’t just to stop this email; it was to detect the campaign wherever it might appear next. Below are two detections/threat-hunting queries used to identify further attempts. 

These detections were deployed across all our customers. Although only one customer received the original phishing email, others could have been targeted next.  

Targeted email detection 

Query purpose:
Detects phishing emails sent from suspicious infrastructure using spoofed branding and containing malicious links. 

Mapped MITRE Techniques: 

• T1566.002 – Phishing: Spearphishing Link
  Detects emails that trick users into clicking malicious URLs. 

• T1585.001 – Establish Accounts: Social Media Accounts (Impersonation)
  Impersonates Facebook login and Red Bull job offers. 

IOC correlation across multiple tables 

Looks across email, endpoint, and network data to detect any user interaction with known phishing infrastructure (suspicious domains, URLs, IPs). Correlates suspicious URLs in emails with device-level web requests and matching sender infrastructure. 

Mapped MITRE Techniques: 

• T1566.002 – Phishing: Spearphishing Link
  Detects delivery of phishing URLs via email. 

• T1071.001 – Application Layer Protocol: Web Protocols
  Monitors device communication with malicious IPs/domains over HTTP/S. 

Final thoughts 

This campaign was a layered deception engineered to evade detection and exploit trust at every step. The attackers abused legitimate email infrastructure, leveraging Mailgun and the trusted domain post.xero.com to sneak through spam filters with fully authenticated messages. They served their phishing content over HTTPS using a valid TLS certificate from Let’s Encrypt, creating the illusion of legitimacy while hiding behind a secure connection. 

The infrastructure was distributed across low-reputation VPS providers, with domains spun up just days before the campaign went live. Subdomains spoofed not only Red Bull but also well-known influencer brands like MrBeast and Meta, all hosted on the same IP and managed under the same malicious infrastructure. The fake job application flow mimicked Glassdoor and Facebook, complete with a working reCAPTCHA, a tactic likely intended to evade automated scanners and make the journey feel real to the victim. 

This investigation underscores how modern phishing operations have evolved. It’s no longer about crude HTML and spelling mistakes. Instead, attackers are combining brand impersonation, and infrastructure-as-a-service to scale fast, phish wide, and stay ahead of basic defences. 

For a SOC, this means going beyond blocking domains. It’s about hunting infrastructure patterns, monitoring cloud mail providers like Mailgun, pivoting on TLS artefacts like JARM fingerprints, and educating users to question even the most polished messages. 

SPF, DKIM, and DMARC do not guarantee that a message is safe, only that it was not forged at the SMTP level and came from an authorised sender. Attackers are increasingly Piggybacking on trusted third-party mail platforms like Mailgun, SendGrid, Salesforce and Sending through domains with properly configured email authentication. In this case, the phishing campaign weaponised trust by using a legitimate and reputable domain, to pass all filtering checks and reach the inbox clean.

Indicators of compromise (IOCs) 

 More resources

You can learn more here on the importance of employee phishing awareness training for your organisation, or learn more about how to identify phishing emails.

You may also find this information on Business Email Compromise helpful.

To speak to one of our expert cybersecurity consultants about our Managed SOC services, or to arrange phishing awareness training for your oragnisation, fill in the form below.