In the past eighteen months, generative AI (gen AI) has gone from being the source of jaw-dropping demos to a top strategic priority in nearly every industry. A majority of CEOs report feeling under pressure to invest in gen AI. Product teams are now scrambling to build gen AI into their solutions and services. The EU and US are beginning to put new regulatory frameworks in place to manage AI risks.

Amid all this commotion, hackers and other cybercriminals are hardly standing idly by. They’re looking into using gen AI for doing everything from improving the grammar of phishing messages to exploring ways of faking video and audio to trick or extort money from victims.  They’re also looking for ways to attack the very AI models that businesses are busy investing in.

If you’re a CISO, or any security professional, the time to begin evaluating gen AI is now. In a recent white paper, IBM’s chief technology officer for security software, Sridhar Muppidi, outlined five key recommendations for evaluating gen AI’s use in defending against cyberattacks. Here’s a quick look at a few of those recommendations.

Use gen AI in threat hunting and response

As attackers increase their use of gen AI, Muppidi notes that their attacks will become pervasive, evasive, and adaptive. Security teams will need to adapt by using this technology for their own advantage. AI and machine learning can already make security teams more efficient.

For example, AI-powered security information and event management (SIEM) solutions can help analysts prioritize risks detected. They help minimize analysts’ focus on false positives and allow them to instead concentrate on the critical threats at hand. Gen AI-enabled solutions will do much more, including accelerating threat hunting through natural language searches, generating threat detection and response playbooks, and empowering analysts with natural language chatbots. All of these AI-driven solutions can alleviate human bottlenecks and make security far more efficient—responding faster and doing more with less.

Evaluate gen AI based on the time it saves defenders

CISOs and their teams can expect to be bombarded with a lot of product offers from security providers in the next year or two, all touting the advantages of their particular AI-powered technology. How do you sort through all these product descriptions and demos to zero in on what’s going to make the biggest impact for your Security Operations Center (SOC)?

We recommend focusing on time savings. Time is critical in every SOC. SOCs are famously understaffed. Analysts feel overworked and often frustrated. Anything that saves analysts time—whether it’s time spent manually investigating incidents, identifying false positives or writing incident reports—is worth moving to the top of your priority list.

Challenge gen AI providers on trust

When evaluating gen AI products, one aspect that is often not given enough attention is trust. Do you trust the provider selling you this cybersecurity solution? Does the provider have a framework for securing its AI data, model, and usage? Among the questions you should ask the provider:

• What data was your model trained on?
• How representative is that data of the data my SOC works with every day?
• Can I evaluate it in my own environment to see how it performs before I adopt it?

As impressive as gen AI products seem today, and as presence permeates nearly every topic of conversation, this technology is still in its infancy—especially in the field of cybersecurity. New models and techniques are being announced every month. For that reason, it’s crucial you ask the provider about their own product goals. You should ask, point blank:

• How much are you investing in the development of gen AI in your products?
• Do you have a dedicated team evaluating and developing AI for cybersecurity?
• Who else is using your TDIR solution?

As your organization adopts gen AI in its supply chain, customer service, marketing, HR, product development, and other operations, your attack surface will grow. So, you’ll need to use these same gen AI capabilities to secure your AI data, models, and usage.

The bottom line? When attackers are using gen AI, your best strategy is to fight fire with fire.

For a more in-depth look at Muppidi’s recommendations for adopting gen AI for cyber defense, download “5 criteria for evaluating generative AI in threat management.”

The post 3 recommendations for adopting generative AI for cyber defense appeared first on Security Intelligence.

This year marked the 19th season of the National Collegiate Cyber Defense Competition (NCCDC). For those unfamiliar, CCDC is a competition that puts student teams in charge of managing IT for a fictitious company as the network is undergoing a fundamental transformation. This year the challenge involved a common scenario: a merger. Ten finalist teams were tasked with managing IT infrastructure during this migrational period and, as an added bonus, the networks were simultaneously attacked by a group of red teams pretending to be bad actors.

Every year the students’ mission is to mitigate the risk of the red team attacks and ensure their business successfully transforms, all while continuing operations. This competition is unique as it lets the students get a feel for the chaos and stress that ensues when an organization is compromised, undergoing major transitions all while continuing to provide value to customers and report progress to their leadership team.

I’m lucky enough to have founded the National CCDC red team with my good friend Dave Cowen during the competition’s second year. Having participated as a core red team member for almost 20 years I’ve worked with many students and seen massive shifts in the technology, both offensive and defensive. Interestingly enough, while technology has changed dramatically, and exploits and vulnerabilities come and go, many of the core lessons remain the same. These are some key lessons that underpin the successful teams year after year.

Communication is key

The reality is, compromise happens, things break, mistakes are made, systems do not always operate as intended. The best way to navigate through these problems is clear, concise communication. Ensure your team knows the next steps to take, who is responsible for taking those actions, and that your leadership chain knows what to expect next. Having incident and crisis response plans baked and tested in advance can help in this effort.

Understand what is exposed

Put simply, you can’t defend what you don’t know about. On the red team, we are always looking for systems that are not supposed to be exposed, administration interfaces that should be locked down, that one user account with the default or an easily guessable password. The good news is, you can do the same thing. With the ever-changing and growing complexity of today’s networks, it is critical to look at your network the way the attackers do. Build a list of exposed infrastructure, keep that list up to date and audit those systems regularly to ensure they are working as intended.

Plan for failure

Be ready for something to break. Being able to detect, adapt and deal with those failures is a major differentiator. Review your plans with an eye for corner cases or assumptions to prepare for what could go wrong.

For instance, you have a punch-down list of steps to harden your Linux system. Great. Will you still have access to that list if your internet connection goes down? What happens if the Linux system has an apk based package manager instead of yum? Do you know how to fix the package manager if it is broken? While you can’t plan for every possibility, make sure your plan is robust enough to enable you to jump over hurdles as they are put in front of you.

Overall, NCCDC is a unique and respected competition format, enabling student teams to experience the chaos of realistic compromises while managing the pressures of running day-to-day business operations. All of this prepares them for what to expect as they graduate and move on to careers in cybersecurity.

Congratulations to this year’s winning team UCF and to the nearly 1,800 students competing in the qualifying and regional competitions which represented 198 colleges and universities. We’re excited to welcome the next generation of cybersecurity professionals and look forward to continuing to learn from you in the coming years.

The post What we can learn from the best collegiate cyber defenders appeared first on Security Intelligence.

When the Cerberus code was leaked in late 2020, IBM Trusteer researchers projected that a new Cerberus mutation was just a matter of time. Multiple actors used the leaked Cerberus code but without significant changes to the malware. However, the MalwareHunterTeam discovered a new variant of Cerberus — known as Ermac (also known as Hook) — in late September of 2022.

To better understand the new version of Cerberus, we can attempt to shed light on the behind-the-scenes operations of the actor maintaining Ermac. While a new version of the malware has been released, we will focus on the original version.

Gaining insight into the backstage operations of the malware is not simply a case of reverse engineering malware samples that were released into the wild. Once that reverse engineering was complete, however, unique and interesting aspects of the inner workings of the malware were revealed.

The Cerberus connection

As a Cerberus descendent, Ermac shares the same source code and fraud capabilities, including stealing a user’s bank credentials and second-factor authentication (2FA) messages that are delivered to the user via SMS or notification.

Here is an example of the shared preferences file created by Cerberus and Ermac. We can easily see that Ermac malware has the same elements as Cerberus, and there are also new entries representing new capabilities in Ermac.

Figure 1: Cerberus shared preference.

Figure 2: Ermac shared preference.

How Ermac is unique

The capabilities of Ermac were already discussed in depth. However, it is worth mentioning that Ermac malware contains a different packer than Cerberus. The Ermac packer is open source and can be found online.

This is yet more evidence that Ermac could be a new operator and that the threat actor is actively maintaining the leaked Cerberus code and constantly evolving Ermac’s code base.

Figure 3: This is the first page presented once connecting to the Ermac command and control server.

A deep dive into the Ermac command and control server (C&C) user interface (UI) reveals the differences between Cerberus and Ermac and provides a unique glimpse into the Ermac functionality, monetization scheme and features under development. IBM Trusteer researchers have discovered two new beta capabilities in the Ermac malware: ransomware and a virtual private network (VPN) connection.

Wide-ranging capabilities

These images taken from the C&C demonstrate Ermac’s different capabilities.

Figure 4: ERMAC C&C bot management page.

The data that the C&C manages is organized in a structured table with multiple columns.

The first column shows the ID that is generated for each bot. We can also see the different actions and device modes: for example, if the user is currently watching the screen, whether different models are loaded and so on.

The next column stores information about the victim’s device and operating system version.

Column three stores different tags regarding the bot’s status; for example, “favorite,” “blacklist” and “trash.”

The next column is called GEO and stores information about the country and device location of the bot.

Next, there is information regarding the malware installation date and time and the last time the bot was successfully connected to the C&C.

The “injection” column contains the different applications on which the malware can perform overlay attacks.

The “action” column lists the different actions the C&C operator can command the bot to perform on the victim’s device. These actions include open inject, forward calls, clear application data and more (see Figures 8-13).

The logs column contains the raw data exfiltrated from the victim’s device, including the contact list, 2FA, list of installed applications, application notifications, keystrokes log and more.

Figure 5: Ermac capabilities.

One of the most interesting screens is the “Auto command,” which is still in beta mode. On the screen, we can see capabilities like sending SMS, opening inject (overlay screen), grabbing the contacts list and the killbot, which is an Ermac self-destruct switch. We can also see unique commands such as “Clear app data” and “Get Accounts.”

Visibility to the C&C exposes new commands still under development: “beta Ransomware” and “beta Set bot VPN.”

Figure 6: Ermac events.

Here, we can see Ermac events. All activities of the bots can be seen in this figure.

Figure 7: Devices list screen (in development).

Another capability that is still under development is the ability to upload or download files from the bot itself. In production, this allows the bot operator to have more control over the victim’s machine and opens the door to new attack tactics.

Figure 8: Bot commands.

The malware operator can choose any of the infected devices, initiate a call from that device and even pick which SIM to use for the call. The “lock screen” checkbox can be turned on or off. While on, Ermac shows the victim a fake screen during the entire duration of the call, thus hiding the ongoing call from the victim while preventing any other use of the device.

Figure 9: Calling command.

Figure 10: SMS command.

The clear cache command can be used to clear all the data of an app. When the malware clears the data, it also clears the cache.

Figure 11: Clear Cache command.

The fraudster can lure victims to open their bank application by sending a push notification with a text from the “bank.”

Figure 12: Send Push command.

The fraudsters can steal the seed phrase from the user’s device used for the crypto wallet and later use it to log in to the victim’s account without having to prove their identity.

Figure 13: Get Seed Phrase command.

In the C&C user management panel, we can see all the users and roles that exist in the system. This demonstrates that Ermac is built to be operated in a fraud-as-a-service (FaaS) model. The Ermac operator, “root,” can create a new user and password from this screen that can later be used by a fraudster client to manage their bots by logging into the C&C using this new user.

Figure 14: C&C user management panel.

Figure 15: C&C user management panel “Create New User” screen.

When the admin creates a new user, they can pick a token (password) for the user to log in with and can assign a role to the user.

Figure 16: C&C user management panel “Create New User” screen defines a role.

Figure 17: Permissions screen.

Each role has its own permission profile that is managed on the permissions screen.

Fraud as a service continues to evolve

Although Ermac’s risk is very similar to Cerberus, Ermac has some new capabilities that have not been seen before. This is one of the more sophisticated Cerberus mutants because of the new capabilities that it offers, such as “ransomware” and “set bot VPN.”

We expect to see more mutations with new capabilities using Cerberus’s leaked code. It is interesting and rare to have a look from “the other side” of malware, as we have done in this article, to see the C&C and how fraudsters manage and control bots all over the world.

 IBM Trusteer researchers will continue to monitor changes in the malware and keep you updated.

The author would like to thank Nethanella Messer and James Kilner for their contribution to this article.

The post Ermac malware: The other side of the code appeared first on Security Intelligence.

Web injections, a favored technique employed by various banking trojans, have been a persistent threat in the realm of cyberattacks. These malicious injections enable cyber criminals to manipulate data exchanges between users and web browsers, potentially compromising sensitive information.

In March 2023, security researchers at IBM Security Trusteer uncovered a new malware campaign using JavaScript web injections. This new campaign is widespread and particularly evasive, with historical indicators of compromise (IOCs) suggesting a possible connection to DanaBot — although we cannot definitively confirm its identity.

Since the beginning of 2023, we have seen over 50,000 infected user sessions where these injections were used by attackers, indicating the scale of threat activity, across more than 40 banks that were affected by this malware campaign across North America, South America,  Europe and Japan.

In this blog post, we will delve into an analysis of the web injection utilized in the recent campaign, its evasive techniques, code flow, targets and the methods employed to achieve them.

A dangerous new campaign

Our analysis indicates that in this new campaign, threat actors’ intention with the web injection module is likely to compromise popular banking applications and, once the malware is installed, intercept the users’ credentials in order to then access and likely monetize their banking information.

Our data shows that threat actors purchased malicious domains in December 2022 and began executing their campaigns shortly after. Since early 2023, we’ve seen multiple sessions communicating with those domains, which remain active as of this blog’s publication.

Upon examining the injection, we discovered that the JS script is targeting a specific page structure common across multiple banks. When the requested resource contains a certain keyword and a login button with a specific ID is present, new malicious content is injected.

Credential theft is executed by adding event listeners to this button, with an option to steal a one-time password (OTP) token with it.

This web injection doesn’t target banks with different login pages, but it does send data about the infected machine to the server and can easily be modified to target other banks.

Code delivery

In the past, we observed malware that directly injected the code into the compromised web page. However, in this campaign, the malicious script is an external resource hosted on the attacker’s server. It is retrieved by injecting a script tag into the head element of the page’s HTML document, with the src attribute set to the malicious domain.

HTML snippet:

During our investigation, we observed that the malware initiates data exfiltration upon the initial retrieval of the script. It appends information, such as the bot ID and different configuration flags, as query parameters. The computer’s name is usually used as the bot ID, which is information that isn’t available through the browser. It indicates that the infection has already occurred at the operating system level by other malware components, before injecting content into the browser session.

Figure 1: The initial obfuscated GET request fetching the script

Evasion techniques

The retrieved script is intentionally obfuscated and returned as a single line of code, which includes both the encoded script string and a small decoding script.

To conceal its malicious content, a large string is added at the beginning and end of the decoder code. The encoded string is then passed to a function builder within an anonymous function and promptly executed, which also initiates the execution of the malicious script.

Figure 2: Encoded string passed to de-obfuscation function, followed by removal of artifacts used for decoding the script. Two long strings were added to the beginning and end of the string to make it harder to find the code manually.

At first glance, the network traffic appears normal, and the domain resembles a legitimate content delivery network (CDN) for a JavaScript library. The malicious domains resemble two legitimate JavaScript CDNs:

In addition, the injection looks for a popular security vendor’s JavaScript agent by searching for the keyword “adrum” in the current page URL. If the word exists, the injection doesn’t run.

Figure 3: Searching for a security product’s keyword and doing nothing if it’s found

The injection also performs function patching, changing built-in functions that are used to gather information about the current page document object model (DOM) and JavaScript environment. The patch removes any remnant evidence of the malware from the session.

All of these actions are performed to help conceal the presence of the malware.

Dynamic web injection

The script’s behavior is highly dynamic, continuously querying both the command and control (C2) server and the current page structure and adjusting its flow based on the information obtained.

The structure is similar to a client-server architecture, where the script maintains a continuous flow of updates to the server while requesting further instructions.

To keep a record of its actions, the script sends a request to the server, logging pertinent information, such as the originating function, success or failure status and updates on various flags indicating the current state.

Figure 4: Every a.V function call sends an update to the server about what function it was sent from and the current state of different flags

Figure 5: An example of multiple traffic logs, sent within a few seconds of the script running

The script relies on receiving a specific response from the server, which determines the type of injection it should execute, if any. This type of communication greatly enhances the resilience of the web injection.

For instance, it enables the injection to patiently wait for a particular element to load, provide the server with updates regarding the presence of the injected OTP field, retry specific steps (such as injecting an SMS submission overlay) or redirect to the login page before displaying an alert indicating that the bank is temporarily unavailable.

The server keeps identifying the device by the bot ID, so even if the client tries to refresh or load the page again, the injection can continue from its previously executed step.

If the server does not respond, the injection process will not proceed. Hence, for this injection to be effective, the server must remain online.

Script flow

The script is executed within an anonymous function, creating an object that encompasses various fields and helper functions for its usage. Within the object, the injection holds the initial configuration with fields such as bot ID, phone number and password. These fields are initially empty but are populated with relevant values as the run progresses.

Additionally, the object includes details such as the C2 server’s domain and requests path, default values for query parameters and default settings for various flags such as “send SMS” and “send token.” These default values can be modified later based on the server’s response, allowing for dynamic adjustments during runtime.

Following the initial configuration, the script sends a request to the server providing initial details, and assigns a callback to handle the response, allowing the execution to proceed.

Subsequently, the script proceeds to remove itself from the DOM tree, enhancing its ability to conceal its actions. From that stage onward, all subsequent script actions are asynchronous, saved inside event handlers and dependent on the responses received from the server.

The steps the script should perform are mostly based on an “mlink” flag received from the server on the initial request. The next step of the injection is to check for the specific login button of the targeted bank. The results of the element query are sent, and the “mlink” state changes accordingly.

Following that, a new function runs asynchronously on an interval, looking for the login button and assigning a malicious event listener if found. The listener waits for a click event, collects the login credentials and handles it based on the current configuration.

For example, if the “collect token” flag is on, but the script can’t find the two-factor authentication (2FA) token input field, it just stops the current run and does nothing. If the token is found or wasn’t looked for in the first place, the script sends all the gathered information to the server.

After that, it can inject a “loading” bar to the page (opengif function), cancel the original login action or allow the client to continue with the actions by removing the handler and “clicking” it again on behalf of the user (by dispatching another “click” event).

Figure 6: The event listener prevents the default action of the login button or deletes itself and dispatches another click event based on the outcome of function G

Figure 7: This section of function G reads credentials and tries to read the injected token field value, depending on the current state of the page and flags

Potential operational states

Returning to the “synchronous” part of the callback, let’s examine some potential operational states and the corresponding actions taken.

When the “mlink” value is 2, the script injects a div that prompts the user to choose a phone number for 2FA. Once the user selects a phone number, a login attempt can be executed using the stolen credentials, and a valid token is sent to the victim from the bank.

Figure 8: Prompting a phone number for two-factor authentication

The following state is when “mlink” is equal to three, where the input field for the OTP token is injected. In this manner, DanaBot deceives the victim into providing the token, effectively bypassing the 2FA protection mechanism.

Figure 9: Prompting for the received token

When the “mlink” value is four, the script introduces an error message on the login page, indicating that online banking services will be unavailable for a duration of 12 hours. This tactic aims to discourage the victim from attempting to access their account, providing the threat actor with an opportunity to perform uninterrupted actions.

Figure 10: An error message that banking services are unavailable for 12 hours, giving the threat actor ample time to work

When the “mlink” value is 5, the script injects a page loading overlay that mimics the appearance of the original website’s loading animation. A timeout is set before transitioning to a different state, effectively “completing” the page load process.

Figure 11: An injected loading screen, an exact duplicate of the original loading screen

When the value of “mlink” is six, a “clean up” flow is initiated, removing any injected content from the page. This value serves as the default assignment for the flag in case no specific instruction is received from the server.

In total, there are nine distinct potential values for the “mlink” variable, each corresponding to different states and behaviors. Additionally, multiple flags activate various actions and result in different data being sent back to the server. Combining these “mlink” values and flags allows for a diverse range of actions and data exchanges between the script and the server.

Urging vigilance

IBM has observed widespread activity from this malware campaign affecting banking applications of numerous financial institutions across North America, South America, Europe and Japan. This sophisticated threat showcases advanced capabilities, particularly in executing man-in-the-browser attacks with its dynamic communication, web injection methods and the ability to adapt based on server instructions and current page state. The malware represents a significant danger to the security of financial institutions and their customers.

Users should practice vigilance when using banking apps. This includes contacting their bank to report potentially suspicious activity on their accounts, not downloading software from unknown sources and following best practices for password hygiene and email security hygiene.

Individuals and organizations must also remain vigilant, implement robust security measures and stay informed about emerging malware to effectively counteract these threats.

IBM Security Trusteer helps you to detect fraud, authenticate users and establish identity trust across the omnichannel customer journey. More than 500 leading organizations rely on Trusteer to help secure their customers’ digital journeys and support business growth.

The post Web injections are back on the rise: 40+ banks affected by new malware campaign appeared first on Security Intelligence.

Security information and event management (SIEM) systems remain a key component of security operations centers (SOCs). Security orchestration, automation, and response (SOAR) frameworks, meanwhile, have emerged to fill the gap in these capabilities left by many SIEM systems.

But as many companies have begun reaching the limits of SIEM and SOAR systems over the last few years, they have started turning to other solutions such as extended detection and response (XDR). But does this shift spell the end of SIEM and SOAR? Or is the future one of component-based cooperation?

Here’s what SOAR and SIEM look like in 2023 and what’s on the horizon for enterprise security.

SIEM and SOAR: What’s changed since 2020?

In 2020, a Security Intelligence piece spoke to the increase in fast, flexible and customizable cloud-based SIEM solutions. The piece also highlighted the need for SOAR deployments to help companies automate key operations and respond to emerging threats.

Three years on, the market has evolved. While most SOCs still rely on SIEM tools, IT professionals are painfully aware of their limitations. Much like legacy technologies that may frustrate moves to the cloud, aging SIEM solutions can hamper effective incident response.

The reason is simple. While logging and event management are necessary to understand one’s current security posture, they’re not enough in isolation to address issues as they occur. Combining them with SOAR helps extend their usable life but doesn’t eliminate the main issue. At their core, these tools are reactive, not proactive, meaning their security benefits are finite.

Explore IBM Security QRadar: Request a demo

Current trends in SIEM and SOAR

Despite their limitations, SIEM and SOAR are both seeing significant market growth. It makes sense: While companies recognize the need for new approaches to evolving security threats, SIEM and SOAR solutions have become fundamental aspects of cybersecurity frameworks. In 2022, the SIEM market was worth $5.2 billion and is now on track to reach $8.5 billion in the next five years. SOAR, meanwhile, saw a market value of $1.32 billion last year with a predicted compound annual growth rate of 16.4%.

While the scale of SIEM and SOAR adoption contributes to this increasing valuation, market trends also play a role. Key trends in 2023 include:

Shifting Attack Patterns

Attackers are changing their approach. Informed by the move to remote and hybrid work, malicious actors have shifted both forward and back: Forward, in that they’ve found new ways to exploit third-party and zero-day vulnerabilities. Back, in that they’ve ramped up phishing attack efforts on remote workers because these attacks still work.

In response, SIEM and SOAR tools are both getting back to basics to help companies detect potential phishing efforts, and integrating new threat data to help pinpoint possible points of compromise.

Process Automation

Automation now plays a key role in effective defense. According to a recent IBM survey, 87% of SOC team members say that automation would save some or a lot of time during threat response. But just 55% of teams use automation for threat hunting, and only 53% use automation to improve logic and alerts.

As a result, 2023 comes with an ongoing effort to move SIEM and SOAR solutions into the cloud where scalable resources can better support automation options.

Breathing new life into SIEM

Read a few articles on SIEM, and you’ll find a common theme: Security information and event management is “dead.”

Is it true? Not quite. Is it wrong? Not exactly. Here’s why: SIEM is great at what it does, which is collecting security data and informing IT teams. But what began as regular reports on the state of security have rapidly escalated into what’s known as “alert fatigue” — the sheer number of potential incidents and possible problems tied to desktop, mobile and personal devices has inundated teams with alerts. Despite best efforts, these alerts eventually begin to blend together, and they start to lose meaning. Add in a few false positives, and it’s often easier for teams to ignore repeated warnings.

Consider recent survey data, which found that SOC team members are only getting to half of the alerts they’re supposed to review every day. Even worse? Team members spend one-third of their workday validating incidents that aren’t a real threat. It’s no surprise, then, that alert fatigue is setting in.

The result is a landscape where both SIEM and SOAR are now starting to benefit from artificial intelligence. In both cases, the adoption of AI tools can narrow alert windows and automate security responses so IT staff aren’t inundated with alerts. Instead of getting hundreds of easily addressed alerts each day, teams only get alerts that require responses ASAP. All other issues can be handled by self-service portals for staff encountering login or credential issues or session termination by AI if suspicious behavior is detected.

What’s next for security solutions?

While most companies have no plans to abandon SIEM or SOAR — after all, why fix what’s (mostly) not broken — they recognize the need for solutions that help fill in the gaps.

This is the role of extended detection and response (XDR). A combination of network and endpoint detection and response (NDR and EDR) tools, XDR makes it possible for companies to both identify threats and respond to them in real-time. This is critical in a world driven by hybrid and remote work. The sheer number of endpoints across increasingly complex network environments makes visibility a top priority for organizations but makes achieving this visibility a challenge. XDR targets the behavior of applications and services across complex networks to help companies pinpoint where potential problems exist and take action to remediate these threats.

Now considered the most effective tool for threat hunting, XDR solutions are an expected investment for two-thirds of companies over the next six to 12 months. Much like SOAR and SIEM, however, even XDR tools aren’t a magic bullet for security. Instead, they form part of a connected, holistic approach to cybersecurity that provides the proactive processes currently missing from most enterprise SOCs.

Put simply? In 2023, SOAR and SIEM are part of a larger threat management landscape where companies will shift to proactive models by layering real-time detection and response solutions onto existing security frameworks.

Enhance your security posture with a modern-day SIEM solution that makes threat detection smarter so analysts can remediate faster – all while maintaining your business’s bottom line. Get a hands-on demo of the award-winning IBM Security QRadar SIEM here.

The post SIEM and SOAR in 2023: Key trends and new changes appeared first on Security Intelligence.

Threat hunting involves looking for threats and adversaries in an organization’s digital infrastructure that existing security tools don’t detect. It is proactively looking for threats in the environment by assuming that the adversary is in the process of compromising the environment or has compromised the environment.

Threat hunters can have different goals and mindsets while developing their hunt. For example, they can look for long-term threats in the environment that advanced threat actors can exploit. Or they can look for current trends and threats being exploited by environmental adversaries.

Threat hunting 101

How can we hunt for threats in our environment? Let’s walk through some steps along with examples.

Step 1: Research the threat actors and their tactics. We should always start our hunt by researching ongoing or past tactics and techniques used by threat actors and how they can affect our organization. We should review threat intelligence, review metrics on the security alerts and security incidents, the technology exploited by threat actors, etc.

Step 2: Develop a hypothesis. This hypothesis can be based on the adversary we are hunting, such as the tactics, techniques and procedures (TTPs) they use. Let’s consider an example where we want to search for adversaries utilizing system services as persistence mechanisms.

What can be our hypothesis?

Windows services are being created and launched by threat actors with the aim of running either an executable or a script file for persistence.

If attack group APT41 creates Windows services to establish malware persistence in our environment, we should see the activity in the endpoint detection and response (EDR) tool.

If APT41 creates Windows services to establish malware persistence in our environment, we should see Windows events showing service creations after logins from anomalous IP addresses.

Step 3: Understand the attack. Our next step will be focusing on what the attack technique is and how it can be executed based on the threat actor group we are focusing on.

Questions to consider for our example, which can be adapted to hunt for other TTPs:

• What is the name of the service being created on the system by the adversary?
• Is the service being created on the same system or a remote system?
• Is there any user account being created before the service creation?
• What does the service do?
• What tools and permissions does it require to execute?
• Is this an action performed by custom-built, licensed or open-source tools?
• Can any living-off-the-land binary perform the same action?

Example: The following are the services created and executed by the attack group APT41 described in this Group-IB blog post:

• sc \\172.26.16.81 Create SuperIe binPath= “cmd.exe /k c:\users\public\SecurityHealthSystray.exe”
• sc Create syscmd binpath=”cmd/k start”type= own type= interact sc \\192.168.111.112 create res binpath=”C:\PerfLogs\vmserver.exe” sc start LxpSrvc

The above commands create a service on the host 192.168.111.112 and 172.26.16.81 under the Public and Perflog folder.

Step 4: Understand the artifacts created by this action. This step is the key to determining if we can effectively test the hypothesis using as many methods as possible.

Usually, multiple types of artifacts are created for a type of action. Accounting for artifacts associated with different attack techniques can be helpful in creating variations in detections and hunt queries. It can also be beneficial when a threat actor tries to tamper with the evidence. If the attacker deletes one artifact or if it is not logged properly, there is always something else to fall back on.

Things to think about:

• What artifacts are created on the source system? Note that the source system is the system from where the malicious activities are originating.
• What artifacts are created on the destination system? Note that the destination system is the system that is being targeted or the system where the service is being created.
• What artifacts will be visible?
• Are there any chained events? Note that chained events mean that the threat actor is utilizing multiple techniques which can be correlated to hunt; for example, service creation after logging in from a malicious IP address.
• What platforms does your organization have that can be utilized to search for these artifacts?
• Can the artifact be deleted or modified easily?

Let’s take the example above and analyze methods to hunt for service creation.

Some of the artifacts we can look for on the destination system include:

• When a service is created, a couple of artifacts are generated on the system. For example, Windows event logs in the system or security event logs will have records for the events generated. Based on EDR the organization has, we can search for “New service created events” by the name of the service being created.
• Registry key(s) and value(s) for the service we seek.
• If the service creates additional processes on the system, there might also be artifacts related to the process execution of the malicious file in the Shimcache, Prefetch and Amcache. We can try hunting for files being created under the Prefetch folder.

Now, let’s think about other functionalities of the sc.exe executable creating the service.

The Microsoft executable sc.exe, which is used for creating a service, also has the ability to create a remote service on a specified server.

Before starting the hunt, we can think about the following questions:

• Is the attacker moving laterally and creating a service?
• Is the service being created on the same compromised system?

Destination system artifacts include:

• When a service is created on a different system, a network logon event is created on the destination system, and all the usual artifacts described above for the service creation are created.
• To hunt for these types of events, we can search for services created from private IP addresses and correlate them with network logon events.

Source system artifacts include:

• On the source system from where this service creation command was provided, there might be a logon event indicating the usage of alternate credentials. For example, event ID 4648 will be created, indicating where the threat actor has moved.

Below is one of the methods that can be utilized to create remote services:

1) Authenticate

net use \10.x.x.x\admin$ /user:nameofuser

2) Create service

sc.exe \10.x.x.x create NewServicetest binpath= c:\windows\system32\cmd.exe

3) Perform any actions

For more about sc.exe, check out this Microsoft article.

Step 5: Use labs to determine what events and artifacts are generated when a specific attack is performed (optional but highly recommended to get effective results). If our organization has a dedicated lab setup, we could do some red teaming exercises to see what kind of events and alerts are generated by the simulated threat actor activity.

Observations to make:

• How easy was it to perform the attack? For example, in another hunt focused on looking for credential dumping, the difficulty of simulating an attack would be important to know because of various methods that can be utilized to perform the attack and to determine the artifacts created by that dump. This won’t affect the artifacts created, but sometimes we don’t have custom tools built by the threat actors, so we might not get to know what’s happening and what we can see in the EDR tool. We might know the capabilities, but we are not sure how they perform the attack. For example, a password dump can be performed via dumping Chrome browsers passwords from the password store location, dumping a security account manager (SAM) registry hive, dumping lsass via procdump, or even dumping rdpclip and performing strings on it to get passwords or using valuevault to view credentials.
• What type and how many detections or alerts were generated when we performed the attack? If there were no alerts, we can start analyzing the events in our security tools. If there are alerts, we can try to find the gaps in the detections and ways we can bypass them. Also, we can think about different methods that the adversary can use to pivot to get the same results. For the example in the writeup, this refers to other ways the threat actor can create services on the target system.

Explore cyber threat hunting solutions

Step 6: Review the platform and feasibility of the hunt. Based on the research and data from the above steps, we need to see what platforms our organization has and where the hunt could be performed. We also need to determine if the hunt is even feasible to perform from the data we are recording in our environment.

Step 7: Develop the basic query. We can start developing the query now that we understand the attack and artifacts.

Examples of the queries we can run on Microsoft Advanced Threat Protection (MDATP) include (refer to the link and example above for service names and actions for which this EDR query is developed):

DeviceRegistryEvents

|where ActionType in (“RegistryValueSet”)

and RegistryKey matches regex @”HKEY_LOCAL_MACHINE\\SYSTEM\\.*\\Services\\.*”

and RegistryValueName == “Start” and RegistryValueData == “2”

//| where RegistryValueData has_any (“SecurityHealthSystray.exe”, “vmserver.exe “, “LxpSrvc”)

//|where  RegistryValueName has_any (“SecurityHealthSystray.exe”, “vmserver.exe “, “LxpSrvc”)

DeviceEvents

| where ActionType == ‘ServiceInstalled’

| where InitiatingProcessCommandLine has_any (“SecurityHealthSystray.exe”, “vmserver.exe”, “LxpSrvc”)

DeviceEvents

| where ProcessCommandLine has_any (“SecurityHealthSystray.exe”, “vmserver.exe “, “LxpSrvc”)

Step 8: Fine-tune the query. If the query returns numerous results, we need to modify the query to look for unique values or sum the events and maximum or minimum entries, sort by time, display the top 10 results, exclude the baseline events observed in our organization, etc.

Step 9: Further actions. If we have the malware sample and know the functionality of the malware, we can go one step further and think about how the threat actors can modify the same malware to reuse it after the enterprise security tools block them based on the current indicators of compromise.

We can also consider whether the same malware can be tweaked with minimal efforts to bypass the detections we create or already exist on our infrastructure and EDR tool.

Step 10: Actionable items. Once the hunt is finished, the threat hunters can report any malicious systems they find to the security operations center or computer security incident response team or create a detection query for the endpoint platforms.

IBM Security can significantly improve detection rates and accelerate the time to detect threats as well as investigate and remediate threats. For more information about IBM’s threat-hunting services, visit our website.

The post Threat hunting 101: How to outthink attackers appeared first on Security Intelligence.

Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem.

Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing more on building cybersecurity networks to be more powerful and secure.

In this article, we will be identifying a few of those vulnerabilities associated with cybersecurity in an organization and their impact on the business. Also, we will deduce a methodology for managing vulnerabilities in an organization and experiences with customers in implementing this methodology.

Common cybersecurity threats

Let’s walk through a few of the cybersecurity-related vulnerabilities that impact organizations the most.

Phishing

Phishing is the most widespread cybersecurity vulnerability that impacts more than 85% of organizations around the world. In phishing attacks, users are tricked into downloading malicious links that are sent to them through email. The email sent looks like a legitimate email with all the necessary information available in it. Thus, users are tricked into either opening an attachment or clicking a harmful link included in the email.

The most common type of phishing attack is email phishing. Over time, attackers have formulated other methods as well, including smishing, vishing and search engine phishing. In smishing, malicious links are sent through SMS over a phone, whereas in vishing phone calls are made to trick users. Search engine phishing is the most recent methodology where attackers create fake websites and ranks them on search engines, which compels the user to enter crucial information, resulting in robbing end users.

Ransomware

Ransomware is one of the most common types of threats that impacts hundreds of organizations on a daily basis. In ransomware attacks, organizations’ data is encrypted by attackers so that it cannot be accessed by anyone inside an organization. To unlock the data, attackers demand heavy ransoms thus resulting in huge loss of money, as well as disruption of their services.

Organizations usually tend to pay these ransoms to cyber attackers as they don’t have the resources to recover from a ransomware attack. In some cases, even after paying the ransom organizations are unable to retrieve their data.

Malware attacks

Malware attacks are malicious programs designed to cause harm or damage to an organization’s infrastructure, system, or network. The origin of malware is usually public Wi-Fi, spam emails, downloading malicious content, and clicking on pop-up ads. Once malware is released into the system, it can compromise all the critical and personal information available on the organization’s servers and systems.

Malware can be classified into one of the following categories: virus, trojan, worm, adware, spyware, malvertising. Malware is sometimes difficult to detect in the system and can change the system settings and permissions, spy on user activity, and block critical programs on users’ computers.

Distributed denial of service (DDoS)

In a distributed denial of service (DDoS) attack, an organization’s online services are made unavailable by flooding it with internet traffic from multiple sources. Cyber attackers target all the critical resources of bank or government websites to ensure end users are unable to access information available online on these websites.

Amazon Web Services (AWS) and GitHub were some of the latest victims of DDoS attacks. The common type of DDoS attacks includes UDP flood, ICMP (ping) flood, SYN flood, Slowloris, ping of death, HTTP flood, and NTP amplification.

Password theft

Another major threat that organizations face is employees using weak or common passwords. With most organizations using multiple application services these days, reusing easily guessed passwords can lead to compromising data.

Also, passwords can be compromised when users enter their credentials unknowingly into a fake website. Thus, it’s of utmost importance to use unique passwords that are hard to guess for each platform to ensure the security of the data.

Explore vulnerability management services

Impact of cyberattacks on an organization

One of the worst outcomes of a cyberattack is the drop in revenue as an organization must pay a hefty price to recover data from threat actors — and restore normal business operations. In 2018, a social media giant lost more than $13 billion in value after a data breach affected 50 million of its users. The company said attackers were able to exploit a vulnerability in a feature known as “View As” to gain control of people’s accounts. Their stock fell as much as 3% on the stock exchange.

Customers who have their personal information leaked tend to feel less secure providing sensitive information to the breached organization in the future — let alone, continuing to do business with the company. Loss of trust and faith equates to reputational damage for an organization. A major American retail giant lost the credit card information of more than 40 million customers in 2013 due to a data breach, which resulted in reputational damage and a loss of $18.5 million.

Depending upon the intensity of the cyberattack and the type of information compromised, organizations may have to pay an actual settlement and face legal consequences to compensate for the loss. A multinational American tech company suffered from one of the largest cyberattacks in the history of the internet. They were hit with multiple breaches in 2014 and 2016, which impacted more than 1 billion user accounts. The breach included names, email addresses, phone numbers, birthdays, etc. The tech company currently has several lawsuits against them and an ongoing investigation in U.S. Congress.

Cyberattacks can bring business to a halt by causing outages, thus causing a risk to business continuity. Users could be locked out of a system preventing them from accessing critical information. It would also lead to trading disruptions, like the inability to perform online transactions. In 2020, the National Stock Exchange of one of the island countries in the southwestern Pacific Ocean had to shut down operations following an extended DDoS attack on its network provider.

Threat modeling methodologies and technologies

Threat modeling is a proactive strategy of identifying potential vulnerabilities and developing countermeasures to either mitigate or counter those vulnerabilities to prevent systems from cyberattacks. Threat modeling can be performed at any stage during development — though it is recommended to perform it at the beginning of the project. In this way, threats can be identified and rectified sooner.

Multiple methodologies can be utilized for performing threat modeling. Choosing the correct technology depends upon what type of threats are to be tackled in the system. We’ll walk through five of the most popular threat modeling technologies used these days.

1. STRIDE

STRIDE is one of the most mature threat modeling techniques, which was adopted by Microsoft in 2002. STRIDE is an acronym for the type of threats it covers:

• S — Spoofing occurs when attackers pretend to be another person. One example of spoofing is when an email is sent from a fake email address, pretending to be someone else.
• T — Tampering occurs when information or data is modified or altered without authorization. The data can be tampered with by modifying a log file, inserting a malicious link, etc.
• R — Repudiation refers to the ability of an intruder to deny any malicious activity due to a lack of evidence. Attackers always want to hide their identity, so they hide their wrongdoings discreetly to avoid being tracked.
• I — Information disclosure is exposing data to unauthorized users that reveals information about the data that can be used by attackers to compromise the system.
• D — Denial of Service is overloading services with traffic to exhaust resources thus resulting in the crashing of a system or shutting it down to legitimate traffic.
• E — Elevation of Privilege occurs when attackers gain unauthorized access to information by gaining additional privileges in the system.

2. Common Vulnerability Scoring System (CVSS)

CVSS is a standardized threat scoring system used for known vulnerabilities. It was developed by the National Institute of Standards and Technology (NIST) and maintained by the Forum of Incident Response and Security Teams (FIRST).

CVSS captures a vulnerability’s principal characteristics while assigning a numerical severity score (ranging from 0-10, with 10 being the worst). The score is then translated into a qualitative representation which could be Critical, High, Medium, and Low. This helps organizations assess, identify, and effectively operate the threat management process.

3. VAST

Visual, Agile and Simple Threat (VAST) is an automated threat modeling technology based on ThreatModeler. VAST offers a unique plan so that the creation of threat model plans doesn’t require any specialized security subject matter expertise.

Implementing VAST requires the creation of application and operational threat models. Application threat models use a process flow diagram to represent the architectural aspect, while operational threat models are created from an attacker’s point of view based on a data flow diagram.

4. PASTA

Process for attack simulation and threat analysis (PASTA) is a seven-step risk-centric methodology developed in 2012. It assists organizations in dynamically identifying, counting, and prioritizing threats.

Once cybersecurity experts define a detailed analysis of identified threats, developers can develop an asset-centric mitigation strategy by analyzing the application through an attacker-centric perspective.

5. Attack Trees

Attack trees are charts displaying the path that show how an asset could be attacked. These charts display attack goals as the roots with possible paths as branches.

Attack trees are one of the oldest and most widely used threat model technologies. Earlier attack trees were used as a standalone methodology, but recently they are often combined with other technologies such as STRIDE, PASTA and CVSS.

Organizations must decide which threat modeling framework best suits their needs. Different methodologies are better for different situations and teams. Understanding the available options and the benefits and limitations of each can help with making an informed decision and improve the effectiveness of threat modeling efforts.

Conclusion

Managing threats is an evolving process. The main way to ensure a threat-free environment is to regularly test security infrastructure, utilizing the right tools and methodologies for threat management and inculcating a culture of knowledge and information within all employees. If these points are taken care of then an organization is doing its best to protect data and secure its system from any harmful attacks, vulnerabilities or threats.

As per recent trends, cyberattacks have increased on a monthly basis by 37% since the COVID-19 outbreak. As more employees are working from home or hybrid, businesses will need to have robust cybersecurity and digital strategies that account for changing working practices and exposure to new threats.

Let our team of cybersecurity experts help you stay ahead of threats and attacks against your organization. Learn more about IBM Security’s Threat Monitoring, Detection and Response services.

The post Vulnerability management, its impact and threat modeling methodologies appeared first on Security Intelligence.

This post was made possible through the research contributions provided by Amir Gendler and Michael  Gal.

In its latest research, IBM Security Lab has observed a noticeable increase in campaigns related to malicious Chrome extensions, targeting  Latin America with a focus on financial institutions, booking sites, and instant messaging. This trend is particularly concerning considering Chrome is one of the most widely used web browsers globally, with a market share of over 80% using the Chromium engine. As such, malicious actors can easily reach a large number of potential victims by distributing their malware through malicious extensions.

IBM Security Lab uncovered a new malware, “Predasus,” which is designed to inject malicious code through a Chrome extension. We’ve observed this mechanism being used to target various websites, including the web version of WhatsApp. Attackers accessed and used the target sites through legitimate means in order to deploy Predasus malware, which provided them the ability to steal users’ financial and other sensitive information.

This blog will provide an analysis of the Predasus malware and its mechanisms and detail how attackers are able to exploit the WhatsApp web to steal victims’ information.

Targeted browser extensions can infect a device through various methods, including social engineering tactics, exploiting vulnerabilities in the browser or operating system, or tricking users into downloading and installing them. Just like other methods of malware distribution, attackers may administer the extension through phishing emails, malvertising, fake software updates, or by exploiting browser or operating system vulnerabilities.

According to IBM Security Lab, Predasus has been observed engaging in a range of malicious activities, including stealing sensitive data such as login credentials, financial information, and personal details.  In this specific attack, Predasus is designed to terminate the active process of the Chrome browser while concurrently modifying the Chrome Browser Ink. This action occurs each time the browser initializes, facilitating the loading of the malevolent “extension_chrome” from a specific directory.

The attacker can then steal sensitive information, modify browser behavior, or perform phishing attacks. This attack vector is different from past methods in several ways. Firstly, it uses a sophisticated technique to terminate the active process of the Chrome browser, which is likely to evade detection by traditional antivirus or security software. Secondly, the attacker modifies the Chrome Browser Ink, which could allow the installation of the malicious extension without the user’s knowledge or consent.

Finally, because the attack appears to be specifically targeted, it could indicate the attacker may be seeking to compromise a specific set of users or organizations. Each of these steps is explained in more detail in the following section.

More from Trusteer

The operation of the attack

Exploiting browser extensions is just another way attackers can latch onto a user’s online financial transactions. They change methods from process injection or MITM to malicious Chrome extensions, which can steal users’ bank credentials and other personal information.

The scenario typically starts with a user opening an email attachment, which could be a PDF, Word, or Excel file. Unbeknownst to the user, the attachment contains malware that infects their machine, and, once downloaded, the malware is automatically deployed. Once the machine is infected, the malware connects to a first command and control (C&C) server and downloads several files that are written to a folder named “extension_chrome” under %APPDATA%. It terminates any process related to Google Chrome and creates malicious .LNK files in several locations, replacing legitimate ones.

Predasus uses the following commands in order to replace the old Chrome browser with a new one with the malicious extension:

• TASKKILL  /IM chrome.exe /F
• C:\Program Files\Google\Chrome\Application\chrome.exe”  –load-extension=”C:\Users\user\AppData\Roaming\extension_chrome
• “C:\Program Files\Google\Chrome\Application\chrome.exe” –no-startup-window /prefetch:5

It then executes one of these .LNK files to launch Google Chrome while automatically loading malicious .JS files. The malware also connects to a second C&C server (vialikedin[.]org) and downloads another JS file (px.js) that detects Adblockers. The malicious extension is constantly loaded onto the browser.

The malicious Chrome extension is designed to wait until the user accesses a targeted website – the targets of which are viewable in the javascript. At this point, it will steal their login credentials and other sensitive information, such as account numbers, PINs, and security questions. This information is then forwarded to a C&C server managed by the attackers.

Because the malicious Chrome extension operates silently in the background, many users may not even be aware their information has been stolen until stolen information is used to initiate unauthorized transactions or transfer funds.

In summary, the attack involves the following steps:

Attackers leverage WhatsApp Web’s popularity for malicious extension attacks

Our team has observed this mechanism being used specifically to target the web version of WhatsApp. It is worth noting that the emergence of these malicious extensions does not come as a surprise, as WhatsApp’s popularity has made it an attractive target for cyber criminals seeking to exploit its user base for nefarious purposes.

With WhatsApp’s ease of use, cross-platform compatibility, and ability to connect people across borders, it has become a staple for many individuals and businesses. However, with its popularity, comes a risk — it has become a prime target for cyber criminals looking to steal personal data and money.

Recently, we have seen a new malicious extension targeting WhatsApp’s web application.

Figure 1 – Malware targeting Whatsapp and injecting external malicious script

But why is this the case?

Firstly, WhatsApp’s web application is easy to access and use. With just a QR code scan, users can easily connect their phones to their computers and start messaging. This convenience, however, also makes a malicious actor’s job easier.

Secondly, WhatsApp is particularly popular in countries such as India, Brazil, and Mexico, with many people relying on it for daily communication,  giving attackers a wider pool of potential targets.

Behind the scenes of the malicious extension

Upon successful changes of the Chrome browser with the new malicious extension, we detected a series of anomalous activities executed by the malicious extension.

Figure 2 – manifest.json file of the malicious extension

manifest.json file contains various settings and configurations for the extension.

From the configuration, we can see the name of the extension is misspelled: “Secuirty Update”.

The extension has the following permission:

• “alarms”: Allows the extension to schedule tasks or reminders at specific times.
• “background”: Allows the extension to run in the background, even when the extension’s popup window is closed.
• “cookies”: Allows the extension to access and modify cookies for any website the user visits.
• “idle”: Allows the extension to detect when the user’s system is idle (i.e., not being actively used).
• “system.display”: Allows the extension to detect and adjust display settings on the user’s system.
• “tabs”: Allows the extension to access and modify browser tabs and their content.
• “storage”: Allows the extension to store and retrieve data from the browser’s local storage.
• “webRequest”: Allows the extension to monitor, block, or modify network requests made by the browser.
• “webRequestBlocking”: Allows the extension to block network requests made by the browser.
• “browsingData”: Allows the extension to clear the user’s browsing data (such as history and cache) for specific websites.
• “http://*/*”: Allows the extension to access any HTTP website.
• “https://*/*”: Allows the extension to access any HTTPS website.

Some of these permissions pose a risk, as they allow the extension to access or modify sensitive user data. As such, it’s important to be careful when granting permissions to browser extensions and to only install extensions from trusted sources.

Inside the “manifest.json” there’s “content_scripts” which specifies the extension should inject “main.js” into all frames of all URLs.

Figure 3 – main.js inject external JavaScript

The new script’s source is set to “hxxps://techcosupportservice.com/ext/ok.js”, which means when the script is executed, it will load and execute the JavaScript code from that URL.

This technique is commonly used to load external JavaScript files into a web page dynamically. By doing so, the web page can load additional functionality or libraries on-demand, rather than having to include all the JavaScript code in the page’s HTML source directly.

Figure 4 – external script ok.js

The script called “ok.js” contains configuration information and is designed to check whether the victim is visiting a website that is included in a targeted list.

Upon the victim navigating to the web.whatsapp.com website, a script called “main.js” is injected into the user’s browser. This script is malicious in nature and could be used for various nefarious purposes, such as monitoring the users’ browsing behavior or stealing sensitive information entered by the user on the webpage.

Figure 5 – WhatsApp malicious injection

The attacker loads a scam website from the malicious injection and presents the victim with a message requesting they need to renew their subscription to continue using WhatsApp web. This fraudulent message is designed to trick the victim into providing sensitive information, such as their payment details or login credentials.

Figure 6 – Fake payment request for WhatsApp

After the victim has entered their personal information, the attacker then prompts the victim to enter a One-Time Password (OTP) via SMS. The victim may believe this is a legitimate step in the authentication process, but the attacker is trying to steal the victim’s OTP. Additionally, now the attacker can establish an unauthorized session with the bank, which they could potentially use to transfer money or carry out other fraudulent activities.

Figure 7 – Fake OTP page

Figure 8 – Transaction confirmed

Once the victim has entered their OTP, the attacker’s website or application sends all of the victim’s personal information, including the credit card number and OTP, to the attacker’s C&C server. The attacker can then use this information for fraudulent purposes, such as making unauthorized purchases or identity theft.

Figure 9 – C&C uAdmin panel

Darknet selling uAdmin panel

There has been a noticeable increase in the demand for C&C panels on the darknet, with a particular emphasis on the highly versatile uAdmin panel.

The management panel of this tool can be customized to collect user login credentials, credit card information, and cookies. Moreover, it can redirect traffic and facilitate various other malicious activities.

Figure 10 – uAdmin capabilities taken from Darknet

Once acquired by a cyber criminal, the uAdmin Panel can become a tool for carrying out various attacks. The customization options available through uAdmin Panel can enable the attacker to carry out different types of malicious activities, such as:

• Stealing User Data: uAdmin Panel can be used to steal user data, including login credentials, personal information, and financial data. This information can then be used for a range of malicious purposes, such as identity theft or financial fraud.
• Redirection of Attacks: uAdmin Panel can also be configured to redirect attacks to different servers or websites. This can be used to evade detection or to target specific victims.
• Web-Injects: uAdmin Panel can be used to configure JavaScript Web injections in order to steal victim-sensitive information.
• Harvesting Cookies: uAdmin Panel can also be used to harvest cookies, which can be used to gain unauthorized access to user accounts or to track user activity.

Figure 11 – Darknet selling uAdmin Panel & Webinjects

The screenshot displays a list of financial institutions, and it appears to be associated with a “uadmin panel.” The prices listed indicate that some of these financial institutions are selling either just the management panel or the panel along with webinject kits.

Targeted list

IOCs

MD5:
50e9958bb2a5b6ae6ed8da1b1d97a5bb
d2183968f9080b37babfeba3ccf10df2

Domains

hxxps://techcosupportservice.com

hxxps://techcosupportservice.com/panel_m/conn.php

hxxp://62.204.41.88/lend/rc.exe

hxxps://contestofskillonline.com/uadmin/gate.php

hxxps://techcosupportservice.com/ext/vvv1.js

hxxps://techcosupportservice.com/ext/ok.js

hxxps://techcosupportservice.com/ext/main.js

hxxps://techcosupportservice.com/ext/background.js

hxxps://techcosupportservice.com/ext/manifest.json

hxxps://techcosupportservice.com/jquery.js

hxxp:// vialikedin.org

How to stay safe from malicious Chrome extensions

To protect against these malicious extensions, it’s important to be vigilant when installing any new browser extensions. Users should only download extensions from trusted sources and carefully review the permissions requested by the extension before installation. Additionally, they should use two-factor authentication and regularly update their browser and extensions.

The rise of malicious Chrome extensions is a worrying trend that highlights the need for users to be vigilant when browsing the web.

It is suspected this malware campaign may potentially spread to the North American and European regions.

To learn how to authenticate customers, detect fraud and protect against malicious users across all channels, explore IBM Security Trusteer solutions.

The post The rise of malicious Chrome extensions targeting Latin America appeared first on Security Intelligence.

White hat hackers serve as a crucial line of cyber defense, working to identify and mitigate potential threats before malicious actors can exploit them. These ethical hackers harness their skills to assess the security of networks and systems, ultimately helping organizations bolster their digital defenses. But what drives someone to pursue a career as a white hat hacker, and how do you get started in leveraging so-called “evil” skills for the greater good??

In this exclusive Q&A, we spoke with seasoned white hat hacker Gilit Saporta, Director of Analytics for DoubleVerify’s Fraud Lab. Gilit has helped out with and stopped some of the world’s sneakiest ad fraudsters across streaming, the open web, mobile, etc. Before her role as Director of Analytics at DV, she worked at Simplex as a Fraud Fighting Team Leader and Head of Fraud Intelligence. Prior to that, Gilit was Head of Training for Forter, and for nearly seven years, led analytics and risk science initiatives at PayPal.

Did you go to college? What did you go to school for?

As an adopted daughter to parents who immigrated to Israel a few years after World War II, I was honored to be the first person in my extended family to attend university in Israel. I graduated from Tel Aviv University, where I majored in Theatre Arts (BA summa cum laude, valedictorian and MFA summa cum laude). I was lucky enough to be able to pursue my passion for art in parallel to my work in tech for a couple of years and even had a few of my plays produced in fringe theaters in Tel Aviv.

What was your first role in tech?

Going way back, as a teenager I had a summer vacation job for a telephone company, where I physically maintained analog phone line routing systems back in the 1990s.

But to be a bit more focused on high-tech, as an IDF military intelligence officer, I started to learn code and build logic for innovative defense products at the age of 18. This experience probably landed me my first “real” role in tech: a student position at the age of 21 catching early attacks on e-commerce sites for a startup called FraudSciences, that was later acquired by PayPal. I was looking for an interesting part-time job I could do to help fund my university studies, and in a way, I almost fell into it. Today, I love hearing my kids tell people that their mom has been “catching bad people online for over 20 years.”

What is the most valuable skill you learned in your role?

Keeping an open mind and a curious mindset was and remains the core of my skill set. Through my first roles, I learned that being curious about the endless research options of the data around you will allow you to work with the most intelligent — and fun — people. Plus, you’ll get the rush of feeling that there’s always another hill to climb.

I’ve always loved solving puzzles, so learning that the passion for digging into data quirks is in itself a skill was a huge revelation for me.

What soft skills do you think make a person successful in tech, fraud protection and cybersecurity?

Stay humble, knowing that there’s lots to learn from newcomers with a fresh perspective. This is a soft skill that all researchers should possess, especially when it comes to growing into leadership roles. I see that by continuously encouraging others to express even their “hunch” about potential theories is a strong asset for the team’s creativity and that great discoveries are made thanks to this culture.

Any parting thoughts or final piece of advice to someone looking into your type of role?

These days, there are ample learning opportunities and reading materials available about any flavor of cybersecurity and fraud protection products. I recommend not only reading samples of this ocean of information but also interacting with the community of fraud fighters whenever possible — conferences, meetups, professional social media and beyond. Contribute your own thoughts and questions to the community, hypothesize about scams and schemes that you would imagine are happening, get some feedback and gradually become a master of storytelling — since the story of the attack is often just as important as the quantitative analysis.

The post How I got started: White Hat Hacker appeared first on Security Intelligence.

Vulnerabilities like Log4j remain responsible for security breaches a full year after the discovery of the flaw. In the months after widespread reporting about the vulnerability, 40% of Log4j downloads remained vulnerable to exploitation.

Rapid response — by both security teams and hackers

What made this exposure so damaging was how widespread this piece of code is and how hard it is to find exactly where it’s used. This open-source logging code from Apache was the most popular java logging library, clocking in at over 400,000+ downloads from GitHub. The code is embedded in many internet services and apps, including Twitter, Amazon, Microsoft, Minecraft and others. As an easily accessible piece of open-source logging code, developers used it rather than taking the time to create new code during development. In days after its discovery, Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency (CISA), said in a CNBC interview, “The Log4j vulnerability is the most serious vulnerability that I’ve seen in my decades-long career.” She went on to say, “This is not something that will be patched and finished. This is something that we are likely going to be working on for months, if not years, given the ubiquity of the software and ease of exploitation.”

Publication of the vulnerability moved security teams to action. Apache listed all the projects affected by the Log4j flaw but publicizing the flaw also prompted bad actors to take advantage of slower-moving or understaffed team responses. Cybersecurity software business Check Point noted that within days of reporting the vulnerability, more than 60 new variations of the exploit were introduced in less than 24 hours.

Flaw still inspires new attacks

The initial Log4j vulnerability exposure was widespread and pervasive, but the danger remains, still threatening businesses. Threat landscapes shift with time. For example, Log4Shell is a vulnerability in Log4j 2. It allows a remote attacker to take control of a device on the internet if the device is running specific versions of Log4j 2. Apache created a patch, but that patch left part of the vulnerability unfixed, requiring second, third and fourth patches to fix new vulnerabilities as they were found. Threat actors rely on security and IT teams to be too busy and users too uninformed about threats to simply ignore these patches. As recently as November 2022, Iran-linked threat actors exploited Log4Shell via unpatched VMware. CISA observed suspected threat activity at a Federal Civilian Executive Branch (FCEB) organization. They determined that cyber threat actors had exploited the Log4Shell vulnerability in an unpatched VMware Horizon server. From there, they installed crypto mining software to the server, moved to the domain controller, compromised credentials and then implanted Ngrok reverse proxies on several hosts.

This may be among the newest iterations of the Log4j threat, but they assuredly won’t be the last. And, of course, there will be new threats that arrive in new ways through other vulnerabilities. It’s clear that updating software and encouraging users to install patches isn’t enough. Even when organizations do their best to stay up to date on all patches, threats morph and move fast enough to make those patches outdated. It may seem updating devices and software belongs in the realm of IT. Still, given the urgency of security weaknesses and their business impact, security retrofitting needs to be a full-time concern.

Retrofitting as a central task for cybersecurity teams

Large organizations with thousands of devices and arduous processes for software and hardware updates remain especially susceptible, whether that’s to the Log4j vulnerability or as-yet-unknown vulnerabilities. Here are some tips on how to structure your team’s response plans and ensure you can retrofit security controls in the face of modern cybersecurity threats.

1. Make addressing vulnerabilities a security team function. Software patches and device updates frequently fall to IT teams to accomplish. However, as noted above, patches and updates frequently can’t be done quickly enough to head off threats before they cause harm. Rather than overburden busy IT personnel, make threat vigilance and mitigation a security team function. Keep your security team on target by ranking priorities in order of urgency. Consider expanding this team if they’re stretched thin. Considering the cost to the business of falling prey to these attacks, the expense of expanding the team should be a reasonable price to pay for the added protection.
2. Watch the watchers. Governments worldwide support cybersecurity agencies whose main mission is to warn organizations about cybersecurity threats. In the U.S., that organization is CISA. In the U.K., it’s the National Cyber Security Centre (NCSC). You can sign up to receive alerts from these and other trusted organizations. They describe the threat and offer resources and advice on how best to mitigate damage to your organization.
3. Communicate early and often. Ensure there are open lines of communication between your cybersecurity and IT teams, as well as other mission-critical teams within your organization. Neither team can watch or know everything. Additionally, if the worst happens, it’s wise to have open communications with your vendors, partners and customers. If they put you at risk or you put them at risk, you need to know how and with whom to communicate if disaster recovery steps become necessary.
4. Deepen your defense. Criminals are crafty. They will always look for — and find — the next opening to exploit. Your security practices should range from simple (strong passwords, multi-factor authentication or user controls) to more complex (vulnerability hunts or hackathons to find holes). Your organization might find a good threat-hunting program beneficial. The more security layers your organization erects, the less damage cyber criminals can do.
5. Document — and practice — your plan. Disaster recovery plans go way beyond natural disasters. Resilient companies understand how all-encompassing modern disaster planning needs to be. Cybersecurity disaster planning outlines who own and runs the plan, where are the assets that require protection, how to stop damage and loss, when the plan should be updated and what strategies will best protect your company. Like any good plan, it’s not a one-and-done task. Security threats evolve, so your plan must be updated and practiced to ensure it’s current and that each team member understands the role they play.

Organizations of all sizes are vulnerable to security threats. Strengthening your security posture remains the only option in a world where cybersecurity threats continue to multiply.

The post With 40% of Log4j downloads still vulnerable, security retrofitting needs to be a full-time job appeared first on Security Intelligence.