Home > CAPEC List > CAPEC-205: Lifting credential(s)/key material embedded in client distributions (thick or thin) (Version 2.9)  

CAPEC-205: Lifting credential(s)/key material embedded in client distributions (thick or thin)

Lifting credential(s)/key material embedded in client distributions (thick or thin)
Definition in a New Window Definition in a New Window
Attack Pattern ID: 205
Abstraction: Detailed
Status: Deprecated
Completeness: Complete
Presentation Filter:
+ Summary

An attacker examines a target application's code or configuration files to find credential or key material that has been embedded within the application or its files. Many services require authentication with their users for the various purposes including billing, access control or attribution. Some client applications store the user's authentication credentials or keys to accelerate the login process. Some clients may have built-in keys or credentials (in which case the server is authenticating with the client, rather than the user). If the attacker is able to locate where this information is stored, they may be able to retrieve these credentials. The attacker could then use these stolen credentials to impersonate the user or client, respectively, in interactions with the service or use stolen keys to eavesdrop on nominally secure communications between the client and server.

+ Attack Execution Flow
  1. Identify Target:

    Attacker identifies client components to extract information from. These may be configuration files, local databases, binary executables, class files, shared libraries (e.g., DLLs), or other machine code.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments

    Binary file extraction. The attacker extracts binary files from zips, jars, wars, PDFs or other composite formats.

    env-Local env-Embedded env-ClientServer env-Peer2Peer

    Package listing. The attacker uses a package manifest provided with the software installer, or the file system itself, to identify component files suitable for attack.

    env-Local env-Embedded env-ClientServer env-Peer2Peer


    IDTypeIndicator DescriptionEnvironments

    Proprietary or sensitive data is stored in a location ultimately distributed to end users.

    env-Local env-Embedded env-ClientServer env-Peer2Peer

    No sensitive data seems to be stored in the user's client. The storage could be done after the first authentication or execution of the thick client.

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Access to binary code is not realistic. For example, in a client-server environment, binary code on the server is presumed to be inscrutable to an attacker unless another vulnerability exposes it.

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol


    IDTypeOutcome Description
    The attacker identifies one or more files or data in the software that might store credentials information.

    Security Controls

    IDTypeSecurity Control Description
    Obfuscation, anti-debugging, packing can make the observation and reverse engineering more difficult. It is only capable of delaying an attacker, however, not preventing a sufficiently motivated and resourced one.
  1. Apply mining techniques:

    The attacker then uses a variety of techniques, such as monitoring, sniffing, reverse-engineering, cryptanalysis to extract the sensitive information and its associated use by the application.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments

    API Profiling. The attacker monitors the software's use of registry keys or other storage locations that can contain sensitive information.

    env-Local env-Embedded env-ClientServer env-Peer2Peer

    Execution in debugger. The attacker attaches a debugger to the application to monitor authentication process and retrieve important application steps (reverse algorithms) along system calls, network communication, etc.

    env-Local env-Embedded

    Cryptanalysis. The attacker performs cryptanalysis to identify data in the client component which may be cryptographically significant. (Key material frequently stands out as very high entropy data when compared to other mundane data). Given cryptographically significant data, other analyses are performed (e.g., length, internal structure, etc.) to determine potential algorithms (RSA, ECC, AES, etc.). This process proceeds until the attacker reaches a conclusion about the significance and use of the data.

    env-Local env-Embedded env-ClientServer env-Peer2Peer


    IDTypeIndicator DescriptionEnvironments

    Sensitive credentials data are used and embedded inside the client-accessible artifacts.

    env-Local env-Embedded env-ClientServer env-Peer2Peer


    IDTypeOutcome Description
    The attacker extracts credentials related information.
+ Attack Prerequisites
  • The target application must save keys or credential information. Many applications allow users to store authentication information as an option.

+ Typical Severity


+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Analysis
+ Examples-Instances


The Java client program for the ATEN KH1516i IP KVM switch with firmware 1.0.063 and the KN9116 IP KVM switch with firmware 1.1.104 has a hardcoded AES encryption key, which makes it easier for man-in-the-middle attackers to (1) execute arbitrary Java code, or (2) gain access to machines connected to the switch, by hijacking a session. CVE Reference CVE-2009-1472

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Low

To extract sensitive data from configuration files, system registry, local databases, etc.

Skill or Knowledge Level: High

To reverse engineer an application flow to retrieve credentials

+ Resources Required

The attacker must be able to reach the target application's code or configuration files. This may require prior access to the machine on which the target application runs. Authentication information is often encoded or encrypted, but this might not require significant attacker resources to compromise.

+ Solutions and Mitigations

Design: When possible, don't store credentials information on the client side

Implementation: Don't store clear text or obfuscated credential information (or cryptographic keys) on the client side; use strong encryption to store any credentials related information

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Modify files or directories
Read files or directories
Modify application data
Read application data
Execute unauthorized code or commands
Run Arbitrary Code
Gain privileges / assume identity
Bypass protection mechanism
+ Purposes
  • Reconnaissance
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ Content History
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
CAPEC Content TeamThe MITRE Corporation2015-11-09Updated Related_Attack_PatternsInternal

More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 07, 2015