After few of our customers complaint about Bing PPC bot invalidating their pageviews and keep visiting their websites, we have started to find a way to block this. It messed up their analytics data by generating fake pageviews that look like a real user.
We had setup a monitor to identify pattern of this visitor in your analytics and we needed some time until we can acquire sufficient amount of data to analyze this.
They come randomly and at different IP addresses so we could not simply block IP addresses, however all of those IP addresses origin were from Microsoft Azure servers which allows us to backtrace and identify them this way. We have used data set from our database using Hitsteps too and we identified Microsoft Azure hits to be bot, and in Hitsteps, we only count real human visits. We have forbidden our tracker to track Microsoft Azure from now on, and it should not re-appear in your list of visitors anymore.
Interestingly, Microsoft use real world browser useragents which belong to his competitors. We identified useragents that belong to Safari 53 on Windows 7. Safari 7 on iOS 7 and Firefox 23 on Windows 8! We could not simply block it from user-agents due to variety.
As a reddit user put it out this way, During the editorial verification process in Bing Ads, your site may receive traffic from the Bing Ads crawler, which shows as Microsoft Azure. This crawler searches and determines the content of your website by following all of the links and branches throughout your site and pulling relevant keywords from the pages. The depth and frequency of the crawl is related to the number of ads and keywords in your ad groups. The Bing Ads crawler visits sites that it is checking in a very controlled manner. This activity should not affect servers or cause “inaccessible website” errors. (They represent a real browser, therefor made it hard for us to differentiate them from a bot at beginning.)
Bing Ads crawls your site(s) by using the destination URLs that you specify for each keyword-ad combination in your ad group. If you have large keyword lists, your destination URLs may receive hundred of clicks or more. Because this traffic can occur during a very short time, sometimes within only one or two hours, this activity may appear to be invalid activity.
Note that you are not charged by Bing Ads for this traffic, and this activity is not reported on any Bing Ads reports.
This behaviour now can be detected by Hitsteps Analytics and blocked from our users view unless they disable bot protection in their analytics setting.
We are introducing Smart Uptime Monitoring system, bundled into your Hitsteps dashboard.
Let your servers recover automatically. Know about downtimes instantly, do not let your visitors be the one who notify you about your website downtime.
By activating this service, we scan your servers and websites every minute and notify you instantly if we find out they are down. we verify each downtime from multiple countries to remove false alarms.
Upon downtime, we can notify you via Call, SMS or Email.
Additionally, you can define DNS Failover using Cloudflare or setup SSH commands to recover your failed website automatically.
This feature is available from Pro plan onward. You can find Uptime Monitoring in left sidebar of your Hitsteps Dashboard.
We’ve detected a vulnerability in LastPass which allow autofill of password into web login form right after login and right before 2nd factor authentication login.
This issue is rare and does not affect majority of LastPass users, however issue could be re-created by our team on Google Chrome running on MacOS when following environment is set:
- Make sure LastPass is logged out.
- Open a website that you have LastPass to fill up login form automatically.
- Login to LastPass and don’t check “Remember Password” (so password expire after closing chrome)
- When entering 2nd Factor code, don’t check “Remember” checkbox either (so 2nd factor login expire too. otherwise you need to wait 30 days for it to expire which you will get same vulnerability result)
- Upon successful login, you will see LastPass autofilled login form. It is all correct until here right? Yes. next steps is where issue come up.
- Completely quit Chrome browser, make sure all processes are closed.
- Open Chrome again and open that website (or any other website that have autofill for login form)
- Click on LastPass icon and login with your password.
- HERE is where problem happen!
- You are redirected to 2nd Authentication login form. but if you switch back to the website you just opened, you will see your password is autofilled. Autofilled before you login 2nd Factor Authentication form.
So here is the catch. It will only work on 1st login after a successful full login. If you don’t proceed with 2nd Factor authentication login now and close chrome again. and then re-open chrome and repeat step 7 and 8, it would not auto populate your password into web form.
We’ve reached to LastPass and hoping they react fast regarding this issue.
I just want to clarify that this is not a bug. This could be because of the Offline Cache. You may read more about here https://lastpass.com/support.php?cmd=showfaq&id=2775
But… Should not offline cache be secured via 2nd factor authentication too?
And if it is not a bug, why it happen only and only in first login after a successful login, then quitting browser and re-opening it?
If it is expected behaviour, it should always populate login form right after entering login information and before entering 2nd factor code, but now it only auto populate on first try.
Even closing and re-opening browser won’t trigger auto populate anymore.