Hello everyone,
I've been spending some time with Trend Micro Vision One over the past few months, primarily to see how it fits into our existing project management and security workflows. One area I wanted to explore in-depth was its custom rule creation, as our team often needs to monitor for very specific, non-standard behaviors that generic rules might miss. I decided to document my process of creating a rule to detect the misuse of a particular Living-Off-the-Land binary (LOLbin), which I think is a practical exercise for many security-conscious teams.
For this walkthrough, I focused on `certutil.exe`, a legitimate Windows tool that can be abused to download malicious files. The goal was to create a detection that would alert us when it's used in a suspicious manner, without flagging every legitimate administrative use. Here’s a step-by-step breakdown of how I approached it within the Vision One console:
* **Identifying the Key Behavior:** First, I needed to define the suspicious pattern. Research and our own internal logs showed that the primary abuse case involves using `certutil` with the `-urlcache` and `-split` arguments to fetch a remote file. Legitimate uses typically involve certificate management without those specific download-focused flags.
* **Navigating to the Rule Engine:** Within Vision One, I went to the Detection & Response section and selected "Custom Rules" under the Rules menu. The interface is quite intuitive, similar in workflow structure to creating a complex Jira filter or an Asana rule.
* **Setting Rule Conditions:** This was the core of the task. I built a rule with the following logic:
* **Process Name** is `certutil.exe`
* **Command Line** contains `-urlcache`
* **Command Line** contains `-split`
* I combined these with an AND operator to ensure both indicators were present, reducing false positives from administrative tasks that might use one of the arguments alone.
* **Configuring Severity and Response:** I set the rule severity to "High" and configured it to generate an XDR alert. I also mapped it to the relevant MITRE ATT&CK technique (T1140 - Deobfuscate/Decode Files or Information) for better reporting context.
* **Testing and Deployment:** Before enabling it broadly, I used the test mode against historical data to see what it would have caught. After a few adjustments to the command-line logic to exclude a specific internal admin script, I was satisfied and deployed the rule to a pilot group of servers.
The entire process took about an hour from research to deployment. The biggest consideration, much like designing any workflow in Monday.com or Asana, is balancing detection coverage with operational noise. You need to be specific enough to be useful but not so narrow that you miss variants. For teams integrating this into their project management, I'd recommend documenting the rule logic in your team's knowledge base and setting up a regular review, perhaps as a recurring task in your project management platform, to tune the conditions as attacker techniques evolve.
I'm curious if others have built similar custom detections. What LOLbins have you focused on, and did you run into any challenges with tuning the logic or managing alerts within your team's workflow?
grace
The right tool saves a thousand meetings.