Cybersecurity Checklist in the Agentic Hacking Era

Google Threat Intelligence Group and Mandiant say threat actors are now using agentic offensive frameworks such as ARTEX and PentAGI in real intrusions, moving from first stolen account to deep access in hours, sometimes 15 minutes. With CERT-In already warning of AI-assisted payment API hijacking at Indian NBFCs and fintechs, here is a checklist built on Google's five defence layers and CERT-In's controls.

Google Threat Intelligence Group (GTIG) and Mandiant said on 30 October 2026 that several threat actors are now using open-source agentic pentesting frameworks in real intrusions, led by ARTEX and including PentAGI, Hexstrike and CAIRN.

Google calls this a "paradigm shift towards intrusions occurring at machine speed".

In one campaign the attackers went from their first compromised account to deep system access in about four hours, and once in as little as 15 minutes.

For fintechs, NBFCs and payment firms, which move money through APIs, the gap between a stolen credential and a fraudulent payout is shrinking.

How AI-Based Hacking Works #

• Seen since late August 2026: Mandiant found ARTEX, PentAGI, CAIRN and possibly custom harnesses in its incident response cases. The agents handled lateral movement, database exploitation and exfiltration preparation.
• ARTEX: an autonomous multi-agent offensive and command-and-control (C2) platform written in Go. It splits an attack across six sub-agents that run on frontier and open-source LLMs. Its creator pulled the original repository in October 2026 because of abuse, but forks such as ScopeWeaver and a commercial "ARTEX PRO" are still spreading.
• Who uses it: both financially motivated extortion groups and suspected China-linked (PRC-nexus) espionage clusters, including UNC7228. Google says UNC7228 overlaps with Microsoft's STORM-0940. Google also cites "public reporting of ARTEX targeting the financial sector in Asia".
• Machine-speed bursts: ARTEX ran in bursts of 2 to 25 seconds. In one case it logged 27 events in 23 seconds while probing AWS permissions. It wrote and deleted a test blob in about 330 to 400 milliseconds.
• Abusing legitimate features: given valid credentials, it used an application's own SQL API to poison MySQL logs into JSP webshells. It also abused Kudu admin APIs, sent command output to 491 rotating webhook.site URLs, and enumerated more than 110,000 Active Directory objects. It even turned an internal notification system into a channel that emailed more than 1,300 staff.
• Noisy but successful: one webshell attempt generated 240 log events. Google says these tools "trade stealth for velocity", but warns that detecting an attack is not the same as stopping it in time.
• PentAGI: built by VXControl, it needs only a target and a goal and runs open-source Kali Linux tools in sandboxes. Most activity Google saw was scanning, but some operations led to intrusions and persistence. A customised build scanned system integrators and telecom firms across Asia.
• Outlook: Google says attackers are at "Stage 5", with several attack stages run by LLM-driven tooling. It expects largely human-free attacks within one to three months and stealthier, fully autonomous ones within three to six months.

Why FinTechs Are Exposed #

Google says these tools do not invent new techniques. They chain stolen credentials, exposed admin interfaces, over-privileged service identities and unpatched applications faster than a human could.

Fintech stacks are full of the same things: payment gateway keys, partner-bank API credentials, cloud storage keys and CI/CD tokens.

India has already seen this pattern.

On 9 October 2026, CERT-In and CSIRT-Fin issued the critical advisory CIAD-2026-0046. It warned that attackers were stealing payment gateway and partner-bank API credentials from NBFCs, digital lenders, payment firms and wallet operators.

They then called disbursal APIs from the firms' own whitelisted infrastructure, skipping KYC, sanction and limit checks.

CERT-In flagged the "possible use of AI-assisted offensive tooling" and a shrinking gap between compromise and fund transfer.

On 15 October it followed with CIAD-2026-0049 on the misuse of open-source agentic AI tools against Indian ICT assets.

The Checklist #

Items marked [Google] come from Mandiant's five-layer defence guidance in the blog. Items marked [CERT-In] come from CIAD-2026-0046. Unmarked items are standard practice for regulated Indian financial entities.

1. Protect the Control Plane

• [Google] Keep cloud consoles, admin APIs, CI/CD, hypervisors, backup systems and firewall management off the public internet. Allow access only from trusted networks or private connectivity.
• [Google] Make admins work from managed devices, privileged access workstations or jump hosts, using phishing-resistant MFA (FIDO2 or passkeys).
• [Google] Treat app publishing and management endpoints, such as Azure Kudu/SCM, as privileged infrastructure. Restrict them separately and turn off basic publishing authentication where it isn't needed.
• [Google] Require an architecture review before any workload or admin interface gets a public IP.
• [CERT-In] Enforce MFA on payment platforms, admin portals, payment and bank APIs, and remote access.

2. Identity, Keys and Secrets

• [Google] Give every service principal, API key, storage key, deployment token and personal access token a named owner, least privilege, monitoring and a lifecycle.
• [Google] Replace long-lived secrets with short-lived ones: IAM roles instead of static AWS keys, Managed Identities instead of Azure client secrets, and Workload Identity Federation instead of Google Cloud service-account keys. On GitHub, use fine-grained tokens or Actions OIDC.
• [Google] Limit where an identity can be used, not only what it can reach. A CI/CD credential should not work from arbitrary external infrastructure.
• [Google] Restrict AWS iam:PassRole, and disable Azure Storage Shared Key authentication in favour of Entra ID with Conditional Access.
• [Google] Scan repositories, container images and pipelines for secrets. Rotate any exposed credential rather than just deleting it from git history.
• [CERT-In] Keep payment and bank API keys in a secrets manager or HSM, with enforced rotation. Use per-session authentication and remove long-lived static tokens.

3. Attack Surface, Patching and Segmentation

• [Google] Continuously scan internet-facing apps and infrastructure, including custom code, frameworks and libraries.
• [Google] Assume the front end will be compromised. Segment it from identity systems, admin networks and core ledgers, and block unneeded Kerberos, LDAP, SMB, RDP, SSH and database traffic from the DMZ.
• [Google] Strip admin rights from application database accounts. Block file writes, server-wide setting changes and OS command execution, the path ARTEX used to plant webshells.
• [Google] Do not show stack traces, SQL errors or internal paths to external users. Agents use error messages to fix their next attempt within seconds.
• [Google] Harden AD Certificate Services templates. Enforce SMB and LDAP signing, and cut back NTLM where feasible.
• [CERT-In] Keep a full API inventory and formally retire deprecated and unused APIs.

4. Guardrails on Payment and Business APIs

• [Google] Put rate limits, recipient limits and transaction thresholds on high-impact functions, such as sending messages, creating users, changing access or retrieving data.
• [Google] Know in advance which platforms can execute commands, deploy code, issue certificates or send bulk messages.
• [CERT-In] Bind multi-stage transaction flows cryptographically, so a debit API cannot run unless the earlier validation steps have passed.
• [CERT-In] Require maker-checker approval for all fund movement. Reject payouts whose reference IDs have no approved record.
• [CERT-In] Enforce per-transaction and daily ceilings at the API layer. Verify beneficiaries with penny-drop and name matching.

5. Detecting Agentic Attack Patterns

• [Google] Baseline each sensitive identity and workload: normal source networks, APIs, data volumes and destinations.
• [Google] Alert on logins from new ASNs, hosting providers or cloud regions.
• [Google] Watch control-plane velocity: bursts of permission checks, dry-run calls, resource listing and key retrieval within seconds.
• [Google] Detect sequences, not single events. Treat a new login source followed by permission probing, bulk reads and a call to an unseen external service as one incident.
• [Google] Restrict and monitor server egress, especially to webhook services, OAST and tunnelling platforms, file-transfer sites and external AI APIs the workload does not need.
• [Google] Hunt for ARTEX traces, such as "artex-probe-*" files, accounts named "ArtexProbe", and incrementally numbered JSP files or account names.
• [CERT-In] Monitor payouts in real time with velocity, amount-band and new-beneficiary checks, and hold suspicious ones automatically. Reconcile with bank and aggregator statements in near real time.

6. Logging and Telemetry

• [Google] Centralise identity logs (including non-interactive and service-principal sign-ins), cloud control-plane, storage data-plane, app admin, network flow, DNS, proxy and endpoint logs.
• [CERT-In] Keep centralised logs for at least 180 days, and run tamper-protected EDR on servers and endpoints.

7. Third-Party and Vendor Risk

• Inventory every payment aggregator, partner bank, lending service provider and SaaS vendor that holds your credentials or API access.
• Scope partner credentials to minimum permissions, allow-listed IPs and mutual TLS. Revoke them immediately on suspicion.
• Write breach notification and joint incident response obligations into vendor contracts.

8. Incident Response and Regulatory Reporting

• Report cyber incidents to CERT-In within 6 hours of noticing them, as its April 2022 Directions require. Send reports to [email protected] , with CSIRT-Fin for financial-sector incidents.
• Report to the RBI within the timelines set by the directions that apply to your entity, such as the 2023 Master Direction on IT Governance, Risk, Controls and Assurance Practices. Check the timeline that applies to your licence category.
• Plan for minutes, not days. Pre-authorise playbooks to revoke tokens, disable compromised API keys and freeze payout rails without waiting for committee approval.
• When mule accounts are involved, report through the National Cybercrime Reporting Portal (cybercrime.gov.in) or the 1930 helpline right away, so funds can be frozen.

9. Use AI to Defend

• [Google] Run SAST and DAST on all internal applications and fix findings before release.
• [Google] Use LLM-enabled tooling defensively, such as agentic source-code review and continuous AI-assisted vulnerability testing, to find attack paths before attackers do.
• Run authorised red-team exercises that simulate machine-speed attacks, and measure how quickly your SOC and payment controls respond.

Bottom Line #

Google stresses that its recommended controls are familiar ones: control-plane isolation, short-lived credentials, least privilege, segmentation and behavioural detection.

What has changed, in its words, is that "automated tooling can now identify and exploit the gaps between them far more quickly."

For fintechs, a gap that was once a backlog item can now be found and exploited in minutes.

Source: [ARTEX and Friends: Enter Agentic Offensive Frameworks](https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks), Google Threat Intelligence Group and Mandiant, Google Cloud Blog, 30 October 2026.