Use the Sekoia.io events search API in three steps. Create a search job (POST /v1/sic/conf/events/search/jobs) with a query and a time window, wait until the job is done, then read its events in pages of up to 1,000. The Export events button in the Events page works too, but it stops at 500 events. For large volumes, Sekoia offers a massive export API and its own sekoia-event-exporter tool.

Sekoia.io is a European SOC platform, and its event store is often the first place its users look during an investigation. Prime Core has 23,983 detection rules, mapped to 676 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

An API key. Create one in Sekoia.io with permission to search events. Read-only is enough for searching; the massive export needs the SIC_MASSIVE_EXPORT_EVENTS permission.

Your region’s API host. The default is https://api.sekoia.io. Other regions have their own hosts, for example https://api.usa1.sekoia.io.

Query language. The API accepts the same queries as the Events page. The examples below use the classic “dork” syntax (term_lang: dork). Build and test the query in the UI first.

Export with the events search API

API="https://api.sekoia.io/v1"
H="Authorization: Bearer $SEKOIA_API_KEY"

# 1. create the search job
JOB=$(curl -sS -X POST "$API/sic/conf/events/search/jobs" -H "$H" -H 'Content-Type: application/json' \
  -d '{"term": "host.name:\"web-03\"", "earliest_time": "2026-10-19T00:00:00Z", "latest_time": "2026-10-20T00:00:00Z", "term_lang": "dork"}' \
  | jq -r '.uuid')

# 2. wait until the job is done (status 2)
until [ "$(curl -sS -H "$H" "$API/sic/conf/events/search/jobs/$JOB" | jq -r '.status')" = "2" ]; do sleep 3; done

# 3. read the events, 1,000 at a time
TOTAL=$(curl -sS -H "$H" "$API/sic/conf/events/search/jobs/$JOB" | jq '.total')
for ((off=0; off<TOTAL; off+=1000)); do
  curl -sS -H "$H" "$API/sic/conf/events/search/jobs/$JOB/events?limit=1000&offset=$off" | jq -c '.items[]'
done > sekoia_web03_1019.jsonl

Events come back newest first. A job that fails never reaches status 2, so add a timeout if you script this for regular use.

For large exports, start the massive export on a finished job (POST /v1/sic/conf/events/search/jobs/<uuid>/export), wait for the task, then fetch the download link. The sekoia-event-exporter package on PyPI wraps this workflow.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file. 
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export Sekoia Logs appeared first on SOC Prime.

Cloud SIEM runs on top of Datadog Log Management, so exporting “Cloud SIEM logs” means exporting the logs behind it. Use the Logs Search API, POST /api/v2/logs/events/search, with an API key and an application key, and follow the cursor until there’s no next page; each page holds up to 1,000 logs. For history beyond your index retention, read your log archives in S3, GCS or Azure Storage, or rehydrate them. Security signals are a separate API.

Datadog is where many cloud-native teams already keep their logs, which makes it the natural source for an investigation slice. Prime Core has 23,983 detection rules for Datadog, mapped to 676 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

Two keys. The Logs Search API needs an API key (DD-API-KEY) and an application key (DD-APPLICATION-KEY). The application key must belong to a user, or a service account, that can read the logs, and if it’s scoped, it needs log read access.

Your Datadog site. The API host follows your site: api.datadoghq.com (US1), api.us3.datadoghq.com, api.us5.datadoghq.com, api.datadoghq.eu, api.ap1.datadoghq.com and others. Use the one matching your login URL.

Retention. Indexed logs are searchable for as long as their index keeps them. Older logs exist only in archives, if you set any up.

Export with the Logs Search API

DD="https://api.datadoghq.eu"
BODY='{"filter": {"query": "host:web-03 source:sshd", "from": "2026-10-19T00:00:00Z", "to": "2026-10-20T00:00:00Z"}, "page": {"limit": 1000}, "sort": "timestamp"}'

: > dd_web03_1019.jsonl
CURSOR=""
while :; do
  REQ=$(echo "$BODY" | jq --arg c "$CURSOR" 'if $c != "" then .page.cursor = $c else . end')
  RESP=$(curl -sS -X POST "$DD/api/v2/logs/events/search" \
    -H "DD-API-KEY: $DD_API_KEY" -H "DD-APPLICATION-KEY: $DD_APP_KEY" \
    -H 'Content-Type: application/json' -d "$REQ")
  echo "$RESP" | jq -c '.data[]' >> dd_web03_1019.jsonl
  CURSOR=$(echo "$RESP" | jq -r '.meta.page.after // empty')
  [ -z "$CURSOR" ] && break
done

# raw messages only
jq -r '.attributes.message' dd_web03_1019.jsonl > dd_web03_1019.log

The API is rate limited. For big windows, expect it to take a while, and back off when you see 429.

Older logs: archives

If you configured log archives, Datadog writes compressed JSON files to your bucket, organized by date and hour. Download the hours you need and decompress them:

aws s3 cp s3://my-dd-archive/dt=20261019/ ./dd-archive/ --recursive
zcat ./dd-archive/*/*.json.gz > dd_archive_1019.jsonl

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.]
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export Datadog Cloud SIEM Logs appeared first on SOC Prime.

For a targeted pull from Carbon Black Cloud, use the Platform Search API. Create a process search job, wait until all backends have answered, and fetch the results as JSON. For bulk, continuous export, set up the Data Forwarder, which writes endpoint events, alerts and watchlist hits to your own S3 bucket as compressed JSON. Carbon Black EDR, the on-premises product formerly called Response, has a different API.

Carbon Black, now part of Broadcom, records process activity on a lot of corporate endpoints. Prime Core has 15,590 detection rules for Carbon Black, mapped to 638 MITRE ATT&CK techniques. Below is how to get the data out, sanitize it, and investigate it for free in LogTotal.

Get Started For Free

Before you start

An API key and your org key. Create an API key whose access level allows process search, and note the API ID and secret. The org key is shown in the console’s API access settings. Together they make the header X-Auth-Token: <secret>/<id>.

Your environment’s host. Carbon Black Cloud runs several environments, each with its own hostname (for example defense.conferdeploy.net or defense-eu.conferdeploy.net). Use the one in your console URL.

Retention. Process data is kept for a limited time, depending on your subscription. The Data Forwarder is how you keep more.

Option 1: Process search API

CBC="https://defense.conferdeploy.net"
ORG="<org_key>"
H="X-Auth-Token: $CB_API_SECRET/$CB_API_ID"

# 1. start the search job
JOB=$(curl -sS -X POST "$CBC/api/investigate/v2/orgs/$ORG/processes/search_jobs" \
  -H "$H" -H 'Content-Type: application/json' \
  -d '{"query": "device_name:ws-042", "time_range": {"start": "2026-10-19T00:00:00Z", "end": "2026-10-20T00:00:00Z"}, "fields": ["*"], "rows": 10000}' \
  | jq -r '.job_id')

# 2. wait until every backend has answered
until curl -sS -H "$H" "$CBC/api/investigate/v2/orgs/$ORG/processes/search_jobs/$JOB/results?rows=0" \
      | jq -e '.contacted == .completed' >/dev/null; do sleep 3; done

# 3. fetch the results
curl -sS -H "$H" "$CBC/api/investigate/v2/orgs/$ORG/processes/search_jobs/$JOB/results?start=0&rows=10000" \
  | jq -c '.results[]' > cb_ws042_1019.jsonl

This returns process records. Network connections, file and registry modifications for a process are available through the process event details APIs. The official Python SDK (carbon-black-cloud-sdk) wraps all of this.

Option 2: Data Forwarder (bulk)

In the console, configure a Data Forwarder to an S3 bucket you own and choose the data types: endpoint events, alerts, watchlist hits. Files arrive as compressed JSON, one record per line. For an investigation, download the time range and filter by device:

aws s3 cp s3://my-cb-forwarder/<prefix>/ ./cb-fwd/ --recursive
zcat ./cb-fwd/**/*.gz | jq -c 'select(.device_name == "ws-042")' > cb_fwd_ws042.jsonl

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

When it goes wrong

The post How to Export Carbon Black Logs appeared first on SOC Prime.

Wazuh keeps its data in two places. On the Wazuh manager, alerts are written to /var/ossec/logs/alerts/alerts.json, one JSON object per line, and rotated daily into compressed files by date. The same alerts are indexed in the Wazuh indexer (OpenSearch), in wazuh-alerts-4.x-*. Either way, the original log line that triggered an alert is in full_log. To export every event, not just the ones that matched a rule, the manager needs archiving turned on.

Wazuh is the most widely used open-source SIEM and XDR, and its data is easy to get at once you know where to look. Prime Core has 23,542 detection rules for Wazuh, mapped to 671 MITRE ATT&CK techniques. Below is how to export alerts and events, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

Alerts or archives? Alerts are the events that matched a Wazuh rule above the alert level threshold. Archives hold everything the manager received, but only if logall_json is enabled in ossec.conf. If the question is “what else happened on that host?”, you want archives, and they only exist from the moment they were turned on.

Permissions. On the manager, the files are owned by the wazuh user and group, so use sudo. For the indexer, you need a user with read access to the alert indices.

Retention. The manager’s rotated files stay until someone deletes them. The indexer keeps what its index lifecycle policy allows.

Option 1: Files on the manager

# today's alerts so far
sudo cp /var/ossec/logs/alerts/alerts.json ./wazuh_alerts_today.jsonl

# a past day (rotated and compressed)
sudo zcat /var/ossec/logs/alerts/2026/Oct/ossec-alerts-19.json.gz > wazuh_alerts_1019.jsonl

# one agent only
jq -c 'select(.agent.name == "web-03")' wazuh_alerts_1019.jsonl > web-03_alerts_1019.jsonl

# the original log lines behind the alerts
jq -r '.full_log // empty' web-03_alerts_1019.jsonl > web-03_raw_1019.log

With archiving enabled, the same pattern works for /var/ossec/logs/archives/archives.json and its rotated files under /var/ossec/logs/archives/<year>/<month>/.

Option 2: The Wazuh indexer

The indexer is OpenSearch, so our applies as written. Point it at wazuh-alerts-* and filter on agent.name and timestamp:

query = {"query": {"bool": {"filter": [
    {"term": {"agent.name": "web-03"}},
    {"range": {"timestamp": {"gte": "2026-10-19T00:00:00Z", "lt": "2026-10-20T00:00:00Z"}}},
]}}}

The Wazuh dashboard can also generate reports, but not in a format LogTotal reads today.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file: the alert JSON, or the raw lines from full_log. 
2. Sanitize. 
3. Review.

When it goes wrong

The post How to Export Wazuh Logs appeared first on SOC Prime.

A high-severity vulnerability in OpenSSH can allow unauthenticated remote attackers to bypass password authentication on certain Linux systems by submitting an overlong password. Tracked as CVE-2026-123158 and dubbed SSHhole, the flaw carries a CVSS 3.1 score of 8.1 and primarily impacts Linux environments where sshd is linked against musl libc and operates without PAM. Alpine Linux is the most prominent affected platform because its standard openssh-server package uses this configuration by default.

The vulnerability results from an unexpected interaction between OpenSSH password validation and musl libc’s crypt() implementation. When an excessively long password is supplied, crypt() can return the string * to indicate an error. Some Linux accounts that are configured without a conventional password also store * in the password field of /etc/shadow. Under vulnerable conditions, sshd can incorrectly interpret the matching values as successful authentication.

An attacker does not need to know the target user’s password. If an exposed SSH service meets the required conditions, an attacker who can reach the service can authenticate to certain accounts using a password in the vulnerable length range. The impact depends on the privileges assigned to the compromised account. Access to a privileged service account or an account capable of using doas or another privilege escalation mechanism could lead to full system compromise.

Contact Sales

OpenSSH addressed the issue in Portable OpenSSH 10.6p2, released on November 5, 2026. Alpine Linux simultaneously released patched OpenSSH packages for all supported branches and several older branches. The OpenSSH team describes the release as containing a critical security workaround for Linux systems using musl libc with PAM disabled.

Public reproduction environments and proof-of-concept material are already available. However, as of November 6, 2026, the reviewed sources do not report confirmed exploitation of the vulnerability in real-world attacks, and the flaw has not been added to CISA’s Known Exploited Vulnerabilities catalog.

Organizations can strengthen defenses against emerging authentication bypass vulnerabilities with SOC Prime’s AI-Native Detection Intelligence Platform, accelerating threat hunting and detection engineering across SIEM, EDR, XDR, and Data Lake environments.

Security teams can also use Prime Architect to transform vulnerability intelligence into hunting queries and detection logic tailored to their available SSH, authentication, endpoint, and network telemetry.

Detect CVE-2026-123158 by monitoring successful password-based SSH logins to accounts that normally use key-only authentication, unusual authentication attempts containing abnormally long passwords, unexpected remote access to service accounts, and post-authentication activity inconsistent with the account’s normal behavior.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-123158 analysis

CVE-2026-123158 affects OpenSSH sshd before Portable OpenSSH 10.6p2 when it runs on Linux with musl libc and password authentication occurs without PAM. The CVE carries a CVSS 3.1 score of 8.1 with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting remote exploitation without prior privileges or user interaction but requiring a specific system and account configuration.

The root cause lies in the interaction between OpenSSH and the password hashing function provided by musl libc.

On systems where PAM is disabled, sshd performs password validation using the system’s crypt() functionality. For a typical account, /etc/shadow contains a cryptographic password hash, and the value generated from the user’s submitted password is compared against that stored hash.

musl libc behaves differently when the supplied password exceeds its supported input length. For passwords longer than 256 bytes, crypt() returns * as an error value rather than a normal password hash.

The problem arises because * is also commonly used in /etc/shadow for accounts that do not have a traditional password configured.

If a vulnerable sshd receives an overlong password for one of these accounts, the authentication flow can effectively compare the * returned by crypt() with the * stored in the account’s shadow entry. The values match, and authentication can incorrectly succeed.

The CVE description states that, for affected account configurations, passwords between 256 and 1024 characters can result in successful authentication. Independent reproductions describe passwords exceeding the normal 256-byte boundary as sufficient to trigger the vulnerable condition.

The flaw is therefore not a universal password bypass affecting every OpenSSH deployment.

Several specific conditions must align.

First, the server must use musl libc. Alpine Linux is the primary mainstream example, although other embedded or minimal Linux environments can also use musl.

Second, sshd must authenticate users without PAM. Alpine’s standard openssh-server package is built without PAM, while the alternative openssh-server-pam configuration is protected when UsePAM yes is enabled.

Third, password authentication must be enabled. PasswordAuthentication yes is the relevant configuration. Systems configured for public-key-only authentication with PasswordAuthentication no are not exposed to the documented attack path.

Finally, the attacker needs an account whose password field contains *. These can include key-only users, accounts created without passwords, some identities provided through directory services, and certain cloud-image users.

Alpine also notes an additional condition: at least one local account must contain a $5$ or $6$-style password hash for the vulnerable authentication path to operate as described.

The root account deserves special attention. Alpine commonly stores root:*, but OpenSSH’s default PermitRootLogin prohibit-password prevents password authentication directly to root. As a result, a standard Alpine installation does not automatically expose direct root login through this bug.

That protection does not eliminate the broader risk. If another account with * in its password field is remotely accessible and has administrative rights through doas, sudo, container capabilities, or other privileged mechanisms, successful authentication can still provide a path to complete system compromise.

Alpine’s official tiny-cloud images are particularly relevant. Security research identified versions where the alpine account could meet the vulnerable conditions and was also able to use doas to gain elevated privileges. This illustrates why defenders should evaluate account privileges rather than assuming the vulnerability provides either harmless user access or automatic root access in every environment.

glibc-based Linux distributions such as Debian, Ubuntu, and RHEL are not affected by this specific vulnerability because the vulnerable behavior depends on musl libc’s password hashing implementation. Systems using PAM for SSH password validation are likewise outside the documented vulnerable configuration.

Containers require similar qualification. Alpine is widely used as a container base image, but ordinary containers that do not run sshd are not vulnerable through this attack path. The primary concern is containers, appliances, development environments, or legacy workloads that explicitly install and expose an SSH server.

The CVE-2026-123158 PoC landscape has developed quickly. Public reproduction labs are referenced directly by the vulnerability record, demonstrating that defenders should assume the authentication bypass can be reproduced without access to private exploit research. This materially raises remediation urgency even though confirmed malicious exploitation has not yet been reported.

The vulnerability was reported by Özgün Kültekin of Wakefield. OpenSSH publicly released version 10.6p2 with the security workaround on November 5, 2026.

The OpenSSH fix adds validation designed to prevent error values and invalid short password hashes from being accepted during password authentication. OpenSSH notes that it considers the underlying root cause to exist outside sshd, but because the condition can be exploited through the SSH server, the project implemented a defensive workaround in OpenSSH itself.

Alpine Linux has backported the correction across multiple branches:

Administrators should rely on their distribution package status rather than the SSH version banner alone. Linux distributions frequently backport security patches without changing the upstream OpenSSH version displayed during the SSH handshake. A server displaying an older version string may therefore already contain the vendor fix.

For CVE-2026-123158 detection, defenders should prioritize SSH authentication telemetry. A particularly strong hunting signal is a successful password login to an account that is intended to use only public-key authentication or that has no usable password configured.

On Alpine systems, administrators can review /var/log/messages, centralized authentication logs, SIEM records, or equivalent telemetry for Accepted password events involving unexpected service, key-only, or administrative accounts.

Defenders should correlate successful authentication with source IP addresses, login times, session duration, commands executed after login, privilege elevation, changes to authorized_keys, account creation, scheduled jobs, and unexpected outbound network connections.

Network telemetry can also help identify exposed systems. Externally reachable SSH services advertising password or keyboard-interactive authentication should receive higher remediation priority, particularly when the underlying system is Alpine or another musl-based distribution.

At present, there are no campaign-specific CVE-2026-123158 IOCs such as confirmed attacker IP addresses, domains, malware hashes, or command-and-control infrastructure. The absence of static indicators makes behavioral monitoring of SSH authentication and subsequent session activity particularly important.

CVE-2026-123158 Mitigation

The primary remediation is to install OpenSSH 10.6p2 or the corrected package supplied by the Linux distribution. Alpine administrators should update the full system using the current package repositories and restart sshd afterward. Updating the package alone does not replace the already running SSH daemon process.

Organizations running Alpine-based containers should rebuild and redeploy any image that installs openssh-server. Simply updating the host operating system does not patch vulnerable OpenSSH packages embedded inside container images.

Administrators should also identify exposure before assuming that every Alpine host is vulnerable. Key checks include:

1. Determine whether the host uses musl libc.
2. Verify whether sshd is running with PAM disabled.
3. Check whether password authentication is enabled.
4. Identify login-capable accounts whose /etc/shadow password field is *.
5. Review the privileges assigned to those accounts.
6. Confirm the installed OpenSSH package against the distribution’s corrected package version.

If immediate patching is impossible, organizations should disable SSH password authentication.

Configure:

PasswordAuthentication no

and, where applicable:

KbdInteractiveAuthentication no

Administrators should confirm that public-key authentication works before applying this configuration to avoid losing legitimate administrative access.

The SSH configuration should then be validated and the daemon reloaded or restarted. Afterward, external verification should confirm that the server offers only public-key authentication.

Restricting network accessibility provides additional defense in depth. SSH should generally be reachable only from trusted administrative networks, VPN infrastructure, bastion hosts, or explicit source-IP allowlists rather than being universally exposed to the internet.

Organizations should also reconsider whether SSH is required inside containers at all. Modern orchestration environments usually provide alternatives such as docker exec or kubectl exec, eliminating an unnecessary remotely reachable authentication service.

For potentially exposed systems, review historical successful password logins occurring before remediation. Pay particular attention to accounts configured without passwords and identities normally expected to authenticate exclusively with SSH keys.

If an unexpected successful login is identified, treat the account as potentially compromised. Review shell history where available, process execution, privilege escalation, new or modified authorized_keys entries, user and group changes, cron jobs, startup scripts, package installation, and outbound network connections.

Credentials and keys accessible to the compromised account should be considered potentially exposed and rotated according to the findings of the investigation. If the account had administrative privileges, defenders should expand the investigation to the entire host and any systems reachable using credentials stored there.

Public proof-of-concept material means organizations should not wait for evidence of widespread attacks before applying the fix. The exploitation prerequisites narrow the vulnerable population, but systems that meet those conditions can be accessed remotely without knowledge of a valid password.

The post CVE-2026-123158: OpenSSH Password Authentication Bypass Affects Alpine Linux appeared first on SOC Prime.

Use the Log Search API. Send a LEQL query for a log and a time window to https://<region>.rest.logs.insight.rapid7.com/query/logs/<log-key> with your API key in the X-Api-Key header. The API returns events in pages and gives you a link to the next one. Log Search in the UI can export results too.

InsightIDR collects endpoint, network and cloud logs for Rapid7 customers, and its Log Search is where investigations usually start. Prime Core has 23,965 detection rules for InsightIDR, mapped to 676 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

An API key. Create one in the Insight Platform settings (an organization key or a user key) with access to InsightIDR.

Your region. The host depends on where your data lives: us, us2, us3, eu, ca, au, ap.

Log keys. Each log has a key, and queries run against one or more of them. List them with the API, as shown below.

Retention. How far back Log Search goes depends on your subscription.

Export with the Log Search API

REGION=us
BASE="https://$REGION.rest.logs.insight.rapid7.com"
FROM=$(date -d '2026-10-19T00:00:00Z' +%s000)
TO=$(date -d '2026-10-20T00:00:00Z' +%s000)
Q=$(printf '%s' 'where(hostname=web-03)' | jq -sRr @uri)

# list logs and their keys
curl -sS -H "X-Api-Key: $R7_KEY" "$BASE/management/logs" | jq -r '.logs[] | "\(.id)  \(.name)"'

# query one log, following the pages
URL="$BASE/query/logs/<log-key>?query=$Q&from=$FROM&to=$TO&per_page=500"
while [ -n "$URL" ]; do
  RESP=$(curl -sS -H "X-Api-Key: $R7_KEY" "$URL")
  echo "$RESP" | jq -c '.events[]?'
  URL=$(echo "$RESP" | jq -r '.links[]? | select(.rel == "Next") | .href' | head -1)
done > r7_web03_1019.jsonl

Long-running queries may first answer with a link to poll instead of results. Each event’s message field holds the log entry. Extract it with jq -r ‘.message’ when the source was text.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. Look it over before you continue.
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export Rapid7 InsightIDR Logs appeared first on SOC Prime.

Use LogPoint’s Search API, which works in two calls to the same endpoint, /getsearchlogs. The first call sends your query, time range and repos, and returns a search_id. The second call sends that search_id and returns the rows once the search is final. Both calls are form-encoded POSTs authenticated with your username and secret key.

LogPoint is a popular SIEM in Europe, and the Search API is the cleanest way to get a defined slice of its data out. Prime Core has 19,598 detection rules for LogPoint, mapped to 664 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

Your secret key. Every API call carries your LogPoint username and secret key. You find the key in your user profile’s access key settings. Treat it like a password.

Repo names. Searches run against repos, written as <ip>:5504/<repo>, for example 127.0.0.1:5504/_logpoint. The same endpoint family lists them for you (getalloweddata with type logpoint_repos).

Time range. time_range takes either a preset like “Last 24 hours” or a pair of epoch seconds. For incident work, use the epoch pair; date -d ‘2026-10-19T00:00:00Z’ +%s computes it.

Export with the Search API

LP="https://logpoint.example.com"

# 1. start the search (2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC)
SID=$(curl -sS "$LP/getsearchlogs" \
  --data-urlencode "username=$LP_USER" --data-urlencode "secret_key=$LP_KEY" \
  --data-urlencode 'requestData={"query": "device_ip=10.0.0.5", "time_range": [1792368000, 1792454400], "limit": 10000, "repos": ["127.0.0.1:5504/_logpoint"]}' \
  | jq -r '.search_id')

# 2. fetch results until the search is final
while :; do
  R=$(curl -sS "$LP/getsearchlogs" \
      --data-urlencode "username=$LP_USER" --data-urlencode "secret_key=$LP_KEY" \
      --data-urlencode "requestData={\"search_id\": \"$SID\"}")
  [ "$(echo "$R" | jq -r '.final')" = "true" ] && break
  sleep 3
done

echo "$R" | jq -c '.rows[]' > logpoint_1019.jsonl
echo "$R" | jq -r '.rows[].msg // empty' > logpoint_1019_raw.log

Keep the query a filter. A query with | chart or other aggregations returns aggregated rows, not logs. The raw log usually sits in the msg field.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export LogPoint Logs appeared first on SOC Prime.

A high-severity vulnerability in APT, the package management system used by Debian, Ubuntu, and derivative Linux distributions, could allow an on-path attacker to replace a verified software package with a malicious one and execute arbitrary code with root privileges. Tracked as CVE-2026-109518, the flaw carries a CVSS 4.0 score of 7.7 and affects APT’s HTTP download and retry handling.

The vulnerability is caused by improper handling of hard links when APT follows HTTP redirects and retries failed package downloads. Under the right conditions, two different downloads can be merged after a redirect causes them to resolve to the same URI. An attacker able to manipulate traffic between an APT client and a repository can abuse this behavior to substitute an attacker-controlled .deb package after verification has already taken place.

Because Debian packages can execute installation scripts with root privileges, successful exploitation can result in complete system compromise. However, exploitation requires several conditions: the victim must initiate a package installation, APT must communicate over manipulable HTTP, and the Acquire::Retries option must be set to a non-zero value.

Ubuntu 22.04 LTS and newer releases are exposed by default because retries are enabled. Debian has similarly enabled retries by default since APT 2.3.2, including Debian 12. Older releases can still be vulnerable when administrators or automation scripts manually enable retries.

Contact Sales

The vulnerability was discovered by security researcher Max Justicz and publicly disclosed on November 4, 2026. Debian and Ubuntu released security updates on the same day. Neither vendor advisory currently reports exploitation of the flaw in real-world attacks.

Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to operationalize threat intelligence and strengthen defenses against software supply-chain attacks, package manager abuse, malicious payload execution, and post-compromise activity across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-109518 by monitoring suspicious changes in package repository traffic, unexpected redirects or repeated package-download failures, anomalous package installations, and new privileged processes occurring immediately after APT activity.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-109518 analysis

CVE-2026-109518 affects APT deployments on Debian, Ubuntu, and derivative Linux distributions when package files are downloaded over an attacker-manipulable HTTP path and retry functionality is enabled. Ubuntu classifies the vulnerability as High with a CVSS 4.0 score of 7.7 and the vector CVSS:4.0/AV/AC/AT/PR/UI/VC/VI/VA/SC/SI/SA.

APT is responsible for downloading, verifying, and installing packages on Debian-based Linux systems. Package authenticity normally relies on Debian and Ubuntu repository signature mechanisms designed to ensure that packages delivered by mirrors cannot be silently modified by an untrusted intermediary.

CVE-2026-109518 breaks an important part of this trust model under specific download conditions.

The vulnerability occurs when APT handles HTTP redirects and retries. According to Debian’s advisory, APT can merge two separate package downloads when a redirect causes them to share the same URI. When a download subsequently needs to be resumed, incorrect handling of reused hard links can allow the content associated with an already verified package to be overwritten.

An attacker first needs the ability to manipulate HTTP traffic between the victim and the package archive. Potential positions include a malicious or compromised network intermediary, proxy, Wi-Fi network, or package mirror. Ubuntu explicitly includes malicious mirrors and proxies in its threat model.

The attacker can then use redirects together with transient HTTP errors to force APT into its retry path. When APT retries the package download, the flaw in hard-link handling can cause attacker-controlled data to replace content associated with a package that has already passed verification.

This allows the malicious package to bypass the protection normally provided by repository signatures.

The impact becomes particularly severe because .deb packages can contain maintainer scripts executed during installation. These scripts run with root privileges when packages are installed, meaning an attacker who successfully substitutes a package can execute commands with full system privileges.

The vulnerability does not mean that every Debian or Ubuntu host can be compromised remotely at any time. The attack requires the victim system to perform a package installation or upgrade while the attacker can interfere with the network path.

Another important prerequisite is Acquire::Retries.

APT uses this option to determine whether failed downloads should automatically be retried. The vulnerable behavior requires a value greater than zero. Debian’s APT developers state that retries have been enabled by default since APT 2.3.2, while Ubuntu confirms that Ubuntu 22.04 LTS and newer releases use a non-zero default value.

Older systems are therefore not necessarily safe. Although Ubuntu 20.04 LTS and earlier releases do not enable retries by default, custom configuration, deployment automation, or administrator scripts can set Acquire::Retries manually and make those systems exploitable.

The vulnerability exists in APT’s HTTP backend and therefore applies across APT-based frontends, including apt, apt-get, aptitude, and graphical Ubuntu applications that ultimately use the same underlying package management infrastructure. Snap packages are not affected because they use a different distribution mechanism.

HTTPS also changes the attack surface significantly. Ubuntu states that TLS protects against this vulnerability because the attacker must be able to modify HTTP traffic in transit. Package sources accessed exclusively over properly validated HTTPS are therefore protected from the documented on-path attack method. FTP and unrelated transport mechanisms are not affected by this specific issue.

The CVE-2026-109518 PoC situation should be interpreted carefully. Debian and Ubuntu’s official advisories do not link to a public exploit demonstrating full root compromise, and they do not report malicious exploitation in the wild. The technical information released by APT developers nevertheless explains enough of the redirect, retry, and hard-link behavior for defenders to understand the attack requirements.

The weakness is associated with improper hard-link handling and a time-of-check/time-of-use condition. The CVE record maps it to CWE-62, UNIX Hard Link, and CWE-367, Time-of-check Time-of-use Race Condition.

APT developers released fixed versions across multiple maintained branches:

Debian 13 “Trixie” received APT 3.0.4, while Debian 12 “Bookworm” received version 2.6.2.

Ubuntu released the following corrected packages:

Updates for older Ubuntu releases require the applicable Ubuntu Pro or Extended Security Maintenance coverage.

For CVE-2026-109518 detection, security teams should correlate package-management activity with network and endpoint telemetry. Repeated HTTP redirects, transient download failures immediately followed by successful package retrieval, unexpected repository destinations, or package installation from unusual network paths can provide useful investigation pivots.

Endpoint monitoring should also identify unusual child processes spawned during or immediately after APT or dpkg execution. Because successful exploitation results in an attacker-controlled package being installed as root, suspicious shell execution, new services, altered system files, persistence mechanisms, user creation, credential access, or unexpected outbound connections following package installation should be treated as high-priority indicators.

APT and dpkg logs can provide additional context. Defenders should review /var/log/apt/, /var/log/dpkg.log, system journal records, proxy telemetry, DNS logs, and network security data around suspicious package operations. Comparing installed package versions and checksums against trusted distribution repositories can help identify unexpected modifications.

At present, vendor advisories provide no attacker infrastructure, malware hashes, or campaign-specific CVE-2026-109518 IOCs because Debian and Ubuntu have not reported active malicious exploitation. Behavioral monitoring is therefore more valuable than searching for a static IOC list.

CVE-2026-109518 Mitigation

The primary remediation is to install the updated APT package supplied by Debian, Ubuntu, or the relevant derivative distribution. Administrators should not rely solely on network controls because the corrected APT implementation prevents the package verification bypass at its source.

Ubuntu recommends updating all installed packages while explicitly disabling retries during the update process:

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

Organizations that cannot perform a complete system upgrade can target APT itself:

sudo apt update && sudo apt install -o Acquire::Retries=0 –only-upgrade ‘?source-package(^apt$)’

Setting retries to zero during this operation prevents the vulnerable retry path from being used while the security update itself is downloaded and installed.

Security teams should take the following steps:

1. Inventory Debian, Ubuntu, and derivative Linux systems using APT.
2. Identify the installed APT version and compare it with the vendor-fixed release.
3. Prioritize internet-connected systems and environments using untrusted, third-party, or community package mirrors.
4. Apply the vendor security update with Acquire::Retries=0.
5. Confirm that the corrected APT package is installed.
6. Review /etc/apt/sources.list and files under /etc/apt/sources.list.d/ for unexpected HTTP repositories.
7. Move package sources from HTTP to HTTPS where supported.
8. Review proxy and package mirror infrastructure for signs of compromise or unauthorized modification.
9. Investigate unexpected package installations that occurred before the fix was deployed.

Ubuntu confirms that changing package repositories to HTTPS provides protection against the documented attack because exploitation requires modification of HTTP traffic. Administrators should first verify that their selected repository mirrors support TLS and then run sudo apt update to ensure that the configuration operates without errors.

Using HTTPS should be treated as defense in depth rather than a substitute for updating APT. Systems may later use another repository, proxy, automation workflow, or HTTP endpoint, so installing the corrected package remains necessary.

Temporarily setting Acquire::Retries to zero provides another effective workaround against the documented exploitation condition. Since the flaw depends on APT retrying a failed download, disabling retries prevents the vulnerable code path from being reached. This setting can reduce package-download reliability, however, and should primarily be used while applying the actual security update.

Organizations using unattended upgrades should verify patch deployment rather than assuming every machine has already been corrected. Ubuntu notes that unattended-upgrades is enabled by default from Ubuntu 16.04 LTS onward and normally applies security updates within 24 hours, but fleet management, network restrictions, custom repository configurations, or disabled services can prevent successful installation.

If compromise is suspected, administrators should preserve APT, dpkg, proxy, network, and system logs before remediation. Review packages installed during the suspected exposure window, validate package provenance, inspect maintainer scripts, and investigate any root-level processes or persistence established immediately afterward.

Because a malicious package can run arbitrary commands as root, confirmed exploitation should be treated as full system compromise. Rebuilding the affected host from trusted media may be more reliable than attempting to remove individual artifacts, especially when the attacker could have modified system binaries, services, authentication configuration, or kernel-level components.

The post CVE-2026-109518: APT Flaw Enables MitM Root Code Execution appeared first on SOC Prime.

A critical vulnerability in the Linux kernel’s IPv4 TCP networking stack could allow an unauthenticated remote attacker to trigger memory corruption, crash vulnerable systems, and potentially execute arbitrary code with root privileges. Tracked as CVE-2026-98432, the flaw carries a CVSS 3.1 score of 9.8 and has existed in the Linux kernel since version 4.4.

The vulnerability stems from a race condition that can cause the kernel to access IP option data after the underlying memory has already been freed. An attacker capable of reaching an exposed IPv4 TCP service can attempt to trigger the condition using specially timed connection requests containing IPv4 options. No authentication, local privileges, or user interaction are required.

Security interest increased significantly after Anthropic disclosed that an internal Claude research model had developed a working exploit capable of achieving remote root command execution against a Linux server with a Multipath TCP (MPTCP) listener. The exploit first leaks a kernel pointer to bypass KASLR and then uses the same use-after-free condition to corrupt memory and redirect kernel control flow. Anthropic has not released the exploit code.

Importantly, the underlying vulnerability is not limited to MPTCP. Red Hat confirms that systems with ordinary IPv4 TCP networking remain vulnerable even when MPTCP is disabled, including default Red Hat Enterprise Linux configurations.

Contact Sales

As of November 4, 2026, no Linux vendor, CERT, or other reviewed source has reported confirmed exploitation of the flaw in real-world attacks. Public research code demonstrating portions of the vulnerability exists, but a publicly released exploit providing the full remote-root capability demonstrated by Anthropic has not been documented.

Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to strengthen their defenses against emerging vulnerability exploitation, operationalize threat intelligence, and accelerate threat hunting across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-98432 by monitoring unusual IPv4 TCP traffic containing IP options, repeated connection attempts designed to trigger race conditions, kernel crashes or memory-corruption events, and suspicious activity that could indicate successful post-exploitation.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-98432 analysis

CVE-2026-98432 affects the IPv4 TCP connection-handling code in Linux kernels containing the vulnerable implementation introduced in Linux 4.4. The Linux kernel CVE team classifies the issue as critical with a CVSS 3.1 score of 9.8 and the vector AV/AC/PR/UI/S/C/I/A.

The vulnerability is a use-after-free condition caused by a race during concurrent TCP connection processing. When an IPv4 TCP connection is established, tcp_v4_syn_recv_sock() transfers IP options associated with the pending request to the newly created socket without making a separate copy.

Another CPU can simultaneously process a retransmitted SYN associated with the same request socket. During that process, functions responsible for generating the SYN-ACK continue reading the IP options while protected by an RCU read-side critical section.

However, the child socket can be destroyed while that operation is still underway. The kernel then frees the associated inet_opt structure using kfree(), leaving another CPU potentially accessing memory that has already been released. The resulting stale reference creates a use-after-free condition in ip_options_build().

A similar race exists during request socket migration, including configurations using net.ipv4.tcp_migrate_req=1 or BPF-based SK_REUSEPORT_SELECT_OR_MIGRATE. The upstream fix replaces the unsafe memory release with RCU-aware freeing, ensuring readers have finished accessing the object before its memory can be reclaimed.

The first issue specifically affects IPv4. The kernel advisory states that IPv6 is not vulnerable to that particular race because tcp_v6_syn_recv_sock() duplicates the relevant options instead of transferring them in the same manner.

Remote exploitation requires specially constructed network traffic and precise manipulation of the race condition. Red Hat notes that the likely outcomes can include a kernel crash, memory corruption, and potentially remote code execution. The lack of authentication and user interaction substantially increases the risk for systems exposing TCP services to untrusted networks.

Anthropic demonstrated that the vulnerability can be transformed into a full remote-root exploit. Its research model targeted a Linux server accepting Multipath TCP connections and used two stages to achieve command execution.

During the first stage, the exploit repeatedly triggers the race and manipulates a length value so the kernel returns additional adjacent memory in a network response. Eventually, one of these responses contains a kernel pointer. That disclosure reveals information about the kernel memory layout and allows the exploit to defeat Kernel Address Space Layout Randomization (KASLR).

During the second stage, the exploit uses the same vulnerability to cause a buffer overflow and overwrite a callback pointer. The pointer is redirected toward a payload previously placed in kernel memory using legitimate protocol functionality. When the kernel invokes the modified callback, existing kernel functions are chained together until an attacker-selected shell command is executed as root.

A particularly important characteristic of the exploit is that losing the race does not necessarily crash the server. Instead, the connection attempt can simply fail, allowing the attacker to retry repeatedly. In Anthropic’s test environment, obtaining a useful kernel pointer took approximately 48 minutes, followed by another five minutes to achieve root command execution.

This demonstration should not be interpreted to mean that MPTCP is required for exploitation. Anthropic demonstrated one successful exploit path involving an MPTCP listener, but the vulnerable code resides in ordinary IPv4 TCP handling. Red Hat explicitly warns that disabling MPTCP does not fully address the vulnerability and that default RHEL installations remain affected even though MPTCP is disabled by default.

The CVE-2026-98432 PoC situation is also important to distinguish from the existence of a complete weaponized exploit. Anthropic developed a functioning remote-root proof of concept internally but has not published it. Public code reported by security researchers can demonstrate or detect aspects of the underlying race and memory disclosure, but the reviewed sources do not document publicly released code reproducing Anthropic’s complete remote code execution chain.

The vulnerability was reported by Anthropic researcher Xinyang Ge. The upstream Linux fix was applied on October 5, 2026, while the Linux kernel CVE record was published on October 15. Anthropic publicly described its full exploitation research on October 27.

The Linux kernel project identifies the following upstream fixed versions:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

The kernel team recommends upgrading to the latest stable kernel rather than cherry-picking individual commits.

Distribution-specific exposure and remediation differ because Linux vendors maintain their own kernels and backport security fixes. Red Hat currently rates the issue Critical at 9.8 and has released fixes for multiple RHEL 8, 9, and 10 streams. OpenShift and layered products that depend on affected RHEL kernels also require attention.

Ubuntu likewise rates the vulnerability Critical at 9.8. Ubuntu 26.10 has received a fixed generic kernel, while fixes for Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS were available in the -proposed testing pocket as of early November, with additional supported releases awaiting fixes. Administrators should use Canonical’s CVE page rather than relying solely on upstream kernel version numbers.

For CVE-2026-98432 detection, security teams should combine network and host telemetry. Potential network-level hunting signals include unusual inbound IPv4 TCP packets carrying IP options, especially repeated connection attempts containing Record Route or Timestamp options and abnormal patterns of SYN retransmission. The presence of such traffic alone does not confirm exploitation, but it provides a useful hunting pivot when correlated with vulnerable systems.

Host-level monitoring should include Linux kernel crashes, kernel warnings, memory-corruption indicators, unexpected service restarts, and anomalous activity immediately following suspicious network traffic. Because successful exploitation could theoretically provide root code execution, defenders should also monitor for unexpected privileged processes, newly created files, configuration changes, persistence mechanisms, and unexplained outbound connections.

There are currently no attacker-specific CVE-2026-98432 IOCs such as confirmed malicious IP addresses, domains, or malware hashes because the reviewed sources have not reported real-world exploitation. Defenders should therefore prioritize behavior-based detection and exposure assessment rather than relying on static indicators.

CVE-2026-98432 Mitigation

The definitive remediation is to install a vendor-provided kernel containing the security fix. The Linux kernel CVE team recommends moving to the latest supported stable kernel, while Linux distribution users should install packages supplied specifically by their vendor because fixes are commonly backported without changing to an upstream kernel version.

Administrators should prioritize internet-facing Linux servers and other systems accepting inbound IPv4 TCP connections. The attack surface is broad because the vulnerability exists in the kernel networking stack rather than in an individual application or server product.

Organizations should take the following steps:

1. Inventory Linux servers and identify the running kernel with tools such as uname -r.
2. Check the relevant Linux distribution’s security advisory rather than determining exposure solely from the upstream version number.
3. Install the vendor-provided fixed kernel as soon as it becomes available.
4. Reboot affected systems after installing the updated kernel to ensure the patched kernel is running.
5. Prioritize internet-facing servers and infrastructure accepting inbound IPv4 TCP traffic.
6. Review externally exposed TCP services and limit unnecessary network accessibility.
7. Continue monitoring vendor advisories because fix availability differs across Linux distributions, kernel variants, cloud kernels, and support channels.

Red Hat and Ubuntu have also documented an interim packet-filtering approach that drops incoming IPv4 TCP packets containing IP options. The recommended nftables condition checks for an IPv4 header length greater than five and drops matching TCP packets before they reach the vulnerable socket-handling path.

This measure can reduce exposure because the known exploitation path requires IPv4 options. However, both vendors warn that packet filtering is not a complete replacement for installing the corrected kernel. It can also interfere with workloads that legitimately depend on IPv4 options and therefore should be tested before production deployment.

Disabling MPTCP alone should not be treated as sufficient protection. Although Anthropic’s working exploit targeted an MPTCP listener, the underlying vulnerability is in normal IPv4 TCP handling. Red Hat specifically notes that RHEL remains vulnerable in its default configuration even though MPTCP is disabled.

For environments using Go applications, disabling automatic MPTCP behavior can reduce exposure to the specific exploit demonstrated by Anthropic, but this remains an incomplete risk-reduction measure. Systems without an MPTCP listener should not automatically be considered safe because other exploitation techniques may target the same underlying race.

Because no real-world compromise campaign has been confirmed, incident-response guidance should currently focus on identifying potentially vulnerable systems and suspicious exploitation behavior rather than searching for a known attacker infrastructure set. Organizations that observe unusual TCP traffic followed by kernel instability or unexpected privileged execution should treat the activity as potentially malicious and preserve network and host telemetry for investigation.

The post CVE-2026-98432: Critical Linux Kernel TCP Flaw Enables Remote Code Execution appeared first on SOC Prime.

On the New-Scale Security Operations Platform, get an access token with your API key, then call the event search API with a filter, a time range and the fields you want. You get JSON back, one row per event. The Search app can also export results from the UI. Older on-premises Exabeam Data Lake deployments work differently; see the FAQ.

Exabeam collects logs for behavior analytics and SIEM, and since its merger with LogRhythm it covers a big share of the market. Prime Core has 15,635 detection rules for Exabeam, mapped to 542 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

An API key. Create a client ID and secret in the platform’s API key settings, with permission to search events.

Your regional API host. It follows the pattern api.<region>.exabeam.cloud, for example api.us-west.exabeam.cloud or api.us-east.exabeam.cloud.

Query syntax. The event search uses Lucene-style filters, the same ones you type in the Search app. Test there first.

Export with the Search API

BASE="https://api.us-west.exabeam.cloud"

# 1. access token
TOKEN=$(curl -sS -X POST "$BASE/auth/v1/token" -H 'Content-Type: application/json' \
  -d "{\"client_id\": \"$EXA_ID\", \"client_secret\": \"$EXA_SECRET\", \"grant_type\": \"client_credentials\"}" \
  | jq -r '.access_token')

# 2. event search
curl -sS -X POST "$BASE/search/v2/events" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "filter": "host:\"web-03\"",
    "startTime": "2026-10-19T00:00:00Z",
    "endTime": "2026-10-20T00:00:00Z",
    "fields": ["*"],
    "limit": 10000
  }' > exabeam_web03_1019.json

jq -c '.rows[]' exabeam_web03_1019.json > exabeam_web03_1019.jsonl

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the .jsonl file.
2. Sanitize.
3. Review. 

When it goes wrong

The post How to Export Exabeam Logs appeared first on SOC Prime.

Generate an API token, run your Spotter query through the Securonix REST API (/ws/spotter/index/search), and save the events as JSON. When the source sent raw text, the original line is usually kept in the raw event field. Spotter in the UI can export results too. 

Securonix pulls in large volumes of activity data for UEBA and SIEM, which makes it a rich place to export an investigation slice from. Prime Core has 14,283 detection rules for Securonix, mapped to 620 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.

Get Started For Free

Before you start

API access. You need a Securonix user that’s allowed to use the API. Tokens are generated with that user’s credentials and have a validity period you choose.

Your tenant URL. Cloud tenants usually look like https://<tenant>.securonix.net/Snypr.

Retention. Hot data is searchable directly in Spotter. Older data may sit in long-term storage that needs extra steps to search. 

Export with the REST API

BASE="https://<tenant>.securonix.net/Snypr"

# 1. token, valid for one day
TOKEN=$(curl -sS -H "username: $SNX_USER" -H "password: $SNX_PASS" -H "validity: 1" \
  "$BASE/ws/token/generate")

# 2. Spotter query for a time window
curl -sS -G -H "token: $TOKEN" "$BASE/ws/spotter/index/search" \
  --data-urlencode 'query=index=activity AND devicehostname="web-03"' \
  --data-urlencode 'eventtime_from=10/19/2026 00:00:00' \
  --data-urlencode 'eventtime_to=10/20/2026 00:00:00' \
  > snx_web03_1019.json

# 3. one event per line
jq -c '.events[]' snx_web03_1019.json > snx_web03_1019.jsonl

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. Look it over before you continue.
3. Review. 

When it goes wrong

The post How to Export Securonix Logs appeared first on SOC Prime.

A high-severity vulnerability in WordPress Core is being actively targeted in attacks, prompting the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add the flaw to its Known Exploited Vulnerabilities (KEV) catalog. Tracked as CVE-2026-119977, the vulnerability carries a CVSS score of 8.1 and can allow an unauthenticated attacker to execute arbitrary code on a vulnerable server during a WordPress Core upgrade.

The vulnerability stems from a time-of-check time-of-use (TOCTOU) race condition in the WordPress upgrade process. During full-package Core updates, WordPress temporarily stages installation files in predictable, web-accessible locations. Attackers can repeatedly probe these locations and attempt to reach installer components during the brief period in which an upgrade is taking place.

WordPress addressed the issue in version 7.1.4, released on October 28, 2026. The vulnerability affects WordPress versions 4.7 through 7.1.3, while security fixes have also been backported to eligible older branches. WordPress stresses that only the latest release is actively supported.

The risk has moved beyond theoretical exploitation. Wordfence telemetry cited by The Hacker News recorded more than 18,500 requests targeting staged setup-config.php installer paths during the first 21 hours after disclosure. CISA subsequently confirmed evidence of exploitation and required applicable U.S. federal civilian agencies to remediate the vulnerability by November 6, 2026.

Security teams can use the SOC Prime Platform to strengthen detection coverage against emerging exploitation techniques and hunt for suspicious activity associated with vulnerable internet-facing systems. Detect CVE-2026-119977 exploitation by monitoring abnormal requests to WordPress upgrade locations, unexpected PHP execution, newly created administrative accounts, suspicious files, and post-exploitation behavior.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

Contact Sales

CVE-2026-119977 analysis

CVE-2026-119977 is classified as a TOCTOU race condition under CWE-367 and has a CVSS 3.1 score of 8.1. Its vector reflects network-based exploitation requiring no privileges or user interaction, with high potential impact on confidentiality, integrity, and availability. Attack complexity is rated high because successful exploitation depends on reaching a vulnerable resource during a narrow upgrade window.

CVE-2026-119977 affects WordPress Core releases from version 4.7 through 7.1.3. The weakness is not tied to a third-party plugin or theme; it exists in the Core software upgrade mechanism itself.

The issue occurs during full-package Core upgrades. WordPress temporarily extracts the new package into a staging location beneath the wp-content/upgrade directory before replacing the existing installation. In affected releases, portions of this staging location can be predictable and reachable from the web while the update is underway.

One particularly important component is the staged setup-config.php installer. An unauthenticated attacker who correctly predicts the temporary path and reaches that component before WordPress completes cleanup may be able to interact with the staged installation and ultimately execute PHP code on the server.

This creates an unusual exploitation model. A vulnerable WordPress site is not necessarily continuously exploitable. Instead, the attacker must catch the site during the brief period in which a full-package upgrade exposes the staging files. Researchers indicate that the opportunity may last only seconds.

Attackers can compensate for that limitation through automation. Rather than making a single request, threat actors can continuously poll potential upgrade paths and wait for a target to begin updating. Wordfence observed attackers repeatedly requesting variations of staged installer locations, demonstrating that real-world actors quickly understood how to target the race condition.

The large volume of observed requests should nevertheless be interpreted carefully. The reported figures represent blocked requests or exploitation attempts and do not mean that every request resulted in successful remote code execution. Exploitation still requires the request to coincide with an active full-package upgrade and other required server conditions.

Wordfence’s initial telemetry showed more than 18,500 requests against staged installer paths in the first 21 hours. GBHackers subsequently reported nearly 59,000 attempts blocked within a 24-hour period, while The Hacker News cited additional telemetry demonstrating continued exploitation activity.

Independent honeypot telemetry cited by The Hacker News recorded exploitation attempts on October 30, further supporting CISA’s decision to classify the vulnerability as actively exploited. CISA’s addition of the flaw to KEV significantly raises the urgency for organizations operating public WordPress infrastructure.

At the time of writing, the reviewed sources do not document a broadly available, publicly validated CVE-2026-119977 PoC repository. However, public exploit code is not required to establish risk because exploitation attempts have already been observed at scale and CISA has confirmed active exploitation.

WordPress 7.1.4 changes the vulnerable upgrade process. According to the available technical reporting, the remediation includes making staging locations less predictable, introducing additional protections against direct access, and preventing staged configuration data from being promoted in an unsafe manner.

WordPress credited security researcher Umut Bayram with reporting the upgrade-process weakness. Version 7.1.4 was released on October 28, 2026, and the CVE record was subsequently published on October 31.

For CVE-2026-119977 detection, defenders should pay particular attention to web requests targeting unusual paths beneath wp-content/upgrade, especially requests referencing staged copies of setup-config.php. Repeated requests across multiple possible staging directories may indicate automated probing attempting to win the race condition.

Successful exploitation can potentially provide remote PHP code execution in the context of the affected web server. Defenders should therefore correlate suspicious upgrade-path requests with subsequent evidence such as unexpected PHP files, modification of WordPress configuration data, unfamiliar administrator accounts, malicious plugins, unusual child processes spawned by the web server, or unexpected outbound connections.

Public reporting has not identified a comprehensive set of attacker-specific CVE-2026-119977 IOCs such as stable command-and-control domains or malware hashes. This makes behavior-based detection particularly important. Requests to predictable staging paths, suspicious activity during an update window, and post-exploitation modifications provide more durable hunting opportunities than relying exclusively on static indicators.

CVE-2026-119977 Mitigation

The primary CVE-2026-119977 mitigation is to update WordPress immediately. WordPress 7.1.4 contains the security fix, and fixes have also been made available or backported for eligible older release branches. Organizations should prioritize migration to the latest actively supported WordPress version rather than relying indefinitely on legacy security backports.

Administrators should take the following actions:

1. Upgrade internet-facing WordPress installations to version 7.1.4 or later.
2. Verify that automatic updates completed successfully rather than assuming that an update was applied.
3. Inventory older WordPress installations, including forgotten development, staging, and legacy sites.
4. Review web server and WAF logs for requests targeting wp-content/upgrade and staged setup-config.php paths.
5. Investigate unexpected PHP files, new WordPress administrator accounts, unauthorized plugins, and unexplained configuration changes.
6. Review outbound connections and web-server child processes for evidence of post-exploitation activity.
7. Ensure WAF protections operate early enough in the request path to cover direct requests to temporary PHP files.
8. Consider restricting direct web access to temporary upgrade directories where operationally feasible.

Web application firewall rules can reduce exposure to automated exploitation attempts, but they should not be treated as a replacement for patching. Because the vulnerable resource can exist temporarily outside the normal WordPress request flow, administrators should verify that their WAF deployment actually inspects direct requests to staged PHP files.

Organizations that upgraded while active exploitation was already underway should also consider retrospective investigation. Completing the update removes the vulnerable behavior but does not prove that the server was not compromised while the vulnerable staging directory was available.

Review access logs surrounding the precise upgrade timestamp. Requests to the affected staging paths occurring immediately before or during the upgrade should receive additional scrutiny. Security teams should then correlate those requests with file-system changes, WordPress account modifications, PHP execution, suspicious network connections, and other post-exploitation indicators.

If compromise is suspected, isolate the affected host where practical, preserve relevant web, application, authentication, and system logs, and collect suspicious files before remediation. Credentials and secrets accessible to the WordPress/PHP process should be considered potentially exposed and rotated based on the findings of the investigation.

CISA’s inclusion of the vulnerability in KEV confirms that remediation should be treated as an immediate operational priority rather than a routine patch-cycle item. Federal Civilian Executive Branch agencies were directed to address the issue by November 6, 2026.

The post CVE-2026-119977: WordPress Core RCE Flaw Exploited During Software Upgrades appeared first on SOC Prime.

Kimsuky detection depends on recognizing the group’s tradecraft in your own telemetry, not just on matching a hash. Kimsuky is a North Korean APT group, and one of its published campaigns impersonates diplomats to deliver LNK files and PowerShell droppers. Those techniques leave traces in ordinary Windows Security logs: script hosts launched from user-writable folders, hidden PowerShell, new services and scheduled tasks, and quiet account changes.

This article covers Kimsuky detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we describe where the logs came from, what LogTotal flagged, which findings hold up against the raw events, and what the response should be.

Get Started For Free

Kimsuky Analysis

The tradecraft in this sample reads more clearly against the group’s background and its recent campaigns, so we start there before turning to the logs.

Who is Kimsuky

Kimsuky is a North Korean state-sponsored APT group focused on intelligence collection. MITRE ATT&CK tracks it as G0094, and vendors also call it APT43, Velvet Chollima, Black Banshee, THALLIUM, Emerald Sleet, TA427, and Springtail. Its activity is believed to align with North Korea’s Reconnaissance General Bureau.

CISA assesses that the group has most likely operated since 2012. The first detailed public report was Kaspersky’s “The Kimsuky Operation” in 2013, and the name comes from an internal code reference Kaspersky researchers found.

Most Kimsuky operations hit South Korea, with others reaching the United States, Japan, Europe, and Russia. Beyond government and policy targets, victims include academics and the cryptocurrency sector. Spear-phishing is its most observed entry point.

Kimsuky activity in 2026

The sample analyzed here dates from 21 September 2026, inside this period. Its dot-padded, PDF-themed LNK, hidden PowerShell, and logon-triggered scheduled task match these campaigns closely.

The log sample

The sample is a single file, Kimsuky.jsonl, with 3,087 events from one domain controller. It shows Kimsuky-style tradecraft executed against a DC in a controlled emulation, which makes it a useful reference for what this activity looks like in native Windows audit telemetry.

Log source and collection

The JSON layout points to an EVTX-to-JSON conversion rather than a SIEM-normalized export. 

What the events contain

Most events are object and handle auditing (4658, 4656, 4663, 4690), token right adjustments (4703), and file share access (5145). These are high-volume and mostly background noise.

The detection-relevant events are far fewer:

• 49 process creations (4688) with full command lines
• Account and group management (4720–4738)
• Service installation (4697)
• Scheduled task lifecycle: created, updated, deleted (4698, 4702, 4699)
• Active Directory object changes (5136)
• Audit policy changes (4719)

Attack context: an emulation, not a live intrusion

The activity is clearly an emulation of Kimsuky tradecraft. Every attacker command has powershell_ise.exe as its parent process. Objects carry test names such as OrbitalTestSvc, adminuserz, and the password !BackdoorPass1. At the end, the operator removes the service, task, user, and group.

The techniques themselves mirror a published Kimsuky campaign in which the group impersonates diplomats and delivers LNK files and PowerShell droppers. That is why the telemetry is valuable: the behaviors are real even though the operator is not.

Detect Kimsuky

LogTotal processed all 3,087 lines in 16.4 seconds and matched 73 rules against 105 lines. It grouped those matches into 9 attack chains on one host, reported 8, and filtered out 1 at the AI verification step.

How LogTotal’s rules map to raw Kimsuky evidence

Kimsuky IOCs and artifacts from this sample

The artifacts below come from an emulation, so the names themselves will not recur in the wild. The patterns behind them are what to hunt for.

Kimsuky Mitigation

Contain the domain controller first, then rebuild trust in its accounts and logging. LogTotal’s response plan covers the essentials; because the target is a DC, the scope needs to widen to the domain.

LogTotal’s recommended response

1. Isolate the host.
2. Image memory and disk.
3. Verify and remove the OrbitalHealthCheck scheduled task.
4. Check and restore the audit policy.
5. Enable PowerShell Script Block Logging and AMSI telemetry.
6. Apply allowlisting for WScript, CScript, and PowerShell.

Additional steps for a domain controller

1. Start the timeline at the 1102 event. The Security log was cleared at 15:02:41 UTC, so anything before it must come from other sources.
2. Collect and hash everything in C:\Users\Public\Downloads\ and %TEMP%, including the LNK, JScript, PowerShell, HTA, and fake smss.Exe.
3. Confirm cleanup. Verify that OrbitalTestSvc, adminuserz, and admingroupz are gone, and revert the Winlogon\SpecialAccounts\UserList value that hides Administrator.
4. Reset credentials. Reset the Administrator password and plan a double krbtgt reset.
5. Hunt domain-wide for dot-padded LNK file names and for script hosts (wscript.exe, cscript.exe, mshta.exe, powershell.exe) launched from user-writable folders.

Hardening against Kimsuky-style tradecraft

The same controls that catch this sample reduce exposure across the domain. Keep 4688 process creation with command lines enabled, since the 49 process events carried most of the evidence. Alert on 4697 service installs and 4698 task creations that launch hidden PowerShell. Treat any 1102 event on a DC as an incident trigger.

The post Kimsuky Detection and Exploitation Analysis appeared first on SOC Prime.

Send a PowerQuery to the Singularity Data Lake API at /api/powerQuery on your regional Data Lake URL, for example https://xdr.us1.sentinelone.net. The response comes back as a table (columns plus rows), and one jq line turns it into one JSON object per event. Alternatively, export events directly from the Singularity console through Event Search. CSV is a commonly available export format, while JSON or plain-text downloads may be available depending on the interface.

Singularity Data Lake holds SentinelOne’s endpoint telemetry alongside any third-party logs you send it, so it’s often the widest view a SentinelOne customer has. Prime Core has 14,699detection rules for SentinelOne, mapped to 644 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.

Get Started For Free

Before you start

A service user with the right permissions. Create a service user for API access and give its role the Data Lake query permissions (SDL Query API and SDL Search). Create it at the account or site level that actually holds the data. A key made at the wrong scope authenticates fine and returns nothing.

Your regional URL. The US is typically https://xdr.us1.sentinelone.net; other regions use their own hostnames. The console’s help section lists yours.

Know the fields. Endpoint telemetry uses names such as endpoint.name, event.type, src.process.cmdline and tgt.process.cmdline. Third-party logs keep their original text in a message field. Try the query in Event Search first.

Export with the PowerQuery API

SDL="https://xdr.us1.sentinelone.net"

curl -sS -X POST "$SDL/api/powerQuery" \
  -H "Authorization: Bearer $S1_SDL_TOKEN" -H "Content-Type: application/json" \
  -d '{
    "query": "endpoint.name = \"WS-042\" | columns timestamp, endpoint.name, event.type, src.process.cmdline, tgt.process.cmdline",
    "startTime": "2026-10-19T00:00:00Z",
    "endTime": "2026-10-20T00:00:00Z"
  }' > sdl_ws042_1019.json

# table -> one JSON object per row
jq -c '.columns as $c | .values[] | [$c, .] | transpose | map({(.[0].name): .[1]}) | add' \
  sdl_ws042_1019.json > sdl_ws042_1019.jsonl

PowerQuery results are capped, so split long windows into several requests.

The columns stage decides what you get. Leave out fields you don’t need, but keep the command lines and process names: that’s where most detections look.

Export logs through the Singularity Data Lake UI

For quick investigations or smaller log samples, you can export events directly from the SentinelOne Singularity console without using the API.

1. Open Event Search. Sign in to the SentinelOne Singularity console and navigate to Event Search. Select the account or site containing your logs.
2. Set the time range. Choose the period you want to investigate and ensure the correct data sources are included.
3. Run a query. Enable PowerQuery and enter a search filter, for example endpoint.name = “WS-042”. Run the search.
4. Review results. Check the matching events and select the fields you need, such as timestamp, endpoint.name, event.type, src.process.cmdline and tgt.process.cmdline. Avoid aggregation functions if you need individual log events.
5. Export the results. Use the Export or Download option in the results area. Depending on the console version and search mode, you may be able to choose between CSV, JSON and plain text.
6. Save the file. Download the results to your computer. Prefer JSON when available, especially for structured endpoint telemetry. For third-party logs, preserve the message field containing the original log text.

Limitations. Export formats and result limits vary by console version and search mode. Large searches can also exceed the UI export limit; narrow the time range or use the Data Lake API for larger datasets.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the .jsonl file. 
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export SentinelOne Singularity Data Lake Logs appeared first on SOC Prime.

Send your query to the LogScale query API, POST /api/v1/repositories/<repo>/query, and ask for application/x-ndjson: you get one event per line. The original log line sits in @rawstring, so one jq call turns the export back into raw logs. Alternatively, export logs directly from the LogScale UI as plain text, JSON or CSV.

LogScale (formerly Humio) is built for high-volume log search, so it often holds the most complete record a team has. Prime Core has 23,747 detection rules for Falcon LogScale, mapped to 674 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.

This guide covers standalone LogScale, cloud or self-hosted. If you use LogScale inside the Falcon console as part of Next-Gen SIEM, the console and its APIs are different.

Get Started For Free

Before you start

A token. Create an API token with permission to query the repository. Treat it like a password.

Base URL and repository. Cloud customers use their region’s URL, such as https://cloud.us.humio.com. Self-hosted clusters use their own hostname. You also need the repository or view name.

Retention. Each repository has its own retention. Check it before you promise anyone a week of history.

Export with the query API

LS="https://cloud.us.humio.com"
START=$(date -d '2026-10-19T00:00:00Z' +%s000)
END=$(date -d '2026-10-20T00:00:00Z' +%s000)

curl -sS "$LS/api/v1/repositories/security/query" \
  -H "Authorization: Bearer $LOGSCALE_TOKEN" \
  -H "Content-Type: application/json" -H "Accept: application/x-ndjson" \
  -d "{\"queryString\": \"host=web-03\", \"start\": $START, \"end\": $END, \"isLive\": false}" \
  > logscale_web03_1019.ndjson

# raw lines only
jq -r '."@rawstring"' logscale_web03_1019.ndjson > logscale_web03_1019.log

The start and end values are epoch milliseconds; relative values like “24h” work too. The date -d syntax is GNU, so on macOS compute the timestamps another way.

Keep the query a filter. Anything that aggregates (groupBy, count, timechart) returns the aggregate, not events. For very long or heavy searches, use the query jobs API, which runs the search asynchronously and lets you poll for results.

Export logs through the Falcon LogScale Search UI

For quick investigations or smaller log samples, you can export events directly from the Falcon LogScale web interface without using the API.

1. Open Search. Sign in to Falcon LogScale, select the repository or view containing your logs, and open the Search page.
2. Run a query. Enter a search filter, for example host=web-03. Set the time range and run the search.
3. Review results. Check that the returned events match what you need. Avoid aggregation functions such as groupBy(), count() or timeChart() if you want individual log events.
4. Export the logs. From the search results, click Save > Export data to file.
5. Choose the file format.
   • Plain text (.txt): Exports the @rawstring field, preserving the original log lines. Best for LogTotal when the source contains syslog-style text.
   • JSON (.json): Exports complete event objects, including parsed fields and metadata. Best when you need structured events.
   • CSV (.csv): Exports selected fields into a table. Useful for reporting, but less suitable for LogTotal. Select ‘Select all’ in ‘Fields to export’.
6. Download. Enter a filename and click Export to save the file locally.

Limitations. Plain-text export requires the original log content to be available in @rawstring. If that field is missing, export the complete events as JSON instead. For large datasets, narrow the time range or use the query API. Non-aggregated search exports may contain events in a different order from the UI results.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file. 
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export Falcon LogScale Logs appeared first on SOC Prime.

Run your search through Sumo Logic’s Search Job API: create a job, wait until it has gathered all results, then page through the messages. Each message carries the original log line in _raw. The Messages tab in the UI can export results too, but not in a format LogTotal reads today.

Sumo Logic is a common cloud SIEM and log platform, and a natural place to pull an investigation slice from. Prime Core has 23,391 detection rules for Sumo Logic, mapped to 664 MITRE ATT&CK techniques. Below is how to get raw logs out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

An access key. Create an access ID and key in Sumo Logic. The key acts with your role’s permissions, so the role needs to be able to run searches on the data you want.

The right API endpoint. Sumo Logic runs several deployments, and each has its own API host: api.sumologic.com for US1, api.us2.sumologic.com, api.eu.sumologic.com and so on. Match it to the URL you use to log in. A wrong deployment gives you a 401 that looks like a bad key.

Cookies. The Search Job API needs cookies kept between calls, because a job lives on a specific backend node. Without a cookie jar, follow-up calls can fail to find the job.

Limits. A job returns a capped number of messages, and each page holds up to 10,000. Keep time windows tight.

Export with the Search Job API

API="https://api.sumologic.com/api/v1"
AUTH="$SUMO_ACCESS_ID:$SUMO_ACCESS_KEY"
JAR=$(mktemp)

# 1. create the search job
JOB=$(curl -sS -u "$AUTH" -c "$JAR" -b "$JAR" -H 'Content-Type: application/json' \
  -X POST "$API/search/jobs" -d '{
    "query": "_sourceCategory=linux/secure _sourceHost=web-03",
    "from": "2026-10-19T00:00:00", "to": "2026-10-20T00:00:00",
    "timeZone": "UTC"
  }' | jq -r '.id')

# 2. wait until all results are gathered
until curl -sS -u "$AUTH" -c "$JAR" -b "$JAR" "$API/search/jobs/$JOB" \
      | jq -e '.state == "DONE GATHERING RESULTS"' >/dev/null; do sleep 5; done

# 3. page through the messages, keeping the raw lines
COUNT=$(curl -sS -u "$AUTH" -c "$JAR" -b "$JAR" "$API/search/jobs/$JOB" | jq '.messageCount')
for ((off=0; off<COUNT; off+=10000)); do
  curl -sS -u "$AUTH" -c "$JAR" -b "$JAR" "$API/search/jobs/$JOB/messages?offset=$off&limit=10000" \
    | jq -r '.messages[].map._raw'
done > web-03_sumo_1019.log

# 4. clean up
curl -sS -u "$AUTH" -c "$JAR" -b "$JAR" -X DELETE "$API/search/jobs/$JOB" >/dev/null

Keep the query to a plain filter. Queries with aggregation operators return records, not messages, and records don’t carry _raw. For structured output, write jq -c ‘.messages[].map’ instead, which gives one JSON object per line with all fields.

If a job is cancelled, the wait loop never ends. Add a check for CANCELLED if you script this for regular use.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export Sumo Logic Logs appeared first on SOC Prime.

On most distributions, two group memberships cover nearly everything an analyst needs: adm for the text logs in /var/log on Debian and Ubuntu, and systemd-journal for the full system journal. Add the account with sudo usermod -aG adm,systemd-journal <user> and start a new login session. A few logs stay root-only by design, notably /var/log/secure and /var/log/messages on Red Hat-family systems and everything under /var/log/audit. For those, use narrowly scoped sudo, not a root shell.

Giving someone root just so they can read logs is the kind of shortcut that shows up in the next audit, or the next incident. This guide covers the least-privilege way, plus the traps that make “just add them to a group” less simple than it sounds.

Get Started For Free

Who can read what

Exact ownership varies with distribution and version, so check on the box itself:

id
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
getfacl /var/log/journal 2>/dev/null

Option 1: Group membership

sudo usermod -aG adm,systemd-journal analyst

Two details matter. The -a is not optional: without it, usermod -G replaces the user’s groups instead of adding to them. And group changes only apply to new sessions. Log out and back in, or start a fresh login shell, before testing. “I added the group and it still says permission denied” is almost always an old session.

On Red Hat-family systems, adm doesn’t unlock /var/log/secure or /var/log/messages. Those files are root-only there. Use Option 2 or 3.

Option 2: Narrow sudo for root-only logs

Grant specific commands, not a shell. Create /etc/sudoers.d/log-readers with visudo -f:

%logreaders ALL=(root) NOPASSWD: /usr/sbin/ausearch, /usr/local/bin/read-secure-log

read-secure-log is a small root-owned script (mode 0755, owned by root) that does exactly one thing:

#!/bin/sh
exec /usr/bin/zcat -f /var/log/secure /var/log/secure-*

Why a wrapper instead of cat /var/log/secure* in sudoers? Because a * in a sudoers argument matches anything, spaces included. cat /var/log/secure /etc/shadow matches cat /var/log/secure*. A wrapper with no arguments has no such hole.

Don’t grant journalctl through sudo. It opens a pager (less), and !sh inside less gives you a root shell. For journal access, use the systemd-journal group instead.

Option 3: Group ownership that survives rotation

Setting an ACL directly works until the next rotation: sudo setfacl -m g:logreaders:r /var/log/secure. Then the file is recreated, and the ACL is gone. To make access stick, have new files created with the right group in the first place, in both places that create them:

• logrotate, in the file’s stanza: create 0640 root logreaders
• rsyslog, on the action that writes it: action(type=”omfile” file=”/var/log/secure” fileGroup=”logreaders” fileCreateMode=”0640″)

Test it with logrotate -f on a non-production box before rolling it out.

Containers

Don’t add analysts to the docker group just to read container logs. Membership in docker is effectively root on that host. Get container logs from your log collector or SIEM instead, or ask the platform team for read-only access there.

When it goes wrong

The post How to Read Linux Logs Without Root (Permissions Guide) appeared first on SOC Prime.

Canonical has released security updates addressing CVE-2026-112816, a critical authentication bypass vulnerability affecting LXD and MicroCloud. The flaw carries a maximum CVSS score of 10.0 and can allow an unauthenticated remote attacker to impersonate a trusted TLS client without possessing that client’s private key.

Successful exploitation can provide access to the LXD or MicroCloud API with the privileges assigned to the impersonated identity. When the trusted identity has sufficient permissions, an attacker may gain full access to the cluster, managed virtual machines, and potentially root-level access to the underlying host.

The vulnerability stems from improper validation of client certificate chains used for mutual TLS authentication. Instead of authenticating only the leaf certificate for which the client proves possession of the corresponding private key, vulnerable implementations compare every certificate supplied in the client-controlled chain against trusted certificates.

An attacker who can reach the HTTPS API and obtain the public certificate of an already trusted client can therefore append that certificate behind an attacker-controlled leaf certificate and be accepted as the trusted identity.

Canonical disclosed the issue in late October 2026 after the vulnerability was referred by the Incus project. Fixed LXD and MicroCloud releases are now available, and administrators are strongly advised to update immediately.

The flaw is especially significant in infrastructure environments because LXD manages system containers and virtual machines, while MicroCloud coordinates clustered infrastructure. Compromise of an administrative identity can therefore extend beyond a single service and provide control over workloads or the host itself.

For CVE-2026-112816 detection, security teams should prioritize identifying internet- or network-accessible LXD and MicroCloud HTTPS APIs, reviewing trusted client certificates, and correlating successful certificate-based authentication with unexpected source systems or unusual administrative operations.

SOC Prime’s AI-Native Detection Intelligence Platform enables security teams to strengthen coverage for exploitation and post-compromise behavior across network, Linux, cloud, container, and identity telemetry.

Contact Sales

Click Explore Detections to access relevant detection content and hunting logic. To Detect CVE-2026-112816, defenders should combine vulnerable-version inventory with API access monitoring, certificate authentication telemetry, and suspicious administrative activity affecting containers, virtual machines, or cluster configuration.

CVE-2026-112816 analysis

CVE-2026-112816 is an improper certificate validation vulnerability in the HTTPS listener used by Canonical LXD and MicroCloud.

Both products can use mutual TLS to authenticate remote clients. Under normal mTLS behavior, the connecting client presents a certificate and proves ownership of the private key associated with the certificate used as the leaf of the TLS chain.

The problem arises because vulnerable LXD and MicroCloud implementations inspect more than that authenticated leaf certificate.

According to Canonical, remote API authentication logic compared all certificates presented by a client against entries in the trusted certificate store. However, TLS proves private-key possession only for the leaf certificate. Additional certificates in the presented chain are supplied by the client and do not independently prove ownership of their corresponding private keys.

This creates an authentication gap.

An attacker can generate a certificate and private key they control, use that certificate as the leaf, and append the public certificate of a trusted client elsewhere in the presented chain. The vulnerable server may find the trusted certificate and associate the connection with that trusted identity even though the attacker does not possess its private key.

The details for CVE-2026-112816 therefore show that exploitation depends primarily on two prerequisites:

• The attacker can reach the LXD or MicroCloud HTTPS API.
• The attacker possesses the public certificate of an identity already trusted by the target.

The trusted client’s private key is not required.

This distinction explains the vulnerability’s critical severity. Certificate-based authentication is expected to demonstrate possession of a secret private key, but the affected logic effectively allows possession of the public certificate alone to satisfy part of the trust decision.

A standalone LXD installation does not expose its remote HTTPS API by default. The Hacker News notes that LXD normally listens only on its local Unix socket unless an administrator enables network access, for example through the core.https_address configuration.

This means not every vulnerable LXD installation is remotely exploitable from another host.

Exposure becomes significantly higher when administrators enable the API across a management network or expose it to the internet.

MicroCloud presents another relevant attack scenario. Canonical states that an attacker who can intercept the public TLS certificate of a machine joining a MicroCloud cluster may subsequently authenticate as that joined member.

CVE-2026-112816 affects vulnerable Canonical LXD releases including 4.0.14, 5.0.10, 5.21.8, and 6.9 before their corresponding fixed releases.

Canonical lists these patched LXD versions:

• LXD 6.10.1 for the 6/stable channel
• LXD 5.21.9 for 5.21/stable
• LXD 5.0.11 for 5.0/stable
• LXD 4.0.15 for 4.0/stable

For MicroCloud, fixed versions are:

• MicroCloud 3.4.1 for 3/stable
• MicroCloud 2.1.5 for 2/stable

Ubuntu’s CVE record describes successful exploitation as allowing an unauthenticated attacker to authenticate as a trusted client and gain full access to the cluster and managed virtual machines through a crafted certificate chain.

The maximum CVSS score of 10.0 reflects network accessibility, low attack complexity, no required privileges, and no user interaction, combined with potentially high impact to confidentiality, integrity, and availability.

Impact ultimately depends on the privileges of the identity being impersonated.

A restricted identity may provide limited API capabilities. A highly privileged client or cluster identity can provide substantially greater access.

Canonical explicitly warns that impersonation of a privileged trusted user can result in root access to the host machine.

That can potentially allow an attacker to:

• Manage or modify containers and virtual machines.
• Access workloads managed through the compromised LXD environment.
• Modify infrastructure configuration.
• Create new workloads or alter existing ones.
• Interfere with availability.
• Access data available to the impersonated identity.
• Potentially reach the host with root-level privileges when sufficient permissions are available.

The flaw was originally identified in the related Incus project and then referred to Canonical, which confirmed that the same certificate-chain authentication problem affected LXD.

Incus describes the underlying issue similarly: the server requested client certificates without verifying the entire submitted chain, while trust checks iterated across every supplied peer certificate rather than restricting authentication to the actual leaf certificate. Incus addressed the issue in version 7.6.0.

The vulnerability appears to have existed for an extended period. Incus states that the equivalent authentication logic had been present since its initial release. Canonical’s public advisory does not provide an exact date for when the vulnerable LXD behavior was first introduced.

As of November 2, 2026, an independent CVE-2026-112816 PoC and lab reproduction have been published publicly. This represents a change from The Hacker News report published on November 1, which stated that no working exploit had yet been released. The public reproduction appeared after disclosure and is not the original vulnerability research.

Canonical and the referenced reporting have not indicated that the vulnerability has been exploited in real-world attacks.

The Hacker News reports that the issue was not known to be exploited as of the U.S. CISA assessment dated October 30 and was not included in CISA’s Known Exploited Vulnerabilities catalog at that time.

There are therefore no campaign-specific CVE-2026-112816 IOCs such as confirmed malicious IP addresses, domains, malware hashes, or known attacker infrastructure associated with exploitation.

Defenders should instead focus on vulnerability exposure and behavior.

Potential hunting opportunities include:

• Remote connections to LXD or MicroCloud HTTPS APIs from unexpected systems.
• Successful API authentication originating from networks not normally used by trusted administrators.
• A trusted certificate identity appearing from multiple unrelated source systems.
• Administrative API activity that does not match the expected owner of a certificate.
• Unexpected creation, deletion, or modification of containers and virtual machines.
• Changes to trusted certificate entries.
• New or altered cluster members.
• Unexpected changes to storage, networking, profiles, projects, or instance configuration.
• Privileged operations occurring shortly after unusual certificate-based authentication.
• API connections to management interfaces that were not intended to be remotely accessible.

Organizations should also inventory trusted certificates associated with former administrators, retired hosts, automation systems, and cluster members.

Because exploitation requires the public certificate rather than the private key, defenders should not treat the confidentiality of private keys alone as sufficient protection against this specific vulnerability.

Monitoring should also account for shared management networks.

An API that is not exposed directly to the public internet can still be exploitable by an attacker who has already gained a foothold on another system capable of reaching the management interface.

This makes lateral movement particularly relevant. A compromised workstation, server, CI/CD runner, management host, or cloud workload with network access to the LXD API could provide the position needed to exploit an otherwise internally exposed system.

CVE-2026-112816 Mitigation

Canonical recommends upgrading affected LXD and MicroCloud deployments to the latest fixed versions immediately.

For Snap-based deployments, administrators can update using:

sudo snap refresh lxd

and:

sudo snap refresh microcloud

After refreshing, verify the version actually installed rather than assuming that the update was applied successfully.

Canonical noted during disclosure that some LXD point releases were progressing from candidate to stable channels. Administrators should therefore explicitly confirm that their system is running one of the fixed versions.

The primary CVE-2026-112816 mitigation is upgrading to:

Canonical has not published a configuration-based workaround that fully eliminates the underlying authentication defect.

If immediate upgrading is impossible, restrict network access to the HTTPS API as aggressively as operational requirements allow.

Only authorized management hosts and trusted infrastructure should be able to establish connections to the listener.

For LXD installations that do not require remote management, administrators should evaluate whether the network API needs to remain enabled at all.

For environments that require remote access:

• Restrict the API using host or network firewalls.
• Permit connections only from dedicated management networks.
• Avoid exposing the API directly to the public internet.
• Use VPN or bastion-based administrative access where appropriate.
• Segment container and virtualization management infrastructure from user networks.
• Monitor all successful administrative API requests.
• Review trusted certificates and remove entries that are no longer necessary.

These controls reduce exposure but do not correct the vulnerable certificate-validation logic.

Organizations running MicroCloud should prioritize updating all relevant cluster members and review recent joining activity for unexpected systems or certificate identities.

Administrators should also review their trusted certificate stores.

Remove certificates belonging to decommissioned hosts, former administrators, unused automation systems, or identities that no longer require access.

Where suspicious activity is discovered, investigate the affected host and cluster before rotating credentials or modifying evidence.

Relevant sources of telemetry may include:

• LXD and MicroCloud service logs
• Linux system logs
• Firewall and network flow records
• Reverse proxy telemetry, if applicable
• Host EDR data
• Cloud network logs
• Cluster configuration and membership history
• Administrative change records

Look for unexpected instance creation, modification, deletion, snapshot activity, storage operations, networking changes, and configuration updates.

If exploitation is suspected and a privileged certificate identity was impersonated, defenders should treat potential host-level compromise seriously because Canonical confirms that root access may be possible depending on the victim identity’s permissions.

Incident responders should preserve relevant evidence and inspect the system for persistence, unauthorized accounts or certificates, modified services, new workloads, suspicious processes, and abnormal outbound network communication.

Organizations using Incus rather than Canonical LXD should separately update to Incus 7.6.0 or the relevant supported fixed release because the related project was affected by the same underlying certificate-chain trust issue.

Ubuntu also notes that its archive-packaged LXD versions for currently listed Ubuntu releases are either not shipped through the affected package path or not affected, while Canonical’s security guidance focuses on the Snap releases. Administrators should still verify the actual LXD distribution and version running in their environment rather than assuming exposure based solely on the Ubuntu release.

Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

The post CVE-2026-112816: Critical LXD and MicroCloud Authentication Bypass Enables Cluster Takeover appeared first on SOC Prime.

tl;dr

Prime Detect runs detection rules on your clients’ event streams before data reaches the SIEM. It applies Sigma rules to events in transit, tags each match with a severity and a MITRE ATT&CK technique, and links related matches into attack chains. In client testing, about 7% of telemetry was tagged.

MSSPs use Prime Detect to give every client the same 20,000+ detections regardless of which SIEM that client runs, to send less data into SIEMs they pay to operate, and to keep each client’s data inside its own pipeline. It works alongside the SIEMs you already run. It does not replace them.

Contact Sales

Why MSSPs are moving detection ahead of the SIEM

An MSSP’s detection coverage is usually set by whatever each client’s SIEM can hold. That creates three problems that grow with every client you add.

• Uneven coverage. Clients run different SIEMs with different rule limits. The same threat can be caught for one client and missed for another, depending on the platform underneath.
• Ingest cost. Where you operate the SIEM, every event ingested is a cost against your margin, whether it carries a threat signal or not.
• Engineering load. Your detection engineers spend their time porting and tuning the same rules across platforms instead of building the detections clients actually pay for.

Prime Detect moves detection upstream. Rules run on events as they stream through the pipeline, before any SIEM ingests them. Coverage depends on the compute you assign, not on each client’s SIEM. You then decide, per client, what reaches the SIEM.

What Prime Detect does

Detection in the stream

• Applies Sigma rules to events in transit, before SIEM ingest
• Runs 20,000+ detection rules plus your own custom detections, with no fixed rule ceiling
• Tags every match with a severity and a MITRE ATT&CK technique
• Links related matches into attack chains, so analysts see a sequence of activity instead of isolated alerts

Tagged telemetry you can route

• Tags about 7% of telemetry, based on client testing
• Sends tagged events to the SIEM and the rest to warm or cold storage, by your rules
• Produces structured, ATT&CK-labeled events that AI triage and SOAR tools can use directly

Deployment and control

• Runs on Kafka and Kubernetes you or your clients operate
• Keeps data inside the pipeline, with no outbound connection required
• Deploys air-gapped or in the cloud
• Available open source or under an Enterprise license

How it fits with the SIEMs you already run

Prime Detect sits between the event pipeline and the SIEM. Nothing in the SIEM has to change, so it works across a mixed client base.

MSSPs typically deploy it in one of two ways:

• Shared, multi-tenant: one Prime Detect deployment in your environment, with detections and routing set per tenant.
• Per client: a deployment inside the client’s own infrastructure, for clients with strict data residency or air-gap requirements.

Rollout follows the same three steps either way:

1. Forward everything to the SIEM as today, with Detect tags added to matched events.
2. Add a SIEM index or dashboard that raises Detect-tagged events as high-priority alerts.
3. Once tuned, route untagged events to warm or cold storage to cut ingest.

What Prime Detect does not do

• It does not replace the SIEM for centralized logging, search, investigation, or retention.
• It does not decide whether an incident is significant or reportable. Your incident process makes that call.
• It does not make data transfer decisions for you. Where data goes, and under which agreement, stays with your firm and your clients.

NIS2, DORA, HIPAA, and GDPR: where Prime Detect fits

MSSPs carry their own obligations and inherit their clients’. NIS2 defines managed security service providers in Article 6(40) and lists them in Annex I, so many MSSPs are covered entities in their own right. Prime Detect supports the detection side of each rule below. It does not discharge any of them alone.

Sell coverage, not ingest

Most MSSPs price and staff around SIEM volume. That ties margin to how much data clients send, and ties coverage to which platform each client happens to run.

Prime Detect separates the two. Every client gets the same detection baseline. You send the SIEM only the events that matter. Each tenant gets an ATT&CK-mapped record of what you detected, which is the evidence regulated clients need to show oversight of their provider. Your engineers spend their time on the detections that set your service apart.

See it run. Watch Prime Detect work against a live event stream before you commit to a pilot. Request a demo, explore the live demo, or download the open source version to run it yourself.

The post Pre-SIEM Detection for MSSPs appeared first on SOC Prime.

tl;dr

Prime Detect runs detection rules on your event stream before data reaches the SIEM. It applies Sigma rules to events in transit, tags each match with a severity and a MITRE ATT&CK technique, and links related matches into attack chains. In client testing, about 7% of telemetry was tagged. That is the slice worth sending to your SIEM.

Large organizations use Prime Detect to run 20,000+ detections without SIEM rule limits, cut what they pay to ingest, and keep a mapped record of what they detect for regulations such as DORA and NYDFS. It works alongside your existing SIEM. It does not replace it.

Contact Sales

Why banks are moving detection ahead of the SIEM

A SIEM runs detection rules against data it has already ingested and indexed. For a large bank, that model hits two limits.

Rule capacity. Most SIEM deployments run a few hundred active rules before search performance and cost become a problem. A team running 500 of them is choosing what not to see.

Ingest cost. Every event the SIEM ingests is an event you pay to store and search, whether or not it carries a threat signal.

Prime Detect moves detection upstream. Rules run against events as they stream through your Kafka pipeline, before ingest. Rule count is tied to the compute you give it, not to SIEM capacity. You then decide what reaches the SIEM based on what the rules found.

Regulators set the floor. DORA Article 10 requires mechanisms to promptly detect anomalous activity. NYDFS Part 500 requires larger covered entities to centralize logging and security alerting. Neither sets a rule count, but both expect you to show that your detection program works. More detections, each mapped to ATT&CK, give you broader coverage and a clearer record of it.

What Prime Detect does

Detection in the stream

• Applies Sigma rules to events in transit, before SIEM ingest
• Runs 20,000+ detection rules plus your own custom detections, with no fixed rule ceiling
• Tags every match with a severity and a MITRE ATT&CK technique
• Links related matches into attack chains, so analysts see a sequence of activity instead of isolated alerts

Tagged telemetry you can route

• Tags about 7% of telemetry, based on client testing
• Sends tagged events to the SIEM and the rest to warm or cold storage, by your rules
• Produces structured, ATT&CK-labeled events that AI triage and SOAR tools can use directly

Deployment and control

• Runs on the Kafka and Kubernetes your team already operates
• Keeps data inside your pipeline, with no outbound connection required
• Deploys air-gapped or in the cloud
• Available open source as DetectFlow, or under an Enterprise license

How it fits with your existing SIEM

Prime Detect sits between your event pipeline and your SIEM. Nothing in the SIEM has to change. Most teams roll it out in three steps:

1. Forward everything to the SIEM as today, with Detect tags added to matched events.
2. Add a SIEM index or dashboard that raises Detect-tagged events as high-priority alerts.
3. Once tuned, route untagged events to warm or cold storage to cut ingest.

You can change the routing at any point as you learn what works in your environment.

What Prime Detect does not do

• It does not replace your SIEM for centralized logging, search, investigation, or retention.
• It does not satisfy the NYDFS centralized logging requirement on its own.
• It does not decide whether an incident is material or reportable. Your team makes that call.

DORA, NYDFS, and SEC: where Prime Detect fits

These rules set detection, incident, testing, and disclosure duties for the banks they cover. Prime Detect supports the detection side of each. It does not discharge any of them alone.

The detection record examiners ask about

When an examiner asks how a bank detects threats, the answer is usually a list of SIEM rules. With Prime Detect, every detection is mapped to ATT&CK and tagged at the event level. You can show what you were watching for, what fired, and how related activity chained together.

That is the record DORA’s incident process and NYDFS’s 72-hour notice depend on. When an incident happens, the work of building it should already be done.

See it run. Watch Prime Detect work against a live event stream before you commit to a pilot. Use the default user name and passwords listed. Request a demo, explore the live demo, or download DetectFlow to run it yourself.

The post Pre-SIEM Detection for Financial Services appeared first on SOC Prime.