Where: is a path to the shellcode file when 1 or true will enable thread stack spoofing and anything else disables it.Example run that spoofs beacon's thread call stack: .\x64\Release\ThreadStackSpoofer.exe .\tests\beacon64.bin 1 [.] Reading shellcode bytes... [.] Hooking kernel32!Sleep... [.] Injecting shellcode... [+] Shellcode is now running. [>] Original return address: 0x1926747bd51. Finishing call stack... ===> MySleep(5000) [<] Restoring original return address... [>] Original return address: 0x1926747bd51. Finishing call stack... ===> MySleep(5000) [<] Restoring original return address... [>] Original return address: 0x1926747bd51. Finishing call stack... ">PS D:\dev2\ThreadStackSpoofer> .\x64\Release\ThreadStackSpoofer.exe .\tests\beacon64.bin 1
[.] Reading shellcode bytes...
[.] Hooking kernel32!Sleep...
[.] Injecting shellcode...
[+] Shellcode is now running.
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<] Restoring original return address...
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<] Restoring original return address...
[>] Original return address: 0x1926747bd51. Finishing call stack...

How do I use it?
Look at the code and its implementation, understand the concept and re-implement the concept within your own Shellcode Loaders that you utilise to deliver your Red Team engagements. This is an yet another technique for advanced in-memory evasion that increases your Teams' chances for not getting caught by Anti-Viruses, EDRs and Malware Analysts taking look at your implants.While developing your advanced shellcode loader, you might also want to implement:Process Heap Encryption - take an inspiration from this blog post: Hook Heaps and Live Free (https://www.arashparsa.com/hook-heaps-and-live-free/) - which can let you evade Beacon configuration extractors like BeaconEyeChange your Beacon's memory pages protection (https://www.kitploit.com/search/label/Protection) to RW (from RX/RWX) and encrypt their contents - using Shellcode Fluctuation (https://github.com/mgeeky/ShellcodeFluctuation) technique - right before sleeping (that could evade scanners such as Moneta or pe-sieve)Clear out any leftovers from Reflective Loader to avoid in-memory signatured detectionsUnhook everything you might have hooked (such as AMSI, ETW, WLDP) before sleeping and then re-hook afterwards.
Actually this is not (yet) a true stack spoofing
As it's been pointed out to me, the technique here is not yet truly holding up to its name for being a stack spoofer. Since we're merely overwriting return addresses on the thread's stack, we're not spoofing the remaining areas of the stack itself. Moreover we're leaving our call stack unwindable meaking it look anomalous since the system will not be able to properly walk the entire call stack frames chain.However I'm aware of these shortcomings, at the moment I've left it as is since I cared mostly about evading automated scanners that could iterate over processes, enumerate their threads, walk those threads stacks and pick up on any return address pointing back to a non-image memory (such as SEC_PRIVATE - the one allocated dynamically by VirtuaAlloc and friends). A focused malware analyst would immediately spot the oddity and consider the thread rather unusual, hunting down our implant. More than sure about it. Yet, I don't believe that nowadays automated scanners such as AV/EDR have sorts of heuristics implemented that would actually walk each thread's stack to verify whether its un-windable ¯\_(ツ)_/¯ .Surely this project (and commercial implementation found in C2 frameworks) gives AV & EDR vendors arguments to consider implementing appropriate heuristics covering such a novel evasion technique.In order to improve this technique, one can aim for a true Thread Stack Spoofer by inserting carefully crafted fake stack frames established in an reverse-unwinding process. Read more on this idea below.

___________________________
@hacking_Attack
@Hacking_Video

auto begin = PRUNTIME_FUNCTION(excdir.VirtualAddress + imageBase);
auto end = PRUNTIME_FUNCTION(excdir.VirtualAddress + imageBase + excdir.Size);

UNWIND_HISTORY_TABLE mshist = { 0 };
DWORD64 imageBase2 = 0;

PRUNTIME_FUNCTION currFrame = RtlLookupFunctionEntry(
(DWORD64)caller,
&imageBase2,
&mshist
);

UNWIND_INFO *mySleep = (UNWIND_INFO*)(currFrame->UnwindData + imageBase);
UNWIND_CODE myFrameUwop = (UNWIND_CODE)(mySleep->UnwindCodes[0]);

log("1. MySleep RIP UWOP: ", myFrameUwop.UnwindOpcode);

for (PRUNTIME_FUNCTION it = begin; it < end; ++it)
{
UNWIND_INFO* unwindData = (UNWIND_INFO*)(it->UnwindData + imageBase);
UNWIND_CODE frameUwop = (UNWIND_CODE)(unwindData->UnwindCodes[0]);

if (frameUwop.UnwindOpcode != myFrameUwop.UnwindOpcode)
{
// Found candidate function for a desynch gadget frame

}
}
The process is a bit convoluted, yet boils down to reverting thread's call stack unwinding process by substituting arbitrary stack frames with carefully selected other ones, in a ROP alike approach.This PoC does not follows replicate this algorithm, because my current understanding allows me to accept the call stack finishing on an EXE-based stack frame and I don't want to overcompliate neither my shellcode loaders nor this PoC. Leaving the exercise of implementing this and sharing publicly to a keen reader. Or maybe I'll sit and have a try on doing this myself given some more spare time :)More information:a) x64 exception handling - Stack Unwinding process explained (https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-160)b) Sample implementation of RtlpUnwindPrologue and RtlVirtualUnwindc) .pdata sectiond) another sample implementation of RtlpUnwindPrologue
Word of caution
If you plan on adding this functionality to your own shellcode loaders / toolings be sure to AVOID unhooking kernel32.dll. An attempt to unhook kernel32 will restore original Sleep functionality preventing our callback from being called. If our callback is not called, the thread will be unable to spoof its own call stack by itself.If that's what you want to have, than you might need to run another, watchdog thread, making sure that the Beacons thread will get spoofed whenever it sleeps.If you're using Cobalt Strike (https://www.kitploit.com/search/label/Cobalt%20Strike) and a BOF unhook-bof by Raphael's Mudge, be sure to check out my Pull Request (https://github.com/Cobalt-Strike/unhook-bof/pull/1) that adds optional parameter to the BOF specifying libraries that should not be unhooked.This way you can maintain your hooks in kernel32: unhook kernel32 [*] Running unhook. Will skip these modules: wmp.dll, kernel32.dll [+] host called home, sent: 9475 bytes [+] received output: ntdll.dll <.text> Unhook is done. ">beacon> unhook kernel32
[*] Running unhook.
Will skip these modules: wmp.dll, kernel32.dll
[+] host called home, sent: 9475 bytes
[+] received output:
ntdll.dll <.text>
Unhook is done.
Modified unhook-bof with option to ignore specified modules
Final remark
This PoC was designed to work with Cobalt Strike's Beacon shellcodes. The Beacon is known to call out to kernel32!Sleep to await further instructions from its C2. This loader leverages that fact by hooking Sleep in order to perform its housekeeping.This implementation might not work with other shellcodes in the market (such as Meterpreter) if they don't use Sleep to cool down. Since this is merely a Proof of Concept showing the technique, I don't intend on adding support for any other C2 framework.When you understand the concept, surely you'll be able to translate it into your shellcode requirements (https://www.kitploit.com/search/label/Requirements) and adapt the solution for your advantage.Please do not open Github issues related to "this code doesn't work with XYZ shellcode", they'll be closed immediately.
Show Support

___________________________
@hacking_Attack
@Hacking_Video

This and other projects are outcome of sleepless nights and plenty of hard work. If you like what I do and appreciate that I always give back to the community, Consider buying me a coffee (https://github.com/sponsors/mgeeky) (or better a beer) just to say thank you!
Author
(https://github.com/mgeeky) "> Mariusz Banach / mgeeky, 21

(https://github.com/mgeeky)


Download ThreadStackSpoofer (https://github.com/mgeeky/ThreadStackSpoofer)

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
ThreadStackSpoofer - PoC For An Advanced In-Memory Evasion Technique Allowing To Better Hide Injected Shellcode'S Memory Allocation From Scanners And Analysts

https://blogger.googleusercontent.com/img/a/AVvXsEge6kg8MknUuaL-4QkjbY6FA7MqZ38aWsmjYUala72_0YO_yd5ZQ7JrCCVDqphlGek7NPd1tdgx-wj40ypPLvkTdNp3Nww0heeTQkGA3vk8KcEc9ezq-Iv768oQljzAZtNywQFO-UJsUssPjXDfLovsazAU5-wqoKz6cdGTD-Rqwwnibqro8MAhAocu9g=w640-h238 A PoC implementation for an advanced in-memory evasion technique that spoofs Thread Call Stack. This technique allows to bypass thread-based memory examination rules and better hide shellcodes while in-process memory. IntroThis is an example implementation for Thread Stack Spoofing technique aiming to evade Malware Analysts, AVs and EDRs looking for references to shellcode's frames in an examined thread's call stack. The idea is to hide references to the shellcode on thread's call stack thus masquerading allocations containing malware's code.

Implementation along with my ShellcodeFluctuation brings Offensive Security community sample implementations to catch up on the offering made by commercial C2 products, so that we can do no worse in our Red Team toolings. Implementation has changedCurrent implementation differs heavily to what was originally published. This is because I realised there is a way simpler approach to terminate thread's call stack processal and hide shellcode's related frames by simply writing 0to the return address of the first frame we control: void WINAPI MySleep(DWORD _dwMilliseconds)
{
[...]
auto overwrite = (PULONG_PTR)_AddressOfReturnAddress();
const auto origReturnAddress = *overwrite;
*overwrite = 0;

[...]
*overwrite = origReturnAddress;
} The previous implementation, utilising StackWalk64can be accessed in this commit c250724.

This implementation is much more stable and works nicely on both Debugand Releaseunder two architectures - x64and x86. DemoThis is how a call stack may look like when it is NOT spoofed: https://blogger.googleusercontent.com/img/a/AVvXsEgnSXVnZYGiAdCesiZsxpmEY90YQvBwnMfQUdlOaevpLoADoBlClm6tMlNZqgI3swQfcL428sAWInPTBXhWG5TtIkhxPavvQFbT1v5BiZt2-IIqDpoioyePUNIvZw8cjf-5qnYrDoDXptMXraGn5OAbHc0Wm9k_QsNXu_ot3UCanckhEIZlLV8GEHLSAg=w640-h234 This in turn, when thread stack spoofing is enabled: https://blogger.googleusercontent.com/img/a/AVvXsEg4JFrE2bipPvKqwMsqju2PKMx2vb9sQoF-d1CxC3z6To3GcFcvg6FuJYjvu8StAYukgiLtyJBcgH_m8Pj-87cY4_aziWEfpCDcGdi-tr9TB029-hjdzG3dxB1Gp-9Sa2MCTyJrLmXUKql2yIvrAxlbTGzvm7TojTNEiidda1UYkOtsBIyHwZIstpxo5w=w640-h248 Above we can see that the last frame on our call stack is our MySleepcallback. One can wonder does it immediately brings opportunities new IOCs? Hunting rules can look for threads having call stacks not unwinding into following expected thread entry points located within system libraries: kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21 However the call stack of the spoofed thread may look rather odd at first, a brief examination of my system shown, that there are other threads not unwinding to the above entry points as well: https://blogger.googleusercontent.com/img/a/AVvXsEjWXojWCLnFrFMk8AqFyghZQAzYOJIhGqcaxFdew7Ul8jn5zOPLcEGnskP5WQXCiMdV_VPByLkeUNSS-lE5lZrVZ_xLKnfOCU2t1z7IZE1HwuoC9aaASedaZLYcljCeHPp8P0wKn_rZdOATF7Wx5JdvcJPY5k-lig7hKl0784Zj8RSV2Dx3CRfU8zT8MA=w640-h238 The above screenshot shows a thread of unmodified Total Commander x64. As we can see, its call stack pretty much resembles our own in terms of initial call stack frames.

Why should we care about carefully faking our call stack when there are processes exhibiting traits that we can simply mimic? How it works?The rough algorithm is following:

1. Read shellcode's contents from f[...]

___________________________
@hacking_Attack
@Hacking_Video

ile.
2. Acquire all the necessary function pointers from dbghelp.dll, call SymInitialize3. Hook kernel32!Sleeppointing back to our callback.
4. Inject and launch shellcode via VirtualAlloc+ memcpy+ CreateThread. The thread should start from our runShellcodefunction to avoid having Thread's StartAddress point into somewhere unexpected and anomalous (such as ntdll!RtlUserThreadStart+0x21)
5. As soon as Beacon attempts to sleep, our MySleepcallback gets invoked.
6. We then overwrite last return address on the stack to 0which effectively should finish the call stack.
7. Finally a call to ::SleepExis made to let the Beacon's sleep while waiting for further communication.
8. After Sleep is finished, we restore previously saved original function return addresses and execution is resumed.

Function return addresses are scattered all around the thread's stack memory area, pointed to by RBP/EBPregister. In order to find them on the stack, we need to firstly collect frame pointers, then dereference them for overwriting: https://blogger.googleusercontent.com/img/a/AVvXsEhrX1z7OMD_4MRFvi9pTy4wY4nmfwt83pqbzzqb-U_v-JDZ67Lso8kc6FQI4tFt9IuYQ7wfhI4msnHm0FNENt3arDlh723hI-0_d_UUJo_TLxSU5w0vTgU37OfIdLpYHlM0zL9lS7s9wYGV2zUQTtsNHupsg0TJdjFuqu5ywYQTTPIYPBHA3raMP7-VMQ=w640-h486 (the above image was borrowed from Eli Bendersky's post named Stack frame layout on x86-64) *(PULONG_PTR)(frameAddr + sizeof(void*)) = Fake_Return_Address; Initial implementation of ThreadStackSpooferdid that in walkCallStackand spoofCallStackfunctions, however the current implementation shows that these efforts are not required to maintain stealthy call stack. Example runUse case: C:\> ThreadStackSpoofer.exe Where:

* is a path to the shellcode file
* when 1or truewill enable thread stack spoofing and anything else disables it.

Example run that spoofs beacon's thread call stack: PS D:\dev2\ThreadStackSpoofer> .\x64\Release\ThreadStackSpoofer.exe .\tests\beacon64.bin 1
[.] Reading shellcode bytes...
[.] Hooking kernel32!Sleep...
[.] Injecting shellcode...
[+] Shellcode is now running.
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<]
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<]
[>] Original return address: 0x1926747bd51. Finishing call stack... How do I use it?Look at the code and its implementation, understand the concept and re-implement the concept within your own Shellcode Loaders that you utilise to deliver your Red Team engagements. This is an yet another technique for advanced in-memory evasion that increases your Teams' chances for not getting caught by Anti-Viruses, EDRs and Malware Analysts taking look at your implants.

While developing your advanced shellcode loader, you might also want to implement:

* Process Heap Encryption - take an inspiration from this blog post: Hook Heaps and Live Free - which can let you evade Beacon configuration extractors like BeaconEye* Change your Beacon's memory pages protection to RW(from RX/RWX) and encrypt their contents - using Shellcode Fluctuation technique - right before sleeping (that could evade scanners such as Monetaor pe-sieve)
* Clear out any leftovers from Reflective Loader to avoid in-memory signatured detections
* Unhook everything you might have hooked (such as AMSI, ETW, WLDP) before sleeping and then re-hook afterwards. Actually this is not (yet) a true stack spoofingAs it's been pointed out to me, the technique here is not yet truly holding up to its name for being a[...]

___________________________
@hacking_Attack
@Hacking_Video

stack spoofer. Since we're merely overwriting return addresses on the thread's stack, we're not spoofing the remaining areas of the stack itself. Moreover we're leaving our call stack unwindable meaking it look anomalous since the system will not be able to properly walk the entire call stack frames chain.

However I'm aware of these shortcomings, at the moment I've left it as is since I cared mostly about evading automated scanners that could iterate over processes, enumerate their threads, walk those threads stacks and pick up on any return address pointing back to a non-image memory (such as SEC_PRIVATE- the one allocated dynamically by VirtuaAllocand friends). A focused malware analyst would immediately spot the oddity and consider the thread rather unusual, hunting down our implant. More than sure about it. Yet, I don't believe that nowadays automated scanners such as AV/EDR have sorts of heuristics implemented that would actually walk each thread's stack to verify whether its un-windable ¯\_(ツ)_/¯.

Surely this project (and commercial implementation found in C2 frameworks) gives AV & EDR vendors arguments to consider implementing appropriate heuristics covering such a novel evasion technique.

In order to improve this technique, one can aim for a true Thread Stack Spoofer by inserting carefully crafted fake stack frames established in an reverse-unwinding process. Read more on this idea below. Implementing a true Thread Stack SpooferHours-long conversation with namazso teached me, that in order to aim for a proper thread stack spoofer we would need to reverse x64 call stack unwinding process. Firstly, one needs to carefully acknowledge the stack unwinding process explained in (a) linked below. The system when traverses Thread call stack on x64 architecture will not simply rely on return addresses scattered around the thread's stack, but rather it:

1. takes return address
2. attempts to identify function containing that address (with RtlLookupFunctionEntry)
3. That function returns RUNTIME_FUNCTION, UNWIND_INFOand UNWIND_CODEstructures. These structures describe where are the function's beginning address, ending address, and where are all the code sequences that modify RBPor RSP.
4. System needs to know about all stack & frame pointers modifications that happened in each function across the Call Stack to then virtually rollback these changes and virtually restore call stack pointers when a call to the processed call stack frame happened (this is implemented in RtlVirtualUnwind)
5. The system processes all UNWIND_CODEs that examined function exhbits to precisely compute the location of that frame's return address and stack pointer value.
6. Through this emulation, the System is able to walk down the call stacks chain and effectively "unwind" the call stack.

In order to interfere with this process we wuold need to revert it by having our reverted form of RtlVirtualUnwind. We would need to iterate over functions defined in a module (let's be it kernel32), scan each function's UNWIND_CODEcodes and closely emulate it backwards (as compared to RtlVirtualUnwindand precisely RtlpUnwindPrologue) in order to find locations on the stack, where to put our fake return addresses. namazso mentions the necessity to introduce 3 fake stack frames to nicely stitch the call stack:

1. A "desync" frame (consider it as a gadget-frame) that unwinds differently compared to the caller of our MySleep(having differnt UWOP- Unwind Operation code). We do this by looking through all functions from a module, looking through their UWOPs, calculating how big the fake frame should be. This frame must have UWOPS different than our MySleep's caller.
2. Next frame that we want to find is a function that [...]

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
ThreadStackSpoofer - PoC For An Advanced In-Memory Evasion Technique Allowing To Better Hide Injected Shellcode'S Memory Allocation From Scanners And Analysts

___________________________
@hacking_Attack
@Hacking_Video

Abusing Public Infrastructure to Build Your Own VirusTotal for Email: An Open-Source Secure Email Gateway Evaluation Toolkit
https://www.reddit.com/r/redteamsec/comments/qf96ke/abusing_public_infrastructure_to_build_your_own/

Hey Everyone, I recently published an open-source project (Phishious) that allows you to create your own VirusTotal but for evaluating Secure Email Gateway technologies. GitHub - Rices/Phishious: An open-source Secure Email Gateway (SEG) evaluation toolkit designed for red-teamers. (https://github.com/Rices/Phishious) The project piggybacks off a BSides presentation I gave earlier in the year on how email bounce responses can be abused for malicious intent. BSides Presentation (https://www.youtube.com/watch?v=wqRlVtRYwWQ) In the project, I’ve weaponised the attack discussed during this presentation and automated it to an extent that it only requires a few clicks to perform. I’ve uploaded a short video on how to use Phishious - Phishious - Automated Scan Introduction - YouTube (https://www.youtube.com/watch?v=QZ9p4f6B5Ww) I’d love to hear your feedback on the project! Regards,
Rices submitted by /u/Jumpy_Resolution3089 (https://www.reddit.com/user/Jumpy_Resolution3089)
[link] (https://www.reddit.com/r/redteamsec/comments/qf96ke/abusing_public_infrastructure_to_build_your_own/) [comments] (https://www.reddit.com/r/redteamsec/comments/qf96ke/abusing_public_infrastructure_to_build_your_own/)

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
SWEET NECTARS of the SEOUL

https://cdn-images-1.medium.com/max/973/1*s-9uAV80zL9PQ8t0shpX2w.jpeg
TABLE OF CONTENTS

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
How To Stay Safe From Cyber Attacks?

https://cdn-images-1.medium.com/max/1080/1*51uFyNdc30m7RxFhjuFOFw.png
With hacks, scams, cybercriminals, malware, and more, the internet can seem like a dangerous place these days. In addition, the recent…

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
Bocor Lagi, Bocor Lagi… Sekarang Giliran Komisi Perlindungan Anak Indonesia Jadi Korban Hacker

https://cdn-images-1.medium.com/max/1280/1*w5A-h4BbmsERR-3HWM5ltg.jpeg
Kasus kebocoran data yang terjadi pada instansi pemerintahan kembali terjadi. Hal ini semakin membuktikan bahwa masalah keamanan data…

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
Hack the box — Previse Walkthrough

https://cdn-images-1.medium.com/max/1052/1*z-sq423RVs3qmenzg0XLYA.png
Hack the box — Previse Walkthrough

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Black Hat Ethical Hacking
Popular NPM library hijacked to install password-stealers, miners

https://www.blackhatethicalhacking.com/wp-content/uploads/2021/08/Untitled-design-2-1.png Popular NPM library hijacked to install password-stealers, minersPost Views: 113
Reading Time: 1 Minute
Hackers hijacked the popular UA-Parser-JS NPM library, with millions of downloads a week, to infect Linux and Windows devices with cryptominers and password-stealing trojans in a supply-chain attack.
The UA-Parser-JS library is used to parse a browser’s user agent to identify a visitor’s browser, engine, OS, CPU, and Device type/model.

The library is immensely popular, with millions of downloads a week and over 24 million downloads this month so far. In addition, the library is used in over a thousand other projects, including those by Facebook, Microsoft, Amazon, Instagram, Google, Slack, Mozilla, Discord, Elastic, Intuit, Reddit, and many more well-known companies.
https://www.bleepstatic.com/images/news/security/attacks/n/npms/ua-parser-js/downloads-npm-stat.jpg
UA-Parser-JS project hijacked to install malwareOn October 22nd, a threat actor published malicious versions of the UA-Parser-JS NPM library to install cryptominers and password-stealing trojans on Linux and Windows devices.

According to the developer, his NPM account was hijacked and used to deploy the three malicious versions of the library.

“I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don’t realize something was up, luckily the effect is quite the contrary),” explained Faisal Salman, the developer of UA-Parser-JS, in a bug report.

“I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which will probably install malware as can be seen from the diff here: https://app.renovatebot.com/package-diff?name=ua-parser-js&from=0.7.28&to=1.0.0.”

The affected versions and their patched counterparts are:
Malicious version Fixed version 0.7.29 0.7.30 0.8.0 0.8.1 1.0.0 1.0.1
From copies of the malicious NPMs shared with BleepingComputer by Sonatype, we can better understand the attack.
See Also: Apple Pay with VISA lets hackers force payments on locked iPhones
When the compromised packages are installed on a user’s device, a preinstall.js script will check the type of operating system used on the device and either launch a Linux shell script or a Windows batch file.
https://www.bleepstatic.com/images/news/security/attacks/n/npms/ua-parser-js/check-os.jpg
___________________________
@hacking_Attack
@Hacking_Video

tic.com/images/news/security/attacks/n/npms/ua-parser-js/windows-batch.jpg
regsvr32.exe -s create.dllcommand, it will attempt to steal passwords for a wide variety of programs, including FTP clients, VNC, messaging software, email clients, and browsers.

A list of targeted programs can be found in the table below.
WinVNC Firefox FTP Control Screen Saver 9x Apple Safari NetDrive PC Remote Control Remote Desktop Connection Becky ASP.NET Account Cisco VPN Client The Bat! FreeCall GetRight Outlook Vypress Auvis FlashGet/JetCar Eudora CamFrog FAR Manager FTP Gmail Notifier Win9x NetCache Windows/Total Commander Mail.Ru Agent ICQ2003/Lite WS_FTP IncrediMail “&RQ, R&Q” CuteFTP Group Mail Free Yahoo! Messenger FlashFXP PocoMail Digsby FileZilla Forte Agent Odigo FTP Commander Scribe IM2/Messenger 2 BulletProof FTP Client POP Peeper Google Talk SmartFTP Mail Commander Faim TurboFTP Windows Live Mail MySpaceIM FFFTP Mozilla Thunderbird MSN Messenger CoffeeCup FTP SeaMonkey Windows Live Messenger Core FTP Flock Paltalk FTP Explorer Download Master Excite Private Messenger Frigate3 FTP Internet Download Accelerator Gizmo Project SecureFX IEWebCert AIM Pro UltraFXP IEAutoCompletePWs Pandion FTPRush VPN Accounts Trillian Astra WebSitePublisher Miranda 888Poker BitKinex GAIM FullTiltPoker ExpanDrive Pidgin PokerStars Classic FTP QIP.Online TitanPoker Fling JAJC PartyPoker SoftX FTP Client WebCred CakePoker Directory Opus Windows Credentials UBPoker FTP Uploader MuxaSoft Dialer EType Dialer FreeFTP/DirectFTP FlexibleSoft Dialer RAS Passwords LeapFTP Dialer Queen Internet Explorer WinSCP VDialer Chrome 32bit FTP Advanced Dialer Opera WebDrive Windows RAS
See Also: OSINT Tool: Osintgram
In addition to stealing passwords from the above programs, the DLL will execute a PowerShell script to steal passwords from the Windows credential manager, as shown below.
https://www.bleepstatic.com/images/news/security/attacks/n/npms/ua-parser-js/steal-windows-credentials.jpg
What should UA-Parser-JS users do?Due to the widespread impact of this supply-chain attack, it is strongly advised that all users of the UA-Parser-JS library check their projects for malicious software.

This includes checking for the existence of either jsextension.exe (Windows) or jsextension (Linux) and deleting them if they are found.

For Windows users, you should scan your device for a create.dll file and delete it immediately.

While only Windows was infected with a password-stealing Trojan, it is wise for Linux users to also assume their device was fully compromised.

Due to this, all infected Linux and Windows users should also change their passwords, keys, and refresh tokens, as they were likely compromised and sent to the threat actor.

While changing your passwords and access tokens will likely be a huge undertaking, by not doing so, the threat actor can compromise other accounts, including any projects you develop for further supply-chain attacks.
See Also: Hacking stories – Operation Aurora: When China hacked Google Source: www.bleepingcomputer.com (Click Link)Recent News* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/youtube-logo-90x90.jpg Massive campaign uses YouTube to push password-stealing malware3 days ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/ezgif.com-gif-maker[...]

___________________________
@hacking_Attack
@Hacking_Video

-3-90x90.jpg Google: YouTubers’ accounts hijacked with cookie-stealing malware4 days ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/ezgif.com-gif-maker-2-90x90.jpg Acer hacked twice in a week by the same threat actor5 days ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/ezgif-6-e5d8ed29a830-90x90.jpg Credit card PINs can be guessed even when covering the ATM pad6 days ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/REVIL-headpic-90x90.jpg REvil ransomware shuts down again after Tor sites were hijacked1 week ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/google-chrome-adblocker-uai-1440x900-1-90x90.jpg Malicious Chrome ad blocker injects ads behind the scenes1 week ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/maxresdefault-90x90.jpg Brizy WordPress Plugin Exploit Chains Allow Full Site Takeovers2 weeks ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/abstract_mysterysnail-90x90.jpg Microsoft Kills Bug Being Exploited in MysterySnail Espionage Campaign2 weeks ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/apple-iphone-hacking-90x90.jpg Emergency Apple iOS 15.0.2 update fixes zero-day used in attacks2 weeks ago
* https://www.blackhatethicalhacking.com/wp-content/uploads/2021/10/Linux-1280x720-1-90x90.jpg FontOnLake malware infects Linux systems2 weeks ago
The post Popular NPM library hijacked to install password-stealers, miners first appeared on Black Hat Ethical Hacking.

___________________________
@hacking_Attack
@Hacking_Video