55% of organizational data is unknown or unused. That’s what Splunk found in a survey of more than 1,300 business and IT leaders, and most of that “dark” data, it said, was log data.
In security operations, this is a risk. Teams typically analyze only a small part of their logs, and the rest may contain evidence of suspicious activity never to be investigated. Attackers who use valid credentials or avoid known detection signatures can leave traces in this data without triggering alerts. The challenge is making better use of the data organizations already collect to identify risks that might otherwise go unnoticed.
Why so much data goes unanalyzed
Collecting data is easier than making it useful. Even when events are available in Splunk, the systems analyzing them may not know what to look for, how events relate across sources, or why those relationships matter.
1. Rules only find what you tell them to look for
Detection rules work well when you know what you're looking for. But they depend on the patterns, fields, and data sources they've been designed to examine. They struggle when suspicious activity doesn't match an expected pattern, and maintaining coverage across a large, constantly changing environment is difficult. It's like searching a forest with a flashlight.
2. Specialized tools don't connect the whole picture
Adding specialized tools can improve detection and investigation, but each tool sees the environment through its own lens. An alert triage tool might identify a suspicious login, while an endpoint tool records a downloaded file and a network tool captures its connections. Unless those findings are connected, the relationship between them can remain hidden. In its State of Security 2025 report, Splunk found that 78% of security leaders said their security tools were dispersed and disconnected.
3. Connected events still need business context
Even when events are connected, someone still needs to decide what they mean for the business. Which systems handle sensitive data? Which assets are critical? Which compliance obligations apply? Without that context, an investigation can identify suspicious activity without establishing what matters most or what needs attention first.
Investigating Splunk data with Juno in three questions
To see how Juno handles these problems, we connected it to a test Splunk environment containing about an hour of realistic enterprise activity for a health-tech company across more than 20 sourcetypes, including sign-ins, AWS, Microsoft 365, endpoints, firewalls, and network traffic.
We then added the Splunk connector and pointed Juno at the environment. We wrote no detection rules or correlation searches. Juno queried the data where it already lived in Splunk.
Then we asked three questions, following the investigation wherever the evidence led.
1. Is someone outside the company using our employees' accounts?
We gave Juno no hints about which data sources to investigate. The evidence could have been anywhere, from identity logs and cloud activity to endpoints and network traffic.
Juno found four external IPs using valid employee credentials. The associated accounts had signed in through Entra ID, often passing MFA, and logged in over SSH to servers across the company, from the bastion host to the database. Attempts to access the AWS console and Windows systems had failed.
But the failed console attempts didn't tell the whole story. Juno found the same identities using the AWS API to create admin users with access keys, disable logging, and open storage buckets to the internet. One of those buckets held database backups.
For a health-tech company, exposed database backups could create serious regulatory and privacy consequences. Juno flagged the potential HIPAA implications without being prompted. It also identified what it hadn't established: whether the bucket actually contained patient data.
That left a bigger question. Had the activity reached the company's endpoints and network?
2. Did the activity reach our endpoints or network?
We asked Juno to trace the same four IPs through the company's endpoint, firewall and network data, and determine whether any of the traffic had got through.
Palo Alto denied the recorded inbound sessions from the four IPs, while FortiGate rejected their probes. But the outbound evidence told a different story. FortiGate had allowed sessions from inside the network to the same addresses, and Zeek recorded connections involving more than a hundred internal hosts. Juno found that most of those connections were routine traffic, and narrowed the suspicious activity to 11 workstations.
Sysmon logs from those workstations showed a file called b.exe connecting to the attackers' IPs. On one of those machines, Juno found a certutil command that had downloaded the file from one of the same addresses.
Palo Alto had recorded some of this activity too, resetting certain outbound sessions and raising alerts on malware downloads and exploit attempts. The FortiGate firewalls at the company’s other sites had no equivalent rule, and they allowed the same outbound traffic.
Each tool held part of the full evidence, making it difficult to assess how far the activity had spread. This highlighted the limitations of relying on disconnected tools and raised a critical question: which issues should be prioritized based on their potential business impact?
3. What should we deal with first, and why?
We asked Juno to prioritize the findings and explain which facts about the business shaped its recommendations.
Juno put the AWS account takeover and exposed storage first, with the Linux hosts that touched patient data addressed in parallel, followed by the infected workstations. It laid out actions for each stage, carrying forward the evidence from the earlier questions rather than treating the findings as separate incidents.
It’s clear how Juno’s reasoning reflected the business context. The exposed backup buckets warranted urgent investigation because of their potential proximity to sensitive patient data. Disabled audit logging and unauthorized administrator accounts raised additional control concerns under SOC 2. And because the patient-facing application depended on the affected servers, those systems deserved attention alongside the cloud exposure.
How Juno Investigates
Juno connected evidence across eight Splunk sources, from Entra ID and CloudTrail to Palo Alto, FortiGate, Zeek and Sysmon. Two capabilities made that possible, and a third lets analysts check the results.
Ontology (Juno works with your data as it is)
As soon as the connector is added, Juno builds an ontology of your environment, a map of what your data holds and how it connects, without a normalization project or manual configuration. It examines what each sourcetype actually contains rather than relying on its name, then identifies relationships between users, hosts and IP addresses across sources. That’s how it traced the same four IPs from sign-in activity to the affected workstations.
Calibration (Juno accounts for your business)
Through calibration, you describe your business once, and Juno checks that context against the environment and uses it to shape every investigation. The same technical findings can demand different priorities at a hospital, a bank or a manufacturer, depending on the systems involved and the risks they pose.
Verifiability (Juno’s findings can be checked)
Each finding links to the underlying events, so analysts can inspect the evidence for themselves. Juno also identifies what it couldn’t confirm, including when one of its own queries returned incomplete results.
Getting more from the data already in Splunk
Every finding in this investigation came from data the company was already collecting. The three questions just show a different way to use it. Instead of beginning with a predefined detection rule or moving manually between specialized tools, an analyst can start with a question, follow the evidence across data sources, and refine the investigation as new findings emerge.
Juno doesn’t eliminate the need for security expertise or verification. It helps analysts use the data they already collect to discover relationships, investigate their implications and decide where to focus next.
To see what Juno finds in your own Splunk data, request a demo.
