In the current era of mass malware it’s becoming increasingly rare to find something beyond the ‘usual suspects’ we see being spread by high-profile botnets on a regular basis: Dridex spread by Necurs, the ever-increasing number of ransomware families, cryptocurrency miners, credential stealers… the list goes on. These sorts of malware generally make up the majority of incoming malicious samples and are, from a researcher’s standpoint, typically not very interesting.
However, in amongst the digital haystack there exists the occasional needle: we recently came across a sample apparently disguised as a LogMeIn service pack which generated notable amounts of ‘unusual’ DNS requests. Deeper investigation revealed something of a flawed gem, ultimately designed to steal magnetic stripe payment card data: a hallmark of PoS malware.
Point of Sale malware has been around for some time and has been deployed against a broad range of businesses from retailers to hotel groups. However, this appears to be a new family which we are currently calling ‘UDPoS’ owing to its heavy use of UDP-based DNS traffic. At the time of writing, it’s unclear whether the malware is currently being used in campaigns in the wild, although the coordinated use of LogMeIn-themed filenames and C2 URLs, coupled with evidence of an earlier Intel-themed variant, suggest that it may well be.
Note: We have been in contact with LogMeIn throughout this investigation to help determine whether their services or products may have been abused as part of the malware deployment process. No evidence of this was found and it appears that the use of LogMeIn-themed filenames and C2 domain by the actors behind the malware is a simple ‘camouflage’ technique.
A Set of Two – Service & Monitor
Behavioral analysis of the initial sample we discovered, a file named logmeinumon.exe, showed it contacting a similarly LogMeIn-themed C2 server hosted by a Swiss-based VPS provider (details below – note the use of an ‘L’ rather than an ‘I’ in the spelling of logmeln).
Investigation of the C2 revealed it also to be hosting the original dropper file, update.exe. This file is a 7-Zip self-extracting archive containing ‘LogmeinServicePack_5.115.22.001.exe’ and ‘logmeinumon.exe’. Details of these files are in the table below.
Upon executing update.exe, its content is extracted to the %TEMP% directory and ‘LogmeinServicePack_5.115.22.001.exe’ automatically launched using 7-Zip’s built in RunProgram feature.
‘LogmeinServicePackLogmeinServicePack_5.115.22.001.exe – which we have called the service component – is responsible for setting up the malware by placing files into the System32\LogMeInUpd Service directory and creating a new system service for persistence. It does this via a batch file with a semi-random filename embedding standard Windows commands for file and service operations. Once finished it passes over execution to the monitoring component by launching ‘logmeinumon.exe’.
This monitoring component has an almost identical structure to the service component. It’s compiled by the same Visual Studio build and uses the same string encoding technique: both executables contain only a few identifiable plain-text strings, and instead use a basic encryption and encoding method to hide strings such as the C2 server, filenames, and hard-coded process names.
Evasive Maneuvers
Despite maintaining a small footprint – only 88kb in size – the monitor component is a multi-threaded application which creates five different threads after its initialization code is completed. This initialization code is mainly responsible for decrypting and decoding the malware’s internal strings, attempting to carry out an anti-AV/VM check, and either creating or loading an existing ‘Machine ID’ stored in a file called ‘hdwid.dat’ in the same directory where the executables are deployed. This randomly generated identifier is used as {Machine ID} in all of the DNS queries detailed below.
However, only the monitor component makes use of these and, moreover, the code responsible for opening module handles is flawed: it will only try to open cmdvrt32.dll – a library related to Comodo security products – and nothing else.
It is unclear at present whether this is a reflection of the malware still being in a relatively early stage of development/testing or a straightforward error on the part of the developers.
