Threat Models: Malicious Admin

In this model, we'll examine the most challenging security scenario for any organization: dealing with an internal administrator who has gone rogue. Given its nature, this threat is notoriously hard to defend against, identify, and conclusively eliminate.

The level of risk your company faces from a malicious administrator can vary based on your industry and operations. The reasons behind an administrator turning malicious are multifaceted, ranging from personal grievances with management or ethical conflicts with the company's strategy to external pressures (coercive or incentivized) from nation-states or organized crime.

In this model, we will focus on an unsettling scenario where the target is the consumer users’ cryptocurrency private keys housed in vulnerable Hot Wallets.

The Anatomy of the Attack

As in the previous post in the series, we will employ the comprehensive Mitre Att&ck framework to guide us. As the prize in this model is crypto assets, we have added a layer covering the Tactics, Techniques, and Protocols (TTPs) operated by the Lazarus Group, notorious for targeting financial systems and crypto assets.

Ref: - Lazarus Enterprize Compromise Att&ck Layer

The journey to unauthorized data exfiltration often begins with compromising valid accounts. For our scenario, we will consider this to be the rogue administrator, who already has full access.

The Threat Actor:

Coercing an administrator through incentives or threats is considered a sophisticated threat. This is because it involves not just technical skills but also social engineering and psychological manipulation, often requiring a deep understanding of human behavior, organizational dynamics, and possibly even the target's personal life. Additionally, such a threat usually involves multiple layers of planning and execution, including surveillance, blackmail, and sometimes even physical coercion, making it complex and challenging to defend against.

For this scenario, however, we will consider the situation where a person has been planted with the specific motivation of stealing cryptocurrency from day 1. They will do their best to act stealthily to reduce the likelihood of being identified as malicious.

Threats:

• Data theft (database contents exfiltrated)
• System Destruction (evade detection)
• Service disruption (ransomware)
• Malware installation

Vulnerabilities:

• Unmanaged privileged access/absence of a well-configured PAM
• Inadequate logging and monitoring
• Insecure configuration (overly permissive Ports / IAM roles/internet accessible storage systems)
• Insecure credentials storage
• Sensitive information is not encrypted at a field level

Attack Vectors:

Unfortunately, with the malicious administrator model - many of the initial defenses we use to prevent an external attack are already defeated. Identifying an ongoing attack is tricky as, typically, the administrator “will live off the land.” If their duties include administration of databases and cloud infrastructure, an anomaly detection system may have difficulty identifying any malicious activity. Even if it does, there may be a higher likelihood of a SOC dismissing the alert as a false positive again if it looks like normal administrator behavior.

Effective Mitigations:

Mitigating the insider threat can be extremely costly, and many organizations simply accept a level of trust must be placed with the administrator and the level of risk that comes with it.

From the outset and within the bounds of local legislation, background checks should be performed on all staff with access to sensitive information, particularly administrators.  This could range from criminal records to financial background checks. In-depth background checks are relatively typical in the US and UK; however, in places like Ireland, background checks are often limited to previous employer, education, and reference checks, with exceptions, for example, where a person is working with children.

The other method for managing insider threat risk is adopting the “crown jewels” approach. Again, some risk is eaten in this model, but a highly robust set of controls is implemented around a specific system compared to the rest of the network. Controls often include:

• Privileged access management solution - with just enough and just in time access
• Rigorous change control and dedicated deployment infrastructure
• Host-based and network-based intrusion detection and prevention with advanced logging, monitoring, and alerting
• Endpoint detection and response
• Patched, hardened, and continuously vulnerability-scanned systems
• Secure software development and engineering practices
• High-resilient architecture with dedicated, encrypted backups
• Web application firewall (if externally facing)
• Network segmentation and isolation (highly constrained network access inbound and outbound)
• Dedicated jump servers, privileged access workstations with hardware mfa
• Field-level encryption with segregated keys, limited to dedicated (separate) administrators.
• Dedicated trusted execution environments with code attestation to maintain assurance that code from the pipeline is as expected in production
• Multi-party compute for transaction signing
• Optionality for offline cold wallets

This concludes our threat modeling series; I hope it has helped you keep your organization secure.

For a deeper dive into Trusted Execution Environments in the Cloud or insights into our Cryptographic SaaS offering, you can contact our expert team.