Jump to content

itman

Most Valued Members
  • Posts

    12,197
  • Joined

  • Last visited

  • Days Won

    320

Posts posted by itman

  1. Appears Chrome has an issue with Cloudflare and everything else from that matter.

    Per Robtex:

    Quote

    ANALYSIS

    This section shows a quick analyis of the given host name or ip number.

    Scrlink.cool has two name servers and four IP numbers.

    Cloudflare name servers

    The name servers are elinore.ns.cloudflare.com and hugh.ns.cloudflare.com.

    What's the story behind the names of CloudFlare's name servers?.

    IP numbers

    The IP numbers are 2606:4700:e0::ac40:6613, 2606:4700:e0::ac40:6713, 172.64.102.19 and 172.64.103.19. The IP numbers are in San Francisco, United States.

    We investigated one host name that cnames to scrlink.cool.

    Results found

    Scrlink.com, clinksr.com, clrskin.com, crinkls.com, crlinks.com, crslink.com, csrlink.com, linkcsr.com, linkscr.com, linksrc.com, lrnicks.com and lskrinc.com.

  2. 2 hours ago, Haresh2015 said:

    Solution: remove all firewall rules in ESET Advance Setup.

    I would have first set the Eset firewall to its default setting of  Automatic which allows all outbound connections and see if that resolved the Chrome issue. I would also delete all existing rules that apply to Chrome. -EDIT- Prior to deleting the Chrome rules, take a screen shot of all its existing rules. Those can then be reapplied one by one testing the impact of each rule to determine the rule/s preventing Chrome's start up or impacting its execution.

  3. Eset doesn't have a detailed write up on this variant, Win64/Vools.F trojan, but does have one for an earlier variant: https://www.virusradar.com/en/Win64_Vools.B/description .

    It appears this malware is designed to exploit the well publicized SMBv1 vulnerability disclosed here and patched in 2017: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010

  4. 7 hours ago, killer said:

    also my cmd is disabled, everytime i open it, it closes automatically

    What version of Windows do you have installed?

    How are you trying to open the command prompt window? Via Start menu option? If you are using Win 10, enter "command" less the quote marks in the desktop lower toolbar search window. Then click on Command Prompt in the displayed window.

  5. When checking out a screen shot posting on a file share site in a security forum I frequent, hxxps://imx.to/i/1yj02x , Eset detected what appears to be redirect to a malicious porn site based on what other forum posters related:

    Time;URL;Status;Application;User;IP address;SHA1
    2/12/2019 4:27:17 PM;https://afeuvqrsswz.com;Blocked by internal IP blacklist;C:\Program Files\internet explorer\iexplore.exe;XXX-XX\XXXX-XXX;216.21.13.15;021415D73D02C6247001BAD6E5C9BC6E220F34FC

    Eset displayed the above as a small desktop popup alert upon access to the web page. However, the file share web page was still displayed. At that point and knowing better, I should have exited the web site. Instead, I clicked on a "Continue" link displayed which resulted in a locked flashing browser screen with a loud alarm sounding, a voice stating I was infected with malware, and a phone number I needed to call to resolve the issue. Obviously, this was fake malware and I resolved it without issue. However, an average user might have been duped into responding to the fake malware. 

    My question is should Eset not have blocked the file share web page from displaying or terminated its connection thereafter at initial IP blacklist detection time? 

  6. 2 hours ago, LB-ID said:

    It has an Intel HD Graphics 520 video system

    Always helps to post as much relevant information as possible.

    Appears the 1803 update caused all kinds of issues with older Intel graphics chipsets. Below are a few references, You can Google search for others.  Why the problem manifests for you using Eset still remains a mystery. Appears that disabling HVCI - memory integrity protection worked for some:

    https://forums.intel.com/s/question/0D50P0000490RqtSAE/intel-hd-graphics-error-after-windows-10-1803?language=en_US

    https://social.technet.microsoft.com/Forums/azure/en-US/d889c4a0-7aff-49ba-9b73-7b9e2ad5d8b7/intel-hd-graphics-driver-error-after-update-to-1803?forum=win10itprogeneral

  7. 1 hour ago, Wynot said:

    Turns out its Iheart.com

    The site itself is clean per URLVoid: https://www.urlvoid.com/scan/iheart.com/ .

    When I connect using iheart.com, I end up at quickio.iheart.com with an IP address of 34.195.19.104. Interestingly, that also resolves to Amazon per Robtex: https://www.robtex.com/ip-lookup/34.195.19.104 .

    The common theme to these alerts appears to be the connection to Amazon servers in the U.S.. Also I use EIS and are receiving no alerts on any of these connections.

    -EDIT- Forgot to mention to did observe routing connections through the Amazon backbone servers.

  8. As far as that IP address goes, it resolves to Amazon: https://www.robtex.com/dns-lookup/ec2-3-17-238-130.us-east-2.compute.amazonaws.com .

    -EDIT- As far as domain https://secure-drm.imrworldwide.com goes, it is associated with:

    Quote

    The IP number is 138.108.140.100. The IP number is in Schaumburg, United States. It is hosted by Route for Nielsen.

    Secure-drm.imrworldwide.com has a chain of two CNAMEs ultimately pointing to secure-hongkong.imrworldwide.com. Secure-hongkong.imrworldwide.com has one IP number.

    Per Robtex: https://www.robtex.com/dns-lookup/secure-drm.imrworldwide.com

    Finally, IPVOID states 3.17.238.130 is not a valid IP address. Makes sense since it appears it is trying to directly access a backbone server. Appears something is screwed up DNS-wise.

  9. There are advanced persistent threats that can survive a HDD reformat and OS reinstall. What needs to be done is a disk wipe utility capable of performing military grade wiping/reformatting on drive be used. On a large hard drive this could take days or even a week or more to complete. A simpler solution is just to replaced the hard drive with a new one. Prior to doing so, I would experiment with a borrowed or unused hard drive from another device. When the OS is installed  and AV software installed and no infection reoccurs, you have your confirmation the old hard drive is the source. 

    Also both your PCs are part of a larger local network, the malware could be resident on another device on the network.

  10. One last thing.

    Your router log is interspersed with ICMP flood entries. This is basically a "ping" attack. What is interesting is they all originate from IP address, 66.151.55.xxx. This address is associated with Internap Corporation who is a major Internet backbone infrastructure provider. Why they would be performing such activity against your device is very much a mystery. Also to be determined is if these are in any way related to the TCP SYN ACK activity.

    Are you a gamer by any chance?

  11. 47 minutes ago, bbenz said:

    How did you trace the IP's

    I use Robtex: https://www.robtex.com/

    47 minutes ago, bbenz said:

    The internet cuts out every now and then and sometimes shuts off completely to where i need to reset the modem/router to get it back online.

    Another possibility of what is occurring is NetGear is controlling the SYN/ACK activity from the LAN side of the router. Eset IDS sees this activity and is blocking it. This in turn eventually locks up the router. Again, you need to get info from Netgear on how the router responds to these TCP SYN flood attacks. It may end up that you will have to have Eset IDS allow this activity from the router, 192.168.1.1, only.

    -EDIT- This posting is worth a read; scroll down to the end: https://community.netgear.com/t5/Cable-Modems-Routers/DoS-attack-SYN-Flood-Network-activity-stops/td-p/1504584 . Appears HP printer's might be the culprit.

  12. There are a lot of 207.69.0.0/16 subnet addresses in the log you posted. That IP address range is allocated to Earthlink.net. Is Earthlink your ISP? I would contact their tech support about all these TCP SYN ACK transmissions you are receiving and that are being blocked as a DoS attack by your router. You can refer them to your log upload link above. Also one specific IP address I checked, 207.69.195.84, has an imap. prefix for its associated domain name. This makes me think there might be an issue perhaps with their e-mail servers.

    Somewhat of a mystery is IP address, 23.34.140.54, which appears to be a legit Akamai address. Again, it appears the issue lies with the transmissions being forwarded by your ISP.

    Also your log shows WAN side router DoS attacks being detected and supposed to be dropped by the router there. As far as I am aware of, Eset is unaware of this activity and is only monitoring LAN side router activity. It appears the router is "leaking" WAN side DoS activity to the LAN side and this is what Eset's IDS is detecting. You would have to discuss this with Netgear as to why this might be happening. 

    One possibility is that the router has been compromised with malware. Another is the DoS attacks have overwhelmed the router's blocking capability; not a pleasant possibility. Or for some unknown reason, this is by design in regards to TCP SYN Flood attack detection. For the time being, you can modify Eset IDS behavior in regards to this detection not to constantly alert you but still block it and log it if so desired. Refer to this: https://support.eset.com/kb2939/?locale=en_US&viewlocale=en_US on how to do so. If Netgear later informs you this is desired behavior, you can change the Eset IDS actions for this activity for block, notify, and log to "No."

  13. Below is a summarize description of what is detailed in the original link posted by @Marcos:

    Quote

    A SYN Flood attack is where the attacker (there are often many of them) sends a SYN packet to the target. The target then sends an ACK back to the attacker (or the IP that was spoofed by the attacker). During normal TCP session establishment a final ACK would be sent from initiator to the target (ACK'ing the ACK). In a SYN Flood attack this final ACK is never sent by the attacker (or the spoofed IP), causing the target to hold the session half-open until it eventually times out. During such timeout periods if enough sessions can be initiated by the attacker, the targets resources will be depleted and no new connections will be able to be established - A classic example of denial-of-service.

    https://github.com/robcowart/elastiflow/issues/126

    It appears to me that your router to endpoint device communication is not functioning properly. The router is not sending the final ACK to the endpoint device. Eset's IDS protection sees this resultant activity and throws the TCP SYN Flood attack. There also could be a problem with the Win network settings on the endpoint device.

×
×
  • Create New...