Application Manager Basic Concepts and Troubleshooting

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

With the recent surge in End-Point security concerns and the ever increasing prevalence of Ransomware attacks, what better time to cover one of the most basic principles of Application Manager (AM) and how it can be used to mitigate these kind of threats. Additionally, I’ll add some context around the debug logs that can be used to understand what’s going on.
The one feature that really launched AM, and is still as important as now as it was all those years ago is Trusted Ownership. This fundamental aspect uses the NTFS owner on any requested file – if this is something you’re not familiar with, I would suggest having a read of the following article:

https://technet.microsoft.com/en-us/library/cc961992.aspx

There are, however, some points you really should know that are covered in the above article:

• Every object, whether it is in Active Directory or in an NTFS volume, has an owner, usually the user who created the object
• The default owner is normally an individual — the user who is currently logged on. The only exceptions occur when the user is a member of either the Administrators group or the Domain Admins group, in which case the Owner field contains the SID for the group, not the SID for the individual user account
• Owners of NTFS objects can allow another user to take ownership by giving that user Take Ownership permission
• Certain users can take ownership without having permission if they have been assigned the Take ownership of files or other objects (SeTakeOwnershipPrivilege) privilege. By default, this privilege is assigned only to the Administrators group
• A normal user has no option for giving ownership to another individual
• The operating system does not support a give ownership operation at any level - not in the user interface, not in application programming interfaces
• If you want to transfer ownership of an object, you must give another user permission to take ownership and then wait until the other user takes it

Note, for file and folder objects, you can see the ownership of several objects all at once. Open a command console, change to the directory in question, and then type DIR /Q.

Hopefully from the above, one thing is abundantly clear – users should NOT be a member of the local admins group, as every file they write to disk, be it a legitimate document, or an unscrupulous temp file created when opening an attachment, will be owned by local the Administrators group. In XP / 2003 you could change the default behaviour via GPO, but not so since those days…

To take advantage of this, you obviously need to have trusted ownership enabled in the AM config – additionally you can modify the default list of trusted owners if required:

There are circumstances where this may need to be relaxed, such as applications that have modules stored within the executable and get written to disk or compiled on-the-fly at execution time. In these cases, you may need to determine which process(es) exhibit this behaviour using AM Debug Logs, or a utility such as Process Monitor from Microsoft SysInternals.

When configuring such rules, always remember the following diagram, taken from the AM Product Guide in relation to Rule Matching Precedence (or processing order):

This is a top-down list of what accessible / prohibited item types take priority, and is based around how secure those items are – allowing anything in a specific folder is obviously less secure than allowing a specific file, which is less secure than allowing a specific signature (typically an MD5 or SHA-1 hash). For each given type, a rule that allows it takes higher priority than a rule that denies (prohibits) it.

In the case of an application that extracts and executes / loads temporary files, despite the names of these changing the actual binary typically doesn’t change – in this case taking a Digital Signature (hash) is the most secure solution, and is not affected by the NTFS owner, as the file ownership has no bearing on files’ hash, the downside to this approach, however, is updated versions may require new signatures to be taken. In my testing, AM takes around 50ms to hash a 9.5MB file so certainly not slow, but if you have many hefty applications on a busy terminal server it may be something you need to consider.

For each of the rule types (excluding the hash), trusted ownership can optionally be disabled – which carries with it an element of risk – how significant the risk is depends how far down the list above that you do it, and the scope of what that rule applies to – turning off trusted ownership checking for an entire drive should never be done, and even on a folder level should be avoided if it all possible. As for the scope, disabling this option within a single process rule, for example, is much more desirable than doing it for an entire AD Group (if you have absolutely have to use this approach) – personally I would use this as a testing step to get something working, and then start narrowing down what exactly is needed.

I’m not going to dive any further into the possible ways to configure AM, as that’s beyond the scope of this post, but what I will do (being a techie, after all), is get you started with some basic examples.

First off, you’ll need to install (at the very least), the AM Agent, an AM Config (this can just be a case of opening the console and exporting as-is to an MSI or AAMP file – the console has default settings that are always applied) and a license. To verify the most basic config and a license, try and run regedit as a non-admin user and it should be prohibited (its denied for normal users by default), or copy any executable file to anywhere as a non admin user – it will be denied due to trusted ownership when you try to run it.

If that doesn’t happen – check the Application Event Log for either Event ID 9095 (Application Manager cannot find a valid configuration, this may also be logged under Event 8095), or Event ID 9099 (Application Manager is not licensed).

First up I tried opening a dubious looking word document that made its way to my Outlook mailbox that claimed to be a sales order confirmation (no, I hadn’t ordered anything!).

Initially, before AM even had a chance to do anything, Windows Defender had already detected and blocked the attempt – the Windows Defender event log showed an Event 1116 (Windows Defender has detected malware – TrojanDownloader.O97M/Donoff)

I reverted the VM and turned off Windows Defender, since not everyone is using this (I am being a typical user, after all!). This time around Word opened and warned that attachments can contain viruses, so like any user I ignored this and clicked “Enable Editing”. To which I had to ignore another Security Warning and enable Macros (Enable Content). Yes, users really do ignore every possible warning from time to time!

At this point, I’ve ignored every possible warning (and there have been plenty!), and I get rewarded with this:

As you can see, whilst a standard AV product, and even Windows Defender on later OS’s, would detect a signature in the word document and prevent the user opening the file and subsequently quarantine it, AM takes a different approach, and when all else failed, it was there to keep me safe from my own actions! One difference you will notice, is that whilst Word (and the document) opens, when the embedded macro tries to write the vbe (encoded VBScript) to disk and execute it, the request is denied (the same would happen if it used .net to compile and run an executable, for the record!

Two points to note in the above in relation to the more traditional AV / Malware products:

Signature – Products typically rely on regular definition updates to detect “known” threats. AM does not look at the content of files, but simply determines if they are allowed to be executed, which has no need for definitions and/or updates.

Quarantine – Whilst AM isn’t an AV product as such, and doesn’t have a Quarantine feature, it does have Archiving, accessed via the Global Settings ribbon:

As a techie I find this very useful – not only for collecting sample files when (as mentioned earlier) figuring out what files a legitimate application may be trying to execute that are not admin-owned, but in this case, it also keeps a copy of the actual vbe file this document contained, rather than the word document that created it, but from the logs I know how it got there. I could also decode the .vbe to see exactly what it contains, if I really wanted to (and yes, I did – but I’m not putting example code on here for someone to use!).

On the topic of logs, below is an extract of some of the log entries related to this test – I’ve only shown some limited lines from this as they are somewhat verbose (note, AM has a number of options that would make files exempt from being passed through the normal rules processing, this is covered in greater detail in the product guide). The logs are in a number of phases:

• Phase 1 checks for any exemptions (ignore restrictions, disabled features etc)
• Phase 2 checks for Prohibited Media and script files (as you can prohibit the host process, but allow it to launch for certain scripts, if desired), and trusted ownership ~~~~~####
• Phase 3 checks for a matching signature – as mentioned above, this is the definitive way to allow/deny a file, and since the owner is irrelevant would not need to continue to evaluate further rules if matched). This phase then, if required, continues to check each matching (user/group/process/custom/device etc) rule, validating each in accordance with rules processing order above Signature > File > Folder > Drive
• Phase 4 checks for time limits and trusted vendors
• Phase 5 finally check for self-authorisation requests

In this case, the initial execute request is actually against the host program, in this case wscript, which was denied:

Phase II
T000820 367359 18:01:49.044 [CRulesChecker::LogProgress] File: wscript.exe, User: RK-W81-X64-02\StandardUser Check For Script File Program
T000820 367359 18:01:49.044 [CRulesChecker::DenyScriptFileProgram] Deny WSH program - AMMessage will check the script file
T000820 367359 18:01:49.044 [CRulesChecker::DoPhaseII] Phase II (Default Policy): rule=DenyScriptFileProgram result=deny - level 7
T000820 367359 18:01:49.044 [CRulesChecker::DoPhaseIV] No Phase IV conditions have been met, Deny the request

Phase III start
Looking for a matching user policy
Start all checks for policy name=[Everyone]
Check if policy specifies `exempt from rules`
Looking for a matching accessible signature in the policy
Looking for a matching prohibited signature in the policy
Looking for a matching accessible file in the policy
Looking for a matching prohibited file in the policy
Looking for a matching accessible folder in the policy
Looking for a matching prohibited folder in the policy
Looking for a matching accessible drive in the policy
Looking for a matching prohibited drive in the policy

Looking for a matching client policy
Looking for a matching process rule policy
Phase III end

Although Wscript was denied, the “validate scripts” option is enabled by default, which causes the script file itself to be run against the configuration:

T000820 367359 18:01:49.044 [CBaseScriptFileChecker::AreFilesAllowable] GetScriptSettings returned true, bValidateScripts = 1
T000820 367359 18:01:49.044 [CBaseScriptFileChecker::IsScriptFile] Command line - c:\windows\system32\wscript.exe "c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe"

T000820 367359 18:01:49.044 [CFilterData::Initialise] Start ProcessData initialise. Pid: 708, DeviceName: , FileName: c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe, TargetRunning: 0, ScriptHostFile: c:\windows\system32\wscript.exe

T000820 367359 18:01:49.044 [CRulesChecker::LogProgress] File: dsfsdfsdf.vbe, User: RK-W81-X64-02\StandardUser
Trusted Ownership Check

T000820 367359 18:01:49.044 [CAppV5Checker::FileIsAppV5Application] Testing [c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe] ...

T000820 367359 18:01:49.044 [CFileData::OwnerSid] [S-1-5-21-2879594171-1029399448-2302779852-1004] c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe
T000820 367359 18:01:49.044 [CRulesChecker::FileOwnerTrusted] File owner [RK-W81-X64-02\StandardUser] SID [S-1-5-21-2879594171-1029399448-2302779852-1004]

T000820 367359 18:01:49.044 [CRulesChecker::FileOwnerTrusted] File owner is not trusted
T000820 367359 18:01:49.044 [CRulesChecker::DoPhaseII] Phase II (Default Policy): rule=TrustedOwnership result=deny - level 16

T000820 367359 18:01:49.044 [CHookCreateProcessHandler::CompleteJob] HookCompleteRequest="RULE_DENY",Urm="URM_NOT_APPLIED",Dialog="URM_NOT_MANAGED",Time="11.391ms",h="0000000000000A98",AppName="c:\windows\system32\wscript.exe",CmdLine=""c:\windows\system32\wscript.exe" "c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe" ",UserReason="",ParentPID="708",ParentTID="1408",Slot="0",RequestType="Execute",Exists="Yes",AM="0x0",OrigPath="c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe",WorkPath="c:\users\standarduser\appdata\local\temp\dsfsdfsdf.vbe",Dev="\device\harddiskvolume4",FileName="dsfsdfsdf.vbe",FileExt="vbe",Hash="",Description="",OwnerSid="S-1-5-21-2879594171-1029399448-2302779852-1004",PID="708",SN="3",TID="1408",SystemProcess="No",Impersonating="No",ProcessPath="c:\program files\microsoft office\office15\winword.exe",LogonAUID="0-635592",ProcessSid="S-1-5-21-2879594171-1029399448-2302779852-1004",ThreadSid="",StartTime="30508333-3028335605",LogonStatus="LOGON_COMPLETE"

As you can see, the script was owned by the user, and hence untrusted and subsequently denied.

If you look at raw AM debug logs, they are quite daunting at first - to make life easy finding these log entries, I used an AmLogViewer tool I recently wrote as part of another piece of work – this is available via the support portal, and whilst not an official AppSense product, it does make log analysis a lot simpler – the log in this case was 75MB of plain text, but by simply filtering the log in this tool for “Result” = “Deny” and “Request Type” = “Execute”, I only had one event to view, to which you can right-click and view the logs:

To download this handy tool, visit: http://www.appsense.com/kb/160122112054776

Hopefully this has given you some background on Trusted Ownership, and how it can play a vital role in securing your environment when using Application Manager, and also a brief understanding of the rules processing order and how this is laid out in the debug logs.