iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
FortiGate logs can help you investigate suspicious VPN logins, unexpected administrator access, configuration changes, and some security or integrity alerts. Start at Log & Report > System Events > VPN Events, if VPN events are available in your FortiOS configuration. Then check system and security logs and correlate the findings with identity-provider, domain-controller, and endpoint evidence. A FortiGate log by itself cannot prove that malware has established persistence on a workstation or server.
What should you check first?
Before searching, confirm that the relevant logs exist for the period you are investigating. Find out whether the FortiGate stores logs locally, forwards them to a central system such as FortiAnalyzer, or sends them to a syslog destination; also check the available retention period. Fortinet documents the available log-viewing functions and logging options in its event-log guide and logging and reporting guidance.
Missing search results do not establish that no login or malware-related activity occurred. Logging might not have been enabled, the relevant category might not have been collected, or the records may have expired or been stored somewhere other than the device you are checking. Record the time range, log destination, and retention available before drawing conclusions.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Menu names and event availability can vary by FortiOS release and configuration. If you cannot find VPN Events, check whether VPN is enabled under System > Feature Visibility, and consult the documentation for the FortiOS release deployed on the device. Fortinet’s FortiOS 7.6.0 Log & Report guide describes that release’s menu and log features.
Popular on Amazon
Before setting a time filter, establish the suspected incident window from the alert, user report, or related system event. Search a period broad enough to include activity before and after the suspected login, then narrow the results if needed. Record the time zone used by each source; identity and endpoint records may display time differently from the FortiGate. A timeline is much easier to compare when each timestamp is retained with its original source and time zone.
Also note what the logging setup can actually answer. A local view may show only records still retained on that device, while centralized collection may provide a longer history or records from multiple FortiGate devices. Neither approach is useful for a category or period that was never collected. If the initial search is empty, verify the device, category, time range, destination, and retention before treating the absence as a finding.
How do you find suspicious VPN logins?
- Open VPN event logs. In the FortiGate interface, go to Log & Report > System Events > VPN Events, if the feature is available. Set the time range to cover the suspected activity and enough surrounding time to see what happened before and after it.
- Filter on known identifiers. Search for the relevant username, remote IP address, and time interval. If you are investigating a particular user, examine both failed attempts and successful sessions rather than looking only for a successful login.
- Interpret the event sequence. Fortinet documents
ssl-new-conas an initial SSL VPN connection action andtunnel-upas a successful connection action. A successful FortiClient connection may generate twotunnel-uprecords: one withtunneltype="ssl-web"and another withtunneltype="ssl-tunnel", which includes the tunnel IP and FortiClient UID. Do not assume that two records automatically mean two separate logins; inspect their fields and context. - Compare the session details. Useful fields in Fortinet’s example include
user,remip,group,tunnelid,tunneltype,tunnelip, andfctuid. Compare the username and group with what the person should be authorized to use, and compare the remote IP and timestamp with expected user, device, and access patterns. - Look for a sequence, not just a single event. Repeated failures followed by a success, access from an unrecognized source, an unexpected account or group, or a successful session followed by other unusual activity are useful leads. Validate them against approved changes, travel or work context, and other system records; none is proof of compromise on its own.
Fortinet’s SSL VPN event-log technical tip shows the connection actions and fields. It was posted in 2024 and updated on its page in 2026; event details can differ by release, so check the records on the deployed system rather than treating an example as a universal schema.
How to read a VPN event in context
Read the event fields together rather than deciding from a single value. The user identifies the account recorded for the event; remip is the remote address shown in Fortinet’s example; and group helps you compare the session with the access the user is expected to have. The tunnel identifier, type, and IP add detail about the connection. The FortiClient UID can help distinguish the client represented by the record. These fields help frame questions; they do not independently verify the identity of the person operating the device.
For example, an unfamiliar remote IP merits a check against the user’s expected location and device context, but it is not automatically malicious. A user may be traveling or using an approved network. Conversely, a familiar account name does not prove a session was legitimate: the account may have been misused. Check whether the group is appropriate, whether the timing fits the user’s work or an approved change, and whether related identity or endpoint records support the same explanation.
Repeated failures followed by a success are worth reviewing as a sequence. Compare their times, usernames, and source addresses, then see whether activity continued after the successful session. Likewise, one event appearing as two tunnel-up records can reflect the different tunnel details in Fortinet’s example rather than two independent connections. Use the session identifiers and tunnel fields available in your version to make that distinction; do not infer more than the records show.
Also popular on Amazon
What else should you inspect on the FortiGate?
VPN events show session activity, but an investigation should also review system and security records for changes or alerts that could explain how access was obtained or what happened next.
- Administrator access: Look for unexpected administrator logins, especially from unknown source IP addresses. Check the account and timing against authorized administration and change windows.
- Accounts and permissions: Look for unfamiliar or unrecognized accounts and unexpected use of privileged access. If compromise is suspected, validate the firewall and VPN users rather than relying only on the account that raised the initial alert.
- Configuration changes: Identify changes that were not approved, and compare the current configuration and change history with an approved baseline or known-good configuration. Investigate suspicious changes to firewall or VPN settings in context.
- Security events: Review relevant antivirus, web-filtering, file-filtering, application-control, intrusion-prevention, and other security records available in the configured log set. FortiAnalyzer’s FortiGate log-category documentation describes types of security and other logs collected for a device.
- Integrity alerts: Check for file-system integrity warnings. FortiOS real-time file system integrity checking can report an executable integrity mismatch, but the feature and its behavior depend on release and configuration. See Fortinet’s integrity-checking documentation.
An alert or suspicious event needs validation: it may identify an investigative lead, but it does not by itself establish what happened on an endpoint or who caused it. Preserve relevant records and compare configuration changes with a known-good state. Fortinet’s guidance on reported FortiGate credential compromise also emphasizes validating firewall and VPN users and configuration, with attention to accounts that are not recognized.
For administrator events, compare the recorded account, source address, and time with the people and processes authorized to manage the device. An unknown source is a reason to investigate, not conclusive proof of an attacker. For configuration activity, determine whether a corresponding approved change exists and whether the current settings match a known-good configuration. Keep the change record and relevant event together so the conclusion can be reviewed later.
Security logs have a different role from connection and system events. Antivirus, web filtering, file filtering, application control, and intrusion prevention records can show security-product activity that may help explain a suspicious network event. Which records are present depends on the logging setup and the categories collected. An absence of a malware detection in these logs does not establish that a host is clean, and an alert does not replace endpoint investigation.
Can FortiGate logs prove malware persistence?
No. FortiGate logs can show network, authentication, configuration, and security-product activity, and a specific integrity feature can alert to an executable mismatch. They are not a complete forensic record of a workstation or server, so they cannot alone prove that malware established persistence on that host.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
After identifying a suspicious VPN session or firewall event, investigate the affected endpoint with appropriate endpoint-detection and forensic evidence. Look for host-level persistence activity there, and correlate the host’s timeline with the VPN session and the account used. Also review identity-provider or domain-controller logs for unusual account use and possible lateral movement. Fortinet’s June 2026 guidance recommends checking for unexpected administrator access from unknown IPs, suspicious accounts, unauthorized configuration changes, and lateral movement in domain-controller logs.
Also popular on Amazon
Valid credentials can be part of a persistence or access problem even when there is no conspicuous malware artifact on the firewall. FortiGuard Incident Response reported that, in its 2024 investigations, new account creation appeared in approximately 25% of cases and Windows service creation in 22.5% of cases. These figures describe FortiGuard IR’s cases, not all incidents. Its 2023 report said Valid Accounts (T1078) appeared in over 56% of investigations in which a persistence technique was observed; that percentage has the same limited scope and should not be generalized to all organizations. See the 2024 report and 2023 report.
These numbers explain why an investigation should not look only for a malware alert on the firewall. In FortiGuard IR’s 2024 cases, new account creation was reported in approximately one quarter of cases, and Windows service creation was the most commonly observed legacy persistence method, at 22.5%. The 2023 finding on Valid Accounts likewise concerns FortiGuard investigations where persistence was observed. Those observations are useful context for checking accounts, identity records, and host evidence, but they are not predictions of what is happening in a particular network.
The central distinction is where each log is generated. FortiGate records can help establish that a VPN session, administrator access, configuration action, or security event was recorded. Endpoint telemetry and forensic evidence are needed to investigate persistence on the host itself. Identity-provider and domain-controller records can help determine how an account was used and whether activity spread to other systems. A defensible conclusion about malware persistence needs the host and identity evidence, not just a suspicious firewall login.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How should you correlate the evidence?
Build a timeline that connects the VPN session to administrator, identity, configuration, and endpoint events. For each suspicious session, note the timestamp and time zone, username, remote IP, group, tunnel details, and the source log. Then compare those details with identity-provider or domain-controller records and the endpoint’s alert or forensic timeline. Record whether an access or configuration change matches an approved change or known user context.
Keep the distinction between evidence and inference clear. For example, a successful session from an unfamiliar IP establishes that a session was recorded with that source address; it does not, on its own, establish whether the user was an attacker, whether the account was stolen, or whether malware persisted on a host. A suspicious event becomes more meaningful when related records support the same sequence.
When comparing records, preserve the original event details and note the system that produced each entry. Start with the VPN event’s time, username, remote IP, and group; then look for matching or nearby identity and endpoint activity. If an account appears in several systems, compare the timestamps and context instead of assuming that similarly named records refer to the same action. If a source uses a different time zone or timestamp format, document the difference rather than silently shifting the event.
Also popular on Amazon
Use the timeline to test explanations as well as to find suspicious activity. An approved administration window, a known travel pattern, or a documented configuration change may account for an event; record the evidence that supports that explanation. If the explanation does not fit the recorded user, group, source, or timing, keep the event unresolved and continue validating it against other systems. The goal is not to label an unfamiliar value as malicious but to determine which account and systems were involved and what the records actually support.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsShould logs be local or centralized?
Local FortiGate logs are useful when they are available and cover the incident period. Centralized collection can make it easier to search across devices and retain records beyond the firewall’s local retention. FortiAnalyzer can collect and analyze FortiGate logs; a syslog destination can store messages for an external analysis system. The right choice depends on retention, search and correlation needs, device coverage, and whether records remain accessible if the FortiGate itself is compromised.
Neither a central destination nor local storage guarantees that the relevant records exist: verify collection and retention for the event categories and time window under review. For an investigation, preserve the pertinent records and note their source so later comparisons do not rely on memory or a single interface view.
The practical tradeoff is between where the records live and what you need to do with them. Local review is a direct way to examine records on an individual FortiGate, provided the device still has the right logs. FortiAnalyzer offers central collection and analysis, which can help when correlating activity across devices. Syslog forwarding can send messages to an external analysis system. Compare the options by the retention available, how easily you can search and correlate records, how many devices are covered, and whether the records remain accessible if the firewall itself is affected.
FortiAnalyzer is an optional operational tool, not a prerequisite for investigating a FortiGate. If your organization already uses a syslog destination or another central system, verify that the relevant records are being sent and retained there. Whatever the destination, the key question is whether the needed event categories for the incident window are available. If they are not, document that limitation rather than treating the missing record as proof that an event did not occur.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhat should you do if you find a suspicious event?
- Preserve relevant logs. Save the VPN, system, security, identity, and endpoint records available for the relevant window, with their timestamps and source systems.
- Validate the account and access. Check whether the user, group, source, time, and device context are expected, and whether an approved change or known travel/work pattern explains the activity.
- Review the firewall configuration. Compare accounts and configuration changes with authorized records and a known-good baseline. Investigate unknown accounts and unauthorized changes.
- Investigate connected systems. Check identity-provider or domain-controller activity for unusual use and lateral movement, and inspect potentially affected endpoints for host-level persistence evidence.
- Escalate confirmed or unresolved compromise. If the evidence indicates a compromise or cannot be safely resolved internally, use your organization’s incident-response process and qualified incident-response support. Keep the firewall, identity, and endpoint findings together so the investigation can reconstruct the sequence.
The key is to treat a FortiGate alert or unfamiliar VPN session as a lead, not a verdict. Establish what logging was available, inspect the full session and surrounding events, and use identity and endpoint evidence to determine whether access was unauthorized and whether persistence occurred.
Also popular on Amazon
Keep an investigation record of what was searched, which destinations and time ranges were available, and which findings remain uncertain. This is especially important when retention is limited or log coverage is incomplete: a later reviewer should be able to distinguish a clean result from a search that could not cover the relevant period. If the evidence points to a confirmed compromise, FortiGuard Incident Response may be relevant for qualified forensic support; organizations can also use their established incident-response provider and procedures.
Frequently Asked Questions
What does ssl-new-con mean in a FortiGate VPN log?
Fortinet’s SSL VPN example uses ssl-new-con for an initial SSL VPN connection action. Interpret it alongside later events and the other fields in the record; the action alone does not establish that a complete VPN tunnel was successfully set up.
Why might one FortiClient connection appear as two tunnel-up records?
Fortinet documents that a successful FortiClient connection may produce one record for ssl-web and another for ssl-tunnel. The latter includes tunnel IP and FortiClient UID details, so inspect tunnel type and identifiers before counting records as separate sessions.
Recommended Free Tools
Does an empty VPN Events search mean nobody logged in?
Not necessarily. The records may not have been enabled, retained for the selected period, or stored on the device being searched; VPN event availability also depends on feature visibility and FortiOS configuration. Confirm the logging destination and retention before treating an empty result as evidence.
What does a FortiGate executable integrity alert tell me?
FortiOS real-time file system integrity checking can alert to an executable integrity mismatch, when the feature is supported and configured. It is a reason to investigate the device and related evidence, not a complete explanation of what changed or proof of endpoint malware persistence.
Which fields should I compare when reviewing an SSL VPN event?
Fortinet’s example includes user, remip, group, tunnelid, tunneltype, tunnelip, and fctuid. Compare the recorded account, source, group, time, and tunnel context with expected access and related identity or endpoint records.
The Bottom Line
Start with VPN Events, then inspect administrator, account, configuration, security, and integrity records. Confirm logging coverage and retention, validate unfamiliar sessions against user and change context, and correlate firewall evidence with identity and endpoint records. A suspicious login is a lead—not proof of malware persistence.
Free tools Windows power users keep installed
One-click scans. No signup required.
