Connect with us

Security

Extensive hacking operation discovered in Kazakhstan

Published

on

Chinese cyber-security vendor Qihoo 360 published a report on Friday exposing an extensive hacking operation targeting the country of Kazakhstan.

Targets included individuals and organizations involving all walks of life, such as government agencies, military personnel, foreign diplomats, researchers, journalists, private companies, the educational sector, religious figures, government dissidents, and foreign diplomats alike.

The campaign, Qihoo 360 said, was broad, and appears to have been carried by a threat actor with considerable resources, and one who had the ability to develop their private hacking tools, buy expensive spyware off the surveillance market, and even invest in radio communications interception hardware.

Signs point that some attacks relied on sending targets carefully crafted emails carrying malicious attachments (spear-phishing), while others relied on getting physical access to devices, suggesting the use of on-the-ground operatives deployed in Kazakhstan.

Meet Golden Falcon

Qihoo researchers named the group behind this extensive campaign Golden Falcon (or APT-C-34). The Chinese security vendor claimed the group was new, but when ZDNet reached out to Kaspersky, we were told Golden Falcon appears to be another name for DustSquad, a cyber-espionage entity that has been active since 2017.

The only report detailing its previous hacking operations dates back to 2018 when it was seen using spear-phishing emails that lead users to a malware-laced version of Telegram.

Just like the attacks documented by Qihoo this week, the 2018 attacks also focused on Kazakhstan but had used a different malware strain.

Qihoo’s new report is primarily based on data the Chinese company obtained after it gained access to one of Golden Falcon’s command and control (C&C) server, from where they retrieved operational data about the group’s activities.

Here, the Chinese firm said it found data retrieved from infected victims. Collected data involved primarily office documents, taken from hacked computers.

All the stolen information was arranged in per-city folders, with each city folder containing data on each infected host. Researchers said they found data from victims located in Kazakhstan 13 largest cities, and more.


Image: Qihoo 360

The data was encrypted, but researchers said they were able to decrypt it. Inside, they also found evidence that Golden Falcon was also spying on foreign nationals in the country — with Qihoo naming Chinese international students and Chinese diplomats as targets.

Expensive hacking tools

Files on the C&C server revealed what types of hacking tools this group was using. Two tools stood out. The first was a version of RCS (Remote Control System), a surveillance kit sold by Italian vendor HackingTeam. The second was a backdoor trojan named Harpoon (Garpun in the Russian language) that appears to have been developed by the group itself.

In regards to its use of RCS, what stood out was that Golden Falcon was using a new version of RCS. The RCS version number is important because, in 2015, a hacker breached and then leaked all the HackingTeam’s internal files, including the source code for RCS.

At the time, the RCS version number was 9.6. According to Qihoo, the version number for the RCS instances they found in Golden Falcon’s possession was 10.3, a newer version, meaning the group most likely bought a newer version from its distributor.

But Golden Falcon was also in the possession of another potent tool. Qihoo says the group was using a unique backdoor that hasn’t been seen outside the group’s operations and was most likely their own creation.

The Chinese vendor said it obtained a copy of this tool’s manual. It is unclear if they found the manual on the group’s C&C server, or if they obtained it from another source. The manual, however, shows a well-developed tool with a large feature-set, on par with many of today’s top existing backdoor trojans.

gf-harpoon.png

Image: Qihoo 360

Features include:

  • Keylogging
  • Steal clipboard data
  • Take screenshot of the active window at predetermined intervals
  • List the contents of a given directory
  • Get Skype login name, contact list, and chat message history
  • Get Skype and Google Hangouts contacts and voice recordings
  • Record sound via the microphone, eavesdropping
  • Copy a specified file from the target computer
  • Automatically copy files from removable media
  • Store all intercepted data in an encrypted data file, inside a specified directory
  • Send stolen data to a specified FTP server
  • Run a program or operating system command
  • Download files from a given FTP into a specific directory
  • Remotely reconfigure and update components
  • Receive data files from a given FTP and automatically extract the files to a specified directory
  • Self-destruct

Most of the features listed above are the norm for most high-level backdoor trojans, usually encountered in nation-state level cyber-espionage.

Mobile malware

But Qihoo researchers also found additional files, such as contracts, supposedly signed by the group.

It is important to point out that cyber-espionage groups don’t leave contracts sitting around on C&C servers. It is unclear if these contracts were found on Golden Falcon’s C&C server, or were retrieved from other sources. Qihoo didn’t say.

One of these contracts appears to be for the procurement of a mobile surveillance toolkit known as Pegasus. This is a powerful mobile hacking tool, with Android and iOS versions, sold by NSO Group.

The contract suggests that Golden Eagle had, at least, shown interest in acquiring NSO’s Android and iOS surveillance tools. It is unclear if the contract was ever completed with a sale, as Qihoo didn’t find any evidence of NSO’s Pegasus beyond the contract.

gf-nso.png

Image: Qihoo 360

Either way, Golden Eagle did have mobile hacking capabilities. This capability was provided via Android malware supplied by the HackingTeam.

Qihoo said the malware they analyzed included 17 modules with features ranging from audio eavesdropping to browser history tracking, and from stealing IM chat logs to tracking a victim’s geo-location.

Radio interception hardware

A second set of contracts showed that Golden Falcon had also acquired equipment from Yurion, a Moscow-based defense contractor that’s specialized in radio monitoring, eavesdropping, and other communications equipment.

Again, Qihoo only shared details about the contract’s existence, but could not say if the equipment was bought or used — as such capabilities go beyond the tools at the disposal of a regular security software company.

gf-yurion.png

Image: Qihoo 360

Tracking down members?

The Chinese cyber-security firm also said it tracked down several Golden Falcon members through details left in legal digital signatures, supposedly found inside the contracts they discovered.

Researchers said they tracked four Golden Falcon members and one organization.

Using data that was left uncensored in a screenshot shared by Qihoo, we were able to track one of the group’s members to a LinkedIn profile belonging to a Moscow area-based programmer that the Chinese firm described as “a technical engineer” for Golden Falcon.

No official attribution — but plenty of theories

Neither Qihoo nor Kaspersky, in its 2018 report, make any formal attribution for this group. The only detail the two shared was that this was a Russian-speaking APT (advanced persistent threat — a technical term used to describe advanced, nation-state backed hacking units).

During research for this article, ZDNet asked a few analysts for their opinions. The most common theories we heard were that this “looks” to be (1) a Russian APT, (2) a Kazakh intelligence agency spying on its citizens, (3) a Russian mercenary group doing on-demand spying for the Kazakh government — with the last two being the most common answer.

However, it should be noted that these arguments are subjective and not based on any actual substantial proof.

The use of HackingTeam surveillance software, and the inquiry into buying NSO Group mobile hacking capabilities does show that this could be, indeed, an authorized law enforcement agency. However, Qihoo also pointed out that some of the targets/victims of this hacking campaign were also Chinese government officials in north-west China — meaning that if this was a Kazakh law enforcement agency, then they seriously overstepped their jurisdiction.

The Qihoo Golden Falcon report is available here, in Chinese, and here, translated with Google Translate. The report contains additional technical information about the malware used in these attacks, information that we didn’t include in our coverage because it was too technical.



Source link

Security

Retrospective thoughts on KubeCon Europe 2022

Published

on

I’m not going to lie. As I sit on a plane flying away from Valencia, I confess to have been taken aback by the scale of Kubecon Europe this year. In my defence, I wasn’t alone the volume of attendees appeared to take conference organisers and exhibitors by surprise, illustrated by the notable lack of water, (I was told) t-shirts and (at various points) taxis.

Keynotes were filled to capacity, and there was a genuine buzz from participants which seemed to fall into two camps: the young and cool, and the more mature and soberly dressed.

My time was largely spent in one-on-one meetings, analyst/press conferences and walking the stands, so I can’t comment on the engineering sessions. Across the piece however, there was a genuine sense of Kubernetes now being about the how, rather than the whether. For one reason or another, companies have decided they want to gain the benefits of building and deploying distributed, container-based applications.

Strangely enough, this wasn’t being seen as some magical sword that can slay the dragons of legacy systems and open the way to digital transformation the kool-aid was as absent as the water. Ultimately, enterprises have accepted that, from an architectural standpoint and for applications in general, the Kubernetes model is as good as any available right now, as a non-proprietary, well-supported open standard that they can get behind.

Virtualisation-based options and platform stacks are too heavyweight; serverless architectures are more applicable to specific use cases. So, if you want to build an application and you want it to be future-safe, the Kubernetes target is the one to aim for.

Whether to adopt Kubernetes might be a done deal, but how to adopt certainly is not. The challenge is not with Kubernetes itself, but everything that needs to go around it to make resulting applications enterprise-ready.

For example, they need to operate in compliance environments; data needs to be managed, protected, and served into an environment that doesn’t care too much about the state; integration tools are required with external and legacy systems; development pipelines need to be in place, robust and value-focused; IT Operations need a clear view of what’s running whereas a bill of materials, and the health of individual clusters; and disaster recovery is a must.

Kubernetes doesn’t do these things, opening the door to an ecosystem of solution vendors and (often CNCF-backed) open source projects. I could drill into these areas Service Mesh, GitOps, orchestration, observability, and backup but the broader point is that they are all evolving and coalescing around the need. As they increase in capability, barriers to adoption reduce and the number of potential use cases grows.

All of which puts the industry at an interesting juncture. It’s not that tooling isn’t ready: organizations are already successfully deploying applications based on Kubernetes. In many cases, however, they are doing more work than they need developers need insider knowledge of target environments, interfaces need to be integrated rather than using third-party APIs, higher-order management tooling (such as AIOps) has to be custom-deployed rather than recognising the norms of Kubernetes operations.

Solutions do exist, but they tend to be coming from relatively new vendors that are feature rather than platform players, meaning that end-user organisations have to choose their partners wisely, then build and maintain development and management platforms themselves rather than using pre-integrated tools from a singe vendor.

None of this is a problem per se, but it does create overheads for adopters, even if they gain earlier benefits from adopting the Kubernetes model. The value of first-mover advantage has to be weighed against that of investing time and effort in the current state of tooling: as a travel company once told me, “we want to be the world’s best travel site, not the world’s best platform engineers.”

So, Kubernetes may be inevitable, but equally, it will become simpler, enabling organisations to apply the architecture to an increasingly broad set of scenarios. For organisations yet to make the step towards Kubernetes, now may still be a good time to run a proof of concept though in some ways, that sip has sailed perhaps focus the PoC on what it means for working practices and structures, rather than determining whether the concepts work at all.

Meanwhile and perhaps most importantly, now is a very good moment for organisations to look for what scenarios Kubernetes works best “out of the box”, working with providers and reviewing architectural patterns to deliver proven results against specific, high-value needs these are likely to be by industry and by the domain (I could dig into this, but did I mention that I’m sitting on a plane? ).

Jon Collins from Kubecon 2022

Kubernetes might be a done deal, but that doesn’t mean it should be adopted wholesale before some of the peripheral detail is ironed out.

The post Retrospective thoughts on KubeCon Europe 2022 appeared first on GigaOm.

Continue Reading

Security

Retrospective thoughts on Kubecon

Published

on

I’m not going to lie. As I sit on a plane flying away from Valencia, I confess to have been taken aback by the scale of Kubecon Europe this year. In my defence, I wasn’t alone the volume of attendees appeared to take conference organisers and exhibitors by surprise, illustrated by the notable lack of water, (I was told) t-shirts and (at various points) taxis.

Keynotes were filled to capacity, and there was a genuine buzz from participants which seemed to fall into two camps: the young and cool, and the more mature and soberly dressed.

My time was largely spent in one-on-one meetings, analyst/press conferences and walking the stands, so I can’t comment on the engineering sessions. Across the piece however, there was a genuine sense of Kubernetes now being about the how, rather than the whether. For one reason or another, companies have decided they want to gain the benefits of building and deploying distributed, container-based applications.

Strangely enough, this wasn’t being seen as some magical sword that can slay the dragons of legacy systems and open the way to digital transformation the kool-aid was as absent as the water. Ultimately, enterprises have accepted that, from an architectural standpoint and for applications in general, the Kubernetes model is as good as any available right now, as a non-proprietary, well-supported open standard that they can get behind.

Virtualisation-based options and platform stacks are too heavyweight; serverless architectures are more applicable to specific use cases. So, if you want to build an application and you want it to be future-safe, the Kubernetes target is the one to aim for.

Whether to adopt Kubernetes might be a done deal, but how to adopt certainly is not. The challenge is not with Kubernetes itself, but everything that needs to go around it to make resulting applications enterprise-ready.

For example, they need to operate in compliance environments; data needs to be managed, protected, and served into an environment that doesn’t care too much about the state; integration tools are required with external and legacy systems; development pipelines need to be in place, robust and value-focused; IT Operations need a clear view of what’s running whereas a bill of materials, and the health of individual clusters; and disaster recovery is a must.

Kubernetes doesn’t do these things, opening the door to an ecosystem of solution vendors and (often CNCF-backed) open source projects. I could drill into these areas Service Mesh, GitOps, orchestration, observability, and backup but the broader point is that they are all evolving and coalescing around the need. As they increase in capability, barriers to adoption reduce and the number of potential use cases grows.

All of which puts the industry at an interesting juncture. It’s not that tooling isn’t ready: organizations are already successfully deploying applications based on Kubernetes. In many cases, however, they are doing more work than they need developers need insider knowledge of target environments, interfaces need to be integrated rather than using third-party APIs, higher-order management tooling (such as AIOps) has to be custom-deployed rather than recognising the norms of Kubernetes operations.

Solutions do exist, but they tend to be coming from relatively new vendors that are feature rather than platform players, meaning that end-user organisations have to choose their partners wisely, then build and maintain development and management platforms themselves rather than using pre-integrated tools from a singe vendor.

None of this is a problem per se, but it does create overheads for adopters, even if they gain earlier benefits from adopting the Kubernetes model. The value of first-mover advantage has to be weighed against that of investing time and effort in the current state of tooling: as a travel company once told me, “we want to be the world’s best travel site, not the world’s best platform engineers.”

So, Kubernetes may be inevitable, but equally, it will become simpler, enabling organisations to apply the architecture to an increasingly broad set of scenarios. For organisations yet to make the step towards Kubernetes, now may still be a good time to run a proof of concept though in some ways, that sip has sailed perhaps focus the PoC on what it means for working practices and structures, rather than determining whether the concepts work at all.

Meanwhile and perhaps most importantly, now is a very good moment for organisations to look for what scenarios Kubernetes works best “out of the box”, working with providers and reviewing architectural patterns to deliver proven results against specific, high-value needs these are likely to be by industry and by the domain (I could dig into this, but did I mention that I’m sitting on a plane? ).

Jon Collins from Kubecon 2022

Kubernetes might be a done deal, but that doesn’t mean it should be adopted wholesale before some of the peripheral detail is ironed out.

The post Retrospective thoughts on Kubecon appeared first on GigaOm.

Continue Reading

Security

Defeating Distributed Denial of Service Attacks

Published

on

It seems like every day the news brings new stories of cyberattacks. Whether ransomware, malware, crippling viruses, or more frequently of late—distributed denial of service (DDoS) attacks. According to Infosec magazine, in the first half of 2020, there was a 151% increase in the number of DDoS attacks compared to the same period the previous year. That same report states experts predict as many as 15.4 million DDoS attacks within the next two years.

These attacks can be difficult to detect until it’s too late, and then they can be challenging to defend against. There are solutions available, but there is no one magic bullet. As Alastair Cooke points out in his recent “GigaOm Radar for DDoS Protection” report, there are different categories of DDoS attacks.

And different types of attacks require different types of defenses. You’ll want to adopt each of these three defense strategies against DDoS attacks to a certain degree, as attackers are never going to limit themselves to a single attack vector:

Network Defense: Attacks targeting the OS and network operate at either Layer 3 or Layer 4 of the OSI stack. These attacks don’t flood the servers with application requests but attempt to exhaust TCP/IP resources on the supporting infrastructure. DDoS protection solutions defending against network attacks identify the attack behavior and absorb it into the platform.

Application Defense: Other DDoS attacks target the actual website itself or the web server application by overwhelming the site with random data and wasting resources. DDoS protection against these attacks might handle SSL decryption with hardware-based cryptography and prevent invalid data from reaching web servers.

Defense by Scale: There have been massive DDoS attacks, and they show no signs of stopping. The key to successfully defending against a DDoS attack is to have a scalable platform capable of deflecting an attack led by a million bots with hundreds of gigabits per second of network throughput.

Table 1. Impact of Features on Metrics
[chart id=”1001387″ show=”table”]

DDoS attacks are growing more frequent and more powerful and sophisticated. Amazon reports mitigating a massive DDoS attack a couple of years ago in which peak traffic volume reached 2.3 Tbps. Deploying DDoS protection across the spectrum of attack vectors is no longer a “nice to have,” but a necessity.

In his report, Cooke concludes that “Any DDoS protection product is only part of an overall strategy, not a silver bullet for denial-of-service hazards.” Evaluate your organization and your needs, read more about each solution evaluated in the Radar report, and carefully match the right DDoS solutions to best suit your needs.

Learn More About the Reports: Gigaom Key Criteria for DDoS, and Gigaom Radar for DDoS

The post Defeating Distributed Denial of Service Attacks appeared first on GigaOm.

Continue Reading

Trending