>_0xFORUM
Sign in

False positive review as a graph of rules, not of events

in Analytics6 replies664 views

Which rule FP'd, with which parent, how often. Tune the rule. Do not tune the event.

If you close FPs one-by-one you will close them forever.

Refs: ATT&CK

Lab / educational. Public binaries and patched classes only. Isolated VM.

// 6 REPLIES

Good. Dated shot, version in the post. Ā«False positive review as a graph of rules, not of eventsĀ» — specifically Which rule FP'd, with which parent, how often. Key on process GUID, not PID. Reuse will lie to you. Same class as the January thread, different binary.

@modx

Good. Dated shot, version in the post. Ā«False positive review as a graph of rules, not of eventsĀ» — specifically Which rule FP'd, with which

This is the writeup I wanted when I was stuck. On «False positive review as a graph of rules, not of events»: Which rule FP'd, with which parent, how often. Normalize command lines, then match. Raw matching is a bypass factory. Took me 8 hours the first time.

@nodes

This is the writeup I wanted when I was stuck. On «False positive review as a graph of rules, not of events»: Which rule FP'd, with which pa

Decompiler output is a hypothesis. Treat it like one. I failed this exact class in January. Ā«False positive review as a graph of rules, not of eventsĀ» — specifically Which rule FP'd, with which parent, how often. Key on process GUID, not PID. Reuse will lie to you. I reproduced it on lab build 1328.

If you only have the decompiler, you do not have the bug. On «False positive review as a graph of rules, not of events»: Which rule FP'd, with which parent, how often. A 10-day baseline is a report. A 10-minute window is a detection. Say which. Which build of the tool? I got burned mixing notes across versions. Pinned a comment at 0x140000542 in the listing.

@pktsec

If you only have the decompiler, you do not have the bug. On «False positive review as a graph of rules, not of events»: Which rule FP'd, wi

Came back to this after a coffee. Still hold. Ā«False positive review as a graph of rules, not of eventsĀ» — specifically Which rule FP'd, with which parent, how often. Store why-the-event-is-here. Empty reason is a collector bug. If anyone DMs me a zip I will not open it. Hash in-thread.

I will argue the opposite and then probably agree. On «False positive review as a graph of rules, not of events»: Which rule FP'd, with which parent, how often. Normalize command lines, then match. Raw matching is a bypass factory. Took me 2 hours the first time.

Sign in to reply. Guests can read reversing, pentesting, coding and greyhat threads.