Explore AWS STS AssumeRoot, its risks, detection strategies, and practical scenarios to secure against privilege escalation and account compromise using Elastic's SIEM and CloudTrail data.

Preamble

Understanding AWS STS and the AssumeRoot API

Introduction to AssumeRoot

What Are Member Accounts?

How Does AssumeRoot Work?

Potential Abuse of Task Policies

AssumeRoot in Action

Member Account Creation

Environment Setup

Establish an STS Client Session with Stolen Credentials

Assume Root for Member Account on Behalf of Compromised User

Creating a Login Profile for the Member Root Account

Reset the Administrator Password and Login to the AWS Console

Detection and Hunting Opportunities

Hunting \- Unusual Action for IAM User Access Key

Detection \- Unusual Assume Root Action by Rare IAM User

Detection \- Self-Created Login Profile for Root Member Account

Hardening Practices for AssumeRoot Use

AssumeRoot Abuse and Detection Strategies in AWS Organizations

Exploring AWS STS AssumeRoot

Elastic is releasing a threat hunting package designed to aid defenders with proactive detection queries to identify actor-agnostic intrusions.

Why Threat Hunting?

What We Are Providing

Hunting Package

Benefits of these Hunt Queries

Details of Each Hunting Analytic

Hunting Query Creation Example:

How We Plan to Expand

Get Involved

Conclusion

Elevate Your Threat Hunting with Elastic

Elastic Security Labs discusses detection and mitigation strategies for vulnerabilities in the CUPS printing system, which allow unauthenticated attackers to exploit the system via IPP and mDNS, resulting in remote code execution (RCE) on UNIX-based systems such as Linux, macOS, BSDs, ChromeOS, and Solaris.

Update October 2, 2024

Key takeaways

The CUPS RCE at a glance

Elastic’s POC analysis

Executing the ‘Cupshax’ POC

Assessing impact

Remediations

Elastic protections

cupsd or foomatic-rip shell execution

Printer user (lp) shell execution

Network connection by CUPS foomatic-rip child

File creation by CUPS foomatic-rip child

Suspicious execution from foomatic-rip or cupsd parent

Elastic’s Attack Discovery

Key References

Cups Overflow: When your printer spills more than Ink

Using this maturity model, security teams can make structured, measurable, and iteritive improvements to their detection engineering teams..

Detection Engineering Behavior Maturity Model

What is a threat detection ruleset?

Why ruleset maturity is important

Understanding the DEBMM Structure

Tiers

Criteria and Levels

Scope of Effort to Move from Basic to Expert

Tier 0: Foundation 

Criteria

Structured Approach to Rule Development and Management

Creation and Maintenance of Detection Rules

Roadmap Documented or Planned

Threat Modeling Performed

Tier 1: Basic

Managing and Maintaining Rulesets

Improving and Maintaining Telemetry Quality

Reviewing Threat Landscape Changes

Driving the Feature with Product Owners

End-to-End Release Testing and Validation

Tier 2: Intermediate

Continuously Tuning and Reducing False Positives (FP)

Understanding and Documenting Gaps

Testing and Validation (Internal)

Tier 3: Advanced

Triaging False Negatives (FN)

External Validation

Advanced TTP Coverage

Tier 4: Expert

Hunting in Telemetry/Internal Data

Continuous Improvement and Potential Enhancements

Applying the DEBMM to Understand Maturity

Grouping Criteria for Targeted Improvement

Appendix

Example Rule Metadata 

Example Questionnaire

1. Identify Threat Landscape

2. Define the Perfect Rule

3. Define the Perfect Ruleset

4. Maintain

5. Test & Release

6. Criteria Assessment

7. Iterate

Improving detection engineering with Elastic's DEBMM.

Elastic releases the Detection Engineering Behavior Maturity Model

This article describes our analysis of the top malware stealer families, unveiling their operation methodologies, recent updates, and configurations. By understanding the modus operandi of each family, we better comprehend the magnitude of their impact and can fortify our defences accordingly.

Introduction

Telemetry overview

Top stealers overview

REDLINE (REDLINE STEALER)

METASTEALER

STEALC

STEALC - Execution flow

Detection

ES|QL queries

Yara rules

Globally distributed stealers

Elastic Security Labs has identified REF4578, an intrusion set incorporating several malicious modules and leveraging vulnerable drivers to disable known security solutions (EDRs) for crypto mining.

Code analysis 

GHOSTENGINE

GHOSTENGINE modules

EDR agent controller and miner module: smartsscreen.exe

Update/Persistence module: oci.dll

EDR agent termination module: `kill.png`

Powershell backdoor module: `backup.png`

Miner configuration

Monero Payment ID

Malware and MITRE ATT&CK

Tactics

Techniques

Mitigating GHOSTENGINE

Prevention

YARA

Observations

References

Invisible miners: unveiling GHOSTENGINE’s crypto mining operations

This article guides readers through establishing an Okta threat detection lab, emphasizing the importance of securing SaaS platforms like Okta. It details creating a lab environment with the Elastic Stack, integrating SIEM solutions, and Okta.

Prerequisites

Sign up for Okta Workforce Identity

Setting up your free cloud stack

Setup Fleet from the Security Solution

Create an Okta policy

Setup the Okta integration

Install the Elastic Agent on an endpoint

Create an Okta token

Add Okta integration requirements

Enable Okta detection rules

Let’s trigger a pre-built rule

Let’s trigger a custom rule

Bonus: synchronize Active Directory (AD)

Additional considerations

Takeaways

Setup a detection engineering lab for Okta

Monitoring Okta threats with Elastic Security

This article delves into Okta's architecture and services, laying a solid foundation for threat research and detection engineering. Essential reading for those aiming to master threat hunting and detection in Okta environments.

Overview of core services

Integration capabilities

Customization and management

Integration with external directories

Structure and design

API Security

OAuth 2.0 and OIDC implementation

RESTful API and CRUD

SCIM

Access policies

Session initialization and authentication:

Tokens vs cookies:

Single sign-on (SSO):

Session termination:

Application sessions and additional controls:

OAuth 2.0 and OIDC protocols

High-level overview of OAuth

High-level overview of OIDC

Authorization code flow

Step 1 - Initial authorization request:

Step 2 - User authentication and consent:

Step 3 - Authorization code reception:

Step 4 - Redirect URIs and client authentication

Step 5 - Token exchange

Access tokens and scopes

Composition of an access token:

Scopes and permissions:

Token lifespan and refresh tokens:

Token storage:

Security and expiration:

Authentication vs authorization

SAML in authentication

IdP vs SP responsibilities

Single-factor vs multi-factor authentication

Client-side and server-side communications

An introduction for security analysts

Starter guide to understanding Okta

This article explains how we conduct comprehensive cyber threat data analysis using Google Cloud, from data extraction and preprocessing to trend analysis and presentation. It emphasizes the value of BigQuery, Python, and Google Sheets - showcasing how to refine and visualize data for insightful cybersecurity analysis.

作者

Terrance DeJesus

文章

探索 AWS STS AssumeRoot

使用 Elastic 提升您的威胁狩猎能力

CUPS 溢出：当您的打印机溢出的不止是墨水

Elastic 发布检测工程行为成熟度模型

全球分布式窃密器

隐形矿工：揭秘 GHOSTENGINE 的加密货币挖矿操作

使用 Elastic Security 监控 Okta 威胁

了解 Okta 入门指南

用于网络数据分析的 Google Cloud

Google Workspace 攻击面

Google Workspace 攻击面