Named function invocations can break deobfuscation

Macro sheets allow Excel to replicate the effect of a RUN() invocation by defining a name and then referencing it in a sheet by appending () to the name.

For example:

=SET.NAME("InvokeMe",B1)
=InvokeMe()

is identical to calling RUN(B1). You can chain these expressions together as well, for example:

=SET.NAME("IndirectFunction","=B1")
=SET.NAME("IndirectInvocation",EVALUATE("IndirectFunction"))
=IndirectInvocation()

will also replicate calling RUN(B1). It looks like the invocation of a name and treating it as a RUN() expression hasn’t been added to the grammar for the tool yet. Here’s a small PoC for both of these cases that will help if maldoc authors start abusing this.

setname-obfuscation.xls.zip

[DissectMalware]

That make sense to be honest. The same for À (can be represented with two characters in ASCII or one unicode)

[DissectMalware]

Generated an alternate document which can also cause some issues by abusing user defined functions combined with variables set using SET.NAME.

By hiding a subroutine in the sheet somewhere else (it can be simple like, =RETURN(CHAR(var))), we can fake pass an argument to the subroutine and invoke it by making a call like:

=IF(SET.NAME("var",73),InvokeChar(),)

Which is identical to =CHAR(73).

Right now this sort of approach will not be emulated, so once the GOTO() is reached, there’s no content shown.

charsub-method.xls.zip

This is addressed in v0.1.5 (currently on Master branch)