This is not the first malware to use the Go language. Here is the first, from 2012:

http://www.symantec.com/connect/blogs/malware-uses-google-go...

i believe at the same time symantec decided to block every binary compiled with Go's compiler. because that was easiest.

Indeed. https://github.com/golang/go/issues/3606

"Status changed to Unfortunate."

It's heartening when your security software takes the easy way out. Of anything.

Not only Symantec. See https://github.com/golang/go/issues/16292

Maybe soon we will have some malware written in rust. You know, for security.

But I thought everything written in Rust was supposed to be safe! /s

Sure, it will be safe from crashes and errors ;)

Safe from the POV of malware is like debt from the POV of a bank. Your debt is their asset. Your asset is their liability. Or as Amazon says, your margins are their opportunity.

Technically speaking program written in rust would crash like any other programs. The only differences here is program written in typesafe languages would crash without possibility of undefined behavior.

Funny the binary has the strings embedded in them. You'd think they'd at least make it better at hiding itself. You could just do "strings <binfile>" to find them

"We are Anonymous. All your servers will be DDoS-ed starting {{ .Time.Weekday.String }} ({{ .Time.Format "Jan 2 2006" }}) if you don't pay {{ .Amount }} Bitcoins @"

How often do you check your binaries to find out if they've got suspicious strings in them? :)

I think if you're at the point of running strings on it, you're probably already pretty sure the binary is not above-board.

Obligatory warning about running `strings` on untrusted files: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...

Ah good call.

Hmm. Yeah lol I never run it actually. Still though, if I was writing some malware first question I would ask is how to hide it from people.

I can't tell from the write-up: did they find this in-use/in the wild somewhere, or does it come from a VirusTotal submission?

VT has first submission for analysis in mid-august and 22/55 vendors convicting. from the comments, it seems like the story broke here in may:

http://news.softpedia.com/news/crooks-used-sql-injections-to...

The go toolchain leaves a lot of metadata in a compiled binary, even if you supply `ldflags="-s -w"` - including full paths to source files. Although i appreciate struct member names are needed for reflection (e.g. json.Marshal if you're not using ffjson/equivalent).

In this case, it helped to reverse engineer a malicious binary, but in $DAYJOB we have some concerns about more technical end users using this extra metadata to help patch out our license check code, to the point where we're considering commercial exe packers.

> In this case, it helped to reverse engineer a malicious binary, but in $DAYJOB we have some concerns about more technical end users using this extra metadata to help patch out our license check code, to the point where we're considering commercial exe packers.

Considering that that’s a second semester excercise for students, I’m not sure anything can help with that.

I mean, literally, the "bomblab", aka "Dr. Evil's Insidious Bomb, Version 1.1" is standard at every university’s computer science course, and teaches how to reverse engineer and bypass such checks in binaries.

> I mean, literally, the "bomblab", aka "Dr. Evil's Insidious Bomb, Version 1.1" is standard at every university’s computer science course, and teaches how to reverse engineer and bypass such checks in binaries.

i've read the syllabus from such a class; do you happen to know of such an activity that can be participated in by a non-student?

I would like to learn more about executable reverse engineering, and that sort of approach appeals to me.

I’m not sure what I could do – I have a bomb here from such a class on my system, and could send you it, but I don’t have much of the teaching materials.

What I can suggest to you is learning how to use GDB (if you want to get fancy, use the Radare2 bundle), and learning quite a bit of x86 ASM and calling conventions.

Denuvo might work. Sure, someone can crack it, but it would raise the bar enormously.

Why do you care about users patching out your licence check? If they don't want to pay for your stuff they aren't your users anyway. How do they hurt your business?

There are fringe users who are compelled to purchase software by the difficulty of obtaining a cracked version. Especially for less popular software (which won't be cracked right away / at all) it's worth putting in a bit of effort to raise that bar.

I realise some users won't pay regardless, but personally I was compelled to buy Finale and am strongly considering FL Studio due to cracks being difficult to track down during my youth. (Both software are much easier to pirate today, but that wasn't the case in high school, torrenting on dial up isn't pleasant when you share the line with your parents. Plus I can afford it now, and couldn't then.)

Some of the same things that make Go an amazing language for legitimate use, also make it good for writing malwwre. This isn't the first time I see Go get used in such a fashion.

The ultimate definition of a douche is someone that writes malware for Linux.