ASPIRE

YARA之what&why&how

=Start=

缘由：

https://github.com/search?o=desc&q=yara&s=stars&type=Repositories&utf8=%E2%9C%93

正文：

参考解答：

YARA是什么？

模式匹配中的瑞士军刀（The pattern matching swiss knife）

YARA是一款旨在(但不限于)帮助恶意软件研究人员识别和分类恶意软件样本的工具。使用YARA，您可以根据文本或二进制模式创建恶意软件家族(或您想要描述的任何东西)的描述。每一个描述，称为规则，由一组字符串和一个决定其逻辑的布尔表达式组成。

YARA的优势在哪？

  • YARA适用于多平台，可运行在Windows、Linux和Mac OS X上，并且可以通过它的命令行接口或在你自己编写的Python脚本中引入yara-python扩展来使用它。
  • 有社区帮你维护/更新各种规则，不论是恶意软件还是webshell。

YARA有哪些应用？

参考链接：

https://github.com/VirusTotal/yara
http://yara.readthedocs.io/en/latest/index.html

https://github.com/Yara-Rules/rules
https://github.com/nbs-system/php-malware-finder
https://github.com/Neo23x0/yarGen
https://github.com/Neo23x0/yarAnalyzer
https://github.com/mitre/multiscanner
https://github.com/Xen0ph0n/YaraGenerator
https://github.com/godaddy/procfilter

https://github.com/Yara-Rules/rules/tree/master/Webshells
https://github.com/phishme/malware_analysis/tree/master/yara_rules
https://github.com/tenable/yara-rules

https://www.tenable.com/blog/hunting-for-web-shells
http://www.tenable.com/blog/hunting-linux-malware-with-yara
http://www.tenable.com/blog/threat-hunting-with-yara-and-nessus

=END=

Docker

, ,

《 “YARA之what&why&how” 》 有 23 条评论

  23. 特征检测和行为检测两种威胁检测方案的比较
    The difference between signature-based and behavioural detections
    https://s3cur3th1ssh1t.github.io/Signature_vs_Behaviour/
    `
    In this blog post, the main difference between signature-based and behavior-based Detections are explained. In addition, examples are shown with respective Detection bypasses.

    There are multiple Detection-techniques, which a Packer can bypass and there are others, which technically cannot get bypassed. Writing a blog post about this topic is at least for me the easiest way to answer this, as in the future I can just send one link for these kind of questions. 😉

    # Signature-based Detections
    Signature-based Detections are very simple. The very first AV solutions had a signature database with File-Hashes and they just compared the Hash of any executable on disk with the known malicious executable softwares Hash. E.g. this database contained the SHA1/MD5 Hash of the release binary for Mimikatz. Changing the Hash of an executable is as simple as manipulating a single byte in it, so this Detection is not really reliable and at least I hope not commonly used anymore anyway in 2022.

    # Behaviour-based Detections – some examples and bypasses
    But which behaviours could trigger an AV/EDR action or a Memory Scan on runtime? This can basically be everything. Writing stuff into Memory, loading specific libraries in a specific order and/or time-frame, creating registry entries, do initial HTTP requests or any other action.

    I’ll give some few examples here with corresponding bypass techniques for Defender.

    From my personal experience the least common action an AV/EDR does after detecting a specific behaviour is instantly killing the Process. Why is that? Well, AV/EDR vendors don’t want to have too many false positive findings. As false positive findings with the action of killing a Process can lead to disruptions in production environments which is really bad. So they need to be nearly 100% sure, that a behaviour is definitely Malware to kill the corresponding Process. This is also the reason, why many vendors combine the Detection of a behaviour with a Memory Scan afterwards to verify they found something Malicious.

    # Conclusion
    On the one hand, I wanted to use this article to give an overview of what a Packer can technically bypass and at what point the Operator has to take action himself. Some things should hopefully be clear:
    * The Operator should know what his Payload is doing
    * The Operator should know about the Indicators of Compromise (IoCs) for his Payloads
    * Behaviour-based Detections can only get bypassed by the Operator himself via Payload modification

    On the other hand I showed some examples on how to bypass behaviour-based Detections from Defender for
    * The Fodhelper UAC Bypass
    * Meterpreter
    * Cobalt Strike
    For Cobalt Strike detections in other mature environments – well at some point I stopped digging deeper as it was just too much of a BlackBox for me. I’m still excited about it’s future development and will follow all those changes. Who knows, maybe someday I’ll pick it up again.

    The post ended up with the fundamental question about if all this stuff is even needed at all. Sometimes you will not get around it because the software/tool is closed source and known malicious. I personally think, that it’s not. But this just depends on which Payload you’re using. With custom tools or obfuscation many evasion techniques should not be needed at all. But as custom tools or heavy modification for each tool needs a lot of effort, the alternative of more and more evasion techniques has to be accepted in many cases. At one point you just have to question yourself, if additional effort for evasion is worth getting a known malicious Payload to work. I’m curious, where this pushing will lead to in the next years. Maybe there will be a Point at some time, where people prefer more one-time-effort against a constant up-to-date evasion practice.
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注