Receiving an incident report is stressful. You get an alert telling you something bad happened on a device, its network access has been cut off, and now you’ve got a list of remediations before you can bring it back online. You’re trying to make sense of the report Huntress has just sent, all the while you’re getting calls from your client asking why they don’t have internet access.
And things can get even worse. Hackers don’t always work a 9-5, so an incident report might hit your inbox in the middle of the night or on a weekend, leaving you scrambling to fix things before your client is back in the office on Monday.
Our incident reports try to strike a balance—detailed enough to be informative, but concise enough to help you take action quickly. But sometimes, the report alone isn’t enough to fully walk you through what happened.
That’s where Security Operations Center (SOC) Support comes in. You can reach out to us anytime, and we’ll walk you through the incident from the perspective of the SOC analysts here at Huntress, regardless of how big or small the incident is.
The example below demonstrates one of these cases, where the SOC support team was able to provide additional value to a partner facing a security incident.
This ticket highlighted one of the most valuable aspects of the SOC Support team—collaborating with our partners to build the full picture of an incident. Our SOC analysts can only report on what we see from our EDR’s perspective. But security is a team effort, and by working together with the partner we were able to piece together a much clearer chain of events.
Our partner received the following incident report, and they had a few questions as they worked through the remediations.
Figure 1: Huntress Incident report
As the partner dug into the details, they noticed an alert from another security product had triggered at the same time. That raised some important questions:
Were we both alerting on the same exact thing?
Did we isolate the endpoint because we felt the malware hadn’t been properly contained?
Which alert came in first?
What did each product actually do?
And of course, one of the most critical questions—what needed to be done next?
To answer those questions, we needed to determine the sequence of events as things played out. The investigation carried out by our SOC focused on the execution of a process with malicious intent.
This highlights one of the key benefits of our Managed EDR: the focus on the behaviors attackers use to gain and maintain access, which often involves leveraging legitimate tools or services to do so. The additional layer of antivirus (AV) provided another perspective, flagging the presence of the downloaded file itself. Together, this helped us answer key questions about what happened, when it took place, and what actions were taken to contain the threat.
When a partner reaches out with questions about an incident report, the SOC Support team’s first priority is to review the investigation from our end, starting with what our SOC analysts reported and what remediation steps were recommended.
One of the most useful tools at our disposal is the ability to review the specific signal that triggered the report:
Figure 2 : Signals Investigated tab on the Incident report
In this case, there was only one signal that detected malware being downloaded from a suspicious domain.This gives us a solid starting point—we can immediately see what process triggered our alert. Often, the signal is one we’re familiar with, making it easier to quickly piece together the scenario. But this time, the detection wasn’t one we encounter every day, so it warranted adeeper dive.
Our next step was understanding exactly what triggered this detection and why.
Figure 3 : Rule Description from internal Dashboard
The image above was pulled from our SOC dashboard, helping us break down the nature of the signal and the logic behind the detector.
After researching, we determined that we sent this report out because we saw a command being run on this machine that made a connection to a domain listed in the “Living Off Trusted Sites (LOTS) Project” —a database that tracks websites that are often abused in phishing campaigns.
At this stage, we had enough information to confidently assess that the user named in the incident report had likely been phished, and we isolated the host after we saw a connection made to a compromised domain hosting malware. With that context, we were ready to walk the partner through the incident from Huntress’ perspective.
With a clear understanding of the activity we had reported on, the next step was to review the alert the partner had shared in order to create a timeline of events and put together the full picture. The alert in question showed that a file downloaded had been detected, quarantined, and deleted by the AV.
The file was downloaded seconds after the command execution, and was linked to the same user profile we had seen execute the command. Additionally, the alert from the AV had the same timestamp as the one included in our report. This is what originally had caused the partner to question the sequence of events—were we both responding to the same thing, or was something potentially missed?
At this point, the picture was becoming clearer, and some of the language in our incident report made more sense. Our SOC analyst had noted:
"This typically attempts execution of additional malware starting with a .lnk file hosted at this resource, but user interaction appears to have ceased after initially accessing this remote resource."
Put simply, we observed the initial connection to the malicious domain and expected it to download a secondary payload, but in this case, we didn’t see clear evidence that a malicious file was downloaded.
Now that both reports had been reviewed, we were able to address the partner’s specific questions.
Were we both alerting for the same thing? What occurred first in the timeline? Our response below directly addressed the partner’s ticket request for timelines on both alerts.
Huntress detected the execution first, but the actual malware download happened seconds later.
More specifically, Huntress Managed EDR detected the process (Rundll32.exe) responsible for reaching out and downloading the malware. The AV alerted us of the malware file that was downloaded from that domain. This aligns with typical detections from AV solutions that perform signature-based scanning on files.
This explained why both alerts had such close timestamps—our EDR saw thecommand executing, while the AV saw the payload once it had reached disk.
We explained:
Huntress doesn’t isolate an endpoint just because malware is present—we do it to prevent further execution and prevent it from spreading across a network
One of the partner’s biggest concerns was why Huntress had isolated the endpoint despite their AV successfully removing the malware. This is a common question and a great opportunity to explain the value of EDR vs. AV.
Even if an AV solution successfully removes a malicious file, there are still risks:
By isolating the endpoint, we ensured that network activity by the malware was prevented, the admin had time to fully investigate for any lingering threats, and the integrity of the system was preserved before reconnecting the device to the network.
This ticket was an example of an interaction with a partner when stakes were fairly low, and an incident had already been remediated,but that wasn’t immediately clear to the partner based on the incident report alone. By the end of the conversation, the partner had an understanding of what had taken place and the purpose behind our suggested remediations.
Conclusion
Stakes may not always be low, and many incidents have the potential to cause even greater damage. Dealing with those incidents alone can be stressful.
The SOC Support team is here to assist our partners as they navigate the specifics of our incident reports, or if they just need an additional set of eyes on any security-related concerns they have.
