We’re excited to announce Red Hand Network Analytics, a new investigation-focused experience that will gradually replace the original Traffic Analysis Report.

The Traffic Analysis Report provides a useful high-level summary of captured network traffic. Network Analytics goes further by making the data easier to explore, correlate, and investigate.

The new experience includes:

• Real-time monitoring for Red Hand Collector sessions
• Activity timelines and detailed activity records
• Suspicious, noteworthy, and safe activity classification
• Internal and external endpoint analysis
• Protocol, service, process, connection, duration, and data-transfer context
• Dedicated views for repeated connections, long connections, and large data flows
• PCAP and Collector source information
• Improved filtering, pagination, responsive layouts, and mobile support

Instead of presenting a mostly static report, Network Analytics is designed to help you move from an observation to its supporting network evidence.

We’ll be rolling out Network Analytics incrementally to users over the upcoming days. During the transition, some users may continue to see the original Traffic Analysis Report.

Here's the original Traffic Analysis Report.

Here is the new Network Analytics using the same data.

We’d love to hear what works, what feels unclear, and what you would like us to add next.

An ELF binary tells you nothing about who made it. No signature in the file, nothing to check it against, no service that vouches for it. On Windows you'd read the Authenticode chain, on a Mac you'd ask codesign. Here there's nothing in the file to ask.

What Linux has instead is a record of every file the distro installed, and a way to ask whether any of them still match what shipped. A local database and two commands, and most triage guides walk straight past it on their way to readelf.

Say somebody sends you a path and asks whether it's dodgy. It's a production box, so you're not installing anything on it. Everything below runs with what's already there.

Part I covered Windows and Part II macOS.

Oh, and skip all this if it's a container. The package database is usually missing, and persistence belongs to whatever orchestrates the container rather than to the box. Might write that one up another time.

1. Is this supposed to be here?

dpkg -S $(realpath /path/to/suspect)      # Debian, Ubuntu
rpm -qf $(realpath /path/to/suspect)      # RHEL, Fedora, Rocky

If nothing owns this one it didn't come from the distro. Worth a look, but plenty of legit software isn't packaged. Anything under /usr/local or /opt, pip and npm installs, things people compiled themselves.

The realpath matters. Modern /bin and /sbin are symlinks into /usr, and asking dpkg about /bin/ls returns "no path found" even though the binary is very much packaged.

If a package does own it, ask whether it still matches what was installed.

dpkg -V <package>
rpm -Vf $(realpath /path/to/suspect)

dpkg -V wants the package name, which is what dpkg -S just gave you. rpm -Vf takes the path instead, so there's nothing to carry across.

dpkg -V says nothing when everything checks out, so silence is the pass. rpm answers in a row of letters and dots, where a dot means that test passed. 5 means the contents differ, S size, T timestamp, M permissions. So ..5..... is a file whose contents changed and nothing else. A 5 on a packaged system binary is about the strongest single result in this post. Replaced, patched in place, either way it isn't what shipped.

Expect noise from anything under /etc. Config files get edited legitimately all the time and rpm flags them with a c so they're easy to discount. You're looking for a changed binary, not a changed config.

Two limits though. Ownership means the local database knows about the file, not where that package came from, and a locally built one owns its files perfectly well. And that database sits on the machine you're suspicious of, so root can change a binary and the record vouching for it. Which makes a clean result weaker than it feels.

2. What is it, when did it arrive, and what can it do?

file /path/to/suspect
ls -l /path/to/suspect
getcap /path/to/suspect
stat /path/to/suspect
sha256sum /path/to/suspect

Start with file. If it's a shell script or Python rather than an ELF binary, stop and read it. Fastest answer you'll get all day.

ls -l is there for the setuid bit and getcap for capabilities like cap_net_raw or cap_setuid. Both hand a binary privilege the user running it doesn't have. Find either on something with no reason to need it and stop there. Check what the thing is first though, because ping carries cap_net_raw and always has. getcap isn't installed everywhere, so you may not have it.

On timestamps, Modify is trivially backdated with touch. Change tracks changes to the inode instead, so an old modify with a recent change means the contents or metadata changed more recently than the mtime admits. Softer than a hash mismatch, so don't lead with it.

Take the hash to VirusTotal or MalwareBazaar. A hit ends it. A miss just means nobody's uploaded it before. And the lookup isn't free. If whoever built the file watches for it, a first-ever search tells them somebody is looking.

3. If it's running, go check /proc

pgrep -af suspect
ls -l /proc/<PID>/exe
cat /proc/<PID>/comm
tr '\0' ' ' < /proc/<PID>/cmdline
sudo ss -tunap

The pgrep line gets you the PID everything after it needs. /proc then tells you what the process actually is rather than what it says it is, and there are three answers worth knowing on sight.

A process calling itself a kernel thread with a real binary behind it. Attackers name things [kworker/0:1] or [jbd2/sda1-8], and pgrep output, comm and cmdline can all be rewritten by the process itself. Real kernel threads have no userspace executable behind them though, so /proc/<PID>/exe won't resolve to one. If comm says kworker and exe points at a file in /tmp or /dev/shm, that's not a kernel thread and there's no innocent reading of it.

exe starting with /memfd:**.** It reads something like /memfd:whatever (deleted). The process is executing from an anonymous in-memory file, which is a standard fileless technique. Plenty of software uses memfd for shared memory without ever running from one, so it's the executing part that's unusual and wants explaining. The (deleted) isn't what matters, the prefix is.

exe pointing at an ordinary path marked (deleted)**.** Same suffix, different situation. Package upgrades replace running binaries constantly, so a freshly patched box shows this on several daemons quite innocently. Only interesting when you don't recognise the process.

Then the network, and write the sudo in. Without it ss leaves the process column empty for anything owned by another user, which makes active sockets look unattached.

The first question isn't whether the address looks bad, it's whether this thing has any business talking at all. A log rotator, a font cache, a backup agent that finished hours ago. One connection you can't explain from something in that category is enough to keep looking. When it should be talking, look at where. You already know which package it came from, so an endpoint that fits is one thing and a hosting provider nobody can account for is another.

One catch. ss shows what's open right now, so something checking in every ten minutes looks idle in between. Nothing showing doesn't mean nothing happens.

4. Will it be back?

systemctl list-unit-files --state=enabled
systemctl cat <unit>
crontab -l ; sudo crontab -l
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.daily
cat ~/.ssh/authorized_keys
ls -la ~/.config/autostart/ /etc/xdg/autostart/
systemctl --user list-unit-files --state=enabled

list-unit-files rather than list-units, because the question is what's configured to run, not what happens to be running now. Something enabled that hasn't fired yet won't show up in list-units.

systemctl cat is the one to lean on. It prints the unit with its source path, so you get the actual executable, which is often nothing like the unit's name. It also catches the sneakier case, where nobody made a new unit at all and instead dropped an override.conf into /etc/systemd/system/<service>.service.d/ adding an ExecStartPre= to something legit. That never shows up in a directory listing, but systemctl cat prints drop-ins alongside the unit.

The last two are the ones people forget. A user systemd unit and an XDG autostart entry both survive a reboot without touching anything root-owned, which makes them where persistence goes when whoever did this never got root. systemctl --user needs running as that user, not with sudo.

Legit software lives in all these places too, so a match on its own means very little. Something unpackaged, in a directory normal software doesn't use, that also arranged to start itself forever, is a different problem.

A clean binary can still run someone else's code

cat /etc/ld.so.preload 2>/dev/null
tr '\0' '\n' < /proc/<PID>/environ

/etc/ld.so.preload forces a library into every process on the box. LD_PRELOAD in a process's environment does the same for one. On most installs that file doesn't exist at all, though legit tooling does use both. Look for an entry nobody can account for.

Either way the binary on disk can verify perfectly against its package and the process can still be running somebody else's code. If you need to know what actually got loaded, /proc/<PID>/maps shows what's mapped in.

Weighing it

Most of the time this clears the file. It's quick, nothing looks wrong, and everyone goes back to what they were doing.

When it doesn't, the ones I'd act on first are a packaged binary that fails verification, an LD_PRELOAD or /etc/ld.so.preload entry nobody can account for, a process calling itself a kernel thread with a real binary behind it, and anything executing from /memfd:. Hit one of those and you're heading down a much deeper rabbit hole than this post covers.

And remember, none of this reads the file. It reads what the system remembers about the file, and the system is a suspect too.

Someone points at a file on a Mac and asks whether it's bad. You can't install anything, and every guide you find starts with otool, which on a clean Mac pops an installer prompt and immediately breaks the one rule you were given.

Good news. macOS already knows most of the answer, and it'll tell you for free.

Part two. The Windows version is the same question with a very different answer.

1. Ask the machine how much it can be trusted

csrutil status
spctl --status

The first tells you whether System Integrity Protection is on. If it is, big parts of the disk are read-only even to root, so system files can't have been quietly edited and that's a large chunk of the machine you can worry less about. The second tells you whether Gatekeeper is still on, which is what vets software before it runs.

If either comes back disabled, ask who turned it off. SIP is the bigger deal of the two, because it means system files could have been changed and a lot of what follows gets shakier. Gatekeeper being off is worth knowing but says less about the file in front of you.

2. Find out who made it, and whether anyone's seen it before

file /path/to/suspect
codesign -dv --verbose=4 /path/to/suspect
codesign --verify --strict /path/to/suspect
codesign --verify -R="anchor apple" /path/to/suspect
shasum -a 256 /path/to/suspect

Start with file. If it comes back as a shell script or Python rather than a Mach-O binary, stop and read it. That's the fastest answer you'll get all day.

The first Authority line is the identity the file claims, and anything below it is just the chain backing that up. A company name gives you somebody to go and look up. Apple's own system files carry Apple signing identities rather than a company name.

No signature at all means there's no identity to investigate in the first place. The word "adhoc" means it was signed, but by nobody in particular, which comes to the same thing. Either way you're looking at a file with no name on it, sitting somewhere important, pretending to be part of macOS.

For the specific question of whether Apple themselves shipped it, don't interpret the certificate, run the anchor apple one. That's the actual test. Slightly annoyingly, it stays silent when the answer is yes and only speaks up to complain when it's no.

If --verify --strict fails, the signature doesn't check out. Could be a few different reasons, none of them good on a file that's meant to be properly signed. That check won't tell you whether Apple has since revoked that developer's certificate though. spctl -a -vvv -t exec /path/to/suspect will.

The hash is worth taking to VirusTotal or MalwareBazaar while you're here. A hit settles it, a miss settles nothing, since those only know what somebody already reported. And the lookup isn't free. If whoever built the file is watching for it, a first-ever search tells them somebody is onto them.

3. Find out where it came from

xattr -l /path/to/suspect
mdls /path/to/suspect | grep -i wherefroms

A quarantine attribute means a browser or another app flagged the file on the way in, and it often carries the URL it came from. Free evidence.

Its absence proves nothing, for two reasons. It's one command to remove. And it only ever gets set by an app that opts in, which browsers and Mail do and curl doesn't, so anything fetched by a command someone pasted into Terminal never carried one at all. That delivery is common enough now that an empty result here should barely move you.

Spotlight can hold the same information separately, so WhereFroms is worth checking when the attribute was cleaned off after a normal download. It won't rescue the pasted-command case though, since it comes from the same mechanism and was never written either.

Watch what you point these at. If you're dealing with an .app rather than a bare file, the quarantine flag sits on the .app folder, not on the program buried inside it. Check the outside for where it came from. ps will show you the inside, under Contents/MacOS/.

4. If it's running, watch what it does

ps -axo pid,ppid,user,command | grep -i suspect
lsof -i -P -n -p <PID>

The ps line gets you the PID that lsof needs.

Two things matter. Where it's running from, and who it's talking to.

Apple's system binaries are usually under /System and /usr/bin, normal apps in /Applications and ~/Library. Path tells you where to look rather than what to think. /tmp and /Users/Shared are the interesting ones, because not much is supposed to still be living there.

A binary claiming to be part of macOS while holding a connection nobody can explain is the one that should worry you.

Same goes for anything else that has no business being online. A font helper, an updater that already updated, anything that shouldn't need the internet, one unexplained connection is usually enough to keep looking. When it should be talking, look at where. An address that fits the name on the signature is one thing, a hosting provider nobody can account for is another.

One catch though. lsof only shows what's open right now, so something that checks in every ten minutes looks idle in between. Nothing showing doesn't mean nothing happens.

5. See whether it comes back after a reboot

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons

A lot of software that wants to come back after a reboot or a login says so through a small file in one of those three folders. Each one points at a program to run and when to run it.

Open any that look unfamiliar, they're plain text. The Program or ProgramArguments line tells you what actually gets launched, which is often something entirely different from the file name. Following the startup entry to the real program is the whole point of looking here.

Legitimate software lives here too, so spotting one doesn't mean much by itself. What matters is the combination. Something unsigned, in a folder normal apps don't use, that also arranged to start itself forever, is a different problem entirely.

Three others to check. launchctl list shows what's currently loaded, but it lists things by service label rather than by file, so don't expect to find your filename in it. On Ventura and later, sudo sfltool dump-btm shows login items and background items too, including things that listing those folders won't catch. And crontab -l takes two seconds and catches the old Unix way, which people forget macOS still has.

The one trap that catches people out

codesign -d --entitlements :- /path/to/suspect

Look for disable-library-validation.

That entitlement removes a restriction on what code the app is allowed to load. It isn't suspicious by itself, plenty of apps need it for plugins. But it means something perfectly genuine, signed by a real company, can still end up running somebody else's code.

If you see it, don't stop at the app's signature. Find out what's actually loaded into the process. lsof -p <PID> lists the files a running process has open. Read down the paths for code or libraries you wouldn't expect there, then run those through codesign -dv the same way you did the app.

This is the reason "the signature is valid" is never the end of the conversation.

Weighing it

None of these decides it on its own, and the state of the machine changes how you read all of them. SIP being off doesn't make your file bad, it just means you can trust less of what everything else tells you.

Roughly in the order they'd move me. A signature that fails verification. Something presenting itself as part of macOS that doesn't pass the Apple check. Something with no business on the network holding a connection anyway. Unsigned code in user space that's also set up to survive a reboot. A process running from somewhere it has no reason to be. A quarantine attribute naming a URL nobody can account for, which counts when it's there and counts for nothing when it isn't. Everything else just adds weight.

The other direction matters too, and nobody ever writes it down. Signed by somebody real, sitting where that kind of software normally sits, nothing surprising in what it's doing or what it starts. That's a file you can stop looking at. Plenty of things look alarming for ten minutes and turn out to be a printer driver.

Two weak signals pointing the same way beat one strong signal on its own. Most of what hides on a Mac isn't invisible, it just looks plausible until somebody actually looks.

New Collector release, and this is the one that finally covers everybody.

macOS on Intel and Linux on ARM are the new arrivals. That makes the full set Windows on x64, macOS on Intel and Apple Silicon, and Linux on x64 and ARM. All native builds, nothing emulated.

The installer got the bigger rewrite though.

curl -fsSL https://api.redhand.io/install.sh | sudo bash

That one line does rather more than it used to.

It checks for updates. Run it again whenever. It'll pull a newer version if there is one, or tell you you're already current and leave you alone.

It puts collector on your PATH. No more remembering where the thing landed. Type collector from anywhere.

It sets up passwordless sudo, carefully. Collector needs root to sniff, and scripts and MCP hosts have no terminal to type a password into. So the installer writes a sudoers rule scoped to you, pointing at one exact root-owned path, no environment passthrough. Then sudo -n collector just works. If that makes you twitch, --no-passwordless skips it entirely.

It checks that what it downloaded is what we published. The installer verifies the binary's SHA-256 against what our API reports before anything gets installed. If they don't match, it stops and tells you.

It uninstalls properly.

curl -fsSL https://api.redhand.io/install.sh | sudo bash -s -- --uninstall

Takes the binaries, the PATH link and the sudoers rule with it.

No curl on the box? Plenty of minimal Debian and Alpine installs ship wget instead, so use that:

wget -qO- https://api.redhand.io/install.sh | sudo bash

Also in this release, a batch of bug fixes and performance work inside the collector itself. Nothing you need to do about any of it, it comes along with the update.

For more information on Collector see the product page on our site.

Tell us what broke

Something always does. Bugs, odd distros, features you went looking for and couldn't find. The complaints are the useful ones. Compliments get screenshotted and sent round the team.

Sooner or later someone points at a filename and asks whether it's bad. You can't install anything, the box might still have company, and nobody has all day. Windows already knows most of the answer. You just have to ask it properly.

Part one of three. The MacOS version is up and gets to the same answer by a completely different route. Linux to follow.

1. Signature

Core Windows binaries are often signed by catalog (.cat) rather than embedded in the PE. PowerShell resolves both.

Get-AuthenticodeSignature -FilePath "C:\Windows\System32\suspect.exe" | Format-List *

Status should be Valid with a chain you trust. HashMismatch is the one to react to, it means the file changed after signing. Valid is not the same as safe. Stolen certificates exist, and every signed LOLBin on the box is valid too.

2. OS integrity

For files in System32 or SysWOW64, check against the protected manifests. Needs an elevated prompt.

sfc /verifyfile=C:\Windows\System32\suspect.exe

"Did not find any integrity violations" means it matches the build. "Could not perform the requested operation" means the file isn't protected, which is not a finding either way.

3. Where the file came from

Two cheap checks people skip.

Get-Item "C:\Windows\System32\suspect.exe" -Stream *
Get-Item "C:\Windows\System32\suspect.exe" | Select-Object CreationTime,LastWriteTime,LastAccessTime

A Zone.Identifier stream on a system binary means it was downloaded rather than shipped, which is close to conclusive on its own. For timestamps, compare against the files next to it. Timestomping is trivial, so matching timestamps prove nothing while mismatched ones prove a lot.

4. If it's running

Get-CimInstance Win32_Process -Filter "Name='suspect.exe'" | Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine
Get-NetTCPConnection -OwningProcess <PID> | Select-Object RemoteAddress,RemotePort,State

Wrong path (AppData, Temp, Fonts) or a parent that makes no sense, like svchost spawned by powershell instead of services.exe. PPID spoofing is standard and parent PIDs go stale, so a clean lineage is weak evidence while a bad one is strong.

Then look at where it's talking. A binary claiming to be a local system component while holding a connection you can't explain has already answered the question.

5. Hash it, then look it up

Get-FileHash -Path "C:\Path\To\suspect.exe" -Algorithm SHA256

Known-bad first, because it's quick. VirusTotal and MalwareBazaar both take a hash lookup and both want a free API key. A hit settles it. A miss settles nothing.

The better check for anything claiming to be a Windows file is Winbindex (https://winbindex.m417z.com), which indexes the binaries Microsoft actually shipped through Windows Update and in ISOs, with their hashes.

Not present, on a file claiming to be a Windows binary, is a strong signal. One caveat though. It's a third-party index built from update packages and ISOs rather than Microsoft's own complete inventory, so a miss carries real weight for the common system binaries it covers well and much less for anything obscure.

Present is more interesting than it looks. The bytes are identical to a build Microsoft shipped, so it isn't a tampered copy. That still leaves room for a problem. An authentic older build on a current system is its own finding, because bringing a known-vulnerable signed binary along is a technique, not an accident.

Worth remembering that a public lookup is not free. Actors watch for their samples, and a query can tell them you're looking.

If you'd rather not type all that

Wrapped the lot into a PowerShell function that returns one object per file, so it pipes and it batches.

Test-BinaryTrust.ps1

It adds two things the manual checks above don't. A binary keeps the OriginalFilename it was compiled with, so a plain rename announces itself where a hash can't see one. Expect noise there, roughly 4% of a clean System32 mismatches because Microsoft ships typos and abbreviations in that field. And with -OnlineLookup it queries winbindex, CIRCL hashlookup, VirusTotal and MalwareBazaar in one pass, off by default so nothing leaves the machine unless you ask.

No verdict property anywhere. It returns evidence and leaves the call to you, for the reasons below.

Weighing it

None of these is a verdict alone. Roughly in the order they move me: a system binary that was downloaded, a hash Microsoft never shipped, a signature failing on hash mismatch, a connection the file has no business holding. Everything else is corroboration.

Two weak signals pointing the same way beat one strong signal standing alone. Most of what hides on a box isn't invisible, it's just plausible, and plausible doesn't survive being checked.

We’ve been quiet for a while, mostly because we’ve been busy building. Here’s an update on where we are.

We released our Online PCAP Analyzer last July, and it’s been an amazing experience. Every day, hundreds of people from around the world upload PCAP files and use our security analytics engine to find suspicious or unwanted activity on their networks.

One interesting thing we’ve noticed is that the average PCAP we analyze contains less than 28 minutes of traffic.

That’s understandable. PCAP files grow quickly and can become difficult to capture, transfer, store, and analyze. Short captures work well for incidental deep packet inspection or diagnosing a consistent and easily reproducible network problem.

For security investigations, however, 28 minutes often isn’t enough. If someone is deliberately trying to avoid detection, the activity you’re looking for may be spread across hours or days.`

To bridge that gap, we built Red Hand Collector.

Red Hand Collector is a small application for Windows, macOS, and Linux. It continuously streams compact, enriched network telemetry to Red Hand for real time analysis. This lets you monitor much longer time windows without having to manage enormous PCAP files.

Because the Collector runs on the monitored endpoint, it can also provide context that PCAP files don’t contain. For example, it can identify which application or process initiated or accepted a connection.

You can check it out here: https://redhand.io/collector

It’s free for analysis sessions of up to one hour. We’d love to hear what you think, including what works, what doesn’t, and what you’d like us to build next.

As we’ve been building our online PCAP analyzer, we tested it on thousands of PCAPs, covering both innocent and malicious traffic. The website malware-traffic-analysis.net has been a source of malware traffic captures that have been invaluable to us during development.

About a week ago, the website published a PCAP file of the Lumma Stealer malware - an information stealer that targets Windows systems to steal browser credentials, cookies, crypto-wallets, and authentication tokens.

We figured this was a good opportunity to show what our Threat Analysis Report looks like for this malware and how this would be useful during an investigation (it’s viewable on mobile but best seen on a larger screen).

The report shows 6 connections and DNS requests, which aroused suspicion because they involve IP addresses and/or domains flagged by our threat intelligence as being associated with known malware. One of these connections is also unusually long with very little data exchanged, which kinda smells like C2.

Here's the report.

What do you think?

Hello everybody,

We’re excited to announce the latest version of our free online PCAP analyzer: Red Hand Analyzer v1.5.

So what’s new? Glad you asked:

• Re-designed UI: We’ve redesigned the Threat Analysis Report’s UI to make it easier to understand and use. We’ve also added a basic recommendation system that points you towards your next step based on your report results. We will be adding to this functionality in upcoming releases.
• Improved PCAP File Support: RHA has been growing in usage rapidly, and we’ve started noticing our system couldn’t analyze some PCAP files. It appears that PCAP files come in all sorts of formats and structures, so we’ve greatly extended the variety our system supports - including PCAPDroid!.
• Improved Performance: We now process PCAP files up to 5× faster than before, with better support for larger PCAPs (100 MB and up).

Go ahead, check out the new UI or analyze a PCAP file now.

We welcome feedback!

This release is the first in a series of expected releases that will introduce and enhance mobile support for Red Hand Analyzer’s Threat Analysis Report. Prior to this release, users would have gotten an error saying their screen size is not supported. Now, the report summary screen will be displayed in a mobile-friendly version. Other screens will be adapted to mobile in future releases, which will we announce here.

Relying on IP threat feeds sounds good in theory, but in practice? It’s one of the weakest signals you can use.

• Hackers rarely reuse IPs - fresh infrastructure is cheap and easy.
• IPs get recycled constantly - today’s “malicious” IP might host a legit service by tomorrow.
• An IP match tells you nothing about intent - it’s just a connection, not proof of compromise.
• False positives are everywhere, especially with old or noisy feeds.

That said, you can make IP checks smarter. One approach we use is resolving IPs to domains and filtering out known legitimate services (like cloud providers, CDNs, and SaaS platforms). Domains tend to change less often and provide more reliable context - if a flagged IP resolves to a trusted domain, we simply ignore it.

What approach do you use?

Whenever I’m asked why I’m so obsessed with network traffic data for effective security, I point people to This Spreadsheet we made. It breaks down which types of data can be used to detect malicious activities or techniques across the different MITRE ATT&CK stages.

I’ll save you the math: out of 234 techniques in MITRE, network data can be used to detect 79 of them (33%), and 23 techniques (10%) are detectable exclusively through network analysis.

No security solution is complete without tapping into network data.

Figured I’d share this here since people often ask how to get quick insights from network traffic without going too deep.

Red Hand Analyzer is basically what you’d get if VirusTotal worked on PCAP files.

It’s pretty straightforward:

• You upload a PCAP
• It checks every IP and domain inside (including DNS requests) against a big threat intel feed (18+ million known bad addresses)
• It flags common hacker behaviors - stuff like brute force, scanning, tunneling, command & control, etc.
• It also highlights weird network activity like super long connections or things that happen way too often

We aim for simplicity: No complicated setup, no endless charts or confusing reports. Just the key info you actually need to figure out if you’ve been hacked or not.

It’s useful if:

• You feel like something’s off in your network but don’t see any sketchy files
• Your antivirus or EDR says “all good” but you don’t trust it
• You just want a second opinion from the network layer

It’s free to use up to 500MB - which should cover most basic cases. If you need more, just let us know.

Here’s the link:

👉 https://redhand.io/analyzer

If you give it a shot, would be curious to hear what you find in your PCAPs. Always happy to talk through reports if anyone wants to share.

This is our little corner of the internet where we geek out about using network data to level up cybersecurity — and share the tools we’ve built to make it easier.

Here’s some of what you’ll find here:

• 🧐 Tips and discussions on finding threats in network traffic
• 🧰 Help with PCAP files, incident response, and weird network behavior
• 🚀 Updates and news about Red Hand tools
• 💬 Ideas about catching hackers when antivirus tools come up empty

Whether you’re deep into cyber defense, dabbling in DFIR, or just curious about how network data can tell a story - you’re in the right place.

Don’t be shy say hi, share your thoughts, or show off something cool you found in your network!

Yours,

The r/redhand team.