# tl;dr > **update:** This technique got popular enough that even the OffensiveNim repo got updated with an example. Still works, though. In this post I wanted to explore the possibilities and caveats of using XLL files for initial access, as this delivery method has become increasingly popular with threat actors. As an illustration, I have also released a very simple XLL builder, available on github -- https://github.com/zimnyaa/xyrella ![[xyrella.gif]] # XLL files XLL files are, at their core, Windows DLLs with special exports. Excel then calls these exports to communicate what functionality is presented by an XLL. Fortunately, nobody really cares what Excel thinks about our XLL, because the plan is to hijack execution the moment Excel calls any of the DLL functions. The most important (for malware, of course) exports are: - **xlAutoOpen** -- called when the addin is opened with a double-click; - **xlAutoAddin** -- called when the addin is imported within Excel - and, of course, you can always put your payloads in **DllMain**. # opening XLL files XLL files present a prompt when unsigned and double-clicked or added with the "Add-ins" ribbon: ![[Pasted image 20220203175526.png]] If the user clicks the "Enable ..." button, Excel jumps straight to code execution. When manually imported or imported with VBA, though, unsigned XLLs can easily be loaded without any prompts. It is less useful, however, as you either need to instruct the target to install an add-in, which is a pretty uncommon thing for people to do, or run your macro. If people run your macros, you do not really need an XLL, right? > **note:** if you do want to run XLLs with macros, there is some weird behaviour I have noticed. The Application.RegisterXLL method works just fine in subroutines, but does nothing in functions for some reason. If you call a subroutine that loads the XLL within a function due to, for example, a cell update, RegisterXLL returns True, but does nothing. LMK if you know why that happens. # signing XLL files If you have a valid code signing certificate -- this section is not for you, congratulations. One might be willing to make the Excel prompt look a little bit more legit by self-signing the DLL. However, **self-signed XLLs will do worse than unsigned ones**. This is because, for self-signed XLLs, Excel **does not present an "execute malware" button.** Instead, it presents a yellow ribbon (similar to the active content warning, which it practically is). Then, the user is expected to go and figure out how to enable the active content (and he has to choose the content type manually) to import the functionality of the XLL he just clicked on. This is why `xyrella` does not have self-signing functionality -- it just makes things worse. # xyrella `xyrella` is a simple XLL builder without any remote injection functionality (it can unhook NTDLL, though). I sincerely believe that it makes things easier when you separate your intial access method and your injection/EDR bypass technique. From the execution standpoint, `xyrella` is just [[nim-fibers]], compiled to a DLL. The usage is pretty straightforward: >![[Pasted image 20220203181056.png]] The project source is available [here](https://github.com/zimnyaa/xyrella) # credits @dre on BloodhoundGang for threat actor updates @[ajpc500](https://github.com/ajpc500) for NimlineWhispers2 @[khchen](https://github.com/khchen) for Winim @[byt3bl33d3r](https://github.com/byt3bl33d3r) for the ntdll unhooking example