Beyond good ol’ Run key, Part 46

September 24, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

A persistent mechanism that requires a user interaction is probably deemed to fail, but there is still some potential here (I described some functionality like this before) and that’s why I am going to talk about yet another little trick like this here…

Every once in a while Windows needs to tell the user about something important. The standard way to do it is through these annoying balloons at the bottom of the tray’s area (or system area, or whatever they call it nowadays – this changes all the time). One of the first examples of such ‘important’ notification was the Tour in Windows XP. Anytime you install XP from the scratch, or add a new user and that user logs on, the annoying balloon immediately shows up:

tourThe balloons like this are created using the IUserNotification interface. Clicking the ‘cloud’ area executes a program that is associated with the balloon. And this this is the interactivity part I mentioned. The user needs to click the thing to launch the application associated with the message.

Now that we know how the interactive part works, let’s explore the persistence bit.

Windows uses a mechanism called PostBootReminder to preserve a list of important notifications that system will show after the reboot. The name is misleading as these notifications are user-related and stored in the user’s Registry hive. So it’s not really Post Boot, but when Shell is loaded. One just needs to log off and log on again and the thingie will trigger.

Adding PostBootReminder entries is relatively easy. The below reg file is a simple example of such notification:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\PostBootReminders\Malware]
"Title"="Malwaretest"
"Text"="Yet another lame persistence mechanism-wannabe..."
"ToolTip"="Hello World!"
"ShellExecute"="c:\\windows\\system32\\calc.exe"
"IconResource"="%SystemRoot%\\\\system32\\\\shell32.dll,-16783"
"ShowTime"=dword:00803600
"RetryInterval"=dword:0000060
"RetryCount"=dword:00000060
"TypeFlags"=dword:00000000

As we can see, the entries are stored under the HKCU key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\PostBootReminders\<name>

Once the system reads and creates the notification, it deletes the entry. So, in some way it works like a RunOnce key.

The Tour application that is being executed by Windows XP is scheduled the same way, except it is added not prior to reboot/log off, but when Windows Explorer starts. There is a Registry entry:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Applets\Tour\RunCount

that dictates whether the Tour app will get scheduled via PostBootReminders mechanism.

This is obviously a bit of an archaeologic trivia, but I can mention that the name of that PostBootReminders entry is ‘Microsoft.OfferTour’. Of course, being clever reader as you are, you will surely notice that the Tour Registry key, together with a replacement of the Tour program executable (tourstart.exe) could work as a nice persistence mechanism as well (back when replacing files in system32 was easier).

Another trivia to add: there is one more fake PostBootReminders  entry added by Windows Explorer on Windows XP. It is called ‘Microsoft.FixScreenResolution’

displaysettings

and is supposed to help fixing the screen resolution. This entry is controlled by the following Registry key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain\ScreenCheck

The conditions when it is launched are a bit more complex than just a presence/value of the Registry entry and are described in detail here.

Going back to the future – Windows 10 continues to use the very same mechanism. The known PostBootReminders  entries include:

  • Microsoft.AuditingLogIsFull
  • Microsoft.CachedLogon
  • Microsoft.KerbCredentialsExpired
  • Microsoft.LogoffWarning
  • Microsoft.LogonHoursWarning
  • Microsoft.NetDriveReconnectFailed
  • Microsoft.PasswordExpiryWarning
  • Microsoft.SmartCardUnlockRequired
  • Microsoft.SubscriberFailed
  • ProfileError

Going back to the .reg example I posted above – the arguments of the PostBootReminders subkey are passed directly to methods of IUserNotification interface, so their explanation can be easily found by exploring the Microsoft site: Title, Text and TypeFlags, RetryInterval, RetryCount, ShowTime, IconResource, ToolTip. The ShellExecute is just a path to the executable. It is worth mentioning that there is also one more entry that can be added – CLSID – this represents the GUID of the class that will be instantiated if present, but I have not explored it yet and not sure how it works.

As I mentioned, I doubt this thing can fly, but who knows… one could annoy the user, by making the message never go away (hint: RetryCount/RetryInterval), until clicked – same as on the animation below 🙂 [you may need to click to watch]

 

postbootrmeinderloop

rEDRoviruses – Whether you’re a AV or whether you’re a EDR, You’re stayin’ alive, stayin’ alive…

September 19, 2016 in Anti-*, EDR

EDR software is so hot right now. While AV is mainly focused on badness and silent detections/reputation analysis, the EDR solutions log everything. Sooner or later this ‘everything’ will cause trouble to bad guys and they will act on it. Interestingly, while killing AV doesn’t make that much sense (because it’s so afraid of triggering FPs), the nature and immaturity of EDR (and associated with it an omnipresent problem of dead agents) makes it actually a very easy target…

Such kill-EDR, or at least anti-EDR , or perhaps even just detect-EDR (which already exists) techniques are also important to offensive teams that will surely want to know about the EDR presence and … will try their best to bypass/avoid it…

It’s also important to remember that discussion of anti-EDR is very important for another reason. Most of AV is using anti-tampering technologies that prevent AV from being well… tampered with. EDR should follow these steps closely – otherwise, well… they will be tampered with too. And fundamentally, the more protection and attention is given to the security of EDR – the better. Think of the Project Zero blog that excels in killing bugs in a variety of software ranges – I don’t see any reason why they shouldn’t give it a try with EDR software…

The following is a bunch of ideas that EDR vendors should look into to protect themselves against being shut down:

  • Blocking via Software Restriction Policies
  • Blocking via AppLocker
  • Blocking via Image File Execution Options
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
  • Stopping or blocking WMI
    • Many agentless solutions relying on WMI may stop working
  • Disabling Windows Script Host (and VBS/JS) f.ex. via
    • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
    • HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled
      • solutions using visual basic script will stop working – EDR relying on such a single Registry setting needs to ensure this setting is restored prior to execution of every script
  • Disabling the Powershell
  • Changing ACLs to directories/Registry entries
    • Potentially preventing log writing, config updates, etc.
  • Modification of hosts files
    • Same old, same old…
  • Stopping/disabling services
    • I won’t list service names, but they are easy to find
  • Analysis of kernel drivers of EDR solutions may help in finding new ways to escalate privileges