Phishing kit rouba credenciais do seu agente IA (Wazza: sofisticado)

Phishing kit rouba credenciais do seu agente IA (Wazza: sofisticado)

Notícia: Researchers descobriram Wazza: phishing kit profissional que não é simples login copy. Tem session management + traffic control + filtering (infraestrutura completa de ataque). Targeting: Banking, manufacturing, government (US, EU, Australia). Implicação: Agentes IA que precisam de credenciais (API keys, bank access, SaaS logins) são alvos ALTOS pra Wazza.

Implicação: Seu agente WhatsApp/vendas que usa credenciais (integra com Salesforce, banco dados, CRM) pode ser phished. Se attacker consegue credenciais do agente = acessa dados sensíveis (customer info, transactions, passwords).

"Você vendeu agente IA pra banco (atende clientes, aprova transações). Agente precisa de credenciais (acesso ao database bancário). Attacker: Envia phishing pro sysadmin (fake email: 'Security update, reconfirme credenciais'). Admin clica, credenciais capturadas (Wazza kit intercepta). Attacker: Agora tem acesso ao database bancário (via agente). Attacker: Vira transferências, rouba R$ 100M. Banco: Processa você (negligência de segurança). Você: Falido. Lição: Agente precisa security (não só funcionalidade). Credenciais = crown jewels (proteja como ouro)."

What this means: Your agent's credentials are a target. Attackers will phish them. If they get them, they get access to your customer data.

Why it matters: Phishing is sophisticated now (session management, not just login copy). You need defense.

---

O problema: Phishing kits evoluíram (não é mais simples login page)

Why Wazza is dangerous (sophisticated phishing infrastructure)

Traditional phishing kit (old, easy to detect):

Attacker flow:

1. Attacker copies bank login page (HTML, CSS, JS)
2. Attacker hosts on malicious domain (looks-like-real-bank.com)
3. Attacker sends email: "Click here to verify account" (phishing link)
4. Victim clicks link → sees fake login page → enters credentials
5. Attacker captures credentials → sells on darknet

Defense is easy:

• Email security (block suspicious emails)
• URL reputation (block malicious domains)
• Browser warning (chrome warns "not secure")
• User awareness ("don't click suspicious links")

Result: Old phishing kits have low success rate (<5%)

Wazza phishing kit (new, sophisticated, hard to detect):

Attacker flow (with Wazza):

1. Attacker copies bank login page (same as before)
2. Attacker adds INFRASTRUCTURE to phishing kit: a. Session management (create fake session, hijack real session) b. Traffic control (filter out security bots, redirect suspicious IPs) c. Credential validation (check if credentials are real before capturing) d. Rate limiting (prevent brute-force detection) e. Logging + exfil (send credentials to attacker C2 server)
3. Attacker hosts on sophisticated infrastructure (not just malicious domain)
4. Attacker targets specific victim (CEO, engineer, not spray-and-pray)
5. Victim: Clicks link → sees login page → enters credentials
6. Wazza kit: Validates credentials (real or fake?), creates session, hijacks
7. Attacker: Now has valid session (not just credentials, actual access)
8. Attacker: Logs in to real system (as victim) → accesses data

Defense is hard:

• Email security: Can't block (email looks legit, from compromised domain)
• URL reputation: Can't detect (infrastructure mimics real domain perfectly)
• Browser warning: Won't trigger (SSL certificate is valid, domain looks real)
• User awareness: Won't help (victim THINKS they're logging into real system)

Result: Wazza has HIGH success rate (>50% against targeted victims)

Key difference: Session management (Wazza = actual access, not just credentials):

Old phishing:

• Victim enters password → Attacker has password
• But password alone = not enough (2FA, session tokens, etc)
• Defender can detect: "Unknown login from unknown IP"
• Victim can revoke session, change password, stop attack

Wazza phishing (session hijacking):

• Victim enters credentials → Wazza kit intercepts
• Wazza: Validates credentials (real or honeypot?)
• Wazza: Creates legitimate session token (via session management)
• Wazza: Gives attacker the session token (not just password)
• Attacker: Logs in with session token (2FA bypassed, looks legitimate)
• Defender: Can't detect (legitimate session, legitimate IP, legitimate behavior)
• Victim: Has no idea (attacker already inside)
• Damage: Happens BEFORE victim realizes (attacker transfers money, steals data)

Why Wazza targets agentes IA (agents need credentials):

Agent threat model:

• Agent integrates with multiple SaaS (Salesforce, HubSpot, database)
• Agent needs credentials to access (API keys, passwords, tokens)
• Credentials stored in agent config (often not encrypted, not rotated)
• If attacker phishes credentials → attacker can impersonate agent
• Attacker: Uses agent's access to steal customer data, make fraudulent changes
• Result: Data breach, compliance violation, customer trust loss

Example (e-commerce agent):

• Agent: Integrates with database (reads customer orders, addresses, emails)
• Agent credentials: Stored in .env file (plaintext or weak encryption)
• Attacker: Phishes employee (fake email: "Update payment method")
• Employee: Enters credentials (Wazza kit intercepts)
• Attacker: Gets database credentials (via Wazza session hijacking)
• Attacker: Queries customer database (100K customers, PII exposed)
• Data breach: GDPR fine = R$ 50M+, customer lawsuit = R$ 500M+
• Root cause: Agente credentials weren't protected

---

Solução: Proteger credenciais do agente (defense strategy)

How to defend agent credentials (3-layer security)

Layer 1: Never store credentials (use token-based auth instead)

python

WRONG: Store credentials in plaintext

class BadAgent: def init(self): self.db_user = "admin" self.db_password = "SuperSecret123" # Stored in plaintext! self.api_key = "sk_live_abc123" # Stored in plaintext!

def connect_database(self):
    # If attacker gets credentials, they have PERMANENT access
    connection = db.connect(
        user=self.db_user,
        password=self.db_password
    )
    return connection

RIGHT: Use tokens with expiration (short-lived)

class SafeAgent: def init(self, token_endpoint: str): self.token_endpoint = token_endpoint self.current_token = None self.token_expiry = None

def get_fresh_token(self) -> str:
    """
    Get fresh token (expires in 1 hour)
    If attacker steals token, only valid for 1 hour
    """
    response = requests.post(
        self.token_endpoint,
        json={"scope": "database:read"},
        headers={"Authorization": f"Bearer {self.refresh_token}"}
    )
    
    self.current_token = response.json()["access_token"]
    self.token_expiry = datetime.now() + timedelta(hours=1)
    
    return self.current_token

def connect_database(self):
    # Check if token expired
    if datetime.now() > self.token_expiry:
        self.get_fresh_token()  # Get new token
    
    # Connect with short-lived token (not permanent credentials)
    connection = db.connect(
        token=self.current_token
    )
    return connection

def revoke_token(self):
    """
    Revoke token immediately (in case of compromise)
    Attacker can't use old token
    """
    requests.post(
        f"{self.token_endpoint}/revoke",
        json={"token": self.current_token}
    )
    self.current_token = None

Example

agent = SafeAgent(token_endpoint="https://auth.company.com/token") token = agent.get_fresh_token() # Get 1-hour token db = agent.connect_database() # Connect with token

Later: Token expires

time.sleep(3600) # 1 hour db = agent.connect_database() # Automatically gets fresh token

If compromise detected

agent.revoke_token() # Invalidate token immediately

Layer 2: Encrypt credentials at rest (if you must store them)

python from cryptography.fernet import Fernet import os

class EncryptedCredentialsManager: """ Store credentials encrypted (not plaintext) """

def __init__(self):
    # Load encryption key from environment (not in code)
    self.encryption_key = os.getenv("CREDENTIAL_ENCRYPTION_KEY")
    self.cipher = Fernet(self.encryption_key)

def store_credential(self, name: str, value: str):
    """
    Encrypt credential before storing
    """
    encrypted = self.cipher.encrypt(value.encode())
    
    # Store in secure database (not .env file)
    db.execute(
        "INSERT INTO encrypted_creds (name, value) VALUES (?, ?)",
        (name, encrypted)
    )
    print(f"[SECURE] Credential '{name}' encrypted and stored")

def retrieve_credential(self, name: str) -> str:
    """
    Decrypt credential when needed
    """
    row = db.execute(
        "SELECT value FROM encrypted_creds WHERE name = ?",
        (name,)
    ).fetchone()
    
    if not row:
        raise ValueError(f"Credential '{name}' not found")
    
    encrypted = row[0]
    decrypted = self.cipher.decrypt(encrypted).decode()
    
    print(f"[SECURE] Credential '{name}' decrypted for use")
    return decrypted

def rotate_credential(self, name: str, new_value: str):
    """
    Rotate credential (change to new value)
    Limits window of exposure if compromised
    """
    # Store old credential (for rollback)
    old_value = self.retrieve_credential(name)
    db.execute(
        "INSERT INTO credential_history (name, value, rotated_at) VALUES (?, ?, NOW())",
        (name, old_value)
    )
    
    # Update to new credential
    self.store_credential(name, new_value)
    
    print(f"[SECURITY] Credential '{name}' rotated")

Example

creds = EncryptedCredentialsManager()

Store credential (encrypted)

creds.store_credential("database_password", "SuperSecret123")

Later: Retrieve credential (decrypted only when needed)

db_password = creds.retrieve_credential("database_password")

Every 30 days: Rotate credential

creds.rotate_credential("database_password", "NewSecret456")

Layer 3: Monitor credential usage (detect compromise early)

python class CredentialAuditTrail: """ Log all credential usage (detect suspicious access) """

def __init__(self):
    self.audit_log = []

def log_credential_access(self, credential_name: str, context: dict):
    """
    Log when credential is accessed
    """
    entry = {
        "timestamp": datetime.now().isoformat(),
        "credential": credential_name,
        "source_ip": context.get("ip_address"),
        "user_agent": context.get("user_agent"),
        "action": context.get("action", "accessed"),
        "success": context.get("success", True)
    }
    
    self.audit_log.append(entry)
    
    # Check for suspicious patterns
    self._check_for_compromise(credential_name, entry)

def _check_for_compromise(self, credential_name: str, entry: dict):
    """
    Detect unusual access patterns (sign of compromise)
    """
    # Check 1: Access from unusual IP
    known_ips = ["192.168.1.1", "203.0.113.5"]  # Expected IPs
    if entry["source_ip"] not in known_ips:
        self._alert(f"SUSPICIOUS: {credential_name} accessed from unknown IP {entry['source_ip']}")
    
    # Check 2: Access at unusual time
    hour = datetime.now().hour
    if hour not in range(9, 18):  # Outside business hours
        self._alert(f"SUSPICIOUS: {credential_name} accessed outside business hours")
    
    # Check 3: Rapid access (brute force?)
    recent_accesses = len([log for log in self.audit_log 
                           if log["credential"] == credential_name 
                           and (datetime.now() - datetime.fromisoformat(log["timestamp"])).seconds < 60])
    if recent_accesses > 10:
        self._alert(f"SUSPICIOUS: {credential_name} accessed 10+ times in 1 minute (brute force?)")
    
    # Check 4: Failed access attempts
    if not entry["success"]:
        failed_count = len([log for log in self.audit_log 
                            if log["credential"] == credential_name 
                            and not log["success"]])
        if failed_count > 5:
            self._alert(f"SUSPICIOUS: {credential_name} failed {failed_count} times (compromise attempt?)")

def _alert(self, message: str):
    """
    Send security alert (email, Slack, etc)
    """
    print(f"[SECURITY_ALERT] {message}")
    # Send to security team
    # requests.post("https://security-monitoring.company.com/alert", json={"message": message})

Example

audit = CredentialAuditTrail()

Agent accesses database with credential

audit.log_credential_access( credential_name="database_password", context={ "ip_address": "192.168.1.1", "user_agent": "Agent/v1.0", "action": "database_query", "success": True } )

Suspicious: Same credential accessed from unknown IP

audit.log_credential_access( credential_name="database_password", context={ "ip_address": "123.45.67.89", # Unknown IP! "user_agent": "Mozilla/5.0", # Different user agent! "action": "data_export", "success": True } ) # -> Alert: SUSPICIOUS access from unknown IP

---

Defense checklist (before agent goes to production)

Credential security:

□ Never hardcode credentials

• No passwords in code (especially GitHub)
• No API keys in .env files (only encryption keys)
• No secrets in config files

□ Use token-based auth (short-lived)

• Implement OAuth 2.0 or similar
• Tokens expire in 1 hour (max)
• Refresh tokens rotate with each use
• Can revoke tokens immediately if compromised

□ Encrypt credentials at rest

• AES-256 encryption (minimum)
• Encryption keys stored separately (HSM, KMS)
• Never decrypt unless needed
• Decrypt only in memory (not on disk)

□ Rotate credentials regularly

• Every 30-90 days (passwords)
• Every 6-12 months (API keys)
• Immediately if compromise suspected
• Automatic rotation (not manual)

□ Monitor credential usage

• Log all access (who, when, where, what)
• Alert on suspicious patterns
• Immutable audit trail (can't be deleted)
• Review audit logs monthly

□ Implement principle of least privilege

• Agent only gets access it needs (not admin)
• Database user: Read-only (not write/delete)
• API key: Limited scopes (not full access)
• Separate credentials per service

□ Secure credential storage

• Use password manager (1Password, HashiCorp Vault)
• Or cloud secret manager (AWS Secrets Manager, GCP Secret Manager)
• Not plaintext files, not Git repos, not email
• Access controlled (only authorized users)

□ Test credential security

• Simulate phishing attacks (red team test)
• See if attacker can extract credentials
• Test if tokens can be hijacked
• Verify audit logging works

Anti-phishing measures:

□ Email security

• SPF, DKIM, DMARC (prevent domain spoofing)
• Link rewriting (detect malicious URLs)
• Credential detection (alert on unusual access)
• Employee training (recognize phishing)

□ Network security

• VPN requirement (for production access)
• IP whitelist (only known IPs can access)
• Anomaly detection (unusual access pattern)
• Rate limiting (prevent brute force)

□ Application security

• HTTPS only (encrypt in transit)
• Certificate pinning (prevent MITM attacks)
• Input validation (prevent injection attacks)
• Output encoding (prevent XSS attacks)

□ Incident response

• Plan written (what to do if phished)
• Team trained (who does what)
• Communication plan (who to notify)
• Rollback procedure (how to recover)

□ Compliance

• SOC 2 audit (verify security controls)
• Penetration testing (annual, by third party)
• Vulnerability scanning (continuous)
• Risk assessment (identify weaknesses)

---

Real-world example: How Wazza could compromise your agent

Scenario: SaaS company has customer support agent (integrates with Salesforce)

What happened (actual attack):

Day 1:

• Attacker researches company (finds support team email addresses)
• Attacker: Creates phishing email (looks like Salesforce password reset)
• Subject: "Security Alert: Unusual login attempt on your Salesforce account"
• Body: "Click here to verify your identity and secure your account"
• Link: "https://salesforcelogin-verify.com/auth" (looks legit, but fake)

Day 2:

• Support engineer gets email
• Engineer: Worried about security (recent news about hacks)
• Engineer: Clicks link → sees Salesforce login page
• Engineer: Enters username + password (appears to work)
• Behind scenes: Wazza kit intercepts, validates credentials, creates session
• Attacker: Gets session token (can now log in as engineer)

Day 3:

• Attacker logs into Salesforce (via session token)
• Attacker: Looks like legitimate login (same IP as company, same user agent)
• Attacker: Exports customer database (all 100K customers, contact info)
• Attacker: Creates new API key (for future access)
• Attacker: Exports all conversations (sensitive customer details)

Day 4:

• Attacker: Discovers agent configuration (stored in Salesforce)
• Agent credentials: Database password, API keys
• Attacker: Exports agent credentials (now has full system access)

Day 5:

• Attacker: Uses agent credentials to access customer database directly
• Attacker: Queries sensitive data (payment info, PII)
• Attacker: Sells data on darknet (R$ 500K)

Day 10:

• Company discovers breach (customer complaint: "My data is online")
• Damage: 100K customers affected, GDPR fine = R$ 50M+, lawsuit = R$ 500M+
• Root cause: Support engineer fell for phishing (Wazza kit was sophisticated)
• Lesson: Agent credentials weren't protected (no encryption, no rotation, no monitoring)

What should have happened (with proper security):

Day 1 (same):

• Attacker sends phishing email

Day 2:

• Support engineer clicks link → sees Salesforce login
• Engineer enters credentials
• Wazza kit tries to intercept → BUT...
• Detection 1: Unusual IP access (not company VPN) → Alert sent
• Detection 2: Credential access outside business hours → Alert sent
• Detection 3: Session created from unknown location → Session blocked
• Engineer: Prompted to verify in app ("Are you logging in right now?")
• Engineer: Realizes it's not a real login → Doesn't proceed
• Attacker: Gets nothing

Day 3:

• Security team reviews alerts
• Security team: Changes engineer's Salesforce password
• Security team: Rotates all agent credentials
• Security team: Reviews audit logs (finds phishing attempt)
• Security team: Notifies engineer ("You were phished, here's training")

Day 4+:

• Attacker has nothing (credentials were rotated, session was revoked)
• No data breach
• Zero damage
• Lesson: Multi-layer security prevented compromise

---

Conclusão: Wazza phishing = credential security is existential

Hard truth: Phishing is sophisticated now. Attackers use Wazza kit (session management, traffic control) to hijack credentials and sessions. Your agent's credentials are valuable targets.

Your agent needs security (not just functionality):

1. Never store credentials (use short-lived tokens instead)
2. Encrypt credentials (if you must store them)
3. Monitor access (alert on suspicious patterns)
4. Rotate regularly (limit window of exposure)
5. Test defenses (phishing simulation, pen testing)

If you don't:

• Attacker phishes credentials → Gets access to agent
• Attacker uses agent → Steals customer data
• You get fined → GDPR/compliance fines = R$ 50M+
• You get sued → Customer lawsuit = R$ 500M+
• Company goes bankrupt

Action items (implement now):

1. Audit agent credentials (are they stored in plaintext?)
2. Implement token-based auth (short-lived, rotatable)
3. Setup credential encryption (AES-256, HSM-backed)
4. Enable audit logging (all credential access)
5. Test phishing defenses (send fake phishing email to team)
6. Train employees (recognize phishing, report immediately)
7. Implement 2FA (for all production access)
8. Setup alerts (unusual credential access)

De agente "vulnerável a phishing" (Wazza = game over) pra agente "hardened against phishing" (protected credentials, audit logging, anomaly detection) → OpenClaw Agent Security Framework

Seu agente ainda não tem credential security? Implemente AGORA. Antes de ser phished. 🚀