Search Results

The Feature Inventory  in Carbon Black Cloud is an essential tool that helps administrators and security professionals manage and investigate their endpoint security posture effectively. Let’s dive into its key components, starting with the Endpoints  tab, and explore the features and capabilities it provides. Endpoints Tab The Endpoints  tab is your starting point for managing and investigating endpoints in your environment . Below is an overview of its layout and functionality: Filters for Investigation On the left-hand side of the tab, you’ll find several filters that simplify endpoint investigations. These filters include: Sensor Status : Displays whether sensors are active, inactive, or in an error state. Operating System (OS) : Allows you to filter endpoints by their operating system. Sensor Version : Helps identify which version of the Carbon Black sensor is installed. Other Metadata Filters : These include options for grouping endpoints by their organizational unit, IP range, or other custom tags. Each filter is self-explanatory and designed to make pinpointing specific endpoints quick and efficient. Top-Right Controls At the top-right corner of the screen, you’ll find two key options: Sensor Options The Sensor Options  menu provides several actions to manage sensors: Manage Sensor Settings : Enables deletion of unused sensors. View Company Code : Displays the company code required during sensor installation. Download Sensor Kit : Offers the installation package for the sensor. Send Installation Request : Allows you to email installation instructions by entering the recipient’s details. Add Group: The Add Group  feature helps you dynamically assign sensors to specific groups based on predefined criteria : Sensors matching all criteria for a group are added automatically. If a sensor does not match any group’s criteria, it is assigned to the default Standard policy . Group assignments are dynamic and will change if a sensor no longer meets the criteria for its current group. You can define group criteria using “AND” or “OR” conditions, offering flexibility in your configurations. Note : Sensors can belong to only one group at a time. If multiple groups match, the sensor is assigned to the group with the highest priority. Sensor Update Status Adjacent to the Endpoints  tab, you’ll find the Sensor Update Status  section. This feature displays: Sensor versions installed across your environment. Details of sensors requiring updates or showing errors ------------------------------------------------------------------------------------------------------------- Live Example: Viewing Sensor Details When sensors are available, you’ll see details organized by status. Filters such as Sensor Status  or Signature Status  provide critical insights: Sensor Status: Carbon Black provides detailed statuses for sensors, including connectivity and operational health. For example: Active : Sensors reporting data and functioning correctly. Inactive : Sensors not reporting or disabled. Error : Sensors with connectivity or configuration issues. Signature Status : The Sig  column in the interface indicates the status of sensor signatures: Signature version status Circle : Signatures are up to date (released within the last 7 days). Triangle : Signatures are outdated (older than 7 days). Square : Signatures are unreported or unidentifiable, possibly due to local scan configuration issues or connectivity errors. These visual indicators make it easy to assess and prioritize updates or troubleshooting efforts. Sensor update status: Actions on Endpoints When managing endpoints in Carbon Black Cloud, you can take the following actions: Add to Asset Groups Add selected endpoints to specified asset groups (if you’re using this feature). Remove from Asset Groups Remove endpoints from specific asset groups. Assign Policy Assign a prevention policy to determine sensor behavior. Update Sensors Update the sensor version on selected endpoints. Start Background Scan Initiate a one-time inventory scan to identify pre-existing malware. If the controlling policy includes background scan settings, the scan type (standard or expedited) will follow that policy. Otherwise, the default is a standard scan. Pause Background Scan Temporarily stop the background scan. It will restart when the service or endpoint restarts. Enable/Disable Bypass Enable bypass: Temporarily disable policy enforcement on the endpoint. Disable bypass: Reinstate policy enforcement. Quarantine/Unquarantine Assets Quarantine an endpoint to limit its outbound traffic and block inbound traffic. Release an endpoint from quarantine when it is no longer a threat. Uninstall Sensors Remove macOS and Windows sensors. After removal, the sensor will appear as deregistered until deleted. Delete Deregistered Assets Fully remove a sensor from the Carbon Black Cloud console. Disable Live Response Disable Live Response for remote investigations and remediation. Re-enabling it requires sensor reinstallation. Query Assets Run SQL queries against endpoints to gather specific information. Manage Sensor Gateway Connection Control whether endpoints communicate directly with Carbon Black Cloud or through a Sensor Gateway. Investigate and Go Live: Threat Hunting and Commands Each endpoint provides several options for deeper investigation. Below are some key features: Investigate This is your go-to option for threat hunting . If you want detailed steps on this, check out our article below Mention Link: Go Live The "Go Live" option allows you to run live commands on an endpoint. These commands can be invaluable during an active investigation. Query Asset Last Option (Prebuilt queries) USB Devices Management Under the "USB Devices" tab, you can monitor connected USB devices. The filters and options available here are self-explanatory, as shown in the screenshot below (see attachment). However, you might wonder, how do I block USB devices? The answer lies in creating a policy. When setting up a policy (as detailed in this article), you can include rules for blocking USB devices. Once a device is blocked, you will see an option to approve or reject it directly under the "USB Devices" tab. Example Scenario: A USB device is blocked by policy. Navigate to the "USB Devices" tab to see the blocked device. Approve the device if needed, or leave it blocked. Sensor Groups We’ve discussed sensor groups earlier. For more details, refer to the "Actions on Endpoints" section above. Sensor groups are an efficient way to manage multiple endpoints with similar configurations or policies. Conclusion By understanding these features, you can take full advantage of Carbon Black Cloud for endpoint management, threat hunting, and USB device control. Use the tools wisely to enhance your organization's cybersecurity posture. Keep experimenting with these settings, and don’t hesitate to tweak configurations based on your organization's needs. I’ll leave you here for now, but stay tuned for my next guide—there’s always more to learn! Upcoming Article: Carbon Black (P6:Settings): A Practical Guide/An Practical Training

---------------------------------------------------------------------------------------------------------- Clarification Note: I've noticed that this article has sparked some important discussions, and I truly appreciate the feedback. To clarify, I’m not suggesting that the PICERL model is the only correct approach, nor am I claiming that the DAIR model is superior. The intent here is simply to provide a structured, understandable way to view the incident response lifecycle—especially for organizations that currently lack any formal process. If your team prefers a dynamic or adaptive approach, or chooses to follow the DAIR model or a customized version of PICERL, that’s absolutely valid. The goal is not to force a one-size-fits-all solution but to encourage more structured and thoughtful incident response planning. This article is meant to provide a foundational understanding, and I fully support adapting the model to fit your organization’s maturity level, threat landscape, and operational style. --------------------------------------------------------------------------------------------------------- If you guys remember, I had written a post a while back about the DAIR model  — and honestly, the response was wild. I got so many messages, and follow-ups asking for a deeper dive into the topic. So here I am, trying to break it down better, one phase at a time. https://www.cyberengage.org/post/rethinking-incident-response-from-picerl-to-dair https://medium.com/@cyberengage.org/rethinking-incident-response-from-picerl-to-dair-7b153a76e044 Let’s get into it. ------------------------------------------------------------------------------------------------------------- 🚨 First, let’s be clear: Incident Response is not  linear There’s no magical 6-step recipe to handle incidents. Real-world incidents are messy. You’ve got multiple events happening in parallel , your alerting system is going off, someone’s panicking, and maybe your containment plan just half-worked. Things overlap  — and a linear approach just doesn't hold up anymore . For example: You detect something sketchy — cool, that’s your detection phase, right? But what if during containment or eradication, you uncover a whole new set of TTPs  or realize that another part of the system was compromised before detection even kicked in? Now you’re circling back. This is where DAIR  — the Dynamic Approach to Incident Response  — steps in. It’s not about replacing PICERL. It’s about shifting our mindset to a flexible, outcome-driven process . ⚙️ DAIR: Dynamic. Not Chaotic. DAIR breaks down into waypoints  rather than locked steps. Think of it like GPS rerouting in real time — you still want to reach your destination (containment and recovery), but you may need to take a few turns based on roadblocks you hit along the way. Here’s the core flow: Detect Analyze Improve Respond But in real life, it's more of a loop  than a line. ------------------------------------------------------------------------------------------------------------- 🧠 Preparation: The underrated superhero of IR Before you even start thinking about detection, you’ve gotta "know thy organization." Not just buzzwords — I’m talking about: What actually matters to the business? What’s your visibility like — do you have endpoint telemetry? Firewall logs? Sysmon? Or are you just hoping EDR will save the day? Who’s reviewing the logs, and how often? What’s your backup recovery process? Ever tested it? (Spoiler: most haven’t.) Also, can your IR team actually respond ? Do they get tabletop exercises , actual practice runs , or are they just hoping Google + gut feeling = success? Too many IR teams get stuck during a real event because they weren’t prepared for their own tools, their own network, or their own people. The DAIR model, just like PICERL, starts with preparation  because without it, everything else falls apart fast. ------------------------------------------------------------------------------------------------------------- 🔍 Detect: It’s not about noise — it’s about meaning Detection is where most IR teams spend their lives. But let’s break it down: IOA (Indicator of Attack)  = something an attacker does to get what they want (e.g. lateral movement, bypass attempts, privilege misuse) EOI (Event of Interest)  = “Hey, does this event actually matter to us  based on our  risk and context?” You can get a million IOAs, but if they don’t align with what your organization cares about, it might not even qualify as an EOI. That’s a big difference. Not every alert needs panic mode. Now, detection can be passive  (you get alerted from your SIEM, a user reports weird behavior, etc.), or active  — a.k.a. threat hunting. Active detection is where you're out there looking  for trouble. And once you detect something, that’s when clock starts ticking. Also, don’t underestimate human signals : A sysadmin noticing weird CPU spikes, or your helpdesk getting calls about failed logins — these can be golden early indicators . Blend your tech intel  (logs, EDR, network alerts) with your people intel , and your detection game gets way stronger. ------------------------------------------------------------------------------------------------------------- 🔍 Verifying & Triage — Don’t Just Jump the Gun Alright, so just because you spotted something weird doesn’t mean it’s go-time.This is where verify and triage  come into play — and trust me, this step saves you from chasing ghosts or overreacting to a false alarm. So what are we really doing here? We're asking basic but critical questions : “Is this actually a real incident?” “Is it something that impacts our environment or our business?” “Is it worth pulling in the full IR team, or can we handle it quietly?” Let’s be honest — not everything weird is worth a full-blown IR war room.Sometimes it’s just noise.Sometimes it's someone forgetting their password and triggering alerts with failed logins from five devices at once. So we verify : Is this event something that should even be on our radar? And then we triage : Based on what we know so far, who do we need in the room? For example, if it’s someone threatening a coworker over email, maybe that’s an HR + legal thing, not just IR. If it's ransomware in your backups? That’s game-on. Also — don’t skip getting management input here. You don’t want to be guessing whether something is “business-critical” or not. Always align technical actions with business priorities. That’s how you earn trust. ------------------------------------------------------------------------------------------------------------- 📏 Scoping: How Bad Is It, Really? Once we know it’s real, the next question is: How deep does this thing go? Scoping is about figuring out the blast radius. Which systems are affected? Which users? Which parts of the network? Maybe you found a malicious registry key with an encoded blob in one system — cool, but how many other systems have that same key ? Maybe an attacker used a known IP — where else did that IP touch your infrastructure? To do this right, you’re gonna pull from a ton of data sources : EDR, SIEM, logs, threat intel, PowerShell outputs, config files, even registry snapshots if needed. Sometimes the scoping phase alone is a full-on detective mission. And here’s the catch: you’ll probably do this more than once. The DAIR model treats response phases as a loop , not a one-and-done checklist. So as you uncover new info (TTPs, new users, lateral movement), you’ll loop back and rescope  again — and again — until you're confident you’ve mapped the full picture. Skipping or half-assing this step is what leads to "Oops, we missed that second C2 channel."  Don’t be that IR team. ------------------------------------------------------------------------------------------------------------- 🛑 Contain — Stop the Bleed Alright, now that we know what we’re dealing with, it’s time to freeze the attacker  in place. Containment  is all about one thing: making sure the bad actor can’t keep doing damage  while we plan next steps. This isn’t just pulling the plug. It’s smart isolation : Throw the host into a private VLAN Block known attacker IPs Change DNS routes Lock compromised user accounts Cut C2 channels with some smart ACL magic Now, containment doesn't always mean full-on disconnection. Sometimes you want to watch what they’re doing for a little longer — gather more data before cutting them off. And speaking of data: this is a golden time for evidence collection .If you isolate a host, grab logs, memory dumps, network traces — before  the system reboots or changes state. But don’t go overboard. If leadership doesn’t care about forensic review or court action, maybe you don’t need a full 100GB image of that file server. Balance data collection vs. business value . Also — everything you do during containment should support what’s coming next. For example, if you’re revoking credentials now, you’re also laying the foundation for eradication  and recovery  later. That’s why DAIR is a loop — not everything is siloed. ----------------------------------------------------------------------------------------------------- 🚨 Eradicate: Time to Clean House Once you’ve caught wind of the attacker’s activity and put up the initial blocks (aka containment), it’s time to get serious: erase their fingerprints from your house . Eradication isn’t just about kicking them out. It’s about reversing the damage they did , and making sure no doors are left open for them to stroll back in. Here’s what this really looks like: Wipe out malicious processes, hidden users, or rogue scheduled tasks. Roll back from known-good backups — assuming you’ve got some. Remove persistence mechanisms (e.g., registry tweaks, rootkits, or cron jobs). Patch up the hole they crawled through — whether it was a CVE, weak creds, or a bad config. If they messed with source code or tried sneaky fraud tricks (hello, bogus transactions), unwind all of that too. This phase leans heavily on your earlier investigation work. What you learned while analyzing logs, running memory forensics, or doing packet captures — that’s what guides your clean-up operation. 🧠 Tip: Containment ≠ Eradication.  One stops the bleeding, the other heals the wound. ----------------------------------------------------------------------------------------------------- 🔧 Recover: Don’t Just Reboot — Reinforce Alright, so you’ve cleaned up the mess. Now what? Recovery  isn’t about just flipping the switch and saying, “We’re good.” It’s about making sure we don’t end up in this same mess again. This is where root cause analysis  comes into play. Not just what happened — but why  it happened. Ask yourself: Why was this even possible? Was it a bad policy, or a good one nobody followed? Did our alerts fire and nobody noticed? Was that admin using the same password since 2017? Recovery also means: Rebuilding or restoring systems with clean images. Changing compromised credentials and revoking tokens. Reissuing API keys or cloud creds. Validating app integrity (especially for dev or prod environments). Getting SMEs to test the system before it goes live again. And yes — test everything. Don’t just patch and pray. Make sure everything works as expected before  you bring it all back online. And when you do go live? Watch those systems like a hawk. Assume the attacker wants back in. ----------------------------------------------------------------------------------------------------- 🔁 Repeat: Because One Loop Is Never Enough Let’s be real — IR isn’t a one-and-done process. During the recovery or eradication phases, you’ll often discover more indicators, more footholds , or other places where the attacker left a mark. And when that happens? You don’t just patch and move on. You loop back : Re-scope the incident based on new findings Re-contain the new areas Re-analyze logs or malware samples Re-do eradication if needed Expand recovery if more systems are impacted You’ll rinse and repeat this until: There’s nothing left of the attacker’s presence Stakeholders are confident the threat is neutralized You’ve implemented proper safeguards to prevent a repeat This isn’t just busywork. It’s how real IR works in the field . Especially when you’re dealing with APTs or any attacker with actual skills, you’re going to learn more as you go . ----------------------------------------------------------------------------------------------------- Debrief: Let’s Talk Real Talk Post-Incident Alright, the chaos has settled, the alerts have calmed down, and you’ve officially closed the incident. But we’re not done yet. It’s time to debrief —and no, this isn’t just about typing up a long, boring report. This is your chance to actually learn something  from the whole mess. This is where we sit down and talk: What worked? What completely flopped? What can we do better next time? Sometimes this is a polished PDF with a cover page and timeline. Sometimes it’s just well-documented notes in your IR platform or ticketing system. Format doesn’t matter. Value does. So what should the Debrief look like? Capture what happened (timeline, impact, decisions made). Be honest. No fluff. Just facts (and where you’re not sure, make it clear it’s conjecture). Record what tools and people helped vs. slowed things down. Highlight wins—your team did something right in the heat, so give credit. Then, use it! Share it with key stakeholders (they might finally approve that EDR upgrade you’ve been asking for). Use it to fix broken playbooks , fine-tune escalation paths , and close the feedback loop . Schedule a follow-up (don’t ghost your own process). Did the changes you suggested actually happen ? Pro Tip: Right after an incident, security is fresh in everyone’s mind. It’s the perfect moment to ask for improvements: better logging, better tooling, more training, etc. The biggest mistake is skipping the debrief. That’s how lessons get lost. And remember:  The next incident is coming . What you learn here will determine whether you’re sprinting or stumbling when it hits. ----------------------------------------------------------------------------------------------------- Stay flexible. Stay curious. And stay humble — because attackers love when defenders get lazy.

When managing Carbon Black, the Enforce  tab plays a pivotal role . It houses the tools for creating and managing policies , which dictate how sensors interact with assets, prevent threats, and allow or block specific behaviors. Introduction to Policies Policies in Carbon Black are collections of prevention rules and behavioral settings. These define how sensors interact with endpoints to: Allow or block specific behaviors. Implement custom blocking rules. Modify communication between sensors and the Carbon Black Cloud. Interface Overview When you click on the Policies  section, you’ll find: Left Panel:  Lists all your created policies. Main Panel:  Contains tabs like General , Prevention , Local Scan , and Sensor  for each selected policy. ------------------------------------------------------------------------------------------------------------- Policy Tabs and Their Functions 1. General Tab This section provides basic information about the policy: Policy Name  and Description. Additional configurable settings. 2. Prevention Tab This is the core of policy management. It allows users to configure: Permissions : Permissions in Carbon Black involve whitelisting paths or applications . Unlike other tools like SentinelOne, Carbon Black uses flexible path-based formats for exclusions: Example: C:\windows\carbonblack\** **\carbonblack\** Core Prevention Settings : Use Carbon Black’s backend engines for threat detection and response . These s ettings allow you to configure actions like terminating processes or generating alerts. Blocking and Isolation Rules Carbon Black offers robust capabilities, such as path-based blocklisting: Example: Block PowerShell and Python executables using: **\powershell*.exe **/python USB Blocking Enable or configure USB restrictions as per your organizational requirements. 3. Sensor Settings Fine-tune how sensors operate, including options for auto-deleting known malware and enabling local scanners. ------------------------------------------------------------------------------------------------------------- Creating a New Policy To create a policy: Click New Policy . Fill in details like: Name  and Description. Copy Settings From : Use predefined templates provided by Carbon Black for common use cases. These serve as baselines that you can modify to suit specific needs. Predefined Policies Predefined policies are templates that: Establish a baseline level of enforcement. Can be assigned to sensors. Allow customization but cannot be deleted. Each Predefined policy with description: Now after Writing description and Policy name next tab you have to configure - Core prevention and Permission (I am Leaving those as default because these are testing policies) In Below screenshot if see there are few process which are predefined by Carbonblack. Example in case of Carbonblack thinks its Adware it will terminated to process automatically. (How cool is that!) For My perspective, Do not touch below configuration even you creating new policy for production environment (Leave those as default) . If you want to add any other path or file name you can add by clicking add file path Last thing to configure in Policy is USB Blocking: If needed, you can add rules to block USB devices. This is optional and depends on your use case. Once you’ve configured the required settings, your policy is ready to go! ------------------------------------------------------------------------------------------------------------- Reputation Management The Reputation  tab is where you can manage files and applications based on their reputation. Blocking Hashes : You can block specific SHA-256 hashes if you know they’re malicious. Adding Exclusions : Similarly, you can add hashes to an exclusion list to avoid false positives. This feature provides flexibility and precision for managing files based on their known behaviors. ------------------------------------------------------------------------------------------------------------- Malware Removal Managing detected malware is one of the core features of Carbon Black Cloud. Here’s how to handle it effectively: Detected Malware : The Detected  tab shows files classified as KNOWN_MALWARE, SUSPECT_MALWARE, or PUP (Potentially Unwanted Program) . You can: Search for specific files by hash or filename. Take action to delete malware directly from the Investigate page. Auto-Deleting Known Malware :You can configure policies to automatically delete known malware after a specified time. Go to Enforce > Policies . Select the desired policy and enable Auto-delete known malware hashes after . Choose the time frame and save. Deleted malware moves from the Detected  tab to the Deleted  tab. Remember, once malware is deleted, it cannot be restored, so proceed carefully. ------------------------------------------------------------------------------------------------------------- Cloud Analysis The Cloud Analysis  feature integrates with Symantec CYNIC to improve protection against unknown threats. Here’s how you enable it: Navigate to Enforce > Policies . Select a policy. Enable Submit unknown binaries for analysis  under the Sensor tab. This submits "NOT_LISTED" binaries (e.g., .exe, .dll) to Symantec CYNIC for automated analysis. It’s worth enabling this feature to bolster your defenses against new and evolving threats. ------------------------------------------------------------------------------------------------------------- Recommendations Carbon Black Cloud generates recommendations to improve the health of your environment. These suggestions are based on: Blocked events in your organization. Global insights from other organizations. Accepted reputation rules. You can review these recommendations and apply them to optimize your configurations. ------------------------------------------------------------------------------------------------------------- Wrapping Up That’s all you need to know about policy management in Carbon Black Cloud! From exclusions and blocking rules to handling malware and leveraging cloud analysis, you now have a solid foundation to manage policies effectively. Keep experimenting with these settings, and don’t hesitate to tweak configurations based on your organization's needs. I’ll leave you here for now, but stay tuned for my next guide—there’s always more to learn! ---------------------------------------------------------------------------------------------------------- Upcoming article: Carbon Black (P5:Inventory): A Practical Guide/An Practical Training ----------------------------------------------------------------------------------------------------------

The Investigate  feature in Carbon Black is a powerful tool that allows you to perform deep searches, analyze details, and hunt for suspicious activities across your environment . It’s like a forensic magnifying glass, enabling SOC analysts to dig into both failed and successful operations  performed by applications and processes on endpoints. While I won’t dive into a full analysis tutorial here, this is an overview of how the feature works and why it’s so useful. Let’s break it down. ------------------------------------------------------------------------------------------------------------ Overview of the Investigate Page When you open the Investigate  page (screenshot provided below), you’ll notice its similarity to SentinelOne’s timeline feature. Filters on the Left : These allow you to refine your search. Search Bar : Positioned at the top, you can run queries tailored to your investigation needs. Search Guide : Found at the top-right, this embedded guide assists you in crafting advanced queries. Carbon Black markets this feature as a way to analyze every observation stored in the cloud , allowing you to: Identify failed or successful operations. Collect and act on data from your search results. Use advanced search techniques for detailed visibility into events, processes, and observations. ------------------------------------------------------------------------------------------------------------ How to Use Investigate: A Basic Example Let’s revisit a scenario from a previous article: you’ve created a rule to block wmiprvse.exe when invoked by cscript.exe. Now you want to investigate. Run a Simple Query : process_name:cscript.exe This query fetches all processes matching the name cscript.exe. Below the search bar, you’ll find three tabs: Observations Processes Auth Events ------------------------------------------------------------------------------------------------------------ The Observations Tab The Observations Tab  provides a list of all interesting activities in your environment that didn’t necessarily trigger an alert. Use Case : You detected a suspicious file and want to hunt for related activity. Observations allow you to search for processes, registry modifications, or other actions tied to the file. Filters on the Left : These can be used to narrow your hunt and pinpoint specific activities. Action Tab : Clicking on the graph-like structure (Process Analysis) lets you investigate further. Example Query for Hunting : alert_category:THREAT OR sensor_action:DENY OR ttp:FILELESS This expands your search scope, focusing on threats, denied actions, or fileless attacks. ------------------------------------------------------------------------------------------------------------ The Processes Tab The Processes Tab  gives details of all processes that ran in your environment based on your query. Example : fileless_scriptload_cmdline:.ps1 This query filters for PowerShell script (.ps1) executions. The output lists processes tied to such executions, enabling you to spot any malicious activity. ------------------------------------------------------------------------------------------------------------ The Auth Events Tab This is one of the standout features of Carbon Black. The Auth Events Tab  provides detailed insights into Windows authentication events, supplementing process activity logs. What You Can Investigate : Who logged in to an endpoint during suspicious activity. Failed login attempts and brute-force attacks. Privilege escalation attempts and lateral movement. Remote logins from anomalous sources. Insider threats or use of stolen credentials. Why It’s Valuable : SOC analysts gain critical context during threat hunting and incident response. Carbon Black’s ability to correlate authentication events with process activity  reduces response times and minimizes reliance on third-party tools. Example Search : Failed Login Attempts on a Specific Endpoint : (With Search/Filter) Remote Logins : (With Search/Filter) ------------------------------------------------------------------------------------------------------------ Why I’m a Fan of This Feature Carbon Black’s I nvestigate  tool offers simplicity and depth, eliminating the need to manually sift through logs. You can: Quickly search for anomalies. Export details for reporting. Investigate further with ease. Real-World Benefits: The seamless integration of authentication data with process analysis enhances visibility, making it easier to detect and respond to threats like lateral movement, privilege escalation, or brute-force attacks. ------------------------------------------------------------------------------------------------------------ Stay tuned for the next article!Until then, keep learning and growing. See you soon! 😊 Upcoming article : Carbon Black (P4:Enforce): A Practical Guide/An Practical Training ----------------------------------------------Dean-------------------------------------------------

Carbon Black EDR (Endpoint Detection and Response) is a powerful tool, but its interface can be a little overwhelming for new users. Let me walk you through some of its key features, starting with the Dashboard  and then moving on to the Alerts  tab. I’ll share what I know, with examples and screenshots for better understanding. ------------------------------------------------------------------------------------------------------------- The Dashboard: A Quick Overview The Carbon Black Dashboard is made up of widgets that provide a high-level view of policies, alerts, and overall activity . These widgets are pre-defined, which is both a strength and a limitation. You can’t add custom widgets, which sometimes feels restrictive if you want to monitor something very specific. Now, I’ll be honest: I don’t personally use dashboards , whether it’s Carbon Black, SentinelOne, or any other tool. I prefer to dig into things manually. That’s just how I work. But I can see the appeal of dashboards for administrators who want a quick overview. If you’re someone who relies on dashboards, the widgets here are decent, though not customizable. Since the visuals speak for themselves, I won’t go into great detail. You’ll understand everything through the screenshots. ------------------------------------------------------------------------------------------------------------- Moving to the Alerts Tab Now, let’s dive into the Alerts  tab. This section is much more interactive and flexible. Here's a quick breakdown: The Search Bar At the top of the Alerts tab, y ou’ll find a search bar where you can look up alerts based on parameters like: File name Device ID Hash For example, if you type de in the search bar, it will auto-fill suggestions like "Device ID" or "Policy Name," making it easier to refine your search. Similarly, you can search by hash or file name. One great feature is that after performing a search, you can save the filter and add it to your favorites. This way, you don’t need to repeat the same search every time. Time Filters On the right-hand side, there’s a time filter where you can choose to view alerts for a specific period, such as the past day, hour, or month. ------------------------------------------------------------------------------------------------------------- Filters/Grouping/Search Guide Options On the left-hand side, you’ll see additional filters to make searching alerts easier. You can filter by Type , Priority , and more. Now if u see Top right hand side you will see option Group By None : Alerts are shown individually, one by one. Threat ID : Groups alerts that share the same threat ID. For example, if multiple alerts are related to a remote tool, selecting "Threat ID" groups them together for easier viewing. Search Guide One of my favorite features in the Alerts tab is the Search Guide  link at the top . If you click on it, you’ll find a detailed guide on how to search using the bar. It’s incredibly useful if you’re not familiar with the search syntax or want to refine your searches further. View of search Guide: ------------------------------------------------------------------------------------------------------------- Types of Alerts Let’s now look at the types of alerts in Carbon Black . There are two main categories: CB Analytics:- These alerts are generated automatically by the Carbon Black Cloud analytics engine. They are essentially detections based on built-in analytics. Watchlist Hits:- Watchlist hits are rule-based detections. For instance, if you’ve set up a rule to monitor for certain IOCs (Indicators of Compromise) , any matches will trigger an alert under this category. According to the official documentation: Watchlists are saved searches that run periodically against process or binary data in Carbon Black EDR. They run every 10 minutes and notify users when new results are found . Filter by Priority One of the key filters available is Priority Level . You can use this to narrow down alerts based on their assigned priority. For example, you might only want to focus on high-priority alerts. Once you apply this filter, only the relevant alerts matching that priority will show up. It’s a simple yet effective way to zero in on what needs immediate attention. More filter screenshot: Group By: None vs. Threat ID As I mentioned earlier, the Group By  filter can be set to either: None : This displays alerts individually, one by one. Threat ID : Groups alerts that share the same threat ID. For instance, if multiple alerts relate to a "Remote Tool" threat, grouping by Threat ID will cluster them together. Below, you’ll see screenshots showing both options: Group By None : Each alert appears separately. Group By Threat ID : Similar alerts are grouped, which makes it easier to analyze related threats. ------------------------------------------------------------------------------------------------------------- Diving Into a Particular Alert Let’s take a closer look at a specific alert, starting with a Watchlist Hit . Here’s what you’ll find in a typical alert: Arrow for Detailed View Next to the Actions  section, there’s an arrow (>) that you can click to expand the alert. This will reveal more information about the alert, including its Alert ID  and the Reason  it was triggered. Alert ID : This uniquely identifies the alert. Reason : Indicates the watchlist or rule that triggered the alert . For instance, if you’ve set up a rule to detect IOC hits, you’ll see the corresponding rule listed here. Processes and Parent Processes Below the basic alert details, you’ll see the Parent Process  and Process  information. This shows the process chain for the activity that triggered the alert. I won’t spend too much time explaining these since most of us are familiar with how processes and parent processes work. If you need even more details, there’s a Show All  button that you can click to e xpand and view additional process information. Remediation Steps After the process details, you’ll find Remediation Steps . This section suggests actions you can take in response to the alert, such as: Deleting the application Quarantining the asset Taking remote actions on the device Device Details Just below the remediation steps, you’ll find a section for Device Details , which provides information about the endpoint where the alert was triggered. This can include the device name, OS version, and other critical details. Threat History Scrolling further down, you’ll come across the Threat History  section . This provides context on how often similar alerts have been detected across devices , helping you understand th e scale of the issue. ------------------------------------------------------------------------------------------------------------- No Need to Scroll: Use the Expand Option Instead of scrolling through the alert details, you can use the Expand  button at the top of the alert. Clicking this will display all the alert details on a single page, saving you time and making it easier to view everything at once. ------------------------------------------------------------------------------------------------------------- In depth Analysis of alert and view: Process Analysis: A Visual Insight If you want to investigate an alert beyond just the basics like hash, IOC, or file paths, Process Analysis  is your go-to tool. When you select Process Analysis , the first thing you’ll notice is a graphical representation . This graph visually lays out the parent-child process relationships , making it easy to trace back how the suspicious activity started and its subsequent actions. Screenshot Example : The graph provides clarity on which process initiated the activity, its children, and the sequence of events. It’s particularly helpful for identifying anomalies in the execution chain. Filters and Modules As you scroll down, you’ll find additional filters, including details like: Loaded Modules : Shows the DLLs or components loaded by a specific process. File Modifications : Lists changes made to files. Registry Modifications : Displays registry edits made by the process. These are standard features in most EDR tools, but Carbon Black makes the information easy to navigate. Search Guide At the top-right corner of the process analysis section, there’s a Search Guide  link. If you’re unsure about analyzing alerts, this guide provides handy tips and examples. It’s a quick way to get familiar with the interface and techniques. ------------------------------------------------------------------------------------------------------------- CB Analytics Alerts Now, let’s shift to CB Analytics Hits , another type of alert you’ll encounter. Blocked CB Analytics Alerts Let’s say Carbon Black detects a suspicious process like wmiprvse.exe invoking another application. If you’ve created a policy to block this activity , Carbon Black will: Detect the activity. Apply the policy and block the process. In the alert details, you’ll see that the policy was enforced. This is similar to a Watchlist Hit , but with the key difference being that the threat was actively blocked . Non-Blocked CB Analytics Alerts On the flip side, if there’s no policy in place to block the suspicious activity, Carbon Black will still flag it as worth investigating. For example, Carbon Black might detect another application but not block it because there’s no policy for that scenario. The alert details in this case will look similar to a watchlist hit, allowing you to analyze and decide on the next steps. ------------------------------------------------------------------------------------------------------------- Takeaways on Alerts That’s essentially how the Alerts Tab  works. From using filters  to navigating process analysis graphs , you have all the tools to investigate and take action. Don’t forget, if you ever feel stuck, the Search Guide  is always there to assist. If there’s enough interest, I’ll create a dedicated article on how to analyze alerts in detail. But for now, let’s move on to the next topic—I’ve got more articles to write (lol). Upcoming article : Carbon Black (P3:Investigate): A Practical Guide/An Practical Training Dean

Welcome to this guide on using Carbon Black as an Endpoint Detection and Response (EDR) tool . Carbon Black has long been recognized for its contributions to the cybersecurity landscape. While it wasn’t the first to introduce EDR (the concept was coined by Gartner analyst Anton Chuvakin in 2013 ), it has played a pivotal role in the evolution of endpoint security . In this article, we’ll explore Carbon Black’s features, capabilities, and its journey within the competitive EDR market. By the end, you’ll have a clear understanding of Carbon Black's functionality and how it compares to other EDR solutions. ------------------------------------------------------------------------------------------------------------- Introduction to Carbon Black Carbon Black specializes in advanced threat detection and response. Its strength lies in real-time visibility into endpoints, enabling quick detection and mitigation of threats. Over time, it has become an essential tool for organizations aiming to strengthen their cybersecurity posture. Key Features Real-Time Endpoint Monitoring : Tracks activities across endpoints to detect unusual behavior. Threat Hunting Capabilities : Enables deep visibility into endpoint activities for proactive threat hunting. Application Control : Prevents unauthorized applications from running. Malware Analysis : Offers cloud-based analysis for suspicious executables. ------------------------------------------------------------------------------------------------------------- The Evolution of Carbon Black Carbon Black became part of VMware in 2019 and was later acquired by Broadcom in 2021 as part of Broadcom’s VMware acquisition. While these transitions have provided financial backing and broader integration, I have notcied a decline in support during the integration phase, especially with the merger of Carbon Black and Symantec(My Personal Comment). ------------------------------------------------------------------------------------------------------------- Using the Carbon Black Dashboard The Carbon Black Cloud dashboard is designed for simplicity, providing a centralized view of your environment. Top Navigation Bar Left Side : Displays the Carbon Black Cloud branding. Right Side : Includes: Notifications : Alerts for recent updates or completed downloads (e.g., reports). Help Tab : Provides documentation and resources for troubleshooting or learning about features. Quick Feature Highlight Near the Right-hand side, you’ll notice a small arrow (>) . Clicking this reveals which features are enabled in your environment. For example, advanced features like Vulnerability Management may require additional licensing. The built-in documentation for these features can be incredibly helpful if you’re stuck. ------------------------------------------------------------------------------------------------------------- Exploring the Left-Hand Menu The left-hand menu is where most of the action happens. Here’s a breakdown of its main sections: 1. Dashboard A high-level overview of your environment, including key metrics and activity summaries. 2. Alerts Displays all alerts triggered by suspicious activity. You can investigate and act on alerts from here. 3. Investigate The Investigate  tab acts like a tool allowing you to perform advanced threat hunting. Similar to SentinelOne’s Deep Visibility , this feature lets you query endpoint activities in detail. 4. Live Query Run SQL-like queries across endpoints for targeted data retrieval. (Kind a Threat hunting) 5. Enforce A collection of subset of features: Policies : Create and manage endpoint policies. Reputation : Block malicious hashes or allow trusted ones. Malware Removal : Review and take action on identified malicious files. Cloud Analysis : Upload executables for in-depth analysis by the Carbon Black team. Recommendations : Receive suggestions to optimize your Carbon Black Cloud console. 6. Vulnerability Displays detected vulnerabilities across your environment. Tracks endpoint exposure to CVEs and provides actionable insights. 7. Inventory Contains several subsections for managing endpoint assets: Endpoints : Lists all endpoints and their details. USB Devices : Tracks allowed or blocked USB devices. Sensor Groups : Create and order sensor groups for automated policy assignments. 8. Settings Configuration options for customizing your Carbon Black deployment. (We will talk about each in future articles) ------------------------------------------------------------------------------------------------------------- Comparison: Carbon Black vs. SentinelOne While Carbon Black is a robust tool, my personal experience suggests that SentinelOne  offers more user-friendly capabilities. ------------------------------------------------------------------------------------------------------------- Having worked extensively with Carbon Black, I can attest to its potential. However, as with any tool, the key is to understand its strengths and limitations. While Broadcom's acquisition of VMware has led to some challenges. I’ll pause here for now, as it’s time to work on another article! Until then, keep hunting and learning. See you soon! 😊 Happy Carbon Black managing! 🚀 Upcoming article: Carbon Black (P2:Dashboard/Alerts): A Practical Guide/An Practical Training

If you’ve started using Arkime  (formerly Moloch), you already know it's a powerful tool for digging deep into packet captures and indexed network traffic. But here's the deal — most of that power lives in how you search . And trust me, once you get comfortable with Arkime's search language, it feels less like digging through data and more like interrogating the network . 🕵️‍♀️ ---------------------------------------------------------------------------------------------------------- 🧠 First: What Are We Even Searching? In Arkime, you’re not just searching raw packets like in Wireshark. You're querying SPI data  — Session Profile Information . It's metadata extracted from full PCAP captures that’s been indexed for fast retrieval. This means you’re asking questions like: “Which sessions involved DNS lookups for ‘google’?” “Did anyone POST data to a shady site?” “Who used TLS but without Diffie-Hellman?” You use Arkime's query bar  in the viewer UI — and it’s actually pretty user-friendly. ---------------------------------------------------------------------------------------------------------- ✨ Query Language 101 (Way Simpler Than It Looks) Arkime has its own mini search language. Don’t worry, it’s not too weird. Here’s how it works: Task Syntax AND && OR ` Equals == Not equals != Exists == EXISTS! Group logic ( ... ) Example: host.dns == *google* && http.method == POST This finds DNS sessions with “google” in the hostname AND  HTTP POST requests — maybe signs of data exfiltration? ---------------------------------------------------------------------------------------------------------- 🔍 Let's Talk Field Types (Because This Changes How You Search) Arkime fields come in different types — and you search each a little differently. 🧾 String Fields These are your domains, URIs, methods, headers, etc. Tokenized : Arkime breaks strings up by dots, slashes, and dashes. So www.cyberengage.org/becomes: www, cyberengage, org, and www.cyberengage.org Wildcards : * = any characters ? = single character→ http.uri == "www.cyberengage.*" matches .org, .edu, .com, etc. Lists : Want OR logic quickly? Use brackets: http.uri == [login, reset, password] Regex : Use /regex/ style for advanced pattern matching host.http == /.*\cyberengage\.com/ 🌐 IP Address Fields You can match by: Exact IPs : ip.dst == 192.168.1.10 CIDR : ip.src == 10.0.0.0/8 With ports : ip.dst == 8.8.8.8:53 🔢 Numeric Fields Standard comparisons work: >, <, >=, != src.port >= 10000 📅 Date Fields Yes, you can time travel: timestamp >= "2024-07-01 00:00:00" Or go relative like: timestamp >= now-24h 🦉 Helpful Stuff Built Right In 🧠 Autocomplete Start typing host in the search bar and Arkime gives you suggestions like: host.dns host.http host.tls This is amazing when you’re not sure of the exact field name. 🦉 The Owl Button Top-left corner of the interface = Arkime's Owl . Click it anytime to get quick help, field lists, and syntax reminders. 📈 The Viewer UI – It’s Not Just a Table Each row in the interface = a session  (not an individual packet). This is important. Arkime combines both sides  of a conversation into one entry. You’ll see: Timestamps Byte/packet counts Protocols Directional traffic graphs (red vs blue = client vs server) You can: Click the green plus sign  to expand any session Extract PCAPs  of the session instantly Switch views  to show packets, bytes, or session summaries And yes — you can zoom into a time range  interactively just like in Wireshark! 🎯 Quick Query Examples (Copy-Paste Friendly) Find all DNS requests containing “google” host.dns == cyberengage All POST requests to Home Depot domains http.method == POST && host.http == cyberengage.org TLS sessions that don’t  use Diffie-Hellman tls.cipher == EXISTS! && tls.cipher != DHE Any session where a TLS certificate was present cert.issuer.cn == EXISTS! Match IP in range with port ip.dst == 192.168.1.0/24:443 ---------------------------------------------------------------------------------------------------------- So you’ve fired up Arkime, run a few basic searches, and pulled up some sessions. Cool. But now you’re thinking, “Okay, now what?” Welcome to the real power of Arkime — the Viewer interface . This is where packet forensics turns visual, interactive, and actually fun . 🔓 “Unrolling” a Session — No More Packet-by-Packet Misery Click that little green or blue “+” icon  on any session row. Boom. You just “unrolled” the session. Now you’re looking at: All the SPI (Session Profile Information)  fields Arkime extracted A breakdown of client and server metadata Easy-to-click fields that build your next search for you This is Arkime’s secret sauce. You’re not parsing hex dumps or scrolling through TCP streams — you’re getting parsed, indexed, clickable context . Want to filter all sessions that used the same HTTP User-Agent? Just click it. Want to pivot off a suspicious DNS request? Click it. ---------------------------------------------------------------------------------------------------------- 📦 No PCAP Left Behind (Even If You Delete It) One super cool feature: even if your original .pcap files get deleted or expire from disk, the SPI data stays . That means you can still search for sessions based on: IPs DNS names TLS info HTTP headers And more… …even if the raw packets are long gone. That's thanks to Elasticsearch, which is storing and indexing all that juicy metadata. ---------------------------------------------------------------------------------------------------------- 🎨 Visual Packet Direction — Just Like Wireshark (But Better) If the original PCAP is still available and not locked by permissions, Arkime shows you client-server packet flows using colors: 🔵 Blue = client → server 🔴 Red = server → client This helps you see session direction  at a glance — useful when you're dealing with command-and-control traffic, exfiltration, or handshake behaviors. ---------------------------------------------------------------------------------------------------------- 🧪 Decode & Decompress — On the Fly Did the response come back GZIP'd? No worries. Arkime lets you uncompress  responses directly in the browser — just click the “Uncompress”  button. Same goes for files and images : Click “Show Images & Files” Arkime will display images right inside the UI Not an image? You’ll get a download link , but it forces a .pellet extension to keep things safe — no accidental malware clicks 👀 This makes Arkime way more analyst-friendly. No need to carve files manually — the UI helps surface artifacts you care about. ---------------------------------------------------------------------------------------------------------- 🔗 “Connections” Tab — Visualize Relationships, Not Just Results Here’s where Arkime gets fancy. The Connections tab  lets you build visual relationships  between any two data points. You can pair: ip.src with host.dns ip.src with ip.dst smb.user with smb.fn (username vs. accessed file) Anything you want — as long as it's in the SPI What you get is an interactive graph , showing: Who talked to whom How often Which IPs resolved which domains Which users accessed which files You can hover  to see session counts, bytes, packets... or even drag nodes  to explore visually. It's like building your own mini threat intel map. ---------------------------------------------------------------------------------------------------------- 🔍 The Hunt Tab — Search Inside Packets, Not Just Metadata Most of Arkime’s power is in SPI — but sometimes, you need to dig deeper. That’s where Hunt  comes in. What is a “Hunt”? It’s a background task  that scans the actual packet data (raw PCAP) for matches, not just metadata. Example use cases: Searching inside payloads for malware signatures Finding credentials Looking for file fragments or strings Hunt Options You Can Customize: How many packets per session to search Reassembly (streamed) or per-packet inspection Direction (client→server, server→client, or both) Match method (literal string, regex, etc.) Once the hunt finishes: It adds huntName and huntId to the session SPI Even if the PCAP is deleted later, the match stays searchable ! 💡 Bonus: You can save hunts  and reuse them later  — perfect for recurring analysis like APT TTPs, keyword searches, or IOC sweeps. ---------------------------------------------------------------------------------------------------------- 🧰 Final Thoughts: Why This Matters When you're dealing with mountains of network traffic, the difference between pain and productivity often comes down to how your tools surface data . Arkime isn’t just capturing packets — it’s making them usable . Once you learn the basic search syntax, Arkime becomes insanely powerful. You're no longer swimming in raw packets — you're running smart, targeted queries and extracting meaningful results fast. -----------------------------------------------Dean------------------------------------------------------

Let’s be honest — dealing with network traffic at scale isn’t exactly a walk in the park. Sure, command-line tools are powerful, flexible, and scriptable. But if you’ve ever tried to string together a bunch of scripts to process large volumes of PCAPs, you know how quickly things can turn into a tangled mess. Debugging scripts, managing tools, filtering data, reviewing results — it’s like solving a puzzle... blindfolded. Naturally, when we need to dig into network packets, most of us reach for Wireshark . It’s a trusted friend — great for deep packet inspection, clean interface, amazing protocol support. But the second you throw gigabytes (or terabytes) of traffic at it? Boom. It chokes. 🫣 So what’s the alternative if we want to scale up without shelling out thousands of dollars for commercial network forensics solutions? Say hello to Arkime . -------------------------------------------------------------------------------------------------------- 🌐 Meet Arkime: Open Source, Scalable, and Surprisingly Powerful Arkime (previously known as Moloch , and yes, you’ll still see that name floating around in some commands and docs) is an open-source tool designed specifically to capture, index, and analyze network traffic — at scale. What makes it stand out? Three things: It captures full packet data. It indexes traffic for lightning-fast search. It gives you a clean web interface to explore, filter, and export PCAPs. Think of Arkime as the bridge between bare-bones command-line tools and overpriced commercial network forensics platforms. It was originally created by folks at AOL (yes, that AOL) who needed something robust but flexible. Fast forward to today, and it’s used by defenders and analysts worldwide who want powerful PCAP analysis without blowing their budget. -------------------------------------------------------------------------------------------------------- 🧩 How Arkime Works — Without the Boring Diagrams Arkime isn’t just one single app — it’s a modular system: Capture Node : Think of this as the sensor. It grabs packets off the wire and stores them. Elasticsearch : This is where Arkime keeps track of all the session metadata — aka, Session Profile Information (SPI) . This lets you search super fast, even across billions of packets. Viewer : The web interface where you search, filter, view session details, and extract PCAPs. Now here’s where it gets cool: Arkime scales horizontally . That means you can run everything on one box if you’re working with small-to-mid traffic volumes (like in a lab). But in a real-world environment? You can deploy multiple capture nodes  across your network — each feeding metadata back to a centralized Elasticsearch cluster. So yeah, it’s built for scale. -------------------------------------------------------------------------------------------------------- 🧪 Real Talk: Where Arkime Shines and Where It Stumbles Arkime is not perfect, and it's not trying to be everything for everyone. But here’s a breakdown: ✅ What’s Awesome : Free and open source . (Did I mention that already? Worth repeating.) Scalable  across small labs or large, enterprise-wide deployments. Fast search  across massive PCAP data. Simple, browser-based UI  for analysis. Integration-friendly  — you can plug Arkime into other tools or SIEMs easily. Active community  — if you’re stuck, there’s a free Slack group where the devs actually reply! ❌ Where It Falls Short : Protocol coverage  isn’t as wide as Wireshark. Some obscure or proprietary protocols just won’t parse unless you write your own parser (which isn’t trivial). Live traffic at high speeds?  Yeah, that’s where you’ll need to invest time in tuning. Poor architecture = dropped packets. No official support . This is community-powered. If your boss wants an SLA, you’re out of luck unless you hire third-party consultants. Deployment complexity  increases with scale. You need to understand Elasticsearch well and know how to tune it for performance and stability. -------------------------------------------------------------------------------------------------------- 🧠 Why You Should Care (Even If You’re Just a One-Person DFIR Team) Let’s face it — not everyone works at a fancy SOC with million-dollar tools. Whether you're running a home lab, working incident response at a midsize company, or just learning packet forensics, Arkime fills that sweet spot  between Wireshark and expensive enterprise tools like RSA NetWitness or Fidelis. Need to: Hunt down command and control traffic? Pull sessions involving a suspicious domain? Track data exfiltration over DNS or HTTP? Arkime makes all of that way easier, without you spending hours combing through raw PCAPs manually. -------------------------------------------------------------------------------------------------------- Please note: For demonstration purposes, I installed Arkime using WSL. However, this setup is not recommended for production use. For optimal performance and full functionality, it is strongly advised to install Arkime on a native Ubuntu environment or a dedicated Linux server. Installing Package Configuring Arkime You can have maxmind account and can say yes but I said no Run the service Next Add user Enable the service Once done Visit http://localhost:8005/ Output While it's possible to run Arkime on WSL for testing purposes, please note that resource consumption—particularly CPU and memory usage—can increase rapidly during operation. If you're using WSL, I recommend disabling services like arkime-capture, arkime-viewer, and elasticsearch after completing your tests to avoid unnecessary system strain. --------------------------------------------------------------------------------------------------------- 🚀 Final Thoughts Arkime isn’t trying to replace Wireshark — it’s trying to extend your power as a network analyst . It’s not flashy. It won’t hold your hand. But if you give it a chance, it’ll become one of the most powerful tools in your forensics arsenal. ---------------------------------------------------Dean------------------------------------------------- Do not miss upcoming article!!!! Querying Like a Pro in Arkime: Getting the Most Out of Arkime Viewer: Beyond the Basics

In the final part of this Petra Security overview, let’s dive into one of my favorite tabs: Reporting  — and then explore how you can conduct effective threat hunting  using Petra’s Activity and Users views. Let’s go. 📊 Reporting: The Power of Organized Insights The Reporting  tab in Petra is divided into focused views — so you can break down incidents, trends, and anomalies without hunting through messy dashboards. At the top left, you have the option to generate downloadable PDF reports , which are super helpful for SOC leads, management, and even clients during monthly security reviews. 🚫 Failed Attacks: Know What Was Blocked The first tab shows you Failed Attacks . This is exactly what it sounds like — reporting on all login attempts and activity Petra stopped  before they could do any damage. And that’s important. You not only get to investigate what happened , but also what could’ve happened  — and how Petra stopped it . This allows security teams to: Identify patterns Prepare for future attacks Patch weak spots in identity hygiene As I always say — don’t take security lightly. It’s not just about reacting; it’s about getting ahead of attackers. 🧠 Uncommon Activity: ML-Powered, Analyst-Friendly (Show false positives it closed which seems compromise but not) Now, let’s talk about the real MVP of the Reporting tab — Uncommon Activity . This is where Petra’s machine learning truly shines.  From a SOC perspective, this is a huge deal. For example: Impossible travel detections New device sign-ins Sudden location changes Proxy/VPN logins Petra filters out the noise and only flags what actually matters . You see, I’ve worked with many SOC L1/L2 teams. I know firsthand how many false positive impossible travel alerts  they close daily. Petra solves that — it’s automated, reliable, and doesn’t require babysitting. And that brings massive cost-efficiency  to a company. False Positive example: 🚨 Microsoft P1/P2 Risk Tab— But Without the Noise (Show All false positives it closed) We all know Microsoft’s P1 and P2 license features — especially risky user and risky login alerts. But let’s be honest: they generate a lot of false positives. Petra provides the same — and better , but with machine learning that actually works . No whitelist needed. No tuning rules for VPNs. It just understands behavior  and adapts. ------------------------------------------------------------------------------------------------------------- 🔍 Threat Hunting with Petra: Two Ways to Investigate Let’s say you want to investigate a specific user — maybe you’re wondering: Did they download any sensitive files? When did that happen? What IP did they use? You have two ways to do this in Petra: 1. Activity View (Which I have shown in my second article) This is the full organizational timeline — filter by the user’s email ID, add action filters (e.g. “File Downloaded”), and start hunting. 2. Users Tab ( Which I have shown in my second article as well) In simple language this activity is user specific: Click on a user and get: Identity summary (job title, auth methods, etc.) Activity timeline (login, file access, email events, etc.) This per-user deep dive  is smooth and intuitive — a dream for any SOC analyst doing incident recon. ------------------------------------------------------------------------------------------------------------- Before wrapping up this overview, I want to share a few important investigation tips  that Petra itself recommends  — and after working through several incidents, I can confidently say these tips are spot on but there alot more which you hav to focus on but lets keep this simple for now . Whether you're responding to a live compromise or reviewing past activity, keeping these points in mind will make your investigation faster, sharper, and more effective . ✅ Focus on Sent  and Created  Events in Exchange These are often your first clue  that something malicious happened — especially: Emails created or sent to external recipients Attempts to phish trusted third parties Potential data exfiltration  events Sent emails = intent. If an attacker created or sent a message, it usually means they’re trying to expand access  or extract data . 🗑️ Watch for Soft Deleted  and Hard Deleted  Events Attackers try to cover their tracks — and Petra captures that. They might: Delete their phishing emails Remove inbox rules they created Delete replies to hide communication threads Petra preserves these events even if they’re deleted  — a huge win for forensic integrity. 🔐 Investigate Permission Changes  in SharePoint If you see external sharing enabled or permission levels escalated — especially during or right after a compromise — that’s a red flag . This often points to: Unauthorized access grants Sharing links sent outside the org Attackers prepping data for download Petra highlights this clearly, making SharePoint investigations way easier. ⚠️ Look for Malicious App Installs  and Mail Filter Rules These are some of the most common persistence mechanisms  attackers use post-compromise. Petra will: Auto-highlight  malicious app registrations Show new inbox rules , like forwarding or redirect rules Let you remove both instantly via the Remediation Actions Panel This helps you not just detect the attacker — but kick them out and shut the door behind them . 📬 Answer the Big Questions Most clients and security leads want to know two things: Did the attacker send anything externally? Was any sensitive data accessed? With Petra, you can answer both questions confidently — using audit-backed evidence across Exchange, SharePoint, and Teams. ------------------------------------------------------------------------------------------------------------- Final Thoughts: My Honest Take on Petra Security Let me be clear — this tool isn’t trying to be everything .  It doesn’t cover Defender for Endpoint or vendor telemetry. It focuses on identity. And what it does for Entra ID logs, Exchange, SharePoint, and Teams — it does better than anything else I’ve seen . In fact, I honestly believe it’s a solid replacement for Microsoft Entra P2  — except, unlike Microsoft's built-in tools, Petra actually works . “Petra stopped 10 attacks with 0 false alarms. No whitelists needed — even with VPN usage. If you manage Microsoft environments, you should be using Petra.” – Co-founder of one of the best security companies out there That’s not marketing hype — that’s real-world validation . I know this tool is paid — but what you get in return? Unmatched insight. Reduced analyst workload. Peace of mind. ------------------------------------------------------------------------------------------------------------- 🤝 Want to Learn More or Connect? I’m not here to tell you to buy or not buy this tool. I’m here to say: Petra deserves your attention . If you’re serious about identity security in Microsoft 365 — and want real visibility, real-time ML, and actual investigation power — Petra is worth your time. And hey, if you want to get in touch with Petra security firm and firm which give you security, feel free to reach out to me. I’d be happy to connect you with the right people. ------------------------------------------------------------------------------------------------------------- Upcoming Article: Who’s Using a Proxy or VPN in Your M365 Environment — and Why It Matters https://www.cyberengage.org/post/who-s-using-a-proxy-or-vpn-in-your-m365-environment-and-why-it-matters

While working with SOC teams in Microsoft environments, I’ve observed that during impossible travel investigations, analysts often have to manually verify whether the login IPs belong to VPNs or proxy services — a tedious process that adds unnecessary complexity to their workflow. In today’s threat landscape, knowing where users log in from — and whether they’re behind a VPN, proxy, or data center IP  — is crucial. But not all proxy use is malicious. In fact, a lot of it is completely benign . That’s where most tools fall short: they either over-alert or under-contextualize. Petra doesn’t. ------------------------------------------------------------------------------------------------------------ 🧠 Petra’s Approach: Context First, Always Petra Security was built to detect real account compromises , not generate noise. It doesn’t just flag every VPN or proxy login — instead, it performs deep analysis to distinguish legitimate user behavior  from suspicious patterns. Yes, some attackers use VPNs. But so do: Traveling executives Remote employees Third-party contractors Mobile users switching networks Petra understands that — and separates harmless VPN use from actual threats . But here’s the cool part: even benign usage is logged, preserved, and made instantly accessible  for analysis. 🔍 Two Powerful Ways to Investigate VPN and Proxy Use in Petra Whether you're investigating an incident or just trying to understand user access trends, Petra offers two main methods : 📊 1. Reporting Interface — for Stakeholder-Friendly Insights Want a fast, clean way to see who logged in from a proxy or data center ? Here’s how: Go to your tenant (top left corner) Click the Reporting  tab Open the Uncommon Activity  sub-tab Filter by Type: Proxy and Data Center Use You’ll get a list of users who accessed the environment through proxies, along with: Timestamp of the event User details IP, ISP, and data center provider info Each entry can be clicked to open a dedicated view  showing the context around the event, powered by Petra’s built-in log viewer. Perfect for quick reviews and sharing with stakeholders during audits or reviews. 🧠 2. Logs Viewer — for Deep Dive Investigations For analysts or incident responders, Petra’s Activity Viewer  (aka Logs Viewer) is where the real power lies. To investigate proxy use deeply: Navigate to the tenant’s main dashboard Scroll to the Activity  panel Apply these filters: Proxy: Yes — to isolate proxy traffic Login Status: Successful — to focus on real accesses Now you’re seeing every successful login that came through a proxy. 🔧 Advanced Filtering at Your Fingertips Want to pivot quickly? Petra makes it seamless: Filter by User :Right-click a username → Include — focuses only on that user Filter by ISP or Provider :Right-click an ISP (like Cloudflare or DigitalOcean) → Exclude — remove known-good noise Combine with other fields like Country, Device Type, Operating System , or Login Method  for laser-focused investigations This flexibility is what makes Petra such a powerful forensic tool — whether you're doing routine monitoring or full-scale IR. ------------------------------------------------------------------------------------------------------------ 🛡️ What About Malicious VPN Use? Petra does classify suspicious VPN/proxy activity as an incident  — when it detects behavioral anomalies or infrastructure overlap with known threats. But for everything else — including normal, repeated proxy use — Petra keeps a record, provides deep context, and lets you make the final call  based on full visibility. ------------------------------------------------------------------------------------------------------------ 🔍 Final Thought You can’t detect identity compromise without understanding how users are connecting. Petra’s approach to VPN and proxy detection is smart, contextual, and deeply investigable — without the noise or guesswork. Whether you're hunting for threat actor infrastructure or just learning who your heavy VPN users are, Petra gives you the tools — and clarity — to act confidently. -------------------------------------------------------------------------------------------------------- Next Article: SharePoint and OneDrive Logs in M365: The Goldmine You’re Overlooking (with a Hidden Twist) https://www.cyberengage.org/post/sharepoint-and-onedrive-logs-in-m365-the-goldmine-you-re-overlooking-with-a-hidden-twist --------------------------------------------------------------------------------------------------------

If you’ve been around the M365 security space long enough, you’ve heard the term Business Email Compromise (BEC)  more times than you can count. It’s a term that makes most defenders instinctively focus on mailbox rules , phishing emails , and login anomalies . But here’s the uncomfortable truth: email often isn’t the real target anymore. More and more, attackers are skipping Outlook altogether and heading straight to the real goldmine — SharePoint and OneDrive. ------------------------------------------------------------------------------------------------------------- 🎯 Why Attackers Are Laser-Focused on SharePoint & OneDrive Modern attackers understand one thing very well: organizations store their crown jewels in cloud storage, not just in emails . Here’s why SharePoint and OneDrive are so appealing: ✅ Structured folders and filenames  make data discovery easy(No need to dig through email threads) 📁 Sensitive content  like credentials, contracts, financials, and legal agreements are commonly stored 🔍 Search is fast  and intuitive, especially for attackers with read access 🧪 Files are often linked across departments , giving attackers access to multiple teams ------------------------------------------------------------------------------------------------------------- 💡 Defenders: Expand Your Focus So, here’s the takeaway: If your BEC investigation ends at the mailbox, you might be missing the real breach. Ask yourself: Did the attacker touch SharePoint or OneDrive? What documents were accessed? Downloaded? Was anything uploaded back into the environment? How fast did the attacker move? ------------------------------------------------------------------------------------------------------------- Now comes to one question which you might have witnessed as well! ------------------------------------------------------------------------------------------------------------- 🚨 The SharePoint or Ondedrive Log Puzzle: What’s With the IPs? When parsing SharePoint or Onedrive activity, one field naturally grabs attention: ClientIP. You’d expect this to reflect the end-user’s IP address — and sometimes it does. But here’s the twist: many of these IPs actually belong to Microsoft datacenters.   That’s right — instead of pointing to the user's laptop in USA or Mumbai, you're sometimes staring at an Azure IP block from San Antonio or somewhere across the country . And that can throw off your investigation if you're not ready for it . ------------------------------------------------------------------------------------------------------------- 🧠 Why This Happens (According to Microsoft) After digging through Microsoft’s documentation (and quite a bit of head-scratching), the explanation becomes clear — and honestly, kind of brilliant. According to Microsoft: “For some services, the value displayed in this property might be the IP address for a trusted application (for example, Office on the web apps) calling into the service on behalf of a user and not the IP address of the device used by person who performed the activity.” In simple terms: if a user edits a document via the Excel Web App or Word Online , that activity might come from a Microsoft backend service — not  the user's physical machine. What you're seeing is activity being routed: Partly from the end-user's device And partly from the Microsoft web service acting on their behalf It’s like forensic shadow puppetry — the user pulls the strings, but the actions come from a different hand. ------------------------------------------------------------------------------------------------------------- 🎯 The Forensic Takeaway: Attribution Gets Tricky So what does this mean for defenders? It means you need to be extra cautious when attributing SharePoint activity . Specifically: ✅ Some activity truly originates from the user’s machine and IP 🔄 Other activity comes through Microsoft datacenters close to the user (regional) ❗ And occasionally, it comes from datacenters located hundreds or thousands of miles away If you're not aware of this nuance, you might mistake legitimate user activity for lateral movement or threat actor behavior — or worse, ignore suspicious access altogether. ------------------------------------------------------------------------------------------------------------- 🧩 Clues Still Exist The good news? SharePoint or Onedrive logs contain plenty of additional metadata  — like UserAgent, Operation, and timestamps — that help you correlate events and validate whether an action was initiated by a real user or something fishy is going on. ------------------------------------------------------------------------------------------------------------- 👁️‍🗨️ Petra Helps You See This And this is where Petra shines.  Petra’s ML models understand user behavior across SharePoint and OneDrive  and won’t trip on false positives like Microsoft’s native tools . Instead of just watching for login anomalies, it monitors file access behavior and anomalies , so you get real, actionable insights — not alert fatigue. -----------------------------------------------------Dean--------------------------------------------------

------------------------------------------------------------------------------------------------------------- If there’s one tab in Petra Security that I keep going back to, it’s the Incidents  tab. This is where all the action happens. Whether it’s a suspected business email compromise (BEC) or credential abuse, Petra gives you a full incident timeline , with zero fluff  and maximum clarity . ------------------------------------------------------------------------------------------------------------ 🕵️‍♂️ It Doesn’t Just Show the Breach — It Reconstructs It Let me walk you through what I love about it. When you open an incident: You see what the attacker accessed  — including emails read , emails deleted , files touched , and actions taken . It confirms the length of attacker access  — for example: “ Attacker had access for 8 minutes” This level of precision is rare in M365 investigations. And it tells you how long Microsoft’s logging delay  was — “Microsoft logs were delayed by 4 minutes” That context is gold when you’re trying to piece things together quickly. 📧 Real Example: 327 Emails Read In one incident view, Petra showed the attacker read 327 emails . You can literally see: Which emails were opened Whether the attacker sent  emails Whether they modified  or deleted  anything Everything is timestamped. No guesswork. No stitching logs from multiple sources. ------------------------------------------------------------------------------------------------------ 📅 A Timeline That Actually Tells a Story Now this is what really makes Petra stand out — the timeline view . It doesn’t just dump logs. It tells the story  of the incident: Phishing email received Login attempt (failed or successful) File downloaded Inbox rule created User disabled Account locked by Petra Attacker session terminated 1. First screenshot showed Start of the activity from Phishing! 2. Second screenshot is last Page when Petra has locked account and killed the session and disabled the user All of this is visually aligned , so you can follow the breach minute-by-minute — including automated remediation actions Petra took in real-time. It makes investigation fast, visual, and accurate. 🌐 Deep Dive Into Logins: Who, Where, How Let’s say you want to dig deeper into the login behavior of above scenario. Just click the Login  tab inside the incident. You’ll see: Previous login IP Known user location Device and browser used (user agent) And then the attacker’s new IP , location, and device So if someone logs in from USA at 9 AM, and then suddenly another login shows up from Brazil five minutes later using a different ISP and browser — it’s immediately obvious. 📨 Attachment Received & Opened — Email Evidence Tells All Want to confirm whether a user received a phishing email and clicked it? Petra’s Exchange  tab within the incident confirms: Whether the attachment was received (In this case Yes above screenshot) Whether it was opened (In this case Yes Accessed attachments/Read) And what happened immediately afterward (like malicious app installs or SharePoint access ( In this case No ) This is huge when you need to prove chain of attack  or answer the client’s question: “How did this even start?” ------------------------------------------------------------------------------------------------------ ⚙️ Remediation Actions — Right at Your Fingertips But wait — Petra doesn’t just show you the damage. It lets you take real-time action  directly from the incident panel: ✅ Lock the account 🚫 Kill active sessions 🔐 Reset the password This isn’t just monitoring — it’s investigation + response , in one place. No need to jump into Azure, Security Center, or PowerShell. One-click and done . ------------------------------------------------------------------------------------------------------------ Thoughts This incident panel is the reason I keep telling people: Petra is different. Everything you need is in one place — presented clearly, contextually, and without a bunch of unnecessary clicks or tabs. The UI is clean. The data is actionable. And the fact that Petra tracks and highlights exact attacker actions ? That’s a game-changer. Honestly, I just hope no big company comes in and acquires this as well! . We’ve seen how that story goes — the innovation gets buried. But for now, Petra is still crushing it, and I’m here for it. -------------------------------------------------------------------------------------------------------- Upcoming Article: Petra Security: Reporting, Threat Hunting, Investigation tip and Final Thoughts https://www.cyberengage.org/post/petra-security-reporting-threat-hunting-investigation-tip-and-final-thoughts