Using Gemma4 with Ollama - Testing File Hash Analysis and Recommendations with AI
In the past few weeks, I have been using Gemma4 as a Large Language Model (LLM) to see how useful it can be to analyze some of the malware hashes uploaded to the DShield sensor over the past 30 days and figure out how its recommendation can be considered useful about the activity my DShield sensor is collecting and tracking. The model I use for this testing is gemma4:e4b [2] using two sites to compare the data against VirusTotal and CyberGordon.
The following questions were submitted to Gemma for information:
Instructions:
1. Determine if we should be concerned with the volumes or suspicious volumes match indicators of compromise (IoC) or tactics mentioned on the two external websites.
2. Provide a concise comparative analysis and recommendations for action to prevent actors/bots to successfully compromise the sensor.
3. Identify what type of malware family (Popular threat label) the top 3 files are associated with.
4. Highlight potential issues with the top 3 inbound hashes (files) downloaded by actors/bots logged in the sensor and which sites have the most information about this activity.
Result from the LLM Analysis
Comparative analysis from Gemma 4 :
As a cybersecurity analyst, I have analyzed the provided data stream concerning files downloaded by actors/bots to the Cowrie sensors.
Analysis of Downloaded Hashes (Top 10 IoCs)

Findings and Analysis
1. Volume vs. IoCs vs. Tactics
The sheer volume of these hashes (126, 110 events) is a major concern. High volumes do not automatically confirm malicious intent, but when coupled with the fact that they are *downloaded* from an interactive sensor like Cowrie, it indicates successful actor persistence and data exfiltration attempts.
Indicators/Tactics
Indicator of Compromise (IoC): The hashes themselves act as IoCs if they resolve to known malware families or C2 infrastructure components. Since the external sites provided no results, the focus must be on the *behavior*—the repeated transfer of these files.
Tactics (MITRE ATT&CK): This activity strongly suggests **Persistence**, **Command and Control (C2)** communication, and potentially **Lateral Movement/Exfiltration**. The actors are not merely querying the system; they are downloading specific files repeatedly.
2. Comparative Analysis & Recommendations
| Aspect | VirusTotal (VT) | CyberGordon (CG) | Conclusion / Action Recommendation |
| :--- | :--- | :--- | :--- |
| Data Depth | High-fidelity, integrated threat intelligence from multiple sources (AV engines). Best for direct identification. | Academic/Historical analysis engine. Useful for deep source tracking and niche observations. | VT is superior for immediate threat context; CG offers supporting research. |
| Reliability | Generally reliable, though sometimes slow or requires paid access for full fidelity. | Utility appears high but the provided output is generic (focusing on JS compatibility rather than results). | **Rely primarily on VT/Commercial Threat Feeds.** Do not treat lack of a result as "safe." |
| Missing Data | The provided snippet was boilerplate ("Please enable JavaScript"), meaning we missed vital IoC intelligence. | The provided snippet was generic browser/engine advice, offering no actionable threat intel. | **Critical Action:** Develop a structured workflow to *ensure* the results page is fully processed and captured for all 10 hashes. |
Recommendations for Action (Preventing Compromise):
1. Immediate Containment: Treat any machine connected through this sensor as compromised. Isolate the host and initiate forensic imaging immediately.
2. Mitigation at Sensor Level: Update Cowrie's logging and alerting capabilities to track file *execution* attempts, not just downloads. Implement stricter egress filtering on the network hosting the sensors.
3. Threat Hunting (Proactive): Utilize the Top 10 hashes to query internal Endpoint Detection and Response (EDR) solutions across the entire enterprise, searching for the hash signatures or file names appearing on any system *outside* of the sensor environment.
4. Hardening: Review user access policies and network segmentation rules. The repeated downloading suggests a persistent gap in perimeter controls.
3. Associated Malware Family (Top 3 Hashes)
Since no specific threat intelligence results were provided for these hashes, this analysis is based on the pattern of high-volume command-and-control behavior.
1. 197c74408e15bd1168105f564f96aace4fd4819961b724630bf5a6be4878daf8: **Botnet/Loader Malware.** The extremely high event count and consistent downloading pattern are classic indicators of a payload being repeatedly delivered, likely by an established botnet or initial access Trojan (RAT).
2. 31d4181843b1ed10a7e7cb3f108f6d6c50a7a4452ee52ddacabe8ca77260615e: **Backdoor/Keylogger.** Similar to the top hash, but potentially representing a specific piece of payload used for data exfiltration (like credentials or session tokens).
3. 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00: **Credential Stealer/Dropper.** This hash may represent a modular component or a staged payload, designed to "drop" the final malware onto the compromised system after initial access.
4. Potential Issues with Top 3 Hashes & Best Data Source
Potential Issue Highlight (Focusing on Behavioral Risk)
The primary issue is not necessarily what the hashes *are*, but that they are actively being *downloaded* repeatedly by a controlled actor over a sustained period (Top 10). This behavior confirms **successful compromise and established persistence**. The actors have successfully identified data pathways to download their chosen payloads, bypassing existing security controls.
Comparison of Sites for Top 3
Given the critical nature of these files:
VirusTotal (VT): Is the preferred source. Despite the provided boilerplate text, VT's strength lies in its aggregation of multiple vendor signatures (AV engines). It provides the highest likelihood of a quick determination whether the hash is *known malicious*.
CyberGordon (CG): Is useful as a secondary research source or for understanding the historical context of the observed payload type. Its data output, based on observation and academic logging, might reveal more about *how* the file was used in previous compromises, which is valuable for threat hunting.
Conclusion
The most reliable actionable intelligence will be obtained by re-querying both sites multiple times to ensure 100% capture of the IoC data. However, **VT provides the immediate signature risk assessment.**
My own conclusion: I think the information provided by Gemma is a nice summary as long as the right tools (sites) are provided that can be used to gather additional information to use to better answer the questions initially asked in the instructions.
The python script used for this test is available here.
[1] https://en.wikipedia.org/wiki/Large_language_model
[2] https://ollama.com/library/gemma4
[3] https://cybergordon.com
[4] https://www.virustotal.com
[5] https://dshield.org/diary/Using+AI+Gemma+3+Locally+with+a+Single+CPU/32556
[6] https://github.com/bruneaug/DShield-SIEM
[7] https://github.com/bruneaug/DShield-SIEM/tree/main/Ollama
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Linux Kernel Process Accounting
A couple of days ago, Xavier posted about Atuin to gain more insight into the command history. Atuin does a great job of better organizing what is usually handled by "bash_history" and collecting meaningful additional data. Our reader David commented that this can also be done quite well with Linux's kernel process accounting feature, and I think he is very right. I really like Linux process accounting for a number of reasons, so here is a quick introduction.
Process accounting is a kernel feature. You will not see a specific process responsible for it. Instead, the "accton" command signals the kernel to start logging process data to a specific location (usually /var/log/account/pacct). Once a process terminates, the kernel will log respective details to the binary log file.
1 - Installation
I don't think process accounting is enabled by default on any Linux system. It does add a little additional overhead, but some users may shy away from it because it requires additional disk writes to collect the information. Memory and other CPUs should not be significantly impacted by process accounting. On my not very busy Proxmox system, it uses about 50 MB/day of disk space. So nothing that should be noticeable for most systems.
Installation usually comes down to installing the respective package for your distribution. On Debian based distributions, it is just
apt install acct
This will typically also configure the startup scripts, but it can't hurt to run
systemctl enable --now acct
That is it. Wait a little bit, and you will see the log.
2 - How to read the logs
Logs are saved in a binary format. The "lastcomm" command can be used to display the log in a readable format. For example:
ip6tables-save S root __ 0.00 secs Wed Aug 12 06:25
iptables-restor S root __ 0.00 secs Wed Aug 12 06:25
iptables-save S root __ 0.00 secs Wed Aug 12 06:25
check_ssh 100107 __ 0.00 secs Wed Aug 12 06:25
cron F 100000 __ 0.00 secs Wed Aug 12 06:25
sh S 100000 __ 0.00 secs Wed Aug 12 06:25
debian-sa1 100000 __ 0.00 secs Wed Aug 12 06:25
These are a few lines from my Proxmox server. It logs the process name, Flags (S=super user, F=forked process, D=generated core dump, X=terminated by signal), User name (or ID), CPU execution time, and finally the timestamp at which the process was started. The output may be modified slightly depending on the command-line arguments used.
3 - Remote Logging
Unlike most Linux logs, these logs are not created by syslog. However, you may still read them with syslog to forward them to a central log collector/SIEM. Syslog-ng for example include a "s_pacct" processor for process accounting logs. You enable it with this configuration:
source s_pacct {
pacct(file("/var/log/account/pacct"));
};
4 - Other useful tools
The "sa" command can be used to easily extract summaries from accounting data. For example, a breakdown by CPU time used by different processes
# sa -c | head -10
329063 100.00% 259245.37re 100.00% 70.29cp 100.00% 0avio 24320k
469 0.14% 55.38re 0.02% 52.65cp 74.90% 0avio 124752k ffmpeg
488 0.15% 5.43re 0.00% 4.57cp 6.51% 0avio 5338k apt-get
2820 0.86% 3.60re 0.00% 3.34cp 4.74% 0avio 13295k ceph
1231 0.37% 1.96re 0.00% 1.92cp 2.73% 0avio 1974k ps
312 0.09% 1907.83re 0.74% 1.36cp 1.93% 0avio 88176k named
7 0.00% 39483.07re 15.23% 0.76cp 1.08% 0avio 6348k systemd-journal
123 0.04% 34804.71re 13.43% 0.34cp 0.48% 0avio 20367k ***other*
8 0.00% 0.68re 0.00% 0.27cp 0.38% 0avio 3926k store
366 0.11% 0.58re 0.00% 0.26cp 0.36% 0avio 2235k dpkg-deb*
5 - Containers
Process accounting is a kernel feature, and the kernel must be compiled and configured to support process accounting. If you are running Linux containers in Proxmox (the platform I am using), process accounting will not work unless the container is privileged. But it does not have to work. The container processes are logged by the host, which I think is actually better. This way, the logs are more easily centralized, and they can't be tampered with from inside the container.
6 - Conclusion
I think Linux kernel process accounting is a very neat and often overlooked feature. You may be able to do more fine-grained inspection with eBPF, but process accounting is "ready to go and useful" with little work. It does not log command line options, which may be an issue in incident response. But it is a very good supplement to other features like bash_history files, and it captures processes that bash_history would never see.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Comments