This persistence trick has a historical value only (at least as far as I can tell). It only works on old Windows XP, and only on systems with IME e.g. Chinese.
On these systems when console window is created, the kernel32.dll reaches out to the following Registry entry:
It then fetches the string that is stored there. If the entry is not present, the default ‘conime.exe’ string is assumed.
The conime.exe, or its replacement is then launched.
In the demo below, I run a test on Chinese Windows XP, where I set the value to calc.exe. You can’t specify a full path – the system will prepend the value with a path referring to its system directory (e.g. c:\windows\system32\). Of course, we can always use parent directory trick to run any file from any location on a system (e.g. ..\..\test\malware.exe will run c:\test\malware.exe)
There is only one place visited by Windows coders less often than anything else: their program’s resource section. This is either a sacred or a scary place, depending on the coders’ inner fears or strengths – but no matter which one it is, with this post I want to draw your attention to program’s VERSIONINFO section.
If program is coded in Visual Studio – its versioninfo is typically pre-populated with a bunch of boilerplate TODO strings:
It is the place where we specify the name of the program, its version, description, add copyright notice, and where we add the name of the company that produced it, etc.. Some programmers adjust these automatically via intricate command line tools or scripts, some edit these manually. Some… forget to do so….
Now… creating software is exciting. Writing your new, revolutionary code is an exhilarating experience (or a dull one, if you are bored to death in your job), and with all these cool (boring) features you are adding so quickly, the poor versioninfo section is typically left behind.
It’s signed… kinda forever. Certificate revocations happen quite rarely. And if legitimate, your .exe will most likely end up on many popular download, mirroring sites, and/or in in AV and EDR repositories. And if it has a built-in vulnerability, backdoor, or some stupid logic flaw or dependency, and worse – if there is an active exploit/trick for it – you can be sure that it will become a long-living part of an arsenal of attacker groups. And if you still have doubts… nothing is ever permanently deleted from the internet anyway 😉
Back to your signed file…
If you have not edited these versioninfo properties – they will make it to the signed build. If there is no proper QC process, the version information bits that you were supposed to fill-in early in the process will be left untouched e.g.:
TODO: File Description
TODO: Company Name
Yup. Anyone viewing properties of your signed file will see something like this:
It’s ugly. And… it’s so… common.
Over years I have seen many signed binaries with the version info populated with a default ‘TODO” boilerplate. I find it to be a truly interesting phenomenon. I mean, who would forget it before signing? Right?
I was curious how many companies actually did forget to change that boilerplate at some stage in the past. Obviously, I don’t have all the files of the world, so the list below is biased, but on the other hand, I have been collecting clean files for many years now… so I think it’s still kinda representative – especially that many big names are on it.
The examples are just single hash/company, but there are more hashes/company, obviously:
Acer Incorporated
2C11C7769AFBA91795309335E95364610B64A0D5
Advanced Micro Devices
E7C988AAE8A28537418BAAF9C6D627F1E9A71D3D
Alps Electric Co.
F0081345B04426F2327CC83BCB78549F266D02B2
ASUSTeK Computer Inc.
4EFE7101C6E34FF6654B27C0E356B3906077228F
AzureWave Technologies
B502DF357711B544A9D358F4BBD5A570AC94A2D8
Broadcom Corporation
163BD9619BE13A149CD0FC23E9591D0B557FF8AC
Clearwire Corporation
3A34C830547BF851D803351D9F0F9FE5A756ECAB
Conexant Systems
B0464EA6E85DCF73BCDB7F59E2FE39E1F30F0BC6
CyberLink
E9376D0887317F7294887AD51C40DB8C775D1439
Dell Incorporated
404E4A8C86A6E45328B324B5BAC0CA1022C46F7C
DTS
3FDB841A79DC5A19581608A9F7DC277D646DD2B9
GENESYS LOGIC
C3E0A08681282C2F07647B62607FC02F684E2302
Hewlett Packard
9A947DB8463B010CE60FAE48C995C2349E913026
HTC Corp.
C2702513C3B1E8782A5C09845EA3AD9DD6150272
Huawei Technologies Co.
D4BA877C07342C2EE4DD07D35A3FCF065C28A7D9
Intel Corporation-Mobile Wireless Group
CB92B9366322BADD7FE8468586D6BCF5F3EDD267
IVT CORPORATION
05B5F6413FE4AE449007B6FC70FBB196DA5F3881
Lenovo Information Products (Shenzhen) Co.
71F10E73D71A651CC2A31B5D5B4A4710A386E419
Logitech
A81A76EFF455966DBAFEFE33AFA0005B128652A3
Magic Control Technology Corp.
334367D94B8096BE8109DBAA7B2DF43CF7EE4DB3
Microsoft Windows Hardware Compatibility Publisher
638A2003B302900AF56AF7BE9FB83F6EC022F391
Penpower Technology Ltd.
10ECABAE634F48F57594BE5A72723415B3FC2192
Ralink Technology Corporation
E75E67EF40D83C4819E47F138AA3AE24955787EF
Realtek Semiconductor Corp
D9F1DCC120C684D233AA7F2C234AC6A3C35C0B4C
Samsung Electronics CO.
A37D12C80ACF024F6F0D1EABD919BB3149C2B4EC
Sentelic Corporation
B53564DE1380AF1169F8D356E8BC8C917310F627
Softex Incorporated
679528394EF830468E2A335C597CD75E8096B8CD
Stardock Corporation
6CF78EF4597F9646B01654AD5ABFE4F73A93006B
VIA Technologies Inc.
A8CBD410AEA6A7C5E850B8659725E736BBFAA30F
Wave Systems Corp.
EB357F2096537F6AA1A24366258F781AD5DE9CFF
And I list these not to shame the companies. As I mentioned – I think it’s an interesting phenomena from a sample clustering perspective, and I don’t think it really affects security in any significant way. At the end of the day, a signed file is still a signed file so you can be sure it’s ‘better’ than an unsigned one. Yes, there are malware families signed with a stolen or a forged certificate, but still, you will be always better off trusting the signed files more than non-signed ones.
Still… how does it affect us, Blue teamers?
I don’t have all the answers and welcome comments. Obviously, adding exclusions/whitelists that treat ‘TODO’ strings as a trusted ‘Signed Publisher’ is not a good idea. This obviously adds a need for us to whitelist these files by hashes, or paths.
If found on the investigated system, these files may attract the attention of forensic investigators as well (e.g. if they look at autostart records and detect entries that point to signed TODO executables). After so many, heavily publicized reports about stolen certs, or supply chain attacks, it’s only natural to immediately generate hypothesis about ‘if I see TODO: strings, this system was probably attacked by someone using malware signed with a stolen cert’.
Finally, it also exposes a less-discussed weakness of the signed files:
We often forget that there are programmers behind every signed file
These coders make mistakes; many mistakes
– a.k.a. if there is a bug in versioninfo, there could be a bug in the code. Or… it could be a feature :-).
Last, but not least: if you produce software on regular basis, please add the QC stage to your process where the release build is always checked against TODO entries. Kill the build if needed, because it is a proper build breaker. Fix it. Release good releases. Thank you.
