The Ouroboros of Cybercrime - Witnessing Threat Actors go from Pwn to Pwn’d: This talk highlighted the cyclical nature of cybercrime, where threat actors who compromise systems are themselves targeted and compromised by other groups. It illustrated how attacks evolve and often come full circle, underscoring the volatility and risks within the cybercrime ecosystem.

The XE Files - Trust No Router: James Atack provided an in-depth look into Cisco Talos’s recent findings on widespread router compromises, revealing that tens of thousands of routers remain vulnerable to backdoors. He emphasized the persistence of the adversary and the concerning lack of response from some organizations, calling for enhanced vigilance around network devices.

New Features in the Zeek Network Monitor: Christian Kreibich discussed the latest advancements in Zeek, including scriptability with JavaScript, performance improvements, and enhanced telemetry integration with Prometheus. These updates open new possibilities for network analysis, making Zeek an even more robust tool for proactive network monitoring.

Sigma Unleashed - A Realistic Implementation: Mathieu Le Cleach from CERT-EU shared a real-world implementation of Sigma rules for better detection across multiple SIEMs and EDRs. His tool, Droid, supports versioning, modular rule validation, and cross-platform deployment, helping organizations maintain adaptable and effective detection capabilities.

Predictive Analytics for Adversary Techniques in the MITRE ATT&CK Framework using Rule Mining: Tristan Madani presented a predictive model using association rule mining to anticipate adversary techniques based on historical data within the MITRE ATT&CK framework. By applying Apriori and FP-Growth algorithms, he showcased how this approach can enhance threat hunting by identifying probable attack patterns and improving proactive defense.

Exploring Firmwares - Tools and Techniques for New Cartographers: Eloïse Brocas introduced attendees to firmware analysis, guiding them through file system extraction and cartography using tools like Pyrrha and Numbat. She demonstrated how custom parsers with Kaitai Struct and visual mapping can uncover vulnerabilities and provide deep insights into firmware structure, aiding in securing IoT and embedded devices.

Building a Reliable Network

One of the most rewarding aspects of conferences is networking. Over the years, the people I’ve met at these events have become go-to resources, especially when urgent information is needed—whether for an incident response or tracking specific threat actors. Networking at conferences goes beyond just meeting people; it’s about building a trusted circle that becomes invaluable over time. Through these connections, I’ve gained access to private communities where tradecraft, Indicators of Compromise (IoCs), and other crucial intelligence are shared within trusted circles—information you won’t find on public feeds. This network provides a distinct advantage, allowing faster, more informed responses to emerging threats.

• Get Out There: A firm handshake and a quick chat can lead to partnerships that prove crucial down the line. Conferences offer a rare chance to meet key players in the field face-to-face, from vendor contacts to fellow CTI analysts.
• Follow-Up Is Key: Once the event wraps, I make it a point to follow up with new contacts through email or social media. Consistent interaction ensures the network grows beyond just a business card collection.

Tools and Techniques: Always Something New

Each conference is packed with workshops and talks that showcase the latest tools and techniques. I’ve found this invaluable in staying updated and avoiding the “outdated” trap that can sneak up if you skip even a year.

• Evaluation Through Practice: I look at each new tool with an eye on its practical applications. Will it replace an existing tool? Fill a gap? Workshops provide a low-risk way to test drive and evaluate, often with feedback from the presenters and other attendees.
• Inspiration for Efficiency: Each event brings fresh insights. Listening to discussions or just chatting during breaks has sparked ideas on how to refine my daily workflows.

Test Training Providers Before Committing

Professional training can be costly, and conference workshops offer a rare chance to try before you buy, which I find invaluable:

• Preview Content and Format: Testing out a training provider’s content, format, and instructor style through workshops is key. It gives a snapshot of the depth of training on offer and helps me decide if it’s worth the investment.
• Collect Resources for Evaluation: I try to gather any resources provided, as they give me a better sense of the program’s scope and whether it meets my needs.

Personal Development: Validation, Gaps, and Reflection

Conferences offer a unique space for personal growth. Not only do they validate existing skills, but they also highlight areas for improvement and encourage meaningful self-reflection.

• Validate Skills: When a workshop feels straightforward, it’s a boost—an indicator that I’m on track. Occasionally, it even pushes me to consider running a workshop myself or sharing insights with peers.
• Identify Knowledge Gaps: Areas that prove challenging are equally valuable, showing me where to focus my development efforts in the coming months.
• Self-Reflection and Feedback: Conferences allow me to step back and reflect on my daily practices. Traveling with colleagues offers a great opportunity to gather feedback and brainstorm on our workflows.

Documentation: Bringing the Value Home

To keep the value of each conference alive, I make documentation a priority. This not only benefits my future self but also my colleagues, who may not have attended.

• Notes and Feedback: I take time to refine my notes post-conference, aiming for constructive feedback that I’d find helpful myself. It’s about creating something that others can understand and apply.
• Resource Collection: Gathering slides, videos, and any shared materials is part of my routine. These resources help me revisit topics and keep the content fresh long after the event.
• Sharing What Matters: I believe in going beyond a summary, focusing on relevance. Sharing insights with colleagues—what’s important and why—ensures the knowledge serves the team, not just myself.

By documenting each event thoroughly, I’ve been able to track which conferences were truly impactful over the years—those that resulted in actionable changes in my practice versus those that offered less value. Time is a critical resource, especially when balancing conference attendance with full-time work. Proper records allow me to focus on the most beneficial events going forward and help build a track record I can use to demonstrate the value of attendance to management. This documentation becomes evidence, supporting the need to attend future events by showcasing the direct impact these conferences have had on my work.

For me, conferences have become a cornerstone of both my professional and personal growth. They’re not just events but essential check-ins on my journey as a CTI analyst, each one shaping my skills, network, and outlook in the cybersecurity world.

Morning Sessions

Back to the Failure - Did Your Physical Security Really Evolve in the Last 40 Years? Presented by Simon Geusebroek from Synacktiv, this talk revisited the evolution (or lack thereof) of physical security measures over the past four decades. Geusebroek demonstrated how many physical security systems, such as locks and access controls, remain vulnerable to basic bypass techniques. The session highlighted how outdated security practices and reliance on certifications give a false sense of security, allowing attackers to easily breach supposedly “secure” facilities.

Blowing up Gas Stations for Fun and Profit Pedro Umbelino exposed vulnerabilities in Automated Tank Gauging (ATG) systems, which monitor fuel levels in critical infrastructures like gas stations and military bases. Umbelino revealed several zero-day vulnerabilities that could allow attackers to remotely manipulate fuel storage systems, potentially causing environmental and economic damage. Despite previous warnings, many ATG systems remain unprotected and accessible online, leaving critical infrastructure at risk.

Reversing Flutter with Blutter and Radare2 This technical workshop delved into the complexities of reverse engineering Flutter applications. Axelle Apvrille guided attendees through the complexities of reverse engineering Flutter applications. Flutter, a popular cross-platform mobile development framework, poses unique challenges for reverse engineers due to its custom binary format. Apvrille introduced tools like Blutter and Radare2 to analyze and manipulate Flutter binaries, offering practical techniques to uncover vulnerabilities and modify app behavior.

Afternoon Sessions

Scanning with the Artemis Security Scanner Presented by Krzysztof Zając, this session focused on Artemis, an open-source tool for automating vulnerability scanning across domains. Zając walked through how CSIRTs, network administrators, and hosting providers can set up Artemis to scan large networks and automatically report findings. The hands-on session covered the tool’s installation, configuration, and reporting capabilities, providing a scalable solution for identifying vulnerabilities across thousands of domains.

iOS Compromise Detection Using Open Source Tools David Durvaux and Christophe Vandeplas led this workshop on detecting compromises on iOS devices using sysdiagnose and other open-source tools. They demonstrated how sysdiagnose can collect detailed diagnostic data from iPhones and iPads, and how security teams can use these tools to uncover potential breaches, including spyware and misconfigurations. Participants learned how to parse sysdiagnose files and use the data to build timelines, enabling more efficient and thorough investigations of iOS device

Morning Sessions

CSIRT and the Chocolate Factory: This case study detailed how a small company in the chocolate machinery business faced a ransomware attack. Despite paying the ransom, they were unable to decrypt their files. The CSIRT team stepped in, uncovering a flaw in the ransomware that allowed them to recover the files without needing the decryption key, providing key insights into ransomware analysis and remediation.

The Gist of Hundreds of Incident Response Cases: Stephan Berger shared lessons learned from his experience in incident response, emphasizing the importance of focusing on key artifacts, such as Anti-Virus logs and suspicious network activity. He also highlighted the importance of automating and streamlining incident investigations to handle large environments more efficiently.

IoT Hacks Humans: Unexpected Angles of Human Process Compromise: This talk explored how IoT devices, which interact closely with human processes, can be manipulated to create significant security risks. By collecting data from connected devices, attackers can influence behaviors, spread disinformation, and exploit digital identities. He highlighted real-world examples, such as opinion manipulation and personal surveillance. The talk emphasized the expanding human attack surface due to connected environments and stressed the need for better defenses and awareness to counter these growing threats.

KubeHound: Identifying Attack Paths in Kubernetes Clusters: Julien Terriac introduced KubeHound, a tool designed to automate the identification of attack paths in Kubernetes clusters. By applying graph theory, KubeHound allows security teams to visualize and prioritize vulnerabilities, making it easier to protect large-scale Kubernetes environments.

It Has Been 0 Days Since the Last Edge-Device Security Incident: Paul Rascagneres from Volexity discussed recent zero-day vulnerabilities in edge devices, focusing on Ivanti Connect Secure and Palo Alto Global Protect. The talk highlighted the challenges of detecting and responding to these vulnerabilities and emphasized the need for better monitoring and forensics on edge devices.

Afternoon Sessions

Chrome V8 Exploitation Training for Beginners: Hoseok Lee led a hands-on workshop that introduced participants to the inner workings of the Chrome V8 engine. The training covered debugging techniques, analyzing vulnerabilities, and exploiting bugs, providing beginners with a comprehensive guide to V8 exploitation.

Securing the Stars: Modern Satellite Vulnerabilities: Vic Huang presented an analysis of satellite vulnerabilities, including real-world cases of compromised communication systems. He highlighted weaknesses in both traditional satellite systems and open-source CubeSat projects, emphasizing the urgent need for better security in space technology.

DFIQ: Codifying Digital Forensic Intelligence: Thomas Chopitea introduced DFIQ, a framework designed to organize and automate digital forensic investigations. By codifying investigative questions and creating structured workflows, DFIQ aims to standardize forensic practices and improve consistency in investigations.

Cyber Threats to Advanced Intelligent Connected Vehicle Systems: Shihao Xue and Yuqiao Ning detailed the vulnerabilities present in Intelligent Connected Vehicles (ICVs), including issues with the T-Box and CAN bus interfaces. They demonstrated how these vulnerabilities could be exploited for remote vehicle control and data theft, stressing the need for stronger security in automotive systems.

APT28: Following Bear Tracks Back to the Cave: Golo Baulig from IBM X-Force explored the operations of the Russian state-sponsored group ITG05 (APT28), detailing recent campaigns, evolving malware, and infrastructure changes. Baulig’s analysis provided insights into ITG05’s activities, including their targeting of NATO member states and their continuous adaptation to geopolitical shifts.

Morning Sessions

The morning sessions at the conference provided an in-depth look at the evolving cybersecurity landscape, covering a range of topics from the resilience of modern botnets to advancements in automation and threat intelligence tools. Each talk presented unique insights into how the threat environment is changing and the innovations being developed to counter these risks, offering valuable lessons for CTI professionals.

Insights from Modern Botnets Miguel Hernández’s presentation delved into the inner workings of modern botnets, illustrating how these threats remain highly adaptable. Botnets like Mirai and Shellbot continue to evolve, with numerous variants easily accessible and used for DDoS attacks and cryptomining. Hernández highlighted how botnets operate as a service, rebranding when discovered, and often target critical sectors such as government and finance. The research emphasized the growing sophistication and accessibility of these threats.

NeuroCTI: Benchmarking, Successes, Failures, and Lessons Learned Aaron Kaplan shared his work on NeuroCTI, a custom large language model (LLM) fine-tuned for CTI purposes. Kaplan discussed the challenges of training local models for CTI data extraction, the difficulty of building a reliable dataset, and the privacy concerns around cloud-based solutions. The model shows promise in tasks such as summarization, named entity recognition (NER), and mapping TTPs to MITRE ATT&CK, but off-the-shelf LLMs still present tough competition. The session underscored the need for fine-tuning and local deployment to protect sensitive data.

Tales of the Future Past Saâd Kadhi from CERT-EU provided a reflective talk on the lessons learned from past cyber incidents and how they shape the future of cybersecurity. He discussed the ongoing importance of traditional attack vectors, such as cyberespionage and information operations, while highlighting the potential threats posed by emerging technologies like AI. Kadhi cautioned that while AI offers automation potential, it lacks the human intuition necessary for comprehensive threat detection, urging caution in over-relying on machine intelligence for security tasks.

Integrating New Tools in Your Workflows Within Minutes in MISP Sami Mokaddem demonstrated the ease of integrating new tools into existing cybersecurity workflows using MISP. The session showcased how the MISP automation framework, including pymisp, misp-modules, and workflows, allows for the quick deployment of external tools to enrich threat intelligence data. Mokaddem highlighted the flexibility of MISP’s workflow editor, which can automate enrichment of .onion addresses, while restricting the sharing of undesirable content.

Lessons Learned from (almost) 8 Years of Sigma Development Thomas Patzke offered valuable insights from his experience maintaining the open-source Sigma project, a language for creating detection rules across different security platforms. Patzke discussed the challenges of balancing simplicity and scalability, highlighting the benefits of a complete toolchain rewrite in 2020. The separation of code and rules, along with the adoption of better development practices like test-driven development, improved the project’s maintainability and adoption, but also introduced new complexities around coordination and dependency management.

Afternoon Sessions

This afternoon’s sessions provided in-depth insights into the evolving threat landscape and defensive strategies across different platforms, from Windows malware persistence to Linux rootkits, industrial protocol vulnerabilities, and an innovative approach to honeypots using large language models (LLMs). Each talk presented actionable strategies for detection and defense against these sophisticated threats, alongside a hands-on workshop that introduced participants to Return Oriented Programming (ROP) on ARM64, further equipping attendees with practical skills in exploit development.

Workshop: ROP on ARM64 - A Hands-On Tutorial In the workshop, Saumil Shah provided participants with a practical introduction to Return Oriented Programming (ROP) on ARM64. The tutorial covered essential ARM64 assembly concepts, common ROP gadgets, and practical exploit development techniques, including building ROP chains. Shah’s workshop offered a hands-on experience with an ARM64 emulator and equipped participants with the skills to navigate the unique challenges posed by the ARM64 architecture, making it a valuable session for anyone interested in exploit development on this platform.

Malware and Hunting for Persistence Cocomelonc’s presentation focused on unconventional malware persistence techniques in Windows environments. The session highlighted how adversaries use registry modifications and DLL hijacking to maintain persistence on compromised systems. Through case studies, including vulnerabilities in Internet Explorer, Microsoft Teams, and cryptographic APIs, Cocomelonc demonstrated how attackers exploit legitimate Windows resources to evade detection and maintain long-term access, emphasizing the importance of robust detection strategies to counter these attacks.

Breaking Industrial Protocol Translation Devices Claire Vacherot shared insights from her research into vulnerabilities in Anybus X-gateways, critical devices used for translating industrial protocols. Vacherot revealed how these often-overlooked gateways are prime targets for attackers, given their role in maintaining communication between OT systems. She detailed three critical vulnerabilities in the device, including unauthenticated access, manipulation of proprietary protocols, and denial-of-service attacks, showing how attackers can exploit these weaknesses to disrupt industrial processes.

In-Depth Study of Linux Rootkits: Evolution, Detection, and Defense Stephan Berger’s talk explored the evolution of Linux rootkits, from early userland techniques to modern kernel-level rootkits. Berger outlined advanced rootkit techniques, such as hooking kernel functions and exploiting eBPF, and provided a thorough review of detection strategies using integrity checking, behavioral analysis, and memory forensics. By analyzing rootkits like Bedevil and Diamorphine, Berger underscored the importance of using modern detection tools to uncover sophisticated threats in Linux environments.

Decoding Galah: an LLM-Powered Web Adel Karimi introduced Galah, an innovative honeypot powered by large language models (LLMs) that dynamically generates realistic HTTP responses to simulate multiple web applications. Karimi discussed the challenges of building Galah, including issues with response formatting and the difficulty of maintaining deception. Despite these challenges, Galah successfully engaged attackers, particularly in cases involving open proxy emulation. This approach showcased the potential of using LLMs to improve honeypot realism and increase attacker interaction.

I created this post to gain a more extensive comprehension of file uploads, allowing me to rebuild the feature within my custom Telepath client in C#. In a following blog entry, I will look into how one can download files from Synapse/Axon.

LMDB?

LMDB (Lightning Memory-Mapped Database) is a powerful software library that facilitates lightning-fast transactions for applications requiring massive amounts of data storage and access. It’s specifically designed to be fast, reliable, and endlessly scalable - rendering it the optimal selection for programs needing substantial performance levels with minimal latency.

LMDB employs a revolutionary technique known as memory mapping, which gives the system permission to process a file just like it were part of its internal memory. As a result, it becomes simple and quick for users to access data stored in the database since no copying or transferring is needed — data can be acquired directly from memory!

The transactional nature of LMDB is integral, providing a reliable way to manage database updates and ensure that they remain consistent. This durability is especially essential in applications where data integrity can’t be compromised, as it guarantees the preservation of an unchanged state - even if there’s a power failure or system crash!

LMDB offers an impressive, dynamic database solution fit for applications that need rapid and reliable access to enormous amounts of data. This technology is utilized all over the world in a wide range of contexts, from advanced web apps to embedded systems and even databases themselves.

Test bed

For the purpose of this post, we will be uploading two files. The first one is an empty file named test.txt and contains nothing inside it; while the second one is titled hello-world.txt, which only has a string that says Hello World!.

$ shasum -a 256 test.txt 
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  test.txt
$ shasum -a 256 hello-world.txt 
7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069  hello-world.txt

To initiate transmission of our two data files, we first launched a Vertex Synapse node (via Docker) on port 8903 to interact with the Telepath API. We then fired up Wireshark to capture the traffic between server and client before running the following commands in a Storm client:

$ python3 -m synapse.tools.storm tcp://root:***@localhost:8903/

Welcome to the Storm interpreter!

Local interpreter (non-storm) commands may be executed with a ! prefix:
    Use !quit to exit.
    Use !help to see local interpreter commands.

storm> !pushfile test.txt
uploading file: test.txt
.........
file:bytes=sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
        :name = test.txt
        :sha256 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
        .created = 2023/02/10 07:32:06.671
complete. 1 nodes in 105 ms (9/sec).
storm>  !pushfile hello-world.txt
uploading file: hello-world.txt
.........
file:bytes=sha256:7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
        :name = hello-world.txt
        :sha256 = 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
        .created = 2023/02/10 08:01:12.755
complete. 1 nodes in 25 ms (40/sec).

storm> !quit
o/

We paused the Wireshark capture and scrutinized the relevant packets, paying special attention to their msgpack-encoded messages. By copying these as a hex stream in Wireshark, we were able to decode them online. with ease.

Exchanges Telepath Messages

To begin, we must fetch a handle to write onto and save. The best way to do this is by sending out the t2:init message for the method getAxonUpload. With that done, we can write our desired data.

[
  "t2:init",
  {
    "todo": [
      "getAxonUpload",
      [],
      {}
    ],
    "name": null,
    "sess": "865026c78fe7e6fa304394d460738505"
  }
]

The server will return a response containing various key values, with one of the most important being iden which we’ll need to upload our file.

[
  "t2:share",
  {
    "iden": "730bc4268e211064c973c27510acd2d1",
    "sharinfo": {
      "meths": {},
      "syn:commit": "92fc8df3c249f39c26d76ff2db2a48b2b5abd41f",
      "syn:version": [
        2,
        122,
        0
      ],
      "classes": [
        "synapse.axon.UpLoadProxy",
        "synapse.lib.share.Share",
        "synapse.lib.base.Base"
      ]
    }
  }
]

To start, we will be uploading the empty file test.txt. We have nothing to write in this case, thus all that is needed is a call of save on our handle (which you should remember as synapse.axon.UpLoadProxy).

[
  "t2:init",
  {
    "todo": [
      "save",
      [],
      {}
    ],
    "name": "730bc4268e211064c973c27510acd2d1",
    "sess": "865026c78fe7e6fa304394d460738505"
  }
]

The server provides the following affirmative notifications, confirming that we have completed our task.

[
  "t2:fini",
  {
    "retn": [
      true,
      [
        0,
        {
          "type": "Buffer",
          "data": [
            227, 176, 196, 66, 152, 252, 28, 20, 154, 251, 244, 200, 153, 111, 
            185, 36, 39, 174, 65, 228, 100, 155, 147, 76, 164, 149, 153, 27, 
            120, 82, 184, 85
          ]
        }
      ]
    ]
  }
]
[
  "share:fini",
  {
    "share": "730bc4268e211064c973c27510acd2d1"
  }
]

The value in the field data provides us with the SHA256 hash of the file, as you can decode for example with CyberChef.

For the second instance, we are uploading a text file titled hello-world.txt which isn’t blank; it carries the string Hello World! that is translated as:

$ hexdump -C hello-world.txt
00000000  48 65 6c 6c 6f 20 57 6f  72 6c 64 21              |Hello World!|
0000000c

That is, in decimal

$ hexdump -e'"%07.8_ad  " 8/1 "%d " "  " 8/1 "%d " "  |"' -e'16/1  "%_p"  "|\n"' hello-world.txt 
00000000  72 101 108 108 111 32 87 111 114 108 100 33      |Hello World!|

By using the write method on our handle, we can store the bytes contained in the field data, which are expressed as decimals.

[
  "t2:init",
  {
    "todo": [
      "write",
      [
        {
          "type": "Buffer",
          "data": [
            72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33
          ]
        }
      ],
      {}
    ],
    "name": "730bc4268e211064c973c27510acd2d1",
    "sess": "865026c78fe7e6fa304394d460738505"
  }
]

After executing the operation, we received confirmation that it was a success.

[
  "t2:fini",
  {
    "retn": [
      true,
      null
    ]
  }
]

We can now save the file, like demonstrated above with the empty file.

Uploading the file to Axon does not register in Synapse’s server. Thus, there is a need for us to record a file:bytes node in Synapse and we do this by sending a t2:init message for the storm method with query [ file:bytes=$sha256 ] { -:name [ :name = $name] } along with its corresponding mapping variable.

[
  "t2:init",
  {
    "todo": [
      "storm",
      [
        "[ file:bytes=$sha256 ] { -:name [:name=$name] }"
      ],
      {
        "opts": {
          "repr": true,
          "vars": {
            "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
            "name": "test.txt"
          }
        }
      }
    ],
    "name": null,
    "sess": "865026c78fe7e6fa304394d460738505"
  }
]

In return, we get a generator and the node. For brevity in our explanation,we will omit any message related to node-edits from this output.

[
  "t2:genr",
  {}
]
[
  "t2:yield",
  {
    "retn": [
      true,
      [
        "init",
        {
          "tick": 1676014326577,
          "text": "[ file:bytes=$sha256 ] { -:name [:name=$name] }",
          "task": "453997a728583c8038263f8116cab3ca"
        }
      ]
    ]
  }
]
...
(skipping two node-edit message)
...
[
  "t2:yield",
  {
    "retn": [
      true,
      [
        "node",
        [
          [
            "file:bytes",
            "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
          ],
          {
            "iden": "3fda2bf653ccbf15df887152bcf2fa86a0a95375cefd45e47dbe1f76051e2b87",
            "tags": {},
            "props": {
              ".created": 1676014326671,
              "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
              "name": "test.txt"
            },
            "tagprops": {},
            "nodedata": {},
            "reprs": {
              ".created": "2023/02/10 07:32:06.671"
            },
            "tagpropreprs": {},
            "path": {}
          }
        ]
      ]
    ]
  }
]
...
[
  "t2:yield",
  {
    "retn": [
      true,
      [
        "fini",
        {
          "tock": 1676014326682,
          "took": 105,
          "count": 1
        }
      ]
    ]
  }
]

Our Synapse instance has just added a new node, which our t2:yield with node details. We can verify that the files exist in our client:

storm> file:bytes
file:bytes=sha256:7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
        :name = hello-world.txt
        :sha256 = 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
        .created = 2023/02/10 08:01:12.755
file:bytes=sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
        :name = test.txt
        :sha256 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
        .created = 2023/02/10 07:32:06.671
complete. 2 nodes in 5 ms (400/sec).

It is possible to create a model of any given file in Synapse without having to manually upload the file. This comes in handy when you are working on malicious intrusions, for example: “sample xxx drops yyy” where both xxx and yyy refer to specific hashes. We can then design the files as file:bytes with their corresponding hash properties set up. If at some point we decide to upload these files (e.g., from VirusTotal), Synapse will automatically detect this and avoid recreating it if its original hashes match those on record.

Structured data and data modeling enables us to gain a deeper comprehension of the world and how it works. We can query our system to uncover correlations, retrieve information or create statistics, warnings, etc. In Synapse, for example, I model organizations with ou:org type which is referred to as “A human organization such as a company or military unit.”

With ou:org, there is an abundance of properties available. But rather than being overwhelmed by the multitude of possibilities, focus on your specific needs to determine what fields would be essential for you to record information and answer any future questions. Utilize your primary intelligence and collection requirements to identify which elements you should prioritize to achieve optimal results.

It’s interesting to note the distinction between type and orgtype, as both captures essentially the same thing. The ou:orgtype type captures an organization-type taxonomy with a more specific set of values than what is found in the free text field. Having such constrained values can be extremely useful when creating statistics; for example, you could define types such as corporation, non-profit organization, government agency, or cooperative.

The ou:org type is based on a GUID, so finding a unique identifier for deconfliction can prove difficult. However, we can use an alternative property

• such as the organization’s name – to identify if it already exists when importing or creating our organizations. This saves us from having to conduct searches every time! To achieve this goal, Synapse proposes GUID generators driven by an extra property. We are particularly interested in the $lib.gen.orgByName(name) generator which will generate an ou: org with the specified name if it does not already exist yet. Furthermore, another generator of interest is $lib.gen.orgByFqdn(fqdn), which returns a generated organization node based on a domain used for emailing purposes - usually taken from an email address itself!

As an initial case study, let’s discuss my enterprise Cyantlabs. The following steps will generate the node (or retrieve it if it has already been created).

storm> $lib.gen.orgByName("cyantlabs")

Afterward, we can broaden the node’s properties with more detailed information.

storm> ou:org:name="cyantlabs" [ loc="be.bru.brussels" dns:mx=$lib.list("cyantlabs.com") ]

By introducing the organization, we can now transition from an individual email address to that of the company. For instance

storm> inet:email="spam@cyantlabs.com" -> inet:fqdn -> ou:org

We can also utilize the second generator based off of a domain name. For instance, after starting with an email address, we acquire its related domain to subsequently create (if necessary) the organization node.

storm> [ inet:email="info@nviso.eu" ] -> inet:fqdn $lib.gen.orgByFqdn($node)

An intriguing element is the ‘loc’ datatype, which forms a hierarchy with dot-separated strings. For instance, we can easily fetch all Belgian organizations stored in our system:

storm> ou:org:loc=be.*

or organizations situated in the Brussels region

storm> ou:org:loc=be.bru.*

ou:org=8a9d383c25ebf82bd710b274e75ef5fd
    .created=2023/02/04 01:03:05.826
    name=nviso
    loc=be.bru.etterbeek
    dns:mx=(nviso.eu)
ou:org=17c8a7cdaae78909c954a28ea7cec2b9
    .created=2023/02/01 23:21:06.839
    dns:mx=(cyantlabs.com)
    name=cyantlabs
    loc=be.bru.schaerbeek

By tracking organizations in Vertex Synapse, you can leverage the ou:org node and its various properties to effectively manage your organization roster. Once the nodes are created, several useful properties can be utilized - such as location and DNS MX records - to gain a better understanding of the organizations you’re tracking. As this article shows, Vertex Synapse provides an intuitive way to record and monitor your (cyber) structured data.

Happy modeling! :)

In an ideal scenario, these logs are ingested in your SIEM and you can compile your Sigma rule to the proper backend. But in real life, that is not always the case and you sometimes need to fallback on good ol’ text files. During an incident response, you don’t have the luxury to wait for the logs to be ingested; during a threat hunt you don’t want the SOC to spend time ingesting a useless log source.

To illustrate the process, let’s take a log entry from AWS Network Firewall

{
  "firewall_name": "test-firewall",
  "availability_zone": "us-east-1b",
  "event_timestamp": "1602627001",
  "event": {
    "timestamp": "2020-10-13T22:10:01.006481+0000",
    "flow_id": 1582438383425873,
    "event_type": "alert",
    "src_ip": "203.0.113.4",
    "src_port": 55555,
    "dest_ip": "192.0.2.16",
    "dest_port": 111,
    "proto": "TCP",
    "alert": {
      "action": "allowed",
      "signature_id": 5,
      "rev": 0,
      "signature": "test_tcp",
      "category": "",
      "severity": 1
    }
  }
}

While grep, cut, sort, awk or jq are of great help (in particular when the log file is jsonl), they form recipe that are difficult to share and document. Good luck if your log format is XML however. You could probably create the grep expression that would matches the log entries you assessed malicious but you would like to hoard that knowledge.

When the SOC has completed its job of ingesting the log source, you don’t want to come back and re-create a detection rule.

A solution is to write a Sigma rule and apply it directly to the text file. Chainsaw 2.0 released yesterday supports JSON logs, with some caveat.

For our example, we could assess for example that this log entry is malicious because it is an alert ("event_type":"alert") to the destination ip 192.0.2.16 (so "dest_ip":"192.0.2.16"). A possible rule is then

title: Suspicious activity to compromised machine
id: 94f9921a-23b2-11ed-861d-0242ac120002
status: experimental
description: An alert for the test rule test_tcp to a compromised machine
author: Antoine Cailliau
date: 2022/08/24
detection:
    selection:
        EventType: 'alert'
        DestinationIp: '192.0.2.16'
    condition: selection
level: low
fields:
    - Signature
    - SourceIp
    - DestinationIp
falsepositives:
    - Unknown    

Before being able to execute the rule against the JSON file, we need to create a mapping that will translate the fields of the Sigma rule to the correct JSON fields. For the example here, I decided the following mapping:

That can be translate in Chainsaw format as follow. Note that the format requires a filter section, commonly on the provider. Here I decided to call the provider AWS-Network-Firewall.

---
name: Chainsaw's Sigma mappings to AWS Firewall logs
kind: json
rules: sigma

groups:
  - name: Sigma
    timestamp: Timestamp
    filter:
      Provider: "*"
    fields:
      - name: Firewall Name
        from: FirewallName
        to: firewall_name
      - name: Availability Zone
        from: AvailabilityZone
        to: availability_zone
      - name: Time Created
        from: TimeCreated
        to: event_timestamp
      - name: Timestamp
        from: Timestamp
        to: event.timestamp 
      - name: Flow ID
        from: FlowID
        to: event.flow_id
      - name: Event Type
        from: EventType
        to: event.event_type
      - name: Source Ip
        from: SourceIp
        to: event.src_ip
      - name: Source Port
        from: SourcePort
        to: event.src_port
      - name: Destination Ip
        from: DestinationIp
        to: event.dest_ip 
      - name: Destination Port
        from: DestinationPort
        to: event.dest_port 
      - name: Protocol
        from: Protocol
        to: event.proto 
      - name: Action
        from: Action
        to: event.alert.action 
      - name: SignatureID
        from: Signature ID
        to: event.alert.signature_id 
      - name: Revision
        from: Revision
        to: event.alert.rev 
      - name: Signature
        from: Signature
        to: event.alert.signature
      - name: Category
        from: Category
        to: event.alert.category
      - name: Severity
        from: Severity
        to: event.alert.severity 
      - name: Provider
        from: Provider
        to: provider

For our JSON lines to have a chance to match the rule, we need to massage it for Chainsaw:

1. Our log file is composed on JSON lines and Chainsaw requires an array of JSON objects.
2. Our log file does not contain the provider field.
3. The format of the date 2020-10-13T22:10:01.006481+0000 does not please Chainsaw.

Hopefully, jq can apply such transform very easily.

$ cat 20220824-aws-network-firewall.json \
    | jq '.provider = "AWS-Network-Firewall"' \
    | jq '.event.timestamp = (.event.timestamp | split(".")[0] | strptime("%Y-%m-%dT%H:%M:%S") | strftime("%Y-%m-%dT%H:%M:%S.0000Z"))' \
    | jq -s . \
    > 20220824-aws-network-firewall_chainsaw.json

and we can now run the Sigma rule against the log file,

$ ./chainsaw hunt ./20220824-aws-network-firewall_chainsaw.json \
    --sigma ./example-aws-rule.yaml \
    --mapping ./mappings/sigma-aws-firewall.yml

For example,

$ ./chainsaw hunt ./20220824-aws-network-firewall_chainsaw.json --sigma ./example-aws-rule.yaml --mapping ./mappings/sigma-aws-firewall.yml  --json -q | jq .
[
  {
    "group": "Sigma",
    "kind": "individual",
    "document": {
      "kind": "json",
      "data": {
        "availability_zone": "us-east-1b",
        "event": {
          "alert": {
            "action": "allowed",
            "category": "",
            "rev": 0,
            "severity": 1,
            "signature": "test_tcp",
            "signature_id": 5
          },
          "dest_ip": "192.0.2.16",
          "dest_port": 111,
          "event_type": "alert",
          "flow_id": 1582438383425873,
          "proto": "TCP",
          "src_ip": "203.0.113.4",
          "src_port": 55555,
          "timestamp": "2020-10-13T22:10:01.0000Z"
        },
        "event_timestamp": "1602627001",
        "firewall_name": "test-firewall",
        "provider": "AWS-Network-Firewall"
      }
    },
    "name": "Suspicious activity to compromised machine",
    "timestamp": "2020-10-13T22:10:01+00:00",
    "authors": [
      "Antoine Cailliau"
    ],
    "level": "low",
    "source": "sigma",
    "status": "experimental",
    "falsepositives": [
      "Unknown"
    ],
    "id": "94f9921a-23b2-11ed-861d-0242ac120002"
  }
]

Happy hunting :bow_and_arrow:

Webshell are a very common plague in today attack and are used by almost all the documented threat actors. You can find plenty webshells freely available on GitHub. A few YARA rules to webshells are commonly available, and a few Sigma rules detects suspicious process spawned from common web server executables.

Let’s assume for the example a webshell in C# (because that is my favorite language) that compiles and execute the code dynamically, like one allegedly used by APT34 leaked in 2019, SUPERNOVA as used during the SolarWinds compromise or in ShaPyShell released a year ago. The webshell will take a source code as a parameter, will compile the code, and execute the compiled code. A second attack we will have a look at will drop an executable in the C:\inetpub\wwwroot folder. I will not provide such webshell, there is no reason to lower the bar for any attacker.

First, I started with a clean Windows 10 machine, installed IIS and ASP.NET components, and the webshell causing the activity I want to detect. For monitoring and detection, I’m focused on SysMon and wanted to test the latest version that went out yesterday. I thereby installed SysMon 14 and used a default configuration file with a small addition to trigger the latest capability of SysMon:

<RuleGroup name="" groupRelation="or">
    <FileBlockExecutable onmatch="include">
        <TargetFilename condition="contains all">C:\inetpub\wwwroot</TargetFilename>
    </FileBlockExecutable>
</RuleGroup>

Now, the testing harness is set up. We can simulate the attack and generate the EVTX file. My process is

1. Test the malicious activity to ensure that it works.
2. Open eventvwr and clear the SysMon log (or other log source I can use to detect the behavior)
3. Execute the malicious activity.
4. Refresh the eventvwr and export the relevant log file(s) as EVTX.

For the example, I generated the following 3 events. An event recording w3wp.exe writing a DLL,

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" /> 
        <EventID>11</EventID> 
        <Version>2</Version> 
        <Level>4</Level> 
        <Task>11</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8000000000000000</Keywords> 
        <TimeCreated SystemTime="2022-08-17T14:36:03.5803606Z" /> 
        <EventRecordID>2246</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="3000" ThreadID="1232" /> 
        <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
        <Computer>MalwareLab</Computer> 
        <Security UserID="S-1-5-18" /> 
    </System>
    <EventData>
        <Data Name="RuleName">DLL</Data> 
        <Data Name="UtcTime">2022-08-17 14:36:03.568</Data> 
        <Data Name="ProcessGuid">{0fd50764-f82f-62fc-4504-000000001600}</Data> 
        <Data Name="ProcessId">8124</Data> 
        <Data Name="Image">c:\windows\system32\inetsrv\w3wp.exe</Data> 
        <Data Name="TargetFilename">C:\Windows\Temp\qriyblj4.dll</Data> 
        <Data Name="CreationUtcTime">2022-08-17 14:36:03.568</Data> 
        <Data Name="User">IIS APPPOOL\DefaultAppPool</Data> 
    </EventData>
</Event>

An event recording w3wp.exe executing a compiler csc.exe,

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" /> 
        <EventID>1</EventID> 
        <Version>5</Version> 
        <Level>4</Level> 
        <Task>1</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8000000000000000</Keywords> 
        <TimeCreated SystemTime="2022-08-17T14:36:03.6081662Z" /> 
        <EventRecordID>2248</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="3000" ThreadID="1232" /> 
        <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
        <Computer>MalwareLab</Computer> 
        <Security UserID="S-1-5-18" /> 
    </System>
    <EventData>
        <Data Name="RuleName">-</Data> 
        <Data Name="UtcTime">2022-08-17 14:36:03.601</Data> 
        <Data Name="ProcessGuid">{0fd50764-fcd3-62fc-9104-000000001600}</Data> 
        <Data Name="ProcessId">6300</Data> 
        <Data Name="Image">C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe</Data> 
        <Data Name="FileVersion">4.8.4084.0 built by: NET48REL1</Data> 
        <Data Name="Description">Visual C# Command Line Compiler</Data> 
        <Data Name="Product">Microsoft® .NET Framework</Data> 
        <Data Name="Company">Microsoft Corporation</Data> 
        <Data Name="OriginalFileName">csc.exe</Data> 
        <Data Name="CommandLine">"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /noconfig /fullpaths @"C:\WINDOWS\TEMP\qriyblj4.cmdline"</Data> 
        <Data Name="CurrentDirectory">C:\inetpub\wwwroot\</Data> 
        <Data Name="User">IIS APPPOOL\DefaultAppPool</Data> 
        <Data Name="LogonGuid">{0fd50764-f82f-62fc-acea-9d0000000000}</Data> 
        <Data Name="LogonId">0x9deaac</Data> 
        <Data Name="TerminalSessionId">0</Data> 
        <Data Name="IntegrityLevel">High</Data> 
        <Data Name="Hashes">MD5=F65B029562077B648A6A5F6A1AA76A66,SHA256=4A6D0864E19C0368A47217C129B075DDDF61A6A262388F9D21045D82F3423ED7,IMPHASH=EE1E569AD02AA1F7AECA80AC0601D80D</Data> 
        <Data Name="ParentProcessGuid">{0fd50764-f82f-62fc-4504-000000001600}</Data> 
        <Data Name="ParentProcessId">8124</Data> 
        <Data Name="ParentImage">C:\Windows\System32\inetsrv\w3wp.exe</Data> 
        <Data Name="ParentCommandLine">c:\windows\system32\inetsrv\w3wp.exe -ap "DefaultAppPool" -v "v4.0" -l "webengine4.dll" -a \\.\pipe\iisipmda7b0f18-2ba4-4c04-ae39-359c977c2aa7 -h "C:\inetpub\temp\apppools\DefaultAppPool\DefaultAppPool.config" -w "" -m 0 -t 20 -ta 0</Data> 
        <Data Name="ParentUser">IIS APPPOOL\DefaultAppPool</Data> 
    </EventData>
</Event>

And an event recording w3wp.exe dropping an executable in the inetpub folder,

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" /> 
        <EventID>27</EventID> 
        <Version>5</Version> 
        <Level>4</Level> 
        <Task>27</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8000000000000000</Keywords> 
        <TimeCreated SystemTime="2022-08-17T14:36:04.2708793Z" /> 
        <EventRecordID>2252</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="3000" ThreadID="1232" /> 
        <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
        <Computer>MalwareLab</Computer> 
        <Security UserID="S-1-5-18" /> 
    </System>
    <EventData>
        <Data Name="RuleName">-</Data> 
        <Data Name="UtcTime">2022-08-17 14:36:04.270</Data> 
        <Data Name="ProcessGuid">{0fd50764-f82f-62fc-4504-000000001600}</Data> 
        <Data Name="ProcessId">8124</Data> 
        <Data Name="User">IIS APPPOOL\DefaultAppPool</Data> 
        <Data Name="Image">c:\windows\system32\inetsrv\w3wp.exe</Data> 
        <Data Name="TargetFilename">C:\inetpub\wwwroot\MyAppCopy.exe</Data> 
        <Data Name="Hashes">MD5=870000F5100C6F8F407540C96200D5C4,SHA256=DA19CCE90EA7B0CB0A0FC754BB10C015ECCC73147EBB7712F2818A44D1663BC9,IMPHASH=698FA83DA166EDB916866EF085B426D9</Data> 
    </EventData>
</Event>

Based on these three events, we can write Sigma rules that detects the suspicious activity.

• The first event is suspicious because it looks abnormal for IIS (Image ends with w3wp.exe) to write (EventID: 11) a DLL in the temp folder (TargetFilename starts with C:\Windows\Temp\ and ends with .dll, avoid regular expression where possible).
• The second event is suspicious because it looks abnormal for IIS (ParentImage ends with w3wp.exe) to call (EventID: 1) spawn a C# compiler (Image ends with csc.exe).
• The third event is suspicious because it looks abnormal for IIS (Image ends with w3wp.exe) to drop an executable (EventID: 27).

Because the first two events are related to the dynamic execution of C# code within IIS, I decided to group them within a single Sigma rule.

title: Dynamic C# Webshell compilation by IIS
id: ebf2c122-d2fc-416c-a90c-698a4ba9161e
status: experimental
description: Detects dynamic compilation of C# code executed by IIS.
tags:
    - attack.execution
author: Antoine Cailliau
date: 2022/08/17
logsource:
    category: process_creation
    product: windows
detection:
    selection_csc:
        EventID: 1
        ParentImage|endswith: 'w3wp.exe'
        Image|endswith: 'csc.exe'
    selection_compiled_output:
        EventID: 11
        Image|endswith: 'w3wp.exe'
        TargetFilename|endswith: 'dll'
        TargetFilename|startswith: 'C:\Windows\Temp'
    condition: selection_csc or selection_compiled_output
level: medium
falsepositives:
    - Legitimate dynamic web applications

The third event is not related to that specific type of webshell and we created a second Sigma rule.

title: IIS writing executable file
id: 2f8504e9-b715-4a7f-bb7c-fa3100dc8246
status: experimental
description: Detects a blocked executable dropped by IIS
tags:
    - attack.execution
author: Antoine Cailliau
date: 2022/08/17
logsource:
    category: file_creation
    product: windows
detection:
    selection:
        EventID: 27
        Image|endswith: 'w3wp.exe'
    condition: selection
level: low
falsepositives:
    - Unknown

Now, we complete the process described here by testing the rules on many EVTX to avoid false positive and include more true positive.

I do not claim that these rules are fool proof and they are likely to require some tuning depending on your environment. Knowing your baseline is key aspect in detection, and could be part of a complete post series.

My language of choice for detecting suspicious log entries is Sigma. Sigma is to logs what Yara is to files and Snort is to network traffic. (Florian Roth)[https://twitter.com/cyb3rops] already shares a tremendous amount of Sigma rules that detect suspicious events but some events will be specific to your environment and your incidents. For example,

• If you detected an abused account, you can write a detection rule that triggers on any log mentioning the account and be notified of any further event.

• If you detected a compromised host that is used to RDP to other machines, you can write a detection rules that, when executed against the event logs of all your machines, will help you scoping the intrusion.

Because Sigma rules are source-agnostic, you can write one rule and use it to run against collected event log files, as a Kibana query or as a Sentinel KQL query. With the increasing diversity in systems, it is a bless to not have to maintain many detection rules that achieve the same logic.

To learn more about detection engineering with Sigma, I recommend the following course: Detection Engineering with Sigma that has, in my opinion, a good return on investment.

My process to develop Sigma rules against Windows Event logs:

1. Find malicious or suspicious activity in event log entries.
2. Characterize why the activity is suspicious, focus on your rationale for assessing that the activity is not right.
3. Write a Sigma rules that detects the activity
4. Run the rules against event logs that contains the suspicious activity (to confirm the rule is detecting the activity), against event logs that are known to be clean (to assess the false positive rate), and against a collection of generic event logs containing malicious activity as in the (evtx-attack-sample)[https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES] dataset.
5. Assess the true and false positives rates, refine and go to Step 4 until you are satisfied.

To run the rules, I use Chainsaw to run the sigma rules against EVTX files.

You first need to install and compile the tool:

$ git clone https://github.com/countercept/chainsaw.git
$ cd chainsaw
$ cargo build --release

You might need to install dependencies first. On ubuntu:

$ sudo apt install cargo gcc-multilib

The tool is then available in the target/release/ folder:

$ cd target/release/
$ ./chainsaw --help

When installed you can run the rules with hunt command:

$ ./chainsaw hunt /path/to/evtx/folder/ \
    --sigma /path/to/sigma/rules/ \
    --mapping ../../mappings/sigma-event-logs-all.yml

For example, to train, we would like to run the set of “standard” Sigma rules from the (official repository)[https://github.com/SigmaHQ/sigma] against the known-to-be-malicious evtx files from (evtx-attack-sample)[https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES].

First, clone the rules and the samples

$ git clone https://github.com/SigmaHQ/sigma
$ git clone https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES.git 

Then, we can detect malicious activity by running the tool (I assume that your are in chainsaw/target/release folder)

$ ./chainsaw hunt /mnt/hgfs/Cases/EVTX-ATTACK-SAMPLES/ \
    --sigma /mnt/hgfs/Cases/sigma/rules \
    --mapping ../../mappings/sigma-event-logs-all.yml

Depending on your marchine it can take a while to complete. In my case, it detected quite a few log entries to check :-)

[+] 1353 Detections found on 924 documents

Other useful ressources:

• Rapidly Search and Hunt through Windows Event Logs
• Down the Chainsaw path to analyse Windows Event logs