Intro

Attacks on cloud infrastructure have been steadily increasing in quantity, sophistication and scope. Common cryptomining attacks still exists, but the proliferation of BEC (Business Email Compromise) and SMS spamming along with full-bore ransomware and data theft is on the rise. This rise coincides with an increase in offensive toolkits and open-source scripts targeting cloud services.

Detecting the usage of these scripts requires a thoughtful understanding of the APIs involved in these attacks. Identifying attacks that are underway involves tooling for correlating multiple groupings of APIs in corresponding cloud logs. From a threat intel and campaign-tracking perspective, these same groupings of APIs can be identified in the attack frameworks for both open-source tools and closed-source tools that are uploaded to file repositories (e.g. VirusTotal). However, the multi-step translation process involving original API names translated into various differing SDK syntaxes and finally converted to numerous detection languages is a manual, time-consuming and error-prone process - until now.

Introducing CAPICHE Detection Framework

CAPICHE Detection Framework (Cloud API Conversion Helper Express) is an open-source tool designed to simplify each step of cloud API detection translation pipeline, enabling any defender to instantly create numerous styles of detection rules from groupings of APIs (even if the complete API names are not initially known!). With this framework defenders are one command away from dynamically assembling multiple sets of cloud APIs (e.g. one set of APIs related to IAM Policy modifications/assignments and another set of APIs related to IAM User/Group/Role assignments), translating these API names into their SDK-specific counterparts (e.g. the CreateAccessKey API is translated to create-access-key for AWS CLI usage but create_access_key for Boto3 usage) and then generating any number of final detection rule formats (e.g. YARA, YARA-L, Sigma, VirusTotal VTGrep content searching, Google Dorking).

Key Features

Cloud Related:

Compatible with AWS cloud provider.

Development: Created in Python programming language and easy to use.

API Related:

Translation of APIs into their SDK specific counterparts.

Usability:

Easy to use regular expressions for searching APIs based in name or description.

Detection:

Different styles of final detection rule formats from groupings of APIs.

Final Formats:

YARA, YARA-L, Sigma, VirusTotal VTGrep content searching and Google Dorking.

How CAPICHE Detection Framework works

CAPICHE has several python scripts for each process starting from the translation of APIs based in the desired patterns and specified SDK. Each step can be executed interactively in python so that the results for the user are more comprehensive and more usable. In this method, there can be several results with many combinations for each final detection format.

There is a default JSON file for all the APIs in AWS, so based in patterns given from the user, there will be a correct translation for the eventSource and eventName with descriptions for each API.

Steps of execution:

• Load the API data list as a JSON file
• Search for any API by name or description by regular expressions
• Specify the SDK, so there can be different translation for each part of the APIs
• Translation of APIs for different contents
• Generate strings from these translated APIs, so they can be used for each detection format, especially for YARA rules.
• Generated strings for different variable prefixes, get together and create the YARA rule.
• Generate the content for VirusTotal as VTgrep content for all these strings desired and also the header part.
• Generate the content for Google Dorking syntax.
• Create sigma rules for specified patterns and userAgent content.
• Define events and associations as the last step for YARA-L rules.

Usage Examples

Example #1: Creating the YARA rule for all the APIs where the User related APIs have the search pattern for name '^(account|secrets.*):put’ and SDK as ‘boto’, while Policy related APIs have the search pattern for description '(create).policy','secrets|secretsman.’ and SDK as ‘awscli’

matched_names = search_api_name(api_data, '^(account|secrets.):put')
matched_descriptions = search_api_description(api_data, '(create).policy','secrets|secretsman.')
api_user = transform_api_list(api_data, "boto", matched_names)
api_pol = transform_api_list(api_data, "awscli", matched_descriptions)
yara_strings_user = generate_yara_string(api_data,api_user['APIListTransformed'], "user", "wide ascii", "User-focused APIs", True)
yara_strings_pol = generate_yara_string(api_data,api_pol['APIListTransformed'], "pol", "wide ascii", "Policy-focused APIs", True)
final_yara_rule = generate_yara_rule("UserPolicy", "CAPICHE", "Users and Policies",yara_strings_user + yara_strings_pol, "((any of $user) and (any of $pol*))",[{"hash": "1234567890"}])
print(final_yara_rule) 

Output:

rule UserPolicy
{
meta:
author = "CAPICHE"
description = "Users and Policies"
hash = "1234567890"
strings:
$user_01 = "put_alternate_contact" wide ascii // User-focused APIs - API Description: Modifies the specified alternate contact attached to an Amazon Web Services account
$user_02 = "put_contact_information" wide ascii // User-focused APIs - API Description: Updates the primary contact information of an Amazon Web Services account
$user_03 = "put_resource_policy" wide ascii // User-focused APIs - API Description: Attaches a resource-based permission policy to a secret
$user_04 = "put_secret_value" wide ascii // User-focused APIs - API Description: Creates a new version with a new encrypted secret value and attaches it to the secret
$pol_01 = "put-lifecycle-policy" wide ascii // Policy-focused APIs - API Description: Creates or updates the lifecycle policy for the specified repository
$pol_02 = "put-registry-policy" wide ascii // Policy-focused APIs - API Description: Creates or updates the permissions policy for your registry
condition:
((any of $user*) and (any of $pol*))
}

Example #2: Creating the VTgrep content for the same strings as above and header as ‘’import boto3’.

vt_syntax = generate_vtgrep_content("import boto3") + " AND (" + generate_vtgrep_content(yara_strings_user, "OR") + " AND " + generate_vtgrep_content(yara_strings_pol, "OR") + ")"
print(vt_syntax)

Output:

content:"import boto3" AND ((content:"put_alternate_contact" OR content:"put_contact_information" OR content:"put_resource_policy" OR content:"put_secret_value") AND (content:"put-lifecycle-policy" OR content:"put-registry-policy"))

Conclusion

Permiso Security is continually hard at work to show our customers the most important activity across all of their identity and cloud environments, always linking the context of the originating identity (human or non-human). We hope CAPICHE enables security practitioners to improve their detection, hunting and labeling capabilities by simplifying the cloud API identification, translation and detection generation process. Don’t let your detection ideas get lost in translation, capiche?

You can access CAPICHE on GitHub: https://github.com/Permiso-io-tools/capiche