Security operations teams work with enormous amounts of telemetry every day. Google SecOps provides structured search capabilities that help analysts investigate security events across different data sources.
In many investigations, analysts can rely on the Unified Data Model (UDM) to search normalized security data. However, there are situations where the information an analyst needs may exist only in the original log.
This is where Raw Log Search in Google SecOps becomes particularly useful.
Raw Log Search allows security analysts to examine the original log data and search for information that may not be available through normalized UDM fields. It can be valuable for threat hunting, incident investigation, troubleshooting parsing issues, and validating what a security product actually reported.
What is Raw Log Search in Google SecOps?
Google SecOps processes incoming security logs and converts relevant information into a structured format known as the Unified Data Model.
UDM makes security investigations easier because similar information from different products can be represented using standardized fields.
For example, an IP address, hostname, username, or network connection can be searched using structured fields rather than searching the entire text of a log.
However, not every piece of information from an original log is necessarily available as a UDM field.
A vendor-specific attribute, command-line argument, filename, registry value, application message, or other piece of text may remain visible only in the original log.
Raw Log Search allows an analyst to search that original information.
In simple terms:
UDM Search: Search structured security information.
Raw Log Search: Search the original log message.
Both approaches are useful, but they serve different purposes.
When should you use Raw Log Search?
Raw Log Search is particularly helpful when you know or suspect that a specific piece of information exists in the original telemetry.
Common examples include:
- Usernames
- Filenames
- Command-line arguments
- Registry keys
- Domains
- URLs
- IP addresses
- Hashes
- Vendor-specific fields
- Application messages
- HTTP-related information
- Data from logs that have not been parsed correctly
For example, imagine that an endpoint log contains a suspicious command-line argument, but you cannot find that value in the expected UDM field.
Instead of assuming that the information was not collected, you can search the raw logs.
This helps answer an important investigation question:
Was the information never ingested, or was it ingested but not normalized into the expected UDM field?
That distinction can be extremely useful during security investigations.
How to perform a basic raw-log search
In the Google SecOps investigation interface, you can use the raw search syntax to look for a specific string.
A basic query looks like this:
raw = "example.com"
This searches the available raw log data for the specified value.
You can replace the example with an investigation artifact such as a hostname, domain, username, filename, IP address, or other distinctive value.
For example:
raw = "suspicious-domain.com"
Or:
raw = "powershell.exe"
The results allow the analyst to examine the original log information associated with the search term.
The most effective searches usually start with a distinctive artifact rather than a very generic keyword.
Searching for something highly specific can reduce noise and make the investigation easier to follow.
Searching raw logs with regular expressions
Sometimes you are not looking for one exact value.
You may instead want to identify a pattern.
Google SecOps supports regular expressions for raw-log searches.
For example:
raw = /AB*C/
Regular expressions can be useful when several log entries share a recognizable structure but do not contain exactly the same text.
They can help with investigations involving patterns in hostnames, filenames, identifiers, application messages, or other log content.
However, regular expressions should be used carefully. An overly broad pattern can return a large number of unrelated results and make an investigation unnecessarily difficult.
A good approach is to begin with a relatively specific pattern and expand it only when necessary.
Searching unparsed logs
One of the most useful applications of Raw Log Search is investigating logs that have not been successfully parsed.
When a log is properly parsed, important information can be represented as structured UDM fields.
When parsing fails, however, the original data may still be present even though the expected structured event is unavailable.
You can use a raw-log query together with the parsing status to investigate this situation.
For example:
raw = /.+/ parsed = false
This can help identify raw logs that have not been parsed.
You can then investigate whether the affected logs are coming from a particular security product or log source.
This is particularly valuable for security engineering teams because an apparent lack of searchable information does not always mean that the underlying telemetry is missing.
The information may simply not have been normalized.
Filtering raw logs by log source
Large environments can generate an enormous amount of security telemetry.
A search for a common term across every log source may produce too many results.
Filtering the investigation by log source can make the search much more useful.
For example:
raw = "failed login" log_source IN ["OKTA"]
The exact log-source name depends on the telemetry configured in your Google SecOps environment.
Source filtering is especially useful when the same keyword can occur in multiple products.
For example, the phrase “authentication failure” could appear in identity-provider logs, endpoint logs, VPN logs, operating-system logs, and application logs.
Restricting the search to the relevant source helps analysts focus on the evidence that matters to the investigation.
Raw Logs vs UDM Search
Raw Log Search and UDM Search should not be viewed as competing methods.
They complement each other.
UDM Search is generally more appropriate when the information you need is already represented in a structured field.
For example:
principal.ip = "192.0.2.10"
A structured query provides a precise way to search a known field.
Raw Log Search becomes more useful when you need to investigate the original message itself.
Consider a security event containing a command line.
The command may be present in the original endpoint log but not available in the UDM field you expected.
A raw search can help determine whether the command-line information exists in the original telemetry.
This creates a useful investigation workflow:
Start with UDM → Identify a gap → Search the raw log → Compare the results → Continue the investigation.
Investigating parsing and normalization gaps
Raw Log Search can also help security teams improve their telemetry quality.
Suppose an analyst expects to find a particular value in a UDM field but receives no results.
There are several possibilities.
The value may not have been generated by the source system. The log may not have been ingested. The information may exist in a different field. Or the information may exist in the raw message but have not been normalized correctly.
Raw-log investigation helps distinguish between these possibilities.
For example, suppose an endpoint generates a log containing:
User: administrator
Command: powershell.exe -enc <value>
Host: workstation-01
If the expected command-line field does not contain the PowerShell information, an analyst can search the raw log for:
raw = "powershell.exe"
If the original message appears in the results, the investigation can move toward understanding the parsing or normalization behavior.
This makes Raw Log Search useful not only to SOC analysts but also to detection engineers and security platform administrators.
Searching for suspicious indicators
Raw logs can be particularly useful during threat hunting.
An analyst may receive an indicator such as:
- A suspicious domain
- An IP address
- A file name
- A hash
- A command-line fragment
- A registry path
- A user account
- A specific application message
The analyst can search the raw telemetry for that artifact.
For example:
raw = "suspicious-domain.com"
After identifying matching entries, the analyst can examine the surrounding event information and determine which system generated the log.
The investigation can then move from the raw evidence toward related events, entities, users, hosts, and network activity.
This helps transform a simple indicator search into a broader investigation.
Narrow your searches whenever possible
One of the most common mistakes when searching raw logs is starting with an excessively broad query.
Searching for a common term such as:
raw = "error"
could potentially produce a huge number of results.
Instead, begin with a more distinctive value.
For example:
raw = "powershell.exe -enc"
or:
raw = "specific-hostname"
You can then refine the search using additional filters and a narrower investigation time range.
A focused search generally makes it easier to identify relevant activity and reduces unnecessary noise.
Understanding the investigation context
A raw-log match should not automatically be treated as evidence of malicious activity.
A string appearing in a log simply means that the value exists in the telemetry.
For example, finding:
raw = "powershell.exe"
does not by itself prove that PowerShell was used maliciously.
The analyst should examine the surrounding context.
Questions worth asking include:
- Which host generated the event?
- Which user was involved?
- When did the activity occur?
- What process generated the event?
- What command was executed?
- Was the activity expected?
- Were there related network connections?
- Did similar events occur on other systems?
- Does the activity correspond with known administrative behavior?
Raw logs provide evidence, but the surrounding context is what helps an analyst interpret that evidence correctly.
Using Raw Log Search as part of threat hunting
Threat hunting often involves searching for evidence that may not correspond to a predefined detection rule.
Raw Log Search can help hunters investigate unusual artifacts across collected telemetry.
A practical workflow is to begin with a hypothesis.
For example:
“I want to determine whether a particular command-line pattern appears in endpoint telemetry.”
The analyst can search for the pattern in raw logs and then examine matching events.
If relevant activity is found, the analyst can pivot into UDM-based investigation to identify affected assets, users, timestamps, and related events.
This combination of raw and structured searching can provide a more complete view of an investigation.
Documenting findings from raw logs
Raw-log evidence can also be valuable when documenting security investigations.
When recording findings, analysts should capture the relevant information needed to reproduce or understand the investigation.
This can include:
- The search term
- Relevant time range
- Log source
- Affected host or user
- Important raw-log content
- Associated UDM event
- Investigation findings
- Actions taken
Maintaining clear investigation notes helps other analysts understand how a conclusion was reached and makes future investigations easier.
Organizations should also apply their internal security, privacy, access-control, and data-retention requirements when handling raw security logs.
Best practices for Raw Log Search
A few practical habits can make raw-log investigations more effective.
Start specific. Search for a distinctive indicator before trying broad keywords.
Use UDM when appropriate. If the information is already available in a structured field, use UDM Search for efficient investigation.
Use raw logs to validate assumptions. When expected data is missing, check whether it exists in the original telemetry.
Filter by source. Narrowing the search to the relevant log source can significantly reduce noise.
Use an appropriate time range. Investigating the period relevant to the incident makes results easier to interpret.
Investigate context. A raw-log match is not automatically suspicious. Examine the surrounding activity.
Look for parsing gaps. If valuable information exists in raw logs but not in UDM, investigate whether parsing or normalization needs attention.
Raw Log Search is an important capability for security analysts working with Google SecOps.
UDM provides the structured foundation for efficient security investigations, while raw logs provide visibility into the original telemetry behind those events.
The two approaches work best together.
Use UDM Search when you need structured security information. Use Raw Log Search when you need to inspect the original message, investigate unparsed data, search for information that was not normalized, or determine why expected information is missing.
For threat hunters, SOC analysts, detection engineers, and security administrators, understanding this distinction can make investigations more systematic and help uncover information that might otherwise remain hidden inside the original security telemetry.