How Grey-Hat Facebook Tools Actually Work: Tokens, Cookies, and RPA

Grey-hat Facebook tools are not magic. They exploit three specific technical mechanisms to control Facebook ad accounts outside of Meta's official authorization framework. Understanding how grey hat facebook tools work at a technical level is essential for any media buyer — whether you use them, compete against people who do, or need to evaluate the security implications for your own accounts.

This is a technical deep-dive. We will cover the exact mechanisms, data flows, and detection vectors for each method. No moral commentary — just engineering reality.

The Three Pillars of Grey-Hat Access

Every grey-hat Facebook advertising tool relies on one or more of these three access methods:

1. Token extraction and abuse — Using EAAB tokens to call Facebook's Marketing API without official OAuth authorization
2. Cookie injection — Importing session cookies to hijack authenticated browser sessions
3. RPA (Robotic Process Automation) — Controlling the Facebook web UI through automated browser actions

Some tools use a single method. The most sophisticated tools combine all three. Let us examine each in detail.

Pillar 1: EAAB Tokens

What EAAB Tokens Are

When you log into Facebook and access Ads Manager, your browser session generates access tokens that authorize API requests. The most valuable of these is the EAAB (Extended Access) token — a long-lived token that begins with the literal string "EAAB" followed by a base64-encoded payload.

An EAAB token encodes:

• The user ID of the authenticated Facebook user
• The app ID of the application that generated the token (usually Facebook's own Ads Manager app)
• Permission scopes — what the token is authorized to do (ads_management, ads_read, business_management, etc.)
• An expiration timestamp — typically 60-90 days for long-lived tokens
• A cryptographic signature that Meta validates on every API call

With a valid EAAB token, you can make the same API calls that Facebook's own Ads Manager makes. Create campaigns, modify budgets, upload creatives, pull insights, manage payment methods — everything.

How Tokens Are Extracted

Method 1: Chrome Extension Extraction

The most common extraction method uses Chrome extensions that intercept network requests within the browser. When you open Ads Manager, your browser makes API calls to graph.facebook.com with the EAAB token in the Authorization header or as a URL parameter.

A Chrome extension with webRequest permissions can intercept these requests and extract the token. The flow:

User opens Ads Manager → Browser makes API call → Extension intercepts request →
Token extracted from header/URL → Stored locally or sent to external server

Extensions like "Facebook Token Extractor" (various names, frequently removed from Chrome Web Store) automate this process. Some grey-hat tools include their own branded extensions.

Method 2: Cookie-to-Token Conversion

Facebook's session cookies can be used to generate tokens programmatically. The process:

1. Extract the c_user and xs cookies from an authenticated session
2. Make a request to Facebook's OAuth endpoint using those cookies as authentication
3. Request token generation for the Ads Manager app ID
4. Receive a fresh EAAB token

This method is how tools that work with cookie imports (see Pillar 2) convert session access into API access.

Method 3: OAuth Abuse

Some tools register as legitimate Facebook developer applications, then abuse the OAuth flow to request excessive permissions. The user authorizes the app thinking it is a legitimate tool, and the app stores and uses the token for unauthorized purposes.

This has become less viable as Meta has tightened app review processes, but legacy apps with broad permissions still exist.

How Tools Use Tokens

Once extracted, the token is used to make direct API calls to Facebook's Marketing API:

Campaign Creation:

POST /act_{ad_account_id}/campaigns
Authorization: Bearer EAAB...
Content-Type: application/json

{
  "name": "Campaign Name",
  "objective": "OUTCOME_SALES",
  "status": "ACTIVE",
  "special_ad_categories": []
}

Ad Set Creation:

POST /act_{ad_account_id}/adsets
Authorization: Bearer EAAB...

{
  "campaign_id": "123456",
  "name": "Ad Set Name",
  "targeting": { ... },
  "billing_event": "IMPRESSIONS",
  "bid_amount": 1000,
  "daily_budget": 5000
}

Creative Upload:

POST /act_{ad_account_id}/adcreatives
Authorization: Bearer EAAB...

{
  "name": "Creative Name",
  "object_story_spec": { ... }
}

The API calls are identical to what legitimate tools make. The difference is the authorization path — legitimate tools obtained the token through Facebook's official OAuth flow with user consent and app review. Grey-hat tools extracted it from a browser session.

Token Lifespan and Rotation

EAAB tokens have a built-in expiration, typically 60-90 days. However, several factors can invalidate a token earlier:

• Password change — All tokens for the account are immediately invalidated
• Security checkpoint — Facebook's security systems can invalidate tokens when suspicious activity is detected
• Session termination — User logging out of all sessions invalidates associated tokens
• App deauthorization — Removing app permissions invalidates tokens issued to that app

Grey-hat tools handle token expiration through:

• Automatic re-extraction — Chrome extensions running in the background continuously extract fresh tokens
• Token refresh endpoints — Some tools use undocumented Facebook endpoints to extend token lifespan
• Cookie fallback — When a token expires, the tool falls back to cookie-based session access to generate a new token

Detection Signals for Token Abuse

Meta detects unauthorized token usage through several signals:

1. App ID mismatch — Tokens generated by Facebook's own apps (Ads Manager, Business Suite) carry specific app IDs. Meta can detect when these tokens are used from unexpected origins
2. Request pattern analysis — Human users of Ads Manager create one campaign at a time with pauses. Tools create dozens in rapid succession
3. IP correlation — The token was generated from one IP (the user's browser) but API calls come from another IP (the tool's server)
4. Missing browser context — Legitimate Ads Manager API calls include browser headers, timing patterns, and associated web socket connections. Raw API calls from tools lack this context
5. Volume anomalies — Creating 50 campaigns across 50 accounts in 5 minutes from a single application signature

Pillar 2: Cookie Injection

The Relevant Cookies

When you log into Facebook, your browser receives several authentication cookies. The two critical ones:

c_user — Contains the numeric Facebook user ID. This tells Facebook which account the session belongs to.

xs — The session token. This is the actual authentication credential. It is a complex encoded string that includes session metadata and a cryptographic signature.

Together, these two cookies constitute a complete Facebook session. Any browser that presents these cookies to facebook.com will be recognized as the logged-in user — no password required.

Additional relevant cookies:

• fr — Facebook's cross-site tracking cookie
• datr — Browser identification cookie (persists across sessions)
• sb — Browser identification, similar to datr
• presence — Chat/messaging presence indicator

How Cookie Injection Works

The injection process:

1. Export: Cookies are extracted from the source browser session. This can be done via browser developer tools, extensions, or programmatic access to the cookie store. The output is typically in Netscape cookie format or JSON:

{
  "name": "c_user",
  "value": "100012345678",
  "domain": ".facebook.com",
  "path": "/",
  "httpOnly": true,
  "secure": true,
  "sameSite": "None",
  "expirationDate": 1742515200
}

2. Transfer: The cookie data is moved to the target environment — an anti-detect browser profile, a tool's account database, or a shared team repository.

3. Import: The receiving browser loads the cookies into its cookie store for the facebook.com domain. This is typically done before navigating to Facebook, so the first page load is already authenticated.

4. Session Validation: The browser navigates to facebook.com. Facebook's servers validate the cookies and serve the authenticated user experience.

Why Cookie Injection Is Popular

Cookie injection serves several purposes in the grey-hat ecosystem:

Account Management Without Passwords: Media buyers who purchase accounts from marketplaces receive cookies, not passwords. The original password may be unknown or changed. Cookie injection is the only way to access these accounts.

Multi-Account Operations: Managing 50+ Facebook accounts would require 50+ email/password combinations. Cookies are more portable — paste a cookie string, and the profile is ready.

Avoiding Login Triggers: Every Facebook login from a new device/location triggers security checks — verification codes, CAPTCHA, identity verification. Cookie injection skips the login process entirely, avoiding these triggers.

Session Persistence: Cookies maintain sessions across browser restarts. A properly configured anti-detect browser profile with injected cookies can maintain a Facebook session for weeks without re-authentication.

Cookie Formats and Tooling

Grey-hat tools accept cookies in several formats:

• Netscape format: The oldest cookie export format. Plain text, one cookie per line. Universal compatibility.
• JSON format: Structured, used by most modern tools. Each cookie is a JSON object with all attributes.
• Base64-encoded string: Some marketplaces sell cookies as a single encoded string that tools decode automatically.
• Browser profile export: Anti-detect browsers can export entire profiles including cookies, localStorage, and IndexedDB.

Tools for Cookie Management:

• EditThisCookie (Chrome extension) — Manual cookie export/import
• Cookie-Editor — Similar functionality, more maintained
• Anti-detect browser importers — AdsPower, GoLogin, Multilogin all have built-in cookie import dialogs
• Custom scripts — Puppeteer's page.setCookie() API allows programmatic cookie injection

Cookie Security and Risks

Cookie injection carries significant security risks:

Cookie Theft: If someone obtains your Facebook cookies, they have full access to your account. Cookies sold on marketplaces may have been stolen via malware, phishing, or data breaches — not voluntarily exported by account owners.

Session Hijacking: Facebook cannot distinguish between the original user and someone who injected their cookies. There is no two-factor authentication checkpoint for cookie-based session access.

Cascading Compromise: If a tool's database is breached, every stored cookie becomes accessible to attackers. The AdsPower breach in December 2024 demonstrated this risk — the compromised Chrome extension accessed users' session data across multiple platforms.

Expiration and Invalidation: Cookies expire. Facebook periodically rotates session tokens. A cookie that works today may not work tomorrow, creating a constant need for fresh cookies — and a constant market for cookie providers.

Pillar 3: RPA (Robotic Process Automation)

What RPA Means in This Context

RPA in Facebook advertising means software that controls the Facebook web interface by simulating human actions. Instead of calling APIs with tokens, RPA tools open a browser, navigate to Ads Manager, click buttons, fill forms, and submit campaigns — exactly as a human would, but faster.

The Technology Stack

Browser Automation Frameworks:

• Puppeteer — Node.js library for controlling Chromium. The most common framework for Facebook automation
• Playwright — Microsoft's multi-browser automation library. Supports Chromium, Firefox, and WebKit
• Selenium — Older framework, still used in some tools. Slower but mature

Integration with Anti-Detect Browsers:

Anti-detect browsers expose automation interfaces that Puppeteer/Playwright can connect to. The flow:

Anti-Detect Browser (unique fingerprint) → Puppeteer connects via CDP →
Script navigates Facebook UI → Actions executed as if by human user

AdsPower, for example, exposes a Chrome DevTools Protocol (CDP) endpoint for each profile. A Puppeteer script connects to this endpoint and has full control over the browser session — with the anti-detect fingerprint intact.

How Autolaunch Works via RPA

The "autolaunch" (автозалив) workflow through RPA:

1. Profile selection: Script selects an anti-detect browser profile with an active Facebook session
2. Navigation: Browser opens facebook.com/adsmanager/creation
3. Campaign setup: Script fills in objective, budget, schedule
4. Ad set configuration: Targeting, placement, optimization goal
5. Creative upload: Image/video upload, ad copy, URL, CTA
6. Review and publish: Submit campaign for review
7. Loop: Repeat for next account/profile

Each step involves:

• Element detection: Finding the correct button, input field, or dropdown by CSS selector, XPath, or ARIA label
• Human-like interaction: Adding random delays between actions (200-2000ms), moving the mouse naturally, scrolling to elements before clicking
• Error handling: Detecting popups, CAPTCHA challenges, account restrictions, and handling each case
• Verification: Confirming each step completed successfully before proceeding

Advantages of RPA Over Token Access

Lower Detection Risk: RPA generates genuine browser events — mouse movements, keyboard input, scroll events, focus changes. Meta's detection systems see a browser session that looks human.

No Token Dependency: RPA does not need an EAAB token. It works with any authenticated browser session (including cookie-based sessions).

UI Change Resilience: Advanced RPA tools use visual element recognition rather than fixed CSS selectors. If Facebook moves a button, the tool can still find it by its visual appearance.

Full Feature Access: The Facebook UI exposes features that the Marketing API does not — certain targeting options, creative tools, and account settings are UI-only.

Disadvantages of RPA

Speed: RPA is inherently slower than API calls. Creating a campaign via API takes 1-3 seconds. Via RPA, it takes 30-120 seconds including human-like delays.

Fragility: Facebook's UI changes frequently. A class name change, a layout shift, or a new modal dialog can break scripts. Maintenance burden is high.

Scale Limitations: Each RPA operation requires a browser instance. Running 50 simultaneous campaign creations requires 50 browser instances — significant CPU and RAM consumption.

Error Recovery: When something goes wrong mid-process (unexpected popup, page load failure, element not found), recovery is complex. Token-based API calls fail cleanly with error codes. RPA failures can leave browser sessions in unknown states.

Hybrid Approaches

The most sophisticated grey-hat platforms combine all three methods:

1. Cookie injection to establish sessions in anti-detect browser profiles
2. Token extraction from those sessions for fast API operations
3. RPA fallback for operations that require browser interaction or when tokens are flagged

This layered approach provides maximum flexibility. Dolphin Cloud, for example, can create campaigns via token API calls for speed, fall back to RPA when API patterns trigger detection, and use cookie injection to maintain persistent sessions across dozens of accounts.

The Detection Arms Race

Meta invests heavily in detecting unauthorized tool usage. The detection signals span all three access methods:

Behavioral Analysis

• Campaign creation patterns that are too uniform (same structure, timing, naming conventions)
• Activity hours that do not match the account's historical patterns
• Simultaneous activity across multiple accounts that correlates (same creatives, same targeting, same timing)

Technical Signals

• API requests without proper app signatures
• Browser fingerprints that are statistically too unique (ironically, anti-detect browsers can create fingerprints that are too perfect)
• WebGL renderer strings that do not match reported hardware
• Timezone mismatches between fingerprint, IP, and account settings

Network Analysis

• Multiple accounts accessed from the same IP range
• Proxy usage patterns (residential proxies from providers known for ad fraud)
• Geographic impossibilities (account logged in from two continents within minutes)

Creative and Content Analysis

• Identical or near-identical ad creatives across accounts
• Landing pages that match known cloaking patterns
• Ad copy similarity clustering across flagged accounts

Each detection improvement by Meta triggers countermeasures from tool developers — new fingerprinting techniques, improved behavioral simulation, more sophisticated obfuscation. This arms race is continuous and accelerating.

The Official Alternative

For media buyers who want the automation capabilities without the technical risks, tools like AdRow provide official Marketing API access with:

• OAuth-based authentication — no tokens to extract, no cookies to inject
• Bulk campaign operations — create and manage campaigns at scale through the documented API
• Automated rules — conditional logic that acts on campaigns based on performance data
• Zero detection risk — all operations are authorized and expected by Meta's systems

The complete ecosystem map provides broader context on where these tools fit, and the autolaunch explainer covers the specific campaign creation workflows in detail.

Understanding how grey-hat tools work is not an endorsement of using them. It is technical literacy that every serious media buyer should have — because your competitors certainly do.