Proton Experimental Malware (Linux Steam)

[Argenis]

When using:

Steam Beta Branch: Stable Client
Steam Version: 1716584667
Steam Client Build Date: Fri, May 24 13:48 UTC -08:00
Steam Web Build Date: Fri, May 24 13:31 UTC -08:00
Steam API Version: SteamClient021

I download Proton experimental packages, and my Linux endpoint protection says that there's variants of Babar, Fugrafa, and Fragtor malware found when scanning Steam's folders, specifically on the Proton Experimental folders.

Cleaning them makes Proton still work properly, but I wanted to report this somewhere as there's no place to do so properly in Steam, and while I own Proton Experimental, Steam still says I don't own it so I can't report it per-se.

[Argenis]

Αναρτήθηκε αρχικά από Ben Lubar:

Αναρτήθηκε αρχικά από m662:

Can you provide a link to the scanned resource itself from the official source I can at the very least scan it with my enterprise endpoint see if it detects any behavior.

Since they won't do it, I will:

https://steamdb.info/depot/1493711/history/?changeid=M:7743326805990044174
https://www.virustotal.com/gui/file/723c879ec2df19a5df12ca022d26e92c840662127b4715f4972cfa83aac84fb7/detection

Here's what I can tell you right now without having done any investigation locally: it's a false positive.

How do I know? Because it would be utterly pointless to hide malware in shutdown.exe inside a Proton installation. There are almost no cases where that program would be run by any game. Certainly no instances of shutdown.exe being called in any Steam game I'm aware of.

But in the interest of completeness, I will now load shutdown.exe into Ghidra, the NSA's software reverse engineering framework. We're looking for some difference from the source code at https://github.com/ValveSoftware/wine/blob/bleeding-edge/programs/shutdown/main.c which was last edited in 2019 and has had no substantial changes since 2015 (though one could argue that there were no substantial changes between that version and AT&T's implementation of /bin/true from 1984: https://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

And what do we find? About what we should expect:

int __cdecl _wmain(int _Argc,wchar_t **_Argv,wchar_t **_Env)

{
  byte bVar1;
  byte bVar2;
  int iVar3;
  undefined uVar4;
  char *in_stack_ffffffec;
  
  if ((___wine_dbch_shutdown & 1) == 0) {
    if (_Argc < 1) {
      return 0;
    }
  }
  else {
    _wine_dbg_log.constprop.0(0,0x20,0xd8,"stub:",(char)in_stack_ffffffec);
    uVar4 = SUB41(in_stack_ffffffec,0);
    bVar2 = ___wine_dbch_shutdown & 1;
    if (_Argc < 1) goto LAB_004021fd;
  }
  iVar3 = 0;
  bVar1 = ___wine_dbch_shutdown;
  do {
    while (uVar4 = SUB41(in_stack_ffffffec,0), (bVar1 & 1) != 0) {
      iVar3 = iVar3 + 1;
      in_stack_ffffffec = _wine_dbgstr_wn.constprop.0();
      _wine_dbg_log.constprop.0(0,0x20,0xd8,&DAT_0040401d,(char)in_stack_ffffffec);
      uVar4 = SUB41(in_stack_ffffffec,0);
      bVar2 = ___wine_dbch_shutdown & 1;
      bVar1 = ___wine_dbch_shutdown;
      if (_Argc == iVar3) goto LAB_004021fd;
    }
    iVar3 = iVar3 + 1;
    bVar2 = 0;
  } while (_Argc != iVar3);
LAB_004021fd:
  if (bVar2 == 0) {
    return 0;
  }
  _wine_dbg_log.constprop.0(0,0x20,0xd8,&DAT_00404021,uVar4);
  return 0;
}

An implementation of /bin/true with some debug logging.

I did not know that when using that tool, it analyzed the compiled software deployed by Steam's servers to the end users.

Thank you for that information, I'd still love to have steam analyze the resulting package being given to end-users.

[m662]

Αναρτήθηκε αρχικά από Ben Lubar:

Αναρτήθηκε αρχικά από m662:

Can you provide a link to the scanned resource itself from the official source I can at the very least scan it with my enterprise endpoint see if it detects any behavior.

Since they won't do it, I will:
An implementation of /bin/true with some debug logging.

Well that saves me a lot of time but for the sake of my offer I will still put it in our ESET Enterprise point. Though seeing the Re I have little doubt your wrong on this matter. My thanks to you as I know how valuable this kind of expertise and time is especially on voluntary basis.

Got the sample from
From: DepotDownloader.exe -app 1493710 -depot 1493711 -username m662
depots\1493711\14456479\files\lib\wine\i386-windows\shutdown.exe

Nothing comes up at our side thing did not even threw a alert when I send the .exe straight from mail. I am submitting the sample to [e-mail] so they can do a scan on there end they usually not report back to the client but they do submit the results in a DB that other vendors can check against.

Addendum
Eset Endpoint scan
https://gcdnb.pbrd.co/images/Ne1r60dRglJz.png

Eset Protection dashboard system alerts
https://gcdnb.pbrd.co/images/Z1oWqSHXRsRA.png

[Argenis]

Αναρτήθηκε αρχικά από m662:

Αναρτήθηκε αρχικά από Ben Lubar:

Since they won't do it, I will:
An implementation of /bin/true with some debug logging.

Well that saves me a lot of time but for the sake of my offer I will still put it in our ESET Enterprise point. Though seeing the Re I have little doubt your wrong on this matter. My thanks to you as I know how valuable this kind of expertise and time is especially on voluntary basis.

Got the sample from
From: DepotDownloader.exe -app 1493710 -depot 1493711 -username m662
depots\1493711\14456479\files\lib\wine\i386-windoww\shutdown.exe

Nothing comes up at our side thing did not even threw a alert when I send the .exe straight from mail. I am submitting the sample to [e-mail] so they can do a scan on there end they usually not report back to the client but they do submit the results in a DB that other vendors can check against.

Addendum
Eset Endpoint scan
https://gcdnb.pbrd.co/images/Ne1r60dRglJz.png

Eset Protection dashboard system alerts
https://gcdnb.pbrd.co/images/Z1oWqSHXRsRA.png

Thank you, I just want to note that his analysis was of the source code and it does not take into consideration if the build/deploy/compiled storage clients use to download are compromised, also known as a supply chain attack.

Just my two cents, but I just wanted to make everyone aware.

[m662]

Αναρτήθηκε αρχικά από Argenis:

Thank you, I just want to note that his analysis was of the source code and it does not take into consideration if the build/deploy/compiled storage clients use to download are compromised, also known as a supply chain attack.

Just my two cents, but I just wanted to make everyone aware.

depotdownloader does what the steam normally does it contacts Steams repo than gets the package. Ben Lubar did one from the source build I simulated retrieval as an official client from regular server network.

DPD process captured here.
https://go.screenpal.com/watch/cZht3lVLML4

And again command line is provided if you want to check with DepotDownloader yourself.
But from my professional perspective Ben Lubar method provided more tangible evidence than mine as I do not reverse engineer code unless I absolutely have to. I got people for that but they are not cheap on hour rate and I imagine Ben is not cheap either.


I highly advice if you have a enterprise subscription to simply submit it to them because you really should not base conclusions on heuristics alone. Especially in the case where unlike 99% of Steam users you have access to professional sources. Which you must trust because why would you ever sign a enterprise contract in the first place if you don't


That said me personally am going to move on from this case. Have a nice time here and hopefully this alleviates some of your worry and if not again reach out to your business contact. I pester mine all the time when in doubt that is what the S.L.A's are for after all.

[76561199648916059]

It's not the first time or last time malware was slipped into installation code, there are several game installs that do this as well.

What I don't agree with is giving up on taking care to not completely check it and at least investigate into the issue, it is presumptuous to assume a mistake or corrupted code could not get into a steam install

[Komarimaru]

Αναρτήθηκε αρχικά από Majestically Awkward:

It's not the first time or last time malware was slipped into installation code, there are several game installs that do this as well.

What I don't agree with is giving up on taking care to not completely check it and at least investigate into the issue, it is presumptuous to assume a mistake or corrupted code could not get into a steam install

No Malware was in the code, quit spouting lies.

[m662]

Αναρτήθηκε αρχικά από Majestically Awkward:

It's not the first time or last time malware was slipped into installation code, there are several game installs that do this as well.

What I don't agree with is giving up on taking care to not completely check it and at least investigate into the issue, it is presumptuous to assume a mistake or corrupted code could not get into a steam install

Well than your welcome to come up with your own verifiable data and test-lab results if you believe either missed crucial steps in the detection process.

All the methods have been documented I personally added the client retrieval of the data as video evidence and have submitted it to a reputable cyber-security vendor for further review. Your welcome to spend your own professional time on the matter.

We have a rule in IT never trust always verify.

[76561199648916059]

I can respect that but it's always good to take the time to send it to a professional analyst in events like this, false positives are why things like power grids went down, make no mistakes steam is a big target for many who want to make a name for themselves.

Better safe then reckless abandonment of a situation like this

[Iron Knights]

Warfare extended to Linux since it's the biggest enemy of MS. Most virii are written by Corporations.

[m662]

Αναρτήθηκε αρχικά από Majestically Awkward:

I can respect that but it's always good to take the time to send it to a professional analyst in events like this, false positives are why things like power grids went down, make no mistakes steam is a big target for many who want to make a name for themselves.

Better safe then reckless abandonment of a situation like this

Yes if you have those resources and willing to spend them you should.

However I am going to disagree with Steam being a big target. Any target is a target unless you actively monitor for it in your security. What I can say is that Steam has not come up in any security feeds for years in our SOC. That said again caution is never a bad thing but verify data.

I would be more worried though with regards to these.

Russian Web Hosting Data Leak Over 54 million user profiles were exposed, compromising sensitive data such as email addresses and phone numbers. February 22, 2024

Microsoft Azure Data Breach Accounts of hundreds of senior executives were compromised. The attack used phishing and cloud account takeovers. February 12, 2024

Bank of America Data Breach The data breach was traced to a cyberattack targeting Infosys McCamish Systems, compromising names, SSNs, and account details. February 6, 2024

Cyber Attack on the Russian Center for Space Hydrometeorology (Planeta) 2 petabytes of data were deleted, impacting over 50 state entities, including the Ministry of Defense of the
Russian Federation and Roscosmos. January 26, 2024

Mother of All Breaches (MOAB) This massive data leak of over 26 billion records from various platforms emphasized the importance of cybersecurity globally. January 22, 2024