Read on Twitter
I& #39;ve seen a couple of instances of rules at $job where someone put "XXXXX" in a rule and it causes ERROR_TOO_MANY_MATCHES, which stops the entire scan job. This has masked legitimate rules from matching on that sample. It sucks and I fix them when I see them, but it got me...
thinking about how this can be leveraged into something more interesting. Let& #39;s say you see some vendor put out a YARA rule and you know it flags on your sample which is in VT. Is it possible to upload a benign file that causes the vendor rule to ERROR_TOO_MANY_MATCHES?
I have no idea how the VT backend works, but if they batch up N files to be processed by a single worker then when ERROR_TOO_MANY_MATCHES happens they could (in theory) drop the remaining M files? So if you upload enough of these trigger files you could reduce the efficacy...
of the rule. Again, I have no idea how VT works on the back end nor would I suggest experimenting to find out but it is an interesting problem to consider. At $job we don& #39;t have this problem because we don& #39;t batch up our runs (each file is scanned in a single job).
This has implications beyond VT too. Places which process files in batches will have this. I have no idea how Klara works on the backend but I think they are just blasting yara (the command line version) over entire directories, so they would likely have this problem?
Anyways, this is all a thought exercise after a conversation I had with @michael_yip - the second most handsome British person I& #39;ve had the pleasure of interacting with. Nothing will come close to Sir Tom Lancaster (AKA: The British Barry White).
