Understanding How Hackers Exploit Credentials

✨ I deployed a public-facing Azure Windows VM and watched what happened next. ⏱️ Within hours, it began receiving tens of thousands of authentication attempts. (around 60k+ attempts in first two hours after deployment) 🔐 I connected Windows Security Events to Microsoft Sentinel and analyzed the activity using KQL — not to “catch hackers,” but to understand how these attacks actually look in real logs. 🔍 What I observed: ⚠️ High-volume automated authentication attempts shortly after exposure 🧪 Clear credential spraying behavior from individual source IPs 📈 Hundreds of different account names targeted per minute 🎯 Strong focus on common usernames (administrator, admin, user, test, service-style accounts) 🛡️ No evidence of successful compromise or post-authentication exploitation ✨ This lab reinforced a simple but critical lesson: Exposed infrastructure is discovered fast. And most attacks rely on weak credentials — not sophistication. 📁 Full analysis, KQL queries, and screenshots are documented in my GitHub: https://lnkd.in/eghBZWez

149 Million Credentials Exposed Through Infostealer Malware. No Corporate Breach Confirmed. Recent reporting has identified a publicly exposed dataset containing approximately 149 million stolen credentials with an estimated size of 96 GB. The data includes usernames, passwords, browser autofill records, cookies, and keystroke logs. According to reporting from threat Intelligence, the dataset aggregates credentials harvested from millions of infected end user systems rather than from any single breached organization. The exposed credentials reference multiple platforms including roughly 420,000 accounts associated with Binance, as well as services such as Gmail, Facebook, Instagram, Netflix, and TikTok. Importantly, no evidence indicates a breach of these platforms’ backend infrastructure. Threat researchers attribute the exposure to widespread deployment of infostealer malware on consumer and enterprise endpoints. As documented in multiple investigations by BleepingComputer, these malware families are commonly delivered via fake software updates, pirated applications, game modifications, and malicious browser extensions. Once executed, infostealers extract credentials directly from browsers and local credential stores. This includes session data and saved passwords, allowing attackers to capture valid credentials at the moment of authentication regardless of transport security controls such as HTTPS. Because the compromise occurs at the endpoint layer, credentials from unrelated services are collected together. A single infected device can expose email accounts, cloud platforms, financial services, and cryptocurrency wallets simultaneously. The appearance of Binance credentials in the dataset reflects compromised user devices rather than a failure in Binance systems. Any service accessed from an infected endpoint becomes vulnerable at login time. Researchers noted that the database was accessible for an extended period, enabling indexing, searching, and reuse by multiple threat actors. This significantly increases the likelihood of credential stuffing, account takeover, identity fraud, and highly targeted phishing campaigns using valid credentials. From a defensive and architectural perspective, this incident reinforces several key points. - Endpoint security is a primary security boundary. - Browser extensions and unofficial software distribution channels remain high risk vectors. - Credential only authentication is insufficient in the presence of endpoint compromise. - Mitigation requires layered controls including robust endpoint protection, regular extension audits, unique credentials managed via password managers, and hardware backed multi factor authentication. As consistently highlighted by DFIR and threat intelligence reporting, modern large scale breaches increasingly originate from compromised user devices rather than centralized enterprise infrastructure. Security strategies must adapt accordingly.

They didn’t break in. They logged in. A $500,000 theft.  4 victims.  Multiple Australian super funds.  All from one of the oldest attacks in the book: credential stuffing.  Attackers used leaked usernames + passwords from past breaches.  No zero-days. No ransomware. Just login forms and reused credentials. Why did it work?  – No #enforced #MFA  – No dark web monitoring  – No login throttling  – And… password reuse (again)  This wasn’t a tech failure. It was a #risk #management failure. Here’s the uncomfortable truth:  If you’re not scanning for leaked credentials tied to your domain, you have no idea how exposed your business already is.  Credentials are the #1 path to compromise in 2025.  #MFA alone isn’t enough.  • Monitor exposed credentials  • Lock down login flows  • Train users with real-world examples  •  Detect suspicious login behavior in real time 

Most security programs can tell you what controls they deployed. Very few can prove those controls stop the attack path that matters. That gap is where breaches happen. Here is what the modern identity attack path looks like, and why traditional measurement misses it. The attacker does not exploit a vulnerability. They phish, proxy, or register a malicious OAuth app. The user authenticates legitimately. MFA is satisfied. The attacker captures the session token (MITRE T1528). That token is now the credential. Tokens may remain valid after authentication depending on platform and revocation controls. If tied to a non-human identity or refresh token, access can persist indefinitely without explicit revocation (T1078). The attacker queries APIs instead of scanning networks, enumerating mailboxes, file stores, and identity relationships through legitimate interfaces. Using trusted integrations, they pivot across SaaS and cloud with no malware, just delegated access through paths the organization built (T1199). Data leaves via APIs expected to move data (T1537). Google’s Threat Intelligence Group detailed a campaign where attackers used compromised OAuth tokens from the Salesloft Drift integration to access Salesforce environments. Cloudflare confirmed the mechanics in their incident response disclosure. This is not a control failure. It is a measurement failure. Would your current program detect this? Most programs measure coverage: endpoints with EDR, identities with MFA, vulnerabilities patched within SLA. Coverage measures what you deployed. Exposure measures what an attacker can reach. These are fundamentally different. CTEM addresses this through five phases. Scoping must include OAuth tokens, non-human identities, and API credentials or the model has a blind spot where attackers target. Organizations often operate with triple-digit ratios of non-human identities to human users. Discovery must extend to that full population. Prioritization must reflect attack path context. A moderate misconfiguration chained with a stolen token and trusted SaaS integration reaches sensitive data faster than a critical CVE on an isolated server. Equally important is whether existing compensating controls already reduce exploitability. Validation is the phase most programs skip. Validation means testing whether controls stop token theft, consent phishing, and NHI abuse against your own defenses. Start by testing one identity attack path end-to-end: token theft, API access, lateral movement across a trusted integration. Mobilization turns validated findings into remediation with clear ownership, enriched context, and tracked execution. Without it, findings sit in queues and exposure persists. Not “Do we have controls?” But “Did we prove those controls stop the attack path that matters?” Views are my own #CTEM #ExposureManagement #IdentitySecurity #MITREATTACK #CISOLeadershipy

Attackers don’t break in anymore; they log in. Nearly 80% of breaches involve compromised credentials. That means most incidents begin with legitimate access and escalate through hidden relationships, privileges, and trust paths that security teams never knew existed. When valid credentials are the entry point, perimeter defense becomes secondary. The real question becomes: Once an attacker is on the inside with control of a legitimate identity, what can it reach? This is why Identity Attack Path Management (APM) has become essential. Security teams must move beyond point-in-time findings and begin to understand how small misconfigurations combine into full compromise paths to critical assets. But building a mature APM practice isn’t trivial. It demands adversary-level insight (to see your environment the way an attacker does), prioritization of the riskiest paths, and sustained remediation over time, not just more alerts. That’s exactly why we created BloodHound Scentry: to pair BloodHound Enterprise with experienced operators who help organizations analyze, prioritize, and eliminate attack paths while designing durable privilege boundaries around the systems that matter most. Security isn’t about preventing every foothold. It’s about ensuring a foothold doesn’t become a breach. Because the question isn’t whether attackers can get in; it’s whether they can move.

New Ransomware Tactic: Qilin Targets Chrome Credentials 🚨 The Qilin ransomware group is escalating its attacks with a dangerous new strategy: stealing credentials directly from Google Chrome. This shift in tactics marks a concerning development in the ransomware landscape, and here’s what you need to know: ➜ Key Insights: → Credential Harvesting: ↳ Qilin deploys a custom stealer to collect account credentials stored in Google Chrome browsers. ↳ This tactic was observed by the Sophos X-Ops team during incident response engagements, highlighting an alarming change in ransomware operations. → Sophisticated Attack Execution: ↳ The attack began with Qilin gaining network access using compromised VPN credentials without multi-factor authentication (MFA). ↳ After an 18-day dormancy period, the attackers moved laterally, deploying PowerShell scripts to harvest credentials and ultimately encrypt data across the compromised network. → Widespread Impact: ↳ The Group Policy Objects (GPOs) applied to all machines in the domain, allowing Qilin to potentially steal credentials from every device connected to the network. ↳ This extensive credential theft can lead to follow-up attacks, widespread breaches, and long-lasting threats. → Measures to Protect Your Organization: ↳ Implement Multi-Factor Authentication (MFA): Add an extra layer of security to your accounts to defend against credential theft, even if initial login credentials are compromised. ↳ Regularly Update and Patch Systems: Ensure that all systems, especially browsers like Chrome, are up-to-date to close vulnerabilities that could be exploited by ransomware groups. ↳ Conduct Regular Security Audits: Assess your network security to identify potential vulnerabilities, ensuring robust defenses are in place against advanced threats. ↳ Adopt the Principle of Least Privilege: Restrict user access to only what is necessary to minimize the potential damage from a breach. ↳ Network Segmentation: Divide your network into smaller segments to limit the spread of an attack, making it easier to isolate and contain threats. P.S. Is your organization equipped to defend against the evolving tactics of ransomware groups like Qilin? ♻️ Share this post to raise awareness and 🔔 follow Brent Gallo - CISSP for more updates on cybersecurity. #CyberSecurity #Ransomware #ITSecurity #CredentialTheft #DataProtection #NetworkSecurity #MFA #Resilience #CyberThreats

Hackers can compromise an MFA-Protected Google Workspace account: Despite using multi-factor authentication (MFA), attackers are finding ways around it using advanced phishing techniques. In this example, it begins with a phishing email containing files that link to a spoofed site. The site first presents a CAPTCHA, then redirects to a fake Google Workspace login page. The user enters their credentials and completes MFA—but behind the scenes, the session is hijacked and handed to the attacker. This method bypasses MFA not by breaking it, but by stealing the authenticated session, giving attackers full access without needing to re-authenticate. While similar tactics have frequently targeted Microsoft 365, this is the first time I’ve observed it being used against Google Workspace. If you receive a file or message that feels even slightly off, always validate it using a different, trusted communication method. Also, always look at the URL of the domain you are trying to log into to validate it is correct. Watch the video where I walk through this example in more detail: https://lnkd.in/gmrpqeVN

Here's something building owners and facilities directors need to understand about how cyber attacks on buildings actually happen. It's usually not a sophisticated hacker exploiting some technical flaw. More often, someone just uses a stolen username and password to walk straight in through the front door. The systems that control your building — heating, cooling, access control, lighting — are increasingly managed through web-based portals. Tridium Niagara, Johnson Controls Metasys, Honeywell. Your engineers log into these systems remotely, often saving their passwords in a browser for convenience. There's a category of malware called infostealers. Their entire job is to find and steal those saved passwords. Cheap to deploy. Hard to detect. Increasingly common. Once an attacker has those credentials, they don't need to break anything. They log in with legitimate details and your own system thinks it's your engineer. New intelligence from H2 2025 confirms this is accelerating. At Kelso Building Services, we built our secure remote access program specifically around this threat. Every remote session into a customer's BAS environment runs through an isolated, monitored access layer — no saved credentials, no direct exposure, full audit trail. MFA required. Every time. If you manage a building and you don't know whether your controls contractor accesses your systems this way, that's the question to ask this week. Not next quarter. This week. #OTSecurity #BuildingAutomation #FacilitiesManagement #CyberSecurity

How to explain a Credential Dumping attack (using Mimikatz) in an interview or stakeholder conversation: When a Windows machine is compromised, the risk is not limited to that single system. Any user who has logged into that machine may have their credentials exposed. Windows stores authentication material inside the LSASS process to support logon functionality, single sign-on, and Kerberos operations. This includes NTLM hashes, Kerberos tickets, and in some cases plaintext passwords. If an attacker gains administrative privileges, they can access LSASS memory and extract this credential material using tools like Mimikatz. Importantly, Mimikatz reads credentials that are already present in memory in a usable form. This means the impact of a compromise depends heavily on who has logged into the system. On shared servers or jump boxes, multiple administrators may have active or cached sessions. Dumping LSASS in these environments can yield credentials across different privilege levels. This is how a single compromised host can become a pivot point for broader access across the network. This technique targets credentials stored in memory. Other credential stores, like the SAM database, contain local account hashes and require different extraction methods. From a defensive perspective, the goal is to reduce credential exposure and protect LSASS: - Enable LSA Protection (RunAsPPL) where possible - Deploy Credential Guard on supported systems - Minimize privileged logons to sensitive machines - Disable legacy features like WDigest - Monitor for processes accessing LSASS If one compromised machine leads to multiple credential exposures, the issue is not just the breach itself, but how much access is concentrated on that system. You can read more attacks explained this way at https://explainthehack.com. Further reading: LSA Protection (RunAsPPL): https://lnkd.in/e3Z6ChhR Credential Guard (Virtualization-Based Security): https://lnkd.in/eQumdP8m Securing privileged access / limiting admin logons: https://lnkd.in/eiYenk5S Disabling WDigest (prevent plaintext password caching): https://lnkd.in/eZaYiFi4 Detecting LSASS access (credential dumping detection): https://lnkd.in/eZyxz9kY Mimikatz overview (context + risk): https://lnkd.in/eCHKE4nT

KEBEROASTING EXPLAINED: This is a common attack technique in Active Directory environments where attackers extract and crack service account credentials by exploiting weaknesses in the Kerberos authentication protocol. Here’s a concise explanation: How Kerberoasting Works: 1. Reconnaissance: • An attacker, often with low privileges, enumerates Active Directory to identify service accounts with Service Principal Names (SPNs). SPNs are unique identifiers for services running on a server that are associated with Active Directory accounts. 2. Requesting a Service Ticket: • The attacker requests a Kerberos Service Ticket (TGS) for a specific SPN. • The Kerberos Key Distribution Center (KDC) issues the TGS encrypted with the service account’s password hash. 3. Extracting the TGS: • The attacker retrieves the TGS from memory or through network traffic. 4. Offline Password Cracking: • The attacker uses tools like Hashcat or John the Ripper to perform an offline brute force or dictionary attack on the TGS to extract the plaintext password of the service account. Kerberoasting is a widely known technique used in many penetration tests and real-world attacks, making its detection and mitigation a critical aspect of Active Directory security. Best ways to avoid it: limit privileges and employ both detection tools and service account monitoring.