SSH Log Analysis using Splunk

Project Objective:

This project analyzes SSH authentication logs to identify successful logins, failed attempts, repeated failures that may indicate brute-force activity and unauthenticated connections that could signal scanning. Splunk is used to ingest the logs, run SPL queries, visualize patterns and build alerts for early threat detection.

What I learned:

I strengthened my skills in log ingestion, SPL querying, dashboard creation and alerting. More importantly, I gained practical experience interpreting SSH activity and turning raw log data into meaningful security insight.

Preparation:

1. Log in to your Splunk Enterprise or Splunk Free instance using your administrative credentials to access the data ingestion and analysis interface.

2. Navigate to Apps then click Search & Reporting, which serves as Splunk’s primary workspace for searching visualizing and managing ingested data.

3. Select Add Data and chose the Upload option to begin importing a local log file into Splunk for indexing and field extraction.

4. Browse for and select the provided ssh_log.json file, then proceed with the upload to prepare it for parsing and indexing.

5. Set the sourcetype to _json, enabling Splunk’s built-in JSON parser to automatically extract fields and structure the SSH log events for efficient searching.

6. Assign the data to dedicated index, such as ssh_logs, to keep SSH related activity organized and easily retrievable during analysis.

7. Review the configuration summary and select start searching to complete the ingestion process and begin exploring the newly indexed SSH log data.

Task 1: Ingest and Parse Logs

1. Upload the ssh_log.json file into Splunk:

Begin by uploading the SSH log dataset into your Splunk environment, as shown in the preparation section. This step loads the raw JSON events into Splunk so they can be properly parsed, indexed, and used for analysis throughout the remaining tasks.

2. Verify that Splunk has correctly extracted all required SSH related fields:

Run a simple search against your SSH index and expand several events to confirm that the following fields appear consistently across the dataset.

• event_type — Categorizes the SSH activity (e.g., Successful SSH Login, Failed SSH Login, Multiple Failed Authentication Attempts, Connection Without Authentication).

• auth_success — Indicates whether authentication succeeded (true), failed (false), or was not applicable (null).

• auth_attempts — Shows the number of authentication attempts associated with the event, useful for identifying brute‑force patterns.

• id.orig_h — The source IP address initiating the SSH connection.

• id.resp_h — The destination host or IP receiving the SSH connection.

3. Run a validation search to view all key fields together Execute a structured search to display the essential fields in a single table for quick verification:

Review the output to confirm that each field is present, correctly populated and ready for deeper analysis in subsequent tasks.

Task 2: Analyze Failed Login Attempts

1. Search for all failed SSH login events Start by filtering the dataset to focus only on failed SSH authentication activity. In the Search & Reporting app, run the following search:

SPL Query: index=ssh_logs event_type=”Failed SSH Login”
| stats count by id.orig_h

2. Identify the top 10 source IPs generating failed logins to prioritize the most suspicious sources, refine your search to surface only the IPs with the highest volume of failed attempts. Extend the previous query as follows:

3. Create a bar chart for failed login attempts per source IP

With the search results in place, convert the data into a visual representation for easier pattern recognition:

• Run the search from Step 2.
• In the Visualization tab, select Bar Chart as the visualization type.
• Ensure id.orig_h is used as the X‑axis (source IP) and count as the Y‑axis (number of failed attempts).
• Optionally, add a clear title (e.g., “Top 10 Source IPs by Failed SSH Logins”) and axis labels to make the chart more interpretable for other analysts or stakeholders.

These bar chart provides a quick, visual summary of which IPs are generating the most failed SSH login attempts, supporting rapid triage and further investigation.

Task 3: Detect Multiple Failed Authentication Attempts (Brute Force)

1. Search the logs for events indicating multiple failed authentication attempts Begin by isolating SSH activity where the system has already classified the behavior as multiple failures. In the Search & Reporting app, run:

index=ssh_logs event_type=”Multiple Failed Authentication Attempts”
| stats count by id.orig_h, id.resp_h

This search filters for events with event_type="Multiple Failed Authentication Attempts" and then uses stats to calculate how many such events are associated with each source IP (id.orig_h) and destination host (id.resp_h). This helps you understand which source–destination pairs are repeatedly involved in suspicious authentication activity.

2. Identify source IPs with repeated failures over a defined threshold To focus on the most concerning activity, apply a threshold to highlight IPs with a high number of failed attempts. You can extend the previous search to detect sources exceeding a threshold, such as 5 attempts:

This query returns only those source–destination pairs where the number of “Multiple Failed Authentication Attempts” events suggest persistent, potentially automated attack behavior, such as brute‑force or password spraying.

Get Jason Hoskins Jr.’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

3. Build a time‑bounded search to support alerting logic For an operational alert, you typically need to detect excessive failed attempts within a specific time window. Adjust the SPL to aggregate failed logins by source IP over a 10‑minute period:

index=ssh_logs event_type=”Failed SSH Login”
| bin _time span=10m
| stats count as failed_attempts by _time, id.orig_h
| where failed_attempts > 5

This search groups events into 10‑minute buckets, counts failed login attempts per source IP within each window, and then returns only those IPs that exceed 5 failures in that period.

4. Configure a Splunk alert based on excessive failed logins Once you have validated the search logic, convert it into a scheduled alert:

• Run the time‑window search from Step 3 and verify the results.
• Click Save As → Alert in the search toolbar.
• Name the alert (for example, “Excessive Failed SSH Logins — Possible Brute Force”).
• Set the Alert Type to Scheduled and choose an appropriate schedule (e.g., every 5 or 10 minutes) to align with your detection window.
• Under Trigger Conditions, select Trigger alert when number of results is greater than 0. This ensures the alert fires whenever at least one source IP exceeds 5 failed attempts in a 10‑minute window.
• Configure alert actions, such as sending an email, creating an incident ticket, or writing to a notable index, depending on your environment and workflows.

5. Trigger the alert when any IP attempts more than 5 logins within 10 minutes with the above configuration, Splunk will evaluate the search on the defined schedule. Any time a source IP records more than 5 failed SSH login attempts in a 10‑minute interval, the alert will trigger. This enables near‑real‑time detection of potential brute‑force activity and provides SOC analysts with actionable intelligence for rapid investigation and response.

Task 4: Track Successful Logins

1. Search for all successful SSH login events Start by isolating events where SSH authentication was successful. In the Search & Reporting app, run the following query:

SPL Query: index=ssh_logs event_type=”Successful SSH Login”
| stats count by id.orig_h, id.resp_h

This search filters on event_type="Successful SSH Login" and then uses stats to calculate the number of successful logins for each source IP (id.orig_h) and destination host (id.resp_h). This helps you understand which external sources are successfully accessing which systems.

2. Enrich successful logins with prior failed attempts for context To identify potential account compromise, you want to know whether a successful login was preceded by multiple failed attempts from the same source IP and to the same destination. You can correlate failed and successful attempts using a combined search such as:

SPL Query: index=ssh_logs (event_type=”Failed SSH Login” OR event_type=”Successful SSH Login”)
| eval outcome=if(event_type=”Successful SSH Login”,”success”,”fail”)
| stats count(eval(outcome=”fail”)) as failed_attempts,
count(eval(outcome=”success”)) as successful_logins
by id.orig_h, id.resp_h
| where successful_logins > 0 AND failed_attempts > 0

This query counts failed and successful attempts per source–destination pair and then returns only those cases where both exist, highlighting scenarios where repeated failures were eventually followed by a successful login, a useful indicator of possible brute‑force success or account compromise.

3. Optionally prioritize highly suspicious patterns To make the results more actionable, you can add thresholds that focus on high‑risk behavior (for example, many failures followed by at least one success):

SPL Query: index=ssh_logs (event_type=”Failed SSH Login” OR event_type=”Successful SSH Login”)
| eval outcome=if(event_type=”Successful SSH Login”,”success”,”fail”)
| stats count(eval(outcome=”fail”)) as failed_attempts,
count(eval(outcome=”success”)) as successful_logins
by id.orig_h, id.resp_h
| where successful_logins > 0 AND failed_attempts >= 5
| sort — failed_attempts

4. Build a search for top source IPs with successful logins To support dashboarding, create a search focused specifically on successful SSH logins by source IP:

index=ssh_logs event_type=”Successful SSH Login”
| stats count as successful_logins by id.orig_h
| sort — successful_logins
| head 10

This query returns the top 10 source IPs ranked by the number of successful SSH logins, giving you a concise view of which IPs are most active in successfully accessing your systems.

5. Create a dashboard panel for top successful login source IPs Once the search is returning the desired results, convert it into a reusable dashboard visualization:

• Run the search from Step 1 and 4 and verify the results.
• Click Save As → Dashboard Panel.
• Choose an existing dashboard (e.g., “SSH Security Overview”) or create a new one.
• Name the panel clearly, such as “Top Source IPs with Successful SSH Logins”.
• Select Bar Chart (or another suitable visualization) as the panel type.
• Configure the visualization so that id.orig_h appears on the X‑axis (source IP) and successful_logins on the Y‑axis (count of successful logins).
• Optionally add descriptive axis labels and a short panel description explaining that this chart highlights IPs with the highest volume of successful SSH logins, useful for spotting unusual or high‑risk access patterns.

Task 5: Spot Suspicious Connections Without Authentication

1. Search for SSH connections that occurred without any authentication attempt:

Begin by identifying events where an SSH connection was established but no authentication process followed. These events can indicate reconnaissance activity, automated scanning tools, or unauthorized probing of your SSH service. Run the following search in Search & Reporting:

SPL Query: index=ssh_logs event_type=”Connection Without Authentication”
| stats count by id.orig_h

This query filters for events labeled Connection Without Authentication and then uses stats to count how many times each source IP (id.orig_h) initiated such connections.

2. Interpret the results to identify suspicious behavior Reviewing the output allows you to quickly see which IP addresses are repeatedly initiating SSH sessions without attempting to authenticate. This pattern is often associated with:

• Port scanning
• SSH service enumeration
• Automated bots probing for open SSH endpoints
• Early stages of intrusion attempts

3. Prioritize high‑frequency sources for further investigation Source IPs with unusually high counts of unauthenticated connections should be examined more closely. These may warrant additional correlation with firewall logs, threat intelligence feeds, or geolocation data to determine whether the activity is benign or malicious.

4. Create a time‑based visualization of unauthenticated SSH connections To understand when suspicious unauthenticated SSH activity occurs, generate a time chart that shows how often each source IP initiates a connection without attempting authentication. Run the following search in Search & Reporting:

SPL Query: index=ssh_logs event_type=”Connection Without Authentication”
| timechart count by id.orig_h

This command aggregates events into time buckets and plots the count of unauthenticated connections per source IP over time. The result is a clear, chronological view of scanning or probing behavior.

5. Interpret the time chart to identify suspicious patterns Once the visualization loads, examine the chart for indicators of malicious reconnaissance, such as:

• Repeated spikes from the same source IP
• Consistent activity at regular intervals (common with automated scanners)
• Sudden bursts of unauthenticated connections targeting your SSH service
• Multiple IPs probing simultaneously, which may indicate distributed scanning

6. Recognize potential port‑scanning or SSH probing behavior Unauthenticated SSH connections are rarely legitimate. When a source IP repeatedly initiates connections without attempting to authenticate, it often signals:

• Port scanning tools mapping open SSH ports
• Bots probing for SSH banners or version information
• Attackers testing connectivity before launching brute‑force attempts
• Early‑stage reconnaissance preceding targeted attacks

The time chart helps you visually correlate these patterns, making it easier to distinguish isolated noise from systematic probing.

Conclusion:

By completing this project, I have developed the ability to monitor and investigate SSH activity through Splunk dashboards, identify brute-force attempts and other suspicious authentication behaviors. I also configured alerts to detect high-risk events in real time by confidently parse, search, visualize and operationalize SSH log data within Splunk.