Skip to main content
Cybersecurity

HPE hack claim leaves questions unanswered, threats still out there

“The bigger risk is from unauthorized access to the stolen objects,” one expert tells IT Brew.

Split photo illustration of an in office worker and at home worker.

Illustration: Anna Kim, Photos: Adobe Stock

3 min read

Pipeline blues.

A breach at one of the world’s largest tech companies earlier this month was the work of a notorious hacking group.

Hewlett Packard Enterprise (HPE) said it became aware of the breach on Jan. 16 when Serbian hacking group IntelBroker contacted the company, though it’s still unclear how much information the group obtained.

Awareness is key. In an email, HPE VP of Corporate and Financial Communications Laura Keller said that the company “became aware on Jan. 16 of claims being made by a group called IntelBroker that it was in possession of information belonging to HPE.”

“HPE immediately activated our cyber-response protocols, disabled related credentials, and launched an investigation to evaluate the validity of the claims,” Keller added. “HPE’s investigation has confirmed there is no operational impact to our business nor to HPE products, and no evidence of non-public customer information having been accessed.”

IntelBroker claims that they have information from HPE’s internal networks and is offering to sell company APIs, WePay, and GitHub repositories, as well as a number of other developer-centric materials.

Open questions. How the attack happened is still in question. In an email, KnowBe4 Data-Driven Defense Evangelist Roger Grimes told IT Brew that HPE appears to have followed the rules and taken precautions—raising the question of how exactly IntelBroker accessed the company’s information. While an attacker could, in theory, utilize stolen source code, Grimes said he was unaware of such a hack taking place in the past.

Top insights for IT pros

From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.

“Still, if there was stolen source code and you had a dedicated adversary that was appropriately motivated, having your source code out there is something no development vendor wants,” Grimes wrote. “But to me the bigger risk is from unauthorized access to the stolen objects...did it occur, and if so, how did it occur, and what steps have been taken to prevent it from occurring in the future?”

Targets acquired. Victor Acin, head of threat intel at Outpost24, was more concerned about the potential for developer environments in general being targeted by threat actors. The problem, Acin told IT Brew in an email, is that the platforms “are often managed with lower security standards than production, as they are typically isolated from the internet, despite holding critical assets like source code, credentials, and information about what systems the mirror in production interacts with.”

“A breach in this kind of environment could allow an attacker to poison the development pipeline, ultimately affecting the production environment, with the worst-case scenario being actually gaining control over the final application, as it happened with SolarWinds a few years ago,” Acin wrote. “It’s imperative that organizations treat development environments as high-value targets, ensuring they are secured with the same rigor as production to mitigate risks of breaches and data theft.”

Top insights for IT pros

From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.