It would be possible to do this if the authentication method was designed to allow for redundancy. The simplest example would be if team members authenticated to each other with a password, but they were allowed to send redundant characters along with the password. (I'm assuming here that all teams use the same authentication method!)
So let's say the blue team password is "BERRY" and the green team password is "LEAF". Now, the string "ASDBERRYFOO" would successfully authenticate a blue team member. However, "FOOBERRYLEAF" would successfully authenticate a member to both teams! The teams don't know each others' passwords, so the latter does not look any more suspicious to anyone than the former. Eve doesn't know the passwords of red or blue teams either, so she cannot know whether that string actually includes a password to one or more teams.
Of course, this method is highly vulnerable to replay attacks. Eve can very well just go ahead and send "FOOBERRYLEAF" to anyone she might encounter, and that way she would find out that it authenticates to both blue and green teams (even if she still doesn't actually know the passwords -- they might as well be "OOBE" and "RYLEA"!).
One could try to improve the scheme by only accepting a certain authentication string once -- so if "FOOBERRYLEAF" has been used, it shouldn't work again. Alice can still create an unlimited amount of similar strings as she knows the passwords.
A better method would be to use one-time passwords so that even the "BERRY" part does not repeat.
The redundancy part is still my main issue though: why would anyone actually use a scheme where the same message could be interpreted in two different ways? Obviously my "FOOBERRYLEAF" example is too naive. I think in reality you wouldn't just concatenate strings, but you'd find some clever hash collision or something like that to achieve the same result. But I'll leave that part for others to ponder...