Category Archives: Compromise Detection

Beyond good ol’ Run key, Part 18

Posted on by

If you hear legitimate & legacy in the same sentence then it is – most likely – not a good news.

The not-so-known persistence mechanisms that have a reason to be there are quite interesting, because they are often obscure and long forgotten. And while left unknown to a general public they may be still heavily utilized for legitimate purposes even if just by a niche group of people.

Maybe that’s why the mechanism I am going to describe survived such a long journey from Windows NT to Windows 10 Preview…

I am talking about Logon Scripts.

There is not much online about their internals. The best I could find was this post:

Logon scripts (both GPO and user) are actually handled by USERINIT.EXE.  If I recall correctly, the user logon script is handled by the same instance of USERINIT.EXE that starts the desktop instance of EXPLORER.EXE (i.e. the one that would be spawned from gina!WlxActivateUserShell), whereas the domain GPO scripts are executed by separate instances of USERINIT.EXE which are requested to be spawned by WINLOGON.EXE via gina!WlxStartApplication.

The easy way to screw up the execution of these login scripts (i.e. works fine with MSGINA so I know the configuration is right, but with my replacement GINA installed they no longer run) would be to miss including the expected environment variables that WINLOGON was trying to impart to the spawned instances of USERINIT.EXE, since its via environment variables that the intention for USERINIT.EXE to run a particular script is commuicated.

Be sure you’re building an environment block that includes all the environment specified in the pEnvironment parameter to the Wlx functions cited.  In the case of GPO scripts you’re looking for an envrionment variable such as “UserInitGPOScriptType”, and “UserInitMprLogonScript” is the environment varibale WlxActivateUserShell is expected to create with the pszMprLogonScript parameter string’s contents.

The funny fact is that userinit.exe is relying on environment variables and these can be always abused – this makes it easy to quickly set up a simple persistence mechanism by using the Registry Environment keys.

There are 3 environment variables the mechanism relies on:

  • A pair of UserInitLogonServer & UserInitLogonScript identifying where to run script from; first one identifies the server, the second location
  • UserInitMprLogonScript – this one is a simple path to a script; there may be more than one; MPR stands for Multiple Provider Router

That’s it.

Setting up the HKEY_CURRENT_USER\Environment variables and dropping scripts in an appropriate location is enough to pull this off.

To test the UserInitMprLogonScript setting:

  • Save the following file as c:\test\UserInitMprLogonScriptlog.bat
@echo off             
@echo # 'UserInitMprLogonScript' 
@if exist c:\test\UserInitMprLogonScript.log @del c:\test\UserInitMprLogonScript.log
@echo UserInitMprLogonScript executed !> c:\test\UserInitMprLogonScript.log
@pause
  • Add the following Registry Entry
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Environment]
"UserInitMprLogonScript"="c:\\test\\UserInitMprLogonScript.bat"

Once you log off and log on again you should see the script running, and if it is not shown in a dedicated terminal window (e.g. in case of Windows 10 Preview) you can confirm it did execute by checking if the file c:\test\UserInitMprLogonScript.log exists.

Why breaches happen under IR teams noses

Posted on by

Having an IR Team is not a guarantee of breach-free life for the organization. In this short post I am trying to list very specific reasons why breaches happen despite IR teams being present and active. Instead of writing yet-another-smart-ass-who-knows-it-all post that talks about ‘events are ignored’, ‘teams are underfunded’, etc. I am trying to list very specific issues that negatively affect the IR team’s work & contribute to actual breaches actually happening (note: the ‘events are ignored’ is not a root cause; it is a result of problems that are rooted much deeper).

So, here it is – it’s obviously subjective so use at your own risk:

  • I think the fundamental problem is that the IR teams don’t hunt i.e. they don’t look at the data their organization generates: AV Alerts, Proxy traffic, DNS queries, etc.
    • IMHO apart from looking at the alerts generated by security controls this should be the major activity of any IR team
    • Triage should be a regular activity on every system; it sounds very difficult logistically, but at the end of the day all you need is something basic e.g. did any Run key change, did any application appear in the %APPDATA% – this can be surely automated company-wide with a few lines of scripting language; introducing such control requires a power of influence though [last point on the list below]
  • Instead:
    • They receive tones of emails daily – few hundreds emails a day is not uncommon with 90%+ being absolutely useless.
    • They receive a lot of ‘threat intel’ feeds which they have to often manually parse and incorporate into their own security controls – these are important, but will never be more important than analysis of the internal data generated by the org.
    • They spend too much time evaluating ‘new’ software from vendors; eventually they end up being beta testers of the software instead of looking at the data.
    • They are often bound by the same rules as all other employees: ironically, a hacker who can download and use any tool imaginable is being treated with dir, netstat, wmic; sometimes sysinternals tools (if they are allowed)
    • They are asked to socialize, network and participate in many corporate activities. The number of man hours wasted by endless meetings is incredible.
    • They are often managed by people w/o credentials to do the job – understanding IR requires skills from a large number of disciplines – unfortunately it is not uncommon for the managers to be typical corporate climbers who don’t have a passion for the job. They will also execute their little authority to bring you down if you happen to step on their toes.
    • They are not allowed to work from home (there are some organizations that allow it which is a huge benefit to the organization: working from home allows to use your home lab to analyze malware, research, access resources banned by corporate policies, freely network with others in the industry, it also allows you to really focus on analysis – this is probably the most important bit).
    • They work in the environment full of legacy applications. Old Java, enabled VBA is a major reason why infections happen – upgrading the environment should be really high on C-level folks’ agenda.
    • They are often trained to overestimate the remediation capabilities of security controls e.g. antivirus software (see my post).
    • They are often doing Project Management work deploying solutions instead of actually using them. I would argue one needs separate roles for tool builders and tool users in the successful IR team.
    • They rarely have a power to influence at the C-level. They end up whining with their peers in their cubicles and… nothing changes.

I don’t think breaches can be prevented 100%, as I argue in my other post every single infection detected by AV is a compromise. Same goes for network alerts. Giving IR team tools and time to deal with all of them is incredibly important so that these small fires can be extinguished quickly. And then give them even more time to hunt.

So…. If you want to establish a successful IR program in your org, give your IR team a power to shrug all the useless activities off, kill useless emails at source, train these guys as hell, give them a monitored access to all security controls and most importantly – let them be totally antisocial, but ensure their voice is heard at C-level.