Posts

Finding the same bugs in all the familiar places

Image
A while back, I had a patch of cases where I was regularly looking at samples leveraging DLL Side loading (also called “Search Order Hijacking”) as part of their setup phase.  This vulnerability exists because of how Windows handles resolving libraries for applications and can be exploited to cause an application to inadvertently load (at the same privilege level) a malicious library.  When a library is loaded by an application (either delayed or at execution), Windows will check the following locations  in order for a copy of the library: (https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order) The above shows the locations checked when SafeDllSearchMode is disabled.  When enabled, the current directory is checked fifth, instead of second.   This process can be exploited when a malicious library is added to one of these locations - before the actual library natively resides.  For example, if MyApp.exe is attempting to load TestLib.dll

Fresh PlugX October 2019

Image
On 15 November 2019, I received a VirusTotal notification for a copy of PlugX that had been uploaded ( Yara - PlugXBootLDRCode from  https://github.com/citizenlab/malware-signatures/blob/master/malware-families/plugx.yara  ). MD5          : ce67994a4ee7cf90645e93aec084230d SHA1         : b42c84f851b8b7d2d2ddfbc9ac94e001204faf45 SHA256       : 6b46e36245b5b9ed13c0fbfae730b49c04aba43b98deb75e388e03695ff5cbd1 Type         : Win32 DLL First seen   : 2019-11-15 08:04:32 UTC Last seen    : 2019-11-15 08:04:32 UTC&nbsp First name   : plugx.dll  What stood out from the notification (outside of the file being named plugx.dll ) was a compilation time of  Fri Oct 4 08:34:45 2019 UTC  (a little more then a month before the writing of this post). Initial Validation This specific rule matches on operations for assembling a set of API calls - shown below $ yara -s All.yara sample PlugXBootLDRCode [PlugX,Family] 6b46e36245b5b9ed13c0fbfae730b49c04aba43b98deb75e388e03

Backdooring a HID Reader

Image
A while back, I bought a HID Prox Pro II on eBay for some long-forgotten experiment — likely this . Outside of being well documented and cheaply available , @shakataganai wrote a fantastic article about how to connect it to an Arduino, which makes it ideal for some testing. HID Prox Pro II While exploring the device, I was disappointed that the actual components of the device (except the antenna) were sealed under some type of resin coating. Despite the components being inaccessible, I noticed there was a lot of available space inside…Big enough to fit an entire Proxmark3 . So — theoretically, it may be possible to install a device inside this empty space that could capture tag data whenever someone swipes. Interior of HID reader Proxmark3 sitting inside Feedback from folks on Twitter noted the potential for interference between the two devices — which makes sense, if the HID card reader is emitting a signal to power a card, a second device in close proximity could cause a p

Lazarus obfuscation in Feb 2019

Image
Lazarus obfuscation in Feb 2019 Starting off, I’d like to give a shot-out to Brian Bartholomew (Twitter: @Mao_Ware) for his general awesomeness and for his post on 30 January from which this research starts. Using this as a base for the following Yara rule, I found a similar sample (SHA256: 625f63364312cec78a4c91abedba868d551d79185ff73e388f561017b13347f0 ) also packed with UPX. rule LazarusDocJan2019_01 { meta: author = “Silas Cutler” description = “Detection for Lazarus Payload from Jan 2019” ref = “ https://twitter.com/DrunkBinary/status/1090625122883510274 " version = “0.1” strings: $ = “\”Main Invoked.\”” $ = “\”Main Returned.\”” $ = “%sd.%se%sc %s > %s 2>&1” condition: all of them } As with the sample Bart identified, the control server is not obfuscated in the binary: Control server in WinM ain function Sandboxing of the sample, confirms the malware beacons to this URL: GET /intro/info/info.