I don't use this Lookout app, so I cannot tell you whether it has this hint somewhere. But I can give you some clues how to "rule out innocent apps", so you don't have to "remove all applications". With some luck, this filtering leaves only a few candidates.
First indicator you gave: It happens whenever I connect to Wi-fi/3G. So it has to be a) an app with "some WiFi permission", which also listens to the "network changed" broadcast (to put it in easy words). So first let's check for apps with matching permissions:
Guardian Droid and Permission Explorer (source: Google Play)
Two helpful apps for this are Guardian Droid and Permission Explorer, as shown in the screenshots. They help you identify apps by permissions (and also apps with excessive permissions). Taking the Permission Explorer screenshot as a base here, your suspect app should be in one (or more) of the following groups: Internet, Access_Network_state. Most likely in both: it needs to know when Internet is accessible (so it's interested in the network state), and most likely wants to access it (Internet).
With this check, you will have ruled out some apps already. Probably not enough, as many/most apps will have the Internet permission even when not requiring it themselves – to load ads. So the next step is to check which of the filtered apps are listening to the "network state changed" broadcast (an indicator that your suspect does this is that the alert is triggered immediately when WiFi was connected, if I understood you correctly).
S2 APK Viewer and App Detective (source: Google Play)
For this we take a look at S2 APK Viewer and App Detective. Both of them allow to browse the Manifest of your
.apks (Apps). Watch out for
<receiver>s, which declare what broadcasts an app is interested in.
By these steps, you will not end up with the single candidate, but rather with several. But at least you don't have to check them all. As a broadcast listener can alternatively be declared dynamically by code (instead of in the manifest), our friend might not be listed in the "reduced set" having applied all filters, but must be amongst those left over by the first (permission) scan.
Whilest not completely solving your issue, I hope this at least helped narrowing down candidates to an acceptable level.
As it turns out in this case, it still leaves ~200 candidates to check. So let me suggest something I should have thought of from the beginning: investigating Android's logs. There are multiple ways to do this, like using dedicated apps (CatLog, Gemini LogCat, and LogCat Extreme are good examples), or doing it via
adb logcat (requires ADB to be setup on your computer, see Is there a minimal installation of ADB?). If something raises a security notification, it should show up in the logs at least as warning (so you can restrict your investigation to this loglevel and higher ones). Most of the LogCat apps let you setup filters via their GUI. For the command line tool, you can take a look at its help page. Moreover, there's a nice article on "adb logcat" Command Arguments - Output Filters, which should be quite useful here.
Start the logcat viewer. If possible, clear "past entries" from the output, or set a mark (if the app offers this). After that, connect to WiFi. As soon as the warning pops up, stop log recording (or set the "end mark"). Now investigate the recorded lines. I'm positive this leaves much less than ~200 candidates – and wouldn't even be surprised you'd end up with an exact hit.