Executive summary
APT28 is the actor that the UK National Cyber Security Centre (NCSC) assesses is almost certainly Military Unit 26165 within Russia’s military intelligence service, the GRU, according to its router advisory. ESET’s report published on 28 October 2026 includes Sednit among the active groups in its April–September reporting period, with the actor-specific statement on page 21 of the full report. The operational picture combines the joint government advisory’s credential, phishing and mailbox operations with targeted implants and the historical firmware compromise documented in ESET’s LoJax investigation. We assess that defenders are likely (B2) to gain more immediate coverage by addressing identity, email and network-device exposure together, while retaining a separate investigation path for firmware evidence, than by treating firmware implants as the default explanation for every persistent intrusion.
Status and contextual background
| Field | Assessment and source |
|---|---|
| Principal names | APT28; Fancy Bear, used by CrowdStrike; Forest Blizzard, used by Microsoft; Sednit, used by ESET. Source-specific equivalences are set out below. |
| MITRE ATT&CK identifier | G0007, in MITRE’s versioned actor entry |
| Assessed sponsorship | The NCSC assesses APT28 is almost certainly the GRU’s 85th Main Special Service Centre, Military Unit 26165; the GRU is Russia’s General Staff Main Intelligence Directorate. |
| Active since | At least 2004, according to MITRE and ESET. |
| Latest verified reporting | ESET’s report released on 28 October 2026 places Sednit among the active groups observed during April–September 2026. It does not give an individual last-seen date for Sednit. |
| Current version | Version 2, assessed as of 29 October 2026; specific technical descriptions retain their original observation dates. |
Names describe source-defined activity
CrowdStrike’s Fancy Bear profile explicitly lists APT28 among its community identifiers. ESET’s Sednit research explicitly connects Sednit with APT28, Fancy Bear and Forest Blizzard. Microsoft calls the actor Forest Blizzard in its April router investigation, while the NCSC’s accompanying advisory explicitly lists Forest Blizzard as an APT28 name. These are documented naming relationships, rather than an attribution inferred from a shared tool.
The joint government advisory cautions that commercial tracking does not necessarily map precisely to the government’s understanding of an actor. Accordingly, this profile retains the reporting organisation’s name and confidence when describing an individual operation. For example, ESET assesses the attribution of Operation RoundPress to Sednit with medium confidence; that qualification remains attached to the campaign even though the broader actor identity is well established. A reader should be able to separate confidence in the existence of an intrusion from confidence in its operator.
This distinction also matters when deciding what belongs in an APT28 detection library. A common cloud provider, malware framework or router model is useful investigative context. It is insufficient by itself to identify the operator. The defensible unit of comparison is the observed procedure, its surrounding artefacts and the source’s attribution basis, rather than an isolated product name.
Objectives, targets and the latest update
The joint advisory carried by the US Cybersecurity and Infrastructure Security Agency (CISA) describes an espionage campaign against Western logistics and technology organisations, including those supporting assistance to Ukraine. It documents targeting of transport, defence and related services, follow-on attempts against business partners, and collection interests such as shipping manifests and movement schedules. Those interests explain why administrative mailboxes and accounts with apparently ordinary business responsibilities can deserve close protection. Privilege is only one measure of an account’s intelligence value.
The newest ESET report supports continued activity, with an important limit. Its Russia section says Gamaredon, Sednit and TA488 accounted for much of the activity observed during the reporting period. The accompanying sector and initial-access percentages cover Russia-aligned groups collectively. They are not APT28 percentages, and this profile does not present them as such. Nor does a report covering April–September prove that a particular tool or infection continued uninterrupted until the publication date. The update strengthens the case for continued attention to the actor; it does not supply a new technique-level timeline for every campaign.
Historical context and operations timeline
The table is a selected evidence timeline. Entries marked “new reporting” were published after 13 March 2026; their observation periods may begin earlier.
| Publication or observation | What the source establishes | Limit |
|---|---|---|
| 27 September 2018 | ESET’s LoJax report documents successful firmware installation in at least one case and attributes LoJax to Sednit with high confidence. | A verified capability, not a population-wide prevalence measurement. |
| 22 April 2024 | Microsoft’s GooseEgg analysis describes post-compromise privilege escalation and scheduled-task persistence. | The reporting date is not the first-use date. |
| 15 May 2025 | ESET’s RoundPress investigation describes webmail exploitation and data theft, attributed to Sednit with medium confidence. | Campaign attribution retains that confidence level. |
| 18 July 2025 | The NCSC attributes AUTHENTIC ANTICS to APT28. | Credential and token persistence, not a firmware finding. |
| 10 March 2026 | ESET describes BeardShell and modified Covenant and records selected machines monitored for more than six months in its 2025 analysis. | An observed surveillance interval, not an actor-wide median. |
| 7 April 2026 — new reporting | The NCSC describes router-enabled DNS hijacking operating from 2024 into 2026. | Infrastructure activity across years does not establish one victim’s duration. |
| 28 October 2026 — new reporting | ESET’s April–September report, page 21, includes Sednit among the most active Russia-aligned groups in that period. | The report does not assign its aggregate technique percentages to Sednit. |
Technical analysis
The recurring baseline: accounts, mail and exposed services
The joint government advisory describes password guessing, credential phishing, malicious attachments and exploitation of internet-facing systems. Its post-compromise findings include changing mailbox permissions and authentication settings to support continued collection. It also reports ordinary host persistence through scheduled tasks, startup shortcuts and registry run keys. This breadth is a stronger starting point for practical threat modelling than any assumption that an advanced operator always needs an unusual implant.
We use “baseline” here to describe techniques recurring across the cited investigations, not to claim a measured percentage of APT28 intrusions. Public reporting is shaped by visibility: a conspicuous firmware discovery attracts a detailed technical paper, while account compromise may appear in a larger advisory. Counting publications would therefore be a poor way to estimate the relative incidence of these techniques. The operational decision should instead start with the organisation’s exposed services, available logs and the consequences of losing particular accounts.
In Operation RoundPress, ESET describes crafted emails exploiting cross-site scripting (XSS) in webmail to execute JavaScript in the victim’s browser context. The products covered include Roundcube, MDaemon, Zimbra and attempted exploitation of Horde. ESET says the payloads could steal credentials and mailbox data; it also notes that the Horde exploit appeared non-working. The report attributes the campaign to Sednit with medium confidence.
Its persistence findings are more specific than “the mailbox was permanently infected”. The JavaScript itself lacked true persistence and ran again when the malicious message was reopened. Some Roundcube payloads could add Sieve forwarding rules, while the MDaemon payload could create an application password. Those account-level changes need separate examination from the original message. Closing a browser or removing the email is not a sufficient test of whether all access paths have gone.
Routers extend the collection surface beyond the managed endpoint
The NCSC’s April advisory describes changes to small office/home office (SOHO) router settings so downstream devices receive attacker-controlled Domain Name System (DNS) resolvers through Dynamic Host Configuration Protocol (DHCP). Selected requests were redirected towards interception infrastructure while other requests resolved normally. The NCSC assesses that the operations are opportunistic, with the actor likely filtering a broad initial pool for users of potential intelligence value. The supported mechanism is malicious network configuration and subsequent interception, not evidence of a firmware rootkit in each router.
Microsoft’s account adds a crucial qualification: active adversary-in-the-middle (AiTM) interception affected a subset of the compromised networks. In the described Transport Layer Security (TLS) interception, attackers presented an invalid certificate; reading the underlying plaintext depended on the user ignoring the warning. Microsoft identified more than 200 organisations and 5,000 consumer devices affected by the malicious DNS infrastructure, but reported no indication that Microsoft-owned services or assets were compromised. Those figures should not be recast as a count of successfully intercepted corporate mailboxes.
For exposure assessment, the employee’s network path belongs beside the corporate asset inventory. A well-managed laptop can still receive network configuration from equipment outside the organisation’s direct administration. Investigation should establish the actual resolver used, the router that supplied it and whether authentication activity followed a redirection. A suspicious network path and a stolen account are different findings and may require different owners to repair them. Router replacement should therefore be coordinated with the identity team, with account access verified separately afterwards.
Host access and resilient implants
Microsoft’s GooseEgg investigation describes a tool used after initial compromise to gain elevated permissions through the Windows Print Spooler. Its observed installation included a scheduled task. Microsoft distinguishes the tool’s ability to launch other applications with elevated permissions from the actor’s subsequent choices. The useful defensive separation is initial entry, privilege escalation and the persistence actually installed on the particular host.
ESET’s March research announcement describes repeated deployment of BeardShell and a modified Covenant against Ukrainian military personnel. BeardShell used the legitimate Icedrive storage service for command and control; Covenant served as the principal espionage implant, with BeardShell providing a fallback. ESET’s technical report identifies Component Object Model (COM) hijacking for BeardShell and SlimAgent persistence. These observations support investigation of multiple access paths on the same host, without implying that each path survives a complete rebuild.
The NCSC’s AUTHENTIC ANTICS attribution supplies another identity-focused example. It describes malware that intercepts credentials and OAuth authentication tokens through login prompts and exfiltrates information using the victim’s email account without leaving the messages in the sent folder. The NCSC says it was designed to enable persistent access to Microsoft cloud accounts while blending with legitimate activity. Here persistence concerns access to an account and its authentication material; it does not describe code residing below the operating system.
LoJax is documented firmware persistence, with a defined scope
ESET’s LoJax investigation found successful installation of a malicious Unified Extensible Firmware Interface (UEFI) module in Serial Peripheral Interface (SPI) flash in at least one case. The module could restore and run malware from the operating-system disk during boot, surviving both an operating-system reinstall and disk replacement. ESET attributed LoJax to Sednit with high confidence using infrastructure connections and associated tooling. It described firmware-writing prerequisites as platform-dependent, including vulnerable or misconfigured write protections.
That finding justifies retaining firmware in the investigative model for a sufficiently supported case. It does not establish that firmware infection is routine across APT28 operations. In this profile, “rare documented firmware persistence” describes the limited cases established by the cited evidence; it is not a numerical estimate of the actor’s undiscovered use. A firmware implant’s existence also does not prove use of another vulnerability merely because that vulnerability affects the preboot environment.
Related current analysis: EDK2 UEFI PXE preboot exposure. This link is a subject comparison, not an attribution of the vulnerability to APT28. Initial code execution before the operating system, permission to rewrite protected firmware, and a verified implant that survives repair are separate propositions. An investigation should record evidence for each step it claims rather than importing LoJax’s properties into an unrelated vulnerability assessment.
Selected ATT&CK mappings
These mappings use observed behaviour in the cited reports. MITRE ATT&CK is an adversary-behaviour knowledge base, not a test that identifies an operator from a single technique.
| Observed behaviour | Technique | Evidence and scope |
|---|---|---|
| Password spraying | T1110.003 | Joint government advisory; credential attacks in the logistics campaign. |
| Spearphishing links | T1566.002 | Joint advisory; credential and malware delivery. |
| Mailbox permission changes | T1098.002 | Joint advisory; sustained email collection. |
| Scheduled tasks | T1053.005 | Joint advisory; observed host persistence. |
| Compromised network devices | T1584.008 | NCSC router advisory; devices recruited into operational infrastructure. |
| Adversary-in-the-middle | T1557 | NCSC router advisory; credential interception. |
| COM hijacking | T1546.015 | ESET’s March technical report; BeardShell and SlimAgent. |
| Web services for command and control | T1102 | ESET’s March technical report; cloud services used by the implants. |
Persistence, surveillance and dwell time
For this profile, dwell time means the interval between initial compromise and detection in a particular victim environment. An analyst may be able to establish only a minimum observed interval, because the first retained log entry may post-date initial access. Reports should state the start event, the end event and the evidence supporting each. Detection and successful eviction are also different end points. An attacker may retain an access path after discovery, while an old artefact can remain after active access has ended.
There is a concrete, bounded duration observation in ESET’s March technical report: its 2025 analysis of Sednit-controlled Covenant cloud drives identified machines monitored for more than six months. This supports prolonged surveillance of those observed machines. The report does not provide an actor-wide median, a representative denominator or a fully specified first-compromise-to-detection interval for each machine. Consequently, this profile does not convert that observation into “APT28’s average dwell time”.
Three other clocks should be kept distinct. A server’s first and last observed use describe infrastructure longevity. Dates spanning successive campaigns describe continuity of operations. A payload’s ability to restore access after a reboot describes a persistence capability. None independently measures how long one victim was compromised before detection. Likewise, two related samples separated by years can support code lineage without showing that a single implant survived on a single host throughout those years.
We assess that a realistic possibility (B3) in a continuing incident is that apparently successful remediation has removed one foothold while another remains. The premises are the joint advisory’s coexistence of account and host persistence and ESET’s paired-implant findings. This is a scenario for responders to test, not a claim that it happened in every incident or that the remaining foothold must be firmware.
An incident timeline should therefore maintain separate rows for each host, account and network device. Record earliest confirmed execution, earliest confirmed account misuse, observed persistence changes, containment actions and the first clean verification after each action. Mark unknown periods explicitly. Where retention is short, the correct conclusion may be “compromise predates available logs”. That statement is more useful than a precise duration derived from a domain registration date or the age of an unrelated malware sample.
Operational parallels and impact assessment
The comparison across sophisticated operators is strongest at the level of access dependencies. The NCSC’s April 2026 advisory on China-nexus covert networks describes large networks of compromised edge devices used to route operations. It names Volt Typhoon and Flax Typhoon as users of different such networks and warns that multiple actors may use a shared network. The parallel with APT28 is the defensive difficulty of distinguishing legitimate network equipment from traffic passing through compromised equipment. Shared infrastructure concepts do not establish shared command, developers or attribution.
Firmware persistence has also been documented outside the Sednit reporting. Kaspersky’s MoonBounce analysis describes an implant in motherboard SPI flash and attributes the activity, with medium-to-high confidence, to APT41 or a closely affiliated actor. That is a separate investigation and attribution. Its relevance is that the storage location of malicious code can determine whether a disk-centred recovery addresses the affected component. It does not make every UEFI exposure evidence of either group.
Identity recovery provides a third comparison. CISA’s SolarWinds eviction announcement points organisations to recovery across both on-premises and cloud environments and states that the US government attributed the activity to the Russian Foreign Intelligence Service. The operational lesson is to define the full scope of access before declaring eviction. It should not be used to merge that actor with APT28. Related current analysis: BeyondTrust/Bomgar, trusted access and SolarWinds lessons.
For an organisation handling sensitive negotiations, defence information or transport coordination, the practical impact can include loss of confidentiality even when systems remain usable. This is our impact assessment, grounded in the joint advisory’s described collection of logistical information. Response planning should cover correspondence, attachments, contact networks and authentication material in scope. The presence of a vulnerable device alone does not establish that any of these were stolen; that conclusion requires evidence of access and collection.
Indicators and detection guidance
Historical indicators are useful for retrospective searches. They should carry the source and applicable campaign, and they should not be treated as an assertion that infrastructure remains malicious today. This profile deliberately prioritises behaviour over a long blocklist. The following are file-level leads from the cited research, rather than unique identifiers of APT28.
| Indicator or artefact | Source | How to use it |
|---|---|---|
servtask.bat |
Microsoft GooseEgg analysis | Examine associated scheduled tasks, file content and process ancestry; the name alone is insufficient. |
tcpiphlpsvc.dll |
ESET’s March technical report | Compare the recovered file against the report’s BeardShell sample details. |
eapphost.dll |
ESET’s March technical report | Compare against the report’s SlimAgent sample details and investigate its loading context. |
The following are our defensive recommendations, based on the behaviours above. They are investigation opportunities, not claims that a particular alert proves an intrusion.
For identity and email, correlate unusual sign-ins with mailbox searches, delegated permissions, forwarding changes and newly registered authentication methods. Preserve enough context to distinguish authorised administration from an unexplained change. If an account has been recovered, test whether application passwords, delegated access or other account settings need separate attention. Ask the mail administrator to review configuration as well as authentication logs; a clean endpoint scan does not answer the mailbox question.
For routers and DNS, compare current configuration with an approved baseline, including the source of configuration received by endpoints. Investigate unexpected resolvers and changes that coincide with certificate warnings or unusual sign-ins. Establish whether the equipment is managed by the organisation, an employee or a service provider so the correct party can preserve and repair it. Avoid treating all traffic from a consumer network as malicious; the useful signal is an unexpected relationship or change supported by additional evidence.
For hosts, correlate persistence changes with process execution, newly introduced files and the account that made the change. Prioritise unexplained scheduled tasks, startup entries and COM registrations when they intersect with a relevant alert or sensitive user. Where a legitimate cloud service appears in suspicious process activity, inspect the calling process and account rather than concluding that the provider is malicious. Scope any blocking decision to the evidence and operational need.
For firmware, escalate on concrete artefacts or unresolved evidence after properly scoped recovery, with specialist assistance and platform-specific documentation. Preserve the device and relevant evidence before destructive remediation. Record the precise component examined, the acquisition method and its limitations. A firmware investigation should produce a defensible finding about the tested platform; it should not become a catch-all explanation for an account that was never fully recovered.
Incident response guidance
First, preserve a connected timeline. Collect relevant identity, mail, endpoint and network records before retention or configuration changes remove them. Record the time and purpose of each containment action, including which access path it was intended to close. Separate confirmed compromise from exposure requiring investigation, and keep the assumptions visible to the response lead.
Second, contain the affected paths together. A network-device incident may require router repair and account recovery; a mailbox incident may require permission review as well as credential changes. Use a trusted administrative environment for recovery. Plan session revocation, credential rotation and authentication-method review around what the investigation establishes, then confirm that legitimate access has been restored and suspicious access has stopped.
Third, remove persistence at the layer where it was found. Document the host tasks, mailbox changes, application credentials or network configuration that require repair. If firmware compromise is confirmed, work with the platform supplier and qualified responders on a supported recovery or replacement path. Do not assume that rebuilding the operating system addresses code or configuration stored elsewhere. Conversely, an unexplained sign-in should prompt investigation of identity exposure before a firmware diagnosis is asserted.
Finally, verify recovery independently of the original alert. Search for recurrence through every confirmed access path and check adjacent accounts and systems supported by the evidence. Establish what logs would reveal continued access and ensure they are being collected. The closure record should say what was repaired, how it was tested and what remains unverified. A successful restart is a useful system event, but it is not an eviction verdict.
Mitigation recommendations
Treat email and identity as a shared protection boundary. Maintain supported webmail software, reduce unnecessary exposure and use phishing-resistant authentication where the platform supports it. Restrict and review delegated access, application passwords and external forwarding according to business need. Give sensitive operational roles appropriate protection even where they hold no administrative privileges. Validate recovery procedures before an incident makes them urgent.
Extend asset ownership to edge equipment and remote working. Maintain a register of devices, supported software versions, management access and responsible owners. Restrict management interfaces to authorised administrative paths. Retire equipment that cannot be maintained, and provide a practical route for staff to report unexpected certificate prompts or network changes. The goal is a configuration that can be checked and restored, including for people working away from an office.
On endpoints, monitor changes to persistence and privilege boundaries and retain the evidence needed to connect those changes with user and network activity. Control unnecessary execution paths without assuming that legitimate software or cloud services are inherently safe. Make firmware maintenance and integrity assurance part of the lifecycle for sensitive systems, using controls appropriate to the actual hardware. Validate those controls with the supplier; a feature name alone is not proof that the relevant protection is enabled or effective.
Exercise the whole recovery chain. A useful rehearsal should require the team to explain how it would distinguish a removed payload from a recovered account, and a repaired network path from a restored firmware trust boundary. Assign owners for those checks and define the evidence required to close each. This turns persistence from a general warning into a set of testable recovery obligations.
Future outlook — assessment
We assess that APT28 is likely (B2) to remain relevant to organisations supporting Ukraine and to organisations holding intelligence of strategic value, based on the joint advisory’s targeting assessment and ESET’s latest activity report. The evidence supports preparing for recurrent identity and exposed-service access alongside selective custom implants. It does not support a universal dwell-time estimate, a claim that firmware persistence is the norm, or an attribution of the companion UEFI vulnerability to this actor.
Version history
Version 2 adds the report released on 28 October 2026, verified source-specific naming, a comparison of recurring tradecraft with LoJax, and explicit distinctions between surveillance duration, infrastructure age and persistence capability. It also adds current related-analysis links and recovery guidance organised around the affected access paths. The earlier article remains available as the previous profile.