[et_pb_section fb_built=”1″ _builder_version=”4.27.4″ _module_preset=”default” da_disable_devices=”off|off|off” global_colors_info=”{}” theme_builder_area=”post_content” da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on”][et_pb_row _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_text _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
In my 2024 article, Cyber Security 2024: Key Trends Beyond the Hype<\/a>,<\/em> I aimed to stay rational and avoid hype\u2014especially around AI\u2014and pointed out that most real-world attacks still involved unpatched systems, weak credentials, and social engineering. Over the past year, that has largely remained true.<\/p>\n Now, as we move into 2025, I\u2019m revisiting those same areas with updated examples. Supply chain attacks remain a key concern\u2014especially for identity providers and open-source libraries. Token and cloud API abuse hasn\u2019t slowed down, and attackers keep finding ways to bypass or disable EDR solutions, often hiding behind legitimate software. Meanwhile, basic security missteps still leave many organizations open to recurring threats.<\/p>\n Although I was skeptical about AI-based attacks last year, we do see attackers using AI to automate tasks like scripting or generating phishing emails. There\u2019s still no proof of a fully AI-driven breach from start to finish\u2014it\u2019s more of an efficiency boost than a total game-changer. My goal here is to remain as sober and factual as possible, highlighting what\u2019s genuinely evolving in these trends and where we should pay close attention going into 2025.<\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2025\/02\/cyb3rops_illustration_supply_chain_attacks_cyber_security_hidde_30e27397-205e-48b8-8759-c42565d96b41.png” title_text=”cyb3rops_illustration_supply_chain_attacks_cyber_security_hidde_30e27397-205e-48b8-8759-c42565d96b41″ _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_image][et_pb_text _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n Supply chain attacks continue to pose a serious threat to organizations of all sizes, even those with sophisticated security measures. While these attacks often target software providers or trusted third-party vendors, recent events show that Identity and Access Management (IAM) service providers<\/strong> themselves can become single points of failure. A single breach at a major identity platform can compromise thousands of companies at once, exposing credentials, tokens, and other valuable data.<\/p>\n Okta\u2019s late-2023 breach is a prime example of how quickly an incident can escalate. Initially, the company reported that only 1% of customers were affected. Weeks later, it revealed that its entire customer base was impacted<\/a>. To an outside observer, it seems Okta was overwhelmed by the attack\u2019s sophistication and remained cautious in what it disclosed. As more details emerged, the root cause turned out to be surprisingly mundane – an Okta employee logged into a personal Google account on a corporate laptop, opening the door for a massive data exposure. For organizations depending on IAM services, it\u2019s a stark reminder that even top-tier providers have blind spots, and if they\u2019re compromised, the implications can be extremely severe.<\/p>\n Shortly after the Okta breach, another incident at Microsoft highlighted just how powerful stolen signing keys can be. In an attack attributed to a Chinese threat actor (Storm-0558), a private encryption key for Microsoft\u2019s identity services was taken.<\/p>\n While Microsoft initially stated the attack impacted only Outlook.com and Exchange Online, independent research suggests<\/a> the key could have theoretically been used to forge tokens for services like SharePoint, OneDrive, Teams, or even third-party apps using \u201cLogin with Microsoft.\u201d Because identity provider keys can grant access to a huge number of services, this breach may be more significant than Microsoft\u2019s public statements suggest.<\/p>\n In reality, organizations have little direct control over how a major cloud provider safeguards its signing keys, so transparency from the provider after any compromise is crucial. Without clear information about the nature and scope of a breach, customers can\u2019t accurately assess their exposure or respond effectively.<\/p>\n Open source ecosystems also continue to be a prime target. Malicious actors tamper with NPM packages<\/a>, PyPi modules<\/a>, GitHub repositories, or other code libraries, embedding backdoors in widely used dependencies. A notable example involves XZ Utils, a Linux compression library, which was briefly taken over by a suspicious contributor<\/a> who shipped malicious updates aimed at undermining SSH authentication. Luckily, the rogue versions (5.6.0 and 5.6.1) weren\u2019t widely adopted, limiting real-world impact. However, if they had been broadly deployed\u2014especially in embedded or firmware environments\u2014the fallout could have been much worse. As the reliance on open source only grows, so does the importance of continuous monitoring, code signing, and stricter vendor risk assessment.<\/p>\n These incidents show how quickly a single supplier or identity service compromise can affect thousands of organizations. Sometimes, more details only emerge after weeks, revealing a bigger problem than originally reported. When widely used vendors or open-source libraries are attacked, the damage often extends far beyond one victim. Because so many companies rely on the same tools and providers, supply chain attacks remain one of the most serious threats in cybersecurity today.<\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2025\/02\/cyb3rops_illustration_token_and_cloud_api_abuse_attackers_attac_7c1cf3c3-0ad4-4709-8663-01ea080fec17.png” title_text=”cyb3rops_illustration_token_and_cloud_api_abuse_attackers_attac_7c1cf3c3-0ad4-4709-8663-01ea080fec17″ _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_image][et_pb_text _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n Session tokens have become a critical part of modern authentication flows. They let users stay logged in to web apps, cloud consoles, and enterprise services without repeatedly entering credentials. While this feels convenient, it also introduces new ways for attackers to slip through defenses\u2014even in setups that use multi-factor authentication (MFA). If a token is stolen or forged, someone with malicious intent can bypass many security checks and move laterally with little friction.<\/p>\n Below are some practical points worth highlighting:<\/p>\n The Microsoft Storm-0558 incident showed that losing control of a signing key can be more damaging than a typical credential leak. If attackers can forge their own tokens, they\u2019re suddenly able to impersonate users in multiple cloud services. For any organization relying on a major cloud or identity provider, it\u2019s important to understand how those critical signing keys are protected\u2014because if they\u2019re compromised, you\u2019ll want to detect and respond immediately.<\/span><\/p>\n Many organizations rely on services like Slack, Teams, or analytics platforms, which connect via tokens or API keys. These secrets often end up in code repositories, config files, or logs. Attackers systematically comb through public GitHub repos to find them. Integrating scanning tools (e.g., GitGuardian or truffleHog) into your CI\/CD pipeline can help detect these tokens before they become a liability.<\/p>\n Token theft isn\u2019t limited to standard web sessions. Many Office 365\u2013integrated apps, mobile apps, backend microservices, or serverless functions rely on tokens that can offer broader network access than a local user account. Although LSASS (Local Security Authority Subsystem Service) is also a user-mode process, it often has stronger protections (for example, Credential Guard or Protected Process Light) that make direct memory access more difficult. In contrast, Office 365\u2013integrated apps and other cloud-connected processes may not have those same security measures, which can make token extraction easier. Worse yet, these tokens can have privileges that extend into various cloud services, potentially causing greater damage than a compromised local account.<\/p>\n At a minimum, turning on logging or anomaly detection for internal API calls can help reveal suspicious token usage\u2014meaning you\u2019d track typical patterns of API calls (who calls what, how often, at what times, etc.) and flag any outliers. For instance, if a token with standard user permissions starts performing admin-like actions on backend systems, or if an unusual volume of calls occurs outside normal work hours, that could trigger an alert for further investigation.<\/p>\n In a zero-trust setup, every request is authenticated\u2014usually via a token. When those tokens become the primary way of granting access, attackers will prioritize stealing or forging them. Requiring continuous validation, checking for abnormal IP addresses or login times, and limiting privileges to the bare essentials can mitigate some of these risks.<\/p>\n Even robust technical defenses can fail if employees share their tokens or accept rogue MFA prompts. Attackers keep finding new ways to trick users into handing over access, including real-time phishing tactics that intercept session cookies. Regularly updating security training\u2014and emphasizing the changing face of phishing\u2014is crucial.<\/p>\n By keeping an eye on token usage, scanning for accidental leaks, and teaching employees to question unusual login prompts, organizations can make token abuse more difficult for attackers. It\u2019s not an all-encompassing fix, but it helps curb the most common ways threat actors leverage stolen or forged tokens.<\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2025\/02\/cyb3rops_illustration_attackers_hiding_evading_security_feature_71225e27-965e-4d17-a782-53e77925cd48.png” title_text=”cyb3rops_illustration_attackers_hiding_evading_security_feature_71225e27-965e-4d17-a782-53e77925cd48″ _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_image][et_pb_text _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n As Endpoint Detection and Response (EDR) solutions become more common on workstations and servers, attackers have adapted. Instead of dropping obvious malware onto well-monitored endpoints, they\u2019ll often store malicious tools on older or unmonitored systems (e.g., network appliances, print servers, exotic systems, outdated embedded devices) and later pivot into the EDR-guarded zone. However, not all attackers stop there\u2014some actively disable EDR agents on highly monitored endpoints to move about undetected.<\/p>\n Below are some recurring tactics we\u2019re observing:<\/p>\n Attackers often hijack compromised user or admin accounts to access files, internal apps, or cloud services. Because these actions seem normal on the surface, they frequently slip past rule-based detections. Baselines of typical user behavior or alerting on suspicious account usage can help spot these scenarios.<\/p>\n Some adversaries go beyond evasion and deliberately disable the EDR\u2019s visibility on a targeted system. They may load a known vulnerable driver<\/a>, gaining kernel privileges to unhook or kill the security agent altogether. Once the agent is neutralized, attackers can deploy tools or tamper with the OS without detection.\u00a0<\/p>\n Rather than dropping custom executables (which EDR might flag), attackers use existing OS utilities (e.g., PowerShell, WMI) to escalate privileges, move laterally, or exfiltrate data. These \u201cliving off the land<\/a>\u201d techniques leave fewer artifacts and require closer scrutiny of standard processes to detect anomalies.<\/p>\n Attackers often target devices that aren\u2019t covered by modern EDR solutions\u2014like older servers, virtual appliances, or networking appliances from vendors such as Fortinet, Ivanti, and Cisco. These devices not only suffer from recurring critical vulnerabilities but also offer limited logging and a restricted shell, making them hard to investigate thoroughly. By focusing on these \u201cblind spots,\u201d attackers can store malicious tools, launch deeper intrusions, and exfiltrate data without triggering the usual EDR alarms. If these systems aren\u2019t regularly patched and closely watched, they remain a constant weak point in the network.<\/p>\n Gaining higher privileges often starts with subtle phishing or manipulation tactics. By impersonating help desk personnel, building rapport with employees, or sprinkling in accurate technical details, attackers trick people into revealing credentials. Once they have elevated access, they keep their actions low-key to avoid raising alarms.<\/p>\n Attackers frequently scope out which endpoints are guarded by EDR or similar monitoring tools. They might read internal documentation or test quiet scans to see what triggers alerts. This reconnaissance phase is marked by caution\u2014any loud move could blow their cover.<\/p>\n To avoid leaving clear IOCs, attackers combine Windows Registry modifications, scheduled tasks, or WMI event subscriptions with stolen tokens from valid sessions. A valid token may allow them to continuously re-authenticate without dropping any new binaries. In a large environment, this can linger for weeks if there are no specific checks for reused or anomalous tokens. Organizations need continuous, behavior-based monitoring to detect unexpected processes, modified configurations, and suspicious token usage.<\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2025\/02\/cyb3rops_illustration_abuse_of_legitimate_software_cyber_securi_99a7743c-0755-4a76-97b8-0bcc0f0d4238.png” title_text=”cyb3rops_illustration_abuse_of_legitimate_software_cyber_securi_99a7743c-0755-4a76-97b8-0bcc0f0d4238″ _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_image][et_pb_text _builder_version=”4.27.4″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n Attackers are increasingly swapping out traditional malware for legitimate software to evade detection. Whereas classic remote access trojans (RATs) often trigger antivirus and EDR alerts, legitimate tools like ConnectWise Control, Anydesk, NetSupport, TeamViewer, Atera, LogMeIn, or Splashtop usually fly under the radar because they\u2019re widely used by IT teams. The same goes for built-in utilities and common third-party applications that aren\u2019t inherently malicious. When adversaries exploit these, it\u2019s harder for security products to flag the activity as unusual – especially in large organizations.<\/p>\n1. Supply Chain Attacks<\/h1>\n
Okta: A Breach That Shook Customer Trust<\/h3>\n
Microsoft: The Underrated Damage of a Compromised Key<\/h3>\n
Open Source Supply Chain Risks<\/h3>\n
2. Token and Cloud API Abuse<\/h1>\n
Token Forging (Lessons from High-Profile Breaches)<\/h3>\n
Third-Party Integrations and Code Repositories<\/h3>\n
Beyond Web Browsers<\/h3>\n
Zero Trust Increases Token Value<\/h3>\n
User Education & MFA<\/h3>\n
3. Evading EDR in Heavily Monitored Environments<\/h1>\n
Relying on Legitimate Accounts<\/h3>\n
Direct Attacks on EDR Agents<\/h3>\n
Minimizing Additional Tools<\/h3>\n
Staging Tools on Under-Protected Systems<\/h3>\n
Layered Social Engineering<\/h3>\n
Reconnaissance for Weak Spots<\/h3>\n
Stealthy Persistence<\/h3>\n
4. Abuse of Legitimate Software<\/h1>\n