Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EDR Addition - FortiEDR #84

Merged
merged 7 commits into from
Dec 13, 2024
Merged

EDR Addition - FortiEDR #84

merged 7 commits into from
Dec 13, 2024

Conversation

SecurityAura
Copy link
Contributor

@SecurityAura SecurityAura commented Nov 17, 2024

Description

Please provide the below information so we can validate before merging:

  1. Does the proposed EDR feature align with our definition of telemetry?(definition here)
  2. Could you please provide documentation to support the telemetry you are proposing?(If it is held privately, please reach out to me or @inodee)
  3. If no documentation is available for all the categories you are proposing, could you provide screenshots or sanitized logs?

1: Yes it does.
2: Documentation and screenshots will be provided to Kostas directly.
3: It does not look like Fortinet exposes the event schema(s) of the telemetry that is collected through their product.

Type of change

Please delete options that are not relevant.

  • [X ] New feature (adding additional EDR product or proposing new event categories/sub-categories)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.

  • FortiEDR was installed on a Windows 11 VM on ProxMox
  • VM was left open for a few hours (even few days) so that telemetry could be passively collected
  • For each telemetry category (e.g.: Process, Network, File, Registry, etc.) the available "type" of events (e.g.: Process Creation) were queried for matching events
  • Event types that returned results were marked as "Yes" in the JSON. Event types that did not return any results were left alone for further testing
  • For event types that did not return any results, the telemetry-generator.ps1 tool was ran to generate matching telemetry.
  • New searches were executed for the event types that did not return any results before, to see if they did. If they did, they were marked as "Yes" in the JSON. If they didn't, they were marked as "No"
  • Multiple sub-categories were marked as "Partially" for reasons that will be detailed below
  • Any FortiEDR event type matching an edr-telemetry sub-activity that is NOT enabled in the "Standard Collection Profile" of FortiEDR was marked as "Via EnableTelemetry"

Test Configuration:

  • EDR version: FortiEDR v5.2.2.577 (which is the latest available in the console I'm using, as of submitting this PR)
  • Operating System version: Windows 11 23H2

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my corrections or additions are accurate
  • I have checked my code and corrected any misspellings

Additional Information

FortiEDR can be seen as some kind of dual EDR/SIEM agent. The main reason being that, in the Collection profile which defines what telemetry (event types) is captured by the agent, there is the option to enable a "Event Log Entry Created" type.

As far as I can see, this basically enable SIEM collection on the agent, with a LOT of Windows Event Logs being created. For instance:

  • Authentication Events
  • User Account Events (created, disabled, modified)
  • PowerShell ScriptBlock Logging
  • BITSClient
  • Etc

All events that "matches" the edr-telemetry project sub-categories. However, the caveat here is that the FortiEDR agent just collects too much from that setting alone. Which means that it most likely collect Event IDs that are ENABLED at the Windows level and it does not enable them itself.

Therefore, in order to actually collect these events, the "Event Log Entry Created" type needs to be enabled in the Collection profile AND the target Event ID(s) must be configured on Windows. This would be true for the following sub-category:

  • User Account Activity - Local Account Creation
  • User Account Activity - Local Account Modification
  • User Account Activity - Local Account Deletion
  • User Account Activity - Account Login
  • User Account Activity - Account Logoff
  • Schedule Task Activity - Scheduled Task Creation
  • Schedule Task Activity - Scheduled Task Modification
  • Schedule Task Activity - Scheduled Task Deletion
  • Service Activity - Service Creation
  • Device Operations - Virtual Disk Mount
  • Device Operations - USB Device Unmount
  • Device Operations - USB Device Mount
  • Other Relevant Events - Group Policy Modification
  • WMI Activity - WmiEventConsumerToFilter
  • WMI Activity - WmiEventCOnsumer
  • WMI Activity - WmiEventFilter
  • BIT JOBS Activity - BIT JOBS Activity
  • PowerShell Activity - Script-Block Activity

Since all these sub-categories can be covered by known/existing Event IDs in Windows. Therefore, the "Partially" reason could be something like:

Obtained through Event Logs by enabling their collection in FortiEDR's Collection profile

2024/11/16 - Initial version of this PR. May go through some modifications following discussion and/or comments and suggestions!

@tsale
Copy link
Owner

tsale commented Dec 13, 2024

Thank you for the PR @SecurityAura!

-- For transparency, evidence provided via direct communication for each event --

I've made some adjustments to the previously marked events as "Partially" — they have now been updated to "Via EventLogs". This change reflects that these events can be collected through Windows Event Logs if enabled at the system level, but the EDR does not independently collect them via ETW.

To clarify:

  • Via EventLogs: Events collected from Windows Event Logs if they exist and are enabled at the system level. This does not mean the EDR enables or collects them directly through ETW.
  • Via EnablingTelemetry: Refers to additional telemetry enabled within the EDR product but is not active by default.

These changes ensure clearer differentiation between partial implementations and event collection methods. I will go ahead and merge this PR now!

@tsale tsale merged commit 0691a0e into tsale:main Dec 13, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants