Netwitness Security LLC blog

Amazon Cloudwatch Event Source Log Configuration Guide

Admin — Wed, 03 Dec 2025 05:00:00 GMT

Amazon CloudWatch Event Source Log Configuration Guide provides the following information:

Introduction about Amazon CloudWatch Logs Service
Setting up AWS CloudWatch Logs
Setting up Amazon Universal CloudWatch Plugin
Amazon CloudWatch Collection Configuration Parameters

For more information, refer the PDF available in the Attachments section.

F5 Source Code Breach: Hunting UNC5221's BRICKSTORM with NetWitness

Admin — Fri, 31 Oct 2025 04:00:00 GMT

F5 Source Code Breach: Hunting UNC5221's BRICKSTORM with NetWitness®

Hey folks, Dave Glover here with some critical intel you need to act on right now. On October 15, 2025, F5 dropped a bombshell disclosure that's sending shockwaves through our industry—a nation-state threat actor, tracked as UNC5221 (China-nexus), maintained persistent access to F5's corporate network for over 12 months, exfiltrating BIG-IP source code and undisclosed vulnerability intelligence. CISA immediately issued Emergency Directive ED-26-01, and for good reason—this isn't just another breach, it's a strategic supply chain compromise with massive downstream implications.

If you're running F5 BIG-IP appliances (and let's be honest, who isn't?), you need to be threat hunting right now. This post will arm you with the knowledge and NetWitness queries to detect BRICKSTORM backdoor activity and related TTPs in your environment.

The Breach: What Happened

F5 discovered the intrusion on August 9, 2025, but evidence suggests UNC5221 had been inside since at least mid-2024.

The attackers exfiltrated:

Portions of BIG-IP source code across multiple modules (all BIG-IP products affected)
Information about undisclosed vulnerabilities
Engineering knowledge management system data

The stolen source code dramatically increases the risk of rapid zero-day discovery and weaponization. F5 has since released patches for over 20 vulnerabilities spanning BIG-IP (all modules), F5OS-A/C, and BIG-IP Next. Key CVEs include:

CVE-2025-53868 (BIG-IP all modules)
CVE-2025-61955 (F5OS-A; F5OS-C)
CVE-2025-60016 (BIG-IP all modules; BIG-IP Next SPK; BIG-IP Next CNF)
...and 20+ more

Full vulnerability list available at: https://my .f5.com/manage/s/article/K000154696

Meet BRICKSTORM: The Appliance Whisperer

UNC5221's weapon of choice is BRICKSTORM, a Go-based backdoor specifically engineered to compromise network appliances that don't support traditional EDR. Here's what makes it dangerous:

Technical Capabilities:

Statically-linked Go ELF binary (linux/amd64)—completely self-contained, no dependencies
HTTP/2 over TLS with WebSocket upgrade for persistent C2 tunnel
Yamux multiplexing—multiple logical streams over a single socket (legacy SPDY-inspired tech from 2009)
Built-in SOCKS proxy for TCP pivoting and lateral movement
Multipart/form-data exfiltration with base64/quoted-printable encoding and compression to blend with legitimate web traffic
No hardcoded domains or credentials - all supplied at runtime

Operational Security:

Average dwell time: 393 days
Minimal security telemetry generation
C2 domains never reused across victims
Masquerades as legitimate system processes (e.g., pg_update, vami-httpd, vmprotect)

Attack Lifecycle: How They Operate

Initial Access: Exploitation of internet-exposed BIG-IP management interfaces (likely zero-days)
Establish Foothold: Deploy BRICKSTORM on appliances (F5 BIG-IP, VMware vCenter/ESXi, network edge devices)
Persistence: Modify systemd, init.d, or rc.local to auto-start backdoor on reboot
Credential Harvesting: Deploy BRICKSTEAL (Java Servlet filter) on vCenter to capture credentials; Clone VMs of Domain Controllers, password vaults, SSO providers
Lateral Movement: SSH to appliances using stolen credentials; SOCKS proxy from appliance management IPs
Complete Mission: Exfiltrate emails via Microsoft Entra ID Enterprise Applications; Download source code repositories as ZIP archives

NetWitness Detection: Sample Queries to Hunt BRICKSTORM

Alright, enough theory—let's get to the good stuff. Here are NetWitness queries you can run right now to hunt for indicators of BRICKSTORM activity and UNC5221 TTPs in your environment.

Hunt for Suspicious HTTP/2 + WebSocket Traffic from Appliances
BRICKSTORM uses HTTP/2 negotiation via ALPN and upgrades connections to WebSocket for persistent C2. Appliance management IPs should rarely establish outbound HTTP/2 or WebSocket connections.
# Detect HTTP/2 traffic from known appliance subnets
ip.src = '<your_appliance_subnet>' && http.version = '2.0'

# Detect WebSocket upgrade requests from appliances
ip.src = '<your_appliance_subnet>' && http.header contains 'Upgrade: websocket'

# Combine both for high-fidelity alert
ip.src = '<your_appliance_subnet>' && (http.version = '2.0' || http.header contains 'Upgrade: websocket')

Pro Tip: Create a meta key for your appliance management IPs (BIG-IP, vCenter, ESXi, VPN concentrators, firewalls) and substitute with your actual ranges.
Detect Yamux Multiplexing Protocol Signatures
BRICKSTORM uses Yamux (SPDY-inspired multiplexing) over TLS. While Yamux traffic is encrypted, you can look for patterns in connection behavior and TLS characteristics.
# Look for persistent long-duration TLS sessions from appliances
ip.src = '<your_appliance_subnet>' && service = 443 && session.duration > 3600 && packets > 1000

# Detect TLS connections with HTTP/2 ALPN from appliances
ip.src = '<your_appliance_subnet>' && ssl.alpn = 'h2'

# Hunt for TLS sessions to non-standard ports (Yamux can run on any port)
ip.src = '<your_appliance_subnet>' && service != 443 && (tls.version = '1.2' || tls.version = '1.3')
Identify Appliances Communicating with External IPs (Not Vendor Domains)
Appliances should only communicate with manufacturer domains for updates and telemetry. Any other outbound connections are highly suspicious.

# Detect outbound connections from appliances NOT to F5/VMware/known vendors
ip.src = '<your_appliance_subnet>' && direction = 'outbound' && !(alias.host contains 'f5.com' || alias.host contains 'vmware.com' || alias.host contains '<add_your_vendor_domains>')

# Focus on HTTPS connections to unknown destinations
ip.src = '<your_appliance_subnet>' && service = 443 && !(alias.host contains 'f5.com' || alias.host contains 'vmware.com')
Hunt for DNS over HTTPS (DoH) from Appliances
BRICKSTORM can use DNS over HTTPS (DoH) to evade detection. Appliances should never use DoH.

# Detect DoH queries (usually to public resolvers)
ip.src = '<your_appliance_subnet>' && (alias.host = 'dns.google' || alias.host = 'cloudflare-dns.com' || alias.host = 'dns.quad9.net' || url contains '/dns-query')

# Broader hunt for HTTPS to known DoH providers
ip.src = ' && (ip.dst = '8.8.8.8' || ip.dst = '1.1.1.1' || ip.dst = '9.9.9.9') && service = 443
Detect Windows Logon Events Sourced from Appliances (Type 3 Network Logons)
UNC5221 uses compromised appliances to log into Windows systems via SMB/RDP. Appliances should rarely authenticate to Windows endpoints.

# Hunt for SMB traffic from appliances to Windows servers
ip.src = ' ' && service = 445 && ip.dst = ' '

# Detect RDP sessions initiated from appliances
ip.src = ' ' && service = 3389

# Look for Kerberos/NTLM authentication from appliances
ip.src = '<your_appliance_subnet>' && (service = 88 || service = 135 || service = 139)

Windows Event Correlation: Enrich with Windows Event Logs (Event ID 4624 Type 3) where source IP matches appliance management IPs.
Hunt for Multipart/Form-Data Exfiltration
BRICKSTORM exfiltrates data using multipart/form-data POST requests with base64/quoted-printable encoding and compression to mimic legitimate web traffic.

# Detect large multipart/form-data uploads from appliances
ip.src = '<your_appliance_subnet>' && http.method = 'POST' && content.type = 'multipart/form-data' && bytes.dst > 1048576

# Look for base64 patterns in POST bodies (may trigger on legitimate traffic)
ip.src = '<your_appliance_subnet>' && http.method = 'POST' && payload contains 'base64'
Detect SSH Enablement and New Local Account Creation on vCenter/ESXi
UNC5221 frequently enables SSH on vSphere appliances and creates temporary local admin accounts.

# Hunt for SSH connections TO vCenter/ESXi management IPs
ip.dst = '<vcenter_esxi_management_ips>' && service = 22

# Look for SSH from unexpected internal sources
ip.dst = '<vcenter_esxi_management_ips>' && service = 22 && !(ip.src = '<authorized_jump_boxes>')

Log Correlation: Check vCenter audit logs (/var/log/audit/sso-events/audit_events.log) for PrincipalManagement events creating/deleting local users and SystemConfiguration.BashShellAdministrators group modifications.
Detect VM Cloning Activity on vCenter
UNC5221 clones sensitive VMs (Domain Controllers, password vaults) to extract credentials offline without triggering EDR.

# Hunt for SMB/vSphere API traffic patterns consistent with VM cloning
ip.src = '<vcenter_management_ip>' && (service = 443 || service = 902) && session.size > 10485760

Log Collection: Search vCenter VPXD logs for vim.event.VmBeingClonedEvent, vim.event.VmClonedEvent, and vim.event.VmRemovedEvent, filtering for VSPHERE.LOCAL\Administrator account during 01:00-10:00 UTC.
Hunt for Commercial VPN/Proxy Usage
UNC5221 uses commercial VPN services (PIA, NordVPN, Surfshark, VPN Unlimited, PrivadoVPN) and compromised SOHO routers for obfuscation.

# Detect connections to known commercial VPN provider IP ranges
(asn = '<PIA_ASN>' || asn = '<NordVPN_ASN>' || asn = '<Surfshark_ASN>') && (ip.src = '<your_internal_subnets>' || ip.dst = '<your_internal_subnets>')

# Hunt for TLS connections to VPN provider domains
alias.host contains 'privateinternetaccess' || alias.host contains 'nordvpn' || alias.host contains 'surfshark' || alias.host contains 'vpnunlimitedapp' || alias.host contains 'privadovpn'
Detect Microsoft 365 Mailbox Access via Enterprise Applications
UNC5221 creates Entra ID Enterprise Applications with mail.read or full_access_as_app scopes to exfiltrate executive emails.

# Hunt for unusual Graph API access patterns
alias.host = 'graph.microsoft.com' && url contains '/mail' && http.method = 'GET'

# Detect bulk email downloads
alias.host = 'graph.microsoft.com' && url contains '/messages' && session.size > 10485760

Microsoft 365 Log Correlation: Query Unified Audit Log or Sentinel OfficeActivity table for MailItemsAccessed events with Enterprise Application ClientID, focusing on source IPs from commercial VPN ranges.
Baseline and Anomaly Detection: Appliance Outbound Traffic
Create a baseline of normal appliance behavior and alert on deviations.

# Baseline query: Map all outbound destinations from appliances
ip.src = '<your_appliance_subnet>' && direction = 'outbound' aggregation: alias.host, ip.dst, service

# Anomaly detection: Alert on NEW destinations never seen before
ip.src = '<your_appliance_subnet>' && direction = 'outbound' && ! (alias.host = '<whitelisted_vendor_domains>')

Implementation: Run baseline weekly, export results, and create exclusion lists. Alert on any NEW connections.

Indicators of Compromise (IOCs)

BRICKSTORM File Hashes (SHA-256)

90b760ed1d0dcb3ef0f2b6d6195c9d852bcb65eca293578982a8c4b64f51b035 (Pg_update)
2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df (Listener/spclisten)
aa688682d44f0c6b0ed7f30b981a609100107f2d414a3a6e5808671b112d1878 (Vmprotect/vmp)

Note: UNC5221 never reuses malware samples or C2 domains across victims. Hash-based detection alone is insufficient - focus on TTP-based hunting.

Enablers of Compromise (EOCs): What Made this Possible

This is where I want to shift your thinking. Yes, we need to hunt for IOCs and detect active compromise, but let's talk about Enablers of Compromise - the underlying weaknesses that gave UNC5221 a 12-month vacation in F5's network.

Key EOCs:

Internet-exposed appliance management interfaces (BIG-IP, vCenter, ESXi)
Lack of centralized logging from appliances to SIEM
No EDR capability on network appliances
Poor appliance inventory management ("unknown unknowns")
Weak network segmentation (appliances could reach Windows servers/internal apps)
Insufficient monitoring of outbound traffic from management IPs
Log log retention gaps (393-day average dwell time exceeded most log retention)

Forward-Thinking Defense:

Isolate management interfaces from the internet (VPN-only access)
Implement zero-trust network segmentation (appliances should NOT freely access Windows/internal networks)
Centralized appliance logs to NetWitness with extended retention
Deploy decoy credentials and honeypot appliances to detect lateral movement
Enforce Multi-Factor Authentication for all administrative access (including vCenter, ESXi, and BIG-IP)
Enable vSphere Lockdown Mode and restrict SSH to authorized jump boxes

Immediate Actions: What You Need to Do Right Now

Inventory ALL appliances (F5 BIG-IP, vCenter, ESXi, firewalls, and VPN concentrators) - if it doesn't support EDR, it needs to be on this list
Patch F5 devices immediately to the latest fixed release
Remove public exposure of F5 management interfaces or restric to specific IP ranges
Run the NetWitness queries in this post against 12+ months of captured data (if retention allows)
Review vCenter/ESXi audit logs for unauthorized VM cloning, SSH enablement, and local account creation
Audit Microsoft 365 Enterprise Applications for suspicious mail.read/full_access_as_app permissions
Deploy YARA rules against appliance backups and filesystems
Forward appliance logs (syslog, VAMI, VPXD, and audit logs) to NetWitness for continuous monitoring

The Bigger Picture: Supply Chain Risk

This breach isn't just about F5—it's a wake-up call about the fragility of our supply chain. When a security vendor gets compromised and their source code stolen, the downstream impact cascades to every customer running those products. With over 600,000 internet-connected F5 devices globally, the attack surface is enormous.

UNC5221's targeting of legal services, SaaS providers, BPOs, and technology companies suggests objectives beyond simple espionage:

IP theft to fuel zero-day development
Access operations to establish pivot points into downstream customer environments
Strategic intelligence collection aligned with PRC economic interests

The fact they maintained access for over a year undetected should give every CISO and security engineer pause. Traditional signature-based defenses failed. EDR didn't exist on the compromised appliances. This is why we need TTP-based hunting, behavioral analytics, and a relentless focus on Enablers of Compromise.

Final Thoughts: Stay Vigilant

I know this is a heavy post, but the threat is real and active right now. UNC5221 is sophisticated, patient, and incredibly stealthy. They're not smash-and-grab criminals - they're nation-state operators playing the long game.

Your job is to make their life harder. Run these queries. Patch your systems. Lock down your appliances. Build detections around the TTPS, not just the IOCs. And most importantly, think forward - what conditions in your environment would enable an attacker to persist for 393 days? Fix those.

If you find something suspicious, don't hesitate to escalate and bring in forensics expertise. This is not the time for "wait and see".

Stay safe out there and keep those logs flowing.

Dave Glover

References

MSAzureGraph Universal Plugin for Microsoft Graph API

Admin — Fri, 17 Oct 2025 04:00:00 GMT

Microsoft Graph is a Microsoft developer platform that enables integration with multiple services in Microsoft cloud. It provides a unified programmability model that you can use to access the tremendous amount of data in Microsoft 365, Windows 10, and Enterprise Mobility + Security. Microsoft Graph API is a RESTful web API that enables you to access Microsoft Cloud service resources.

In RSA NetWitness 11.5 or higher versions, we integrated the Microsoft Graph API through the Plugin collection type. This integration helps our customers to collect various event types or alerts from Microsoft cloud services through Microsoft Graph API.

Event types currently supported by NetWitness msazuregraph plugin are as given below. The latest azure log parser needs to be enabled in NetWitness Log decoder to parse these events. Please refer official RSA document for more information on configurations

Microsoft Event types Supported via NetWitness msazuregraph Plugin

Directory Audit Logs
SignIn Logs
Security Alerts
Risk Detection Logs
Azure Sentinel incidents
Microsoft Defender XDR incidents

In addition to the above event types, customers can collect any other event types which are supported through Microsoft Graph API and route them to a custom parser created in NetWitness or get in touch with NetWitness customer support to add official support for fine parsing.

Note: Microsoft Azure: Admin Logs, Azure AD Audit/Sign-in (via native API) and Microsoft Azure Security Alerts Plugins will be deprecated soon because native APIs used in former plugin were already deprecated from Microsoft. Also security alerts are supported in this plugin using the same API. It is recommended that customers start using Microsoft Graph API Plugin instead.

Additional Resources

Netwitness MS Azure Graph API Plugin Configuration Guide

Microsoft Graph Documentation

Microsoft Graph API Guide

Microsoft Azure NSG & NetWitness Integration

Admin — Wed, 03 Sep 2025 04:00:00 GMT

Microsoft Azure Network Security Group Flow Logs are a feature of Azure Network Watcher that provide information about ingress and egress IP traffic through a configured Network Security Group. The NetWitness plugin built for Azure NSG can authenticate and pull flow logs from Azure storage in real time.

“While Virtual Network (VNET) is the cornerstone of Azure networking model and provides isolation and protection. Network Security Group (NSG) is the main tool you need to use to enforce and control network traffic rules at the networking level. Customers can control access by permitting or denying communication between the workloads within a virtual network, from systems on customer’s networks via cross-premises connectivity, or direct Internet communication. In the diagram below, both VNETs and NSGs reside in a specific layer in the Azure overall security stack, where NSGs, UDR, and network virtual appliances can be used to create security boundaries to protect the application deployments in the protected network.”

What is a Network Security Group (NSG)?

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg

How does it work?

These flow logs are written in JSON format and show outbound and inbound flows on a per rule basis.

It provides the following information:

MAC Address of the NIC, flow applies to
5-tuple information about the flow (Source IP, Destination IP, Source Port, Destination Port, Protocol),
And if the traffic was allowed or denied.

Flow logs are stored only within a storage account and follow the logging path as shown below:

https://{storageAccountName}.blob.core.windows.net/insights-logs-networksecuritygroupflowevent/resourceId%3D/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/microsoft.network/networksecuritygroups/{nsgName}/{year}/{month}/{day}/{hour}/m=00/{macAddress}/PT1H.json

Logs have a retention policy that can be set from 1 day to 365 days. If a retention policy is not set, the logs are maintained forever. RSA Netwitness uses Shared Access Signature (SAS Token) to authenticate and pull flow logs from Azure storage in real time.

Use Cases:

With the visibility into Network Flow traffic in the Azure framework, multiple use-cases can be built. For example:

See the overall stats of Allowed vs Denied Traffic in your network, and based on what’s normal, setup alerts if its above or below a certain threshold.
Summary of Protocol usage in the environment, set alerts for abnormal protocol usage.
Top Destination Address Reached out to from your environment.
Set Alerts against blacklisted IP Addresses
Setup rules based on IP range to determine Inbound vs Outbound vs Lateral traffic and then build a dashboard to see the pattern.

Downloads and Documentation:

Configuration Guide: Microsoft Azure NSG Event Source Configuration Guide

Collector Package on RSA Live: "MS Azure NSG Flow Logs"

Parser on RSA Live: CEF (device.type="msazurensg")

Scattered Spider Report

Admin — Tue, 19 Aug 2025 04:00:00 GMT

In July 2025, activity related to the Scattered Spider cybercrime group remained front and center for defenders despite a slight lull following several arrests in the United Kingdom. Law enforcement agencies in the U.S., U.K., Canada, and Australia updated their joint advisory on July 29, noting that Scattered Spider has added the DragonForce ransomware to its arsenal and continues to refine social-engineering techniques such as phishing, push-bombing, and SIM-swap attacks to steal credentials and deploy remote-access tools. cisa.gov Government partners warned that the group’s operators impersonate IT help-desk staff, tricking employees into password resets and multifactor authentication transfers, and then use legitimate remote-management tools like AnyDesk to maintain persistence. therecord.media

Several private-sector reports published during the month described how Scattered Spider widened its target set from retail and insurance to aviation and cloud-service providers. CrowdStrike observed attacks on VMware vCenter environments in which attackers created unmanaged virtual machines, attached domain controller disks to dump Active-Directory databases, and installed tunnelling tools such as Chisel, MobaXterm, ngrok, Pinggy, Rsocx, and Teleport to communicate with command-and-control servers. crowdstrike.com ExtraHop’s mid-July report highlighted that the group relies heavily on typo-squatted domains impersonating corporate portals; domains such as “7-eleven-hr[.]com,” “citrix-okta[.]com” and “pfchangs-support[.]com” were among those identified. extrahop.com Picus Security added that Scattered Spider repurposes abandoned company domains like “twitter-okta[.]com” and uses dynamic-DNS subdomains (e.g., “klv1[.]it[.]com”) to host its phishing kits. picussecurity.com.

Researchers cautioned that copycat actors already adopt Scattered Spider’s playbook and that defenders should not become complacent. The Hacker News noted that, although Mandiant had not seen new intrusions directly attributable to the group since the arrests, other actors such as UNC6040 mimicked its social-engineering tactics. thehackernews.com Accordingly, security teams are advised to ingest known indicators into their SIEMs, monitor for suspicious domain resolution, and pay close attention to help-desk interactions and MFA reset requests. Monitoring for remote-access tools (AnyDesk, TeamViewer, ScreenConnect, Teleport) and ransomware families (DragonForce, ALPHV/BlackCat, RansomHub) is also crucial. rapid7.com controlrisks.com

July's findings underscore that although Scattered Spider may experience temporary setbacks, it poses a significant risk across various industries. In response, NetWitness’s FirstWatch team has proactively integrated previously identified indicators of compromise from Scattered Spider into its Threat Feed to strengthen defenses.

Domain-based IoCs

IoC (Domain)	Source
7elevenhr[.]com	ExtraHop extrahop.com
activecampiagn[.]net	ExtraHop extrahop.com
acwaapple[.]com	ExtraHop extrahop.com
bbtplus[.]com	ExtraHop extrahop.com
bellhr[.]com	ExtraHop extrahop.com
bestbuycdn[.]com	ExtraHop extrahop.com
birdsso[.]com	ExtraHop extrahop.com
citrixokta[.]com	ExtraHop extrahop.com
commonspiritcorpokta[.]com	ExtraHop extrahop.com
consensysokta[.]com	ExtraHop extrahop.com
corphubspot[.]com	ExtraHop extrahop.com
ctscomcast[.]com	ExtraHop extrahop.com
doordashsupport[.]com	ExtraHop extrahop.com
duelbitscdn[.]com	ExtraHop extrahop.com
freshworkshr[.]com	ExtraHop extrahop.com
geminisso[.]com	ExtraHop extrahop.com
guccicdn[.]com	ExtraHop extrahop.com
itbitokta[.]com	ExtraHop extrahop.com
iyft[.]net	ExtraHop extrahop.com
klaviyohr[.]com	ExtraHop extrahop.com
login.freshworkshr[.]com	ExtraHop extrahop.com
aplikacijeintercom[.]com	ExtraHop extrahop.com
morningstarokta[.]com	ExtraHop extrahop.com
mytsl[.]net	ExtraHop extrahop.com
oktaziffdavis[.]com	ExtraHop extrahop.com
pfchangssupport[.]com	ExtraHop extrahop.com
prntsrc[.]net	ExtraHop extrahop.com
pureokta[.]com	ExtraHop extrahop.com
signinnydig[.]com	ExtraHop extrahop.com
simpletextingcdn[.]com	ExtraHop extrahop.com
squarespacehr[.]com	ExtraHop extrahop.com
sytemstern[.]net	ExtraHop extrahop.com
ssoinstacart[.]com	ExtraHop extrahop.com
stsvodafone[.]com	ExtraHop extrahop.com
twitterokta[.]com	Picus Security picussecurity.com
xngryscaleox0d[.]com	ExtraHop extrahop.com
xsso[.]com	ExtraHop extrahop.com
klv1[.]it[.]com	Picus Security picussecurity.com
trycloudflare[.]com	CrowdStrike crowdstrike.com
googlemail[.]com	CrowdStrike crowdstrike.com

IoC (Tool/Malware)

IoC (Tool/Malware)	Type	Source
AnyDesk, TeamViewer, ScreenConnect (ConnectWise), Splashtop	Legitimate remote-access tools repurposed for persistent access	CISA, Rapid7 & Control Risks rapid7.com controlrisks.com
Teleport	Infrastructure-access tool installed on compromised servers for persistent C2 channels	Rapid7 & Rewterz rapid7.com rewterz.com
FleetDeck	RMM platform abused for remote access	Rapid7 rapid7.com
Chisel (communicates with trycloudflare subdomains)	Protocol tunnelling tool used inside VMware environments	CrowdStrike crowdstrike.com
MobaXterm, ngrok, Pinggy, Rsocx	Proxy/tunnelling tools used for C2	CrowdStrike crowdstrike.com
S3 Browser	Tool used to enumerate and exfiltrate AWS S3 buckets	CrowdStrike crowdstrike.com
Evilginx / Evilginx2 phishing proxies	Adversary-in-the-middle kit capturing session cookies and MFA tokens	ExtraHop extrahop.com
Spectre RAT	Custom remote-access trojan (malware-as-a-service) with enhanced obfuscation	Picus Security picussecurity.com
DragonForce ransomware	Ransomware family linked to Scattered Spider	CISA & multiple articles cisa.gov
ALPHV/BlackCat, RansomHub, Qilin, Avaddon	Ransomware families associated with Scattered Spider or affiliates	Control Risks controlrisks.com
Ave Maria (Warzone RAT), Raccoon Stealer, Vidar Stealer, Ratty RAT	Data-stealing malware used in campaigns	The Hacker News thehackernews.com
STONESTOP/POORTRY	BYOVD toolset (malicious drivers) used to disable endpoint protection	Rapid7 rapid7.com

Using RSA Logs and/or Packets to Send or Receive Data from/to LogStash – Putting it all together - Demonstration

Admin — Tue, 17 Jun 2025 04:00:00 GMT

What is LogStash:

LogStash is an Elastic product that can collect, parse, and transform logs to be presented to some type of output such as an Elastic Stack or a RSA Decoder or Virtual Log Collector.

https://www.elastic.co/downloads/logstash-oss

Why LogStash:

Depending on the environment, LogStash can act as an intermediary to process data from various sources and send it to a specified destination, called an output. I can think of three simple examples for the RSA use case. The first example is sending data from the data lake to Netwitness. The second is sending data from Netwitness to other sources. Finally, it can also be configured to collect data from various sources and send that data to Netwitness or the data lake.

https://en.wikipedia.org/wiki/Data_lake

RSA LogStash Components:

As mentioned above there are several scenarios. Depending on the configuration ether the Codec or Export Connector will be used.

LogStash Codec:

https://community.netwitness.com/s/article/InstallandConfiguretheNetWitnessCodec

The Codec is used forward Logstash events to the NetWitness Platform in RFC-5424 format, you need to install the NetWitness codec on your system and refer to it in your output plugin configuration.

Example:

Data Lake/Warehouse, Syslog, etc --> LogStash --> RSA Decoder

LogStatsh Export Connector:

https://community.netwitness.com/s/article/NetWitnessExportConnectorDeployment

Logstash Output plugin to send the input events to a data warehouse destination.

Example:

RSA Decoder --> LogStash --> Data Lake/Warehouse

Supporting Documentation:

Export Connector Install: Configure Logstash Output Plugin

Logstash:Install Logstash

The Process:

The process is fairly simple but LogStash is a product external to RSA and managed by Elastic. Because of this, it will be necessary to download LogStash and create its own virtual machine. This demonstration will provide a foundation to learn more about the process and how everything interacts.

Preparation for the demonstration:

Download the CentOS 7 iso.

CentOS Mirrors List

Download LogStash if you want to manually install it. This demo will pull it directly using the rpm –import method.

Download Logstash Free • Get Started Now | Elastic

Once CentOS is installed, the following items are going to be required for the Demo. The actual install, may be different, so please note this.

Minimal Install of Centos 7

The minimal install is all that the demo requires

add jre for keytool

Keytool is required for the demo certificate process

yum install java-11-openjdk-devel

yum install mlocate

mlocate is used to quickly search for files

----> Begin initial setup

Demonstration

(view in My Videos)

Download and install the public signing key:Insert into logstash.repo

   rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

   vi /etc/yum.repos.d/logstash.repo‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Copy and paste into the new file

[logstash-7.x]
name=Elastic repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The repository is ready for use. You can install it with:

yum install logstash
systemctl enable logstash.service #Adds to startup
reboot
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Check the LogStash status to make sure the LogStash service automatically starts after the reboot

systemctl status logstash‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Download and copy the connector to tmp (WinSCP) - netwitness-export-connector-1.1.0.zip

systemctl stop logstash
cd /usr/share/logstash
bin/logstash-plugin install file:///tmp/netwitness-export-connector-1.1.0.zip
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Validate the connector is installed

bin/logstash-plugin list‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Add the following to the conf file (this initiates data pull via the decoder api on the decoder 50104)

vi /etc/logstash/conf.d/netwitness-192.168.2.121-input.conf‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

input {
netwitness_export_connector {
host => "192.168.x.x" #Decoder IP Address
username => "admin" #API username
password => "your_password" #API password
decoder_type => "decoder"
}
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Clean up the input.conf to make sure there are no characters that cannot be seen

sed -i -e 's/\r$//' /etc/logstash/conf.d/netwitness-192.168.x.x-input.conf‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Restart LogStash to load the input.conf

systemctl start logstash
tailf /var/log/logstash/logstash-plain.log... if you see regex errors check E.3 again
Look for a different sessionid
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Test with TCPDump

cd /tmp
tcpdump -i eth0 -A -nvvv port 50004 -s 65535 -w logstashDump.txt
tcpdump -r logstashDump.txt‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Example History for the export connector

[root@localhost conf.d]# history
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
vi /etc/yum.repos.d/
vi /etc/yum.repos.d/logstash.repo
yum install logstash
systemctl enable logstash.service
reboot
systemctl status logstash
systemctl stop logstash
cd /usr/share/logstash
bin/logstash-plugin install file:///tmp/netwitness-export-connector-1.1.0.zip
systemctl start logstash‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

----> Begin with the certificate section

Demonstration: No Audio

(view in My Videos)

On the LogStash Server

If there is an existing certificate authority proceed to step 2. (Step 1) - The certificates can be called what ever fits the environment.

openssl genrsa -out CA-key.pem 2048 
openssl req -new -key CA-key.pem -x509 -days 2000 -out CA-cert.pem
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Resume Certificate Process (Step 2)

openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -out signingReq.csr (set a password)
openssl x509 -req -days 1000 -in signingReq.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out server-cert.pem
openssl pkcs12 -export -in server-cert.pem -inkey server-key.pem -certfile CA-cert.pem -out logstash-input-netwitness.p12 (set export password)
mkdir /etc/pki/logStashDecoder (on the logstash server)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

On the decoder

scp /etc/pki/nw/trust/truststore.pem root@192.168.x.x:/etc/pki/logStashDecoder‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

if known_host contains a key for this host you may want to delete it.

vi ~/.ssh/known_hosts‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

LogStash Server

keytool -importcert -keystore logstash-input-netwitness.p12 -trustcacerts -alias nw-inter -file /etc/pki/logStashDecoder/truststore.pem -storetype PKCS12 (enter password)
Trust this certificate: yes
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

cp logstash-input-netwitness.p12 /etc/logstash
chown logstash:logstash /etc/logstash/logstash-input-netwitness.p12
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Curl to the Decoder API

curl -X POST -d server-cert.pem https://192.168.2.121:50104/sys/trustpeer
curl -X POST -d server-cert.pem https://192.168.2.121:50104/sys/caupload
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

alternative to the curl command above - If using the rest interface is preferred (trustpeer and caupload)

https://192.168.x.x:50104/sys/trustpeer

https://192.168.x.x:50104/sys/caupload

copy and paste the server-cert.pem

Check the certificate exists on the Decoder

cd /etc/netwitness/ng/decoder/trustpeers‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Change the keystore password on logstash - current password is changeit

keytool -storepasswd -keystore /usr/lib/jvm/java-11-openjdk-11.0.9.11-0.el7_9.x86_64/lib/security/cacerts
Untrusted certificate from above (ex. your_password)
keytool -importcert -file /etc/pki/logStashDecoder/truststore.pem -keystore /usr/lib/jvm/java-11-openjdk-11.0.9.11-0.el7_9.x86_64/lib/security/cacerts -alias nw-core-cert -storepass your_password


‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

   systemctl restart logstash‍‍‍‍‍‍‍‍‍

   tailf /var/log/logstash/logstash-plain.log‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Please let me know your thoughts or suggestions, as this is a work in progress.

Test 2 Blog from Composer Updated

Admin — Fri, 21 Mar 2025 04:00:00 GMT

Second composer blog. Update immediately published! And then republished

From Webshell to C2: The Evolution of Post-Exploitation and Covert Operations

Admin — Sun, 23 Feb 2025 05:00:00 GMT

From Webshell to C2: The Evolution of Post-Exploitation and Covert Operations

Authors:

Mortada AboSteit, Senior Consultant Incident Response

Mohamed Osama, Senior Consultant Incident Response

Abdelrahman Bakry, Senior Analyst Incident Response

Introduction

In the realm of advanced cyber threats, attackers often exploit overlooked vulnerabilities to establish an initial foothold within a compromised environment. Among these vulnerabilities, those related to insufficient input validation stand out as a prevalent and dangerous category. Examples include SQL injection, where malicious input manipulates database queries; cross-site scripting (XSS), which allows attackers to inject harmful scripts into web pages; and file inclusion vulnerabilities, such as Local File Inclusion (LFI), which can expose sensitive server files. These flaws provide attackers with numerous opportunities to bypass security measures. One specific instance is the absence of input validation in upload functionalities for a misconfigured website, which can serve as an ideal entry point for adversaries to maintain persistence and conduct targeted attacks.

While these exploitation techniques are a common trait of several attackers, the post-exploitation activities differ from one actor to another.

NetWitness Incident Response team recently investigated an attacker who, after exploiting a website’s weak posture uploaded a specific Web Shell to finally implant a Mythic command-and-control (C2).

Mythic is a cross-platform, post-exploitation, red teaming framework built with GoLang, docker, docker-compose, and a web browser UI. It is often used by Red Teams to simulate real attacks, but in this case, a real actor adopted it with the goal of persisting in the victim network.

Understanding the misuse of such tools, particularly when paired with insecure configurations, underscores the critical need for rigorous input validation, secure coding practices, and proactive monitoring to defend against persistent adversaries leveraging Mythic or similar post-exploitation frameworks.

Figure 1: Attack Overview

Tool

Initially developed for red team operations, Mythic has been co-opted by several Threat Actors for malicious purposes. Notably, its versatility and modular design have made it a favored tool for Advanced Persistent Threat Groups (APT) in intrusion campaigns.

The Advanced Persistent Threat (APT) group known as Transparent Tribe, also referred to as APT36 or Mythic Leopard, has been observed utilizing the Mythic Command and Control (C2) framework in their cyber espionage operations. In addition to APT36, other state-sponsored APT groups have been observed utilizing the Mythic Command and Control (C2) framework in their cyber operations.

It is designed to provide a collaborative and user-friendly interface for operators and managers, as well as leverage it throughout the red teaming activities. The tool allows attackers to stealthily manage compromised systems, execute payloads, escalate privileges, and exfiltrate data while evading detection.

The increasing number of cases where the tool has been used by these actors started the idea about developing a blog to delve into detecting Mythic’s activity within a network, particularly for Mythic C2 Agent adopted to execute privilege escalations and lateral movements toward a Domain Controller.

In alignment with our traditional approach, based on the three main investigative dimensions of Network, Endpoint, and Logs, we explore, in this blog, the detection of Mythic based on NetWitness Network (NDR) and Netwitness Endpoint (EDR) platforms, complemented by open-source digital forensics tools. The resulting synergy is able to enhance detection and investigation capabilities.

The Attack

The case we present involved an attack where the Threat Actor was closely adhering to the seven steps of the Cyber Kill Chain.

The attacker started with the Reconnaissance phase, during which he identified that the victim’s website was vulnerable to Unrestricted File Upload. This was followed by exploiting this weakness during the Weaponization phase, where the Threat Actor prepared a WebShell to be directly uploaded to the Web Server.

Subsequently, the Threat Actor leveraged the WebShell's upload functionality as the Delivery method.

Figure 2: Cyber Kill Chain

During the Exploitation Phase, the Threat Actor performed local discovery and enumeration on the webserver leveraging Windows native commands such as Whoami, IPConfig, and Netstat to gather critical information about the compromised machine. This activity was conducted stealthily, evading detection by the SOC team.

Figure 3: Whoami executed on the WebServer

Figure 4: IPConfig executed on the WebServer

Figure 5: Netstat executed on the WebServer

During the Installation stage, the Threat Actor managed to upload and install the C2 implant, masquerading it as a legitimate Notepad++.exe file to have an active callback within the Mythic C2 Server.

Figure 6: Upload and execute C2 Agent

From the Mythic C2 server, an active callback originated from the infected web server, granting the Threat Actor entrenched access. The C2 agent was noticed running with the privilege of the default web engine “Microsoft IIS” user account “IIS APPPOOL\DefaultAppPool”.

Figure 7: Active Callback Channel from the C2 Agent on WebServer

During the Command & Control phase, the Threat Actor executed multiple enumeration commands to gather detailed information about the compromised environment and also to evaluate the inherited granted access of web user “IIS APPPOOL\DefaultAppPool”.

These enumeration attempts were purposed to move laterally in the network, and actively work to escalate privileges to a domain administrator account while targeting access to the Domain Controller.

For enumerating the Domain Controller, the Threat Actor executed “dc_list” followed by “net_shares” to list open shares on the Domain Controller. This was a successful attempt as the Threat Actor was able to identify the presence of the ADMIN$ share, which can surely be used to land on the Domain Controller.

Figure 8: Domain Controller Enumeration

Directly afterward, the Threat Actor adopted a batch script to execute a dictionary attack to crack the domain administrator’s password by leveraging a batch script , and a customized word list which led to successful login to the Domain Controller with a privileged account.

Figure 9: Password Cracking of the Domain Admin Password

After successfully compromising the domain administrator's password, the Threat Actor leveraged Windows Management Instrumentation (WMI) to execute a PowerShell command designed to download and execute the Command and Control (C2) implant on the Domain Controller.

The implant was retrieved from a malicious public domain over a non-standard web traffic port, with the payload deceptively disguised as a legitimate OneDrive.exe file to evade detection.

Figure 10: Abusing WMI to download and execute the C2 Implant on the DC

Now, the Threat Actor has two active callback channels, from the public internet-faced WebServer and the Domain Controller with the user accounts IIS APPPOOL\DefaultAppPool and Domain Administrator respectively.

Figure 11: Two Active callback Channels from the C2 Web Interface

Figure 12: DC local enumeration

In the final phase, Action on Objectives, the Threat Actor employed persistent tactics to maintain access to compromised Domain Controller despite potential disruptions such as system restarts, credential changes, or other actions that could terminate their foothold. The chosen persistence mechanism was the creation of a Scheduled Task, ensuring continued access and control over the infected environment, enabling sustained access to critical systems, particularly the Domain Controller.

This approach facilitated the achievement of the ultimate objective, setting a persistent foothold on the organization’s primary Domain Controller.

Figure 13: Persistence applied to the DC with a Scheduled Task

Incident Triggered by NetWitness Respond Module

On the Netwitness Respond page, the Analyst was prompted by an incident that triggered for the infected Web Server, which pointed to possible lateral movement due to creating Net Utility on the Web Server while remotely attempting to access ADMIN$ share on the Domain Controller.

Figure 14: Incident and Alerts on NW Respond

Detection using NetWitness Network Threat Detection and Response Solution

Netwitness NDR recorded several suspicious HTTP POST connections. These connections coincided with the upload of files bearing suspicious names. Additionally, such anomalous communication aligned with alarming techniques and tactics outlined in the MITRE ATT&CK framework.

Figure 15: Suspicious Files uploaded to the Web Server

Based on the above detection, the Analyst focused the investigations on the suspicious file name login.aspx and was able to analyze the raw packets related to the same HTTP Post request.

Figure 16: Post Request placing web shell on the Web Server

Leveraging the advanced capabilities of NetWitness NDR, particularly the Packet Reconstruction feature, the Analyst conducted an in-depth investigation of an HTTP POST request. This analysis enabled the full reconstruction of a file, login.aspx, uploaded during the same HTTP session. The file was identified as a web shell, equipped with upload and execution functionalities.

Figure 17: Reconstructed Webshell reconstructed by NW NDR

Through the reconstruction of subsequent sessions associated with the same HTTP POST request, the Analyst uncovered the commands executed by the Threat Actor, along with the corresponding outputs for each command.

Figure 18: Reconstruction to Whoami Cmnd

Figure 19: Reconstruction to IPConfig Cmnd

Figure 20: Reconstruction to Netstat Cmnd

To deepen the investigation, the

Using NetWitness to Detect Phishing reCAPTCHA Campaign

Admin — Wed, 16 Oct 2024 04:00:00 GMT

Using NetWitness to Detect Phishing reCAPTCHA Campaign

Author: Mohamed Osama, Senior Consultant Incident Response, NetWitness

Introduction

Recently, a sophisticated phishing campaign mimicking reCAPTCHA technology, which stands for Completely Automated Public Turing test to tell Computers and Humans Apart, has been targeting unsuspecting employees across various sectors.

The campaign capitalizes on social engineering techniques, tricking victims into bypassing security measures by convincing them to paste malicious code into their systems. Using the familiar and trusted reCAPTCHA interface, attackers can lure employees into believing that they are merely verifying their identity to access legitimate websites or services, while in reality, they are inadvertently initiating a harmful process that compromises their machine.

Once the malicious code is executed, it installs an infostealer malware designed to siphon sensitive information from the infected device. This malware also establishes a backdoor, allowing attackers to remotely control the system through a Command-and-Control (C2) server. The lack of cybersecurity awareness among many employees has made this campaign particularly effective, as the phishing webpage appears authentic and exploits the perceived security of reCAPTCHA. This attack highlights the critical need for enhanced employee training and awareness to defend against evolving cyber threats.

The current campaign is leveraging multiple redirections over different websites, which finally ends with the reCAPTCHA web page. It usually consists of a landing HTML page with embedded encoded mshta or PowerShell command line arguments for downloading and invoking the malicious code respectively. In addition, it has been observed that mshta, a Windows-native binary designed to execute Microsoft HTML Application (HTA) files, was also abused for downloading compressed ZIP files that eventually decompress and execute the infostealers on the compromised machine.

This campaign has been tracked by NetWitness Incident Response team, among other vendors as well. It is known to install infostealer malware, specifically Lumma Stealer however, in this blog post, I will leverage a stealthier file-less approach that directly leads to Command-and-Control (C2) and a complete takeover of the compromised machine by the threat actor.

Figure 1: Attack Diagram

Tool

The fake reCAPTCHA code has been publicly available on GitHub for many years as of the time of this blog. I used a publicly available reCAPTCHA GitHub repository where the available code leverages an index.html landing web page that mimics the reCAPTCHA format, with additional instructions to paste a specific line, which looks innocent enough to lure the user into completing the verification process.

Figure 2: Full view of fake reCAPTCHA web page

The available reCAPTCHA code, totally created for PoC purposes, is analyzed as per below.

Figure 3: Analysis of index.html

Figure 4: Analysis of recaptcha-verify.html

In this blog, I will only leverage the landing page, index.html, to execute a PowerShell command for downloading and invoking a malicious C2 Stager into a hidden spawned PowerShell process. The C2 chosen is SilentTrinity, which was covered in detail in another blog post. This is just another PoC where a fileless technique can be leveraged to directly initiate a C2 communication with the threat actor, evading the detection of multiple EPP (Endpoint Protection Platform) and EDR (Endpoint Detection and Response) solutions.

The Attack

The attack unfolds as per below cyber kill chain.

Figure 5: Cyber kill chain

The weaponization stage includes the attacker crafting a fake reCAPTCHA index.html code through hardcoding a Base64 encoded PowerShell command, which downloads the SilentTrinity C2 stager.ps1 script and injects it in the memory of a hidden spawned PowerShell running process. Afterwards, the attacker creates suspicious websites redirecting to the malicious reCAPTCHA landing web page.

Figure 6: Customized index.html

The delivery method is favored by the attacker to be a phishing email tricking the user into clicking an inserted hyperlink towards the suspicious websites, thus assuring that the user will be prompted with the fake reCAPTCHA page.

The reCAPTCHA web page will appear normal to untrained eyes where it will instruct the user to paste some content into the Run prompt of the machine. We can also notice that the entered phrase looks typical to the one in the instructions.

Figure 7: reCAPTCHA verification steps

Figure 8: Run prompt with reCAPTCHA lure message

However, scrolling backwards in the entered phrase shows the actual command preceding the lure verification message.

Figure 9: Hidden command preceding lure message

Once the user clicks OK, the C2 implant will be loaded and initiates a stealthy communication and beaconing with the C2 server.

Figure 10: C2 stager pulled from C2 attack server

Figure 11: PowerShell checking in with C2 attack server

At this point, the threat actor acquired full remote control over this compromised machine, where some local system enumeration commands are fired however, the attack’s magnitude can vary depending on the level damage and impact the threat actor can induce on such compromised machine and corresponding corporate network.

Figure 12: System enumeration commands executed

The Detection Using Endpoint Telemetry Data

From NetWitness Endpoint perspective and during frequent hunting activities, the analyst observed multiple behaviors of compromise (BOC) generated pointing to peculiar PowerShell executed.

Figure 13: NetWitness Investigate page highlighting anomalous PowerShell activity

The analyst thoroughly checked the command line arguments and discovered multiple attempts to execute a PowerShell process with encoded command leveraging the below flags:

-nop: Does not load the Windows PowerShell profile
-w hidden: WindowStyle set to be hidden
-ep bypass: Temporarily bypass the execution policy and run scripts in a single PowerShell session
-ec: Accepts a base-64-encoded string version of a command.

The analyst also notices a reCAPTCHA verification message following the executed commands.

Figure 14: Command line arguments executed by PowerShell

Focusing the analysis on spawned PowerShell processes leads to the discovery of multiple generated MITRE ATT&CK and NetWitness alerts.

Figure 15: MITRE ATT&CK and NetWitness alerts generated

The analysis continues to uncover PowerShell process map, where its parent process is identified to be explorer.exe, a native Microsoft Windows corresponding to Windows GUI shell. NetWitness process map points out multiple child processes spawned by PowerShell, such as whoami and netstat.

Figure 16: PowerShell process map

Note

As I did not utilize the second web page (reCAPTCHA-verify) of the used PoC in this attack scenario, it is not highlighted in the previous detection section. However, leveraging another web page or even mshta to download malicious content on the victimized machine would be easily detected through the following Behavior of Compromise (BOC) populated values.

boc = ‘lolbas initiates network connections’,’mshta runs powershell’

Figure 17: Suspicious mshta activity

Figure 18: Command line argument executed by mshta

Figure 19: Generated BOCs for mshta running PowerShell

The Detection Using Packet Data

As the analysis continues, the analyst shifts the investigation towards the packet perspective, where the analyst discovers multiple anomalous HTTP protocol characteristics populating values under meta key analysis.service. This is coupled with alarming MITRE ATT&CK techniques and tactics, along with non-standard TCP ports used in the communication.

Figure 20: Peculiar HTTP communication over non-standard ports

The analyst took a deeper dive inside this communication, where hardcoded PowerShell command is discovered within an HTML file representing the server’s response.

Figure 21: Raw packet analysis showing encoded PowerShell command

The analyst reconstructed the raw packet in its original form, a web page, and it was clearly a loaded reCAPTCHA page holding some strange instructions to follow.

Figure 22: reCAPTCHA web page reconstructed by NetWitness

Following the logical investigation stream, the analyst focused the analysis on all the communication between the possibly compromised machine and the anomalous web server simulating a reCAPTCHA web page. Accordingly, other indicators are surfaced leading to the discovery of SilentTrinity C2 as in below.

Figure 23: SilentTrinity IOCs generated by NetWitness

Figure 24: C2 stager GET request by the victim machine

Figure 25: C2 Beaconing and Communication

Note

For building up a detection rule to trigger upon the discovery of plaintext keywords within a raw packet (ex: HTML page), NetWitness Search Pattern rule can be easily leveraged. However, if NetWitness Packets is on version 12.3 or earlier, then a possible workaround is to leverage the built-in native SEARCH parser, which can be enabled from NetWitness Decoder config page, it loads its configuration from search.ini file under the same config page of the decoder.

Figure 26: Native SEARCH parser

The below lines can be added to search.ini file as in below.

[reCAPTCHA_Detected]

Services=80;8080;8000

Keywords= reCAPTCHA ;Captcha ;textToCopy ;copy ;commandToRun ;powershell

Case=0

[execCommand_JavaScript_Method_Detected]

Services=80;8080;8000

Keywords= document.execCommand

Case=0

Figure 27: Customized search.ini file

The logic of the above configuration lines is to look for specific keywords, such as document.execCommand (JavaScript method) among other keywords, which would be possibly alarming if discovered. Decoder’s parsers need to be reloaded afterwards, from Decoder’s explore page.

Figure 28: Parser's reload signal

Afterwards, an Application rule can be created to alert on Indicators of Compromise (IOC) meta key.

Figure 29: reCAPTCHA Application rule condition

At this point, if a raw packet is exposing keywords as configured, NetWitness would alert as below.

Figure 30: reCAPTCHA application rule triggered

Investigation

At this moment of the analysis, the analyst should be able to quickly triage the compromised machine. Multiple approaches can be applied. One of the most optimal ones is to analyze the RunMRU (Run Most Recently Used) registry hive, which is populated when a user enters a command into the START > Run prompt. Entries will be logged in the user hive under this path.

Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Based on the below collected artifact, the analyst identifies an encoded PowerShell command executed in the Run prompt of this specific user. This confirmed that the victimized user followed the reCAPTCHA malicious instructions.

Figure 31: Analysis of RunMRU registry hive

Accordingly, another approach that could be extremely useful during lite forensics phase is to acquire the PowerShell’s process memory and pinpoint injected malicious code.

Figure 32: PowerShell memory dump analysis showing executed command

Figure 33: Whoami command captured in the analyzed PowerShell process memory

Figure 34: Abstract of the injected C2 PowerShell script into the process' memory

Conclusion

Cybersecurity awareness is a fundamental component of an organization's security posture, as even the most robust technical defenses can be undermined by an uninformed employee making a simple mistake. Innocent actions, such as clicking on a phishing link or unknowingly executing malicious code from a fake reCAPTCHA page, can lead to critical breaches, allowing attackers to bypass security controls and infiltrate the network. This underscores the importance of continuous security training for all staff, combined with the implementation of advanced detection and response technologies like Network Detection and Response (NDR), Endpoint Detection and Response (EDR), and Security Information and Event Management (SIEM). These technologies work together to monitor and detect suspicious activity, provide visibility across the network, and enable swift incident response, ensuring that human error is mitigated by layered defenses and proactive security measures.

Netwitness Platform Integration with Amazon Elastic Kubernetes Service

Admin — Wed, 07 Aug 2024 04:00:00 GMT

Kubernetes:

Kubernetes is an open-source system that helps us to run and management of containerized applications and workloads. It is a distributed system consisting a cluster of control plane nodes and worker nodes. The worker nodes host the Pods that are the components of the application workload. The control plane manages each node in the cluster.

Components of a Node:

kubelet: It is an agent node that runs on each node in a cluster and communicates with control plane. It runs health checks and reports them.
container runtime: It is a software that helps run the containers.
kube-proxy: It is an agent that translates service object to network rules in the nodes.

Components of Control plane:

kube-apiserver: It is the front-end component of control plane that exposes the Kubernetes API.
kube-scheduler: It watches each pod and makes sure it is assigned to a node.
kube-controller-manager: It is a control plane component that runs all control processes like node controller, job controller, Service Account controller and EndpointSlice controller.
cloud-controller-manager: This is a component that runs controller processes that are only specific to cloud provider like checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding (node controller) or setting up routes in the underlying cloud infrastructure (route controller) or creating, updating and deleting cloud provider load balancers (service controller)
etcd: It is a key-value data store to store all critical information throughout the cluster.

Amazon Elastic Kubernetes Service (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on Amazon Web Services. Amazon EKS ensures every cluster has its own unique Kubernetes control plane to avoid overlaps of cluster or aws accounts. The Amazon EKS architecture can be referred here: Amazon EKS architecture - Amazon EKS

Amazon EKS provides built-in tools for logging. The EKS audit and diagnostic of control plane can be forwarded to Amazon CloudWatch and these logs are sent as log streams to a group for each Amazon EKS cluster in CloudWatch.

For configuring logging to CloudWatch refer: https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

Netwitness Platform now has integrated the Amazon EKS control plane logs with Amazon CloudWatch plugin.

To take advantage of this new capability within RSA NetWitness, please visit the link below and search for the terms below in RSA Live.
Configuration Guide: https://community.netwitness.com/s/article/AWSCloudWatchEventSourceLogConfigurationGuide
Collector Package on RSA Live: "Log Collector configuration content for event source Amazon CloudWatch"
Parser on RSA Live: Kubernetes