7 minmedium
Facebook Phishing Attacks: How Credential Theft Works
Zscaler ThreatLabz identified six Facebook phishing domains registered on 02/13/2011 by the same individual in China. The domains host identical fake Facebook login pages that capture user credentials before redirecting victims to legitimate Facebook or Google. The campaign leverages fast-flux DNS with rapidly rotating IP addresses and a shared DNS server (fbnameserver.com) previously tied to other Facebook phishing operations, making takedowns and blocklisting difficult.
Conf:highAnalyzed:2026-07-30
Showing defanged values
- domaindirectsecuresite[.]comPhishing domain hosting fake Facebook login page; registered 02/13/2011 by same individual in China
- domainfbnameserver[.]comShared DNS nameserver used by all phishing domains; previously associated with other Facebook phishing campaigns
- domainhighsecuritydirect[.]comPhishing domain hosting fake Facebook login page; registered 02/13/2011 by same individual in China
- domainofficialsecuredsite[.]comPhishing domain hosting fake Facebook login page; registered 02/13/2011 by same individual in China
- domainsecuredirectsite[.]comPhishing domain hosting fake Facebook login page; registered 02/13/2011 by same individual in China
- domainsecuredsitedirect[.]comPhishing domain hosting fake Facebook login page; registered 02/13/2011 by same individual in China
Detection / Hunteropenrouter
What Happened
Attackers created fake websites that look like the Facebook login page to trick people into entering their username and password. When someone types their credentials into these fake pages, the attackers capture them. The victims are then redirected to the real Facebook or Google website so they don't realize they've been tricked. The attackers used a technique called fast-flux DNS, which constantly changes the server addresses behind the fake domains, making it very hard for security teams to shut them down. Anyone who uses Facebook could be affected if they click on a suspicious link. This matters because stolen login details can be used to take over accounts, impersonate people, or send more phishing messages. Users should carefully check web addresses before entering passwords and enable multifactor authentication (a second login step) on their accounts.
Key Takeaways
- Multiple Facebook phishing domains registered on the same day by the same individual in China, all hosting identical fake login pages.
- Domains employ fast-flux DNS with rapidly changing IP addresses to evade takedown and complicate blocklisting.
- Shared DNS infrastructure via fbnameserver.com, previously associated with other Facebook phishing campaigns.
- Phishing pages redirect victims to legitimate Facebook or Google after credential capture to avoid suspicion.
- As of 02/16/2011, these domains were not yet blocked by Google Safe Browsing.
Affected Systems
- Facebook users (any platform)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Victim clicks a link directing them to one of the phishing domains (e.g., securedirectsite.com)
- Credential Capture: Fake Facebook login page collects username and password from the victim
- Redirection: Victim is redirected to legitimate Facebook or Google to avoid suspicion
- Infrastructure Evasion: Domains use fast-flux DNS with rapidly rotating IPs and shared nameserver (fbnameserver.com) to resist takedown
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules or queries are provided in the article. The article is an informational blog post describing phishing infrastructure and IOCs.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | This is a phishing campaign involving web-based credential theft. EDR telemetry is not directly relevant since the attack occurs in the browser, not on the endpoint via malware execution. |
| Network Visibility | High | DNS resolution to the phishing domains and HTTP connections to those domains are fully observable via network telemetry (DNS logs, proxy logs, web gateway logs). Fast-flux DNS behavior (rapidly changing A records) is also detectable via passive DNS analysis. |
| Detection Difficulty | Easy | The phishing domains and shared DNS server are explicitly identified. Blocking these domains and alerting on DNS resolutions is straightforward. Fast-flux behavior adds complexity to IP-based blocking but domain-based detection remains effective. |
Required Log Sources
- DNS query logs
- Web proxy/SWG logs
- Passive DNS data
- Threat intelligence feed blocklists
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for DNS queries to domains registered recently that mimic legitimate social media login pages, particularly those containing keywords like 'secure', 'direct', or 'official' combined with social media brand names. | DNS query logs, passive DNS, domain registration (WHOIS) data | Initial Access | Low — newly registered domains with these naming patterns are uncommon in normal enterprise traffic |
| Consider hunting for domains resolving to rapidly changing sets of IP addresses (fast-flux behavior), which may indicate phishing or malware infrastructure. | Passive DNS, DNS response logs, threat intelligence platforms | Infrastructure | Low — fast-flux DNS is rare in legitimate infrastructure, though some CDN behaviors may superficially resemble it |
| Consider hunting for HTTP POST requests to non-Facebook domains containing form fields named like 'email' or 'pass' that mimic Facebook's login form parameters. | Web proxy logs, SWG inspection logs, full packet capture | Credential Capture | Medium — legitimate web applications also use login forms; correlation with domain reputation and registration age is needed to reduce false positives |
Control Gaps
- IP-based blocklisting alone would be ineffective due to fast-flux DNS rapidly rotating IP addresses
- Google Safe Browsing did not block these domains as of the article date, leaving browser-based protections insufficient
- DNS-level filtering would need to target the domain and nameserver rather than individual IPs
Key Behavioral Indicators
- Multiple domains registered on the same day by the same registrant with similar naming patterns (secure/direct/official)
- Shared DNS nameserver (fbnameserver.com) across multiple phishing domains
- Fast-flux DNS behavior — domain A records changing rapidly across many IPs
- HTTP POST to non-Facebook domain containing credential-like form fields followed by redirect to facebook.com or google.com
False Positive Assessment
Low — the identified domains have clear phishing intent with no legitimate purpose. The naming patterns and shared infrastructure provide strong indicators of malicious activity. However, the domains are from 2011 and may no longer be active.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider blocking the identified phishing domains and the shared DNS server (fbnameserver.com) at your DNS resolver, web proxy, or SWG if still relevant to your environment.
- If your organization uses a threat intelligence feed, consider submitting these domains and the DNS server to your TI platform for tracking and cross-referencing against historical campaign data.
- If applicable, consider checking proxy and DNS logs for any historical traffic to the identified domains to identify potentially compromised users.
Infrastructure Hardening
- Consider implementing DNS filtering or response policy zones (RPZ) to block known phishing domains at the resolver level.
- Evaluate whether your web proxy or SWG can perform real-time analysis of newly registered domains and flag domains with suspicious naming patterns mimicking legitimate services.
- If supported by your tooling, consider monitoring for fast-flux DNS behavior in your environment's DNS traffic as an indicator of malicious infrastructure.
User Protection
- Consider enabling multifactor authentication (MFA) on all social media and critical accounts to limit the impact of credential theft.
- If your organization manages browser security, consider evaluating whether your web filtering solution blocks newly registered domains that impersonate well-known services.
- Consider deploying browser-based anti-phishing extensions or ensuring Safe Browsing protections are enforced via policy.
Security Awareness
- Consider incorporating this phishing pattern into existing security awareness training — emphasize verifying the URL before entering credentials on any login page.
- If your organization has a phishing reporting program, consider reminding users to report suspicious login pages, especially those reached via unsolicited links.
- Consider educating users that legitimate services will not ask for credentials on domains other than their official domain (e.g., facebook.com).
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping3 techniques
Tactic
Initial Access
Tactic
