• File Path: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Security.dll
  • Description: System.Security.dll
  • Comments: Flavor=Retail


Type Hash
MD5 20BAD6F39CB80482259347F3497597FC
SHA1 0B588D57F836C2F4D9B48B7DD26244A155A6EF6C
SHA256 EE27034A1E30F9A4EE5073115F060A3FAB04E194210A985EA113B5488F63D61D
SHA384 4D756AF8D19EE8754CB7524F9F505FABA75E82C108DEF0F67B2CE97A40B684B97103FFB330BC04943D30C4215ACB8894
SHA512 E57ABA1E8A2551C6CC0BD38DBAD1312AE55218CA2BBF2129037830C1D917F7EC59E87F8CB1D446D7255E306601813A763431CF1D3F9B5D37D5F677D06E301BEC
SSDEEP 1536:n42g9f3tgBHMcT0uXFCBuPxKQRvXDzVsSOfHZUztd8bO515yufqNxR2n:n42gl37mxKQRvXDzVsSOfHZUztd8bO5h
IMP DAE02F32A21E03CE65412F6E56942DAA
PESHA1 465552BB8BEC916392EC3B4EFE17C6F5CB39396B
PE256 2304E71A338112724DED8D5865E568F9990630E6CF8EBC964FFCCBDC361BDC87


  • Status: Signature verified.
  • Serial: 33000001519E8D8F4071A30E41000000000151
  • Thumbprint: 62009AAABDAE749FD47D19150958329BF6FF4B34
  • Issuer: CN=Microsoft Code Signing PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
  • Subject: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

File Metadata

  • Original Filename: System.Security.dll
  • Product Name: Microsoft .NET Framework
  • Company Name: Microsoft Corporation
  • File Version: 4.8.4084.0 built by: NET48REL1
  • Product Version: 4.8.4084.0
  • Language: English (United States)
  • Legal Copyright: Microsoft Corporation. All rights reserved.
  • Machine Type: 32-bit

File Scan

  • VirusTotal Detections: 0/76
  • VirusTotal Link:

Possible Misuse

The following table contains possible examples of System.Security.dll being misused. While System.Security.dll is not inherently malicious, its legitimate functionality can be abused for malicious purposes.

Source Source File Example License
malware-ioc misp_invisimole.json "description": "Windows User Account Control (UAC) allows a program to elevate its privileges to perform a task under administrator-level permissions by prompting the user for confirmation. The impact to the user ranges from denying the operation under high enforcement to allowing the user to perform the action if they are in the local administrators group and click through the prompt or allowing them to enter an administrator password to complete the action. (Citation: TechNet How UAC Works)\n\nIf the UAC protection level of a computer is set to anything but the highest level, certain Windows programs are allowed to elevate privileges or execute some elevated COM objects without prompting the user through the UAC notification box. (Citation: TechNet Inside UAC) (Citation: MSDN COM Elevation) An example of this is use of rundll32.exe to load a specifically crafted DLL which loads an auto-elevated COM object and performs a file operation in a protected directory which would typically require elevated access. Malicious software may also be injected into a trusted process to gain elevated privileges without prompting a user. (Citation: Davidson Windows) Adversaries can use these techniques to elevate privileges to administrator if the target process is unprotected.\n\nMany methods have been discovered to bypass UAC. The Github readme page for UACMe contains an extensive list of methods (Citation: Github UACMe) that have been discovered and implemented within UACMe, but may not be a comprehensive list of bypasses. Additional bypass methods are regularly discovered and some used in the wild, such as:\n\n* <code>eventvwr.exe</code> can auto-elevate and execute a specified binary or script. (Citation: enigma0x3 Fileless UAC Bypass) (Citation: Fortinet Fareit)\n\nAnother bypass is possible through some Lateral Movement techniques if credentials for an account with administrator privileges are known, since UAC is a single system security mechanism, and the privilege or integrity of a process running on one system will be unknown on lateral systems and default to high integrity. (Citation: SANS UAC Bypass)", © ESET 2014-2018
malware-ioc misp_invisimole.json "description": "Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token. For example, Microsoft promotes the use of access tokens as a security best practice. Administrators should log in as a standard user but run their tools with administrator privileges using the built-in access token manipulation command <code>runas</code>.(Citation: Microsoft runas)\n \nAdversaries may use access tokens to operate under a different user or system security context to perform actions and evade detection. An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.(Citation: Pentestlab Token Manipulation)\n\nAccess tokens can be leveraged by adversaries through three methods:(Citation: BlackHat Atkinson Winchester Token Manipulation)\n\n**Token Impersonation/Theft** - An adversary creates a new access token that duplicates an existing token using <code>DuplicateToken(Ex)</code>. The token can then be used with <code>ImpersonateLoggedOnUser</code> to allow the calling thread to impersonate a logged on user's security context, or with <code>SetThreadToken</code> to assign the impersonated token to a thread. This is useful for when the target user has a non-network logon session on the system.\n\n**Create Process with a Token** - An adversary creates a new access token with <code>DuplicateToken(Ex)</code> and uses it with <code>CreateProcessWithTokenW</code> to create a new process running under the security context of the impersonated user. This is useful for creating a new process under the security context of a different user.\n\n**Make and Impersonate Token** - An adversary has a username and password but the user is not logged onto the system. The adversary can then create a logon session for the user using the <code>LogonUser</code> function. The function will return a copy of the new session's access token and the adversary can use <code>SetThreadToken</code> to assign the token to a thread.\n\nAny standard user can use the <code>runas</code> command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account.\n\nMetasploit’s Meterpreter payload allows arbitrary token manipulation and uses token impersonation to escalate privileges.(Citation: Metasploit access token) The Cobalt Strike beacon payload allows arbitrary token impersonation and can also create tokens. (Citation: Cobalt Strike Access Token)", © ESET 2014-2018
atomic-red-team Another bypass is possible through some lateral movement techniques if credentials for an account with administrator privileges are known, since UAC is a single system security mechanism, and the privilege or integrity of a process running on one system will be unknown on remote systems and default to high integrity.(Citation: SANS UAC Bypass)</blockquote> MIT License. © 2018 Red Canary
signature-base apt_solarwinds_sunburst.yar $ss4 = “[]::getcurrent().name” ascii nocase wide CC BY-NC 4.0
signature-base cn_pentestset_tools.yar $s0 = “cl -eventlog All/Application/System/Security” fullword ascii /* PEStudio Blacklist: strings */ CC BY-NC 4.0

MIT License. Copyright (c) 2020 Strontic.