Bugzilla – Bug 164
create "wildcard" signatures
Last modified: 2021-11-30 15:42:28 EST
There are phishing mails that contain: <static text><phishing url><static text> Currently sigs have to be created each time the 'phishers' change their domain. Phishing detection engine enhancement: new signature type: static text(hex):any url from .pdb containing certain flag:static text(hex) Example (hypotethical): some text to fool the user into clicking right here : <phishing url> some other text Signature will look like: <.... text before url...>:special symbol(**):<....text after url....> Implementation notes: - take advantage of partial signature matching facility in matching engine - figure out a way to plug-in some code whenever our special ** symbol is encountered. - This would match any domain from the .pdb containing a certain flag - then it would pass control to the partial match algo, to search for further matches If this would be very hard to implement, then I'll have to think another approach.
Hi Tomasz, Some technical implementation details of this feature: - all the non-regex sigs in the .pdb/.wdb are already loaded in an AC-trie, so all I need to figure out is how to tell the matcher to switch to another AC-root when it encounters a [y], and switch back to original root, when done with [y], or when [y] fails match. - add support for '[' in cli_parse_add (inside strchr(hexsig, '{')) - add another field to cli_ac_patt for [y] - figure out a way to map y to .pdb/.wdb AC-roots - add support temporarily switching to another ac_root in cli_ac_scanbuff (in current->islast before :622) Is there anything I missed, or are any of my assumptions wrong/need further discussion?
implementation detail: subsig_i;${a-b}0{c-d}$subsig_i+1 It remembers the last match position for subsig_i and subsig_i+1, and when both subsig_i and subsig_i+1 matched, only then it tests whether the macro matches.
Created attachment 1143 [details] updated macro patch Here is the macro patch updated to master. In the LDB there is (one or more) special subsignature ${min-max}MACROID$, which means: must match any signature from group MACROID (for current filetype), and the match must occur at a distance of min-max from the start(!) of the previous logical subsignature match. It also has the sideeffect of making the previous subsignature considered a match only if both that and the macro matches. The offset of first match for the previous logical subsig will be the offset where the {min-max} distance is satisfied. The macro logical subsignature will have a count of 0 (if it didn't match together with the previous subsig), or a count of 1 if it did. There can be at most 32 macro groups, signatures are added to a macro group by using $MACROID$ as offset. For example pdb entries could be converted to PDB:3:$0:<hexsig of domainname> if we assign macro id 0 to PDB (and we can assign 31 more macro ids to whatever). Example: test.ldb: TestMacro;Target:0;0&1;616161;${3-4}12$ test.ndb: D:0:$12:6262 D:0:$12:6363 D:0:$11:6262 test.dat: aaaaxccdd test-nomatch.dat: aaaaxxxccdd
Committed in r5076-753-gab89360.