You are browsing the archive for Archaeology.

Beyond good ol’ Run key, Part 106

June 1, 2019 in Anti-Forensics, Archaeology, Autostart (Persistence)

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:

  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\ConsoleIME

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)

When your TODO list is always short of something…

June 1, 2019 in Archaeology, Clustering

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.

Until the day you sign.

I mean, the day you literally sign your release .exe and then… it becomes IMMORTAL.

Why immortal?

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.