Notícias
Notícias
5 min de leitura
17 de outubro de 2026

Uma credencial M365 vazou: 173 clientes hackeados

ConnectWise: uma credencial M365 vazou. 173 tenants hackeados (supply chain attack). Seu SaaS integra M365? Risco real.

Equipe OpenClaw

Equipe OpenClaw · Time de Engenharia & Produto

A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…


Uma credencial M365 vazou: 173 clientes hackeados

Cenário que ninguém fala (mas está acontecendo AGORA):

Você é founder de SaaS com agent (atendimento, automação, integração).

Seu SaaS integra com M365 (Outlook, Teams, SharePoint, etc).

Por quê?

  • Clientes usam M365 (ubíquo em empresas)
  • Você integra pra ler emails (support tickets)
  • Você integra pra enviar emails (respostas)
  • Você integra pra agendar meetings
  • Você integra pra acessar dados (documentos, sharepoint)

Pergunta:

Onde você guarda as credenciais M365 dos clientes?

Resposta (honesta):

Você não sabe (exatamente).

Opção A: Em seu database (encrypted) Problem: if hacker gets database, gets credentials

Opção B: Em um vault (Hashicorp, AWS Secrets Manager) Problem: if hacker gets vault access, gets credentials

Opção C: Distribuído com terceiros (como sua infraestrutura) Problem: if THIRD PARTY gets hacked, credentials leak

Opção D: Apenas tokens (OAuth2) Problem: if third party gets hacked, tokens leaked (attackers can impersonate your app)

Realidade:

Você está confiando em:

  1. Sua segurança (OK, talvez)
  2. Seus fornecedores (menos OK)
  3. Seus fornecedores de fornecedores (definitivamente NOT OK)

Isso é chamado: supply chain attack


What happened: ConnectWise security breach

The incident (October 2026)

Timeline:

ConnectWise Cloud Backup (SkyKick):

  • Backup service for M365
  • Used by MSPs (managed service providers)
  • Stores M365 credentials (to backup customer data)

What happened:

  • Attacker compromised ONE credential (belonging to ConnectWise Cloud Backup)
  • Used that credential to sign into M365 tenants
  • Gained access to 173 customer environments
  • Accessed emails, files, data

Scale:

  • One credential compromised
  • 173 customers affected
  • Unknown how many attackers
  • Unknown how long they had access
  • Unknown what data was stolen

Why this is terrifying:

Normal attack:

  • Attacker: targets Company A
  • Effort: high (social engineering, finding vulnerability)
  • Result: maybe 1 company hacked

Supply chain attack (ConnectWise):

  • Attacker: targets ConnectWise (backup provider)
  • Effort: medium (one credential)
  • Result: 173 companies hacked (instantly)

Difference: 173x impact with LESS effort

Why credentials get compromised

Common reasons:

  1. Phishing

    • Attacker sends email: "Urgent: verify your password"
    • Employee clicks, enters password
    • Attacker now has credential
    • Example: ConnectWise employee might have clicked
  2. Malware

    • Employee's laptop gets infected
    • Malware logs all keystrokes
    • Attacker captures password
  3. Weak password

    • ConnectWise using: "Password123" (example)
    • Attacker guesses or uses dictionary attack
  4. Password reuse

    • ConnectWise employee uses same password everywhere
    • Password leaked from GitHub (common)
    • Attacker tries same password on M365
    • Works!
  5. No MFA (multi-factor authentication)

    • Even if password leaked: attacker can't login (without MFA)
    • If NO MFA: attacker logs in freely
  6. Insider threat

    • Disgruntled employee sells credentials

Why 173 companies were affected (not just 1)

The leverage problem:

ConnectWise Cloud Backup stores:

  • M365 credentials for 1000+ customers
  • In one place (their database)

If hacker gets 1 credential:

  • It's the MASTER credential (for backup service)
  • Uses it to access M365
  • Then accesses ALL 173 customers

It's like:

  • You have 173 houses
  • All protected by 1 master key
  • Hacker gets master key
  • Breaks into all 173 houses

The risk: why your SaaS is exposed

Your supply chain (you're not secure)

Your architecture (typical):

Customer ↓ Your SaaS ↓ M365 (via credential) ↓ Customer data (emails, files, calendar)

Trust chain: ✓ Customer trusts your SaaS ✓ You trust your infrastructure ✗ Your infrastructure trusts 10+ third parties: - Cloud provider (AWS, Azure, etc) - Secrets manager (Vault, AWS Secrets) - CI/CD pipeline (GitHub, GitLab) - Logging service (Datadog, etc) - Monitoring (New Relic, etc) - Backup service (your own + backup providers) - And 5 more...

Problem: you're only as secure as your weakest link

Example:

  • Your security: 9/10 (good)
  • AWS security: 9.5/10 (excellent)
  • GitHub security: 9/10 (good)
  • Your logging provider: 6/10 (average) ← THIS IS THE WEAK LINK

Hacker: bypasses the 9-9.5, exploits the 6 Result: your M365 credentials leak

The ConnectWise angle (directly relevant)

If your SaaS uses ConnectWise:

You (SaaS): → integrate with ConnectWise Cloud Backup (for customer data backup) → provide M365 credentials to ConnectWise (so they can backup M365 data)

ConnectWise gets hacked: → Your M365 credentials leak → Your customers' data accessed → Your SaaS is now liable → LGPD fine: R$ 1M - R$ 50M → Customer lawsuits: R$ 10M+ → Reputation destroyed

Even if you don't use ConnectWise

You're still at risk:

Your supply chain includes:

  • Cloud provider (store credentials)
  • Secrets manager (store credentials)
  • CI/CD pipeline (passes credentials)
  • Monitoring service (sees credential usage)
  • Backup service (stores backups with credentials)
  • Support team access (to debug issues)
  • Former employees (who had access)

Each is a potential breach point If ANY gets compromised: → Your M365 credentials leak → Customer data accessed → You're liable


The fallout: legal + financial

LGPD compliance (Brazil)

If M365 credentials leak + customer data accessed:

LGPD violation:

  • Unauthorized access to personal data
  • Fine: 2% of revenue (annual) up to R$ 50M

Example:

  • Your SaaS revenue: R$ 10M/year
  • Fine: 2% × R$ 10M = R$ 200k
  • Plus: remediation costs, notification costs
  • Plus: customer compensation
  • Total: R$ 500k - R$ 2M

Customer liability

Customers will sue:

Scenario:

  • Hacker accesses customer's M365 (via your SaaS)
  • Steals customer emails (confidential)
  • Customer loses a deal (info was leaked)
  • Loss: R$ 500k

Customer sues you:

  • "Your SaaS leaked our M365 credentials"
  • "You didn't protect our data"
  • "You were negligent"

Your liability:

  • Direct: R$ 500k (customer's loss)
  • Indirect: R$ 1M+ (legal fees, settlements)

Reputation damage

Before breach:

  • 100 customers
  • Logo on your website
  • 5-star reviews

After breach:

  • "Company X had security breach"
  • Social media: "Never use Company X"
  • Press: "SaaS leaks customer data"
  • Customers leave

Result:

  • 50% churn (customers leave)
  • New sales: -90% (nobody trusts you)
  • Valuation: -80% (if raising capital)

How to protect yourself (practical)

1. Don't store M365 credentials (OAuth2 instead)

Old approach (DANGEROUS):

python

NEVER DO THIS

username = "user@company.com" password = "P@ssw0rd123" # LEAKED!

client = MicrosoftGraphClient( username=username, password=password )

If hacker gets your database:

→ hacker has username + password

→ hacker can impersonate user

→ hacker accesses all M365 data

New approach (SAFE with OAuth2):

python

SAFE: use OAuth2

client = MicrosoftGraphClient( client_id="your_app_id", # public, OK to leak redirect_uri="https://your-saas.com/callback" )

User authorizes (via Microsoft login page)

You get: refresh_token (time-limited)

If hacker gets refresh_token:

→ token expires in 90 days

→ hacker loses access

→ customer revokes access (1 click)

→ hacker can't impersonate

Benefit:

- No password stored

- No credential leak risk

- Customer controls access

- Time-limited tokens

2. Use strong secrets management

What to do:

python

SAFE: secrets in vault (AWS, Hashicorp, etc)

from aws_secretsmanager_caching import SecretCache

cache = SecretCache() secret = cache.get_secret_string("m365_refresh_token")

Security features:

- Encrypted at rest

- Encrypted in transit

- Access logged

- Rotation policy (90 days)

- Audit trail

- MFA required to access

If hacker gets AWS credentials:

- Still can't access secret (needs extra MFA)

- Access is logged (you'll know)

- Token rotates automatically

3. Enable MFA everywhere

For your team:

ConnectWise credential was likely:

  • Weak password OR
  • No MFA enabled

If MFA enabled:

  • Phishing attack wouldn't work (attacker needs phone to login)
  • Malware couldn't steal credentials (needs phone code)
  • Password leak wouldn't matter (attacker still can't login)

Practical steps:

  1. Enable MFA for all employees

    • Authy, Google Authenticator, or hardware keys
  2. Enforce MFA for M365 access

    • No exceptions
    • All users, all the time
  3. Use conditional access (Azure AD)

    • Block logins from suspicious locations
    • Block logins from new devices
    • Require MFA for admin access

4. Implement zero-trust architecture

Idea: assume everything is compromised

Old approach (perimeter security):

  • Trust everyone inside network
  • Heavy protection outside
  • Problem: one breach = full access

Zero-trust approach:

  • Trust nobody (even inside network)
  • Verify everything
  • Principle: least privilege

Example:

  • Employee needs M365 access
  • Verify: who are you? (MFA)
  • Verify: what device? (certificate check)
  • Verify: from where? (IP location)
  • Verify: do you need this? (access policy)

Only then: grant access And: monitor constantly (anomaly detection)

5. Audit your supply chain

Questions to ask:

  1. Who has access to M365 credentials?

    • Your team?
    • Your cloud provider?
    • Third-party services?
    • Backup providers?
  2. How are credentials protected?

    • Encrypted?
    • In vault?
    • Rotated regularly?
    • Access logged?
  3. What happens if they're stolen?

    • Can you revoke access immediately?
    • Are there time-limited tokens?
    • Can customer revoke access?
  4. Do your third parties have the same standards?

    • Do they use MFA?
    • Do they audit access?
    • Do they have security certifications?
    • What's their breach response plan?

6. Have an incident response plan

When (not if) breach happens:

Day 1:

  • Detect breach (monitoring alert)
  • Isolate affected customers
  • Revoke M365 refresh tokens
  • Notify customers immediately

Day 2-3:

  • Forensics: what was accessed?
  • Legal review: LGPD obligations?
  • Notify regulators (ANPD, if required)
  • Prepare customer communication

Day 4+:

  • Rebuild confidence
  • Enhanced security measures
  • Compensation (if applicable)
  • Root cause analysis

ConnectWise lesson: what happened

Why ConnectWise was targeted

ConnectWise is:

  • Trust layer (MSPs trust them with credentials)
  • High value target (access to 173 customers)
  • Likely: not perfect security (small percentage compared to Microsoft)

Attacker logic: "Break into small provider Access big customers Much easier than breaking into Microsoft"

Result: 173 breaches from 1 attack

What you should do NOW

If you use ConnectWise:

  1. Change your M365 password (if stored)
  2. Enable MFA on ConnectWise account
  3. Check M365 audit logs for unauthorized access
  4. Force refresh all tokens (revoke old ones)
  5. Notify your customers "We use ConnectWise. There was a breach. We've taken these steps. You're safe."

If you use ANY third-party backup/integration service:

  1. Ask: Do you use passwords or OAuth? (OAuth is safer)

  2. Ask: Do you enforce MFA? (You should require it)

  3. Ask: How do you protect credentials? (Vault? Encryption? Rotation?)

  4. Ask: What's your breach response time? (Should be hours, not days)

  5. Consider: Should I use them? (Is the risk worth the benefit?)


Conclusion: credential security is non-negotiable

Reality:

ConnectWise: 1 compromised credential = 173 breaches Your SaaS: 1 compromised M365 credential = ?

If you're integrating M365:

  • You're handling sensitive customer data
  • Attackers will target you (or your suppliers)
  • One breach = legal liability + reputation damage
  • You MUST have strong credential security

Action plan:

  1. Audit: do you store passwords? (STOP if yes)
  2. Migrate: to OAuth2 (time-limited tokens)
  3. Secure: use vault (AWS Secrets, Hashicorp Vault)
  4. Protect: enforce MFA (no exceptions)
  5. Monitor: log all M365 access (detect anomalies)
  6. Plan: have incident response plan (tested)
  7. Review: audit third parties (suppliers, backup)

Cost of NOT doing this:

If breach happens:

  • LGPD fine: R$ 200k - R$ 50M
  • Customer liability: R$ 500k+
  • Reputation damage: -80% valuation
  • Legal fees: R$ 100k+
  • Remediation: R$ 50k+

Total: R$ 1M - R$ 100M

Cost of implementing security:

  • OAuth2 integration: R$ 10k (one-time)
  • Secrets manager: R$ 500/month
  • MFA tools: R$ 1k/month
  • Audit/monitoring: R$ 2k/month

Total: R$ 4k/month (R$ 48k/year)

Simple math: spending R$ 50k/year saves R$ 1M+ in breach costs.

→ OpenClaw: M365 Security, OAuth2 Integration, Credential Protection, Supply Chain Risk, LGPD Compliance

Seu SaaS integra M365? Usa OAuth2 ou senha? 🔐


Publicado em 17 de outubro de 2026

Leia também