Integrity Tech advisory AA26-281A: review mailbox access

On 8 October, the US Department of Justice and FBI announced court-authorised domain seizures targeting Microscan and FishHub. According to documents cited in the announcement, actors associated with Integrity Technology Group used these tools. Polish airports appeared among the scanning targets: that describes reconnaissance, rather than confirmed breaches at those organisations. Source: the DOJ announcement.

Joint advisory AA26-281A, published by Australia’s ASD on 9 October, describes automated reconnaissance combined with hands-on activity and the collection of email and credentials. Integrity Tech’s links to the Chinese government are the advisory authors’ assessment. The document identifies similarities with Flax Typhoon activity but cautions that names and activity sets do not have a one-to-one correspondence. It includes indicators of compromise and exploited vulnerabilities. Source: the joint advisory published by ASD.

Breachroad’s conclusion: use this alert to review access to email and infrastructure. Neither the announcement nor the domain seizures determine whether an individual company is safe or compromised. The following plan is our recommendation for organising that review.

Give the review an owner

Involve the people responsible for email, identity, network edge devices and incident response. In a small organisation, that might mean two employees and an IT provider. Job titles matter less than knowing who can demonstrate the actual configuration and who can authorise a change.

Start with a short map: where email runs, which services face the internet, who holds administrative accounts and which remote connections are approved. Include systems operated by partners. Saying that a provider handles security does not establish whether someone will assess the alert and report a result.

A mailbox review should produce evidence

We suggest four questions for the service owner:

1. Who can access the mailbox? Review active accounts, delegated access, application permissions and service access. Investigate every entry without an identifiable owner.
2. What can preserve access? Assess active sessions, authentication mechanisms and exceptions to sign-in policy. A documented MFA requirement does not demonstrate that every access route is covered.
3. Where can messages go? Check forwarding, mailbox rules and integrations that read mailbox contents. Their business justification should be current and verifiable.
4. What history is available? Establish log retention, who analyses events and how concerns are escalated. Missing records are a visibility gap, rather than evidence that no incident occurred.

This is an example control review, rather than a complete investigation procedure. Record its date, scope and limitations. A statement that no anomalies were found in the evidence examined is more useful than a broad assurance that everything is secure.

An indicator needs context

In our assessment, a matching indicator should start an investigation. Check the event time, device, account and process, and whether the organisation operated the relevant service at that point. Distinguish a blocked attempt from an action that actually reached a system.

A search with no matches also needs context. Did it cover all relevant sources, and did retained logs include the appropriate period? Avoid extending the finding beyond what the evidence supports. If signs of unauthorised access emerge, move the case into incident handling, preserve evidence and coordinate access restrictions with the response team.

The practical deliverable is a short decision record. It should identify the systems reviewed, evidence available, unanswered questions and the person responsible for each follow-up. Our recommendation is to give missing evidence an owner and review date instead of treating an incomplete search as a closed case.

A scenario for staff training

An administrator finds a remote access application that appears to be a legitimate product. An employee remembers someone from support asking them to launch it, but there is no ticket or named service owner. This is a hypothetical training scenario, rather than an account of a victim in the announcement.

Useful questions concern who requested the access, its approved purpose, how long it ran and which permissions it received. Staff should know how to report the discrepancy without deleting potential evidence themselves. The exercise connects employee awareness with administrative decisions and helps a team avoid considering the case resolved simply because one application was removed.

We explain a broader approach to alerts in our guide to the threat intelligence lifecycle. To practise assessing warnings, reporting suspicious requests and reviewing access within your organisation, explore our cybersecurity training for organisations.