back to article What does Go-written malware look like? Here's a sample under the microscope

The folks at Deep Instinct say they have studied a Go-written variant of the malware used by the Arid Viper cyber-crime ring. Deep Instinct, founded in 2015, says it uses deep learning to detect and block malware. While training a deep-learning model that's focused on identifying software nasties written in Go, the researchers …

  1. Anonymous Coward
    Anonymous Coward

    Fell for the subheading clickbait

    I thought there would be a mention of the old Gopher protocol coming back into use somewhere.

    1. Clausewitz 4.0 Bronze badge
      Devil

      Re: Fell for the subheading clickbait

      Same here.

  2. Anonymous Coward
    Anonymous Coward

    Antivirus engines may be unfamiliar with ...

    "Antivirus engines may be unfamiliar with the structure or identities of executables produced from these newer languages"

    Which underscores how crappy AV is, especially the "AI" based ones. When I release new binaries & first run them through Virus Total, the majority of false positives are always from Cylance & the other "AI" AV's, which of course, generally also have no false positive reporting processes for them to correct their buggy detection.

  3. fg_swe

    Security Backwards

    1.) A program downloaded from the interwebs (as opposed to properly installed), should prompt a warning to the user.

    2.) In a properly sandboxed system, each executable will only have limited access to files, database connections, camera etc, it actually needs. By default, a random *.exe should only have access to itself, a small collection of standard DLLs and itself. Word should have access to *.docx, C Compiler to *.c and *.h, Catia to *.3dxml and so on.

    3.) The fact that Windows still grants access based on User-ID is a testimony of Microsoft still living in the 1990s. They simply don't bother to proactively secure the system. Any *.exe or any VBA script owns whatever the user owns. And it can open an https connection to badguy.com for immeditate exfiltration of the booty.

    Instead of proper engineering, the "AI" clowns come in and try their bandaids.

    1. fg_swe

      More Specifically

      A) Each *.exe and each script should have a digital signature which includes a unique program name, the name of the author and his organization. This will create some work for script engine developers - so be it.

      B) Each *.exe and each script should have a sandbox profile that limits access and can be inspected by the user easily. Type Enforcement should be the norm. Almost all VBA scripts have no business in reading C code, for example. Scripts and programs without a signed sandbox profile must not be executed. Android is very close to this idea.

      C) IT Administrators can install code signing certificates for their organization. They will work with the script/*.exe author to create proper sandbox profiles and then do the signing.

      D) A centralized mechanism for disabling a named program or script should exist for IT Administrators.

    2. fg_swe

      Sandboxie

      One non-MSFT guy attempted to do the right thing:

      https://sandboxie-plus.com/sandboxie/

      This is the correct approach, but needs more investment.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022