Microsoft’s 13-million-follower X account was taken over for a crypto pump-and-dump this week. Not through a sophisticated exploit chain or a platform zero-day - through compromised social media credentials. The same week, researchers counted over 543,000 valid credentials sitting in public GitHub repositories in a single month, and OpenAI fired three safety researchers for leaking internal data. Three different organizations, three different contexts, one common thread: identity controls that do not match the value of what they protect.

In the News

Microsoft’s X Account Hijacked for Crypto Pump-and-Dump

Attackers compromised the credentials for Microsoft’s official X (formerly Twitter) account - which has over 13 million followers - and used it to promote a fraudulent cryptocurrency token in a classic pump-and-dump scheme. The attackers posted promotional content for the fake token, driving purchases long enough to inflate the price before Microsoft regained control and removed the posts.

The takeover does not appear to involve a vulnerability in the X platform itself. The evidence points to compromised credentials - likely a shared password or OAuth token for the social media management tool used to operate the account. Social media accounts at major enterprises are frequently managed through shared credentials or delegated OAuth applications, and they rarely receive the same authentication controls applied to production infrastructure.

This is a non-human identity problem. The credential that controls a 13-million-follower account has massive blast radius, but it is typically managed outside the enterprise identity stack - no MFA enforcement, no anomalous-login detection, no automated rotation. For defenders, the question is straightforward: who in your organization owns the credentials for your highest-reach social media accounts, and are those credentials subject to the same controls as your production service accounts?

What defenders should do: Inventory all social media account credentials as non-human identities. Enforce phishing-resistant authentication (FIDO2) wherever the platform supports it. Implement secrets rotation on OAuth tokens. Deploy identity threat detection to flag anomalous logins on high-value shared accounts.

Source: BleepingComputer

543,000 Live Credentials Found in Public GitHub Repositories

Researchers identified over 543,000 valid credentials - API keys, service account tokens, database connection strings, and cloud platform secrets - exposed in public GitHub repositories during July 2026 alone. A significant portion of these credentials remained active and usable at the time of discovery, meaning anyone who found them could authenticate to the associated services.

GitHub’s native secret-scanning feature, which automatically flags known secret patterns in commits, caught some of these exposures. But the scanning relies on regex pattern matching for known token formats from partnered providers. It misses custom token formats, base64-encoded credentials, secrets embedded in configuration files with non-standard naming, and credentials from providers not enrolled in GitHub’s scanning partnership program. The result is a coverage gap that grows as organizations adopt more services with more API key formats.

This is the non-human identity sprawl problem distilled to a single statistic. Every one of those 543,000 credentials represents a service account or API integration that a human developer created, committed to a repository, and never rotated. Many outlive the project that created them. The blast radius of each one depends on the permissions it carries - and in many environments, service account permissions are broader than they need to be because no one audits them after creation.

What defenders should do: Deploy secrets management tooling that scans beyond platform-native capabilities - covering custom formats, encoded values, and configuration files. Enforce automated credential rotation on all NHI credentials. Audit service account permissions for least privilege. Treat any credential committed to a public repository as compromised, regardless of whether scanning flagged it.

Source: BleepingComputer

OpenAI Fires Three Safety Researchers for Leaking Internal Data

OpenAI terminated three members of its internal safety research team after an investigation determined they had leaked sensitive company information. OpenAI has not disclosed the specific content that was shared or the recipients, but the firings signal that the leaked material was significant enough to warrant immediate termination rather than remediation.

The incident is a textbook insider risk scenario. Safety researchers at a frontier AI company hold privileged access to model internals, training data, evaluation results, and safety testing methodologies - all of which carry significant competitive and security value. When that access is not monitored with identity threat detection and response (ITDR) controls, unauthorized disclosure can proceed undetected until the damage is done.

AI companies are not exempt from the same access-control fundamentals that apply to every enterprise. Privileged access to sensitive research requires session monitoring, anomalous-access detection, and least-privilege scoping - the same controls that defend financial data, source code, and customer records in any other industry.

What defenders should do: Implement ITDR controls that monitor privileged access to sensitive internal data - especially in R&D functions. Enforce least-privilege access with regular recertification. Deploy session monitoring and anomalous-access detection on repositories, document stores, and internal knowledge bases that hold competitively sensitive material.

Source: The Hacker News

Defender Action Items

  • Inventory all social media and shared-credential accounts as non-human identities; enforce phishing-resistant auth and secrets rotation on each
  • Deploy NHI discovery and secrets scanning that covers custom token formats and encoded credentials - do not rely solely on platform-native scanning
  • Implement ITDR monitoring on privileged access to R&D, safety, and competitively sensitive data stores
  • Patch CVE-2026-76504 (Cisco Catalyst SD-WAN Manager, CVSS 9.8) immediately - restrict management plane to trusted networks and audit API logs for unauthorized admin sessions (source)
  • Patch CVE-2026-104286 (Fortinet FortiMail, CVSS 9.8) immediately or take offline - unauthenticated arbitrary file write with no workaround (source)

Detection Queries

For detecting anomalous service-account or API-key authentication from unexpected sources - a signal relevant to both the GitHub credential exposure and the Microsoft account takeover:

index=auth sourcetype=oauth OR sourcetype=api_auth
| eval hour=strftime(_time, "%H")
| stats count dc(src_ip) AS unique_sources values(src_ip) AS source_ips BY user app
| where unique_sources > 3 OR (hour < 6 OR hour > 22)
| sort -unique_sources

This query surfaces service accounts or API tokens authenticating from an unusually high number of source IPs or during off-hours - both indicators that a credential may be in use by an unauthorized party. Tune the unique_sources threshold based on expected behavior for each service account. False positive rate is moderate in environments with legitimate multi-region service deployments; filter known CI/CD runner IP ranges.

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.