Improving security posture across the Microsoft partner ecosystem

The Deputy CISO blog series is where Microsoft  Deputy Chief Information Security Officers (CISOs) share their thoughts on what is most important in their respective domains. In this series, you will get practical advice, tactics to start (and stop) deploying, forward-looking commentary on where the industry is going, and more. In this article, Raji Dani, Vice President and Deputy CISO for Microsoft business functions, finance, and marketing dives into the importance of securing customer service solutions.

Following up on our previous post about managing risk in customer support operations, I wanted to share insight into how we manage the potential risk associated with another critical element of our ecosystem: Microsoft partners that we work with to help our customers deploy and manage some of our products.

While organizations often rely on a wide range of partners, including hardware suppliers and application developers, this post focuses on a specific category of trusted partners that many enterprises use to manage and maximize the value of their technology investments. For Microsoft, these partners are Microsoft Cloud Solution Providers (CSPs), and they help customers buy, manage, and optimize cloud services like Microsoft 365 and Microsoft Azure.

Like many organizations, Microsoft has a strong partner network that is a core part of the success of its services. Partners play a critical role in reaching and enabling broad customer segments and are core to our commercial business and go-to-market strategy. It’s therefore critical that we understand and manage risk in this space. This helps us ensure that the Microsoft partner ecosystem remains healthy, compliant, and effective, and ultimately helps drive the best outcomes for our customers. Keep reading to learn about the approach we have taken at Microsoft to secure this ecosystem, along with our roadmap for upcoming work in this space.

The risks facing partner ecosystems

As with the other business areas we have written about, the risks here are not theoretical. Threat actors, including nation-states, look to exploit partners as a vector to attack customers. Microsoft relies on its partners to engage deeply with customers across multiple scenarios. Cyberattackers in turn see this as a potential opportunity to exploit those customers through the infrastructure and platforms used by Microsoft partners.

CSPs often manage a large set of downstream customers, which means compromise of a CSP can have a large impact.

If not securely configured, a cyberattacker with access to a CSP’s tenant could potentially gain access to a broad set of customers managed by that CSP. As a result, CSPs can become targets of cyberattackers looking to steal large quantities of customer data or compromise customer resources in Azure. Again, these risks are not theoretical. We have seen nation-state attackers target our CSPs with this exact goal in mind.

This is a particularly challenging problem because securing this ecosystem depends on work taken on by both Microsoft and its partners. Microsoft provides the platforms that CSPs use to operate, while each partner manages their own tenants used for CSP operations. We need to ensure every element of this space is secure, since threat actors can exploit weaknesses in any part of the ecosystem.

How Microsoft secures its partner ecosystem

As with other key business areas, it is the goal of Microsoft to enable business success while managing risk. In the CSP scenario, this means building strong protections into the platforms that our CSPs depend on, enabling robust visibility into potential misuse of those platforms, and working with our CSPs to continually raise security standards within their own environments.

We continue to invest in strengthening security in this space at Microsoft. Our approach is guided by a set of core principles that can be applied broadly across partner ecosystems, helping organizations reduce risk and improve resilience. The following sections outline these principles and how Microsoft is implementing them in practice.

1. Partner vetting

Before an organization can begin operating as a CSP, it goes through a vetting process ensuring its validity. This process verifies the identity of the organization and ensures that it legitimately intends to operate as a CSP. This complements the work we are doing to improve CSP security posture. Partner vetting helps ensure that only legitimate organizations can enter the ecosystem, while CSP security posture improvements help enhance the operating standards of organizations already in the ecosystem. We continue to enhance these vetting capabilities based on an understanding of threat intelligence and cyberattacker trends.

2. Enhancing security posture of CSP tenants

Security in the CSP ecosystem is a shared responsibility, with Microsoft enforcing controls at the platform and control plane layer through mechanisms like granular delegated administrative privileges (GDAP), while CSPs are responsible for maintaining the security posture of their tenants. To reduce the risk of tenant compromise and limit negative downstream effects on customers, we have evolved CSP authorization to incorporate mandatory security requirements as a condition for obtaining and retaining authorization. This establishes a clear expectation that maintaining a strong security posture is not optional, but a prerequisite for operating as an authorized CSP.

As the threat landscape continues to evolve, we will periodically reassess the expectations associated with CSP authorization to ensure they remain aligned with the risks facing the ecosystem. This may, over time, result in refinements to the security baseline we define for our partners. We will continue to collaborate closely with our partners to maintain clarity and alignment as these expectations evolve.

3. Least privilege for access to downstream customers

CSPs require access to customer environments to perform their management operations. But this does not mean that a CSP needs unfettered access to those customer environments. Instead, access from a CSP to a customer tenant should follow the principles of least privilege and have strong role-based access control (RBAC). Access should only be granted with customer consent and should be constrained both in terms of scope and duration. The GDAP protocol enables CSPs to manage downstream customers based on these principles.

As part of this access control principle, we have built capabilities that allow internal Microsoft security teams to rapidly revoke a CSP’s GDAP access to customers when required. This capability can be used in a range of scenarios, including incident response, changes in partner status, or termination of a partner relationship. It helps ensure that access can be quickly withdrawn and contained when risks are identified, limiting potential impact to downstream customers.

4. Strong monitoring and response capabilities throughout the stack

Microsoft is responsible for providing strongly secured common platforms and key to that promise is robust telemetry, monitoring, and incident response capabilities across those platforms. We collect a high volume of diverse telemetry signals from across our platforms and analyze them to detect suspicious activity. This enables our security response teams to quickly identify and respond to CSP-targeting threats that arise from our platforms. Containing risk in this way is an important reason that Microsoft reserves the right to revoke a CSP’s GDAP access to downstream customers when required.

In short, we have made a set of improvements to the security posture across the CSP ecosystem, both at the Microsoft platform layer and at the partner tenant layer. Like all other areas of security, our work here is never completely done. We plan to continually enhance security across all of these areas as we learn more about cyberattacker trends and risks to the ecosystem.

Protecting partners and customers means protecting the ecosystem

The key lesson here remains that the platforms we provide to partners cannot be an afterthought when it comes to security. Even though these partner platforms are not directly part of the product or service infrastructure we maintain, Microsoft must treat them just like it does its “core” infrastructure. Cyberattackers do not care whether a given system is considered internal or marked for external use. If it gives them a way to achieve their goals (in this case the compromise of customers) they will look to exploit it.

This applies broadly to any organization working with partners. As the provider of a partner platform, there is a responsibility to protect both partners and customers by ensuring these platforms meet the highest security bar, and that is what we at Microsoft are working diligently to do.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Improving security posture across the Microsoft partner ecosystem appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/N2FMWhE
via IFTTT

ToddyCat-Linked Umbrij Malware Abuses OAuth to Access Gmail via Google API

The threat actor known as ToddyCat has been attributed to a new malware called Umbrij that's designed to gain surreptitious access to a victim's email correspondence via the Google API.

"In this campaign, the attackers focused their attention on corporate email communications hosted on Gmail, targeting access compromise via APIs," Kaspersky said in a detailed report published this week. "Because the Google API relies on the OAuth 2.0 protocol for authorization, applications can use an OAuth token to access requested email resources."

The adversary is said to have developed Umbrij to acquire this token and use it to connect to the browser's management console in headless mode via a remote debugging port.

Subsequently, a series of requests was issued to obtain an OAuth authorization code, which was then exchanged for an access token to reach the target resources via the API. The technique has been codenamed Shadow Token via Remote Debug (STRD) by the Russian cybersecurity vendor.

What's notable about the attack is that it's viable on Chromium-based browsers and exploits an active Gmail session. In other words, the idea is to launch the browser in headless mode, connect via the remote debugging port to seize control, and leverage an already logged-in Gmail session to obtain access to the Google account resources.

Three different versions of Umbrij have been uncovered, including versions that feature helper functions for debugging and for searching and selecting user accounts within the browser.

ToddyCat is the name assigned to an advanced persistent threat (APT) that has a history of targeting various organizations in Europe and Asia since at least 2020. In November 2025, Kaspersky detailed the hacking group's use of a custom tool dubbed TCSectorCopy to lay their hands on Microsoft Outlook email data belonging to targeted companies.

The cybersecurity company said it discovered Umbrij during what it described as a "threat hunting operation," as part of which a scheduled task impersonating its software ("KasperskyEndpointSecurityEDRAvp") was used to launch a digitally signed file. The signed file then employed DLL side-loading to launch Umbrij.

To accomplish this task, three legitimate binaries susceptible to DLL side-loading were abused -

• BDSubWiz.exe, a component of the Submission Wizard in Bitdefender ConnectAgent
• VSTestVideoRecorder.exe, a component of the video-recording tool used for testing with Microsoft Visual Studio
• GoogleDesktop.exe, a discontinued Google Desktop Search application used for indexing files and performing quick searches on a local Windows computer

Regardless of the executable used, the end result is the same: launching the rogue Umbrij DLL written in .NET and obfuscated with ConfuserEx, an open-source obfuscator. The tool can also be invoked along with command-line parameters that specify which browsers to target (Google Chrome or Microsoft Edge), instruct it to save a screenshot of the user profile as a PDF file, and provide the system username under which the tool will run.

Umbrij workflow diagram

Umbrij, once launched, performs a series of preparatory actions on a compromised Windows host to breach the Gmail account -

• Verify the availability of the port that will be designated for browser debugging.
• Retrieve the user context by searching for the "explorer.exe" process and duplicating the token of the first such process it encounters in order to retain all of that logged-in user's privileges. Alternatively, the -user <username> switch can be used alongside the tool to specify the target user whose token needs to be duplicated.
• Construct the path to the web browser application folder within the user's local application data repository and then parse the Local State file corresponding to Chrome or Edge to gather information about stored browser user profiles.
• Enumerate all profiles and scan them for a field named "user_name" that includes an email address. It's worth noting that the presence of an email address signals that the user is authenticated to a Google service.
• Create a directory called "BackupFiles" within "%LOCALAPPDATA%\Google\Chrome\" and "%LOCALAPPDATA%\Microsoft\Edge\."
• Copy the following files and folders of each target user profile into them: IndexedDB, Local Storage, Network, Login Data, Login Data For Account, Preferences, Secure Preferences, and Web Data. Should these files be locked by other processes, the tool includes a force-copy mechanism.
• Search the "Program Files" and "Program Files (x86)" folders for the browser installation folder for Chrome and Edge.
• Launch the browsers in headless mode by using the user profile copied to the "BackupFiles" folder, causing the browser to apply all active user cookies, including the signed-in Google account, and skip authentication.
• Use Puppeteer, a JavaScript library used for controlling Chromium-based browsers via the Chrome DevTools Protocol, to connect to the remote debugging port and send an authorization code request to direct the browser to a "accounts.google[.]com/o/oauth2/v2/auth/identifier" URL containing a "client_id" that corresponds to a migration tool used for importing local PST files and data from Microsoft Exchange accounts into a Google Workspace account. The HTTP GET request also specifies the set of permissions required by the application. Use JavaScript to emulate mouse click events to select the appropriate Google account after navigating to the URL and grant it the necessary permissions, including full access to Gmail, Drive, Contacts, Calendar, and Tasks.
• Redirect the browser session to a local address specified in the initial request and extract the OAuth authorization code from it.

"Umbrij, like most other tools in ToddyCat’s arsenal, logs its actions in detail and saves them to a file," Kaspersky said. "It also saves the retrieved authorization code to this log file, which the operator subsequently exfiltrates from the compromised host." 

"The acquired authorization code is then exchanged for an OAuth access token. The threat actors use that token to connect to the Gmail account through the API, thus compromising corporate email communications."

To counter the threat, it's advised to review the authorization codes granted to applications by navigating to "myaccount.google[.]com/connections" and then looking for applications named "Google Workspace Migration for Microsoft Outlook" or "Google Workspace Sync for Microsoft Outlook." If either of those applications is present and is not actually used within the organization, it's essential to revoke their access to invalidate the OAuth tokens.

"The ToddyCat APT group continues to search for ways of compromising corporate email communications," Andrey Gunkin, senior malware analyst at Kaspersky, said. "Their new tool, Umbrij, automates the attackers’ attempts to gain access to organizational email accounts. This automation not only helps increase the scale and frequency of their attacks but also demonstrates ToddyCat’s strong motivation and advanced technical skills."

from The Hacker News https://ift.tt/HFyew81
via IFTTT

Identity Lifecycle Management Wasn't Built for AI Agents

Identity lifecycle management was architected around a person with an employment record, a manager, and a departure date. AI agents have none of those. As autonomous principals proliferate across enterprise environments, the governance model built for humans develops structural blind spots that traditional IGA tools weren't designed to detect. This guide covers where that model breaks, what it fails to govern, and what extending it to agents actually requires.

What Identity Lifecycle Management Was Designed to Handle

To understand why identity lifecycle management breaks down around AI agents, you need to understand what it was built to do well and who it was built for. The entire architecture rests on a single foundational assumption: every identity maps to a human being whose organizational status changes through documented, HR-driven events.

The identity lifecycle management process governs access from an identity's first provisioning event through every modification it accumulates to its eventual deactivation. At its core, it's an event-driven control system built around three canonical transitions: joiner, mover, and leaver.

HR as the Authoritative Engine

The HR platform, whether Workday, SAP SuccessFactors, or ServiceNow HR, functions as the system of record that drives the entire identity and access management lifecycle. A new hire record triggers automated provisioning into Active Directory or Azure AD, which propagates entitlements to downstream applications through IGA connectors. A department transfer updates role attributes and recalculates the appropriate entitlement set. A termination event triggers deprovisioning workflows across all connected systems.

The strength of the model is its determinism. Access rights reflect a verifiable organizational fact: a person holds a specific role in a specific team under a specific manager. Role-based access control maps those attributes to defined entitlement sets, delivering the right permissions at onboarding without manual negotiation per account.

Identity governance lifecycle management builds accountability on top of that structure. Access certification campaigns route to the identity manager or application owner for attestation. Separation-of-duties controls detect conflicting permissions. Audit logs tie every provisioning action back to the originating HR event and the approver who authorized it, providing the compliance evidence that frameworks such as SOX, HIPAA, and PCI DSS require.

What the Identity Lifecycle Management Phases Enforce in Practice

When an employee changes roles, attribute updates automatically recalculate entitlements, revoking what the new role doesn't require and granting what it does. When an employee leaves, the HR termination event triggers deprovisioning across all connected applications. Certification campaigns run on a defined cadence to fill the gaps between events, requiring managers to attest to current access against current role requirements.

Every control in the standard identity lifecycle management phases assumes a human principal with an employment record, a manager relationship, and a predictable transition pattern. Access review workflows route to humans. Provisioning triggers are triggered by humans entering or changing their status in the HR system. Offboarding fires when a human's organizational status changes.

The model is coherent, auditable, and well-supported by decades of IGA tooling. It reliably governs the human identity population. The problem begins precisely at its edges, where the principals accumulating access inside enterprise environments no longer have employment records, managers, or departure dates.

Where AI Agents Fall Outside That Model

AI agents don't arrive through HR. They don't have employment records, reporting structures, or defined role profiles that map to entitlement sets. They are created by engineers, orchestration frameworks, or automated deployment pipelines, and they land in production with whatever permissions the developer scoped at creation time or whatever the platform granted by default.

That origin story breaks every assumption the identity lifecycle management model depends on.

No Authoritative Source, No Governed Entry Point

Standard identity and access management lifecycle controls require an authoritative source to initiate provisioning. For humans, that source is the HR system. For AI agents, provisioning typically happens through a developer committing a configuration file, a platform API call that instantiates a new agent runtime, or an orchestration layer like LangChain, AutoGen, or AWS Bedrock Agents spinning up a new execution context. None of those events touches an IGA platform. None generates a provisioning record tied to a defined identity owner.

The agent arrives with credentials already attached: a manually created service account, an API key generated and stored in an environment variable, or an OAuth grant issued through a developer consent flow. The IGA platform, if it sees the credential at all, treats it as a static machine identity with a fixed purpose. What it's actually dealing with is an autonomous principal that will make access decisions, traverse API boundaries, and accumulate behavioral scope in ways no static service account ever does.

Dynamic Scope in a System Built for Fixed Roles

Role-based access control works because human job functions are, within limits, predictable. A database administrator needs specific permissions. A finance analyst needs access to a defined set of systems. Entitlement sets get designed around those functions and updated when roles change through documented HR events.

AI agents don't operate within fixed functional boundaries. An agent built to summarize internal documents may, through tool-calling or RAG retrieval patterns, end up querying APIs it wasn't explicitly provisioned for, writing outputs to storage systems outside its original scope, or chaining actions across multiple enterprise systems to complete a task. The access surface expands at runtime, driven by the agent's objective-seeking behavior rather than by any policy decision made in advance by a governance team.

Identity lifecycle management phases weren't designed to govern runtime-expanding scope. They were designed to govern access defined at provisioning and adjusted at known transition points.

Simultaneous Multi-Environment Instantiation

A human identity exists in one place at a time. An AI agent can run as dozens of parallel instances across cloud environments, containerized workloads, and SaaS API surfaces simultaneously. Each instance may carry its own credential set, its own tool permissions, and its own session context, none of which is correlated in any IGA system.

In multi-agent architectures, the complexity compounds further. Orchestrator agents spawn sub-agents, delegate tasks, and pass credentials between execution contexts. The identity and access management lifecycle has no native model for a principal that forks, delegates, and recombines access rights dynamically across a distributed execution graph.

When an IGA platform encounters an agent identity, it sees a service account with an API key or an OAuth client credential. Identity governance lifecycle management tooling applies the same governance logic it applies to any machine identity: it checks for an owner, verifies the credential age, and notes whether the account appeared in the last access review.

What it doesn't see is that the account is actively making authorization decisions, traversing application boundaries, and operating with a degree of autonomy that no traditional service account possesses. The governance record looks static. The actual access behavior is anything but.

The Lifecycle Events Agents Never Trigger

The joiner-mover-leaver model works because human employment generates a continuous stream of structured events that governance systems can act on. AI agents generate none of them. Every control point in the standard identity lifecycle management phases depends on a signal that agent deployments never produce by design.

No Joiner Event, No Governed Entry

When a new employee joins, the creation of an HR record triggers provisioning. Access gets scoped to a role definition, routed through an approval chain, and recorded in the IGA platform with an owner attached. The identity enters the governance boundary on day one.

An AI agent enters production through a deployment pipeline, a Terraform apply, or a direct API call to an agent orchestration platform. No IGA workflow fires. No access request gets submitted. No manager approves the entitlement set. The agent's credentials, whether a service account, an OAuth client, or an API key, are created inline with the deployment, often by the same automated process that provisions the compute environment. The identity and access management lifecycle never receives a joiner signal, so the governance record for that agent starts as a blank.

No Mover Event, No Entitlement Recalculation

When a human employee changes roles, HR attribute updates flow into the IGA platform, triggering entitlement recalculation. Access appropriate to the old role gets revoked. Access required by the new role gets provisioned. The governance record reflects the current organizational reality.

AI agents change scope constantly, and none of those changes generate a mover event. An agent retooled to access a new data source, extended to call additional APIs, or redeployed against a different environment doesn't update any HR system. No IGA connector receives an attribute change. No access review fires to reconcile what the agent now reaches against what it was originally provisioned for. Identity governance lifecycle management has no visibility into scope expansion that happens entirely within the deployment layer.

No Access Review Signal

Periodic access certification depends on a manager or application owner receiving a review task tied to a specific identity. That routing logic requires an identity with a human owner on record and an organizational relationship that the IGA platform can traverse.

Agent identities accumulate permissions across deployment iterations without generating any of the signals that recertification workflows depend on. Each new tool integration, each additional API scope, and each expanded OAuth grant layer is added to the agent's access profile without triggering a review. The what is identity lifecycle management question, answered honestly for agents, is a model that produces no certification record, no attestation history, and no evidence of ongoing governance.

No Leaver Event, No Deprovisioning

Offboarding fires when an HR termination record closes the employment relationship. The agent equivalent, a deployment being retired, a workflow being deprecated, or a project being shut down, produces no equivalent signal.

Retired agent credentials persist in secrets managers, environment variable stores, and OAuth authorization servers long after the workload they served stopped running. An identity lifecycle management solution built around HR-triggered deprovisioning has no mechanism to detect that an agent is gone. The credentials remain valid. The access paths remain open. The governance record shows an active identity because, from the IGA platform's perspective, nothing has changed.

What This Means for Provisioning, Reviews, and Offboarding

The governance gaps described above aren't theoretical edge cases. They produce concrete risks, compounding them at every operational stage of an agent's existence. When provisioning has no defined scope, when reviews produce no actionable signal, and when offboarding has no trigger, the access surface expands in only one direction.

Provisioning: Over-Permission as the Default Starting Point

Human provisioning starts from a role definition. The IGA platform maps job functions to an entitlement set, and the new identity receives access calibrated to what that function requires. Scope is defined before the identity exists.

Agent provisioning works in reverse. A developer needs the agent to complete a task and grants access broad enough to ensure success. The path of least resistance across major cloud and SaaS platforms is permissive: AWS IAM policies default toward broad resource access when scoped to wildcards, OAuth consent flows issue all requested scopes without challenging individual permissions, and service account creation in Azure AD or Google Workspace carries no built-in entitlement governance check.

The agent arrives in production over-permissioned from its first moment of operation, with no minimum-necessary baseline, no approval chain, and no IGA record linking the granted access to a defined business requirement.

Access Reviews: Routing Logic That Finds No Owner

Certification campaigns in standard identity governance lifecycle management platforms route review tasks based on identity attributes, specifically manager relationships and application ownership records. A reviewer receives a list of identities and their entitlements, confirms each access grant remains appropriate, and submits an attestation.

Agent identities break the routing logic at its foundation. Most carry no manager attribute. Many have no defined human owner in the IGA platform. Where application ownership records exist, they typically point to a team rather than an individual, and that team's familiarity with what the agent currently accesses rarely matches what was originally provisioned.

When certification campaigns do reach agent identities, reviewers attest to the access record in the IGA system, which reflects what was provisioned at creation rather than what the agent has accumulated through iterative deployment changes. The attestation is formally complete and operationally meaningless.

Offboarding: Credentials That Outlive Their Workload

HR-triggered deprovisioning is deterministic. A termination record closes, the IGA platform sends deprovisioning instructions to every connected application, and the access path closes at a defined moment.

Agent deprecation generates no equivalent signal. A development team retires a workflow, archives the repository, and decommissions the compute environment. The service account persists in Active Directory or Entra ID. The API key remains valid in the secrets manager. The OAuth authorization grant remains valid on the authorization server. None of the systems that issued those credentials received a revocation instruction because no system monitored the agent's operational status in the first place.

Stale agent credentials aren't a minor hygiene issue. A long-lived API key with production database access, attached to a workload that no longer runs, is an ungoverned access path with no owner, no review history, and no expiration. In environments running large numbers of agents across iterative deployment cycles, those credentials accumulate faster than any manual audit process can keep up with.

The identity and access management lifecycle, as currently implemented across most enterprise environments, has no mechanism to detect agent inactivity, flag credential age against operational status, or trigger revocation when a workload goes dark.

How to Extend Identity Lifecycle Management to Cover Agents

Extending identity lifecycle management to cover AI agents doesn't mean retrofitting HR-driven workflows onto a principal type for which they were never designed. It means rebuilding the governance logic around the agent's actual operational characteristics: how it gets created, how its scope evolves, and how its operational life ends.

Automated Discovery Across Every Deployment Surface

Agent identities get created across cloud provider IAM systems, SaaS OAuth authorization servers, Kubernetes service accounts, secrets managers, and CI/CD pipeline credential stores. No single system maintains a complete inventory, and agents deployed through automated pipelines frequently appear in none of the places a traditional IGA platform looks for them.

A genuine identity lifecycle management solution for agents requires continuous, automated discovery that instruments the environments where agents actually live: reading IAM policy attachments in AWS and Azure, extracting OAuth client registrations from authorization servers, surfacing service account configurations from Kubernetes namespaces, and identifying API keys embedded in runtime configurations. Discovery has to be ongoing because agent deployments change faster than any quarterly audit cycle can capture.

Attribute Modeling Built Around Agent Behavior

Human identity attributes map to organizational structure: department, job title, manager. Those attributes anchor entitlement decisions and review routing. Agent identity requires an entirely different attribute model.

Each agent identity needs a documented owning team, a defined operational purpose, a bounded list of the systems and APIs it's authorized to reach, a deployment timestamp, and an expected operational lifetime tied to the workload it serves. Behavioral attributes matter equally: which APIs the agent calls, how often, and across which data surfaces. An identity governance lifecycle management approach built for agents treats observed access patterns as governance inputs, using behavioral baselines to surface permission grants the agent holds but never exercises.

Policy-Driven Provisioning Scoped to Agent Function

Rather than granting access at deployment time and reviewing it later, provisioning for agent identities should follow the same least-privilege logic that mature IAM program frameworks apply to privileged human accounts: define the minimum access the agent requires to perform its documented function, enforce that scope through policy at credential issuance, and attach the credential to a defined owner who carries accountability for any scope changes.

In practice, this means integrating agent provisioning into IGA intake workflows rather than leaving it entirely within the deployment pipeline. When an agent requires access to a production API or a sensitive data store, that request routes through an access governance control, not around it.

Continuous Behavioral Monitoring as the Review Substitute

Periodic access certification produces no actionable signal for agent identities. The operational substitute is continuous behavioral monitoring: tracking what each agent actually calls, comparing observed access against the provisioned entitlement set, and flagging divergence in real time.

When an agent starts calling APIs outside its provisioned scope, that divergence is a governance event requiring immediate response, not a finding to surface at the next quarterly review. Behavioral monitoring closes the gap left by recertification campaigns across the identity and access management lifecycle for agent principals.

Deprecation Workflows Triggered by Operational Status

Offboarding for agents requires a trigger mechanism that reflects operational reality. Inactivity monitoring tied to credential usage logs provides the signal: an API key that hasn't generated an authenticated request within a defined window is a candidate for revocation review. Scope change detection flags when a deployment modifies the permissions attached to an agent credential, generating a governance event that routes to the owning team for reauthorization.

Connecting those signals to automated revocation workflows, integrated with AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, closes the offboarding gap without requiring a manual discovery step. The identity lifecycle management phases for agents end when operational status ends.

Where Orchid Security Fits In

Most enterprise IAM stacks govern the identity population they can see through their existing connectors. Agent identities, ungoverned credentials, and authentication paths that bypass the corporate IdP fall into the space that those connectors don't reach. That's the gap Orchid Security was built to close.

Continuous Discovery Across the Full Identity Surface

Orchid deploys lightweight orchestrators that instrument applications directly, extracting authentication flows, authorization logic, account configurations, and credential storage patterns from both managed and unmanaged environments. The result is a continuously updated identity inventory that reflects what the environment actually contains, including every agent identity, service account, and API credential that never passed through an IGA intake workflow.

For organizations asking what identity lifecycle management is in practice, Orchid's answer starts with visibility: you govern what you've found, and most programs haven't found everything.

An Identity Graph That Reflects Agent Reality

Orchid's identity graph maps every principal, human and non-human, to the authentication flows, entitlements, and application access paths it actually uses. For agent identities specifically, the graph surfaces the owning team, the provisioned permission set, observed behavioral patterns, and credential age, producing the attribute model that identity governance lifecycle management for agents requires, but traditional IGA platforms don't generate.

Guardrails for Autonomous Identity

Orchid's guardrails for the autonomous identity apply policy-driven controls directly to agent identity populations: scoped provisioning tied to documented agent function, continuous monitoring of behavioral divergence from provisioned entitlements, and deprecation workflows triggered by inactivity signals rather than HR events.

The platform integrates with existing IAM, PAM, and IGA infrastructure, routing remediation through the tools organizations already operate rather than replacing them. Governance scope expands to match the actual identity surface, including agent identities, and the identity and access management lifecycle extends to cover the principals that every traditional identity lifecycle management solution leaves outside its boundary.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/ZBK7j2Q
via IFTTT

XenServer 9 is here. You already own it. Now it’s time to put it to work.

Enterprises are under pressure from three directions at once: rising virtualization costs, increasing licensing uncertainty, and growing operational complexity. At the same time, many business-critical workloads remain on-premises or in hybrid environments. For these organizations, control over cost, performance, governance, and data sovereignty matters as much as agility.

For Citrix customers, the answer is closer than most realize. XenServer 9, generally available today, is included in the existing Citrix Platform License (CPL), Universal Hybrid Multi Cloud (UHMC), and Citrix for Private Cloud (CPC) entitlements, with up to 10,000 sockets at no additional cost. That changes the economics of the rethink entirely.

XenServer 9 for enterprise virtualization: reducing cost and operational complexity

XenServer 9 is built for organizations actively reassessing their virtualization strategy under cost pressure. It reduces operational complexity, strengthens security, and provides predictable lifecycle management across on-premises and hybrid environments. Beyond licensing, XenServer 9 simplifies infrastructure operations. A consolidated management plane, predictable lifecycle updates, and native integration with Citrix DaaS mean fewer tools, fewer handoffs, and a clearer upgrade path for environments that have grown over years.

How XenServer 9 simplifies virtualization operations and lifecycle management

While cost is often the initial driver for evaluation, long-term platform decisions are ultimately determined by operational impact. XenServer 9 is designed to reduce that burden by simplifying lifecycle management, upgrades, and ongoing system maintenance.

Instead of requiring large, disruptive upgrade cycles, XenServer 9 enables a more incremental and controlled approach to change. This helps infrastructure teams reduce operational risk while maintaining stability in production environments—particularly in large-scale or distributed infrastructures.

Improving performance, security, and reliability with XenServer 9

XenServer 9 strengthens the underlying platform, improving performance, security, and operational continuity. Workloads benefit from more efficient resource utilization and improved hardware alignment, helping deliver more consistent application performance across modern infrastructure environments.

At the same time, the platform introduces stronger security foundations, including hardware-level protections that help ensure system integrity from boot onwards. This reduces exposure to low-level threats and strengthens the overall security baseline for enterprise deployments.

Lifecycle and driver management have been improved to reduce disruption during updates and hardware changes. This allows organizations to maintain compatibility with modern infrastructure while reducing operational overhead during maintenance cycles.

While XenServer 9 is supported with any workload, it also enhances operational alignment in Citrix DaaS environments. By improving visibility at the infrastructure layer, it helps administrators understand the potential impact of maintenance and change activities on running workloads and end-user sessions. This supports more informed operational decisions and helps reduce the risk of unintended disruption during infrastructure changes.

How XenServer 9 helps regain control of virtualization cost and complexity

Taken together, these capabilities reinforce a clear message: XenServer 9 is a pragmatic response to the pressure infrastructure teams are facing today. It reflects a market reality in which cost, operational simplicity, and stability are tightly interconnected requirements that must be addressed together.

In this context, platforms are no longer defined by feature breadth, but by their ability to deliver predictable economics and operational stability over time. XenServer 9 is built for exactly that shift. It helps organizations regain control over their virtualization environments, reduce operational complexity, and establish a stable foundation for both current and future workloads across on-premises and hybrid environments.

Getting started with XenServer 9

XenServer 9 is available today at no extra cost for customers on CPL, UHMC, and CPC licenses.

To learn more about XenServer 9 or evaluate its fit for your environment, connect with your Citrix representative or explore the XenServer webpage.

from Citrix Blogs https://ift.tt/XeHTR5L
via IFTTT

FortiBleed Credential Theft Linked to INC and Lynx Ransomware Operations

The recently discovered financially-motivated FortiBleed campaign has been attributed to INC and Lynx ransomware operations, indicating that the verified, stolen credentials were intended for follow-on intrusions.

"An operator tied to FortiBleed's infrastructure was found actively working negotiation panels for both groups, tying mass FortiGate credential theft directly to ransomware deployment for the first time," SOCRadar said in a new report published Wednesday.

The company said it tracked scanning activity against approximately 11,250 FortiGate portals in more than 150 countries, followed by confirmed admin-level access on 409 targets and successful completion of the full attack chain on 354 of them. In all, at least 12 ransomware deployments have resulted from this access, causing hundreds of endpoints to be encrypted across affected organizations.

The large-scale credential-harvesting operation, which came to light last month, involved the threat actors systematically scanning the internet for exposed Fortinet devices, attempting to break into them using known credential combinations, and then deploying custom packet sniffers to passively gather credentials and other authentication data from network traffic.

The campaign is assessed to have targeted 430,000 FortiGate firewalls globally, gathering over 110 million credentials in the process. The activity was exposed after an operational security error on the part of the attackers left a server containing credentials stolen from thousands of Fortinet appliances exposed on the internet.

The Golang sniffer is estimated to have been installed on about 12,000 Fortinet devices, making it a subset of the total number of networking gear targeted.

The latest findings from SOCRadar show that an operator with access to FortiBleed infrastructure was found logged in to both INC Ransom and Lynx negotiation panels, with victims listed by INC Ransom overlapping with data from the campaign. The links are based on one of the 200 newly discovered servers associated with the FortiBleed infrastructure that granted visibility into internal files, logs, and operational documentation.

Tooling, logs, and working hours indicate that the activity is the work of a Russian-speaking threat actor who likely operates as an initial access broker. Much of the targeting has singled out manufacturing, technology, and logistics sectors in Latin America and the Asia Pacific regions.

SOCRadar also said it discovered an internal document that indicates it's an organized operation comprising about 20 people with a clear division of labor. "A small core of lead operators drives most high-impact intrusions, backed by specialists and support staff," it added.

In addition, the threat actors are believed to be in possession of at least one zero-day vulnerability in Nextcloud. The threat intelligence firm said it's actively coordinating with the affected vendor.

The disclosure comes as eSentire said it observed threat actors exploiting a flaw in Fortinet FortiClient EMS (CVE-2026-35616, CVSS score: 9.1) to deploy an information stealer called EKZ Stealer against a customer in the energy, utilities, and waste sector with the end goal of harvesting credentials from Chromium-based browsers and Firefox and exfiltrating them via PowerShell. 

from The Hacker News https://ift.tt/bxMPvVG
via IFTTT

New ChocoPoC RAT Targets Vulnerability Researchers via Fake PoC Exploit Repos

Attackers are hiding a data-stealing trojan inside fake exploit code aimed at the people who hunt bugs for a living. The malware, called ChocoPoC, travels in Python proof-of-concept (PoC) repositories on GitHub that claim to exploit hot new CVEs.

Run one, and it quietly lifts your saved passwords, browser cookies, and files, then hands the attacker a shell on your machine. YesWeHack and Sekoia published their joint findings on July 1 and warned that, as of that report, the malware and its servers were still live, so do not run any of these PoCs.

The trick is where the code sits. The visible PoC looks clean. The malware hides in a Python package that the PoC pulls in as a dependency, so it slips past a quick code review.

How the trap works

The bait is time pressure. When a big flaw drops, researchers race to test it and grab community PoCs to move fast. This campaign turns that habit into an infection route.

The chain, in plain terms:

1. You clone the repo and run pip install to fetch the PoC's requirements.
2. That pulls in a package named frint, which in turn drags in a second package, skytext.
3. skytext ships a small compiled file (gradient.so on Linux, gradient.pyd on Windows) that runs the moment you launch the PoC.
4. It only wakes up when it sees the real PoC loaded, checking for a file named EXPLOIT_POC.py or similar, then unpacks its payload and downloads the trojan.

That last check is why a plain sandbox sees nothing. Detonate the package on its own, without the full PoC around it, and the malware stays asleep.

What it steals and does

Once running, ChocoPoC is a full remote access trojan. It pulls saved passwords, cookies, autofill, and history from Chrome, Brave, Edge, and Firefox. It grabs text files, notes, and local databases, along with shell history, network settings, and the list of running processes.

The attacker can also run any shell command, run arbitrary Python, pull whole folders, and slow the malware down to stay quiet. Several command names are in Spanish, and the code carries small bugs, which the researchers read as hand-written rather than AI-generated.

For control, the malware hides in plain sight. It reads its orders from a dataset on Mapbox, a normal mapping service, using it as a dead drop. It resolves that address over DNS-over-HTTPS and uses a domain-fronting trick, so the traffic looks like ordinary Mapbox API calls. Larger uploads go to a separate server at 91.132.163.78.

How far has it spread

YesWeHack and Sekoia found at least seven fake PoC repos, each tied to a high-profile flaw:

• FortiWeb path traversal (CVE-2025-64446)
• React2Shell (CVE-2025-55182)
• MongoBleed (CVE-2025-14847)
• PAN-OS auth bypass (CVE-2026-0257)
• Ivanti Sentry command injection (CVE-2026-10520)
• Check Point VPN auth bypass (CVE-2026-50751)
• Joomla SP Page Builder RCE (CVE-2026-48908)

The skytext package alone was downloaded about 2,400 times, mostly on Linux. Downloads do not prove anyone was infected, but they spiked right after major CVEs went public, which fits the lure.

An earlier run of the same campaign, going back to late 2025, used two other packages, slogsec and logcrypt.cryptography, with near-identical code. Sekoia assesses with high confidence that one actor is behind both, based on reused control markers.

It says the operator rotated through GitHub, PyPI, and Mapbox accounts, several built from leaked or stolen logins. No known group has been named.

Security researchers make a rich target. They run untrusted code by design, often with high privileges, and their machines hold client credentials, private reports, and details of live engagements. Compromise one, and you can reach far past a single laptop.

The MUT-1244 campaign showed the payoff, using fake PoC repositories to steal SSH keys and cloud credentials from red teamers and researchers.

This is not a new idea, only a new wrapper. North Korea's Lazarus group has courted researchers for years, posing as fellow bug hunters and shipping malicious Visual Studio projects in 2021, then burning a zero-day on them in 2023, with fresh waves since.

On the commodity-crime side, Trend Micro found a fake PoC for a Windows LDAP flaw (CVE-2024-49113) that stole researcher data in early 2025, and a separate campaign pushed fake CVE PoCs carrying a trojan called WebRAT in late 2025, mostly hitting students and junior testers.

What ChocoPoC adds is the hiding spot. The malware lives in a dependency, so the PoC you actually read stays clean. As the researchers put it, the malware itself is old news, but "what is changing is the delivery mechanism."

What to do now

• Treat any PoC as hostile until proven otherwise, and steer clear of code from brand-new or unknown accounts.
• Read the full dependency chain, not just the PoC file. Watch for freshly published packages, unfamiliar maintainers, and accounts with hidden history.
• Test only in a throwaway VM, but remember isolation alone will not trip this one. The real fix is not installing the packages at all.
• Check your systems for frint, skytext, slogsec, and logcrypt.cryptography, plus the file hashes in the report. If you ran any of them, rotate credentials and rebuild the host.

The bigger risk is downstream. These lures target the researchers who supply detections and PoCs to frameworks like Nuclei and MDUT. Sekoia flags the danger of a double supply chain hit: poison one researcher, and the bad code can ride into a framework thousands of others trust.

from The Hacker News https://ift.tt/QdzIFSD
via IFTTT

SharePoint RCE CVE-2026-45659 Added to CISA KEV After Active Exploitation

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added a high-severity flaw impacting Microsoft SharePoint Server to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.

The vulnerability, tracked as CVE-2026-45659 (CVSS score: 8.8), is a case of remote code execution arising from the deserialization of untrusted data. The issue was addressed by Microsoft in May 2026 for SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016.

Microsoft noted that any authenticated attacker could trigger the vulnerability, and that it does not require admin or other elevated privileges. In a network-based attack, an authenticated attacker with a minimum of Site Member permissions (PR:L) could leverage it to execute code remotely on the SharePoint Server.

"Microsoft SharePoint Server contains a deserialization of untrusted data vulnerability which allows an authorized attacker to execute code over a network," CISA said.

According to the Windows maker's advisory, the flaw has been tagged with an "Exploitation Less Likely" assessment. It's currently not known how the vulnerability is being exploited, who is behind the activity, and what the end goals of these efforts are.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are advised to apply the fixes by July 4, 2026.

Microsoft Uncovers Parallel Threat Activity from 2 Clusters

Late last month, Microsoft revealed that a routine ransomware investigation uncovered two unrelated attackers operating simultaneously within the same network, while adopting deliberate techniques to establish persistent access and complicate incident response efforts.

One set of attacks has been attributed to Storm-2603, a threat actor known for deploying Warlock ransomware often by exploiting known vulnerabilities in on-premises SharePoint servers since mid-2025.

"In this case, initial access was likely attempted through a separate vulnerability, with requests for files like win.ini and web.config, indicating probing for local file inclusion," Microsoft said. Evidence points to it being CVE-2025-11371 (CVSS score: 9.1), a critical flaw impacting Gladinet Triofox.

Upon gaining initial access, the threat actor is said to have deployed tools like Velociraptor to blend malicious activity with trusted administrative behavior, as well as established multiple remote access channels through Cloudflare tunneling, Zoho Assist, and Secure Shell (SSH) connections configured through Visual Studio Code.

The attack also escalated privileges by creating new local and domain administrator accounts, while a vulnerable driver ("NSecKrnl.sys") acted as a conduit for tampering with endpoint security protections to help reduce their visibility.

In tandem, Microsoft said it uncovered signs of a second, unrelated threat actor co-existing in the same environment using DLL side-loading and custom backdoors, thereby making attribution more challenging.

Further investigation uncovered that the attackers had moved laterally beyond the first network and into a second organization, which confirmed they had been compromised by the same ransomware activity attributed to Storm-2603.

"Together, these overlapping activity streams enabled sustained access while masking the full scope of the intrusion," the Microsoft Incident Response team said. "The blend of known ransomware tactics and hidden techniques allowed the threat actors to establish deep and lasting access."

"What may appear to be a single ransomware incident can quickly expand into something more complex-spanning organizations, blending tactics, and even involving multiple threat actors operating in parallel. For security teams, the implication is clear: isolated signals rarely tell the full story."

from The Hacker News https://ift.tt/GpDlBgX
via IFTTT

StarWind Virtual SAN Free: A PowerShell Scripting Quick Start

StarWind Virtual SAN Free is a great HA storage solution for homelabbers and even production. Unlike the trial license that expires in 30 days, the free license is eternal would work for much longer (stay tuned for the upcoming changes in VSAN Free licensing).

There are some caveats, though: no GUI for LUNs creation and support means the community forum. Our engineers will happily help you there.

Management and initial setup run entirely through PowerShell. You can build your own scripts from the included samples, and you’ll want to. The CreateHA script is the most commonly asked question on the forum. What follows covers scripts for both Linux and Windows installations, plus how to standardize deployments across multiple sites.

Deployment workflow

1. Grab the deployment guide for your hypervisor from the resource library. Follow it until you hit the step where you create StarWind Highly Available (HA) devices.

2. Stop there.

3. Create HA devices with the script below, then pick the guide back up where you left off. Check your system against the StarWind VSAN system requirements and the best practices guide before you start.

How to get the scripts?

CreateHA_2 and CreateHA_3 ship inside the StarWindX module, which you install from the same executable as StarWind VSAN itself. The latest build is on the downloads page.

Pick the right hypervisor during download. (Check your confirmation email if you lost the link.)

The Windows installer is straightforward:

1. Run it as Administrator.

2. Hit Next.

3. Select Management Console from the drop-down and tick Integration Component Library. The Windows Management Console works for monitoring even in the Free edition, and neither piece asks for a license key. Just pay attention to what you select.

4. Click Next again.

5. Create a desktop icon if you want one, then hit Next once more.

6. Then click Install.

For Linux-based setups (i.e., bare metal and CVM), grab the installer from the Web UI. Hit the gear icon, then Downloads. Once Management Console and StarWindX are on the box, the samples sit at C:\Program Files\StarWind Software\StarWind\StarWindX\Samples\powershell.

The script

Now, lets take a look at the script. The script below is pretty much a standard Create2HA.ps1 with some minor adjustments.

param($addr="172.27.31.198", $port=3261, $user="root", $password="starwind",

$addr2="172.27.31.199", $port2=$port, $user2=$user, $password2=$password,

#common

$initMethod="NotSynchronize",

$size=1024,

$sectorSize=512,

$failover=0,

$bmpType=1,

$bmpStrategy=0,

#primary node

$imagePath="/mnt/sdb1/volume1",

$imageName="test2",

$createImage=$true,

$storageName="",

$targetAlias="test2",

$poolName="pool1",

$syncSessionCount=1,

$aluaOptimized=$true,

$cacheMode="none",

$cacheSize=0,

$syncInterface="#p2=172.16.20.231:3260,172.27.21.231:3260",

$hbInterface="#p2=172.16.10.231:3260,172.27.31.199:3260",

$createTarget=$true,

$bmpFolderPath="",

#secondary node

$imagePath2="/mnt/sdb1/volume1",

$imageName2="test2",

$createImage2=$true,

$storageName2="",

$targetAlias2="test2",

$poolName2="pool1",

$syncSessionCount2=1,

$aluaOptimized2=$false,

$cacheMode2=$cacheMode,

$cacheSize2=$cacheSize,

$syncInterface2="#p1=172.16.20.230:3260,172.27.21.230:3260",

$hbInterface2="#p1=172.16.10.230:3260,172.27.31.198:3260",

$createTarget2=$true,

$bmpFolderPath2=""

) 


The full parameter list is documented in the configuration guide. A few need explanation.

User and password

The defaults for talking to the service are root/starwind. They stay the same even if your CVM uses different credentials.

The password is stored encrypted in

C:\Program Files\StarWind Software\Starwind\StarWind.cfg

For CVM and Linux bare-metal deployments, that path is

/opt/starwind/starwind-virtual-san/drive_c/starwind/StarWind.cfg

initMethod

Do you want initial sync to happen or not? Skipping synchronization when creating devices saves time. The script uses NotSynchronize for this reason, though you can also set this to SyncFromFirst, SyncFromSecond, or SyncFromThird to force a full sync from a specific node right away.

size

Device size in MB.

sectorSize

Either 4096 or 512. A sector size of 512 is required for Linux-based systems (and it works fine on Windows too). VMs running databases sometimes behave oddly with 512.

failover

Set 0 for Heartbeat, 1 for Node Majority. In CreateHA_3.ps1, you can set this parameter to 1 to create a 3-way replica using Node Majority. Node Majority relies only on synchronization links for communication. You can drop the heartbeat line entirely. If you need a 2-way mirrored device with Node Majority, use CreateHAPartnerWitness.ps1 or CreateHASmbWitness.ps1 instead. Learn more about failover strategies here.

bitmap block

RAM works most of the time. If you’re unsure, or there is no storage faster than the data disk connected, leave it as is. Learn more about bitmap here

imagePath

Where the device sits. Watch your forward and backward slashes. In CVM, HA devices sit on the block device formatted as XFS while creating a volume.

imageName

Name for the imagefile.img. That isn’t the target name yet. Stay consistent. You can use the same name on both nodes.

storageName

Leave it. It’s only used if you’re adding a partner to an existing device.

targetAlias

The iSCSI target name. Choose it carefully. It can be node-specific like host1-target1. In practice target1 is enough. The same name works on both nodes.

poolName

Leave it. It relates to SMI-S provider work.

syncSessionCount

Leave it. This controls how many iSCSI sessions an HA device establishes over a sync interface. A value of 1 is enough in most cases. You can try 2. Don’t expect a positive performance impact. It’s rarely set higher than that.

aluaOptimized

Leave it as is.

Caching

In most cases you don’t need a cache. Unlike the controller cache, it isn’t battery-backed. Learn more here about how caching works.

syncInterface

The partner synchronization IP address. This must be a dedicated IP that is not used for data or management traffic.

hbInterface

The partner heartbeat IP addresses. VSAN uses heartbeat only for ping. You can set heartbeat over the data and management links if you want. At least one StarWind communication path should go over a different NIC to avoid split-brain.

For Windows-based installations, the same rules apply. Watch your slashes. The imagePath should look like My computer\C\starwind

Common issues

Things go sideways. Usually it’s one of five things.

• It might not work on the first attempt. Remove leftover files from C:\Program Files\StarWind Software\StarWind\headers and from the underlying storage. For CVM and Linux, check /opt/starwind/starwind-virtual-san/drive_c/starwind/headers.
• Back up your working script. Updating StarWindX overwrites anything saved in the default folder at C:\Program Files\StarWind Software\StarWind\StarWindX\Samples\powershell.
• StarWindX and StarWind VSAN versions must match. Use the same executable as the installed service version. If you installed VSAN from that executable, you’re fine. For CVM, check the Dashboards view. Compare the VSAN build shown there against the executable by right-clicking it, choosing Properties, then Details.
• Open ports 3260 and 3261 in the firewall. Port 3261 is for the Management Console. 3260 is for iSCSI.
• If you’re running multiple iSCSI connections in Windows – like 127.0.0.1 plus two partner IPs – set iScsiDiscoveryListInterfaces to 1. This is Windows-specific. Actually, it also applies to compute and storage separated scenarios.

Adding a partner to an existing device

Make sure every device is synchronized and connected from both replication partners to every node that consumes the storage.

1. Stop the StarWindService on one node. On CVM or Linux, run:

   sudo systemctl stop starwind-virtual-san.

   For Windows, open services.msc and stop the StarWind Virtual SAN service.

2. Navigate to C:\Program Files\StarWind Software\StarWind. On CVM, that’s /opt/starwind/starwind-virtual-san/drive_c/starwind/StarWind.cfg.
3. Copy StarWind.cfg.
4. Edit it as described above.
5. Start the StarWindService.
6. Wait for fast synchronization to finish.
7. Repeat on the other node.

What about CreateHA_3?

CreateHA_3 builds a 3-way-mirrored HA device and supports both Node Majority and Heartbeat failover strategies, which is why you need to be careful with the interface parameters.

For a 2-way mirrored HA device using Node Majority, use CreateHAPartnerWitness.ps1 or CreateHASmbWitness.ps1. Those scripts have the same syntax but use only synchronization networks for heartbeat. They don’t use dedicated heartbeat networks. In CreateHA_3, pay attention to the sync- and hbInterface parameters. Double-check that you’re entering the replication partner IPs, not the local node IPs, for both heartbeat and sync interfaces.

FAQ

Why might replication be taking a while?

Check the $initMethod value and the device size.

Replication fails with error 200

Two things usually cause this. First, check if there is leftover content in the destination directory or /headers folder. Second, verify the interfaces are set up correctly on both primary and secondary nodes.

The device is created on one node but not the other

Verify interface configuration on both sides.

Sync keeps interrupting

Check MTU values and make sure they’re aligned across the entire stack. If you suspect networking, start with MTU at the base 1500. That’s 1514 for most Windows drivers.

How do I create a device from an existing .img file?

There isn’t a stock script for that. You’ll need to write your own. Good luck.

Final configuration checks

Creating a device properly is how you avoid split-brain. The displayed script configures redundant paths to keep HA devices resilient against NIC failures.

If you’re deploying StarWind VSAN for the first time, stick to the default Create2HA.ps1 parameters. Get the two nodes talking, verify the sync completes, and only then start tuning cache or failover strategies.

from StarWind Blog https://ift.tt/rNc0wF1
via IFTTT

Microsoft named a leader in the Frost Radar for cloud and application runtime security

Cloud security is shifting from visibility to contextual risk reduction, extending into the applications, APIs, and workloads where attacks actually occur. Because modern workloads are built and run in the cloud, security teams must understand which exposures matter most, prioritize what can truly be exploited, and reduce risk across the full stack from infrastructure to application runtime.

As organizations expand across multicloud and hybrid environments, they adopt modern architectures built on containers, Kubernetes, microservices, APIs, and AI-powered workloads. This increases both the volume and interconnectedness of security signals. The challenge is no longer identifying individual risks, but determining how vulnerabilities, identities, and data exposures combine across infrastructure and the applications running on it to create real attack paths, and which of these are most critical to fix at the source. Effective risk reduction depends on understanding which of these paths are actually reachable and exploitable in a live environment.

Frost & Sullivan’s 2026 Frost Radar™ for Cloud/Application Runtime Security (CARS) reflects this shift. The report highlights how cloud security is evolving from a collection of posture and workload capabilities into a unified runtime risk operations model, correlating signals across code, cloud, runtime, applications, and security operations center (SOC) workflows to prioritize and reduce risk continuously.

Read the full Frost Radar report

Within this evolving market, Microsoft is positioned as a visionary leader because of the scale of its hyperscale ecosystem, operational breadth of Microsoft Defender for Cloud when integrated with Microsoft Defender XDR, and large customer base. That recognition reflects where the category is heading: toward platforms that connect cloud and application security into one operational view of risk.

Why cloud security is being redefined

The Frost Radar makes a clear point: cloud security is no longer about visibility or compliance alone. It is becoming an operational discipline for reducing risk across the full runtime—from cloud infrastructure to the application code executing on top of it.

Modern environments introduce complexity across:

• Multicloud and hybrid infrastructure.
• Rapid development and continuous deployment.
• Containers, serverless, microservices, and APIs.
• AI-powered workloads, agents, and machine identities.

This complexity exposes the limits of traditional, siloed tools—where cloud posture, workload protection, and application security each live in their own console. Organizations now need platforms that can:

• Correlate posture, runtime, identity, data, and application signals.
• Prioritize risk based on exploitability—not severity alone.
• Integrate security across development, cloud operations, and the SOC.
• Validate whether a vulnerability is actually reachable inside a running application.

This is the shift the report describes: from detecting issues to operationalizing risk reduction across the lifecycle—and across both cloud and application layers.

What distinguishes leading platforms

Frost & Sullivan evaluates providers on growth and innovation—but, more importantly, on how effectively they help organizations manage real risk. Five themes define the next generation of platforms:

1. Platform unification over point solutions.
2. Code-to-cloud-to-SOC integration.
3. Risk prioritization based on exploitability.
4. Correlation across identity, data, cloud, and application context.
5. Expansion into AI-powered workloads.

Taken together, these capabilities represent a move from fragmented visibility to connected, contextual risk management that spans cloud detection and response (CDR) and application detection and response (ADR)—the two halves the market is converging into a single runtime fabric.

How Microsoft help organizations manage real risk

1. Connect signals to prioritize real attack paths

Most security tools surface large volumes of findings across cloud infrastructure and applications, but isolated findings do not reflect how cyberattacks actually happen. Threat actors exploit how misconfigurations, excessive permissions, and data exposure combine to create a path to critical assets.

Microsoft Defender for Cloud correlates posture, identity, data, and runtime signals to identify which risks are truly exploitable. A misconfigured storage resource on its own may appear low priority. However, when it is exposed to the internet, combined with excessive access permissions, and connected to sensitive data, it becomes part of a clear attack path that can be used to compromise the environment.

What this means: Security teams can prioritize real attack paths instead of individual findings, helping to reduce alert fatigue and improve remediation speed and precision.

Get started with Microsoft Defender for Cloud

2. Continuously validate and act on risk across the lifecycle

Security needs to operate continuously across development, runtime, and operations, spanning both the application and the cloud environment it runs in. Defender for Cloud connects insights across code and infrastructure definitions, cloud configuration and runtime context, application and API layers, and security operations workflows through Defender XDR.

A vulnerability identified before deployment can be tracked through to runtime, where it is evaluated in the context of the running environment and surfaced in security operations if it is determined to be exploitable.

What this means: Organizations can continuously validate risk and respond more effectively by connecting development, cloud environments, and security operations.

3. Reducing complexity across fragmented cloud and application security workflows

As environments scale, fragmented tools and workflows make it difficult to understand how risks connect and where to focus first. When cloud infrastructure and application security are managed separately, investigation becomes slower and more manual.

Defender for Cloud helps bring these signals together in a single investigative flow, where risks can be analyzed across configuration, runtime context, application behavior, and identity exposure.

Instead of switching between separate tools, security teams can investigate a single incident across its initial misconfiguration, runtime impact, application behavior, and identity exposure, a more connected experience.

What this means: Security teams can investigate faster, prioritize risk more efficiently, focus on what matters most, and respond more quickly across fragmented cloud and application environments.

What this signals for security leaders

The Frost Radar offers a signal for where cloud security is headed: toward platforms that connect context across cloud and application environments so teams can prioritize the risks most likely to be exploited and reduce exposure faster. Security leaders should now ask:

• Can the platform correlate signals across identity, endpoints, data, cloud, runtime, and applications?
• Does it span the full code-to-cloud lifecycle—and reach into the SOC?
• Can it prioritize risk based on exploitability—not just severity?
• Does it bring cloud detection and response together with application detection and response?
• Can it scale across multicloud and AI environments?

These are the capabilities that define the next generation of cloud and application runtime security.

Bottom line

Frost & Sullivan’s 2026 CARS analysis reinforces a clear shift: cloud security is moving from fragmented visibility to unified, contextual risk management across the entire lifecycle—and across both the cloud and the application layer.

Microsoft’s position as a visionary leader in the Frost Radar reflects this shift—bringing together posture, runtime, identity, endpoints, data, and application signals into a connected platform that helps organizations prioritize and reduce risk continuously.

Get the full Frost Radar report

Learn more

• Read Frost & Sullivan’s 2026 Frost Radar™ for Cloud/Application Runtime Security to see how leading vendors are evaluated—and how the category is shifting toward unified cloud and application runtime risk operations.
• Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Microsoft named a leader in the Frost Radar for cloud and application runtime security appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/yS2zpDX
via IFTTT