Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: 'hex' keyword #741

Open
Neo23x0 opened this issue Sep 24, 2017 · 3 comments

Comments

@Neo23x0
Copy link
Contributor

commented Sep 24, 2017

A new keyword hex that encodes a string could improve the rule writing process to face the rise of malicious embedded scripts in OLE objects.

Instead of the string

$s1 = "68007400740070003a002f002f00"

a user could write

$s1 = "http://" wide hex

and other users could understand the rule without a comment.

/* http:// - wide and hex encoded */
$s1 = "68007400740070003a002f002f00"

Update 14.11.17: corrected the request - see the comment below

@plusvic

This comment has been minimized.

Copy link
Collaborator

commented Sep 24, 2017

But that's exactly what the wide modifier does, right? I mean, these two strings are equivalent:

$s1 = "http://" wide

$s1 = { 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 }
@Neo23x0

This comment has been minimized.

Copy link
Contributor Author

commented Sep 25, 2017

Ah - no.
let me explain it differently.
The objects are embedded in a hex encoded form. (see the screenshot)

screen shot 2017-09-25 at 16 47 21

If you hex decode the strings, you'll get the VBA code in wide formatting. (not sure if this is always the case but I haven't seen ASCII code)

screen shot 2017-09-25 at 16 51 15

So, it would be easier for a user to to write

$vba1 = "10.24.113.102/office.png" hex wide

Instead of

$vbacode1 = "00310030002E00320034002E00310033002E003100300032002F006F00660066006900630065002E0070006E0067" 

(note that this string and no byte chain)

I propose this feature because

  1. I have seen a lot of malicious scripts and obfuscation stuff for which I wrote rules with strings like $vbacode1recently and the number of malicious embedded content is rising
  2. I though that it wouldn't be that difficult to implement

Possible problem:

  • The nocase keyword and its application
@Neo23x0

This comment has been minimized.

Copy link
Contributor Author

commented Sep 25, 2017

I see that I made an error in the initial request. I used the { instead of " symbols.
My fault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.