Break the silence: Kazakhstan-nexus UAT-6275 targets CIS government organizations

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

---

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Figure 1. Regional targeting.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Figure 2. Lure document masquerading as a Russian diplomatic congratulatory letter to the Armenian Ministry of Foreign Affairs. 

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Figure 3. Decoy impersonating Turkmennebit and proposing cooperation with Orsk Oil Refinery management.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Figure 4. Campaign timeline. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

Figure 5. First observations of four UAT-6275 infection chains, June 2025 – April 2026.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

Figure 6. Chain C retrieves a GitHub-hosted PowerShell script; later samples also deploy PickleShell to the Startup folder.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Figure 7. Chain D exploits CVE-2025-8088 to place PickleShell in the Windows Startup folder for execution at the next sign-in.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Figure 8. Timing of 77 GitHub commits in UTC+3 and UTC+5, with 09:00–18:00 local working hours shaded.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

from Cisco Talos Blog https://ift.tt/Upe3zax
via IFTTT

ShapeBlue Migrate v0.6.0: OVERLAY Migrations No Longer Require Powering Off the VMware VMs

ShapeBlue Migrate v0.6.0 is now available to all ShapeBlue customers who need to migrate from VMware to Apache CloudStack! The key improvement in the new version is that OVERLAY no longer needs the VMware VM powered off. The VM keeps running while the migration prepares, then waits for its cutover policy, the same way Changed Block Tracking (CBT) works. That gives Migrate two warm migration methods instead of one. OVERLAY can now also work from VMFS source storage, and it consolidates its disks automatically after the move.

 

Download the Product Brief

 

OVERLAY Is Now a Warm Migration Method

OVERLAY is the fastest of Migrate’s four transfer methods. It creates a qcow2 overlay on top of the source VMDK and converts in place, so no disk data crosses the network. Until now, the catch was that the source VM had to be powered off before the migration started, so downtime began at the start of the migration instead of at the cutover.

In v0.6.0 the source VM stays up. The migration prepares while the VM runs, then waits in Awaiting Cutover until its cutover policy fires. Downtime happens only at the cutover, and you get OVERLAY’s speed without shutting the workload down early.

That leaves two warm methods to choose from, per VM or per wave. CBT copies data over the network and re-syncs changes. OVERLAY skips the copy entirely when the storage layout allows it.

 

VMFS source storage, via Relocate

OVERLAY’s other limit was storage. It needs the source datastore to be an NFS export that is also mounted in CloudStack as primary storage, which ruled out VMFS.

v0.6.0 adds a relocation step. A VM on VMFS is moved with Storage vMotion, while it keeps running, to the NFS datastore set as the Relocate via target in its datastore mapping. If the migration fails or is cancelled, or once a completed migration has been consolidated, Relocate back returns the VM to its original datastores on request.

A pre-flight check reports every problem with the target, the vCenter privileges and CloudStack’s backing-file setting before anything moves, and a Storage vMotions in flight setting limits how many relocations run at once. vSAN and VVol are expected to work the same way but are not yet tested.

 

Automatic Disk Consolidation

After an OVERLAY import, the migrated volume is a qcow2 file backed by the source VMDK. Until that chain is collapsed, the source datastore stays in use and the source VM has to stay powered off and untouched.

v0.6.0 collapses the chain for you. The new OVERLAY chain consolidation setting runs whether the migrated VM is running or stopped in CloudStack, and a running VM takes no extra downtime for it. When it finishes, the source VM and its files are released.

Each finished OVERLAY migration also gets its own Consolidate button, and outstanding consolidations are flagged so they don’t get forgotten. A bandwidth cap limits the load on the NFS export while they run. Consolidations use their own lane on each worker, so they don’t take a migration slot or hold up a cutover.

 

Warm Migration Without VDDK

OVERLAY has never depended on VMware’s VDDK library. That mattered less while it required a powered-off VM, because an estate that couldn’t get VDDK was left with cold migrations only.

The last two releases changed that. v0.5.0 added a direct NFS read path for CBT, which removed VDDK from warm migrations on NFS source storage. v0.6.0 makes OVERLAY warm and extends it to VMFS. An estate without VDDK now has a warm migration route on either NFS or VMFS.

Getting VDDK has become harder for some estates, which we covered in a separate post on the Broadcom download pages.

 

Ceph RBD as a Migration Destination

CBT and VDDK migrations can now write directly to Ceph RBD primary storage. Migrate detects RBD support from CloudStack and writes converted disks straight to RBD images. Until support is detected, RBD pools are shown as disabled, along with the reason.

The target needs CloudStack 4.22.2 or later, and the workers need qemu’s RDB driver and the nbd kernel module. The worker installer adds both where it can. OVERLAY and OVF still write to NFS primary storage only.

 

Choosing How Guest IP Address are Handled

Until now, keeping a guest’s network identity meant injecting a static configuration into the guest. That works, but many estates don’t want addressing managed inside the guest.

v0.6.0 adds a Default IP Handling Mode, which you can override per wave and per VM. It has three options:

• Inject the static configuration into the guest, as before
• Have CloudStack assign the same IP and leave the guest on DHCP
• Keep the source MAC address and let DHCP hand back the same IP

If you run your own DHCP or IPAM, you no longer have to work around guest-level injection.

One thing to check after upgrading: guest IP and MAC preservation is now off by default. If your deployment relied on it, enable it in Settings and set a default temporary import network.

What This Means for a Migration Project

• The fastest method no longer means downtime up front
• VMFS estates can use OVERLAY, and the relocation can be reversed
• No manual clean-up after an OVERLAY wave
• Ceph RBD can be a target for CBT and VDDK
• IP handling that fits how your network already works

Download the Product Brief

 

Fixes from Real Migrations

v0.6.0 also includes fixes for issues found in customer deployments and in testing on real infrastructure. Two of them concern data integrity in CBT. A copy could miss recent writes if a VMware snapshot or an unconsolidated delta was in the disk chain during a direct NFS read, and a delta or final pass could keep data the guest had since zeroed.

Task handling is also more reliable. A worker that stalled briefly could have its task picked up by a second worker, which created a duplicate VM in CloudStack. A cutover’s final sync could also get stuck behind routine deltas from other VMs. All of these are fixed, and the full list is in the release notes.

 

Availability

ShapeBlue Migrate v0.6.0 is available now to all ShapeBlue customers. To learn more or to talk through your VMware to Apache CloudStack migration, contact us at info@shapeblue.com.

Download the Product Brief

 

FAQ about ShapeBlue Migrate v0.6.0

Does OVERLAY still need the source VM powered off?
No. A running VM stays up and waits in Awaiting Cutover until its cutover policy fires, the same as CBT. After the cutover, the source VM only has to stay powered off until its disk chain has been consolidated.

Can OVERLAY use VMFS datastores now?
Yes. The VM is moved with Storage vMotion, while still running, to the NFS datastore set as the Relocate via target. It can be moved back if the migration fails or is cancelled.

Do I still need to clean up OVERLAY disks by hand?
No. OVERLAY chain consolidation collapses the backing chain whether the migrated VM is running or stopped, with no extra downtime for a running VM. Anything outstanding can be handled with the per-VM Consolidate button.

Which methods can write to Ceph RBD?
CBT and VDDK. OVERLAY and OVF remain NFS-only, and the target needs CloudStack 4.22.2 or later.

What happened to the Unregister OVERLAY Source VM setting?
Consolidation replaces it and releases the source VM and its files completely. If you used that setting, configure OVERLAY chain consolidation after upgrading.

How do I get v0.6.0?
It’s available to all ShapeBlue customers and upgrades in place over v0.5.0.

The post ShapeBlue Migrate v0.6.0: OVERLAY Migrations No Longer Require Powering Off the VMware VMs appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/8nFSsic
via IFTTT

CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday urged organizations to take steps to immediately update their Ivanti Connect Secure (ICS) appliances and deployments to the latest version following the disclosure of an actively exploited vulnerability.

The security flaw, tracked as CVE-2026-104935 (CVSS score: 8.6), is a case of authentication bypass impacting ICS versions 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior that could allow a remote unauthenticated attacker to execute arbitrary commands.

"CISA is aware of cyber threat actors exploiting this zero-day authentication bypass vulnerability, which allows remote, unauthenticated execution of arbitrary commands, to conduct credential theft and data exfiltration," the agency said.

The agency has since added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by October 16, 2026.

CISA is also recommending that customers of affected ICS deployments review Ivanti's Connect Secure Upgrade and Migration Compatibility Guide for patching guidance, cautioning that version 22.8 reaches end-of-life on January 31, 2027.

"Organizations seeking to determine whether they were compromised will need to conduct network and memory forensics to identify evidence of exploitation," it added.

In the event a compromise is detected, CISA is advising organizations to implement the following actions -

• Create a backup of the appliance configuration.
• Conduct a factory reset and upgrade the appliance to the latest version.
• For cloud and virtual systems, rebuild the virtual instance and upgrade to the latest version.
• Restore the appliance configuration from the backup created in step 1.
• Reset passwords for all accounts, including domain, administrator, and local accounts. Revoke and reissue stored certificates; reset stored API keys and license server credentials.

The development comes as Previdian disclosed that it has observed 105 exploitation attempts targeting its honeypot sensors as of October 14, 2026. The attack attempts have originated from 50 unique IP addresses geolocated to Singapore and the U.S. Some of the observed IP addresses are listed below -

• 216.73.160[.]59
• 216.73.160[.]61
• 216.73.160[.]210
• 45.8.19[.]111

According to Previdian founder and CEO, Ryan Dewhurst, threat actors are using the X-DSCGI-PATH header to reach an internal CGI handler and upload Perl scripts dressed up as ZIP files. The scripts return unique markers that determine whether remote code execution has succeeded.

"We're seeing coordinated attempts to exploit this Ivanti vulnerability, but the payloads captured so far are primarily testing for code execution rather than deploying malware, or compromising the device," Dewhurst told The Hacker News. "However, full weaponized exploitation is likely to follow in the coming hours and days."

In a separate report, Volexity said it first observed the exploitation of CVE-2026-104935 on October 3, 2026, with a previously undocumented threat actor dubbed UTA0576 leveraging it in conjunction with a privilege escalation vulnerability to achieve unauthenticated root-level code execution. UTA0576 is assessed to be driven by criminal motives rather than espionage.

Following successful exploitation, the threat actor is said to have engaged in broad post-exploitation actions, including extracting credentials stored on the ICS VPN appliance, exfiltrating limited Active Directory metadata, deploying a Kerberos tool capable of Kerberoast attacks and credential testing, conducting host reconnaissance, LDAP packet capture, and dropping a Python LDAP tool to search for administrator passwords and BitLocker recovery keys.

"The recovered payloads demonstrate deliberate efforts to conceal malicious activity through selective log modification, removal of temporary execution artifacts, and restoration of altered system state," Volexity researchers Charlie Gardner, Sean Koessel, and Steven Adair said.

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

How to Run a Deepfake Readiness Drill Before a Cloned Voice Calls Your Team

Cloned voices and synthetic video calls now show up in payment fraud, help desk resets, and access requests. A structured drill shows security teams exactly where verification breaks down, while nothing is at stake.

The call comes in at 4:40 on a Friday. It's the CFO, or it sounds exactly like her, asking the controller to push a supplier payment out before the weekend because a deal closes Monday. She's traveling, she's rushed, and she apologizes for the bad connection. Ten minutes later an email lands with the wire details.

A couple of years ago that scenario was a conference talk. Now it shows up in incident reports. In a 2025 Gartner survey of 302 cybersecurity leaders, 62% said their organization had experienced at least one deepfake attack in the prior 12 months. In the same survey, 43% reported at least one deepfake audio call incident and 37% had run into deepfakes on video calls.

And the wire is only the obvious ask. The same cloned voice can call the help desk to move an MFA token, or ask an identity admin to set up a new global admin ahead of an "audit." A fraudulent wire tends to surface at reconciliation. A quietly added admin account can sit there for months.

Most organizations have a policy that says to verify unusual payment and access requests. Far fewer have checked whether that policy survives a phone call from someone who sounds like the person who signs off on everyone's paycheck. A deepfake readiness drill is how you find out, on your own schedule, with nothing real on the line.

Why detection by ear falls short

Security awareness training has long taught employees to look for tells. Awkward phrasing, an odd sender address, a link that doesn't match the text. Voice clones and real-time face swaps leave fewer of those tells every quarter. Asking people to hear the fake is asking a lot.

In a May 2025 warning about AI-generated voice messages impersonating senior US officials, the FBI noted that cloned voices can sound nearly identical to the real person and told recipients to confirm identity by calling an independently sourced phone number before acting on anything.

Security leaders already know this. In a January 2026 Osterman Research study of 128 US security and IT leaders, commissioned by IRONSCALES, 60% said they lacked confidence in their ability to counter deepfake attacks even with the training they already run.

So the defense has to rest on process more than perception. If an employee runs the same verification step every time money, credentials, or permissions are involved, the quality of the fake stops mattering much. A drill tests whether that step actually happens when someone senior is leaning on them.

Step 1. Map the voices worth cloning and the people worth calling

Start with two short lists.

The first is the people an attacker would impersonate. That means executives who can approve payments or direct staff (CEO, CFO, CIO, CISO, general counsel). Then go a level down. VPs and directors in finance, IT, and HR make requests like these every week, so a call from one of them raises fewer eyebrows than a surprise call from the CEO. Add a few outside contacts with real authority over money or access, like a key supplier's accounts receivable lead or the engineer at your managed service provider.

The second is the people an attacker would call. Accounts payable, treasury, payroll, HR, executive assistants, the IT help desk, and anyone who can grant or change access in your identity platform. The help desk and the identity admins get left off these lists a lot. They shouldn't be. A cloned voice asking for an MFA reset is a fast route to Account Takeover (ATO). A cloned voice asking for a new admin account skips a few steps.

For everyone on the first list, note how much public audio and video exists. Earnings calls, podcast appearances, conference keynotes, webinar recordings, and social media clips all give an attacker training material. A CFO with three hours of recorded keynotes is a much easier clone than one who's never been on camera. It doesn't take three hours, though. A few minutes from a single webinar can be enough, which puts most directors on the list too.

What comes out of this step is a short matrix: the identities most worth faking and the people most likely to get their calls. In most organizations that's a few dozen people. Manageable.

Step 2. Write the verification rules before testing them

A drill without a clear rule only measures instinct. Before running any scenario, document what employees are supposed to do. Strong verification rules tend to share a few traits.

• Out-of-band callback. Any request to move money, change bank details, share credentials, reset MFA, or change who has access to what gets confirmed through a number pulled from the internal directory or vendor master file. Never a number supplied in the request itself.
• Clear thresholds. Spell out which actions always require verification, no matter who's asking or how urgent it sounds.
• Dual approval. Two people sign off on new payees, changed banking details, new privileged accounts, and role changes.
• Challenge phrases. The most-impersonated executives and their direct support staff share a phrase that rotates on a schedule.
• No-blame reporting. Anyone who realizes they already acted on a suspicious request (paid it, reset it, granted it) reports it right away, and nobody gets shamed for it. Shame the first person who comes forward and the next one with that sinking feeling keeps quiet while the attacker keeps working.
• Explicit permission to pause. The CEO and CFO tell their teams, in writing, that nobody gets in trouble for hanging up and calling back.

Don't skip that last one. Deepfake fraud runs on urgency and hierarchy. An employee who thinks slowing down a VP will cost them at review time is the easiest target in the building. So tell people to trust their gut. The voice can be perfect and the request can still feel wrong, and that feeling is worth listening to even when they can't explain it. My advice to every team I talk to: don't just do something, stand there. A minute of standing still and one callback costs nothing. Acting on the fake costs a lot more.

Step 3. Design multi-channel scenarios

Real attacks rarely show up as a single phone call. They usually start in email or chat to set up context, then move to voice or video to apply pressure. Drill scenarios should follow the same path.

Before building anything, get sign-off from legal, HR, and every executive whose identity will be used. Cloning someone's voice without consent creates its own set of problems. Many teams use a consenting executive's voice, a clearly labeled synthetic stand-in, or a live actor working from a script.

Four starter scenarios cover most of the risk.

1. Urgent wire from the CFO. A spoofed email flags a confidential acquisition payment, followed by a voicemail in the CFO's voice asking the controller to process it before end of day.
2. Supplier bank change. A message from a known vendor contact announces new banking details, followed by a Microsoft Teams call from the "vendor" to confirm the update.
3. Help desk reset. A caller who sounds exactly like the VP of sales says she's traveling, locked out, and needs MFA moved to a new phone before a board meeting.
4. Access cleanup. An email from the CISO's office announces a quarterly permissions review. Then a Teams call from the "IT director" walks an identity admin through it. Strip excess rights from five users who don't need them, and while you're in there, add a contractor account to a privileged group for the auditors. The cleanup is good hygiene. The one addition is the attack.

Time the scenarios around the same pressure points attackers pick. Quarter close, audit season, the days before a holiday, and weeks when executives are publicly known to be on the road.

Step 4. Run it in stages

Start with a tabletop exercise. Walk the target group through each scenario in a conference room and ask what they'd do at every step. It surfaces policy gaps cheaply. (Someone almost always asks which number they're supposed to call, and nobody in the room is sure.)

Then move to live simulations with a small group. A few ground rules keep it safe.

• Brief a small control group. The executive sponsor, the SOC lead, and the head of finance should know the drill is running so a real escalation doesn't kick off a real incident response.
• Keep money and access out of reach. Use a test payee, a payment request that stops at approval, and a sandbox group with no real privileges. Nothing real should be able to move.
• Set stop conditions. If a participant gets distressed or the scenario starts bleeding into real business, end it and debrief on the spot.
• Tell participants afterward, every time. A drill that feels like a trap burns the trust the whole program depends on.

Step 5. Measure what actually happened

A single pass/fail score is the least useful number a drill produces. The behaviors underneath it tell security teams far more.

• Verification rate. The share of participants who used the documented callback or challenge step before acting.
• Time to escalation. How long it took someone to report the request to security, if anyone did.
• Report path. Whether the report reached the SOC through the expected channel or stalled in a manager's inbox.
• Break points. The exact step where the process failed. No directory number, an unclear threshold, or the "executive" pushing to skip the callback.
• Bundled requests. In the access scenario, whether anyone questioned the privilege grant tucked inside the cleanup, or approved the whole batch because most of it looked right.
• Trust signals cited. What participants say convinced them. "It sounded exactly like him" and "the email came first, so I assumed it was real" point to very different fixes.

Spend the most time on the break points. Each one maps to a specific fix in policy, tooling, or training.

Step 6. Debrief, fix, and repeat

Keep debriefs blameless and fast, ideally the same day. Most people who fall for a good drill feel lousy about it. Tell them it was built to fool them, because it was. Then walk participants through what was fake, how it was built, and which signals they could have checked. Fix what broke. Update the callback directory, tighten thresholds, and fold the scenarios into the regular phishing simulation program so the lessons don't fade after one round.

Repeat the drill at least twice a year, and any time the high-exposure list changes. A new CFO, an acquisition, or a heavy conference season all count. Rotate scenarios so nobody passes by recognizing the script.

Where technology fits

Process carries most of the load. Tooling helps at two points in the attack chain.

The first is the setup message. Most voice and video deepfake attempts are preceded by an email or chat message that establishes context. Behavioral email security that flags unusual requests from executives, managers, or vendor contacts can break the chain before the call ever happens.

The second is the call itself. Real-time identity verification for collaboration platforms like Microsoft Teams analyzes voice and video during a meeting and warns participants when someone doesn't match the identity they claim. Many detection tools look for artifacts, the glitches a generator leaves behind, and those get harder to spot with every model release. A sturdier approach checks the person, comparing behavioral and biometric signals against a profile of the real speaker. When evaluating these tools, look closely at privacy, specifically whether they record or transcribe meetings or only process signals in the moment. IRONSCALES, the first and only email security platform with deepfake protection built into the product, takes the behavioral and biometric route for Microsoft Teams meetings. It works from mathematical voice and face profiles, with no recordings or transcripts kept.

Start small, start this quarter

A first drill doesn't need a budget line. Two lists, one page of verification rules, four scenarios, and a debrief template are enough to learn where you actually stand.

For finance and compliance teams that want more detail on warning signs, FinCEN's alert on deepfake fraud schemes describes criminals using generative AI to impersonate executives and direct employees to transfer funds. One of its red flags is worth building straight into the drill. Watch for anyone who switches communication methods mid-conversation and blames technical glitches. That "bad connection" from the CFO on a Friday afternoon is exactly the moment to hang up and call back.

Note: This article has been expertly written and contributed by Audian Paxson, Principal Technical Strategist, IRONSCALES.

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/TdVNChZ
via IFTTT

Hirudo Android Trojan Uses Patched Banking Apps to Bypass Their Built-In Security Checks

Cybersecurity researchers have disclosed details of a new Android banking trojan called Hirudo that works by replacing legitimate banking apps with purpose-built patched versions designed to bypass security checks from inside the app itself, marking a new escalation in financial fraud.

Dutch mobile security company ThreatFabric said it identified replacements for eight Indonesian banking apps, while credential targeting in the malware spans Indonesia, China, India, Mexico, Morocco and Thailand.

"The operation combines credential theft, device takeover, screen and camera capture, and SMS theft, in combination with a fairly mature backend," Eward Driehuis, vice president of fraud engineering at ThreatFabric, said in a statement shared with The Hacker News.

Hirudo facilitates on-device credential theft and live remote control. The malware is delivered by shopping, adult video, and entertainment dropper apps that carry the trojan as a separate installation package, which is then served as an in-app update.

Some of the dropper apps are listed below -

• Shopora (com.agbbh.kjdrttt)
• 1V1 X (com.onev.vip)
• KoiShort (com.koishort.app)
• ZoyaTV (com.zoyatv.app)

"The lure is functional, loading real content in a WebView, a storefront, a video catalogue or short dramas, so the experience looks legitimate," ThreatFabric explained. "Behind that content the dropper runs a fixed startup routine: it collects promotion-tracking data, fetches its campaign configuration, and checks whether the payload, the Hirudo RAT, is already installed with its accessibility service and notification access enabled."

If it's not present, it displays a fake in-app update prompt to trigger the installation of the malware. It's worth emphasizing that Hirudo is installed as a second app and must be granted its own permissions before it can carry out the malicious activities.

As observed in the case of StreamRat, the malware implements an anti-detection technique based on blocking Internet access by configuring a deliberately non-functional VPN connection prior to the payload installation. This is seen as an attempt to prevent other apps and services, like Google Play Protect, from carrying out cloud-based checks of the payload.

"However, Play Protect also provides offline detection for known potentially harmful applications, meaning that the mechanism does not completely disable its protection," ThreatFabric noted last month. "We therefore assess that the technique is more likely intended to reduce the effectiveness of online reputation and code-analysis mechanisms rather than bypass Play Protect entirely."

Depending on the nature of the lure app used, the dropper is also designed to serve bogus screens to capture payment PINs, serve fake screens requesting login credentials for banks and wallet apps, display fake lock screen pattern and PIN overlays, and facilitate total remote control of the device.

While all this behavior is par for the course when it comes to Android banking trojans, it's their attempts to replace the target banking app with a tampered copy that stand out. Specifically, the purpose-built replacements embed a hooking engine to blind signature, accessibility, screen-capture, and Play Integrity checks from within the app. The replacement targets eight Indonesian apps.

"For these, the RAT detects the installed banking app through accessibility, checks its signing certificate against a stored reference, [and] then shows a fake 'update' prompt," ThreatFabric explained. "It opens Android's uninstaller for the genuine app without waiting for the user to tap, and downloads the bank-specific replacement in parallel."

While the need for having to remove the app before installing its near-identical malicious copy is a "real constraint," the mechanism offers the ability to bypass the banking app's own security checks by returning responses fed by the attacker beforehand.

This involves returning the genuine app signing certificate, returning an empty list when querying for enabled accessibility services, and stripping the FLAG_SECURE flag so that the app's screens can be viewed and recorded remotely.

"Key-attestation certificates are re-signed with a bundled keybox, and Play Integrity requests are relayed over plain HTTP to an operator-controlled server, which returns a verdict for the app to accept," the mobile security company said.

"Two details are worth underlining for defenders. First, the attestation keybox the engine ships is not the operators' own: it is a publicly leaked keybox. Second, because the Integrity request is relayed rather than genuinely produced, a valid Integrity response alone is not evidence of an untampered app."

Evidence indicates that the malware is distributed via fake web pages masquerading as Google Play Store landing pages for shopping, short drama, and football apps. Unsuspecting users are assessed to be directed to these websites through ads on Meta-owned social media platforms.

The entire operation rests on a backend that combines device control with the ability to manage different campaigns and stolen data, including device records, lock-screen history, and financial profiles containing monthly income and risk-score fields.

"Hirudo marks a deliberate escalation in how Android bankers approach hardened applications," ThreatFabric said. "By moving its tampering inside the target app, the operation shifts the contest from the device to the application's own integrity checks, and from a bespoke patch to a reusable engine that can be retargeted at other apps and regions."

"Once an app can be replaced, its locally produced signals, signature, accessibility list, and integrity verdict, must be treated as attacker-influenced and verified server-side," ThreatFabric said.

Last month, the findings came a little over a month after the cybersecurity firm revealed StreamRat's targeting of Spanish-speaking users via Meta and TikTok advertisements impersonating a free TV streaming service named Streamtv Esp to enable control over compromised Android devices.

"StreamRat abuses accessibility services and MediaProjection to provide operators with near-complete control over infected devices, combining VNC and hidden-screen control, UI-tree collection, keylogging, credential-stealing overlays, internet and screen-blocking capabilities," ThreatFabric said.

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

An AI Agent Found a Critical OTP Bypass in Production. The Attack Was the Easy Part.

The bug was simple: the login let you choose where your sign-in code went. Proving it on a live website was the hard part.

TL;DR

• During an authorized assessment, an AI pentesting agent found a critical authentication bypass on a major insurer's production website, on its own.
• One login request let the user choose where the one-time passcode went.
• The attack was the easy part. Proving it on a live site took web context built over a decade.

The Login Worked. Then the Agent Stopped.

Reflectiz's AI pentesting agent was mapping the login flow of a major insurer's production website, which has millions of users.

The agent requested a login code and directed it to an email inbox it controlled. The code arrived. The login went through. Its guardrails halted the test after the login succeeded.

The agent had discovered a critical-severity authentication bypass on its own. Reflectiz reported it to the insurer.

The Flaw: The Request Chose Where the Code Went

A one-time passcode (OTP) only proves who you are if it goes somewhere already linked to the account. Here, that link was broken.

The login request carried two fields that decided delivery: the channel and the address. Normally, the code went by text to the phone number on the account. But the request could change the channel. Switch it to email, and the server sent the code to whatever address the request named, not the address registered to the account.

Simplified, the request looked like this:

The server never checked that the address belonged to the account.

Binding a code to its account is one of the most basic checks in authentication. OWASP's testing guide asks this in plain words: "Are the OTPs tied to the correct user account...?"

An attacker with the required customer identifiers could potentially use the flaw to access that customer's account.

From a Suspicious Field to a Proven Bypass

The agent began with reconnaissance, looking at the site's JavaScript and the API calls behind its pages. That analysis surfaced the OTP request and two values that appeared to control how and where the code was sent. Values like those can suggest a hypothesis, but they’re not a finding, since the server might reject the changes or block them later in the login. So the agent built a targeted test around both values and ran it through the live login flow, which confirmed the bypass.

Illustration of the authenticated state the agent reached before stopping. Recreated and anonymized.

Want to see how that testing process works? Book a technical demo to examine how Reflectiz investigates website workflows, validates findings, and controls execution.

Web Context Is the Hard Part

Plenty of automated testing stops at the login gate, but much of what matters sits behind it. A testing system that cannot reach a workflow cannot assess what happens inside it.

Reflectiz solved that problem long before the agent existed. The company has spent more than a decade scanning thousands of production websites, which meant logging in, receiving verification codes, and navigating multi-step flows. So, on sites the company already monitors, the agent starts with that context instead of a blank URL.

Reflectiz's agentic pentesting puts that web context to work. It drives a real browser through the flows a customer follows, including one-time passcodes and 2FA.

Reflectiz CTO and co-founder Ysrael Gurt, a longtime ethical hacker, built the agent on that foundation.

One Finding Is Not a Coverage Report

A confirmed vulnerability may show what failed, but it doesn’t show how much of the application was tested.

The OTP test ran alongside other attack plans on the same site. Reflectiz's agentic pentesting pairs that open-ended investigation with a structured plan: test every discovered endpoint against every applicable attack category. A separate validator agent reproduces each suspected finding with the same payload and context before it is reported.

The output is a coverage record of which tests ran, their recorded outcomes, and any exclusions.

Pentested Is Not the Same as Secure

The insurer said it had pentested the site about six months earlier. This assessment found an exploitable login flaw, though it is unclear when the weakness was introduced.

That is not a reflection on human testers, because a skilled tester could have found this flaw too. It’s more a reflection on the nature of point-in-time testing. It has its place, but how often can anyone afford to look?

Websites change with every release, but pentest schedules don't. They’re rigid, which isn’t much use against attackers who now use AI to find flaws fast and won’t wait for the next test window.

Agentic testing keeps pace. It can repeat focused tests as often as the site changes, provided the agent has the right access and clear boundaries, and produces evidence a reviewer can verify.

Reflectiz reports up to 10x the testing capacity at the same operational cost as traditional manual pentesting. The comparison concerns testing volume, rather than a guarantee of 10x more vulnerabilities found. In the demo, ask how scope, testing depth, and frequency affect capacity and cost for your applications.

Bring Your Toughest Website Workflow to the Demo

Book a 30-minute technical demo with a Reflectiz web security specialist. Before the demo, think about a workflow that matters to your business. It could be login, account recovery, checkout, or a customer portal.

During the demo you can then review:

• How the agent navigates authenticated, multi-step workflows
• What evidence it finds to support a validated finding
• How scope, guardrails, and coverage are documented

Discuss your application's requirements and what a first assessment would involve. No commitment is required, and there’s no need to test your website during the walkthrough.

Book your agentic pentesting demo

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/uYjl38I
via IFTTT

AI-Found Linux Kernel Flaw Gives Local Users Root, and Can Break a Guest Out to the Host

A flaw in Linux's vhost subsystem lets a local user read and write kernel memory at will and become root across nearly a decade of kernel versions. In one virtualization setup, it lets an untrusted virtual machine write to the host's memory and hijack the program that runs the virtual machine.

The bug is tracked as CVE-2026-74580 and named Vghost. Tencent Zhuque Lab, which found the flaw, released a fix on August 3 and published a full write-up on October 12 with working demos of both attacks. There is no public sign it has been exploited yet.

vhost is the part of the Linux kernel that speeds up network and other input/output for virtual machines and containers. A local user reaches it by opening a device node, usually /dev/vhost-net or /dev/vhost-vsock.

On the host, the flaw gives an unprivileged user a reliable way to read and write any kernel address, bypass KASLR, and escalate to root. The attack is deterministic: it needs no memory grooming and no lucky timing.

The second attack is narrower. When a virtual machine's virtio device is placed behind a virtual IOMMU with iommu_platform turned on, and vhost runs in device-IOTLB mode, an untrusted guest can trigger the same bug and make the host kernel write out of bounds into the host's QEMU process. From there, a guest can overwrite a function pointer in QEMU and take control of where the host process runs next, or crash it.

How it works

vhost keeps a small cache of the memory mappings behind each virtual ring and the shared queues it uses to move data. A cache hit is treated as proof that the region was already checked. The cache is cleared when the mapping is updated or invalidated and when the queue is reset, but not when the VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM commands change the ring's addresses or size while the queue is live.

With a device IOTLB attached, those commands accept the new addresses without checking them, leaving that check for later. Once the cache is filled, the subsequent check never runs, and vhost continues translating new addresses using the old mapping. The kernel then copies data to or from that pointer without a bounds check, so a write to the used ring or a read of a descriptor lands outside the mapped region. That gives the attacker kernel read and write.

The flaw sat in the code for about nine years because it took two reasonable changes to create it. A 2017 change (Linux 4.11) added the cache and its shortcut. A 2020 change (Linux 5.9) moved address checking out of the command and into a later step, removing the check that would otherwise have caught the stale translation.

Who is affected, and what to do

The flaw affects Linux kernels from 4.11 up to 7.2-rc4. Tencent reproduced the full local-user-to-root chain on five distribution kernels: Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0, and Oracle Linux 10.2. On Ubuntu, the device node was limited to the kvm group, so the starting point there was a member of that group rather than any user.

On the other four tested images, the node was world-readable at mode 0666, so any local user could reach it.

The fix (commit de845981da67) clears the cache whenever the ring is reconfigured. Install a kernel that contains it and reboot. The first fixed upstream stable releases are listed below; vendors may also backport the fix without changing their version number.

Stable branch	First fixed version
5.10.y	5.10.265
5.15.y	5.15.216
6.1.y	6.1.183
6.6.y	6.6.152
6.12.y	6.12.104
6.18.y	6.18.45
7.1.y	7.1.9
7.2	7.2

Red Hat, Amazon Linux, and Oracle Linux have shipped fixes. Ubuntu has fixed 22.04 and, as of October 13, still lists its 24.04 and 26.04 kernels as in progress.

Until a fixed kernel is in place, restrict access to the vhost device nodes. Remove world access to /dev/vhost-net and /dev/vhost-vsock, limit the owning group to trusted virtualization services, and treat membership in that group as a privilege while the vulnerable kernel is running.

There is no interim workaround for the guest-to-host escape; for that path, the patched kernel is the only remedy.

The severity, and the AI finder

The flaw is rated high, not critical, and the raters disagree on how high. The kernel.org CVE team scores it 8.8 and marks its scope as changed, because the guest-to-host write reaches memory in the host's QEMU process and crosses the boundary between a guest and its host.

Red Hat scores it at 7.3 and marks the scope as unchanged, treating the impact as remaining within the host's own trust boundary; it also rates the integrity impact lower. Amazon scored it 7.8 and Oracle 7.3.

The bug was found with help from Corvus AI, a multi-agent system Tencent built for kernel vulnerability research. The upstream fix credits it with an Assisted-by line, and Tencent says the pipeline found the flaw.

This is machine-assisted research, not an attack run by AI. It is the same team and pipeline behind an 18-year-old SCTP kernel flaw disclosed in August, which also reached root and, in testing, escaped a container.

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

What is GPU Partitioning in Windows Server and How Do You Configure It?

For years, giving a virtual machine real GPU access on Hyper-V meant handing an entire physical card to a single VM using Discrete Device Assignment (DDA).

Windows Server 2025 changes that with GPU Partitioning, usually shortened to GPU-P. It allows a single physical GPU to be divided into multiple isolated partitions, each assigned to a different virtual machine. In this article, we will look at what GPU-P actually is, how it differs from passthrough, what hardware it demands, and how to configure it in practice.

What GPU Partitioning Actually Is

GPU Partitioning is a Hyper-V feature that lets multiple virtual machines share one physical GPU by dividing it into fractions. Each VM receives a dedicated slice of the GPU’s resources, including video memory, compute, and encode and decode capacity, rather than time-slicing the whole device or emulating it in software.

The important detail is where the isolation comes from. GPU-P is built on Single Root I/O Virtualization (SR-IOV), the same PCIe standard that has been used for years to configure network adapters into virtual functions. SR-IOV pushes the separation down into the hardware, so each partition is enforced by the device and the platform rather than by a driver in the host operating system. Each VM can only reach its own assigned fraction of the GPU, with a predictable performance envelope and a real security boundary between tenants.

To the guest operating system, the partition simply appears as a GPU. You install the vendor’s guest driver inside the VM, and applications use it the way they would use a physical card.

GPU-P Compared to Discrete Device Assignment

Discrete Device Assignment (DDA) is not going away, and it is still the right option for workloads that need full access to the physical card. The trade-offs are worth being explicit about.

 

Aspect	GPU Partitioning (GPU-P)	Discrete Device Assignment (DDA)
Sharing model	Multiple VMs share one physical GPU	One VM owns the entire GPU
Density	High — several VMs per card	One VM per card
Typical use case	VDI, AI inference, multi-tenant graphics	Training runs, single heavy workload
Isolation	Hardware-enforced via SR-IOV	Full device passthrough
Live migration	Supported on Windows Server 2025	Not supported, VM must be shut down

 

One important note is that a physical GPU cannot operate in both modes at once. You choose either DDA or partitioning for a given card, not both.

Where It Makes Sense

Two scenarios drive most GPU-P deployments.

The first is virtual desktop infrastructure. Productivity applications, browsers, and visualisation tools all lean on GPU acceleration, and a partitioned card lets you give far more users a hardware-accelerated desktop from the same server than a passthrough model ever could.

The second is AI and machine learning inference. Inference is generally far less demanding than training, and a single accelerator can comfortably serve several models at once. Splitting a 24 GB card into four partitions of roughly 6 GB gives four separate inference workloads their own isolated slice.

Requirements

GPU-P depends on hardware capabilities, so the prerequisites are not optional and they start below the operating system.

• Host operating system: Windows Server 2025. If you intend to run GPU-P in a failover cluster with live migration, you need the Datacenter edition.
• CPU: A processor with IOMMU and DMA bit tracking support, meaning Intel VT-d or AMD-Vi. AMD EPYC 7003 (Milan) and 4th Gen Intel Xeon Scalable (Sapphire Rapids) and later support GPU-P including live migration. AMD EPYC 7002 (Rome) supports partitioning but not live migration.
• Firmware: Virtualization extensions and SR-IOV enabled in BIOS or UEFI.
• GPU: An enterprise card with SR-IOV support: NVIDIA A2, A10, A16, A40, L2, L4, L40, L40S, and RTX Pro 6000 Blackwell Server Edition, or the AMD Radeon PRO V710. Consumer cards do not support SR-IOV and cannot be partitioned.
• Drivers: Vendor GPU virtualization drivers on the host, and guest drivers inside each VM. NVIDIA deployments that need live migration require vGPU Software v18.x or later.
• Guest operating systems: Windows 10 or later, Windows 10 Enterprise multi-session, Windows Server 2019 or later, and Ubuntu 18.04, 20.04, or 22.04 LTS.

If you are clustering, add one more requirement: every node must be homogeneous. Same GPU make, same model, same partition count, and matching driver versions. Mixing vendors, or even different models from the same vendor, is unsupported.

Configuring GPU Partitioning

There are two paths. Windows Admin Center is the recommended one, particularly for clusters, because it validates homogeneity across nodes and tells you when a configuration will not work. PowerShell gives you scripting and automation, but you are responsible for applying identical settings to every node yourself.

Using Windows Admin Center

You need the GPUs extension version 2.8.0 or later.

 

 

Connect to the server or cluster, then go to Settings > Extensions > GPUs and check the Assigned status column for each card. Partitioned means the GPU is ready. Paravirtualization means the partitioned driver is installed but SR-IOV has not been enabled in firmware, and Not assignable means the device cannot be used this way at all.

 

 

From the GPU partitions tab, use Configure partition count to divide the selected GPUs, then Assign partition to attach a partition to a VM. Windows Admin Center stops and restarts the VM for you as part of the assignment.

 

 

Using PowerShell

The same workflow in an elevated PowerShell session:

powershell

# 1. Confirm the GPU supports partitioning and see the valid partition counts

Get-VMHostPartitionableGpu | Format-List Name, ValidPartitionCounts, PartitionCount

# 2. Divide the GPU into partitions (valid counts are defined by the vendor)

Set-VMHostPartitionableGpu -Name "GPU_ID" -PartitionCount 4

# 3. Assign a partition to a virtual machine

Add-VMGpuPartitionAdapter -VMName "VM01"

# 4. Verify the assignment

Get-VMGpuPartitionAdapter -VMName "VM01" | Format-List InstancePath, PartitionId

# 5. Remove the partition when it is no longer needed

Remove-VMGpuPartitionAdapter -VMName "VM01"

Valid partition counts are predefined by the vendor, typically 1, 2, 4, 8, or 16, and VRAM per partition is calculated from that count rather than set by hand. Once the partition is attached and the VM is running, install the vendor’s guest driver inside the VM before the workload will see the device.

Some limitations that you should be aware of

• One partition per VM. A virtual machine can only hold a single GPU partition. If a workload needs more than one card’s worth of capacity, GPU-P is not the mechanism.
• The VM and its partition share a host. A partition cannot be assigned across servers.
• Live migration is slower. Hyper-V falls back to TCP/IP with compression rather than RDMA when a GPU partition is attached, because the device state is more complex to transfer. Expect higher host CPU usage and longer migration times.
• Failover is not guaranteed to keep the GPU. If a VM restarts on another node and no free partition is available there, it may come up without GPU access. Capacity planning across the cluster matters.
• Partition sizes are fixed by the vendor. You pick from a supported list, not an arbitrary number.

Summary

This guide covered what GPU Partitioning is in Windows Server 2025 Hyper-V and how to configure it and what kind of workloads that it is intended for.

GPU-P will not replace passthrough for workloads that need a full GPU card, and the one-partition-per-VM limit is a real constraint for some workloads. But for VDI and GenAI inference at the edge, it turns an expensive, underused accelerator into a resource several workloads can share.

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

Agents Are Identities Too: Identity Security After CyberArk with Amy Blackshaw

Brandon interviews Amy Blackshaw, Senior Vice President of Identity Marketing at Palo Alto Networks, about identity security in the age of AI agents. Blackshaw, who spent four years leading product marketing at CyberArk before Palo Alto Networks acquired it in February 2026, explains how identity management evolved from an IT operations task into a security discipline, and why identities now need to be protected across their full lifecycle. She walks through the three segments of identity security (access management, privileged access management, and identity governance), argues that human-driven quarterly access reviews are painful and error-prone, and says vendors like Palo Alto Networks are pulling governance into the identity security platform and using AI-driven roles to pre-approve most access.

Blackshaw describes how frontier AI models change the attack landscape, with the cost of entry dropping toward zero and attackers moving at machine speed. She cites Unit 42 figures on how fast intrusions reach data exfiltration, an initial access time of about 25 minutes, and a recent investigation in which the full attack took under 10 hours. Her answer is control alongside detection and response: zero standing privileges and just-in-time access, so an attacker who steals a credential reaches a dead end. She and Brandon discuss why the most boring attacks, like a weak password and no second factor, are often the most effective, and why attackers often succeed with hard-coded machine credentials.

On agents, Blackshaw says an agent is a machine identity with human-like traits: it can reason, decide, and escalate its own privileges, and you can't MFA it. She argues agents should be first-class identities with least privilege, just-in-time access, lifecycle governance, and a gateway for policy. For human-in-the-loop agents, the person is the anchor and must approve the moments that matter, with guardrails against consent fatigue. For autonomous agents, policy is the anchor, with tightly set permissions, behavior monitoring, and a kill switch. Brandon and Blackshaw also cover how to apply zero standing privilege for admins, developers, and agents without slowing developers down, and why policy and context (time, location, and usual behavior) should decide access. They close on who owns identity, which now rolls up through the CISO and increasingly reaches the CIO and CEO, why identity and security operations teams need to share data, and Blackshaw's case for platformization in a fragmented security market.

SHOW: 1071

SHOW TRANSCRIPT: The Enterprise AI Show #1071 Transcript

SHOW VIDEO: https://youtu.be/CcaFoJRu0YM

SHOW SPONSORS:

• NordLayer - Use ENTERPRISE10 for 10% off
• Palo Alto - Secure every identity with Idira by Palo Alto Networks 

SHOW LINKS

• Pathways to Identity Security Success
• SC World: Palo Alto Networks launches Idira
• IdentitySecOps: The Closed-Loop Model for AI-Speed Defense
• Unify Identity and Security Operations to Stop AI Attacks (ebook)
• Unit 42 Frontier AI Defense
• Frontier AI and Identity Security in Financial Services (Q&A)
• Cortex XSIAM
• Palo Alto Networks Idira
• Prisma AIRS
• Amy Blackshaw: You Do Not Have Three Years
• 2026 Unit 42 Global Incident Response Report

GUEST BIO

Amy Blackshaw is Senior Vice President of Identity Marketing at Palo Alto Networks, where she leads marketing for the identity business unit under the Idira brand. She has spent almost 20 years in cybersecurity, most of it in product marketing at large vendors, including four years leading product marketing at CyberArk, the pioneer of privileged access management, which Palo Alto Networks acquired in February 2026. [PLACEHOLDER: add any additional bio details]

Contact Amy Blackshaw:

• Amy Blackshaw on LinkedIn

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/qgIJAC6
via IFTTT

ATT&CK v20: Critical Infrastructure Campaigns, Adversary Use and Abuse of AI, & Iranian Cyber

ATT&CK v20: Critical Infrastructure Campaigns, Adversary Use and Abuse of AI, & Iranian Cyber Espionage

ATT&CK v20 brings more critical infrastructure and cross-domain activity into the framework, with Campaigns for attacks on U.S. water utilities and an AI-assisted breach of Mexican government infrastructure that reached both IT and OT, along with new and updated Groups and Software tied to Iranian cyber espionage, Chinese and North Korean operations, and ransomware. Enterprise gains AI-focused and AI-enabled Techniques, ICS added Techniques for command and script execution and command and control over protocols industrial networks already use, and Mobile un-deprecated a Technique for delivering malicious apps outside official stores. On the defensive side, ICS Detection Strategies (DETs) now carry platform and Asset context, tying behaviors to the operational role of each system, and Mobile DETs reflect the visibility limits of Android and iOS.

Here’s what’s in v20:

• ICS: Two Campaigns, the 2026 U.S. water utility attacks and the IT/OT breach of Mexican government infrastructure; two new pieces of Software, CyberAv3ngers’ IOControl and the AI-generated toolkit from the Mexico breach; and Command and Scripting Interpreter with six Sub-Techniques plus two new command and control Sub-Techniques, so ICS mappings can align to the specific interpreter or protocol an adversary used.
• Cyber Threat Intelligence (CTI): Iran-linked NIMBUS MANTICORE and 13 pieces of its espionage toolkit; updates to People’s Republic of China (PRC)-backed Salt Typhoon on its exploitation of edge devices at telecom providers and to North Korea’s APT38 on its software supply chain compromises; and The Gentlemen’s ransomware, locks ESXi hosts and network-attached storage (NAS) as well as endpoints., plus the Vidar infostealer.
• Enterprise: Nine new Techniques and Sub-Techniques for prompt injection, AI-enabled exfiltration, AI result poisoning, attacks on AI-assisted defenses, CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) evasion, and application-specific password theft, plus a supply chain update that reaches into developer tooling, so mappings can capture how adversaries get around Multi-Factor Authentication, bot checks, and AI systems.
• Defense: Platform and Asset context for ICS DETs, Mobile DETs that reflect what Android and iOS let defenders see, and 15 new DETs and 38 Analytics for this release’s behaviors, with ICS Analytics tuned to filter out routine engineering and maintenance activity.
• Mobile: An un-deprecated Technique for delivering malicious apps outside official stores, malware that relays tap-to-pay card data to an adversary for ATM cash-outs, and 28 revised Software entries.

You’ll find the full details in the release notes, detailed changelog, and changelog.json.

ICS | Water Utility and Government Breaches, New OT Malware, and Execution and Command & Control Techniques

The new Campaign, C0066: 2026 U.S. Water Utilities Attacks tracks adversarial activity, that hasn’t been formally attributed, reaching internet-facing Programmable Logic Controller (PLCs) across more than 30 Minnesota water and wastewater utilities and locking operators out of their own systems. C0064: AI-Assisted Breach of Mexico’s Government Infrastructure is a cross-domain Campaign, spanning IT and OT, with intruders moving across Mexican government institutions and reaching a municipal water utility.

We also added two pieces of Software, S9046: IOControl a G1027: CyberAv3ngers’ malware for Linux-based IoT and OT devices, including PLCs, Human-Machine Interface (HMIs), and fuel management systems, and S9045: BACKUPOSINT v9.0 APEX PREDATOR, the AI-generated, 49-module Python toolkit used in the Mexico breach.

Additionally, T1701: Command and Scripting Interpreter was added to ICS, with Sub-Techniques for T1701.001: PowerShell, T1701.002: Windows Command Shell, T1701.003: Unix Shell, T1701.004: Visual Basic, T1701.005: Python, and T1701.006: JavaScript. It replaces T0807: Command-Line Interface and T0853: Scripting, both now deprecated, so ICS mappings can show which interpreter an adversary used.

New T0869.001: DNS and T0869.002: Publish/Subscribe Protocols Sub-Techniques under T0869: Standard Application Layer Protocol capture adversaries hiding command and control in protocols industrial networks already rely on, and M1061: Limit Software/Package Installation addresses keeping unauthorized software off of ICS assets.

Enterprise | MFA Bypass, Developer Tooling, and AI

T1697: Steal Application Specific Passwords tracks adversaries who phish, generate, or harvest application-specific passwords to log in without facing MFA. T1696: Anti-Automation Evasion, with Sub-Techniques T1696.001: Automate CAPTCHA Completion and T1696.002: Avoid CAPTCHA, addresses ways adversaries get past bot checks. We also gave T1195.001: Compromise Software Dependencies and Development Tools a major update to include IDE and coding agent configuration files.

This release also adds AI-focused and AI-enabled Techniques. T1699: Direct Prompt Injection and T1698: Indirect Prompt Injection describe malicious prompts entered into an LLM’s interface or embedded in content it processes. T1700: AI-Enabled Exfiltration captures how adversaries may direct enterprise AI agents to exfil data, and T1608.007: Stage Capabilities: AI Result Poisoning captures the manipulation of web content to influence what AI search and assistants recommend. T1685.007: Disable or Modify Tools: Impair Autonomous Defenses tracks attempts to disrupt LLM-assisted analysis of malware and activity.

Cyber Threat Intelligence | Iranian Espionage, PRC and DPRK Operations, and Ransomware

We added G1059: NIMBUS MANTICORE, an Islamic Revolutionary Guard Corps (IRGC)-associated espionage group that targets aerospace, defense, and telecommunications organizations. We also included 13 pieces of its Software, such as the S9059: MiniBike backdoor and its S9060: MiniBus, S9053: MiniJunk, and S9052: MiniFast successors.

G1045: Salt Typhoon, the PRC-linked group behind compromises of major telecoms providers, received an update covering its exploitation of public-facing network edge devices. The Democratic People’s Republic of North Korea’s (DPRK)-backed G0082: APT38 now reflects its move from financial theft into software supply chain compromises, including poisoned npm packages.

On the criminal side, G1058: The Gentlemen (not really gentlemen) run S9051: The Gentlemen Ransomware, a RaaS with lockers for Windows, Linux, NAS, BSD, and ESXi. We also added S9050: Vidar, a widely used Windows infostealer often deployed alongside ransomware and cryptominers.

Going Agile

In August we released v19.2, our first Agile release for CTI, bringing G1057: ShinyHunters, G1056: TeamPCP, and the S9008: Shai-Hulud family into ATT&CK to ensure defenders could prepare for and respond to them faster. Adversaries don’t wait for our release windows, and Agile releases let us publish Groups, Software, and Campaigns (but not Techniques) when significant activity breaks between biannual versions. We’ll keep doing these agile releases between the cycles, and if you have a rapid release suggestion, let us know.

Defense | ICS Asset Context, Mobile Visibility, and New Detection Strategies

Detection Strategies (DETs) have covered Enterprise, Mobile, and ICS since v18. In v20, we tailored them to what defenders can see in each domain. ICS DETs now name the platforms they apply to (Windows, Linux, Network Devices, and Embedded) and the Assets they target, so you can tell whether a strategy fits an engineering workstation, a PLC, or both. Mobile DETs account for what Android and iOS expose: they separate what you can monitor continuously from what you only see under certain conditions, through device management, or in a forensic review. In all three domains, each DET now links an adversary behavior to the data you can collect for it and the Analytics that use that data.

For this release, we wrote six Detection Strategies for Enterprise and nine for ICS, backed by 38 Analytics. In ICS, each new interpreter has its own strategy, from DET0929: Behavioral Detection of PowerShell Execution in ICS to DET0930: Behavioral Detection of Windows Command Shell Execution in ICS, and the 22 new ICS Analytics are tuned to set aside vendor software, engineering workflows, and approved maintenance, so alerts focus on execution outside the OT baseline. ICS Detection Strategies now list the platforms they apply to, Windows, Linux, Network Devices, and Embedded, so defenders can match each strategy to the assets it covers. In Enterprise, DET0926: Suspicious Acquisition and Use of Application-Specific Passwords pairs with the new MFA bypass Technique. We also updated ten Data Components across all three domains.

Mobile | Deliver Malicious Application via Other Means and Tap-to-Pay Card Fraud

We brought back T1476: Deliver Malicious Application via Other Means, last seen in v11, and rewrote it for how malicious apps reach phones today: direct APK downloads, links sent over SMS, messaging apps, and QR codes, and third-party app stores. With the Technique back, we reconnected it to the malware that relies on it, updating 28 existing Mobile Software entries, including S0422: Anubis, S0480: Cerberus, S0440: Agent Smith, and S0318: XLoader for Android, along with the Groups that distribute them, such as G0070: Dark Caracal and G0112: Windshift.

We also added S9040: NGate, which relays victims’ payment card data through the phone’s tap-to-pay (NFC) chip so an adversary can withdraw cash at an ATM, and a newer variant also captures card PINs. S0491: StrongPity now spans Enterprise and Mobile.

Up Next | ATT&CKcon 7.0 & v21

Join us for ATT&CKcon 7.0, October 27–28, in McLean, VA, or online. We still have in-person seats, so register here, and virtual registration is open. If your organization wants to sponsor, email us at attack@mitre.org. You’ll find hotel and venue details in the FAQ.

We’ve already started on the v21 release, planned for April. Tell us what you’d like to see and if you see something, contribute something.

Thank You

Many of the objects, Campaigns, Techniques, and DETs, in this release started with someone’s report, feedback, or question. Thank you to the researchers, defenders, and vendors who published what they found and or shared observations with us. You’ll find every v20 contributor in the release notes.

Connect with us via email, LinkedIn, Slack, Bluesky, or X

---

ATT&CK v20: Critical Infrastructure Campaigns, Adversary Use and Abuse of AI, & Iranian Cyber was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.

from MITRE ATT&CK™ https://ift.tt/mhy6WSA
via IFTTT