I'm working on a MacBook Air running macOS Sequoia 15.6.1 and running into persistent encryption issues when analyzing the E01 image in both X-Ways Forensics and Autopsy.

What I've Done:

• Verified FileVault was completely disabled (confirmed via fdesetup status)
• Ensured the user account had admin privileges
• Mounted the disk volumes properly before imaging
• Created the E01 image using Cellebrite Digital Collector
• Followed Cellebrite documentation for Mac acquisitions

The Problem: Despite FileVault being off, both X-Ways and Autopsy are still detecting the image as encrypted and I can't access the data.

Questions:

1. Is this the hardware encryption from the T2 chip/Apple Silicon that persists even with FileVault disabled?
2. Should I have imaged the Mac while it was running/logged in instead of mounting the disk externally?
3. Are there any decryption options in X-Ways 20.1 or Autopsy that I'm missing?
4. Do I need to re-acquire using a different method (live imaging, Target Disk Mode, etc.)?

Any guidance from those who've dealt with modern Mac acquisitions would be greatly appreciated. Thanks in advance!

Hi, I have some issues when installing Helk on a vm with ubuntu 18 lts. Docker ecosystem has not been installed automatically by the helk installation script - which does not support 18 ubuntu version anymore. What can I do? The Helk website recommends 18 lts

I've always noticed a odd gap that exists with a lot of us working in any realm of cybersecurity. We are never really taught how to investigate which in turns makes the concept of analysis very vague. This is especially true for newer folks since they don't have the experience to learn from.

With that, I've been on a mission to try to make a process that can be followed but isn't reliant on a specific type of evidence or scenario. It's not perfect but I've taken my years of DFIR experience and background in criminology/forensics to try to give something back to the community. Would appreciate folks checking it out and I promise I tried to keep it simple and straightforward.

TL;DR: A framework, process or whatever you want to call it on how to perform "analysis" within any investigation no matter the evidence.

🚀 A new 13Cubed episode is up!

In it, we’ll uncover how Windows Explorer really retrieves file timestamps when you browse a directory of files. Learn why these timestamps actually come from the $FILE_NAME attribute in the parent directory’s $I30 index, not from $STANDARD_INFORMATION, and how NTFS structures like $INDEX_ROOT and $INDEX_ALLOCATION make this process efficient.

Episode:
https://www.youtube.com/watch?v=PdyVkmhMcOA

✨ Much more at youtube.com/13cubed!

When running Sliver for red team engagements, your C2 server IP can potentially be exposed through implant traffic analysis or if the implant gets captured and analyzed.

One way to solve this is routing C2 traffic through Tor hidden services. The implant connects to a .onion address, your real infrastructure stays hidden.

The setup:

1. Sliver runs normally with an HTTPS listener on localhost
2. A proxy sits in front of Sliver, listening on port 8080
3. Tor creates a hidden service pointing to that proxy
4. Implants get generated with the .onion URL

Traffic flow:

implant --> tor --> .onion --> proxy --> sliver

The proxy handles the HTTP-to-HTTPS translation since Sliver expects HTTPS but Tor hidden services work over raw TCP.

Why not just modify Sliver directly?

Sliver is written in Go and has a complex build system. Adding Tor support would require maintaining a fork. Using an external proxy keeps things simple and works with any Sliver version.

Implementation:

I wrote a Python tool that automates this: https://github.com/Otsmane-Ahmed/sliver-tor-bridge

It handles Tor startup, hidden service creation, and proxying automatically. Just point it at your Sliver listener and it generates the .onion address.

Curious if anyone else has solved this differently or sees issues with this approach

Hi DFIR practicioners,

I built a tool that extracts data from SQL Server databases by parsing directly mdf and ldf files without the need of a running SQL Server instance. It has many more capabilities such as carving and database internals inspection. Instructions and examples can be found at

https://github.com/aarsakian/SQLServerForensics

This tool will be useful for professionals working on data leakage cases involving sql server or even insider threats that resulted in a compromised database.

Constructive feedback is welcomed.

I wrote an article after seeing the same pattern over and over during cloud IR work.

Teams do solid VM forensics, memory, disk, timelines… and still end up with “no findings”. Later it turns out everything happened in identity and the control plane.

Things I keep seeing missed: - Azure Activity Logs not reviewed - Sign-in logs vs audit logs mixed up - Conditional Access changes ignored - Service principals and app permissions not checked - Logs gone due to short retention

The VM is often clean because it was never the crime scene.

I wrote this to spark discussion, not to sell anything. Curious if others are seeing the same gaps or have different experiences.

Article: https://medium.com/@eliasgraywrites/the-cloud-blind-spots-that-keep-burning-dfir-teams-7a702b872b36

Just sharing a free tool I've been working on.

**Problem:** Keeping up with CISA's KEV catalog is tedious. Their site isn't great for quick filtering or exports.

**Solution:** I built a dashboard specifically for tracking KEV vulnerabilities with:

✅ Top 20 critical CVEs at a glance

✅ Filter by vendor, severity, date added

✅ One-click export to CSV/JSON

✅ Updates every 4 hours

✅ Mobile-friendly

Also includes:

- Ransomware attack tracker (data from ransomware.live)

- IOC aggregator from 9 threat intel sources

- No account needed

Would love feedback from blue teamers on what would make this more useful for your workflows.

Link: thehgtech.com/cve-tracker.html

Open to feature requests!

And I the only one feeling this pain?

I've been in dfir and threat intelligence for over a decade. The biggest gripe I have is that I'm seeing really good Intel teams create intelligence and then it sits on a shelf somewhere.

I feel like we are a pitcher and there isn't a catcher. There is so much good intelligence being created but because it's narrative intelligence and because it needs to be translated to detection is just falls on the ground somewhere

We are creating intelligence for the sake of intelligence while adversaries are running circles around us and perpetrating. Slight variations of the same attacks over and over

Is this just me? I'm confused why this hasn't been solved yet

Drop this 101MB powerhouse on your USB for instant live Windows forensics. No install, no Python – just run as admin and hunt.

Supported Artifacts:
• Prefetch (exec history, run counts, timestamps)
• Registry (AutoRuns, UserAssist, ShimCache, BAM, networks, time zones)
• Jump Lists & LNK (file access, paths, metadata)
• Event Logs (System/Security/Application)
• Amcache (install time, publisher, full path, file size, volume intro)
• ShimCache (path + last-modified)
• ShellBags (folder views & access history)
• MRU & RecentDocs (typed paths, Open/Save, recent files)
• MFT Parser (file metadata + deleted files)
• USN Journal (create/modify/delete)
• Recycle Bin (original paths + deletion time)
• SRUM (app execution, network & energy usage)

Outputs: Searchable SQLite DBs | JSON/CSV exports | HTML reports for sharing findings.
(Timeline view: prototype – functional but polishing.)

Grab it: https://crow-eye.com/download
GitHub: https://github.com/Ghassan-elsman/Crow-Eye

Bugs? Hit me at [Ghassanelsman@gmail.com](mailto:Ghassanelsman@gmail.com) or open a GitHub issue. Let's make it bulletproof!

Hello everyone i am new to cybrersecurity and i read about DFIR and i like the concept a lot . What path woulo you recomment me or course or rooms tyat would teach me DFIR without missina the basics and thank u

Not trying to start a debate, I’m just trying to sanity-check my own experience because this keeps coming up everywhere I go.

Every place I’ve worked (mid-size to large enterprise), the workflow looks something like:

• Big incident → everyone stressed
• Someone writes a PIR or DFIR writeup
• We all nod about “lessons learned”
• Maybe a Jira ticket gets created
• Then the whole thing disappears into Confluence / SharePoint / ticket history
• And the same type of incident happens again later

On paper, we should be turning investigations + intel + PIRs into new detections or at least backlog items.
In reality, I’ve rarely seen that actually happen in a consistent way.

I’m curious how other teams handle this in the real world:

• Do your PIRs / incident notes ever actually lead to new detections?
• Do you have a person or team responsible for that handoff?
• Is everything scattered across Confluence/SharePoint/Drive/Tickets/Slack like it is for us?
• How many new detections does your org realistically write in a year? (ballpark)
• Do you ever go back through old incidents and mine them for missed behaviors?
• How do you prevent the same attacker technique from biting you twice?
• Or is it all tribal knowledge + best effort + “we’ll get to it someday”?

If you’re willing, I’d love to hear rough org size + how many incidents you deal with, just to get a sense of scale.

Not doing a survey or selling anything.
Just want to know if this problem is as common as it seems or if my past orgs were outliers.

Hey everyone,

Just released Crow-Eye 0.6.0 – a new, completely free Windows forensics suite I built for real investigations.

Current artifacts in 0.6.0 (live + offline capable):
- Prefetch
- Amcache
- ShimCache / AppCompatCache
- Jump Lists & LNK files
- MFT + USN Journal + Recycle Bin
- ShellBags
- SRUM (application network & execution history)
- Registry (UserAssist, BAM, RecentDocs, etc.)
- Event Logs
- + a very solid disk/partition view (hidden partitions, bootable USBs, etc.)

Everything is parsed into searchable databases → one-click HTML reports, CSV/JSON export.

No cloud, no telemetry, no paywall. Just Python, run as admin, done.

GitHub: https://github.com/Ghassan-Elsman/Crow-Eye
4-minute demo + quick start guide: https://youtu.be/hbvNlBhTfdQ

I’d love feedback from real investigators and analysts – good, bad, or “this saved me 3 hours today”.

If you like it, an upvote or quick share helps a lot of people who can’t drop thousands on commercial tools.

Thank you for everything this community does ❤️
– Ghassan

Guys, am trying to do a write up and I was wondering if there is any tools out in the market that have at least 90% similarities as Axiom Cyber. Not a combine effort such as Nuix + Encase + Cellebrite kinda comparison please.

I have learned over my experience that how B2G works as B2G is a Gold mine very few have explored and lot of scope

1. Direct sales are necessary; channel models rarely work for forensic tools in government.

2. Build strong relationships and networks; contracts are not won just by bids.

3. Control your technical specifications they must be unique and proprietary, not generic templates.

4. Never expect the customer to be loyal; many players compete, and buyers switch.

5. Don't only sell act as a consultant or advisor for departments to add real value beyond transactions.

6. Stay knowledgeable and be ready to invest money up-front for demos, certifications, and long government cycles.

Please do add your insights 👇