Fortinet FortiPAM Secret Events
Secret-request and clear-text-view logs of one Fortinet FortiPAM appliance, for testing privileged-access analytics. Records are ECS JSON with the native FortiPAM key-value message kept byte-for-byte in event.original and parsed under fortinet.fortipam.* with its native key names. Sixty users in seven roles work with 43 secrets in seven folders, about 2,200 records a day on a UTC working-day curve. Recurring episodes show clear-text password harvesting after an access request.
Quick Start
uv tool install eventum-generator
git clone https://github.com/eventum-generator/content-packs.git
cd content-packs
eventum generate \
--path generators/identity-fortinet-fortipam/generator.yml \
--id fortipam \
--live-mode trueEvent Types
| Event ID | Description | Frequency | Category |
|---|---|---|---|
| 2303064603 | clear-text-view: clear text view allowed | 90.4% of records | iam |
| 2304064604 | request: secret request created | 9.6% of records | iam |
Realism Features
- Each user opens sessions at random, weighted per user: most sessions view one to five secret passwords in clear text, sometimes opening the previous one again; about one in five starts with a request for an approval-gated secret, usually followed by a view of it after approval and sometimes by more views or a second request. A user's secrets come from the role's folders, weighted by folder and by the secret's popularity.
- About 2,200 records a day: 15 an hour at 00:00-07:00 and 21:00-24:00 UTC, 81 at 07:00-08:00 and 18:00-21:00, 173 at 08:00-18:00, with about 3% variation from day to day. Users are present in proportion to this curve, and night records come from the same users (on-call work). The busiest users log about 80 records a day, the quietest about 16.
- A user's consecutive records are a median of about 4 minutes apart (10% within 40 seconds), never a sub-second burst: seconds to minutes apart in office hours and several minutes apart at night. A view of a requested secret follows its request after a median of about 9 minutes (10% within 2 minutes); 78% of requests are followed by such a view.
- Requests, a request followed by a view of the same secret, sessions of several distinct views, re-views and second requests all occur in ordinary work of both modes, and each episode user requests each possible first secret about twice a day or more and opens each of the other episode secrets at least three times a day. In ordinary work, a user who views a requested secret views at most four other distinct secrets within 30 minutes of the request; the same sequence spread over 30-60 minutes occurs about 20 times a day.
- Episodes happen only between 07:00 and 19:30 UTC and only for six busy users, with secrets those users request and open often; with an interval that is not a multiple of 24 h, episodes due at night move to 07:00-08:00, so some gaps exceed the interval. Each episode adds its own records, so counts of the chain parts are about one per episode higher with anomaly_mode true. From an episode's request until 30 minutes after it, the user has no records other than the episode's; the last episode view comes 1-7 minutes before the end of that time. A match does not prove misuse: the documented logs carry no approval decision, source address or view reason.
- Only the two log IDs with published raw lines are modeled: secret request created (FortiSIEM FortiPAM sample) and clear text view allowed (FortiPAM 1.7.0). Request approval and denial, launches, check-in/out and password changes are absent. Each record keeps the key set and order of its source example, so clear-text views carry no devname/devid, and no syslog envelope is emitted.
- uuid is assumed to be the secret object UUID, stable per secret; starttime is the request minute and expirytime a preset duration of 30 min to 8 h; agent is always GUI and the time zone is UTC. Volumes, shares, session shapes and the hour curve are synthetic choices, not measured production frequencies, and the curve repeats every day with no weekday cycle. Secret, account and address names are fictional, on RFC 1918 addresses. No Elastic integration exists, so the ECS projection is inferred.
Sample Output
{
"@timestamp": "2026-09-01T16:03:57.422325Z",
"ecs": {
"version": "8.17.0"
},
"event": {
"action": "request",
"category": [
"iam"
],
"code": "2304064604",
"dataset": "fortinet.fortipam",
"kind": "event",
"module": "fortinet",
"original": "date=2026-09-01 time=16:03:57 devname=\"FPAVULTM1234567\" devid=\"FPAVULTM1234567\" eventtime=1788278637422325394 tz=\"+0000\" logid=\"2304064604\" type=\"secret\" subtype=\"secret-request\" eventtype=\"secret-request\" action=\"pass\" operation=\"request\" secretid=777 secret=\"aws-prod-root\" account=\"root\" uuid=\"d45fdd32-a650-594a-9758-3f8f1f70a449\" user=\"s.lewis\" starttime=\"2026-09-01 16:03:00\" expirytime=\"2026-09-01 16:33:00\" msg=\"Created secret request.\"",
"outcome": "success",
"type": [
"creation"
]
},
"fortinet": {
"fortipam": {
"account": "root",
"action": "pass",
"eventtime": 1788278637422325394,
"eventtype": "secret-request",
"expirytime": "2026-09-01 16:33:00",
"logid": "2304064604",
"msg": "Created secret request.",
"operation": "request",
"secret": "aws-prod-root",
"secretid": 777,
"starttime": "2026-09-01 16:03:00",
"subtype": "secret-request",
"type": "secret",
"tz": "+0000",
"user": "s.lewis",
"uuid": "d45fdd32-a650-594a-9758-3f8f1f70a449"
}
},
"observer": {
"hostname": "FPAVULTM1234567",
"product": "FortiPAM",
"serial_number": "FPAVULTM1234567",
"vendor": "Fortinet"
},
"related": {
"user": [
"s.lewis"
]
},
"user": {
"name": "s.lewis"
}
}Parameters
| Parameter | Default | Description |
|---|---|---|
| anomaly_mode | true | Add harvesting episodes to the background; false emits background only |
| anomaly_interval_hours | 24 | Hours between episodes by source time, 2 to 8,760 |
| device_name | FPAVULTM1234567 | Appliance name, written to devname/devid and observer.* |
Related Generators
Keycloak 26.7.4 Event Log
Keycloak 26.7.4 jboss-logging user and admin event lines for one realm with 1,500 users and 5 administrators, as native text in event.original with keycloak.*, user.*, source.* and url.* fields following the Elastic keycloak.log pipeline. Recurring episodes show one administrator failing five to eight logins from a VPN egress address, then logging in to the admin console and granting a privileged realm role.
Active Directory audit
About 21,800 normalized Security records per day from a small domain, with Kerberos, NTLM and temporary group membership.
ALD Pro domain controller
About 61,200 selected records/day from one domain controller, including native KDC, LDAP access and audit records.