This post was originally published on this site

[This is a Guest Diary by William Constantino, an ISC intern as part of the SANS.edu BACS program]

In the beginning of my Internet Storm Center (ISC) internship, I wasted too much time trying to build my SIEM from an old computer I had lying around, or a new Raspberry Pi I purchased. I keep running into roadblocks and errors. Also, I was distracted while trying to finish up another course, and I had every intention of looking at my log files every day, but it wasn’t happening. I did the easy thing of saying “I’ll look at it tomorrow. The JSON logs and Sqlite3 were the other problems with reading the logs without a SIEM, it produced massive amounts of data to parse through. To me it was like trying to find a needle in a haystack. To resolve this problem, I built two automated python tools to assist with those tasks and analyze the data. 

The first tool helped me process and organize the data I was looking at and helped point me in the right direction of interesting things to investigate further. This tool gave me the following capabilities:

1. It loads, reads, and parses JSON files by extracting the source IP addresses, request methods, accessed URLs, timestamps, user agents, response codes, credentials, and hashes.
2. Tracks IP activity by recording the different request methods used (GET, POST, etc.), and it stores the timestamps of requests for timeline analysis.
3. Counts URL accesses for identifying the most frequently visited endpoints, logs the user agent strings to detect patterns in client access, and captures the response codes to track server errors or unusual behavior.
4. Detects suspicious activity by flagging suspicious file requests (.php, .exe, .zip, etc.), extracts credential attempts (20 of the most used usernames and passwords), and identifies hashed values (MD5, SHA1, CRC32, NTLM, etc.)
5. Generates a generic security report by reporting the top 10 most active IPs, bottom 10 least active IPs, and the total amount of Unique IPs. It gives a summary of total requests, detected hashes, and credential attempts.
6. Lastly it measures how long the script takes to process the log file. It displays the results in minutes and seconds (I added this last because I just wanted to know how long it was taking to read and parse through the data).
7. The sample output from this tool is from 2025-05-31, and it was a massive log file at over 3.5GB for one day (why I added the timer). I will break down the output in sections for Tool 1 below:

Figure 1: Top 10 most Active IP addresses, Bottom 10 Least Active IPs, and General Summary.

Continued Output Tool 1:

Figure 2: The Request Methods Used and Top Accessed URLs.

Continued Output Tool 1: 

Figure 3: Suspicious File Requests and Top User-Agent Strings.

Continued Output Tool 1: 

Figure 4: Top attempted usernames and attempted passwords.

Continued Output Tool 1:
 

Figure 5: Hashes Detected and the Time it took to read the log file.

Once I had this output to look at, I determine what IP address that is the most interesting. However, I usually start with the one with the largest number of requests to see what is going on. I will look at all 10-20 (Top and Bottom 10) individually and see what they were doing and then determine which IP address to highlight for my analysis. Sometimes, if I’m looking at the same exploit, I’ll research all the other IPs to see if there is a novel attack or a different type of attack. To assist with a further investigation, I developed a second tool to help me with this. It is basically, the same as the first tool, but it focuses on further detailed analysis of specific IP(s).

The second python tool performs a detailed analysis on a specific IP address or addresses that you want further analysis on from a given a JSON log file. This tool does the following things:

1. Provides a prompt to input one (1) or multiple IP addresses.
2. It extracts the “sip” (source IP) field from each log entry and identifies requests.
3. The script gathers the HTTP request methods used by the target IP (GET, POST, HEAD, etc.). It also records the timestamps of the request timeframe.
4. Analyzes the User-Agent Strings which can provide insight into whether the requests originated from a legitimate browser, automated bot, or a hacking tool.
5. Examines response codes to show whether the target IP successfully accessed certain resources.
6. Detects suspicious file requests (.php, .exe, .zip, .bat, .sh, .py)
7. Credential attempts using default usernames and passwords (currently only the top twenty of each). 

Below is my output for the second tool (also for 2025-05-31). It is basically, the same as the first tool, but it focuses on further detailed analysis of specific IPs.

Output Tool 2:

Figure 6: Prompt to enter one (1) IP or multiple IP addresses separated by a comma.

Continued output Tool 2:

Figure 7: I inputted IP address (141.98.80.134). In this case, it was the #1 active IP.

Continued output of Tool 2:

Figure 8: Analysis for IP (141.98.80.134) with a massive number of requests.
 
According to the top accessed URLs in this investigation of this IP are known for CVE-2021-20016. I’ve actually seen this type of attack lately. 

Figure 9: Internet Storm Center Report for an exploit for Sonicwall [1].

Continued output of Tool 2:

Figure 10: User-Agent Strings and Attempted Passwords. 

This script will notify if it did not find any data for the specific fields looked at. The first tool does not do this, but usually there are all types of data and no field is empty during the investigation.

Continued output of Tool 2:

Figure 11: The Log Analysis is Complete. 

It took almost 13 minutes to complete. This was a massive file compared to other days, so analysis will be much faster with less data.
Using this tool to analyze the data in a short amount of time, the analyst will be able to inquire more information about the IP from websites like Virustotal, IPQualityScore, APIVoid, and etc. That information might give additional data points to see if further investigation is warranted or not.

In Conclusion, my script(s) or python tool(s) can assist help detect potential attackers that are targeting their DShield Honeypot. The tools can assist in forensic analysis by tracking IP behavior, login attempts, suspicious files, and other types of data. Additionally, they can provide insights into common attack patterns and methods that could be used by malicious actors. Moreover, other students or individuals can benefit from using these tools for their analysis and attack observations. This is only the starting point for these tools, massive improvements can be made to make them even more effective and useful. In the short term, though, these tools significantly assisted in my analysis projects during this internship. I have attached the links to my GitHub for both tools below.

[1] https://isc.sans.edu/diary/31906
[2] https://github.com/JJWCons/log-scripts/blob/main/logfile_investigation.py (Tool 1 Code)
[3] https://github.com/JJWCons/log-scripts/blob/main/single_multi_IP.py (Tool 2 Code)
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

As an avid daily reader of TLDR Information Security I benefit twofold. First, I gain interesting insights and recommendations regarding launches and tools, where I first learned about OctoSQL. Second, concerning vulnerability details inevitably land in my inbox on a near daily basis. Aside from my recommendation to join the TLDR InfoSec mailing list, diary readers also benefit twofold as, herein, I share the use of OctoSQL as a fast CLI interface to vulnerability data aggregated via CVE-Vulnerability-Information-Downloader. If ever you’ve wanted to join vulnerability data (CVE, CVSS, EPSS, etc) from disparate data sources and file types, this is the diary for you.

The 03 JUN 2025 edition of TLDR InfoSec brought us details on Qualcomm’s three patched zero-day vulnerabilities in its Adreno GPU driver that are being actively exploited in targeted attacks. Per the TLDR InfoSec issue, CVE-2025-21479 and CVE-2025-21480 cause memory corruption through unauthorized GPU command execution while CVE-2025-27038 is a use-after-free vulnerability in Chrome’s graphics rendering. “Google’s Threat Analysis Group (TAG) confirmed these vulnerabilities are under limited, targeted exploitation, and Qualcomm provided patches to device manufacturers in May with urgent deployment recommendations.” There has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors, including a previous zero-day used adversially with Cellebrite software to unlock activists’ and journalists’ Android devices.[1]
While this reference was an effective summary of the issues, it did not contain vulnerabilty stats with which to assess severity and exploitability.
One of my favorite raw data source aggregators for such details is the CVE-Vulnerability-Information-Downloader. With updated a data and OctoSQL in hand, a few useful SQL queries later, we’ll know everything we need. Yes, you can also search web sources, but you may have production scenarios with limited egress access coupled with the need an for easily extensible full-blown dataflow engine which can be used to add a SQL interface to your own applications.

Be sure Docker or the like (Rancher Desktop) are available, and acquire a NVD API key if you don’t already have one. In your preferred data or tools directory:

git clone https://github.com/trinitor/CVE-Vulnerability-Information-Downloader.git
cd CVE-Vulnerability-Information-Downloader
cp env_example .env

Edit the .env file and add your NVD API key, then run:

docker compose up -d  
docker exec -it vulnerability-tables-cron bash /opt/scripts/download.sh

Note that the docker exec download process can take up to twenty minutes to finish. Be patient, don’t panic. 😉
This will populate the CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output directory of your installation CSV and JSON versions of CISA Known Exploited Vulnerabilities (KEV) catalog, CVE, CVSS, and EPSS files. This nicely sets up our situation, albeit arbitrary, where we’d like to query these disparate data file types and join key elements such as known exploitation and EPSS score for specific CVEs.
Here’s where OctoSQL provides capably. I installed OctoSQL on Ubuntu 25.04 with brew:

brew install cube2222/octosql/octosql

The OctoSQL binary is available via any path after installing via brew, it’s my preferred one-shot approach.
Just cd to CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output and you’re ready to go.
I first crafted a query to return all the Qualcomm CVEs in CISA’s KEV (CISA_known_exploited.csv) catalog to validate the assertion that there has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors.

octosql "SELECT vendorProject, product, CVE, dateAdded FROM CISA_known_exploited.csv WHERE vendorProject='Qualcomm'"

Figure 1: Qualcomm CVEs in KEV catalog

The assertion is valid, as seen in Figure 1: Qualcomm vulnerabilities have indeed been victim to active exploitation in the wild.
What about the three currently referenced CVEs CVE-2025-21480, 21479, and 27038? If already known to be exploited, what is the probability of exploitation per EPSS?

A query to join CISA’s KEV (CISA_known_exploited.csv) and FIRST’s EPSS.json follows:

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE CVE='CVE-2025-21480' OR CVE='CVE-2025-21479' OR CVE='CVE-2025-27038'"

Figure 2: KEV & EPSS join for Qualcomm CVEs

As seen in Figure 2, those are low EPSS scores, indicating a rather low probability of exploitation. What about all the other known exploited Qualcomm CVEs? Here again I join KEV Catalog results with EPSS to answer the question with results produced in descending order by EPSS score.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC"

Figure 3: Qualcomm KEV entries by EPSS rank

Turns out the highest scoring Qualcomm CVE is one the current three of interest, CVE-2025-27038, with a score of only 0.16672 as seen in Figure 3.
What does it all mean?
Per Jay Jacobs of Cyentia, EPSS is driven by data and has a strong temporal aspect. It only learns from the exploitation activity it sees (from data partners) and predicts on the vulnerability attributes presented. Those with low EPSS scores on the KEV are more likely to be “Access Vector:Local”, “Confidentiality:None”, require some privileges and/or be without published exploit code. Those with higher EPSS scores tend to have exploit code published, be integrated into pen testing tools and scanners, and/or involve remote command execution/injection. Likelihood of exploitation for these Qualcomm vulns is low due to “Access Vector:Local” above all else.
One additional excellent feature offered by OctoSQL is the ability to explain query plans. As you build complex queries, and potentially productionize them, explainability will be important. Rerunning our last query with the –explain flag set yields an informative visualization as seen in Figure 4. Setting it to 1 produces a query plan without type and schema information, while setting it to 2 includes type and schema. I use 1 here for visual clarity.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC" --explain 1

Figure 4:

I’ve barely scratched the surface of its potential use cases here, but I’ve incorporated OctoSQL into my personal practice, and truly appreciate the ability to query disparate sources in my terminal. I also appreciate the ability to download vulnerability data use the information for enrichment courtesy of the CVE Vulnerability Information Downloader. Please consider both of these offerings for your on purpose and benefit.

Cheers…until next time.

Russ McRee | @holisticinfosec | infosec.exchange/@holisticinfosec | LinkedIn.com/in/russmcree

References

[1] Prasanna Gautam, Eric Fernandez & Sammy Tbeile, TLDR Information Security, 03 JUN 2025
[2] Jay Jacobs, Why does EPSS score some CVEs on the KEV so low?, https://www.cyentia.com/integrating-epss-and-kev, retrieved 05 JUN 2025

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I recently came across an interesting phishing e-mail. At first glance, it looked like a “normal” phishing that tried to pass itself off as a message from one of the Czech banks asking account holders to update their information…

Nevertheless, when I hovered above the rectangle that a recipient was expected to click on, I was surprised to see that the link in the pop-up actually pointed to the legitimate domain of the bank.

My first thought was that threat actors behind the phishing made a mistake. My assumption was that they used a real e-mail from the bank as a baseline that they wanted to modify to create a message that would point recipients to a malicious site, and mistakenly sent it out before it was finished – strange as it may sound, it wouldn’t have been nowhere near the first case of something like that I’ve seen. 

Nevertheless, once I looked at the HTML code of the message, it quickly emerged that I was wrong. The threat actors actually used a technique which changes displayed content based on a “browser” it is opened in. The technique in question leverages HTML conditional statements <!–[if mso]> and <!–[if !mso]> that specify content that should be displayed if a  message/HTML page is opened in Outlook or in any other reader/browser.

Using it, threat actors behind the message caused the link shown/pointed to in Outlook to a benign one, while making it point to a – presumably – credential stealing website in any other e-mail client/browser…

<!--[if mso]>
    ...
    <a href=[benign link] >
    ...
<![endif]--><!--[if !mso]><!-->
    ...
    <a href=[malicious link] >
    ...
<!--<![endif]-->

In this case, threat actors likely used this technique with the intention of hiding the malicious link in corporate environments, where Outlook is commonly used (alongside security mechanisms that scan web traffic, DNS requests, etc.) and where users would probably be less likely to click, since an e-mail from a bank sent to their work e-mail, instead of a private one, would probably be a red flag on its own, while ensuring that recipients who opened the e-mail in a non-Outlook client would still be directed to the malicious website.

While this approach isn’t new – in fact, it has been documented since at least 2019[1] – its use in the wild is not too common… And since it is therefore among the lesser-known phishing techniques I believe it is worthy of at least this short reminder of its existence.

[1] https://www.libraesva.com/outlook-comments-abused-to-deliver-malware/

———–
Jan Kopriva
LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.