<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blogs on Sandor Tokesi - Cloud Security Architect</title>
    <link>https://tokesi.cloud/blogs/</link>
    <description>Recent content in Blogs on Sandor Tokesi - Cloud Security Architect</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 27 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tokesi.cloud/blogs/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Patching the Sentinel MCP server for safety</title>
      <link>https://tokesi.cloud/blogs/26_02_27_sentinel_mcp/</link>
      <pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/26_02_27_sentinel_mcp/</guid>
      <description>MCP servers are now the default way to connect AI to real systems, tools and data. In SOC scenarios, they are used to pull logs, run hunts, and automate response steps. It feels clean and simple: you ask the model, it calls the tool, you get what you were looking for.
Reality is messier. MCP servers are optimized for access, not guardrails, and controls are rarely available by default. The result is that a single vague natural language request can turn into an expensive and problematic execution.</description>
    </item>
    
    <item>
      <title>Logs to ADX from all your machines via AMA</title>
      <link>https://tokesi.cloud/blogs/26_02_06_ama_changes/</link>
      <pubDate>Fri, 06 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/26_02_06_ama_changes/</guid>
      <description>In a previous post, I explored how Azure Monitor Agent (AMA) could turn Event Hubs into a reliable, scalable backbone for your logging infrastructure, effortlessly pulling logs from Azure VMs and routing them to Event Hubs or Storage Accounts.
But here comes the bad news: Microsoft just announced the retirement of this &amp;lsquo;Send data to Event Hubs and Storage (Preview)&amp;rsquo; feature on July 31, 2026.
The somewhat good news? They&amp;rsquo;re replacing it with a fresh capability.</description>
    </item>
    
    <item>
      <title>Practical Notebook Use Cases in Sentinel data lake</title>
      <link>https://tokesi.cloud/blogs/25_11_28_notebook/</link>
      <pubDate>Fri, 28 Nov 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_11_28_notebook/</guid>
      <description>Jupyter Notebooks are remarkably versatile tools, even within Microsoft Sentinel&amp;rsquo;s data lake where current capabilities are limited. While Microsoft frequently highlights historical threat intelligence correlation and long-term threat hunting as use cases, notebooks unlock far more practical possibilities.
In a previous post, I explored the theoretical foundations of using notebooks for advanced data pipelines in Microsoft Sentinel. This follow-up takes a different approach: focusing on practical solutions that solve problems I&amp;rsquo;ve encountered in production environments.</description>
    </item>
    
    <item>
      <title>Modern Data Architecture with Sentinel data lake</title>
      <link>https://tokesi.cloud/blogs/25_11_14_datalake_pipelines/</link>
      <pubDate>Fri, 14 Nov 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_11_14_datalake_pipelines/</guid>
      <description>When discussing Microsoft Sentinel data lake, the narrative centers on immediate value: cheaper ingestion, long-term storage, and historical correlation. These benefits are real, but they don&amp;rsquo;t address some interesting options.
Sentinel data lake with KQL Jobs and Notebooks transforms how SIEM data flows. Instead of direct ingestion, these tools allow data forwarding from one table to another. Cheap data lake storage enables ingestion of all raw data, while pipeline capabilities enable transformation of data after loading.</description>
    </item>
    
    <item>
      <title>Data Architecture for AI Era #2</title>
      <link>https://tokesi.cloud/blogs/25_09_02_data_models2/</link>
      <pubDate>Tue, 02 Sep 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_09_02_data_models2/</guid>
      <description>In today&amp;rsquo;s big data landscape, establishing a proper data architecture is essential before you begin collecting data. As data generation continues to accelerate, making informed decisions about what to store, where to store it, and in what format become increasingly critical. In the age of AI, having accessible, well-structured data is even more important - and since you can&amp;rsquo;t predict what the future holds, it&amp;rsquo;s crucial to future-proof your data collection strategy.</description>
    </item>
    
    <item>
      <title>Data Models in the Age of AI #1</title>
      <link>https://tokesi.cloud/blogs/25_09_01_data_models/</link>
      <pubDate>Mon, 01 Sep 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_09_01_data_models/</guid>
      <description>In today&amp;rsquo;s cybersecurity landscape, data models are crucial - they give data the structure and context it needs to be truly usable and effective. Standardized models act as a universal language, turning raw security data into actionable insights for rapid detection, efficient investigation, and precise response. Choosing the right data model is essential for both traditional SOCs and advanced AI-driven security platforms, as they require structured and normalized data for accuracy.</description>
    </item>
    
    <item>
      <title>Sentinel Data Lake - Tiers and Tables</title>
      <link>https://tokesi.cloud/blogs/25_08_01_datalake_tables/</link>
      <pubDate>Fri, 01 Aug 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_08_01_datalake_tables/</guid>
      <description>Microsoft has just introduced Sentinel Data Lake (SDL) in public preview, and there&amp;rsquo;s already a flurry of excitement in the cybersecurity world. Most community blog posts so far focus on how to turn it on and when you might want to use it, but very few delve into how it will change your day-to-day experience - especially when it comes to how your data is organized and accessed.
Rather than providing step-by-step instructions and how-tos, this post will break down what the new Data Lake means at table level: how data is structured, how the different components interact, and what you should consider if you want to enable the Data Lake for your existing Sentinel environment.</description>
    </item>
    
    <item>
      <title>DCRs #3 - Event Hubs as a log relay to Sentinel</title>
      <link>https://tokesi.cloud/blogs/25_07_28_dcr_eventhubsource/</link>
      <pubDate>Mon, 28 Jul 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_07_28_dcr_eventhubsource/</guid>
      <description>Managing logs in a SIEM environment can be challenging, especially when aiming to design a solution that is extensible, highly available, future-proof, and reasonably priced. In this third installment of the &amp;lsquo;Powerful Capabilities of Data Collection Rules&amp;rsquo; series, I show how the &amp;lsquo;Event Hubs-to-DCR&amp;rsquo; preview pipeline turns a standard Event Hubs into a scalable, cost-effective log funnel for Sentinel, enabling filtering, enrichment, and log flow control.
Microsoft&amp;rsquo;s Deployment Guide Microsoft already provides an excellent, detailed step-by-step guide for deploying Event Hub–to–Microsoft Sentinel pipelines.</description>
    </item>
    
    <item>
      <title>DCRs #2 - AgentDirectToStore</title>
      <link>https://tokesi.cloud/blogs/25_06_30_dcr_types_agentdirecttostore/</link>
      <pubDate>Mon, 30 Jun 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_06_30_dcr_types_agentdirecttostore/</guid>
      <description>In the last post, we looked at the &amp;lsquo;Direct&amp;rsquo; DCR that simplifies API-based data ingestion. Today, we&amp;rsquo;re looking at the AgentDirectToStore Data Collection Rule type, which gives you more options for where to send your data.
The &amp;lsquo;AgentDirectToStore&amp;rsquo; DCR lets the Azure Monitor Agent collect Azure VM data and send it straight to Azure Storage (Blob or Table) or Event Hubs - skipping Log Analytics entirely. This route gives you more control over where your monitoring data lands.</description>
    </item>
    
    <item>
      <title>Powerful Capabilities of DCRs #1 - Direct type</title>
      <link>https://tokesi.cloud/blogs/25_06_26_dcr_types_direct/</link>
      <pubDate>Tue, 24 Jun 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_06_26_dcr_types_direct/</guid>
      <description>DCRs are the modern backbone of data ingestion for Azure Sentinel, replacing legacy methods with a scalable, flexible, and consistent approach that uses a common data ingestion pipeline for all data sources. DCRs enable advanced filtering, transformation, and routing of data before it even hits your storage solution. In addition to these core features, DCRs offer a range of lesser-known and less frequently used functionalities that are well worth investigating for organizations looking to maximize their monitoring capabilities.</description>
    </item>
    
    <item>
      <title>Fluent Bit #2 - Data Replay</title>
      <link>https://tokesi.cloud/blogs/25_04_20_data_replay/</link>
      <pubDate>Sun, 20 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_04_20_data_replay/</guid>
      <description>In my previous post, I demonstrated how to set up basic aggregated logging for firewall events using Fluent Bit, effectively reducing log ingestion costs in a way similar to Sentinel’s Summary rules. In this follow-up, I will walk you through a practical solution for storing these logs cost-effectively in an Azure Storage Account and show how you can later bring them back into Sentinel for analysis.
This setup serves as a simple proof of concept, highlighting how you can utilize affordable storage to retain logs for detection without sacrificing access to detailed information when needed.</description>
    </item>
    
    <item>
      <title>Fluent Bit #1 - Aggregated logging</title>
      <link>https://tokesi.cloud/blogs/25_04_17_aggregated_logging/</link>
      <pubDate>Thu, 17 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_04_17_aggregated_logging/</guid>
      <description>As companies grow and adopt new IT solutions, they naturally generate more data—and with that comes rising data storage costs. This is where telemetry data management or telemetry data pipeline tools come into play. These tools can help by trimming down unnecessary data or moving less critical information to more affordable storage options, saving both space and money.
There is a wide range of free tools available that allow you to build a custom pipeline to suit your needs.</description>
    </item>
    
    <item>
      <title>Shared tables: How to optimize them in Sentinel</title>
      <link>https://tokesi.cloud/blogs/25_03_07_shared_tables/</link>
      <pubDate>Fri, 07 Mar 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_03_07_shared_tables/</guid>
      <description>When it comes to managing logs in Microsoft Sentinel, shared tables like Syslog, CommonSecurityLog, and AzureDiagnostics often serve as the default destinations for consolidating data from various solutions. While forwarding logs to these tables aligns with Microsoft&amp;rsquo;s &amp;lsquo;best practices&amp;rsquo;, this approach comes with significant limitations that have only grown as Microsoft introduced new features. In this post, we&amp;rsquo;ll explore the drawbacks associated with utilizing these tables and discuss why avoiding them can be advantageous.</description>
    </item>
    
    <item>
      <title>Enhancing Azure Policies for Log Collection</title>
      <link>https://tokesi.cloud/blogs/25_01_01_policy/</link>
      <pubDate>Wed, 01 Jan 2025 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/25_01_01_policy/</guid>
      <description>Azure Policies are an excellent tool for standardizing and scaling your environment within Azure. They can be used to configure log collection from Azure resources to Microsoft Sentinel. While you can manually set up log collection if your Azure environment is small, a growing cloud presence will necessitate a more scalable and standardized solution, such as an Azure Policy.
Built-on policies Azure offers a wide range of default policies for log collection purposes.</description>
    </item>
    
    <item>
      <title>Advanced DCR Scenarios - For SIEM migration</title>
      <link>https://tokesi.cloud/blogs/24_12_06_advanced_dcr/</link>
      <pubDate>Thu, 05 Dec 2024 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/24_12_06_advanced_dcr/</guid>
      <description>DCRs and their ingestion-time transformations have been around for quite a while. They are commonly used in modern Sentinel deployments, but I&amp;rsquo;ve utilized several specific configurations that are particularly useful during SIEM onboarding, migration, and troubleshooting scenarios.
The primary focus of this article is to showcase the versatility of DCRs, demonstrating how they can simplify your tasks and enhance the robustness of your deployments.
Scenarios: The following strategies are ones I&amp;rsquo;ve utilized during past SIEM migrations to manage costs effectively, verify incoming data, and detect potential misconfigurations.</description>
    </item>
    
    <item>
      <title>Sentinel Phantom Fields: Understanding and Managing Inaccessible Data</title>
      <link>https://tokesi.cloud/blogs/24_10_01_phantom_fields/</link>
      <pubDate>Tue, 01 Oct 2024 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/24_10_01_phantom_fields/</guid>
      <description>Read the blog post on BlueVoyant&amp;rsquo;s site: Sentinel Phantom Fields: Understanding and Managing Inaccessible Data.
Microsoft has transitioned to a DCR-based log ingestion and manual schema management for tables for some time now. Lots of organizations are adopting this modern approach over the old method to parse, filter, and enrich their logs during ingestion. While this system is highly effective, it carries potential risks if not used properly. It is possible to incur unnecessary expenses by generating billable fields that remain inaccessible when querying the events.</description>
    </item>
    
    <item>
      <title>Saving cost through parsing</title>
      <link>https://tokesi.cloud/blogs/24_05_20_cost_saving_via_parsing/</link>
      <pubDate>Mon, 20 May 2024 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/24_05_20_cost_saving_via_parsing/</guid>
      <description>When selecting a new security technology, cost is a crucial factor. It does not matter how effective a tool may be, it becomes irrelevant if it&amp;rsquo;s unaffordable for you. As a result, it is critical to have someone who is experienced with the solution to prevent overpayment and maximize your investment.
Expert assistance is crucial when considering a Security Information and Event Management (SIEM) solution. SIEMs often come with varying licensing models and can be quite costly.</description>
    </item>
    
    <item>
      <title>Defender for Cloud Sentinel connectors review</title>
      <link>https://tokesi.cloud/blogs/24_03_09_mdc_xdr/</link>
      <pubDate>Sat, 09 Mar 2024 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/24_03_09_mdc_xdr/</guid>
      <description>A slightly different version of this article appeared on BlueVoyant’s website. Click on this link to read it there: https://www.managedsentinel.com/defender-for-cloud-and-defender-xdr-connectors-in-sentinel/
Alternately, you may read it on my blog by scrolling down.
Defender for Cloud and Defender XDR connectors Over the past few weeks, Microsoft Defender for Cloud has received multiple updates. Microsoft has introduced a new tenant-level Defender for Cloud connector, replacing the old subscription-level one. Additionally, they have implemented a new functionality, allowing detections from Defender for Cloud to be integrated into Defender XDR, along with detections from other Defender solutions.</description>
    </item>
    
    <item>
      <title>The cost of a watchlist</title>
      <link>https://tokesi.cloud/blogs/23_12_29_watchlist/</link>
      <pubDate>Fri, 29 Dec 2023 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/23_12_29_watchlist/</guid>
      <description>Sentinel&amp;rsquo;s watchlist is a collection of entities that can be used to correlate your logs with a rarely changing data set. Although watchlists can be updated via the Azure Portal GUI or even its API, watchlists are typically left in Sentinel unmaintained and untouched for extended periods.
I commonly encounter some watchlists in a client&amp;rsquo;s SIEM when reviewing existing Sentinel instances. Even though some of them are tiny —just a few MB— I occasionally encounter watchlists that are more than 100 MB.</description>
    </item>
    
    <item>
      <title>Log splitting with Data Collection Rules</title>
      <link>https://tokesi.cloud/blogs/23_11_01_dcr/</link>
      <pubDate>Wed, 01 Nov 2023 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/23_11_01_dcr/</guid>
      <description>The initial release of this article appeared on BlueVoyant&amp;rsquo;s website. Click on this link to read it there, along with some lovely diagrams: https://www.managedsentinel.com/log-splitting-with-data-collection-rules/
Alternately, you may read it on my blog by scrolling down.
In a recent article, Microsoft discussed log splitting in Data Collection Rules (DCRs), also known as Multi-Destination Data Collection Rules. Microsoft mentioned a few uses for this capability among the many that it can be put to use.</description>
    </item>
    
    <item>
      <title>Ingestion delay variance issues with Bins and Buckets</title>
      <link>https://tokesi.cloud/blogs/22_10_31_bins/</link>
      <pubDate>Mon, 31 Oct 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_10_31_bins/</guid>
      <description>I&amp;rsquo;m pretty sure you&amp;rsquo;ve already dealt with the ingestion delay issue if you use a SIEM with scheduled rules. There are numerous articles on the internet that explain how to handle ingestion latency without missing any events and without having your rules double-process a log. While these blog posts are excellent, they frequently do not explain the issues with ingestion delay variance. Here, I&amp;rsquo;ll walk you through a specific use-case of how to detect X number of events in Y time while accounting for ingestion time fluctuations without missing any detections.</description>
    </item>
    
    <item>
      <title>How to stop cross-tenant log forwarding? (you cannot)</title>
      <link>https://tokesi.cloud/blogs/22_08_14_crosstenant_diagnostic_logging/</link>
      <pubDate>Sun, 14 Aug 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_08_14_crosstenant_diagnostic_logging/</guid>
      <description>You may want to forward Azure resource logs to a different tenant from time to time. Fortunately, using the Diagnostic settings option in Azure to forward -at least some of the- logs to another tenant is quite simple. I needed to test out some of the interesting scenarios because I couldn&amp;rsquo;t find a detailed description of how the Diagnostic settings work. I&amp;rsquo;ll share my findings with you here.
I had a specific scenario in mind to put to the test.</description>
    </item>
    
    <item>
      <title>Automated Archiving configuration with Function App</title>
      <link>https://tokesi.cloud/blogs/22_06_18_automated_archiving/</link>
      <pubDate>Thu, 16 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_06_18_automated_archiving/</guid>
      <description>Archiving is a fairly new feature in Sentinel that was introduced to help you decrease the cost of your long-term data retention for events that are not used or only rarely used. Previously, you either retained your data outside of Sentinel or had to pay the costly retention fees, but now you can keep your data in the Log Analytics workspace for a lesser cost thanks to Archiving. However, there is a problem with this solution.</description>
    </item>
    
    <item>
      <title>Ingestion-Time Data Transformation in Sentinel</title>
      <link>https://tokesi.cloud/blogs/22_04_04_ingestion_time_data_transformation/</link>
      <pubDate>Mon, 04 Apr 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_04_04_ingestion_time_data_transformation/</guid>
      <description>Lately, each month, I see a new feature from Microsoft that I think is going to be a game-changer for Sentinel. And again, there is a new one that was introduced a month ago, and I think it could be a feature that moves Microsoft’s SIEM to the next level. This feature is called the Ingestion-Time Data Transformation. With this feature, you can easily enrich your logs with additional data or filter the ingested events and fields, which can help you save on the ingestion and retention costs.</description>
    </item>
    
    <item>
      <title>The hidden dangers of NFTs</title>
      <link>https://tokesi.cloud/blogs/22_03_14_nfts/</link>
      <pubDate>Mon, 14 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_03_14_nfts/</guid>
      <description>&amp;ldquo;NFT&amp;rdquo; was the buzzword in the crypto scene in the last few years. The technology is new, and an incredible number of new and inexperienced people have started to work with it. The huge developer community in crypto and NFT space means a lot of new applications and projects are created every day. On the other hand, it also means a lot of solution is never really checked from a security point of view, and lots of bugs can be found in the community-developed programmes.</description>
    </item>
    
    <item>
      <title>Near-Real-Time rule restrictions</title>
      <link>https://tokesi.cloud/blogs/22_01_24_nrt/</link>
      <pubDate>Mon, 24 Jan 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_01_24_nrt/</guid>
      <description>Near-Real-Time (NRT) rule is a pretty new addition to Microsoft Sentinel. There are already blog posts out there detailing the functionality of this rule type and explaining in which scenarios it can be useful. There is some information on Microsoft&amp;rsquo;s site though that left some people confused. The limitations and NRT rules themselves are not working in the way lots of people expect them. So instead of a general introduction of the NRT rules I rather focus on these topics.</description>
    </item>
    
    <item>
      <title>HoneyDoc with Azure and Remote Template Injection</title>
      <link>https://tokesi.cloud/blogs/22_01_09_honeytoken/</link>
      <pubDate>Sun, 09 Jan 2022 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/22_01_09_honeytoken/</guid>
      <description>This post is to show you a practical implementation of a prototype honeytoken which is based on Remote Template Injection and Azure Function App. There are lots of honeytoken solutions on the market. You can find free options as well as expensive commercial services out there. A lot of them also give you a nice way to integrate them into your SIEM while others lack this capability. Which one you choose is really up to your needs.</description>
    </item>
    
    <item>
      <title>Sentinel Connector Health monitoring</title>
      <link>https://tokesi.cloud/blogs/21_12_22_health_monitoring/</link>
      <pubDate>Wed, 22 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_12_22_health_monitoring/</guid>
      <description>When you deal with logs and events in an environment you have to ensure that your log sources and forwarders are up and running. Monitoring the health of these devices is crucial. You can have the best SOC team in the world and a &amp;lsquo;catch all attack&amp;rsquo; detection rule collection, but without logs they are useless. Having a log source down for months can also be problematic from a compliance point of view.</description>
    </item>
    
    <item>
      <title>Sentinel rule deployment with missing tables</title>
      <link>https://tokesi.cloud/blogs/21_11_08_functions/</link>
      <pubDate>Tue, 09 Nov 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_11_08_functions/</guid>
      <description>If you deploy Sentinel daily, you possibly have a step-by-step process you follow to maximize your efficiency. A process like this is needed to be effective and to be able the make your setup reliable and repeatable. Rule creation in Sentinel can be a part of the procedure and it often isn’t the last step. Rules can only be deployed in Sentinel if the table (data source) they are based on is already in Sentinel.</description>
    </item>
    
    <item>
      <title>(Ingestion-) Time will tell</title>
      <link>https://tokesi.cloud/blogs/21_10_02_ingestion_time/</link>
      <pubDate>Fri, 01 Oct 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_10_02_ingestion_time/</guid>
      <description>When you handle logs in a SIEM, times are really important. It doesn&amp;rsquo;t matter whether you investigate alerts, or you create a detection, having the proper times and knowing the different time-related fields can be critical. One of these time fields is the ingestion time value which tells you when an event became available in a SIEM for you to query. I&amp;rsquo;m showing you here how to create a detection and perform an investigation without missing any alerts.</description>
    </item>
    
    <item>
      <title>Per-Table retention in Sentinel</title>
      <link>https://tokesi.cloud/blogs/21_08_27_retention/</link>
      <pubDate>Thu, 26 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_08_27_retention/</guid>
      <description>The log retention period in any SIEM can have a big impact on your cost as well as your investigation and threat hunt capabilities. Defining a low period can be cheaper but it also limits your capabilities to find patterns in your network, to do proper incident response, and to carry out a threat hunt on older data based on newly discovered techniques. All the logs have different values in the long run.</description>
    </item>
    
    <item>
      <title>The best Commitment Tier for you</title>
      <link>https://tokesi.cloud/blogs/21_08_17_cost/</link>
      <pubDate>Tue, 17 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_08_17_cost/</guid>
      <description>A SIEM is the foundation of a modern, well-working SOC. This also means a significant part of the SOC budget can be the cost of the SIEM. Azure Sentinel offers you various payment options based on your usage. Choosing the proper one can make a big difference and can save you a lot of money compared to the default setting. Even though choosing the best one is not too difficult, a lot of companies tend to pick a suboptimal one and then stick with it for a long time.</description>
    </item>
    
    <item>
      <title>Parameterized Alerts in Azure Sentinel</title>
      <link>https://tokesi.cloud/blogs/21_07_27_parameterized_alerts/</link>
      <pubDate>Tue, 27 Jul 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_07_27_parameterized_alerts/</guid>
      <description>A few months ago, Microsoft introduced a new functionality in the Sentinel Analytics Rules which can be used to dynamically define values in incidents. Instead of hardcoding values like the name of the incident or its description, one can specify the content based on the KQL-query used for alerting. This is an option I needed in a lot of other SIEMs in the past, but most of the time it was not there.</description>
    </item>
    
    <item>
      <title>Using Att&amp;ck framework in Azure Sentinel</title>
      <link>https://tokesi.cloud/blogs/21_06_22_attack_in_sentinel/</link>
      <pubDate>Tue, 22 Jun 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_06_22_attack_in_sentinel/</guid>
      <description>The Mitre Att&amp;amp;ck framework is frequently utilized by Security Operation Centers to describe the behavior of the threat or to display detection capabilities. Because of the widespread use of the framework, a lot of Security vendors introduced it in their tooling. Azure Sentinel also has some capabilities related to Att&amp;amp;ck, but it does not provide every functionality a SOC needs. I created some solutions in the past (and present) to bypass Sentinel’s limitations which I am going to show in this article.</description>
    </item>
    
    <item>
      <title>Hiding the Referrer</title>
      <link>https://tokesi.cloud/blogs/21_05_01_referrer/</link>
      <pubDate>Sat, 01 May 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_05_01_referrer/</guid>
      <description>When you investigate a malicious site opening or malicious file download, oftentimes you want to find out how your user got there. Checking the referrer information in proxy logs is one of the most trivial things to do if you want to identify the root cause, the initial site. Unfortunately, there are ways for an attacker to create a site that will alter or hide the referrer information. If the logs do not have the required referrer information and you are not aware that they can be hidden, you can incorrectly assume that there was no referrer at all.</description>
    </item>
    
    <item>
      <title>Ways of phishing 2 - HTML smuggling</title>
      <link>https://tokesi.cloud/blogs/21_04_11_ways_of_phishing_02/</link>
      <pubDate>Sun, 11 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_04_11_ways_of_phishing_02/</guid>
      <description>As a sequel of my previous post, I’m going to talk a little bit about another technique used in phishing that I encountered recently. This technique is HTML smuggling. This method is not new, but it definitely appears in more and more attacks, including phishing scenarios. This is why it is so important to know about the ins and outs of this approach.
List of the three methods I’m showing in this 3 episode-long series:</description>
    </item>
    
    <item>
      <title>Ways of phishing 1 - Remote Template Injection</title>
      <link>https://tokesi.cloud/blogs/21_03_16_ways_of_phishing_01/</link>
      <pubDate>Tue, 16 Mar 2021 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/21_03_16_ways_of_phishing_01/</guid>
      <description>Phishing is one of the most used initial access techniques. This is the reason why most of the companies have an adequate solution to mitigate the threat of these e-mails. But this is a constant cat-and-mouse game. As defenders produce clever mitigations, attackers introduce newer yet unseen methods to bypass them. Here, I am going to describe some phishing techniques which I encountered lately (late 2019 – early 2021). All these approaches are going to be ones I felt like are not detected or mitigated properly most of the time.</description>
    </item>
    
    <item>
      <title>Find your prey - as a threat hunter</title>
      <link>https://tokesi.cloud/blogs/20_10_04_find_your_prey/</link>
      <pubDate>Sun, 04 Oct 2020 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/20_10_04_find_your_prey/</guid>
      <description>So many SOCs I have seen are on a really low maturity level. On the other hand, having a SOC is not a new and fancy thing anymore so more and more companies start to have a really tuned and well-working security team now. As the security function matures in a company, they tend to invest in a Threat Hunting team. A team like this can be a big and sometimes even risky investment for a company.</description>
    </item>
    
    <item>
      <title>Prompt response to ransomwares</title>
      <link>https://tokesi.cloud/blogs/20_09_12_ransomware2/</link>
      <pubDate>Sun, 13 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/20_09_12_ransomware2/</guid>
      <description>Automation is one of the key elements of a modern Security Operation Center. In a traditional SOC without any automation, analysts have to spend a lot of time on tedious and repetitive tasks. This is really inefficient in multiple ways. The analysts can’t use their skills, they must do something that a simple program could do as well. Also, doing things manually can significantly increase the time between starting an investigation and successfully resolving an incident.</description>
    </item>
    
    <item>
      <title>Hunters after ransomwares</title>
      <link>https://tokesi.cloud/blogs/20_07_13_ransomware/</link>
      <pubDate>Mon, 13 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/20_07_13_ransomware/</guid>
      <description>Ransomware is one of the biggest buzzwords nowadays in security. Vendors are advertising their security products by telling it can stop ransomwares, but also on the other side of the field, ransomwares, ransomware kits or services are selling pretty well. Over the last year, one could read an article every month about how ransomwares are not relevant now but also about the rising and more and more sophisticated ransomware attacks. This article is not going to be a general description, it is rather going to be about some specific behavior of ransomwares I observed lately that can help us detect and hunt for these nasty things.</description>
    </item>
    
    <item>
      <title>How (not) to log DNS traffic</title>
      <link>https://tokesi.cloud/blogs/20_06_06_dns_logging/</link>
      <pubDate>Sat, 06 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/20_06_06_dns_logging/</guid>
      <description>Companies tend to create their security detections based on the trending behavior of threat actors. One of the constantly re-occurring techniques is DNS-based activities like exfiltration via DNS (Domain Name System) or C2 (Command and Control) communication via DNS. Still, a lot of companies are lacking in DNS logging, missing DNS-based detection rules, or not aware of their own blindspots.
In this post I’m not trying to explain how to detect DNS-based techniques.</description>
    </item>
    
    <item>
      <title>Unremovable malware with WSL</title>
      <link>https://tokesi.cloud/blogs/19_11_01_unremovable_malware_with_wsl/</link>
      <pubDate>Fri, 01 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_11_01_unremovable_malware_with_wsl/</guid>
      <description>Windows Subsystem for Linux (or, as I&amp;rsquo;m incorrectly calling it, Linux Subsystem for Windows) is a tool in Windows 10 that provides a Linux kernel on top of the Windows kernel. WSL can translate Linux system calls to Windows language. This way one can execute Linux-related apps/commands in Windows without re-compilation. It can be powerful in the hand of a good administrator but it also has some drawbacks as it was mentioned in this reddit post: https://www.</description>
    </item>
    
    <item>
      <title>Defcon DFIR CTF 2019 writeup - Triage VM</title>
      <link>https://tokesi.cloud/blogs/19_09_17_defcon_dfir_ctf/</link>
      <pubDate>Tue, 17 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_09_17_defcon_dfir_ctf/</guid>
      <description>This year an unofficial Defcon DFIR CTF was provided by Champlain College’s Digital Forensic Association. They created challenges in 5 topics which are available for anyone for a little practice on this site: defcon2019.ctfd.io. The challenges are sorted into the following categories:
DFA Crypto Challenge Deadbox Forensics Linux Forensics Memory Forensics Triage VM Questions I&amp;rsquo;m pretty new in forensics, started my journey approximately 9 months ago and have been doing it as an active hobby for 6 months now.</description>
    </item>
    
    <item>
      <title>USB storage forensics in Win10 #1 - Events</title>
      <link>https://tokesi.cloud/blogs/19_08_03_usb_storage_forensics_1/</link>
      <pubDate>Sat, 03 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_08_03_usb_storage_forensics_1/</guid>
      <description>Having information about USB devices connected to a system can be essential for some investigations and analyses. Most of the removable storages used nowadays are USB pen drives so knowing how to identify and investigate these is crucial. The main purpose of USB drive forensic analysis is to identify the connected devices and find some of the following information about it: connection and removal time, files copied to or from the device, opened and executed files and software from the attached drive.</description>
    </item>
    
    <item>
      <title>Malicious process analyzer</title>
      <link>https://tokesi.cloud/blogs/19_05_31_malicious_process_investigation/</link>
      <pubDate>Fri, 31 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_05_31_malicious_process_investigation/</guid>
      <description>I have recently started to make some basic research with osquery. I investigated some malware infections in the past and I decided that I&amp;rsquo;m going to take a look at them with osquery as well. I was curious how much data I can retrieve with osquery and how much I will benefit from its usage. I was honestly surprised because it helped me make some basic information gathering faster than my earlier methods.</description>
    </item>
    
    <item>
      <title>DNS investigation on Windows</title>
      <link>https://tokesi.cloud/blogs/19_05_07_dns_investigation/</link>
      <pubDate>Tue, 07 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_05_07_dns_investigation/</guid>
      <description>Recently, a friend of mine has asked for my help in an investigation. In his SIEM system, he saw that a machine generated some DNS sinkhole events, but he couldn&amp;rsquo;t find the originally requested DNS by the host. The events were generated because the machine tried to resolve a DNS hostname which was marked as malicious in the DNS Server. Unfortunately due to the huge amount of DNS requests in a network, this company did not store the DNS events in the SIEM.</description>
    </item>
    
    <item>
      <title>NTFS Timestamp changes on Windows 10</title>
      <link>https://tokesi.cloud/blogs/19_04_22_win10_ntfs_time_rules/</link>
      <pubDate>Mon, 22 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_04_22_win10_ntfs_time_rules/</guid>
      <description>During my File System Tunneling related investigation I tested NTFS timestamp changes in case of different operations on Windows 10. I used SANS&amp;rsquo;s DFPS_FOR500_v4.9_4-19 and Cyberforensicator&amp;rsquo;s timestamp posters for comparison. I found out that my results were different from theirs. In my tests, some of the operations produced different timestamp changes and inheritance than the previously mentioned posters show. These timestamp rules can change in every Windows version so it is worth checking them from time to time.</description>
    </item>
    
    <item>
      <title>File System Tunneling in Windows</title>
      <link>https://tokesi.cloud/blogs/19_04_13_windows-file-system-tunneling/</link>
      <pubDate>Sat, 13 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19_04_13_windows-file-system-tunneling/</guid>
      <description>File System Tunneling is a really old feature of Windows. It was already discussed on many security or Windows administration related blogs and books. However, it is still somewhat obscure for lots of examiners because its forensic implication is limited. The simplest way to test and observe it in action is to delete a file and then create a new one with the same name in the same path. The new file is going to inherit the creation timestamp of the original file.</description>
    </item>
    
    <item>
      <title>Evade the analyst</title>
      <link>https://tokesi.cloud/blogs/19-03-31_evade-the-analyst/</link>
      <pubDate>Sun, 31 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://tokesi.cloud/blogs/19-03-31_evade-the-analyst/</guid>
      <description>There are various different methods and techniques to evade detection by an IDS. If you know how a SIEM in a network works you can also adapt your attack to prevent the target from detecting your move. But this post is a first of a series in which I want to share my (only) 3 years of observation and experience as an Incident Responder about how to avoid being detected by a Security Analyst/ Incident Responder, not by the security system itself.</description>
    </item>
    
  </channel>
</rss>
