As a Venyu customer using FortiEDR to protect your endpoints, you will begin receiving communication emails like this that provide tips or reminders for adjustments that can be made to improve your security. These can be a bit lengthy, but the information being communicated is valuable. This series of emails will be sent at least quarterly, but feel free to reach out at any point via a support case if you have questions regarding a best practice or something about which you’re unsure. In the first installment of this series, we’ll provide some guidance regarding exceptions. Exception writing and triaging events are probably the two most common types of question that we receive, so we wanted to start off by providing a few useful tips.
Limiting Exceptions
When writing exceptions, they should be limited to the collector groups, destinations, and users that need to use the processes that triggered the event. If there is a process that only needs to run from your domain admins or developers to certain internal IPs, limit the exception to the collector group where only those users reside and a destination using an IP set created for those IPs. Unless it’s a process that needs to communicate across the entire environment, try to avoid allowing it to all groups. A lot of exception writing boils down to reducing risk – If you use “all destinations” for your exception, it exposes you to more risk than if you limit it to “Internal Destinations” or even better, a meaningful IP set that you created. Reminder: IP sets can be created under Administration > IP Sets.
You should also always use the dependencies aka “When created by” part under “Triggered Rules” portion of an Event Exception. Note: All Windows collectors need to be running at least 5.0 to use dependencies and to select a username for the “Users” field. The screenshot below shows an example of an event exception using a dependency. You’ll also notice in the screenshot that the exceptions are limited to the current path. Using current path is a must when dealing with unsigned exe’s and dll’s, but it’s also best to use the current path if something should always be running from that path (i.e. – svhost.exe should always run from \Windows\System32). Please do not ever write a blanket exception with no dependencies or specific users for any of the known Windows dll’s and exe’s (especially Powershell). Sometimes users may assume that it’s okay to all because it’s part of the Windows OS, but malware authors commonly misuse Windows dll’s and exe’s to carry out attacks. Threat actors will also sometimes gain a foothold by exploiting a vulnerability and can carry out attacks by using Powershell, without any malware being present. Writing blanket exceptions with no dependencies for Windows dll’s and exe’s exposes your organization to a significant amount of risk.
Effective Event Triage
Events
Each time that you begin analyzing an event, you should be doing a mini risk assessment on what you’re seeing. We will take the following event (screenshot below) as an example.
- What classification has Fortinet given this event? Fortinet Cloud Services will reevaluate events as time goes on and sometimes will change the classification, but if you see something classified as malicious, the level of risk is increased.
- Is the process something that you recognize? If yes, that’s something that should ease your mind a bit. If not, you’ll want to be more critical as you continue evaluating.
- Is the process signed by a known signer? You can see whether a process is signed from the event viewer and can look up the signature information in VirusTotal via the Forensics tab. If it’s not signed, that should further your suspicion.
- Was the process blocked or allowed? If you have moved your collector groups into security policies that are in prevention mode, most rules should already be set to block (a couple are set to log, which we’ll cover in the next installment in our series of tips). A process being blocked should also help put your mind at ease, knowing that FortiEDR did its job.
- How many events across how many devices and raw data items (i.e. – total scope) are you seeing? If it’s a piece of known software that you know is deployed throughout the organization, seeing an event impact many devices should make sense. If it’s a process that you don’t know that is seen across multiple devices, that should make the risk go up.
- Is the process path something that makes sense or is it launching from a Temp directory? Known processes will launch from specific paths (i.e. – netsh.exe will launch from \Windows\SysWOW64\netsh.exe). Seeing something launch from a temp directory or an odd file path should increase your level of suspicion.
- What time was the process originally received and has it continued to happen? If you notice that the process was received on a user machine in the middle of the night when the user was asleep, this should increase your level of suspicion.
If we take the example in the screenshot below, we see that it’s classified as “inconclusive,” which is a mid-range classification. Teams.exe is a known program that is deployed in the environment, and it shows a signed certificate. It was blocked, so happens to be malicious, I’m relieved. The process path looks normal for Teams, and it happened during normal work hours. From looking at this, we feel pretty confident that this is a false positive, but it’s always best to next look at the triggered rules and the event graph (under “Advanced Data”) before writing your exception. These will be covered in the next two sections.
Triggered Rules
FortiEDR determines whether processes pose a threat by checking to see if the process call to the OS kernel violates a rule in the security policies. All rule violations pose some level of risk, but there are some that are much more prevalent with malware. If you have a bunch of events that you’re trying to analyze, you’ll probably want to prioritize those in some way. Outside of sorting the classification (and starting with malicious first), another way to prioritize is based upon triggered rules. You can search triggered rules, by using the advanced search field. You can access this by clicking on the down arrow next to the magnifying glass in the “Search Event” field of the Event Viewer. Once there you’ll see several different searchable areas (one of which is Rules – shown below). Three rules to prioritize will be Process Injection, Unmapped Executable, and Injected Thread. If you have events that match these, it’s not 100% confirmed that the event is malicious, but it certainly something that warrants additional scrutiny.
Event Graph
If we continue using the Teams event as an example and navigate to the “Advanced Data” section of the Event Viewer, we’ll see an Event Graph. We’ve zoomed in to make it readable and only show where the event was seen. The first part of this Event Graph is the standard Windows process chain for a user logon. In a future tip email, we’ll cover standard Windows process chains. Knowing this was part of the user logon process and knowing that Teams launches during start up for our machines helps us to piece together that Update.exe (in the file path of Teams – you can find this in the Stack View within Forensics) was causing Teams to write a json file to its own application data directory (path for the json file can be seen in Forensics as well). This behavior of Teams is known to be safe (so you can safely create an exception for this in your environment if you’re running teams, using the exception writing tips I listed previously).
Please submit a support case via https://myaccount.eatel.com if you have any questions about the tips above or anything else relating to FortiEDR,
