{
	"id": "85f51acd-529f-4303-b648-34778e454592",
	"created_at": "2026-04-10T03:21:29.409044Z",
	"updated_at": "2026-04-10T03:22:17.568871Z",
	"deleted_at": null,
	"sha1_hash": "55aa66199d9b854b613d3a8a400c382d014c9759",
	"title": "Novel Fake CAPTCHA Chain Delivering  Amatera Stealer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 80338,
	"plain_text": "Novel Fake CAPTCHA Chain Delivering  Amatera Stealer\r\nArchived: 2026-04-10 02:40:35 UTC\r\nThe Blackpoint SOC has identified a new Fake CAPTCHA campaign that leverages a signed Microsoft Application\r\nVirtualization (App-V)1 script, SyncAppvPublishingServer.vbs, as a LOLBIN to proxy execution through a legitimate\r\nWindows component. Instead of launching PowerShell directly, the attacker uses this script to control how execution begins\r\nand to avoid more common, easily recognized execution paths. \r\nEarly stages are designed to validate execution order and user behavior rather than exploit a vulnerability. Progression is\r\ngated on conditions established during the initial interaction, and when those expectations are not met, execution quietly\r\nstalls. This reinforces that the delivery flow itself is a core part of the attack, not just a means to reach the final payload. \r\nAs the chain progresses through several additional in-memory stages, it makes two notable pivots. First, it pulls live\r\nconfiguration from a public Google Calendar file, an example of attackers living off someone else’s infrastructure to keep\r\ndelivery logic flexible. Later, it uses PNG-based steganography to deliver an encrypted payload hidden inside an image,\r\nwhich is extracted and executed entirely in memory. \r\nThe chain ultimately ends with the delivery of Amatera Stealer, a well-known information stealing malware family. What\r\nmakes this campaign worth paying attention to isn’t the payload itself, but how deliberately it avoids drawing attention along\r\nthe way. By chaining together signed Microsoft components, execution gates based on user behavior, third-party services,\r\nand fully in-memory stages, the actor is optimizing for reliability. This is the kind of activity that can slip past environments\r\nbuilt to detect obvious malware, quietly succeed without triggering alarms, and only surface once the damage is already\r\ndone. \r\nKey Findings  \r\nThe campaign uses a Fake CAPTCHA lure, proxying execution through the signed App-V script SyncAppvPublishingServer.vbs. \r\nEarly stages verify user interaction and execution order using environment and clipboard state, stalling execution\r\nwhen those checks fail. \r\nSubsequent PowerShell stages rely on alias and wildcard abuse to dynamically resolve sensitive cmdlets at runtime. \r\nConfiguration for later stages is pulled from a public Google Calendar (.ics) file, allowing delivery logic to be\r\nupdated without redeploying earlier stages. \r\nPayload delivery later in the chain uses PNG based steganography, with encrypted PowerShell content embedded\r\ninside image files. \r\nThe embedded payload is extracted, decrypted, and decompressed entirely in memory before execution transitions\r\nfrom PowerShell into native shellcode. \r\nThe final payload delivered is Amatera Stealer, an information stealing malware family commonly used to harvest\r\nbrowser data and credentials. \r\nObserved Killchain \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 1 of 12\n\nPublishing More than Applications \r\nThe infection chain begins with a Fake CAPTCHA social engineering prompt, a technique that has become increasingly\r\ncommon over the past year. The user is instructed to manually paste and execute a command via the Run dialog, framed as\r\na required step to complete a human verification check (Figure 1). \r\nFigure 1: Fake CAPTCHA prompting execution via the Run Dialog \r\nInstead of invoking PowerShell directly, the supplied command instead abuses SyncAppvPublishingServer.vbs, a signed\r\nMicrosoft script associated with Application Virtualization (App-V). Under normal conditions, this script is used to\r\npublish and manage virtualized enterprise applications. In this campaign, it serves as a LOLBIN, allowing the attacker to\r\nproxy PowerShell execution through a trusted Microsoft component. \r\nExecution is initiated via wscript.exe, altering the process ancestry from the more common and detection\r\nfriendly explorer.exe → powershell.exe chain. Instead, execution flows through wscript.exe and an App-V publishing\r\nscript (Figure 2), which can fly under the radar as legitimate activity on systems where App-V components are present. \r\nFigure 2: Fake CAPTCHA execution process tree with SyncAppvPublishingServer.vbs \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 2 of 12\n\nIt’s important to note that App-V components are not universally available. App-V is built into\r\nmodern Enterprise and Education editions of Windows 10 and Windows 11, as well as modern Windows\r\nServer versions, but is not present on standard Home or Pro installations. On systems where App-V is absent or not\r\nenabled, the command fails outright, and the infection chain does not progress. This is significant for two reasons: it disrupts\r\nexecution in many sandbox and security research environments that lack App-V components, and it naturally filters out\r\nlower value, single user hosts in favor of enterprise managed systems. \r\nAs part of the initial execution, the command sets a temporary environment variable named ALLUSERSPROFILE_X to a\r\nshort opaque value. By itself, this variable is meaningless; however, it becomes important later when it acts as a marker\r\nproving the user executed the command manually, an execution gate. \r\nThe embedded PowerShell logic avoids embedding obvious strings by reconstructing functionality at runtime using aliases\r\nand wildcard resolution. Rather than calling sensitive cmdlets directly, the script uses shorthand aliases and pattern matching\r\nto resolve them indirectly. For example, gal is an alias for Get-Alias, and gal i*x retrieves the alias matching iex,\r\nwhich resolves to Invoke-Expression. Similarly, gcm is an alias for Get-Command, and gcm *stM* resolves to Invoke-RestMethod through wildcard matching.  \r\nOnce reconstructed, the logic retrieves a remote script hosted on attacker-controlled infrastructure and executes it entirely in\r\nmemory, transitioning execution from user assisted interaction into a fully automated loader chain. \r\nThe returned script, called herf54, contains no instantly readable PowerShell logic (Figure 3). Instead, it consists of\r\nthousands of variables with cmdlet-looking names, each storing a short base64 encoded fragment. These names exist solely\r\nto mislead static inspection. \r\nFigure 3: First lines of herf54, storing base64 fragments for later use \r\nAt runtime, these fragments are assembled into an ordered array, concatenated into a single base64 string, decoded, and\r\nexecuted in memory using ScriptBlock.Create. This stage’s sole purpose is to reconstruct and execute the next loader while\r\nburying it under an avalanche of noise. \r\nThe decoded loader implements its own HTTPS fetch routine\r\nusing System.Net.Sockets.TcpClient and System.Net.Security.SslStream. Instead of relying on Invoke-WebRequest or Invoke-RestMethod, it manually constructs an HTTP GET request, writes it directly to a TLS stream, and\r\nextracts the response body by splitting on the HTTP header delimiter (Figure 4). This approach sidesteps telemetry and\r\ndetections commonly associated with standard PowerShell networking cmdlets. \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 3 of 12\n\nFigure 4: Simplified version of the custom HTTPS request function \r\nOnce this function is defined, the loader immediately enforces an execution gate tied to clipboard contents (Figure 5). The\r\nclipboard access itself is lightly obfuscated but ultimately resolves to Get-Clipboard, and the script searches for a specific\r\nmarker matching $env:ALLUSERSPROFILE_X=’…’. If that marker is not present, the script displays decoy messages\r\nusing WScript.Shell.Popup() and then intentionally stalls by entering an infinite wait state\r\nvia ManualResetEvent().WaitOne(). \r\nFigure 5: Simplified version of the clipboard-based execution gate \r\nThis intentionally inhibits analysis in sandboxes that detonate the script without simulating the expected clipboard state, as\r\nthey do not fail or exit cleanly; they simply wait indefinitely. Only when the expected marker is present does execution\r\ncontinue into the next stage. \r\nPutting Malware on the Calendar\r\nWith the execution gate satisfied, the loader transitions into its next stage by pulling configuration data from a\r\npublic Google Calendar (.ics) file (Figure 6). This approach mirrors a broader pattern seen across modern malware\r\nfamilies, including campaigns that abuse Steam profiles, social platforms, or blockchain based dead drops, where trusted\r\nthird-party services are used to host live configuration data. By externalizing configuration in this way, the actor can rapidly\r\nrotate infrastructure or adjust delivery parameters without redeploying earlier stages of the chain, reducing\r\noperational friction and extending the lifespan of the initial infection vector. \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 4 of 12\n\nFigure 6: Effective Google Calendar configuration data retrieval and parsing\nAlthough it’s presented as a calendar object, an .ics file is just plain text. The loader treats it accordingly, fetching the file\nusing its custom HTTPS routine and manually parsing the contents rather than relying on any calendar specific libraries. It\nscans the file for a VEVENT entry with a SUMMARY value of povvv, using this as a simple selector to ensure it extracts\nconfiguration from the intended event. This approach allows the calendar to contain additional noise or decoy entries\nwithout disrupting execution.\nOnce the correct VEVENT block is located, the loader extracts the associated DESCRIPTION field. Because .ics files\noften wrap long values across multiple lines, the loader first normalizes the field before decoding it. After base64 decoding,\nthe DESCRIPTION resolves to a pipe-delimited configuration string containing three values:\nt=sec-t2[.]fainerkern[.]ru\np=svc-int-api-identity-token-issuer-v2-mn[.]in[.]net\npu=8f0b3df4e0aadf775c9bc934f53b2d17\nEach value in the decoded configuration directly influences subsequent stage delivery. The loader first issues a request\nto hxxps[://]/, discarding the response. This request functions as an additional execution gate, again\ntying progression of the chain to the clipboard-derived token produced during the initial Fake CAPTCHA interaction. By\nreusing the same token at this stage, the actor reinforces execution ordering and ensures that later stages only proceed when\nthe earlier user-driven steps have occurred as intended.\nFrom there, the loader constructs a victim specific subdomain. It gathers a series of environment derived values,\nconcatenates them, hashes the result using MD5, and truncates the output to the first eight hexadecimal characters (Figure\n7). This truncated hash is then used as a subdomain, resulting in a URL of hxxps[://].\n\n/.\nFigure 7: Simplified version of the unique per-victim subdomain generation\nFrom here, the loader assembles another PowerShell stage on the fly. Sensitive method names are resolved dynamically,\nand iex is reconstructed at runtime by extracting characters from $env:ComSpec, again avoiding direct use of high-risk\nstrings. The resulting downloader is Unicode-encoded, base64-encoded, and executed via WMI\nusing Win32_Process.Create, spawning a hidden 32-bit PowerShell instance. This handoff establishes a clean execution\nboundary between the earlier loader logic and the next stage of the chain.\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\nPage 5 of 12\n\nThe script returned by this request does not immediately introduce additional network activity. Instead, it functions as\r\nanother transitional loader intended to derive and execute the next stage. The script reconstructs a large embedded base64\r\npayload, decodes it at runtime, and applies a repeating XOR operation to recover the underlying PowerShell source. The\r\nXOR key used during this process is the string AMSI_RESULT_NOT_DETECTED (Figure 8). \r\nFigure 8: Simplified version of the XOR via the key AMSI_RESULT_NOT_DETECTED \r\nWhile the decryption routine itself is intentionally lightweight, it is sufficient to frustrate static inspection and ensure that\r\nmeaningful content is only revealed through execution. Once decrypted, the recovered PowerShell code is executed directly\r\nin memory via a dynamically generated script block. \r\nPicture Perfect Delivery \r\nAt this point in the execution chain, the campaign incorporates image steganography for payload delivery, hiding an\r\nencrypted and compressed PowerShell payload inside a benign looking PNG image that is retrieved and processed entirely\r\nin memory (Figure 9). \r\nFigure 9: Conceptual version of the PNG image retrieval \r\nRather than downloading another script directly, this stage resolves native WinINet APIs at runtime and uses them to fetch\r\nimage content in a way that closely resembles legitimate browser behavior. The loader dynamically loads wininet.dll and\r\nresolves functions such as InternetOpenA, InternetOpenUrlA, InternetReadFile,\r\nand InternetCloseHandle using LoadLibraryA and GetProcAddress, invoking them through dynamically constructed\r\ndelegates. This approach avoids the native PowerShell networking functions and bypasses many logging and inspection\r\nmechanisms that focus on script-based HTTP activity. \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 6 of 12\n\nThe script attempts to retrieve a benign looking PNG file (Figure 10) from three different CDN hosted URLs, stopping once\r\none successfully returns data. The same image was hosted across the following public image platforms for redundancy: \r\ngcdnb[.]pbrd[.]co \r\niili[.]io \r\ns6[.]imgcdn[.]dev \r\nFigure 10: PNG image retrieved from one of three CDNs \r\nOnce the image is successfully retrieved, the loader uses System.Drawing to construct a bitmap object and directly access\r\nthe raw pixel buffer. From this buffer, it extracts an embedded payload using Least Significant Bit (LSB) steganography, a\r\ntechnique that hides data within the lowest order bits of pixel values without noticeably altering the image’s\r\nappearance (Figure 11). \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 7 of 12\n\nFigure 11: Simplified version of the LSB extraction function \r\nThe loader first reads the initial 64 least significant bits and reconstructs them into an integer value that specifies the exact\r\nlength of the hidden payload. It then sequentially rebuilds each payload byte from eight individual pixel LSBs, continuing\r\nuntil the declared length is reached. This length driven extraction process is fully deterministic and avoids the ambiguity and\r\npattern matching typically associated with heuristic steganographic detection.  \r\nAfter extraction, the recovered byte stream is decrypted using a repeating XOR operation (Figure 12). The XOR key is\r\nderived by XOR-combining two embedded 32-byte arrays, resulting in the fixed ASCII\r\nkey s8YUKQ0CqUd6HNwGSRDZ%Qpux1N9MKHh. Each extracted byte is XORed with the corresponding key byte\r\nusing a repeating key schedule. While this encryption is lightweight, it prevents direct inspection of the embedded content\r\nand preserves the visual and structural integrity of the PNG file. \r\nFigure 12: Conceptual example of XOR key derivation and decryption of the byte stream \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 8 of 12\n\nThe decrypted data is then GZip decompressed in memory and interpreted as UTF-8 PowerShell source code. The resulting\r\nscript is executed directly in memory using Invoke-Expression, continuing the execution into the next stage of the loader\r\nchain. \r\nThe PowerShell code executed at this stage no longer performs any network retrieval or environmental checks. Instead, it\r\nserves as a final self-contained transformation layer that prepares malware execution entirely in memory (Figure 13). \r\nFigure 13: Conceptual logic of final stage PowerShell loader \r\nOnce this script runs, it immediately initializes a 32-byte rolling key alongside a large, embedded byte\r\narray containing encrypted data. Decryption begins with a simple byte-level normalization step, where a fixed constant is\r\nsubtracted from each value. This transformation is not intended to be cryptographically strong, but it is enough to prevent\r\nstraightforward static inspection and force the payload to be evaluated at runtime. \r\nThe script then applies a second, more meaningful decryption pass using a rolling XOR routine. Each byte is XORed with a\r\nposition-dependent key value, and the key itself is mutated as decryption progresses. Because the key evolves with each\r\nprocessed byte, the output depends on the full execution order, making reliable static recovery impractical without emulating\r\nthe entire routine. \r\nAfter decryption completes, the script trims padding data from both the beginning and end of the buffer and decodes the\r\nremaining bytes as UTF-8 text. The resulting content is executed directly in memory. Rather than introducing new logic, this\r\ndecrypted script immediately repeats the same process with a second embedded blob, this time recovering a raw shellcode\r\npayload instead of additional PowerShell source. \r\nFrom here, execution transitions fully out of the PowerShell runtime. The recovered shellcode is staged in memory using\r\nnative Windows system calls, with NtAllocateVirtualMemory used to allocate executable memory\r\nand NtProtectVirtualMemory used to update page permissions, before execution is transferred directly to the shellcode\r\nentry point via a newly created thread. This shellcode functions as a native loader responsible for mapping and executing the\r\nfinal payload. \r\nAll Roads Lead to Amatera \r\nThe shellcode loader ultimately maps and executes a Windows PE payload identified as Amatera Stealer, a modular\r\ninformation stealing malware family. Previously tracked under the ACRStealer name, Amatera has continued to evolve\r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 9 of 12\n\nthrough frequent updates and is commonly delivered through multistage loader chains designed to favor in memory\r\nexecution and limit static artifacts. \r\nAfter execution, the payload establishes outbound Command and Control (C2) communication by connecting directly to a\r\nhardcoded IP address, 212.34.138[.]4, while supplying a spoofed HTTP Host header. In Amatera campaigns, this technique\r\nis used to decouple the network destination from the hostname presented at the application layer. As a result, some\r\nmonitoring and logging tools record the connection under the supplied Host header value rather than the raw IP address,\r\ncausing C2 traffic to be surfaced as an apparently legitimate or unrelated domain. Historically, Amatera samples\r\nhave leveraged this behavior by impersonating well known, high traffic domains such as microsoft.com, google.com,\r\nand facebook.com, reducing the likelihood of immediate scrutiny during routine network triage. \r\nIn this case, the payload instead supplies cdn[.]extreme[REDACTED]videos[.]com as the Host header while\r\ncommunicating directly with the C2 IP. This choice certainly stands out and is somewhat confusing when viewed in the\r\ncontext of earlier Amatera variants. Rather than presenting a high reputation or commonly accessed domain, the selected\r\nhostname is extremely unusual, likely drawing more attention than it deflects. As a result, this implementation arguably\r\nundermines the original purpose of Host header spoofing and may actually be less effective than omitting a spoofed Host\r\nheader altogether. \r\nBeyond its use of Host header spoofing, the network communication stack stands out for how deliberately it avoids standard\r\nWindows networking libraries. Rather than relying on WinHTTP or WinINet, the malware performs socket operations\r\nthrough a WoW64 syscall to NtDeviceIoControl, targeting the \\\\Device\\\\Afd\\\\Endpoint interface. This approach, which\r\nhas been repeatedly observed in Amatera samples, allows the malware to interact directly with the Windows networking\r\nstack while bypassing many user mode API hooks commonly used by EDR and network inspection tooling. \r\nAlthough the payload communicates over TLS, the encrypted channel is treated as a transport layer rather than a security\r\nboundary. All C2 traffic is additionally encrypted at the application layer using Windows SSPI APIs,\r\nincluding AcquireCredentialsHandleA, InitializeSecurityContextA, EncryptMessage, and DecryptMessage. This\r\nlayered encryption model is a recurring characteristic of the Amatera family and ensures that even if TLS traffic is\r\nintercepted or inspected, the contents of requests and responses remain opaque. \r\nBeyond its use of layered encryption, the payload leverages an encrypted GetEndpoints request used as an\r\ninitial coordination step with the C2 infrastructure. The response to this request provides a set of short identifier keys, such\r\nas a, b, c, g, m, o, w, and err, each mapped to an endpoint path supplied by the server. These key value pairs are retained in\r\nmemory and used to route subsequent C2 communications, allowing the malware to rely on paths provided by the server\r\nrather than embedding fixed URLs or static endpoints within the payload itself. \r\nSubsequent C2 requests are issued using HTTP POST with binary payloads, with operational details such as configuration\r\nretrieval, host registration, and tasking embedded entirely within encrypted request bodies rather than exposed through URL\r\nparameters. This communication model limits the amount of contextual information available at the network layer and is\r\nconsistent with patterns observed across Amatera samples. \r\nThe behaviors described above, along with the remaining functionality observed during execution, align closely with what\r\nhas been previously documented for Amatera Stealer. This includes its registration and tracking mechanisms, configuration\r\ndriven behavior, and tasking, all of which reflect its established modular execution model. Notably, the string GETWELL is\r\nalso embedded within the malware, a marker that has been repeatedly observed across Amatera campaigns and is widely\r\nregarded as a reliable indicator of the family. \r\nConclusion \r\nWhat makes this campaign interesting isn’t any single trick, but how carefully thought out everything is when chained\r\ntogether. Each stage reinforces the last, from requiring manual user interaction, to validating clipboard state, to pulling live\r\nconfiguration from a trusted third-party service. The result is an execution flow that only progresses when it unfolds (almost)\r\nexactly as the attacker expects, which makes both automated detonation and casual analysis significantly harder. \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 10 of 12\n\nThe reliance on platforms like Google Calendar and public image CDNs reflects an increasing tendency for attackers to\r\n“live off someone else’s infrastructure”, allowing them to externalize configuration and staging. By storing live parameters\r\nand payload containers in third-party services, the actor can update, rotate, or disable parts of the chain without redeploying\r\nearlier stages. When combined with in-memory execution and steganographic delivery, this design favors operational\r\ncontrol and longevity, allowing the campaign to adapt without exposing new static artifacts. \r\nIn the end, all of this complexity exists to deliver a familiar result: Amatera Stealer, operating with layered encryption,\r\nevasive networking, and modular tasking. That contrast is the real takeaway. The payload isn’t especially novel, but the\r\ndelivery strategy around it is carefully engineered to survive long enough to matter. As fake CAPTCHA lures and user-assisted execution continue to thrive in the wild, defenders are increasingly forced to look beyond what ran and focus on\r\nhow and why it was able to run at all. Understanding those paths, and the trust relationships they abuse, is quickly becoming\r\njust as important as detecting the malware waiting at the end. \r\nRecommendations \r\nRestrict access to the Windows Run dialog via Group Policy to prevent Fake CAPTCHA style command execution. \r\nRemove App-V components where they are not required to eliminate abuse via SyncAppvPublishingServer.vbs. \r\nEducate users to recognize Fake CAPTCHA lures and avoid executing commands presented through pop-ups or\r\nunexpected prompts. \r\nEnable comprehensive PowerShell logging and monitor for alias-heavy, wildcard-based, or dynamically constructed\r\nexecution patterns. \r\nMonitor for suspicious process lineage involving script hosts and PowerShell, such as explorer.exe → wscript.exe\r\n→ powershell.exe → powershell.exe. \r\nAlert on PowerShell execution originating from App-V scripts such as SyncAppvPublishingServer.vbs. \r\nMonitor for outbound connections where the requested Host header or TLS SNI does not align with the resolved IP\r\naddress. \r\nIndicators of Compromise (IOCs) \r\nNetwork\r\nType  Indicator  Context / Notes \r\nDomain  cdn[.]jsdelivr[.]net \r\nCDN abused in the initial Fake\r\nCAPTCHA \r\nDomain   sec-t2[.]fainerkern[.]ru \r\nExecution gate request pulled from\r\nGoogle Calendar \r\nDomain \r\nsvc-int-api-identity-token-issuer-v2-\r\nmn[.]in[.]net \r\nNext stage domain returned from Google\r\nCalendar \r\nDomain   gcdnb[.]pbrd[.]co \r\nCDN used to distribute PNG stage\r\npayload \r\nDomain  iili[.]io \r\nCDN used to distribute PNG stage\r\npayload \r\nDomain   s6[.]imgcdn[.]dev \r\nCDN used to distribute PNG stage\r\npayload \r\nDomain  cdn[.]extreme[REDACTED]videos[.]com  Host header spoofed by Amatera \r\nIP\r\nAddress \r\n212.34.138[.]4  Amatera C2 \r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 11 of 12\n\nFiles \r\nFilename  Hash  Context / Notes \r\n herf54  b61fe68f0b1bef12eed8a34769120d77579af9d3c529ac48dfe82a08eefa001b \r\nRetrieved from initial \r\nCAPTCHA \r\nbasic.ics  64d723ead9b43a049f9c8e23c8d4ec09ffabeac2d9b079c863c89a4aab7c9a45 \r\nMalicious Google Cal\r\n.ics file \r\nN/A  9c35e9f637365706c00acaa050a4510adfcb47e7052b870c6d07f6d4464ac2d2 \r\nIntermediary PowerSh\r\nstage returned from Go\r\nCalendar C2 callout \r\nN/A  3df78f628494b9d8d560ee2841fc3b5da6eecf9397f693f4416dab9e573ce38f \r\nIntermediary PowerSh\r\nstage leveraging PNG \r\nqhs9hr5gPqez.png  bbfc4b48676aa78b5f18b50e733837a94df744da329fe5b1b7ba6920d9e02dc3 \r\nPNG embedded with\r\nPowerShell payload \r\nfOa2bcJ.png  bbfc4b48676aa78b5f18b50e733837a94df744da329fe5b1b7ba6920d9e02dc3 \r\nPNG embedded with\r\nPowerShell payload \r\nYzkCM2.png  bbfc4b48676aa78b5f18b50e733837a94df744da329fe5b1b7ba6920d9e02dc3   \r\nPNG embedded with\r\nPowerShell payload \r\nN/A  5339d1169e2187a482fcbc86ea94e9799bb9dbaf264622595ee6e94b54b51778 \r\nDecompressed PowerS\r\npayload extracted from\r\nPNG \r\nN/A  d8db6df5c28db9967206c652d5f48d46b6f863b4c4abb2f234ce8f41aea601cc \r\nFinal stage PowerShel\r\nshellcode loader \r\nN/A  18dad9cb91fb97a817e00fa0cd1cb9ab59f672b8ddab29f72708787f19bf6aa1 \r\nShellcode loader\r\nfor Amatera \r\nAppendix \r\n1. Microsoft Application Virtualization  \r\nSource: https://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nhttps://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blackpointcyber.com/blog/novel-fake-captcha-chain-delivering-amatera-stealer/"
	],
	"report_names": [
		"novel-fake-captcha-chain-delivering-amatera-stealer"
	],
	"threat_actors": [],
	"ts_created_at": 1775791289,
	"ts_updated_at": 1775791337,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/55aa66199d9b854b613d3a8a400c382d014c9759.pdf",
		"text": "https://archive.orkl.eu/55aa66199d9b854b613d3a8a400c382d014c9759.txt",
		"img": "https://archive.orkl.eu/55aa66199d9b854b613d3a8a400c382d014c9759.jpg"
	}
}