How Vulnerabilities Impact Cloud Management Platforms

Last week, a simple vulnerability in DeepSeek led to exposure of over 1 million chat records! An attacker could have easily exploited this to gain full database control and escalate privileges. I said 'could have'—because this flaw was caught by Wiz Research before any known exploitation. Here’s how the researcher (acting as an “attacker” in this case) uncovered it: 𝗔𝘁𝘁𝗮𝗰𝗸 𝗙𝗹𝗼𝘄: 1) Attacker starts by mapping DeepSeek’s public domains > discovers 30 internet facing sub domains. 2) Attacker now starts scanning for non-standard open ports on these domains > Bingo! Detects 2 unusual open ports (8123 & 9000) on  hxxp[://]oauth2callback[.]deepseek[.]com 3) Attacker investigates further > Identifies these ports lead to database access without any authentication! > The database is ClickHouse commonly used for real time data processing. 4) Attacker simply appends "/path" to the URL (this is the standard path that allows direct execution of SQL queries via browser with ClickHouse) > Returns a full list of accessible datasets > "log_stream" table contained over 1 million log entries that had Chat history, API keys etc (Pls see image I attached for easy understanding. Credits to Wiz) 𝗔 𝗙𝗲𝘄 𝗧𝗵𝗼𝘂𝗴𝗵𝘁𝘀: 1) If you think about it, a simple misconfiguration on a single cloud asset could easily lead to a massive breach of your entire company's data! All an attacker needs to do is find that one simple mistake. That’s the asymmetry in cybersecurity. 2) Cloud misconfigurations are everywhere. Why? A few reasons: --> A developer assumes cloud services have secure config by default. But several services require manual config post creation to restrict access. --> A developer enables broad access during testing as a quick workaround but forgets to remove it. The same config goes into production. --> A developer creates cloud resources without proper IT and Security team's oversight (aka Shadow IT problem) So, yes, this problem is dependent on solving many other systemic issues such as security hygiene, default access control policies, gating testing to production changes and so on. 3) But consider this for a second: It is your database. It is you who enabled the unauthenticated access. But someone else found out about it before you did. How? Because they were ready for it. 4) If an attacker can continuously scan your IPs, sub domains and identify accidentally exposed databases, you should be able to do that too. In fact, with the level of control and visibility you have on your assets, you should be able to do that before they do. 5) Build the security capability to automatically identify your company's public assets, scan them for ‘anonymous access’ and respond rapidly for the identified cases. Beat attackers at their own game. If you enjoyed this or learned something, follow me at Rohit Tamma for more in future! #cybersecurity #applicationsecurity #threatdetection #informationsecurity #infosec #cloudsecurity

🚨 ☁️ - New Recorded Future Insikt Group report! This research examines how cloud intrusions are converging on a consistent pattern: adversaries rarely need to deploy traditional malware once they obtain a valid identity. The operational pivot is quiet but consequential. Access now precedes tooling. After authentication, attackers increasingly rely on native platform functionality to enumerate environments, manipulate backups, alter encryption states, and move data through sanctioned workflows. From the system’s perspective the activity is compliant. The infrastructure does exactly what it was designed to do, just for the wrong principal. What emerges is a different kind of compromise. Historically an intrusion introduced foreign code into a trusted environment. In cloud environments the attacker instead borrows trust from the environment itself. Detection therefore becomes less about identifying artifacts and more about interpreting intent, which is a far less stable signal. Administrative behavior, automation, and malicious action begin to occupy the same telemetry space. That shift quietly reshapes response and policy. Attribution frameworks built around infrastructure and tooling struggle when the operational layer is indistinguishable from legitimate enterprise administration. Actions that produce real operational impact can occur through standard consoles, tokens, and APIs. The observable evidence increasingly looks like misused governance rather than external penetration. The dependence on shared platforms compounds this effect. A single compromised vendor or federated identity can propagate access across multiple tenants, turning what would once have been an isolated incident into a cross organizational event with systemic characteristics. The boundary between incident response and resilience planning narrows accordingly. Cloud security is therefore drifting away from the traditional model of defending systems toward validating authority. The practical question is less whether an environment was breached and more whether the actor operating inside it had the right to act at all.

In 2024, we anticipate a surge in targeting cloud environments, which could have significant implications for space cybersecurity. Since satellite operations rely increasingly on the cloud for storage, processing, and communication, vulnerabilities in these platforms could spell trouble for space-related systems. Why is this a concern? 1️⃣ 𝗗𝗶𝘀𝗿𝘂𝗽𝘁𝗶𝗼𝗻 in cloud platforms can sever vital communication channels between ground stations and satellites, hampering mission-critical activities such as data transmission, telemetry, and command execution. 2️⃣ 𝗕𝗿𝗲𝗮𝗰𝗵 𝗿𝗶𝘀𝗸𝘀 could lead to unauthorized access or theft of proprietary information, jeopardizing the confidentiality and integrity of space missions and research endeavors. 3️⃣ 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗱𝗲𝗹𝗮𝘆𝘀 from cloud compromises can impact satellite deployments, trajectory adjustments, and real-time monitoring, potentially impeding scientific research or commercial satellite services. So, what can be done to address this? ✅ 𝗖𝗹𝗼𝘂𝗱-𝗦𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗠𝗲𝗮𝘀𝘂𝗿𝗲𝘀: Adopt advanced, cloud-native security tools designed for satellite operations. This could include endpoint detection, AI-driven threat intelligence, and automated response protocols tailored to the unique demands of space systems. ✅ 𝗭𝗲𝗿𝗼-𝗧𝗿𝘂𝘀𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀: Enforce zero-trust frameworks across all cloud-based operations, where no entity (internal or external) is trusted by default. This enhances identity verification and restricts access to sensitive mission data, minimizing unauthorized entry points. ✅ 𝗥𝗲𝗱𝘂𝗻𝗱𝗮𝗻𝗰𝘆 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴: Establish redundant communication channels and data storage systems that can activate when primary pathways are compromised. This builds resilience into mission-critical processes, enabling quicker recovery in the event of an attack. ✅ 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗠𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲: Space missions often involve high-stakes operations, so timely detection and response are essential. Real-time monitoring and an agile incident response team dedicated to cloud security can make all the difference in averting a crisis. Space cybersecurity isn’t just about preparing for tomorrow’s threats - it’s about building resilient, responsive frameworks that can evolve with the fast-changing digital landscape. Organizations committed to space advancement must be just as committed to securing the cloud environments that make it possible. #cybersecurity #satellites #cyberattacks #cloudsecurity #spacetech #resilience #zerotrust

Last week, the friendly AI chatbot on many companies’ websites became the back door that allowed malicious actors to gain access to backend systems including Salesforce, Google Workspace, Slack, AWS, Snowflake, and more. I’m talking about the #Salesloft #Drift breach, which so far has impacted over 700 organizations including several cybersecurity companies. This type of supply chain attack should be a wake-up call for any company using cloud integrations (HINT: that’s basically everyone). WHAT HAPPENED? The attackers didn't infiltrate Salesforce or other platforms directly. Instead, they compromised Drift—Salesloft’s AI chat tool—and stole OAuth tokens that granted Drift secure access to other backend systems and data sources. Think of it this way: in order for an AI customer service chatbot to work well, it needs to “know” relevant information about your company, platform, customers, and standard operating procedures. By connecting the chatbot to your CRM, your knowledgebase, and other data-rich internal resources, the AI chatbot is smarter and more effective. But in doing this, you just linked multiple previously standalone systems together, creating a heightened set of security risks for your organization. Now, any one mistake or vulnerability in that chain could have catastrophic consequences for your data security and privacy across all of the linked platforms. WHAT DOES THIS MEAN FOR YOU? In my work with clients—from agile startups to well-resourced enterprises—I’ve seen a recurring pattern: cloud tools that are quickly stitched together for productivity gains, with little to no thought for the cybersecurity implications of an integration. It used to be that you needed an entire IT department to get one system to talk to another. Now in the era of cloud, you can link systems together to share data using something as simple as “Sign in with Microsoft” or copy/pasting an API key. In 5 minutes, nearly any user in your organization can setup new data flows, connect an AI agent, or setup a chat integration—all without fully revisiting permissions or understanding the idea of 𝘀𝗵𝗮𝗿𝗲𝗱 𝗮𝘁𝘁𝗮𝗰𝗸 𝘀𝘂𝗿𝗳𝗮𝗰𝗲𝘀. This “race to AI” in the pursuit of efficiency often blinds teams to the hidden risk: the broader your connections, the larger your potential fallout. WHAT YOUR IT TEAM SHOULD DO RIGHT NOW: 👉 Assume your tokens are compromised. 👉 Immediately revoke and rotate all OAuth tokens and API keys. 👉 Inventory your integrations: prune any no longer needed. Productivity and convenience in the cloud must never overshadow security discipline. As the Drift incident shows: you’re only as strong as your weakest link. So next time you’re eager to pilot a new AI tool, whether built by a startup or a well-known industry player, do me a favor and run it past your cybersecurity advisor first. Your clients (and future self) will thank you. #CloudSecurity #OAuth #SupplyChainRisk #ZeroTrust #CyberLeadership @eSilo

Serverless doesn't shrink your attack surface. It relocates it. 𝘓𝘦𝘢𝘳𝘯𝘪𝘯𝘨 𝘚𝘦𝘳𝘷𝘦𝘳𝘭𝘦𝘴𝘴 𝘚𝘦𝘤𝘶𝘳𝘪𝘵𝘺 by Joshua Arvin Lat makes the core argument clearly: teams that move fast with serverless architectures often move fast past the security model those architectures actually require. 𝗧𝗵𝗲 𝗲𝘅𝗽𝗼𝘀𝘂𝗿𝗲 𝗹𝗮𝘆𝗲𝗿 When critical systems and sensitive data migrate to serverless infrastructure without a corresponding shift in security posture, the gap becomes an incident waiting 'on a timeline'. 𝗪𝗵𝗮𝘁 𝗶𝘀 𝘄𝗼𝗿𝘁𝗵 𝗮𝗽𝗽𝗹𝘆𝗶𝗻𝗴 🔹 Audit your serverless functions for privilege escalation paths before attackers do. IAM misconfiguration in serverless is not a configuration smell; it is an exploitable vector.  🔹 Run offensive and defensive exercises against your own infrastructure. Understanding how attacks unfold against vulnerable serverless apps is the gap between theoretical compliance and operational security.  🔹 Track regression on function permissions and event trigger scope after every deployment. Silent scope creep in serverless is one of the least monitored failure modes in cloud security. 𝗥𝗶𝘀𝗸 𝘁𝗼 𝘄𝗮𝘁𝗰𝗵 🔹 Teams with strong cloud fluency often underestimate serverless-specific attack surfaces precisely because the infrastructure feels abstracted. That confidence is the vulnerability. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗴𝗮𝘁𝗲 𝗳𝗼𝗿 𝘀𝗲𝗿𝘃𝗲𝗿𝗹𝗲𝘀𝘀 𝗿𝗲𝗮𝗹𝗶𝘁𝘆 𝗔𝘂𝗱𝗶𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Can you reconstruct exactly what a function accessed, when, and under what permissions?  ⚙️ 𝗣𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲 𝘀𝗰𝗼𝗽𝗲: Are function roles scoped to minimum required access, and is that verified post-deploy?  𝗗𝗲𝗳𝗲𝗻𝘀𝗲 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻: Have you tested your defenses using the same offensive techniques an attacker would use? 🔍 𝗖𝗿𝗼𝘀𝘀-𝗰𝗹𝗼𝘂𝗱 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆: Does your security posture hold equally across AWS, Azure, and GCP, or are there platform-specific gaps?  𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗿𝗲𝗮𝗱𝗶𝗻𝗲𝘀𝘀: If a serverless function is compromised tonight, do you have detection and containment playbooks ready to execute? ⚠️ If your team runs serverless workloads on two or more cloud providers, where are the security assumptions you've carried over from one platform that don't actually apply to another? #ServerlessSecurity #CloudSecurity #AWSecurity #AzureSecurity #GoogleCloudSecurity #PenetrationTesting #CloudArchitecture #PrivilegeEscalation #SecurityEngineering #ResponsibleAI

🔍 From CVEs to Exposure Intelligence -- A Technical Model for Risk-Based Vulnerability Management The traditional CVSS-based approach is no match for today’s attack surfaces. A modern exposure management strategy must integrate telemetry, threat intel, and control-plane signals to defend against adversaries who chain misconfigs, stale privileges, and unpatched services. Here’s a breakdown of key InfoSec risks—and technically grounded remediations: 🔴 Risk #1: CVE overload with no context-aware prioritization 🟢 Remediation: - Implement exploitability filters using threat intelligence feeds (e.g., Exploit-DB, CISA KEV, Mandiant TI). - Use EPSS (Exploit Prediction Scoring System) and MITRE ATT&CK mapping for attacker-centric triage. - Weight vulns by asset criticality using tagging (e.g., public-facing, prod, regulated). 🔴 Risk #2: Fragmented visibility across hybrid/cloud environments 🟢 Remediation: - Aggregate telemetry from EDR (e.g., osquery, Sysmon), CSPM tools, and IAM logs. - Build an exposure graph to visualize relationships between identities, misconfigs, and data stores. - Continuously scan for unknown/rogue assets across on-prem and cloud. 🔴 Risk #3: Configuration drift and unmonitored assets 🟢 Remediation: - Use IaC drift detection (e.g., driftctl, AWS Config) to catch unintended changes. - Enforce compliance-as-code using CIS/NIST baselines with automated remediation pipelines. - Align infrastructure with source-of-truth inventories (CMDB, IaC repos). 🔴 Risk #4: Disconnected workflows between security and IT/DevOps 🟢 Remediation: - Shift security left using tools like Trivy, Checkov, or GitHub Actions in CI/CD. - Pipe exposure insights directly into ITSM platforms (e.g., Jira, ServiceNow). - Use policy-as-code (OPA, Rego) to enforce guardrails without manual approvals. 🔴 Risk #5: Alert noise with no correlation to real risk 🟢 Remediation: - Enrich findings with identity posture (e.g., dormant admin accounts), open ports, and data classification. - Use attack path analysis to correlate and score multi-step exposures. - Prioritize remediation based on blast radius and business impact, not just vuln count. 📌 Exposure management isn’t about more alerts—it’s about graph-driven visibility, risk-aligned prioritization, and automation-first remediation. This isn’t just a shift in tooling—it’s a shift in mindset. The future of InfoSec lies in exposure-centric, not alert-centric defense. 📖 Learn more: 👉 https://lnkd.in/gPJtATGu #InfoSec #CyberSecurity #ExposureManagement #SecurityEngineering #ThreatModeling #CloudSecurity #AttackSurfaceReduction #RiskBasedSecurity #DevSecOps #SecurityArchitecture #BlueTeamOps #MITREATTACK

VMware Hyperjacking Vulnerabilities: A Critical Threat to Virtual Environments Introduction: A Major Security Risk in Virtualized Systems Three newly discovered critical vulnerabilities in VMware’s virtual machine (VM) products have raised serious security concerns. These flaws enable hyperjacking attacks, where a hacker who compromises a single VM can take control of the hypervisor, gaining access to all other VMs on the system. Given VMware’s widespread use in enterprise, government, and cloud environments, the risks posed by these vulnerabilities are severe. Key Details: How Hyperjacking Works • Exploiting Virtual Machine Escape: • Virtual machines (VMs) typically operate in isolated environments to protect customer data and networks. • A hypervisor manages these VMs, ensuring they remain separate from one another. • The discovered vulnerabilities allow an attacker to break out of an isolated VM and seize control of the hypervisor, giving them full access to all VMs on that host. • Why This Attack Is So Dangerous: • Once the hypervisor is compromised, the attacker can access or manipulate all customer data stored in connected VMs. • Multi-tenant cloud environments (where multiple organizations share infrastructure) are especially vulnerable. • The breach eliminates traditional security boundaries, allowing attackers to move laterally across networks. • Security Expert Warning: • Researcher Kevin Beaumont emphasized that once a hypervisor is compromised, “all bets are off”, meaning traditional security protections become ineffective. • A successful attack could provide hackers with full administrative control over an entire virtualized infrastructure. Why It Matters: The Broader Implications • Enterprise and Cloud Security at Risk: Businesses, government agencies, and cloud service providers relying on VMware-based virtualization could see catastrophic breaches. • Potential for Espionage and Ransomware Attacks: Threat actors could steal sensitive data, install persistent backdoors, or deploy ransomware across an organization’s entire virtual infrastructure. • Urgent Need for Patching and Mitigation: Organizations using VMware virtual machines should immediately apply patches and review security controls to limit the blast radius of a potential breach. With virtualization technology forming the backbone of modern IT infrastructure, these VMware vulnerabilities highlight the growing risks in cloud and enterprise security. As hyperjacking attacks become more sophisticated, robust defenses, rapid patching, and proactive threat detection are essential to mitigating the threat.

🔭A vulnerability was recently discovered in HTTP requests within web applications managing AWS infrastructure. These vulnerabilities could potentially allow attackers to capture access keys and session tokens (which are often temporarily shared with external users, who can upload device logs to CloudWatch), enabling unauthorized access to backend IoT endpoints and CloudWatch instances. What is at risk: 📛Attackers can intercept these credentials in clear text, potentially uploading false logs or sending MQTT messages to IoT endpoints. This not only compromises data integrity but also increases operational costs through fraudulent activities. 📞The PoC showed a peer-to-peer screen sharing application built on AWS that HTTP made requests to specific endpoints that could expose sensitive credentials. 🗒Two unique endpoints were found: ‘/createsession’ and ‘/cloudwatchupload’. When a request was sent to the ‘/createsession’, the web application responded with access keys and session tokens corresponding to an AWS IOT endpoint. These keys were successfully used to send MQTT messages to the AWS IOT endpoint. 🛠Recommended Actions: Data should be routed through an internal server that validates and securely forwards it to AWS services. Implementing centralized auditing, logging, and rate limiting will further enhance security. This case serves as a stark reminder of the ongoing risks and design flaws prevalent in integrating web applications with backend cloud services. #CyberSecurity #AWS #InfoSec #CloudSecurity #DataProtection

I audited 3 years of cloud configurations as CISO (Chief Information Security Officer). 94% of our critical incidents traced back to one type of mistake. Not unauthorized tools. Not external attackers finding zero-days. Not misconfigured firewalls. IAM (Identity and Access Management) permissions granted during fast-growth sprints — and never revisited. A developer needed prod access to hit a deadline. Granted it. Deadline passed. Access stayed. Nobody came back to revoke it. Another service account spun up with admin rights "temporarily" during a migration. Migration completed 18 months ago. Admin rights: still active. Owner: no longer at the company. We found 340 over-privileged identities in a single audit. 12 had active keys with no last-used date — meaning we had no idea if they were being used by a legitimate process, an automated script we had forgotten about, or something else entirely. Your biggest cloud security threat isn't hackers finding sophisticated vulnerabilities. It's your own engineers moving fast — doing exactly what you hired them to do. The permissions weren't malicious. They were the residue of growth. And they were everywhere. The 4-step audit that found every one of them — and the governance change that stopped new ones from accumulating — is in today's article. 📄 4-Step Cloud Configuration Audit + IAM Governance Framework: https://lnkd.in/gqYmkPgM 📧 Thursday 5:30 PM CST (Central Standard Time): The Fast CISO Issue #11 — Finance sent me an $80,000 surprise cloud bill. Buried inside it was a security incident. The 5-Signal Cloud Security Cost Audit is in this week's newsletter. Subscribe: https://lnkd.in/gKv_jyAy #CISO #CloudSecurity #IAM #SecurityLeadership #CyberSecurity

After a conversation with Ferenc Spala earlier this week, something struck me about how we manage risk. I think we over-index on the Common Vulnerabilities and Exposures (CVE) list, guided by CVSS scores. CVEs and CISA KEVs take up most of the mental bandwidth. While this approach helps create awareness, it also obscures a much broader set of risks that fall outside of that traditional vulnerability classification scheme. Attackers don’t stop to ask whether a system has CVEs; for them, any weak spot is an opportunity. What are these “other” risks? They run the gamut from misconfigurations to end-of-life (EOL) systems, missing or poorly maintained controls, incorrect permissions, and more. A default password left on a critical system, for example, may not show up in a CVE database, but it can be just as damaging as a high-severity software flaw. A cloud file share with world-readable permissions can be the perfect foothold for lateral movement. Historically, teams have heavily relied on CVE-based metrics to decide which vulnerabilities to patch first, often using CVSS/EPSS as the key determinant for priority. This has served the industry reasonably well in terms of tackling the most visible software flaws. But as attack surfaces become more complex, and as we integrate more services, platforms, and APIs than ever before, the risk we face isn’t limited to neatly cataloged CVEs. Ransomware operators, for example, routinely abuse misconfigurations and credential issues to pivot through environments. That’s where an expanded, more holistic view of exposure management comes in. The idea we’ve been pursuing is to map non-CVE exposures like misconfigurations or control gaps to TTPs (tactics, techniques, and procedures) that attackers employ when exploiting typical CVEs. In other words, if a certain set of TTPs is commonly used to exploit a known vulnerability in a particular software component, those same TTPs may be relevant if there’s a misconfiguration that enables the same lateral movement or privilege escalation. By analyzing both CVEs and non-CVEs through the lens of TTPs, we can prioritize remediation efforts in a much more unified and realistic way. From a defensive standpoint, the potential impact and the actual attacker workflow may look very similar even if one is assigned a CVSS score and the other isn’t. By classifying both exposures in terms of the TTPs they enable, we can see that their remediation priority might be comparable. This approach helps security teams escape the trap of “CVE-centric thinking” and pushes us to see our environment more through the eyes of an adversary. This helps us think beyond Patch Tuesday and OWSAP top 10. True potential in exposure management lies in a unified view that spans the spectrum of vulnerabilities, misconfigurations, and architectural weaknesses. I am excited about the move from patch management to genuine exposure management!! More here: https://lnkd.in/gAur4uCd