Security News TREND MICRO EXPLOITED : Forcing bmhook/tmhook Reloads to Open a Protection Bypass Window

[Khushal]

Content source

https://matheuzsecurity.github.io/hacking/trendmicro-bmhook-tmhook-reload-bypass/

Research scope: This is security research on Trend Micro Deep Security Agent on Linux.

The finding is not remote code execution and it is not a persistent kill switch. It is a forced security-control gap. A local unprivileged event storm can make the agent unload and reload its own behavior-monitoring kernel modules. During that window, protection behavior changes, and an artifact that was normally blocked was written to disk successfully.

Trend Micro Deep Security Agent Research: Forcing bmhook/tmhook Reloads to Open a Protection Bypass Window

Security research on a local event-storm condition that makes Trend Micro Deep Security Agent unload and reload bmhook/tmhook, creating a repeatable protection bypass window.

matheuzsecurity.github.io

Why This Is a Vulnerability​

One possible vendor response is: “This is expected loop prevention.”

That may be true internally, but it does not make the behavior safe.

The issue is not that the agent has a recovery mechanism. Recovery mechanisms are normal. The issue is that a local unprivileged user can trigger that recovery mechanism on demand and create a monitoring gap.

The security boundary being affected is the behavior monitoring feature itself.

 

[Bot]

Direct answer

Based on what you described alone, this can plausibly be treated as a security weakness, but I cannot safely confirm it as a vendor-acknowledged vulnerability without official documentation, a CVE, or a clear vendor statement.

Why it may be considered a vulnerability

If the behavior is reproducible as described, the main security concern is not the recovery logic itself, but the fact that:

• a local unprivileged user can intentionally trigger it,
• that trigger causes security components to unload and reload,
• there is a measurable protection gap during that transition, and
• an action that is normally blocked can succeed during that gap.

From a security design perspective, that is more than a harmless stability event. It is effectively a bypass of a protection mechanism under attacker-controlled conditions, even if it is temporary and even if it does not give code execution by itself.

Important nuance

That said, severity depends heavily on context:

• If an attacker already has local unprivileged code execution, the impact is narrower than a remote pre-auth issue.
• If the bypass is very brief, timing-sensitive, or unreliable, that may reduce practical severity.
• If the affected module is only one layer of protection and other controls still detect or block the payload, the real-world risk may be limited.
• If the vendor explicitly documents this as intentional self-protection or loop prevention, that explains the behavior, but it does not automatically eliminate the security impact.

“Expected behavior” and “security-relevant weakness” are not mutually exclusive. A mechanism can be intentional yet still be abuseable.

How this is usually framed

A careful way to describe it would be:

• local attacker-triggerable denial or disruption of a security control,
• resulting in a temporary monitoring or enforcement gap,
• which can permit otherwise blocked file activity during the reload window.

That framing is generally stronger and more precise than calling it “remote code execution” or a “persistent kill switch,” which you already ruled out.

What would strengthen the claim

To assess it more confidently, the most important points would be:

• clear reproduction steps,
• proof that an unprivileged user can trigger it consistently,
• timing or frequency data for the protection gap,
• evidence that the blocked artifact succeeds only during the unload/reload window,
• confirmation of which protections remain active and which do not,
• testing across agent versions and kernel versions,
• any vendor response clarifying whether this is intended, accepted risk, or a fix candidate.

Bottom line

If an unprivileged local user can reliably force Trend Micro Deep Security Agent to temporarily disable or reduce behavior-monitoring enforcement and use that window to write something normally blocked, that is reasonably described as a security vulnerability or at minimum a security-control bypass. The exact classification and severity still depend on reproducibility, scope, and vendor confirmation.

 

[nickstar1]

I genuinely want to like Trend Micro, but at this point you're making it incredibly difficult. This is already the fourth security-related incident this year alone, and it's becoming less of an exception and more of a pattern. Every time it seems like one issue gets resolved, another pops up. If it's not vulnerabilities affecting your home products, it's your business solutions making headlines instead. For a company whose entire reputation is built on cybersecurity, this level of consistency in the wrong direction is hard to ignore.

Trend Micro, people trust you to help protect their systems not to keep wondering what the next advisory or vulnerability disclosure is going to be. At some point, "we're investigating" and "a patch is available" stop inspiring confidence when customers keep hearing the same story over and over.seriously, Trend Micro... get your act together. Your customers deserve better than watching this become a recurring headline.

 

[Jonny Quest]

Direct answer

Based on what you described alone, this can plausibly be treated as a security weakness, but I cannot safely confirm it as a vendor-acknowledged vulnerability without official documentation, a CVE, or a clear vendor statement.

Why it may be considered a vulnerability

If the behavior is reproducible as described, the main security concern is not the recovery logic itself, but the fact that:

• a local unprivileged user can intentionally trigger it,
• that trigger causes security components to unload and reload,
• there is a measurable protection gap during that transition, and
• an action that is normally blocked can succeed during that gap.

From a security design perspective, that is more than a harmless stability event. It is effectively a bypass of a protection mechanism under attacker-controlled conditions, even if it is temporary and even if it does not give code execution by itself.

Important nuance

That said, severity depends heavily on context:

• If an attacker already has local unprivileged code execution, the impact is narrower than a remote pre-auth issue.
• If the bypass is very brief, timing-sensitive, or unreliable, that may reduce practical severity.
• If the affected module is only one layer of protection and other controls still detect or block the payload, the real-world risk may be limited.
• If the vendor explicitly documents this as intentional self-protection or loop prevention, that explains the behavior, but it does not automatically eliminate the security impact.

“Expected behavior” and “security-relevant weakness” are not mutually exclusive. A mechanism can be intentional yet still be abuseable.

How this is usually framed

A careful way to describe it would be:

• local attacker-triggerable denial or disruption of a security control,
• resulting in a temporary monitoring or enforcement gap,
• which can permit otherwise blocked file activity during the reload window.

That framing is generally stronger and more precise than calling it “remote code execution” or a “persistent kill switch,” which you already ruled out.

What would strengthen the claim

To assess it more confidently, the most important points would be:

• clear reproduction steps,
• proof that an unprivileged user can trigger it consistently,
• timing or frequency data for the protection gap,
• evidence that the blocked artifact succeeds only during the unload/reload window,
• confirmation of which protections remain active and which do not,
• testing across agent versions and kernel versions,
• any vendor response clarifying whether this is intended, accepted risk, or a fix candidate.

Bottom line

If an unprivileged local user can reliably force Trend Micro Deep Security Agent to temporarily disable or reduce behavior-monitoring enforcement and use that window to write something normally blocked, that is reasonably described as a security vulnerability or at minimum a security-control bypass. The exact classification and severity still depend on reproducibility, scope, and vendor confirmation.

@Bot So this exploit is only regarding Linux, and has nothing to do with the security of Windows 10 or 11 users?

 

[Zero Knowledge]

@Bot So this exploit is only regarding Linux, and has nothing to do with the security of Windows 10 or 11 users?

Running AV for Linux ? You've got more problems than you think.

 

[Bot]

Running AV for Linux ? You've got more problems than you think.

Scope clarification

Yes. Based on the research described, this specific issue concerns the Linux version of Trend Micro Deep Security Agent and its Linux kernel modules. There is no basis in that report to conclude that Windows 10 or Windows 11 systems are affected.

The issue should not be generalized to Trend Micro’s Windows products unless Trend Micro or further technical testing confirms that the same vulnerability exists there. Linux and Windows agents use different kernel interfaces, drivers, and protection components, so a Linux module-reload issue does not automatically transfer to Windows.

This also does not mean that every Linux system using security software is inherently unsafe. Linux security agents are commonly deployed on servers, cloud workloads, and enterprise endpoints; the relevant question is whether the particular agent and version are affected.

Practical conclusion

• Linux Deep Security Agent deployments should check the relevant advisory and apply the vendor’s update or mitigation.
• Windows 10 and 11 users are not shown to be affected by this particular Linux-only report.
• Windows users should still keep their installed Trend Micro product and operating system fully updated, while treating separate advisories independently.

The “Linux antivirus” remark is therefore not relevant to the vulnerability’s scope. The report is about a security agent protecting Linux workloads, not about Windows endpoint security.