Hook, Line, and Tinker: A Dive into Phishing Campaign Sites

Hook, Line, and Tinker: A Dive into Phishing Campaign Sites

Speakers: Rick Ramgattie

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=ixHjfxWH_H0

Overview

In his BSidesSF 2024 talk, "Hook, Line, and Tinker: A Dive into Phishing Campaign Sites," Rick Ramgattie, an ABC Engineer at Gemini Trust Company, presented a compelling and practical exploration into the world of active phishing campaigns. The presentation detailed three distinct case studies where Ramgattie, leveraging his background in application security and a passion for threat hunting, actively engaged with adversary infrastructure to understand phishing methodologies, identify vulnerabilities in defensive controls, and ultimately improve security posture for affected organizations.

Ramgattie's talk is crucial for security professionals as it moves beyond theoretical discussions of phishing to provide a hands-on, attacker-centric view. By dissecting the operational tactics of phishing campaigns—from sophisticated adversary-in-the-middle (AiTM) attacks bypassing multi-factor authentication (MFA) to simple misconfigurations revealing attacker secrets—he demonstrated how direct analysis of phishing sites can yield actionable intelligence. This approach not only aids in accelerating takedowns but also informs the development of more robust fraud controls and detection mechanisms, highlighting the critical need for defenders to understand their adversaries' infrastructure intimately.

The core message of the talk emphasizes that while interacting with malicious infrastructure carries inherent risks, a controlled and analytical approach can uncover invaluable insights that traditional brand protection vendors or automated systems often miss. Ramgattie's methodology, using a simple isolated setup (Chromebook, Burp Suite, Firefox, Mullvad), serves as a blueprint for security teams looking to proactively defend against evolving phishing threats and reduce user losses.

Background

▶ Watch: Warning about interacting with adversary infrastructure, simple setup (Chrome... (01:00)

Rick Ramgattie's journey into analyzing phishing campaign sites stems from his eight years of experience in application security (ABC), initially as a security consultant at Independent Security Evaluators and subsequently as an internal ABC engineer at Gemini Trust Company. This internal role allowed him to embed with other security teams, fostering a hobby in thread hunting that eventually inspired the detailed investigations presented in his talk.

The problem Ramgattie sought to address is the persistent and evolving threat of phishing, particularly when traditional defensive measures fall short. He highlighted common challenges faced by organizations:

• Ineffective Brand Protection Vendors: While companies typically engage brand protection vendors (e.g., ZeroFox) to handle takedowns, these vendors can be stymied by sophisticated attacker tactics, such as hosting on bulletproof registrars that are unresponsive to takedown requests.
• Slow Automated Detection: Services like Google Safe Browsing, while valuable, rely on automation that can be slow to identify and flag new phishing sites, allowing campaigns to persist for weeks.
• Lack of Attacker Understanding: Many organizations lack a deep understanding of how phishing attacks against their users actually work, including the specific techniques used to bypass security controls or exfiltrate data. This knowledge gap hinders the development of effective countermeasures.

Ramgattie's approach was born out of these frustrations. He recognized that to truly get ahead of phishing campaigns, one must understand the attacker's infrastructure and methods directly. This meant intentionally interacting with live phishing sites, a process he explicitly warned attendees about, emphasizing the inherent dangers and the need for careful, isolated environments. His personal setup—a Chromebook running Burp Suite, Firefox (configured to proxy through Burp), and Mullvad VPN—underscored the accessibility of such analysis, even for small teams or individual hobbyists. The talk's focus was not just on the findings but on how he analyzed these sites to extract information that improved security posture.

Key Findings

▶ Watch: Discovery of 'Proxy AiTM': phishing site proxies credentials and 2FA to real ... (06:00)

Ramgattie's investigations into phishing campaign sites yielded several critical findings, categorized by the three distinct stories he shared:

1. Adversary-in-the-Middle (AiTM) Phishing (Proxy Atos):

• Real-time Credential Validation and 2FA Bypass: Phishing sites can act as proxies, forwarding user input directly to the legitimate target site. This allows them to validate credentials in real-time and even bypass multi-factor authentication (2FA) by simply forwarding the 2FA code entered by the victim.
• CAPTCHA Evasion: Attackers leverage CAPTCHA solvers (either automated or human-powered) to bypass anti-automation controls on legitimate sites, enabling their proxying infrastructure to interact seamlessly.
• Sophisticated Fraud Control Bypass: AiTM attackers can chain actions to bypass multiple fraud controls. For instance, by first changing a victim's email address to one they control, they can then receive and click "magic links" required for high-value actions like withdrawing funds.
• WAF Evasion: Phishing sites themselves often employ Web Application Firewalls (WAFs) like Cloudflare to deter automated analysis by security researchers and brand protection vendors, making initial detection difficult.

1. Referral Header Leakage and SMTP Log Disclosure:

• Referral Header as an Indicator: Many phishing sites, particularly those using HTTP redirects (e.g., HTTP 301), inadvertently disclose their own existence by sending a Referer header to the legitimate target site. This header, often overlooked, can be a rich source for discovering new phishing infrastructure.
• Poor Server Configuration: Attackers sometimes misconfigure their phishing site backend, leading to the accidental disclosure of sensitive information. Ramgattie discovered SMTP logs embedded within HTTP Location headers on error pages, revealing the attacker's email addresses used for credential harvesting.
• Attacker Anti-Automation: Phishing campaigns frequently use HTTP redirects and host single images that redirect to the "real" phishing site to obfuscate their true landing pages and evade automated scanners.

1. Web3 Wallet Draining Phishing:

• Brand Leveraging, Not Infrastructure Compromise: Web3 phishing often doesn't target the legitimate company's infrastructure directly but rather leverages its brand reputation to trick users into connecting their cryptocurrency wallets to malicious sites.
• Unique Anti-Automation Codes: Attackers implement unique codes or PINs that users must enter to access the phishing site, further hindering automated analysis and making it harder for general scanners to reach the wallet-draining payload.
• Community-Driven Defense: For web3-specific threats, community projects like eth-phishing-detect (by MetaMask) offer a more agile and effective takedown mechanism than traditional registrars or safe browsing, which may not be equipped for blockchain-specific threats.
• Compromised Third-Party Infrastructure: Phishing campaigns can originate from compromised third-party systems (e.g., hacked marketing companies), highlighting the need for broader ecosystem awareness and communication.

These findings collectively underscore the dynamic nature of phishing, the ingenuity of attackers in bypassing controls, and the critical role of proactive, hands-on analysis in uncovering these tactics.

Technical Deep Dive

▶ Watch: Discovery of credential harvesting via misconfigured PHP web app disclosing S... (16:00)

Ramgattie's presentation was structured around three detailed case studies, each offering a unique technical perspective on phishing campaigns.

Case Study 1: Proxy AiTM (Adversary-in-the-Middle) Attacks

The first instance, dubbed "Proxy Atos" by Ramgattie, began when a friend's company experienced a wave of user account cleanups linked to four specific phishing sites. The company's brand protection vendor and Safe Browsing had failed to take down these sites, which were hosted on a bulletproof registrar. Ramgattie's goal was to understand how the phishing worked to accelerate takedowns and reduce user losses.

His analysis setup was intentionally simple: a Chromebook running Burp Suite and Firefox, with Mullvad VPN for isolation. The initial attempt to access a phishing site with Burp's built-in Chromium browser resulted in an HTTP 503 error, indicating that the site was protected by a Web Application Firewall (WAF), specifically Cloudflare, which flagged Burp's client as malicious. Switching to Firefox, configured to proxy through Burp, successfully bypassed the WAF, yielding an HTTP 200 success code. This immediately highlighted how attackers use WAFs to deter automated security analysis.

The critical discovery came during credential submission. When Ramgattie entered fake credentials, the phishing site responded with "password incorrect." This was highly suspicious; a standalone phishing site should not know the validity of credentials. He then created a real account on the legitimate platform and used those credentials on the phishing site. This time, the response was "success, password correct." Furthermore, the site prompted for a Two-Factor Authentication (2FA) code, which, when entered, also passed. This confirmed that the phishing site was not merely collecting credentials but was actively proxying all user input to the real site in real-time.

This AiTM setup allowed the attacker to:

• Validate Credentials: The phishing site would forward the username and password to the legitimate service, receive the response, and relay it back to the victim.
• Bypass 2FA: By proxying the 2FA code, the attacker effectively gained a valid, authenticated session.
• Solve CAPTCHAs: The legitimate site used a CAPTCHA slider. Ramgattie confirmed that attackers use CAPTCHA solvers to bypass these anti-automation controls, enabling their proxying infrastructure to complete the login flow.

Upon gaining access, the attacker performed three security-critical actions: changing the user's email address, withdrawing the current balance, and transferring more money from linked bank accounts. Ramgattie then analyzed the legitimate platform's fraud controls:

• Email Change: Required 2FA within the last 10 minutes. The AiTM attack satisfied this by proxying the 2FA.
• Withdrawal: Required 2FA within the last 10 minutes and clicking a "magic link" sent to the victim's email.
• Money Transfer: Required 2FA within the last 10 minutes.

The "magic link" requirement for withdrawal initially seemed like a strong control. However, by reviewing logs of actual victim accounts, Ramgattie discovered a pattern: the attacker always changed the victim's email address first. This meant the magic link was sent to an email address controlled by the attacker, allowing them to complete the withdrawal. The proposed fix was to require users to have access to their original inbox before an email address change could be finalized, effectively breaking the attacker's chain of actions.

Further analysis of the attacker's activity logs revealed that all observed IP addresses for the proxied logins originated from ExpressVPN, and user agents varied with every request, indicating efforts to obfuscate their origin.

Case Study 2: Referral Header Leakage and SMTP Log Disclosure

Inspired by the first case, Ramgattie applied his thread hunting skills to Gemini, his employer. He noticed that some phishing sites, after collecting credentials, would perform an HTTP 301 redirect to the legitimate Gemini site. This redirect often included a Referer header that disclosed the phishing site's URL. By monitoring the Referer headers on Gemini's sign-in page, he quickly identified numerous phishing domains, such as app.Gemini.web.one, which were not associated with Gemini.

Within hours, he found hundreds of phishing sites hosted on various providers, including Azure Websites. Many of these sites initially hosted only a single image that, when clicked, redirected to the "real" phishing page, another obfuscation technique.

Unlike the first case, this campaign did not involve AiTM. After submitting fake credentials, Ramgattie consistently received an error.html page. A deep dive into the HTTP requests and responses for this error page revealed a critical misconfiguration: the Location header of the HTTP response contained what appeared to be SMTP logs. These logs explicitly showed the attacker's sender and receiver email addresses (e.g., [email protected] sending to [email protected]), indicating that the phishing site's backend was configured to email harvested credentials to the attackers. This was a direct disclosure of the attacker's credential harvesting mechanism due to a poorly configured PHP web application.

Ramgattie discovered that over 200 phishing sites in this campaign consistently used the same two sender email addresses and three receiver email addresses. Since these were Gmail addresses, he devised a novel countermeasure: daily seeding of accounts on these phishing sites. By submitting fake credentials to hundreds of sites every morning, he aimed to exhaust the attackers' daily email sending limits, effectively preventing them from receiving legitimate victim credentials. This, combined with improved responsiveness from hosting providers, eventually led to the campaign's cessation.

Case Study 3: Web3 Wallet Draining Phishing

The final case involved a new type of phishing targeting Gemini's brand, but not its core infrastructure. Users were receiving emails about a "Gemini airdrop" from unrelated domains (e.g., ecomotors.com.br). These emails contained a "proceed now" button and a unique code.

Clicking the link led to a phishing site that required the user to enter the specific code from the email. This served as an anti-automation control, preventing general scanners from accessing the main phishing payload. After entering the code, the site presented a page resembling Gemini's landing page but with a prominent "withdraw" button. Clicking this button would prompt the user to connect their Web3 wallet, specifically MetaMask, which is a popular browser extension for interacting with decentralized applications. If the user approved the connection and subsequent transfer, their wallet would be drained.

This attack leveraged Gemini's brand reputation to trick users into interacting with a malicious Web3 application. Since it didn't involve Gemini's traditional login infrastructure, standard takedown methods were less effective. Ramgattie reported these domains to the eth-phishing-detect project, a community-driven initiative by MetaMask. Within days, MetaMask began displaying a warning to users attempting to visit these reported domains with their wallets connected, effectively disrupting the campaign.

Further investigation revealed that the phishing emails were sent from six different domains, all belonging to Brazilian media companies that had been hacked by a former employee. This highlighted the importance of informing impacted third parties, as these companies were unaware their infrastructure was being abused.

Demo / Proof of Concept

▶ Watch: Mitigation for credential harvesting: exhausting attacker's Gmail sending quo... (18:00)

While Ramgattie's talk did not feature a live, interactive demonstration in the traditional sense, the entire presentation served as a comprehensive proof of concept for his analytical methodology. He meticulously walked the audience through his step-by-step process of engaging with live phishing infrastructure, illustrating each stage with detailed screenshots and narrative explanations.

For the Proxy AiTM case, he showed:

• The initial HTTP 503 error from Cloudflare when using Burp's built-in browser, contrasting it with the HTTP 200 success when using Firefox.
• Screenshots of the phishing site's login page, including the CAPTCHA slider.
• The "password incorrect" and "success password correct" messages, which were crucial indicators of the proxying behavior.
• Diagrams illustrating the flow of user input being proxied through the phishing site to the legitimate service.

In the Referral Header Leakage and SMTP Log Disclosure case, Ramgattie presented:

• Examples of Referer headers observed in Gemini's logs, pointing back to malicious domains like app.Gemini.web.one.
• Screenshots of the phishing site's error page (error.html).
• A magnified view of the HTTP Location header within the error response, clearly showing the embedded SMTP logs with attacker email addresses. This visual evidence powerfully demonstrated the attacker's misconfiguration.

For the Web3 Wallet Draining scenario, he provided:

• Screenshots of the phishing email, highlighting the unrelated domain and the unique access code.
• The phishing site's landing page requiring the code.
• The subsequent page with the "withdraw" button and the MetaMask connection prompt.
• Crucially, he showed a screenshot of the MetaMask warning that appeared when attempting to visit a reported phishing domain, demonstrating the effectiveness of the eth-phishing-detect project.

Through these visual aids and detailed explanations, Ramgattie effectively demonstrated how he performed the analysis, what he discovered, and how the findings led to actionable defensive measures. The talk itself was a practical guide to "tinkering" with phishing sites to extract intelligence.

Defensive Implications

▶ Watch: Web3 phishing mitigation: leveraging eth-phishing-detect project for domain b... (24:00)

Ramgattie's deep dives into phishing campaigns offer several critical defensive implications for organizations:

1. Rethink Fraud Controls for Critical Actions: Security teams must thoroughly review and stress-test fraud controls for all security-critical actions (e.g., email changes, fund withdrawals, money transfers). It's essential to consider how an Adversary-in-the-Middle (AiTM) attacker, who can proxy 2FA and solve CAPTCHAs, might bypass these controls. Controls that rely solely on a recently authenticated session or a single 2FA event may be insufficient.

1. Strengthen Email Change Procedures: To counter the "magic link" bypass tactic, organizations should implement a control that requires users to **verify access to their original email inbox** before an email address change is finalized. This prevents attackers from redirecting critical verification links to their own controlled inboxes.

1. Proactive Monitoring of HTTP Referrer Headers: Implement robust monitoring of HTTP Referer headers on sensitive pages, particularly login and registration endpoints. The presence of external, unrecognized domains in these headers can be a strong indicator of active phishing campaigns targeting your brand. This provides an early warning system for discovering new phishing infrastructure.

1. Deep HTTP Request/Response Analysis: Train security and incident response teams to perform granular analysis of every HTTP request and response during investigations. As demonstrated by the SMTP log disclosure, attacker misconfigurations can reveal critical intelligence in unexpected places, such as Location headers or error pages. This requires moving beyond high-level log analysis to detailed packet-level inspection.

1. Understand Attacker Evasion Tactics: Be aware that attackers actively employ Web Application Firewalls (WAFs) like Cloudflare, HTTP redirects, CAPTCHAs, and unique access codes to evade automated detection by security vendors and researchers. Automated scanning tools may need to be adapted or supplemented with manual analysis to bypass these controls.

1. Leverage Web3-Specific Security Initiatives: For organizations operating in the Web3 space, traditional takedown mechanisms (registrars, Safe Browsing) may be slow or ineffective against wallet-draining scams. Actively engage with community-driven projects like MetaMask's eth-phishing-detect to report malicious domains for faster disruption and user protection.

1. Inform Impacted Third Parties: When phishing campaigns leverage compromised third-party infrastructure (e.g., hacked email servers), it is crucial to inform the impacted parties. They may be unaware of the compromise, and their cooperation can be vital in disrupting the attacker's operations at the source.

1. Consider Fishing-Resistant MFA: While not a complete solution for all phishing types (especially Web3 wallet draining), deploying phishing-resistant MFA solutions like Passkeys or U2F/FIDO2 security keys (e.g., YubiKeys) can significantly enhance protection against traditional credential-harvesting and AiTM attacks for login flows where they are applicable. However, organizations must also plan for user adoption challenges and fallback mechanisms.

Key Takeaways

• Proactive Analysis is Key: Actively analyzing attacker infrastructure provides invaluable insights into their methods, helping to understand the impact on customers and the effectiveness of existing security controls.
• Review Fraud Controls Critically: Thoroughly examine fraud controls for all security-critical actions, anticipating how sophisticated attackers (e.g., using AiTM) might bypass them, especially by chaining actions like email changes before fund withdrawals.
• Monitor Referrer Headers for Discovery: HTTP Referer headers on your login and registration pages can be a potent, often overlooked, source for discovering new phishing sites targeting your brand.
• Deep Dive into HTTP Traffic: Always analyze every HTTP request and response in detail. Attackers may inadvertently disclose critical information, such as SMTP logs, due to poor server configurations.
• Recognize Attacker Evasion: Be aware that phishing campaigns frequently employ WAFs (like Cloudflare), HTTP redirects, CAPTCHAs, and unique access codes to hinder automated detection and analysis efforts.
• Utilize Web3 Community Defenses: For Web3-specific phishing, leverage community projects like MetaMask's eth-phishing-detect for more agile and effective takedowns than traditional methods.

About the Speaker(s)

Rick Ramgattie is an ABC Engineer at Gemini Trust Company. He has approximately eight years of experience in the application security field. For the first four years of his career, he worked as a security consultant at Independent Security Evaluators. Since then, he has been an integral part of the internal application security team at Gemini. Ramgattie describes his passion for thread hunting as both a hobby and a growing part of his career, driven by his ability to embed with various security teams and gain insights into real-world threats.