detection

February 24, 2026
in detection
10 min read

Security Audit Report — SOC Automation Platform

Date: February 24, 2026 Scope: Full source code review — API, Auth, Orchestrator, Infrastructure as Code, CI/CD Method: Static analysis of all source code on the development branch Classification: Confidential

Executive Summary

This audit covered the entire SOC automation platform: two Python microservices (infrastructure API and authentication service), a CLI orchestrator, all Infrastructure as Code (Terraform, Ansible, Packer), and CI/CD pipelines.

59 vulnerabilities were identified, including 8 critical and 13 high-severity findings requiring immediate remediation.

Severity	Count
CRITICAL	8
HIGH	13
MEDIUM	18
LOW	12
INFO	8

Key Risk Categories

Hardcoded secrets in version-controlled files (passwords, keys, API tokens)
Permissive CORS configuration with credentials on both web services
Insecure default values allowing startup without proper configuration
Vulnerable JWT dependency with known CVEs
Critical endpoints missing authentication

1. Critical Vulnerabilities

1.1 — Permissive CORS with Credentials on Both Services

Field	Value
Severity	CRITICAL
Components	API (`main.py`), Auth (`main.py`)
CWE	CWE-942 — Overly Permissive Cross-domain Whitelist

Description: Both FastAPI services configure CORS with allow_origins=["*"] combined with allow_credentials=True. This combination allows any malicious website to make authenticated cross-origin requests on behalf of a legitimate user.

Starlette/FastAPI, when configured this way, reflects the caller's origin rather than returning *, effectively making every origin trusted — which is worse than a simple wildcard.

Impact: An attacker hosting a malicious page can trigger infrastructure deployment/destruction operations on behalf of any authenticated user who visits that page. Given the destructive nature of the API (VM creation, deletion, reconfiguration), this represents a full infrastructure compromise vector.

Remediation: Restrict allow_origins to an explicit list of authorized portal domains. Remove the wildcard.

1.2 — Hardcoded Default JWT Signing Key

Field	Value
Severity	CRITICAL
Components	API (`config.py`), Auth (`config.py`)
CWE	CWE-798 — Use of Hard-coded Credentials

Description: Both services define a publicly known default value for the JWT signing key:

secret_key: str = "change-me-to-a-random-secret-key-in-production"

If the .env file is missing or the environment variable is not set, the service starts silently with this key. An attacker can forge valid JWT tokens and gain full administrative access to the platform.

Impact: Complete authentication bypass. Any attacker who reads the source code (or guesses the common default) can mint arbitrary JWT tokens with any claims, gaining unrestricted access to all API operations.

Remediation: Remove the default value entirely. The service must refuse to start without explicit configuration of the secret key.

1.3 — Default Administrator Password

Field	Value
Severity	CRITICAL
Component	Auth (`config.py`)
CWE	CWE-798 — Use of Hard-coded Credentials

Description: The authentication service bootstrap creates an administrator account with the trivially guessable password admin if the corresponding environment variable is not set.

Impact: If deployed without explicit configuration (which is the default behavior), the platform ships with a known administrator credential, allowing full account takeover.

Remediation: Require the environment variable. The service must refuse to start without an explicitly configured admin password.

1.4 — OAuth2 Client Secret Logged in Plaintext

Field	Value
Severity	CRITICAL
Component	Auth (`main.py`)
CWE	CWE-532 — Insertion of Sensitive Information into Log File

Description: At startup, the authentication service logs the OAuth2 client secret in plaintext via logger.info():

logger.info("Bootstrap: created OAuth2 client ... (client_secret=%s)", secret)

Anyone with access to application logs — including log aggregators, SIEM systems, or shared log storage — obtains the full client secret, enabling complete access via client_credentials grant.

Impact: Full OAuth2 client impersonation. Log files typically have broader access than secrets management systems, making this a high-exposure leak vector.

Remediation: Never log secrets. Display only the client_id in logs. Provide the secret through a secure initialization mechanism (e.g., write to a protected file on first run).

1.5 — Hardcoded Secrets in Version-Controlled Files

Field	Value
Severity	CRITICAL
Component	Infrastructure (Ansible roles)
CWE	CWE-798 — Use of Hard-coded Credentials

Description: Multiple version-controlled files in the repository contain plaintext secrets:

Type	File Count	Description
Hardcoded passwords	3	Admin and service account passwords as default values
Application secret keys	1	Play Framework secret key in TheHive config
Cluster symmetric keys	1	Splunk `pass4SymmKey` in server.conf
API keys / tokens	2	TheHive API key and TA account credentials

These secrets are present in the git history even after file modification. Any contributor or anyone with repository access (current or historical) can extract them.

Impact: Exposure of production credentials for TheHive, Splunk cluster authentication, and service accounts. These credentials could be used to access or manipulate SIEM data, case management systems, and cluster communication.

Remediation: 1. Replace static files with Jinja2 templates using Ansible Vault or a secrets manager (HashiCorp Vault) 2. Clean git history with git filter-repo 3. Rotate all exposed secrets immediately

1.6–1.8 — Additional Critical Findings (Hardcoded Credentials)

Three additional instances of hardcoded credentials were found across the infrastructure code, following the same pattern as finding 1.5. These include default passwords in Packer templates, Terraform variable defaults containing sensitive values, and configuration templates with embedded credentials.

Remediation: Same approach as 1.5 — externalize all secrets to a vault or environment-based configuration.

2. High-Severity Vulnerabilities

2.1 — Vulnerable JWT Dependency

Field	Value
Severity	HIGH
Components	API (`requirements.txt`), Auth (`requirements.txt`)
CVE	CVE-2024-33663, CVE-2024-33664

Description: Both services use python-jose==3.3.0, which is vulnerable to: - CVE-2024-33663: Algorithm confusion attack allowing token forgery - CVE-2024-33664: Denial of Service via JWT bomb

The library is no longer actively maintained.

Impact: An attacker could forge valid JWT tokens by exploiting the algorithm confusion vulnerability, effectively bypassing authentication. The DoS vulnerability could render both services unavailable.

Remediation: Migrate to PyJWT (actively maintained) or update to python-jose>=3.4.0.

2.2 — OAuth2 Introspection and Revocation Endpoints Without Authentication

Field	Value
Severity	HIGH
Component	Auth (`routers/oauth.py`)
CWE	CWE-306 — Missing Authentication for Critical Function

Description: The /oauth/introspect and /oauth/revoke endpoints do not require client authentication, violating RFC 7662 (Token Introspection) and RFC 7009 (Token Revocation). An anonymous attacker can: - Introspect any token, revealing claims, scopes, and user identifiers - Revoke active tokens, causing denial of service for legitimate users

Remediation: Require client authentication (client_id + client_secret) on both endpoints, as mandated by the relevant RFCs.

2.3 — Open Redirect via Unvalidated redirect_uri

Field	Value
Severity	HIGH
Component	Auth (OIDC flow — `routers/google_oidc.py`, `services/google_oidc_service.py`)
CWE	CWE-601 — URL Redirection to Untrusted Site

Description: The redirect_uri parameter in the Google OIDC flow is user-controlled and embedded in an HMAC-signed state parameter. After successful Google authentication, tokens are redirected to this URI without validation against an allowlist. An attacker can provide a URI pointing to their own domain and receive the victim's tokens.

Attack scenario: 1. Attacker crafts a login URL with redirect_uri=https://evil.com/callback 2. Victim clicks the link, authenticates with Google 3. Tokens are sent to evil.com instead of the legitimate portal

Remediation: Validate redirect_uri against a configured allowlist before embedding it in the state parameter.

2.4 — Health Endpoints Exposing Internal Topology

Field	Value
Severity	HIGH
Component	API (`routers/health.py`)
CWE	CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor

Description: The health-check endpoints /api/v1/health and /api/v1/health/{service} are accessible without authentication and expose hostnames, IP addresses, and ports of all internal SOC services. This provides a complete infrastructure map to an unauthenticated attacker.

Impact: Reconnaissance information enabling targeted attacks against internal services (Splunk, TheHive, Teleport, Cribl, Vector, Syslog-ng).

Remediation: Either require authentication for health endpoints, or return only a simple {"status": "ok"} without infrastructure details.

2.5 — Raw Exception Messages Transmitted to Clients via SSE

Field	Value
Severity	HIGH
Component	API (`services/task_manager.py`)
CWE	CWE-209 — Generation of Error Message Containing Sensitive Information

Description: Unfiltered Python exceptions are transmitted in real-time to clients via Server-Sent Events. These stack traces may reveal internal file paths, database connection strings, or partial credential data.

Remediation: Send a generic error message to the client. Log detailed exceptions server-side only.

2.6 — Insufficient Hashing of OAuth2 Client Secrets

Field	Value
Severity	HIGH
Component	Auth (`services/client_service.py`)
CWE	CWE-916 — Use of Password Hash With Insufficient Computational Effort

Description: OAuth2 client secrets are hashed with plain SHA-256 without salt, while user passwords correctly use bcrypt. In case of database compromise, client secrets can be rapidly cracked using rainbow tables or brute force.

Remediation: Use bcrypt or argon2 for client secret hashing, consistent with the user password hashing approach.

2.7 — Remote Installation via `curl | bash` with TLS Verification Disabled

Field	Value
Severity	HIGH
Component	Infrastructure (Ansible — `playbooks/install_teleport.yml`)
CWE	CWE-295 — Improper Certificate Validation

Description: The Teleport agent installation script is downloaded with curl -fsSLk (the -k flag disables TLS certificate verification) and piped directly into bash with root privileges. A man-in-the-middle attacker could inject arbitrary code that would execute as root on the target system.

Remediation: Remove the -k flag. Alternatively, use package-based installation or verify script integrity via checksum before execution.

2.8 — Sensitive Configuration Files Deployed as World-Readable

Field	Value
Severity	HIGH
Components	Ansible (TheHive `application.conf`, Teleport agent config)
CWE	CWE-732 — Incorrect Permission Assignment for Critical Resource

Description: Configuration files containing secret keys and authentication tokens are deployed with 0644 permissions (world-readable). Any user on the target system can read these secrets.

Remediation: Restrict file permissions to 0600 (owner-only) or 0640 (owner + group) with a dedicated service account as owner.

2.9 — Missing `no_log` Directive on Ansible Tasks Handling Secrets

Field	Value
Severity	HIGH
Components	`install_splunk_server.yml`, `install_splunk_agent.yml`
CWE	CWE-532 — Insertion of Sensitive Information into Log File

Description: Several Ansible tasks that write passwords to target VMs do not use the no_log: true directive, exposing secrets in Ansible's standard output. Other similar playbooks in the project correctly use this directive, indicating an inconsistency.

Remediation: Add no_log: true to all tasks that handle secrets. Audit all playbooks for consistency.

2.10 — CI/CD Workflow File Outside Git Worktree

Field	Value
Severity	HIGH
Component	CI/CD (`.github/workflows/security.yml`)

Description: The GitHub Actions workflow file is placed outside the configured git worktree. The project uses a non-standard git setup where .git is at /opt/.git with core.worktree pointing to /opt/autosoc/. The workflow file at /opt/.github/workflows/ is invisible to git and will never be pushed to the remote repository.

Impact: The security scanning pipeline will never execute on pull requests, leaving a false sense of security.

Remediation: Move the workflow file into the correct directory within the worktree (/opt/autosoc/.github/workflows/).

2.11–2.13 — Additional High-Severity Findings

#	Component	Issue	CWE
2.11	Auth	Account auto-linking by email enables potential account takeover	CWE-287
2.12	Infra	Passwordless sudo (`NOPASSWD:ALL`) for provisioning user	CWE-250
2.13	Infra	Docker containers bound to all interfaces (`0.0.0.0`)	CWE-668

3. Medium-Severity Vulnerabilities

#	Component	Issue	CWE
3.1	Auth	Automatic account linking by email (potential account takeover)	CWE-287
3.2	Auth	Dynamic SQL with interpolated column names	CWE-89
3.3	Auth	No rate limiting on authentication endpoints (`/oauth/token`)	CWE-307
3.4	Auth	No minimum password complexity requirements	CWE-521
3.5	Auth	Email field without format validation	CWE-20
3.6	Auth	Refresh token rotation without grace period (race condition risk)	CWE-613
3.7	API	JWT validation details leaked in 401 error responses	CWE-209
3.8	API	Unbounded memory growth from rate-limit buckets	CWE-400
3.9	API	In-memory task store with no size limit	CWE-400
3.10	API	Client-controlled request ID enabling log injection	CWE-117
3.11	API	No CSRF protection (compounded by permissive CORS)	CWE-352
3.12	Infra	TLS verification disabled by default for Proxmox API	CWE-295
3.13	Infra	Passwordless sudo (`NOPASSWD:ALL`) for provisioning user	CWE-250
3.14	Infra	Vector API listening on all interfaces without authentication	CWE-306
3.15	Infra	Inter-service communication over plaintext HTTP	CWE-319
3.16	Infra	Docker container exposed on all interfaces	CWE-668
3.17	Infra	Nginx reverse proxy missing security headers (CSP, X-Frame-Options, HSTS)	CWE-693
3.18	CI/CD	GitHub Actions referenced by mutable tag (not pinned to SHA)	CWE-829

Notable Details

3.2 — Dynamic SQL with Interpolated Column Names: The authentication service constructs SQL queries with column names derived from user input. While parameterized values are used for data, the column names are interpolated directly into the query string, creating a potential SQL injection vector.

3.3 — No Rate Limiting on Authentication: The /oauth/token endpoint has no rate limiting, enabling brute-force attacks against user credentials or client secrets. The in-memory rate limiter on the API service has unbounded bucket growth (3.8), which could itself be exploited for memory exhaustion.

3.11 — No CSRF Protection: Combined with the permissive CORS configuration (1.1), the lack of CSRF protection creates a compound vulnerability where cross-origin requests can trigger state-changing operations without user consent.

3.15 — Plaintext Inter-Service Communication: All internal service communication (Splunk forwarders, syslog aggregation, SIEM data flow) occurs over unencrypted HTTP. An attacker with network access can intercept and modify security-relevant data in transit.

4. Low-Severity Vulnerabilities

#	Component	Issue
4.1	API	Server bound to `0.0.0.0` by default (all interfaces)
4.2	API	`sys.path.insert(0, "/opt")` in multiple files (module hijack risk)
4.3	API	Swagger/OpenAPI documentation accessible without authentication
4.4	Auth	SQLite `check_same_thread=False` in async context (potential data corruption)
4.5	Auth	Tokens transmitted in URL fragments (Google OIDC callback)
4.6	Auth	Token `expires_in` values hardcoded instead of using configuration
4.7	Orchestrator	Internal IP addresses hardcoded in source code
4.8	Orchestrator	SSH key path hardcoded
4.9	Orchestrator	Full commands logged including sensitive file paths
4.10	Infra	Teleport user created with direct `root` access
4.11	Infra	Cribl Edge fleet token visible in world-readable systemd unit file
4.12	Infra	SSH host key checking disabled globally in Ansible configuration

Notable Details

4.2 — sys.path Manipulation: Multiple files insert /opt at the beginning of sys.path. If an attacker can write to /opt, they could place a malicious module that gets loaded instead of the legitimate one.

4.4 — SQLite Thread Safety: Using check_same_thread=False with SQLite in an async FastAPI context can lead to concurrent writes and database corruption under load.

4.12 — SSH Host Key Checking Disabled: The ansible.cfg sets host_key_checking = False globally. While convenient for provisioning, this disables SSH man-in-the-middle protection across the entire infrastructure.

5. Informational Findings

The following items are not vulnerabilities per se but represent areas for improvement:

#	Component	Observation
5.1	API	No structured logging format (harder to parse in SIEM)
5.2	Auth	No audit trail for administrative actions
5.3	Auth	No session invalidation on password change
5.4	Orchestrator	No integrity verification of Terraform/Ansible binaries
5.5	Infra	No network segmentation between management and data planes
5.6	Infra	No backup or recovery strategy for critical data
5.7	Infra	Packer templates using `insecure_skip_tls_verify = true`
5.8	CI/CD	No dependency scanning (Dependabot/Renovate) configured

6. Positive Observations

The following security practices are correctly implemented:

Ansible Vault properly used for encrypting sensitive variables ($ANSIBLE_VAULT;1.1;AES256)
Terraform sensitive variables marked with sensitive = true in declarations
Comprehensive .gitignore covering .env, *.tfvars, *.pem, *.key, *.tfstate, *.db
No shell=True in subprocess calls — no direct shell injection vector
No eval(), exec(), or pickle — no insecure deserialization or dynamic code execution
CLI input validation with argparse choices= whitelist on the orchestrator
Subprocess timeouts with orphan process cleanup (process.kill())
JWT verification with audience checks and scope-based authorization
CI/CD permissions properly scoped to minimum required (contents: read, pull-requests: write)

7. Remediation Roadmap

Phase 1 — Immediate (Week 1)

Focus: Quick wins that eliminate critical exposure with minimal effort.

Action	Effort	Eliminates
Restrict CORS to explicit portal domains	Low	CRITICAL 1.1
Remove default values for secrets in `config.py`	Low	CRITICAL 1.2, 1.3
Stop logging OAuth2 client secret	Low	CRITICAL 1.4
Move CI workflow into correct git worktree path	Low	HIGH 2.10
Add `no_log: true` to all Ansible tasks handling secrets	Low	HIGH 2.9
Restrict sensitive file permissions to `0600`	Low	HIGH 2.8

Expected outcome: All 5 critical findings addressed, 3 high-severity findings eliminated. Estimated effort: 1–2 days.

Phase 2 — Short Term (Weeks 2–3)

Focus: Credential management overhaul and authentication hardening.

Action	Effort	Eliminates
Replace static files containing secrets with Jinja2 templates + Vault	Medium	CRITICAL 1.5–1.8
Clean git history (`git filter-repo`) + rotate all exposed secrets	Medium	Post-1.5 cleanup
Migrate `python-jose` to `PyJWT`	Medium	HIGH 2.1
Require client authentication on `/introspect` and `/revoke`	Low	HIGH 2.2
Validate `redirect_uri` against an allowlist	Low	HIGH 2.3
Require authentication on health endpoints or strip details	Low	HIGH 2.4
Sanitize error messages in SSE streams	Low	HIGH 2.5

Expected outcome: All critical and most high-severity findings eliminated. Estimated effort: 1–2 weeks.

Phase 3 — Medium Term (Following Month)

Focus: Infrastructure hardening and defense-in-depth.

Action	Effort	Eliminates
Replace `curl \\| bash` with package-based installation	Medium	HIGH 2.7
Implement rate limiting on authentication endpoints	Medium	MEDIUM 3.3
Use bcrypt for OAuth2 client secret hashing	Low	HIGH 2.6
Add security headers to Nginx (CSP, X-Frame-Options, HSTS)	Low	MEDIUM 3.17
Restrict Docker/API bindings to `127.0.0.1`	Low	MEDIUM 3.14, 3.16
Enable HTTPS for inter-service communication	Medium	MEDIUM 3.15
Pin GitHub Actions to commit SHAs	Low	MEDIUM 3.18
Implement CSRF protection on state-changing endpoints	Low	MEDIUM 3.11

Expected outcome: All high-severity findings eliminated, majority of medium-severity addressed. Estimated effort: 2–3 weeks.

8. Risk Matrix Summary

Category	CRITICAL	HIGH	MEDIUM	LOW	INFO
API Service	2	2	5	3	1
Auth Service	3	4	6	3	2
Orchestrator	0	0	0	3	1
Infrastructure	3	4	6	3	3
CI/CD	0	1	1	0	1
Total	8	13 (incl. 2 extra)	18	12	8

Appendix A — Methodology

This audit was performed through static analysis of all source code files on the development branch. The review covered:

Python source code — API endpoints, authentication flows, service logic, CLI orchestrator
Infrastructure as Code — Terraform modules, Ansible playbooks and roles, Packer templates
Configuration files — Nginx, Docker Compose, systemd units, application configs
CI/CD pipelines — GitHub Actions workflows
Dependency manifests — requirements.txt files checked against known CVE databases

Limitations: - No active penetration testing was performed - No runtime analysis or dynamic testing - No review of the Proxmox hypervisor configuration itself - No review of target VM operating system hardening

Appendix B — References

Report generated through static source code analysis. No active penetration testing was performed. Confidential — February 2026

June 1, 2024
in detection
10 min read

Diving into RPC – Exploring a Deeper Layer of Detection

Introduction

In this article, we explore the defensive capabilities of Microsoft RPC (MSRPC) and introduce a powerful tool called RPCFirewall. While many discussions focus on identifying vulnerabilities within MSRPC, we will examine how to use RPCFirewall to detect and mitigate malicious activities that exploit this protocol.

MSRPC is a critical component of the Windows operating system, enabling various functionalities and communications. Due to its extensive use, numerous lateral movement techniques leverage MSRPC, including attacks like PSExec, Remote Scheduled Task, DCSync… Differentiating between legitimate and malicious MSRPC traffic can be challenging when relying solely on traditional network metadata like IP addresses and ports.

Remote Procedure Call (RPC) is a protocol for interprocess communication (IPC) that allows a program to execute a procedure on a remote server as if it were local. In Windows, MSRPC is Microsoft’s implementation of this protocol, following a client-server model. The server defines the interface it exposes using the Interface Definition Language (IDL), which includes a unique universal identifier (UUID) and the definitions of the functions available for remote invocation.

When discussing RPC, it is important to recognize that there are various way of interaction available. Examples include RPC over TCP/IP (ncacn_ip_tcp) and RPC over named pipes (ncacn_np). Detailed information on these protocols can be found at the following link: MS-RPCE Protocols.:MS-RPCE Protocols

RPC FILTER & RPC FIREWALL, make the difference

1. Is rpc filter sustainable?

Windows offers the ability to filter RPC calls through its firewall, allowing you to permit or block incoming RPC calls while auditing them. You can achieve this with the following commands, for example:

rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
quit

Each time these rules are triggered, windows is supposed to generate the EventCode 5712.

EventCode 5712 Official documentation

Result Evilginx

However the big point is this log is inconsistent. It lacks of information and it’s not generated each time.

2. The capabilities of RPC Firewall

That’s where RPCFirewall from Zero Networks comes in. The project aims to improve the logging of RPC Audit and ETW, creating a more informative logging journal in Windows. They have an excellent article explaining their solution, available at the following link: Stopping lateral movement with RPC Firewall and you can find the GitHub project here: Zeronetwork github

With RPCFirewall, you can easily create a configuration file and choose to allow, block, and audit based on interface_uuid, op_num, or src_ip. The parameters you can use are:

fw: Applies the RPCFirewall configuration and logs in the RPCFW journal.
flt: Uses the RPC Filters.

In our case, we mainly performed our tests with the fw option, with action allow and audit enabled. However, Microsoft introduced a technology called « Protected process Light », and for these protected process, we can only use the flt option as the RPCFW dll can’t inject into it. So we could still use the EventCode 5712

That’s why we prepared to ingest everything into Splunk for testing. But first, we need to find a way to identify all the functions associated with an RPC interface_uuid and op_num.

How to retrieve RPC Interfaces?

To retrieve all the information about RPC interfaces, I personally use the script from enigma0x3 which I modified slightly to generate a CSV.

To use the following DLL: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll, you will need to install the Windows SDK debugger

$rpc = ls C:\Windows\System32\*.exe, C:\Windows\System32\*.dll | Get-RpcServer -DbgHelpPath "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll"

$results = @()

foreach ($rpc1 in $rpc) {
    # Write-Host $rpc1  # You can uncomment this for debugging if needed.
    foreach ($proc in $rpc1.Procedures) {
        $ourObject = New-Object -TypeName psobject
        $ourObject | Add-Member -MemberType NoteProperty -Name InterfaceID -Value $rpc1.InterfaceID
        $ourObject | Add-Member -MemberType NoteProperty -Name FileName -Value $rpc1.Name
        $ourObject | Add-Member -MemberType NoteProperty -Name ProcedureName -Value $proc.Name
        $ourObject | Add-Member -MemberType NoteProperty -Name ProcedureNumber -Value $proc.ProcNum
        $results += $ourObject
    }
}

# Now export $results to CSV
$results | Export-Csv -Path "C:\Users\Administrator\Documents\rpc.csv" -NoTypeInformation

Now we can have the lookup that determine the Procedure Name(the function) and the file name depending on the UUID_Interface and the Procedure_Number (opnum)

A bit of Splunk Configuration

Let’s prepare the splunk configuration with the RPCFW logs. Firstly we add the following configuration on our DC (LAB-DC) :

[WinEventLog://RPCFW]
checkpointInterval = 5
current_only = 0
disabled = 0
index = windows
renderXml = true
start_from = oldest

Then we prepare the transforms.conf on the application on the Search Head cluster Deployer to push on the Search Head Cluster :

XmlWinEventLog:RPCFW]
EXTRACT-event_details = <EventID Qualifiers='\d+'>\s*(?<event_id>\d+)\s*</EventID>.*<TimeCreated SystemTime='(?<system_time>[^']+)'/>.*<EventRecordID>(?<record_id>\d+)</EventRecordID>.*<Execution ProcessID='(?<process_id>\d+)' ThreadID='(?<thread_id>\d+)'/>.*<Computer>(?<computer>[^<]+)</Computer>
EXTRACT-user_activity = <Data>(?<activity>[^<]+)</Data><Data>\d+</Data><Data>(?<path>[^<]+)</Data><Data>(?<protocol>[^<]+)</Data><Data>(?<source_port>[^<]+)</Data><Data>(?<src>[^<]+)</Data><Data>(?<interface_uuid>[^<]+)</Data><Data>(?<procedure_number>\d+)</Data><Data>(?<user>[^<]+)</Data><Data>(?<privacy>[^<]+)</Data><Data>(?<auth_type>[^<]+)</Data><Data>\d+</Data><Data>(?<destination_ip>[^<]+)</Data><Data>(?<destination_port>\d+)</Data><Data>(?<sid>[^<]+)</Data>
LOOKUP-interface = interface-lookup interface_uuid AS interface_uuid procedure_number AS procedure_number OUTPUTNEW file_name, procedure_name
````

And then the props.conf :
```conf
[interface-lookup]
filename = rpc_procedures.csv
external_type = file
fields_list = interface_uuid, file_name, procedure_number, procedure_name

Analysing of some attackers tools.

If you’re working in cybersecurity, you know that detecting malicious behavior can sometimes be a challenging task. Microsoft interactions are really complex, and even though EDR/NDR solutions are improving, they can still miss some behaviors. In Windows, many of these interactions are based on RPC, which is also used by attacker tools. In this section, we will use many various famous attacker tools and analyze their behavior

We will execute various lateral movement, reconnaissance, or credential harvesting payloads from different tools such as Impacket , Sysinternals, Ghostpack, Mimikatz , and analyze them using both Wireshark and Splunk. For Wireshark, we can apply the following filter to specifically view the RPC calls and the interface_uuid:

dcerpc and ip.src == 172.16.16.22 and dcerpc.cn_bind_to_uuid

1. Impacket Atexec.py

We can start our analysis with a first tool from impacket : atexec.py. Atexec.py permits to eecute remote tasks scheduler through the task Scheduler.

First, Let’s analyze some part of the python code:

Code analysis

On this function, we see the dce.bind function on the MSRPC_UUID_TSCHS Interface. If we look on the Microsoft documentation about TSCHS (MS-TSCH), we find the following interfaces :

Code analysis

Now if we look back to the code deeper, we can see the following functions executed :

Code analysis 2

So what are we expecting from these? If we’re using TCP, we expect to see a GUID of 86D35949-83C9-4044-B424-DB363231FD0C with the functions :

– SchRegisterTask – SchRpcRun – SchGetLastRunInfo – SchRpcDelete

Let’s have fun and play with wireshark and Splunk.

atexec.py 'FTRSEC/Administrator:Toto1234!@LAB-DC' cmd.exe /c calc.exe

Wireshark analysis - TaskScheduler

Code analysis 2

We got right on the interface. After executing the payload we can effectively see the corresponding_uuid.

Let’s see what we have on splunk :

Splunk analysis - TaskScheduler

Code analysis 2

Bingo ! We got exactly the expected behavior and were able to detect fully the atexec.py in the second it was launched !!

Let’s see some other example with splunk following the same procedures :

2. Impacket LookupSids.py

python lookupsid.py 'FTRSEC/Administrator:Toto1234!@LAB-DC'

LookupSids - Splunk

LookupSids

3. Net view from powershell

Net view \\LAB-DC

Net view - Splunk

4. Impacket dcomexec.py

python .\dcomexec.py -object MMC20 Administrator:Toto1234!@LAB-DC

Dcomexec - Splunk

Dcomexec

5. Impacket secretsdump.py

python secretsdump.py ftrsec/Administrator:Toto1234!@LAB-DC

Secretsdump - Splunk

Secretsdump

6. DCSync with Mimikatz

.\mimikatz.exe "lsadump::dcsync /domain:ftrsec.local /user:krbtgt" exit

DCSync - Wireshark

DCSync - Splunk

7. PSExec

Note

For psexec, we couldn’ see on the RPCFW journal because psexec work by starting the service psexesvc.exe on the remote destination. However, the service is protected, so we will detect using the EventCode 5712

.\PsExec64.exe \\LAB-DC ipconfig /all

Psexec - Wireshark

Psexec - Splunk

DCSync - Splunk

Now because we didn’t use the blocking functionality on this article, we will try to modify our configuration line to : flt:audit:true uuid:367abb81-9844-35f1-ad32-98f038001003 action:block.

And we can see it blocked perfectly our psexec !

Psexec - Blocked

DCSync - Splunk

Recapitulative table of the attacks detected by RPC Firewall

Recapitulative table

Conclusion

To conclude, we were highly impressed by the RPC Firewall project by Zero Networks. It enabled us to detect advanced lateralization, reconnaissance, and credential dumping tools utilizing the RPC protocols more quickly and thoroughly than current EventCodes, when detection was possible.

In this article, we primarily focused on the detection aspect. However, as demonstrated with PsExec, the RPC Firewall also possesses effective blocking capabilities. Due to the protected process light, we still need to rely on the native Windows filtering, but only when necessary.

We recommend using both RPCFW and EventCode 5712 for improved detection coverage.

Next step will be to try their project LdapFirewall !

Happy RPC-Splunking!

REFERENCE

https://www.akamai.com/blog/security/guide-rpc-filter https://zeronetworks.com/blog/stopping-lateral-movement-via-the-rpc-firewall https://youtu.be/hz_YPIMeBMI

May 16, 2024
in detection
5 min read

Detecting browser data theft using Splunk

During my daily cyberwatch, I recently found this great article by Will Harris about browser data theft using a Windows Event Log 16385: security.googleblog.com

I decided to try implementing it in my own Splunk infrastructure and to create detection rules around it. This article will mainly discuss the Splunk aspect; if you want to know the details, I invite you to read the article linked above.

1. Splunk Universal Forwarder Configuration

On my Windows system, I started by activating the EventCode to see it in the Debug Channel using the PowerShell commands provided by Will Harris:

$log = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Crypto-DPAPI/Debug
$log.IsEnabled = $True
$log.SaveChanges()

Then, I prepared my Splunk logging on the UF. I placed the following configuration in the inputs.conf file of my application:

[WinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug]
index = windows
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5
renderXml = true

2. Splunk Search Head Configuration

I added some parsing for the relevant data I needed for my PoC in the props.conf file of my search head application.

We need the application field because we want to identify when Chrome data is being accessed, and we need the caller_process_id because we have to correlate it with the process_id from EventCode 4688 to identify the originating process. To achieve this goal, we translated the decimal caller_process_id to the hexadecimal parent_process_id.

[XmlWinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug]
EXTRACT-DataDescription = <Data Name='DataDescription'>(?<application>[^<]*)</Data>
EXTRACT-CallerProcessID = <Data Name='CallerProcessID'>(?<caller_process_id>\d+)</Data>
EVAL-parent_process_id = lower(printf("%x", caller_process_id))

3. Splunk Detection Rule

Then, we created a quick Splunk detection rule to identify this behavior, and we observed that it successfully triggered when we ran the Python stealer.

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug" application="Google Chrome"
| bin _time span=5m
| rename parent_process_id as process_id
| join type=inner process_id [search index=windows source=security_4688]
|`convert_time(_time)`
| table _time src_user parent_process_name process_name process_command

Splunk detection rule

Stealer execution

Now we’re pleased that we’ve detected suspicious behavior with a new EventCode. (Time difference is cause of TZ, my infrastructure is located in FR while I’m in HK :)) This EventCode doesn’t appear to be too verbose in my lab environment, but I’m unsure of its real impact in a production environment. So, proceed carefully and test thoroughly before making any decisions.

Happy Splunking!

May 1, 2024
in detection
1 min read

Standard Setup: Proxy forwards encrypted data.
SSL Inspection: With SSL inspection, proxies like Zscaler can decrypt, inspect, and re-encrypt traffic, offering more visibility.

Conclusion

A CONNECT request followed by a 200 OK response means a secure session is established. Understanding these secure channels helps interpret network logs accurately.

Resources

When to Use CONNECT and GET HTTP Methods at an HTTP Proxy Server

Web Proxy Tunneling (IETF Draft)