This document describes Spikerz workspace SIEM alerts. These alerts are generated at the workspace level and may include signals reported by connected social media platforms. They are designed for SOC teams, IT, and security stakeholders to understand what happened, why it matters, and how to assess risk.

All event names below are the exact values delivered to your SIEM — security alerts in the type field, audit events in the action field. Use them verbatim when building searches, dashboards, and correlation rules.

1. SIEM Alert Structure

All Spikerz SIEM alerts share a consistent schema, making them easy to ingest and correlate in any SIEM.

Common fields

Field	Description
`_id`	Unique event identifier
`workspaceId`	Spikerz workspace where the event occurred
`platform`	Social platform involved (Instagram, Facebook, TikTok, etc.) or `null`
`accountId`	Internal identifier of the connected account (nullable)
`assetUsername`	Username of the social media asset (nullable)
`employeeId`	Employee identifier (for employee-related events)
`employeeUsername`	Username of the employee (for employee-related events)
`email`	User or employee email (for audit events)
`type`	Security alert type (populated for security alerts, otherwise `null`)
`category`	Security alert category (populated for security alerts, otherwise `null`)
`action`	Audit event action (populated for audit / event log entries, otherwise `null`)
`timestamp`	ISO 8601 timestamp
`sourceType`	Always `spikerz`
`metadata`	Event-specific contextual data (role, device, location, trigger, etc.)

Security alerts vs audit events

Type	Identification	Purpose
Security alert	`type` + `category` populated	High-signal security events
Audit / event log	`action` populated	Visibility, audit, correlation

2. Severity Levels

Each event below has a recommended severity. The payload itself does not carry a severity field — assign these values in your SIEM when ingesting or classifying Spikerz events, and escalate them further using the detection scenarios in section 7.

Severity	Meaning
🚨 Critical	Immediate security incident — respond now
🔴 High	Strong security signal — investigate promptly
🟠 Medium	Potential risk or loss of visibility — review
🟢 Low	Expected or routine activity — retain for audit and correlation

3. SIEM Event Examples (JSON)

Below are realistic example payloads showing how Spikerz sends events to your SIEM.

Security alert example (type + category)

Security alerts populate type and category, and leave action as null.

{
  "_id": "507f1f77bcf86cd799439011",
  "workspaceId": "workspace_123",
  "platform": "instagram",
  "accountId": "17841445325350983",
  "assetUsername": "example_account",
  "employeeId": null,
  "email": null,
  "type": "autoAccountLockoutNewLoginTriggered",
  "category": "accountSecurity",
  "action": null,
  "timestamp": "2026-04-11T12:55:29.062Z",
  "sourceType": "spikerz",
  "metadata": {
    "trigger": "suspicious_login",
    "device": "Chrome on Windows 10",
    "location": "Berlin, DE"
  }
}

Audit / event log example (action)

Audit events represent workspace activity, configuration changes, and operational actions. They populate action, and leave type and category as null.

{
  "_id": "507f1f77bcf86cd799439012",
  "workspaceId": "workspace_123",
  "platform": "instagram",
  "accountId": "17841445325350983",
  "assetUsername": "example_account",
  "employeeId": "emp_456",
  "email": "[email protected]",
  "type": null,
  "category": null,
  "action": "workspace_access_granted",
  "timestamp": "2026-04-11T13:02:10.481Z",
  "sourceType": "spikerz",
  "metadata": {
    "role": "admin",
    "grantedBy": "workspace_owner"
  }
}

4. Security Alerts (Workspace)

These are delivered as security alerts — the value below appears in the type field, with the listed category.

4.1 Account Lockout & Takeover Prevention

Category: accountSecurity

Alert name (type)	Explanation	Severity
`manualAccountLockoutActivated`	Account was manually locked by a workspace user	🚨 Critical
`autoAccountLockoutNewLoginTriggered`	Automatic lockout after a suspicious new login	🚨 Critical
`autoAccountLockout2FAChangedTriggered`	Automatic lockout after a 2FA change	🚨 Critical
`autoAccountLockoutNumberChangedTriggered`	Automatic lockout after a phone number change	🚨 Critical

Category: accountSecurity

Alert name (type)	Explanation	Severity
`newLoginDetected`	New login to the account detected	🟠 Medium
`suspiciousActivityNewLogin`	Suspicious activity — login from an unrecognized device or location	🔴 High

4.3 Account Protection (2FA, Password & Recovery Contacts)

Category: accountSecurity. Authentication, password, and recovery changes reported by connected social platforms.

Alert name (type)	Explanation	Severity
`2faAdded`	Two-factor authentication enabled	🟢 Low
`2faChange`	Two-factor authentication configuration changed	🟢 Low
`2faRemoved`	Two-factor authentication disabled	🚨 Critical
`passwordChanged`	Account password changed on the platform	🔴 High
`emailAdded`	Recovery email added	🟢 Low
`emailRemoved`	Recovery email removed	🔴 High
`emailChange`	Recovery email changed	🔴 High
`phoneNumberAdded`	Recovery phone number added	🟢 Low
`phoneNumberRemoved`	Recovery phone number removed	🔴 High
`phoneNumberChange`	Recovery phone number changed	🔴 High

4.4 Data Breaches

Category: dataBreaches

Alert name (type)	Explanation	Severity
`emailDataBreachesDetected`	Account email found in breach databases	🟠 Medium
`passwordsLeaked`	Password found in breach databases	🔴 High

4.5 Permissions, Roles & Pages

Category: permissions. Base severities are Low — escalate admin-related and bulk changes using the detection scenarios in section 7.

Alert name (type)	Explanation	Severity
`permissionAdded`	Permission added on a social media asset	🟢 Low
`permissionRemoved`	Permission removed from a social media asset	🟢 Low
`roleAdded`	Role added on a social media asset	🟢 Low
`roleRemoved`	Role removed from a social media asset	🟢 Low
`roleChanged`	Role changed on a social media asset	🟢 Low
`pageAdded`	Page added to the workspace	🟢 Low
`pageRemoved`	Page removed from the workspace	🟠 Medium
`automaticPermissionRemovalSuccess`	Spikerz automatically removed a risky permission	🚨 Critical
`failedPermissionOperation`	A permission operation failed to execute	🟠 Medium
`unauthorizedUserDetected`	A user with access is not recognized as authorized	🚨 Critical
`compromisedUserDetected`	A user with access has been flagged as compromised	🚨 Critical
`compromisedUserPermissionRemoved`	Permissions of a compromised user were removed	🚨 Critical

4.6 Invitations

Category: permissions

Alert name (type)	Explanation	Severity
`invitationSent`	Access invitation sent	🟢 Low
`invitationResent`	Access invitation resent	🟢 Low
`invitationCancelled`	Access invitation cancelled	🟢 Low
`invitationExpired`	Access invitation expired	🟢 Low

4.7 Connectivity

Category: accountSecurity

Alert name (type)	Explanation	Severity
`accountDisconnected`	Social media account disconnected from Spikerz — monitoring stops until reconnected	🟠 Medium
`accountDeactivated`	Social media account deactivated on the platform	🔴 High

4.8 Test Alert

Category: accountSecurity

Alert name (type)	Explanation	Severity
`testAlert`	Test event sent when validating the SIEM integration	🟢 Low

5. Employee Alerts

Employee-level security alerts. These populate employeeId (and email where relevant).

Alert name (type)	Category	Explanation	Severity
`employeeEmailDataBreachesDetected`	`dataBreaches`	Employee email found in breach databases	🟠 Medium
`employeePasswordsLeaked`	`dataBreaches`	Employee password found in breach databases	🔴 High
`employeeNameChanged`	`permissions`	Employee display name changed	🟢 Low
`employeeTerminated`	`permissions`	Employee marked as terminated	🟠 Medium
`employeeAccessExpired`	`permissions`	Employee access expired	🟢 Low

6. Audit / Event Log Actions

These are delivered as audit events — the value below appears in the action field. Audit actions are Low severity by default; escalate them in context using the detection scenarios in section 7.

6.1 Secure Email & Secure Phone

Action	Explanation	Severity
`secure_email_generated`	Secure email address generated for an asset	🟢 Low
`secure_email_auto_forward_updated`	Secure email auto-forwarding settings changed	🟢 Low
`secure_email_deleted`	Secure email address deleted	🟢 Low
`secure_email_webhook_received`	Message received on a secure email address	🟢 Low
`secure_phone_generated`	Secure phone number generated for an asset	🟢 Low
`secure_phone_auto_forward_updated`	Secure phone auto-forwarding settings changed	🟢 Low
`secure_phone_deleted`	Secure phone number deleted	🟢 Low
`secure_phone_sms_received`	SMS received on a secure phone number	🟢 Low

6.2 2FA Vault

Action	Explanation	Severity
`two_factor_activation_code_stored`	2FA activation code stored in the vault	🟢 Low
`two_factor_6_digits_code_generated`	2FA 6-digit code generated	🟢 Low
`two_factor_backup_codes_stored`	2FA backup codes stored in the vault	🟢 Low
`two_factor_backup_codes_deleted`	2FA backup codes deleted from the vault	🟢 Low
`two_factor_authenticator_deleted`	2FA authenticator deleted from the vault	🟢 Low
`two_factor_used_via_extension`	2FA code used via the browser extension	🟢 Low

6.3 Password Vault

Action	Explanation	Severity
`manual_password_rotate_triggered`	Password rotation initiated	🟢 Low
`password_copied`	Password copied from the vault	🟢 Low
`password_added`	Password added to the vault	🟢 Low
`password_changed`	Password updated in the vault	🟢 Low
`password_update_prompted`	User prompted to update a stored password	🟢 Low
`password_update_saved`	Stored password update saved	🟢 Low
`password_update_dismissed`	Stored password update dismissed by the user	🟢 Low

6.4 Employee Protection

Action	Explanation	Severity
`employee_protection_enabled`	Employee protection enabled	🟢 Low
`employee_backup_email_set`	Employee backup email set	🟢 Low
`employee_backup_email_removed`	Employee backup email removed	🟢 Low
`employee_terminated`	Employee marked as terminated	🟢 Low
`permissions_settings_changed`	Social media permissions configuration changed	🟢 Low
`whitelist_user_added`	Social media account added to whitelist	🟢 Low
`whitelist_user_removed`	Social media account removed from whitelist	🟢 Low
`user_marked_as_unauthorized`	User manually marked as unauthorized	🟢 Low
`user_marked_as_authorized`	User manually marked as authorized	🟢 Low

6.5 Extension & Browser

Action	Explanation	Severity
`extension_installed`	Spikerz browser extension installed	🟢 Low
`account_selected`	Account selected in the extension	🟢 Low
`autofill_attempted`	Credential autofill attempted via the extension	🟢 Low
`platform_login_succeeded`	Platform login via the extension succeeded	🟢 Low
`platform_login_failed`	Platform login via the extension failed	🟢 Low
`widget_opened`	Extension widget opened	🟢 Low
`widget_workspace_picked`	Workspace selected in the extension widget	🟢 Low

6.6 Threat Protection

Action	Explanation	Severity
`detection_layer_used`	A detection layer was used to evaluate activity	🟢 Low
`disconnect_on_login_executed`	Automatic disconnect executed on login	🟢 Low

6.7 Workspace Access, Connections & Sessions

Action	Explanation	Severity
`workspace_access_granted`	Workspace access granted to a user	🟢 Low
`workspace_access_revoked`	Workspace access revoked from a user	🟢 Low
`workspace_access_changed`	Workspace access level changed	🟢 Low
`asset_access_granted`	Asset-level access granted to a user	🟢 Low
`account_connected`	Social media account connected to Spikerz	🟢 Low
`account_refreshed`	Social media account connection refreshed	🟢 Low
`user_logged_in`	User logged in to Spikerz	🟢 Low
`user_logged_out`	User logged out of Spikerz	🟢 Low

6.8 Alert Responses

Responses to confirmable alerts sent to Slack / Teams. A denial is a strong incident signal.

Action	Explanation	Severity
`alert_approved_by_user`	User confirmed the activity behind an alert as legitimate	🟢 Low
`alert_denied_by_user`	User denied the activity behind an alert — it was not them	🔴 High

7. Detection Scenarios — Recommended Correlation Rules

We recommend implementing the following correlation rules in your SIEM. Each rule combines or escalates the events above; the severity to assign is the severity of the resulting incident, which may be higher than the base severity of the individual events.

Implementing these rules

Spikerz delivers the raw events — the rules themselves are built in your SIEM’s rule engine, keying on the type / action values and metadata fields documented above:

SIEM	Where to build the rule
Microsoft Sentinel	Scheduled analytics rules (KQL)
Splunk	Correlation searches (SPL)
Elastic	Detection rules — EQL is ideal for the sequence-based scenarios
Rapid7 InsightIDR	Custom detection rules
CrowdStrike NG-SIEM	Correlation rules

For example, scenario 2 (mass admin removal) as a Microsoft Sentinel analytics rule:

SpikerzEvents
| where type in ("roleRemoved", "permissionRemoved")
| where metadata.role == "admin"
| summarize removals = count() by workspaceId, bin(timestamp, 1h)
| where removals >= 3

Sequence-based scenarios (e.g. scenario 3 — 2FA removed followed by a password change) are implemented with time-windowed joins in KQL/SPL, or with Elastic EQL, e.g. sequence by accountId with maxspan=30m.

#	Scenario	Rule logic	Severity to assign	Recommended response
1	Admin removed	A `roleRemoved` or `permissionRemoved` event where `metadata` indicates an admin role	🔴 High	Verify the change with the asset owner; if unexpected, treat as a takeover attempt
2	Mass admin removal	3 or more `roleRemoved` / `permissionRemoved` (admin) events in the same workspace within 1 hour	🚨 Critical	Assume an active takeover — lock the account and engage incident response
3	2FA removed, then password changed	`2faRemoved` followed by `passwordChanged` on the same account within 30 minutes	🚨 Critical	Classic takeover chain — lock the account immediately
4	Recovery contact swap	`emailChange` and `phoneNumberChange` on the same account within 1 hour	🚨 Critical	Both recovery paths replaced — verify with the owner urgently
5	New login followed by security change	`newLoginDetected` or `suspiciousActivityNewLogin` followed by `2faRemoved`, `emailChange`, or `passwordChanged` within 1 hour	🚨 Critical	Unrecognized session is changing security settings — lock the account
6	Compromised or unauthorized user	Any single `compromisedUserDetected` or `unauthorizedUserDetected` event	🚨 Critical	Page on-call; remove the user's access and audit their recent actions
7	Alert denied by user	Any `alert_denied_by_user` event	🔴 High	The user explicitly disowned the activity — investigate as unauthorized access
8	Bulk permission churn	More than 5 permission / role events on one asset within 1 hour	🔴 High	Review all changes in the window; revert unauthorized ones
9	Account lockout triggered	Any `manualAccountLockoutActivated` or `autoAccountLockout*` event	🚨 Critical	Open an incident automatically — a lockout means a takeover was suspected or in progress
10	Monitoring loss	`accountDisconnected` with no `account_connected` within 24 hours, or 2+ disconnects within 1 hour	🔴 High	Attackers may disconnect monitoring first — reconnect and review platform activity
11	Repeated failed logins	5 or more `platform_login_failed` events on the same asset within 30 minutes	🔴 High	Possible credential stuffing — rotate the password and review access
12	Vault tampering	`two_factor_authenticator_deleted`, `two_factor_backup_codes_deleted`, `secure_email_deleted`, or `secure_phone_deleted` outside an approved change window	🟠 Medium	Confirm the deletion was intentional and authorized
13	Offboarding gap	`employeeTerminated` / `employee_terminated` with no `permissionRemoved` for that employee within 24 hours	🔴 High	Terminated employee still has access — revoke permissions
14	Breach followed by login	`passwordsLeaked` or `emailDataBreachesDetected` followed by `newLoginDetected` on the same account within 7 days	🔴 High	Leaked credentials may be in use — force a password rotation
15	Off-hours privilege grant	`roleAdded` (admin) or `workspace_access_granted` outside business hours	🟠 Medium	Confirm the grant with the requester the next business day

8. Testing Your Integration

Triggering the Test SIEM Events action sends one test entry to your configured SIEM for every SIEM-enabled alert type and event log action listed above, plus a testAlert marker event. Use it to validate parsing, field mapping, and your correlation rules end to end.

Supported SIEM platforms: Splunk, Microsoft Sentinel, CrowdStrike, Elasticsearch, and Rapid7.

Spikerz SIEM Alerts: Structure, Severity & Event Types

1. SIEM Alert Structure

Common fields

Security alerts vs audit events

2. Severity Levels

3. SIEM Event Examples (JSON)

Security alert example (type + category)

Audit / event log example (action)

4. Security Alerts (Workspace)

4.1 Account Lockout & Takeover Prevention

4.2 Login & Suspicious Activity

4.3 Account Protection (2FA, Password & Recovery Contacts)

4.4 Data Breaches

4.5 Permissions, Roles & Pages

4.6 Invitations

4.7 Connectivity

4.8 Test Alert

5. Employee Alerts

6. Audit / Event Log Actions

6.1 Secure Email & Secure Phone

6.2 2FA Vault

6.3 Password Vault

6.4 Employee Protection

6.5 Extension & Browser

6.6 Threat Protection

6.7 Workspace Access, Connections & Sessions

6.8 Alert Responses

7. Detection Scenarios — Recommended Correlation Rules

Implementing these rules

8. Testing Your Integration