Fortinet FortiEDR 7.0 Administrator (NSE6_EDR_AD-7.0)

The query configuration, named "CLI Command," explicitly targets Target.Process.Filename ("net.exe") and classifies it as Suspicious. When the net user command executes, it runs net.exe, which directly matches this query. In FortiEDR, a match on a query classified as suspicious typically triggers an incident.

• Option A is incorrect: The query is explicitly configured with a Suspicious classification, directly contradicting the statement that the activity is not suspicious.
• Option B is incorrect: FortiEDR's role here is to detect command-line activity, not to trigger CLI commands itself.
• Option D is incorrect: The query is a Scheduled Query set to repeat every 15 minutes. This indicates that detection and incident generation will occur during the next scheduled run, not immediately.

✅ Option A (Correct)
Reasoning: The exhibit clearly shows that the 'Executing user' for both the cmd.exe and PING.EXE processes is 'R2D2-KVM63\fortinet'. Additionally, the 'Command line' for PING.EXE is 'fortinet.com', indicating that the user 'fortinet' executed a ping command targeting 'fortinet.com'.

✅ Option C (Correct)
Reasoning: Based on the provided exhibit of the 'Threat hunting event details', there is no section or tab displaying MITRE ATT&CK details or any related information for this event. The available view only shows 'Summary' and the process chain, without any MITRE specific indicators.

❌ Why the other choices are incorrect:

• Option B is incorrect: The event details are explicitly labeled as 'Process Creation' for both cmd.exe and PING.EXE. While these processes involve files, the primary event type being reported is process creation, not a file action (like file modification, deletion, or access).
• Option D is incorrect: The exhibit does not provide any indication that the PING.EXE process was blocked. The 'Status' shown for the endpoint 'R2D2-kvm63' is 'Running', and there are no 'Blocked' or 'Prevented' flags associated with the PING.EXE process itself.

✅ Option A (Correct)
Reasoning: The history shows device R2D2-kvm63 was automatically moved between collector groups. This automated response action is orchestrated by FortiEDR playbooks, confirming playbooks are configured for such events.

✅ Option C (Correct)
Reasoning: Moving the device to a "High Security Collector Group" is a direct response to a malicious event. This action enforces heightened restrictions and containment, functionally isolating the endpoint to prevent further threat propagation.

❌ Why the other choices are incorrect:

• Option B is incorrect: The exhibit shows a malicious classification and a device movement, but no explicit confirmation of the malicious event itself being blocked.
• Option D is incorrect: An actual automated action (device movement) occurred. In simulation mode, actions are only logged as potential, not executed.

✅ Option B (Correct)Reasoning: The activity audit entries explicitly state, "Detected as Unknown malware." This indicates that FortiEDR's intelligence had not previously identified this specific malware variant or signature.✅ Option D (Correct)Reasoning: The second entry in the activity audit clearly shows "from FortinetCloudServices" with a "Classification change: Malicious," confirming FCS classified it.❌ Why the other choices are incorrect:* Option A is incorrect: The status at the top of the incident handler screen explicitly shows "Status Unhandled," meaning the incident has not been resolved.* Option C is incorrect: The incident is consistently classified as "Malicious" (bug icon at the top, and within both audit entries). There is no indication it was classified as suspicious.

✅ Option D (Correct)Reasoning:FortiEDR's Threat Hunting module enables defining and scheduling custom queries. These queries can be configured to run periodically (e.g., every 15 minutes) across all endpoints to search for specific registry modifications, directly matching the requirement.❌ Why the other choices are incorrect:* Option A is incorrect: Communication control rules manage network and process execution, not scheduled data collection or proactive querying.* Option B is incorrect: Manual queries are executed on demand. Policy overrides do not provide a scheduling mechanism for recurring queries.* Option C is incorrect: Playbook triggers react to real-time events. While they can detect changes, they do not execute scheduled, proactive data searches across endpoints.

✅ Option A (Correct)
Reasoning: The exhibit shows 'TestApplication.exe' with a 'Status' of 'Running' (indicated by the green square icon). This explicitly means the application was successfully launched and is currently active on the system.

✅ Option C (Correct)
Reasoning: The event details clearly state the 'Classification' for 'TestApplication.exe' as 'Malicious', accompanied by a red bug/worm icon. This indicates that FortiEDR (FCS) has identified the application as malicious.

❌ Why the other choices are incorrect:
 

• Option B is incorrect: The top status bar and the event details both explicitly state the event 'Status' as 'Unhandled', not 'Handled'.
• Option D is incorrect: While 'TestApplication.exe' is classified as 'Malicious', the exhibit provides insufficient information to determine if it is 'sophisticated' malware. The triggered rules (Invalid Checksum, Suspicious Packer, Writable Code) indicate malicious activity but not necessarily sophistication level.

Reference: https://docs.fortinet.com/document/fortiedr/7.0.0/administration-guide/526715/viewing-incidents-and-incident-details

The exhibit shows the ConnectivityTestAppNew.exe incident with an overall status of "Unhandled". However, the detailed events within the incident display a 'No Entry' icon under the 'Action' column, which typically signifies a blocking action. This contradiction (an assigned block action, yet an unhandled incident and unhandled individual events) is characteristic of a FortiEDR policy operating in simulation (Audit) mode. In this mode, rules trigger and log their intended actions (like blocking), but the actions are not actively enforced, thus leaving the incident in an 'Unhandled' state for administrator review. This observation best reconciles all visual cues.