An on-premise Trend Micro endpoint management server can push code to every protected machine, so an attacker who exploits its console or steals an administrator account gains a ready-made software deployment tool across the estate. All 12 Trend Micro entries in CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.21) affect the on-premise management products: Apex One, its predecessor OfficeScan, Apex Central and Worry-Free Business Security. Trend Micro reported in-the-wild exploitation attempts against Apex One in August 2025 and again in May 2026. This guide covers hardening those servers: console exposure, administrator roles, agent tamper settings, the credentials the platform holds, logging, the exploited vulnerabilities and what to check after exposure. It is for endpoint, security operations and infrastructure teams. General endpoint protection practice is in the EDR Guide, which this page does not repeat. Settings and bulletins were checked against Trend Micro online help and Trend Micro security bulletins on 28 October 2026.
Key takeaways
- The management server is a tier 0 asset. It deploys code and policy to every agent; CVE-2026-34926 showed an attacker with server access could inject code that is then deployed to agents. Protect it like a domain controller.
- Never expose the console to the internet. Trend Micro's own advice for the pre-authentication console flaw CVE-2025-54948 was to restrict console access by source IP where it was externally reachable.
- Scope every console account. Role-based administration limits each account to specific agent tree domains and menu items with Configure, View or No Access. Few people need root domain Configure rights.
- Require passwords for agent unload and uninstall. Without them, anyone with local admin rights can stop protection before running ransomware.
- Patch to the minimum fixed builds, then keep going. For the May 2026 bulletin that means Apex One SP1 CP build 18012 (or build 17079 for new installs) with agents at 14.0.0.17079 or later; Trend Micro describes these as minimums.
How identity and access work in Trend Micro Apex One
Apex One on-premise has a management server with a web console, and security agents on endpoints that receive policy, pattern updates and components from the server. Apex Central, where used, manages several Apex One servers and other Trend Micro products from one console. Identities fall into three groups.
| Identity | Where defined | What it can do | Main risk |
|---|---|---|---|
| Console administrators | Administration > Account Management > User Accounts: custom (local) accounts or Active Directory users and groups | Change policy, exclusions and agent privileges; deploy agents; trigger tasks on agents, scoped by role and agent tree domain | Stolen or over-privileged accounts turn the console into a deployment and tamper tool |
| Agents | Registered to the server | Receive configuration and components; report detections | A compromised server or tampered agent breaks protection for many hosts |
| Service and integration accounts | Server Windows service accounts, database access, AD integration, Apex Central registration, remote install credentials | Run the platform and connect it to other systems | Credentials with broad Windows or domain rights stored on a server many attackers target |
Adding an Active Directory user or group requires the Apex One server to be joined to the domain, so the server's own security directly affects the domain. A server that is domain-joined, holds deployment credentials and can run code on every endpoint belongs in the same protection tier as your domain controllers: the same admin workstations, the same logon restrictions and the same monitoring. See the AD Domain Controller Hardening Guide for that baseline.
Admin roles and privileged access
- Role-based administration: define custom roles first, then create accounts and assign one role each. Trend Micro's online help describes giving each administrator only the tools they need, limiting the domains of the agent tree they manage, and giving non-administrators view-only access.
- Agent Domain Control: when adding an account, grant access to specific domains rather than the root domain unless the person genuinely manages the whole estate. Unselected domains are hidden from that account.
- Agent tree menu rights: for each menu item choose Configure, View or No Access. Keep Configure on exclusions, agent privileges, uninstall and task execution for a small group.
- Prefer directory groups to local accounts: AD groups give you joiner and leaver control and MFA through your normal access tooling where you front the console with it. Local custom accounts must meet the product's 8 to 32 character complexity rule and should be limited to break-glass use.
- Use dedicated admin accounts: console administrators should use separate privileged accounts from privileged access workstations, never their daily email account. See the Privileged Access Workstations Guide.
- Console access implies code execution: CVE-2023-41179 required administrative console access and then allowed remote code execution through the third-party antivirus uninstaller module. Treat every console admin account as able to run code on endpoints.
Integrations, API tokens and service accounts
| Credential or integration | Why it matters | Hardening |
|---|---|---|
| Server service accounts | Run the management services on Windows | Least privilege, no interactive logon, no domain admin rights; monitor for logon outside the server |
| Database credentials | The database stores policy and agent configuration | Restrict the database to the management server; use integrated authentication with a dedicated account |
| Remote install credentials | Remote Install Agent deploys agents to endpoints using an account with local admin rights | Use a dedicated deployment account with admin rights only where needed; remove rights after deployment; consider package or UNC-based deployment instead |
| Active Directory integration | Server is domain-joined to use AD accounts and synchronise structure | Read-only lookup account; treat the server as tier 0 |
| Apex Central registration | Central console pushes policy to managed servers | Apply the same role scoping and network restrictions to Apex Central; it controls more than one server |
| Agent unload, unlock and uninstall passwords | Shared secrets that disable protection | Set strong unique values, store in a vault, rotate after staff changes or suspected exposure |
These are non-human credentials with estate-wide reach. Record an owner, purpose and rotation date for each. See the Service Account Security Guide.
Logging and detection
- Console audit: Apex One system event logs record console logons, password changes, logoffs and session timeouts. Forward them, with Windows Security logs from the server, to your SIEM.
- Configuration changes: alert on new console accounts or roles, changes to agent privileges (unload, unlock, uninstall), new scan exclusions, and policy changes applied to the root domain.
- Server behaviour: watch the management server for new files in web-accessible folders, unexpected child processes of the web server or Apex One services, and outbound connections that are not update or Apex Central traffic.
- Agent health: sudden drops in reporting agents, agents unloaded or uninstalled, and pattern versions falling behind are early tamper signs. Map them to MITRE ATT&CK T1685 Disable or Modify Tools.
- Abuse as a deployment tool: tasks or components pushed to many agents outside change windows map to T1072 Software Deployment Tools.
Metrics:
- Days from a Trend Micro bulletin to all servers and agents on the fixed build.
- Management consoles reachable from outside the management network (target zero).
- Console accounts with root domain Configure rights (keep to a named handful).
- Share of agents with unload and uninstall passwords required (target 100 percent).
- Agents not reporting for more than seven days.
Known exploited Trend Micro vulnerabilities
From the CISA KEV catalogue (local copy, version 2026.10.21). Read the Trend Micro bulletin for current fixed builds.
| CVE | Product | Type (KEV) | Added to KEV |
|---|---|---|---|
| CVE-2026-34926 | Apex One on-premise server | Directory traversal allowing code injection deployed to agents | 2026-05-21 |
| CVE-2025-54948 | Apex One Management Console on-premise | Pre-authentication OS command injection | 2025-08-18 |
| CVE-2023-41179 | Apex One, Worry-Free Business Security | Third-party AV uninstaller RCE, needs console admin access | 2023-09-21 |
| CVE-2022-40139 | Apex One, Apex One as a Service | Improper validation of rollback components, RCE | 2022-09-15 |
| CVE-2022-26871 | Apex Central | Arbitrary file upload, RCE | 2022-03-31 |
| CVE-2021-36741, CVE-2021-36742 | Apex One, Apex One as a Service, WFBS | File upload; privilege escalation | 2021-11-03 |
| CVE-2020-8599 | Apex One, OfficeScan server | Authentication bypass | 2021-11-03 |
| CVE-2020-8467 | Apex One, OfficeScan | Migration tool RCE | 2021-11-03 |
| CVE-2020-8468 | Apex One, OfficeScan, WFBS agents | Content validation escape | 2021-11-03 |
| CVE-2020-24557 | Apex One, OfficeScan, WFBS | Improper access control that may disable the product | 2021-11-03 |
| CVE-2019-18187 | OfficeScan | Directory traversal leading to RCE | 2021-11-03 |
Recent bulletins in detail
- August 2025 (KA-0020652): CVE-2025-54948 and CVE-2025-54987 affected Apex One 2019 on-premise management server build 14039 and below, CVSS 3.1 9.4, with at least one in-the-wild attempt. A short-term FixTool_Aug2025 blocked known exploits but disabled the Remote Install Agent console feature; the permanent fix was SP1 CP build 14081 (15 August 2025). Apex One as a Service was not affected.
- May 2026 (KA-0023430): CVE-2026-34926 (server, on-premise only, CVSS 6.7) needs server access and administrative credentials obtained by other means, and lets an attacker modify a key table to inject code deployed to agents. The same bulletin fixed several agent local privilege escalation flaws (CVSS 7.8). Fixed builds: SP1 CP 18012 for existing SP1 users or build 17079 for new installs; agents at least 14.0.0.17079; SaaS agents 14.0.20731.
The lesson from both is that the server's exposure and its administrator credentials decide how bad a flaw becomes. See the CISA KEV Catalogue Guide for prioritisation.
Hardening baseline
- Inventory: list every Apex One, OfficeScan, Apex Central and WFBS server with build number. OfficeScan is the predecessor product; plan migration for anything not on a supported release.
- Patch: apply the latest critical patch for servers and confirm agent builds, starting with internet-reachable or widely accessible servers.
- Network isolation: place the console in a management network reachable only from admin workstations; allow agent communication ports from endpoints and nothing else inbound. Never publish the console to the internet.
- Accounts: review all console accounts; remove stale ones, replace shared local accounts with named AD group membership, keep one or two break-glass local accounts in a vault.
- Roles: build custom roles by job (help desk view, endpoint engineer for one domain, platform owner) and limit root domain Configure rights.
- Agent tamper protection: under Agents > Agent Management > Settings > Privileges and Other Settings, set Unload and Unlock and Uninstallation to require a password, and use Apply to All Agents from the root domain so new agents in existing domains are covered.
- Server hardening: treat the server as tier 0: dedicated host, restricted interactive logon, current Windows patches, EDR on the server itself, no browsing or email.
- Service accounts: least privilege, unique passwords or managed service accounts, documented owners.
- Logging: forward console and server logs to the SIEM and enable the alerts above.
- Backup: back up server configuration and database, store backups as sensitive, and test restore.
Roll changes out by agent tree domain: apply tamper passwords to a pilot domain first, confirm help desk processes for legitimate uninstalls, then apply to all agents. Keep the previous settings documented so you can revert per domain.
Checking a server after exposure
- Preserve server logs, web server logs and the Apex One system event logs before patching.
- Apply the fixed build, then review console accounts, roles, exclusions and agent privilege settings for changes you cannot attribute.
- Look for unexpected files in the server's web folders and new scheduled tasks or services.
- Check whether components, tasks or policies were pushed to agents during the exposure window, and hunt on endpoints that received them.
- Rotate console admin passwords, service account credentials, remote install credentials and agent unload and uninstall passwords.
The EDR Tampering and BYOVD Response Playbook covers the endpoint side.
Common misconfigurations
- Console published for remote admins: pre-authentication console flaws turn this into direct server compromise.
- Everyone is root domain administrator: help desk staff with full Configure rights can add exclusions or uninstall agents everywhere.
- No unload or uninstall password: ransomware operators routinely stop security tools before encrypting.
- Tamper settings applied to future domains only: Apply to Future Domains Only does not cover new agents added to existing domains.
- Domain admin as the deployment account: a stolen remote install credential gives the attacker the domain.
- Patching the server but not agents: agent local privilege escalation fixes need agent builds updated too.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| Patching and KEV tracking | SI-2, RA-5 | ID.RA-01, PR.PS-02 | T1190 Exploit Public-Facing Application |
| Console roles and scoping | AC-6, AC-2 | PR.AA-05 | T1078.002 Domain Accounts |
| Change control on policy and agents | CM-5, CM-6 | PR.PS-01 | T1072 Software Deployment Tools |
| Tamper protection | SI-3 | DE.CM-09 | T1685 Disable or Modify Tools |
Practitioner checklist
- All Trend Micro management servers inventoried with build numbers and support status.
- Servers and agents on current fixed builds for every KEV-listed flaw.
- Console reachable only from the management network.
- Named accounts via AD groups; local accounts limited to vaulted break-glass use.
- Custom roles scoped by agent tree domain; root domain Configure rights limited.
- Unload, unlock and uninstall passwords required on all agents.
- Service, database and remote install accounts least privilege with owners.
- Console and server logs in the SIEM with alerts on account, exclusion and privilege changes.
- Management server handled as a tier 0 asset.
Standards and references
- Trend Micro: Apex One Management Console RCE bulletin (KA-0020652)
- Trend Micro: Apex One May 2026 Security Bulletin (KA-0023430)
- Trend Micro: Apex One Role-based Administration
- Trend Micro: Apex One Adding a Custom Account
- Trend Micro: Apex One Unload and Unlock Privileges
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Software Deployment Tools
Related NHI Mgmt Group resources: EDR Guide · EDR Tuning and Exclusions Management Guide · Bring Your Own Vulnerable Driver and EDR Killers Guide · Service Account Security Guide