A company’s email can hold customer contracts, invoices, product plans and password-reset messages. The October 8, 2026 advisory from the FBI, CISA, NSA and international partners describes several ways attackers reached that information: exploiting exposed software, stealing credentials and using applications with mailbox access.

The investigations concern Integrity Technology Group and actors it enables. For a founder or security leader, the useful question is concrete: which of those routes are open in our company, and could we close them quickly? This analysis follows the evidence, then turns it into priorities for small teams and tests for larger organizations.

What the report establishes

The agencies describe Integrity Technology Group, or Integrity Tech, as a China-based company with links to the Chinese government. According to the advisory, its activities include acquiring or developing tools, hosting infrastructure and compromising networks. The report attributes the targeting to actors enabled by that company; it does not describe a single incident with one victim and one intrusion timeline.

Reported targets include government services, critical manufacturing, healthcare, IT, law enforcement, education and religious organizations. The advisory identifies activity affecting organizations in the United States, Southeast Asia, Africa and North America.

The agencies associate some of the techniques with activity publicly tracked as Flax Typhoon, Ethereal Panda and Red Juliett. They also warn that commercial threat-group names do not necessarily correspond one-to-one with government attribution. [1]

How the activity reaches sensitive data

OBSERVED METHODSFour parts of the access problem
01 / Exposure

Find a reachable weakness

Scan public services and applications for vulnerabilities.

Review: exposed assets and patch status.
02 / Identity

Obtain usable access

Attack passwords, harvest credentials and access accounts.

Review: authentication and application permissions.
03 / Persistence

Keep a connection open

Install VPN software that reconnects after a restart.

Review: remote-access software and outbound connections.
04 / Collection

Retrieve and transfer data

Collect mailbox content, databases and directory information.

Review: data access and export activity.
Oktsec’s grouping of methods described in the advisory. It is not a reconstruction of one attack, and the report does not establish that every victim experienced all four.

Scanning includes old vulnerabilities

The report lists common scanning tools and describes MicroScan, a Python-based web application containing more than 1,300 penetration-testing scripts. The agencies report its use as early as 2017.

Appendix B lists eight successfully exploited CVEs, ranging from 2014 to 2023. They include CVE-2019-11510 in Pulse Connect Secure and CVE-2021-22205 in GitLab. The age of these vulnerabilities matters operationally: an asset that was missed during an earlier patch cycle can remain an entry point years later. The list is a reason to reconcile the external asset inventory with actual versions and exposure, rather than limit the review to recent vulnerability announcements.

Email access spans several interfaces

The advisory describes EBurst being used for password guessing and password spraying against Microsoft email environments. Password spraying tries a small set of passwords across multiple accounts. The report lists several interfaces targeted by the tool, including Outlook Web Access, Exchange Web Services and ActiveSync. Reviewing only the browser login page can leave other routes unexamined.

The FBI also recovered a cross-site scripting payload that altered a vulnerable webpage to present credential fields and offer an executable download. Its analysis found mailbox-querying functions in the resulting malware; the FBI assesses that it likely targeted email for exfiltration.

Legitimate VPN software provides persistence

In observed activity, the actors installed SoftEther VPN clients on victim devices and configured them to reconnect on startup. Installers were sometimes named to resemble Windows executables. The advisory notes that legitimate VPN software can be less likely to trigger endpoint detection.

The defensive question is whether that installation and connection were authorized. A software name alone cannot answer it. The device owner, installation history, startup configuration and remote destination provide the context needed to investigate.

Collection can use ordinary application access

The report describes a PHP script, Curlc4.txt, using the Exchange Web Services API to access email, calendars and contacts. It also describes office-cli automating Microsoft 365 mailbox access and extraction using configuration containing identifiers and a secret. Separately, DC.exe used Active Directory replication functionality, known as DCSync, to retrieve sensitive directory information, including credentials.

These examples explain why defenders need evidence of what an authenticated account or application did after gaining access. A successful login is not proof that a subsequent mailbox export or directory replication request was legitimate. The advisory explicitly recommends monitoring cloud-connected applications with access to sensitive files and email. [1]

Three lessons that should change your priorities

1. An abandoned service still belongs in your security budget

MicroScan and the older exploited CVEs illustrate why a forgotten system remains relevant to an attacker. A discontinued customer portal, a test server or an old VPN can still expose software and credentials. Prioritize assets by internet exposure, exploitability and the access they provide. A low-traffic system with privileged access can deserve attention before a newer, more visible product.

The decision: every reachable service needs an owner who can justify keeping it online. Include retirement and external verification in the work required to close a project.

2. Protect the mailbox’s applications as well as its users

The report’s email-collection tools show why reviewing employee logins leaves part of the problem unresolved. Applications can have their own credentials and permissions. Microsoft documents app-only mailbox access without a signed-in user, so a user’s MFA setting does not establish that every application reading their mail is appropriately restricted. [4]

The decision: put mail-reading integrations, their owners and their permissions on the same review schedule as privileged accounts. A CRM connector or meeting assistant should have a documented business purpose and an access limit that someone has tested.

3. A patch closes a weakness; incident closure requires more evidence

The unauthorized VPN installations matter because they can preserve access independently of the original entry point. After a suspected intrusion, patch status alone cannot answer whether an attacker still has credentials, an application grant or a remote connection.

The decision: define incident closure around the access you investigated and removed. The advisory recommends isolating affected hosts, collecting evidence, determining scope and planning eviction. Treat patching as part of that process. [1]

For startups: a focused first-week review

A founder, CTO or IT provider can lead this review with the person who administers email and cloud services. The sequence below is Oktsec’s proposed starting point for a small team; adapt it to your systems and current incidents. Record an owner and a due date for anything you cannot resolve.

01 / EMAIL AND ADMINISTRATORS

Ask for the exceptions to MFA

Have your email administrator show which human accounts are not covered by MFA, including administrators and contractors. Review each exception and remove unused accounts. Separate application identities for the permissions review below. Test normal sign-in and recovery with a designated test account before changing access for everyone.

Done when: every human account is covered or has a named, time-limited exception; the team knows how to recover access.

02 / CONNECTED APPLICATIONS

Find out who else can read your mail

Ask for the list of CRM integrations, assistants, automations and other applications with mail access. For each one, record its owner, the mailboxes it can reach and whether it can read, send or delete. Check whether the business still uses it before removing access. Review suspicious access as an incident.

Done when: each active integration has a business owner and a tested access boundary. Keep the permissions export as the review record.

03 / PUBLIC SERVICES

Close the test system nobody owns

Compare your cloud and hosting accounts with an authorized external inventory. Include old demos, staging sites, VPNs and administration panels. Check versions against vendor advisories and prioritize exposed, exploited vulnerabilities. Confirm dependencies before retiring a service, then verify externally that it is no longer reachable.

Done when: every exposed service has an owner and a remediation decision; retired services fail the external reachability check.

04 / RESPONSE

Rehearse losing access to a mailbox

Use a test mailbox containing fictitious messages. Ask your administrator to demonstrate how they would disable a compromised user or revoke an application’s access, locate the relevant logs and contact the response lead. Verify the outcome after the provider’s propagation window. Keep the provider’s support details somewhere accessible if company email is unavailable.

Done when: someone can execute the response, the test access fails as expected, and the evidence shows what changed and when.

If capacity is limited: begin with exposed vulnerable systems and identities that can reach sensitive mail or administrative functions. Have the administrator demonstrate the current configuration and one test result. “We use cloud email” or “we have antivirus” leaves those questions unanswered.

For enterprises: test across the handoffs

Larger organizations often split these responsibilities across infrastructure, identity, messaging, endpoint and security operations teams. An assessment should follow access across those boundaries. The advisory recommends validating controls against the relevant MITRE ATT&CK techniques. These are three bounded exercises to put that recommendation into practice.

IDENTITY + MESSAGING

Can an integration read a mailbox outside its scope?

Give a test application access to one test mailbox and attempt the same read against a second mailbox containing only fictitious data. Review the effective grants across the identity provider and email service. In Exchange Online, Microsoft warns that a scoped Application RBAC grant does not cancel a separate, broader Entra grant. Its authorization test also excludes those separate grants. [4]

Pass condition: the intended mailbox works, the out-of-scope read is denied, and the reviewer can explain every grant affecting the result.

ENDPOINT + NETWORK + SECURITY OPERATIONS

Does an unexpected connection reach a responder?

On an isolated test endpoint, emulate an unapproved persistent remote connection under a written exercise scope. Check endpoint events, outbound traffic and the alert that reaches the on-call team. Record whether the analyst can identify the device, account, destination and person authorized to contain it.

Pass condition: the activity is prevented or detected as designed, and the response reaches the responsible team within your agreed target.

INCIDENT RESPONSE + SYSTEM OWNERS

What evidence would justify closing the incident?

Run a tabletop using a compromised public application and suspected mailbox access. Require decisions on affected accounts, application credentials, installed software, evidence preservation and business continuity. Then exercise the selected containment steps with test identities and systems.

Pass condition: each suspected access route has an investigation outcome, an owner and a verified containment action or documented residual risk.

Keep the test scope, expected result, observed result and follow-up owner together. A blocked test and a detected test demonstrate different controls. Report both accurately, including missing logs and systems outside the exercise.

Use the indicators with their dates

Appendix A contains domains, IP addresses, file hashes and other indicators. It explicitly warns that some observations date back as far as 2016 and recommends investigating or vetting indicators before taking action such as blocking.

That qualification matters when importing the list into a security platform. A historical IP address is not evidence that its present user is malicious. Likewise, some dates marked with an asterisk in the domain table are WHOIS registration-expiration dates, not dates on which the FBI last observed malicious activity.

Use the dates and context to support retrospective searches and correlate matches with local evidence. For ingestion, the FBI’s advisory listing links the corresponding STIX files. Keep the source and observation dates attached to imported records so that analysts can interpret a match.

Before you connect an AI assistant to email

The advisory describes automation and manual activity; it does not establish generative-AI or autonomous-agent use. The relevant lesson for teams deploying AI is the access they grant to their own assistants.

Consider a proposed assistant that summarizes support requests. Its task calls for reading the support mailbox. Access to the founder’s inbox, permission to send messages or the ability to export the company’s email should each require a separate business decision.

Before the pilot, define the permitted mailboxes and actions, the identity the assistant uses, who can approve changes and who can revoke access. Test with fictitious mail: the assistant should read the approved inbox, fail to read an excluded inbox and fail to send if sending is outside its role. Enforce those limits in application permissions and connected systems; a prompt telling the assistant to stay within scope is not an access control.

Then rehearse stopping it. Disable the test integration, verify that access actually stops and retain the permission decision, test results and revocation record. That gives the team something concrete to review before expanding the pilot. See our AI agent governance guide for ownership, approvals and evidence.

Sources and scope

  1. FBI, CISA, NSA and international partners, Chinese Government-linked Cyber Threat Actors Combine Automated and Hands-on Hacking Tools to Steal Sensitive Data, AA26-281A, October 8, 2026. Attribution and scope: pp. 4–5; technical details: pp. 5–11; response and mitigations: pp. 13–16; indicator caveats: p. 19; exploited CVEs: p. 58. Official NSA-hosted copy.
  2. NSA, publication announcement, October 8, 2026.
  3. FBI Internet Crime Complaint Center, industry alerts and downloadable indicators, entry for October 8, 2026.
  4. Microsoft Learn, Role Based Access Control for Applications in Exchange Online. Resource scopes, app-only access, overlapping permission grants and authorization-test limitations. Accessed October 11, 2026.

This analysis uses the October 8 advisory. Attribution follows the agencies’ assessment; the diagram and practical checks are Oktsec’s analysis of that public evidence.