Category Archives: Autostart (Persistence)

Beyond the good ol’ .bashrc entry… Part 1

Posted on by

I really don’t know if this is the first post in the series, or just a one-off that is also, the last. There are many fantastic blog posts out there that deal with the most popular Linux persistence tricks, f.ex. here. The latter is one of the best resources on Linux persistence that I know of, so I encourage everyone to read it first….

So, why starting something new, here?

Truth be told that I was never the biggest user of Linux, but same as it is with macOS – their footprint is now so prominent that there is no escape 😉 So, since I am not an expert on Linux, this blog series (if it really happens) is about a different Linux… The non-expert-one. The year of Linux on the Desktop is probably still ahead of us, but there is already a lot of dumb-linux-user-level (like me) persistence opportunities in today’s desktop Linux versions that we can explore…

Here’s the first one: The Terminal profile…

One of the more interesting options offered by Terminal’s configuration panel is this:

As it clearly says, you can set a custom command to execute when the terminal window is created under that given profile. A kinda stealth, conditional persistence, isn’t it?

And what’s interesting about this configuration choice, apart from launching Gnome Calculator when you open a terminal in this profile (suggesting that any executable configured to execute from there could simply do its malicious thing first, then launch the shell so no one is the wiser…), is that the configuration of this setting is not preserved in a traditional way (inside an .ini or any familiar ‘linuxish’ textual configuration file), but in a place that is a Linux cousin of Windows Registry: dconf…

Now, one can install dconf-editor to view these settings, but it complicates things. It’s very Windows-ish way of preserving the configuration data, after all. Still that’s the easiest way to spot the bad guy:

Is there an equivalent of RegShot for Linux today that can detect these changes in dconf?

Matlab persistent lolbin – 2 years too late, but always…

Posted on by

I just realized I have never published a post about lolbinish/persistencish Matlab feature that I referred to in this twit. The Tl;dr; is that Matlab can load a DLL of our choice when we use its feature that is both Matlab-user friendly, and … unbelievable.

Using the following command line invocation:

MATLAB.exe -nosplash -nodesktop -r "run('c:\test\test.m'); exit;"

we can instruct matlab to load the matlab file named ‘test.m’ in a batch-like fashion.

The ‘test.m’ in this example include a short piece of code shown below:

x = foo();

When matlab loads the ‘test.m’, it tries to resolve the function ‘foo’ that it will eventually recognize as unknown; as a result, it will look for locally present Matlab executable files (*.mex32 on 32-, and *.mexw64 on 64-bit Windows), and will try to find that function there. In our case (on 64-bit version of OS/matlab) it will look for a ‘foo.mexw64’ file, load it (it is a DLL), and then call a function mexFunction acting as an interface between matlab and the matlab executable.

The example session is shown in this animation:

It’s obvious there are at least two scenarios where this ‘feature’ can be used for offensive purposes:

  • niche Lolbin – having a library of your choice loaded by matlab may help to evade security software
  • niche and stealthy persistence – matlab files can be modified in a viral way to force the loading our our library of choice at some random moment in the future