On March 16, 2026, CareCloud appeared in public reporting for a cybersecurity incident that affected parts of its environment. While the root cause is still being investigated internally, it’s clear that months before the breach hit the news, credentials tied to CareCloud were already circulating in infostealer logs.
Lunar’s telemetry picked up a recurring pattern of carecloud.com credentials exposed between mid‑2025 and early 2026. It’s a familiar sequence, in which Windows machines are quietly infected, logins are harvested in the background, and following a long gap, a malicious actor turns those credentials into real access.
What Lunar Saw Before the CareCloud Incident
Looking back over our data, we saw a clear exposure window between May 2025 and January 2026, when approximately 88 distinct credential sets tied to carecloud.com personas appeared in infostealer logs linked to families like LummaC2 and Rhadamanthys.
Those credentials came from a mix of corporate and personal Windows endpoints, all used to access business‑related resources, such as Microsoft 365, SSO gateways, and third‑party portals. On April 9, 2026, after the incident became public, Lunar ran a correlation and confirmed that this nine‑month exposure period lined up as a clear precursor window to the breach timeline.
That kind of gap is typical of how today’s access‑broker ecosystem works, in which credentials are stolen, bundled, and sometimes traded more than once before someone decides to use them against a specific target.
Snapshot: Key Exposure Details
- Domain involved: carecloud.com
- Observed exposure window: May 2025 – January 2026
- Approximate distinct exposures: ~88 credential sets
- Primary malware: LummaC2, Rhadamanthys infostealers
- Impacted infrastructure: Mixed corporate and personal Windows endpoints
- Targeted service categories: Microsoft 365, SSO gateways, third‑party portals used for business operations
Eighty‑eight exposed identities is not a massive number in the context of a large healthcare SaaS provider, but many of those accounts are connected to systems that plug directly into CareCloud’s daily workflows. If one exposed account is often enough to get an attacker started, dozens create options to execute elaborate attacks.
Infostealers and the Power of Valid Accounts
Modern attackers increasingly prefer a login page to an exploit kit. Rather than hammering away at software flaws, they go after people’s browsers and reuse whatever those browsers remember.
LummaC2 and Rhadamanthys are good examples of that model. Once they land on a Windows device, typically through a phishing link, a malicious installer, or a “free” cracked download, they quietly pull out:
- Stored browser credentials and autofill data
- Session cookies that can sometimes be replayed to sidestep MFA
- System metadata and, in many cases, other sensitive artifacts tied to the user’s digital footprint
All of this feeds into what MITRE ATT&CK calls Valid Accounts (T1078), meaning the use of real usernames and passwords instead of trying to break software. With working credentials in hand, an adversary can impersonate a legitimate user in third‑party portals, cloud apps, or partner systems that CareCloud relies on. To a SOC watching from the inside, early activity can look like a normal session from a familiar user.
A Likely Attack Pattern
We are not claiming that any of the specific exposed accounts we observed between May 2025 and January 2026 was the direct entry point for CareCloud’s March 2026 incident. But we can say that the telemetry fits a pattern we see regularly in identity‑driven attacks:
- Infection on a corporate or personal device: A user working with CareCloud systems clicks a phishing link or installs a malicious file on a Windows endpoint. An infostealer such as LummaC2 or Rhadamanthys is dropped in the background.
- Exfiltration of credentials: The infostealer scrapes the browser for logins and cookies, including those used to access Microsoft 365, CareCloud’s SSO gateways, and third‑party portals in the CareCloud ecosystem, then sends everything back to its operators.
- Brokerage and stockpiling: Credentials are wrapped into automated logs and pushed to underground markets or private channels. Initial Access Brokers tag carecloud.com entries and may keep them on the shelf for weeks or months.
- Reconnaissance and access attempts: When someone decides to act, they use those stolen credentials to test access to VPNs, cloud services, or partner portals. If one works, and MFA or device checks aren’t strong enough, this becomes a quiet foothold for a broader intrusion.
It’s less a smash‑and‑grab than a slow burn, in which attackers steal first, wait, then see where those identities can take them.
The Human Factor and Shadow IT
Every exposed credential in this window came from a Windows endpoint, but not all of those machines were likely managed by CareCloud. Some were probably personal devices that employees or contractors used to reach business portals, while others were corporate laptops doubling as personal browsing devices.
In practice, that looks like:
- Logging into CareCloud admin or billing portals from a home PC
- Keeping “remember me” turned on in the browser for CareCloud and Microsoft 365 accounts
- Mixing work logins and personal accounts in the same browser profile
Those personal or dual‑use machines rarely have the same EDR coverage, patching cadence, or hardening as core corporate assets, but they still store company credentials and session cookies. Malicious actors don’t care whether the machine sits on a home network or behind a corporate firewall—the browser is enough.
That’s how the perimeter quietly dissolves. The first compromise happens outside the official environment, while the impact lands squarely inside it.
Defensive Takeaways for Identity‑Driven Risk
The activity we saw in the months leading up to CareCloud’s March 2026 incident is another reminder that identity protection can’t stop at the login page. A few practical steps help close the gap between exposure and misuse:
- Monitor for infostealer‑harvested credentials: Use external intelligence that flags when corporate accounts show up in fresh logs. Treat each appearance as a small incident and reset the password, revoke active sessions, and review recent activity on that account.
- Enforce hardware‑based MFA on high‑value access paths: For administrator accounts, support personnel, and critical third‑party portals, move beyond SMS and basic push‑based MFA toward FIDO2/WebAuthn security keys. That makes stolen passwords and many replayed cookies much harder to leverage.
- Strengthen endpoint integrity and limit unsupervised access: Ensure strong EDR coverage and hardening across corporate Windows assets, and set clear rules for accessing business‑critical portals from unmanaged personal devices. Where you can’t fully block BYOD, use conditional access and risk‑based policies to keep the most sensitive access on trusted endpoints.
- Reduce browser‑based sprawl: Encourage either separate browser profiles or dedicated browsers for corporate work, limiting how far a single infostealer infection can reach.
Infostealers aren’t going away. The goal is to make the identities they capture less valuable, and to shorten the time between when credentials are stolen and when they can be classified as safe again.
Disclaimer
This report is based on telemetry observed by Lunar and publicly available information. The findings presented are provided for informational purposes only. Lunar does not claim direct attribution, nor does it assert that the observed credential exposures were the definitive cause of the reported security incident. This analysis represents a correlation of temporal data points and does not constitute a “smoking gun” or identify “patient zero.”
Previous post