## Introduction

Application programming interfaces (APIs) are the glue that holds together the modern world. They allow applications to communicate with each other, share data, and perform tasks. As a result, APIs are increasingly being used to access sensitive data and systems. This makes them a prime target for cyberattacks.

In 2023, APIs are becoming the new battleground for application security. Here are some of the reasons why:

- **The number of APIs is exploding:** The number of APIs in use is growing exponentially. In fact, it is estimated that there will be over 500 billion APIs in use by 2023. This growth is being driven by the increasing popularity of cloud computing, microservices, and DevOps.
 
 
- **APIs are often poorly secured:** API security is often overlooked by developers. This is because APIs are often seen as a communication layer between applications, and not as a security boundary. As a result, APIs are often vulnerable to a variety of attacks, such as unauthorized access, injection attacks, and denial-of-service attacks.
 
 
- **APIs are used to access sensitive data:** APIs are often used to access sensitive data, such as financial information, customer data, and intellectual property. This makes them a valuable target for attackers.



The growing number of APIs, their poor security posture, and the sensitive data they often access make them a major target for cyberattacks.

## How to Mitigate API Security Risks?

There are a number of steps that organizations can take to mitigate API security risks. These include:

- **Implementing strong authentication and authorization controls:** This will help to prevent unauthorized access to APIs.
 
 
- **Encrypting data in transit and at rest:** This will help to protect sensitive data from being intercepted or stolen.

 
- **Using API security tools and services:** There are a number of API security tools and services available that can help to detect and prevent API attacks.
 
 
- **Training developers on API security best practices:** Developers should be trained on how to develop secure APIs.


By taking these steps, organizations can help to protect their APIs and the data they access.


## How Threatspy Can Help?

Here are some of the ways Threatspy can help organizations mitigate API security risks:

- **Comprehensive security scanning:** Threatspy uses advanced heuristic algorithms to scan APIs for a wide range of vulnerabilities, including SQL injection, cross-site scripting, and denial-of-service attacks. 
 
- **Accurate assessments:** Threatspy's scanning engine is highly accurate, minimizing false positives and providing organizations with accurate assessments of their API security posture.
 
- **Automated remediation:** Threatspy can automatically remediate many API vulnerabilities, saving organizations time and money.
 
- **Seamless integration:** Threatspy integrates with a wide range of workflow apps & CI/CD pipeline, making it easy for organizations to incorporate it into their existing security processes.




**According to a recent report by Akamai, APIs are now the top target for attackers, accounting for 83% of web-related attacks.**

With [Threatspy](https://www.secureblink.com/threatspy), developers can confidently release secure APIs and applications, knowing that any vulnerabilities identified can be fixed and remediated in real-time. Threatspy's heuristic approach identifies both known & unknown vulnerabilities and prioritizes  with a custom-built Reachability Framework, while its Auto Remediation Playbook and Mitigation Campaign streamline the remediation process and calculate ROI. This allows organizations to rapidly identify & mitigate vulnerabilities than they can today.


To get started with Threatspy, [request a demo now !](https://www.secureblink.com/threatspy#join-waitlist)



Learn why APIs are becoming the new battleground for application security. Explore unique security challenges and essential measures for API protection.

APIs: The New Battleground for Application Security - Here's Why

Application Security 

Web Application Firewalls (WAFs) have become a go-to security tool for organizations looking to protect their websites & web applications from a whole host of cyberattacks. WAFs can effectively block many types of attacks, including cross-site scripting (XSS), SQL injection, and more. But what if we told you that your organization's web applications and APIs may still be at risk even if you have a WAF in place? 


In this blog post, we'll know the reasons why even with WAF, your organization is not safe! 


### WAFs are not foolproof: 
While WAFs work by looking for known patterns or indicators of attacks in incoming traffic and blocking requests that match these patterns. However, hackers are also leveraging new techniques to bypass WAFs, making it difficult for WAFs to keep up with the ever-evolving threat landscape

For example, an attacker can use obfuscation techniques to hide malicious payloads or encode payloads to evade pattern-based detection. Additionally, an attacker can use a slow attack rate or make slight variations to bypass WAFs' rate-limiting rules. In some cases, attackers can bypass WAFs entirely by exploiting application logic flaws that are outside the scope of WAFs.

### WAFs do not protect against all types of attacks: 
WAFs help protects against common web-based attacks, but do not provide comprehensive attacks. 
For example, WAFs are not designed to protect against attacks that primarily target the application vulnerability, such as code injection or misconfigured servers. They also do not protect against attacks that target users directly, such as phishing or social engineering.



### WAFs can cause false positives: 
WAFs can often generate false positives, blocking legitimate traffic and preventing users from accessing your application. False positives can occur due to various reasons, such as misconfiguration, inadequate rules, or unanticipated traffic patterns. For example, if you have an e-commerce website, a sudden surge in traffic during holiday sales might trigger a false positive and block legitimate traffic, leading to frustration among users and can also cause operational issues for your organization.



Therefore, WAFs can be an important part of your application security strategy but shouldn't be relied upon as the sole means of protecting your application highlighting the imperativeness of adopting a comprehensive tool that manages it all from a single platform without any hiccups. 

This brings us to [Threatspy](https://bit.ly/3PV3C4M), which enables teams to proactively manage known, unknown, and third-party vulnerabilities inside their applications by automating the detection, prioritization, and remediation process. It uses a heuristic approach to identify vulnerabilities and prioritize them with a custom-built Reachability Framework, providing a Security Posture score based on contextual analysis, allowing your organization to take a more comprehensive and effective approach towards protecting your applications & APIs from the inside out. 

Experience Threatspy in action with our [free trial!](https://www.secureblink.com/threatspy#join-waitlist) 


Learn why relying solely on WAFs for application security is not enough. Discover the importance of Threatspy in managing known, unknown, & third-party vulnerabilities

Even With Web Applications Firewall Your Organization Is Not Safe?

Application security scanning is a process used to identify security vulnerabilities in applications. Heuristic scanning is a type of application security scanning that uses rules and algorithms to identify security vulnerabilities in an application. This is different from signature-based scanning, which uses predefined signatures to detect possible vulnerabilities. In this [blog](https://bit.ly/3Xfos1A), we will understand what heuristic application security scanning is and how it is different from traditional signature-based application security scanning.

## Heuristic Application Security Scanning

Heuristic application security scanning does not need a database to detect vulnerabilities. This type of application security scanning uses rules and algorithms to identify vulnerabilities that signature-based scanning methods may not detect. This is why it is able to identify zero-day vulnerabilities, the ones that have been disclosed but don't have any available patch or fix, classifying them under the category of unknown vulnerabilities. 

## Signature-Based Application Security Scanning

Signature-based scanning is a traditional application security scanning process primarily used to identify known vulnerabilities by searching for predefined signatures. These scanners rely on a database of signatures, and their checks depend only on non-reliable criteria, such as the version details and numbers of the target web application, file paths, and directory structures, etc. due to that, they are more prone to reporting false positives in detecting vulnerabilities. This means they are ineffective at defending against ever-evolving attacks, constantly being updated to evade detection.

## Conclusion

In conclusion, both heuristic application security scanning and signature-based application security scanning play a crucial role in the overall security of applications against modern threats. By using both methods to scan for vulnerabilities, organizations can ensure the overall security of applications.

So we have developed [Threatspy](https://bit.ly/3Woo7JN), a Heuristic AppSec Management Platform that enables an organization to proactively address the known, unknown & third-party vulnerabilities associated with their applications by adaptively automating the detection, prioritizations, and remediation process before threat actors exploit them.

By staying attuned to the latest application security trends, organizations can outperform without worrying about their web applications and keep them safe from ever-evolving threats.

Want to take the very first step towards integrating Heuristic Approach in your application security? Then [head over to request a demo](https://bit.ly/3PV3C4M) to witness Threatspy in action!



In this blog, we discuss the underlying concepts of the Heuristic Application Security Scanning and how it can be leveraged to address ever-evolving application security issues real quick!

Heuristic Application Security Scanning Explained

# Cybersecurity News Analysis: Lazarus Hacking Group Targets Spanish Aerospace Company

In a recent cybersecurity incident, the notorious North Korean hacking group known as 'Lazarus' demonstrated their evolving tactics by targeting employees of a Spanish aerospace company. The attack involved a cunning blend of social engineering and the deployment of a previously undocumented backdoor named 'LightlessCan.' Let's dissect the technical details of this operation.

## Operation Dreamjob: A Deceptive Approach

Lazarus initiated this attack with a deceptive LinkedIn message from a fake recruiter, masquerading as 'Steve Dawson' from Meta (Facebook). The target was lured into engaging with the attackers by feigning interest in a job opportunity. As the conversation progressed, the victim was asked to prove their proficiency in C++ programming, a clever ruse to introduce malicious payloads.

## Payload Delivery and Execution

To deliver the malicious payloads, Lazarus employed ISO files containing executable quizzes. When executed, these files silently dropped an additional payload onto the victim's machine using DLL side-loading through 'mscoree.dll,' a legitimate program ('PresentationHost.exe'). This additional payload was the NickelLoader malware loader, responsible for deploying two backdoors, including 'LightlessCan.'

## miniBlindingCan: A Versatile Backdoor

miniBlindingCan, a variant of BlindingCan with reduced functionality, was one of the backdoors deployed. This backdoor supports a range of commands, allowing the attacker to gather system information, update communication intervals with the command and control (C2) server, download and decrypt files, and execute shellcode. Its versatility makes it a potent tool for cyber espionage.

## LightlessCan: The Advanced Backdoor

ESET's analysis revealed LightlessCan as the star of this attack. It's a successor to BlindingCan, boasting a more sophisticated code structure, different indexing, and enhanced functionality. In version 1.0, it supports a staggering 43 commands, with an additional 25 commands lurking in the code, yet to be implemented. What sets LightlessCan apart is its ability to mimic native Windows commands, such as 'ping' and 'ipconfig,' while remaining invisible to real-time monitoring tools.

## Evolving Defense Measures

One intriguing defense measure implemented by Lazarus is the encryption of one LightlessCan payload with a key dependent on the target's environment. This tactic thwarts attempts by security researchers or analysts to access the victim's computer, emphasizing Lazarus' commitment to secrecy and espionage.

## Espionage Over Financial Gain

This attack underscores that Lazarus' motives extend beyond mere financial gain, such as cryptocurrency theft. Their 'Operation Dreamjob' campaign reveals a strategic shift towards espionage, targeting sensitive information and intellectual property.

## Implications for Organizations

For organizations in the crosshairs of threat groups like Lazarus, this development is concerning. The introduction of LightlessCan showcases the group's growing sophistication and adaptability. Enterprises must remain vigilant, continuously updating their cybersecurity defenses to counter evolving threats.

## Conclusion

The Lazarus hacking group's recent attack on a Spanish aerospace company serves as a stark reminder of the ever-changing landscape of cybersecurity threats. Their blend of social engineering and the deployment of advanced backdoors like LightlessCan demonstrates the need for organizations to stay proactive and vigilant in defending against cyber adversaries.

In this dynamic environment, understanding the nuances of such attacks is paramount to crafting effective defense strategies. As cybersecurity professionals, staying informed about the latest tactics and tools employed by threat actors is essential to safeguarding our digital assets and sensitive information.

For the Spanish aerospace company, this incident serves as a wake-up call, highlighting the need for robust cybersecurity measures to protect against persistent and determined adversaries like Lazarus. The future of cybersecurity lies in continuous adaptation and proactive defense, and organizations must rise to the challenge to secure their digital infrastructure.

Lazarus hacking group's cyber espionage: Learn how LightlessCan infiltrated a Spanish aerospace company 

Lazarus Targets Spanish Aerospace with LightlessCan

CVE-2023-42793, a critical vulnerability resulting in ripples, specifically targets TeamCity, JetBrains' popular CI/CD server. Its implications are significant, granting unauthenticated attackers the ability to execute arbitrary code on TeamCity servers, thereby facilitating remote code execution (RCE). 
Here, in this [Threatfeed](https://www.secureblink.com/cyber-security-news) we delve into the details of CVE-2023-42793, assess its consequences, and discuss the measures required to safeguard your systems.

## Key Information

### Sonar's Discovery

The discovery of CVE-2023-42793 can be credited to Sonar's Vulnerability Research Team. They discovered a vulnerability that enables unauthenticated attackers to gain remote code execution privileges on TeamCity servers. This vulnerability poses an imminent threat, as it allows attackers to steal source code, access sensitive service secrets and private keys, manipulate the build process, and compromise the integrity of software releases. This vulnerability is not dependent on user interaction, making it an enticing target for malicious actors. Meanwhile, Greynoise is currently tracking many IP addresses from which CVE-2023-42793 exploit attempts are being made.

### Vulnerability Details

The root cause of this vulnerability lies in an authentication bypass. Specifically, TeamCity versions 2023.05.3 and earlier of the on-premises variant are susceptible. Attackers can exploit this flaw without requiring a valid account on the target instance, rendering it easily exploitable. As a result, we are compelled to emphasize the urgency of prompt action to mitigate this risk.

## Impact

### The Gravity of RCE

[CVE-2023-42793](https://nvd.nist.gov/vuln/detail/CVE-2023-42793)  strikes at the heart of cybersecurity concerns. With RCE capabilities, attackers can not only pilfer source code but also gain access to highly confidential service secrets and private keys. Moreover, the ability to interfere with the build process by injecting malicious code jeopardizes the integrity of software releases. The most concerning aspect is that this vulnerability requires no user interaction, making it an attractive option for cybercriminals.

### Urgency of Action

To underscore the urgency of the situation, it's crucial to note that this vulnerability does not necessitate a valid account on the targeted instance. Its trivial exploitability raises concerns about its potential exploitation in the wild. Shodan currently identifies over 3,000 on-premises TeamCity servers accessible from the Internet. 

## Indicators of Compromise

### Unveiling Malicious Activity

One crucial indicator of compromise is the existence of an authentication token named RPC2. This token's presence strongly suggests unauthorized and potentially malicious user activity on the server. It's essential to recognize that an attacker may attempt to cover their tracks by deleting or renaming this token post-exploitation.

## Technical Details

### Request Interceptors

TeamCity employs request interceptors to execute specific actions for every HTTP request. A critical role of these interceptors is the authorization mechanism. These interceptors are part of the global request handling process and are often overlooked during security assessments. In the context of this vulnerability, a wildcard expression, "**/RPC2," was unintentionally included, disabling the authorization check for requests ending with "/RPC2."

### Request Path Parameters

TeamCity offers a REST API for external application integration. While the documentation outlines endpoints, some hidden endpoints, like "/app/rest/users/<userLocator>/tokens/{name}," can be exploited. This specific endpoint allows an unauthenticated attacker to create a new authentication token with an arbitrary name, including "RPC2."

## Patch

### The Path to Security

JetBrains swiftly addressed this vulnerability with the release of TeamCity version 2023.05.4. The patch removes the wildcard expression for the "/RPC2" pre-handling exception, ensuring that pre-handling is only disabled when "/RPC2" is accessed directly without additional prefixes in the requested path. This measure effectively prevents authentication bypass for other endpoints.

## Timeline

### Collaborative Efforts

JetBrains and the Sonar Vulnerability Research Team maintained open communication throughout the discovery and remediation process. JetBrains' rapid response and efficient collaboration ensured a swift resolution to this critical security issue.

- **September 6, 2023**: The vulnerability is reported to JetBrains.
- **September 6, 2023**: JetBrains acknowledges receipt of the report.
- **September 7, 2023**: JetBrains fixes the issue in the 2023.05 branch.
- **September 12, 2023**: JetBrains prepares a plugin as a workaround.
- **September 14, 2023**: JetBrains confirms the issue as a major security concern.
- **September 18, 2023**: TeamCity version 2023.05.4 is released, addressing the vulnerability.
- **September 18, 2023**: JetBrains notifies customers to update promptly.
- **September 19, 2023**: CVE-2023-42793 is published.
- **September 21, 2023**: Coordinated release of blog posts from JetBrains and Sonar.
- **September 27, 2023**: Full disclosure follows the public release of an exploit.

## Learnings

### The Importance of Authorization

This incident underscores the significance of authorization checks. While endpoints often receive individual checks, global request interceptors are frequently overlooked. These interceptors, part of the global attack surface, must not be neglected in security assessments.

### Taming Wildcards

Wildcard expressions, while versatile, can inadvertently expose vulnerabilities. A more restrictive approach is advisable to prevent unintended vulnerabilities like the inclusion of "/**/RPC2."



Discover and address the critical JetBrains TeamCity vulnerability (CVE-2023-42793). Stay secure in the world of cybersecurity.

Catch the Critical JetBrains TeamCity Vulnerability (CVE-2023-42793)

In July 2023, Our scanners detected a series of atypical commits across hundreds of GitHub repositories, seemingly originating from Dependabot but concealing malevolent intentions. This [Threatfeed](https://www.secureblink.com/cyber-security-works) delves deep into the technical intricacies of this cyberattack, highlighting the tactics employed by threat actors and the implications for developers and security professionals.

## **Deceptive Commits**

Between July 8-11, threat actors embarked on a sophisticated campaign, compromising both public and private GitHub repositories, focusing predominantly on Indonesian user accounts. Their modus operandi involved crafting counterfeit commit messages meticulously designed to mimic genuine contributions from Dependabot. This ruse aimed to deceive developers into dismissing the malicious activity.

The attackers ingeniously camouflaged their actions by impersonating the user account "dependabot[bot]." This manipulation added a layer of authenticity to their deceitful commits, making them appear benign at first glance.

## **Malicious Code Unveiled**

In our extensive analysis of the affected repositories, we uncovered two distinct patterns of code changes suggestive of automated scripting. The first insidious alteration introduced a new GitHub Action file named "hook.yml." This file triggered every code push event, surreptitiously exfiltrating GitHub secrets and variables to a malicious endpoint: `hxxps://send[.]wagateway.pro/webhook`.

The second malicious modification was equally cunning. The attackers targeted JavaScript files (`.js`) within the projects, appending obfuscated lines of code at the end. This code snippet created a new script tag, executed in web browsers, and fetched an additional script from `hxxps://send[.]wagateway.pro/client.js?cache=ignore`. Its purpose was clear: intercepting user-submitted passwords from web forms and funneling them to the same exfiltration endpoint.

## ** Attack Chain**

Understanding the attack's progression is crucial to fortifying defenses against such incursions. The assault unfurled in three distinct phases:

**Step 1 – Workspace Initialization:** Victims inadvertently played a pivotal role by initializing their development environments with personal access tokens (PATs) or alternative identification methods. These tokens, stored locally on their machines, became ripe targets for extraction. Notably, PATs do not mandate two-factor authentication (2FA), rendering them vulnerable to exploitation.

**Step 2 – Stealing the Developer's Credentials:** How attackers acquired developers' credentials remains speculative, but a prevalent method suggests using malicious packages. These insidious packages covertly exfiltrated PATs to the attackers' command and control (C2) server, providing unhindered access to compromised accounts.

**Step 3 – Poisoning the Victim's Code Projects:** Armed with stolen PATs, the attackers authenticated themselves on GitHub and executed the malevolent code changes detailed earlier. The scale of this assault suggested automation, highlighting the need for robust threat detection and prevention measures.

## **Implications and Lessons**

This incident serves as a stark reminder of the evolving sophistication of supply chain attacks, particularly when attackers exploit trusted entities like Dependabot. Developers and organizations must exercise vigilance in code acquisition, even from reputable sources like GitHub. It underscores the need for enhanced security measures.

To mitigate the risk of compromised tokens, GitHub introduces a groundbreaking solution: fine-grained personal access tokens (PATs) in public beta. These tokens afford developers granular control over permissions, reducing the potential for damage if a token is breached.

However, it's important to note that access log activity for GitHub's personal access tokens is exclusively visible to enterprise accounts, leaving non-enterprise users in the dark about potential compromises.

## **Fine-Grained Personal Access Tokens: A Game Changer**

GitHub recognizes the paramount importance of safeguarding credentials and introduces fine-grained PATs to bolster security. Here's how they differ from the traditional personal access tokens (classic):

- **Granular Permissions:** Fine-grained PATs offer over 50 granular permissions that control access to GitHub's APIs, granting read or read-and-write access on a per-permission basis. For instance, a PAT can be configured to read issues within a repository exclusively.

- **Repository Targeting:** Unlike classic PATs, fine-grained tokens do not possess universal access. They are tailored to specific repositories or organizations, minimizing the scope of potential breaches.

- **Expiration:** Fine-grained PATs come with expiration dates, ensuring that access is time-limited and reducing long-term risk.

## **Creating Fine-Grained Personal Access Tokens**

Developers can create fine-grained PATs through the Developer Settings section in their account settings. This feature simplifies building integrations and testing scripts, offering a level of control and security previously unavailable.

## **Approving and Auditing Tokens**

Organization owners gain newfound control over fine-grained PATs. They can opt to approve or reject each token targeting their organization or repositories. This feature enhances visibility and accountability, empowering organizations to safeguard their resources effectively.

## **Choosing the Right Access Method**

While fine-grained PATs represent a significant leap in access control, there are scenarios where classic PATs remain necessary, such as access beyond one's organization or integration with enterprise account APIs. GitHub Actions and GitHub Apps are recommended for long-term automation needs, combining highly targeted permissions with administrator controls.

## **What's on the Horizon**

GitHub's commitment to security extends beyond this release. Future enhancements include support for GraphQL with fine-grained PATs, expanded API support for fine-grained permissions, and additional features for administrators to set and enforce PAT policies at scale.

## **Get Started with Fine-Grained PATs**

Fine-grained personal access tokens are now available to all GitHub users, organizations, and enterprises on GitHub.com. Users are encouraged to provide feedback as GitHub continually refines this groundbreaking security feature.


Discover the intricate GitHub attack: Threat actors impersonating Dependabot, stealing secrets & passwords.

Our Product

Resource Library

Subscribe to Our Weekly Threat Digest

Contact Us

PRODUCT

threatspy

threatspy

SOLUTIONS

By Industry

Healthcare

Healthcare

Education

Education

IT & Telecom

IT & Telecom

By Role

Government

Government

CISO/CTO

CISO/CTO

DevSecOps

DevSecOps

RESOURCES

Threat Feed

Threat Feed

Threat Research

Threat Research

White Paper

White Paper

SB Blogs

SB Blogs

COMPANY

Our Story

Our Story

Our Team

Our Team

Career

Career

Press And Media

Press And Media

Contact Us

Contact Us

Quantum Cryptography

Stay Cyber-Updated

Ready to get started?

Product

Solutions

Resources

Company

Find Us Online

contact@secureblink.com

@ Copyright 2023 Secure Blink. All rights reserved.

4th Floor, Plot No- 7-10 Sector 126, Noida, UP -201303