Subscribe
Share
Share
Embed
Podcast audio-only versions of weekly webcasts from Black Hills Information Security
Hello, everybody, and welcome to today's Black Hills information security webcast. My name is Jason Blanchard. I'm the content community director here at Black Hills, and I get to introduce Tom D. Young today for our webcast, and it's inside the SOC triage smarter, not harder. And so if you don't know how these webcasts begin, it's we reach out to people on the team who are good at sharing their knowledge, and we say, hey.
Jason Blanchard:Wouldn't you like to? And they say, sure, but I'm not sure what I should talk about. And then we talk it over, and then Tom settled on this, and it is a fantastic topic. Tom is a part of our SOC that we have for our clients and for our own internal use. And so Tom's gonna give you like, he does this every day.
Jason Blanchard:Like, this is what he does. And so if you're here to learn from Tom, maybe as you're watching, you're like, why does he do it that way? There might be a little bit of, why does he do it that way? But as you're watching, it's like, is there something I can use to help improve the work that I do, or the work that our team does? And so we appreciate you being here, yeah, for you to learn, and we appreciate, you coming back if that's the case.
Jason Blanchard:Alright, Tom. It's all yours. I'll be backstage, and we'll be back for q and a at the end.
Tom DeJong:Alright. Well, thanks, Jason. I appreciate the intro. So I just wanted to start by saying thanks to everybody who made it out today. I really appreciate it, and I hope you guys enjoy the webcast.
Tom DeJong:So getting started, this is my presentation, Inside SOC, Triage Smarter, Not Harder. Alright. So just a little about me. I've been with BHIS since October 2022. I originally came on as an intern with the systems team, and I have since transitioned to the SOC.
Tom DeJong:In in the SOC, I work as a triage lead, and I'm also a mentor to new hires and interns. So so in my day to day work, I do quite a bit of triaging alerts. I I tried looking up some stuff on YouTube about how to triage alert, and there was a couple videos, but there wasn't really a ton of content. I thought it would be a good thing to go over in a webcast. So I've also done some incident response consulting at BHIS and I also do backdoors and breaches for clients.
Tom DeJong:So that's a little about my job here at BHIS. So for education, I have a degree in information technology. And during during my schooling, I gravitated towards information security topics and I decided to follow that path. It's been going good so far. So outside of work, love to go snowboarding in the winter and when it's warmer outside, I like to go rock climbing and hiking.
Tom DeJong:I live in South Dakota, so we have the beautiful Black Hills to to go adventure in nature. Alright. So here's a little breakdown of the agenda. We'll be covering triage fundamentals. We'll talk about the triage mindset, the anatomy of an alert, the triage process, how to identify real threats versus noise, deciding whether you should escalate or close an alert, common mistakes that SOC analysts make.
Tom DeJong:There'll be some real world triage tips. I'll have a live demo, and then there will be a questions and answer session at the end like Jason was saying. So please feel free to send your questions into Discord throughout the presentation, and we'll try and get them answered at the end. Okay, so just wanted to start out with a breakdown. So what is triage?
Tom DeJong:So in the context of information security, triaging an alert is the process of evaluating and prioritizing security alerts to make a determination on which one requires immediate action, if it needs further investigation, or if it could be safely closed. So what are the goals of triaging? So we're wanting to determine the impact and severity of an alert. For example, your alerts will probably have a severity tied to it, it's your job to validate that severity based on the context. You'll also be so also a part of it is identifying real threats that need to be escalated or something that needs immediate action.
Tom DeJong:So for example, you might get an alert for an encoded PowerShell command. So after decoding that, can see there's a file download from a suspicious IP. So you would enrich the alert and you can see that the IP is linked to malware campaigns. In this scenario, you're probably gonna escalate immediately and potentially isolate the host. You'll have document decisions and findings.
Tom DeJong:So using that encoded PowerShell from the last example, it's gonna be important to document things like the timestamp, the user, the host, the IP address, the decoded command, the process ID, and just provide a brief explanation of why you escalated. And lastly, in the goals column, we have filtering out false positives. So you might get an alert for a suspicious net. Exd command being run by an admin. Let's say this is the tenth time you've seen this alert this week.
Tom DeJong:You're probably gonna wanna filter this out because it's happening frequently, and the user should be authorized to run these commands considering they're an admin. Moving on to the what it involves column. So we got the first up is reviewing alert metadata. And we'll kind of get into more more on this on the next slide. Moving on to judging if behavior is normal, suspicious, or malicious.
Tom DeJong:So let's say you get an alert where a user from the HR department is running cmd. Exe to launch an instance of PowerShell. Well, that's a little suspicious because why is the user from HR running these admin tools? We also have make a decision, escalate close, further investigation. So let's say you get an alert for suspicious network connection.
Tom DeJong:So after gathering enrichments, you can confirm that the domain from the alert is a safe Microsoft domain. And maybe you review some past tickets and you can also see that this alert has been triggered once a month and has been confirmed to be safe in the past. Considering this, you decide to close the alert. And lastly, we have enriching data with threat intel or internal context. Just to make sure we're all on the same page here, so what is enrichment?
Tom DeJong:Enrichment is the process of adding external or internal context to raw data to make it more meaningful, actionable, and easier to triage. So let's say for this example there's an alert showing a connection to a domain that you would enrich. And you would enrich this by looking up the domain with a tool like VirusTotal or doing a Who is lookup. There's all sorts of ways you can enrich data. Okay.
Tom DeJong:So so why does triage matter? So the first up, have becoming more efficient. So, you know, this is important because time counts when you're working on the SOC. And as you begin to master how to triage, you'll be able to move faster without cutting corners. This is gonna help you spend less time working on alerts that are low severity and focus on investigating more important alerts.
Tom DeJong:We also have reducing alert fatigue. So what is alert fatigue? This is gonna happen when analysts are overwhelmed by the volume or repetition of alerts. This leads to missed threats, rushed decisions, and analyst burnout. Being good at triage provides you the ability to confidently close low risk or false positive alerts.
Tom DeJong:And being able to work through these alerts quickly is key to reducing alert fatigue, reducing burnout, and it keeps your mind sharp for high severity alerts. Then we have the improving threat detection. So being able to give more attention to the alerts that need it means you're more likely to catch the real threat. Being able to confidently triage alerts will help you become better at crafting and tuning detections. And lastly, we have building trust in your decisions.
Tom DeJong:So consistent triage shows that you know what you're doing, and over time, you will build confidence with yourself, your team, and leadership. They will also have confidence in you when it comes to high pressure incidents that you will encounter while working in the SOC. Okay, so I'm going to talk about triage mindset a little bit. I call these the three pillars of the triage mindset. So we have efficient and decisive, analytic and context aware, and clear and communicative.
Tom DeJong:So starting off with efficient and decisive. So you're going to want to be efficient, not rushed. You know, this is going to mean you're working fast with a process, but not fast at the expense of accuracy. So I find it helpful to be methodical. I just repeat the same things over and over all day.
Tom DeJong:This could be something like having generic queries ready to go that you're going be able to reuse during future investigations. Or like, I have a template I use for all of my tickets I'm filling out. Next up, we have decision oriented. When I say this, I mean just know when you have enough information to escalate, close, or investigate further. Know, triage ends with a decision, and you're not going to want to endlessly dig at this stage.
Tom DeJong:So just remember that if you are having a tough time, you can make the decision to ask a teammate for help. And if you struggle with this, you can ask yourself, Do I have enough context to make a confident call? If not, what is one other thing that I need to check? Lastly in this column, have being calm under pressure. So don't panic even when the volume or urgency is high.
Tom DeJong:Remember, take a breath and walk through your process. For example, you might see a string of alerts that appear to be a ransomware attack unfolding. It's important to check the key fields, get another on your team involved as soon as possible, and quickly working to take action. And then the second column, the analytic and context aware. So you want to be curious, not complacent.
Tom DeJong:Always ask yourself questions. Some good questions are going to be, Why did this trigger an alert? Is this expected activity? And just remember that even if something looks harmless, make sure to dig deep enough to know for sure. We have context driven.
Tom DeJong:So context turns data into insight. I always try and answer the five who, what, when, where, and why. So as an example, who triggered the alert? What system was involved? When did it happen?
Tom DeJong:Where is this activity coming from or going? And why is this activity happening? The same alert may be benign or malicious depending on the five Ws, so it's very important to answer those. And we have pattern oriented. So you're going to want to be looking for trends and repetition across users, systems, and behavior.
Tom DeJong:For example, you might receive a PowerShell execution alert on a user's machine. So instead of escalating right away, you're going to want to check the role of the user, research what the command does, and you're probably going to want to review past tickets. Maybe during this, you'll find that the user is an admin. And while looking over the past tickets, you can see similar alerts triggered during maintenance in the past. So in this scenario, I'd make the decision to close the alert.
Tom DeJong:You know, this is a known admin, it appears to be expected activity. Then in the last column, we have clear and communicative. So being communicative, this is going to be things like writing concise and thorough notes so that others can follow your logic. And the mindset isn't just internal, it will show in how you write notes, update tickets, and share findings. So being able to include clear and brief communication helps the next person in the workflow.
Tom DeJong:Then we have consistent documentation. So document your actions and reasoning so that nothing gets lost. John Strand says document as you go. So it's important to have clear and consistent documentation that ensures that your triage process is understandable, repeatable, and easier to review by anyone else on your team. Lastly, we have ask questions.
Tom DeJong:So reach out to others when you need help. When doing this, be sure to provide context and show your thinking. Remember, none of us know everything, and when doing triage, you'll frequently encounter things you don't know. And I've always thought asking for help is a sign of strength. And chances are, if you're wondering something, then another teammate is probably wondering the same thing.
Tom DeJong:You know, you might see an alert for RDP access to a server after hours. So you're going to want to document relevant alert details such as timestamp, user, source IP. You're going to want to document the checks that you did. So have you checked the login history or the user role and known IPs? And then you could ask a senior analyst what they think of the situation.
Tom DeJong:And maybe in this scenario, the senior analyst is able to quickly review your documentation and take quick action to remediate the alert. Okay. So what is the anatomy of an alert? I've broken this down into three sections as well, so we'll start with the core elements section. We have the alert name, rule name, and detection logic.
Tom DeJong:These fields are going to help you identify what behavior or indicator triggered an alert. You can use this to find the key fields to document and figure out where to pivot to next from that. The timestamp this is important for documenting when things happen. You can also use this to correlate with other logs. The username is also important for identifying who triggered the alert and what their role is in the company.
Tom DeJong:Their host name, that's going to tell you where the activity is happening. We got the process ID. This is going to uniquely identify a specific instance of a process. The process name shows you what process was running. The command line is going to show you the exact arguments that were used when the process ran.
Tom DeJong:The file path will show you where on disk the affected file is located. Hashes are going to be important for verifying different files in the reputation. Domains and IPs. This is going to be helpful for identifying where traffic is going to and where it's coming from. And lastly, we have the source and destination ports.
Tom DeJong:This can be important because it can help you identify the protocol or service used during a connection. And I will say, the anatomy of an alert changes depending on this is a nice overview for process creation events or network events. So if you have AWS alerts, you might be able to translate some of these to that, but they will probably be different fields. So questions to ask. You know, is this behavior normal for the user or host?
Tom DeJong:Remember, context is key, and what's suspicious for one user may be completely normal for another. For number two, we have does this command or domain look suspicious? So the command line arguments and domains can often give away the attacker behavior. Three, we have is this alert part of a pattern I've seen before? Repeated alerts can reveal misconfigurations or real persistent threats.
Tom DeJong:They can also be useful when identifying past investigations where you can check to see if this has been confirmed as expected activity. Four, we have Is there enough context to investigate? Missing important data can impact your ability to make a decision on how to proceed with triage. And there will be times that you need to dig deeper to uncover missing data. And for five, we have What logs or tools can I use to check?
Tom DeJong:So different alerts require different sources to validate. Knowing where to look can help you come to a decision on how to proceed with triage. And in the Work Smarter column, we have, you're going to want to spot the red flags early, so try and train yourself to quickly recognize signs of suspicious activity. You know, this could be, an unknown RMM tool. You know, there's all sorts of things that you will come to find.
Tom DeJong:And, you know, as you do more triaging, spotting those red flags is going to be easier for you. So remember that making a decision early helps prioritize your time and focus. Next up, we have focus on key data fields. And this will change depending on the type of alert, but you're going to want to focus on the important fields first. So I like to start with the fields listed in the core elements section of the slide and pivot around from there.
Tom DeJong:Remember, not all fields are equally useful, so prioritizing important ones can help speed up decision making. Then we have check for enrichments. So add context by looking up hashes or IPs or domains. You can also check your internal resources like a knowledge base for the user role or what a specific system does. Enrichments can turn a vague alert into an informed decision.
Tom DeJong:Then we have correlate with other alerts or logs. So viewing an alert by itself might not show you the full picture. You're going want to check for related activity in the firewall logs or maybe in the SIEM. One alert may seem benign, but looking at others may provide a context that makes it look suspicious. So let's say, for example, you're seeing alerts for a password spray, and then you see an impossible travel login alert, and then you can see the creation of a mailbox rule.
Tom DeJong:Looking at the picture of these three alerts, it does make it seem like the password spray was successful because there is an impossible travel login. And then we can see the attacker did something by creating a mailbox rule to try and hide their tracks. And lastly, refer to internal documentation. So using internal documentation helps you make faster and more confident triage decisions. You may look at things like past investigations, known software, or client owned domains.
Tom DeJong:This will help you avoid reinvestigating the same benign activity over and over. Keeping good internal documentation can speed up triage. Okay, so this is an example of a typical alert you might see. Starting off in the category at the top, you can see this detection is named potentially suspicious RENDLL32 activity. And after looking at the rule logic, this specifically triggered because of the URL.
Tom DeJong:Dll and the file protocol handler arguments in the command line. So what are the key fields for this alert? We're going to have the category or rule name. We'll have the source, which would be the host name, the timestamp, the command line, the file path, or in this, it would be the same as the process executable. We have the hash, the parent command line, the parent file path, the username, and then the parent process ID and the process ID.
Tom DeJong:So that link at the bottom will take you to the rule logic in the Lima Charlie GitHub repo for you to check out for yourself. Okay. So this is how I've broken down the triage process. So starting up in the top left, we have review the alert. So you're gonna wanna carefully read through the alert.
Tom DeJong:Try not to just skim the alert. It can be easy to do, but it is important to read through the key fields. You're going to want to check the severity, the rule name, detection logic, and other key metadata fields. You know, you're going want to ask what triggered the alert, what behavior was flagged. This should be much easier to pivot once you figure those out.
Tom DeJong:So this is important because this is going to form your first impression of an alert that you're reviewing. That impression can guide your triage path. Even without enrichment, certain alerts can signal danger. So try not to overanalyze too soon, but also don't ignore any red flags. The first time you review an alert is about identifying whether you need to dig deeper, escalate quickly, or close out the alert.
Tom DeJong:Then we have gather context. So after reviewing the alert, the next step is to dig deeper and enrich the data with context. So check the user's role and behavior history. You know, is this a service account, an IT admin, or just a regular user? You're going to also want to check the asset involved, such as the endpoint or server.
Tom DeJong:Is this system a domain controller? Is it a laptop or a test virtual machine? So you'll want to enrich the alert with ThreatIntel. So run the file hash and virus total or check the URL on URL scan. And then you're going to want to review relevant logs for previous alerts.
Tom DeJong:So look at past tickets for the user or host or look for any other alerts that could be related. Remember, the more context you gather, the better picture you will paint. This will help you separate real threats from noise. Then we have make a decision. So this is going to be the most important moment in the triage process.
Tom DeJong:During this step, you will turn your analysis into action. Look at everything you've gathered and determine which decision you make. You will decide to escalate, investigate further, or close. Some criteria for each are going to be, you know, escalate. This is malicious or highly suspicious activity.
Tom DeJong:So it could be things like you have found strong indicators of compromise, or maybe the behavior is clearly malicious and can't be explained confidently. They investigate further. You know, this will be something that might still be unclear or potentially important. So for this example, maybe the alert is showing suspicious activity, but there isn't quite enough context to come to a conclusion yet. So there may also not be enough data to make a confident decision.
Tom DeJong:So that means that you need to go gather more logs, or you might need to get context from the user, or get a second opinion. And then closing, this would be things that are benign, false positive, or known behavior. So we could say maybe the alert was triggered by normal behavior, known processes, or activity that has been confirmed in the past. Triage is incomplete without a decision, and that decision is needed to move forward. And I just wanted to say, try not to guess.
Tom DeJong:Make a decision with confidence, even if that decision is, This alert needs more info to investigate further. And then we have, lastly, the document outcome. So you're going to want to so triage doesn't end when you make a decision. It ends when you've clearly documented what you saw, what you did, and why. And good documentation builds trust, it supports investigations, and it really helps the entire SOC team.
Tom DeJong:So you're going to want to document a note that says what you reviewed. You know, you'll briefly describe the alert and what triggered it. This will include those key metadata fields that we've kind of been talking about, you know. It could be the process name or the user. Then you'll want to document what context you found, so outline the steps taken during your investigation.
Tom DeJong:For example, you checked the virus total for the hash, or you reviewed the process tree. Then we have document the outcome. Did you decide to escalate, investigate further, or close? And make sure you clearly justify your decision. This is going to be important because your notes will help the next analyst if the alert triggers in the future, And SOC tickets can be beneficial if the alert you reviewed turns into something like an active incident response incident.
Tom DeJong:Okay. So I wanted to kind of talk about what is real threat or just noise. This will be something you encounter while you're triaging things. So what I mean when I say that is, how can you tell an alert deserves more action or if it's okay to just close it out? Being aware of these can help newer analysts build judgment and confidence when identifying false positives, expected behavior, or actual threats.
Tom DeJong:So just some quick definitions here. Real threat that's going be an alert that indicates suspicious or malicious behavior that will require action. Then the noise the noise is going be alerts that are triggered by benign or expected behavior. So starting with the real threat, you're going want to identify red flags that spark a deeper investigation. This might be something like abnormal behavior for the user or host, or maybe you're seeing hacking tools like Mimikatz or Metasploit.
Tom DeJong:It could be things like the sequence of the alerts showing multistep activity. You might see an alert for execution, an alert for lateral movement, and an alert for exfiltration. Then we have the just noise. So some examples of this are gonna be scheduled PowerShell backups or admins using remote management tools like PSExec or Remote Desktop Protocol. Maybe it's known good external domains like Microsoft telemetry you're seeing in the alert.
Tom DeJong:It could even be vulnerability scanners that are hidden systems. As a tip here, you're going want to keep the internal documentation that you can reference to things like approved software, admin users, and maybe known external domains. And just because it's noise doesn't mean that it's worthless. Overall, it does still deserve quick validation. And if you feel you're encountering a lot of noisy alerts, then that is a great opportunity for you to tune your detection logic.
Tom DeJong:Moving on to tools and techniques. So so these are gonna help you add context. It's gonna help you validate alerts and ultimately make smarter triage decisions. So you could use a SIEM or an EDR enrichment. You know, this will these will be tools that you can use to dig deeper into the alerts.
Tom DeJong:You could use threat intelligent platforms like VirusTotal or URL Scan. This threat intel is going to give you external reputation and validation to support or refute what you are seeing. Then we got internal playbooks. So, you know, what's the standard operating procedure for this alert type? You know, playbooks are going to help you triage consistently and it also helps you meet your team's expectations.
Tom DeJong:And lastly in this, we have host and user baselining. So what is normal for this environment? Remember, the same alert could be totally benign or very dangerous depending on who triggered it and where. When in doubt, remember triage is in black and white. It is normal for newer analysts to feel uncertain, and the thing that matters most is how you handle these when you aren't 100% sure.
Tom DeJong:So search for past occurrences of the alert. Reviewing a past alert, it might tell you if something is benign or if the activities from a specific process needs to be escalated. You can also see how other analysts approach an investigation to gain insight on what context to gather. Try to default to the investigate more mentality instead of blindly escalating. So you're going to want to try to avoid escalating to be safe, and you're going to want to ultimately investigate until you can justify your decision.
Tom DeJong:And then we have ask a senior analyst for help. So just when you do this, make sure you bring your findings and reasoning. And then we have document what you're trying, even if you're still unsure. Here's another tip here. Sometimes when I feel unsure about something, writing everything out would really help me understand what's happening.
Tom DeJong:And I tell that to all new hires and all the interns I'm working with because it works. All right, so I kind of wanted to talk about escalating or closing, break it down a little further. So important for analysts to confidently make the right decisions during triage. So escalating is going be when you pass the alert to another team, Depending on what type of SOC you are, this could be a client organization, or it could be the incident response team. So what are some criteria for escalating?
Tom DeJong:These are going to be some strong indicators and alerts should be escalated. The confirmed malicious it's been confirmed malicious behavior in the past, behavior that matches known attack patterns. Maybe you see some connections to suspicious or malicious IPs or domains. It could even be activity that you're seeing on a critical system, like a domain controller. And then we have the persistence.
Tom DeJong:There might be persistent mechanisms or signs of backdoor. And then there would also be requires containment or isolation. Oh, I think I skipped one here. So also the use of unauthorized tools. So what is our criteria for closure?
Tom DeJong:An alert can be closed if triage shows the activity is benign, expected, or already handled. So here are some indicators that an alert could be closed. Maybe it's an alert from a noisy or broad rule. It could be expected behavior of a known business process. Maybe it's activity that has already been covered by existing tuning or allow list.
Tom DeJong:You may see benign network behavior. It could be alerts that are triggered by internal tools. There may be no indicators of compromise. And maybe it's an alert you see in a test lab, a test or lab environment. And lastly, we have, maybe it's a repeated alert that is already escalated or handled.
Tom DeJong:So if closing an alert, it is important to document why you closed the alert. This can be useful for tuning purposes or maybe other analysts reviewing your investigation. All right, so I kind of wanted to go over some common mistakes to avoid, And some of these still happen to me as a heads up. It can be tough. So these are just some things you should look out for.
Tom DeJong:So starting on the top left, we have escalating without evidence. So our example mistake might be an analyst will escalate an alert just because it looks bad or without doing a proper investigation. So this is harmful because it wastes time, it erodes trust, and it also creates unnecessary alert noise. What should you do instead? You're going to want to investigate, enrich, and document.
Tom DeJong:And make sure you're escalating with proper justification. We have over investigating low risk alerts. So, the mistake here would be spending thirty minutes on alerts that are clearly benign activity. It could be related to admin tools or scheduled tasks that the organization runs. This is going to be harmful because it reduces time for higher priority work and it increases burnout chances.
Tom DeJong:So what should you do instead? You're going to want to use internal resources in context to confidently close benign alerts. This is another scenario where you could also tune them out of your detection logic. Then we have skipping context checks. So a mistake here would be failing to check past tickets or user role or asset type.
Tom DeJong:This is harmful because it can lead to false positives and even missed threats. So what should you do instead? Check for past investigations or escalations before fully digging into alert. I can't tell you how many times I have got in there and started doing an investigation, only to look after twenty minutes and see, oh, this was already investigated yesterday. So it can definitely help to be more time efficient.
Tom DeJong:Then we have weaker missing documentation. So the mistake here would be writing vague things in your documentation such as, Oh, this looks fine, or No threat found. This is harmful because it creates gaps for audits and leads, and it leads to repeated triage of the same alert. In this scenario, you should be clearly documenting what was investigated, what you found, and what decision you made. Then we have not asking for help when needed.
Tom DeJong:So the mistake here would be an analyst struggling silently and closing out alerts without fully understanding what's happening. This is harmful because it can slow analyst growth, it increases the risk of mistakes, and it leads to burnout. You know, you may also end up missing true threats. So what should you do instead? You should ask questions to your team.
Tom DeJong:Nobody's going to get mad at you, and it's okay to not know things. We've all been at a point where we didn't know and had someone to help us. Then we have treating all alerts the same. So this would be things like giving equal attention to every alert regardless of severity, asset type, or threat type. This is harmful because it leads to alert fatigue, burnout, and it can be a misallocation of time.
Tom DeJong:So instead, you should prioritize higher severity alerts, high value assets, suspicious behavior or known threat patterns. Okay, so what are some tips for making the right call? Triage decisions can be high pressure, especially when the queue is full and the alert you're working is unclear. Making good triage decisions isn't about guessing it's about staying calm, following your process, and applying context to the alert. So here are some practical tips to avoid mistakes and build confidence in your decisions.
Tom DeJong:First up, we have don't escalate out of fear. So it's common for newer analysts to make fear based decisions, and unfortunately, this can lead to alert fatigue and inefficiency in the SOC. Escalation should be evidence based, not an emotionally driven decision. And it's important not to panic or give in to the desire to just play it safe. Blindly escalating creates alert fatigue and can erode trust in your team.
Tom DeJong:So if you're feeling unsure, investigate more until you have the evidence you need. I myself struggle with this still, but you know, when this is happening, I try to take a step back, take a breath, and really think about all the context I have. Then we have use a checklist. So using a checklist, and even a mental one, can prevent an overreaction and ensure that you're not missing something obvious. So before escalating or closing an alert, ask yourself questions.
Tom DeJong:Is this activity abnormal? Does the activity pose a risk to the business? Is there enough context to justify an action? Can I describe why this is suspicious or malicious? If you're unable to explain why something is suspicious, then that is a good sign that you are missing key context.
Tom DeJong:I just wanted to say I find myself asking the last question often, and I find that it really helps me to hone in on the key details and understand all the context that I've gathered up until that point. So there have been times that I was escalating to be safe, but I wasn't able to fully explain why the activity seemed suspicious. But once I sat and really thought about it, it was apparent that the alert in that scenario was a false positive. So overall, using a checklist won't slow you down but actually make you faster, clearer, and more confident. And then we have know your environment.
Tom DeJong:So without understanding your environment and understanding what normal is, then you can't assess risk accurately. And I'll say it again, what looks suspicious in one company may be totally normal in another. You're going want to build familiarity with asset roles, user behavior, and common processes and procedures. The more you know about your environment, the faster you'll be
Tom DeJong:able to spot the anomalies.
Tom DeJong:So for example here, using PSExec in one company is something that you see IT using frequently. While in another, it could be a huge red flag that requires immediate action because it would be unimproved software that is abused by threat actors. All right, so I wanted to give some smart documentation tips. So as a SOC analyst, you're going to want to write clear, useful, and efficient notes. This will improve your investigations, enable collaboration, and reinforce your decision making skills.
Tom DeJong:So starting with the top half, what to include in a good triage note? So you're going want to do your summary. This will be a description of what triggered the alert. For example, you got an alert for network connection via certutil. You might say something like, the alert triggered because a user named Bob used certutil to connect to a domain and downloaded a file.
Tom DeJong:Then we'll move on to actions taken. So these will be checks that you performed during your investigation. Here you're going want to list the tools or logs that you used. I would also include any enrichment or internal documentation you referenced. So, for example, you could say something like, I checked command line arguments, I reviewed the process tree, and I searched the file and hash, I checked the file hash and IP in VirusTotal.
Tom DeJong:Then you'll want to do your findings. So these will be key details you found during your investigation. Going off the certutil example again, you could say the command line argument is certutil. Exe url baddomain.com file. Exe.
Tom DeJong:So this would be them trying to download a file from this baddomain.com. So maybe this is something where when you looked it up in VirusTotal, can see the domain and the hash both had 20 flags on VirusTotal. And then last for the what to include is going be your decisions. So why you chose to escalate, close, or investigate further. Make sure to include a brief justification for your decision.
Tom DeJong:So in this example, for the certutil, we can say, I escalated this alert due to strong indicators of compromise. The certutil command line is a known LOBAS technique, and both the domain and file in the alert were flagged by 20 vendors. And for those of you that don't know, LolBASS is going to be living off the land, binaries, and scripts. So moving down to the bottom half, some tips for better, smarter notes. So you're going to want to be specific.
Tom DeJong:Document detailed findings. Clearly describe your findings using accurate terminology. Try to avoid vague language like this looks suspicious or seems fine. You will want to be concise, so summarize your findings. And they'll help to keep your notes short and readable.
Tom DeJong:Try to summarize what you see in the logs instead of just copy and pasting a chunk of raw data. Having concise notes are easier to review, especially during stressful times. Be consistent. So use the same structure across investigations. You structure your triage notes, toys list, the summary, the actions, the findings, and the decision.
Tom DeJong:Consistency will make your notes more predictable, scannable, and more useful for your team. And then references. So include links to resources you used or found. This could be things like the queries used, internal tickets that were referenced, virus total lookups. Remember, references support your conclusions and give others a fast way to validate your findings or dig deeper.
Tom DeJong:So this is just a basic documentation template that you can use. So we have the summary, like we talked about, just a brief description of the alert and what triggered it. We have the actions taken, you know, checks you perform, tools, logs, enrichment sources. Then we have the findings. So this will be like key context, suspicious or benign behavior, or notable evidence, and then the decision.
Tom DeJong:So did you escalate, close, or investigate further? You know, you're going to want to document your reasoning for this decision. I added a couple bullet points down here at the bottom to keep in mind, so use bullet points for clarity. Try to keep it short but meaningful, and link to relevant tools or logs, if allowed. So now we're going to talk about some soft skills that make a difference.
Tom DeJong:So communication is our first job. So strong communication is one of the most underrated skills in the SOC. Being good at communication helps your team work faster, avoid confusion, and respond effectively to threats. Then we have write concise and clear notes, so try to keep your documentation short but informative. Then we have asking good questions, so next time you're feeling unsure, ask a question that shows that you've already done some thinking about the topic.
Tom DeJong:For example, you could say, I saw X in the logs, and I checked Y, but I'm still unclear on Z. Does this look normal to you? Remember, good questions lead to better answers and they also help you grow as an analyst. And then we have sharing relevant updates. So keep your team informed of your status during triage or incidents.
Tom DeJong:You know, for example, you could say, I'm still investigating this alert, but I did find this suspicious script. Depending on your organization, you might use a messaging app like Teams. You could just do it all in updating your tickets, or maybe you have a dashboard. Real time updates improve team coordination and prevent duplicated effort. Next we have the active listening.
Tom DeJong:So when things are chaotic, it can be easy to jump to conclusions. Active listening helps you to slow down, absorb key details, and respond more effectively. So be sure to listen carefully before reacting. It can be hard sometimes, but try not to interrupt or assume. Let others finish explaining their thought process or findings.
Tom DeJong:Jumping to conclusions can lead to duplicated work or missed context, so listening well improves accuracy and teamwork. You can do things like taking time to understand the context. You know, take a step back and ask yourself, what is the full picture here? What's been investigated already? And to make it all really quick, you're going to want to read previous notes, chat threads, or ticket history before responding or acting.
Tom DeJong:Understanding the background or previous work a teammate did helps you to make better decisions and avoid miscommunication. Then we have ask clarifying questions. We've covered them a little bit, but use questions like, When did this activity start? Which user account was involved? Have we seen this before?
Tom DeJong:Asking clarifying questions shows that you're engaged and thinking critically about an issue. Then we have collaboration. So SOC teams thrive when analysts work together, support each other and share knowledge. Good collaboration builds trust, it speeds up investigation, and ultimately helps everybody level up. So share your findings or shortcuts with the teams.
Tom DeJong:If you learn something like a new tool trick or a log quirk, pass it on to the team. They will definitely appreciate it. I know I do when it happens. So just remember that keeping knowledge to yourself doesn't help the team, but sharing knowledge levels up the whole team. You could also do things like picking up slack when it gets busy.
Tom DeJong:If you finish your tickets early or see a teammate who has swamped, offer to help. This could even be reviewing someone's draft notes or double checking an alert they they triaged. So I know that I always appreciate when I have a teammate who offers to help me with things. Remember, the teams that support each other avoid burnout and work more effectively. The last one for the collaboration is giving and receiving feedback without ego.
Tom DeJong:Be open to constructive feedback on your triage notes, analysis or decisions. And when you're giving feedback, try to focus on the process, not the person. And this can be tough at times, but, you know, giving and receiving feedback helps everybody grow. And a healthy team culture encourages learning, and feedback is an important part of that. Then lastly, we have composure.
Tom DeJong:So SOC work is fast paced and high pressure. Being able to stay calm, focused, and methodical during chaotic moments helps you to make better decisions and avoid costly mistakes. So use a playbook when it's chaotic. You know, when alerts start piling up, be sure to lean on established procedures. Playbooks exist to help guide decision making under stress.
Tom DeJong:Having consistency in process is going to lead to fewer errors even when it's chaotic. We have think before you escalate. We've covered this a little earlier, but it is important to take a breath and verify the evidence before escalating an alert. Just try to remember that escalations add noise, and it can increase pressure on the team. Lastly, we have managing time and focus when it's busy.
Tom DeJong:Try to prioritize alerts based on severity and potential impact. If possible, try to avoid multitasking across too many complex alerts, as it can lead to mistakes. Staying organized helps you stay effective even when things get hectic. All right, so now we're talking about managing alert fatigue. Recognizing the signs of alert fatigue is the first step towards managing it effectively.
Tom DeJong:What are some symptoms of alert fatigue? You may do things like skimming alerts. You know, an analyst might start scanning alerts quickly without reading them fully. This can lead to missing important details or patterns. Maybe they escalate in to be safe.
Tom DeJong:You know, when you feel overwhelmed, may be tempted just to escalate alerts you're unsure about just to get them off your plate. Just remember, escalation should be evidence based, not a response to pressure. We have closing alerts too quickly. You may dismiss alerts without sufficient investigation because it looks fine or it seems like noise. Getting in the habit of quickly closing alerts can lead to missed threats.
Tom DeJong:We have feeling burnout. Constant alert volume and repetitive tasks can lead to frustration, exhaustion, and disengagement. Burnout affects the quality, consistency, and your well-being. And long term fatigue leads to turnover, which will ultimately lead to a weaker security posture. So why does alert fatigue happen?
Tom DeJong:Alert fatigue isn't just about alert volume. It's about how alerts are surfaced, handled, and supported. So these common causes can wear analysts down over time. Poorly tuned detections. This could be alerts that trigger on normal activity or internal tools.
Tom DeJong:Detections like this can cause analysts to spend time investigating events that probably should have been filtered out. It might be pressure to act quickly on every alert. Depending on the organization, the SOC culture may push for speed over depth. This could manifest as analysts having a close it fast mentality. So when that happens, analysts feel rushed and they'll end up missing real threats.
Tom DeJong:It could be repetitive, low fidelity alerts. So these will be alerts that trigger frequently but rarely lead to real incidents. This can lead to the alerts becoming background noise that analysts start to ignore or dismiss. Repetition desensitizes analysts, it can also lead to real threats being missed. Then we have the growing workload without automation or support.
Tom DeJong:SOC teams are expected to manage an increasing number of alerts without corresponding increases in tools or staffing. Efficiency suffers without automation to help do things like triaging basic alerts or gathering enrichment sources into a unified dashboard. A growing queue with no relief leads directly to burnout and turnover. Moving on to managing fatigue. So there are ways to reduce the impact of alert fatigue and stay sharp during triage.
Tom DeJong:These are just some strategies that help analysts work smarter, not harder, while avoiding burnout. So leverage your internal documentation. Use things like playbooks or previous triage notes to speed up investigations. Don't reinvent the wheel and learn from past alerts. Using internal documentation saves time and removes uncertainty when patterns repeat.
Tom DeJong:You're going want to use your enrichments wisely, so try to avoid information overload by being more targeted in how you enrich alerts. For example, you are probably not going to have to look up every hash you see in an alert. You're going want to focus on the important hashes and look those up. You could also pull in threat intel or maybe the asset context or user roles into a unified dashboard with a tool like a SOAR. So remember, enrichment smartly gives you clarity without wasting time chasing irrelevant data.
Tom DeJong:Then we have tune and improve your detections. If you are encountering noisy or low value alerts often, then that's a great time for tuning. You know, make sure you provide feedback to engineers or detection teams when false positives are frequent. When you are able to proactively improve detection quality, then you will be able to help reduce alert fatigue for everybody. And then lastly in this column, we have taking mental breaks.
Tom DeJong:So be sure to step away between complex investigations or during long shifts. Having a brief reset helps prevent burnout and also helps restore focus. You are more effective when you're rested, and alert fatigue often starts with mental overload. Lastly, we have shifting your mindset. So managing alert fatigue isn't just about tools, it's also about how you approach the work.
Tom DeJong:A strong mindset helps you stay focused, resilient, and confident over time. So triage is about consistency. You don't need to be perfect, but try to be consistent. Try to be methodical and follow your process. Another thing you can do is focus on progress.
Tom DeJong:So every alert is a chance to learn something new or sharpen your skills. Staying focused on improvement helps you avoid burnout and feel more in control. And we have trust the process. So standard operating procedures or workflows and playbooks are there to guide you when things get hectic. Trusting the process prevents decision fatigue and it keeps you grounded.
Tom DeJong:And lastly, have lean on your team. Remember, you're not alone, and collaboration is one of the best defenses against fatigue and frustration. Teams like communicate and back each other up, stay more effective and engaged. All right. So moving on to the live demo here.
Tom DeJong:I'll be using a tool called Lima Charlie. They have a very generous free tier that allows you to have two free sensors. So
Tom DeJong:and
Tom DeJong:then as a way to take notes, like a fake ticketing system, I'll be using Obsidian. So to get this to get these alerts, I I spun up a Windows VM and tried to trigger as many alerts as I could with one process. Let's see here. Okay. So I created this fake sock ticket.
Tom DeJong:So here we can see that the alert is a suspicious PowerShell activity detected. And as this mock alert, I kind of tried to make it like maybe a user risk score, was over. So so ultimately, there's three alerts that triggered. We have non interactive PowerShell process spawned, suspicious execution of a PowerShell with base 64, and encoded PowerShell command line execution. The three of these alerts triggered a high severity alert.
Tom DeJong:This is coming from Lima Charlie. We got our timestamp. We have our host name. We have the user, the process ID, the process, and the command line. So looking at these, I can see an encoded PowerShell command here.
Tom DeJong:That's a little suspicious, and it makes sense with the alerts that triggered. Our parent process is going to be WScript. It looks like there is a VBS script named demo. Vbs that spawn this PowerShell encoded command. So let's go to Lehman Charlie.
Tom DeJong:So I have the detections pulled up here for the sake of time. So let's see here. This matches up with our time, 12:17 08:26 forty one. So let's go to this first alert here. Looks like it doubled up.
Tom DeJong:So we can see this is the noninteractive PowerShell process spawned. And let's see here. Let's do it for this one, a suspicious execution of a PowerShell with base 64. We're gonna go and look at the alert or the rule logic just to see what what triggered this alert. Based on the name, it's kind of obvious what we're looking at, but just to show you the full triage process.
Tom DeJong:Looking at the rule logic, it's looking for a new process or an existing process. It needs to be a Windows host. It needs to the file path or executable in this scenario, needs to be PowerShell. And the command line either has to have an e, an en, an e n c, e n c l, or e c. So when we looked at the command, we could see there's an e n c here.
Tom DeJong:So going back here, we can see this. Here's our full base 64 command. I'm curious what that says. But alright. So let's pivot over to the timeline where we can check the process tree.
Tom DeJong:Here's our tree view. Okay. So we can see this originally started with explore. Exe. Here's our WScript.
Tom DeJong:Here's our PowerShell.
Tom DeJong:And it looks like Conhost spawned. And then it looks like it terminated. So so let's decode that base 64. We'll exit out our tree view here. Let's see here.
Tom DeJong:So
Tom DeJong:we're gonna let's see if I can
Tom DeJong:get my cursor in the right spot. Copy it. So I got Cyberchef pulled up here, so let's paste this in. And then we will go from base 64, and then let's take out those null bytes. Okay.
Tom DeJong:So we can see this command, and I'm just gonna copy this because we're gonna wanna fill in our ticket. It says start process PowerShell argument list, write output triage smarter, not harder. So this command is just going to print it to like, it's going to open a PowerShell window and just write triage smarter, not harder. So that doesn't really seem suspicious right off the bat. So so let's go to all this, and we're just gonna write in our findings.
Tom DeJong:We'll do a bullet decoding base 64 is start process. Okay. And then another thing I was curious about is going to be I'm gonna exit out of these. The hashes here. You can see here this file is signed.
Tom DeJong:But for the sake of this, let's copy this PowerShell hash. Let's see if it's legitimate. Okay. This is a file that's distributed by Microsoft, so let's copy this too. And then let's go back here.
Tom DeJong:So one of our findings is legitimate PowerShell
Tom DeJong:hash.
Tom DeJong:And we'll just put the VirusTotal link in here. So we've done that. So one of the last things is who is this user? So let's just say Tom DeYoung, b h I s, LinkedIn, since we don't have access to it. Okay.
Tom DeJong:We can see this guy works in the SOC here. All right. So this is a user that's probably gonna be authorized to use PowerShell. So we could write that in here. I like to copy the links and paste it in for the next person in line.
Tom DeJong:So user is part of the SOC. Okay. So and and you know, normally in these situations, this is this is one where you probably don't need to run the hashes for all these. And just for the sake of time, I'm not gonna do it. But all right, let's fill this out here.
Tom DeJong:So starting with the summary, what do we have here? We have multiple alerts
Tom DeJong:triggered the user risk score because of suspicious PowerShell execution. We could say the suspicious PowerShell used an encoded command. And PowerShell was spawned by WScript. Okay.
Tom DeJong:So that's kind of a good brief overview of what happened here for the summary section. So what did we all do here? So we reviewed process tree. We decoded base 64 payload. I cannot type today, apparently.
Tom DeJong:Let's see here. We verified the command output. We reviewed user role. And let's say nothing in the process tree looks suspicious.
Tom DeJong:I guess we could probably put that up here with those other. So that's good for our actions taken section. We got a couple of our findings done here. Yep. It looks like we kind of got all of our findings.
Tom DeJong:We're doing the documents as you go.
Tom DeJong:So what's our decision here? Our decision is ultimately going to be close the alert. And we'll say and then we could say, give your reasoning. So I believe this activity is benign. And then we could do just a short little justification here.
Tom DeJong:We could say, Dom Dion is a member of the SOC and appears to be performing this activity for a webcast. I believe the command is non malicious as it just prints Triage smarter, not harder. And then you could say no further action required.
Tom DeJong:Alright. So this is this is a good we got our summary, our actions taken, our findings, and the decision. So that should wrap up the live demo here. So let me
Tom DeJong:go back to my slide. So I just wanted to
Tom DeJong:put the rule object. These three rules here are going to be the rules that triggered. We only looked at the base sixty four one, but I thought you guys might want to check it out later. So I posted those here. And that's it.
Tom DeJong:I appreciate you guys coming out. I had a good time with this. I hope the webcast is helpful for you.
Deb Wigley:Good job, Tom. Done.
Jason Blanchard:Good job, Tom.
Tom DeJong:Hey. Take care. Thanks, guys.
Deb Wigley:Yeah. Good.
Tom DeJong:Take a take
Jason Blanchard:a So there is a CTF challenge. We're making sure that the GitHub link works. If the GitHub link isn't working, just check it again in about fifteen, twenty minutes. But there's a CTF challenge to go along with today. I put it in the Zoom chat.
Jason Blanchard:I'm putting it in the Discord chat. And if there's something not working, give us a few minutes to just fix it. Alright, Tom. If you're gonna just wrap up everything in one final thought, what would it be?
Tom DeJong:I think it would be, you know, take your time doing triage. You know, it's gonna be stressful, so take a breath. You know, make sure you use your team for help. And, yeah, you'll get better at it in time. It can be very stressful when you're first starting out, and it's still stressful after you've been doing it for a couple years.
Tom DeJong:But, you know, you're going be okay at the end of the day, and just try and use every opportunity as a learning opportunity.
Jason Blanchard:Awesome, Tom.
Deb Wigley:Well said.
Jason Blanchard:Alright, everybody. Thank you so much for joining. We're gonna go into post show banter. We're gonna answer some questions and, talk about, like, if you wanted to hire us to be your sock. We got some q and a we can do with that.
Jason Blanchard:And then, for most of us, it is the end of the year, so we're taking a break until the beginning of 2026. If you've been with us in 2025, thank you so much. If you if this is your first time here, hello, and welcome. Please join us again in 2026. We do this about two to three times a week.
Jason Blanchard:We love to share our knowledge. It is the way that we introduce ourselves to others. And so we don't spend money on, like, marketing and boost at RSA and things like that. We do this. We spend our money doing this to help others because we feel like the better prepared you are, the better prepared the rest of the world is.
Jason Blanchard:It's kinda selfish. I tell this to college students all the time. One of the reasons that we teach you is because eventually I'm going to be old, older. Right? And I will need that next generation of people who are, like, protecting my, things that I've been able to have in my life.
Jason Blanchard:And so thank you, for helping, protect others. Thank you for helping to protect your organization. Thank you for wanting to protect other people. It's a noble cause, and we appreciate it. Alright.
Jason Blanchard:Alright. We're on post show banter. Good job, Tom. How are feeling? I'm feeling pretty good.
Tom DeJong:Not as nervous as the the first webcast I did. So Yeah. My voice is a little hoarse, but we'll make it through.
Jason Blanchard:Yeah. Let's do it. We got a couple questions here. We'll ask those questions. I got a couple questions for you.
Jason Blanchard:What does the first three to six months look like for junior level SOC analysts, and what does the team or manager expect from them?
Tom DeJong:Oh, I'd say the first three to six months are gonna be learning. I mean, that could even go up into a year. Like, one of the interns that we had that's been working, he's just kind of getting to the point where he's starting to feel really confident in his decisions. I think he started back in April. So it can be tough in the beginning, but it will pay off, you will feel confident in time.
Tom DeJong:When you're first starting out, I like to see people asking a lot of questions. I'll never get mad at you for asking questions. I don't really promote that type of thing. So, you know, you'll, you'll be in uncertain situations a lot, but that's part of working in a SOC. You know, It's it's kinda you're like a professional.
Tom DeJong:What is this? I'm gonna go Google, do a cursory research on it, then go from there. So so, yeah, I'd say that's kinda lots of questions in the beginning and, you know, maybe not feeling the most confident, but it will come in time.
Jason Blanchard:Thanks, Tom. Alright. Next question is, could you elaborate on the example of an adversary creating an email rule to hide their tracks?
Tom DeJong:Yes. I can. So this is probably gonna be one of the attacks we see the most often in the BHIS SOC. It would be a business email compromise. So let's say that you get an account compromised, a threat actor logs in, and it could be like a phishing email.
Tom DeJong:They'll take over other businesses. Like, let's say you have a law firm and they're communicating with one of their vendors. So a threat actor may get into the vendor's network, send an email to the law firm, and they're going to want to hide that email they sent to the law firm. So they'll create an inbox rule and it may be something they're trying to hide, like a period as a rule name. So that will essentially reroute all of the email to this folder where it can remain hidden from the from the user that is compromised.
Tom DeJong:I think Troy is actually the one that created one of our best rules there for that.
Troy Wojewoda:Yeah. So so historically, what we see when threat actors create those mailbox rules, like Tom said, they create they create some kind of rule logic to do basically one of two main things. One is to send mail to a certain folder for, like, harvesting, so if they're after whatever they're after, right? Whatever their motive is, most of these are financially motivated. And then the other one is deletion rules.
Troy Wojewoda:So like Tom says, they're hiding their tracks. They set up mailbox rules essentially to when that victim environment maybe writes back saying, Hey, I've been hacked. Don't open up any of these mailboxes, emails sent from me. Well, if anything comes from that victim, the threat actor already has logic to delete the email, so the so the other, you know, users don't see that. So yeah.
Jason Blanchard:Devious. Devious. Very devious.
Deb Wigley:I have a question from LinkedIn, actually.
Tom DeJong:Go. Are
Deb Wigley:there situations where a breach is obvious and the need for speed takes precedence over detailed documentation?
Tom DeJong:Yes. And and this is something where, you know, really focusing on just the triage aspect of it, You know, it's not going to you're not going to want to fully dig into this, in this stage of it. As an investigation, yeah, I mean, I'd say if there was a ransomware attack unfolding, it's probably going to be the most important to get on the phone with whoever's being attacked, get your teammates in, and just say, hey, I'm seeing something like a ransomware unfolding in your environment. Because with the ransomware attack specifically, time is everything. So yes, in certain scenarios, if it's pretty obvious they're being compromised, I would say you don't have to take as detailed of documentation in the beginning, because you're going to want to inform whoever works in their network so they can start isolating hosts and things like that.
Tom DeJong:So yes, I would say there's times that it is important to just get in contact and maybe breeze through documentation Yeah. Being perfect.
Deb Wigley:Yeah. Try and answer.
Jason Blanchard:Question here. What is sending you these alerts? Are they coming from multiple sources? Where are you triaging these alerts? Like, is there a ticket system, a SIM, miscellaneous dashboard?
Jason Blanchard:Where's the alerts coming from, Tom? Where are the alerts coming from?
Deb Wigley:Inside the house.
Tom DeJong:Deb, you stole it right out of my mouth.
Deb Wigley:Oh, dang it. Sorry.
Tom DeJong:Great minds. Oh, yeah. So, I mean, alerts can come from a lot of different places. It could be your EDR. It could be your firewall.
Tom DeJong:It could be, you know, you know, and and then, you know, these alerts may go to something like a SIM, which then the SIM would maybe go to a ticketing system. So so generally, I'd imagine the alerts are going to go to the SIM and then open up a ticket, and that's where you'll kind of be doing the cursory triage and the investigation. So but, you know, they they come from all all sorts of log sources.
Jason Blanchard:Do they does it ever come from the end user going, I think something's weird here? Mhmm.
Tom DeJong:Yeah. Of course. Yep. Yep. I think I think that that would probably be kinda bad if you didn't have that.
Tom DeJong:Mhmm. I feel like users being able to raise, tickets with with the SOC and everything is, probably pretty crucial.
Jason Blanchard:Yeah. Alright. Deb, do you have another one, or do you want me?
Deb Wigley:I do not at this time.
Jason Blanchard:Okay. Would you escalate an alert where the IP is flagged as malicious by one third to two third enrichment tools like Recorded Future, Virus Total, or Whozis?
Tom DeJong:I guess. IPs can be hard because, yeah, that one depends. It can be hard because sometimes the IPs will have, like, negative reputation on VirusTotal, but, you know, the IP has moved around. It's I don't know. It would depend on my situation and what the additional context is, but potentially, that's definitely that's definitely something that would feed into my decision on whether to escalate or not.
Jason Blanchard:Alright. So I'm gonna take a break here for a second. There's 300 of you still watching. Thank you so much for being here. Troy, you just released a blog.
Jason Blanchard:The blog just went out. The blog's on Discord. We're gonna put a link to the blog here on, we we we haven't really done something like this before. Like, the plan is to do something like this. Normally, we just say, hey.
Jason Blanchard:Here's here's things that we know. Here's procedures. Here's methodology. Here's tactics. Here's tools.
Jason Blanchard:We'll write blogs on those. We'll put that out so the community can read it. But this is special. Troy, tell me why it's special, and I'll put the link into Zoom chat.
Troy Wojewoda:Yeah. This is this is special for a number of reasons, but I think one of the primary ones is that the threat at the the threat intelligence that are that's in this blog is pretty hot right now, meaning that the the IP addresses and domains that are referenced in this are have have been being utilized by the threat actor for over a year. And still from a reputational perspective, like Tom was talking about things having bad reputation, there's very little bad reputation associated with this. So there's not a lot up until right now, there hasn't been a lot of OSINT or, you know, open source intelligence around this activity. Not only from the domains and IPs perspective, but really the technique that's detailed in this blog is something specific.
Troy Wojewoda:There's not like technically a MITRE technique right now that I mean, there's some gray area with that. You'll read this blog and hopefully, you know, might to go through it a couple times, but technique being leveraged by the threat actor, specifically leveraging a COM handler to get code execution to work, is not a new thing, but the way that the threat actor kind of was going about registering this COM object and utilizing it is somewhat of a new technique. So we have some blogs actually, I don't know if it was last year, it was last year into this year, where some of the pen testing folks were sharing information of how they hijack some of the DLLs with these comm handler actions. This is a little bit different where the threat actor was not necessarily hijacking the comm objects, but creating comm handler actions and using scheduled tasks that are native to the Windows operating system. So pretty stealthy.
Troy Wojewoda:Work kind of came out of an engagement known as a breach assessment service, something we don't advertise that much, but we're planning to you'll see more of this next year in 2026. So the breach assessment services was essentially mirrored or modeled after how we do IR, right? But instead of waiting for something to pop or alert, we actually go proactively like hunt. Just like we threat hunt in the SOC, we do these for other customers too. They're wishing, maybe there's a merger and acquisition going on, right?
Troy Wojewoda:And they're like, hey, we just, you know, we wanna test to make sure that they're not vulnerable or have these weaknesses, but we're really concerned that there may be threat actor activity in this environment. So that's where there's no smoking gun. There's no, you know, indicators that there's malicious activity, but we go in there with these assessments and we essentially look for indicators of compromise, TTPs that we commonly run into when we do incident response engagements. And in this case, we found this activity in the customer environment for at least seven months undetected. Customer had two state of the art EDRs.
Troy Wojewoda:Nothing nothing triggered in there. So so pretty hot threat intelligence, and we're pretty excited to at least share this out to the world. Hopefully, your environment doesn't have this activity going on, but, you know, take this information and and and, you know, reassure yourselves and your organizations based off of that.
Jason Blanchard:Detroit, John taught me a long time ago when I was, like, getting when I started doing backdoors and breaches, tabletops and stuff, he's like, sometimes you find an incident by looking for an incident. Is that what breach assessment is? Like, looking for an incident by looking for an finding an incident by looking for an incident.
Troy Wojewoda:Finding an incident by basically looking for essentially TTPs. Right? The the the the Tom kind of brought up mailbox rules. Right? So mailbox rules are a very common TTP that threat actors do when they gain access to a three sixty five environment.
Troy Wojewoda:It's one of the common dance moves that we see when they get these business email compromises. They set up mailbox rules for various reasons, right? The way they set those up kind of sticks out in a way, because they deviate from a behavioral perspective, especially if you're baselining like, okay, Jason has created mailbox rules before in the tenant, but they make sense, But then all of a sudden there's this weird mailbox rule that just says dot dot dot dot dot or something like that, it's like why would a human make a mailbox rule with that name? Mhmm. In fact, Tom kind of alluded to it, like when he was like, because we create a rule back in the day, it was like, where did something like that happened?
Troy Wojewoda:And that's because in March, especially in the browser context of March, you can't leave the rule name blank. You gotta put something in there. So you gotta imagine a threat actor gains access. They wanna make a mailbox rule, but they don't know what to put in there, so they just put, you know, a single character in there. But it's not really indicative of human behavior.
Troy Wojewoda:So not necessarily means that when we do these threat hunts that we're gonna find high fidelity, like, oh, yes. This is threat actor activity, but we look for the the, you know, the deviations from baselines. Right? So so we bring in not only the known TTPs, but we also also do the the the threat hunting, establish a baseline, looking for deviations of of of those baselines as well.
Jason Blanchard:Alright. So I'm gonna wrap up with one question for Tom. And then in case anyone wants to do business with us as us being your SOC, I'm gonna have one final question for Troy. So we're gonna wrap up here. Tom, here's the question.
Jason Blanchard:Question popped up, but I think a lot of people were wondering, how is AI impacting the work that you're doing, And how will AI impact the work that you're doing in 2026?
Tom DeJong:Oh, okay. So for SOC work, I use AI a lot to kind of help me pivot around. I'll I'll just put in something like, okay. Well, what's this command do? It can help you figure out the next thing that you need to go research.
Tom DeJong:Always trust, but always verify it. And don't be copy and pasting it into comments going to the customers. But I use it a lot for that. We're seeing it a lot. We're testing out some things for rule creation with it.
Tom DeJong:And I'll say I'm not the most savvy with AI. I'm trying to get better at using it myself and use it for more things. But there's that. I believe there was a cool webcast on AgenTik AI that was done maybe a few months ago, where it's kind of they're kind of having it start doing some SOC investigations. So I'd say those are the main ways that I'm seeing it being used right now in the SOC.
Jason Blanchard:Thanks, Tom. I feel that's a, like, a good honest answer. Like, I'm not savvy at AI. Like, same. Have knowledge of AI.
Jason Blanchard:I'm familiar with AI, but I am not proficient or an expert in AI. Mhmm. Nor is any most likely anyone on this, Zoom session right now listening or attending. Alright. Troy, last question for you.
Jason Blanchard:If someone wanted to hire us for their SOC, what do they get?
Troy Wojewoda:What do they get? So they get the stuff Tom was talking about, like the triage, the the alerting, the real time monitoring. There's also a slew of other services. So So I mentioned the threat hunting, we continuously threat hunt. When we see something based off of a threat hunt, and then we say, okay, we could turn this into a DTEC, that gets passed off to the detection engineering team, and they build DTEC's in for real time monitoring.
Troy Wojewoda:We do active directory reviews, we do tabletop exercises with our customers to make sure that we're giving them that prescriptive kind of these are the right cyber hygiene kind of things to do before, you know, incidents may occur. Right? Let me me see what else do we do. We have the general consulting built into it, so I I think, you know, when you're a SOC customer and you're like, you have a question, you can look to BHIS to say, you know, we wanna we wanna get on the the horn with somebody to talk about, you know, x y z. So there's there's there's some of that built into that.
Troy Wojewoda:Incident response retainers are built into it. I think the the the the the best part of it all is you you get a team of dedicated, passionate individuals that wanna make sure that they're doing the right due diligence for your not just your organization, but all the customers. Everybody's passionate on the team. Nobody's afraid to ask questions. And we all kind of, we do a lot of, you know, collaborative sharing and cross pollination, if you will, from the different areas within the SOC.
Troy Wojewoda:So that's the fun. That's the, you know, man, I'm I'm I'm sure I probably missed one or two little things here and there.
Jason Blanchard:Yeah. Yeah. Yeah. I think one of my favorite things about everyone that works in the SOC is that they are they have so much fun doing this, and they love doing the kind of work that they're doing. And Tom, like, when you talk about what you get to do and Troy would talk about what you get to do and Hayden talks about what he like, there's so much, like, excitement for, like, this is cool stuff.
Jason Blanchard:So if you want to work with our team so we can do all the cool stuff with you, reach out to us to contact us for them. Alright, Deb. Finish this off. It is 2025. Last thoughts.
Jason Blanchard:We're gonna wrap this up. This is the last webcast of 2025. I I I didn't count up, but I'm pretty sure it's, like, 350 this year. If you count up the news and the webcast and the workshops and the training and the everything else, it's about 350 times this year. So Yeah.
Jason Blanchard:This is the last one for the year. Deb, take us out.
Deb Wigley:Yeah. That's a lot of pressure. But, yeah, I guess you've seen our faces 350 times, some of them. Thank you again. We just always thank you for spending your time with us.
Deb Wigley:There's I always say there's so much noise, especially this year. It's been it's been a year. It's a lot of good things, but it's also been challenging for a lot of people. So, we're just so grateful that you hang out with us and that you learn from us and, and you trust us. So we'll see
Tom DeJong:you next year. I love you guys.
Tom DeJong:Alright.
Tom DeJong:That's it.
Jason Blanchard:And with that, Ryan, for the last time this year, kill it with fire, sir. Kill it, Ryan. Serial kill it, Ryan. Serial kill it.
Deb Wigley:Have one job.
Jason Blanchard:Kill it.