While files can be polymorph to escape detection, it is also shown that PDF can be easily polymorphed to escape detection by AV. And the best of this doesn't involve complicated mathematics.
This article was based on:
OK, lets start with names. After PDF spec 1.2, basically we can encode all the names (which is followed after the "/") using hexadecimals. For example :
We want to open my blog using the /URI name:
But AV may be looking for "/URI", we can encode it into hex by doing this:
This is all in hex, but to create more choices, we can have :
and so on. You get the picture. This will allow us to morph the name a bit.
Secondly, we can also morph the strings values. In this case, its the URL. We have several tricks that can be used here.
Firstly, the "escape new line" method:
This can be use to break into new lines (for easy reading maybe). Also, just push this further, we can do this:
or even more extreme, we can break all the characters. Lets see AV write one rule that can detect that. (I am sure multiple rules can do it, but that's the challenge leave for the AV companies)
How about Hexadecimal? Yes, we can do that too:
Or yes, even with some space :
/URI (687474 703a2f2f6e656d657369 73762e626c6f6773706f74 2e636f 6d)
Now, that's really going to piss the AV detection off. But hexadecimal is not the only thing we can use for encoding the values. We can use octal decimals as well:
To finish this off, PDF even suppose anonymous encryption which the user does not need to know the password to operate the PDF. Now, we are really using the other end of the blade back at the AV. So the whole string will look like some rubbish instead.
Of course, some of the above can be effectively mix and match to morph your PDF payload, but it is very unlikely the encryption can be detected by AV. Unless the AV ban all /URI tags, but until then, PDF is ideal for phishing and other very bad things.