So, I had previously created a quick summary about USB activity, but I got a lot of requests asking for a more detailed version. That’s exactly why I’m here with this updated article! I’ve tried to keep things simple while adding a bit more depth so it’s easier to understand and actually useful. If you’re curious to learn even more, don’t forget to check out the full USB forensics series as well — it covers everything in much greater detail.. USB activity summary Windows Even

Part 1: https://www.cyberengage.org/post/meet-the-ce-sentinelone-assistant-i-built-it-for-myself-but-you-can-try-it-too 1. DFIR Investigation Tab The DFIR Investigation tab is the biggest addition to the CE S1 Assistant since launch. It takes a completely different approach to the problem — instead of helping you write queries to find things, it analyses logs you already have. Here is the workflow it was built around. You get an alert. You open SentinelOne Deep Visibility and

Press Windows + R. Type something. Hit Enter. That's it — that's the entire user interaction. What happens in the registry afterward is far more interesting. The Run dialog has existed since Windows XP and hasn't changed much since. It's the power user's shortcut — a quick way to launch applications, open specific paths, fire up system tools, or connect to network resources without touching a mouse. Most casual users have never opened it. The ones who have tend to use it con

(How logs are generated, why they matter, and how investigators actually use them) Big picture Before you can analyze logs , you need to understand where logs even come from in Google Cloud. Google Cloud generates logs in two fundamental ways : Platform-level Audit Logs → Logs generated automatically by Google Cloud itself Application / workload logs → Logs generated by what you run (VMs, apps, network traffic, etc.) From a DFIR point of view: Audit Logs tell you “what chan

The core idea In Google Cloud, Service Accounts are identities for machines , not humans .They are used by resources like VMs, Cloud Functions, Kubernetes, etc. to talk to other Google Cloud services. Unlike AWS (where users can directly generate API keys), Google Cloud forces you to use Service Accounts when you want: Programmatic access Static credentials Non-interactive authentication So:👉 If code needs access, it almost always runs as a Service Account. ---------------