Common Http And Https Exploits For Networks

1. The victim unknowingly visits a web page that has been compromised by malware.
2. The compromised web page redirects the user, often through many compromised servers, to a site containing malicious code.
3. The user visits this site with malicious code and their computer becomes infected. This is known as a drive-by download. When the user visits the site, an exploit kit scans the software running on the victim’s computer including the OS, Java, or Flash player looking for an exploit in the software. The exploit kit is often a PHP script and provides the attacker with a management console to manage the attack.
4. After identifying a vulnerable software package running on the victim’s computer, the exploit kit contacts the exploit kit server to download code that can use the vulnerability to run malicious code on the victim’s computer.
5. After the victim’s computer has been compromised, it connects to the malware server and downloads a payload. This could be malware or a file download service that downloads other malware.
6. The final malware package is run on the victim’s computer.

Independent of the type of attack being used, the main goal of the threat actor is to ensure the victim’s web browser ends up on the threat actor’s web page, which then serves out the malicious exploit to the victim.

Some malicious sites take advantage of vulnerable plugins or browser vulnerabilities to compromise the client’s system. Larger networks rely on IDSs to scan downloaded files for malware. If detected, the IDS issues an alert and records the event to log files for later analysis.

Server connection logs can often reveal information about the type of scan or attack. The different types of connection status codes are listed here:

• Informational 1xx – This is a provisional response, consisting only of the Status-Line and optional headers. It is terminated by an empty line. There are no required headers for this class of status codes. Servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
• Successful 2xx – The client’s request was successfully received, understood, and accepted.
• Redirection 3xx – Further action must be taken by the user agent to fulfil the request. A client SHOULD detect infinite redirection loops because these loops generate network traffic for each redirection.
• Client Error 4xx – For cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the situation, and if it is temporary. User agents SHOULD display any included entity to the user.
• Server Error 5xx – For cases where the server is aware that it has erred, or it cannot perform the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and if it is temporary. User agents SHOULD display any included entity to the user.

To defend against web-based attacks, the following countermeasures should be used:

• Always update the OS and browsers with current patches and updates.
• Use a web proxy like Cisco Cloud Web Security or Cisco Web Security Appliance to block malicious sites.
• Use the best security practices from the Open Web Application Security Project (OWASP) when developing web applications.
• Educate end-users by showing them how to avoid web-based attacks.

The OWASP Top 10 Web Application Security Risks is designed to help organizations create secure web applications. It is a useful list of potential vulnerabilities that are commonly exploited by threat actors.

• Use a web proxy to block malicious sites.
• Because attackers often change the source HTML of the iFrame in a compromised website, make sure web developers do not use iFrames. This will isolate any content from third-party websites and make modified pages easier to find.
• Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
• Make sure the end-user understands what an iFrame is. Threat actors often use this method in web-based attacks.

HTTP 302 Cushioning
Another type of HTTP attack is the HTTP 302 cushioning attack. Threat actors use the 302 Found HTTP response status code to direct the user’s web browser to a new location. Threat actors often use legitimate HTTP functions such as HTTP redirects to carry out their attacks. HTTP allows servers to redirect a client’s HTTP request to a different server.

HTTP redirection is used, for example, when web content has moved to a different URL or domain name. This allows old URLs and bookmarks to continue to function. Therefore, security analysts should understand how a function such as HTTP redirection works and how it can be used during attacks.

When the response from the server is a 302 Found status, it also provides the URL in the location field. The browser believes that the new location is the URL provided in the header. The browser is invited to request this new URL. This redirect function can be used multiple times until the browser finally lands on the page that contains the exploit. The redirects may be difficult to detect due to the fact that legitimate redirects frequently occur on the network.

These are some ways to prevent or reduce HTTP 302 cushioning attacks:

• Use a web proxy to block malicious sites.
• Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
• Make sure the end user understands how the browser is redirected through a series of HTTP 302 redirections.

Domain Shadowing
When a threat actor wishes to create a domain shadowing attack, the threat actor must first compromise a domain. Then, the threat actor must create multiple subdomains of that domain to be used for the attacks.

Hijacked domain registration logins are then used to create the many subdomains needed. After these subdomains have been created, attackers can use them as they wish, even if they are found to be malicious domains. They can simply make more from the parent domain. The following sequence is typically used by threat actors:

1. A website becomes compromised.
2. HTTP 302 cushioning is used to send the browser to malicious websites.
3. Domain shadowing is used to direct the browser to a compromised server.
4. An exploit kit landing page is accessed.
5. Malware downloads from the exploit kit landing page.

These are some ways to prevent or reduce domain shadowing attacks:

• Secure all domain owner accounts. Use strong passwords and use two-factor authentication to secure these powerful accounts.
• Use a web proxy to block malicious sites.
• Use a service such as Cisco Umbrella to prevent users from navigating to web sites that are known to be malicious.
• Make sure that domain owners validate their registration accounts and look for any subdomains that they have not authorized.

The following are examples of email threats:

• Attachment-based attacks – Threat actors embed malicious content in business files such as an email from the IT department. Legitimate users open malicious content. Malware is used in broad attacks often targeting a specific business vertical to seem legitimate, enticing users working in that vertical to open attachments or click embedded links.
• Email spoofing – Threat actors create email messages with a forged sender address that is meant to fool the recipient into providing money or sensitive information. For example, a bank sends you an email asking you to update your credentials. When this email displays the identical bank logo as mail you have previously opened that was legitimate, it has a higher chance of being opened, having attachments opened and links clicked. The spoofed email may even ask you to verify your credentials so that the bank is assured that you are you, exposing your login information.
• Spam email – Threat actors send an unsolicited email containing advertisements or malicious files. This type of email is sent most often to solicit a response, telling the threat actor that the email is valid and a user has opened the spam.
• Open mail relay server – Threat actors take advantage of enterprise servers that are misconfigured as open mail relays to send large volumes of spam or malware to unsuspecting users. The open mail relay is an SMTP server that allows anybody on the internet to send mail. Because anyone can use the server, they are vulnerable to spammers and worms. Very large volumes of spam can be sent by using an open mail relay. It is important that corporate email servers are never set up as an open relay. This will considerably reduce the number of unsolicited emails.
• Homoglyphs – Threat actors can use text characters that are very similar or even identical to legitimate text characters. For example, it can be difficult to distinguish between an O (upper case letter O) and a 0 (number zero) or a l (lower case “L”) and a 1 (number one). These can be used in phishing emails to make them look very convincing. In DNS, these characters are very different from the real thing. When the DNS record is searched, a completely different URL is found when the link with the homoglyph is used in the search.

Just like any other service that is listening to a port for incoming connections, SMTP servers also may have vulnerabilities. Always keep SMTP software up to date with security and software patches and updates.

To further prevent threat actors from completing their task of fooling the end-user, implement countermeasures. Use a security appliance specific to email such as the Cisco Email Security Appliance.

This will help to detect and block many known types of threats such as phishing, spam, and malware. Also, educate the end-user. When attacks make it by the security measures in place, and they will sometimes, the end-user is the last line of defence. Teach them how to recognize spam, phishing attempts, suspicious links and URLs, homoglyphs, and never open suspicious attachments.

• Stored (persistent) – This is permanently stored on the infected server and is received by all visitors to the infected page.
• Reflected (non-persistent) – This only requires that the malicious script is located in a link and visitors must click the infected link to become infected.

These are some ways to prevent or reduce XSS attacks:

• Be sure that web application developers are aware of XSS vulnerabilities and how to avoid them.
• Use an IPS implementation to detect and prevent malicious scripts.
• Use a web proxy to block malicious sites.
• Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
• As with all other security measures, be sure to educate end-users. Teach them to identify phishing attacks and notify infosec personnel when they are suspicious of anything security-related.

Action Point
PS: If you would like to have an online course on any of the courses that you found on this blog, I will be glad to do that on an individual and corporate level, I will be delighted to do that because I have trained several individuals and groups and they are doing well in their various fields of endeavour. Some of those that I have trained include staff of Dangote Refinery, FCMB, Zenith Bank, and New Horizons Nigeria among others. Please come on Whatsapp and let’s talk about your training. You can reach me on Whatsapp HERE. Please note that I will be using Microsoft Team to facilitate the training. 

I know you might agree with some of the points that I have raised in this article. You might not agree with some of the issues raised. Let me know your views about the topic discussed. We will appreciate it if you can drop your comment. Thanks in anticipation.

CRMNUGGETS  is committed to fact-checking in a fair, transparent and non-partisan manner. Therefore, if you’ve found an error in any of our reports, be it factual, editorial, or an outdated post, please contact us to tell us about it.