14.9 C
London
Monday, September 9, 2024

Stealth Falcon preying over Center Jap skies with Deadglyph


For years, the Center East has maintained its popularity as a fertile floor for superior persistent threats (APTs). Within the midst of routine monitoring of suspicious actions on the techniques of high-profile clients, some primarily based on this area, ESET Analysis stumbled upon a really refined and unknown backdoor that we now have named Deadglyph. We derived the title from artifacts discovered within the backdoor (comparable to 0xDEADB001, proven additionally in Desk 1), coupled with the presence of a homoglyph assault. To the perfect of our information, that is the primary public evaluation of this beforehand undocumented backdoor, utilized by a bunch that displays a notable diploma of sophistication and experience. Based mostly on the concentrating on and extra proof, we attribute Deadglyph with excessive confidence to the Stealth Falcon APT group.

Deadglyph’s structure is uncommon because it consists of cooperating parts – one a local x64 binary, the opposite a .NET meeting. This mix is uncommon as a result of malware usually makes use of just one programming language for its parts. This distinction may point out separate improvement of these two parts whereas additionally benefiting from distinctive options of the distinct programming languages they make the most of. Totally different language will also be harnessed to hinder evaluation, as a result of combined code is tougher to navigate and debug.

The standard backdoor instructions should not applied within the backdoor binary; as a substitute, they’re dynamically obtained by it from the command and management (C&C) server within the type of further modules. This backdoor additionally options a variety of capabilities to keep away from being detected.

On this blogpost, we take a more in-depth take a look at Deadglyph and supply a technical evaluation of this backdoor, its goal, and a few of the further parts we obtained. We’re additionally presenting our findings about Deadglyph on the LABScon 2023 convention.

Key factors of the blogpost:

  • ESET Analysis found a classy backdoor with uncommon structure that we now have named Deadglyph.
  • The principle parts are encrypted utilizing a machine-specific key.
  • Conventional backdoor instructions are applied through further modules obtained from its C&C server.
  • We obtained three out of many modules – course of creator, file reader, and data collector.
  • We attribute Deadglyph to the Stealth Falcon group.
  • Moreover, we discovered a associated shellcode downloader; we postulate it might doubtlessly be used for set up of Deadglyph.

The sufferer of the analyzed infiltration is a governmental entity within the Center East that was compromised for espionage functions. A associated pattern discovered on VirusTotal was additionally uploaded to the file-scanning platform from this area, particularly from Qatar. The focused area is depicted on the map in Determine 1.

Stealth Falcon preying over Center Jap skies with Deadglyph
Determine 1. Victimology of Deadglyph; the associated pattern was uploaded to VirusTotal from Qatar (in darker colour)

Stealth Falcon (also called Challenge Raven or FruityArmor) is a risk group linked to the United Arab Emirates based on MITRE. Energetic since 2012, Stealth Falcon is thought to focus on political activists, journalists, and dissidents within the Center East. It was first found and described by Citizen Lab, which revealed an evaluation of a marketing campaign of spyware and adware assaults in 2016.

In January 2019, Reuters revealed an investigative report on Challenge Raven, an initiative allegedly using former NSA operatives and aiming on the identical kinds of targets as Stealth Falcon. Based mostly on these two reviews referring to the identical targets and assaults, Amnesty Worldwide has concluded (proven in Determine 2) that Stealth Falcon and Challenge Raven truly are the identical group.

Deadglyph Figure 2
Determine 2. Claudio Guarnieri has related Stealth Falcon with Challenge Raven

In September 2019, we revealed analysis on a backdoor, attributed to Stealth Falcon, that used an uncommon approach, Background Clever Switch Service, for C&C communication. We now reveal the results of our in-depth evaluation of what presumably is the latest addition to Stealth Falcon’s espionage toolset.

Deadglyph backdoor

Deadglyph’s loading chain consists of a number of parts, as illustrated in Determine 3. The preliminary part is a registry shellcode loader, which masses shellcode from the registry. This extracted shellcode, in flip, masses the native x64 a part of the backdoor – the Executor. The Executor subsequently masses the .NET a part of the backdoor – the Orchestrator. Notably, the one part on system’s disk as a file is the preliminary part, which is within the type of a Dynamic Hyperlink Library (DLL). The remaining parts are encrypted and saved inside a binary registry worth.

Deadglyph Figure_02
Determine 3. Deadglyph loading chain parts

Whereas the exact methodology of the preliminary compromise vector just isn’t but decided, our suspicion is that an installer part is concerned in deploying additional parts and establishing persistence inside the system.

In the remainder of this part, we analyze every part.

Registry shellcode loader

Deadglyph’s preliminary part is a tiny DLL with a single export, named 1. This part is persevered utilizing Home windows Administration Instrumentation (WMI) occasion subscription and serves as a registry shellcode loader. It’s executed through the command line rundll32 C:WINDOWSSystem32pbrtl.dll,#1.

The registry shellcode loader begins its operation by decrypting the trail to the encrypted shellcode saved inside the Home windows registry, utilizing RC4. We suspect the trail is exclusive for every sufferer; within the case analyzed right here, the registry path was:

SoftwareClassesCLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg

The basis registry key’s both HKLM or HKCU, relying on whether or not the present course of is operating with elevated privileges or not. The identical logic could be present in additional parts.

Following this, the loader derives a machine-specific RC4 key utilizing the system UUID retrieved from the uncooked SMBIOS firmware desk. Utilizing this key, it masses, decrypts, after which executes the shellcode. It is very important spotlight that this key derivation method ensures that correct decryption received’t happen if the loader is executed on a special pc.

Curiously, the loader will also be configured by a flag in its .information part to make use of a hardcoded key to decrypt the shellcode, as a substitute of the machine-specific one.

We noticed a homoglyph assault mimicking Microsoft Company within the VERSIONINFO useful resource of this and different PE parts. This methodology employs distinct Unicode characters that seem visually related, however on this case not an identical, to the unique characters, particularly Greek Capital Letter San (U+03FA, Ϻ) and Cyrillic Small Letter O (U+043E, о) in Ϻicrоsоft Corpоratiоn.

Registry shellcode

Comprised of two components, the registry shellcode consists of a decryption routine and an encrypted physique. First, the decryption routine rotates every byte of the encrypted physique to the left by one (ROL 0x01). Subsequently, management is transferred to this decrypted physique. The decrypted physique consists of a PE loader and a PE file, the latter being the Executor, which represents the native a part of the backdoor. This loader is accountable for parsing and loading the related PE file.

Executor

The Executor is the native x64 a part of the Deadglyph backdoor, which does the next:

  • masses its configuration,
  • initializes the .NET runtime,
  • masses the embedded .NET a part of the backdoor (the Orchestrator), and
  • acts as a library for the Orchestrator.

First, two default configurations embedded within the .information part are AES-decrypted. The configurations embody varied parameters, together with encryption keys, security and evasion settings, and the entry level of the next part.

In the course of the preliminary execution, these two default configurations are saved inside the Home windows registry, from the place they’re loaded on subsequent runs, enabling the implementation of updates. The registry path for every configuration is generated with the next format:

HKLMSoftwareClassesCLSID{<variable_GUID>}(Default)

<variable_GUID> is a generated GUID, which is exclusive to every sufferer.

Following this, the .NET runtime is initialized, then the Executor RC4-decrypts the .NET a part of the backdoor often called the Orchestrator. The Orchestrator is situated inside the .rsrc part of the Executor. The configuration specifies the Orchestrator’s execution methodology as an entry level. Furthermore, a definite construction is offered to facilitate accessibility of the Executor’s capabilities by the Orchestrator.

After launching the Orchestrator, the Executor acts as a assist library for the Orchestrator. The Executor accommodates many fascinating capabilities; we describe a few of them within the following part, in context of their utilization by the Orchestrator and additional loaded modules.

Orchestrator

Written in .NET, the Orchestrator is the primary part of the Deadglyph backdoor. This part’s major position includes establishing communication with the C&C server and executing instructions, usually facilitated by way of the middleman position of the Executor. In distinction to the previous parts, the Orchestrator is obfuscated, using .NET Reactor. Internally, the backdoor is known as agent, which is a typical title for the shopper half in varied post-exploitation frameworks.

Initialization

The Orchestrator first masses its configuration and two embedded modules, every accompanied by its personal set of configurations, from assets. These assets are Deflate compressed and AES encrypted. They’re referenced by an ID that’s SHA-1 hashed right into a useful resource title. An outline of those assets is offered in Desk 1.

Desk 1. Orchestrator assets

 

Useful resource title

ID (decimal)

ID (hex)

Description

43ed9a3ad74ed7ab74c345a876b6be19039d4c8c

2570286865

0x99337711

Orchestrator configuration.

3a215912708eab6f56af953d748fbfc38e3bb468

3740250113

0xDEEFB001

Community module.

42fb165bc9cf614996027a9fcb261d65fd513527

3740250369

0xDEEFB101

Community module configuration.

e204cdcf96d9f94f9c19dbe385e635d00caaf49d

3735924737

0xDEADB001

Timer module.

abd2db754795272c21407efd5080c8a705a7d151

3735924993

0xDEADB101

Timer module configuration.

The configuration of the Orchestrator and embedded modules is saved in XML format. An instance of an Orchestrator configuration is proven in Determine 4.

Deadglyph Figure_04
Determine 4. Orchestrator configuration

The outline of Orchestrator configuration entries is proven in Desk 2.

Desk 2. Orchestrator configuration entries

Key

Description

okay



AES key used for persisting module configurations.

a



Community module initialization methodology title.

b



Unknown community module-related flag.

c



Timer module initialization methodology title.

d



Flag enabling utilization of machine-specific AES key (system UUID) for assets.

p



Community module useful resource ID.

t



Timer module useful resource ID.

After the useful resource parts are loaded, a number of threads are created to hold out distinct duties. Considered one of these threads is accountable for conducting setting checks, a perform applied inside the Executor. One other thread is dedicated to establishing periodic communication with the C&C server, enabling the retrieval of instructions. Lastly, a set of three threads is employed for the aim of executing obtained instructions and subsequently transmitting any generated output again to the C&C server.

The environment-checking thread displays operating processes to determine undesirable ones. This thread operates with two distinct lists of course of names. If a course of on the primary listing is detected, C&C communication and command execution is paused till the undesirable course of not exists. If there’s a match for any course of on the second listing, the backdoor instantly quits and uninstalls itself.

Neither listing was configured within the analyzed occasion, so we don’t know what processes may usually be checked for; we imagine it’s in all probability supposed to evade evaluation instruments that would detect suspicious exercise and result in discovery of the backdoor.

Communication

The Orchestrator makes use of two embedded modules for C&C communication – Timer and Community. Just like the Orchestrator, these modules are obfuscated with .NET Reactor. The configuration for each modules is equipped by the Orchestrator. Throughout the Orchestrator, a preset configuration for the modules is included; optionally, the Orchestrator may load an up to date configuration model from the registry:

HKLMSoftwareClassesCLSID{<variable_GUID>}<mod_cfg_res_ID>

The backdoor accommodates an fascinating security measure associated to communication. If the backdoor is unable to ascertain communication with the C&C server for a period surpassing a predefined threshold, configured inside the Executor, a self-uninstallation mechanism is triggered. This time threshold is laid out in hours and was set at one hour within the examined case.

This method serves a twofold goal. On one hand, it prevents the era of redundant community requests in the direction of an inaccessible server. Then again, it reduces the possibilities of subsequent detection if the operators lose management over the backdoor.

Timer module

This small module executes the desired callback at a configurable interval. It’s utilized by the Orchestrator together with the Community module to speak with the C&C server periodically. To forestall the creation of detectable patterns in community logs, the execution interval is topic to randomization, primarily based on a proportion specified within the configuration. Within the analyzed occasion, the interval was set to 5 minutes, with a ±20% variation launched for randomness.

One other methodology to keep away from detectable community patterns in periodic communication could be present in era of requests despatched to the C&C server. This mechanism, applied within the Executor, includes the inclusion of padding of various size, comprised of random bytes, inside the requests, leading to requests of various sizes.

Community module

The Community module implements communication with the C&C servers laid out in its configuration. It may well ship information to a C&C server utilizing HTTP(S) POST requests. Notably, it gives a number of mechanisms to accumulate proxy configuration particulars. This characteristic suggests a possible give attention to environments the place direct web entry just isn’t accessible.

An instance of a decrypted (and beautified) configuration is proven in Determine 5.

Deadglyph Figure_06
Determine 5. Community module configuration

Configuration entries comprise particulars associated to community communications – C&C URLs, HTTP Person-Agent, and optionally a proxy configuration.

When speaking with the C&C server, a customized binary protocol with encrypted content material is used beneath HTTPS.

Instructions

The Orchestrator receives instructions from the C&C server within the type of duties, that are queued for execution. There are three sorts of duties processed:

  • Orchestrator duties,
  • Executor duties, and
  • Add duties.

The primary two sorts are obtained from the C&C server and the third is created internally to add the output of instructions and errors.

Orchestrator duties

Orchestrator duties supply the flexibility to handle the configuration of the Community and Timer modules, and in addition to cancel pending duties. The overview of Orchestrator duties is proven in Desk 3.

Desk 3. Orchestrator duties

Kind

Description

0x80



Set configuration of community and timer modules.

0x81



Get configuration of community and timer modules.

0x82



Cancel job.

0x83



Cancel all duties.

Executor duties

Executor duties supply the flexibility to handle the backdoor and execute further modules. It’s notable that the standard backdoor performance just isn’t inherently current inside the binary itself. As a substitute, these capabilities are obtained from the C&C server within the type of PE recordsdata or shellcode. The complete extent of the backdoor’s potential stays unknown with out these further modules, which successfully unlock its true capabilities. An outline of module duties is proven in Desk 4, which incorporates particulars concerning the few recognized modules. Equally, Desk 5 offers an summary of administration duties related to the Executor.

Desk 4. Executor duties – modules

Kind

Description

0x??–0x63



Unknown

0x64



File reader

0x65



Unknown

0x66



Unknown

0x67



Unknown

0x68



Unknown

0x69



Course of creator

0x6A



Unknown

0x6B



Unknown

0x6C



Information collector

0x6D



Unknown

0x6E



Unknown

Desk 5. Executor duties – administration

Kind

Description

0x6F-0x76

Not applied

0x77

Set Executor configuration

0x78

Get Executor configuration

0x79-0x7C

Not applied

0x7D

Replace

0x7E

Stop

0x7F

Uninstall

The command that units the Executor configuration can change the:

  • undesirable course of lists,
  • time threshold of C&C communication failure, and
  • time restrict for execution of further modules.
Modules

We managed to acquire three distinctive modules from the C&C server, every akin to a special Executor job sort, as proven in Desk 4. Based mostly on accessible data, we estimate there are 9 to 14 modules in complete. Because the modules are actually backdoor instructions, they’ve one fundamental operation to execute after which optionally return their output. The modules we obtained are DLLs with one unnamed export (ordinal 1), through which they resolve essential API capabilities and name the primary perform.

When executed, the modules are supplied with an API decision perform, which might resolve Home windows APIs and customized Executor APIs. The Home windows APIs are referenced by a DWORD hash, calculated from the title of the API and its DLL. Small hash values (<41) are handled specifically, referencing the Executor API perform. The Executor API contains a complete of 39 capabilities which can be accessible to the modules. These capabilities pertain to quite a lot of operations, together with:

  • file operations,
  • encryption and hashing,
  • compression,
  • PE loading,
  • entry Token Impersonation, and
  • utility.

In the remainder of this part, we describe the modules that we obtained.

Course of creator

Module 0x69 executes the desired command line as a brand new course of and offers the ensuing output again to the Orchestrator. The method could be created below a special consumer, and its execution time could be restricted. Notably, an uncommon Job API is used on this module’s performance.

This module was served with the command line cmd.exe /c tasklist /v.

We assume it serves as an idle command issued mechanically, whereas the operators watch for one thing fascinating to occur on the compromised pc.

Information collector

Module 0x6C collects in depth details about the pc through WMI queries and passes it again to the Orchestrator. Details about the next is collected:

  • working system,
  • community adapters,
  • put in software program,
  • drives,
  • companies,
  • drivers,
  • processes,
  • customers,
  • setting variables, and
  • safety software program.
File reader

Module 0x64 reads the desired file and passes the content material again to the Orchestrator. Optionally, it might delete the file after studying.

We noticed this module used to retrieve the sufferer’s Outlook information file

c:Customers<redacted>AppDataLocalMicrosoftOutlookoutlook.ost.

Chain with shellcode downloader

Within the technique of investigating Deadglyph, we encountered a doubtful CPL file signed with an expired certificates and no countersignature with a timestamp, which had been uploaded to VirusTotal from Qatar. Upon nearer examination, it turned evident that this CPL file functioned as a multistage shellcode downloader, sharing sure code resemblances with Deadglyph. The loading chain is illustrated in Determine 6.

Deadglyph Figure_03
Determine 6. Shellcode downloader loading chain

In its preliminary kind, which serves as the primary stage, this file anticipates having a .cpl extension (Management Panel file) and is supposed to be executed through a double-click motion. Upon execution on this method, the embedded shellcode undergoes XOR decryption, and the operating processes are checked to determine an acceptable host course of for subsequent injection.

If avp.exe (a Kaspersky endpoint safety course of) is operating, %windirpercentsystem32UserAccountBroker.exe is used. In any other case, the default browser is used. Then, it creates the host course of in a suspended state, injects the shellcode by hijacking its major thread, and resumes the thread.

The second stage, the shellcode, consists of two components. The primary a part of the shellcode resolves API hashes, utilizing the identical distinctive hash calculation approach employed in Deadglyph, and decrypts strings with course of names. It begins a self-delete thread tasked with overwriting and subsequently erasing the first-stage file. Following this, the shellcode proceeds to examine the at present lively processes, concentrating on a safety answer.

If any of the desired processes are detected, the shellcode creates a sleeper thread with the bottom precedence (THREAD_PRIORITY_IDLE) and permits it to stay lively for a period of 60 seconds earlier than terminating its operation. This interval is probably going applied as a precautionary measure to evade sure detection mechanisms employed by safety options. Lastly, the shellcode proceeds to invoke the execution of the second a part of its code.

The second a part of the shellcode masses an embedded PE file with stage three and calls its export with ordinal quantity 1.

The third stage, a DLL, serves as a .NET loader and accommodates the payload in its .rsrc part.

To load the payload, the .NET runtime is initialized. In the course of the .NET initialization, two intriguing strategies are carried out, seemingly supposed to evade Home windows Antimalware Scan Interface (AMSI) scanning:

  • The .NET loader quickly hooks the GetModuleHandleW import within the loaded clr.dll, whereas calling ICorRuntimeHost::Begin. The hook tampers with the return worth when GetModuleHandleW known as with NULL. It returns a pointer to a dummy PE with no sections.
  • It then subtly patches the AmsiInitialize import title string within the .rdata part of the loaded clr.dll to amsiinitialize.

The fourth stage is a .NET meeting, obfuscated with ConfuserEx, that serves as a shellcode downloader. First, it XOR-decrypts its configuration in XML format from its assets. A beautified model of the extracted configuration is introduced in Determine 7. The configuration entries comprise particulars associated to community communication and blocklisted processes.

Deadglyph Figure_05
Determine 7. Shellcode downloader configuration

Earlier than continuing, it checks the operating processes in opposition to an inventory of blocklisted processes from the configuration. If a match is detected, the execution halts. It is very important be aware that within the analyzed occasion, this blocklist wasn’t arrange.

Subsequent, it sends an HTTP GET request to the C&C server to retrieve some shellcode, utilizing parameters specified within the configuration (URL, Person-Agent, and optionally Proxy). Regrettably, throughout our investigation we had been unable to accumulate any shellcode from the C&C server. Nonetheless, we hypothesize that the content material being retrieved might doubtlessly function the installer for Deadglyph.

Following this, the retrieved shellcode is executed inside a newly created thread. After ready till the shellcode thread finishes execution, the shellcode downloader removes all recordsdata situated within the listing %WINDIRpercentServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.

Lastly, it makes an try and delete itself after a 20-second interval, using the next command, earlier than concluding its operation and exiting:

cmd.exe alternative /C Y /N /D Y /T 20 & Del /f /q <current_process_exe_path>

This self-deletion doesn’t make sense on this chain. This is because of the truth that the shellcode downloader is executed inside a browser or system course of after being injected, moderately than working as an impartial executable. Furthermore, the preliminary file was already deleted by the second stage. This remark means that the shellcode downloader won’t be an unique payload of this chain and may be used individually in different operations.

Conclusion

We’ve got found and analyzed a classy backdoor utilized by the Stealth Falcon group that we now have named Deadglyph. It has an uncommon structure, and its backdoor capabilities are offered by its C&C within the type of further modules. We managed to acquire three of those modules, uncovering a fraction of Deadglyph’s full capabilities.

Notably, Deadglyph boasts a spread of counter-detection mechanisms, together with steady monitoring of system processes and the implementation of randomized community patterns. Moreover, the backdoor is able to uninstalling itself to attenuate the probability of its detection in sure instances.

Moreover, our investigation led us to the invention of a compelling multistage shellcode downloader chain on VirusTotal. We suspect this downloader chain is probably going leveraged within the set up technique of Deadglyph.

For any inquiries about our analysis revealed on WeLiveSecurity, please contact us at threatintel@eset.com.
ESET Analysis gives non-public APT intelligence reviews and information feeds. For any inquiries about this service, go to the ESET Menace Intelligence web page.

IoCs

Information

SHA-1

Filename

Detection

Description

C40F1F46D230A85F702DAA38CFA18D60481EA6C2

pbrtl.dll

Win64/Deadglyph.A

Registry Shellcode Loader.

740D308565E215EB9B235CC5B720142428F540DB

N/A

Win64/Deadglyph.A

Deadglyph Backdoor – Executor.

1805568D8362A379AF09FD70D3406C6B654F189F

N/A

MSIL/Deadglyph.A

Deadglyph Backdoor – Orchestrator.

9CB373B2643C2B7F93862D2682A0D2150C7AEC7E

N/A

MSIL/Deadglyph.A

Orchestrator Community module.

F47CB40F6C2B303308D9D705F8CAD707B9C39FA5

N/A

MSIL/Deadglyph.A

Orchestrator Timer module.

3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32

N/A

Win64/Deadglyph.A.gen

Course of creator module.

3D2ACCEA98DBDF95F0543B7C1E8A055020E74960

N/A

Win64/Deadglyph.A

File reader module.

4E3018E4FD27587BD1C566930AE24442769D16F0

N/A

Win64/Deadglyph.A

Information collector module.

7F728D490ED6EA64A7644049914A7F2A0E563969

N/A

Win64/Injector.MD

First stage of shellcode downloader chain.

Certificates

Serial quantity

00F0FB1390F5340CD2572451D95DB1D92D

Thumbprint

DB3614DAF58D041F96A5B916281EA0DC97AA0C29

Topic CN

RHM LIMITED

Topic O

RHM LIMITED

Topic L

St. Albans

Topic S

Hertfordshire

Topic C

GB

E-mail

rhm@rhmlimited[.]co.uk

Legitimate from

2021-03-16 00:00:00

Legitimate to

2022-03-16 23:59:59

C&C servers

IP

Area

First seen

Remark

185.25.50[.]60

chessandlinkss[.]com

2021-08-25

Deadglyph C&C server.

135.125.78[.]187

easymathpath[.]com

2021-09-11

Deadglyph C&C server.

45.14.227[.]55

joinushealth[.]com

2022-05-29

Shellcode downloader C&C server.

MITRE ATT&CK strategies

This desk was constructed utilizing model 13 of the MITRE ATT&CK framework.

 

Tactic

ID

Title

Description

Useful resource Growth

T1583.001

Purchase Infrastructure: Domains

Stealth Falcon has registered domains for C&C servers and to acquire a code-signing certificates.

T1583.003

Purchase Infrastructure: Digital Non-public Server

Stealth Falcon has used VPS internet hosting suppliers for C&C servers.

T1587.001

Develop Capabilities: Malware

Stealth Falcon has developed customized malware, together with customized loaders and the Deadglyph backdoor.

T1588.003

Receive Capabilities: Code Signing Certificates

Stealth Falcon has obtained a code-signing certificates.

Execution

T1047

Home windows Administration Instrumentation

Deadglyph makes use of WMI to execute its loading chain.

T1059.003

Command and Scripting Interpreter: Home windows Command Shell

Shellcode downloader makes use of cmd.exe to delete itself.

T1106

Native API

A Deadglyph module makes use of CreateProcessW and CreateProcessAsUserW API capabilities for execution.

T1204.002

Person Execution: Malicious File

The shellcode downloader chain requires the consumer to double-click and execute it.

Persistence

T1546.003

Occasion Triggered Execution: Home windows Administration Instrumentation Occasion Subscription

The preliminary Deadglyph loader is persevered utilizing WMI occasion subscription.

Protection Evasion

T1027

Obfuscated Information or Info

Deadglyph parts are encrypted. Deadglyph Orchestrator and embedded modules are obfuscated with .NET Reactor.

The shellcode downloader is obfuscated with ConfuserEx.

T1070.004

Indicator Elimination: File Deletion

Deadglyph can uninstall itself.

The shellcode downloader chain deletes itself and deletes recordsdata within the WebDAV cache.

T1112

Modify Registry

Deadglyph shops its configuration and encrypted payload within the registry.

T1134

Entry Token Manipulation

Deadglyph can impersonate one other consumer.

T1140

Deobfuscate/Decode Information or Info

Deadglyph decrypts encrypted strings.

The shellcode downloader chain decrypts its parts and configurations.

T1218.011

System Binary Proxy Execution: Rundll32

The preliminary Deadglyph loader is executed utilizing rundll32.exe.

T1480.001

Execution Guardrails: Environmental Keying

Deadglyph is encrypted utilizing a machine-specific key derived from the system UUID.

T1562.001

Impair Defenses: Disable or Modify Instruments

The shellcode downloader avoids AMSI scanning by patching clr.dll in reminiscence .

T1620

Reflective Code Loading

Deadglyph reflectively masses its modules utilizing a customized PE loader.

Discovery

T1007

System Service Discovery

A Deadglyph module discovers companies utilizing the WMI question SELECT * FROM Win32_Service.

T1012

Question Registry

The shellcode downloader chain queries the registry for the default browser.

T1016

System Community Configuration Discovery

A Deadglyph module discovers community adapters utilizing WMI queries SELECT * FROM Win32_NetworkAdapter and SELECT * FROM Win32_NetworkAdapterConfiguration the place InterfaceIndex=%d.

T1033

System Proprietor/Person Discovery

A Deadglyph module discovers customers with the WMI question SELECT * FROM Win32_UserAccount.

T1057

Course of Discovery

A Deadglyph module discovers processes utilizing WMI question SELECT * FROM Win32_Process.

T1082

System Info Discovery

A Deadglyph module discovers system data comparable to OS model, drives, setting variables, and drivers utilizing WMI queries.

T1518

Software program Discovery

A Deadglyph module discovers put in software program utilizing WMI question SELECT * FROM Win32_Product.

T1518.001

Software program Discovery: Safety Software program Discovery

A Deadglyph module discovers safety software program utilizing WMI queries SELECT * FROM AntiVirusProduct, SELECT * FROM AntiSpywareProduct and SELECT * FROM FirewallProduct.

The shellcode downloader chain checks operating processes for a safety answer.

Assortment

T1005

Knowledge from Native System

Deadglyph has a module for studying recordsdata.

Command and Management

T1071.001

Software Layer Protocol: Internet Protocols

Deadglyph and the shellcode downloader talk with the C&C server through the HTTP protocol.

T1090

Proxy

Deadglyph and the shellcode downloader can use HTTP proxy for C&C communication.

T1573.001

Encrypted Channel: Symmetric Cryptography

Deadglyph makes use of AES to encrypt C&C communications.

Exfiltration

T1041

Exfiltration Over C2 Channel

Deadglyph makes use of the C&C channel for exfiltration.



Latest news
Related news

LEAVE A REPLY

Please enter your comment!
Please enter your name here