Powershell, the Gandcrab infection and the long-forgotten server

April 30, 2019

Powershell, the Gandcrab infection and the long-forgotten server

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

CyberUK 2019 If your hair isn’t already grey enough, GCHQ staff have revealed a handful of infosec incidents that, in their words, “surprised us”.

During a talk at CyberUK 2019, the annual shindig of the spy agency’s public-facing offshoot, the National Cyber Security Centre (NCSC), a bespectacled and bearded chap who was introduced only as “Toby L” told an enthralled audience one of his “favourite war stories”.

The NCSC is part of GCHQ’s drive since 2013 to rebuild public trust and convince industry that the government is also interested in their economic wellbeing. As part of that, NCSC occasionally gets called in to help with particularly pernickety problems involving malware infections on corporate networks.

“This specific instance of Gandcrab was not the most exciting,” said “Toby”. “It’s ransomware that’s relatively well-understood in the community. It’s relatively easy to recover from one of those compromises. It’s not the ransomware that’s interesting, though, but how it got where it was.”

A look over the company’s logs revealed that Gandcrab had been introduced via a download from Pastebin – an encoded Base64 binary summoned through a Powershell command, no less.

“Base64 on Powershell is a perfectly legit function. It provides a mechanism to run your Powershell scripts without a dedicated commandlet or a dedicated script file,” commented Toby. “It does look pretty weird and dodgy when you’ve got encoded commands being sent to Powershell but it’s a legitimate use of it.”

What ran Powershell, then? NCSC traced that back to a file called agentmon.exe – and this was where it got interesting.

“It’s a legit file from Kaseya, an IT vendor. They sell products that allow remote management monitoring. If you have an outsourced IT vendor managing your network remotely from their office somewhere in the world, chances are they use a tool like Kaseya. They log into your network, access controls on RDP [remote desktop], SSH, whatever you might be using. Coming in through a backdoor if you like, a custom protocol.”

Agentmon.exe was running on that particular network with system-level privs, deploying Powershell commands across it daily – “adding to the noise ratio a bit”, as Toby put it. Digging into Kaseya’s logs revealed something even more intriguing: the server issuing the commands had been run by an outsourced IT provider, and that provider’s contract with the infected company had ended quite a while ago.

CVE-2017-18362 explained half the story. The critical vuln allows anyone with access to the Kaseya server’s ManagedIT.asmx page through its web interface to execute arbitrary SQL queries. As Toby put it: “No whitelisting, no blacklisting, no password entry… send SQL commands and HTTP POST and it’ll just run it.”

But Powershell? Easy if you know about CVE-2018-20753, which allows (yup, you guessed it) unprivileged remote attackers to execute Powershell payloads on all managed devices.

When the external MSP’s contract had ended, post-contract cleanup by both parties hadn’t included the Kaseya deployment on all the devices across the network. Left unpatched, unoperated and unremembered, the Kaseya server had been found by a baddie who’d made use of two relatively old CVEs to compromise the entire network and distribute ransomware across it.

“One of those weird tech issues,” shrugged Toby.

Malwareless malignancy

Another NCSC bod, “Harry W”, as equally descript as his colleague Toby, took to the podium.

An executive at a company got a WhatsApp invite to a conference call from a personal assistant. After establishing comms, the PA said: “We use Viber [another cross-platform VoIP app] now.”

“It’s a legitimate product,” said Harry. “A perfectly fine messaging platform.”

The PA sent the exec a crafted link. But this was no URL made up of dodgy ASCII lookalike characters, or substituting 1 for I, or even to a suspect domain. This was a URL to viber.com/activate-secondary/[string of random characters].

“Activate secondary is a very specific feature of Viber,” said Harry. “It allows you to sync your Viber accounts on one device with another; for example, a desktop. You can sync messages between different systems. Make phone calls off one and send messages off the other. Enables users to use it a bit more flexibly.”

A useful feature, then. For both good and bad users.

“What we saw was a number of individuals in this organisation who did click this link,” said Harry. “They would activate secondary, paired their device with another – I think it was on the African continent somewhere. What happens? Full address book popped over. Not just the Viber address book; the entire address book on the phone. You might have personal info on there about job titles. Makes the next pivot for social engineering that bit easier.”

It gets worse.

“If you’ve paired your device, it also allows you to spoof phone calls as the person you’ve just synced with,” revealed Harry. “The attacker can now use your caller ID. If you’ve got a credit card synced, you can make Viber-to-landline calls – much more lucrative! You can also, rather than just ringing friends, ring your own 091 hotline number to bring in extra money.”

“Malwareless,” he continued. “It wasn’t using anything particularly sophisticated, but still, a really interesting channel in which they were trying to get that extra information from targets.”

As he pointed out, no mobile device management platform would have picked up this attack; Viber is a legitimate messaging app present in the various app stores. “Again, when you’ve got legit functions from an app, how can you monitor and detect those?”

Security locking out your attack? Never mind – just enrol for a company VPN

Another cautionary tale came from an attack by Iran-based hacking crew APT35, aka “Newscaster”.

The targeted company had been hit a couple of months previously. Diligently, the firm did all the right things: beefed up security, briefed non-techie staff on things to do and not to do, and the rest of it. All exactly by the book.

Except for their VPN implementation.

Users across the company were told to register for access to the new company-wide VPN. No VPN, no access to business-critical stuff. The VPN itself was protected by 2FA.

“What they had missed out was the enrolment to the 2FA VPN authentication was initiated by the users,” said the NCSC bod. “Not all users, particularly those based in offices, need 2FA. So they didn’t enrol, right? All the [threat] actor did was target a bunch of accounts, figure out a user who wasn’t enrolled and then enrolled themselves instead.”

The hackers were literally signing themselves up to the new access-all-areas corporate VPN. They were eventually discovered and shut out again, but not before they had gained access to a critical proof-of-concept deployment where access had been locked down to just four specific accounts.

As well as telling some fascinating stories, the point of this session was a bit wider: NCSC, even as an arm of GCHQ, is getting out there and helping industry with its infosec headaches. While some chunks of industry will doubtless need a lot more convincing than this to give people from a state spy agency access to their sensitive internal networks, it’s a real shift from the days of 2013 and the Snowden revelations.