As with any headline in Cyber, new tactics, techniques, and attack vectors by threat actors are still rapidly evolving each day.
Detection Engineering Ethos
Similar to how Google (Reference 1) approaches threat detection, at Tarian, we also align with the ethos of “You write it, you triage it”. This means that everyone in our team can write new detection logic, commit to our code base, and then on-flow to our customers.
The purpose of ownership of this process is to ensure that the person who built out the detection is tuned and working correctly. That is not to say that collaboration doesn’t happen, but stop and think: What is the incentive of having a separate detection engineering team that pushes an alert down if they are not actively triaging it?
This approach causes alert fatigue and real fatigue. Merging of detection engineering and triage ownership drastically increases the overall alert quality.
Our approach to detection engineering prioritises high-impact threats posing the most significant risks to our customers. Based on observed threat trends from the 2024 Huntress Threat Report, 24% of all threats have been related to infostealers, while 6.5% were linked to Remote Monitoring and Management (RMM) tools.
Given these findings and intelligence throughout the community, we have focused heavily on initial access detections to both attempt to detect Infostealers being dropped and the usage of credentials from these stealers.
We have strengthened our monitoring of RMM tool activity, including network behaviours and usage patterns within customer environments. We take a targeted approach to detection engineering, ensuring our efforts are directed where they have the most impact with the least amount of noise and that we have detection on either side of the attack chain.
A Targeted Approach
But what is our methodology in building out this targeted approach? Take a new attack vector, such as the uptick in the User Agent “axios” being used in business email compromises late last year. Yes, it is trivial to spoof User Agents, but sometimes a threat actor is lazy or forgets to change the User Agent, making it easier to detect.
We take this threat and review existing logs across all of our customers through scheduled threat hunting across all hot searchable data. This shows that the correct log source is available; if it is not available, we have a gap, and we collaborate with the customer to onboard the required log source.
If there is a match in the logs, further investigation is done on that specific customer, as it may be a sign of a compromise. If no match is found, this is good; we then move into labbing the compromise; for this example, we’d use the axios framework to simulate a login by a threat actor and then build the rule as code and push. This methodology is used for each and every new detection that is written in-house.
Managing Scale
Detection engineering at scale as an MSSP – managing multiple environments with different log sources and technologies can be difficult. It is important to have a technology stack that assists with this out-of-the-box natively.
In a previous life, the life cycle of creating a detection, testing the detection, staging then pushing with tuning could take up to 48 hours or more. The alert would then be way too noisy in one environment, which meant manually tuning for that customer, taking more time to get coverage.
This was solely due to the poor technology stack in use. This is also evident when the technology stack is non-MSSP friendly or requires us to “just use the API”. Our workflow now using detection as code can cut this process down to thirty minutes and pushed to our entire customer base using multiple native technologies out of the box with Microsoft Sentinel.
But What about SOAR?
Security Orchestration, Automation, and Response (SOAR) platforms are often positioned as a solution to streamline incident response, but they come with challenges. Many SOAR implementations require a dedicated team to continuously develop, fine-tune, and maintain automation workflows.
This complexity arises because most SOAR platforms demand significant customisation, API integrations, and ongoing scripting efforts to ensure effective response actions across diverse environments.
We integrate automation directly into our detection engineering workflows
At Tarian, rather than relying on a traditional SOAR setup that can be resource-intensive, we integrate automation directly into our detection engineering workflows. This means that automation is embedded at the detection level rather than being managed as a separate, standalone system. For example, when a detection triggers, automated enrichment steps are performed in real-time, such as:
- Conducting IP lookups to determine if an IP address belongs to a known proxy or threat actor.
- Running nested searches to correlate user activity, device history, and authentication patterns.
- Checking threat intelligence feeds for file hashes associated with known malware campaigns.
By embedding automation within detections themselves, we reduce the need for complex, external SOAR workflows while ensuring rapid and scalable response actions. This approach allows us to push automation across all customer environments efficiently—without requiring extensive manual tuning or reliance on dedicated SOAR teams.
We provide a range of services in both Managed Detection and Response (MDR) and Security Operations Centre (SOC) consulting and health checks. If you are struggling with your visibility, alerting and detection engineering – reach out for a chat.
Reference 1 – https://cloud.google.com/transform/how-google-does-it-modernizing-threat-detection
Reference 2 – https://www.huntress.com/resources/2025-cyber-threat-report
